Dear Sun-Managers,
I thought the group would be interested in a more accurate summary than
the original that I posted
Thanks to the careful reading of my summary by mikem@ll.mit.edu, he initially
questioned the [in]ability of a user to then remove the sticky bit on their own
home directory which would then allow them to remove the symbolic link even if
they were not the owner of the link. Since I hadn't needed to implement the
solutions received as of yet, I took the opportunity to try them out. In brief,
I added the sticky bit to my home directory and as root on my NFS server created
an arbitrary (but valid) symlink. I verified that root was indeed the owner.
Then, back at my workstation, I rm'd the symbolic link with nary a complaint
from the OS. In the second email from Michael, he clarified the
behavior of the stick bit based on (what else?) the man page for sticky(8)
which states:
A directory for which the sticky bit is set res-
tricts deletion of files it contains. A file in a sticky
directory may only be removed or renamed by a user who has
write permission on the directory, and either owns the file,
owns the directory, or is the super-user.
So the only way to actually prevent a user from deleting symlinks in
his/her homedir is to make sure that the person DOES NOT own their
homedir. A method for doing this was provided by Michael as well.
One would create a group for each user and be sure that the permissions
on their homedir's were set appropriately at the group level to then allow
only the user themselves to write to the directory. Any symlinks then
put in the homedir (as root for instance) would not be able to be deleted
by the user. I have yet to try this in practice but I will when I get the
chance. Thanks again to mikem@ll.mit.edu (Michael J Maciolek) for clarifying
the issues.
-- Joel
----- Begin Included Message -----
>From mikem@ll.mit.edu Tue Apr 27 13:42:29 1993
Received: from tcpg01a.ny.jpmorgan.com by newton.ny.jpmorgan.com (4.1/SMI-4.0)
id AA23435; Tue, 27 Apr 93 13:42:27 EDT
Received: by tcpg01a.ny.jpmorgan.com (5.65/fma-120691);
id AA11464; Tue, 27 Apr 93 13:42:26 -0400
Received: by jpmorgan.jpmorgan.com (5.65/fma-120691);
id AA10273; Tue, 27 Apr 93 13:42:25 -0400
Received: by ll.mit.edu (4.1/LL-1.3) id AA05663; Tue, 27 Apr 93 13:39:19 EDT
Return-Path: <mikem@ll.mit.edu>
Date: Tue, 27 Apr 93 13:39:18 -0400
From: mikem@ll.mit.edu (Michael J Maciolek)
To: shandelm@jpmorgan.com
Subject: Re: SUMMARY: chmod on symbolic links
Content-Length: 2852
Status: RO
Hmm...I hadn't really thought about it that carefully when I sent my
first message...I knew the owner would be able to set and remove the
sticky bit himself, but I hadn't really paid very close attention to
the actual workings of the sticky bit on a directory.
So after I got your message, I looked at man(8) sticky, and found this:
A directory for which the sticky bit is set restricts deletion
of files it contains. A file in a sticky directory may only be
removed or renamed by a user who has write permission on the
directory, and either owns the file, owns the directory, or is
the super-user.
Bottom line - if the user is the owner of the directory, he/she can
always delete any files that are in that directory. It seems that the
same solution to preventing the users from removing the sticky bit would
also make the sticky bit work the way you want - but the users must NOT
be allowed to own their own home directories.
This isn't entirely unworkable, by the way. Here's one possibility.
For each user, create a corresponding entry in the /etc/group file, and
make each user the sole member of his/her private group. Example:
/etc/passwd:
billc:*:1111:10:Bill C:/home/billc:/bin/csh
mikem:*:1234:10:Mike M:/home/mikem:/bin/csh
/etc/group:
staff:*:10:
billc:*:1111:billc
mikem:*:1234:mikem
We see that billc is user number 1111, mikem is user number 1234, and the
passwd file shows that both of them are members of the 'staff' group (as
are all staff personnel). We also see that there are groups named "billc"
and "mikem", and they have "billc" and "mikem" as their only members.
Now, we can make each user's home directory owned by root, group-owned by
whoever it belongs to, and (very important) make it group-writable:
% chown root.billc /home/billc
% chown root.mikem /home/mikem
% chmod 1775 /home/billc /home/mikem
% chmod g+s /home/billc /home/mikem
% ls -ldg billc mikem
drwxrwsr-t 2 root billc 512 Apr 27 13:00 billc/
drwxrwsr-t 2 root mikem 512 Apr 27 13:01 mikem/
End result: billc and mikem don't own their home directories, but they're
still the only ones who can write in them (except, of course, for root) since
they're only owner-writable by root, and group-writable by people in the
appropriate group (but there's no one in the billc group except billc, and
no one else in the mikem group, except mikem.)
Now, you (as root) can put all the extra files into this directory that
you want, and mikem can't delete or rename them. I think this achieves
the result that you desire, but at the cost of some additional overhead
managing the /etc/group file. It's not a big hassle; I maintain my group
file the same way (for different reasons).
Hopefully this will put some air back into your previously burst bubble. :-)
-- Mike Maciolek
mikem@ll.mit.edu
----- End Included Message -----
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:07:47 CDT