Yeah. I think that with a "xpra start-or-attach --display=$userid" should do about exactly what I want it to. Awesome, thank you. When might I be able to see some supporting code in the repo? I'm excited.
On Tue, Dec 24, 2019, 10:04 AM Antoine Martin via shifter-users < shifter-users@lists.devloop.org.uk> wrote: > On 23/12/2019 21:48, Celeste Weingartner via shifter-users wrote: > > Antoine, > > > > Now that I think about it I could change the command shell for those > users > > to a custom shell, and I think perhaps I could get the results I'm > looking > > for that way can you tell me if paramiko requests and interactive session > > by default? Because I think without an interactive session the shell > > specified for specific users in the password file might not fire. > The SSH session is not interactive and does not request a pty, that's > true of all the backends, not just paramiko. > What I am suggesting instead is something like this: > http://man.openbsd.org/OpenBSD-current/man5/sshd_config.5#ForceCommand > > Cheers, > Antoine > > > > > On Mon, Dec 23, 2019, 12:58 PM Antoine Martin via shifter-users < > > shifter-users@lists.devloop.org.uk> wrote: > > > >> On 23/12/2019 01:10, Celeste Weingartner via shifter-users wrote: > >>> I had considered tying it to user ID and that's a good idea. While > >> changing > >>> the remote xpra command is certainly an option I could write into the > >>> frontend, I want this to be a bit more secure and not rely on the > >> frontend > >>> to do the right thing, is there a easy way to specify a new command > >> server > >>> side and system wide?or user group wide? > >> No. > >> The remote command is requested by the SSH transport (ie: paramiko > >> openssh or plink), it is always specified by the client - that's just > >> how SSH works. > >> > >> xpra's builtin SSH server already intercepts the 'xpra _proxy' command > >> to avoid spawning a new subprocess unnecessarily. But modifying this > >> behaviour is likely way too complicated for what you are trying to > >> achieve. (and this would only work with xpra running as ssh server) > >> > >> If you want to limit what your users can execute via ssh logins then you > >> should look into OpenSSH command restrictions and you can then place > >> your override script in a whitelisted location, ie: > >> /usr/local/bin/xpra > >> To see which remote commands your clients will attempt to run, see: > >> xpra showconfig | grep remote-xpra > >> > >> Cheers, > >> Antoine > >> > >>> > >>> Sorry for the double email Antoine > >>> > >>> > >>> On Fri, Dec 20, 2019, 6:59 AM Antoine Martin via shifter-users < > >>> shifter-users@lists.devloop.org.uk> wrote: > >>> > >>>> On 19/12/2019 16:19, Celeste Weingartner via shifter-users wrote: > >>>>> im writing a frontend for Xpra that will use ssh to connect. I would > >> like > >>>>> to make a ultra persistant chrome session be remotely served.. > >>>> Running browsers through xpra seems to be a popular use case. > >>>> Are you using xpra's builtin ssh server or are you allowing those > users > >>>> shell access on your server? (and restricting what commands they are > >>>> allowed to run?) > >>>> > >>>>> Ive got > >>>>> firejail working for chrome, and i can manually connect with xpra > start > >>>>> someu...@apphost.com --start-child='google-chrome' and that works.. > >> and > >>>> i > >>>>> can reattach to it no problem but if i reisssue another start, it > >> starts > >>>>> another x session, which i do not want.. I want it limited to one per > >>>> user. > >>>> An easy way to achieve that would be to derive the X11 display for > each > >>>> user from their user id. That way a user would only ever be able to > >>>> start a single session. > >>>> FYI: most browsers, including chrome, are limited to a single instance > >>>> per user account. > >>>> > >>>> To make things easier to manage, we could add a new subcommand: > >>>> "xpra attach-or-start" > >>>> Or maybe a new flag: > >>>> "xpra attach --create=yes" > >>>> Or even: > >>>> "xpra start --reuse-session=yes" > >>>> Ideas and suggestions welcome. > >>>> > >>>> When connecting over ssh, the xpra client will run "xpra _proxy", > >>>> potentially with extra arguments, and this is what connects the xpra > >>>> server to the ssh channel. > >>>> The remote xpra command can be changed using the "--remote-xpra=" > >>>> command line option. > >>>> This would be a decent place to override the default behaviour and > start > >>>> a new server instance if one is not found, before trying to connect to > >> it. > >>>> > >>>> Cheers, > >>>> Antoine > >>>> > >>>> > >>>> > >>>> > >>>>> max. > >>>>> > >>>>> > >>>>> On Mon, Dec 16, 2019 at 6:06 AM Antoine Martin via shifter-users < > >>>>> shifter-users@lists.devloop.org.uk> wrote: > >>>>> > >>>>>> On 16/12/2019 07:59, Celeste Weingartner via shifter-users wrote: > >>>>>>> Hi Everyone, im not sure if the devel list would be the place for > >> this > >>>> or > >>>>>>> not.. So i'll ask. > >>>>>>> > >>>>>>> Im trying to use Xpra to create an application server. For a > specific > >>>>>>> application. I do not want users to be able to spawn more than 1 > xpra > >>>>>>> server process. I want them to be limited to 1. Short of disabling > >>>> server > >>>>>>> commands, and using firejail which im already doing, how can I > >> further > >>>>>>> limit it to one server per user? Im willing to be there's some > sort > >> of > >>>>>>> bash magic that can be done in the xpra startup, but im unsure > where > >> to > >>>>>>> even begin there, im not a python coder... Bash I can do.. But can > >>>>>> anyone > >>>>>>> provide some pointers or tips? > >>>>>> How are you going to start the sessions? Is it going to be on demand > >> for > >>>>>> each user? > >>>>>> How are they connecting to the server? ssh? > >>>>>> Are you going to give them a command line to run or an xpra URI they > >>>>>> just click on? > >>>>>> > >>>>>> This is not the first time something like this has been requested, > so > >>>>>> maybe we can make it easier to setup. > >>>>>> > >>>>>> Cheers, > >>>>>> Antoine > >>>>>> > >>>>>>> > >>>>>>> Thanks in advance, > >>>>>>> > >>>>>>> Celeste > >>>>>>> _______________________________________________ > >>>>>>> shifter-users mailing list > >>>>>>> shifter-users@lists.devloop.org.uk > >>>>>>> https://lists.devloop.org.uk/mailman/listinfo/shifter-users > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> shifter-users mailing list > >>>>>> shifter-users@lists.devloop.org.uk > >>>>>> https://lists.devloop.org.uk/mailman/listinfo/shifter-users > >>>>>> > >>>>> _______________________________________________ > >>>>> shifter-users mailing list > >>>>> shifter-users@lists.devloop.org.uk > >>>>> https://lists.devloop.org.uk/mailman/listinfo/shifter-users > >>>>> > >>>> > >>>> _______________________________________________ > >>>> shifter-users mailing list > >>>> shifter-users@lists.devloop.org.uk > >>>> https://lists.devloop.org.uk/mailman/listinfo/shifter-users > >>>> > >>> _______________________________________________ > >>> shifter-users mailing list > >>> shifter-users@lists.devloop.org.uk > >>> https://lists.devloop.org.uk/mailman/listinfo/shifter-users > >>> > >> > >> _______________________________________________ > >> shifter-users mailing list > >> shifter-users@lists.devloop.org.uk > >> https://lists.devloop.org.uk/mailman/listinfo/shifter-users > >> > > _______________________________________________ > > shifter-users mailing list > > shifter-users@lists.devloop.org.uk > > https://lists.devloop.org.uk/mailman/listinfo/shifter-users > > > > _______________________________________________ > shifter-users mailing list > shifter-users@lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users > _______________________________________________ shifter-users mailing list shifter-users@lists.devloop.org.uk https://lists.devloop.org.uk/mailman/listinfo/shifter-users
