* Possibly unwanted rootcontext= behavior? @ 2020-11-05 12:44 Ondrej Mosnacek 2020-11-05 13:51 ` Stephen Smalley 0 siblings, 1 reply; 7+ messages in thread From: Ondrej Mosnacek @ 2020-11-05 12:44 UTC (permalink / raw) To: SElinux list; +Cc: Stephen Smalley, Paul Moore 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 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. Thanks, -- Ondrej Mosnacek Software Engineer, Platform Security - SELinux kernel Red Hat, Inc. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Possibly unwanted rootcontext= behavior? 2020-11-05 12:44 Possibly unwanted rootcontext= behavior? Ondrej Mosnacek @ 2020-11-05 13:51 ` Stephen Smalley 2020-11-05 15:31 ` Paul Moore 0 siblings, 1 reply; 7+ messages in thread From: Stephen Smalley @ 2020-11-05 13:51 UTC (permalink / raw) To: Ondrej Mosnacek; +Cc: SElinux list, Paul Moore On Thu, Nov 5, 2020 at 7:44 AM Ondrej Mosnacek <omosnace@redhat.com> 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Possibly unwanted rootcontext= behavior? 2020-11-05 13:51 ` Stephen Smalley @ 2020-11-05 15:31 ` Paul Moore 2020-11-05 17:22 ` Ondrej Mosnacek 0 siblings, 1 reply; 7+ messages in thread From: Paul Moore @ 2020-11-05 15:31 UTC (permalink / raw) To: Stephen Smalley; +Cc: Ondrej Mosnacek, SElinux list On Thu, Nov 5, 2020 at 8:51 AM Stephen Smalley <stephen.smalley.work@gmail.com> wrote: > On Thu, Nov 5, 2020 at 7:44 AM Ondrej Mosnacek <omosnace@redhat.com> 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. I worry that would be confusing, allowing the root inode to be relabeled yet still showing the old label in the mount options. It would seem that simply blocking a root inode relabel when a rootcontext is specified would be the cleanest choice, assuming existing systems do not rely on this behavior. Ondrej, Stephen, any idea how common this is on normal systems? My gut feeling says "not very common", but that is just a guess. -- paul moore www.paul-moore.com ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Possibly unwanted rootcontext= behavior? 2020-11-05 15:31 ` Paul Moore @ 2020-11-05 17:22 ` Ondrej Mosnacek 2020-11-05 17:28 ` Stephen Smalley 0 siblings, 1 reply; 7+ messages in thread From: Ondrej Mosnacek @ 2020-11-05 17:22 UTC (permalink / raw) To: Paul Moore; +Cc: Stephen Smalley, SElinux list On Thu, Nov 5, 2020 at 4:31 PM Paul Moore <paul@paul-moore.com> wrote: > On Thu, Nov 5, 2020 at 8:51 AM Stephen Smalley > <stephen.smalley.work@gmail.com> wrote: > > On Thu, Nov 5, 2020 at 7:44 AM Ondrej Mosnacek <omosnace@redhat.com> 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. > > I worry that would be confusing, allowing the root inode to be > relabeled yet still showing the old label in the mount options. It > would seem that simply blocking a root inode relabel when a > rootcontext is specified would be the cleanest choice, assuming > existing systems do not rely on this behavior. > > Ondrej, Stephen, any idea how common this is on normal systems? My > gut feeling says "not very common", but that is just a guess. I don't even know what use case it's supposed to solve :) I suppose if you freshly format some storage drive and you want the root dir to be labeled immediately after mounting, rootcontext= could be useful. For such a use case Stephen's approach would make sense (you might still want to eventually relabel the root dir to something else), but there are some gotchas... For example, the label is initially set only in the inode security struct, but not written to the xattrs (I only looked at the code briefly, I could be wrong here), so you would still need to manually set the label on the root directory after mounting for the label to persist. And if you remount the superblock after changing the label, the internal label will be reset to the old one (which you are forced to specify in the mount options), but again not persistently. That's all very unintuitive. So, IMHO, good ways to fix it are either disallowing changing the label altogether, or making sure the label is propagated to the xattrs (if supported) and allowing to remount with a different rootcontext= option (or with no rootcontext). But that's only if I guessed the use case correctly. -- Ondrej Mosnacek Software Engineer, Platform Security - SELinux kernel Red Hat, Inc. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Possibly unwanted rootcontext= behavior? 2020-11-05 17:22 ` Ondrej Mosnacek @ 2020-11-05 17:28 ` Stephen Smalley 2020-11-05 17:36 ` Stephen Smalley 2020-11-06 4:12 ` Paul Moore 0 siblings, 2 replies; 7+ messages in thread From: Stephen Smalley @ 2020-11-05 17:28 UTC (permalink / raw) To: Ondrej Mosnacek; +Cc: Paul Moore, SElinux list On Thu, Nov 5, 2020 at 12:22 PM Ondrej Mosnacek <omosnace@redhat.com> wrote: > > On Thu, Nov 5, 2020 at 4:31 PM Paul Moore <paul@paul-moore.com> wrote: > > On Thu, Nov 5, 2020 at 8:51 AM Stephen Smalley > > <stephen.smalley.work@gmail.com> wrote: > > > On Thu, Nov 5, 2020 at 7:44 AM Ondrej Mosnacek <omosnace@redhat.com> 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. > > > > I worry that would be confusing, allowing the root inode to be > > relabeled yet still showing the old label in the mount options. It > > would seem that simply blocking a root inode relabel when a > > rootcontext is specified would be the cleanest choice, assuming > > existing systems do not rely on this behavior. > > > > Ondrej, Stephen, any idea how common this is on normal systems? My > > gut feeling says "not very common", but that is just a guess. > > I don't even know what use case it's supposed to solve :) I suppose if > you freshly format some storage drive and you want the root dir to be > labeled immediately after mounting, rootcontext= could be useful. For > such a use case Stephen's approach would make sense (you might still > want to eventually relabel the root dir to something else), but there > are some gotchas... For example, the label is initially set only in > the inode security struct, but not written to the xattrs (I only > looked at the code briefly, I could be wrong here), so you would still > need to manually set the label on the root directory after mounting > for the label to persist. And if you remount the superblock after > changing the label, the internal label will be reset to the old one > (which you are forced to specify in the mount options), but again not > persistently. That's all very unintuitive. > > So, IMHO, good ways to fix it are either disallowing changing the > label altogether, or making sure the label is propagated to the xattrs > (if supported) and allowing to remount with a different rootcontext= > option (or with no rootcontext). But that's only if I guessed the use > case correctly. I think the original use case was primarily tmpfs mounts, so that e.g. one could mount a tmpfs on /dev that is immediately labeled with device_t. Not fundamentally opposed to preventing relabeling afterward but always possible that could break existing userspace somewhere. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Possibly unwanted rootcontext= behavior? 2020-11-05 17:28 ` Stephen Smalley @ 2020-11-05 17:36 ` Stephen Smalley 2020-11-06 4:12 ` Paul Moore 1 sibling, 0 replies; 7+ messages in thread From: Stephen Smalley @ 2020-11-05 17:36 UTC (permalink / raw) To: Ondrej Mosnacek; +Cc: Paul Moore, SElinux list On Thu, Nov 5, 2020 at 12:28 PM Stephen Smalley <stephen.smalley.work@gmail.com> wrote: > > On Thu, Nov 5, 2020 at 12:22 PM Ondrej Mosnacek <omosnace@redhat.com> wrote: > > > > On Thu, Nov 5, 2020 at 4:31 PM Paul Moore <paul@paul-moore.com> wrote: > > > On Thu, Nov 5, 2020 at 8:51 AM Stephen Smalley > > > <stephen.smalley.work@gmail.com> wrote: > > > > On Thu, Nov 5, 2020 at 7:44 AM Ondrej Mosnacek <omosnace@redhat.com> 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. > > > > > > I worry that would be confusing, allowing the root inode to be > > > relabeled yet still showing the old label in the mount options. It > > > would seem that simply blocking a root inode relabel when a > > > rootcontext is specified would be the cleanest choice, assuming > > > existing systems do not rely on this behavior. > > > > > > Ondrej, Stephen, any idea how common this is on normal systems? My > > > gut feeling says "not very common", but that is just a guess. > > > > I don't even know what use case it's supposed to solve :) I suppose if > > you freshly format some storage drive and you want the root dir to be > > labeled immediately after mounting, rootcontext= could be useful. For > > such a use case Stephen's approach would make sense (you might still > > want to eventually relabel the root dir to something else), but there > > are some gotchas... For example, the label is initially set only in > > the inode security struct, but not written to the xattrs (I only > > looked at the code briefly, I could be wrong here), so you would still > > need to manually set the label on the root directory after mounting > > for the label to persist. And if you remount the superblock after > > changing the label, the internal label will be reset to the old one > > (which you are forced to specify in the mount options), but again not > > persistently. That's all very unintuitive. > > > > So, IMHO, good ways to fix it are either disallowing changing the > > label altogether, or making sure the label is propagated to the xattrs > > (if supported) and allowing to remount with a different rootcontext= > > option (or with no rootcontext). But that's only if I guessed the use > > case correctly. > > I think the original use case was primarily tmpfs mounts, so that e.g. > one could mount a tmpfs on /dev that is immediately labeled with > device_t. > > Not fundamentally opposed to preventing relabeling afterward but > always possible that could break existing userspace somewhere. commit 0808925ea5684a0ce25483b30e94d4f398804978 Author: Eric Paris <eparis@parisplace.org> Date: Mon Jul 10 04:43:55 2006 -0700 [PATCH] SELinux: add rootcontext= option to label root inode when mounting Introduce a new rootcontext= option to FS mounting. This option will allow you to explicitly label the root inode of an FS being mounted before that FS or inode because visible to userspace. This was found to be useful for things like stateless linux, see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190001 Signed-off-by: Eric Paris <eparis@parisplace.org> Acked-by: Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by: James Morris <jmorris@namei.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Possibly unwanted rootcontext= behavior? 2020-11-05 17:28 ` Stephen Smalley 2020-11-05 17:36 ` Stephen Smalley @ 2020-11-06 4:12 ` Paul Moore 1 sibling, 0 replies; 7+ messages in thread From: Paul Moore @ 2020-11-06 4:12 UTC (permalink / raw) To: Stephen Smalley; +Cc: Ondrej Mosnacek, SElinux list On Thu, Nov 5, 2020 at 12:28 PM Stephen Smalley <stephen.smalley.work@gmail.com> wrote: > On Thu, Nov 5, 2020 at 12:22 PM Ondrej Mosnacek <omosnace@redhat.com> wrote: > > On Thu, Nov 5, 2020 at 4:31 PM Paul Moore <paul@paul-moore.com> wrote: > > > On Thu, Nov 5, 2020 at 8:51 AM Stephen Smalley > > > <stephen.smalley.work@gmail.com> wrote: > > > > On Thu, Nov 5, 2020 at 7:44 AM Ondrej Mosnacek <omosnace@redhat.com> 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. > > > > > > I worry that would be confusing, allowing the root inode to be > > > relabeled yet still showing the old label in the mount options. It > > > would seem that simply blocking a root inode relabel when a > > > rootcontext is specified would be the cleanest choice, assuming > > > existing systems do not rely on this behavior. > > > > > > Ondrej, Stephen, any idea how common this is on normal systems? My > > > gut feeling says "not very common", but that is just a guess. > > > > I don't even know what use case it's supposed to solve :) I suppose if > > you freshly format some storage drive and you want the root dir to be > > labeled immediately after mounting, rootcontext= could be useful. For > > such a use case Stephen's approach would make sense (you might still > > want to eventually relabel the root dir to something else), but there > > are some gotchas... For example, the label is initially set only in > > the inode security struct, but not written to the xattrs (I only > > looked at the code briefly, I could be wrong here), so you would still > > need to manually set the label on the root directory after mounting > > for the label to persist. And if you remount the superblock after > > changing the label, the internal label will be reset to the old one > > (which you are forced to specify in the mount options), but again not > > persistently. That's all very unintuitive. > > > > So, IMHO, good ways to fix it are either disallowing changing the > > label altogether, or making sure the label is propagated to the xattrs > > (if supported) and allowing to remount with a different rootcontext= > > option (or with no rootcontext). But that's only if I guessed the use > > case correctly. > > I think the original use case was primarily tmpfs mounts, so that e.g. > one could mount a tmpfs on /dev that is immediately labeled with > device_t. > > Not fundamentally opposed to preventing relabeling afterward but > always possible that could break existing userspace somewhere. I'd be curious to see what sort of breakage, if any, we might see if we blocked the relabel when rootcontext is in use. Ondrej, any chance you can finish that patch enough to do some basic testing? -- paul moore www.paul-moore.com ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-11-06 4:13 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-11-05 12:44 Possibly unwanted rootcontext= behavior? Ondrej Mosnacek 2020-11-05 13:51 ` Stephen Smalley 2020-11-05 15:31 ` Paul Moore 2020-11-05 17:22 ` Ondrej Mosnacek 2020-11-05 17:28 ` Stephen Smalley 2020-11-05 17:36 ` Stephen Smalley 2020-11-06 4:12 ` Paul Moore
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.