How to grant a user rights to change ownership of files/directories in a directory

Question

How do I grant a specific user the right to change user and group ownership of files and directories inside a specific directory?

I did a Google search and saw that there is such a thing as setfacl, which allows for granting users specific rights to change permissions for files and directories. From what I read, though, this command does not allow granting chown permissions.

So, say a file has

user1 user1 theFile1
user1 user1 theDirectory1

Issuing the following command would fail.

[user1@THEcomputer]$ chown user2 theFile

I do have root access on the computer. Is there a way to grant a user to issue chown commands inside a directory?

UPDATE: How to add a user to a group.

Here is the article that I used to add datamover to the hts group.

[root@Venus ~]# usermod -a -G datamover hts
[root@Venus ~]# exit
logout
[hts@Venus Receive]$ groups
hts wireshark datamover
[hts@Venus Receive]$ 

UPDATE (address comment by RuiFRibeiro):

Changing the ownership of the directory to the directory does not work, see screenshot.

[datamover@Venus root]$ ls -la
total 311514624
drwxrwxrwx. 6 datamover datamover         4096 Oct 14 14:05 .
drwxr-xr-x  4 root      root              4096 Aug 20 16:52 ..
-rwxrwxrwx. 1 datamover datamover          674 Aug 31 16:47 create_files.zip
drwxrwxrwx  2 datamover datamover         4096 Oct 17 17:07 dudi
-rwxrwxrwx. 1 datamover datamover 318724299315 Oct 13 15:47 Jmr400.mov
-rwxrwxrwx. 1 datamover datamover    182693854 Aug 31 16:47 Jmr_Commercial_WithSubtitles.mov
-rwxrwxrwx. 1 datamover datamover     80607864 Aug 31 16:47 Jmr_DataMover_Final.mov
drwxrwxrwx. 2 datamover datamover       122880 Aug 23 11:54 ManyFiles
drwxrwxrwx. 3 datamover datamover         4096 Oct 25 07:18 Receive
drwxrwxrwx  2 datamover datamover         4096 Oct 14 13:40 sarah
-rwxrwxrwx  1 datamover datamover      3184449 Oct 14 14:05 SourceGrid_4_40_bin.zip
[datamover@Venus root]$ cd ./Receive/
[datamover@Venus Receive]$ ls -la
total 178540
drwxrwxrwx. 3 datamover datamover      4096 Oct 25 07:18 .
drwxrwxrwx. 6 datamover datamover      4096 Oct 14 14:05 ..
-rwxrwxrwx  1 hts       hts       182693854 Oct 25 07:18 Jmr_Commercial_WithSubtitles.mov
drwxrwxrwx  2 datamover datamover    122880 Oct 23 13:33 ManyFiles
[datamover@Venus Receive]$ chown datamover:datamover ./Jmr_Commercial_WithSubtitles.mov
chown: changing ownership of './Jmr_Commercial_WithSubtitles.mov': Operation not permitted

Here is an attempt as the owner of the file:

[hts@Venus Receive]$ chown datamover:datamover Jmr_Commercial_WithSubtitles.mov
chown: changing ownership of 'Jmr_Commercial_WithSubtitles.mov': Operation not permitted

So as you can see, neither possibility works.

