Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature request: std::os::unix::process::CommandExt.groups() #38527

Closed
zackw opened this issue Dec 22, 2016 · 2 comments · Fixed by #72160
Closed

feature request: std::os::unix::process::CommandExt.groups() #38527

zackw opened this issue Dec 22, 2016 · 2 comments · Fixed by #72160
Assignees
Labels
C-feature-accepted Category: A feature request that has been accepted pending implementation. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@zackw
Copy link
Contributor

zackw commented Dec 22, 2016

std::os::unix::process::CommandExt already offers .uid() and .gid() methods to control the user identity of the child process (calling setuid and setgid respectively).

For complete control of Unix credentials, there should also be a way to call setgroups in the child. (setgroups is not in POSIX, but getgroups and the concept of the supplementary group list are; I would expect this not to be a portability concern.)

This feature would eliminate a use of before_exec and an unsafe block (to call libc::setgroups) from the program I'm currently writing, which is a port to Rust of a setuid C program. For illustration, this function exists in the C version:

/* A process which is setuid - that is, getuid() != 0, geteuid() == 0 -
   behaves differently than one which holds _only_ root credentials.
   We don't want the scripts acting up because of that.  This is done
   only for child processes because one of the differences is that a
   setuid program can be killed by the invoking (real) UID, which we
   do want to allow.  */
static void
become_only_root(void)
{
  if (geteuid() != 0)
    fatal("must be run as root");

  /* Discard all supplementary groups. */
  if (setgroups(0, 0))
    fatal_perror("setgroups");

  /* Set the real GID and UID to zero. This _should_ also set the
     saved GID and UID, divorcing the process completely from its
     original invoking user. */
  if (setgid(0))
    fatal_perror("setgid");
  if (setuid(0))
    fatal_perror("setuid");
}

This issue has been assigned to @slo1 via this comment.

@steveklabnik steveklabnik added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. and removed A-libs labels Mar 24, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Jul 26, 2017
@dtolnay dtolnay added C-feature-accepted Category: A feature request that has been accepted pending implementation. and removed C-feature-request Category: A feature request, i.e: not implemented / a PR. labels Nov 18, 2017
@dtolnay
Copy link
Member

dtolnay commented Nov 18, 2017

I would be prepared to consider a PR to add groups().

@slo1
Copy link
Contributor

slo1 commented Apr 30, 2020

@rustbot claim

@rustbot rustbot self-assigned this Apr 30, 2020
@bors bors closed this as completed in 22ddcd1 Jan 22, 2021
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Nov 10, 2021
Add a real tracking issue for `CommandExt::groups`

The `unstable` attribute referenced the closed RFE rust-lang#38527, so I filed tracking issue rust-lang#90747.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Nov 10, 2021
Add a real tracking issue for `CommandExt::groups`

The `unstable` attribute referenced the closed RFE rust-lang#38527, so I filed tracking issue rust-lang#90747.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-accepted Category: A feature request that has been accepted pending implementation. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants