|
|
Subscribe / Log in / New account

The trouble with symbolic links

The trouble with symbolic links

Posted Jul 8, 2022 10:16 UTC (Fri) by tialaramex (subscriber, #21167)
In reply to: The trouble with symbolic links by Hello71
Parent article: The trouble with symbolic links

"SUID is profoundly broken" I find a lot easier to get behind than "symbolic links are the problem".

One of the things I appreciate in Rust is that where there are special cases somebody takes the time to think about whether in fact there's some more general principle of which the special case was just the easy to observe part, the tip of the iceberg so to say, and to provide for the general principle, rather than just the special case.

Example: If you're a Rust beginner you learn that Option's None and Result's Error can be passed back up to your caller where appropriate with the '?' try operator and this seems like a special case, you can't go around treating an integer, or a file handle, or some other kind of thing this way. Or can you? In fact the general principle is the (nightly gated) Try trait, and Option and Result merely implement Try (they're allowed to do this even in stable Rust because Rust internally isn't subject to its own stability rules or it'd be recursively impossible to develop anything)

Another example: In languages with ad hoc polymorphism ("Function overloading") it's obvious that "LWN.net".contains("LWN") and "LWN.net".contains('.') are both reasonable things to write so you just overload the function to do either. Rust doesn't have ad hoc polymorphism, so it must decide what type that parameter is such that both "LWN" and '.' match or else provide two functions with different names. The resulting trait Pattern once again represents a more general principle - any pattern which could match parts of a string, and so in Rust you can also write "LWN.net".contains(char::is_alphabetic) because hey, char::is_alphabetic is a function which matches parts of a string so why not.

I think SUID just isn't one of those things, it's a profoundly special case, and so we should immediately be prejudiced against it as a design feature of the operating system. Rather than everything just falling out naturally, as we'd like for a general solution, SUID means everywhere we need to handle this differently. If you've just written a bunch of low level code there's a good chance that if I remind you that SUID exists you'll need to go back and add a bunch of conditional branches to handle that...


to post comments

The trouble with symbolic links

Posted Jul 8, 2022 11:25 UTC (Fri) by farnz (subscriber, #17727) [Link] (1 responses)

Another reason to be biased against SUID is that it's a quick solution to the problem of users not having root access to the entire machine.

There are three different ways to run something as root on a Linux-like system (assuming that you've got an ordinary user account):

  1. Get someone to log in as root and run the command directly for you.
  2. Send a message over a suitable transport to something that runs the process for you - AF_UNIX sockets, SSH to localhost or similar, authenticating you and deciding whether you can do that.
  3. Get someone to make the command SUID and run it yourself.

The first is a non-starter if you're not trusted with root yourself - the coordination to keep someone with root access around is a pain.

The second involves more code. You have to have something running that can make the policy decisions based on a string sent to it, and then execute the process for you. There's also complexity around transferring "enough" environment state to the privileged process, and transferring results back.

The third is easy. Most of your SUID process's state is the same as it would have if it wasn't SUID, except for a few "minor" bits here and there (and this list of things is growing as we find security holes that cannot be fixed except by resetting state).

Ideally, everyone would bother to do the second option for things that need to be privileged - but that's a lot of work, and SUID is a "neat hack" that means you don't need to do it.

The trouble with symbolic links

Posted Jul 9, 2022 20:19 UTC (Sat) by NYKevin (subscriber, #129325) [Link]

The thing is, between systemd and polkit, option 2 is far easier now than it has ever been in the past. I think we are pretty much at the point where suid could just be outright deprecated and it wouldn't be that big of a deal. The anti-systemd crowd would not like that, of course, but what else is new?


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds