Implemented close_range (sort of) for Mac by philocalyst · Pull Request #1540 · trifectatechfoundation/sudo-rs

philocalyst · 2026-04-06T17:12:26Z

Just like on Linux, there really isn't a close_range function (If we consider libc authoritative).

But there are some other solutions! I basically stole from the C sudo project (As recommended in the original thread).

Specifically, this implements using /dev/fd on macOS. In the original C implementation this uses some odd abstraction which vaguely concerns me, but here we use a literal like on Linux.

And also specifically, this uses the recommended proc_pidinfo approach as the main solution (the /dev/fd is a fallback).

Funniest here is the WIGGLE_ROOM constant, which just covers from some expected user entropy. I would like feedback on what could happen if WIGGLE_ROOM is exceeded. All in all, it sticks fairly close to the C implementation, linked in the relevant commit.

Tried to stick to the code style I saw elsewhere in the codebase, but outside of that likely comment, I was interested in what the expectation is for testing? Left out of this PR (for now) so I'm marking it as a draft, just because it is the area of expertise I lack the most in. Commentary there would be MOST appreciated.

Also... I can't compile because I'm on Mac, so the other reason for delayed testing is me setting up a Linux VM.

@squell

Closes #901

src/system/mod.rs

bjorn3 · 2026-04-07T14:29:50Z

Also... I can't compile because I'm on Mac, so the other reason for delayed testing is me setting up a Linux VM.

If you do rustup target add x86_64-unknown-linux-gnu, you should be able to do cargo check --target x86_64-unknown-linux-gnu.

mhm

Basically stolen from here, https://github.com/sudo-project/sudo/blob/116115229a625afe068ac6c593a5ce2176a96a08/lib/util/closefrom.c#L117-L143 But rust-ified

Little uncertain of the nested logic here for getting a validated fd, but it means there's no duplicate error message, and is a lot tighter. ALSO FIXES THE FIXME

… pipeline

cleaned up

philocalyst · 2026-04-07T16:12:19Z

Checks cleanly! @bjorn3

squell · 2026-04-07T20:25:16Z

Note that there's a highly experimental longer-lived macos-experiment branch which compiles and (sort of) works; it still is missing some bits you might want to look at (see the final WIP commit).

If you would like to hack to get sudo-rs running on your MacBook, could be fun check it out. It's almost completely untested so use caution.

Also be aware that MacOS support has a rather low priority for us, for a couple of reasons:

The commits on that branch shows that a lot of stuff we take for granted on Linux/FreeBSD simply isn't there on that platform and that adds a lot of extra checks/workarounds.
It's not likely to be used by many (without Apple shipping it, which seems unlikely)

That said, doesn't mean fun can be had with it, and I would be happy to accept contributions on the macos-experiment branch (this one probably should also go there).

philocalyst · 2026-04-07T21:24:06Z

It sounds fun to me too! Wondering if there IS a path to merging with mainline EVENTUALLY? Just to keep in mind when developing, I tend to be pretty pragmatic. Where does that leave the two macos issues (btw)? ▰▰▰▰▰ Miles Wirth 🙃

…

