On Mon, Apr 04, 2022 at 04:26:44PM -0700, Linus Torvalds wrote: > > > (a) "what about suid bits that user space cannot react to" > > > > What do you mean here? Do you mean setid bits on the file itself? > > Right. > > Maybe we don't care. > > Maybe we do. > > Is the user-space loader going to honor them? Is it going to ignore > them? I don't know. And it actually interacts with things like > 'nosuid', which the kernel does know about, and user space has a hard > time figuring out. So there *used* to be suidperl which was a setuid version of perl with some extra security checks. (See [1] for more details.) The suidperl binary would be used by #!/usr/bin/perl so it could honor setuid bits on perl scripts, but it was deprecated in Perl 5.8 and removed in Perl 5.12 in 2010[2]. [1] https://mattmccutchen.net/suidperl.html [2] https://metacpan.org/release/SHAY/perl-5.20.2/view/pod/perl5120delta.pod#Deprecations So it's possible that the user-space loader might try to honor them, and if there was such an example "in the field", it might be nice if there was a way for the kernel to advise userspace about the nosuid. But I'm not aware of any other shell script interpreter that tried do what perl did with suidperl. > So if the point is "give me an interface so that I can do the same > thing a kernel execve() loader would do", then those sgid/suid bits > actually may be exactly the kind of thing that user space wants the > kernel to react to - should it ignore them, or should it do something > special when it sees that they are set? > > I'm not saying that they *should* be something we care about. All I'm > saying is that I want that *discussion* to happen. I'm not convinced we should. I suppose *if* the shell script was suid, *and* the file system was mounted nosuid, then the check could return false, and that would be mostly harmless even if the script interpreter didn't support setuid. But it's extra complexity, and in theory it could break a setuid script, where the setuid bit was previously a no-op, and it now might cause a problem for that user. - Ted
