Re: [OpenAFS] /afs permissions
Todd M. Lewis wrote: > Unfortunately, the only available "someplace" to turn on encryption is > on the client. Turning on encryption on a client encrypts all traffic > bound to that client (most of it unnecessarily). Yet the same data > passes in the clear if another client accesses it. > > It would be a Good Thing if encryption were a per directory thing like > an ACL, enforced by the server, so you could make sure your sensitive > information was never passed in the clear. I have no idea how hard it > would be to implement an "encrypted directory" flag, but I suspect it > would mean breaking things. Would this be a reasonable thing to put on > the wish list? It is a reasonable thing to add to the wish list. I want to see an ability to add at the directory, volume and file server level the ability to specify acceptable security classes and modes. Today we have: none rxkad, clear rxkad, encrypted If the client request does not satisfy the security requirements, an error is returned. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] /afs permissions
>It would be a Good Thing if encryption were a per directory thing like >an ACL, enforced by the server, so you could make sure your sensitive >information was never passed in the clear. I have no idea how hard it >would be to implement an "encrypted directory" flag, but I suspect it >would mean breaking things. Would this be a reasonable thing to put on >the wish list? I remember being at an AFS Workshop where someone suggested enforcing encryption on the server (I think his suggestion was at the volume level) ... boy, did that poor guy get crucified by the workshop participants. Personally, I think it's a good idea ... I'm not sure whether or not it would be easier to do it from an implementation standpoint at the volume or directory level, though. --Ken ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] /afs permissions
[EMAIL PROTECTED] wrote: On 10/28/05, Joe Buehler <[EMAIL PROTECTED]> wrote: Something of importance, is putting sensitive information like ssh private keys and PGP keys, etc in AFS is a bad idea unless you have encryption in there someplace. Same is true for any network based filesystem. Unfortunately, the only available "someplace" to turn on encryption is on the client. Turning on encryption on a client encrypts all traffic bound to that client (most of it unnecessarily). Yet the same data passes in the clear if another client accesses it. It would be a Good Thing if encryption were a per directory thing like an ACL, enforced by the server, so you could make sure your sensitive information was never passed in the clear. I have no idea how hard it would be to implement an "encrypted directory" flag, but I suspect it would mean breaking things. Would this be a reasonable thing to put on the wish list? -- +--+ / [EMAIL PROTECTED] 919-962-5273 http://www.unc.edu/~utoddl / / A bicycle can't stand alone because it is two-tired. / +--+ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] /afs permissions
On 10/28/05, Joe Buehler <[EMAIL PROTECTED]> wrote: > The default afsd options (for AIX machines at least) end up > producing a /afs directory that is mode 777. This causes > sshd to refuse to use public key files stored in .ssh > directories somewhere under /afs. Something of importance, is putting sensitive information like ssh private keys and PGP keys, etc in AFS is a bad idea unless you have encryption in there someplace. Same is true for any network based filesystem. -- Jay Kline http://www.slushpupie.com/ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] /afs permissions
Thus spake Joe Buehler ([EMAIL PROTECTED]): > My question is, where does the mode 777 come from? Well, who created the directory? > Is there any real reason for it to be 777 given that it's the AFS > mount point? Wouldn't 755 be a better mode? [10:38] [EMAIL PROTECTED]:~ $ ls -dl /afs drwxr-xr-x 2 root root 4096 Nov 9 2004 /afs [10:38] [EMAIL PROTECTED]:~ $ Works for me ... ;-) -- Consistency: Every time you release an apple over Sir Isaac Newton, it will drop on his head. That's good. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] /afs permissions
The default afsd options (for AIX machines at least) end up producing a /afs directory that is mode 777. This causes sshd to refuse to use public key files stored in .ssh directories somewhere under /afs. You need "StrictModes no" in sshd_config. My question is, where does the mode 777 come from? As far as I know, there is nothing special about the mode on /afs. You could probably have your admin chmod it. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] /afs permissions
The default afsd options (for AIX machines at least) end up producing a /afs directory that is mode 777. This causes sshd to refuse to use public key files stored in .ssh directories somewhere under /afs. Adding -afsdb -dynroot -fakestat causes the mode to change to 755, which works properly. I haven't checked to see which option causes the mode change. My question is, where does the mode 777 come from? Is there any real reason for it to be 777 given that it's the AFS mount point? Wouldn't 755 be a better mode? -- Joe Buehler ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
