some hits from latest set of updates

Daniel J Walsh dwalsh at redhat.com
Thu Apr 15 19:51:06 UTC 2004


Gene Czarcinski wrote:

>The latest version of udev (024-3) may fix something but it breaks others -- 
>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120956
>
>My reason for this message is really another matter.  When I say the large 
>number of denied messages involving udev, I immediately reinstalled 
>udev-023-2 and, sure enough, they went away ... well mostly.  My sound was 
>broken again ... not for root (I could run s-c-soundcard) but for the user.
>
>OK, I knew how to fix that ... "telinit 1", "setfiles /etc/security... /dev", 
>"telinit 5"  ... sound works again for the user.
>
>Now, my question is how will this be handled in the future?  With the large 
>number of updates during the release development cycle, the number of updates 
>(and sometimes reinstall oldpackage) has created situtations where the 
>attributes on a file have gotten screwed up.
>
>Through experience (I have done it enough times), I have come to know that 
>occasionally I will need to do a relabel (or if I am lucky and know the 
>general area, a setfiles).  But how will this be handled once FC2 is release?  
>Will a general user be willing to run selinux=1, enforcing=1 if things get 
>screwed up when they update packages and suddenly things stop working 
>(because some file is mis-labeled)?
>
>I want to run selinux and plan to run enforcing=1 regardless of what FC2 ships 
>by default.  But, will that be true of most users?
>  
>

First off the volume of changes will hopefully slowdown.  Maybe not till 
FC3.  :^(
File contexts should not be getting changed so often, and major changes 
like xorg and stuff
will not be happening as often.    Basically we have got to get better.  
One problem is that we
are sharing rawhide with the user community, so if someone submits a 
package in rawhide, you and I
see it at the same time.  If it breaks policy it takes time for us to 
fix it.  (Xorg being an example.)  As
others start to run SELinux, and everyone becomes more aware of SELinux 
these problems
should happen less often.

>Gene
>
>--
>fedora-selinux-list mailing list
>fedora-selinux-list at redhat.com
>http://www.redhat.com/mailman/listinfo/fedora-selinux-list
>  
>



More information about the fedora-selinux-list mailing list