On Tue, 2015-12-01 at 21:58 +0200, Petko Manolov wrote:
> First off, this is not a real patch rather than my idea in a C form. I feel
> uncertain about a few points:
>
> 0) does keyrings keep a timestamp when created or last updated? David?
>
> 1) is jiffies(_64) the best thing to use for timestamping?
> sched_clock() is known to stop at suspend/sleep.
"struct key" defines a couple of time stamps, but none of them are what
we need.
union {
time_t expiry; /* time at which key
expires (or 0) */
time_t revoked_at; /* time at which key was
revoked */
};
time_t last_used_at; /* last time used for
LRU keyring discard */
> 2) the code below is not optimal - it removes the node from the RB tree
> and then walks it again to find the right place. Mimi, any
> objections to restructure integrity_inode_get() for speed when
> dealing with timestamps?
Instead of removing the iint's from the RB tree, how about just clearing
the cached appraised info in the iint. Something like:
iint->flags &= ~(IMA_APPRAISED | IMA_APPRAISED_SUBMASK);
> 0) is crucial. If there is no such thing as "time of the last update" for
> keyrings i guess we'll either have to implement it or use another mechanism
> to
> get similar result.
For this usecase, we need a timestamp for the last time a key was added
to the keyring.
Mimi
--
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html