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.
Related
We are getting the error "permission denied" when trying to write to a file that is owned by a service user and a shared group. In particular that is www-data:www-data and the user trying to write to it is in the group www-data.
There is no acl on none of the parent folders and the permissions to the file and folders are correct.
Here some details:
$ sudo -u deploy id -Gn
www-data
$ ls -lah /tmp
drwxrwxrwt 17 root root 4.0K Jul 11 11:22 .
drwxr-xr-x 23 root root 4.0K Jul 8 10:08 ..
...
-rw-rw-r-- 1 www-data www-data 0 Jul 11 10:50 test
...
$ echo 'hello world' | sudo -u deploy tee -a /tmp/test
tee: /tmp/test: Permission denied
hello world
we tried that on different folders and made sure there is no acl on any of the folders or parents or files...
Unfortunately that is not described in the link stark posted in the comment. And also not in any other page I found until I found an answer here on stackoverflow that clarified it.
2018 two new filesystem configurations got added to sysctl that should prevent regular files and fifos from beeing opened with the O_CREAT flag (as append mode is doing) in directories with the sticky bit set unless the user is the owner of the file. This commit added the settings: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=30aba6656f61ed44cba445a3c0d38b296fa9e8f5
To change that behaviour you have to set fs.protected_regular to 0:
sudo sysctl fs.protected_regular=0
Or to persist the change add fs.protected_regular=0 to your sysctl.conf.
side node: since O_CREAT is not deleting or renaming the file I'm wondered why it is connected to the sticky bit. It really is possible to create a file in directories with the stick bit set.
I am using docker on ubuntu 16.04 with user id mapping (user namepsaces) enabled. I have following settings:
/etc/passwd
myusername:x:1000:1000:,,,:/home/myusername:/bin/bash
/etc/subuid
myusername:100000:65536
/etc/subguid
myusername:100000:65536
When I start a container the files are being correctly mapped from 0 (root) to my subuid 100000.
host
-rw-r--r-- 1 100000 100000 0 Mär 30 13:05 testfile
container
rw-r--r-- 1 root root 0 Mar 30 13:05 testfile
I can read the file on the host machine, but I cannot edit it. My assumption was that 100000 is "my" subuid, so I can edit those files. How can I achieve that those files are accessible by myusername without sudo?
I'm not sure how to fix this with user namespace mapping but you can work around it with ACL's.
If you don't mind leaking some UID information into the container, you can add an ACL to the directory for your host user. ACL's sit on top of the standard POSIX permissions.
To set a default ACL on the parent directory, that new entries inherit:
setfacl -d -m u:1000:rwx volume_dir/
To set the ACL on all existing files and directories in a directory:
setfacl -R -m u:1000:rwX volume_dir/
The X auto detects directories and sets them to executable but skips making files executable. Unfortunately this type of differentiation is not available on the default ACL.
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.
My crontab isn't running and I'm trying to figure out why. I've created a symbolic link within /etc/cron.d to /var/www/mysite.crontab
user#ip-xxxxxxxxxx:/etc/cron.d$ ll
total 20
drwxr-xr-x 2 root root 4096 Apr 11 03:48 ./
drwxr-xr-x 96 root root 4096 Apr 16 00:50 ../
lrwxrwxrwx 1 root root 30 Apr 11 03:47 mysite.crontab -> /var/www/mysite.crontab
-rw-r--r-- 1 root root 124 Feb 27 2012 drupal7
-rw-r--r-- 1 root root 544 Sep 12 2012 php5
-rw-r--r-- 1 root root 102 Apr 2 2012 .placeholder
The actual cron file is...
#Purge old deals
4 1 * * * www-data wget -q -O- http://www.mysite.com/cron/clean > /dev/null 2>&1;
Oddly enough the problem is with the name of the file. You are not permitted to use a . as a part of the name of the file when present in the /etc/cron.d dirctory.
The logic for this is in the database.c file, in the function valid_name. Renaming the file to something like mysite_crontab should fix the issue.
In general, the filename should probably just be a simple name mysite the fact that it's in this directory implies that it's a cron file already.
The file that is being pointed to must be owned by root, this is stated in the man page for the support of the /etc/cron.d directory:
Support for /etc/cron.d is included in the cron daemon itself, which handles this location as the system-wide crontab spool. This directory can contain any file defining tasks following the format used in /etc/crontab, i.e. unlike the user cron spool, these files must provide the username to run the task as in the task definition.
Files in this directory have to be owned by root, do not need to be executable (they are configuration files, just like /etc/crontab) and must conform to the same naming convention as used by run-parts(8): they must consist solely of upper- and lower-case letters, digits, underscores, and hyphens. This means that they cannot contain any dots. If the -l option is specified to cron (this option can be setup through /etc/default/cron, see below), then they must conform to the LSB namespace specification, exactly as in the --lsbsysinit option in run-parts.
The intended purpose of this feature is to allow packages that require finer control of their scheduling than the /etc/cron.{hourly,daily,weekly,monthly} directories to add a crontab file to /etc/cron.d. Such files should be named after the package that supplies them.
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).