jc@minya.UUCP (John Chambers) (06/19/91)
| In article <5485@risky.Convergent.COM>, gilles@diox.Convergent.COM (Gilles COURCOUX) writes: | > In article <23182@shlump.lkg.dec.com> jc@netrix.nac.dec.com writes: | > | > [I tried to answer directly by Email, but mails bounced back with: | > ----- Transcript of session follows ----- | > User "jc" is no longer employed here and has moved to a site that | > does not have electronic mail access. We therefore cannot forward the mail.] This is actually one of my accounts at work, which I'm following up here at home for convenience and so you can possibly reply to this one. The above is among the more brain-damaged messages that I've seen in the last few years. A simple "user unknown" would have been much more useful. The facts in the message are all entirely incorrect, and I generally feel that an incomplete message is usually better than an incorrect one. But enough flaming, however mild; the above poses an interesting puzzle. The actual login id there was lan_csse, which is a shared account that I and several other people are allowed to use to get at news. Of course, this is probably the worst possible way to access news, since all the news readers try to keep track of what has been shown on a per-user basis. I mean, we do have fun reading each others' mail and chuckling at all the flames, etc., but it's mostly a pain. I've played around with some schemes to try to keep it straight. What I'm doing right now is sourceing a file that does a bunch of initialization, including setting $home to the 'jc' subdirectory, setting $user to 'jc', and so on. This works for keeping my stuff (email, a few test programs) straight from other users. Unfortunately, it means that the news/mail programs send things out identified as coming from the 'jc' user, who isn't in /etc/passwd, so it doesn't work too well. I don't have write access to /usr/lib/aliases, so I can't define the proper forward to my home machine. So further research is necessary on how to kludge a multi-user account so that it works sensibly, without using super-user privileges. Does anyone have any clever ideas? Yeah, I know; the correct answer is "Don't do something so dumb." Good advice, but I'm not the owner of the machine, and I can't really go around insulting the guys who are nice enough to give me access to one of the few real BB systems in the company. Anyhow, I've seen this done so often that I sorta feel that it is a permanent part of the growing world of Unix system management, and we oughta know how to correct for admins that do such dumb things. I mean, you and I know that a new account on a Unix system ain't such a big deal, but there are admins who take such things seriously, and they are not gonna go away. So what's the right way to handle multi-user accounts gracefully? [Of course, one partial answer is to remember to put a Reply-To: line in all outgoing news and mail messages; too bad I don't always remember to do that. ;-] All opinions Copyright (c) 1991 by John Chambers. Inquire for licensing at: Home: 1-617-484-6393 ...!{bu.edu,harvard.edu,ima.com,eddie.mit.edu,ora.com}!minya!jc Work: 1-508-486-5475 {sppip7.lkg.dec.com!jc,ub40::jc} -- All opinions Copyright (c) 1991 by John Chambers. Inquire for licensing at: Home: 1-617-484-6393 ...!{bu.edu,harvard.edu,ima.com,eddie.mit.edu,ora.com}!minya!jc Work: 1-508-486-5475 {sppip7.lkg.dec.com!jc,ub40::jc}
les@chinet.chi.il.us (Leslie Mikesell) (06/21/91)
In article <798@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >So further research is necessary on how to kludge a multi-user account >so that it works sensibly, without using super-user privileges. Does >anyone have any clever ideas? Personally, I think it's easier all around to just give everyone their own account since the administrator has to deal with that for some users anyway and everything more or less takes care of itself, including file ownership and accounting mechanisms. If I were concerned about security, I'd probably set up a chroot environment that looked like a different machine and tweak the mailer to deliver things addressed to that machine or subdomain to the right place. Recent SysV's have some support in login(1) to make certain id's perform a chroot and then run login again from there, so internally you could have a different administrator to maintain the sub-password file. I'm not sure if anyone actually uses this. It doesn't really give perfect security since root in the sub-login can mknod() a device driver that points to the real disks or kmem. The sub-domain or different machine name would work as well without the chroot, though, as long as the mailer will handle it. I've only worked with Smail3, which could be configured to do it easily, or you could use a prefix or suffix with a unique identifier and set up a delivery method based on that. Les Mikesell les@chinet.chi.il.us