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 -
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
