> Our analysis (subject to correction) is that we have two choices for
> this transfer of home directories:
>
> 1. Make the top level directory system:anyuser rl, and create a
> private subdirectory for all users. Move their protected
> files into the private directory and use symbolic links to
> make the top level look the same.
>
> The problems we see with this are
> a. a user can save mail into his/her top level and it's readable
> b. some user will do rm * in the private directory because "they
> were just duplicate files". Don't laugh, we've been there.
> c. cp mbox mbox.hold creates a readable copy.
> etc. There are non-intuitive ramifications to regular UNIX
> commands.
>
> 2. Protect the top level directory with system:anyuser l permissions
> only. Everything is still unreadable, and the user can create
> a public subdirectory if he/she wants to.
>
> However, this means that many files now expected to be readable
> by root are unreadable. Specifically,
> .forward - sendmail expects to read this
> .plan - finger expects to read this
> calendar
> .rhosts
> and I've probably missed a few here.
> And if you 'rlogin' rather than 'telnet' from one of our trusted
> machines, you come in without a token and can't even read your
> .login. [Side question - since rsh machine csh -i carries your
> token along, has anyone modified an rlogin to do the same?]
>
> I'm sure many other sites have faced this choice. What did you do?
Here at RPI, we protect the top level directory with system:anyuser l
permissions, but we also create subdirectories like this:
private no permissions except owner
public system:anyuser rl
yesterday mount point for the user's backup volume
We explained that users can move a file into their public directory to
share it, or move it into private to prevent it from being seen.
Users can move and link their necessary dotfiles into the public
directory if they wish, and many users have done this.
By making the choices explicit for them, the users can understand and
choose where to store their files. And if they decide to make
subdirectories under public or private, the inherited acls are correct
because they were precreated that way.
Jim Ault, ITS Systems Programmer, [EMAIL PROTECTED] <><
