Elektrified X.org released [LWN.net]

Elektrified X.org released

Posted Dec 1, 2004 16:23 UTC (Wed) by tzafrir (subscriber, #11501)
In reply to: Elektrified X.org released by evgeny
Parent article: Elektrified X.org released

How do you create different permissions on different part of the database without a priviliged daemon (or something uglier, such as a SUID root binary) ?

This is an important requirement: user applications need not run as root to read configuration. But there should be a place for the secret data.

But please name one thing a database provides that a filesystem doesn't. What database exactly (daemon? file-based? which one?)

(Log in to post comments)

Elektrified X.org released

Posted Dec 1, 2004 21:37 UTC (Wed) by evgeny (guest, #774) [Link]

> How do you create different permissions on different part of the database
> without a priviliged daemon (or something uglier, such as a SUID root binary) ?

Depends on the implementation. For a DB _service_ (a daemon running) it's solved like for any other similar problem (and there is no need for it to run under a privileged account - e.g. slapd on my server runs as an unprivileged user 'ldap', yet system-wide authentication works fine). For a simple file-based DB like SQLite it can be solved by splitting the whole data into a few files (1 - writable by root, readable by everyone; 2 - r/w by root ony, plus, similarly, two files per user account).

> But please name one thing a database provides that a filesystem doesn't.

Expressions (aka views). E.g. SELECT * FROM user WHERE user.id > 400 - to have a list of "real" users - used, for example, to send an announce email. Etc. Other things are replication, atomicity, true locking, notifications, rollbacks, versioning, transparent remote access, scalability (in _both_ directions). You get all these for free with a decent RDBMS, and NONE of them with an existing filesystem.

Elektrified X.org released

Posted Dec 2, 2004 22:55 UTC (Thu) by tzafrir (subscriber, #11501) [Link]

> > But please name one thing a database provides that a
> > filesystem doesn't.
>
> Expressions (aka views). E.g. SELECT * FROM user WHERE
> user.id > 400 - to have a list of "real" users - used,
> for example, to send an announce email. Etc.

OTOH, the strict typing of the data will get back at you when you try something like:

grep -rl /home/joe /etc/

> Other things are replication,

Try rsync

> atomicity, true locking,

What about filesystem-level locking?

> notifications,

Change notification for a directory is available.

> rollbacks, versioning,

Put arch/subversion in there (cvs probably won't do as it does not support renames)

> transparent remote access,

Add a remote-access daemon. Quite simple to implement. You have to figure out the authentication method first. Currently practically no existing daemon intgrates well enough with the system.

> scalability (in _both_ directions).

Filesystem access is quite scalable

Elektrified X.org released

Posted Dec 3, 2004 19:42 UTC (Fri) by evgeny (guest, #774) [Link]

> OTOH, the strict typing of the data will get back at you when you try something like:
>
> grep -rl /home/joe /etc/

Sorry, I didn't get what you meant.

> Try rsync [etc etc etc]

I don't want. For the same reason that nobody in sane mind will pipe 'telnet 80 | html2txt | less' to browse the Web. Possible - yes. Great when nothing else is available - yes. But call this THE ultimate browser?!