[OpenAFS] home on afs woes
Wed, 4 Jan 2006 14:59:10 -0800
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.