Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!harvard!bbnccv!bbncca!wanginst!vaxine!encore!necis!yde
From: yde@necis.UUCP (David Elins ext. 220)
Newsgroups: net.bugs.uucp,net.news.adm
Subject: Re: mkdir() under suid
Message-ID: <244@necis.UUCP>
Date: Tue, 11-Feb-86 09:02:14 EST
Article-I.D.: necis.244
Posted: Tue Feb 11 09:02:14 1986
Date-Received: Fri, 14-Feb-86 06:34:46 EST
References: <495@kepler.UUCP>
Reply-To: yde@necis.UUCP (David Elins ext. 220)
Organization: NEC Information Systems
Lines: 44
Xref: linus net.bugs.uucp:651 net.news.adm:499

In article <495@kepler.UUCP> mojo@kepler.UUCP (Morris Jones) writes:
>Problem: Directories created by programs running under a user id
>	 different from the real user id (suid bit set) are owned
>	 by the real user and not the effective user.
>...
>But the news documentation hints at another solution -- building
>your own version of mkdir().  Did you do this?  Will you share it
>with me?

I never saw this documentation and didn't know that the directory
ownership problem was known.

Anyway, I fixed it on our 2.10.3 news installation and will be
happy to send the fix to anyone who requests it.

By the way, I did not change mkdir, but changed the portion of inews.c
that calls mkdir. On USG systems it was changing the ownership of directories
it created before it actually created the directories.

There was another problem I had to fix also: the expire program supports
a -n option to specify newsgroups that are to be expired. It wasn't parsing
these newsgroups as it had in news 2.10.2, and nothing was being expired.
I don't know if this was a bug or a feature as it could be worked around
by invoking expire with a slightly different syntax (-n newsgroup1,newsgroup2,)
but I will supply that fix too, if anyone wants it.

Now the obligatory question (probably should go to unix-wizards,
but this is my first posting, I don't want to inundate the net):

In fixing the directory ownership problem mentioned above, I noticed
that if a process's effective uid was non-zero but the real uid was
zero (root), a setuid(0) system call failed. The documentation implies
that if the argument to setuid() is the process's real uid, setuid
should succeed (and set the effective uid = the arg = the real uid).
This works as advertised if the real uid is non-zero (e.g. uucp) and
it works as advertised on our system III systems, but not on system V.
I know how to fix it, but I would like confirmation from someone who has
been working with Unix longer than I that this really is a bug and not
an intentional exception, before I do it.


Thanks in advance.

david