[Rpm-maint] FSM hooks for rpm plugin

Reshetova, Elena elena.reshetova at intel.com
Wed Jan 9 18:19:40 UTC 2013

>Hmm, do you mean FSM_INIT hook is the "pre" hook and FSM_COMMIT the "post"
hook, or that both INIT and COMMIT have their own separate pre- and

Sorry for being unclear, I just meant that for FSM it is better to have two
hooks before file is put to the filesystem and after as opposite to one

>If the former, its not symmetric as fsmCommit() does not get called on
removed files, and there are almost certainly other (at least error) paths
where fsmCommit() wont get called. Of course we can make the removal-path
call FSM_COMMIT hook despite not being in fsmCommit(), but ... perhaps the
>hook names should follow the pre/post convention then, eg FSM_FILE_PRE and
>In either case, I think file removals should be covered by the hooks
>too: you might want to strip security-related labels or such before
actually removing, eg to prevent "leaks" through hardlinks (see
>removeSBITS() in fsm.c).

I didn't think of removal cases originally, this is really a good point that
we should take them into account, too. The safe choice won't be to strip the
security-related label in this case, because in hardlink case this might
open a hole in a system. For example, if my package has file
"sensitive_data" and plugin labelled it "Sensitive" upon installation.
During run-time only processes that have access to "Sensitive" can
read/write this file. But suppose attacker would make a hard link to the
file and then somehow initiate a package uninstall. Plugin will remove the
file (the first path to it), strip the label and then attacker can access
the file via hardlink because file isn't protected with the correct label
anymore. Moreover in MAC systems you can't just remove a label, since
everything has to have a label, you can only change label. So, I guess the
correct way in this case would be to change the label to some special
"Isolated" label that no one has any rights to read/write/execute. Then even
if hardlink is left, it is unusable after package uninstallation. 

>Perhaps the hooks should take an additional argument to indicate the
operation - create/remove at least, but depending on other things skip might
be needed as well.

OK, so then I will make two hooks FSM_FILE_PRE and FSM_FILE_POST that would
be always called for any file (both install and remove). I will pass the
info about the operation type to the hook together with path and mode. 
I guess FSM_FILE_PRE can be called just after FsmInit(), but what would be
the correct place for FSM_FILE_POST? Seems like I would have to call it
twice based on operation performed either in commit() or unlink().

>Yup, path and mode is minimalism to the extreme :) Being able to sanely 
>pass rpmfi objects would be nice but it requires bunch of other changes 
>to happen first.

Yes, I guess other arguments would have to wait for changes to come. 

>Rpm checks signatures when reading packages/headers, so unless signature 
>checking is disabled, the headers that were fed to 
>rpmtsAddInstall/EraseElement() are already signature checked. With 
>caveats. Eg. while rpm generally assumes the re-opened package within 
>transaction is the same thing as initially added to the transaction, 
>technially the callback can hand us something else. In which case things 
>are likely to go not very well :) And then there's the fact that rpm 
>doesn't have a mechanism to actually enforce signed packages only, etc.

This is smth I didn't know about rpm: never looked into that part before:
was thinking that signature is checked per package one by one. 

>But this reminds me...

>The root issue with MSM delaying conflict checking until its basically 
>too late was insufficient information available during rpmtsPrepare(): 
>at that point rpm has long since ditched the header object, which you'd 
>need to get the MSM-specific data to decide if something should be 
>allowed or not. And the next time the header is available is indeed only 
>inside the psm/fsm stage deep inside already running transaction.

>I think we need to have additional hook(s) in the 
>rpmtsAddInstall/EraseElement() area where the full header is available 
>for the cases where additional data is needed by plugins. There's just a 
>slight problem: these hooks would be called long before the plugins are 
>currently even initialized, so the plugin initialization would have to 
>change quite significantly.

Yes, I guess if we go this path, then plugin initialization would have to
happen in rpmtsCreate(). Currently there is only memory for pointer
allocated, but I guess nothing prevents us from doing the loading of plugins
here too. What do you think?
I can move the loading here from rpmtsRun() and also then add hooks in
addinstall and EraseElement. So, these hooks will be called per each package
in transaction and before even transaction starts, and then from header h I
can pass the needed info to the hook, which would make the plugin to be
aware of sw source earlier than now. So, then the conflict hook is called
later, it has all the needed info and if there are some conflicts it can't
allow, it can stop the transaction in advance. 

This sounds all good, but there is still small problem left. I still would
like to enforce my own policy on what signatures are ok and not and what are
the action if signature verification fails. Do you think this should be the
part of new hook in addInstallElement? This would be logical since it again
allows us to fail transaction way before it started (if needed) without
installing some packages from it first. In this case verify hook isn't
needed at all. 

>If you're referring to the unified package object absraction I think I 
>mentioned at some point (related to the mess of stuff currently needed 
>for file conflict calculations), that's basically just a fuzzy cloud 
>dream at the moment. It'd require massive changes to rpm internals (and 
>API as well), and I dont have much of a clue when that might happen in 
>reality so we'll just have to get by what we got now, more or less.

OK, thank you for explaining. It was hard to understand the transition to
this object, but I guess it is normal if it still in "fuzzy cloud dream
state" :)

>Sure, just send what you have, even if only as a basis of further 
>discussion. Looking at an actual patch helps highlighting the bizarre 
>dark corners of rpm that need dealing with :)

It seems that talking to you first is better than writing patches :) I guess
now we might have 3 different patches in a queue: FSM hooks, changing the
plugin initialization, and new hooks for add/eraseElement. 
Do you have order preferences for this?

Btw, not related to hooks. I am using rpm from master on my host machine for
testing hooks and etc. Also, I have been porting plugin to your latest dev.
release since we are finally moving to a new rpm (happiness!). 
But then it comes to using rpm from master it seems that rpm2cpio gets
broken on my machine: I get plenty of cpio: Malformed number <garbage>. I
discover it when running gbs build for our Tizen environment with rpm from
master. I think this is smth related to lzma, but I don't really understand
what happens. Could it be that it gets disabled for some reason or I didn't
use correct configure options when compiling rpm? 

Best Regards,

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7220 bytes
Desc: not available
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20130109/4be83ce6/attachment.p7s>

More information about the Rpm-maint mailing list