tgt@cbnews.ATT.COM (Tim Thompson) (07/14/88)
I've received a request from a portion of our user community for a private newgroup - one that only a certain group of users can read and post to. I'm sure this has been done elsewhere, and have a good idea about how to do it, but I'm interested in hearing how others have accomplished this. Obviously, the FASCIST define in defs.h can be used to limit the number of people who can post to a given group. According to the doc, however, it does nothing to stop that group of people from reading the private newsgroup. I can combined what has been called the SLEAZY approach with FASCIST to accomplish the desired functionality. (Ever meet a sleazy fascist?) By this, I mean that I can make /usr/spool/news/XXX mode 750 owned by news and with group YYY. People who should be able to read the newsgroup would be put into group YYY. News is happy because it has owner permission to write. Only people with read access to the directory (i.e. members of group YYY) can read the files in it. A minor modification will need to be made to 'rn' - the error message tells me that "Newsgroups YYY has not spool directory". It'll be easy enough to check errno and return a better error message. I've also been told that I could run notesfile in parallel with the 2.11 B news for the private newsgroup, but this seems like more trouble than it's worth. My question, then, is as follows: Is there a more elegant way to implement private newsgroups under 2.11 B news? These private newsgroups won't be transmitted anywhere else -they'll only live on this one machine. The problem lies in that only a certain class of users should be allowed to read and/or post to them. Waiting for the replies to come rolling in, Tim Thompson tgt@cbnews.ATT.COM
eric@snark.UUCP (Eric S. Raymond) (07/16/88)
In article <657@cbnews.att.com>, tgt@cbnews.ATT.COM (Tim Thompson) writes: > My question, then, is as follows: Is there a more elegant way to implement > private newsgroups under 2.11 B news? These private newsgroups won't > be transmitted anywhere else -they'll only live on this one machine. > The problem lies in that only a certain class of users should be allowed > to read and/or post to them. As of this morning, the `elegant way' is to bring up 3.0 on your machine. Private groups with posting *and reading* authorization check are now a fully supported feature of the 3.0 beta; the code and documentation changes will go to the beta sites this afternoon as part of patch #2. If you run with FASCIST on, you can control posting and reading access to groups on a per-user basis. Netnews uses group permissions to achieve this. All news database files (including article text) are created and maintained owned by NEWSUSR and NEWSGROUP, with permissions u=rwx,g=rx,o-rwx (750). Thus only programs that are suid or sgid NEWSUSR can read news database files. Only programs that are suid NEWSUSR can write them. Readers are sgid NEWSUSR; rnews, expire and sendbatch are suid NEWSUSR. Within the interfaces, security checks are done in the standard service layers that news readers and posters use to get at the news database. Essentially, if you're locked out of a group, the service layer forces your subscription bit for it off at startup time, so you never see it. The few reader commands that permit you to go to a not-previously-subscribed group have their own checks. It will be the site administrator's responsibility to ensure that homebrew readers use the standard service libraries (and thus incorporate the security checks). Security restrictions are expressed in the ADM/authorized file. The ADM/fascist file of older versions had two colon-separated fields per line, the first a user or group name and the second a subscription specifying those groups for which said user or group has posting privileges. The ADM/authorized format adds an optional third colon-separated field to specify *reading* privileges. FASCIST mode has two minor disadvantages. One is that you have to newgroup news or su news or root to snoop the machine history and active files to track problems. The other is that users who want to roll their own readers (and aren't just front-ending the ednews tool) will need to get someone with root privileges to set their programs sgid NEWSUSR on each runtime generation. So there you have it. Folks, get in your feature-wish-lists now, because I'm *not* going to want to do a lot of iffy hacking on the code once the beta is complete (I'd just have to beta again, and despite a low level of problems this test has *not* been easy on me -- nothing involving within-hours responses to reports from 50 different sites ever is). -- Eric S. Raymond (the mad mastermind of TMN-Netnews) UUCP: ..!{uunet,att,rutgers!vu-vlsi}!snark!eric Smail: eric@snark.UUCP Post: 22 South Warren Avenue, Malvern, PA 19355 Phone: (215)-296-5718
zeeff@b-tech.UUCP (Jon Zeeff) (07/18/88)
In article <dadJ7#2sFpPf=eric@snark.UUCP> eric@snark.UUCP (Eric S. Raymond) writes: [ info about News 3.0 ] > >If you run with FASCIST on, you can control posting and reading access to >groups on a per-user basis. Netnews uses group permissions to achieve this. >All news database files (including article text) are created and maintained >owned by NEWSUSR and NEWSGROUP, with permissions u=rwx,g=rx,o-rwx (750). Thus >only programs that are suid or sgid NEWSUSR can read news database files. Only >programs that are suid NEWSUSR can write them. Readers are sgid NEWSUSR; >rnews, expire and sendbatch are suid NEWSUSR. > I hope that the group write permissions are turned off on *all* news files in case someone gets a sgid shell. >FASCIST mode has two minor disadvantages. ... >... The other is that users who want to roll their own readers (and >aren't just front-ending the ednews tool) will need to get someone with root >privileges to set their programs sgid NEWSUSR on each runtime generation. > It seems to me that just getting someone with root to sgid to NEWSUSR is the least of the problems. Every reader would have to be gone over very carefully and modified to protect it's sgid status. For many readers, this may be a big task that will never get done right. Where possible, I'd just stick with setting the perms on protected news groups to g=rx,o-rwx with the group set to some group that only privledged users are in. It's not as flexible, but we know it's secure. Maybe I'm wrong, but I think that a sgid secure version of rn would be a big job. -- Jon Zeeff Branch Technology, uunet!umix!b-tech!zeeff zeeff%b-tech.uucp@umix.cc.umich.edu
daveb@llama.rtech.UUCP (Dave Brower) (07/21/88)
In article <dadJ7#2sFpPf=eric@snark.UUCP> eric@snark.UUCP (Eric S. Raymond) writes: >In article <657@cbnews.att.com>, tgt@cbnews.ATT.COM (Tim Thompson) writes: >> My question, then, is as follows: Is there a more elegant way to implement >> private newsgroups under 2.11 B news? These private newsgroups won't >> be transmitted anywhere else -they'll only live on this one machine. >> The problem lies in that only a certain class of users should be allowed >> to read and/or post to them. > >As of this morning, the `elegant way' is to bring up 3.0 on your machine. >Private groups with posting *and reading* authorization check are now a fully >supported feature of the 3.0 beta; the code and documentation changes will go >to the beta sites this afternoon as part of patch #2. ... How will these 3.0 security features work in an nntp environment? This may be an unsolvable problem, but it seems worth mentioning. -dB "Ready when you are Raoul!" {amdahl, cpsc6a, mtxinu, sun, hoptoad}!rtech!daveb daveb@rtech.com <- FINALLY!
eric@snark.UUCP (Eric S. Raymond) (07/25/88)
In article <2333@rtech.rtech.com>, daveb@llama.UUCP (Dave Brower) writes: > How will these 3.0 security features work in an nntp environment? This > may be an unsolvable problem, but it seems worth mentioning. The security checks are implemented way above the level that 3.0 talks to NNTP. The only difference NNTP makes (from a security point of view) is that the database files aren't actually locally present to be snooped on. -- Eric S. Raymond (the mad mastermind of TMN-Netnews) UUCP: ..!{uunet,att,rutgers!vu-vlsi}!snark!eric Smail: eric@snark.UUCP Post: 22 South Warren Avenue, Malvern, PA 19355 Phone: (215)-296-5718