linux-kernel - Re: A desktop environment[1] kernel wishlist

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]

Message-ID: <20141104092809.GB2953@quack.suse.cz>
Date:	Tue, 4 Nov 2014 10:28:09 +0100
From:	Jan Kara <jack@...e.cz>
To:	Heinrich Schuchardt <xypron.glpk@....de>
Cc:	Jan Kara <jack@...e.cz>,
	"Sergey \"Shnatsel\" Davidoff" <sergey@...mentaryos.org>,
	Pavel Machek <pavel@....cz>, linux-kernel@...r.kernel.org
Subject: Re: A desktop environment[1] kernel wishlist

On Mon 03-11-14 19:21:43, Heinrich Schuchardt wrote:
> On 31.10.2014 10:36, Jan Kara wrote:
> >On Mon 27-10-14 20:02:51, Sergey "Shnatsel" Davidoff wrote:
> >>>If "recursive mtime" was available, would that work for you?
> >>
> >>It would work for detecting "offline" changes. I suppose recursive
> >>mtime not viable for online monitoring, mostly because detecting file
> >>renaming would be a massive PITA (and we already have fanotify with
> >>exactly this problem).
> >   Yes, you'll get only "something has changed in a subtree" information for
> >each directory. You'd then have to rescan the directory to find out what
> >has changed. But there's no simple solution for this - either you have to
> >process tons of events for busy directory tree or you have to somehow
> >reduce the amount of information provided to userspace...
> 
> If inotify_add_watch() would allow to mark a complete mount (like
> fanotify_mark() called with FAN_MOUNT) events for all files on this
> mount could be detected. If furthermore inotify_read() would return
> the complete relative path of the changed file relative to the mount
> in inotify_event->name, it would be obvious what the meaning of the
> event is.
  There are two catches though:
1) Getting of the path itself is unreliable due to presence of other fs
changes happening in parallel to you traversing the directory tree.

2) The name you get from inotify_event->name is unreliable because by the
time you read the event, directory tree may be completely different.

  These are the reasons why fanotify passes file descriptors with the
events instead of names.

  Also for mountpoint wide notification your app has to be much faster
processing events so that the event queue doesn't overflow (and thus forces
you to do full rescan). fanotify deals with this by not limiting event
queue length at all but that's one of the reason why it's restricted to
CAP_SYS_ADMIN users.

  So all in all I would find it better to extend fanotify to provide
directory events (that was originally planned but the support was dropped
due to technical issues), solve problems with unlimited event queues, add
some permission checking for passed file descriptors and audit fanotify to
verify it's otherwise safe for regular users.

								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
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/