I seem to have run into an interesting problem with NSS translating Linux
permissions correctly. No matter what I do, the permissions are always
translated as "666". The main concern here is that OpenSSH is specifically
looking for "400" on the $HOME/.ssh/authorized_keys file for certain users
(in my case FTP via SSH -- These clients need to use public-key

OpenSSH has the ability to ignore the file permissions ("StrictModes yes"
in the /etc/ssh/sshd_config file) and, under normal circumstances, OpenSSH
recommends not doing this. However, since this is an NSS volume with all
the eDirectory rights bells and whistles (i.e. only eDirectory users have
explicit rights to their own home directory), I'm thinking this isn't much
of a security risk.

Can anyone think of a reason why setting OpenSSH to ignore file permissions
would be a security risk inside of an eDirectory enviroment? Obviously,
group/world read/writable in a plain Linux environment would be stupid, but
all of our $HOME directories are NSS-controlled.

btw -- "StrictModes yes" is a workaround ("bandaid") in order to get SSH to
allow public-key authentication to work. The real problem here is that NSS
does not appear to be translating NSS file/directory rights to Linux
permissions. Any other application that requires specific file permissions
will most likely break, since NSS appears to be offering only "666" for
file permissions, regardless of what you try to set them to (via chmod).