A server stack is the collection of software that forms the operational infrastructure on a given machine. In a computing context, a stack is an ordered pile. A server stack is one type of solution stack — an ordered selection of software that makes it possible to complete a particular task. Like in this post about How can I chown a file to a subuid without sudo was one problem in server stack that need for a solution. Below are some tips in manage your linux server when you find problem about linux, user-permissions, chown, uid, .
Basically, What is going on here and what am I not understanding?
I have a set of subuids for my user. I want to chown a file to specific subuid which is part of this user’s allocation
administrator@host:/home/administrator$ cat /etc/subuid root:100000:65536 administrator:165536:65536 administrator:1000000:9000001 administrator@host:/home/administrator$ cat /etc/subgid root:100000:65536 administrator:165536:65536 administrator:1000000:9000001
Trying to chown this file is failing despite this subuid being part of the allocation.
administrator@host:/home/administrator$ ls -lhat ... -rw-rw-r-- 1 administrator administrator 229 Aug 2 13:00 file drwxrwxr-x 7 administrator administrator 4.0K Aug 2 13:00 .. administrator@host:/home/administrator$ chown 1500000:1500000 file chown: changing ownership of 'file': Operation not permitted administrator@host:/home/administrator$ stat file File: file Size: 229 Blocks: 8 IO Block: 4096 regular file Device: 802h/2050d Inode: 658357 Links: 1 Access: (0664/-rw-rw-r--) Uid: ( 1000/administrator) Gid: ( 1004/administrator) Access: 2018-08-02 13:00:36.529197108 +0000 Modify: 2018-08-02 13:00:36.529197108 +0000 Change: 2018-08-02 13:00:36.529197108 +0000 Birth: - administrator@host:/home/administrator$
However, I can remove the file as user, if I use sudo to chown it – but it shows as a write protected file when I do. This indicates I do in fact have permissions to modify files with this subuid.
administrator@host:~$ touch file administrator@host:~$ chown 1500000:1500000 file chown: changing ownership of 'file': Operation not permitted administrator@host:~$ sudo chown 1500000:1500000 file administrator@host:~$ rm file rm: remove write-protected regular empty file 'testfile.txt'? administrator@host:~$
Can anyone explain the inner workings which is going on here? I’ve probably misunderstood something basic somewhere. I can’t tag this as subuid because not enough rep, so I’ll use uid.
There is a program
lxc-usernsexec that comes along with
lxc. This allows you to remap user id’s using the maps
Specifically, you can do the following.
lxc-usernsexec -- touch /tmp/test
ls -l /tmp/testwill show that the file is owner:group the same as the first subuid:subgid pair in your map.
rm /tmp/testshould give an error since you do not currently have the right uid/gid.
lxc-usernsexec -- rm /tmp/testshould remove the file.
Hope this helps! The above probably requires various things setup for unprivileged LXC container use. In particular, I think
/proc/sys/kernel/unprivileged_userns_clone should be 1.
Subuids aren’t meant to work the way you expect them to work. They are designed to map UIDs in a user namespace to different UIDs outside that namespace, which comes in handy (and actually was designed) for containers.
However, a process still can have only one UID set (user namespace), and users are not permitted to change ownership of files, for obvious security reasons. It doesn’t matter, as far as the process itself is concerned, if the user is actually someone else outside the namespace.
This is why the
chown command fails: it doesn’t matter if you could have some other UID, should the namespace was different, at that moment, you don’t have that UID, and therefore, you can’t change the ownership of any files (since you’re not root).
As of why can you remove the file: it has actually nothing to do with subuids, instead, it all depends on you having the ownership of the directory the file resides in. Since file deletion changes the directory, and not the file itself, if you can write the directory, you can remove any files from that (except for “sticky” directories).
Your problem has nothing to do with subuid .
According to https://superuser.com/questions/697608/chown-operation-not-permitted
Non-privileged users (not root) cannot chown files to other user names. To use chown, a user must have the privileges of the target user. In other words, only root can give a file to another user.
As a complement to @Kapil’s answer, and since it may be difficult to install additional tools if you are not root, you can also use
podman unshare (shipped with Podman) or
rootlesskit (shipped with rootless Docker) as an alternative to
lxc-usernsexec (shipped with LXC).