On 03/07/2013 04:27 PM, Reshetova, Elena wrote:
If we now see a proper use case: like pre-commit can be used for
content checking or even checksum calculation (I would still probably
prefer to calculate it when it is read from archive: feels a bit safer
that way, while I understand logically that if file is in tmp location
and properly protected, nothing should happen to it anyway).
Yup, if you get it directly from the "source" then nothing can be tampering
with it, and certainly for at least checksum calculation is going to be more
efficient if you can do it on the fly (but then rpm can do multiple checksums
already, what's missing is exporting that functionality in a sane way). OTOH
if >something can tamper with the file that we're creating then it can do
nasty stuff anyway, so its perhaps a bit academic.
Yes, I agree, I guess I went too paranoid on this, which I guess happens if
you work related to security :)
Yeah, occupational hazards. Each job has their own :)
Another concrete use-case could be a plugin to put %config files into a
version control of some kind. While this too would mostly be interested in
actually created/erased files, it might actually want to know about %ghosts
and such to be able to snapshot >changes made by admin that might've
occurred outside of the package. Guess this needs further thought, or
better yet, actually trying to do it, but this might be a use-case for the
current hooks as they are now, getting called for all files of a package
>whether actually touched or not.
This almost drives us to have this set of hooks:
1) pre/post where they are now
2) metadata hook (both install and remove)
3) pre fsm commit hook for checking on a file content ()
Indeed needs more thinking ....
Naah, we just need more hooks! :P
Until we get so many of them that we can't manage them anymore and they are
going to live on their own ;)
Seriously though, I've started thinking of that very same set of hooks so
we're probably not too far off-target here. But now I find myself wondering
whether 2) is actually necessary afterall: if we have pre- (and perhaps post
too) commit hook, and can pass in some additional information as file action
flag >bits... we could have something like FA_SETMETA bit for the entries
where its appropriate (ie non-hardlinks I guess), and if there's a
post-commit hook as well, the plugins can decide whether to set permissions
before or after rpm.
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.
- Panu -
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
