11–20 of 126 posts
This is a feature in the same way that shellsock was used as a feature for many years by experts. Thankfully I'm expecting something like POSIX to save us this time.
"X is fundamentally broken" is a tired trope. To me, something is broken if it is no longer working as intended. It used to work, but now it does not - it is broken. If something works as intended, but its utility is limited, and it can be improved, it is not broken.
Symlinks work as intended, but they cause a lot of unintended security vulnerabilities, i.e. they break lots of otherwise-functioning code. You can play with your words and redefine their meanings, but the vulnerabilities remain.
No, bad coders on UNIX platforms do this.
The code may be valid code, but if it's intending to support running on UNIX it should do it properly not assuming it's on a FAT32 filesystem in 2022.
Or, even better, run the code you don't trust on fat32 filesystems, see how far that gets.
Interestingly, Windows actually did exactly what's proposed at the end when MS added them in Vista. To minimize the security issues with symlinks, you had to elevate to admin to create them. It was only during the life of Windows 10 that they even added the option to not have to elevate to create them. It was done specifically because symlinks are often shared across systems since they end up in places like git repos…
Earlier quoted context omitted.
Symlinks work as intended, but they cause a lot of unintended security vulnerabilities, i.e. they break lots of otherwise-functioning code. You can play with your words and redefine their meanings, but the vulnerabilities remain.
> but they cause a lot of unintended security vulnerabilities No, bad coders on UNIX platforms do this. The code may be valid code, but if it's intending to support running on UNIX it should do it properly not assuming it's on a FAT32 filesystem in 2022. Or, even better, run the code you don't trust on fat32 filesystems, see how far that gets.
Do you really think that using open(), stat(), lstat() (!), realpath(), mkdir(), rename() etc etc etc is a sign of a bad coder? The problem is that the APIs set you up for unexpected failure, and even some of the provided workarounds to 'safely' handle symlinks don't do it well enough.
In the case of symlinks, I think it's fair to blame the tools rather than the workman.
Earlier quoted context omitted.
Symlinks work as intended, but they cause a lot of unintended security vulnerabilities, i.e. they break lots of otherwise-functioning code. You can play with your words and redefine their meanings, but the vulnerabilities remain.
> but they cause a lot of unintended security vulnerabilities No, bad coders on UNIX platforms do this. The code may be valid code, but if it's intending to support running on UNIX it should do it properly not assuming it's on a FAT32 filesystem in 2022. Or, even better, run the code you don't trust on fat32 filesystems, see how far that gets.
Programmers aren't using them because the language standard libraries point them in the wrong direction.
[0] https://github.com/google/guava/wiki/Release21#user-content-... [1] https://github.com/rust-lang/rust/blob/1c63ec48b8cbf553d291a...
I think that in a hypothetical world where symlinks worked like hard links, we'd be swapping out the security complaints in this post for articles about how hard it is to upgrade a POSIX system properly, tools and tricks you can use to make sure you truly replaced all instances of a binary with a known vulnerability, and so on.
Interestingly, Windows actually did exactly what's proposed at the end when MS added them in Vista. To minimize the security issues with symlinks, you had to elevate to admin to create them. It was only during the life of Windows 10 that they even added the option to not have to elevate to create them. It was done specifically because symlinks are often shared across systems since they end up in places like git repos…
You could create symlinks since Windows Vista without permission elevation, if having disabled the UAC ("User Account Control").
There doesn't seem to be a way to batch together operations that involve walking through directories and symlinks to do something to a file. This seems to be a major source of complexity.
I always thought Unix v7+ should have added some kind way to do atomic groups of syscalls, eg: begin_transaction (); lstat ("/path", ...); lstat ("/path/foo", ...); commit (); In Unix v7 mkdir was not a system call. It was a setuid program implemented using mknod + link. That was racy so the mkdir(2) system call was added. But it could have been solved more generally (and more elegantly) by adding transactions. It co…
Earlier quoted context omitted.
> but they cause a lot of unintended security vulnerabilities No, bad coders on UNIX platforms do this. The code may be valid code, but if it's intending to support running on UNIX it should do it properly not assuming it's on a FAT32 filesystem in 2022. Or, even better, run the code you don't trust on fat32 filesystems, see how far that gets.
Part of the problem is that handles on directories on which one can then use the the *at family of syscalls are not first-class citizens in many programming languages. Which in turn might be due to portability concerns with windows, e.g. Java's SecureDirectoryStream isn't available there[0]. Apparently windows does have an openat-like API[1], but it's low-level. Programmers aren't using them because the language stan…
There doesn't seem to be a way to batch together operations that involve walking through directories and symlinks to do something to a file. This seems to be a major source of complexity.
I always thought Unix v7+ should have added some kind way to do atomic groups of syscalls, eg: begin_transaction (); lstat ("/path", ...); lstat ("/path/foo", ...); commit (); In Unix v7 mkdir was not a system call. It was a setuid program implemented using mknod + link. That was racy so the mkdir(2) system call was added. But it could have been solved more generally (and more elegantly) by adding transactions. It co…