On Fri, Apr 30, 1999 at 04:38:57PM +0200, Magnus Ahltorp wrote:
> Why in the world would anyone want to have a /tmp in a distributed
> file system? It's bad enough as it is on a local disk. The only reason
> for having sticky bits on a local file system is that it's a major
> administrative overhe
Why in the world would anyone want to have a /tmp in a distributed
file system? It's bad enough as it is on a local disk. The only reason
for having sticky bits on a local file system is that it's a major
administrative overhead to create separate temp directories for each
user.
An add-only direc
We find /coda/tmp really handy around our cluster. No tokens needed,
available everywhere.
Also, the sticky bit issue applies to mail as well as tmp: it needs a
solution.
- Peter -
> [EMAIL PROTECTED] said:
> | > We find /coda/tmp really handy around our cluster. No tokens
> | > needed, available everywhere.
> |
> | (religious comment: this is just plain wrong)
How can an experience "we find" be wrong? It would indeed take religion
to object to that. Many of us use /coda
[EMAIL PROTECTED] said:
| > We find /coda/tmp really handy around our cluster. No tokens
| > needed, available everywhere.
|
| (religious comment: this is just plain wrong)
|
| Do you have a need for sticky bits there?
I completely agree with the observation that a directory for scratch
files
> We find /coda/tmp really handy around our cluster. No tokens needed,
> available everywhere.
(religious comment: this is just plain wrong)
Do you have a need for sticky bits there?
> Also, the sticky bit issue applies to mail as well as tmp: it needs a
> solution.
Shared mail directories ar
On Fri, 30 Apr 1999, Peter J. Braam wrote:
> > [EMAIL PROTECTED] said:
> > | > We find /coda/tmp really handy around our cluster. No tokens
> > | > needed, available everywhere.
> > |
> > | (religious comment: this is just plain wrong)
>
> How can an experience "we find" be wrong? It would inde
[EMAIL PROTECTED] said:
| So you want a sticky bit on the directory. Not a bad idea - this is
| also quite desirable for email spool directories etc. This is one of
| the main problems of the AFS/Coda security model. Where it tries to
| diverge from Unix it runs into trouble in system directori
On Thu, Apr 29, 1999 at 11:34:41AM -0400, Peter J. Braam wrote:
> So you want a sticky bit on the directory. Not a bad idea - this is
Exactly.
[...]
> So the picture would be roughly as follows: when you want to delete a
> file or remove a directory, we require rights on two objects: the pare
| > Also, the client does NOT now it's venus UID, even though it has a
| > token, it can only see the cleartext part, but has no way of
| > validating it. I found this out when working on the hoard stuff.
| ??? When does this apply? vuid is used in permission checking. Is
| this during disconne
[EMAIL PROTECTED] wrote:
>
> [EMAIL PROTECTED] said:
> | So you want a sticky bit on the directory. Not a bad idea - this is
> | also quite desirable for email spool directories etc. This is one of
> | the main problems of the AFS/Coda security model. Where it tries to
> | diverge from Unix it
Hi,
So you want a sticky bit on the directory. Not a bad idea - this is
also quite desirable for email spool directories etc. This is one of
the main problems of the AFS/Coda security model. Where it tries to
diverge from Unix it runs into trouble in system directories like
"mail", "/tmp" etc.
[EMAIL PROTECTED] said:
| I have a volume named public mounted in /coda/public and a group
| called public. I want that all user belong group public can write in /
| coda/public but can't delete file of other users. Is it possible
| without set a acl for any user ?
Well, you can set an ACL for
Hi,
I have a volume named public mounted in /coda/public and a group called
public. I want that all user belong group public can write in /coda/public
but can't delete file of other users. Is it possible without set a acl
for any user ?
Thanks.
14 matches
Mail list logo
