[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: FC2 and FC1 and common home

On Tue, 2004-04-06 at 16:43 -0400, Colin Walters wrote:
> On Mon, 2004-04-05 at 12:57, Shahms King wrote:
> > 1) Unlabeled files in an xattr-capable filesystem.
> >    -- Yes, this is a corner case, but will have to be dealt with,
> > especially for people upgrading from FC1 -> FC2 and RHEL3 -> RHEL4. 
> > Most people don't want to reformat their home directories ;-P (isn't
> > that the point of an upgrade?).  Having anaconda 'make relabel' on
> > unformatted, mounted partitions is probably reasonable for this specific
> > case, but not all.  
> Yeah.  Jeremy?  What do you think?  Maybe each previously-formatted
> filesystem could have a checkbox for whether it should be relabeled with
> security contexts.  Alternatively we could just do it - older ext{2,3}
> should still be able to read it.

Unfortunately, they can't.  Anything before one of the FC1 update
kernels actually panics on boot if you have xattrs set on the
filesystem.  And I'm not really sure that I want to have anaconda in the
business of relabeling huge chunks of your filesystem by hand.  This is
actually related to a bug 120126 which was filed today.  I'm still
thinking on it, thus far without a clear idea of how I'm leaning.

One problem is that we do partitioning before we ask about SELinux which
leads to a bit of a chicken and the egg question of how to handle this
(it's pointless to ask someone who's installing without SELinux if we
should label their preexisting /home).

> > 6) NIS/LDAP user information.  If giving all users the user_u identity
> > and just living with that is acceptable, that's one thing, but if the
> > "standard practice" is expected to be adding every system user into
> > users.te and recompiling/reloading the policy, it's more than simply
> > impractical.
> Having all users be user_u and just relying on DAC should be sufficient
> for most sites.  But I don't see why having a script to add users to
> users.te would be so impractical.

Because users.te isn't centrally managed.  I shouldn't have to touch
every one of the systems I maintain just to add a user.  If I have to do
that, we might as well go back to the stone ages where I had to manually
distribute a new passwd file to every machine I maintain to add a


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]