Should I expect output like this from rpm -V from a fresh install, even if I haven't touched the policy myself?
[root@blane ~]# rpm -V selinux-policy-targeted .......TC c /etc/selinux/targeted/contexts/default_contexts .......TC c /etc/selinux/targeted/contexts/default_type .......TC c /etc/selinux/targeted/contexts/failsafe_context ..5....TC c /etc/selinux/targeted/contexts/files/file_contexts .......TC c /etc/selinux/targeted/contexts/files/media .......TC c /etc/selinux/targeted/contexts/initrc_context .......TC c /etc/selinux/targeted/contexts/removable_context .......TC c /etc/selinux/targeted/contexts/userhelper_context .......TC c /etc/selinux/targeted/contexts/users/root ..5....T. c /etc/selinux/targeted/policy/policy.18
Since policy/policy.18 is marked %config(noreplace) the new policy.18 file is installed as policy.18.rpmnew and hence it seems manual intervention is needed to load the new policy, it's not a simple rpm -U or up2date run away - is this desirable?
joe
Joe Orton wrote:
Should I expect output like this from rpm -V from a fresh install, even if I haven't touched the policy myself?
[root@blane ~]# rpm -V selinux-policy-targeted .......TC c /etc/selinux/targeted/contexts/default_contexts .......TC c /etc/selinux/targeted/contexts/default_type .......TC c /etc/selinux/targeted/contexts/failsafe_context ..5....TC c /etc/selinux/targeted/contexts/files/file_contexts .......TC c /etc/selinux/targeted/contexts/files/media .......TC c /etc/selinux/targeted/contexts/initrc_context .......TC c /etc/selinux/targeted/contexts/removable_context .......TC c /etc/selinux/targeted/contexts/userhelper_context .......TC c /etc/selinux/targeted/contexts/users/root ..5....T. c /etc/selinux/targeted/policy/policy.18
Since policy/policy.18 is marked %config(noreplace) the new policy.18 file is installed as policy.18.rpmnew and hence it seems manual intervention is needed to load the new policy, it's not a simple rpm -U or up2date run away - is this desirable?
joe
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
This means that you modified the file_context/policy.18 file by using selinux-policy-targeted-sources file. The upgrade of selinux-policy-targeted-sources should do a make reload when it completes, causing the policy.18 and file_contexts file to be replaced. This way if you made local changes they will be maintained. (There was/is a bug with the moving of the /usr/bin files to /usr/sbin that is causing certain *sources rpms not to do a make load.
make -C /etc/selinux/targeted/src/policy load will force a load from sources.
Dan
On Wed, Nov 24, 2004 at 10:05:55AM -0500, Daniel J Walsh wrote:
Joe Orton wrote:
...
..5....T. c /etc/selinux/targeted/policy/policy.18
Since policy/policy.18 is marked %config(noreplace) the new policy.18 file is installed as policy.18.rpmnew and hence it seems manual intervention is needed to load the new policy, it's not a simple rpm -U or up2date run away - is this desirable?
This means that you modified the file_context/policy.18 file by using selinux-policy-targeted-sources file. The upgrade of selinux-policy-targeted-sources should do a make reload when it completes, causing the policy.18 and file_contexts file to be replaced. This way if you made local changes they will be maintained. (There was/is a bug with the moving of the /usr/bin files to /usr/sbin that is causing certain *sources rpms not to do a make load.
No, I didn't make any local changes, I haven't touched the files, this was on a fresh kickstart. Ah, it looks like the %post script for selinux-policy-targeted-sources will reload the policy the first time it's installed too, i.e. by anaconda. So it's doomed from the out.
That could be changed to really only happen on upgrades, but I'd question whether -sources should automatically reload the policy at all. Getting so easily into a state where "up2date selinux-targeted-policy" doesn't automatically apply policy updates (given no local modifications to the sources) is bad.
joe
Joe Orton wrote:
On Wed, Nov 24, 2004 at 10:05:55AM -0500, Daniel J Walsh wrote:
Joe Orton wrote:
...
..5....T. c /etc/selinux/targeted/policy/policy.18
Since policy/policy.18 is marked %config(noreplace) the new policy.18 file is installed as policy.18.rpmnew and hence it seems manual intervention is needed to load the new policy, it's not a simple rpm -U or up2date run away - is this desirable?
This means that you modified the file_context/policy.18 file by using selinux-policy-targeted-sources file. The upgrade of selinux-policy-targeted-sources should do a make reload when it completes, causing the policy.18 and file_contexts file to be replaced. This way if you made local changes they will be maintained. (There was/is a bug with the moving of the /usr/bin files to /usr/sbin that is causing certain *sources rpms not to do a make load.
No, I didn't make any local changes, I haven't touched the files, this was on a fresh kickstart. Ah, it looks like the %post script for selinux-policy-targeted-sources will reload the policy the first time it's installed too, i.e. by anaconda. So it's doomed from the out.
That could be changed to really only happen on upgrades, but I'd question whether -sources should automatically reload the policy at all. Getting so easily into a state where "up2date selinux-targeted-policy" doesn't automatically apply policy updates (given no local modifications to the sources) is bad.
Ok we can turn off automatic update of policy from selinux-policy-*sources, but then the user will need to manually update the policy if he has manipulated it.
joe
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
Daniel J Walsh wrote:
Joe Orton wrote:
On Wed, Nov 24, 2004 at 10:05:55AM -0500, Daniel J Walsh wrote:
Joe Orton wrote:
...
..5....T. c /etc/selinux/targeted/policy/policy.18
Since policy/policy.18 is marked %config(noreplace) the new policy.18 file is installed as policy.18.rpmnew and hence it seems manual intervention is needed to load the new policy, it's not a simple rpm -U or up2date run away - is this desirable?
This means that you modified the file_context/policy.18 file by using selinux-policy-targeted-sources file. The upgrade of selinux-policy-targeted-sources should do a make reload when it completes, causing the policy.18 and file_contexts file to be replaced. This way if you made local changes they will be maintained. (There was/is a bug with the moving of the /usr/bin files to /usr/sbin that is causing certain *sources rpms not to do a make load.
No, I didn't make any local changes, I haven't touched the files, this was on a fresh kickstart. Ah, it looks like the %post script for selinux-policy-targeted-sources will reload the policy the first time it's installed too, i.e. by anaconda. So it's doomed from the out.
That could be changed to really only happen on upgrades, but I'd question whether -sources should automatically reload the policy at all. Getting so easily into a state where "up2date selinux-targeted-policy" doesn't automatically apply policy updates (given no local modifications to the sources) is bad.
Ok we can turn off automatic update of policy from selinux-policy-*sources, but then the user will need to manually update the policy if he has manipulated it.
A more seamless mechanism to upgrade policy is gonna be needed eventually. I know of several problem areas, ready to attempt better upgrade if/when you are, if you wish to attempt through rpm. A distribution mechanism outside rpm is a quite sane alternative implementation as well.
73 de Jeff
On Nov 24, 2004, Daniel J Walsh dwalsh@redhat.com wrote:
Ok we can turn off automatic update of policy from selinux-policy-*sources, but then the user will need to manually update the policy if he has manipulated it.
Can't we find a middle ground, like: update policy automatically if there have been changes, and leave it alone otherwise since the non-sources policy update will have already taken care of it?
Alexandre Oliva wrote:
On Nov 24, 2004, Daniel J Walsh dwalsh@redhat.com wrote:
Ok we can turn off automatic update of policy from selinux-policy-*sources, but then the user will need to manually update the policy if he has manipulated it.
Can't we find a middle ground, like: update policy automatically if there have been changes, and leave it alone otherwise since the non-sources policy update will have already taken care of it?
Sure, but how can I tell in the post install section of the sources package?
Dan
Daniel J Walsh wrote:
Alexandre Oliva wrote:
On Nov 24, 2004, Daniel J Walsh dwalsh@redhat.com wrote:
Ok we can turn off automatic update of policy from selinux-policy-*sources, but then the user will need to manually update the policy if he has manipulated it.
Can't we find a middle ground, like: update policy automatically if there have been changes, and leave it alone otherwise since the non-sources policy update will have already taken care of it?
Sure, but how can I tell in the post install section of the sources package?
One way is for rpm to supply a hint, like an envvar, based on a more global context than available in %post.
However the hack would need some design.
Hint: I'd look seriously at using %post -p <lua> if I were you, there is a global and persistent variable space that shares state with rpm that will be much more convenient than impedance matching through envvar's.
73 de Jeff
How about something like the following.
if [ -x /usr/sbin/selinuxenabled -a -f /etc/selinux/config ]; then . /etc/selinux/config POLICYFILE=/etc/selinux/%{type}/policy/policy.18 RPMPOLICYFILE=$POLICYFILE.rpmnew if [ "${SELINUXTYPE}" = "%{type}" -a /usr/sbin/selinuxenabled -a \ -e $RPMPOLICYFILE -a \ $RPMPOLICYFILE -nt $POLICYFILE ]; then diff -q $RPMPOLICYFILE $POLICYFILE > /dev/null || make -C /etc/selinux/%{type}/src/policy load > /dev/null 2>&1 fi fi
Daniel J Walsh wrote:
How about something like the following.
if [ -x /usr/sbin/selinuxenabled -a -f /etc/selinux/config ]; then . /etc/selinux/config POLICYFILE=/etc/selinux/%{type}/policy/policy.18 RPMPOLICYFILE=$POLICYFILE.rpmnew if [ "${SELINUXTYPE}" = "%{type}" -a /usr/sbin/selinuxenabled -a \ -e $RPMPOLICYFILE -a \ $RPMPOLICYFILE -nt $POLICYFILE ]; then diff -q $RPMPOLICYFILE $POLICYFILE > /dev/null || make -C /etc/selinux/%{type}/src/policy load > /dev/null 2>&1 fi fi
*.rpmnew exists iff the original file was locally modified wrto the md5 contained within the old package metadata is what to watch out for.
Left over *.rpmnew can/will exist from previous upgrades, nuking *.rpmnew is recommended and perhaps will simplify some logic, and avoid clock skew issues.
inter-package existence tests like "-x /usr/sbin/selinuxenabled" are tricky because when and where the scriptlet is run needs to be considered. You might just as well add a Requires: and rely on the transaction being ordered correctly, that is likelier to work predictably, and is a simpler script to write.
The whole scheme assumes that ${SELINUXTYPE} changes rarely, but wot's a girl to do?
HTH Isn't rpm annoying? ;-)
73 de Jeff
On Wed, Nov 24, 2004 at 03:39:11PM -0500, Daniel J Walsh wrote:
How about something like the following.
Why not just have the Makefile touch some file as a side-effect of loading a modified policy, and then the %post script for -sources can automatically reload policy in %post run iff that file exists?
joe
On Nov 24, 2004, Daniel J Walsh dwalsh@redhat.com wrote:
Alexandre Oliva wrote:
On Nov 24, 2004, Daniel J Walsh dwalsh@redhat.com wrote:
Ok we can turn off automatic update of policy from selinux-policy-*sources, but then the user will need to manually update the policy if he has manipulated it.
Can't we find a middle ground, like: update policy automatically if there have been changes, and leave it alone otherwise since the non-sources policy update will have already taken care of it?
Sure, but how can I tell in the post install section of the sources package?
One relatively simple way is to have make rules that use move-if-changed after attempting to update the policy files into a temporary name. If the policy update is a no-op, you'll keep the old timestamp and rpm won't complain any more.
Was there any resolution on this issue? The problem still seems to be present in the latest policy-targeted-1.17.30-2.* packages. (Do you want me to file a bug?)
Regards,
joe
Joe Orton wrote:
Was there any resolution on this issue? The problem still seems to be present in the latest policy-targeted-1.17.30-2.* packages. (Do you want me to file a bug?)
Regards,
joe
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
No I just moved the fix from the Rawhide policy to the FC3 policy. So this will be fixed in 1.17.30-2.42
selinux@lists.fedoraproject.org
-
Alexandre Oliva -
Daniel J Walsh -
Jeff Johnson -
Joe Orton