On 05/04/2022 01:26, Linus Torvalds wrote:
On Mon, Apr 4, 2022 at 3:25 PM Kees Cook <keescook@xxxxxxxxxxxx> wrote:
[...]
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).
I think AT_EACCESS should be usable with the new EXECVE_OK too.
(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.
I think we don't. I think the only corner case that could be different
is for files that are executable, SUID and non-readable. In this case it
wouldn't matter because userspace could not read the file, which is
required for interpretation/execution. Anyway, S[GU]ID bits in scripts
are just ignored by execve and we want to follow the same semantic.
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
