[news.software.b] C News and setuid

neulynne@uts.uni-c.dk (Mogens Lynnerup) (02/01/91)

In relay/relaynews.c C News wants to do a setuid(geteuid). Could someone
please tell me reason for this. Why does one want to set the real uid to the
effective?

On our machine, an Amdahl running UTS (some kind of Sys 5.3), it doesn't work,
and so far i've only found one machine, an Alliant FX8 running BSD, where it
works. I've tried an IBM RS/6000 running AIX 3.1, an Apollo DN3500 running
Domain/OS 10.2 and a Silicon Graphics running IRIX System V.3.

Mogens
-- 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+      Mogens Lynnerup                                                        +
+      UNI-C Aarhus, Danish Computing Centre for Research and Education.      +
+      Olof Palmes Alle 38, DK 8200 Aarhus C.                                 +
+      Phone: +45-86-784444                                                   +
+                                                                             +
+      E-Mail: neulynne@uts.uni-c.dk or neulynne@vm.uni-c.dk                  +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

geoff@zoo.toronto.edu (Geoffrey Collyer) (02/02/91)

Mogens Lynnerup:
> In relay/relaynews.c C News wants to do a setuid(geteuid). Could someone
> please tell me reason for this. Why does one want to set the real uid to the
> effective?

Some older Unixes, notably V7 and probably System III, present a problem
when trying to make a directory from a setuid program.  There is no mkdir
system call and the mkdir command is setuid-root and chowns the resultant
directory to its real uid.  A setuid program such as relaynews invoking a
setuid-root mkdir command will result in mkdir chowning the directory to
relaynews's real uid, not its effective uid ("news"), which will probably
cause the resultant directory to be unwritable by relaynews.  At least on
4BSD and our local V7 systems at the time, setuid(geteuid()) makes
relaynews's real uid "news" and thus mkdir gets the ownership right.

> On our machine, an Amdahl running UTS (some kind of Sys 5.3), it doesn't
> work, and so far i've only found one machine, an Alliant FX8 running BSD,
> where it works. I've tried an IBM RS/6000 running AIX 3.1, an Apollo
> DN3500 running Domain/OS 10.2 and a Silicon Graphics running IRIX System
> V.3.

Years ago, when relaynews was written, it appeared that all modern Unixes
were permitting setuid(geteuid()) and doing the obvious and sensible
thing.  Alas, that was before the SVID and SysV (and now POSIX) went mad
and started inventing saved-userid-at-exec and other cracked schemes for
muddying a previously clean and simple mechanism for the sake of some
ill-defined and small class of problems.  We don't have many pure System
V's around here, since our machines tend to need TCP/IP and Ethernet
support, so it's hard to be sure just *what* a modern System V does with
setuid(geteuid()), but judging from the complaints we have had, it
doesn't set the real uid (i.e. it botches the setuid() call) or getuid()
doesn't return the real uid (a different botch).

