On 02/26/2010 03:57 PM, Stephen Smalley wrote:
On Fri, 2010-02-26 at 15:52 -0500, Daniel J Walsh wrote:
On 02/26/2010 03:47 PM, Stephen Smalley wrote:
On Fri, 2010-02-26 at 15:25 -0500, Daniel J Walsh wrote:
On 02/26/2010 03:16 PM, Stephen Smalley wrote:
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.
No I removed the break after finding seclabel, and set found to 0 if ro
is found.
So it will either search the entire structure for seclabel or break out
with ro.
+ if (strcmp(item, "ro") == 0) {
+ found = 0;
+ break;
+ }
if (strcmp(item, "seclabel") == 0) {
found = 1;
- break;
}
Actually, given your other comment, I guess we can't do it this way, as
if they have e.g. read-only root with writable mounts underneath, we'll
never reach them.
We have that problem with or without this patch. Since no seclabel is
the same problem.
It isn't quite the same though. If someone were using SELinux, then I'd
expect their root filesystem to support labeling (otherwise init and
friends won't transition). But they might very well go with a read-only
root after installation.
The latest fixfiles picks the "correct" mounts and does not cross file
system barriers.
restorecon -R -v /
Would not pick up file systems if any labels are wrong on a dir, because
it stops traversing if it gets an error anyways.
But I do not have a problem dropping this patch.
I think we need to stay with the setfiles/fixfiles solution for this case.
--
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.
