Re: silent semantic changes with reiser4

[Jamie Lokier]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/