[lkml]   [2013]   [Jan]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] open(2): document O_PATH
On Thu, May 03, 2012 at 03:11:56PM +0100, Al Viro wrote:
> On Thu, May 03, 2012 at 07:34:35PM +0530, Aneesh Kumar K.V wrote:
> > I looked at dnotify_flush, they remove markers on an inode.
> > But then it also checks for filp to match. So I am not sure
> > whether skipping dnotify_flush for O_PATH descriptor have any impact. We
> > can't use O_PATH descriptor for dnotify fcntl any way. So in
> > dnotify_flush we will not match the filp.
> >
> > Viro,
> >
> > Any reason why we skip dnotify_flush ?
> See your last sentence above - why bother finding the mark, scanning the
> list, etc. when we know that there won't be any matches?

[Apologies for replying to the wrong posting, but this is the closest thing
thread-wise to what I wanted to reply to that I've got sitting in my mailbox]

The rules are:
* syscalls acting purely on descriptor level are allowed - close(),
dup(), dup2(), dup3(), fcntl(F_DUPFD{,_CLOEXEC}), fcntl(F_[SG]ETFD),
fcntl(F_GETFL), passing descriptors in SCM_RIGHTS datagrams)
* syscalls using the descriptor just to indicate a location in
the tree - *at() family, fchdir(), fstat()
The list might get expanded - for example, fstatfs() arguably belongs to the
second group. The approach had been conservative - the second group gets
expanded on per-case basis. E.g. anything requiring the file to have
been opened for write is *not* a candidate, so it really has to be reviewed
separately for each syscall of that sort.

As far as dnotify and POSIX locks go, close() (and replacing dup2(), etc.)
are irrelevant - the rules are exactly as usual. All dnotify watches or
POSIX locks associated with that opened file get evicted; it's just that
there is no way to *set* them on O_PATH descriptors in the first place.
We might eventually allow fcntl(F_NOTIFY) on them, but I'm not sure there's
any good reason to do so; allowing to use them for setting POSIX locks is
almost certainly a bad idea wrt security.

The test in filp_close() is just an optimization - if/when we allow F_NOTIFY
on O_PATH descriptors, the same commit will need to make the call of
dnotify_flush() in filp_open() unconditional. All there is to it...

 \ /
  Last update: 2013-01-08 20:41    [W:0.051 / U:3.724 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site