Re: perl or libc6 bug?: getpwnam('root') in NIS environment
In article <cistron.19990416061857.H21088@frederick.itri.loyola.edu>,
Michael Stone <firstname.lastname@example.org> wrote:
>On Fri, Apr 16, 1999 at 09:46:26AM +0200, Heiko Schlittermann wrote:
>> Ooops, so an xlock would have problems in NIS enviroment with security
>> based on ports?
>xlock won't work unless you make it setuid.
Yep. The only way around this is a daemon running suid root which you
can feed a loginname/passwd and which says ok/not ok.
Now Sun did this basically with their passwd.adjunct (sortof shadow) file.
The password file would contain ##username in the password field, or
at least getpwnam() would return that.
The crypt() function is normally called as crypt(passwd, crypted_passwd).
The libraries crypt() function reckognizes the ##username as crypted
password, and since it has the username and password now call the
authentication daemon. If it is the right password crypt()
returns ##username as well, tricking userland into the fact that the
original crypted password and the result from crypt() are the same.
I _think_ most of the framework for this is in glibc 2.1 as well, perhaps
someone should talk to the glibc people to see if something like this
could be implemented ?
It would have to be a special daemon, a small standalone setuid application
that checks the password (with a small delay of say 0.1 seconds) would
do as well (I dislike too many daemons running)
Indifference will certainly be the downfall of mankind, but who cares?