9

When I use setfacl to manage on what permissions should the children files / directories have, for some reason the files have all the permissions except the execute ("x") one.

someuser@someuser-MS-7816:/opt/lampp/htdocs/project$ getfacl .
# file: .
# owner: someuser
# group: webs
# flags: -s-
user::rwx
group::rwx
other::rwx
default:user::rwx
default:group::rwx
default:other::rwx

someuser@someuser-MS-7816:/opt/lampp/htdocs/project$ touch file
someuser@someuser-MS-7816:/opt/lampp/htdocs/project$ mkdir dir
someuser@someuser-MS-7816:/opt/lampp/htdocs/project$ ls -l
total 4
drwxrwsrwx+ 2 someuser webs 4096 paź 31 13:35 dir
-rw-rw-rw-  1 someuser webs    0 paź 31 13:35 file

I thought it has something to do with umask but changing it in various ways never gives the expected result unless I'm missing something.

How can this be fixed?

11

Hauke Laging’s answer is trying to say:

Any program that creates a file or directory specifies the mode (permissions) that it wants that file to have.  This is almost always hard-coded in the C program (or whatever language is used) and is hardly ever directly accessible to the user.  Then the umask value and the default ACL can turn off permission bits, but not add them.

Your problem is that, while mkdir specifies a mode of 777 (rwxrwxrwx), almost all programs that create files specify 666 (rw-rw-rw-).  This includes touch, the shell (for I/O redirection; e.g., program > file), the editors (vi, vim, emacs, etc…), dd, split, and so on.  Therefore, you will not get permissions of rwxrwxrwx on a plain file immediately upon creation (by any of these programs), no matter what you do with ACLs; you must create the file and then chmod it.

There are a couple of exceptions to this rule:

  • cp and related programs (e.g., cpio, tar, etc.) that copy or otherwise re-create a file, which will (attempt to) set the new file to the same mode as the original file.
  • Compilers, which create binary executable files, specify a mode of 777 (at least, if the compilation succeeds), so the user will actually be able to execute the program they just compiled.
7
  • I assume this only applies to the traditional Unix permission modes, which correspond to the user, group, and other ACL entries. If you have default ACL entries for named users or groups, they'll be inherited as specified, right? – Barmar Oct 31 '14 at 20:26
  • Is this a quote from somewhere? If so, please add the source and, if not, please remove the quote formatting. – terdon Jan 29 '16 at 13:10
  • @terdon: It’s not a quote; it is (as described) a paraphrase of Hauke Laging’s answer.  How should this be handled?  (1) I could have edited the other answer, but I know that massive rewrites of other people’s posts are frowned upon.  (And note, FWIW, that my rep on this site was < 2000 in October 2014.)  (2) I could have posted it as a comment on the other answer.  Or rather, I could have posted it as a series of three comments, since it’s > 1200 characters.  But that’s not consistent with my understanding of the purpose of comments.  … (Cont’d) – Scott Jan 29 '16 at 19:11
  • 1
    Hey, it wasn't a complaint! This is a fine answer and I only found it because I was wondering the same thing. I would just remove the quote formatting, that's all. Posting an answer clarifying an existing one is fine as long as you mention the original (which you did). Yes, adding a link would be a good idea but it's no big deal. You are clearly not just copying his answer into yours. – terdon Jan 29 '16 at 19:15
  • 1
    I didn’t think it was a complaint; thanks for the praise.  But surely you realize that any request from a rhombus-person has the air of an iron fist in a velvet glove.   :-)   P.S. I have edited my answer in accordance with your suggestion. – Scott Jan 29 '16 at 19:32
4

You don't mention what the "expected result" is. I assume it is the files having the x bits set.

You cannot enforce that as default ACL (like umask) just prevents permissions but does not set them itself. A new directory or file does not get more permissions (for user, group, and other) than the open() or mkdir() call which creates it requests.

