[PATCH] pam_exec questions and possible patch

[Aaron Cohen]

> > 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?)

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?

3) Let's look at the other scenario
# User runs an executable setuid to something other than root
[user]$ chown user2 testuid
[user]$ chmod u+s testuid
[user]$ testuid

--- The calling process has: Ruid = user, Euid = user2
--- After setuid(geteuid()), the pam_exec'ed program will have: Ruid =
user, Euid = user2 (no change)

> > It seems slightly hairy to me, because for instance if
> > it's in the auth section a user could cause a program to be executed
> > by another user by only unsuccessfully attempting to log in as that
> > user.
>
> Only an admin can configure this module, so it depends on what he
> allows and what not.
>
> > Secondly, is there any way to distinguish in the exec'ed program that
> > the session is being opened or closed?  I've finally created a simple
> > patch that defines a PAM_SESSION_ACTION environment variable in the
> > executed subprocess so that my script can do the correct actions.
> >
> > Thirdly, does the seteuid option actually work correctly?
>
> Yes, it does. Please also look at the example section of the manual
> page.
>
> > 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(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.


> > My patch changes this by setting the effective
> > userid of the subprocess to the user id of the user who's session is
> > being created if this option is specified.
>
> This change breaks all available configurations, especially the example
> from the manual page.
> Please introduce new options, not change existing one.
>

Ok, I've introduced a new option "run_as_user" that takes an optional
user parameter.  With none specified it sets the uid to the user being
authenticated.  I've also added environment variables to specify each
of the various pam hooks being called so that for instance one shell
script can be used to do all pam related activity you'd like.

One thing I didn't take the time to figure out was how to specify that
the right side of an assignment is optional in docbook.  So it looks
slightly funny with an extra space in the man page.  I'd actually like
it to look like [run_as_user[=_username_]].

Thanks,
Aaron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pam_exec.patch
Type: text/x-patch
Size: 7538 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pam-list/attachments/20070326/6f4b096b/attachment.bin>