4

I can't manage to set x bit to created file.

archemar@foobar:~/D> echo echo hello world > v.sh
archemar@foobar:~/D> ls -l v.sh
-rw-rw-r--+ 1 archemar group1 17 Apr 12 08:12 v.sh

no x-bit, let's look at acl

archemar@foobar:~/D> getfacl v.sh
# file: v.sh
# owner: archemar
# group: group1
user::rw-
group::rwx                      #effective:rw-
group:group1:rwx             #effective:rw-
mask::rw-
other::r--

group1 is rwx in acl !!

let's look at acl for local dir

archemar@foobar:~/D> getfacl .
# file: .
# owner: FTP_D_adm
# group: admin
user::rwx
group::rwx
group:group2:rwx
group:admin:rwx
group:group1:rwx
mask::rwx
other::r-x
default:user::rwx
default:group::rwx
default:group:group1:rwx
default:mask::rwx
default:other::r-x

I am part of group1:

archemar@foobar:~/D> id
uid=1001(archemar) gid=1001(group1) groups=1001(group1),16(dialout),33(video)

let's try to execute

archemar@foobar:~/D> ./v.sh
-bash: ./v.sh: Permission denied

setting g+x is trivial, but real file will come through ftp. Is there a way to have bit x set ?

OS is suse 11.4, directory is NFS 3 mounted, ACL is set on filesystem.

Archemar
  • 31,554
  • "group1 is rwx in acl !!" -- well, no, because it tells you immediately afterwards that the effective permission is rw. This is because ACL will never implicitly grant execution rights as this would be dangerous. In fact you can't even do d:g:root:rwx, the file would still be effective rw despite being created by root and belonging to group root. – pzkpfw Feb 10 '21 at 13:00

2 Answers2

3

I don't think you can use ACLs to forcibly set a permission bit.

Using the Linux ACL man page as reference, the default ACL is copied to the file's permissions, but

  1. The access ACL entries corresponding to the file permission bits are modified so that they contain no permissions that are not contained in the permissions specified by the mode parameter [given to open(), creat() etc.].

Since the permission bit mask corresponds to the group permission bits, it's affected here.

If there is no default ACL, the umask is used instead, but the same masking is still done.

Which is of course in line with the usual custom of a program being able to limit the permissions to those it passes to open when creating the file, be it excluding execute permissions with mode 0666, or excluding other users from accessing the file with mode 0600.

ilkkachu
  • 138,973
1

This has been answered peripherally in these two questions:

How does umask affect ACLs?

https://superuser.com/questions/180545/setting-differing-acls-on-directories-and-files

The relevant bits are generally from man setfacl:

The perms field is a combination of characters that indicate the >permissions: read (r), write (w), execute (x), execute only if the file is a directory or already has execute permission for some user (X). Alternatively, the perms field can be an octal digit (0-7).

(Emphasis mine)

The relevant section from the first question in the anwser by @slm♦ is the following:

To summarize

  • Files won't get execute permission (masking or effective). Doesn't matter which method we use: ACL, umask, or mask & ACL.

  • Directories can get execute permissions, but it depends on how the masking field is set.

  • The only way to set execute permissions for a file which is under ACL permissions is to manually set them using chmod.

Which basically means that it seems you cannot do what you want to do with ACL, since very few programs actually explicitly say that they want to create an executable file.

Community
  • 1
user6075516
  • 898
  • 6
  • 11
  • 1
    I think that snippet from the setfacl man page refers to the input understood by the program, not behaviour implemented by the system. The section in question starts "The setfacl utility recognizes the following ACL entry formats..." – ilkkachu Apr 14 '17 at 13:25