[Registry] Re: LinuxRegistry in Freedesktop & KDE

[Avi Alkalay]

> Any system based solely on the file system is bad for security.  With
> it, we're limited to the very ineffective UNIX file permissions.  In
> order to assign different keys to be writable to different users (staff
> members and such that I don't want to give a universal-super-power root
> password to) I'd have to create a UNIX group for each set of files/keys
> (which isn't feasible given the limits on groups most systems have) or
> use POSIX ACLs which are not universally available.

Oh really? Maybe you should teach us some good parctices on security
sysadmin.
You, as a sysadmin, will give access permission to whatever you think is
good, exactly as you do today for files, but in a more fine grained way.

I didn't know UNIX file persmission are ineffective. Can you tell us with
your extensive sysadmin experiences on how it made you loose data or let
hackers get in?
Maybe I understood what you mean: You want some kind of SSL
X509-certified access to files. Well, UNIX FS will never do it. You'll
have to stack software to achieve it.


> A daemon can provide more powerful access control (by authenticating the
> user connecting to the daemon and using built in ACL policy geared
> specifically for configuration management), as well as enforce logging
> of key changes and fix race conditions on keys that LR can't handle
> (which are both major security issues).  The daemon also means that the
> configuration tools themselves do not need to run as root, which is very
> important given that graphics toolkits generally aren't that secure (way
> too much code that's highly complex in nature).

Oh really? How can a daemon know which user had connected to him? Maybe
passing an XML document describing its UID? Oh yes. Aren't XML generated
by the user?

About race conditions, I allways said you'll need an additional layer of
software, and pay the specialization consequences. Many software don't
need it. LR is designed to be for generic use.





> All of these issues are present with current file-based configuration
> systems, yes, but if you're going to make people switch APIs and loose
> all existing experience and knowledge regarding configuration their
> systems, perhaps you should try to fix these real problems (among the
> others we've raised already, like network-shared configuration, change
> notification, value/type constraints, etc.) and not just worry about
> something as trivial and irrelevant as file format...

Yes, the small number of experienced UNIX people will have the new OPTION
of doing point-and-click to consistently configure Apache, for example.
And the big majority of Windows users will GET THE ABILITY to use Linux.



> 
> >    bash# rg vi system/sw/XFree
> > 
> > And vi will pop with an XML vision of your keys. Then you'll change and
> > save it, and rg will find what you changed, and apply it.
> 
> That's not much better than one file per key.  If you're going to add
> hacks for linear editing of keys, provide it in a format users can
> safely, easily, and efficiently edit, not a format intended for machine
> parsing.  Most apps that have introduced XML config files have gotten a
> *lot* of flak from users because it is such an incredible pain to work
> with compared to other file formats, like those you're trying to get rid
> of.

The way user will be able to edit their configurations is
point-and-click. This is the only way accepted today in real world
businesses. Anyway I needed an (very very simple) XML format for dumping,
reloading keys.
Programatically, and for security, 1 file per key it is still better.
Speed is an issue yet.




> That's great for Apache.  You're not pushing LR for Apache, you're
> pushing it for the entire system.  You can't assume that since it's not
> bad for one daemon in one use case that it's therefor not bad for the
> entire system.

I'm ready to assum that, with a very open mind. But honestly the issues
are still smaller then the benefits, in my vision.
Even with all this flames, I think this discussion is very healthy, and
is helping me to think in possible changes to LR.



> And boot up time *does* matter.  Users don't want to wait for their
> machine to boot.  Many desktops (and especially laptops) need to boot up
> a lot more than once per 6 months, often many times per day, and these
> systems have slower disks than most servers.  Laptops especially need to
> avoid file system traffic as much as possible because spinning up the
> disk (or keeping it spinning for longer than necessary) slaughters
> battery life.  The less seeking and traversal the disk has to do, the
> better.


>From BASH man page, BUGS section: "It's too big and too slow."
But nowbody dreams to port all Linux startup scripts to C. Why? Because
to keep everything open, editable, and flexible it is absolutely required
to stay this way.

LR has issues, I admit and want to address them. But its goal is to
provide programatical flexibility, while not killing the human readable
paradigm.





-- 
http://www.fastmail.fm - Email service worth paying for. Try it for free