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 for Android: free password hash cracker in your pocket

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

Message-ID: <CABaUXi4CkosMHDuNMMhTg3Ahrts5re-rJsPxN4JNp0Wu3AbKdA@mail.gmail.com>
Date:	Mon, 27 Oct 2014 20:02:51 +0400
From:	"Sergey \"Shnatsel\" Davidoff" <sergey@...mentaryos.org>
To:	Pavel Machek <pavel@....cz>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: A desktop environment[1] kernel wishlist

> 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).

Another approach to offline monitoring is using things like btrfs
changelogs - e.g. incremental "btrfs send", but I don't think that's
viable for other filesystems and I don't know how efficient it is even
on btrfs.

Actually, being able to read btrfs changelog from userspace more or
less as it happens (<200ms latency on commodity x86) would fulfill our
requirements for online VFS monitoring facility, and we could use
"btrfs send" approach for replaying offline changes. The good thing
about this approach is that it can use a fixed-size buffer for feeding
the info in userspace - if userspace can't keep up, the data is not
lost but recorded to the filesystem and can be retrieved from it
later. In this case we'd be tied to a specific filesystem, but that's
worlds better than nothing at all.

-- 
Sergey "Shnatsel" Davidoff
--
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/