I'm getting tired of the increasing breakage in SysV and the standards,
so I'm retreating further and further from the exotic periphery of Unix
system calls to avoid being bitten as standards organisations break
promises made by Unix to programmers over at least the last 15 years
(`existing practice: just say no').  My current plan is to get rid of
all uid setting in relaynews and setnewsids and require that relaynews
always be invoked with real uid of "news" (or local equivalent).  This
will have the beneficial side-effects of eliminating a build question,
simplifying relaynews and fixing a festering portability problem.
-- 
Geoff Collyer		utzoo!geoff, zoo.toronto.edu!geoff

rees@pisa.ifs.umich.edu (Jim Rees) (02/03/91)

In article <1991Feb2.060633.23602@zoo.toronto.edu>, geoff@zoo.toronto.edu (Geoffrey Collyer) writes:

  Mogens Lynnerup:
  > In relay/relaynews.c C News wants to do a setuid(geteuid)...
  > ...it doesn't work...  I've tried ... an Apollo
  > DN3500 running Domain/OS 10.2 ...

  ...it's hard to be sure just *what* a modern System V does with
  setuid(geteuid()), but judging from the complaints we have had, it
  doesn't set the real uid (i.e. it botches the setuid() call) or getuid()
  doesn't return the real uid (a different botch).

I wrote the getuid() and setuid() system calls used in Apollo Domain/OS
10.2.  In Berkeley (real) Unix, setuid() sets both real and effective IDs.
In System V, it doesn't.  I don't remember if there is any way to set the
real user id in System V.  Seems to me there was some stupid "security"
reason for this, but we never tried to figure out System V, we just
implemented it.  Everyone in R&D at Apollo used Berkeley Unix (both flavors
run on the same machine at the same time).

neulynne@uts.uni-c.dk (Mogens Lynnerup) (02/04/91)

>>>>> On 2 Feb 91 21:46:48 GMT, rees@pisa.ifs.umich.edu (Jim Rees) said:

Jim>   ...it's hard to be sure just *what* a modern System V does with
Jim>   setuid(geteuid()), but judging from the complaints we have had, it
Jim>   doesn't set the real uid (i.e. it botches the setuid() call) or getuid()
Jim>   doesn't return the real uid (a different botch).

Well that's more or less the same conclusion I've come up with. Maybe this 
stuff about being able to/needing to do the setuid(geteuid) the way that C
News expects it to, is really not a question about old versus new UNIX systems
but a question about SYS V versus BSD.

And now to my original question. Why will one want to set the read UID equal
the effective UID? I've had C News running for about nine months with the
setuid(geteuid) stuff disabled and as fare as I can see everything works.
-- 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+      Mogens Lynnerup                                                        +
+      UNI-C Aarhus, Danish Computing Centre for Research and Education.      +
+      Olof Palmes Alle 38, DK 8200 Aarhus C.                                 +
+      Phone: +45-86-784444                                                   +
+                                                                             +
+      E-Mail: neulynne@uts.uni-c.dk or neulynne@vm.uni-c.dk                  +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

fitz@wang.com (Tom Fitzgerald) (02/05/91)

geoff@zoo.toronto.edu (Geoffrey Collyer) writes:
> My current plan is to get rid of
> all uid setting in relaynews and setnewsids and require that relaynews
> always be invoked with real uid of "news" (or local equivalent).  This
> will have the beneficial side-effects of eliminating a build question,
> simplifying relaynews and fixing a festering portability problem.

So will inews invoke newsspool instead of relaynews and leave the article
to be unbatched later?

---
Tom Fitzgerald   Wang Labs        fitz@wang.com
1-508-967-5278   Lowell MA, USA   ...!uunet!wang!fitz

henry@zoo.toronto.edu (Henry Spencer) (02/06/91)

In article <b0cutv.ete@wang.com> fitz@wang.com (Tom Fitzgerald) writes:
>So will inews invoke newsspool instead of relaynews and leave the article
>to be unbatched later?

Something like that, probably; details are still being sorted out.
-- 
"Maybe we should tell the truth?"      | Henry Spencer at U of Toronto Zoology
"Surely we aren't that desperate yet." |  henry@zoo.toronto.edu   utzoo!henry

clewis@ferret.ocunix.on.ca (Chris Lewis) (02/06/91)

In article <4f948f06.1bc5b@pisa.ifs.umich.edu> rees@citi.umich.edu (Jim Rees) writes:
>In Berkeley (real) Unix, setuid() sets both real and effective IDs.
>In System V, it doesn't.  I don't remember if there is any way to set the
>real user id in System V.

If your effective ID is root, setuid(anything) will work and will set
both the real and effective id's.  That's what the Cnews kludge setnewsids
does, and is how su manages to do it.

>Seems to me there was some stupid "security" reason for this,

I'd sure love to know what it was - I've had to work around this many times.
-- 
Chris Lewis, Phone: (613) 832-0541, Internet: clewis@ferret.ocunix.on.ca
UUCP: uunet!mitel!cunews!latour!ecicrl!clewis
Moderator of the Ferret Mailing List (ferret-request@eci386)
Psroff enquiries: psroff-request@eci386, current patchlevel is *7*.

woods@eci386.uucp (Greg A. Woods) (02/08/91)

In article <1991Feb2.060633.23602@zoo.toronto.edu> geoff@zoo.toronto.edu (Geoffrey Collyer) writes:
> Years ago, when relaynews was written, it appeared that all modern Unixes
> were permitting setuid(geteuid()) and doing the obvious and sensible
> thing.  Alas, that was before the SVID and SysV (and now POSIX) went mad
> and started inventing saved-userid-at-exec and other cracked schemes for
> muddying a previously clean and simple mechanism for the sake of some
> ill-defined and small class of problems.  We don't have many pure System
> V's around here, since our machines tend to need TCP/IP and Ethernet
> support, so it's hard to be sure just *what* a modern System V does with
> setuid(geteuid()), but judging from the complaints we have had, it
> doesn't set the real uid (i.e. it botches the setuid() call) or getuid()
> doesn't return the real uid (a different botch).

Well, just to pick a nit, the problems "solved" by the SVID specified
behavior of setuid() are very well defined, and quite real.

Specifically, without "saved user(group)-id at exec", accountability
is not achievable.  In addition, the new behavior allows a process to
switch between its real and effective user(group)-id without starting
with an effective uid of 0, and without forking.  Some will argue that
none of these features are necessary....

And, in fact it is quite clear from the SVID exactly what modern SysV
does with setuid(geteuid()).

In addition I argue that the SVID mechanism is quite clean and
elegant, and is certainly much more so than the mess in BSD-4.2.
It is also more upwardly compatible.

The real botch was with the failure to provide a mkdir() call
simultaneously with the new setuid() behavior (though this was fixed
with the release of SVID Issue 2 and SysVr3.0).

BTW, though the SVID was published in 1986, I've just peered at a copy
of the XENIX 3.0 setuid()/setgid() manual page which was printed in
1984.  It is almost identical to the SysVr3.0 (1988) manual page.
(SysVr3.0 adds an error return EINVAL for uid or gid being out of
range.)  (This version of XENIX did not have a mkdir() either.)
I would seem to me to be quite logical to assume that if UNIX 3.0 (and
thus XENIX 3.0) had this "new" behavior, it would be around for some
time, though I suppose one might have ignored logic if one didn't want
UNIX 3.0 to survive.
-- 
							Greg A. Woods
woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP		ECI and UniForum Canada
+1-416-443-1734 [h]  +1-416-595-5425 [w]  VE3TCP	Toronto, Ontario CANADA
Political speech and writing are largely the defense of the indefensible-ORWELL

henry@zoo.toronto.edu (Henry Spencer) (02/21/91)

In article <NEULYNNE.91Feb1154357@uts.uni-c.dk> neulynne@uts.uni-c.dk (Mogens Lynnerup) writes:
>In relay/relaynews.c C News wants to do a setuid(geteuid). Could someone
>please tell me reason for this. Why does one want to set the real uid to the
>effective?

Because on some old systems, there is no other way that relaynews, running
setuid, can create directories that belong to "news".

Revised approaches to this are being studied.
-- 
"Read the OSI protocol specifications?  | Henry Spencer @ U of Toronto Zoology
I can't even *lift* them!"              |  henry@zoo.toronto.edu  utzoo!henry