[lkml]   [2004]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: silent semantic changes with reiser4
    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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:05    [W:2.907 / U:0.780 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site