4 ms·

Yes. One does not even need to reach for Rust. Literally any other language (in common use) other than very badly used C++ would not have had this problem. C

by jerf 4y ago

Yes. One does not even need to reach for Rust. Literally any other language (in common use) other than very badly used C++ would not have had this problem. C delenda est.

thr0wnawaytod4y 4y ago
but if sudo was written in java we'd have other problems ;)
- jerf 4y ago
  Yes, I agree. I did not mean to imply that literally any other language would have been better for sudo, which I see is a viable reading of my original post. Go, for instance, would be a terrible choice, because the way the runtime deeply assumes you're running in a multithread environment, even before it gets to your "main" function, means that exactly the sort of UNIX hackery sudo is designed to do is effectively impossible. I have a system myself that is otherwise entirely in Go, but we have a very small C-based wrapper whose job it is to be setuid, open a few files with the escalated privileges, do some user verification, then change its uid and gid and exec the "real" Go program, because Go just can't do those things. Dynamically typed languages as a whole would be a bad idea. Java's startup time for such a small executable would be a problem. I'm just saying this problem is unique to C, and in my opinion, sufficiently endemic to security software to disqualify it entirely. Mind you, you might well end up at Rust in the end anyhow. Perhaps D. It isn't necessarily a long list for a sudo replacement. But... C delenda est.
  - pjmlp 4y ago
    In a way it is kind of an ironic tragedy, that the followers of C church worship UNIX and Plan 9, while ignoring the end station from the priesters, Inferno and Limbo, where C was confined to the minimal trust base of the kernel and a couple of drivers, with everything else in userspace mostly written in Limbo. Here is "runas" in Limbo, https://bitbucket.org/inferno-os/inferno-os/src/master/appl/cmd/runas.b https://bitbucket.org/inferno-os/inferno-os/src/master/appl/...
- pjmlp 4y ago
  Do you know one of the reasons why Multics had a better security score than UNIX on DoD assement? PL/I does bounds checking by default.
  - titzer 4y ago
    For reals. The fact that C toolchains have never even offered a bullet-proof bounds-checked (no UB) mode, no matter what the slowdown, boggles the mind. For something like sudo, literally running 100x slower would not be an issue. Its highest priority should be security.
    - encryptluks2 4y ago
      100x slower would definitely be an issue. I am prompted for my sudo password probably 30x daily.
      - bee_rider 4y ago
        How long does sudo take to load on your system. Multiply that by 3000, is it really a noticeable number?
        Izkata 4y ago
        Seems to float around 0.005s (using "time sudo -k" to avoid timing user input), so yeah, x3000 = 15 seconds. Very noticeable. Or even the x100 from (G)GP, that's a half second. Sometimes spiking to a full second.
        titzer 4y ago
        I am seeing an average of 0.0008 over 100 runs on Linux (i.e. less than a millisecond).
        tmtvl 4y ago
        Careful, admiral Hopper will give you an earful if you disrespect milliseconds.
- deleted 4y ago
  [deleted]
- kaba0 4y ago
  Like what? It would be written once correctly and work as is intended pretty much forever.
Barrin92 4y ago
I don't understand why redhat in particular still is so obsessed with C. I saw that Flatpak was written in C looking at the repo recently and for such a security relevant, relatively young project I don't know why people still stick to non-GC languages.
- dottedmag 4y ago
  You meant unsafe, not non-GC?
- kirbyfan64sos 4y ago
  Rust came out in 2015, a year after the first release of Flatpak (back when it was still called xdg-app) in 2014. The ecosystem was also much smaller; some very necessary things for working nicely on Linux that exist now like zbus (the prominent async-compatible D-Bus library) wouldn't be a thing for several more years. RH does have an interest in Rust, used in projects such as Stratis. It's just that the Linux dev ecosystem has been very C-reliant for a long time, and a massive amount of binding and other ecosystem work is still happening to make this possible. *EDIT:* and the reason I mention Rust specifically is that, in these types of lower-level projects, a lot of things can start to get hairy very quickly in higher level languages. Things like some namespace APIs very much wanting to be run on a single thread, or trying to maintain performance when you're intercepting and examining every D-Bus message, or even just when you want your functionality to be in a reusable core library.
  - adrianN 4y ago
    Safer systems languages than C predate C.
    - cryptonector 4y ago
      But the Unix environment is written in C, and there's a ton of legacy from the past several decades still to migrate from C. It's going to be slow going. That said, ditching sudo seems like the right thing to do, but then, writing a drop-in replacement is non-trivial too because sudo/sudoers is so baroque -- yet w/o a non-drop-in replacement would require user/customer migrations. Meanwhile RedHat and others don't have infinite resources, and they inherited sudo.
nequo 4y ago
What is the reason that safety-critical tools like sudo and OpenSSL are not written in Ada? Rust is still undergoing a lot of work but Ada has been around, has been stable, and it is fast. Is it that GNAT only became available relatively late in the lifetime of GNU/Linux? Or is there another technical reason for it?
- pjmlp 4y ago
  UNIX and C are symbiotic, for a long time, C would be the only compiler in the box, eventually C++ joined the party as they share the same origin. Anything else required buying the product and justify why the compilers in the box wouldn't do it . When UNIX SDKs became commercial, it was even worse, you would naturally one buy the main one, not pay twice for programming languages. Then the UNIX clones also followed the same culture focusing on C for the clones. Early versions of the GNU manifesto explicitly refer that C should be the preferred language. That is how we landed here.

