brian@neptune.AMD.COM (Brian McMinn) (10/28/87)
Why are new spool directories owned by root instead of news? When a new news group is created, I run inews -C to create the entries in the active and other files. This apparently does not create the directory in /usr/spool/news/whatever. Everything works fine until an article is posted from here into the new group. If no articles for that newsgroup have been received, then Pnews screams about a missing spool directory. If some articles have been received, then Pnews screams about not being able to write into the directory. Seems that the directory was created by and is owned by root instead of news. Our inews program is suid "news". Any help would be appreciated. Brian -- Brian McMinn brian@neptune.AMD.COM Advanced Micro Devices Austin, Texas 1-(512)-462-5389
dave@lsuc.UUCP (11/01/87)
In article <474@neptune.AMD.COM> brian@neptune.AMD.COM (Brian McMinn) writes: >Why are new spool directories owned by root instead of news? > > Seems that the >directory was created by and is owned by root instead of news. > >Our inews program is suid "news". Any help would be appreciated. On some versions of UNIX (including vanilla v7), setUID is disabled for root. There's actually code in the kernel that doesn't do what the setUID bit does if it's rn by root. I don't know why this "feature" was first installed, but it's likely the cause of your problem. root is running inews as root; then later, someone runs inews as news or uucp, and can't write into the directory. Just make sure that you don't run inews from crontab or as root, if you have this feature. If crontab is the problem, just stick a "su news" in front of the code that is ultimately running inews (rnews -U or whatever). David Sherman The Law Society of Upper Canada Toronto -- { uunet!mnetor pyramid!utai decvax!utcsri ihnp4!utzoo } !lsuc!dave Pronounce it ell-ess-you-see, please...
rick@seismo.CSS.GOV (Rick Adams) (11/03/87)
For a long time, inews has checked to see if it was running as root and if it was, assumed the worst and did setuid() calls to give it the intended permissions. This "shouldn't" be the problem. --rick
slb@boole.acc.virginia.edu (sandy) (11/05/87)
In article <474@neptune.AMD.COM> brian@neptune.AMD.COM (Brian McMinn) writes: >Why are new spool directories owned by root instead of news? > > Seems that the >directory was created by and is owned by root instead of news. > >Our inews program is suid "news". Any help would be appreciated. I think the problem is that inews and mkdir are both setuid programs. When inews runs the real id is whoever called inews, and the effective id is news (or whoever you use at your site). When mkdir is called, the effective uid becomes root and the real uid is still whoever called inews, so that person ends up owning the directory. Inews tries to get around this by doing a setuid(geteuid()) when it is run by root, but many systems (like SYSV) don't allow this. Some suggestions for workaround are given in section 7.3 of the Installation Guide. sandy -- sandy bryant slb@virginia.edu uunet!virginia!slb
greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) (11/06/87)
In article <44176@beno.seismo.CSS.GOV> rick@seismo.CSS.GOV (Rick Adams) writes: >For a long time, inews has checked to see if it was running as root and >if it was, assumed the worst and did setuid() calls to give it the >intended permissions. > >This "shouldn't" be the problem. Unfortunately, I believe it is the problem. We had the same problem here (news directories being created owned by root) and it was eventually traced to uucp being invoked by root when running as an ethernet server. The generic ethernet server (necessarily run as root) executed a simple set-UID program that did a setuid(geteuid()) and then executed uucico. We found that, for some reason, a set-UID program invoked by root doesn't operate the same way as a non-set-UID program; something gets confused. We ended up having to run the intermediate program as a non-set-UID program; it did a stat() of uucico to find out the UID/GID to set itself to. The above is for System V; if you have a UCB system, your mileage may vary. If somebody has sources, I'd be curious as to just what is going on; I can't explain it, and once the "cure" of the non-set-UID intermediate program was discovered, I stopped pursuing the problem. -- -- Greg Noel, NCR Rancho Bernardo Greg.Noel@SanDiego.NCR.COM or greg@ncr-sd
wcs@ho95e.UUCP (11/08/87)
In article <1877@ncr-sd.SanDiego.NCR.COM> greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) writes: :In article <44176@beno.seismo.CSS.GOV> rick@seismo.CSS.GOV (Rick Adams) writes: :>For a long time, inews has checked to see if it was running as root and :>if it was, assumed the worst and did setuid() calls to give it the :>intended permissions. :>This "shouldn't" be the problem. :directories being created owned by root) and it was eventually traced to uucp :... uucp being invoked by root when running as an ethernet server. :... We found that, for some reason, a set-UID program invoked by root doesn't :operate the same way as a non-set-UID program; something gets confused. :program as a non-set-UID program; it did a stat() of uucico to find out the :UID/GID to set itself to. System V has several "features" in its setuid-handling. One obvious workaround is for the news code to chown directories to news when it creates them. Obviously this requires a #define SYSV, unless 4.3BSD now lets mere mortals use chown? -- # Thanks; # Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs