linux-kernel - Re: [PATCH 2/4] fanotify: Add pids to events

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 15 Jan 2010 16:12:09 +0100
From:	Andreas Gruenbacher <agruen@...e.de>
To:	Matthew Helsley <matt.helsley@...il.com>
Cc:	Eric Paris <eparis@...hat.com>, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, viro@...iv.linux.org.uk,
	hch@...radead.org, containers@...ts.linux-foundation.org,
	matthltc@...ibm.com,
	Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>,
	Oleg Nesterov <oleg@...hat.com>
Subject: Re: [PATCH 2/4] fanotify: Add pids to events

On Friday 15 January 2010 05:41:10 Matthew Helsley wrote:
> Eric, you never replied to my point about pid namespaces
> (http://lkml.org/lkml/2009/7/1/2). I'm still concerned that it's a
> problem for this patch. I've cc'd some pid namespace folks, listed the
> problems, and some alternative solutions (where I could think of any)
> below:
> 
> 1. Since fanotify doesn't hold a reference to the struct pid then the
> pid can become stale before the event is acted upon.
>     solution a: Just ignoring this problem, like other interfaces
> often do, is probably ok.
>     ... ?
>     solution z: Seems to require taking a reference to the pid and
> giving userspace a way to drop the reference after it's done using
> this value to refer to the process (yuck).

struct fsnotify_event->tgid does hold a reference to the appropriate struct 
pid.  The reference is released when that struct fsnotify_event is freed.

> 2. If the event recipient does a clone and enters a new pidns the pid
> number will be incorrect without any indication.

No, if a process has a pid within the listener's namespace the listener will 
see this pid; otherwise, the resulting pid value is 0.

> 3. If the listening process is not in the same or an ancestor pid
> namespace of the triggering process then there is no correct pid
> corresponding to the event.

Indeed, if the listener is not in the same or an ancestor pid namespace, the 
pid in the event will end up as 0.  The event still indicates that something 
has happened to a file the listener is interested in though, it's just unclear 
who triggered the event.  I don't see a problem with that though -- do you?

Thanks,
Andreas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/