Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
> Checking the permissions on the mountpoint to allow unmounting is > > - rather inelegant: user can't see those permissions, can only > determine if umount is allowed by trial and error > > - may be a security hole, e.g.: > > sysadmin: > > mkdir -m 777 /mnt/disk > mount /dev/hda2 /mnt/disk > > Of course the user doesn't have the right to delete the contents of > the mount, yet the permissions on the mountpoint would imply that s/he > has permission to umount the disk. It is becoming increasingly apparent, that mount/umount permission based on file permissions is inherently broken: 1) there are user-writable files under /proc/$PID/, which definitely shouldn't be allowed to be overmounted 2) if user mounts an fs read-only, then wants to create a submount of this, it will fail with the current patchset Solving 2) should be trivial: submounting a mount owned by the user should be always allowed regardless of the file permissions. Maybe this could be generaized to say, that a mount can be submounted by an unprivileged user IFF parent mount is owned by said user. This would get rid of some of the complications in the current patchset, namely the functionality of MNT_ALLOWUSERMNT and MNT_USER flags would be merged, and the permission checking would be removed. For example on login, the user could get a private namespace set up some that the home directory is owned by the user, and hence can be freely submounted: clone(CLONE_NEWNS) mount --bind /home/$USER /home/$USER mount --remount -ouser=$USER /home/$USER This is of course more limiting than allowing mounts based on file permissions, but it's also a lot cleaner. Hmm? Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
> > > As I said earlier, I see a case where two mounts that are peers of each > > > other can become un-identical if we dont propagate the "allowusermnt". > > > > > > As a practical example. > > > > > > /tmp and /mnt are peers of each other. > > > /tmp has its "allowusermnt" flag set, which has not been propagated > > > to /mnt. > > > > > > now a normal-user mounts an ext2 file system under /tmp at /tmp/1 > > > > > > unfortunately the mount wont appear under /mnt/1 > > > > Argh, that is not true. That's what I've been trying to explain to > > you all along. > > I now realize you did, but I failed to catch it. sorry :-( It is my fault also. I will add better description to the patch headers. > > The propagation will be done _regardless_ of the flag. The flag is > > only checked for the parent of the _requested_ mount. If it is > > allowed there, the mount, including any propagations are allowed. If > > it's denied, then obviously it's denied everywhere. > > > > > and in case if you allow the mount to appear under /mnt/1, you will > > > break unpriviledge mounts semantics which promises: a normal user will > > > not be able to mount at a location that does not allow user-mounts. > > > > No, it does not promise that. The flag just promises, that the user > > cannot _request_ a mount on the parent mount. > > ok. if the ability for a normal user to mount something *indirectly* > under a mount that has its 'allowusermnt flag' unset, > is acceptable under the definition of 'allowusermnt', i guess my only > choice is to accept it. :-) It is the only "sane" way I think. Maybe the MS_SETFLAGS/MS_CLEARFLAGS mount operation could have an option for propagating the given flag(s). Then it's really up to the sysadmin, to determine in each case what the desired behavior is. Yes, you are right, that most of the time propagating the "allowusermnt" between peers may be the right thing to do. But for example propagating it from master to slave may not be a good thing at all. So it shouldn't be for the kernel to decide. Thanks, Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
On Wed, 2007-04-18 at 21:14 +0200, Miklos Szeredi wrote: > > As I said earlier, I see a case where two mounts that are peers of each > > other can become un-identical if we dont propagate the "allowusermnt". > > > > As a practical example. > > > > /tmp and /mnt are peers of each other. > > /tmp has its "allowusermnt" flag set, which has not been propagated > > to /mnt. > > > > now a normal-user mounts an ext2 file system under /tmp at /tmp/1 > > > > unfortunately the mount wont appear under /mnt/1 > > Argh, that is not true. That's what I've been trying to explain to > you all along. I now realize you did, but I failed to catch it. sorry :-( > > The propagation will be done _regardless_ of the flag. The flag is > only checked for the parent of the _requested_ mount. If it is > allowed there, the mount, including any propagations are allowed. If > it's denied, then obviously it's denied everywhere. > > > and in case if you allow the mount to appear under /mnt/1, you will > > break unpriviledge mounts semantics which promises: a normal user will > > not be able to mount at a location that does not allow user-mounts. > > No, it does not promise that. The flag just promises, that the user > cannot _request_ a mount on the parent mount. ok. if the ability for a normal user to mount something *indirectly* under a mount that has its 'allowusermnt flag' unset, is acceptable under the definition of 'allowusermnt', i guess my only choice is to accept it. :-) RP > > Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
On Wed, 2007-04-18 at 16:01 +0100, Christoph Hellwig wrote: > I suspect the right answer here is to make nfs mount handling smarter. > The way mounting works the filesystem is allowed to choose whether it > can re-used a superblock or needs a new one. In the NFS case we probably > want to allow multiple superblocks for the same export if important > paramaters like the security model mismatch. It might also be another application for layering. If I were able to share enough of the inode and dentry information between superblocks, then all sorts of interesting possibilities arise... Cheers Trond - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
On Wed, 2007-04-18 at 11:19 +0200, Miklos Szeredi wrote: > > > Allowing this and other flags to NOT be propagated just makes it > > > possible to have a set of shared mounts with asymmetric properties, > > > which may actually be desirable. > > > > The shared mount feature was designed to ensure that the mount remained > > identical at all the locations. > > OK, so remount not propagating mount flags is a bug then? As I said earlier, are there any flags currently that if not propagated can lead to conflicts with the shared subtree semantics? I am not aware of any. If you did notice a case, than according to me its a bug. But the new proposed 'allow unpriviledged mounts' flag; if not propagated among peers (and slaves) of a shared mount can lead to conflicts with shared subtree semantics. Since mount in one shared-mount; when propagated to its peer fails to mount and hence lead to un-identical peers. > > > Now designing features to make it un-identical but still naming it > > shared, will break its original purpose. Slave mounts were designed > > to make it asymmetric. > > What if I want to modify flags in a master mount, but not the slave > mount? Would I be screwed? For example: mount is read-only in both > master and slave. I want to mark it read-write in master but not in > slave. What do I do? Making mounts read-only or read-write -- will that effect mount propagation in such a way that future mounts in any one of the peers will not be able to propagate that mount to its peers or slaves? I don't think it will. Hence its ok to selectively mark some mounts read-only and some mounts read-write. However with the introduction of unpriviledged mount semantics, there can be cases where a user has priviledges to mount at one location but not at a different location. if these two location happen to share a peer-relationship than I see a case of interference of read-write flag semantics with shared subtree semantics. And hence we will end up propagating the read-write flag too or have to craft a different semantics that stays consistent. > > > Whatever feature that is desired to be exploited; can that be exploited > > with the current set of semantics that we have? Is there a real need to > > make the mounts asymmetric but at the same time name them as shared? > > Maybe I dont understand what the desired application is? > > I do think this question of propagating mount flags is totally > independent of user mounts. > > As it stands, currently remount doesn't propagate mount flags, and I > don't see any compelling reasons why it should. > > The patchset introduces a new mount flag "allowusermnt", but I don't > see any compelling reason to propagate this flag _either_. > > Please say so if you do have such a reason. As I've explained, having > this flag set differently in parts of a propagation tree does not > interfere with or break propagation in any way. As I said earlier, I see a case where two mounts that are peers of each other can become un-identical if we dont propagate the "allowusermnt". As a practical example. /tmp and /mnt are peers of each other. /tmp has its "allowusermnt" flag set, which has not been propagated to /mnt. now a normal-user mounts an ext2 file system under /tmp at /tmp/1 unfortunately the mount wont appear under /mnt/1 and this breaks the shared-subtree semantics which promises: whatever is mounted under /tmp will also be visible under /mnt and in case if you allow the mount to appear under /mnt/1, you will break unpriviledge mounts semantics which promises: a normal user will not be able to mount at a location that does not allow user-mounts. RP > > Miklos > - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
> >> > I've tried to make this unprivileged mount thing as simple as > >> > possible, and no simpler. If we can make it even simpler, all the > >> > better. > >> > >> We are certainly much more complex then the code in plan9 (just > >> read through it) so I think we have room for improvement. > >> > >> Just for reference what I saw in plan 9 was: > >> - No super user checks in it's mount, unmount, or namespace creation paths. > >> - A flag to deny new mounts but not new bind mounts (for administrative > > purposes > >> the comment said). > >> > >> Our differences from plan9. > >> - suid capable binaries. (SUID please go away). > >> - A history of programs assuming only root could call mount/unmount. > > > > I hate suid as well. _The_ motivation behind this patchset was to get > > rid of "fusermount", a suid mount helper for fuse. > > > > But I don't think suid is going away, and definitely not overnight. > > Agreed, unless it just happens that killing is equally as hard as > doing non-privileged mounts. Which I really don't think will be > the case. suid executables can always be replaced by a non-privileged > part that connect to a daemon on localhost. > > > Also I don't think we want to require auditing userspace before > > enabling user mounts. > > Given the complexity of the code to avoids audits adds, and especially > the uncertainty of how all of the pieces add up together I really > think we do need to audit user space (but only in a limited way). > > This is a paradigm shift in how mounts are managed and to get > the full benefit of it we need to be prepared to deal with the > paradigm shift. > > Essentially what the audit must ensure is that > (a) non-root users are always run in a non-default namespace so > mounts and unmounts they generate will not have global effect. But unprivileged proceses are not only created through login. What happens, when some process does setuid(NONZERO). With your proposal it now gained the privilege of mounting in the initial namespace. IOW every program calling setuid() now has to be audited for any problems this could cause. > (b) If we setup something like the proposed /share that administrative > tools know how to treat it properly. > > That is not an especially hard audit of user space and it noticeably > reduces the complexity of what we must implement. > > > If I understand correctly, your proposal is to get rid of MNT_USER and > > MNT_ALLOWUSERMNT and allow/deny unprivileged mounts and umounts based > > on a boolean sysctl flag and on a check if the target namespace is the > > initial namespace or not. > > No. I really do not want to treat the initial namespace in a special way > from an implementation point of view. Ah. > >From a distro point of view I don't think we should ever allow a user > into the initial mount namespace, and that is what we should audit. > All of the ways a user can login to a machine. > > We need to audit the login paths anyway if we are going to do anything > interesting with the mount namespace. So I see this as no real > additional overhead to make things usable. > > > And maybe add some extra checks which > > prevent ugliness from happening with suid programs. Is this correct? > > Definitely add some extra permission checks to prevent ugliness from > happening with suid executables. In the general case the problem > with suid executables is that they expect parts of the mount namespace > that a user cannot modify not to be modified. > > Ensuring that our permission checks keep that promise for mount > and umount is going to be a bit challenging, because we need to > think through a lot of scenarios. But it is not that hard. > > > If so, how are we going to make sure this won't break existing > > userspace without doing a full audit of all suid programs in every > > distro that wants this feature? > > The permission checks to ensure you can not modify a filesystem with > mounts in a way that you could not modify it by creating or deleting > files should be enough. Umm, well. What if user mounts a filesystem read-only. Then wants to unmount, but hey, it's read-only, no permission to write, no unmount... That's just a stupid example, but it shows, that file permissions are not always useful for determining what you can mount, and especially what you can unmount. > That probably means that we are restricted to mounting filesystems > with the equivalent of uid=$(id -u) gid=$(id -g). That is if you > aren't root all files in the filesystem you cause to be mounted > must be owned by you. That way you have permission to unmount or > delete them. That rules out unprivileged bind mounts. > At the very least the user who causes a mount to be created should > be the owner and have complete control over the directory mount point. > So that they can at least theoretically remove all of the files and > directories at the mount point (which would be equivalent to > unmounting it). Checking
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
Miklos Szeredi <[EMAIL PROTECTED]> writes: >> > I've tried to make this unprivileged mount thing as simple as >> > possible, and no simpler. If we can make it even simpler, all the >> > better. >> >> We are certainly much more complex then the code in plan9 (just >> read through it) so I think we have room for improvement. >> >> Just for reference what I saw in plan 9 was: >> - No super user checks in it's mount, unmount, or namespace creation paths. >> - A flag to deny new mounts but not new bind mounts (for administrative > purposes >> the comment said). >> >> Our differences from plan9. >> - suid capable binaries. (SUID please go away). >> - A history of programs assuming only root could call mount/unmount. > > I hate suid as well. _The_ motivation behind this patchset was to get > rid of "fusermount", a suid mount helper for fuse. > > But I don't think suid is going away, and definitely not overnight. Agreed, unless it just happens that killing is equally as hard as doing non-privileged mounts. Which I really don't think will be the case. suid executables can always be replaced by a non-privileged part that connect to a daemon on localhost. > Also I don't think we want to require auditing userspace before > enabling user mounts. Given the complexity of the code to avoids audits adds, and especially the uncertainty of how all of the pieces add up together I really think we do need to audit user space (but only in a limited way). This is a paradigm shift in how mounts are managed and to get the full benefit of it we need to be prepared to deal with the paradigm shift. Essentially what the audit must ensure is that (a) non-root users are always run in a non-default namespace so mounts and unmounts they generate will not have global effect. (b) If we setup something like the proposed /share that administrative tools know how to treat it properly. That is not an especially hard audit of user space and it noticeably reduces the complexity of what we must implement. > If I understand correctly, your proposal is to get rid of MNT_USER and > MNT_ALLOWUSERMNT and allow/deny unprivileged mounts and umounts based > on a boolean sysctl flag and on a check if the target namespace is the > initial namespace or not. No. I really do not want to treat the initial namespace in a special way from an implementation point of view. >From a distro point of view I don't think we should ever allow a user into the initial mount namespace, and that is what we should audit. All of the ways a user can login to a machine. We need to audit the login paths anyway if we are going to do anything interesting with the mount namespace. So I see this as no real additional overhead to make things usable. > And maybe add some extra checks which > prevent ugliness from happening with suid programs. Is this correct? Definitely add some extra permission checks to prevent ugliness from happening with suid executables. In the general case the problem with suid executables is that they expect parts of the mount namespace that a user cannot modify not to be modified. Ensuring that our permission checks keep that promise for mount and umount is going to be a bit challenging, because we need to think through a lot of scenarios. But it is not that hard. > If so, how are we going to make sure this won't break existing > userspace without doing a full audit of all suid programs in every > distro that wants this feature? The permission checks to ensure you can not modify a filesystem with mounts in a way that you could not modify it by creating or deleting files should be enough. That probably means that we are restricted to mounting filesystems with the equivalent of uid=$(id -u) gid=$(id -g). That is if you aren't root all files in the filesystem you cause to be mounted must be owned by you. That way you have permission to unmount or delete them. At the very least the user who causes a mount to be created should be the owner and have complete control over the directory mount point. So that they can at least theoretically remove all of the files and directories at the mount point (which would be equivalent to unmounting it). > Also how are we going to prevent the user from creating millions of > mounts, and using up all the kernel memory for vfsmounts? I definitely agree that we need some kind of accounting. I'm don't think we can do this per user (which would be nice) and I don't believe your code does attempts to limit mounts by user either. A simple global limit on the number of mounts should be sufficient. If necessary we can allow the limit to be ignored if you have the appropriate capability. Eric - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
> > > Don't forget that almost all mount flags are per-superblock. How are you > > > planning on dealing with the case that one user mounts a filesystem > > > read-only, while another is trying to mount the same one read-write? > > > > Yeah, I forgot, the per-mount read-only patches are not yet in. > > > > That doesn't really change my agrument though. _If_ the flag is per > > mount, then it makes sense to be able to change it on a master and not > > on a slave. If mount flags are propagated, this is not possible. > > Read-only isn't the only issue. On something like NFS, there are flags > to set the security flavour, turn on/off encryption etc. > > If I mount your home directory using no encryption in my namespace, for > instance, then neither you nor the administrator will be able to turn it > on afterwards in yours without first unmounting it from mine so that the > superblock is destroyed. OK, that's interesting, but I fail to grasp the relevance of this to unprivileged mounts. Or are you thinking of unprivileged NFS mounts? Well, think again, because that involves _much_ more than it seems at first glance. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
On Wed, Apr 18, 2007 at 10:26:29AM -0400, Trond Myklebust wrote: > > That doesn't really change my agrument though. _If_ the flag is per > > mount, then it makes sense to be able to change it on a master and not > > on a slave. If mount flags are propagated, this is not possible. > > Read-only isn't the only issue. On something like NFS, there are flags > to set the security flavour, turn on/off encryption etc. > > If I mount your home directory using no encryption in my namespace, for > instance, then neither you nor the administrator will be able to turn it > on afterwards in yours without first unmounting it from mine so that the > superblock is destroyed. I suspect the right answer here is to make nfs mount handling smarter. The way mounting works the filesystem is allowed to choose whether it can re-used a superblock or needs a new one. In the NFS case we probably want to allow multiple superblocks for the same export if important paramaters like the security model mismatch. This is however only the technical part of the answer. There's a more important one, and that's the user experience - we need a much better way to document which flags are per-superblock and which are per-mount. Due to this and some other issues we'll probably need a new mount API in some time. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
On Wed, 2007-04-18 at 16:03 +0200, Miklos Szeredi wrote: > > Don't forget that almost all mount flags are per-superblock. How are you > > planning on dealing with the case that one user mounts a filesystem > > read-only, while another is trying to mount the same one read-write? > > Yeah, I forgot, the per-mount read-only patches are not yet in. > > That doesn't really change my agrument though. _If_ the flag is per > mount, then it makes sense to be able to change it on a master and not > on a slave. If mount flags are propagated, this is not possible. Read-only isn't the only issue. On something like NFS, there are flags to set the security flavour, turn on/off encryption etc. If I mount your home directory using no encryption in my namespace, for instance, then neither you nor the administrator will be able to turn it on afterwards in yours without first unmounting it from mine so that the superblock is destroyed. Cheers Trond - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
> > > > I've tried to make this unprivileged mount thing as simple as > > > > possible, and no simpler. If we can make it even simpler, all the > > > > better. > > > > > > We are certainly much more complex then the code in plan9 (just > > > read through it) so I think we have room for improvement. > > > > > > Just for reference what I saw in plan 9 was: > > > - No super user checks in it's mount, unmount, or namespace creation > > > paths. > > > - A flag to deny new mounts but not new bind mounts (for administrative > > > purposes > > > the comment said). > > > > > > Our differences from plan9. > > > - suid capable binaries. (SUID please go away). > > > - A history of programs assuming only root could call mount/unmount. > > > > I hate suid as well. _The_ motivation behind this patchset was to get > > rid of "fusermount", a suid mount helper for fuse. > > > > But I don't think suid is going away, and definitely not overnight. > > Also I don't think we want to require auditing userspace before > > enabling user mounts. > > > > If I understand correctly, your proposal is to get rid of MNT_USER and > > MNT_ALLOWUSERMNT and allow/deny unprivileged mounts and umounts based > > on a boolean sysctl flag and on a check if the target namespace is the > > initial namespace or not. And maybe add some extra checks which > > prevent ugliness from happening with suid programs. Is this correct? > > > > If so, how are we going to make sure this won't break existing > > userspace without doing a full audit of all suid programs in every > > distro that wants this feature? > > > > Also how are we going to prevent the user from creating millions of > > mounts, and using up all the kernel memory for vfsmounts? > > Don't forget that almost all mount flags are per-superblock. How are you > planning on dealing with the case that one user mounts a filesystem > read-only, while another is trying to mount the same one read-write? Yeah, I forgot, the per-mount read-only patches are not yet in. That doesn't really change my agrument though. _If_ the flag is per mount, then it makes sense to be able to change it on a master and not on a slave. If mount flags are propagated, this is not possible. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
On Wed, 2007-04-18 at 11:11 +0200, Miklos Szeredi wrote: > > > I've tried to make this unprivileged mount thing as simple as > > > possible, and no simpler. If we can make it even simpler, all the > > > better. > > > > We are certainly much more complex then the code in plan9 (just > > read through it) so I think we have room for improvement. > > > > Just for reference what I saw in plan 9 was: > > - No super user checks in it's mount, unmount, or namespace creation paths. > > - A flag to deny new mounts but not new bind mounts (for administrative > > purposes > > the comment said). > > > > Our differences from plan9. > > - suid capable binaries. (SUID please go away). > > - A history of programs assuming only root could call mount/unmount. > > I hate suid as well. _The_ motivation behind this patchset was to get > rid of "fusermount", a suid mount helper for fuse. > > But I don't think suid is going away, and definitely not overnight. > Also I don't think we want to require auditing userspace before > enabling user mounts. > > If I understand correctly, your proposal is to get rid of MNT_USER and > MNT_ALLOWUSERMNT and allow/deny unprivileged mounts and umounts based > on a boolean sysctl flag and on a check if the target namespace is the > initial namespace or not. And maybe add some extra checks which > prevent ugliness from happening with suid programs. Is this correct? > > If so, how are we going to make sure this won't break existing > userspace without doing a full audit of all suid programs in every > distro that wants this feature? > > Also how are we going to prevent the user from creating millions of > mounts, and using up all the kernel memory for vfsmounts? Don't forget that almost all mount flags are per-superblock. How are you planning on dealing with the case that one user mounts a filesystem read-only, while another is trying to mount the same one read-write? Trond - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
> > Allowing this and other flags to NOT be propagated just makes it > > possible to have a set of shared mounts with asymmetric properties, > > which may actually be desirable. > > The shared mount feature was designed to ensure that the mount remained > identical at all the locations. OK, so remount not propagating mount flags is a bug then? > Now designing features to make it un-identical but still naming it > shared, will break its original purpose. Slave mounts were designed > to make it asymmetric. What if I want to modify flags in a master mount, but not the slave mount? Would I be screwed? For example: mount is read-only in both master and slave. I want to mark it read-write in master but not in slave. What do I do? > Whatever feature that is desired to be exploited; can that be exploited > with the current set of semantics that we have? Is there a real need to > make the mounts asymmetric but at the same time name them as shared? > Maybe I dont understand what the desired application is? I do think this question of propagating mount flags is totally independent of user mounts. As it stands, currently remount doesn't propagate mount flags, and I don't see any compelling reasons why it should. The patchset introduces a new mount flag "allowusermnt", but I don't see any compelling reason to propagate this flag _either_. Please say so if you do have such a reason. As I've explained, having this flag set differently in parts of a propagation tree does not interfere with or break propagation in any way. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
> > I've tried to make this unprivileged mount thing as simple as > > possible, and no simpler. If we can make it even simpler, all the > > better. > > We are certainly much more complex then the code in plan9 (just > read through it) so I think we have room for improvement. > > Just for reference what I saw in plan 9 was: > - No super user checks in it's mount, unmount, or namespace creation paths. > - A flag to deny new mounts but not new bind mounts (for administrative > purposes > the comment said). > > Our differences from plan9. > - suid capable binaries. (SUID please go away). > - A history of programs assuming only root could call mount/unmount. I hate suid as well. _The_ motivation behind this patchset was to get rid of "fusermount", a suid mount helper for fuse. But I don't think suid is going away, and definitely not overnight. Also I don't think we want to require auditing userspace before enabling user mounts. If I understand correctly, your proposal is to get rid of MNT_USER and MNT_ALLOWUSERMNT and allow/deny unprivileged mounts and umounts based on a boolean sysctl flag and on a check if the target namespace is the initial namespace or not. And maybe add some extra checks which prevent ugliness from happening with suid programs. Is this correct? If so, how are we going to make sure this won't break existing userspace without doing a full audit of all suid programs in every distro that wants this feature? Also how are we going to prevent the user from creating millions of mounts, and using up all the kernel memory for vfsmounts? Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
On Tue, 2007-04-17 at 21:43 +0200, Miklos Szeredi wrote: > > > > I'm a bit lost about what is currently done and who advocates for what. > > > > > > > > It seems to me the MNT_ALLOWUSERMNT (or whatever :) flag should be > > > > propagated. In the /share rbind+chroot example, I assume the admin > > > > would start by doing > > > > > > > > mount --bind /share /share > > > > mount --make-slave /share > > > > mount --bind -o allow_user_mounts /share (or whatever) > > > > mount --make-shared /share > > > > > > > > then on login, pam does > > > > > > > > chroot /share/$USER > > > > > > > > or some sort of > > > > > > > > mount --bind /share /home/$USER/root > > > > chroot /home/$USER/root > > > > > > > > or whatever. In any case, the user cannot make user mounts except under > > > > /share, and any cloned namespaces will still allow user mounts. > > > > > > I don't quite understand your method. This is how I think of it: > > > > > > mount --make-rshared / > > > mkdir -p /mnt/ns/$USER > > > mount --rbind / /mnt/ns/$USER > > > mount --make-rslave /mnt/ns/$USER > > > mount --set-flags --recursive -oallowusermnt /mnt/ns/$USER > > > chroot /mnt/ns/$USER > > > su - $USER > > > > > > I did actually try something equivalent (without the fancy mount > > > commands though), and it worked fine. The only "problem" is the > > > proliferation of mounts in /proc/mounts. There was a recently posted > > > patch in AppArmor, that at least hides unreachable mounts from > > > /proc/mounts, so the user wouldn't see all those. But it could still > > > be pretty confusing to the sysadmin. > > > > unbindable mounts were designed to overcome the proliferation problem. > > > > Your steps should be something like this: > > > > mount --make-rshared / > > mkdir -p /mnt/ns > > mount --bind /mnt/ns /mnt/ns > > mount --make-unbindable /mnt/ns > > mkdir -p /mnt/ns/$USER > > mount --rbind / /mnt/ns/$USER > > mount --make-rslave /mnt/ns/$USER > > mount --set-flags --recursive -oallowusermnt /mnt/ns/$USER > > chroot /mnt/ns/$USER > > su - $USER > > > > try this and your proliferation problem will disappear. :-) > > Right, this is needed. > > My problem wasn't actually this (which would only have hit, if I tried > with more than one user), just that the number of mounts in > /proc/mounts grows linearly with the number of users. > > That can't be helped in such an easy way unfortunately. > > > > Propagating some mount flags and not propagating others is > > > inconsistent and confusing, so I wouldn't want that. Currently > > > remount doesn't propagate mount flags, that may be a bug, > > > > For consistency reason, one can propagate all the flags. But > > propagating only those flags that interfere with shared-subtree > > semantics should suffice. > > I still don't believe not propagating "allowusermnt" interferes with > mount propagation. In my posted patches the mount (including > propagations) is allowed based on the "allowusermnt" flag on the > parent of the requested mount. The flag is _not_ checked during > propagation. > > Allowing this and other flags to NOT be propagated just makes it > possible to have a set of shared mounts with asymmetric properties, > which may actually be desirable. The shared mount feature was designed to ensure that the mount remained identical at all the locations. Now designing features to make it un-identical but still naming it shared, will break its original purpose. Slave mounts were designed to make it asymmetric. Whatever feature that is desired to be exploited; can that be exploited with the current set of semantics that we have? Is there a real need to make the mounts asymmetric but at the same time name them as shared? Maybe I dont understand what the desired application is? RP > > Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
Miklos Szeredi <[EMAIL PROTECTED]> writes: >> > I'm still not sure, what your problem is. >> >> My problem right now is that I see a serious complexity escalation in >> the user interface that we must support indefinitely. >> >> I see us taking a nice powerful concept and seriously watering it down. >> To some extent we have to avoid confusing suid applications. (I would >> so love to remove the SUID bit...). >> >> I'm being contrary to ensure we have a good code review. > > OK. And it's very much appreciated :) > >> I have heard it said that there are two kinds of design. Something >> so simple it obviously has no deficiencies. Something so complex it has >> no obvious deficiencies. I am very much afraid we are slipping the >> mount namespace into the latter category of work. Which is a bad >> bad thing for core OS feature. > > I've tried to make this unprivileged mount thing as simple as > possible, and no simpler. If we can make it even simpler, all the > better. We are certainly much more complex then the code in plan9 (just read through it) so I think we have room for improvement. Just for reference what I saw in plan 9 was: - No super user checks in it's mount, unmount, or namespace creation paths. - A flag to deny new mounts but not new bind mounts (for administrative purposes the comment said). Our differences from plan9. - suid capable binaries. (SUID please go away). - A history of programs assuming only root could call mount/unmount. >> In part this really disturbs me because we now have two mechanisms for >> controlling the scope of what a user can do. > > You mean rbind+chroot and clone(CLONE_NS)? Yes, those are two > different mechanisms achieving very similar results. But what has > this to do with unprivileged mounts? The practical question is how do we limit what a user can mount and unmount. I would contend that at first glance stuffing a user in their own mount namespace is sufficient, on a system with utilities aware of the consequences of mount/unmount. So we may not need a unprivileged mount disable except as a way to allow an old user space to run a new kernel. >> A flag or a new namespace. Two mechanisms to accomplish the same >> thing sound wrong, and hard to manage. > > The flag permitting the unprivileged mounts (which we now agreed to > name "allowusermnt") is used in both cases. > > Just creating a new namespace doesn't always imply that you want to > allow user mounts inside, does it? These are orthogonal features. After user space has been updated we always want to allow unprivileged mounts. If I get pushed I will say that we need to remove suid exec capability from user space as well. At which point we don't even need directory security checks, there is enough benefit there I certainly think it is worth considering having an entire NOSUID user space. Removing suid is probably excessive but if it isn't much harder then sane mount namespace support we should probably consider it. >> > - sysadmin creates /mnt/usermounts writable to all users, with >> > sticky bit (same as /tmp), does "mount --bind /mnt/usermounts >> > /mnt/usermounts" and sets the "allow unpriv submounts" on >> > /mnt/usermounts. >> > >> > All of these are perfectly safe wrt userdel and backup (assuming it >> > doesn't try back up /mnt). >> >> I also don't understand at all the user= mount flag and options. > > The "user=UID" or (or MNT_USER flag) serves multiple purposes: > > - help mount(8) move away from /etc/mtab > - allow unprivileged umounts > - account user mounts > >> All it seemed to be used for was adding permissions to unmount. In user >> space to deal with the lack of any form of untrusted mounts I can understand >> this. In kernel space this seems to be more of a problem. > > Why is handling unprivileged mounts in kernel different from handling > them in userspace in this respect? Ok. I just looked at what user space is doing. The difference is that what user space is doing predates mount namespaces, and was there as far as I can tell to keep one user from causing problems for another user. If we choose to make mount namespaces to be the unit of granularity we don't need this capability. All we have to do is deny unmounts that would confuse a suid executable. Which mounts are those? Eric - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
> > > I'm a bit lost about what is currently done and who advocates for what. > > > > > > It seems to me the MNT_ALLOWUSERMNT (or whatever :) flag should be > > > propagated. In the /share rbind+chroot example, I assume the admin > > > would start by doing > > > > > > mount --bind /share /share > > > mount --make-slave /share > > > mount --bind -o allow_user_mounts /share (or whatever) > > > mount --make-shared /share > > > > > > then on login, pam does > > > > > > chroot /share/$USER > > > > > > or some sort of > > > > > > mount --bind /share /home/$USER/root > > > chroot /home/$USER/root > > > > > > or whatever. In any case, the user cannot make user mounts except under > > > /share, and any cloned namespaces will still allow user mounts. > > > > I don't quite understand your method. This is how I think of it: > > > > mount --make-rshared / > > mkdir -p /mnt/ns/$USER > > mount --rbind / /mnt/ns/$USER > > mount --make-rslave /mnt/ns/$USER > > mount --set-flags --recursive -oallowusermnt /mnt/ns/$USER > > chroot /mnt/ns/$USER > > su - $USER > > > > I did actually try something equivalent (without the fancy mount > > commands though), and it worked fine. The only "problem" is the > > proliferation of mounts in /proc/mounts. There was a recently posted > > patch in AppArmor, that at least hides unreachable mounts from > > /proc/mounts, so the user wouldn't see all those. But it could still > > be pretty confusing to the sysadmin. > > unbindable mounts were designed to overcome the proliferation problem. > > Your steps should be something like this: > > mount --make-rshared / > mkdir -p /mnt/ns > mount --bind /mnt/ns /mnt/ns > mount --make-unbindable /mnt/ns > mkdir -p /mnt/ns/$USER > mount --rbind / /mnt/ns/$USER > mount --make-rslave /mnt/ns/$USER > mount --set-flags --recursive -oallowusermnt /mnt/ns/$USER > chroot /mnt/ns/$USER > su - $USER > > try this and your proliferation problem will disappear. :-) Right, this is needed. My problem wasn't actually this (which would only have hit, if I tried with more than one user), just that the number of mounts in /proc/mounts grows linearly with the number of users. That can't be helped in such an easy way unfortunately. > > Propagating some mount flags and not propagating others is > > inconsistent and confusing, so I wouldn't want that. Currently > > remount doesn't propagate mount flags, that may be a bug, > > For consistency reason, one can propagate all the flags. But > propagating only those flags that interfere with shared-subtree > semantics should suffice. I still don't believe not propagating "allowusermnt" interferes with mount propagation. In my posted patches the mount (including propagations) is allowed based on the "allowusermnt" flag on the parent of the requested mount. The flag is _not_ checked during propagation. Allowing this and other flags to NOT be propagated just makes it possible to have a set of shared mounts with asymmetric properties, which may actually be desirable. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
On Tue, 2007-04-17 at 19:44 +0200, Miklos Szeredi wrote: > > I'm a bit lost about what is currently done and who advocates for what. > > > > It seems to me the MNT_ALLOWUSERMNT (or whatever :) flag should be > > propagated. In the /share rbind+chroot example, I assume the admin > > would start by doing > > > > mount --bind /share /share > > mount --make-slave /share > > mount --bind -o allow_user_mounts /share (or whatever) > > mount --make-shared /share > > > > then on login, pam does > > > > chroot /share/$USER > > > > or some sort of > > > > mount --bind /share /home/$USER/root > > chroot /home/$USER/root > > > > or whatever. In any case, the user cannot make user mounts except under > > /share, and any cloned namespaces will still allow user mounts. > > I don't quite understand your method. This is how I think of it: > > mount --make-rshared / > mkdir -p /mnt/ns/$USER > mount --rbind / /mnt/ns/$USER > mount --make-rslave /mnt/ns/$USER > mount --set-flags --recursive -oallowusermnt /mnt/ns/$USER > chroot /mnt/ns/$USER > su - $USER > > I did actually try something equivalent (without the fancy mount > commands though), and it worked fine. The only "problem" is the > proliferation of mounts in /proc/mounts. There was a recently posted > patch in AppArmor, that at least hides unreachable mounts from > /proc/mounts, so the user wouldn't see all those. But it could still > be pretty confusing to the sysadmin. unbindable mounts were designed to overcome the proliferation problem. Your steps should be something like this: mount --make-rshared / mkdir -p /mnt/ns mount --bind /mnt/ns /mnt/ns mount --make-unbindable /mnt/ns mkdir -p /mnt/ns/$USER mount --rbind / /mnt/ns/$USER mount --make-rslave /mnt/ns/$USER mount --set-flags --recursive -oallowusermnt /mnt/ns/$USER chroot /mnt/ns/$USER su - $USER try this and your proliferation problem will disappear. :-) > > So in that sense doing it the complicated way, by first cloning the > namespace, and then copying and sharing mounts individually which need > to be shared could relieve this somewhat. the unbindable mount will just provide you permanent relief. > > Another point: user mounts under /proc and /sys shouldn't be allowed. > There are files there (at least in /proc) that are seemingly writable > by the user, but they are still not writable in the sense, that > "normal" files are. > > Anyway, there are lots of userspace policy issues, but those don't > impact the kernel part. > > As for the original question of propagating the "allowusermnt" flag, I > think it doesn't matter, as long as it's consistent and documented. > > Propagating some mount flags and not propagating others is > inconsistent and confusing, so I wouldn't want that. Currently > remount doesn't propagate mount flags, that may be a bug, For consistency reason, one can propagate all the flags. But propagating only those flags that interfere with shared-subtree semantics should suffice. wait...Dave's read-only bind mounts infact need the ability to selectively make some mounts readonly. In such cases propagating the read-only flag will just step on Dave's feature. Wont' it? RP > > Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
> > mount --make-rshared / > > mkdir -p /mnt/ns/$USER > > mount --rbind / /mnt/ns/$USER > > mount --make-rslave /mnt/ns/$USER > > This was my main point - that the tree in which users can mount will be > a slave of /, so that propagating the "are user mounts allowed" flag > among peers is safe and intuitive. I think it's equally intuitive if flags are not propagated. After all, I may want to set the mount flag _only_ on this particular mount, and not anything else. This is something I wouln't be sure about either way without consulting the man. > True. But the kernel functionality you provide enables both ways so no > problem in either case :) > > > Another point: user mounts under /proc and /sys shouldn't be allowed. > > There are files there (at least in /proc) that are seemingly writable > > by the user, but they are still not writable in the sense, that > > "normal" files are. > > Good point. > > > Anyway, there are lots of userspace policy issues, but those don't > > impact the kernel part. > > Though it might make sense to enforce /proc and /sys not allowing user > mounts under them in the kernel. I think not, it would just be another policy decision having to be made in the kernel on an fs by fs basis, and getting it wrong would be much worse than getting it wrong in userspace. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
> > I'm still not sure, what your problem is. > > My problem right now is that I see a serious complexity escalation in > the user interface that we must support indefinitely. > > I see us taking a nice powerful concept and seriously watering it down. > To some extent we have to avoid confusing suid applications. (I would > so love to remove the SUID bit...). > > I'm being contrary to ensure we have a good code review. OK. And it's very much appreciated :) > I have heard it said that there are two kinds of design. Something > so simple it obviously has no deficiencies. Something so complex it has > no obvious deficiencies. I am very much afraid we are slipping the > mount namespace into the latter category of work. Which is a bad > bad thing for core OS feature. I've tried to make this unprivileged mount thing as simple as possible, and no simpler. If we can make it even simpler, all the better. > > With the v3 of the usermounts patchset, by default, user mounts are > > disabled, because the "allow unpriv submounts" flag is cleared on all > > mounts. > > > > There are several options available to sysadmins and distro builders > > to enable user mounts in a secure way: > > > > - pam module, which creates a private namespace, and sets "allow > > unpriv submounts" on the mounts within the namespace > > > > - pam module, which rbinds / onto /mnt/ns/$USER, and chroots into > > /mnt/ns/$USER, then sets the "allow unpriv submounts" on the > > mounts under /mnt/ns/$USER. > > In part this really disturbs me because we now have two mechanisms for > controlling the scope of what a user can do. You mean rbind+chroot and clone(CLONE_NS)? Yes, those are two different mechanisms achieving very similar results. But what has this to do with unprivileged mounts? > A flag or a new namespace. Two mechanisms to accomplish the same > thing sound wrong, and hard to manage. The flag permitting the unprivileged mounts (which we now agreed to name "allowusermnt") is used in both cases. Just creating a new namespace doesn't always imply that you want to allow user mounts inside, does it? These are orthogonal features. > > - sysadmin creates /mnt/usermounts writable to all users, with > > sticky bit (same as /tmp), does "mount --bind /mnt/usermounts > > /mnt/usermounts" and sets the "allow unpriv submounts" on > > /mnt/usermounts. > > > > All of these are perfectly safe wrt userdel and backup (assuming it > > doesn't try back up /mnt). > > I also don't understand at all the user= mount flag and options. The "user=UID" or (or MNT_USER flag) serves multiple purposes: - help mount(8) move away from /etc/mtab - allow unprivileged umounts - account user mounts > All it seemed to be used for was adding permissions to unmount. In user > space to deal with the lack of any form of untrusted mounts I can understand > this. In kernel space this seems to be more of a problem. Why is handling unprivileged mounts in kernel different from handling them in userspace in this respect? Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
Miklos Szeredi <[EMAIL PROTECTED]> writes: > I'm still not sure, what your problem is. My problem right now is that I see a serious complexity escalation in the user interface that we must support indefinitely. I see us taking a nice powerful concept and seriously watering it down. To some extent we have to avoid confusing suid applications. (I would so love to remove the SUID bit...). I'm being contrary to ensure we have a good code review. I have heard it said that there are two kinds of design. Something so simple it obviously has no deficiencies. Something so complex it has no obvious deficiencies. I am very much afraid we are slipping the mount namespace into the latter category of work. Which is a bad bad thing for core OS feature. > With the v3 of the usermounts patchset, by default, user mounts are > disabled, because the "allow unpriv submounts" flag is cleared on all > mounts. > > There are several options available to sysadmins and distro builders > to enable user mounts in a secure way: > > - pam module, which creates a private namespace, and sets "allow > unpriv submounts" on the mounts within the namespace > > - pam module, which rbinds / onto /mnt/ns/$USER, and chroots into > /mnt/ns/$USER, then sets the "allow unpriv submounts" on the > mounts under /mnt/ns/$USER. In part this really disturbs me because we now have two mechanisms for controlling the scope of what a user can do. A flag or a new namespace. Two mechanisms to accomplish the same thing sound wrong, and hard to manage. > - sysadmin creates /mnt/usermounts writable to all users, with > sticky bit (same as /tmp), does "mount --bind /mnt/usermounts > /mnt/usermounts" and sets the "allow unpriv submounts" on > /mnt/usermounts. > > All of these are perfectly safe wrt userdel and backup (assuming it > doesn't try back up /mnt). I also don't understand at all the user= mount flag and options. All it seemed to be used for was adding permissions to unmount. In user space to deal with the lack of any form of untrusted mounts I can understand this. In kernel space this seems to be more of a problem. Eric - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
Quoting Miklos Szeredi ([EMAIL PROTECTED]): > > I'm a bit lost about what is currently done and who advocates for what. > > > > It seems to me the MNT_ALLOWUSERMNT (or whatever :) flag should be > > propagated. In the /share rbind+chroot example, I assume the admin > > would start by doing > > > > mount --bind /share /share > > mount --make-slave /share > > mount --bind -o allow_user_mounts /share (or whatever) > > mount --make-shared /share > > > > then on login, pam does > > > > chroot /share/$USER > > > > or some sort of > > > > mount --bind /share /home/$USER/root > > chroot /home/$USER/root > > > > or whatever. In any case, the user cannot make user mounts except under > > /share, and any cloned namespaces will still allow user mounts. > > I don't quite understand your method. This is how I think of it: > > mount --make-rshared / > mkdir -p /mnt/ns/$USER > mount --rbind / /mnt/ns/$USER > mount --make-rslave /mnt/ns/$USER This was my main point - that the tree in which users can mount will be a slave of /, so that propagating the "are user mounts allowed" flag among peers is safe and intuitive. > mount --set-flags --recursive -oallowusermnt /mnt/ns/$USER > chroot /mnt/ns/$USER > su - $USER > > I did actually try something equivalent (without the fancy mount > commands though), and it worked fine. The only "problem" is the > proliferation of mounts in /proc/mounts. There was a recently posted > patch in AppArmor, that at least hides unreachable mounts from > /proc/mounts, so the user wouldn't see all those. But it could still > be pretty confusing to the sysadmin. > > So in that sense doing it the complicated way, by first cloning the > namespace, and then copying and sharing mounts individually which need > to be shared could relieve this somewhat. True. But the kernel functionality you provide enables both ways so no problem in either case :) > Another point: user mounts under /proc and /sys shouldn't be allowed. > There are files there (at least in /proc) that are seemingly writable > by the user, but they are still not writable in the sense, that > "normal" files are. Good point. > Anyway, there are lots of userspace policy issues, but those don't > impact the kernel part. Though it might make sense to enforce /proc and /sys not allowing user mounts under them in the kernel. > As for the original question of propagating the "allowusermnt" flag, I > think it doesn't matter, as long as it's consistent and documented. > > Propagating some mount flags and not propagating others is > inconsistent and confusing, so I wouldn't want that. Currently > remount doesn't propagate mount flags, that may be a bug, dunno. Dave, any thoughts on safety of propagating the vfsmount read-only flags? -serge - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
> I'm a bit lost about what is currently done and who advocates for what. > > It seems to me the MNT_ALLOWUSERMNT (or whatever :) flag should be > propagated. In the /share rbind+chroot example, I assume the admin > would start by doing > > mount --bind /share /share > mount --make-slave /share > mount --bind -o allow_user_mounts /share (or whatever) > mount --make-shared /share > > then on login, pam does > > chroot /share/$USER > > or some sort of > > mount --bind /share /home/$USER/root > chroot /home/$USER/root > > or whatever. In any case, the user cannot make user mounts except under > /share, and any cloned namespaces will still allow user mounts. I don't quite understand your method. This is how I think of it: mount --make-rshared / mkdir -p /mnt/ns/$USER mount --rbind / /mnt/ns/$USER mount --make-rslave /mnt/ns/$USER mount --set-flags --recursive -oallowusermnt /mnt/ns/$USER chroot /mnt/ns/$USER su - $USER I did actually try something equivalent (without the fancy mount commands though), and it worked fine. The only "problem" is the proliferation of mounts in /proc/mounts. There was a recently posted patch in AppArmor, that at least hides unreachable mounts from /proc/mounts, so the user wouldn't see all those. But it could still be pretty confusing to the sysadmin. So in that sense doing it the complicated way, by first cloning the namespace, and then copying and sharing mounts individually which need to be shared could relieve this somewhat. Another point: user mounts under /proc and /sys shouldn't be allowed. There are files there (at least in /proc) that are seemingly writable by the user, but they are still not writable in the sense, that "normal" files are. Anyway, there are lots of userspace policy issues, but those don't impact the kernel part. As for the original question of propagating the "allowusermnt" flag, I think it doesn't matter, as long as it's consistent and documented. Propagating some mount flags and not propagating others is inconsistent and confusing, so I wouldn't want that. Currently remount doesn't propagate mount flags, that may be a bug, dunno. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
Quoting Miklos Szeredi ([EMAIL PROTECTED]): > > > > > > Also for bind-mount and remount operations the flag has to be > > > > > > propagated > > > > > > down its propagation tree. Otherwise a unpriviledged mount in a > > > > > > shared > > > > > > mount wont get reflected in its peers and slaves, leading to > > > > > > unidentical > > > > > > shared-subtrees. > > > > > > > > > > That's an interesting question. Do we want shared mounts to be > > > > > totally identical, including mnt_flags? It doesn't look as if > > > > > do_remount() guarantees that currently. > > > > > > > > Depends on the semantics of each of the flags. Some flags like of the > > > > read/write flag, would not interfere with the propagation semantics > > > > AFAICT. But this one certainly seems to interfere. > > > > > > That depends. Current patches check the "unprivileged submounts > > > allowed under this mount" flag only on the requested mount and not on > > > the propagated mounts. Do you see a problem with this? > > > > Don't see a problem if the flag is propagated to all peers and slave > > mounts. > > > > If not, I see a problem. What if the propagated mount has its flag set > > to not do un-priviledged mounts, whereas the requested mount has it > > allowed? > > Then the mount is allowed. > > It is up to the sysadmin/distro to design set up the propagations in a > way that this is not a problem. > > I think it would be much less clear conceptually, if unprivileged > mounting would have to check propagations as well. > > Miklos I'm a bit lost about what is currently done and who advocates for what. It seems to me the MNT_ALLOWUSERMNT (or whatever :) flag should be propagated. In the /share rbind+chroot example, I assume the admin would start by doing mount --bind /share /share mount --make-slave /share mount --bind -o allow_user_mounts /share (or whatever) mount --make-shared /share then on login, pam does chroot /share/$USER or some sort of mount --bind /share /home/$USER/root chroot /home/$USER/root or whatever. In any case, the user cannot make user mounts except under /share, and any cloned namespaces will still allow user mounts. Or are you guys talking about something else? -serge - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
Quoting Eric W. Biederman ([EMAIL PROTECTED]): > "Serge E. Hallyn" <[EMAIL PROTECTED]> writes: > >> > >> Why are directory permissions not sufficient to allow/deny non-priveleged > > mounts? > >> I don't understand that contention yet. > > > > The same scenarios laid out previously in this thread. I.e. > > > > 1. user hallyn does mount --bind / /home/hallyn/root > > 2. (...) > > 3. admin does "deluser hallyn" > > > > and deluser starts wiping out root > > > > Or, > > > > 1. user hallyn does mount --bind / /home/hallyn/root > > 2. backup daemon starts backing up > > /home/hallyn/root/home/hallyn/root/home... > > > > So we started down the path of forcing users to clone a new namespace > > before doing user mounts, which is what the clone flag was about. Using > > per-mount flags also suffices as you had pointed out, which is being > > done here. But directory permissions are inadequate. > > Interesting > > So far even today these things can happen, however they are sufficiently > unlikely the tools don't account for them. > > Once a hostile user can cause them things are more of a problem. > > > (Unless you want to tackle each problem legacy tool one at a time to > > remove problems - i.e. deluser should umount everything under > > /home/hallyn before deleting, backup should be spawned from it's own > > namespace cloned right after boot or just back up on one filesystem, > > etc.) > > I don't see a way that backup and deluser won't need to be modified > to work properly in a system where non-priveleged mounts are allowed, > at least they will need to account for /share. Yes, all the tools need to avoid /share. Though at least it's a single location we can avoid, and it is purely a system configuration issue, whereas fixing deluser to watch for user mounts under /home involves (I assume) rewriting a part of it. > That said it is clearly a hazard if we enable this functionality by > default. > > If we setup a pam module that triggers on login and perhaps when > cron and at jobs run to setup an additional mount namespace I think > keeping applications locked away in their own mount namespace is > sufficient to avoid hostile users from doing unexpected things to > the initial mount namespace. So unless I am mistake it should be > relatively simple to prevent user space from encountering problems. > > That still leaves the question of how we handle systems with an old > user space that is insufficiently robust to deal with mounts occurring > at unexpected locations. > > > I think a simple sysctl to enable/disable of non-priveleged mounts > defaulting to disabled is enough. > > Am I correct or will it be more difficult than just a little pam > module to ensure non-trusted users never run in the initial mount > namespace? The danger with relying on the pam module is that you have to plug it in all the right places. For instance, if we're talking about malicious users, now we have to start worrying about an ftp daemon with user login that isn't using pam, and happens to have an exploitable bug. So it seems to me the per-mount flag you suggested really is the best solution. Now the pam module is still needed, but only to set things up so that the user *can* do user mounts. If there's a way to login bypassing the pam module, then the user simply won't be able to do user mounts anywhere but under /share, and as Miklos suggested the perms on share can probably be set to 000. -serge - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
Quoting Eric W. Biederman ([EMAIL PROTECTED]): > "Serge E. Hallyn" <[EMAIL PROTECTED]> writes: > >> > >> Why are directory permissions not sufficient to allow/deny non-priveleged > > mounts? > >> I don't understand that contention yet. > > > > The same scenarios laid out previously in this thread. I.e. > > > > 1. user hallyn does mount --bind / /home/hallyn/root > > 2. (...) > > 3. admin does "deluser hallyn" > > > > and deluser starts wiping out root > > > > Or, > > > > 1. user hallyn does mount --bind / /home/hallyn/root > > 2. backup daemon starts backing up > > /home/hallyn/root/home/hallyn/root/home... > > > > So we started down the path of forcing users to clone a new namespace > > before doing user mounts, which is what the clone flag was about. Using > > per-mount flags also suffices as you had pointed out, which is being > > done here. But directory permissions are inadequate. > > Interesting > > So far even today these things can happen, however they are sufficiently > unlikely the tools don't account for them. > > Once a hostile user can cause them things are more of a problem. > > > (Unless you want to tackle each problem legacy tool one at a time to > > remove problems - i.e. deluser should umount everything under > > /home/hallyn before deleting, backup should be spawned from it's own > > namespace cloned right after boot or just back up on one filesystem, > > etc.) > > I don't see a way that backup and deluser won't need to be modified > to work properly in a system where non-priveleged mounts are allowed, > at least they will need to account for /share. > > That said it is clearly a hazard if we enable this functionality by > default. > > If we setup a pam module that triggers on login and perhaps when > cron and at jobs run to setup an additional mount namespace I think > keeping applications locked away in their own mount namespace is > sufficient to avoid hostile users from doing unexpected things to > the initial mount namespace. So unless I am mistake it should be > relatively simple to prevent user space from encountering problems. > > That still leaves the question of how we handle systems with an old > user space that is insufficiently robust to deal with mounts occurring > at unexpected locations. > > > I think a simple sysctl to enable/disable of non-priveleged mounts > defaulting to disabled is enough. There is a sysctl for max_user_mounts which can be set to 0. So a simple on/off sysctl is unnecessary, but given that admins might wonder whether 0 means infinite :), and I agree on/off is important, a second one wouldn't hurt. > Am I correct or will it be more difficult than just a little pam > module to ensure non-trusted users never run in the initial mount > namespace? > > Eric - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
> Interesting > > So far even today these things can happen, however they are sufficiently > unlikely the tools don't account for them. > > Once a hostile user can cause them things are more of a problem. > > > (Unless you want to tackle each problem legacy tool one at a time to > > remove problems - i.e. deluser should umount everything under > > /home/hallyn before deleting, backup should be spawned from it's own > > namespace cloned right after boot or just back up on one filesystem, > > etc.) > > I don't see a way that backup and deluser won't need to be modified > to work properly in a system where non-priveleged mounts are allowed, > at least they will need to account for /share. > > That said it is clearly a hazard if we enable this functionality by > default. > > If we setup a pam module that triggers on login and perhaps when > cron and at jobs run to setup an additional mount namespace I think > keeping applications locked away in their own mount namespace is > sufficient to avoid hostile users from doing unexpected things to > the initial mount namespace. So unless I am mistake it should be > relatively simple to prevent user space from encountering problems. > > That still leaves the question of how we handle systems with an old > user space that is insufficiently robust to deal with mounts occurring > at unexpected locations. > > > I think a simple sysctl to enable/disable of non-priveleged mounts > defaulting to disabled is enough. > > Am I correct or will it be more difficult than just a little pam > module to ensure non-trusted users never run in the initial mount > namespace? I'm still not sure, what your problem is. With the v3 of the usermounts patchset, by default, user mounts are disabled, because the "allow unpriv submounts" flag is cleared on all mounts. There are several options available to sysadmins and distro builders to enable user mounts in a secure way: - pam module, which creates a private namespace, and sets "allow unpriv submounts" on the mounts within the namespace - pam module, which rbinds / onto /mnt/ns/$USER, and chroots into /mnt/ns/$USER, then sets the "allow unpriv submounts" on the mounts under /mnt/ns/$USER. - sysadmin creates /mnt/usermounts writable to all users, with sticky bit (same as /tmp), does "mount --bind /mnt/usermounts /mnt/usermounts" and sets the "allow unpriv submounts" on /mnt/usermounts. All of these are perfectly safe wrt userdel and backup (assuming it doesn't try back up /mnt). Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
"Serge E. Hallyn" <[EMAIL PROTECTED]> writes: >> >> Why are directory permissions not sufficient to allow/deny non-priveleged > mounts? >> I don't understand that contention yet. > > The same scenarios laid out previously in this thread. I.e. > > 1. user hallyn does mount --bind / /home/hallyn/root > 2. (...) > 3. admin does "deluser hallyn" > > and deluser starts wiping out root > > Or, > > 1. user hallyn does mount --bind / /home/hallyn/root > 2. backup daemon starts backing up /home/hallyn/root/home/hallyn/root/home... > > So we started down the path of forcing users to clone a new namespace > before doing user mounts, which is what the clone flag was about. Using > per-mount flags also suffices as you had pointed out, which is being > done here. But directory permissions are inadequate. Interesting So far even today these things can happen, however they are sufficiently unlikely the tools don't account for them. Once a hostile user can cause them things are more of a problem. > (Unless you want to tackle each problem legacy tool one at a time to > remove problems - i.e. deluser should umount everything under > /home/hallyn before deleting, backup should be spawned from it's own > namespace cloned right after boot or just back up on one filesystem, > etc.) I don't see a way that backup and deluser won't need to be modified to work properly in a system where non-priveleged mounts are allowed, at least they will need to account for /share. That said it is clearly a hazard if we enable this functionality by default. If we setup a pam module that triggers on login and perhaps when cron and at jobs run to setup an additional mount namespace I think keeping applications locked away in their own mount namespace is sufficient to avoid hostile users from doing unexpected things to the initial mount namespace. So unless I am mistake it should be relatively simple to prevent user space from encountering problems. That still leaves the question of how we handle systems with an old user space that is insufficiently robust to deal with mounts occurring at unexpected locations. I think a simple sysctl to enable/disable of non-priveleged mounts defaulting to disabled is enough. Am I correct or will it be more difficult than just a little pam module to ensure non-trusted users never run in the initial mount namespace? Eric - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
Quoting Eric W. Biederman ([EMAIL PROTECTED]): > Miklos Szeredi <[EMAIL PROTECTED]> writes: > > >> > That depends. Current patches check the "unprivileged submounts > >> > allowed under this mount" flag only on the requested mount and not on > >> > the propagated mounts. Do you see a problem with this? > >> > >> I think privileges of this sort should propagate. If I read what you > >> just said correctly if I have a private mount namespace I won't be able > >> to mount anything unless when it was setup the unprivileged submount > >> command was explicitly set. > > > > By design yes. Why is that a problem? > > It certainly doesn't match my intuition. > > Why are directory permissions not sufficient to allow/deny non-priveleged > mounts? > I don't understand that contention yet. The same scenarios laid out previously in this thread. I.e. 1. user hallyn does mount --bind / /home/hallyn/root 2. (...) 3. admin does "deluser hallyn" and deluser starts wiping out root Or, 1. user hallyn does mount --bind / /home/hallyn/root 2. backup daemon starts backing up /home/hallyn/root/home/hallyn/root/home... So we started down the path of forcing users to clone a new namespace before doing user mounts, which is what the clone flag was about. Using per-mount flags also suffices as you had pointed out, which is being done here. But directory permissions are inadequate. (Unless you want to tackle each problem legacy tool one at a time to remove problems - i.e. deluser should umount everything under /home/hallyn before deleting, backup should be spawned from it's own namespace cloned right after boot or just back up on one filesystem, etc.) -serge > I should probably go back and look and see how plan9 handles mount/unmount > permissions. Plan9 gets away with a lot more because it doesn't have > a suid bit and mount namespaces were always present, so they don't have > backwards compatibility problems. > > My best guess at the moment is that plan9 treated mount/unmount as > completely unprivileged and used the mount namespaces to limit the > scope of what would be affected by a mount/unmount operation. I think > that may be reasonable in linux as well but it will require the > presence of a mount namespace to limit the affects of what a user can > do. > > So short of a more thorough audit I believe the final semantics should > be: > - mount/unmount for non-priveleged processes should only be limited > by the mount namespace and directory permissions. > - CLONE_NEWNS should not be a privileged operation. > > What prevents us from allowing these things? > > - Unprivileged CLONE_NEWNS and unprivileged mounts needs resource > accounting so we don't have a denial of service attack. > > - Unprivileged mounts must be limited to directories that we have > permission to modify in a way that we could get the same effect > as the mount or unmount operation in terms of what files are visible > otherwise we can mess up SUID executables. > > - Anything else? > > There are user space issues such as a reasonable pam module and how > to do backups. However those are user space issues. > > What am I missing that requires us to add MNT_USER and MNT_USERMNT? > > Eric > - > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
Miklos Szeredi <[EMAIL PROTECTED]> writes: >> > That depends. Current patches check the "unprivileged submounts >> > allowed under this mount" flag only on the requested mount and not on >> > the propagated mounts. Do you see a problem with this? >> >> I think privileges of this sort should propagate. If I read what you >> just said correctly if I have a private mount namespace I won't be able >> to mount anything unless when it was setup the unprivileged submount >> command was explicitly set. > > By design yes. Why is that a problem? It certainly doesn't match my intuition. Why are directory permissions not sufficient to allow/deny non-priveleged mounts? I don't understand that contention yet. I should probably go back and look and see how plan9 handles mount/unmount permissions. Plan9 gets away with a lot more because it doesn't have a suid bit and mount namespaces were always present, so they don't have backwards compatibility problems. My best guess at the moment is that plan9 treated mount/unmount as completely unprivileged and used the mount namespaces to limit the scope of what would be affected by a mount/unmount operation. I think that may be reasonable in linux as well but it will require the presence of a mount namespace to limit the affects of what a user can do. So short of a more thorough audit I believe the final semantics should be: - mount/unmount for non-priveleged processes should only be limited by the mount namespace and directory permissions. - CLONE_NEWNS should not be a privileged operation. What prevents us from allowing these things? - Unprivileged CLONE_NEWNS and unprivileged mounts needs resource accounting so we don't have a denial of service attack. - Unprivileged mounts must be limited to directories that we have permission to modify in a way that we could get the same effect as the mount or unmount operation in terms of what files are visible otherwise we can mess up SUID executables. - Anything else? There are user space issues such as a reasonable pam module and how to do backups. However those are user space issues. What am I missing that requires us to add MNT_USER and MNT_USERMNT? Eric - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
> > > > > Also for bind-mount and remount operations the flag has to be > > > > > propagated > > > > > down its propagation tree. Otherwise a unpriviledged mount in a > > > > > shared > > > > > mount wont get reflected in its peers and slaves, leading to > > > > > unidentical > > > > > shared-subtrees. > > > > > > > > That's an interesting question. Do we want shared mounts to be > > > > totally identical, including mnt_flags? It doesn't look as if > > > > do_remount() guarantees that currently. > > > > > > Depends on the semantics of each of the flags. Some flags like of the > > > read/write flag, would not interfere with the propagation semantics > > > AFAICT. But this one certainly seems to interfere. > > > > That depends. Current patches check the "unprivileged submounts > > allowed under this mount" flag only on the requested mount and not on > > the propagated mounts. Do you see a problem with this? > > Don't see a problem if the flag is propagated to all peers and slave > mounts. > > If not, I see a problem. What if the propagated mount has its flag set > to not do un-priviledged mounts, whereas the requested mount has it > allowed? Then the mount is allowed. It is up to the sysadmin/distro to design set up the propagations in a way that this is not a problem. I think it would be much less clear conceptually, if unprivileged mounting would have to check propagations as well. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
On Mon, 2007-04-16 at 11:56 +0200, Miklos Szeredi wrote: > > > > Also for bind-mount and remount operations the flag has to be propagated > > > > down its propagation tree. Otherwise a unpriviledged mount in a shared > > > > mount wont get reflected in its peers and slaves, leading to unidentical > > > > shared-subtrees. > > > > > > That's an interesting question. Do we want shared mounts to be > > > totally identical, including mnt_flags? It doesn't look as if > > > do_remount() guarantees that currently. > > > > Depends on the semantics of each of the flags. Some flags like of the > > read/write flag, would not interfere with the propagation semantics > > AFAICT. But this one certainly seems to interfere. > > That depends. Current patches check the "unprivileged submounts > allowed under this mount" flag only on the requested mount and not on > the propagated mounts. Do you see a problem with this? Don't see a problem if the flag is propagated to all peers and slave mounts. If not, I see a problem. What if the propagated mount has its flag set to not do un-priviledged mounts, whereas the requested mount has it allowed? RP > > Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
> > That depends. Current patches check the "unprivileged submounts > > allowed under this mount" flag only on the requested mount and not on > > the propagated mounts. Do you see a problem with this? > > I think privileges of this sort should propagate. If I read what you > just said correctly if I have a private mount namespace I won't be able > to mount anything unless when it was setup the unprivileged submount > command was explicitly set. By design yes. Why is that a problem? Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
Miklos Szeredi <[EMAIL PROTECTED]> writes: > That depends. Current patches check the "unprivileged submounts > allowed under this mount" flag only on the requested mount and not on > the propagated mounts. Do you see a problem with this? I think privileges of this sort should propagate. If I read what you just said correctly if I have a private mount namespace I won't be able to mount anything unless when it was setup the unprivileged submount command was explicitly set. Eric - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
> > > Also for bind-mount and remount operations the flag has to be propagated > > > down its propagation tree. Otherwise a unpriviledged mount in a shared > > > mount wont get reflected in its peers and slaves, leading to unidentical > > > shared-subtrees. > > > > That's an interesting question. Do we want shared mounts to be > > totally identical, including mnt_flags? It doesn't look as if > > do_remount() guarantees that currently. > > Depends on the semantics of each of the flags. Some flags like of the > read/write flag, would not interfere with the propagation semantics > AFAICT. But this one certainly seems to interfere. That depends. Current patches check the "unprivileged submounts allowed under this mount" flag only on the requested mount and not on the propagated mounts. Do you see a problem with this? Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
On Mon, 2007-04-16 at 11:32 +0200, Miklos Szeredi wrote: > > > Given the existence of shared subtrees allowing/denying this at the > > > mount > > > namespace level is silly and wrong. > > > > > > If we need more than just the filesystem permission checks can we > > > make it a mount flag settable with mount and remount that allows > > > non-privileged users the ability to create mount points under it > > > in directories they have full read/write access to. > > > > Also for bind-mount and remount operations the flag has to be propagated > > down its propagation tree. Otherwise a unpriviledged mount in a shared > > mount wont get reflected in its peers and slaves, leading to unidentical > > shared-subtrees. > > That's an interesting question. Do we want shared mounts to be > totally identical, including mnt_flags? It doesn't look as if > do_remount() guarantees that currently. Depends on the semantics of each of the flags. Some flags like of the read/write flag, would not interfere with the propagation semantics AFAICT. But this one certainly seems to interfere. RP > Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
> > Given the existence of shared subtrees allowing/denying this at the > > mount > > namespace level is silly and wrong. > > > > If we need more than just the filesystem permission checks can we > > make it a mount flag settable with mount and remount that allows > > non-privileged users the ability to create mount points under it > > in directories they have full read/write access to. > > Also for bind-mount and remount operations the flag has to be propagated > down its propagation tree. Otherwise a unpriviledged mount in a shared > mount wont get reflected in its peers and slaves, leading to unidentical > shared-subtrees. That's an interesting question. Do we want shared mounts to be totally identical, including mnt_flags? It doesn't look as if do_remount() guarantees that currently. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
> > "Serge E. Hallyn" <[EMAIL PROTECTED]> writes: > > > Quoting Miklos Szeredi ([EMAIL PROTECTED]): > >> From: Miklos Szeredi <[EMAIL PROTECTED]> > >> > >> If CLONE_NEWNS and CLONE_NEWNS_USERMNT are given to clone(2) or > >> unshare(2), then allow user mounts within the new namespace. > >> > >> This is not flexible enough, because user mounts can't be enabled > for > >> the initial namespace. > >> > >> The remaining clone bits also getting dangerously few... > >> > >> Alternatives are: > >> > >> - prctl() flag > >> - setting through the containers filesystem > > > > Sorry, I know I had mentioned it, but this is definately my least > > favorite approach. > > > > Curious whether are any other suggestions/opinions from the > containers > > list? > > Given the existence of shared subtrees allowing/denying this at the > mount > namespace level is silly and wrong. > > If we need more than just the filesystem permission checks can we > make it a mount flag settable with mount and remount that allows > non-privileged users the ability to create mount points under it > in directories they have full read/write access to. Also for bind-mount and remount operations the flag has to be propagated down its propagation tree. Otherwise a unpriviledged mount in a shared mount wont get reflected in its peers and slaves, leading to unidentical shared-subtrees. RP > > I don't like the use of clone flags for this purpose but in this > case the shared subtress are a much more fundamental reasons for not > doing this at the namespace level. > > Eric > ___ > Containers mailing list > [EMAIL PROTECTED] > https://lists.linux-foundation.org/mailman/listinfo/containers - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
