Date: Mon, 17 Nov 2014 13:30:10 -0500 From: Rich Felker <dalias@...ifal.cx> To: David Drysdale <drysdale@...gle.com> Cc: Andy Lutomirski <luto@...capital.net>, libc-alpha <libc-alpha@...rceware.org>, musl@...ts.openwall.com, Andrew Morton <akpm@...ux-foundation.org>, Linux API <linux-api@...r.kernel.org>, Christoph Hellwig <hch@...radead.org> Subject: Re: Re: [RFC] Possible new execveat(2) Linux syscall On Mon, Nov 17, 2014 at 03:42:15PM +0000, David Drysdale wrote: > I'm not familiar with O_EXEC either, I'm afraid, so to be clear -- does > O_EXEC mean the permission check is explicitly skipped later, at execute > time? In other words, if you open(O_EXEC) an executable then remove the > execute bit from the file, does a subsequent fexecve() still work? Yes. It's just like how read and write permissions work. If you open a file for read then remove read permissions, or open it for write then remove write permissions, the existing permissions to the open file are not lost. Of course open with O_EXEC/O_SEARCH needs to fail if the caller does not have +x access to the file/directory at the time of open. > If it does, then from an implementation perspective that presumably implies > the need for a record of the permission check in the struct file (and that > this property would be inherited by any dup()ed file descriptors). From a > security perspective, having a gap between time-of-check and time-of-use > always sounds worrying... This record already exists for read and write. All that's needed is for an extra bit to be added to record exec/search permission. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.