[Rpm-maint] FSM hooks for rpm plugin

Panu Matilainen pmatilai at laiskiainen.org
Fri Mar 1 11:53:11 UTC 2013


On 02/27/2013 11:14 AM, Panu Matilainen wrote:
> On 02/27/2013 08:18 AM, Reshetova, Elena wrote:
>>
>>> Right, no surprises: there is an issue with hard links :)
>>
>> Oh, this is smth I should have actually remembered, but forgot :( I
>> saw the
>
> I forgot the specifics of hardlinks too, no worries :)
>
>> issue a while back on our system setup, but since from security labelling
>> hard links aren't interesting (security context should be set on a file
>> itself, not a hard link), I simply didn't call hooks for hard links.
>> But I
>> agree that it might be important to know that they will be created and
>> I guess
>> in this case we would need to know when and where it goes. Actually
>> not from
>> labelling point of view, but from general security, a tightly configured
>> system might have restrictions on where files/dirs/links are created. For
>> example, it might not allow creating hard links in certain paths (in
>> order for
>> system to stay well arranged or for example in order to avoid untrusted
>> packages creating hard links in sensitive dirs). The thing here is
>> that such a
>> check should be probably performed before we start to run FSM and
>> unpacking
>> the archive (for the same reason as conflicts).
>
> Yup, restrictions would need to be enforced early on, FSM is too late.
>
>> So, then if we consider that
>> labelling and policy enforcement aren't valid use cases here, we only
>> have
>> informational use case left: plugin wants to know the links and their
>> location
>> as for any other files. Should we then create separate hook/call same
>> hook
>> (with modified parameters) actually at the moment when links are created
>> (later on)?
>
> Hmm. Good question...  arranging pre/post-commit in fsmCommit() hooks
> should be trivial. Although by now, I'm actually starting to wonder
> whether it really makes sense to call any hooks for skipped files
> afterall. The "informational use cases" could just go and look at the
> package file list and their states from psm pre/post-hooks.
>
> Looking at this, I just realized that rpm is currently doing chmod(),
> chown() and all for each hardlink it creates, which just doesn't make
> sense because ... by the very definition of a hardlink, it doesn't.
> Probably worth fixing regardless of what we end up doing with hooks, eg
> additional "setmeta" argument to fsmCommit() whether it should just
> create or set the additional metadata as well, and have pre/post-commit
> hooks get that so plugins get notified of all file creations but also
> can avoid redundant setting of labels etc.

FWIW, this part is now pushed to git master, ie for hardlink sets the 
metadata (permissions etc) is only set once.

> I'm going to poke around with this a bit to see what would make most
> sense, now that I have sufficient selinux plugin code to test it with.
> Like said, I'm starting to have second thoughts on the skipped files, so
> I'll probably look at changing the existing hooks to the "commit model"
> rather than add more: for actually created (and removed) files, the hook
> semantics would be rather obvious. With skipped (and some delayed and
> whatnot) files it gets far more convoluted. If it turns out the plugins
> *really* need the skipped file info as well, we can always add (back)
> more hooks later on :)

Attached is one "study" into this direction, ie hooks are only called 
for files that are actually acted upon. This is a total diff of multiple 
commits with some semi-unrelated changes, so its more useful to look at 
the resulting code more than the diff itself.

I'm not going to push this stuff until further discussion + thought, if 
at all: the more I look and think about this stuff, something about it 
all just doesn't feel quite right :)

Perhaps the problem is the hooks are too generic for their own good now. 
One possibility (that's perhaps more clear with the other cleanup work 
in the patch) is to have a "set additional file metadata" hook, as 
*that* is what our current use-cases (SELinux and MSSF) want to do. 
Which should actually be as simple as adding something like this after 
all the fsmChown(), fsmChmod() etc calls:

     if (!rc)
	rc = rpmpluginsCallFsmFileMeta(fsm->plugins, fsm->path, ...)

And actually that brings it right next to where fsmSetSELabel() is 
currently getting called. I've a feeling a symmetric pre/post-hook pair 
doesn't actually make sense for this particular purpose, it only 
complicates things unnecessarily.

Thoughts?

	- Panu -
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fsm-hooks-hack-0.patch
Type: text/x-patch
Size: 10559 bytes
Desc: not available
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20130301/b78f14da/attachment.bin>


More information about the Rpm-maint mailing list