On Mon, 2012-10-01 at 07:53 +0200, Mike Gabriel wrote:
> Hi John,
> 
> On Mo 01 Okt 2012 04:12:25 CEST "John A. Sullivan III" wrote:
> 
> > On Sun, 2012-09-30 at 10:35 -0400, senrab...@aol.com wrote:
> 
> >> Another quick update - we think enabling fuse in the vserver guest is
> >> part of the problem, though the vserver folks suggest this may be a
> >> security/stability problem.
> >>
> > <snip>
> > Newer kernels may break out the capability required to make FUSE work
> > from the admin capability but I've not investigated that yet.  If you
> > allowed the admin capability in your vserver guest, you shot your
> > security to bits.  If I recall correctly, the capability limitation was
> > not in mounting FUSE drives but only in unmounting them, strangely.
> > That's why we moved the x2gocleansessions script to the VServer host -
> > not to mention that it means we can run one process for many hundreds of
> > servers rather than one each firing every five seconds.
> >
> > We do have this working without opening the admin capabilities but I do
> > not remember the details off the top of my head and we are using an old
> > and heavily adapted version.  Good luck with it - John
> 
> For X2Go Server 3.2.0.0 I am currently fully restructuring the  
> x2goserver src:package. Would it make sense for you to package the  
> x2gocleansessions script in a separate package? What other components  
> do you have running on the Vserver host that do not run on the X2Go  
> servers (Vserver guests)?
<snip>
Hi, Mike.  I believe x2gocleansessions is it and we do not have it quite
right.  We made major changes to the way the database is handled to
close some of the security holes but I think you have already addressed
those issues.  Hmm . . . actually some of those changes may still be
necessary as they were for both security and centralized
x2gocleansessions.  There is one x2go_sessions database for all x2go
servers.  Each server has a separate schema with a trigger to update the
sessions table in a sessions table in the public schema to which only
the postgres user has access.  All of the details are included in those
extensive posts and patches we posted a couple of years ago to the X2Go
mailing list.  Thanks - John

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

Reply via email to