#1214 closed defect (wontfix)
Administrative shadow
Reported by: | psycho_zs | Owned by: | Antoine Martin |
---|---|---|---|
Priority: | major | Milestone: | future |
Component: | android | Version: | trunk |
Keywords: | Cc: |
Description
Please add the ability to shadow another user's session. Like:
xpra shadow ssh:adminuser@server:0 --xuser=someuser
AFAIK, the simplest way to do this: probe for $(getent passwd someuser | cut -d ':' -f 6)/.Xauthority
. If access is denied, prompt for sudo password and try again with sudo.
Change History (4)
comment:1 Changed 5 years ago by
Milestone: | 0.18 → future |
---|
comment:2 Changed 5 years ago by
I've tested it this way:
'commonuser' runs X :0 session on 'server', 'adminuser' connects from 'client'
adminuser@server$ sudo setfacl -m u:adminuser:r /home/commonuser/.Xauthority adminuser@server$ sudo ln -sf /home/commonuser/.Xauthority /home/adminuser/.Xauthority adminuser@client$ xpra shadow ssh:adminuser@server:0
Shadow successfully connects to 'commonuser's X session.
So the only thing sudo is needed for - give access to magic cookie. Xpra and anything else can run from 'adminuser'.
comment:3 Changed 4 years ago by
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Closing as wontfix as this is not xpra's job to get access to other sessions: you should be using xauth for that.
comment:4 Changed 6 weeks ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1214
Note: See
TracTickets for help on using
tickets.
We already have some reliable code for checking access to the X11 server, but I don't think it is xpra's job to invoke sudo.
We would need to re-launch ourselves through sudo, which is also very hard to get right. Then should you (gk)sudo, or su or..