Thorsten, please read the setuid(2) man page!
DESCRIPTION
setuid() sets the effective user ID of the current process. If
the effective UID of the caller is root, the real UID and saved
set-user-ID are also set.
On 3/26/07, Thorsten Kukuk <kukuk@xxxxxxx> wrote:
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)
_______________________________________________
Pam-list mailing list
Pam-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/pam-list
_______________________________________________
Pam-list mailing list
Pam-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/pam-list
