[lkml]   [2004]   [Sep]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: silent semantic changes with reiser4
    On Fri, Sep 10, 2004 at 03:22:59PM -0400, Timothy Miller wrote:
    > Linus Torvalds wrote:
    > >The same goes for something like a "container file". Whether you see it as
    > >"dir-as-file" or "file-as-dir" (and I agree with Jan that the two are
    > >totally equivalent), the point of having the capability in the kernel is
    > >not that the operations cannot be done in user space - the point is that
    > >they cannot be done in user space _safely_. The kernel is kind of the
    > >thing that guarantees that everybody follows the rules.
    > Well, it CAN be done safely if every client has to go through the kernel
    > which does all the appropriate locks/semaphors and then passes the
    > request down to the daemon. (Isn't NFS implemented this way?)
    > This is very micro-kernel-ish, but it's a reasonable idea to do it this
    > way in cases where things are non-critical.
    > Say there's a way to cd into a tgz file to look around. If the access
    > methods through the kernel get routed back to a user-space process
    > (which probably does some amount of caching in memory and on disk of
    > uncompressed bits of the archive), it could be a bit slower than if it
    > were all in-kernel. The thing is that the processing time in the daemon
    > is probably quite high compared to the overhead of the context switches,
    > so it doesn't cost much. (And if it CAN be done in userspace without
    > being horribly convoluted or unsafe, then it SHOULD be done in
    > userspace.) Besides, even if it were a LOT slower to access a tgz file
    > without extracting it first, I would STILL think it was wonderful AND
    > use it a LOT.

    This is only safe for some limited definitions of safety.

    Leaving aside the obvious complexities of making sure the user space
    daemon doesn't just do something crazy, you have a number of problems:

    * Which user does the daemon run as? If it runs as root, it needs to
    enforce strict security requirements in terms of VFS operations coming
    in, and also, it has all the problems of a SUID application running on
    an arbitrary user file. I don't know about you, but I don't trust
    joebob's tarfsd to be suid when running on some script kiddie tarball.

    If it runs as the user making the request, then what happens when two
    users try to open the same file at the same time. Do they see two
    different views of the file? Is one of them locked out? How can they
    possibly synchronize if the views are writable?

    * If the daemon runs as a user, then what happens if you try to run a
    suid program inside of the view? What if root tries to walk into a
    tar file? The conservative view is that the kernel would need to
    always return ENOENT for any process with elevated capabilities, but
    even this is not safe.

    * Consider what happens if foo.tar/blah_blah is automatically bound to
    enter a tarfsd view of foo.tar. What happens if I point the web
    server at foo.tar/blah? The web server runs as httpd or something, so
    presumably httpd ends up running some sort of tarfsd view on the
    file. But if the tarball was made by a malicious person, presumably
    it can obtain httpd user access now by exploiting a bug in tarfsd.

    * Even if you assume the view is read-only and the kernel coerces all
    permissions and ownership and such, there's the possibility of tarfsd
    presenting unexpected syscall results - weird error codes, short
    reads, file data changing underneath mmap, etc. that user applications
    don't expect and may be susceptible to.

    * Besides all these security issues, if this scheme is writable it has
    all the resource problems that loopback network filesystems suffer.
    What if the kernel is short on memory and tries to flush dirty buffers
    to reclaim it. If those buffers are running against the user FS
    daemon, then that daemon must wake up to clear dirty buffers. If it
    tries to allocate memory, deadlock in the kernel.

    Probably the security problems can be solved to some degree by being
    very paranoid in the kernel (at an associated loss in utility), and the
    resource issues can be solved by restricting dirty buffers for loopback
    mounts (at an associated loss in performance), but it's hardly simple.


    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:06    [W:0.026 / U:174.352 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site