Permission denied for user in group (group has directory write permissions)

Question

I'm getting Permission Denied when attempting to create/touch files in a directory with group ownership permissions.

touch /data/www/acoder.txt

[acoder@box]$ touch /data/www/acoder.txt
touch: cannot touch '/data/www/acoder.txt': Permission denied

cat /etc/group

webdev:x:1001:acoder

id shows I am in group webdev:

[acoder@box ~]$ id
uid=1000(acoder) gid=1000(acoder) groups=1000(acoder),10(wheel),1002(webdev) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

ll -lZ /data/

drwxr-xr-x. 3 apache webdev system_u:object_r:httpd_sys_rw_content_t:s0 4096 Mar 20 15:39 www

namei -olm /data/www

[acoder@box ~]$ namei -olm /data/www
f: /data/www
dr-xr-xr-x root   root   /
drwxr-xr-x root   root   data
drwxrwx--- apache webdev www

If acoder is in group webdev, and webdev has group ownership (including write permissions) of the containing directory, what else could be triggering the Permission Denied error?

EDIT

Located a reference to touch with auseach:

time->Tue Mar 21 09:21:15 2023

node=box.example.com type=PROCTITLE msg=audit(1679404875.375:8966252): proctitle=746F756368002F646174612F7777772F6164726961322E747874

node=box.example.com type=PATH msg=audit(1679404875.375:8966252): item=0 name="/data/www/" inode=128 dev=fd:0e mode=040755 ouid=48 ogid=1002 rdev=00:00 obj=system_u:object_r:httpd_sys_rw_content_t:s0 nametype=PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0

node=box.example.com type=CWD msg=audit(1679404875.375:8966252): cwd="/home/acoder"

node=box.example.com type=SYSCALL msg=audit(1679404875.375:8966252): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=7fff2ee2e64b a2=941 a3=1b6 items=1 ppid=602556 pid=602594 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts25 ses=1 comm="touch" exe="/usr/bin/touch" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="access"

Also getting error -1 if the user acoder attempts to upload a file to /data/www/ with sftp

time->Tue Mar 21 09:30:14 2023

node=box.example.com type=PROCTITLE msg=audit(1679405414.563:8966285): proctitle="/usr/libexec/openssh/sftp-server"

node=box.example.com type=PATH msg=audit(1679405414.563:8966285): item=1 name="/data/www/" inode=536875051 dev=fd:0e mode=040770 ouid=48 ogid=1002 rdev=00:00 obj=unconfined_u:object_r:httpd_sys_rw_content_t:s0 nametype=PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0

node=box.example.com type=PATH msg=audit(1679405414.563:8966285): item=0 name="/data/www/acoder.php" inode=626000347 dev=fd:0e mode=0100660 ouid=48 ogid=1002 rdev=00:00 obj=unconfined_u:object_r:httpd_sys_rw_content_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0

node=box.example.com type=CWD msg=audit(1679405414.563:8966285): cwd="/home/acoder"

node=box.example.com type=SYSCALL msg=audit(1679405414.563:8966285): arch=c000003e syscall=257 success=no exit=-1 a0=ffffff9c a1=561c6002f6e0 a2=241 a3=1b6 items=2 ppid=602648 pid=602649 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=3674 comm="sftp-server" exe="/usr/libexec/openssh/sftp-server" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="access"

node=box.example.com type=FANOTIFY msg=audit(1679405414.563:8966285): resp=2

[root@box]#

In both instances I'm seeing where asearch shows context as

subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

but the actual context on the filesystem is

context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

According to RHEL docs,

subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

The subj field records the SELinux context with which the analyzed process was labeled at the time of execution.

I'm confused on what this means exactly. Is SELinux reading the context as different from what I am seeing with ll -lZ?

Both ausearch results reference syscall=257, 257 is openat per ausyscall.

audit2allow isn't suggesting an relevant policy changes:

[root@box]# ausearch -c 'touch' --raw | audit2allow -M my-touch
Nothing to do
[root@box]# 

EDIT 2 (March 24, 2023)

Believe I've narrowed down the problem to fapolicyd. If I stop this service, I can sftp the file. It has to be running however, so I need to learn how to configure it in allowing access to sftp (and probably other processes I haven't unconvered yet)

Any more ideas?

Answer 1

This ended up being an fapolicyd denial.

Not sure if this is considered best practice but I fixed this by

Add new rule:

# fapolicyd-cli --file add /data/www/nbsprod/public_html/ --trust-file nbsprod_pub_html

Update rules with fapolicyd-cli

# fapolicyd-cli --update

Verify that fapolicyd is set to run in enforcing mode (not permissive)

# vi /etc/fapolicyd/fapolicyd.conf

...
permissive = 0
...

Restart fapolicyd

# fapolicyd-cli --update

End user now able to upload scripts to the www directory specified above with fapolicyd running in deny mode.