Arjan van de Ven wrote:

that sounds nasty; maybe fedora should turn off MLS for now until there's a better compatibility?

...

I have read already bug #174618, but they assume a kernel patch for FC4. But as I want to use Centos4 and don't believe RedHat will corporate such a patch into their Kernels.

well if you use CentOS4 the question is "will CentOS put it into their kernel" not "will Red Hat"....

No Centos does only recompile the redhat src.rpm's: If not in RHEL4 => not in Centos4

On Thu, Dec 22, 2005 at 03:31:03PM +0100, Arjan van de Ven wrote:

On Thu, 2005-12-22 at 14:47 +0100, gsc.news@online.de wrote:

...

...

If I recall, there was a change in the ext2 utilities from FC3 to FC4 which fsils with earlier distro created partitions.

I believe you need to disable filechecking with the entries in your fstab file. That is, change the last two digits in your older distros to zero. Alternatively, you could mount the other OS partitions whenever you need to access the files on the common partitions..

Are you talking about a common /home partition?

Yes, and therefore, I can't use my privous installations anymore.

that sounds nasty; maybe fedora should turn off MLS for now until there's a better compatibility?

The latest FC4 update kernel can read MLS labelled filesystems without problem. I've not checked FC3, that one might be a little more tricky, as the compat code requires changes that have happened post 2.6.12 (where FC3 is currently sat). Given the effort required to make that work, the limited time remaining in the FC3 lifetime, and the low general appeal of such a feature, it probably won't get fixed.

Dave

On Friday 23 December 2005 19:23, Arjan van de Ven arjan@fenrus.demon.nl wrote:

given that even RHEL4 can't get compatibility code.. why go through this pain in the first place? Is MLS a compelling enough feature for fedora to go through this pain? Is it even used for something or by someone in the first place?

Firstly the vast majority of Fedora and RHEL users will never use MLS. What they will use is MCS which is based on some of the features of MLS (it's not a sub-set of MLS though).

MCS provides some compelling benefits in terms of managing secret data.

It allows the administrator to create a set of named "categories" for labelling data. Each user login will have a set of categories (which may be empty) assigned to it from the 256 available categories (we produce binary policies that support 256 categories, the administrator can change this but it's unlikely that they would need to).

Every file on disk will have a set of categories (which may be empty). To access a file when running the MCS policy the process must have a set of categories that's a superset of the categories assigned to the file.

This provides several features that are not available in any other way. One is that a file can have multiple categories that are all required by every process that may access it. Traditionally this is implemented by supplemental groups and having the file in question and the directory containing it owned by different groups such that one group is required for directory access and another for file access.

Another feature that we are still working on is the exact method of determining how categories are granted to processes. I'm working on a patch that makes categories mandatory and permits a process to launch a child process with a subset of it's categories. This permits a process to launch a child with less access than it has (something that a non-root process can't do with traditional Linux access control).