[PATCH] pam_exec questions and possible patch

Thorsten Kukuk kukuk at suse.de
Mon Mar 26 13:38:02 UTC 2007


On Mon, Mar 26, Aaron Cohen wrote:

> >> I'm currently trying to use pam_exec to call a script to synchronize
> >> my home directories with a central server and have come across a
> >> couple of issues.
> >>
> >> Firstly, does pam_exec make any sense outside of the "session" section
> >> of pam.conf?
> >
> >Yes, it makes. Only look at the example section of the manual page.
> >
> 
> The example section of the man page unfortunately doesn't make sense to me.
> 
> 1) make -C /var/yp doesn't have any effect for me because I have no
> makefile there and I'm not entirely sure what effect you envision it
> having (what program should I assume is being run and what permissions
> does it require?)

For example update NIS databases after password changes.
 
> 2) Let's look at what actually happens if we invoke the passwd program
> and have a call to some arbitrary pam_exec module with the "seteuid"
> specified.
> 
> [user]$ passwd
> 
> --- The calling process has: Ruid = user, Euid = root (because passwd
> has setuid filesystem attribute and is owned by root)
> --- After setuid(geteuid()), the pam_exec'ed program will have:  Ruid
> = root, Euid = root
> 
> I'm not convinced that makes any sense... what's the goal?

To allow to run the commands as root if a normal user calls setuid
applications, else they will only run with the users UID.

> >> It seems to
> >> me that it simply sets the effective user id to whatever the effective
> >> user id already was.
> >
> >Correct, it sets the effective user id to the one of the calling
> >application.
> >
> 
> Please verify this?  setuid sets the effective user id.  geteuid
> returns the effective user id.

setuid sets the real user id, not the effective one.
 
> setuid(geteuid()) seems an obvious no-op to me (unless the calling
> application happens to have euid of root, and in that case it's the
> real user id that's being set, to root) and a test application I wrote
> seems to confirm this.

Your own argumentation above shows you that it is no no-op. Look at
your own example, something changes, which is important if you call
executeables after fork() or with exec*().

  Thorsten

-- 
Thorsten Kukuk, Project Manager Base System, Release Manager SLES
SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg
GF: Markus Rex, HRB 16746 (AG Nuernberg)




More information about the Pam-list mailing list