From: Marc R. Schoolderman ***@***.***> Sent: 07 April 2026 13:25 To: trifectatechfoundation/sudo-rs ***@***.***> Cc: Miles Wirht ***@***.***>, Author ***@***.***> Subject: Re: [trifectatechfoundation/sudo-rs] Implemented close_range (sort of) for Mac (PR #1540) squell left a comment (trifectatechfoundation/sudo-rs#1540) Note that there's a highly experimental longer-lived `macos-experiment` branch which compiles and (sort of) works; it still is missing some bits you might want to look at (see the final WIP commit). If you would like to hack to get sudo-rs running on your MacBook, could be fun check it out. It's almost completely **untested** so use caution. Also be aware that MacOS support has a rather low priority for us, for a couple of reasons: - The commits on that branch shows that a lot of stuff we take for granted on Linux/FreeBSD simply isn't there on that platform and that adds a lot of extra checks/workarounds. - It's not likely to be used by many (without Apple shipping it, which seems unlikely) That said, doesn't mean fun can be had with it, and I would be happy to accept contributions on the `macos-experiment` branch (this one probably should also go there). -- Reply to this email directly or view it on GitHub: #1540 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

squell · 2026-04-09T12:36:19Z

Yes, there is a path eventually.

There are currently two open issues for MacOS which are the most pressing, one is the one linked to this PR, the other one pertains to implementing these stubs:
fda6eb3

In general the path is:

We're already able to compile and run on MacOS, so that at least is something (we are currently here).
I would say the first order of business is to get that branch to a point where it not only "compiles and runs", but also isn't lacking some code that is critical (as it currently does), and we can manually test to see that it works. I.e. that job is: closing the open issues. (The close_range issue has already been less a concern since the "fallback" close_range implementation exists nowadays; although having it properly implemented would surely be a very nice thing!)
Then we should make sure that it also passes the unit tests (which probably requires further modifications); and after that the compliance testing framework. That latter part will probably be quite annoying.
At the point we're probably staring at a situation where the macos-experiment branch has some modifications (e.g. some typecasts, wrappers to work around e.g. the lack of pipe2) and we can think about how to sweep those under the rug nicely so we don't have to introduce too many #[cfg(target_os = "macos")] things (which is what the branch is currently doing without hesistation)

I would prefer to keep the macos-experiment branch as a collection of commits that can be replayed on top of main, where each commit addresses a particular item, for that purpose.

For example, one of the WIP commits on that branch also has some fcntl-wrapping similar to as what you're doing here. :-)

This approach is similar to how our FreeBSD port was undertaken; we first did the port and then we gradually introduced the changes needed for it back into main.

If we get it to a point where it works well and the maintenance burden for keeping MacOS-modification in main can probably become acceptable low, I woulnd't see a reason not to integrate that entire branch in main. Nobody else is working on it and even if you just pick up #902 it would bring this one step closer.

philocalyst · 2026-04-09T16:27:39Z

Sounds great! So the next step would be to rebase this onto that darwin branch and get the changes working over there? I'll look into #902 ▰▰▰▰▰ Miles Wirth 🙃

…

From: Marc R. Schoolderman ***@***.***> Sent: 09 April 2026 05:36 To: trifectatechfoundation/sudo-rs ***@***.***> Cc: Miles Wirht ***@***.***>, Author ***@***.***> Subject: Re: [trifectatechfoundation/sudo-rs] Implemented close_range (sort of) for Mac (PR #1540) squell left a comment (trifectatechfoundation/sudo-rs#1540) Yes, there is a path eventually. There are currently two open issues for MacOS which are the most pressing, one is the one linked to this PR, the other one pertains to implementing these stubs: fda6eb3 In general the path is: - We're already able to compile and run on MacOS, so that at least is something (we are currently here). - I would say the first order of business is to get that branch to a point where it not only "compiles and runs", but also isn't lacking some code that is critical (as it currently does), and we can manually test to see that it works. I.e. that job is: closing the open issues. (The close_range issue has already been less a concern since the "fallback" close_range implementation exists nowadays) - Then we should make sure that it also passes the unit tests (which probably requires further modifications); and after that the compliance testing framework. That latter part will probably be quite annoying. - At the point we're probably staring at a situation where the `macos-experiment` branch has some modifications (e.g. wrappers to work around e.g. the lack of `pipe2`) and we can think about how to sweep those under the rug nicely so we don't have to introduce too many `#[cfg(target_os = "macos")]` things (which is what the branch is currently doing without hesistation) I would prefer to keep the macos-experiment branch as a collection of commits that can be replayed on top of `main`, where each commit addresses a particular item, for that purpose. For example, one of the WIP commits on that branch also has some `fcntl`-wrapping similar to as what you're doing here. :-) This approach is similar to how our FreeBSD port was undertaken; we first did the port and then we gradually introduced the changes needed for it back into `main`. If we get it to a point where it works well and the maintenance burden for keeping MacOS-modification in main can probably become acceptable low, I woulnd't see a reason not to integrate that entire branch in main. Nobody else is working on it and even if you just pick up #902 it would bring this one step closer. -- Reply to this email directly or view it on GitHub: #1540 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

philocalyst force-pushed the close_range_mca branch 2 times, most recently from 8261079 to 09daa6a Compare April 6, 2026 17:16

bjorn3 reviewed Apr 7, 2026

View reviewed changes

src/system/mod.rs Outdated Show resolved Hide resolved

philocalyst added 8 commits April 7, 2026 12:04

fixed the gating of deps and compile errors

c101478

mhm

created set_cloexec helper function

9a3444e

Created function for managing the closing with proc-pidinfo

5d3b74e

Basically stolen from here, https://github.com/sudo-project/sudo/blob/116115229a625afe068ac6c593a5ce2176a96a08/lib/util/closefrom.c#L117-L143 But rust-ified

Created a hosting function that holds all of the broken-apart logic

e16ae97

function for handling the closing through fd_dirs

554d8c5

Little uncertain of the nested logic here for getting a validated fd, but it means there's no duplicate error message, and is a lot tighter. ALSO FIXES THE FIXME

Some logic fixes to get the existing function to work better with the…

730febe

… pipeline

Removed needless return

feb48a4

cleaned up

Added back comment lost in copy/paste

185fa6c

philocalyst force-pushed the close_range_mca branch from 09daa6a to 185fa6c Compare April 7, 2026 16:04

squell added the macos label Apr 7, 2026

squell added this to the External Contribs milestone Apr 7, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implemented close_range (sort of) for Mac#1540

Implemented close_range (sort of) for Mac#1540
philocalyst wants to merge 8 commits intotrifectatechfoundation:mainfrom
philocalyst:close_range_mca

philocalyst commented Apr 6, 2026 •

edited

Loading

Uh oh!

Uh oh!

bjorn3 commented Apr 7, 2026

Uh oh!

philocalyst commented Apr 7, 2026

Uh oh!

squell commented Apr 7, 2026

Uh oh!

philocalyst commented Apr 7, 2026 via email

Uh oh!

squell commented Apr 9, 2026 •

edited

Loading

Uh oh!

philocalyst commented Apr 9, 2026 via email

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

philocalyst commented Apr 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

bjorn3 commented Apr 7, 2026

Uh oh!

philocalyst commented Apr 7, 2026

Uh oh!

squell commented Apr 7, 2026

Uh oh!

philocalyst commented Apr 7, 2026 via email

Uh oh!

squell commented Apr 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

philocalyst commented Apr 9, 2026 via email

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

philocalyst commented Apr 6, 2026 •

edited

Loading

squell commented Apr 9, 2026 •

edited

Loading