An "orthogonal" way of using libpam

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello!

Sorry if that has been discussed before, it is kind of wish
that would make libpam useful in less usual but real situations:

 - libpam is targeted at providing authentication and authorization for
the puproses of a host, that means all decisions are done in advance by
the superuser, on per host basis

Sometimes it is not the host superuser but a user who should
make the decisions. The typical example is a screen lock command.

In a networked environment it locks not only the local resources (the
local resources may indeed be very limited!) but all the resources the
user session can access, that is, it locks the user credentials of
all kinds, her uid at the local system, her AFS/DFS/Coda tokens, her
ssh-agent, her SMBFS connection and so on.

These resources are not necessarily under the local superuser jurisdiction
(even if the superuser technically could steal them), and it is not good
that the user herself has no control over the lock.

With distributed filesystems a user can have an own environment usable on
computers under different administration realms. I am running such one
myself.
Then while I can count with /bin/sh being in place always, I cannot be
sure that there will be say /etc/pam.d/{xscreensaver,vlock} or even
working "other"...

Nevertheless I do not want to hack a separate *program* that would talk to
the authentication service of my choice (say look into $HOME/etc/passwd
for my screenlock password hash, not really :). I want to use the
wonderful libpam and the modules!

The small problem is that I would have to recompile the library for each
user to let it look for its configuration and the modules at
"non-standard" places. (you see I am not the only user with such needs)

Hence, I would advocate for moving the configuration from the compilation
phase to the runtime one, like if compiled with --with-runtime-config
it would look at $PAM_CONFIG and use it in some way to find
 - pam.{d,conf}
 - security/modules
 (have I forgotten something?)

Of course it is not suitable for setuid binaries like login, but
1. a setuid check may be done before looking for PAM_CONFIG,
2. --without-runtime-config will be exactly as safe as it is now

Any objections? Any support?! :-)

Thanks for the reading!
--
Ivan



_______________________________________________

Pam-list@redhat.com
https://listman.redhat.com/mailman/listinfo/pam-list

[Index of Archives]     [Fedora Users]     [Kernel]     [Red Hat Install]     [Linux for the blind]     [Gimp]

  Powered by Linux