childers@avsd.UUCP (Richard Childers) (01/28/89)
leres@helios.ee.lbl.gov (Craig Leres) writes: >Richard Childers writes: >> When I find .forward files in the LAN ... I cat /dev/null into them and chown them to root and chmod the sucker to 444 and that's that. >This sounds gratuitously fascist to me. Luckly, it's not hard to remove >such a file ... But it is impossible to edit it until it is removed, and provokes the required dialogue between user and administrator ... which is all I ask. >The advanced reader might want to use "rm -f .forward" One presumes that the advanced reader doesn't mangle his .forward ... Actually, I have been at enlightened sites where /usr/lib/aliases was writeable by the world. But if you can't trust your users to edit /usr/lib/aliases, then you probably can't trust them to edit .forward, either. > Craig -- richard -- * -= If it works, it must be a Fluke =- * * * * ..{amdahl|decwrl|octopus|pyramid|ucbvax}!avsd.UUCP!childers@tycho * * AMPEX Corporation - Audio-Visual Systems Division, R & D *
mike@unmvax.cs.unm.edu (Michael I. Bushnell) (02/01/89)
In article <445@avsd.UUCP> childers@avsd.UUCP (Richard Childers) writes: >One presumes that the advanced reader doesn't mangle his .forward ... > >Actually, I have been at enlightened sites where /usr/lib/aliases was writeable >by the world. But if you can't trust your users to edit /usr/lib/aliases, then >you probably can't trust them to edit .forward, either. Hmmm...I disagree. We are an "enlightened" site which lets people edit /usr/lib/aliases. If someone f*cks up, then we have the simple solution of asking "who changed the XXX alias to YYY?" and then we can explain to them the necessity of being more careful in the future. But if we decided that people were not trustable, then there is a hell of a difference between mangling your OWN .forward (which only screws up your own mail) and mangling /usr/lib/aliases (which can steal other peoples' mail, break vital mailing lists, etc.). In short, it may be quite rational to protect users from eachother (by protecting /usr/lib/aliases), but it IS facism to "protect" people from themselves. Michael I. Bushnell \ This above all; to thine own self be true GIG! \ And it must follow, as the night the day, mike@turing.cs..unm.edu /\ Thou canst not be false to any man. Hmmmm.............. / \ Farewell: my blessing season this in thee!
leres@ace.ee.lbl.gov (Craig Leres) (02/01/89)
Several weeks ago, Richard Childers wrote: > When I find .forward files in the LAN ... I cat /dev/null into them and > chown them to root and chmod the sucker to 444 and that's that. Shortly after, I wrote: > This sounds gratuitously fascist to me. Luckly, it's not hard to remove > such a file ... More recently Richard Childers writes: > But it is impossible to edit it until it is removed, and provokes the required > dialogue between user and administrator ... which is all I ask. When one of my users botches his/her .forward file (this is a rare event, perhaps my users are smarter than yours) I find that mail(1) provides an interface that is completely sufficient to "provoke" dialogue with the user. Not once have I had to play power games with superuser privileges to achieve this goal. Craig
karl@sugar.uu.net (Karl Lehenbauer) (02/01/89)
In article <2253@unmvax.unm.edu>, mike@unmvax.cs.unm.edu (Michael I. Bushnell) writes: > Hmmm...I disagree. We are an "enlightened" site which lets people edit > /usr/lib/aliases. If someone f*cks up, then we have the simple solution > of asking "who changed the XXX alias to YYY?" and then we can explain to > them the necessity of being more careful in the future. Thus the cost of providing the flexibility of letting people edit /usr/lib/aliases is that, when they screw up, mail screws up -- sometimes a little, sometimes a lot. I don't know if I would call this policy "enlightened." I would say it balances things a little more toward ease-of-use at the cost of reducing reliability. Why do they need to edit /usr/lib/aliaes anyway? How often does this happen? -- -- uunet!sugar!karl | "We've been following your progress with considerable -- karl@sugar.uu.net | interest, not to say contempt." -- Zaphod Beeblebrox IV -- Usenet BBS (713) 438-5018
guy@auspex.UUCP (Guy Harris) (02/02/89)
>But it is impossible to edit it until it is removed, and provokes the required >dialogue between user and administrator ... which is all I ask. Maybe yes, maybe no; they may just get ticked off, as I presume Mr. Leres would (and as I probably would, too), and just remove it without talking to the administrator. >Actually, I have been at enlightened sites where /usr/lib/aliases was writeable >by the world. But if you can't trust your users to edit /usr/lib/aliases, then >you probably can't trust them to edit .forward, either. Incorrect. You can screw more people by monkeying with "/usr/lib/aliases" than you can by editing ".forward"; by editing the former you can foul up the delivery of mail to people other than yourself without their consent.
mike@unmvax.cs.unm.edu (Michael I. Bushnell) (02/02/89)
In article <3376@sugar.uu.net> karl@sugar.uu.net (Karl Lehenbauer) writes: >In article <2253@unmvax.unm.edu>, mike@unmvax.cs.unm.edu (Michael I. Bushnell) writes: >> Hmmm...I disagree. We are an "enlightened" site which lets people edit >> /usr/lib/aliases. If someone f*cks up, then we have the simple solution >> of asking "who changed the XXX alias to YYY?" and then we can explain to >> them the necessity of being more careful in the future. > >Thus the cost of providing the flexibility of letting people edit >/usr/lib/aliases is that, when they screw up, mail screws up -- sometimes >a little, sometimes a lot. I don't know if I would call this policy >"enlightened." I would say it balances things a little more toward >ease-of-use at the cost of reducing reliability. Why do they need to >edit /usr/lib/aliaes anyway? How often does this happen? They (the faculty) maintain several mail aliases for various groups. They even *create* such aliases relatively frequently. No one's *ever* screwed up anyone else's mail. This makes creating mailing lists easy for arbitrary users. Michael I. Bushnell \ This above all; to thine own self be true GIG! \ And it must follow, as the night the day, mike@turing.cs..unm.edu /\ Thou canst not be false to any man. Hmmmm.............. / \ Farewell: my blessing season this in thee!
dik@uva.UUCP (Casper H.S. Dik) (02/03/89)
In article <2253@unmvax.unm.edu> mike@unmvax.cs.unm.edu (Michael I. Bushnell) writes: >In article <445@avsd.UUCP> childers@avsd.UUCP (Richard Childers) writes: > >>Actually, I have been at enlightened sites where /usr/lib/aliases was writeable >>by the world. But if you can't trust your users to edit /usr/lib/aliases, then >>you probably can't trust them to edit .forward, either. > > >Hmmm...I disagree. We are an "enlightened" site which lets people edit >/usr/lib/aliases. If someone f*cks up, then we have the simple solution >of asking "who changed the XXX alias to YYY?" and then we can explain to >them the necessity of being more careful in the future. Hmmm... you must trust your users very much. People can not only steal other peoples mail, but can add an alias like myalias: |/myhome/myprogram The program /myhome/myprogram will be executed with the uid sendmail uses for untrusted mailers. If it is daemon (it is on my systems) the user could then 'do some things I will not disclose here' and become root in a matter of minutes. At that point he can do more damage to your system than you can repair in the time saved by letting your users edit /usr/lib/aliases. >In short, it may be quite rational to protect users from eachother (by >protecting /usr/lib/aliases), but it IS facism to "protect" people from >themselves. Agreed > Michael I. Bushnell \ This above all; to thine own self be true > GIG! \ And it must follow, as the night the day, >mike@turing.cs..unm.edu /\ Thou canst not be false to any man. > Hmmmm.............. / \ Farewell: my blessing season this in thee! ____________________________________________________________________________ Casper H.S. Dik University of Amsterdam | dik@uva.uucp The Netherlands | ...!uunet!mcvax!uva!dik
mike@turing.cs.unm.edu (Michael I. Bushnell) (02/05/89)
In article <608@uva.UUCP> dik@uva.UUCP (Casper H.S. Dik) writes: >Hmmm... you must trust your users very much. >People can not only steal other peoples mail, but can add an alias like >myalias: |/myhome/myprogram Our goal for security is to prevent users from doing accidental damage. We can restore the system from tape in a matter of hours--with little loss of data. The offending person is easily determined, and we can easily use administrative means to can them. >The program /myhome/myprogram will be executed with the uid sendmail uses >for untrusted mailers. If it is daemon (it is on my systems) the user >could then 'do some things I will not disclose here' and become root >in a matter of minutes. In the interests of letting people know what we mean, you could, for example, modify the atq and have jobs executed as root. The atq is, on most systems, owned by daemon, so daemon can modify it and have jobs run under any uid. >At that point he can do more damage to your system than you can repair >in the time saved by letting your users edit /usr/lib/aliases. As I said, not too much damage. We don't worry. Administrative control is far better than online security. Michael I. Bushnell \ This above all; to thine own self be true GIG! \ And it must follow, as the night the day, mike@turing.cs..unm.edu /\ Thou canst not be false to any man. Hmmmm.............. / \ Farewell: my blessing season this in thee!
childers@avsd.UUCP (Richard Childers) (02/07/89)
dik@uva.UUCP (Casper H.S. Dik) writes: >mike@unmvax.cs.unm.edu (Michael I. Bushnell) writes: >>In short, it may be quite rational to protect users from eachother (by >>protecting /usr/lib/aliases), but it IS facism to "protect" people from >>themselves. >Agreed I beg to disagree, gentlebeings. I am not intent on 'protecting users from each other' when I forbid ~{user}/.forward files ... I am protecting myself. It's not a matter of facism. It's a matter of functionality. I have a mandate, as it were, to maintain the mail subsystem. I also have an unofficial mandate to order my tasks in such a way as to avoid wasting my time. Reading mail to 'root' from 'MAILER-DAEMON', time after time, is a waste of my time. I know what the problem is, I know there is no way I'll ever be able to educate the entire user community, there's always someone browsing the manual - and that, in itself, is a blessing of sorts, since they aren't asking me - so I created a solution, the simplest, cheapest solution I could think of. It works. The meter for determining if the mailer subsystem works, is whether you get any mail from users or MAILER-DAEMON complaining. That's the only meter that really counts. I'm not interfering in anyone's productivity, I'm keeping them from impinging on mine. You may call it administrative fascism ... but I think of it as facilitating things, overall ... maintaining functionality, at the cost of an occasional damaged ego, perhaps, but maintaining functionality. One person objects, but they are inevitably a minority. Is this fascism ? >> Michael I. Bushnell \ This above all; to thine own self be true >> GIG! \ And it must follow, as the night the day, >>mike@turing.cs..unm.edu /\ Thou canst not be false to any man. >> Hmmmm.............. / \ Farewell: my blessing season this in thee! -- richard -- * "Do not look at my outward shape, but take what is in my hand." * * -- Jalaludin Rumi, 1107-1173 * * ..{amdahl|decwrl|octopus|pyramid|ucbvax}!avsd.UUCP!childers@tycho * * AMPEX Corporation - Audio-Visual Systems Division, R & D *
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (02/07/89)
comp.mail.headers, right? Yeah, I thought so. There *is* a comp.mail.misc, folks.
leres@ace.ee.lbl.gov (Craig Leres) (02/08/89)
Karl Kleinpaste writes: > comp.mail.headers, right? Yeah, I thought so. There *is* a > comp.mail.misc, folks. Why so uptight, Karl? Too much caffeine? Craig