linux-kernel - Re: Suggestion: xtime as new inode attribute

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: <20091218145916.GI2123@thunk.org>
Date:	Fri, 18 Dec 2009 09:59:16 -0500
From:	tytso@....edu
To:	Daniel Poelzleithner <poelzi@...lzi.org>
Cc:	Jeffrey Hundstad <jeffrey.hundstad@...u.edu>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Suggestion: xtime as new inode attribute

On Fri, Dec 18, 2009 at 10:27:57AM +0100, Daniel Poelzleithner wrote:
> I think you missunderstood my intension. I wasn't thinking about a
> distribution but the installation on a system. All my systems grow in
> installed packages over time, i think that is something every hard core
> user experiences.
> You test 4-5 programs for a new task you have to do, but over time you
> only use 1-2 of them and simply forget you installed some more programs
> for this.
> With xtime there is a very clean way to find which packages are
> installed and are never used for a long time and can therefore suggested
> to the user to be uninstalled. The cleanup script of course will highly
> depend on the package system used and how the packages are organized and
> named.

This sounds like something a distro might want to do; and as such,
I'll note that if such a feature is *really* wanted, it's something
that can be done in user space --- for example, by adding a hack to
/lib/ld-linux.so which sends a ping-o-gram to a daemon that then
updates the relevant database.  That way you don't penalize every
single inode for something that is only needed for some inodes
(namely, the executables).

An extended attribute might also do, although in that case I'd
strongly suggest that the timestamp field only be updated if the last
execute time is over 24 hours old.  That way you're not constantly
updating the file system for very frequently updated executables such
as "/bin/ls".  Do we really need to know whether /bin/ls was executed
24 seconds ago as opposed to 30 minutes ago?

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