Hi, Am Mittwoch, 19. März 2025, 15:35:58 Mitteleuropäische Normalzeit schrieb William Roberts: > On Wed, Mar 19, 2025 at 8:25 AM Stephen Smalley > <stephen.smalley.work@xxxxxxxxx> wrote: > > > > On Wed, Mar 19, 2025 at 9:16 AM Stephen Smalley > > <stephen.smalley.work@xxxxxxxxx> wrote: > > > > > > On Tue, Mar 18, 2025 at 9:11 AM Petr Lautrbach <lautrbach@xxxxxxxxxx> wrote: > > > > > > > > Stephen Smalley <stephen.smalley.work@xxxxxxxxx> writes: > > > > > > > > > On Mon, Mar 17, 2025 at 1:32 PM Petr Lautrbach <lautrbach@xxxxxxxxxx> wrote: > > > > >> > > > > >> Cathy Hu <cahu@xxxxxxx> writes: > > > > >> > > > > >> > On 17.03.25 15:29, Petr Lautrbach wrote: > > > > >> >> > > > > >> >> You could use `-e <directory>` to exclude read only subdirectories. > > > > >> >> > > > > >> > > > > > >> > Yes that is possible, but also requires a manual change by the user to set > > > > >> > this up together with the snapshot (same as telling them to add <<none>>), > > > > >> > which we would like to avoid. > > > > >> > > > > >> Your -relabel.service's are generated and so can be restorecon options > > > > >> there. > > > > >> > > > > >> Fedora uses fixfiles - > > > > >> https://github.com/SELinuxProject/selinux/blob/main/policycoreutils/scripts/fixfiles > > > > >> - which detects ro filesystems and skip them. > > > > > > > > > > We already have logic in libselinux/src/selinux_restorecon.c to > > > > > exclude filesystems that lack seclabel support; should we augment this > > > > > to also exclude read-only filesystems to avoid the need to work around > > > > > this in all callers? > > > > > > > > > https://github.com/SELinuxProject/selinux/blob/main/libselinux/src/selinux_restorecon.c#L238 > > > > > > > > You're right, I didn't know about that. > > > > > > > > I think it would make sense to exclude also `ro` mount points. Note that btrfs subvolumes don't necessarily show up as separate mount points: Essentially any directory could be a subvolume. That makes it rather annoying to gather a complete list for -e before calling restorecon (would need full FS traversal). To detect ro subols in restorecon, changes of st_dev need to be detected. Quoting my comment from bugzilla: > (Some notes for d): This could be implemented in restorecon by adding to the > if (ftsent->fts_statp->st_dev != state->dev_num) check. The > BTRFS_IOC_SUBVOL_GETFLAGS ioctl can be called on that FD and the result > checked against BTRFS_SUBVOL_RDONLY. That is not too complex or expensive and > does not need additional dependencies on e.g. libbtrfs.) That leaves the question of what to do with that info. At first maybe just set a flag that it's within a read-only subvol and soften error handling, i.e. this: > > > I think the tricky part is the case where the caller deliberately > > > passed those mount points to restorecon/setfiles. The current > > > exclusion logic IIRC won't exclude any explicitly passed directories > > > to avoid silently failing. But skipping read-only mounts on a > > > traversal of a subdirectory would make sense IMHO. > > > > Actually, maybe not. Scenario: Read-only mount on a higher level > > directory with read-write mount of a lower level directory (e.g. > > read-only / with a writable /var), and restorecon or setfiles invoked > > on /. > > Maybe it is best to just defer this to the callers. > > You beat me to this, I had a draft sitting in my inbox. My suggestion > was to report that it occured, but not > fail and keep going if the return code is for read only failure. Cheers, Fabian > > > > >> > Is there a reason why these r-o subvolumes are not skipped by default? > > > > >> > Could they be skipped without a problem and it is just missing the implementation? > > > > >> > > > > > >> > Thanks :) > > > > >> > > > > > >> > Kind regards, > > > > >> > Cathy > > > > >> > > > > > > > >
