[lkml]   [2006]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Security issues with local filesystem caching
    Al Viro <> wrote:

    > > > Currently, CacheFiles temporarily changes fsuid and fsgid to 0 whilst
    > > > doing its own pathwalk through the cache and whilst creating files and
    > > > directories in the cache. This allows it to deal with DAC security
    > > > directly. All the directories it creates are given permissions mask
    > > > 0700 and all files 0000.
    > >
    > > That seems sensible and fine. It is precisely why we added a separate
    > > fsuid in the first place so that the user space nfsd could take on an fs
    > > identity without breaking signal and other security based forms.
    > I see a problem with that; not sure if that's what Christoph is objecting
    > to. What about access to cache tree by root process that has nothing
    > to do with that daemon? Should it get free access to that stuff, regardless
    > of what policy might say about access to cached files? Or should we at
    > least try to make sure that we have the instances in cache no more permissive
    > than originals on NFS?

    Well, if the data is being copied to where userspace can get at it, and if MAC
    is disabled, then it doesn't matter: root can always gain access if it wants
    to, no matter what the DAC-related attributes are.

    I'm quite happy to attach security data to the files in the cache, and use MAC
    if it's available, but most of the time, it can't be the MAC-related attributes
    of the process in who's context we're running.

    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: 2006-10-26 12:49    [W:0.019 / U:6.032 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site