On Sat, Dec 14, 2013 at 5:34 PM, Stefan Baur <newsgroups.mail2@stefanbaur.de> wrote:

Am 14.12.2013 23:26, schrieb Reinhard Tartler:

...

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.

I can't speak for the "why", but isn't it still possible to use a serious DB engine like postgres instead?

http://wiki.x2go.org/doku.php/wiki:advanced:multi-node:x2goserver-pgsql

Yes, but that's not my concern. AFAIUI, we don't need an x2gouser for postgres either, right?

If you're worried about privacy, because the sqlite DB happens t be open to everyone (I don't know - I'm taking your word for granted here), maybe the access rules on the postgres DB are stricter by default, or could at least be set in a stricter way without harming X2Go use?

I'd rather simplify the deployment by removing the x2gouser if it was not necessary in the first place. For installations with central user management, adding a system user is something non-trivial that may require coordination, and I just wonder if we could not simplify the no-configuration-needed-default-install even more.

-- regards, Reinhard

On Sat, Dec 14, 2013 at 5:38 PM, Clemens Lang <neverpanic@gmail.com> wrote:

On Sat, Dec 14, 2013 at 05:26:57PM -0500, Reinhard Tartler wrote:

...

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.

So you'd consider ps aux | grep x2go a privacy issue, too? That gives you the same information, doesn't it?

Excatly my point.

Not that I disagree with removing the user and splitting the database, if possible.

Thank you.

-- regards, Reinhard

Hi Oleksandr,

Thank you very much for your email. I see the confusion. Yes, my site has a centralized user management in the sense that all users are in /etc/passwd but distributed via some configuration mechanism. This means that we do not use LDAP, and the user database is imported from somewhere else. I hesitate to use postgres because I feel it is quite complex to setup. Also, we use dedicated VMs for each user, so there is no need server pooling or the like.

I understand from your email that the sqlite database is used to figure out what are the free X11 display ports. Is this correct? Would probing for a free port work as well? If yes, then let's have every user have its own sqlite.

Please let me know what you think. Reinhard

On Sat, Dec 14, 2013 at 6:26 PM, Oleksandr Shneyder <o.shneyder@phoca-gmbh.de> wrote:

Hello Reinhard,

in central DB different sessions information is stored. For example, used display numbers and ports. x2gostartagent look in the DB when assigning display and ports for new sessions. Historical x2ho has only postgresql support. In postgres version users have access only to his own entries in sessions table. sqlite support was developed for small one-server installation wheres installing of postgresql is oversized. To avoid users modify session data only user "x2gouser" has direct access to DB. For complex setups with central user administrations you should use postgresql instead of sqlite.

regards Alex

Am 14.12.2013 23:26, schrieb Reinhard Tartler:

...

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!

--

Oleksandr Shneyder | Email: o.shneyder@phoca-gmbh.de phoca GmbH | Tel. : 0911 - 14870374 0 Bräuhausgasse 9 | Fax. : 0911 - 14870374 9 D-82205 Gilching | Mobil: 0163 - 49 64 461

Geschäftsführung: Dipl.-Inf. Oleksandr Shneyder

Amtsgericht München | http://www.phoca-gmbh.de HRB 196 658 | http://www.x2go.org USt-IdNr.: DE281977973

---

X2Go-Dev mailing list X2Go-Dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev

-- regards, Reinhard

On Sat, Dec 14, 2013 at 6:26 PM, Oleksandr Shneyder <o.shneyder@phoca-gmbh.de> wrote:

For complex setups with central user administrations you should use postgresql instead of sqlite.

I did take a look into the postgres configuration, but unfortunately, I had to file http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=372. This issue makes the postgres code a real dealbreaker.

-- regards, Reinhard

On Mon, Dec 16, 2013 at 2:30 AM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:

Hi Reinhard, Greetings to NYC!!!

Thanks :-)

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.

Can't we do the cleansessions implicitly at session creation time in the context of the user in the sqlite case?

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.

Does the session broker make sense at all with a sqlitedb?

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].

I never suggested su'ing. Just call the cleansessions from the right context, and you should be fine.

Even if you deploy passwd files in your infrastructure (rather than using LDAP), you still should use PostgreSQL instead of SQLite3.

Which I cannot because of bug http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=372. This is a very similar kind of problem as we are talking here: executing administrative tasks from root for a user is problematic.

-- regards, Reinhard