issetugid() for other procs

Zane C.B. v.velox at vvelox.net
Sun Oct 7 13:49:13 PDT 2007


On Sun, 7 Oct 2007 21:53:14 +0300
Kostik Belousov <kostikbel at gmail.com> wrote:

> On Sun, Oct 07, 2007 at 01:39:17PM -0500, Zane C.B. wrote:
> > On Sun, 7 Oct 2007 21:04:02 +0300
> > Kostik Belousov <kostikbel at gmail.com> wrote:
> > 
> > > On Sun, Oct 07, 2007 at 12:28:05PM -0500, Zane C.B. wrote:
> > > > On Sun, 07 Oct 2007 18:25:57 +0200
> > > > Jan M?nther <jan.muenther at nruns.com> wrote:
> > > > 
> > > > > man getuid, man geteuid.
> > > > 
> > > > This does work for other procs, only the one that is calling
> > > > it.
> > > > 
> > > > Like I said initially I am looking to check if another proc
> > > > has run setuid, seteuid, or been executed or forked by one
> > > > that has.
> > > 
> > > Note that what you trying to do is racy by definition.
> > 
> > Why is that? It seems like something that be useful instead of
> > something taboo. My interest in it is I am writing a database
> > connector interested in making it paranoid as possible.
> 
> Because you do not control the execution of the other process. As
> consequence, value you get is outdated even before you start using
> it.

Yeah, this is another thing I need to look into. I need to look into
how to go about figuring out if a program can be trusted or not. Just
got thinking that any thing that has been run will have been run by
something that ran it setuid.

The project I am looking into is creating a database connector
daemon and related pam module. When a user logs in their password
they used is shoved into the PAM module and then a application can
be used for accessing the database.

Any thoughts in that area?

My large interest in this is in regards to LDAP.


More information about the freebsd-security mailing list