| |||||||||||||
|
| |||||||||||||
Complexity eats kittens alive!!!Complexity eats kittens alive!!!Posted Nov 21, 2009 22:27 UTC (Sat) by man_ls (subscriber, #15091)In reply to: Fedora 12 to remove unprivileged package installation by k8to Parent article: Fedora 12 to remove unprivileged package installation Complexity is also the enemy of sanity, maintainability and many other things. In general it is the bane of information systems. And here we have some people trying to replace a good old simple well-understood scheme with a complex system having lots of knobs and configuration files. I am not saying that nothing new should ever be tried, but if it is more complex than the original solution then the benefits should be clear and understandable. Otherwise the new scheme almost certainly requires more thought. It seems that most LWN readers don't get the supposed advantages of PolicyKit either. No doubt it is much better than sudo and wheel, but perhaps the real use case (maybe a group of RH clients requesting it) needs a better explanation.
(Log in to post comments)
Complexity eats kittens alive!!! Posted Nov 24, 2009 2:18 UTC (Tue) by AdamW (guest, #48457) [Link]
it's pretty simple, really.
su/sudo: your disk management tool runs as root, or as user. ain't choice great?
policykit: administrator can define fine-grained policies for all the following actions:
Mount a device
don't you see how that level of granularity might be just a _tad_ welcome to your average admin? Bear in mind that it's relatively simple to set up policies based on several levels of user roles, each level having a particular set of permissions, so you can set up a bunch of tailored profiles for your particular installation, and easily slot new users into the appropriate role for them...
Complexity eats kittens alive!!! Posted Nov 24, 2009 7:08 UTC (Tue) by man_ls (subscriber, #15091) [Link] Sure, it looks very useful and a real advance over classic Unix permissions. It should be easy to sell to companies. But it is also more complex than classic Unix permissions, so the simpler it is to manage the better.
Complexity eats kittens alive!!! Posted Nov 24, 2009 15:53 UTC (Tue) by dskoll (subscriber, #1630) [Link] don't you see how that level of granularity might be just a _tad_ welcome to your average admin? No, not really. Explain what the difference between "a device" and "a system-internal device" is. What, exactly, are you allowed to do if you are allowed to "Modify a device"? What does "Cancel a job initiated by another user" mean? Kill someone's process? Stop an "at" or "cron" job? We see here creeping Microsoftisms. Vaguely-defined actions (described in dumbed-down, imprecise language) that are supposedly security-critical, so the average admin is completely confused as to what he or she should allow. This is a real step backwards.
Complexity eats kittens alive!!! Posted Nov 24, 2009 20:48 UTC (Tue) by nix (subscriber, #2304) [Link]
The distinction between 'device' and 'system-internal device' is clear
enough: the latter should really be 'external device'. Basically the latter is internal disks and the former is USB stuff and things like that.
What a 'job' is, I have no idea. I agree, there should be a
Complexity eats kittens alive!!! Posted Nov 24, 2009 21:10 UTC (Tue) by dskoll (subscriber, #1630) [Link] The distinction between 'device' and 'system-internal device' is clear enough: the latter should really be 'external device'. It's not clear to me. What if I have a hot-swappable SCSI disk? Is that internal or external? How about if my root file system is on an external USB device? (Don't laugh... I run my EEEPC that way.) Some of the categories listed don't look useful to me. In fact, they look dangerous exactly because they are imprecise. If complexity is the enemy of security, then imprecision is the nuclear weapon.
|
|
||||||||||||