On Mon, Dec 16, 2013 at 2:30 AM, Mike Gabriel <mike.gabr...@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 _______________________________________________ X2Go-Dev mailing list X2Go-Dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
