Improve behaviour for filesystems which don't support ACLs

[ericzolf]

When running podman run -it registry.centos.org/centos:8 bash (i.e. podman in non-root mode) and running the following:

[root@09d4044436b8 /]# getfacl '.' 
# file: .
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

[root@09d4044436b8 /]# python3 
Python 3.6.8 (default, Apr 16 2020, 01:36:27) 
[GCC 8.3.1 20191121 (Red Hat 8.3.1-5)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import posix1e
>>> posix1e.ACL(file='.')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 95] Operation not supported

i.e. basically the same operation which works from the command line, fails within python. I tried different paths, using an ArchLinux image and the result is always the same. The same action works in a container run as root, and I could accept the difference, but given that the same action works from the command line, it doesn't make sense that the library fails. We're talking pylibacl 0.5.4-3. Thanks.

[iustin]

I don't have centos, can you run strace on both of those and attach the files?

Also, what file system are you using?

On a non-container, this works for me as non-root, and the getxattr calls are slightly different, but succeed. I wonder what's different in your case.

[ericzolf]

I don't have centons, can you run strace on both of those and attach the files?

CentOS isn't relevant IMHO, you only need a Linux with podman which can run in user mode (my host system is Fedora), and then you can run for example podman run -it registry.centos.org/centos:8 bash then you are in the container and can run:

yum install epel-release
yum install python3-pylibacl
yum install python3
python3 -c 'import posix1e; posix1e.ACL(file=".")'

I tried strace but it is not allowed within a user container:

strace: ptrace(PTRACE_TRACEME, ...): Operation not permitted
strace: PTRACE_SETOPTIONS: Operation not permitted

Also, what file system are you using?

The container is stored on an ext4 partition (my home directory) but within the container it looks like fuse-overlayfs (given that it works at the command line level, I'm not sure it's relevant).

On a non-container, this works for me as non-root, and the getxattr calls are slightly different, but succeed. I wonder what's different in your case.

That I'm in a container run in user mode, but what that means exactly, no clue 😕

What I'm wondering though on my side is what is different between calling getfacl and using your library?

[ericzolf]

Aha, I can call strace from outside of the container:

$ strace -o podman_acl_strace.log podman exec -it reverent_lederberg python3 -c 'import posix1e; posix1e.ACL(file=".")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
OSError: [Errno 95] Operation not supported
Error: exec session exited with non-zero exit code 1: OCI runtime error

podman_acl_strace.log

And then I tried (with same error message) to call strace -ff -o podman_acl_strace2.log podman exec -it reverent_lederberg python3 -c 'import posix1e; posix1e.ACL(file=".")' and the resulting logfiles are here: podman_acl_strace2.tar.gz

In the file with PID 48077, I see getxattr(".", "system.posix_acl_access", 0x7ffd41fb5d80, 132) = -1 EOPNOTSUPP (Operation not supported)

Then I run:

strace -ff -o podman_acl_strace3.log podman exec -it reverent_lederberg getfacl .
# file: .
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

And the output is: podman_acl_strace3.tar.gz

Interestingly enough, in the PID 48562 file, I also see getxattr(".", "system.posix_acl_access", 0x7ffe516b5e70, 132) = -1 EOPNOTSUPP (Operation not supported) but then getfacl tries other things (which I don't understand) and succeeds.

Hope you can do something with it.

[iustin]

Ah, I see. The getfacl code does this, more or less:

                acl = acl_get_file(path_p, ACL_TYPE_ACCESS);
                if (acl == NULL && (errno == ENOSYS || errno == ENOTSUP))
                        acl = acl_get_file_mode(path_p);

where acl_get_file_mode is:

static acl_t
acl_get_file_mode(const char *path_p)
{
        struct stat st;

        if (stat(path_p, &st) != 0)
                return NULL;
        return acl_from_mode(st.st_mode);
}

So basically: try to read ACL. If it fails because it ACLs are not supported for that filesystem, create a synthetic ACL based purely on the file mode.

This makes a lot of sense for a command line tool, I'm not entirely sure that in a library fallback by default makes sense.

An option to the constructor to allow switching between raw and processed ACLs might allow whatever behaviour one wants, but at this point, the API is mirroring the C api.

[ericzolf]

Thanks for the analysis, I agree with your conclusion. Also in our case (rdiff-backup), it wouldn't make sense as we already save the file mode, so we would back-up something which doesn't really exist and would probably restore ACLs where there were none.

[iustin]

Cool, so just for the purposes of this bug - your problem is solved, I gather, by catching ENOTSUP and skipping the ACLs, correct?

I'll probably add that that parameter (e.g. create_synthetic_acls=False), but in no horry though :)

[ericzolf]

Well, yes but no :-) We were already catching properly the issue in our code, independent from containers, but I noticed this specific behaviour while I was trying to reproduce an issue in a container, also with the idea to use non-root containers for local testing (which would have been much more secure). It sounds like it'll remain an idea and no reality, unless I find a way to get full POSIX support within it.