Two core Unix-like utilities, sudo and su, are getting rewrites in Rust

[J65nko]

From https://arstechnica.com/information-...rites-in-rust/:

Two of the most fundamental tools of the modern Unix-like command line, sudo and su, are being rewritten in the modern language Rust as part of a wider effort to get critical but aging infrastructure pieces replaced by memory-safe counterparts.
As detailed at Prossimo, a joint team from Ferrous Systems and Tweede Golf, with support from Amazon Web Services, is reimplementing sudo and su. These utilities allow a user to perform actions with the privileges of another user (typically a higher-level superuser) without having to learn and enter that other user's password. Given their age and wide usage, the Prossimo team believes it's time for a rework.

[bsd-keith]

Interesting, but wasn't that the reason behind the creating of doas.

[Onauk]

This rewrite seems to be a drop-in replacement of sudo and su which is not the case for doas.

[blackhole]

Originally Posted by bsd-keith

Interesting, but wasn't that the reason behind the creating of doas.

I seem to recall that one of the reasons doas came about was because sudo gained a dependency on a certain lib with a GPL licence, meaning sudo in OpenBSD base was well behind.

[Head_on_a_Stick]

The creator of doas said that the complexities of sudo's configuration file caused them to make an alternative:

Originally Posted by Ted Unangst

The core of the problem was really that some people like to use sudo to build elaborate sysadmin infrastructures with highly refined sets of permissions and checks and balances. Some people (me) like to use sudo to get a root shell without remembering two passwords. And so there was considerable tension trying to ship a default config that would mostly work with the second group, but not be too permissive for the first group.

Writing a small simple replacement meant that we could ship something in base which was totally unsuitable for the power sysadmin group. It could only work for me, and I would be happy. Meanwhile, those who truly needed all the flexibility of sudo would install it from ports, and they would be happy.

https://flak.tedunangst.com/post/doas

So doas is (potentially) more secure because of it's simplicity. I prefer this approach to the "rewrite it in Rust" mentality that has become prevalent.

[Onauk]

Originally Posted by Head_on_a_Stick

So doas is (potentially) more secure because of it's simplicity. I prefer this approach to the "rewrite it in Rust" mentality that has become prevalent.

I also prefer doas for my own use, however for AWS it makes sense to use sudo since the may need configurations which are impossible to do with doas.

[hitest]

I like and use sudo, but, prefer doas on OpenBSD. It's very slick.

[thirdm]

Also prefer, for simplicity reasons, doas on systems where it's available and works. However, on my debian partition it didn't seem to work despite being offered. I didn't look into it further.

Rust in Linux notwithstanding, I'm not putting a lot of significance to this story, particularly for BSD. It's an old idea in two respects: 1. if you only re-wrote your code in Ada, modula II, Lisp, C++, Rust, Haskell, etc. is a very old mailing list troll subject. 2. it's common for language enthusiasts to re-implement smallish unix utilities in their favourite languages.

For #2 I'd give the Perl example of File::Which. If you read its docs on metacpan you can see that there's proposed the justification that Windows lacks this utility lest someone think it just a lark, but I suppose most of the motivation was a (justifiable!) love of the Perl programming language and some free time.

The difference here is that the language memory safety issue might be given out as a more broad or serious justification and one seeming to have some cachet this year (particularly among Rust enthusiasts?). So they have a little money and foundation backing them. There will probably be some linux distro that takes this, but I'm guessing not mainstream ones or at least not Debian and Slackware (Slackware is still mainstream in these parts, no?).

It's interesting Ted Unangst's point on tension between sysadmin with complex requirements and more casual use. That tension runs deep through a lot of hobbiest use of BSD and Linux seems to me. As I get closer to retirement and don't aspire so much to have corporate exploitable skills, more and more I feel a draw to systems without so much pull from the work a day world. E.g. just downloaded Dragoro to play with -- not sure how far that will go, but it looks suitably uninfluenced by today's technical professional enthusiasms. And someday plan9, Minix or even Oberon, there's always someday.

[Onauk]

Originally Posted by thirdm

Also prefer, for simplicity reasons, doas on systems where it's available and works. However, on my debian partition it didn't seem to work despite being offered. I didn't look into it further.

For what it's worth, I use doas with debian on a home server and it worked perfectly so far. sudo is not installed on this server.

[thirdm]

Originally Posted by Onauk

For what it's worth, I use doas with debian on a home server and it worked perfectly so far. sudo is not installed on this server.

Taking the binary debian package, doas version 6.8.1, I can't get the permit persist feature to work. README.md from the debian source explains...

Originally Posted by README

The persist feature is disabled by default and can be enabled with the configure
flag `--with-timestamp`.

This feature is new and potentially dangerous, in the original doas, a kernel API
is used to set and clear timeouts. This API is openbsd specific and no similar A[PI
is available on other operating systems.

As a workaround, the persist feature is implemented using timestamp files
similar to sudo.

See the comment block in `timestamp.c` for an in-depth description on how
timestamps are created and checked to be as safe as possible.