From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: silent semantic changes with reiser4 Date: Thu, 26 Aug 2004 19:16:20 +0100 Message-ID: <20040826181620.GT5733@mail.shareable.org> References: <20040825205149.GA17654@lst.de> <412DA2CF.2030204@namesys.com> <20040826124119.GA431@lst.de> <20040826134812.GB5733@mail.shareable.org> <20040826155744.GA4250@lst.de> <20040826160638.GJ5733@mail.shareable.org> <20040826161303.GA4716@lst.de> <20040826172029.GP5733@mail.shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Christoph Hellwig , Hans Reiser , Alex Zarochentsev , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Alexander Lyamin aka FLX , ReiserFS List Return-path: list-help: list-unsubscribe: list-post: Errors-To: flx@namesys.com To: Linus Torvalds Content-Disposition: inline In-Reply-To: List-Id: linux-fsdevel.vger.kernel.org Linus Torvalds wrote: > > -> the setuid program thus ends up opening a device or fifo, > > when it does pwd's path walk. Yes it could use the getcwd > > syscall, but some programs do their own path walk. > > .. but even if it did that, it should use O_DIRECTORY when it did so. If > it doesn't, it's broken. Didn't someone just say that O_DIRECTORY will succeed on a device, precisely because opendir() is supposed to succeed on the device? I'm not sure. Let me refresh my memory. Linus Torvalds wrote: > And it would be perfectly ok for O_DIRECTORY to open such a file, as long > as it opens the directory branch, not the special device. Oh, I see. You're right. ".." sees the path of directory branches. > > It also fits the container idea very well: > > > > /dev/hda/part1/ <- the filesystem inside partition 1 > > I don't think you can do that. The kernel has no idea how to mount the > filesystem. It is not the kernel which decides. The filesystem containing /dev/hda/part1 opens "the directory branch". If the filesystem is suitably configured, it's exactly the same as opening a .zip or ELF file: it asks userspace for help. Userspace helps by either mounting it, or creating a container virtual directory -- in exactly the same way it helps with .zip and ELF files by creating a container virtual directory for those. It would mount it if the kernel supports the fs, and create a virtual directory if the kernel doesn't support the fs and userspace does. This is exactly the same as when you cd into a filesystem image: the helper mounts (this time with a lookback file mount) if the kernel supports the image fs, otherwise the helper may be able to decode it in userspace. By the way, these mechanisms could allow some of the old filesystems that nobody uses any more to be removed from the kernel altogether and kept in an archive of userspace-only supported filesystems. What do you think of that idea? > If it's already mounted somewhere else, that's a different issue. > Although it might be mounted in several places (as a bind mount) with > different writability, I guess, so even then it might be "interesting". The obvious implementation has the userspace helper just mounting it, end of story. If the mount command fails, it fails. Much like autofs. -- Jamie