lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 18 Apr 2007 17:06:33 +0200 From: Miklos Szeredi <miklos@...redi.hu> To: trond.myklebust@....uio.no CC: ebiederm@...ssion.com, serue@...ibm.com, linuxram@...ibm.com, linux-fsdevel@...r.kernel.org, viro@....linux.org.uk, containers@...ts.osdl.org, akpm@...ux-foundation.org, linux-kernel@...r.kernel.org Subject: 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-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists