[Rpm-maint] FSM hooks for rpm plugin

Panu Matilainen pmatilai at laiskiainen.org
Thu Mar 7 17:55:35 UTC 2013


On 03/07/2013 04:27 PM, Reshetova, Elena wrote:
>
>
>> 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 :)

Yeah, occupational hazards. Each job has their own :)

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

Yup, rpm pretty much has to trust its plugins. OTOH... this made me 
think of another related issue: it would actually be better to set the 
permissions etc before moving the file to its final location. Currently 
we first move the file and then start setting permissions, which means 
executables and all will for a short period of time have totally 
incorrect permissions, labels and all. So if you happen to execute that 
binary during that period, who knows what will happen: it could fail to 
execute at all, execute with wrong capabilities / labels etc.

Setting the permissions before moving would fix that and also avoid 
replacing a previous file at all in case we fail to in one of the 
metadata steps. For the stock metadata the actual path makes no 
difference, but for security labels you'd want the final path though (to 
avoid having to figure out and strip the temp extension from the file), 
so it'd require passing two paths to the pre-commit hook: current and final.

	- Panu -




More information about the Rpm-maint mailing list