On Wednesday, 27 January 2021 5:03:06 PM AEDT Dominick Grift wrote: > >> > @@ -1264,6 +1299,8 @@ allow systemd_tmpfiles_t systemd_journal > >> > > >> > allow systemd_tmpfiles_t systemd_tmpfiles_conf_t:dir list_dir_perms; > >> > allow systemd_tmpfiles_t systemd_tmpfiles_conf_type:file > >> > read_file_perms; > >> > > >> > +allow systemd_tmpfiles_t systemd_nspawn_runtime_t:fifo_file unlink; > >> > >> questionable > > > > Why? > > Not sure yet. other than that is looks incomplete and that i am > wondering why one would be bothering with this. > > Can you tell me a bit more about this event? It's just a fifo that systemd-nspawn left lying around and tmpfiles cleaned up. My way of not bothering is to just allow it. It doesn't seem to do any harm. > >> unconfined should be unconfined. > > > > certbot needs execmem, we generally don't want to give that to unconfined, > > so running certbot in a different domain seems better. > > Those day's are long gone. Nowaday's even `grep` does execmem. grep asks for execmem but seems to work fine without it. certbot won't function without it. > >> But in my personal view unconfined_t shouldnt run lvm with a domain > >> transition in the first place (defeats the purpose of the unconfined > >> domain)> > > I think the problem is the type transition rules. Run lvm etc as > > unconfined_t and then lvm run from init etc won't be able to access it's > > temporary files etc. > > why would lvm run for init have any busyness with temporary files? Seems > unlikely to me and nowaday's we have a lot more flexibility with > type-trans rules. But yes, its a bit late in the game now to change > this. It breaks the model though IMHO. type_transition lvm_t device_t:blk_file fixed_disk_device_t; type_transition lvm_t etc_t:file lvm_metadata_t; Here's a couple of the type_transition rules in the current policy that indicate problems if you removed the transition to lvm_t. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
