Hi Reinhard,
On Sa 14 Dez 2013 23:26:57 CET, Reinhard Tartler wrote:
Hi,
can someone please remind me again why we need a sqlite database that is shared for all users? It allows users to see what other users are currently having running sessions, which I frankly don't consider very important. It could even be considered a privacy issue.
If there isn't a good reason for a shared database, why don't we have x2go users have their own sqlite database in their home directory? This would allow to get rid of the x2go user and all suid/sgid complexity that comes with it.
Background, I'm trying to have my new employer deploy x2go, and I'm currently having trouble to explain this point. I understand that the current printing implementation requires the x2goprint user, but that's not an issue right now.
Thanks, and greetings from NYC!
Greetings to NYC!!!
The problem is that the root process x2gocleansessions (which runs as
a daemon on X2Go Servers) does several clean up jobs in the background
on the database. The x2gocleansessions script has to be able to run
these jobs on behalf of any other normal user, so it by itself runs as
root.
Same applies for the X2Go Session Broker Agent script x2gobroker-agent
(package of same name). It also needs to be able to su to any other
user on the system.
You could now say su'ing does not contradict session DBs in $HOME. And
yes, it does: X2Go (x2gocleansessions, x2gobroker-agent esp.) will
certainly fail on homes with NFSv5+Krb5 and on AFS. Currently, with
NFSv4+Krb5 X2Go works fine. On AFS there seems to be a problem, though
[1].
Even if you deploy passwd files in your infrastructure (rather than
using LDAP), you still should use PostgreSQL instead of SQLite3.
My 2¢... Mike
[1] http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=272
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...