5 ms·

I'm assuming this project's aim is to replace sudo, in which case hand-waving away "Leaving out less commonly used features" is a bit worrying. What are these f

I'm assuming this project's aim is to replace sudo, in which case hand-waving away "Leaving out less commonly used features" is a bit worrying. What are these features? How uncommonly are they used? In which way will it fail if a configuration uses those features? Edit: Looks like their github readme outlines some of these limitations, https://github.com/memorysafety/sudo-rs#differences-from-original-sudo https://github.com/memorysafety/sudo-rs#differences-from-ori...

fermuch 3y ago
It seems like those changes are noted here: https://github.com/memorysafety/sudo-rs#differences-from-original-sudo https://github.com/memorysafety/sudo-rs#differences-from-ori...
- garblegarble 3y ago
  The text seems to imply that's not a list of features not implemented, it's a list of features not implemented that don't output a clear error
dtx1 3y ago
Having so many different feeatures in one of the most basic unix tools is much more of a red flag.
- garblegarble 3y ago
  For sure! But that mistake has already been made, and has been in the wild for years, so removing those features (and proposing yourself as a replacement for the original) is now a breaking change
  - mprovost 3y ago
    OpenBSD replaced sudo with doas (with a vastly reduced feature set) several years ago, and without breaking everything. Sure there are use cases where you absolutely need some feature of sudo, but you can always install it.
    - garblegarble 3y ago
      That seems like the Right Way to do it... As annoying as it is to have to update every sudo reference -> doas, it forces you to think about everywhere you're using it, rather than waiting to see what breaks and then trying to fix it.
      - codetrotter 3y ago
        > As annoying as it is to have to update every sudo reference -> doas, it forces you to think about everywhere you're using it, rather than waiting to see what breaks and then trying to fix it. In my scripts I never call sudo or doas. Instead, if the script needs to do something as root, I write the whole script so that it expects to itself be run as root. And then when I want to run my script, I run it as root doas ./somescript.zsh
        PrimeMcFly 3y ago
        That's a much worse approach from a security pov.
        codetrotter 3y ago
        No. That’s a blanket statement on your part that you cannot make because you don’t know what my scripts look like, or what commands they call.
        xyzzy_plugh 3y ago
        No, it's never better to run whole scripts as root when root is only required for part of it. Unless every expression in your script requires root, the blanket statement holds. In my experience, and in my own scripts, it is better to explicitly check if you are being run as root, advise against it and exit (with maybe some break glass flags) and invoke sudo when escalated privileges are required.
        PrimeMcFly 3y ago
  - speed_spread 3y ago
    Priorities. If a fundamental security tool's design limits it's trustworthiness, it greatly reduces it's usefulness and "breaking" it's interface is thus warranted.
SonOfLilit 3y ago
I've lived through the transition to systemd. I'm sure sysadmins will be able to manage this one. And I'm sure great technical documentation exists, this was a PR release, not where I'd look for a list of missing features.
- jacquesm 3y ago
  I still run into trouble on a fairly regular basis on account of systemd. Especially the log files continue to cause all kinds of issues.
  - happymellon 3y ago
    What issues do you run into with the log files? I have plenty of ideological problems with the design of the logs, but not actually ran into problems in the real world.
    - djbusby 3y ago
      I'm still mad I can't just `tail -f`
      - eptcyka 3y ago
        journalctl -f?
      - stouset 3y ago
        journalctl -f On the flip side, now you get structured logging, efficiently-searchable logs over any of those fields, the ability to easily aggregate logs from multiple machines, the ability to accurately iterate over logs in processes without missing entries, and on and on and on. Logs as a database is wildly superior to logs as a plain text file, with virtually the only downside being that you need a specific program to tail them.
        happymellon 3y ago
        > the only downside being that you need a specific program to tail them. The journal can output to text files as well! But this is exactly it, my only issue is the ideological one that there is no spec for the database. The implementation is the specification, so the only true way of building a reader of logs is to implement the journal. There are attempts to document the layout but if there is any difference then you can't submit a bug to get the layout corrected but the implementation isn't wrong. I can think of plenty of other applications with bigger issues than that. But I think can still want the defacto log for Linux to have an official spec.
