I am parsing process details out of /proc/PID and I am so far unable to find who owns a process from that meta directory's files.
Documentation does not seem to point to that info as well:
The owner of the process is the owner of all files in the /proc/PID directory.
$ ls -l /proc/27595
total 0
dr-xr-xr-x 2 me users 0 Jul 14 11:53 attr
-r-------- 1 me users 0 Jul 14 11:53 auxv
...
Also the file /proc/PID/loginuid holds the UID of the owner of the process.
$ cat /proc/27595/loginuid
1000
The owner of the files in /proc/[pid]/ is not always the user -- programs can e.g. make themselves "non-dumpable" to avoid leaking sensitive information if they become another user, and then the file ownership of the files in the directory can change to root.
But normally the UID of the process can be retrieved by an fstat call (or a stat command ) on the /proc/[pid] directory itself.
Related
I am trying to create a user "foo" on the docker host from within a container, but it fails.
The following files are volume-mounted read-write in the container:
/etc/group:/etc/group:rw
/etc/gshadow:/etc/gshadow:rw
/etc/passwd:/etc/passwd:rw
/etc/shadow:/etc/shadow:rw
When running the following command as root inside the container:
adduser --debug --system --shell /bin/bash --group foo
Then the output is:
Selecting UID from range 100 to 999 ...
Selecting GID from range 100 to 999 ...
Adding system user `foo' (UID 130) ...
Adding new group `foo' (GID 139) ...
/sbin/groupadd -g 139 foo
groupadd: failure while writing changes to /etc/group
adduser: `/sbin/groupadd -g 139 foo' returned error code 10. Exiting.
Permissions of these files look okay to me. Both on the docker host as well as inside the container, permissions are the same.
-rw-r--r-- 1 root root 1167 apr 14 12:51 /etc/group
-rw-r----- 1 root shadow 969 apr 14 12:51 /etc/gshadow
-rw-r--r-- 1 root root 3072 apr 14 12:51 /etc/passwd
-rw-r----- 1 root shadow 1609 apr 14 12:51 /etc/shadow
I have also tried chattr -i on these files, but it still fails.
Is there some other file that I have overlooked and needs to be mounted? Is it even possible what I am trying to achieve?
When you mount an individual file, you end up mounting the inode of that file with the bind mount. And when you write to the file, many tools create a new file, with a new inode, and replace the existing file with that. This avoids partial reads, and other file corruption risks if you were to modify the file in place.
What you are attempting to do is likely a very bad idea, it's the very definition of a container escape, allowing the container to setup credentials on the host. If you really need host access, I'd mount the folder in a different location because containers have other files that are automatically mounted in /etc. So you could say /etc:/host/etc and access the files in the container under /host/etc. Just realize that's even a larger security hole.
Note, if the entire goal is to avoid permission issues between the host and the container, there are much better ways to do this, but that would be an X-Y problem.
I have two groups manually created in /etc/group:
file-owner:x:300:user
user:x:400:
I have a configuration file, owned by the user/group file-owner. I don't want other users to read it.
ls -l /tmp/my-configs.txt
-r--r----- 1 file-owner file-owner 1054552 Jun 11 12:22 /tmp/my-configs.txt
I run a process with id user:user but I cannot read the configuration file owned by file-owner.
Am I doing something wrong?
Suppose I lock a file which is controlled by RCS
[root#host1:/etc/yp]# co -l group auto_home
RCS/group,v --> group
revision 1.6103 (locked)
done
RCS/auto_home,v --> auto_home
revision 1.4003 (locked)
done
[root#host1:/etc/yp]#
I see the files with ",v" generated in RCS directory
[root#host1:/etc/yp/RCS]# ls -lrth | tail -3
-r--r--r-- 1 root other 16M Feb 20 12:20 passwd,v
-r--r--r-- 1 root other 3.5M Feb 21 23:03 group,v
-r--r--r-- 1 root other 4.1M Feb 21 23:03 auto_home,v
[root#host1:/etc/yp/RCS]#
Can we determine who is holding the lock file?
All of the admins use the "root" login for making the changes ( by sudo -s to become root)
If someone has already locked, I see the below message
[root#campyp:/etc/yp]# co -l group
RCS/group,v --> group
revision 1.6103 (locked)
writable group exists; remove it? [ny](n): ^C
RCS: Interrupt
RCS: Cleaning up.
[root#campyp:/etc/yp]#
Can we check who has locked the file?
In RCS, locks are stored in the header of the archive-file. Here is an example header to illustrate:
head 1.1;
access
thomas;
symbols;
locks
thomas:1.1; strict;
comment ## #;
1.1
date 2014.08.14.00.40.55; author thomas; state Exp;
branches;
next ;
desc
##
The rlog command gives that header information:
$ rlog 2linux,v
RCS file: 2linux,v
Working file: 2linux
head: 1.1
branch:
locks: strict
thomas: 1.1
access list:
thomas
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
----------------------------
revision 1.1 locked by: thomas;
date: 2014/08/14 00:40:55; author: thomas; state: Exp;
RCS_BASE
=============================================================================
By default, the author of a lock is determined by checking environment variables LOGNAME and USER. Those are set when your users sudo, e.g., to "root". But the behavior can be overridden:
When you sudo, the original $USER is saved in SUDO_USER. One could reset $LOGNAME and $USER from $SUDO_USER, making locks correspond to the real users.
RCS is documented to support setuid operation with the files owned by root. You may be able to use that, rather than having your users sudo.
Further reading:
rlog(1)
rcsfile(5)
ci(1) (see discussion of setuid)
No. If all your users are root, then the lock will always belong to root.
This is a dubious arrangement at best, anyway. Have users commit edits as themselves; there should be no sane reason to do these things as root in the first place.
Background
I have a test script that creates and destroys file systems on the fly, used in a suite of performance tests.
To avoid running the script as root, I have a disk device /dev/testdisk that is owned by a specific user testuser, along with a suitable entry in /etc/fstab:
$ ls -l /dev/testdisk
crw-rw---- 1 testuser testuser 21, 1 Jun 25 12:34 /dev/testdisk
$ grep testdisk /etc/fstab
/dev/testdisk /mnt/testdisk auto noauto,user,rw 0 0
This allows the disk to be mounted and unmounted by a normal user.
Question
I'd like my script (which runs as testuser) to programmatically create a btrfs file system on /dev/testdisk such that the root directory is owned by testuser:
$ mount /dev/testdisk /mnt/testdisk
$ ls -la /mnt/testdisk
total 24
drwxr-xr-x 3 testuser testuser 4096 Jun 25 15:15 .
drwxr-xr-x 3 root root 4096 Jun 23 17:41 ..
drwx------ 2 root root 16384 Jun 25 15:15 lost+found
Can this be done without running the script as root, and without resorting to privilege escalation (use of sudo) within the script?
Comparison to other file systems
With ext{2,3,4} it's possible to create a filesystem whose root directory is owned by the current user, with the following command:
mkfs.ext{2,3,4} -F -E root_owner /dev/testdisk
Workarounds I'd like to avoid (if possible)
I'm aware that I can use the btrfs-convert tool to convert an existing (possibly empty) ext{2,3,4} file system to btrfs format. I could use this workaround in my script (by first creating an ext4 filesystem and then immediately converting it to brtfs) but I'd rather avoid it if there's a way to create the btrfs file system directly.
I want to know how does a process in Linux decides what privileges it has?
Suppose there is a binary program Read_File that reads from file /home/myname/data.txt and displays the contents of it to the STD output; now, how does Read_File decides whether or not it has permission to read data.txt, what type of ids it checks to decide the privileges?
First, a bit of background:
The process is usually run by a specific user. So for example, if you log in yourself and run the program, it will run with the same privileges as yourself. You can check the permissions on the file with either stat or ls -l.
Using stat
malbert#dredg:/tmp$ stat foo
File: `foo'
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: fb00h/64256d Inode: 618 Links: 1
Access: (0644/-rw-r--r--) Uid: (11204/ malbert) Gid: (10513/domain users)
Access: 2011-06-10 13:03:27.181227226 +0200
Modify: 2011-06-10 13:03:27.181227226 +0200
Change: 2011-06-10 13:03:27.181227226 +0200
The important infos here are:
Access: (0644/-rw-r--r--) Uid: (11204/ malbert) Gid: (10513/domain users)
This tells you the permissions for the owner (rw-), group (r--) and everyone else (r--). It also shows you the current owner id (Uid) and the current group id (Gid).
The abbreviations stand for:
r = read access
w = write access
x = execute/traverse directory access
Using ls -l
ls -l gives you a quick summary:
malbert#dredg:/tmp$ ls -l /tmp
total 48
drwx------ 2 malbert domain users 4096 2011-06-10 08:51 akonadi-malbert.zOSngu
-rw-r--r-- 1 malbert domain users 0 2011-06-10 13:03 foo
drwx------ 2 kdm nogroup 4096 2011-06-10 08:51 kde-kdm
drwx------ 3 malbert domain users 4096 2011-06-10 08:51 kde-malbert
[snip]
Here you can see the same info as with stat, but as a summary. Also, the uid's and gid's are resolved into names (in this case malbert and domain users). You can use ls -u to see these as numeric values.
In case you want to run the application as a different user as yourself, you can either use su, sudo or your application itself can drop priviledges and change the user it is running as. This is usually the way system daemons do things.
ACLs / extended attributes
Be careful about extended attributes. When listing the files using ls -l these are visible with an appended + sign. For example:
malbert#dredg:/tmp$ ls -l
total 48
drwx------ 2 malbert domain users 4096 2011-06-10 08:51 akonadi-malbert.zOSngu
-rw-rwxr--+ 1 malbert domain users 0 2011-06-10 13:03 foo
drwx------ 2 kdm nogroup 4096 2011-06-10 08:51 kde-kdm
drwx------ 3 malbert domain users 4096 2011-06-10 08:51 kde-malbert
[snip]
Notice the following line:
-rwxr--+ 1 malbert domain users 0 2011-06-10 13:03 foo
The + sign in -rwxr--+ points to extended attributes. It is possible that these are ACLs. There is an excellent document on ACLs in the SuSE documentation. Go have a look at it if you need to. Explaining ACLs would certainly explode this article, so I won't discuss those.
Extended attributes could also be related to the file system. See the man page of chattr for more information on that.
Now, as a sidenote: this is StackOverflow. Questions should be development related. For questions like this one, there's http://www.serverfault.com. But As you were not aware, that this is not a development problem, but more related to the OS, I felt I should answer anyway ;)
Good luck, and have fun!
The process doesn't decide anything; whenever it tries an operation the operating system checks it's EUID and decides if has the required privileges.
For example when it tries to access a file, the owner and permissions of the file are checked. If the EUID of the process doesn't have enough privileges for an operation, that operation will fail (usually with EPERM).