Elektrified X.org released (was: X configuration paradigm, and a proposal)

[Sean Middleditch]

On Wed, 2004-12-01 at 14:33 -0300, Avi Alkalay wrote:
> Instead of doing a lot of 'kdb set', you can generate an XML file with
> the keys you want changed, and do 'kdb import keys.xml'. It will be
> more atomic, and will use the kdbSetKeys() call which wraps
> transaction support.

Which requires then a whole new application infrastructure to build up a
whole XML file and then import.  This is especially ridiculous with
shell scripts.

> - Elektra is system-wide by definition. So with a global daemon,
> security has to be handled in the user-space daemon. And security is a
> little thing that you may require this: is the best (kernel space) and
> you have it, or you simply don't have it.

Quite the opposite, the kernel-level access control completely sucks.
Especially when you're basing it entirely on the very archaic UNIX file
system permissions.  You are requiring that users run systems with
SELinux or ACLs or some other uncommon extension in order to get any
sort of sane access control.

A central daemon could easily provide more advanced and consistent
access control and be just as secure as the kernel.

> - Besides, you can't authenticate against a system daemon.
> Authentication means to have a user to *type* a password or *read* it
> from a file. Think about how authentication works in HTTP sessions,
> LDAP, DB servers, etc. I'm open to hear ideas on this point.

This is non-sense.  You can authenticate against a system-daemon very
easily.  Just like you said, using a protocol like HTTP or LDAP,
authentication is perfectly possible if you want to require users to
enter passwords.

You can also used magic cookie authenticate (this is what X uses), UNIX
domain sockets on most UNIXes (they allow you to get the UID of other
side of the connection, so you can easily check who is accessing the
DB), and so on.

We brought this up in the initial discussions of Linux Registry months
ago, if I recall.

> - A daemon is a single point of failure.

So is a unified configuration database...

The daemon shouldn't fail.  Ever.  It is quite possible to write fail-
proof daemons, so long as you are careful and competent.  I have daemons
on my system that have crashed less than the kernel.

> 
> These were the reasons why daemon and a single file (binary or text)
> is accepted only in non-critical, desktopish, single user environment
> (read GConf, that really makes its job!). Not systemwide.

With a daemon, you don't *need* a single file, because the daemon can
handle the magic of atomicity and synchronize access to the files.  A
daemon makes perfect sense even system-wide, even during early bootup.
(Although, as I said, you can make the daemon be an optional part of the
framework, but having it start later in the boot process, and have the
DB operate in a limited mode until it starts.)

> 
> 
> > The best format is probably something like XML, or something very XML-
> > ish, because it can easily store a hierarchy in a single file, is "safe"
> > in terms of value escaping (many custom formats are not), and there are
> > tons of libraries to read/write it efficiently.  It isn't *easily*
> > edited by hand, but if it's "pretty-printed" it can be easy enough.
> 
> Read/write in memory, not on the disk. On the disk you have to rewrite
> the entire file, so bye bye transactions.

::sigh:: Atomic rewrites of files have been around in UNIX for decades.
How do you think *CRITICAL* system files like /etc/passwd, /etc/shadow,
and so on get updated?

Transactions pretty much require that you have guaranteed, unfailable
locking of the database, or a central daemon to synchronize requests.
Without a daemon, that means that for NFS-mounted systems, you can never
let the database be writable.  So you can never store user preferences
in it.  (You probably don't want system preferences to be writable in
this scenario anyhow.)

> 
> 
> > > Overall I'm glad to see this work being done. I'm not convinced the format is
> > > right but the essential goals of unifying configuration spaces, improving
> > > tools and also just going out and doing it are all good things.
> > 
> > Definitely.  Elektra still has major short comings (no transactional
> > guarantees, no notification, no real access control, no temporary
> > keys... mostly things Elektra can never do since it refuses to use a
> > daemon), but it's at least a tiny step in teh right direction that might
> > open some peoples' eyes.
> 
> Notifications is there already. Check the code. Transactions needs
> some stabilization, yes.

Your notifications API is a gross hack.  It might be the best you can do
without a daemon, but it's still practically unusable.  Discussed
already in another message.

> What do you mean with "no real access control"? This is completelly
> delegated to the best guy that can do it: the Kernel.
> And what do you mean about "temporary keys" ?

User session length keys.  Things a user can change during runtime, but
reset when they log back in.  Think of a kiosk, for example.

> 
> 
> 
> > Sean Middleditch <elanthis at awesomeplay.com>
> > AwesomePlay Productions, Inc.
> 
> Thank you,
> Avi
> _______________________________________________
> xdg mailing list
> xdg at freedesktop.org
> http://freedesktop.org/mailman/listinfo/xdg
> 
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.