Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The first stable release of a memory safe sudo implementation

memorysafety.org

Post reply on HN
Print view View original

41–50 of 260 posts

Re: The first stable release of a memory safe sudo implementation

#41

Post by lucideer »

hpb42 wrote: post #23
garblegarble wrote: post #3

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-ori...

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…

> One of those left out features

They indicate that many omittted features are by design, but this particular one is implied to be planned:

> Some functionality is not yet supported; in particular sudoedit

Re: The first stable release of a memory safe sudo implementation

#42

Post by abofh »

jacquesm wrote: post #11
SonOfLilit wrote: post #8

Earlier quoted context omitted.

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.

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.

Have you tried reading them? They're often helpful

Re: The first stable release of a memory safe sudo implementation

#43

Post by Fnoord »

mprovost wrote: post #19
garblegarble wrote: post #10

Earlier quoted context omitted.

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

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.

OpenBSD uses BSD_Auth instead of PAM. So you cannot use your YubiKey with doas via PAM on the Linux ports. At least not in the same way, as they do not support caching it seems.

Re: The first stable release of a memory safe sudo implementation

#44

Post by phanimahesh »

tambourine_man wrote: post #27
hpb42 wrote: post #23

Earlier quoted context omitted.

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…

In Vim: :w !sudo tee % Which I map to :w!! Of course, if you’re not using Vim, you’re doing it wrong :)

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.

Re: The first stable release of a memory safe sudo implementation

#45

Post by [deleted] »

tambourine_man wrote: post #27
hpb42 wrote: post #23

Earlier quoted context omitted.

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…

In Vim: :w !sudo tee % Which I map to :w!! Of course, if you’re not using Vim, you’re doing it wrong :)

[deleted]

Re: The first stable release of a memory safe sudo implementation

#46

Post by cyber_kinetist »

Karellen wrote: post #34
jackmott wrote: post #2

I remember a couple of years ago a root exploit in Sudo that was the result of failing to check for a sentinel value, thinking “that is a bug that wouldn’t happen in Rust, even though it isn’t related to memory safety!” Rust enums are sum types, and imho are one of the few unambiguously good language feature ideas. I miss them any time I use a language where they are not built in. F# is another nice language where th…

> Rust enums are sum types, I wouldn't mind so much if they just called them "sum types" or "tagged unions", or even some other new name. Reusing the existing name "enum" from other languages, but differently from the way all those other languages have used it for 45 gorram years, is freaking maddening.

Swift and Scala also uses the enum keyword to define sum types, and their history goes earlier than Rust, so now you have multiple languages to yell at!

Re: The first stable release of a memory safe sudo implementation

#47

Post by quotemstr »

garblegarble wrote: post #3

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-ori...

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.

Re: The first stable release of a memory safe sudo implementation

#48

Post by quotemstr »

josephg wrote: post #35
hpb42 wrote: post #23

Earlier quoted context omitted.

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…

This would be a great use case for a capability security model. Essentially what you really want is the sudo command to acquire a temporary capability token to edit that specific file. Then run your editor and pass it the capability. (And revoke the capability when the editor process closes). It’s a pity this isn’t more straight forward to implement on Linux.

> Essentially what you really want is the sudo command to acquire a temporary capability token to edit that specific file.

This should be doable with an XDG portal model, right?

Re: The first stable release of a memory safe sudo implementation

#50

Post by queuebert »

gary_0 wrote: post #20
garblegarble wrote: post #3

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-ori...

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#L... )

Is that a Slashdot reference?
Post reply on HN