-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Allow configuration of uid/gid/detach on processes #12085
Conversation
fn main() { | ||
unsafe { libc::setsid(); } | ||
|
||
let config = process::ProcessConfig { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like something that's ripe for FSU:
process::ProcessConfig {
program: "/bin/sh",
io: &[CreatePipe(true, false)],
detach: true,
.. default()
}
Updated with more FSU, configuration options in the |
I'm afraid the libuv implementation is pretty flawed. Things it should do but doesn't:
It's something I had on my mental TODO list but never got around to fixing. I was going to report it but it turns out someone opened an issue for it 8 days ago, see joyent/libuv#1093. |
} | ||
None => {} | ||
} | ||
if config.detach && libc::setsid() == -1 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Libuv doesn't check for setsid() errors because setsid() fails if the process is already the group leader. Probably an academic issue right after forking, though.
Interesting! Should this call Additionally, when you say to drop capabilities, it sounds reasonable to me, but I don't think I'm familiar enough with linux to know which functions do that. Do you have a particular set of functions in mind? Also, thanks for taking a look at this! |
Yes, that's correct.
Here is where things get somewhat complicated, I'm afraid... The recommended approach is to use libcap or libcap-ng but that means taking on a dependency on a library that doesn't always come with the base system. The alternative approach is to make the capget and capset system calls directly. Those system calls have gone through a number of iterations so you need to probe the kernel to figure out what is actually supported. It's not super difficult but it involves a bit of special-casing. It's probably worth mentioning that the man page for the system calls is years out of date. The current API is 0x20080522 and was added in 2.6.26. It should be mostly compatible with 0x20071026, IIRC it was added to work around ABI breakage with 32 bits programs on 64 bits kernels. About capability dropping itself, I would suggest making it opt-in or maybe opt-out but not mandatory. Sometimes you want the child process to inherit some or all of your capabilities. |
Hm, dropping capabilities sounds like it's quite complicated to do robustly, so I may defer that to a later patch (but open an issue on that). Could you explain to me a little more about |
If you cc me on the issue, I'll have a stab at it.
It's a privileged operation so it should come before the call to setuid(). Whether you call setgroups() or setgid() first doesn't matter, the ancillary groups are a property of the user, not the user's primary group.
That's right. There are cases where you might want to retain membership of some groups so it should probably be configurable. |
I have updated with a call to I also opened #12137 about dropping capabilities. |
(errno << 0) as u8, | ||
]; | ||
assert!(output.inner_write(bytes).is_ok()); | ||
unsafe { intrinsics::abort() } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
intrinsics::abort() gets lowered to UD2 or abort(), right? Seems a little harsh for what is basically a run-time error. A call to _exit() is perhaps more appropriate, if only because it won't make the process dump core.
Left one more comment but apart from that looks great to me. |
I, too, have noticed that our failed processes are causing core dumps which is a little annoying. Updated with |
ping r? |
This is blocked on joyent/libuv#1117. |
This just copies the libuv implementation for libnative which seems reasonable enough (uid/gid fail on windows). Closes rust-lang#12082
This notably includes joyent/libuv@6f62d62c in order to fix when processes fail to spawn on windows
This just copies the libuv implementation for libnative which seems reasonable enough (uid/gid fail on windows). Closes #12082
fix: fn_param completion lookup close rust-lang#12073 caused by rust-lang#12040
This just copies the libuv implementation for libnative which seems reasonable
enough (uid/gid fail on windows).
Closes #12082