linux-kernel - Re: userspace pagecache management tool

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:	Sat, 03 Mar 2007 17:02:31 -0800
From:	Ray Lee <ray-lk@...rabbit.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org, Ray Lee <madrabbit@...il.com>
Subject: Re: userspace pagecache management tool

Andrew Morton wrote:
> <wonders about sys_reclaim_dentry(const char *pathname)>

Would there be any other users of it than updatedb? I'm not coming up
with much, but given that I'm not always clever, that doesn't mean much.

<thinks out loud...> A hypothetical on-demand file virus scanner is
going to hit already cached or about-to-be-cached entries by definition.
Perhaps some system audit daemon, such as tripwire. Well, that has the
same access patterns as updatedb, doesn't it: a directory at a time.
find, cp -a, the same.

So instead of sys_reclaim_dentry, how about extending fadvise to work on
the fd returned via opendir? And extending POSIX_FADV_NOREUSE on a file
fd to drop the dentry at close?

(Call me chicken; I just don't want to be the guy suggesting a new
syscall for a single or few users.)

 ~ ~

Alternately, there have been requests for a way for userspace to get
notification of all file events for indexing of data and metadata
(inotify, unfortunately, doesn't scale to a full filesystem). (cf.
http://lkml.org/lkml/2006/9/30/98 .) That'd allow an updatedb daemon to
keep the index up to date all the time, amortizing the cost. More
usefully, it'd allow a content indexing daemon to stay up to date all
the time, though inotify mostly works for those, I suppose.

(Hmm...
	ray@...enix:~$ find ~ -type d | wc -l
	14067

...right. So it probably works fine for normal people.)

Hey, waitaminute. This should be a solved problem? SELinux must have
some sort of requirement for logging file access attempts. Google, at
least, implies so. Perhaps whatever it implements could be lifted into
the core kernel without dragging the rest behind it.

Dunno. Who do we CC?

Ray
-
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/