lkml.org 
[lkml]   [2009]   [Oct]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: symlinks with permissions (fwd)
    Pavel Machek wrote:
    > (I forgot to cc the list)
    >
    > From: Pavel Machek <pavel@ucw.cz>
    > To: "Eric W. Biederman" <ebiederm@xmission.com>
    > Subject: Re: symlinks with permissions
    > X-Warning: Reading this can be dangerous to your mental health.
    >
    > Hi!
    >
    >
    >>>>> Part of the problem is that even if you have read-only
    >>>>> filedescriptor, you can upgrade it to read-write, even if path is
    >>>>> inaccessible to you.
    >>>>>
    >>>>> So if someone passes you read-only filedescriptor, you can still write
    >>>>> to it.
    >>>>>
    >>>> Openly if you actually have permission to open the file again. The actual
    >>>> permissions on the file should not be ignored.
    >>>>
    >>> The actual permissions of the file are not ignored, but permissions of
    >>> the containing directory _are_. If there's 666 file in 700 directory,
    >>> you can reopen it read-write, in violation of directory's 700
    >>> permissions.
    >>>
    >> I can see how all of this can come as a surprise. However I don't see
    >> how any coder who is taking security seriously and being paranoid about
    >> security would actually write code that would have a problem with this.
    >>
    >> Do you know of any cases where this difference matters in practice?
    >>
    >
    > Actually yes, see the bugtraq post. guest was able to write to my file
    > when I expected that file to be protected.
    >
    > According to the bugtraq discussion, people expect directory
    > permissions to work.

    Gawd, I hate to say this, but people have been improperly educated
    if they expect directory permissions to behave thusly. You can not
    count on the permissions on a directory to protect access on a file
    that the directory contains a reference to. Hard links. Mount points.
    /proc/8675309/fd. Passing file descriptors over sockets. Fork, for
    heaven's sake. That's not how Linux directories really work.


    > /proc currently breaks that. I bet there are few
    > systems in the wild that have permissions set up like that, but it is
    > not easy to actually find such systems.
    >
    > Better fix it...
    > Pavel
    >


    Well, /proc/8675309/fd is a silly notion, but it's been around
    long enough that you are going to have trouble getting rid of it
    and doing so wouldn't solve the "problem" in any case.



    \
     
     \ /
      Last update: 2009-10-29 06:09    [W:0.029 / U:2.184 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site