lkml.org 
[lkml]   [2005]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: -mm -> 2.6.13 merge status (fuse)
    From
    Date
    > But the problem you're addressing here largely revolves around the fact that
    > the filesystem implementation is a userspace process which is potentially
    > owned by a different user. So you need to prevent the mount owner from
    > peeking at the fs user's activity. That problem is unique to FUSE and so a
    > solution within fuse is appropriate.

    It's in fact not so unique to FUSE. It would equally well apply to
    v9fs or even samba, since both want to allow unprvileged mounts, and
    synthetic (or at least user-controlled) file serving.

    > This security feature doesn't sounds terribly important to me. So the fuse
    > server can find out what files I'm looking at. But I've already
    > deliberately given the fuse server the ability to ptrace my process?

    If it's deliberate, than OK.

    However with suid/sgid, this is not a deliberate action of the user
    under whose capabilities the process runs. Neither in the case, when
    it's a daemon doing some recursive directory traversal.

    And it's not just peeking at the filesystem access patterns. A much
    more dangerous aspect is controlling _when_ an operation returns
    (e.g. delaying it forever), and _what_ it returns (e.g. huge
    files/directories).

    Of course, this is only truly relevant for systems with untrusted
    users. But I do want to make FUSE work securely in those cases too.

    For the single user system, the sysadmin can turn this feature off,
    and be done with it.

    > Can we enhance private namespaces so they can squash setuid/setgid? If so,
    > is that adequate?

    We could. But that would again be overly restrictive. The goal is to
    make the use of FUSE filesystems for users as simple as possible. If
    the user has to manage multiple namespaces, each with it's own
    restrictions, it's becoming a very un-user-friendly environment.

    Thanks,
    Miklos
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-06-22 11:19    [W:0.023 / U:61.352 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site