Yes, you need to run restorecon where the filesystem is mounted, as the
SELinux context is understood locally.
On Thu, May 27, 2021 at 5:47 PM Luke Sudbery <L.R.Sudbery(a)bham.ac.uk> wrote:
Great - thank you. We had set fcontext equivalence:
[root@host-name ~]# semanage fcontext -C -l
SELinux Local fcontext Equivalence
/var/adm/ras = /var/log
/gpfs-fs/homes/a = /home
/gpfs-fs/homes/b = /home
/gpfs-fs/homes/c = /home
/gpfs-fs/homes/d = /home
/gpfs-fs/homes/e = /home
/gpfs-fs/homes/f = /home
/gpfs-fs/homes/g = /home
/gpfs-fs/homes/h = /home
/gpfs-fs/homes/i = /home
/gpfs-fs/homes/j = /home
/gpfs-fs/homes/k = /home
/gpfs-fs/homes/l = /home
/gpfs-fs/homes/m = /home
/gpfs-fs/homes/n = /home
/gpfs-fs/homes/o = /home
/gpfs-fs/homes/p = /home
/gpfs-fs/homes/q = /home
/gpfs-fs/homes/r = /home
/gpfs-fs/homes/s = /home
/gpfs-fs/homes/t = /home
/gpfs-fs/homes/u = /home
/gpfs-fs/homes/v = /home
/gpfs-fs/homes/w = /home
/gpfs-fs/homes/x = /home
/gpfs-fs/homes/y = /home
/gpfs-fs/homes/z = /home
[root@host-name ~]#
And run restorecon on one of the home directories itself, but not on the
paths above it. Doing this seems to have fixed the problem without the need
for an additional module. In fact it appears to have been the mount point
of the file system that was the problem, so restorecon needs running on
every machine.
Great. But I’m a still bit confused about the need to add home_root_t to
the new home dir roots and to have the equivalency rule – don’t they
achieve the same thing?
Many thanks,
Luke
--
Luke Sudbery
Architecture, Infrastructure and Systems
Advanced Research Computing, IT Services
Room 132, Computer Centre G5, Elms Road
*Please note I don’t work on Monday.*
*From:* d.sastre.medina(a)gmail.com <d.sastre.medina(a)gmail.com>
*Sent:* 27 May 2021 14:19
*To:* Luke Sudbery (Advanced Research Computing) <L.R.Sudbery(a)bham.ac.uk>
*Cc:* selinux(a)lists.fedoraproject.org
*Subject:* Re: Postfix with home dirs on GPFS
Hello Luke,
If you are relocating home directories somewhere else (not /home), you
need to make sure those new home directories are properly labeled. As you
can see in the AVC denials, those directories/files are unlabeled_t.
The semanage-fcontext(8) manual page contains an example:
# semanage fcontext -a -t home_root_t "/disk6"
# semanage fcontext -a -e /home /disk6/home
# restorecon -R -v /disk6
Obviously, you need to replace the paths in the example with the ones on
your use case.
Hope that helps.
On Thu, May 27, 2021 at 1:16 PM Luke Sudbery <L.R.Sudbery(a)bham.ac.uk>
wrote:
Hello,
With home directories on IBM Spectrum Scale and selinux enabled, postfix
is unable to deliver locally. This is using RHELS8.3.
Postfix logs:
May 27 10:23:20 host-name postfix/local[1245962]: A1219F9E: to=<
username(a)host-name.localdomain>, orig_to=<username>, relay=local,
delay=0.03, delays=0.01/0.01/0/0.01, dsn=5.2.0, status=bounced (cannot
update mailbox /gpfs-fs/homes/u/username/Mailbox for user username. unable
to create lock file /gpfs-fs/homes/u/username/Mailbox.lock: Permission
denied)
Although the actual problem is that it can’t/doesn’t read ~/.forward to
know where to really send the mail.
Selinux audit logs show:
type=AVC msg=audit(1622111726.610:10854499): avc: denied { search } for
pid=1315267 comm="local" name="/" dev="gpfs" ino=3
scontext=system_u:system_r:postfix_local_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=0
type=SYSCALL msg=audit(1622111726.610:10854499): arch=c000003e syscall=6
success=no exit=-13 a0=561f9a316390 a1=7ffdc7e109c0 a2=7ffdc7e109c0 a3=0
items=0 ppid=3375 pid=1315267 auid=4294967295 uid=0 gid=0 euid=606178
suid=0 fsuid=606178 egid=100 sgid=0 fsgid=100 tty=(none) ses=4294967295
comm="local" exe="/usr/libexec/postfix/local"
subj=system_u:system_r:postfix_local_t:s0 key=(null)ARCH=x86_64
SYSCALL=lstat AUID="unset" UID="root" GID="root"
EUID="username"
SUID="root" FSUID="username" EGID="users"
SGID="root" FSGID="users"
type=AVC msg=audit(1622111726.611:10854500): avc: denied { search } for
pid=1315267 comm="local" name="/" dev="gpfs" ino=3
scontext=system_u:system_r:postfix_local_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=0
type=SYSCALL msg=audit(1622111726.611:10854500): arch=c000003e syscall=4
success=no exit=-13 a0=561f9a3165c0 a1=7ffdc7e109c0 a2=7ffdc7e109c0 a3=0
items=0 ppid=3375 pid=1315267 auid=4294967295 uid=0 gid=0 euid=606178
suid=0 fsuid=606178 egid=100 sgid=0 fsgid=100 tty=(none) ses=4294967295
comm="local" exe="/usr/libexec/postfix/local"
subj=system_u:system_r:postfix_local_t:s0 key=(null)ARCH=x86_64
SYSCALL=stat AUID="unset" UID="root" GID="root"
EUID="username" SUID="root"
FSUID="username" EGID="users" SGID="root"
FSGID="users"
type=AVC msg=audit(1622111726.611:10854501): avc: denied { search } for
pid=1315267 comm="local" name="/" dev="gpfs" ino=3
scontext=system_u:system_r:postfix_local_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=0
type=SYSCALL msg=audit(1622111726.611:10854501): arch=c000003e syscall=257
success=no exit=-13 a0=ffffff9c a1=561f9a316600 a2=c1 a3=0 items=0
ppid=3375 pid=1315267 auid=4294967295 uid=0 gid=0 euid=606178 suid=0
fsuid=606178 egid=100 sgid=0 fsgid=100 tty=(none) ses=4294967295
comm="local" exe="/usr/libexec/postfix/local"
subj=system_u:system_r:postfix_local_t:s0 key=(null)ARCH=x86_64
SYSCALL=openat AUID="unset" UID="root" GID="root"
EUID="username"
SUID="root" FSUID="username" EGID="users"
SGID="root" FSGID="users"
audit2allow shows:
[root@host-name audit]# audit2allow -w -a
type=AVC msg=audit(1622111726.610:10854499): avc: denied { search } for
pid=1315267 comm="local" name="/" dev="gpfs" ino=3
scontext=system_u:system_r:postfix_local_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=0
Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to
allow this access.
type=AVC msg=audit(1622111726.611:10854500): avc: denied { search } for
pid=1315267 comm="local" name="/" dev="gpfs" ino=3
scontext=system_u:system_r:postfix_local_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=0
Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to
allow this access.
type=AVC msg=audit(1622111726.611:10854501): avc: denied { search } for
pid=1315267 comm="local" name="/" dev="gpfs" ino=3
scontext=system_u:system_r:postfix_local_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=0
Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to
allow this access.
[root@host-name audit]# audit2allow -a
#============= postfix_local_t ==============
allow postfix_local_t unlabeled_t:dir search;
[root@host-name audit]#
Creating a module using these rules fixes the problem.
I’ve also tested creating a user with a home directory with GPFS stopped,
and using the same path that a GPFS user would have. This worked without
any selinux changes, and implies this is a problem with home dirs on GPFS,
rather than just the path itself.
Should this be reported as a selinux bug?
Many thanks,
Luke
--
Luke Sudbery
Architecture, Infrastructure and Systems
Advanced Research Computing, IT Services
Room 132, Computer Centre G5, Elms Road
*Please note I don’t work on Monday.*
_______________________________________________
selinux mailing list -- selinux(a)lists.fedoraproject.org
To unsubscribe send an email to selinux-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure