>> 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. Do you want to do the changes? I can also try to do it tomorrow if they aren't objections. 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