gary_0 3y ago
One feature they didn't mention they left out was the ability to run `make me a sandwich` (https://github.com/sudo-project/sudo/blob/main/Makefile.in#L450 https://github.com/sudo-project/sudo/blob/main/Makefile.in#L...)
- queuebert 3y ago
  Is that a Slashdot reference?
  - tecleandor 3y ago
    Old XKCD joke (maybe coming from an older joke)... https://xkcd.com/149/ https://xkcd.com/149/
    - gary_0 3y ago
      That XKCD joke was all over the Internet in 2006. Now get off my lawn.
      - tecleandor 3y ago
        Well, that comic is from 2006 so not that far away :P ;)
      - kelnos 3y ago
        Huh, it took 6 years for the joke to get added: https://github.com/sudo-project/sudo/commit/c1d6e86d67aa60d7383b16b3783ec3d7cbcf3fb2 https://github.com/sudo-project/sudo/commit/c1d6e86d67aa60d7...
  - deleted 3y ago
    [deleted]
hpb42 3y ago
One of those left out features is `sudoedit` or `sudo -e`. I use this a lot when editing files in /etc or any file that my user does not have permissions. The flag first copies the file to a temporary location with permissions for my user to edit, then opens my text editor (defined via $SUDO_EDITOR env var) as _my user_, without any sudo permissions. After I close the editor, the file is copied back with the original permissions only if there were any changes. The cool thing is running the editor via my user, which loads my user's configuration/plugins, instead of the root user's.
- tambourine_man 3y ago
  In Vim: :w !sudo tee % Which I map to :w!! Of course, if you’re not using Vim, you’re doing it wrong :)
  - phanimahesh 3y ago
    It is a little less useful if the file is not readable by your user, and once you authenticate anything within your vim can also silently run other sudo commands since on most distros sudo remembers the autnentication for a while. Now that I think of it, not sure how sudoedit behaves wrt this cached auth.
    - KMnO4 3y ago
      I think you can use the sudo -k flag to clear the cached auth
  - deleted 3y ago
    [deleted]
- Zardoz84 3y ago
  I usully use "sudo -E EDITOR_OF_MY_CHOICE"
  - liftm 3y ago
    Many editors can execute shell commands, so this isn't the same at all.