For files usually only read and write permission is requested. But if a compiler creates a binary file then it requests execute permission, too.

1
  • Your response is quite chaotic from the English point of view. Can you please correct it? Also I'm not sure what you mean. Take a look at my code. For directories it always works. For files it also always works except the "x" bit. Also if it's not the proper way to do this, then what is except setting an umask each time a directory is accessed? – user294034 Oct 31 '14 at 13:56
1

$ touch file && chmod a+x file

The explanations in other answers are superb. I want to add something that actually gives an answer to the question,

How can this be fixed?

with specific code. @Scott told how to do this,

you must create the file and then chmod it.

The code in my answer shows how to do it and highlights it by putting it first.


More Explanation

To start out, for simplicity, I simply add to the touch command given by the OP, specifically touch file becomes touch file && chmod a+x file.

someuser@someuser-MS-7816:/opt/lampp/htdocs/project$ touch file && chmod a+x file
someuser@someuser-MS-7816:/opt/lampp/htdocs/project$ mkdir dir
someuser@someuser-MS-7816:/opt/lampp/htdocs/project$ ls -l
total 4
drwxrwsrwx+ 2 someuser webs 4096 paź 31 13:35 dir
-rwxrwxrwx  1 someuser webs    0 paź 31 13:35 file

Here, I'll set up the same situation on my machine (Cygwin) to show that it works, then do the same on a virtual Ubuntu box to show the differences in the setup. (Note that the actual command for fixing things doesn't change, I simply want to show some differences that might come up with setfacl, as well as to verify for myself that it works.)

$ uname -a | head -n 1 
CYGWIN_NT-10.0 my_machine 2.10.0(0.325/5/3) 2018-02-02 15:16 x86_64 Cygwin
$ pwd
/home/me
$ mkdir user294034
$ setfacl -m u::rwx user294034/
$ setfacl -m d:u::rwx user294034/
$ setfacl -m g::rwX user294034/
setfacl: illegal acl entries
$ setfacl -m g::rws user294034/
setfacl: illegal acl entries
$ # I guess I don't know how to get the `flags: -s-` on Cygwin
$ setfacl -m g::rwx user294034/
$ setfacl -m d:g::rwx user294034/
$ setfacl -m o::rwx user294034/
$ setfacl -m d:o::rwx user294034/
$ cd user294034
$ getfacl .
# file: .
# owner: me
# group: my_group
user::rwx
group::rwx
other:rwx
default:user::rwx
default:group::rwx
default:other:rwx
$ # I admitted that I don't know how to get `# flags: -s-`
$ umask
0022
$ umask 0000
$ touch file
$ mkdir dir
$ # Here, we'll see the same problem
$ ls -l
total 0
drwxrwxrwx+ 1 me my_group 0 Sep 18 20:31 dir
-rw-rw-rw-  1 me my_group 0 Sep 18 20:31 file
$ # Here, we'll fix the problem
$ rm file
$ touch file && chmod a+x file
$ ls -l
total 0
drwxrwxrwx+ 1 me my_group 0 Sep 18 20:31 dir
-rwxrwxrwx  1 me my_group 0 Sep 18 20:32 file
0

You may try this simple script replaces the ACL records for each file and directory, giving the default permissions specified.

$ cd ~
$ mkdir .config
$ cat <<'EOF' >> .config/dacl
user::rwx
group::rwx
other:r-x
default:user::rwx
default:group::rwx
default:other:r-x
EOF
$ cat <<'EOF' >> .config/facl
user::rw-
group::rw-
other:r--
default:user::rw-
default:group::rw-
default:other:r--
EOF

$ cd /
$ find $1 -type d -exec setfacl -f ~/.config/dacl {} \;
$ find $1 -type f -exec setfacl -f ~/.config/facl {} \;

$ getfacl .
# file: .
# owner: MyUser
# group: Administrators
user::rwx
group::rwx
other::r-x
default:user::rwx
default:group::rwx
default:other::r-x

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.