3 ms·

doas is a much simpler (and therefore better) alternative.

by dev_l1x_be 1y ago

JoshTriplett 1y ago
doas is not a compatible drop-in replacement for existing users.
- hedora 1y ago
  I wonder if there’s one that hardcodes a simple policy like “members of the wheel group can run any command with a password, and a 5 minute timeout”, but is also sudo command line compatible. That’s what 99% of distros default to, and it’s simple.
- dev_l1x_be 1y ago
  I did not claim that. Here is my doas config: cat /etc/doas.conf permit nopass jane as root It be read and understood without prior knowledge. Sudo: #ALL ALL = (root) NOPASSWD: C_ZFS I have no idea what is going here, not sure what ALL means, why root is in (), etc.
- 778464636 1y ago
  Neither is sudo-rs. From TFA: > some features of the original sudo will not be implemented in sudo-rs if they serve only highly niche use cases
- badgersnake 1y ago
  For my limited use case, alias sudo=doas seems to work fine.
Foxboron 1y ago
doas is a really bad option on Linux. The Linux port has not been maintained for 3 years. Has unmerged rowhammer fixes and generally a yolo auth system best described as "dangerous". You are better off using a well maintained project, that includes the CVEs^Wwarts. It's a mistake to think that `doas` on Linux is the same as `doas` on BSD.
- dev_l1x_be 1y ago
  We need a doas-rs port that is maintained, i guess.
  - Foxboron 1y ago
    Just as with the sudo-rs reimplementation, a doas-rs rewrite is not going to solve the inherent issues we get with SUID binaries. We are better off implementing better models (see ssh and run0).
    - dev_l1x_be 1y ago
      Again I did not claim it will solve that issue. I am simply suggesting that doas has an easy to use interface and I prefer it over sudo. Somebody pointed out that doas is not maintained on Linux, so I think it would be great to reqrite it in Rust and keep it maintained.
spyc 1y ago
Both implementations of doas for Linux have (the same) unfixed security issue: - https://github.com/Duncaen/OpenDoas/issues/106 https://github.com/Duncaen/OpenDoas/issues/106 - https://github.com/slicer69/doas/issues/110 https://github.com/slicer69/doas/issues/110 I have a hard time recommending doas over sudo on Linux when the issue has been fixed in sudo but not in doas.
- oynqr 1y ago
  Which distros still have TIOCSTI enabled in their kernel? I just checked for Arch and it's disabled.
- lapsis_beeftech 1y ago
  Those should be closed WONTFIX. Neither doas nor sudo can protect you from the consequences of running untrusted code and must not attempt to do so because it adds needless complexity to safety-critical software.

doas is a much simpler (and therefore better) alternative.

JoshTriplett 1y ago

doas is not a compatible drop-in replacement for existing users.

hedora 1y ago
I wonder if there’s one that hardcodes a simple policy like “members of the wheel group can run any command with a password, and a 5 minute timeout”, but is also sudo command line compatible. That’s what 99% of distros default to, and it’s simple.
dev_l1x_be 1y ago
I did not claim that. Here is my doas config: cat /etc/doas.conf permit nopass jane as root It be read and understood without prior knowledge. Sudo: #ALL ALL = (root) NOPASSWD: C_ZFS I have no idea what is going here, not sure what ALL means, why root is in (), etc.
778464636 1y ago
Neither is sudo-rs. From TFA: > some features of the original sudo will not be implemented in sudo-rs if they serve only highly niche use cases
badgersnake 1y ago
For my limited use case, alias sudo=doas seems to work fine.

Foxboron 1y ago

doas is a really bad option on Linux. The Linux port has not been maintained for 3 years. Has unmerged rowhammer fixes and generally a yolo auth system best described as "dangerous". You are better off using a well maintained project, that includes the CVEs^Wwarts. It's a mistake to think that `doas` on Linux is the same as `doas` on BSD.

dev_l1x_be 1y ago
We need a doas-rs port that is maintained, i guess.
- Foxboron 1y ago
  Just as with the sudo-rs reimplementation, a doas-rs rewrite is not going to solve the inherent issues we get with SUID binaries. We are better off implementing better models (see ssh and run0).
  - dev_l1x_be 1y ago
    Again I did not claim it will solve that issue. I am simply suggesting that doas has an easy to use interface and I prefer it over sudo. Somebody pointed out that doas is not maintained on Linux, so I think it would be great to reqrite it in Rust and keep it maintained.

spyc 1y ago

Both implementations of doas for Linux have (the same) unfixed security issue: - https://github.com/Duncaen/OpenDoas/issues/106 https://github.com/Duncaen/OpenDoas/issues/106 - https://github.com/slicer69/doas/issues/110 https://github.com/slicer69/doas/issues/110 I have a hard time recommending doas over sudo on Linux when the issue has been fixed in sudo but not in doas.

oynqr 1y ago
Which distros still have TIOCSTI enabled in their kernel? I just checked for Arch and it's disabled.
lapsis_beeftech 1y ago
Those should be closed WONTFIX. Neither doas nor sudo can protect you from the consequences of running untrusted code and must not attempt to do so because it adds needless complexity to safety-critical software.