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: Tue, 22 Aug 2006 10:04:03 +0800 (WST) From: Ian Kent <raven@...maw.net> To: David Howells <dhowells@...hat.com> cc: Andrew Morton <akpm@...l.org>, Trond Myklebust <trond.myklebust@....uio.no>, linux-kernel@...r.kernel.org, aviro@...hat.com Subject: Re: [PATCH] NFS: Replace null dentries that appear in readdir's list [try #2] On Mon, 21 Aug 2006, David Howells wrote: OK. I think I get it now. Thanks for your patience. > Ian Kent <raven@...maw.net> wrote: > > > > But does it _matter_ that the thing is mounted or dismounted as a unit? And > > > if so, why? > > > > Yes with autofs version 4, because of the nesting of mounts which also > > introduces issues with expiration. > > The NFS client's automounting facilities handle automatic expiration and > implicit recursive unmounting of xdev submounts. Very cool. I guess I'm not concerned about what the expire timeout is for such trees either as it's not my problem. I'll have to play around with these a bit to work out how I can recognize them in the export list. Hopefully it will be straight forward. > > This should now be left to the NFS client. Yep. > > > Not updating the mtab will be a problem for me also and possibly for > > users that expect to see mounts in it. > > ln -sf /proc/mounts /etc/mtab > > > The "/net" functionality is a standard, expected automounter function. > > Whilst that may be true, it doesn't prohibit working with the NFS clients > automounting capabilities. Yep. Again, not my problem if I treat fsid filesets as the automount unit. > > > > Note that rather than manually mounting the submounts, you could just open > > > and close those directories as that should cause them to automount - > > > though the xdev mountpoints will expire and become automatically unmounted > > > after a certain period. > > > > The xdev (assume you mean NFSv4 submounts) mounts will be the area I need > > to work on, for sure. > > I mean NFSv2, NFSv3 and NFSv4 submounts that cross FSID, but remain on the > same server. > > > I don't quite understand the "open will cause the automount" for NFS > > version < 4. > > Opening the directory will cause its follow_link() op to be invoked, which > will cause an automount if one hasn't already happened. Obviously, if the > automount has taken place, the lower directory won't be seen for the follow to > take place. Yep. But also not my problem as user activity will make this happen automagically. > > > The automounter calls mount(8) when it gets a packet from the > > autofs[4] kernel module due to an access. > > The automounter must mount the root of any tree, yes; but xdev subtrees should > now be left to the NFS client to mount, which can be triggered by stat'ing the > mountpoint - admittedly, if you can reach it without a security error. > > If you do get a security error, and attempt to build the directories anyway, > you run the risk of constructing a false image of the remote share as you > can't tell symlinks from directories, and run the risk of creating invalid > dentries locally because you can't determine the attributes of the remote > object. Yep. No use in stepping on NFSs toes when he just wants to make my life easier for me. Ian - 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