The file created by start-stop-daemon does not respect the acl on the file system. I'm giving a step-by-step commands to reproduce the issue: # REMOUNT THE FILESYSTEM WITH ACL CAP. arcadia ~ # mount -o remount,acl / # CREATE A DIRECTORY WHERE RUN THE TESTS arcadia ~ # mkdir /test # SAY TO SETFACL THAT THE USER AGO HAS RWX ON FILES IN THE /TEST DIRECTORY arcadia ~ # setfacl -R -m u:ago:rwx /test arcadia ~ # setfacl -R -m d:u:ago:rwx /test # TOUCH A TEST FILE IN THE /TEST DIRECTORY (AS ROOT) arcadia ~ # touch /test/test.txt # CHECK THE PERMISSION WITH GETFACL (FINE, USER AGO HAS RWX) arcadia ~ # getfacl /test/test.txt getfacl: Removing leading '/' from absolute path names # file: test/test.txt # owner: root # group: root user::rw- user:ago:rwx #effective:rw- group::r-x #effective:r-- mask::rw- other::r-- # SU - AGO arcadia ~ # su - ago * keychain 2.8.1 ~ http://www.funtoo.org * Found existing ssh-agent: 2023 # LET'S TEST IF USER AGO IS REALLY ABLE TO WRITE IN THE FILE CREATED BY ROOT, SO THE ACL WORKS? YES ago@arcadia ~ $ echo "foo" >> /test/test.txt && echo $? 0 # SIMULATE WHAT START-STOP-DAEMON DOES, AND CREATE A start-stop-daemon.out FILE arcadia ~ # start-stop-daemon --start --quiet --background --stdout /test/start-stop-daemon.out --chdir /test/ --user root:root --exec echo -- "this is a test" # CHECK THE PERMISSION OF THE FILE CREATED BY start-stop-daemon arcadia ~ # getfacl /test/start-stop-daemon.out getfacl: Removing leading '/' from absolute path names # file: test/start-stop-daemon.out # owner: root # group: root user::rw- user:ago:rwx #effective:--- group::r-x #effective:--- mask::--- other::--- # USER AGO IS UNABLE TO WRITE IN THE FILE CREATED BY START-STOP-DAEMON, SO IT DOES NOT RESPECT THE ACL RULES ago@arcadia ~ $ echo "something" >> /test/start-stop-daemon.out -su: /test/start-stop-daemon.out: Permission denied
Here's a summary from an IRC discussion in #gentoo-dev. - ACL mask entry is populated based on group access bits in call to open(2). - start-stop-daemon calls open(2) with mode 0600. - This should be changed to 0660 or 0640 to allow default ACL to "work". 0660 == (S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP) 0640 == (S_IRUSR | S_IWUSR | S_IRGRP )
(In reply to Mike Gilbert from comment #1) > Here's a summary from an IRC discussion in #gentoo-dev. > > - ACL mask entry is populated based on group access bits in call to open(2). > - start-stop-daemon calls open(2) with mode 0600. > - This should be changed to 0660 or 0640 to allow default ACL to "work". > > 0660 == (S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP) > 0640 == (S_IRUSR | S_IWUSR | S_IRGRP ) Thanks for the summary. I guess 660 is fine. With 640 the user is still unable to write.
(In reply to Agostino Sarubbo from comment #2) > Thanks for the summary. > I guess 660 is fine. With 640 the user is still unable to write. I'm not sure why group members or users added via default ACL would need write access to a log file owned by a daemon. Do you have a use case for that?
(In reply to Mike Gilbert from comment #3) > I'm not sure why group members or users added via default ACL would need > write access to a log file owned by a daemon. Do you have a use case for > that? Maybe is not a common situation, but happens for me. We have a lot of jar launched as daemon with s-s-d. These jars run with a nologin user, and we have developers (with bash shell) that needs to see the logs of those jars. Unfortunately some services write thousand and thousand of lines of log and developers sometimes need to delete the log to understand better what happens. If my request is not acceptable, I will adjust my setup with something custom like start_pre()
(In reply to Agostino Sarubbo from comment #4) > Maybe is not a common situation, but happens for me. > If my request is not acceptable, I will adjust my setup with something > custom like start_pre() I'm just trying to better understand your needs to help the openrc devs select between the alternatives. > Unfortunately some services write thousand and thousand of lines of log and > developers sometimes need to delete the log to understand better what > happens. A funny thing about UNIX permissions: to delete (unlink) a file, you need write access on the parent directory. The permissions on the file itself do not matter. On the other hand, to truncate a file in-place, you need write access to the file. Anyway, 0660 seems reasonable to me.
(In reply to Mike Gilbert from comment #5) > (In reply to Agostino Sarubbo from comment #4) > > Maybe is not a common situation, but happens for me. > > If my request is not acceptable, I will adjust my setup with something > > custom like start_pre() > > I'm just trying to better understand your needs to help the openrc devs > select between the alternatives. I never thought that your had bad intentions :)
Submitted a pull request.
https://github.com/openrc/openrc/commit/171e856 This will be included in openrc-0.21.