UPDATE (address countermode's answer)

Group ownership may be changed by the file owner (and root). However, this is restricted to the groups the owner belongs to.

Yes, one does have to log out first. Here is the result of my attempt:

[hts@Venus ~]$ groups hts
hts : hts wireshark datamover
[hts@Venus ~]$ cd /mnt/DataMover/root/Receive/
[hts@Venus Receive]$ ls -la
total 178540
drwxrwxrwx. 3 datamover datamover      4096 Oct 25 07:18 .
drwxrwxrwx. 6 datamover datamover      4096 Oct 14 14:05 ..
-rwxrwxrwx  1 hts       hts       182693854 Oct 25 07:18 Jmr_Commercial_WithSubtitles.mov
drwxrwxrwx  2 datamover datamover    122880 Oct 23 13:33 ManyFiles
[hts@Venus Receive]$ chown hts:datamover ./Jmr_Commercial_WithSubtitles.mov 
[hts@Venus Receive]$ ls -la
total 178540
drwxrwxrwx. 3 datamover datamover      4096 Oct 25 07:18 .
drwxrwxrwx. 6 datamover datamover      4096 Oct 14 14:05 ..
-rwxrwxrwx  1 hts       datamover 182693854 Oct 25 07:18 Jmr_Commercial_WithSubtitles.mov
drwxrwxrwx  2 datamover datamover    122880 Oct 23 13:33 ManyFiles
[hts@Venus Receive]$ chown datamover:datamover ./Jmr_Commercial_WithSubtitles.mov 
chown: changing ownership of ‘./Jmr_Commercial_WithSubtitles.mov’: Operation not permitted
[hts@Venus Receive]$ 

Adding hts to the datamover group does indeed allow me to change the ownership of the group part, so now a partial answer and validation for the statement.

Solution

Only root has the permission to change the ownership of files. Reasonably modern versions of Linux provide the CAP_CHOWN capability; a user who has this capability may also change the ownership of arbitrary files. CAP_CHOWN is global, once granted, it applies to any file in a local file system.

Group ownership may be changed by the file owner (and root). However, this is restricted to the groups the owner belongs to. So if user U belongs to groups A, B, and C but not to D, then U may change the group of any file that U owns to A, B, or C, but not to D. If you seek for arbitrary changes, then CAP_CHOWN is the way to go.

CAUTION CAP_CHOWN has severe security implications, a user with a shell that has capability CAP_CHOWN could get root privileges. (For instance, chown libc to yourself, patch in your Trojan Horses, chown it back and wait for a root process to pick it up.)

Since you want to restrict the ability to change ownership to certain directories, none of the readily available tools will aid you. Instead you may write your own variant of chown that takes care of the intended restrictions. This program needs to have capability CAP_CHOWN e.g.

setcap cap_chown+ep /usr/local/bin/my_chown

CAUTION Your program will probably mimic the genuine chown, e.g. my_chownuser:group filename(s). Do perform your input validation very carefully. Check that each file satisfies the intended restrictions, particularly, watch out for soft links that point out of bounds.

If you want to restrict access your program to certain users, you may either create a special group, set group ownership of my_chown to this group, set permissions to 0750, and add all users that are permitted to this group. Alternatively you may use sudo with suitable rules (in this case you also don't need capability magic). If you need even more flexibility, then you need to code the rules you have in mind into my_chown.

Comments

[Admin]

@RuiFRibeiro I updated my question with two screenshots showing the two different possibilities. As you can see, neither option, namely directory or file owner, works.

[Admin]

@Christopher If I understand your question, and that is a big if, the answer is yes in this exercise, although the capability should be to any user or group, not just always the same. In my case, they are the same, but in general I should be able to specify any valid UID and GUID.

[Admin]

Please don't post images of text, the colours in the screenshot don't matter in this case, and makes the text actively harder to read. Just copy the relevant parts of the text.

[Sarah Weinberger]

The CAP_CHOWN sounds like a global capability to the entire file system, whereas I want to restrict to a specific directory and its children. Also, the answer does not indicate how to give a specific user CAP_CHOWN in CentOS. I also do not want a user to be able to access root, just grant permission to change ownership of files and groups. Note CentOS 7.

[countermode]

CentOS or not doesn't matter for your question. It is just one Linux distribution among many, and they mostly differ by the software packages and the admin interface they provide, and how things are set up. The foundation is Linux, and there is no distribution A where Linux can do things that it can't do with distribution B (proprietary kernel drivers set aside).

[countermode]

@SarahWeinberger Copy & paste as formatted text is preferred to screen shots. Anyway, what is the output of groups hts? If this does not include datamover, then the result is as expected. ~ N.B. If you add a user to a group, then that user must first logout and login again for the change to take effect.

[Sarah Weinberger]

I did not realize that I have to log out first in order for the usermod -a -G <groupname> username change to take affect. Once I did that and verified with the groups hts command, I was indeed able to do a chown hts:datamover <filename> and have that work. I definitely learned something about Linux today. Thank you!

[countermode]

@SarahWeinberger Unfortunately, the UI to capabilities is far from intuitive. The above line is analogous to assigning the SUID bit to an executable. The underlying FS needs to support extended attributes, e.g. ext4, for capabilities are stored as extended attribute. The mechanism is similar to SUID - an executable with, say, CAP_CHOWN capability that is execved will result in a process with this capability. e and p are flags according to effective and permitted capabilities - don't care about that for the moment, just suppose that the command above does what you need here.

[countermode]

@SarahWeinberger As of what creates the program and what creates the restrictions: you have to write the program. The entire decision logic defined by you is at the core of my_chown.