3

I already know I cannot use chown willi-nilly as a normal user however in my situation I have two users: user1 and user2 where user1 is allowed, by the Sudoers file, to sudo in as user2.

Is it still not possible for user1 to give ownership of the file to user2?

The best I have come up with so far is to have user1 perform:

user1@localhost$ sudo --user user2 cp fileOwnedByUser1 /tmp/fileOwnedByUser1
user1@localhost$ rm fileOwnedByUser1
user1@localhost$ sudo --user user2 mv /tmp/fileOwnedByUser1 fileOwnedByUser1

However, this seems clunky and ineficient. Is there a better way for user1 to do this? The only thing that occures to me so far, is to put user1 as being able to run "chown" as root in the Sudoers file.

Improve this question
  • Letting user1 run chown as root is a bad idea. You may as well give them full root access, as chown can be used to get, for example, a setuid shell. – cas Oct 6 '15 at 21:36
  • Perhaps you should review your need to set the ownership, which is really only useful when handling quotas, for example. Why not put the 2 users in the same group and allow group write permissions, or use setfacl -d -m u:user2:rwx on a directory so that all files created there by user1 are writable by user2? – meuh Oct 7 '15 at 8:25
  • @meuh: Unfortunately, it isn't only usefull when handling quotas. In this case user1 is setting up and configuring a file structure in user2's home directory. It would be extremely weird and user-unfriendly to have user2 then have files in their home dir that they don't own. – timthelion Oct 7 '15 at 14:38
  • I agree. So why isn't user1 using sudo as user2 to create the files in the first place? Can't you do something like having the files in a dir and just tar-copying them whilst user2? Like /etc/skel is copied when users are created. – meuh Oct 7 '15 at 14:48
1

The fact that user1 is allowed to run commands as user2 via sudo doesn't matter for the file permission decisions that are taken at a much lower level, in the kernel. There, chown is reserved to root (Linux also allows processes with the capability CAP_CHOWN, but that doesn't help you because giving a process this capability amounts to indirectly giving it root privileges).

You could write a sudo rule, perhaps with a small wrapper script, that allows user1 to call chown on files that belong to user2. The problem is that this is insecure because there would be a race condition between the ownership check on the file and the call to chown: user1 (or even a third user, depending on directory permissions) could substitute another file between the check and the action.

You can write a small program that uses the fchown system call: open the file, call lstat, verify the current ownership, and if everything is fine then call fchown. There's no risk of a file substitution here since the check and the action are performed on the same file handle.

Improve this answer
  • Gilles: Do I understand correctly that you are sugesting that I write a small suid program? – timthelion Oct 7 '15 at 14:40
  • @timthelion That's the only secure method I can think of, assuming you do need to change ownership (rather than copy and delete, or use ACL). – Gilles 'SO- stop being evil' Oct 7 '15 at 15:49
  • I have selected your answer, because I am afraid that you are correct, and that there is no other way to do chowning as a normal user securely besides writing a suid program. However, I will not be taking that route in my final design, because hacking around the problem is actually more practical for me than writing a suid program and having to defend that fact to packagers. – timthelion Oct 8 '15 at 19:27

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.