by jerf 4y ago

Yes. One does not even need to reach for Rust. Literally any other language (in common use) other than very badly used C++ would not have had this problem. C delenda est.

thr0wnawaytod4y 4y ago

but if sudo was written in java we'd have other problems ;)

jerf 4y ago
Yes, I agree. I did not mean to imply that literally any other language would have been better for sudo, which I see is a viable reading of my original post. Go, for instance, would be a terrible choice, because the way the runtime deeply assumes you're running in a multithread environment, even before it gets to your "main" function, means that exactly the sort of UNIX hackery sudo is designed to do is effectively impossible. I have a system myself that is otherwise entirely in Go, but we have a very small C-based wrapper whose job it is to be setuid, open a few files with the escalated privileges, do some user verification, then change its uid and gid and exec the "real" Go program, because Go just can't do those things. Dynamically typed languages as a whole would be a bad idea. Java's startup time for such a small executable would be a problem. I'm just saying this problem is unique to C, and in my opinion, sufficiently endemic to security software to disqualify it entirely. Mind you, you might well end up at Rust in the end anyhow. Perhaps D. It isn't necessarily a long list for a sudo replacement. But... C delenda est.
- pjmlp 4y ago
  In a way it is kind of an ironic tragedy, that the followers of C church worship UNIX and Plan 9, while ignoring the end station from the priesters, Inferno and Limbo, where C was confined to the minimal trust base of the kernel and a couple of drivers, with everything else in userspace mostly written in Limbo. Here is "runas" in Limbo, https://bitbucket.org/inferno-os/inferno-os/src/master/appl/cmd/runas.b https://bitbucket.org/inferno-os/inferno-os/src/master/appl/...
pjmlp 4y ago
Do you know one of the reasons why Multics had a better security score than UNIX on DoD assement? PL/I does bounds checking by default.
- titzer 4y ago
  For reals. The fact that C toolchains have never even offered a bullet-proof bounds-checked (no UB) mode, no matter what the slowdown, boggles the mind. For something like sudo, literally running 100x slower would not be an issue. Its highest priority should be security.
  - encryptluks2 4y ago
    100x slower would definitely be an issue. I am prompted for my sudo password probably 30x daily.
    - bee_rider 4y ago
      How long does sudo take to load on your system. Multiply that by 3000, is it really a noticeable number?
      - Izkata 4y ago
        Seems to float around 0.005s (using "time sudo -k" to avoid timing user input), so yeah, x3000 = 15 seconds. Very noticeable. Or even the x100 from (G)GP, that's a half second. Sometimes spiking to a full second.
        titzer 4y ago
        I am seeing an average of 0.0008 over 100 runs on Linux (i.e. less than a millisecond).
        tmtvl 4y ago
        Careful, admiral Hopper will give you an earful if you disrespect milliseconds.
deleted 4y ago
[deleted]
kaba0 4y ago
Like what? It would be written once correctly and work as is intended pretty much forever.

Barrin92 4y ago

I don't understand why redhat in particular still is so obsessed with C. I saw that Flatpak was written in C looking at the repo recently and for such a security relevant, relatively young project I don't know why people still stick to non-GC languages.

dottedmag 4y ago
You meant unsafe, not non-GC?
kirbyfan64sos 4y ago
Rust came out in 2015, a year after the first release of Flatpak (back when it was still called xdg-app) in 2014. The ecosystem was also much smaller; some very necessary things for working nicely on Linux that exist now like zbus (the prominent async-compatible D-Bus library) wouldn't be a thing for several more years. RH does have an interest in Rust, used in projects such as Stratis. It's just that the Linux dev ecosystem has been very C-reliant for a long time, and a massive amount of binding and other ecosystem work is still happening to make this possible. *EDIT:* and the reason I mention Rust specifically is that, in these types of lower-level projects, a lot of things can start to get hairy very quickly in higher level languages. Things like some namespace APIs very much wanting to be run on a single thread, or trying to maintain performance when you're intercepting and examining every D-Bus message, or even just when you want your functionality to be in a reusable core library.
- adrianN 4y ago
  Safer systems languages than C predate C.
  - cryptonector 4y ago
    But the Unix environment is written in C, and there's a ton of legacy from the past several decades still to migrate from C. It's going to be slow going. That said, ditching sudo seems like the right thing to do, but then, writing a drop-in replacement is non-trivial too because sudo/sudoers is so baroque -- yet w/o a non-drop-in replacement would require user/customer migrations. Meanwhile RedHat and others don't have infinite resources, and they inherited sudo.

nequo 4y ago

What is the reason that safety-critical tools like sudo and OpenSSL are not written in Ada? Rust is still undergoing a lot of work but Ada has been around, has been stable, and it is fast. Is it that GNAT only became available relatively late in the lifetime of GNU/Linux? Or is there another technical reason for it?

pjmlp 4y ago
UNIX and C are symbiotic, for a long time, C would be the only compiler in the box, eventually C++ joined the party as they share the same origin. Anything else required buying the product and justify why the compilers in the box wouldn't do it . When UNIX SDKs became commercial, it was even worse, you would naturally one buy the main one, not pay twice for programming languages. Then the UNIX clones also followed the same culture focusing on C for the clones. Early versions of the GNU manifesto explicitly refer that C should be the preferred language. That is how we landed here.