|
|
Subscribe / Log in / New account

trusted_for() bounces off the merge window

trusted_for() bounces off the merge window

Posted Apr 13, 2022 2:56 UTC (Wed) by clay.sweetser@gmail.com (guest, #155278)
Parent article: trusted_for() bounces off the merge window

Is there a reason why interpreters can't just fstat() a file descriptor, and check whether the file has executable permission before running it?

I also feel like this functionality is overly focused - the whole "how can a program tell if a script should be interpreted" seems like something file metadata would be better suited for (or some central database).

As an example, on Windows both Chrome and Firefox store the "origin" of downloaded files as part of a file's metadata. Then, if a user attempts to execute such a file, the operating system displays an "are you sure you want to execute this?" prompt to the user. Putting aside whether that *particular* mechanism is worthwhile, the general idea seems close to what trusted_for is supposed to do.


to post comments

trusted_for() bounces off the merge window

Posted Apr 13, 2022 8:57 UTC (Wed) by Baughn (subscriber, #124425) [Link]

The kernel does more checks than just the execute flag. Just to name one, the filesystem may be mounted with noexec.

There are others, there may be more in the future, and handling all the checks in one spot—the kernel—makes more sense than duplicating it across a dozen potentially buggy interpreters.

trusted_for() bounces off the merge window

Posted Apr 13, 2022 23:16 UTC (Wed) by simcop2387 (subscriber, #101710) [Link] (2 responses)

> Is there a reason why interpreters can't just fstat() a file descriptor, and check whether the file has executable permission before running it?

This trivially leads to a Time-Of-Check, Time-Of-Use race condition since it's not a property of the FD but instead of the entry on the file system that has the execute permission.

trusted_for() bounces off the merge window

Posted Apr 14, 2022 0:28 UTC (Thu) by clay.sweetser@gmail.com (guest, #155278) [Link] (1 responses)

Huh, I didn't know that. I had assumed that a file descriptor kept a snapshot of the file's permissions when it was initially created, and so would not be affected by future permission changes.

trusted_for() bounces off the merge window

Posted Apr 14, 2022 2:10 UTC (Thu) by NYKevin (subscriber, #129325) [Link]

A file descriptor *does* do that, sort of. It's just that the permissions it keeps track of are O_RDONLY, O_WRONLY, etc., rather than S_IRUSR etc. (i.e. it keeps track of what you asked to do when you called open(2), not what stat(2) or access(2) would have told you). That's probably why the first version of this patch was attempting to add a flag to open(2).


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds