[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: saved IDs and exec (standard violation?)

From: Marcus Brinkmann
Subject: Re: saved IDs and exec (standard violation?)
Date: Sun, 12 May 2002 14:24:24 +0200
User-agent: Mutt/1.3.28i

On Sat, May 11, 2002 at 10:28:19PM -0400, Roland McGrath wrote:
> Just to keep the record straight, I was talking about having the filesystem
> implementing file_exec do it (that's where the only auth diddling is, the
> exec server doesn't do it).  But having the user do it is a better plan.  I
> don't know why I didn't think of that in the first place.  It avoids the
> whole issue of the filesystem having to either trust or deal with a
> user-supplied auth port even with a svuid/svgid change is required.

I agree.  This was actually my first thought about how to fix it ("It seems
to be merely an issue of the default behaviour in glibc, ..."), because
obviously the task already has all the privileges it is leaking, and as such
there is no real security leak in the system, but only at the user's side.

In Unix, there doesn't seem to be a way to change the saved ID other than
changing the effective ID and do a fork().  In the Hurd, we can do better,
it seems.  Maybe we can even have setsuid,getsuid,setsgid,getsgid?  Seems to
be a straightforward addition at least, although I am not sure of what use
it will be when exec resets them.

> The only drawback I see is in the case when svuid!=euid or svgid!=egid, and
> you are executing an sugid file.

I agree, this is not a common thing to do at all.  Might happen with a game
that starts a sound daemon, or things like that.


`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org

reply via email to

[Prev in Thread] Current Thread [Next in Thread]