On Fri, 2010-02-26 at 13:12 -0500, Daniel J Walsh wrote: > On 02/26/2010 09:36 AM, Stephen Smalley wrote: > > On Fri, 2010-02-26 at 09:23 -0500, Daniel J Walsh wrote: > > > >> On 02/26/2010 09:10 AM, Stephen Smalley wrote: > >> > >>> On Fri, 2010-02-26 at 08:41 -0500, Daniel J Walsh wrote: > >>> > >>> > >>>> On 02/25/2010 08:41 PM, Joshua Brindle wrote: > >>>> > >>>> > >>>>> What version of the kernel was this added in? I don't want to > >>>>> completely break old kernels using new toolchains (CLIP backports > >>>>> toolchains to RHEL 4 and 5). It would be better to use seclabel if it > >>>>> is there, otherwise fall back to the old list. > >>>>> > >>>>> -- > >>>>> This message was distributed to subscribers of the selinux mailing list. > >>>>> If you no longer wish to subscribe, send mail to > >>>>> majordomo@xxxxxxxxxxxxx with > >>>>> the words "unsubscribe selinux" without quotes as the message. > >>>>> > >>>>> > >>>> The problem with this is we end up with a lot of cruft in the toolchain, > >>>> that is continually out of data, and makes it hard to figure out what > >>>> the script is doing. We have older versions of the tool chain for those > >>>> platforms, shouldn't we have sort of the latest toolchain. > >>>> > >>>> > >>> If we do that, we ought to make a major bump in the version numbers, > >>> e.g. finally go to 2.1 or 3.0 or something, and make sure the release > >>> announcement clearly marks it as not backward compatible. > >>> > >>> With regard to fixfiles simplification though, can't we eliminate the > >>> need to define or use FILESYSTEMS* altogether in the script by switching > >>> all uses of setfiles to restorecon -R /, since that will automatically > >>> skip non-labeled filesystems on kernels>= 2.6.30? > >>> > >>> > >>> > >> It will still walk on read/only file systems. > >> > > That should be fairly easy to fix in setfiles given that we are already > > reading /proc/mounts - we can just add exclude on any ro mounts. > > > > > How about this patch to remove ro mount points from setfiles/restorecon Your logic depends on the option order - if "seclabel" appears first, then you'll break out of the loop and never see the "ro". If we are ok with that assumption (which happens to be true at present, but /proc/mounts format is not guaranteed to remain stable), then it is ok but then there is no reason to set found to 0 (already initialized to 0). If we want to be robust against ordering changes, we'd need to drop the break; from the seclabel case and keep scanning to check for any subsequent "ro" options. Or you could just use strstr() on the entire mount_info[3] and not worry about splitting it into tokens. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
