On Wednesday 04 January 2006 1:48 pm, Jeffrey Altman wrote: > This should be a reasonable approach. For all machines that > are being logged into using gssapi krb5, those machines must > have been issued a Kerberos principal and they must have a > keytab. Assign the principal an AFS ID and then use a program > such as kstart to obtain and maintain a AFS token in the PAG > within which the sshd resides. Add the AFS ID to a an AFS > group and provide that group rl privileges on the top level > directory of the home volume. This will provide the sshd > the ability to read the directory without requiring that the > directory be world readable. > > Now if you want to lock things down a bit more, move all of > the dot files to a new directory on which 'rl' is granted > for the group and instead give the group 'l' privilege on > the top-level directory and place symlinks from the top-level > directory to the real dot files. This will prevent sshd > from being able to read any of the files in the top-level > directory but it will be able to follow the symlinks to > read the dot files that it requires. > > Jeffrey Altman
This could work to a point, although it strikes me as being a hackish workaround to a capability (well, granularity) that should be in the filesystem to begin with. Authenticating the daemon makes sense. Having to symlink all the authentication files into a separate directory to limit the daemon's privileges is messy and prone to problems induced by user error. It also gives the SSH daemon list privileges to each new directory a user creates in the top level of their home directory, which they would then have to change. If there's a compromise due to this additional privilege, involving e.g. an SSH private key being created in or copied to the wrong place, that could be bad. Best regards, Lester Barrows _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
