[Rpm-maint] FSM hooks for rpm plugin

[Panu Matilainen]

On 03/12/2013 03:15 PM, Reshetova, Elena wrote:
>>> 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.
>>
>> Maybe it is the fact that I had to wake up 3am today to come back to
>> Helsinki, but I don't understand why do we need to know the final path
>> for security labels labelling? I don't think file is labelled based on
>> its destination: it is more like based on what is inside package,
>> manifest,  device security policies and etc.
>
>> It's needed for things where the label does not come from the package but
>> system policy, exactly because we lay the disk on temporary name first. At
>> least with SELinux the label is (automatically) set at file/directory
>> creation time based on its path, and rename() does not automatically relabel
>> it. And >because rpm creates the files with temporary names, the initial
>> labels are "always" wrong and we need to manually adjust them for the final
>> path.
>
> Ok, I guess you are right, assigning label by path is also a valid way, and
> there can be restrictions on this.
>
>> Of course it would be possible to just leave such things for post-commit
>> where we already have the final path, that would be exactly the same as what
>> currently happens. It just means missing the opportunity to get it right
>> early, eliminating one window of live-update breakage (and an opportunity to
>> bail >before committing the file at all on errors).
>
> No, I think we agreed already that I would be better to do it before commit,
> so we can do it right from beginning :)
>
> So, should we then conclude on having just two more hooks (pre and post
> commit) in addition to already existing hooks? I guess your previous exercise
> on it can be a base and then we can add additional parameters, like path and
> etc.

I guess that'd be the conclusion. At least until we find the next 
wrinkle in the theory :)

> Do you want to do the changes? I can also try to do it tomorrow if they aren't
> objections.

I probably should merge (at least some of) the "study" and link count 
patches first, as those change the landscape quite a bit. I'll try to do 
that as soon as the caffeine kicks in for good.

On a somewhat related note, I'm pondering about changing fsm to do 
staged removals too, ie rename before actually removing. It doesn't make 
much difference as things are now, but I've also started seriously 
thinking about changing the fsm to the model we discussed earlier where 
unpacking and setting permissions etc is first done for all files, and 
only if that succeeds completely we actually commit to renaming them all 
to the final target, and undo the whole lot if anything in unpacking failed.

...which of course would actually fundamentally change the landscape 
again: if commit is changed to consist only of renaming a file, then 
"commit" hooks would no longer the right place to do security labeling 
etc. Argh! :) In that model we'd be back to the "set metadata" hook, or 
actually two of them to preserve the possibility of doing something 
after rpm did its own business. And in that model, both pre and post 
metadata hooks should get the temp and final path as separate arguments.

	- Panu -