Correct, map is a separate permission.

Hello Zdenek,

Do you know when we could expect this change to be released? An approximative date would help us for planning.

Thank you in advance!

The build already exists since 2 weeks ago, but got stuck somewhere in the testing process.
I'll take a look.

The build should be available since today morning, sorry for the delay.

I tested update FEDORA-2024-323decc1d9[1], which added the "map" permission indeed, but it also removed the "lock" one:

  # sesearch --allow --source krb5kdc_t --target krb5kdc_principal_t
  allow domain file_type:blk_file map; [ domain_can_mmap_files ]:True
  allow domain file_type:chr_file map; [ domain_can_mmap_files ]:True
  allow domain file_type:file map; [ domain_can_mmap_files ]:True
  allow domain file_type:lnk_file map; [ domain_can_mmap_files ]:True
  allow krb5kdc_t file_type:filesystem getattr;
  allow krb5kdc_t krb5kdc_principal_t:file { getattr ioctl map open read write };

The list changed from { append getattr ioctl lock open read write } to { getattr ioctl map open read write }. Would it be possible to keep all the permissions from the initial list, and add the "map" one?


[1] https://bodhi.fedoraproject.org/updates/FEDORA-2024-323decc1d9

The missing "lock" permission aside, I noticed there are other cases where daemons create files with invalid context, and some other permissions seem to be missing. I will create another bugzilla for these issues.

(In reply to Julien Rische from comment #5)
> I tested update FEDORA-2024-323decc1d9[1], which added the "map" permission
> indeed, but it also removed the "lock" one:
> 
>   # sesearch --allow --source krb5kdc_t --target krb5kdc_principal_t
>   allow domain file_type:blk_file map; [ domain_can_mmap_files ]:True
>   allow domain file_type:chr_file map; [ domain_can_mmap_files ]:True
>   allow domain file_type:file map; [ domain_can_mmap_files ]:True
>   allow domain file_type:lnk_file map; [ domain_can_mmap_files ]:True
>   allow krb5kdc_t file_type:filesystem getattr;
>   allow krb5kdc_t krb5kdc_principal_t:file { getattr ioctl map open read
> write };
> 
> The list changed from { append getattr ioctl lock open read write } to {
> getattr ioctl map open read write }. Would it be possible to keep all the
> permissions from the initial list, and add the "map" one?
Certainly. There seems to be a general problem in policy macros, I replaced
rw_file_perms with mmap_rw_file_perms, not noticing that the latter has unexpectedly different content:

172 define(`rw_inherited_file_perms',`{ getattr read write append ioctl lock }')
173 define(`rw_file_perms',`{ open rw_inherited_file_perms }')
174 define(`mmap_rw_inherited_file_perms',`{ getattr map read write ioctl }')
175 define(`mmap_rw_file_perms',`{ getattr open map read write ioctl }')

Thanks for spotting this. On the other hand, note it is easy to miss an update to a bz which is in late stage (say POST and later), so it's better to create a new bz.

Just mentioning I gave -1 karma to the FEDORA-2024-323decc1d9[1] update because I tested it with the current MIT krb5 version (which is using Berkeley DB), and it is breaking it too:

  # ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR | grep -E '(krb5kdc_t|kadmind_t)'
  type=AVC msg=audit(1710509353.206:154): avc:  denied  { lock } for  pid=857 comm="krb5kdc" path="/var/kerberos/krb5kdc/principal.kadm5.lock" dev="vda2" ino=262657 scontext=system_u:system_r:krb5kdc_t:s0 tcontext=unconfined_u:object_r:krb5kdc_principal_t:s0 tclass=file permissive=0

The "lock" permission is required for this DB backend too.

[1] https://bodhi.fedoraproject.org/updates/FEDORA-2024-323decc1d9