21

I have a directory that contains data shared between a number of users. Access to this directory and anything underneath, will be controlled by the directory's group, which will be added to the users in question. As such I created the folder "sticky group" chmod g+s set. The directory will contain a tree structure with directories and files, with the total amount of files likely being a few million. The files will be fairly small, I don’t anticipate anything bigger than 50MB.

My problem is that the owner of the file or directory is still the user that created it. As such, even if i should remove that user from the access group, I would not remove his access completely.

So:

Are there other options I missed for ensuring that all files and sub-directories have the same owner?

I expect I could periodically surf through the entire directory with a cron-job, but that strikes me as inefficient for what is essentially a once-pr-file command.

I found an example using INotify but that strikes me as high-maintenance, since it requires scripting.

I haven't been able to figure out if ACL can help me with forced ownership.

Is there a smarter way to do this?

What I want is to have a directory that can be shared by adding a group to a user. Anything created in this directory inherits the permission scheme from its parent. If there is a better way than what I’m attempting, I’m all ears.

  • I don't think i understood what you were trying to tell me. Can you elaborate? – Martin Nielsen Nov 4 '14 at 10:11
  • For setting all files and sub-directories having same group & ownership, why not to use chown -hR owner:group? – Pandya Nov 4 '14 at 10:17
  • It is possible, but since new files are being created all the time, and we are talking files in the millions, it would require a cron job that surfs the entire directory periodically. Unless i am missing some point? – Martin Nielsen Nov 4 '14 at 10:18
  • I actually skimmed that question prior to creating this one. It does not seem to address how to force the owner to a specific user. – Martin Nielsen Nov 4 '14 at 13:34
12

Setting a default owner "automatically" would require a directory setuid behaving like setgid. However, while this can be configured on FreeBSD, other UNIX & Linux systems just ignore u+s. In your case however, there might be another solution.

What I want is to have a directory that can be shared by adding a group to a user. Anything created in this directory inherits the permission scheme from its parent. If there is a better way than what I’m attempting, I’m all ears.

So, basically, from what I see, you want to control the access to a directory using the groups mechanism. However, this does not require you to restrict the permissions in the whole directory structure. Actually, the directory --x execution bit could be just what you need. Let me give you an example. Assuming that...

  • The group controlling the access to the group_dir directory is ourgroup.
  • Only people in the ourgroup group can access group_dir.
  • user1 and user2 belong to ourgroup.
  • The default umask is 0022.

... consider the following setup:

drwxrws---    root:ourgroup   |- group_dir/
drwxr-sr-x    user1:ourgroup  |---- group_dir/user1_submission/
drwxr-sr-x    user2:ourgroup  |---- group_dir/user2_submission/
-rw-r--r--    user2:ourgroup  |-------- group_dir/user2_submission/README

Here, let's assume every item was created by its owner.

Now, in this setup:

  • All directories can be browsed freely by everyone in ourgroup. Anyone from the group can create, move, delete files anywhere inside group_dir (but not deeper).
  • Anyone who's not in ourgroup will be blocked at group_dir, and will therefore be unable to manipulate anything under it. For instance, user3 (who isn't a member of ourgroup), cannot read group_dir/user2_submission/README (even though he has r-- permission on the file itself).

However, there's a little problem in this case: because of the typical umask, items created by users cannot be manipulated by other members of the group. This is where ACLs come in. By setting default permissions, you'll make sure everything's fine despite the umask value:

$ setfacl -dRm u::rwX,g::rwX,o::0 group_dir/

This call sets:

  • Default rw(x) permissions for the owner.
  • Default rw(x) permissions for the group.
  • No permissions by default for the others. Note that since the others can't access group_dir anyway, it does not really matter what their permissions are below it.

Now, if I create an item as user2:

$ touch group_dir/user2_submission/AUTHORS
$ ls -l group_dir/user2_submission/AUTHORS
rw-rw----    user2:ourgroup    group_dir/user2_submission/AUTHORS

With this ACL in place, we can try rebuilding our previous structure:

drwxrws---+    root:ourgroup   |- group_dir/
drwxrws---+    user1:ourgroup  |---- group_dir/user1_submission/
drwxrws---+    user2:ourgroup  |---- group_dir/user2_submission/
-rw-rw----+    user2:ourgroup  |-------- group_dir/user2_submission/README

Here again, each item is created by its owner.

Additionally, if you'd like to give a little bit more power/security to those using the directory, you might want to consider a sticky bit. This would, for instance, prevent user1 from deleting user2_submission (since he has -w- permission on group_dir) :

$ chmod +t group_dir/

Now, if user1 tries to remove user2's directory, he'll get a lovely Operation not permitted. Note however that while this prevents directory structure modifications in group_dir, files and directories below it are still accessible:

user1@host $ rm -r user2_submission
Operation not permitted

user1@host $ cat /dev/null > user2_submission/README

user1@host $ file user2_submission/README
user2_submission/README: empty (uh-oh)

