afc@shibaya.lonestar.org (Augustine Cano) (03/23/91)
When I first ran the COPS security package on my 3b1, I got a report more than 250 lines long. Most of the entries were about files and directories being world-writable. Surprisingly, the following few commands eliminated the vast majority. chmod o-w / /usr /usr/bin /usr/adm /usr/lib /usr/spool /usr/spool/news chmod o-w /usr/local /usr/local/bin /usr/local/lib /. /.. /etc/daemons chmod o-w /.phdir /etc/timedsply /usr/lib/cron /usr/lib/dwb /usr/lib/macros chmod o-w /usr/lib/me /usr/lib/ms /usr/lib/news /usr/lib/newsbin chmod o-w /usr/lib/nterm /usr/lib/spell /usr/lib/tabset /usr/lib/tmac chmod o-w /usr/lib/ua One directory that CANNOT be treated in this manner is /usr/spool/uucp. I tried it and kermit couldn't then set or clear locks. The COPS security report is now down to the following: (actual COPS output follows '>', my comments follow each (group of) entry(ies)) > Warning! Root does not own the following file(s): > found found found /bin Is this of any consequence? > Warning! /usr/spool/uucp is _World_ writable! This one has to be ignored; as I said above certain programs might not be able to access locks if this is changed. > Warning! /etc/drvtab is _World_ writable! > Warning! /etc/inittab is _World_ writable! > Warning! /etc/wtmp is _World_ writable! Does anybody know if this has to be so? (particularly for /etc/wtmp). > Warning! /usr/adm/NBS.log is _World_ writable! > Warning! /usr/adm/UNIX.log is _World_ writable! > Warning! /usr/adm/cronlog is _World_ writable! > Warning! /usr/adm/drv.log is _World_ writable! > Warning! /usr/adm/sulog is _World_ writable! > Warning! /usr/adm/unix.log is _World_ writable! Log files... the security risk coming from here is, even in the worst case, minimal. > Warning! /usr/lib/crontab is _World_ readable! > Warning! /usr/adm/sulog is _World_ readable! Should anybody care about these two? COPS output is looking more and more like lint... > Warning! File /dev/console (in /etc/rc*) is _World_ writable! > Warning! File /dev/window (in /etc/rc*) is _World_ writable! > Warning! File /usr/lib/ua/.blanktime (in /etc/rc*) is _World_ writable! > Warning! User uucp's home directory /usr/spool/uucppublic is mode 0777! > Warning! User nuucp's home directory /usr/spool/uucppublic is mode 0777! Of course, since all uucp accounts have the same home directory, the same message appeared once for each uucp-connected machine. > Warning! /usr/lbin/uudecode creates setuid files! This, according to the documentation, is pretty common, but without re-inforcing other problems, seems to be ok. Comments anyone? Most of these "problems" (corrected and remaining) originated with the standard installation of the standard unix pc software, so it's likely you also have them. Whether they can be safely ignored is up to you... Stay tuned for coming attractions: AT&T external monitor for the unix pc? -- Augustine Cano INTERNET: afc@shibaya.lonestar.org UUCP: ...!{ernest,egsner}!shibaya!afc
dnichols@ceilidh.beartrack.com (DoN Nichols) (03/27/91)
In article <1991Mar23.004007.2024@shibaya.lonestar.org> afc@shibaya.lonestar.org (Augustine Cano) writes: >When I first ran the COPS security package on my 3b1, I got a report more >than 250 lines long. Most of the entries were about files and directories >being world-writable. Surprisingly, the following few commands eliminated >the vast majority. You'll also have problems with newer programs which are suid or sgid. As they pass the age of six months, the format of the 'ls -l' output will change. This will be reported as new suid files, and files no longer being suid. (If you have the newest COPS, this may no longer be the case. I don't have it yet, and don't know whether it is dependant upon the format of the 'ls -l' command. By the way, the command for directory listing buried in COPS is tailored to the BSD world. It uses 'ls -lg' to INCLUDE group ownership in the report. On our ls, this TURNS OFF the group ownership part of the report. I would reccomend running coffdates(1) on all the bin directories, to set the date shown in the 'ls -l' to the compilation date, to make sure that the older ones won't change format on you six months after installation. > >One directory that CANNOT be treated in this manner is /usr/spool/uucp. >I tried it and kermit couldn't then set or clear locks. Well, you COULD make kermit sgid to mail :-) >The COPS security report is now down to the following: >(actual COPS output follows '>', my comments follow each (group of) entry(ies)) > [ ... ] >> Warning! /etc/drvtab is _World_ writable! >> Warning! /etc/inittab is _World_ writable! >> Warning! /etc/wtmp is _World_ writable! > >Does anybody know if this has to be so? (particularly for /etc/wtmp). I don't THINK so. >> Warning! /usr/adm/NBS.log is _World_ writable! >> Warning! /usr/adm/UNIX.log is _World_ writable! >> Warning! /usr/adm/cronlog is _World_ writable! >> Warning! /usr/adm/drv.log is _World_ writable! >> Warning! /usr/adm/sulog is _World_ writable! >> Warning! /usr/adm/unix.log is _World_ writable! > >Log files... the security risk coming from here is, even in the worst case, >minimal. Well, it allows one to cover his tracks when attempting a breakin, if he has any kind of account on the system. >> Warning! /usr/lib/crontab is _World_ readable! >> Warning! /usr/adm/sulog is _World_ readable! > >Should anybody care about these two? COPS output is looking more and more >like lint... /usr/lib/crontab IS a risk, since it allows an intruder to see easily which programs/shell-scripts are being run from cron, and as whom. This helps identify good targets for trojan-horse attacks. Find out what is being run with privilege, see whether you can modify/substitute one of those to do YOUR sinister work. >> Warning! File /dev/console (in /etc/rc*) is _World_ writable! >> Warning! File /dev/window (in /etc/rc*) is _World_ writable! >> Warning! File /usr/lib/ua/.blanktime (in /etc/rc*) is _World_ writable! No need to keep .blanktime writable. Set it once as install, then set it to 444. That way, nobody is going to change it on you. [ ... ] >> Warning! /usr/lbin/uudecode creates setuid files! > >This, according to the documentation, is pretty common, but without >re-inforcing other problems, seems to be ok. Depends on what you allow for remote execution. If you are running HDB and have the permissable executable list properly limited, you are probably reasonably safe. >Comments anyone? Most of these "problems" (corrected and remaining) >originated with the standard installation of the standard unix pc >software, so it's likely you also have them. Whether they can be safely >ignored is up to you... Most systems, as they are shipped, are criminally lax. >Stay tuned for coming attractions: AT&T external monitor for the unix pc? I'm waiting. Safe Computing DoN. -- Donald Nichols (DoN.) | Voice (Days): (703) 664-1585 D&D Data | Voice (Eves): (703) 938-4564 Disclaimer: from here - None | Email: <dnichols@ceilidh.beartrack.com> --- Black Holes are where God is dividing by zero ---
clewis@ferret.ocunix.on.ca (Chris Lewis) (03/27/91)
In article <1991Mar23.004007.2024@shibaya.lonestar.org> afc@shibaya.lonestar.org (Augustine Cano) writes: >When I first ran the COPS security package on my 3b1, I got a report more >than 250 lines long. Most of the entries were about files and directories >being world-writable. As you've discovered, the 3b1 is particularly bad w.r.t. security. The problem is threefold: - "vanilla" installations have lots of world-writable stuff. Eg: /, /usr and /etc. - Some of the cleanup and "ordinary" operation scripts will re-clobber the permissions. Eg: /etc/inittab and /etc/wtmp. - Some programs simply have big holes in them (ie, given access to the console and the mouse, it's easy to break into root) >chmod o-w ... /usr/spool/news Unless you're using C-news, you just broke your news system. Aha, you ARE using C-news (/usr/lib/newsbin). Consider this a warning to anybody else reading this article - if you're running B-news, do NOT make /usr/spool/news or /usr/lib/news anything other than 777. Sigh... >chmod o-w /. /.. COPS is busted. >One directory that CANNOT be treated in this manner is /usr/spool/uucp. >I tried it and kermit couldn't then set or clear locks. >> Warning! Root does not own the following file(s): >> found found found /bin >Is this of any consequence? No. C-news, for example, *expects* it to be bin (in order to run "doit.bin"). This is a matter of taste. >> Warning! /usr/spool/uucp is _World_ writable! >This one has to be ignored; as I said above certain programs might not be >able to access locks if this is changed. The real solution is to fix Kermit. Or use HDB (where the lock directory can be made world writable but not everything else) >> Warning! /etc/drvtab is _World_ writable! >> Warning! /etc/inittab is _World_ writable! >> Warning! /etc/wtmp is _World_ writable! >Does anybody know if this has to be so? (particularly for /etc/wtmp). Particularly "/etc/inittab" - this is the most vital file in your machine. (well, aside from /unix and one or two others). A single misplaced character in /etc/inittab can hang your machine requiring a floppy boot. inittab should be 644 or 444, but the admin scripts occasionally zap it back to 666. You should put a chmod in your crontab. Ditto wtmp. drvtab appears to be something built during the boot process, probably doesn't matter much. >> Warning! /usr/adm/NBS.log is _World_ writable! >> Warning! /usr/adm/UNIX.log is _World_ writable! >> Warning! /usr/adm/cronlog is _World_ writable! >> Warning! /usr/adm/drv.log is _World_ writable! >> Warning! /usr/adm/sulog is _World_ writable! >> Warning! /usr/adm/unix.log is _World_ writable! >Log files... the security risk coming from here is, even in the worst case, >minimal. Matter of opinion I guess, but it makes it more difficult to trace breakins if you make it easy for a cracker to clobber them. I don't know about NBS.log, but all of the others can be made 644. >> Warning! /usr/lib/crontab is _World_ readable! >> Warning! /usr/adm/sulog is _World_ readable! >Should anybody care about these two? COPS output is looking more and more >like lint... Depends on how paranoid you are. >> Warning! File /dev/console (in /etc/rc*) is _World_ writable! >> Warning! File /dev/window (in /etc/rc*) is _World_ writable! >> Warning! File /usr/lib/ua/.blanktime (in /etc/rc*) is _World_ writable! >> Warning! User uucp's home directory /usr/spool/uucppublic is mode 0777! >> Warning! User nuucp's home directory /usr/spool/uucppublic is mode 0777! >Of course, since all uucp accounts have the same home directory, the >same message appeared once for each uucp-connected machine. You can fix .blanktime without worrying about it. I contend that if COPS is complaining about uucp userid logins, it's busted. >> Warning! /usr/lbin/uudecode creates setuid files! >This, according to the documentation, is pretty common, but without >re-inforcing other problems, seems to be ok. This is a fun one. tar and cpio can create setuid files too. None of these are a problem because you still can't give away a setuid file. H'm. On the other hand, uudecode making things setuid can cause problems if root unpacks it and other users use it... Mind you, if you're using binary executables from off the net, you deserve what you get ;-) -- Chris Lewis, clewis@ferret.ocunix.on.ca or ...uunet!mitel!cunews!latour!ecicrl!clewis Psroff support: psroff-request@eci386.uucp, or call 613-832-0541 (Canada) **** somebody's mailer is appending .bitnet to my From: address. If you see this, please use the address in the signature, and send me a copy of the headers of the mail message with the .bitnet return address. Thanks!
andy@cs.caltech.edu (Andy Fyfe) (03/27/91)
In article <1991Mar26.225255.6048@ferret.ocunix.on.ca> clewis@ferret.ocunix.on.ca (Chris Lewis) writes: >In article <1991Mar23.004007.2024@shibaya.lonestar.org> afc@shibaya.lonestar.org (Augustine Cano) writes: >>One directory that CANNOT be treated in this manner is /usr/spool/uucp. >>I tried it and kermit couldn't then set or clear locks. >>This one has to be ignored; as I said above certain programs might not be >>able to access locks if this is changed. > >The real solution is to fix Kermit. Or use HDB (where the lock directory >can be made world writable but not everything else) Recent versions of kermit can be make setuid. On my system, kermit is setuid uucp, and /usr/spool/uucp is owned by uucp. Kermit has no trouble making and removing locks. It is also quite paranoid about permissions, so it's fairly safe as far as setuid programs go. The current version, 5A(166), is available on csvax.cs.caltech.edu in the directory pub/3b1 (for those who have anonymous ftp). A possibly-not-quite-so-up-to-date version is available in the OSU archives (as kermit2). Andy Fyfe andy@cs.caltech.edu
john@chance.UUCP (John R. MacMillan) (03/27/91)
Warning: I can be a bit paranoid about security stuff. |> Warning! Root does not own the following file(s): |> found found found /bin | |Is this of any consequence? Not really. |> Warning! /usr/spool/uucp is _World_ writable! | |This one has to be ignored; as I said above certain programs might not be |able to access locks if this is changed. Or make them setuid or setgid, and fix any security holes THAT might open. :-( Sticky directories would be useful here. |> Warning! /etc/drvtab is _World_ writable! |> Warning! /etc/inittab is _World_ writable! |> Warning! /etc/wtmp is _World_ writable! | |Does anybody know if this has to be so? (particularly for /etc/wtmp). /etc/inittab should NOT be world writable! And /etc/wtmp does not need to be world writable. If it is, a cracker who gets on can hide the fact that he/she was on. But if you change it remember to change whatever you have cleaning it up or you're likely to end up with it 0666 again. |> Warning! /usr/adm/NBS.log is _World_ writable! |> Warning! /usr/adm/UNIX.log is _World_ writable! |> Warning! /usr/adm/cronlog is _World_ writable! |> Warning! /usr/adm/drv.log is _World_ writable! |> Warning! /usr/adm/sulog is _World_ writable! |> Warning! /usr/adm/unix.log is _World_ writable! | |Log files... the security risk coming from here is, even in the worst case, |minimal. Not really. A world writable sulog would let someone who su-ed to some other account to hide the fact, or allow anyone to hide any su attempts (now if they could get to root the point is moot). I run a script that checks sulog to see who's trying to su where. Cronlog lets you empirically determine what cron is doing (see below). Other log files can be thought of as giving unnecessary clues about the operation of your system to the cracker, and can allow the cracker to remove or falsify whatever was being logged. As above, if you change the modes, don't forget to change things that may clean up these files. |> Warning! /usr/lib/crontab is _World_ readable! |> Warning! /usr/adm/sulog is _World_ readable! | |Should anybody care about these two? COPS output is looking more and more |like lint... Lint warnings should only be ignored with great care, but I digress. Letting people see what cron is doing (especially for privileged users) gives clues about where to plant trojan horses, and when to attempt to ``break'' programs running as privileged users, by removing temp files, filling the disk, etc. Letting people see who can su to whom tells you who's account to break to increase your chances of getting to whoever they can su to. |> Warning! /usr/lbin/uudecode creates setuid files! | |This, according to the documentation, is pretty common, but without |re-inforcing other problems, seems to be ok. This could be problem for inattentive users or if you have a uudecode alias that runs as root (which I highly recommend AGAINST). |Comments anyone? Most of these "problems" (corrected and remaining) |originated with the standard installation of the standard unix pc |software, so it's likely you also have them. Whether they can be safely |ignored is up to you... Some of the writable directory ones are terrifying, most notably /. On the 3B1, the UA introduces a few horrors of its own, most notably /usr/lib/ua/uasetx, and smgr's mail icon. See ua(4) for EXEC action with the option ``-p Run the process with superuser privileges''. Also, any user can reconfigure your site name, your L.sys file, your lp setup... Out of the box, the security on this machine (like many Unix boxes) is terrible.
emm@iczer-1.UUCP (Edward M. Markowski) (03/28/91)
In article <1991Mar26.225255.6048@ferret.ocunix.on.ca> clewis@ferret.ocunix.on.ca (Chris Lewis) writes: >>chmod o-w ... /usr/spool/news > >Unless you're using C-news, you just broke your news system. Aha, you >ARE using C-news (/usr/lib/newsbin). Consider this a warning to anybody >else reading this article - if you're running B-news, do NOT make /usr/spool/news >or /usr/lib/news anything other than 777. Sigh... In one of the header files in the news distribution(sp?) there is a constant that will allow the lib and spool directories to be set to 755, the articles to be created 644 and the spool dirs 755. I do not rember which header and constant but it is documented there or in the Nutshell book Managing UUCP and USENET. -- ------------------------------------------------------------------------------- Edward M. Markowski -- iczer-1 Administrator ...the garage is flooded from the sprinkler. VOICE : (201) 478-6052 It also left a man's decapitated body, lying UUCP : ..!uunet!iczer-1!emm on the floor next to his own severed head. -or- : ..!tronsbox!iczer-1!emm A head which at this time has no name.
dnichols@ceilidh.beartrack.com (DoN Nichols) (03/28/91)
In article <1991Mar26.225255.6048@ferret.ocunix.on.ca> clewis@ferret.ocunix.on.ca (Chris Lewis) writes: >In article <1991Mar23.004007.2024@shibaya.lonestar.org> afc@shibaya.lonestar.org (Augustine Cano) writes: >>When I first ran the COPS security package on my 3b1, I got a report more >>than 250 lines long. Most of the entries were about files and directories >>being world-writable. [ ... ] >>chmod o-w ... /usr/spool/news > >Unless you're using C-news, you just broke your news system. Aha, you >ARE using C-news (/usr/lib/newsbin). Consider this a warning to anybody >else reading this article - if you're running B-news, do NOT make /usr/spool/news >or /usr/lib/news anything other than 777. Sigh... Is it tolerable to run B-news on the 3b1? I am getting just a partial feed, and even with C-news it can take over an hour to digest a large day's shipment, like today's. [ ... ] >>> Warning! /usr/spool/uucp is _World_ writable! > >>This one has to be ignored; as I said above certain programs might not be >>able to access locks if this is changed. > >The real solution is to fix Kermit. Or use HDB (where the lock directory >can be made world writable but not everything else) Except that the HDB version from THE STORE made the lockfiles live in the same old place, to keep compatability with other stuff in the machine. :-( [ ... ] >>> Warning! /usr/lib/crontab is _World_ readable! >>> Warning! /usr/adm/sulog is _World_ readable! > >>Should anybody care about these two? COPS output is looking more and more >>like lint... > >Depends on how paranoid you are. I don't like leaving a roadmap with a nice heavy guideline for potential troublemakers/trojan_horse_builders, even though one cannot directly dial into this system. [ ... ] >>> Warning! /usr/lbin/uudecode creates setuid files! > >>This, according to the documentation, is pretty common, but without >>re-inforcing other problems, seems to be ok. > >This is a fun one. tar and cpio can create setuid files too. None of >these are a problem because you still can't give away a setuid file. >H'm. On the other hand, uudecode making things setuid can cause problems >if root unpacks it and other users use it... Mind you, if you're >using binary executables from off the net, you deserve what you get ;-) Like the binary (with source) that caused all the furor in the 386 unix newsgroup? :-) Can YOUR computer enjoy a safe sleep? :-) DoN. -- Donald Nichols (DoN.) | Voice (Days): (703) 664-1585 D&D Data | Voice (Eves): (703) 938-4564 Disclaimer: from here - None | Email: <dnichols@ceilidh.beartrack.com> --- Black Holes are where God is dividing by zero ---
clewis@ferret.ocunix.on.ca (Chris Lewis) (04/04/91)
In article <563@iczer-1.UUCP> emm@iczer-1.UUCP (Edward M. Markowski) writes: >In article <1991Mar26.225255.6048@ferret.ocunix.on.ca> clewis@ferret.ocunix.on.ca (Chris Lewis) writes: >>>chmod o-w ... /usr/spool/news >>Unless you're using C-news, you just broke your news system. Aha, you >>ARE using C-news (/usr/lib/newsbin). Consider this a warning to anybody >>else reading this article - if you're running B-news, do NOT make /usr/spool/news >>or /usr/lib/news anything other than 777. Sigh... >In one of the header files in the news distribution(sp?) there is a >constant that will allow the lib and spool directories to be set to >755, the articles to be created 644 and the spool dirs 755. I do not >rember which header and constant but it is documented there or in the >Nutshell book Managing UUCP and USENET. It's in the defs.h for B news. However, it won't work on System V systems because of the way setuid/setgid programs, setuid()/setgid() and mkdir works. (as in, if a setuid program calls mkdir, the directory ends up being owned by the real user not the effective, rnews can't write into it, and there's no "elegant" way around it in System V) Which is why C-news goes to all of the kludgey junk for the "setnewsids" program which runs as setuid root to run relaynews properly. Bnews has no such kludge, though you could retrofit setnewsids if you wanted. -- Chris Lewis, clewis@ferret.ocunix.on.ca or ...uunet!mitel!cunews!latour!ecicrl!clewis Psroff support: psroff-request@eci386.uucp, or call 613-832-0541 (Canada) **** somebody's mailer is appending .bitnet to my From: address. If you see this, please use the address in the signature, and send me a copy of the headers of the mail message with the .bitnet return address. Thanks!
clewis@ferret.ocunix.on.ca (Chris Lewis) (04/04/91)
In article <1991Mar28.035200.725@ceilidh.beartrack.com> dnichols@ceilidh.beartrack.com (DoN Nichols) writes: >In article <1991Mar26.225255.6048@ferret.ocunix.on.ca> clewis@ferret.ocunix.on.ca (Chris Lewis) writes: >>In article <1991Mar23.004007.2024@shibaya.lonestar.org> afc@shibaya.lonestar.org (Augustine Cano) writes: > Is it tolerable to run B-news on the 3b1? I am getting just a >partial feed, and even with C-news it can take over an hour to digest a >large day's shipment, like today's. Depends on what you mean by "partial feed". If your C-news takes over an hour to unpack even a full feed, something's busted. Are you using dbz? My 3b1 with B-news probably takes about 10-15 minutes per day to unpack my entire feed - perhaps about 1Mb compressed daily. On the other hand, C-news could do the whole thing in under a minute. I maintain both types of news systems, so I have a pretty good idea of how both behave. >>The real solution is to fix Kermit. Or use HDB (where the lock directory >>can be made world writable but not everything else) > Except that the HDB version from THE STORE made the lockfiles live >in the same old place, to keep compatability with other stuff in the >machine. :-( Sigh.... Making Kermit run setuid (fixing some of the security holes that may open) is a better solution. >>Depends on how paranoid you are. > I don't like leaving a roadmap with a nice heavy guideline for >potential troublemakers/trojan_horse_builders, even though one cannot >directly dial into this system. That's what I meant. > Can YOUR computer enjoy a safe sleep? :-) Pretty well. I don't let other people log into it and I'm running other software to confirm and maintain security and detect security breaches. -- Chris Lewis, clewis@ferret.ocunix.on.ca or ...uunet!mitel!cunews!latour!ecicrl!clewis Psroff support: psroff-request@eci386.uucp, or call 613-832-0541 (Canada) **** somebody's mailer is appending .bitnet to my From: address. If you see this, please use the address in the signature, and send me a copy of the headers of the mail message with the .bitnet return address. Thanks!
emm@iczer-1.UUCP (Edward M. Markowski) (04/06/91)
In article <1991Apr03.201214.8915@ferret.ocunix.on.ca> clewis@ferret.ocunix.on.ca (Chris Lewis) writes: |In article <563@iczer-1.UUCP> emm@iczer-1.UUCP (Edward M. Markowski) writes: |It's in the defs.h for B news. However, it won't work on System V systems |because of the way setuid/setgid programs, setuid()/setgid() and mkdir |works. (as in, if a setuid program calls mkdir, the directory ends up |being owned by the real user not the effective, rnews can't write |into it, and there's no "elegant" way around it in System V) Which is why |C-news goes to all of the kludgey junk for the "setnewsids" program which |runs as setuid root to run relaynews properly. | |Bnews has no such kludge, though you could retrofit setnewsids if you wanted. It works here. I am have a 3B1, which is running System V I do not seem to have that problem. -- ------------------------------------------------------------------------------- Edward M. Markowski -- iczer-1 Administrator ...the garage is flooded from the sprinkler. VOICE : (201) 478-6052 It also left a man's decapitated body, lying UUCP : ..!uunet!iczer-1!emm on the floor next to his own severed head. -or- : ..!tronsbox!iczer-1!emm A head which at this time has no name.
clewis@ferret.ocunix.on.ca (Chris Lewis) (04/07/91)
In article <580@iczer-1.UUCP> emm@iczer-1.UUCP (Edward M. Markowski) writes: >In article <1991Apr03.201214.8915@ferret.ocunix.on.ca> clewis@ferret.ocunix.on.ca (Chris Lewis) writes: >|In article <563@iczer-1.UUCP> emm@iczer-1.UUCP (Edward M. Markowski) writes: >|It's in the defs.h for B news. However, it won't work on System V systems >|because of the way setuid/setgid programs, setuid()/setgid() and mkdir >|works. (as in, if a setuid program calls mkdir, the directory ends up >|being owned by the real user not the effective, rnews can't write >|into it, and there's no "elegant" way around it in System V) Which is why >|C-news goes to all of the kludgey junk for the "setnewsids" program which >|runs as setuid root to run relaynews properly. >|Bnews has no such kludge, though you could retrofit setnewsids if you wanted. >It works here. I am have a 3B1, which is running System V I do not seem >to have that problem. I just went back and ran some tests with 2.11 PL 19. And sure nuff, it does work. It didn't work back in 2.10.x days which I guess is why I thought it still didn't in 2.11. It works by chmod 777'ing the parent, mkdir'ing the directory, owned by the real id (not news), and then "giving it away" to news and then resetting the parent. Urgh. Still wouldn't work in some versions of UNIX (eg: V7 where chown is usually disabled). This mechanism wouldn't work in BSD, but in BSD you can setuid(geteuid()). C-news uses a simpler approach by doing a setuid(geteuid()) on all of relaynews, which can't be done on System V, so the setnewsid program does it as setuid root (via an equivalent of setuid(getpwnam("news")->pw_uid)) and then exec'ing relaynews. -- Chris Lewis, clewis@ferret.ocunix.on.ca or ...uunet!mitel!cunews!latour!ecicrl!clewis Psroff support: psroff-request@eci386.uucp, or call 613-832-0541 (Canada) **** somebody's mailer is appending .bitnet to my From: address. If you see this, please use the address in the signature, and send me a copy of the headers of the mail message with the .bitnet return address. Thanks!