On Fri, 27 Jan 2006 16:17:46 +0100, Thorsten Kukuk wrote: > You don't need super-user rights, you only need the correct rights. And > this depends on which mode and owner/group /etc/shadow has. With > super-user rights you can of course always read it. Okay, now I understand what you meant. It is true that the permissions shadow file COULD be anything, however, it is traditional (I expected standard) that it be owned by root:root with permissions 0400. If not, it loses the whole point of the shadow file -- hiding passwords from regular users. Should not pam_unix EXPECT traditional permissions on /etc/shadow, given that it is the "standard Unix authentication module"? >> For processes that do not have an effective root uid (e.g. xscreensaver >> installed without setuid root), the password lookup via the shadow >> routines WILL fail. > > Depends on the distribution and the configuration. On SuSE Linux it will > not fail, all screensavers have the rights to read /etc/shadow, but not to > modify it. I am running fedora core 3 and RHEL4. Here screensavers do not have the rights to read /etc/shadow -- they rely on pam_unix to use the helper binary. On SuSE, what allows this? setuid screensaver binary? More open permissions on /etc/shadow? Other ACL mechanism? Even then, from a security perspective, it comes down to what to you trust more to access the shadow file: the screensaver, or the pam_unix helper binary? I personally trust the latter, otherwise I would just enable the screensaver setuid root. Perhaps there should be an option to tell pam_unix to only use the helper binary. That way, when the sys admin knows that the service will fail without it (due to the configuration), this option can be used to avoid trying to authenticate without the helper. Jon _______________________________________________ Pam-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/pam-list
