[lkml]   [2009]   [Oct]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: symlinks with permissions (fwd)
Pavel Machek wrote:
> (I forgot to cc the list)
> From: Pavel Machek <>
> To: "Eric W. Biederman" <>
> 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    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean