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

Re: xlockmore (pam)



On Mon, 9 Sep 1996, Erik Troan wrote:

> 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.

Has anyone thought of the efficiency implications of this approach? Sure,
I know Linux is supposed to be super-fast and all, but in My Real World
(e.g. my 8M home machine ;-) spawning off processes left and right is
probably not a good idea. As little overhead as possible should be
dedicated to authentication - decreasing its speed and increasing its
memory usage will slow down the system for this often-done operation. 
After all, not everyone is running a Turing machine... 

What is wrong with just plain using getpwnam() and getspnam()? If they
fail then obviously you don't have read permissions 

One thing that I *would* like to see is the ability for a module to know
the exit statuses of all previous modules. That way we could have a
logging-and-locking module that just handles things for *all* modules in a
reasonable fashion. And if the user didn't feel the need for the extra
overhead, they could just eliminate it from /etc/pam.conf. That's what the
config file is there for, after all.

-- Elliot

"Have you ever had a microchip implanted in your skull so the government
can keep track of your every move? You will! And the company that will
bring it to you is AT&T"




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