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

Re: xlockmore (pam)



Erik Troan wrote:
> This is just a sketch of a not-at-all thought out idea.
> 
> How about writing a program designed to be set[ug]id so it can read
> /etc/shadow. When it gets run, it exits if euid != ruid, otherwise is
> prints the encrypted password for the current user to the display. Giving
> a user access to his own password isn't really a security problem (other
> then people leaving terminals logged in, but that creates a horde of larger
> problems), and it would allow pam_unix.so (or some other module) to run
> that program to get the auth token if permission to open /etc/shadow is
> refused.
> 

Unfortunately, shadow may optionally contain md5 etc passwords.. So
unless the application you propose know's as much as the
pam_whatever.so that xlock is configured to use, we're going to have
trouble.

The idea of having a helper program though is nice. Perhaps we might
have an executable (suid) called 'passme', that reads a single
(cleartext password) line from stdin and exits with 0 if the password
matches that of the user (deduced from ruid), and 1 if it doesn't.

'passme' could be configured to use pam (of course) but there is a
little difficulty involved in simultaneously reusing the same
executable for multiple authentication schemes (for example, xlock
uses pam_unix and being run as the user, it would need 'passme'
configured for pam_unix too. But what if the sys-admin wants to use
pam_smartcard with vlock at the same time..?)

Perhaps the 'passme' program can somehow deduce the service name of
the parent process (with a command-line argument?) and initialize
libpam with that?

How about this?

Andrew



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