[Rpm-maint] FSM hooks for rpm plugin
elena.reshetova at intel.com
Thu Mar 7 14:27:44 UTC 2013
> If we now see a proper use case: like pre-commit can be used for
> content checking or even checksum calculation (I would still probably
> prefer to calculate it when it is read from archive: feels a bit safer
> that way, while I understand logically that if file is in tmp location
> and properly protected, nothing should happen to it anyway).
>Yup, if you get it directly from the "source" then nothing can be tampering
>with it, and certainly for at least checksum calculation is going to be more
>efficient if you can do it on the fly (but then rpm can do multiple checksums
>already, what's missing is exporting that functionality in a sane way). OTOH
>if >something can tamper with the file that we're creating then it can do
>nasty stuff anyway, so its perhaps a bit academic.
Yes, I agree, I guess I went too paranoid on this, which I guess happens if
you work related to security :)
>> Another concrete use-case could be a plugin to put %config files into a
>> version control of some kind. While this too would mostly be interested in
>> actually created/erased files, it might actually want to know about %ghosts
>> and such to be able to snapshot >changes made by admin that might've
>> occurred outside of the package. Guess this needs further thought, or
>> better yet, actually trying to do it, but this might be a use-case for the
>> current hooks as they are now, getting called for all files of a package
>> >whether actually touched or not.
> This almost drives us to have this set of hooks:
> 1) pre/post where they are now
> 2) metadata hook (both install and remove)
> 3) pre fsm commit hook for checking on a file content ()
> Indeed needs more thinking ....
>Naah, we just need more hooks! :P
Until we get so many of them that we can't manage them anymore and they are
going to live on their own ;)
>Seriously though, I've started thinking of that very same set of hooks so
>we're probably not too far off-target here. But now I find myself wondering
>whether 2) is actually necessary afterall: if we have pre- (and perhaps post
>too) commit hook, and can pass in some additional information as file action
>flag >bits... we could have something like FA_SETMETA bit for the entries
>where its appropriate (ie non-hardlinks I guess), and if there's a
>post-commit hook as well, the plugins can decide whether to set permissions
>before or after rpm.
If instead of hook 2) we have a post fsm commit hook that with proper
parameter, I think it can be serving the same purpose. The only thing is that
setting permissions before rpm does it isn't really possible in this case,
because before fsmcommit() file isn't in final location yet. But again, I
guess rpm would always trust its own plugins by a nature of a system setup, so
we can assume that plugins won't try to change permissions that would break
rpm query or they would break their own system in that case.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7220 bytes
Desc: not available
More information about the Rpm-maint