Setting default username and group for files in directory

Question

Using this helpful post I am able to set a default group and file permissions in a folder.

I'm having trouble setting a default owner (teamlead uid 1234).

setfacl -d -m g::rwx /my/test/folder
setfacl -d -m o::rx /my/test/folder

getfacl /my/test/folder

# file: /my/test/folder
# owner: teamlead
# group: web_prod
# flags: -s-
user::rwx
group::r-x
other::r-x
default:user::rwx
default:group::rwx
default:other::r-x

With that:

[mary@boxen]# touch /my/test/folder/somefile
[mary@boxen]# ll /my/test/folder/somefile
-rw-rw-r--. 1 mary web_prod 0 Nov  6 08:58 somefile

So the right group is assigned, but the new file has ownership of the user creating the file. I'd like newly created files to have teamlead:web_prod owner/group.

It appears that setfacl can be used to set a default user, too. With the existing folder acl config (above):

[mary@boxen]# setfacl -d -m u:1234:rwx /my/test/folder

Now to create a file as a different user. I'm expecting it to have teamlead:web_prod ownership.

[mary@boxen]# touch /my/test/folder/anotherfile
[mary@boxen]# ll /my/test/folder/anotherfile
-rw-rw-r--+ 1 mary web_prod 0 Nov  6 08:58 somefile

New file still has ownership of the owner creating the file, not uid 1234(teamlead).

Is what I'm after even possible, or is the way I'm going about this wrong?

Solution 1

With setfacl you can set default permissions but not default owner/group for newly created files.

To get new files to be owned by a specific user, you'd need a setuid bit that works like the setgid bit on directories. Unfortunately that is not implemented.

With setfacl you can do something which is nearly equivalent in most scenarios: You can set an ACL like default:user:teamlead:rwx (e.g. setfacl -d -m u:teamlead:rwx foo). That way the named user can write the new files, even if somebody else owns it.

Solution 2

A new file is always created belonging to the user that the process creating the file is running as. (The effective user ID, to be precise.) This cannot be changed, because allowing users to create files belonging to other users would be security hole, similar to allowing non-root users to give away a file.

Whatever you're trying to do, you don't need to do this. ACLs are sufficient to ensure that whatever will need to read the file later will have sufficient permissions. Leave the file owned by the user who created it.

Solution 3

If you want to that the new files will be created with the new group, you need change the primary group.

For this you can use usermod and the parameter -g

   -g, --gid GROUP
       The group name or number of the user's new initial login group. The group must exist.
       Any file from the user's home directory owned by the previous primary group of the user will be owned by this new group.
       The group ownership of files outside of the user's home directory must be fixed manually.

e.g.

test2@kinakuta:/tmp$ id
uid=1002(test2) gid=1002(test2) grupos=1002(test2),1003(testgroup)
test2@kinakuta:/tmp$ touch test2
test2@kinakuta:/tmp$ ls -la test2
-rw-r--r-- 1 test2 test2 0 nov 23 22:26 test2
root@kinakuta:/tmp# usermod -g testgroup test2
root@kinakuta:/tmp# su test2
test2@kinakuta:/tmp$ touch test2_1
test2@kinakuta:/tmp$ ls -la test2_1 
-rw-r--r-- 1 test2 testgroup 0 nov 23 22:27 test2_1

Comments

[Gbo]

The question is about assigning ownership to newly created files. Group is already correctly assigned.

[bviktor]

"ACLs are sufficient to ensure that whatever will need to read the file later will have sufficient permissions." False. Your new file's group will be your user's default group. If the users collaborating have different default groups, you won't be able to access each other's files. You need setgid to make the parent folder's group "stick" to all children.

[Gilles 'SO- stop being evil']

@bviktor You can achieve the same effect with ACL.

[bviktor]

How do you specify the owner and group for new files with ACL?

[Gilles 'SO- stop being evil']

@bviktor The owner is whoever creates the file, that doesn't change. The group that owns the file in the traditional permissions is irrelevant. The ACL on new files is the directory's default ACL, in the same way that the owning group on new files is the directory's owning group with BSD semantics (g+s).

[bviktor]

@Gilles nope. The group of new files will be the creator user's "initial login group", not the parent folder's group. The behavior you describe (i.e. new file gets the parent dir's group) requires setgid to be set on the parent. And the group is very relevant because when users collaborate, they can't access each others' files if the group is different. Unless your files are world-accessible which isn't exactly a great idea.

[Gilles 'SO- stop being evil']

@bviktor The point of ACL is that they make files available to whichever users and groups they grant access to. The behavior that the new file gets the parent directory's owning group is not necessary with ACL; instead the new file gets the parent directory's access control list.

[bviktor]

@Gilles Unix ACL does NOT grant access to specific users or groups, that's Windows ACL! That's the whole point, which you keep arguing against. Unix ACL specifies the permissions that the owner, group and others get, not who the owner and group are!

[Gilles 'SO- stop being evil']

@bviktor “Unix ACL specifies the permissions that the owner, group and others get” More generally, Unix ACL can specify the permissions that any user and group gets, not just the permissions that the owning user and owning group get. I'm not familiar with Windows ACL, and I don't know what point you think I “keep arguing against”, but it is a fact that Solaris/Linux/FreeBSD/… ACL (known as “POSIX ACL” although the POSIX draft that proposed them was rejected), which are the topic of this question, can assign permissions to arbitrary users and groups, not just to the owners.

[bviktor]

@Gilles not sure if trolling or ... but I just gave up.

[user319862]

Please update this answer with the command to apply the 'default:user:teamlead:rwx' to directory '/foo'