[898] in SIPB bug reports
/afs/.athena/contrib/sipb/lib/elisp/gnu-dist
daemon@ATHENA.MIT.EDU (daemon@ATHENA.MIT.EDU)
Sun Feb 18 17:08:24 1990
Date: Sun, 18 Feb 90 17:07:43 -0500
From: Jonathan I. Kamens <jik@PIT-MANAGER.MIT.EDU>
To: ambar@ATHENA.MIT.EDU
Cc: bug-sipb@ATHENA.MIT.EDU
In-Reply-To: Jean Marie Diaz's message of Fri, 16 Feb 90 13:59:19 -0500 <9002161859.AA26753@E40-008-8>
Date: Fri, 16 Feb 90 13:59:19 -0500
From: Jean Marie Diaz <ambar@ATHENA.MIT.EDU>
Reply-To: ambar@ATHENA.MIT.EDU
Usnail: 62 Bay State Avenue, Somerville MA 02144
Phonenet: (617) 628-5203
why are many of the files here owned by you (instead of me) and
not group-writable?
There are a couple fixes I have to install...
AMBAR
---------
Date: Fri, 16 Feb 90 16:19:50 EST
From: ambar@MIT.EDU
/afs/.athena/contrib/sipb/vaxbin/inews is writable only by you.
I'm really getting tired of this.
AMBAR
---------
Date: Fri, 16 Feb 90 16:44:57 -0500
From: Jean Marie Diaz <ambar@ATHENA.MIT.EDU>
Reply-To: ambar@ATHENA.MIT.EDU
Usnail: 62 Bay State Avenue, Somerville MA 02144
Phonenet: (617) 628-5203
mips and rt versions of a hacked inews have been installed. (A vax
version will be installed once jik deigns to change the permissions on
/afs/.athena/contrib/sipb/vaxbin/inews.) This inews parses (in a
simple-minded fashion, I'm afraid) the From: line of an outbound posting
and aborts the posting if 1) the user is root, or 2) if the user and the
parsed username do not match, printing appropriate messages in each
case.
this can easily be ducked by mailing the posting to
post-netnews@bloom-beacon.mit.edu. (repeat after me: "news is not secure.")
AMBAR
May I remind you, somewhat crossly (given the cross tone of your
messages), that /afs/.athena/contrib/sipb is an AFS VOLUME.
Group permissions don't mean diddly on AFS volumes. If "ls -l" on a
file says that it is owner-writeable, than it is writeable by anyone
in the ACL for the directory in which that file resides.
This may be changing in future AFS versions, but it has not, as far
as I know, changed yet.
Besides, why do you need write access to the file to change it? If
it's a binary, you have to delete and reinstall it anyway, so write
access to the file itself isn't going to help you.
And BTW, the reason so many of the files in
/afs/.athena/contrib/sipb are owned by me is because I have been the
primary maintainer of the whole locker for a long time, including such
thing as reconciling it from NFS (when NFS was the primary locker), so
many of the files are owned by me. Like I said, though, it doesn't
really matter.
jik
