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. In particular, it has broken the way AFD distributes files, see http://www.dwd.de/AFD/ along with some legacy scripts. Distributions can end up setting this at initrd time or in system scripts: if you have security problems due to link attacks during your early boot sequence, you have bigger problems than some kernel sysctl setting. Do: echo 1 > /proc/sys/fs/protected_symlinks echo 1 > /proc/sys/fs/protected_hardlinks to re-enable the link protections. Alternatively, we may at some point introduce a kernel config option that sets these kinds of "more secure but not traditional" behavioural options automatically.
Unified · Split
| @@ -705,8 +705,8 @@ static inline void put_link(struct nameidata *nd, struct path *link, void *cooki · 704 unmodified lines | |||
| 705 | path_put(link); | 705 | path_put(link); |
| 706 | } | 706 | } |
| 707 | 707 | ||
| 708 | int sysctl_protected_symlinks __read_mostly = 1; | 708 | int sysctl_protected_symlinks __read_mostly = 0; |
| 709 | int sysctl_protected_hardlinks __read_mostly = 1; | 709 | int sysctl_protected_hardlinks __read_mostly = 0; |
| 710 | 710 | ||
| 711 | /** | 711 | /** |
| 712 | * may_follow_link - Check symlink following for unsafe situations | 712 | * may_follow_link - Check symlink following for unsafe situations |