> 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 think this part looks good and clear, but indeed doesn't help with the below part. > 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 :) It doesn’t look anything bad to me, but you are right below that we are now more like trying to fit these hooks somewhere to keep symmetry without even being sure we need it. >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? I have been thinking about it now and I think having a hook for setting file meta data is a good idea in any case (even if we decide to keep pre/post hooks for some other purpose). It shows much clearer the purpose of the hook and it can be placed nicely exactly where metadata is set (and together with your latest commit it will be setting things right for hardlinks and etc.). Another thing is if we still need some kind of pre/post hooks for files separately... I was trying to think of use cases beyond just a logging plugin that you were referring before. One more concrete use case that I now need to look to is using plugin interface for having a package virus scanner. The idea would be that plugin would scan the selected content from the package (native executables, maybe some scripts) and if any malicious pattern is detected, then do smth about it (preferably don't install the content at all to avoid it to be started even unintentially). The difficulty here is that plugin can't scan the code by itself (especially on mobile device) since it doesn’t have a knowledge to do so, so it would need to pass the content of a file in chunks to the actual scanning engine on the platform and get result: malware detected or not. Ideally if malware is detected, as a last layer of defence it would be very good not to call fsmcommit on that file and abort the installation with error to avoid file to be placed in real filesystem, but I guess it would be even better if the scan can happen even earlier that we don't need to abort the package installation in a such nasty way. If this can be done earlier, then I guess there is no need to pre/post hooks, but if not, they might be very much needed together with the update hook that we have already dismissed (it was used only for checksum calculation). What do you think? Best Regards, Elena.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
