How to change ownership of files when dropped into folders

Question

I need some help configuring default folder permissions on a 100TB vol that has 900+ user dirs on it. Each user has a hard quota limit of 25GB.

All user dir perms are set to 755, so every user can ‘see’ into each other user’s named space. We then set up a standard trio of dirs in each user’s space. The standard dirs are named, and their perms set, as follows:

% stat -c '%A %a %n' *
drws-wx-wx 4733 dropbox
drwx------ 700  private
drwxr-xr-x 755  public 

/private is set to 700, for user access only. Each user can store data that is for their eyes only in this dir;

/public is set to 755, so data can be shared with other users. The user can place files in the public dir so that other users can get to it and and make copies for their own use, but other users cannot write there; and

/dropbox is set to 4733, so it is set up to allow other users to drop files into it. The group sticky bit is turned on, so any file dropped into it will assume the GID of the dropbox folder.

These folders work great, set up the way they are, except for one issue that I cannot solve. From what I have read so far, what I need to do does not seem possible, which seems crazy to me (we REALLY need it, and I can’t be the only one out there who needs this capability!).

HERE’S THE NEED========

I need to be able to set up the default /dropbox folder perms for every user so that any file dropped into a user’s dropbox CHANGES OWNERSHIP to the user who owns the dropbox.

=======================

Under current capabilities of the system, when a file is dropped onto another user’s /dropbox dir, ownership remains with the original user. And because the g and o read bits are turned off, the original user no longer has access to the dropped file, since the perms of each /dropbox are set to 733 (write only access for the group and others). Because the file remains owned by the originating user, it is still counted against that user’s quota, even though the file is no longer in that user’s possession. Folks cannot ‘clean-up’ their own 25GB of space if data is spread around in other users’ dropboxes!

That’s REALLY bad for us because of how quota is managed: though we give each user a 25GB ‘space’, what we are really doing is giving each user 25GB of ‘data’, no matter where it lives in the tree. This means that data owned by a single user can exist all over the map, in lots of different /dropbox dirs, making it almost impossible for the user’s themselves to manage their quota. It also makes it hard on admins, because it is difficult to find all data owned by a single user on a vol of this size.

As an interesting aside, the /public directory perms do exactly what I need to have happen with the /dropox dirs, but in reverse: If a user goes into a different user’s /public dir, and grabs a file and copies it to their own named folder (or anywhere else, for that matter), the ownership of the file is changed to the ID of the user doing the copying, so it is then counted against that new user’s quota instead of the originating user’s. That’s perfect.

Also, I’ve set the g sticky bit on the /dropbox dir, such that when any file is dropped into it, the GID of the file being dropped is changed to the GID of the dropbox itself. That’s handy in case the target user is not in the group shown on the file — the group is changed, and the receiving user has access to the file.

This kind of change that can be done so easily for changing the GID on dropped files is EXACTLY the thing I need to have happen with ownership of the files being moved around. Turning on the sticky bit for the user on the folder does not work like turning on the sticky bit for the group — from what I have seen, no changes are effected on files dropped into /dropbox folders that have the user sticky bit on.

Environment: Mac and Linux utilizing NFS file servers. Users use both the GUI as well as command line to move data about.

Thanks very much for any help or guidance.

Answer 1

This mostly can't be done, except on some BSD-based systems.

The setgid that you are already using sets the group of any newly created files or directories to the same group that owns the directory, but setuid is ignored on directories and has a different meaning altogether on files.

From wikipedia's setuid article:

The setuid permission set on a directory is ignored on UNIX and Linux systems. FreeBSD can be configured to interpret it analogously to setgid, namely, to force all files and sub-directories to be owned by the top directory owner.

On systems derived from BSD, directories behave as if their setgid bit was always set, regardless of its actual value. As is stated in open(2), "When a new file is created it is given the group of the directory which contains it."