exec after seteuid
Pierre A. Humblet
Mon Jun 9 13:33:00 GMT 2003
Corinna Vinschen wrote:
> > It seems to work fine but it requires login.exe changes. It's
> > not just a question of security. ash does not setuid, while bash
> > setuid(getuid()), i.e. just the opposite of what we need.
> I'm wondering why a shell should use setuid at all. It's not the
> task of the shell to do this, it's supposed under the environment
> it gets. So this is entirely the task of the processes which
> eventually start a shell (login, rshd, sshd, etc.)
I agree 100%. If you look in bash code there is some explanation,
involving a "privileged mode" (undocumented?). I don't recall the
> > While I was looking at the most recent login.c I saw that you have
> > added a seteuid (priv_uid). Ideally, shouldn't it still be effective
> > while calling dolastlog()? It's weird that the Berkeley code didn't do
> I've uploaded a new login which does that.
OK, will try later.
> > that. There is also the issue raised by Takashi Yano on the list.
> Which is not related to using the wrong token. I've written something
> on the cygwin ML.
Are you running with gid 544 by any chance?
What I saw in login.exe while stracing my patch was
seteuid(new user) <= uses token from login with password
seteuid(18) <= creates a new token, discards token from login
seteuid(new user) <= creates new token.
If the first setegid was a 544, the seteuid(18) would reuse the process
token and the final seteuid() would use the token from the login with
Around 4:00 GMT there were exim related messages about setuid not working.
It was on a Windows 2003 Enterprise. Is that the same as a Windows Server
2003? We have had reports of problems with that one.
Please have a look, for the moment I can't spend any time on these matters.
More information about the Cygwin-patches