1596240846 J * emanuel ~emanuel@2a02:1748:dd5e:7720:aad8:61cd:1c3a:de3f
1596242508 M * Bertl_oO  off to bed now ... have a good one everyone!
1596242509 N * Bertl_oO Bertl_zZ
1596251493 J * fstd_ ~fstd@xdsl-85-197-62-235.nc.de
1596251953 Q * fstd Ping timeout: 480 seconds
1596252535 Q * emanuel Ping timeout: 480 seconds
1596263379 J * Ghislain ~ghislain@adsl2.aqueos.com
1596270805 Q * Ghislain Quit: Leaving.
1596276706 N * Bertl_zZ Bertl
1596276709 M * Bertl  morning folks!
1596281418 M * Bertl  off for now ... bbl
1596281420 N * Bertl Bertl_oO
1596282070 J * Ghislain ~ghislain@adsl2.aqueos.com
1596284966 Q * Aiken Remote host closed the connection
1596289695 M * Hurga hmm, it looks like it works, but since I never tried it... is it safe to give a vserver fs root permission of 700? (Background: I may need to add a non-rood user to the host, and I don't want them to snoop around)
1596289801 M * Hurga I think the guest should not be bothered by it, but as I said, I never tried.
1596296651 M * gnarface should be fine.  you can also give /var/lib/vservers permission 0000 
1596296662 M * gnarface (nothing actually needs access to it)
1596296742 M * gnarface i think there was something about a extended filesystem attribute you could set, but iirc it was redundant after some bug fix release some versions ago
1596296835 M * gnarface just make sure they cant' execute vserver tools like vps and vtop 
1596296840 M * gnarface on the host
1596296883 M * gnarface (you probably want to disallow sudo and su if this is a untrusted user - but if it's an untrusted user i shouldn't have to tell you that they should not have access to the host in the first place)
1596297011 M * gnarface Hurga: ^
1596297027 M * gnarface (you probably want to a quick permissions lock-down check on /etc/vservers too
1596297029 M * gnarface )
1596297070 M * gnarface (it probably is all fine, but i forget if stuff like guest's ip addresses are exposed in there and stuff... if the user can call /sbin/ifconfig though maybe you can't hide that from them)
1596297381 M * Bertl_oO having any (non admin) host access potentially leaks information about guests
1596297401 M * Bertl_oO starts with /proc entries and ends with a number of syscall/netinfo interfaces
1596297422 M * Bertl_oO i.e. only host admins should have access to the host
1596297468 M * gnarface yea, Hurga ^ this guy knows what's up
1596297491 M * Bertl_oO there is some isolation via xid=0 vs xid=1 (if properly enabled in the kernel config)
1596297525 M * Bertl_oO but 'shared' IPs and similar will still leak
1596297548 M * gnarface Hurga: in case you didn't know... it's easy to get sshd on every guest by just specifying a different ip or port number in every sshd_config... you shouldn't need this for remote access
1596297619 M * gnarface Hurga: and if you are just trying to grant the ability for clients to restart their own guests, i recommend making a simple web interface for it
1596300967 J * fstd ~fstd@xdsl-81-173-175-100.nc.de
1596301435 Q * fstd_ Ping timeout: 480 seconds
1596303187 Q * Ghislain Quit: Leaving.
1596310210 M * Hurga gnarface, Bertl_oO: Thanks for the info. I know about the general problems of giving untrusted users access to the host... this was about docker administration. But that seems to work without access to the host, too, so the point is moot... thanks anyway. :)
1596310871 J * Aiken ~Aiken@b951.h.jbmb.net
1596314309 Q * Hurga Quit: Verlassend
1596317525 Q * daniel_hozac Remote host closed the connection
1596317751 J * daniel_hozac ~daniel@81-233-10-51-no42.tbcn.telia.com