[OpenAFS] home on afs woes

[Lester Barrows]

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