| 1 |
On 01/30/2017 07:22 PM, Michael Orlitzky wrote: |
| 2 |
> On 01/30/2017 01:05 PM, Patrick McLean wrote: |
| 3 |
>> |
| 4 |
>> No, that is also enabled by default on vanilla kernels, I just verified |
| 5 |
>> on my machine running a vanilla kernel. It doesn't matter anyway, since |
| 6 |
>> the permissions and ownership information is stored in the inode, not |
| 7 |
>> the dentry so all hardlinks have exactly the same permissions. |
| 8 |
>> |
| 9 |
> |
| 10 |
> I don't believe you =P |
| 11 |
> |
| 12 |
> Check https://github.com/torvalds/linux/blob/master/fs/namei.c: |
| 13 |
> |
| 14 |
> int sysctl_protected_symlinks __read_mostly = 0; |
| 15 |
> int sysctl_protected_hardlinks __read_mostly = 0; |
| 16 |
> |
| 17 |
> And compare with: |
| 18 |
> |
| 19 |
> https://gitweb.gentoo.org/proj/linux-patches.git/tree/1510_fs-enable-link-security-restrictions-by-default.patch?h=4.9 |
| 20 |
> |
| 21 |
> The fact that all permission and ownership information is shared is |
| 22 |
> precisely the problem. When you change ownership of the hardlink (which |
| 23 |
> you'll never know is a hardlink), you change ownership of /etc/shadow. |
| 24 |
> |
| 25 |
> |
| 26 |
|
| 27 |
To provide some background for this, it was included in mainstream |
| 28 |
kernel at one point but caused userland regression in some edge cases so |
| 29 |
was removed again. |
| 30 |
|
| 31 |
It is already discussed at least on [0] and it seems the behavior was |
| 32 |
turned the other way around in [1]: "In commit 800179c9b8a1 ("This adds |
| 33 |
symlink and hardlink restrictions to |
| 34 |
the Linux VFS"), the new link protections were enabled by default, in |
| 35 |
the hope that no actual application would care, despite it being |
| 36 |
technically against legacy UNIX (and documented POSIX) behavior. |
| 37 |
|
| 38 |
However, it does turn out to break some applications. It's rare, and |
| 39 |
it's unfortunate, but it's unacceptable to break existing systems, so |
| 40 |
we'll have to default to legacy behavior. |
| 41 |
" |
| 42 |
|
| 43 |
You'll find some more discussion around this in e.g [bug 540006] |
| 44 |
|
| 45 |
References: |
| 46 |
[0] http://lwn.net/Articles/521626/ |
| 47 |
[1] http://www.spinics.net/lists/stable-commits/msg21052.html |
| 48 |
[bug 540006] https://bugs.gentoo.org/show_bug.cgi?id=540006 |
| 49 |
|
| 50 |
-- |
| 51 |
Kristian Fiskerstrand |
| 52 |
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net |
| 53 |
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 |
Archives