Solved Default extended ACLs not working.

DomXY

DomXY

I got
/dev/zvol/data/sftpshare/data on /usr/local/jails/containers/<censored>/var/db/sftpshare/data (ufs, local, soft-updates, journaled soft-updates, acls)

But when I do
/usr/local/jails/containers/<censored>/var/db/sftpshare/data]# ls -la ; setfacl -d -m g:users:rwx tmp/ I just get
total 1048945
drwxrwxr-x+ 4 root users 1024 Aug 8 16:57 ./
drwxr-xr-x 4 root wheel 4 Aug 4 08:53 ../
drwxr-xr-x 2 root operator 512 Aug 8 16:26 .snap/
-r-------- 1 root wheel 536870912 Aug 8 16:26 .sujournal
drwxrwxr-x+ 7 locmain users 512 Jul 30 18:17 tmp/
setfacl: tmp/: acl_calc_mask() failed: Invalid argument
setfacl: tmp/: failed to set ACL mask


While I can set extended ACLs, when I add the -d to setfacl, it complains about the mask.
What do I need to do, to set default extended ACLs?

Background: It's a ZFS-Root, and I use a zvol with UFS to get POSIX ACLs, to make accessing Linux able to understand permissions correctly and reduce backup impact, when I move much data to the share (sftp), but this might be a different topic.
 
from the manpage

It is possible for files and directories to inherit ACL entries from
their parent directory. This is accomplished through the use of the
default ACL. It should be noted that before you can specify a default
ACL, the mandatory ACL entries for user, group, other and mask must be
set. For more details see the examples below. Default ACLs can be
created by using -d.

setfacl -d -m u::rwx,g::rx,o::rx,mask::rwx dir
setfacl -d -m g:admins:rwx dir

The first command sets the mandatory elements of the POSIX.1e default
ACL. The second command specifies that users in group admins can have
read, write, and execute permissions for directory named "dir". It
should be noted that any files or directories created underneath "dir"
will inherit these default ACLs upon creation
 
Okay. This did solve the issue, but my aim is not reached. The defaults are not handed through properly. Even having set mask::rwx for mandatory and default ACLs the inheriting elements only get a rx (dir) or r (f) mask, which then interferes and removes my (wanted) write access for the additional group.
I already changed the user's class to one similar to default, but changed umask to 002 - problem persists.

And I figured out, setting in login.conf a umask 002, it doesn't change the output of the umask command of the user at all. (This settings seems not to do what I expected.)

According to the example of covacat:

setfacl -d -m g:admins:rwx dir

leads to read only access for admins, inheriting a mask of mask::rx and # effective: rx.

Any ideas? (Got a bit desperate now.)
 
In regular use, the share will be accessed by sftp or sshfs - where do I set the umask in this cases?
 
Yes, I did. But after sudo -i -u <user> I still got umask replying 0022. Similar behaviour (according to the shown umask) for file creation through sftp.

Here some shell:
root@host:/var/db/sftpshare/data # setfacl -d -m u::rwx,g::rwx,o::,m::rwx .
root@host:/var/db/sftpshare/data # setfacl -d -m g:users:rwx .
root@host:/var/db/sftpshare/data # setfacl -m u::rwx,g::rwx,o::,m::rwx .
root@host:/var/db/sftpshare/data # setfacl -m g:users:rwx .
root@host:/var/db/sftpshare/data # getfacl . ; getfacl -d .
# file: .
# owner: root
# group: users
user::rwx
group::rwx
group:users:rwx
mask::rwx
other::---
# file: .
# owner: root
# group: users
user::rwx
group::rwx
group:users:rwx
mask::rwx
other::---
root@host:/ # sudo -i -u dummy
dummy@host:~ $ cd /var/db/sftpshare/data/
dummy@host:/var/db/sftpshare/data $ umask
0022
dummy@host:/var/db/sftpshare/data $ mkdir foo ; touch bar
dummy@host:/var/db/sftpshare/data $ ls -la
total 1048969
drwxrwx---+ 5 root users 1024 Aug 9 11:28 .
drwxr-xr-x 4 root wheel 4 Aug 4 08:53 ..
drwxr-xr-x 2 root operator 512 Aug 8 16:26 .snap
-r-------- 1 root wheel 536870912 Aug 8 16:26 .sujournal
-rw-r-----+ 1 dummy users 0 Aug 9 11:28 bar
drwxr-x---+ 2 dummy users 512 Aug 9 11:28 foo
drwxr-xr-x 7 dummy users 512 Jul 30 18:17 tmp
dummy@host:/var/db/sftpshare/data $ getfacl foo bar ; getfacl -d foo bar
# file: foo
# owner: dummy
# group: users
user::rwx
group::rwx # effective: r-x
group:users:rwx # effective: r-x
mask::r-x
other::---

# file: bar
# owner: dummy
# group: users
user::rw-
group::rwx # effective: r--
group:users:rwx # effective: r--
mask::r--
other::---
# file: foo
# owner: dummy
# group: users
user::rwx
group::rwx
group:users:rwx
mask::rwx
other::---

# file: bar
# owner: dummy
# group: users
getfacl: bar: Invalid argument
dummy@host:/var/db/sftpshare/data $ id
uid=1001(dummy) gid=1001(users) groups=1001(users),1003(enrolee)
root@host:~ # tail /etc/login.conf
## If you want some of the accounts to use traditional UNIX DES based
## password hashes.
##
#des_users:\
# :passwd_format=des:\
# :tc=default:

sftpusers:\
:tc=default:\
:umask=002:
 
Yes, I did cap_mkdb.

However, I did a bit more testing on a VM... The VM is on UFS only - and shows the same behaviour.
While the umask is not inherited on sudo -i -u <username> (which should be done by -i), this can be solved, if I set all users to umask 002.

However, what me still concerns is the - IMHO wrong - behaviour of the extended ACLs:

I set a directory with
setfacl -m g:users:rwx .
setfacl -d -m u::rwx,g::rwx,o::rx .
setfacl -d -m g:users:rwx .


Giving us:
getfacl . ; getfacl -d .
# file: .
# owner: root
# group: wheel
user::rwx
group::r-x
group:users:rwx
mask::rwx
other::r-x
# file: .
# owner: root
# group: wheel
user::rwx
group::rwx
group:users:rwx
mask::rwx
other::r-x

(Please note the group and mask settings.)

But the set mask is not honored. Instead of using the default ACL's mask and group (which should result in a g:users:rwx) the umask only is respected. All in all: this is not a problem of my setup, but the defaults of the ACLs are not respected as I'd expect it. I think, this is not behaving as designed. Is there anything I miss, or what for is the default ACL mask there anyway? (If not honoured at all.)
 
I found the solution. This works from sftp perspective, which is the main use of the folder, so this should be enough for the most of the situations.

The ForceCommand option within the /etc/sshd_config must be set to internal-sftp [B]-u 0[/B], where [U][B]-u[/B][/U] specifies the umask setting for anything new. For my mentioned scenario 2 or 002 would do what I want already, but using 0 or 000 let all be decided by setfacl's defaults.
 
You must log in or register to reply here.
Back
Top