Another thing to take into account is that the ACLs we used set up default permissions. It is therefore possible for the owner of an item to change the permissions associated to it. For instance, user2 can perfectly run...

$ chown g= user2_submission/ -R
or
$ chgrp nobody user2_submission -R

... hence making his full submission directory unavailable to anyone in the group.

However, since you're originally willing to give full rws access to anyone in the group, I'm assuming you're trusting these users, and that you wouldn't expect too many malicious operations from them.

  • Will ACL overrule the default permissions? For example, if i set $ setfacl -dRm u::r,g::rwX,o::0 group_dir/ instead, to only allow members of the group to create files, would the owner be able to edit the files while not in the group? It is critical that users can only edit the files if they are members of the group, regardless of who the owner is. – Martin Nielsen Nov 6 '14 at 11:32
  • You don't need to remove all permissions from the owner for that. If the group has write permission on the file, the group members will be able to edit the file. The owner will just be "a little bit more privileged". ACLs do not always override default permissions (see about ACL effective permissions). – John WH Smith Nov 6 '14 at 13:14
  • The point is that the user should have no priviledges, only the group should. The owner should for all intents and purposes be completely unprivileged unless he/she is in the group. – Martin Nielsen Nov 6 '14 at 13:45
  • Basically, anyone who's not in the group is unprivileged anyway, since he wouldn't be able to enter group_dir in the first place, no matter if he owns the file or not. The only real "privilege" the owner has is that he may change the permissions of its creations (which I detailed a little bit more in my answer). – John WH Smith Nov 6 '14 at 14:30
  • 1
    Absolutely not. The group_dir directory is owned by root:ourgroup with -rwxr-x---, which means that only root and members of ourgroup may access it, i.e. do anything with the files under it. If you don't have --x permission on a directory, you can't access a file within it, even if you have permissions of the file itself. – John WH Smith Nov 6 '14 at 20:12
6

There is a smarter way to do this. It uses a combination of set-gid and default acls. Obviously, you will need an acl enabled file system. Let's assume the directory you want shared is at /var/grpdir and that members of group sharing should be able to access it.

chown root:sharing /var/grpdir
chmod 2770 /var/grpdir #other can't read or traverse into the directory, set-gid is set
setfacl -d -m u::rwX,g::rwX,o::0 /var/grpdir

Default ACLs are inherited by subdirectories created in a directory with default ACLs. So this means, any file created in /var/grpdir will have it's group set to sharing by the directory's setgid bit. Additionally, it will inherit the default acls, which will override the default linux style premissions, because we didn't specify ACLs with specific users or groups. This means all files will be created with ownership <user>:sharing and permissions rw-rw----. Directories will be the same, except they will also have their own default ACLs set to the same as their parent (/var/grpdir), and of course have the executable bits set for user and group. If you remove a user from the sharing group, they won't be able to access the directory (nor any files in it, even if they own them).

Unlike periodically correcting permissions with a cronjob, permissions are always in sync, as they are updated atomically with newly created files and directories. This solution is lightweight; no daemons are necessary, and there's no spike to IO whilst correcting permissions in one fell swoop.

  • So do i understand this correctly: ACLs will overwrite the normal file system permissions if you do not specify a user or group? – Martin Nielsen Nov 6 '14 at 11:36
  • 1
    No, they don't modify any permissions already set on a file. When a directory has default permission acls set, and a file or directory is created in that directory, the NEW file/dir will be given the default permissions as specified. Files copied/moved into the directory retain their permissions, as do files that existed in the directory before the acls are set. Also, chmod and chown can still be used as normal to modify ownership and permissions after the file had been created – sirlark Nov 6 '14 at 13:27
2

I am not aware of any good way to do this. The technically cleanest way would be a FUSE file system which does that. Of course, a lot of work if nobody has done that yet.

Alternatives:

  1. Use samba. samba has the force user parameter. You can export a directory locally and mount it locally. Doesn't make accesses faster but may be acceptable as only loop back networking is involved.

  2. Use a non-Linux file system like FAT32. This must be configured for a certain user to mount it. The access permissions must be handled by the parent directory.

0

I have not heard of any way to automatically change a files ownership such that the file owner is changed when the file is moved into a certain directory. The closest thing is the sticky bit, but it seems you have indicated that group ownership is not enough, the actual user ownership has to change.

In that case, I think your best bet is the cron job with the chown -R flag, as Pandya mentioned. Put it on a cron to run every minute or every five minutes.

If you can explain how your users are using this, there may be some better solution.

ACL can help you to get finer grain control on who is allowed to do what, it won't be automatically changing actual file ownership for you. I think you need to get a more elevated view and evaluate/redesign your solution on that basis.

0

You can use inotify-tools and write a simple bash script like below. Inotify will keep its eye on the directory web and do something whenever an event like dir creation will be occured inside web directory. There are many events existing. You can google it or may have look on this site

while inotifywait -m -e CREATE web; do echo "A new directory has been created"; done

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.