quotemstr 3y ago
There's a gulf between being 99% compatible with something and being a 100% drop-in. If the author of program B wants to replace A, he should go the extra mile and implement every feature of A so as to erase technical excuses for stasis. B needs to put aside his ego, swallow his pride, and implement all the features of A, even the ones her personally dislikes, because the effect of doing otherwise will be that B doesn't replace A. We have to work backwards from out desired outcomes.
- marcus0x62 3y ago
  Perhaps, but if the goal is security of a critical tool, losing some attack surface (features) if they aren’t widely used is a win. Other projects, like ntpsec[0] have taken this approach with good results. Although, I agree with another commenter in this thread[1] that this effort would have been better directed at something with an inherently small attack surface like doas. 0 - https://www.ntpsec.org/accomplishments.html https://www.ntpsec.org/accomplishments.html 1 - https://news.ycombinator.com/item?id=38161016#38162736 https://news.ycombinator.com/item?id=38161016#38162736
  - godshatter 3y ago
    The features they are leaving out were presumably added for a reason. If someone is on a system that is using sudo-rs as a drop-in replacement (not under their control) and they need to use one of those less widely-used features, how secure is the work-around they have to use instead? I'm hoping this factored in to their analysis. Sometimes reimplementing something and leaving out lesser-used features to "reduce the attack surface" can sound an awful lot like "let them pound sand".
    - nucleardog 3y ago
      Did you know you can set up an OpenVPN tunnel with no encryption or authentication? I'm sure for someone out there that's a make-or-break feature, but for the vast majority trying to use OpenVPN it's a massive, insecure footgun. (Hell, how many bugs have protocol negotiation led to in OpenVPN/SSL/etc?) Compare that to Wireguard that just says... it's encrypted. Full stop. Carry on. A lot of this tooling and technology was developed in a different era with different priorities. Security, and especially network security, was not such a huge focus 30-40 years ago. Priorities have shifted. The operating environment is a lot more homogeneous (when's the last time you dealt with a layer 2 protocol besides ethernet?), while the risk of poor security has grown immensely. It's absolutely fair to critically evaluate these features and determine which can be removed to simplify and improve the products for the vast majority of users. If a small fraction of users stay on sudo, but the majority are able to move to a more secure option... that's a win. This is exactly what Wireguard provides versus OpenVPN.
sigio 3y ago
One of the features I use in some (larger) environments, which isn't on the roadmap or implemented is LDAP support in sudo-rs. Using the regular sudo, this allows you to manage the sudo permissions for the entire network from the central LDAP configuration, and even make rules that are time/host/user/command limited in a central location with no chance of simple syntax-errors wiping out your entire configuration, just that single rule is being ignored in this case.
emporas 3y ago
So, statically link the new sudo with the old sudo, and when the user tries to use less commonly used features fallback to the older version in C. The binary executable will be bigger, but disk space is a lot cheaper nowadays, compared to 43 years back. I mean, is there any time where one more level of indirection failed to make everyone happy?

fermuch 3y ago

It seems like those changes are noted here: https://github.com/memorysafety/sudo-rs#differences-from-original-sudo https://github.com/memorysafety/sudo-rs#differences-from-ori...

garblegarble 3y ago
The text seems to imply that's not a list of features not implemented, it's a list of features not implemented that don't output a clear error

dtx1 3y ago

Having so many different feeatures in one of the most basic unix tools is much more of a red flag.

garblegarble 3y ago
For sure! But that mistake has already been made, and has been in the wild for years, so removing those features (and proposing yourself as a replacement for the original) is now a breaking change
- mprovost 3y ago
  OpenBSD replaced sudo with doas (with a vastly reduced feature set) several years ago, and without breaking everything. Sure there are use cases where you absolutely need some feature of sudo, but you can always install it.
  - garblegarble 3y ago
    That seems like the Right Way to do it... As annoying as it is to have to update every sudo reference -> doas, it forces you to think about everywhere you're using it, rather than waiting to see what breaks and then trying to fix it.
    - codetrotter 3y ago
      > As annoying as it is to have to update every sudo reference -> doas, it forces you to think about everywhere you're using it, rather than waiting to see what breaks and then trying to fix it. In my scripts I never call sudo or doas. Instead, if the script needs to do something as root, I write the whole script so that it expects to itself be run as root. And then when I want to run my script, I run it as root doas ./somescript.zsh
      - PrimeMcFly 3y ago
        That's a much worse approach from a security pov.
        codetrotter 3y ago
        No. That’s a blanket statement on your part that you cannot make because you don’t know what my scripts look like, or what commands they call.
        xyzzy_plugh 3y ago
        No, it's never better to run whole scripts as root when root is only required for part of it. Unless every expression in your script requires root, the blanket statement holds. In my experience, and in my own scripts, it is better to explicitly check if you are being run as root, advise against it and exit (with maybe some break glass flags) and invoke sudo when escalated privileges are required.
        PrimeMcFly 3y ago
- speed_spread 3y ago
  Priorities. If a fundamental security tool's design limits it's trustworthiness, it greatly reduces it's usefulness and "breaking" it's interface is thus warranted.

SonOfLilit 3y ago

I've lived through the transition to systemd. I'm sure sysadmins will be able to manage this one. And I'm sure great technical documentation exists, this was a PR release, not where I'd look for a list of missing features.

jacquesm 3y ago
I still run into trouble on a fairly regular basis on account of systemd. Especially the log files continue to cause all kinds of issues.
- happymellon 3y ago
  What issues do you run into with the log files? I have plenty of ideological problems with the design of the logs, but not actually ran into problems in the real world.
  - djbusby 3y ago
    I'm still mad I can't just `tail -f`
    - eptcyka 3y ago
      journalctl -f?
    - stouset 3y ago
      journalctl -f On the flip side, now you get structured logging, efficiently-searchable logs over any of those fields, the ability to easily aggregate logs from multiple machines, the ability to accurately iterate over logs in processes without missing entries, and on and on and on. Logs as a database is wildly superior to logs as a plain text file, with virtually the only downside being that you need a specific program to tail them.
      - happymellon 3y ago
        > the only downside being that you need a specific program to tail them. The journal can output to text files as well! But this is exactly it, my only issue is the ideological one that there is no spec for the database. The implementation is the specification, so the only true way of building a reader of logs is to implement the journal. There are attempts to document the layout but if there is any difference then you can't submit a bug to get the layout corrected but the implementation isn't wrong. I can think of plenty of other applications with bigger issues than that. But I think can still want the defacto log for Linux to have an official spec.

gary_0 3y ago

One feature they didn't mention they left out was the ability to run `make me a sandwich` (https://github.com/sudo-project/sudo/blob/main/Makefile.in#L450 https://github.com/sudo-project/sudo/blob/main/Makefile.in#L...)

queuebert 3y ago
Is that a Slashdot reference?
- tecleandor 3y ago
  Old XKCD joke (maybe coming from an older joke)... https://xkcd.com/149/ https://xkcd.com/149/
  - gary_0 3y ago
    That XKCD joke was all over the Internet in 2006. Now get off my lawn.
    - tecleandor 3y ago
      Well, that comic is from 2006 so not that far away :P ;)
    - kelnos 3y ago
      Huh, it took 6 years for the joke to get added: https://github.com/sudo-project/sudo/commit/c1d6e86d67aa60d7383b16b3783ec3d7cbcf3fb2 https://github.com/sudo-project/sudo/commit/c1d6e86d67aa60d7...
