Adam Done <[EMAIL PROTECTED]> writes: > Why is it nesseccory to put some files into subdirectories would they > still be subjected to AFS ACLs?
It's not that they have to be in subdirectories to be subject to ACLs, since everything in AFS is subject to ACLs, but rather that AFS ACLs are per-directory, not per-file. Some applications, SSH most notably, likes to put different files with different readability requirements in the same directory (authorized_keys should be public, for example, whereas identity needs to be private). In order to make those applications do the right thing, one sometimes has to move some of those files into another directory and replace them with symlinks so that the access control is correct. (SSH with public key authentication works poorly with AFS in the best of circumstances, since when you authenticate with a public key there's no way to get an AFS token automatically, so that application in particular may not be the best example.) > And would I do this just to to files that are always in the home > directory (.ssh, .xsession)? What about new .configs that the user > creates when using an application i.e. in GNOME? It's best to make whatever directory the user treats as their home directory not world-readable by default and then just special-case the files that need to be world-readable, since there are far fewer of those. A common tactic is to make the top-level directory world-listable but not world-readable and then create a public directory that's world-readable, put world-readable files in it, and then symlink them to their expected locations. The drawback of this approach is that it means pretty much all the files and directories created by a naive user will be world-listable, which isn't ideal, but it's straightforward and easy to set up. We take that approach a step further and pre-create certain directories (News, Mail, WWW) that require special ACLs and set them up appropriately. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> _______________________________________________ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
