On Thu, Nov 5, 2020 at 7:44 AM Ondrej Mosnacek <omosnace@xxxxxxxxxx> wrote: > > Hello everyone, > > while trying to fix the NFS rootcontext= issue, I realized that this > funny thing is possible: > > # mount -o rootcontext=system_u:object_r:lib_t:s0 -t tmpfs tmpfs /mnt > # ls -lZd /mnt > drwxrwxrwt. 2 root root system_u:object_r:lib_t:s0 40 nov 5 07:30 /mnt > # mount > [...] > tmpfs on /mnt type tmpfs > (rw,relatime,rootcontext=system_u:object_r:lib_t:s0,seclabel) > # chcon -t bin_t /mnt > # ls -lZd /mnt > drwxrwxrwt. 2 root root system_u:object_r:bin_t:s0 40 nov 5 07:30 /mnt > # mount > [...] > tmpfs on /mnt type tmpfs > (rw,relatime,rootcontext=system_u:object_r:bin_t:s0,seclabel) > > I.e. if you mount a tree with rootcontext=<oldctx> and then relabel > the root node to <newctx>, the displayed mount options will report > rootcontext=<newctx> instead of rootcontext=<oldctx>. A side effect is > that if you try to mount the same superblock again, it will only > permit you to mount with rootcontext=<newctx>, not with > rootcontext=<oldctx>. > > Is that intended, bad, or "weird, but doesn't matter" behavior? I'd say it is bad. > I have a halfway written patch to disallow altering the root node's > context when mounted with rootcontext=, but I'm not sure if that's the > right thing to do or not. Probably the better fix would be to save the original rootcontext SID as a new field of the superblock security struct and use that both when displaying the mount options and when comparing old and new mount options instead of what happens to be assigned to the root inode at the time.
