Tracking Issue for #![feature(unix_chown)]

[joshtriplett]

Feature gate: #![feature(unix_chown)]

This is a tracking issue for the chown family of functions. These functions change the UNIX owner and group of a file or file descriptor.

Public API

pub fn chown<P: AsRef<Path>>(dir: P, uid: Option<u32>, gid: Option<u32>) -> io::Result<()> {}
pub fn fchown<F: AsFd>(fd: F, uid: Option<u32>, gid: Option<u32>) -> io::Result<()> {}
pub fn lchown<P: AsRef<Path>>(dir: P, uid: Option<u32>, gid: Option<u32>) -> io::Result<()> {}

Steps / History

• Implementation: Add chown functions to std::os::unix::fs to change the owner and group of files #88953
  • Blocking issue: fchown takes an AsFd by value, which prevents passing a reference.
• Final comment period (FCP)
• Stabilization PR

[dtolnay]

I think as part of stabilizing, we'll want to chat about what the end game is here. Does std::os::unix take on much more of nix::unistd or nix more broadly, maybe with less type safety if we aren't interested in defining vocabulary types for Uid/Gid? Or only the most widely used APIs? By what metric?

cc @the8472

[joshtriplett]

@dtolnay For my part, I'm not necessarily looking to take on all of nix's functionality. My metric is, roughly, "is this something that's trivial to do with a common shell command, and likely to be desirable in minimal standalone programs". Rust works really well for tiny static binaries, chroots, containers, inits, and similar; it's also helpful for things that need to run with privileges. I'm adding things that I'd like to use for such purposes.

So, for instance, I wouldn't want to add something at the level of quotactl or prctl or finit_module; those make sense to have in separate crates. But I'd like to add other things as fundamental as chroot and chown, such as pipe (now that we have OwnedFd), setgroups, and a setuid/setgid mechanism (if we can portably handle some of the mess there, since unfortunately not all systems have setresuid and setresgid).

One other component of this policy: I think we should only add things that represent well-established interfaces that won't need to change in the future. POSIX functions are fairly safe in that regard, as are some long-established and widely used target-specific functions, but we shouldn't be exposing the forefront of target-specific functionality.

[nagisa]

Just a drive-by comment, but names for these functions seem to not follow the broader conventions used within the standard library (e.g. parent_id and not getppid), though I guess I'm seeing a fair number of other functions that don't refrain from using the original abbreviated names either (chroot?)

[the8472]

Do we need them on the standard library though when alternatives exist? For example the pidfd extensions to Command make sense because one must opt-in at process creation time. Many of the methods in unistd don't need any supporting plumbing. So they seem redundant.

My metric is, roughly, "is this something that's trivial to do with a common shell command, and likely to be desirable in minimal standalone programs". Rust works really well for tiny static binaries, chroots, containers, inits, and similar

This is still nebulous. Shell scripts will often glue things together you can't find in the rust standard library. Even something as simple as decompressing a stream gzip (included in busybox or the python and java standard libraries) will require an external library. Ditto regular expressions. So "minimal" sounds more like a toy program if you eschew external libraries. Or at least a very peculiar, tiny scope that just happens to almost exactly match what the standard library currently offers.
And if the user does use libraries then we're back to the question what value std integration can provide compared to nix.

[joshtriplett]

@nagisa I agree, and under other circumstances, we'd probably call it something a little less abbreviated like change_owner. Here's my justification for why I think chown makes more sense than change_owner or similar here:

If we're adding a function that's likely to run on any target supporting std, such as create_dir or rename, we're likely calling different functions on different targets. It makes sense to use a descriptive name, rather than a target-specific name for one target. And if we could make some kind of portable function to handle ownership changes, I would absolutely favor calling it by a general name.

However, the user and ownership model is so incredibly different between Windows and UNIX that I don't think such an abstraction layer makes sense in the standard library. I think we should build abstraction layers when platforms work more-or-less the same way ("make a directory"), not when we'd have to introduce a fair amount of opinionated policy to have any hope of a useful abstraction.

Given that, I think it makes sense to have a UNIX-specific function exposing the UNIX chown functionality here. And since it's UNIX-specific, and the functions to do this are portably called chown on all UNIX systems, and widely known by that name including via the command-line tool of the same name, to the point that it's a standard vocabulary verb among administrators, I think a more verbose name would be an obfuscation, not an improvement.

I think that justification holds for chroot, and chown. It may hold for some other things. There's other functionality, though, where I think we should improve on naming; for instance, I'm glad we have is_char_device rather than ifchr.

Does that seem reasonable, regarding naming?

[joshtriplett]

Do we need them on the standard library though when alternatives exist? For example the pidfd extensions to Command make sense because one must opt-in at process creation time. Many of the methods in unistd don't need any supporting plumbing. So they seem redundant.

The same argument applies to many things in the standard library. std::os::unix::fs::symlink is fairly standalone; FileExt (read_at, write_at) could easily be done standalone. std::process::id could be standalone. Many pieces of the standard library aren't fundamentally things that have to be in the standard library; they could be in crates.

I'm in favor of caution; we don't want to add interfaces that we may regret later, because we can't remove them. But if we're confident that the interface will stand the test of time without needing to change, then I do think there's value in having a std interface.

[sunfishcode]

The current definition of fchown takes its AsFd argument by value instead of by reference. This means that passing it a &File gets an error, and passing it a File consumes and closes the file. To be usable, fchown's argument should be changed from fd: F to fd: &F.

Alternatively, #93869 proposes to change AsFd so that functions should take AsFd arguments by value.

[joshtriplett]

Good catch. I've marked that as blocking in the top comment; we shouldn't stabilize fchown until we select and apply an appropriate fix for that.

Further discussion in #93869.

[joshtriplett]

I think all the issues with this have been resolved, and I'd like to propose stabilizing it.

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.