[114] in DCNS Development
Reid's comments on AFS default protections
daemon@ATHENA.MIT.EDU (nschmidt@Athena.mit.edu)
Tue Sep 24 10:56:21 1991
From: nschmidt@Athena.mit.edu
To: developers@Athena.mit.edu
Date: Tue, 24 Sep 91 10:55:42 EDT
------- Forwarded Message
Received: by ATHENA-PO-1.MIT.EDU (5.45/4.7) id AA16847; Tue, 24 Sep 91 10:50:26 EDT
Received: from E40-302-4.MIT.EDU by Athena.mit.edu with SMTP
id AA03799; Tue, 24 Sep 91 10:50:09 EDT
Received: by e40-302-4.MIT.EDU (5.61/4.7) id AA05125; Tue, 24 Sep 91 10:50:04 -0400
Message-Id: <9109241450.AA05125@e40-302-4.MIT.EDU>
To: nschmidt@Athena.mit.edu
Cc: mar@Athena.mit.edu, carla@Athena.mit.edu, dot@Athena.mit.edu,
lavin@Athena.mit.edu, roden@Athena.mit.edu
Subject: Re: Major problem with AFS
In-Reply-To: Your message of Mon, 23 Sep 91 17:42:03 -0400.
<9109232142.AA24028@brahms.MIT.EDU>
Date: Tue, 24 Sep 91 10:50:02 EDT
From: Reid M. Pinchback <reidmp@Athena.mit.edu>
I agree, the difference in default security behaviour could be disturbing
to users, particularly when we go and move the user community to AFS.
Those used to setting umask to create their default security/privacy may get
a bit nervous about what they may perceive as an increased tendency
towards inadvertently creating security/privacy holes. It isn't that AFS
directories *can't* be protected, just that users would need to pay more
attention to it. This seems counter-intuitive. We go to all the effort of
having automated tasks so that we don't have to constantly focus on grungy
details. This situation requires us to manually address security concerns
on an on-going basis. Maybe we need AFS to pay attention to umask or an
equivalent variable when permissions are set on new files/directories,
perhaps combining the mask with inheritence in some intelligent and
conservative (with regards to security) way.
Reid
------- End of Forwarded Message
