| Message ID | 20200908075956.1069018-1-mic@digikod.net (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add support for AT_INTERPRETED (was O_MAYEXEC) | expand |
On Tue, Sep 08, 2020 at 09:59:53AM +0200, Mickaël Salaün wrote: > Hi, > > This height patch series rework the previous O_MAYEXEC series by not > adding a new flag to openat2(2) but to faccessat2(2) instead. As > suggested, this enables to perform the access check on a file descriptor > instead of on a file path (while opening it). This may require two > checks (one on open and then with faccessat2) but it is a more generic > approach [8]. Again, why is that folded into lookup/open/whatnot, rather than being an operation applied to a file (e.g. O_PATH one)?
On 08/09/2020 20:50, Al Viro wrote: > On Tue, Sep 08, 2020 at 09:59:53AM +0200, Mickaël Salaün wrote: >> Hi, >> >> This height patch series rework the previous O_MAYEXEC series by not >> adding a new flag to openat2(2) but to faccessat2(2) instead. As >> suggested, this enables to perform the access check on a file descriptor >> instead of on a file path (while opening it). This may require two >> checks (one on open and then with faccessat2) but it is a more generic >> approach [8]. > > Again, why is that folded into lookup/open/whatnot, rather than being > an operation applied to a file (e.g. O_PATH one)? > I don't understand your question. AT_INTERPRETED can and should be used with AT_EMPTY_PATH. The two checks I wrote about was for IMA.
On Wed, Sep 09, 2020 at 09:19:11AM +0200, Mickaël Salaün wrote: > > On 08/09/2020 20:50, Al Viro wrote: > > On Tue, Sep 08, 2020 at 09:59:53AM +0200, Mickaël Salaün wrote: > >> Hi, > >> > >> This height patch series rework the previous O_MAYEXEC series by not > >> adding a new flag to openat2(2) but to faccessat2(2) instead. As > >> suggested, this enables to perform the access check on a file descriptor > >> instead of on a file path (while opening it). This may require two > >> checks (one on open and then with faccessat2) but it is a more generic > >> approach [8]. > > > > Again, why is that folded into lookup/open/whatnot, rather than being > > an operation applied to a file (e.g. O_PATH one)? > > I don't understand your question. AT_INTERPRETED can and should be used > with AT_EMPTY_PATH. The two checks I wrote about was for IMA. Al is saying you should add a new syscall, not try to fold it into some existing syscall. I agree with him. Add a new syscall, just like you were told to do it last time.
On Wed, Sep 09, 2020 at 09:19:11AM +0200, Mickaël Salaün wrote: > > On 08/09/2020 20:50, Al Viro wrote: > > On Tue, Sep 08, 2020 at 09:59:53AM +0200, Mickaël Salaün wrote: > >> Hi, > >> > >> This height patch series rework the previous O_MAYEXEC series by not > >> adding a new flag to openat2(2) but to faccessat2(2) instead. As > >> suggested, this enables to perform the access check on a file descriptor > >> instead of on a file path (while opening it). This may require two > >> checks (one on open and then with faccessat2) but it is a more generic > >> approach [8]. > > > > Again, why is that folded into lookup/open/whatnot, rather than being > > an operation applied to a file (e.g. O_PATH one)? > > > > I don't understand your question. AT_INTERPRETED can and should be used > with AT_EMPTY_PATH. The two checks I wrote about was for IMA. Once more, with feeling: don't hide that behind existing syscalls. If you want to tell LSM have a look at given fs object in a special way, *add* *a* *new* *system* *call* *for* *doing* *just* *that*.
On 09/09/2020 19:08, Matthew Wilcox wrote: > On Wed, Sep 09, 2020 at 09:19:11AM +0200, Mickaël Salaün wrote: >> >> On 08/09/2020 20:50, Al Viro wrote: >>> On Tue, Sep 08, 2020 at 09:59:53AM +0200, Mickaël Salaün wrote: >>>> Hi, >>>> >>>> This height patch series rework the previous O_MAYEXEC series by not >>>> adding a new flag to openat2(2) but to faccessat2(2) instead. As >>>> suggested, this enables to perform the access check on a file descriptor >>>> instead of on a file path (while opening it). This may require two >>>> checks (one on open and then with faccessat2) but it is a more generic >>>> approach [8]. >>> >>> Again, why is that folded into lookup/open/whatnot, rather than being >>> an operation applied to a file (e.g. O_PATH one)? >> >> I don't understand your question. AT_INTERPRETED can and should be used >> with AT_EMPTY_PATH. The two checks I wrote about was for IMA. > > Al is saying you should add a new syscall, not try to fold it into > some existing syscall. > > I agree with him. Add a new syscall, just like you were told to do it > last time. > OK, but I didn't receive a response for my proposition to extend faccessat2(2).
On 09/09/2020 19:13, Al Viro wrote: > On Wed, Sep 09, 2020 at 09:19:11AM +0200, Mickaël Salaün wrote: >> >> On 08/09/2020 20:50, Al Viro wrote: >>> On Tue, Sep 08, 2020 at 09:59:53AM +0200, Mickaël Salaün wrote: >>>> Hi, >>>> >>>> This height patch series rework the previous O_MAYEXEC series by not >>>> adding a new flag to openat2(2) but to faccessat2(2) instead. As >>>> suggested, this enables to perform the access check on a file descriptor >>>> instead of on a file path (while opening it). This may require two >>>> checks (one on open and then with faccessat2) but it is a more generic >>>> approach [8]. >>> >>> Again, why is that folded into lookup/open/whatnot, rather than being >>> an operation applied to a file (e.g. O_PATH one)? >>> >> >> I don't understand your question. AT_INTERPRETED can and should be used >> with AT_EMPTY_PATH. The two checks I wrote about was for IMA. > > Once more, with feeling: don't hide that behind existing syscalls. > If you want to tell LSM have a look at given fs object in a special > way, *add* *a* *new* *system* *call* *for* *doing* *just* *that*. > Fine, I'll do it. It will look a lot like this one though.
On Wed, Sep 09, 2020 at 06:08:51PM +0100, Matthew Wilcox wrote: > On Wed, Sep 09, 2020 at 09:19:11AM +0200, Mickaël Salaün wrote: > > > > On 08/09/2020 20:50, Al Viro wrote: > > > On Tue, Sep 08, 2020 at 09:59:53AM +0200, Mickaël Salaün wrote: > > >> Hi, > > >> > > >> This height patch series rework the previous O_MAYEXEC series by not > > >> adding a new flag to openat2(2) but to faccessat2(2) instead. As > > >> suggested, this enables to perform the access check on a file descriptor > > >> instead of on a file path (while opening it). This may require two > > >> checks (one on open and then with faccessat2) but it is a more generic > > >> approach [8]. > > > > > > Again, why is that folded into lookup/open/whatnot, rather than being > > > an operation applied to a file (e.g. O_PATH one)? > > > > I don't understand your question. AT_INTERPRETED can and should be used > > with AT_EMPTY_PATH. The two checks I wrote about was for IMA. > > Al is saying you should add a new syscall, not try to fold it into > some existing syscall. > > I agree with him. Add a new syscall, just like you were told to do it > last time. Sure, we'll do it. In the meantime, could we at least get an explanation about why using faccessat2() instead of a new syscall is wrong? I could see the reasons for separating the exec checks from the file opening, but this time I don't understand. Is it because it brings too much complexity to do_faccessat()?
On Wed, 9 Sep 2020, Al Viro wrote: > On Wed, Sep 09, 2020 at 09:19:11AM +0200, Mickaël Salaün wrote: > > > > On 08/09/2020 20:50, Al Viro wrote: > > > On Tue, Sep 08, 2020 at 09:59:53AM +0200, Mickaël Salaün wrote: > > >> Hi, > > >> > > >> This height patch series rework the previous O_MAYEXEC series by not > > >> adding a new flag to openat2(2) but to faccessat2(2) instead. As > > >> suggested, this enables to perform the access check on a file descriptor > > >> instead of on a file path (while opening it). This may require two > > >> checks (one on open and then with faccessat2) but it is a more generic > > >> approach [8]. > > > > > > Again, why is that folded into lookup/open/whatnot, rather than being > > > an operation applied to a file (e.g. O_PATH one)? > > > > > > > I don't understand your question. AT_INTERPRETED can and should be used > > with AT_EMPTY_PATH. The two checks I wrote about was for IMA. > > Once more, with feeling: don't hide that behind existing syscalls. > If you want to tell LSM have a look at given fs object in a special > way, *add* *a* *new* *system* *call* *for* *doing* *just* *that*. It's not just for LSM, though, and it has identical semantics from the caller's POV as faccessat().