- deleted 3y ago
  [deleted]

hpb42 3y ago

One of those left out features is `sudoedit` or `sudo -e`. I use this a lot when editing files in /etc or any file that my user does not have permissions. The flag first copies the file to a temporary location with permissions for my user to edit, then opens my text editor (defined via $SUDO_EDITOR env var) as _my user_, without any sudo permissions. After I close the editor, the file is copied back with the original permissions only if there were any changes. The cool thing is running the editor via my user, which loads my user's configuration/plugins, instead of the root user's.

tambourine_man 3y ago
In Vim: :w !sudo tee % Which I map to :w!! Of course, if you’re not using Vim, you’re doing it wrong :)
- phanimahesh 3y ago
  It is a little less useful if the file is not readable by your user, and once you authenticate anything within your vim can also silently run other sudo commands since on most distros sudo remembers the autnentication for a while. Now that I think of it, not sure how sudoedit behaves wrt this cached auth.
  - KMnO4 3y ago
    I think you can use the sudo -k flag to clear the cached auth
- deleted 3y ago
  [deleted]
Zardoz84 3y ago
I usully use "sudo -E EDITOR_OF_MY_CHOICE"
- liftm 3y ago
  Many editors can execute shell commands, so this isn't the same at all.

quotemstr 3y ago

There's a gulf between being 99% compatible with something and being a 100% drop-in. If the author of program B wants to replace A, he should go the extra mile and implement every feature of A so as to erase technical excuses for stasis. B needs to put aside his ego, swallow his pride, and implement all the features of A, even the ones her personally dislikes, because the effect of doing otherwise will be that B doesn't replace A. We have to work backwards from out desired outcomes.

marcus0x62 3y ago
Perhaps, but if the goal is security of a critical tool, losing some attack surface (features) if they aren’t widely used is a win. Other projects, like ntpsec[0] have taken this approach with good results. Although, I agree with another commenter in this thread[1] that this effort would have been better directed at something with an inherently small attack surface like doas. 0 - https://www.ntpsec.org/accomplishments.html https://www.ntpsec.org/accomplishments.html 1 - https://news.ycombinator.com/item?id=38161016#38162736 https://news.ycombinator.com/item?id=38161016#38162736
- godshatter 3y ago
  The features they are leaving out were presumably added for a reason. If someone is on a system that is using sudo-rs as a drop-in replacement (not under their control) and they need to use one of those less widely-used features, how secure is the work-around they have to use instead? I'm hoping this factored in to their analysis. Sometimes reimplementing something and leaving out lesser-used features to "reduce the attack surface" can sound an awful lot like "let them pound sand".
  - nucleardog 3y ago
    Did you know you can set up an OpenVPN tunnel with no encryption or authentication? I'm sure for someone out there that's a make-or-break feature, but for the vast majority trying to use OpenVPN it's a massive, insecure footgun. (Hell, how many bugs have protocol negotiation led to in OpenVPN/SSL/etc?) Compare that to Wireguard that just says... it's encrypted. Full stop. Carry on. A lot of this tooling and technology was developed in a different era with different priorities. Security, and especially network security, was not such a huge focus 30-40 years ago. Priorities have shifted. The operating environment is a lot more homogeneous (when's the last time you dealt with a layer 2 protocol besides ethernet?), while the risk of poor security has grown immensely. It's absolutely fair to critically evaluate these features and determine which can be removed to simplify and improve the products for the vast majority of users. If a small fraction of users stay on sudo, but the majority are able to move to a more secure option... that's a win. This is exactly what Wireguard provides versus OpenVPN.

sigio 3y ago

One of the features I use in some (larger) environments, which isn't on the roadmap or implemented is LDAP support in sudo-rs. Using the regular sudo, this allows you to manage the sudo permissions for the entire network from the central LDAP configuration, and even make rules that are time/host/user/command limited in a central location with no chance of simple syntax-errors wiping out your entire configuration, just that single rule is being ignored in this case.

emporas 3y ago

So, statically link the new sudo with the old sudo, and when the user tries to use less commonly used features fallback to the older version in C. The binary executable will be bigger, but disk space is a lot cheaper nowadays, compared to 43 years back. I mean, is there any time where one more level of indirection failed to make everyone happy?