[lkml]   [2006]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Security issues with local filesystem caching
    On Wed, Oct 25, 2006 at 11:14:16AM +0100, David Howells 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.

    Unionfs used to do the same thing, until we decided that it was better to do
    it some other way. (We went with a work queue approach.)

    Hrm. How do you do DAC checks if you don't copy over the permissions without

    I'm wondering, why don't just you duplicate all the attributes of the files
    (including xattrs)? That would take care of most if not all the DAC/MAC
    issues, no?

    > I can see a few ways to deal with this:
    > (1) Do all the cache operations in their own thread (sort of like knfsd).

    In our case it works well, however we have only very specific times when we
    need to use the work queue, so the performance hit doesn't hurt us as much
    as it would hurt you - I'm assuming you'd be using the thread for a sizable
    portion of calls you get.

    > (2) Add further security ops for the caching code to call. These might be of
    > use elsewhere in the kernel. These would set cache-specific security
    > labels and check for them.

    I'm thinking that it would be nice to combine the caching related security
    code with those for stackable filesystems. I realize that there may not
    really be many things that need to have LSM hooks, but stackable filesystems
    should be something to keep in mind now that ecryptfs is in (and hopefully
    Unionfs will follow shortly :) ). The SELinux guys would probably know
    what's needed.

    > (3) Add a flag or something to current to override the normal security on the
    > basis that it should be using the cache's security rather than the
    > process's security.

    Umm...this sounds little bit too hacky (and a fair amount of code would have
    to get changed.) I'd prefer a more general solution that applies to more
    than just caching.

    Josef "Jeff" Sipek.

    *NOTE: This message is ROT-13 encrypted twice for extra protection*
    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-25 22:27    [W:4.037 / U:0.180 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site