On Mon, Apr 4, 2022 at 3:25 PM Kees Cook <keescook@xxxxxxxxxxxx> wrote:
>
> Maybe. I defer to Mickaël here, but my instinct is to avoid creating an
> API that can be accidentally misused. I'd like this to be fd-only based,
> since that removes path name races. (e.g. trusted_for() required an fd.)
Some people want pathnames. Think things like just the PATH thing just
to find the right executable in the first place.
For things like that, races don't matter, because you're just trying
to find the right path to begin with.
> I think this already exists as AT_EACCESS? It was added with
> faccessat2() itself, if I'm reading the history correctly.
Yeah, I noticed myself, I just hadn't looked (and I don't do enough
user-space programming to be aware of if that way).
> > (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 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.
Linus
