[Rpm-maint] FSM hooks for rpm plugin

Panu Matilainen pmatilai at laiskiainen.org
Thu Mar 7 19:27:05 UTC 2013


On 03/07/2013 08:05 PM, Panu Matilainen wrote:
> On 03/07/2013 07:55 PM, Panu Matilainen wrote:
>> On 03/07/2013 04:27 PM, Reshetova, Elena wrote:
>>>   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.
>
> ...or we could open an fd to the temporary file and pass that along with
> the final pathname. At least all the standard metadata + file
> capabilities + selinux labels are settable via file descriptor as well
> as by path so for those the fd approach wouldn't be a problem.

...except that doesn't work for symlinks. So scratch that idea.

We need to construct both paths in commit anyway so there's no added 
cost or trouble, just needs changing fsmCommit() a little bit.
If the number of arguments starts growing too long, one option could be 
stuffing them into a struct whose pointer we hand to the hooks.
Actually, taking that a little bit further, we could hand an opaque 
"file info" handle to the hooks and force the hooks to go through an API 
to get the data, which would allow changing implementation details and 
adding more data without affecting compatibility.

And yes I'm getting ahead of the schedule here, just thinking out loud :)

	- Panu -



More information about the Rpm-maint mailing list