Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > I generally dislike core kernel code which makes LSM calls conditional > on some kernel state maintained outside the LSM. Sometimes it has to > be done as there is no other good options, but I would like us to try > and avoid it if possible. The commit description mentioned that this > was put here to avoid a SELinux complaint, can you provide an example > of the complain? Does it complain about a double/invalid mount, e.g. > "SELinux: mount invalid. Same superblock, different security ..."? > > I'd like to understand why the sb_set_mnt_opts() call fails when it > comes after the fs_context_init() call. I'm particulary curious to > know if the failure is due to conflicting SELinux state in the > fs_context, or if it is simply an issue of sb_set_mnt_opts() not > properly handling existing values. Perhaps I'm being overly naive, > but I'm hopeful that we can address both of these within the SELinux > code itself. > > In a worst case situation, we could always implement a flag *inside* > the SELinux code, similar to what has been done with 'lsm_set' here. IIRC, the issue is when you make a mount with an explicit context= setting and make another mount from some way down the export tree that doesn't have an explicit setting, e.g.: mount carina:/ /mnt -o context=system_u:object_r:root_t:s0 mount carina:/nfs/scratch /mnt2 and then cause an automount to walk from one to the other: stat /mnt/nfs/scratch/foo For reference, my server has: /nfs/scratch 192.168.6.0/255.255.255.0,90.155.74.16/255.255.255.248 /nfs 192.168.6.0/255.255.255.0,90.155.74.16/255.255.255.248 / 192.168.6.0/255.255.255.0,90.155.74.16/255.255.255.248 and if I look in /proc/fs/nfsfs/volumes, I can see the individual superblocks: NV SERVER PORT DEV FSID FSC v4 c0a80601 801 0:51 0:0 no v4 c0a80601 801 0:56 3:0 no v4 c0a80601 801 0:52 1:0 no v4 c0a80601 801 0:55 3:0 no As you can see, there are two referring to the same 'volume'. Without the "fc->lsm_set=true" bit, you get an error something like: SELinux: mount invalid. Same superblock, different security settings for (dev 0:56, type nfs4) One important question is how should sharing of a mount with unspecified context be handled when we try to unify it with a mount that has an explicit context? David
