lkml.org 
[lkml]   [2007]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Thinking outside the box on file systems
    alan wrote:
    > Imagine the fun you will have trying to write a file name and being told
    > you cannot write it for some unknown reason. Unbeknownst to you, there
    > is a file there, but it is not owned by you, thus invisible.

    This jumped out at me right away. In such a system, an attacker with
    write permissions on a "sticky" directory like /tmp could probe for
    others' files by attempting to create them and recording all cases where
    permission was denied due to an existing, hidden file. But of course,
    this was just an example of something a less UNIX-y permission scheme
    could do, not a key part of such a design.

    Personally, what I'd like to see is a better way of dealing with
    propagation of ownership. Currently, in order to allow "collaboration"
    directories where a directory tree is owned by a certain group and
    anyone in that group can write and create files, one has to change the
    system umask, use a magical bit on the collaboration directory to
    propagate group ownership, and create a group for every user on the
    system in order to keep their personal files safe with the new umask.
    This seems highly flawed. I suggest that propagation of group ownership
    should be the default mode, not a special one, and that the
    group-writable permissions should also be propagated to new files and
    directories. This way, the user's home directory would remain 0755,
    while the collaboration directory could be 0775, without any changing of
    umasks.

    Of course, this would go against tradition, and cause some mayhem in the
    logic responsible for magically determining permissions for new files,
    but since we're talking about thinking outside of the box, I think
    that's excusable :)

    -- m. tharp
    -
    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: 2007-08-15 15:15    [W:0.023 / U:0.776 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site