Mount fixed partitions by default for F7. Was: [BUG] Mounted partitions are not showing up and CD/DVD link not correct

David Zeuthen david at fubar.dk
Wed Mar 21 01:24:05 UTC 2007


On Wed, 2007-03-21 at 01:09 +0000, Richard Hughes wrote:
> On Mon, 2007-03-19 at 17:56 +0000, Richard Hughes wrote:
> > 
> > Is this a rh-legal type problem (in which case I understand) or
> > rh-desktop policy (which can be re-evaluated)? Personally I've
> > explained the 99-fixed-disk thing to at least 4 or 5 people new to
> > linux, and they all thought it was a crazy decision. No offence
> > intended.
> 
> Any feedback on this? Thanks.

That's a bit pushy. Well, it's certainly not a rh-legal thing and as I'm
the package maintainer it ends up being my decision (though I guess the
board can overrule my decisions)... and I don't think this change is
justified so I'm just going to say no, sorry.

FWIW, what really needs to happen is something a lot more flexible and
more fine grained than pam_console so different Fedora spins can ship
with different defaults, e.g. a desktop oriented spin (or livecd or
whatever) will ship with this bit "on"; server / corp desktop oriented
spins can ship with this bit "off". And even when the bit is "off" what
yuou want is to explain to the user that this operation is locked down
and give them an option to e.g. auth (as super user) to perform the
operation anyway.

Sounds familiar? That's because I've wrote about all that about more
than a year ago

 http://lists.freedesktop.org/archives/hal/2006-January/004377.html

 (ignore most of the implementation details; this is afterall more
  than a year old.)

but have been both busy with frying other fish plus I wasn't happy with
the overall architecture of the code I ended up with - just too damn
complex / abstrat plus it requires a whole new system-wide daemon. It
works though; SUSE is already shipping PolicyKit AFAIK.

I have some plans on how to greatly simplify PolicyKit (now that we have
ConsoleKit and D-Bus system bus activation is on the horizon) but
haven't had time to put these thoughts into email form just yet.
Eventually.

FWIW, this is something we sorely need in a modern system + all this is
not restricted to HAL at all; it's about having a formal way of
classifying what a user (uid) / group (gid) / program (security context)
is allowed to do and not to do. Think about parental controls for
example. So as this is applicable to many other things where we today do
broken stuff like running X11 applications as uid 0 - and that pretty
much includes everything in the System->Administration menu. It's just
broken by design.

     David





More information about the devel mailing list