On Thu 04-12-25 14:03:27, Bernd Edlinger wrote:
On 12/4/25 06:49, Al Viro wrote:
On Wed, Dec 03, 2025 at 02:16:29PM +0100, Bernd Edlinger wrote:
Hmm, yes, that looks like an issue.
I would have expected the security engine to look at bprm->filenanme especially in the case, when bprm->interp != bprm->filename, and check that it is not a sym-link with write-access for the current user and of course also that the bprm->file is not a regular file which is writable by the current user, if that is the case I would have expected the secuity engine to enforce non-new-privs on a SUID executable somehow.
Check that _what_ is not a symlink? And while we are at it, what do write permissions to any symlinks have to do with anything whatsoever?
When we execve a normal executable, we do open the binary file with deny_write_access so this might allow the security engine to inspaect the binary, before it is used.
That would be seriously flawed IMO because there are lot of cases where code is executed without deny_write_access() - like shared libraries, code loaded by interpreter, and probably more.
However this behavior has changed recently, now it has some exceptions, where even this behavior is no longer guaranteed for binary executables, due to commit 0357ef03c94ef835bd44a0658b8edb672a9dbf51, but why? I have no idea...
Because for hierarchical storage implementation you may need to fill in the executable data from remote storage on demand and the deny_write_access logic was making this impossible. We even tried to completely remove the deny_write_access logic exactly because it has very limited use and complicates things (commit 2a010c412853 ("fs: don't block i_writecount during exec")) but that had to be reverted because some userspace depends on the ETXTBUSY behavior.
Honza