Messages in this thread | | | From | David Laight <> | Subject | RE: [PATCH v7 0/7] Add support for O_MAYEXEC | Date | Tue, 11 Aug 2020 08:09:10 +0000 |
| |
> On 11/08/2020 00:28, Al Viro wrote: > > On Mon, Aug 10, 2020 at 10:09:09PM +0000, David Laight wrote: > >>> On Mon, Aug 10, 2020 at 10:11:53PM +0200, Mickaël Salaün wrote: > >>>> It seems that there is no more complains nor questions. Do you want me > >>>> to send another series to fix the order of the S-o-b in patch 7? > >>> > >>> There is a major question regarding the API design and the choice of > >>> hooking that stuff on open(). And I have not heard anything resembling > >>> a coherent answer. > >> > >> To me O_MAYEXEC is just the wrong name. > >> The bit would be (something like) O_INTERPRET to indicate > >> what you want to do with the contents. > > The properties is "execute permission". This can then be checked by > interpreters or other applications, then the generic O_MAYEXEC name.
The english sense of MAYEXEC is just wrong for what you are trying to check.
> > ... which does not answer the question - name of constant is the least of > > the worries here. Why the hell is "apply some unspecified checks to > > file" combined with opening it, rather than being an independent primitive > > you apply to an already opened file? Just in case - "'cuz that's how we'd > > done it" does not make a good answer...
Maybe an access_ok() that acts on an open fd would be more appropriate. Which might end up being an fcntrl() action. That would give you a full 32bit mask of options.
David
- Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
| |