On 01/30/2017 07:22 PM, Michael Orlitzky wrote:
> On 01/30/2017 01:05 PM, Patrick McLean wrote:
>>
>> No, that is also enabled by default on vanilla kernels, I just verified
>> on my machine running a vanilla kernel. It doesn't matter anyway, since
>> the permissions and ownership information is stored in the inode, not
>> the dentry so all hardlinks have exactly the same permissions.
>>
> 
> I don't believe you =P
> 
> Check https://github.com/torvalds/linux/blob/master/fs/namei.c:
> 
>   int sysctl_protected_symlinks __read_mostly = 0;
>   int sysctl_protected_hardlinks __read_mostly = 0;
> 
> And compare with:
> 
> https://gitweb.gentoo.org/proj/linux-patches.git/tree/1510_fs-enable-link-security-restrictions-by-default.patch?h=4.9
> 
> The fact that all permission and ownership information is shared is
> precisely the problem. When you change ownership of the hardlink (which
> you'll never know is a hardlink), you change ownership of /etc/shadow.
> 
> 

To provide some background for this, it was included in mainstream
kernel at one point but caused userland regression in some edge cases so
was removed again.

It is already discussed at least on [0] and it seems the behavior was
turned the other way around in [1]: "In commit 800179c9b8a1 ("This adds
symlink and hardlink restrictions to
the Linux VFS"), the new link protections were enabled by default, in
the hope that no actual application would care, despite it being
technically against legacy UNIX (and documented POSIX) behavior.

However, it does turn out to break some applications.  It's rare, and
it's unfortunate, but it's unacceptable to break existing systems, so
we'll have to default to legacy behavior.
"

You'll find some more discussion around this in e.g [bug 540006]

References:
[0] http://lwn.net/Articles/521626/
[1] http://www.spinics.net/lists/stable-commits/msg21052.html
[bug 540006] https://bugs.gentoo.org/show_bug.cgi?id=540006

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to