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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
