Rust 1.58.1 released

While that is *less* problematic than limiting symlinks to root, I am still certain that would break some cases where I have used symlinks in practice. Perhaps we could just leave symlinks *alone* and fix the buggy applications instead?

For example: Say I have "$HOME/bin" symlinked to "$HOME/.local/bin" (true story) and I want to run a script located, according to the $PATH variable, at "$HOME/bin/somescript" as root via sudo. Your scheme breaks this since the bin → .local/bin symlink was created by my non-root user and needs to be followed by root to execute the script. Or more generally—say I just want to run a command as root on some file which has a symlink (which I created) somewhere in its path. Or perhaps I have versioned directories with a "latest" symlink and I want to share the path to the latest version with another user. These are all perfectly legitimate, real-world use cases which absolutely depend on the ability to create symlinks as a non-root user which will be followed by other users.

Or perhaps I totally fail to understand. (Likely I do, becasue that position seems incoherent.)

Hmm. systemd user services exist. GNOME is already using it by default and KDE, other projects are looking into this as well. So I am not sure how admin only symlinks are viable.

I'm using symlinks in all my projects in C++ to link build directories into the build cache, for example. And to link RPC schemas from a central module into consumers. There are no problems with symlinks when they are done within the same permission boundary.

Perhaps Samba should stop abusing the filesystem for its file server access control needs and grow its own storage?

The same symlink-based interfaces systemd uses for system-level configuration are also used for user sessions and user services with configuration files and symlinks under ~/.config/systemd/user/, which are meant to be controlled by regular users, not admins. Remove the symlinks and you break KDE and Gnome login sessions, among other things. Besides systemd, Chrome and Firefox both keep symlinks in their configuration directories. Stack uses them in its versioned GHC installation. Steam needs them for its runtime (libraries, among other things). Wine uses symlinks in its user configuration directories (for drive letters, among other things). And of course there are many other less notable examples. All of these programs need symlinks which can be created and edited by ordinary users in their home directories.

>> Symlinks also appear in essential roles in core interfaces like /sys.
> /sys then is a filesystem that allows symlinks.

You can't usefully distinguish between filesystems which allow symlinks and filesystems which do not (for security reasons). /sys is well-bounded but your Samba shares may well be on the same filesystem as users' home directories, and you can't realistically limit symlinks there. Or in /etc (e.g. the Debian /etc/alternatives/ system is all based on symlinks, as is sysvinit for packages still using that). Or in the root (/bin -> /usr/bin) or in /usr (alternatives, aliased commands). And let's not forget the home directories, which are commonly exported as Samba shares. So Samba will just have to deal with it and support symlinks properly no matter where they may be found.

> Can't be done by mortal developers.

The fact that this issue in the Rust standard libraries has been resolved says otherwise. No one can guarantee perfectly bug-free code, of course, but it *is* possible to handle symlinks correctly. This CVE was never really a symlink issue in the first place. The minor symlink issue was easily dealt with in the original code by not following symlinks to directories. That part worked fine in a single-user, unshared environment. However, you can't just say "if (is_symlink(path)) { unlink(path); } else { recurse(path); }" in a shared filesystem without accounting for the fact that the entry at "path" can change. This is basic concurrency, made worse by the fact that you're sharing state with less privileged code. The same kind of bug could easily occur in other areas having nothing to do with symlinks, such as access checks. Developers have all the tools needed to avoid this issue (openat, fstat, unlinkat, fdopendir), at least on Linux—they just need to use them. As the new implementation does.