Solved linuxulator and FreeBSD ACL

Hello

I’ve setup a Linux (Devuan) chroot environment on my FreeBSD 13.x server. I’m using nullfs to mount few ZFS filesystems inside the chroot. One of these FS has ACLs,that the linux part seems unable to see:

Bash:
# grep /var/log /etc/fstab
/var/log            /compat/devuan01/var/hostlog        nullfs          rw,late                      0       0

# getfacl /compat/devuan01/var/hostlog
# file: /compat/devuan01/var/hostlog
# owner: root
# group: wheel
      group:splunk:r-x---a-R-c--s:-------:allow
            owner@:rwxp--aARWcCos:-------:allow
            group@:r-x---a-R-c--s:-------:allow
      group:splunk:r-----a-R-c---:f------:allow
      group:splunk:r-x---a-R-c---:-d-----:allow
         everyone@:r-x---a-R-c--s:-------:allow

# ls -ld /compat/devuan01/var/hostlog
drwxr-xr-x+ 11 root  wheel  420 Mar 28 16:00 /compat/devuan01/var/hostlog
# chroot /compat/devuan01 /bin/bash -l
# ls -ld /var/hostlog
drwxr-xr-x 11 root root 420 Mar 28 15:00 /var/hostlog

hence, any ACL remains ineffective for linux processes.

Is that to be expected? Is there a workaround?
 
Well, can you self-consume an NFS mount? It also means I need to run an NFS client in Linux userland, unless the FreeBSD host can be the client. I guess I could try (if fact I could also get rid of ACLs and change POSIX rights to indulge my needs).

But more importantly I would love to understand what is happening here with those ACLs and the Linux chroot.
 
I am afraid this “correctly” does not work (yet). zfsprops(7) says with respect to acltype: 😮
nfsv4

default on FreeBSD, indicates that NFSv4‑style ZFS ACLs should be used. These ACLs can be managed with the getfacl(1) and setfacl(1). The nfsv4 ZFS ACL type is not yet supported on Linux.​
So while nullfs(5) copies the nfsv4acls mount(8) option thus exposing ACL data for reading, linux(4) ain’t capable of doing anything with that. You may switch to acltype=posix but apparently then you can’t read/write ACLs from FreeBSD no more. 😩
This requires linux(4) supporting the getxattr/setxattr system calls, which, uhm… is not done yet? So you’ll need to run the actual Linux kernel.
 
I'd expect access rights to be enforced regardless of whether the userspace programs can read the metadata. So what's the issue exactly? (Also Linuxulator is not Linux, keep that in mind when reading man pages.)
 
I’m running the linux binary of Splunk in Linuxulator (/compat/devuan01 chroot).
Inside chroot it runs as splunkfwd, 1000:1000.
Outside chroot, 1000:1000 is undefined, so I’ve created a FreeBSD user:

Code:
splunklinux:*:1000:1000:Splunk Forwarder Linux:/opt/splunkforwarder:/bin/sh

Because my pre-existing ACL is built upon the pre-existing splunk group, I’ve added splunklinux to that group :

Code:
splunk:*:1032:splunkfwd,splunklinux,splunk


unfortunately, the linux splunk binary running as 1000:1000 can’t read files from /compat/devuan01/var/hostlog (nullfs mount of /var/log).
The FreeBSD splunk binary, running on host as splunk:splunk, can read those files.


Forget about that, the group trick solved my problem, I was just looking at the wrong place!
 
Back
Top