Xpra: Ticket #719: Hardcoded umasks limit some use cases

There are several places where xpra hardcodes umasks rather than presenting options with secure defaults. The one that has given us the most trouble is the umask set on the unix-domain sockets. This is set to 660 on mmap sockets and 600 on remote sockets. However, there is a use case for having 660 on remote sockets -- if you wish to allow multiple users to use ssh to log into an xpra instance, you can run the instance with a gid that only the authorized users belong to, and those users can connect using the --socket-dir option.

Unfortunately it can take xpra some time to get around to actually creating the socket, especially if it has to wait for the OS to time out an old socket after a restart. So. if for example you are running the instance as a Type=simple systemd service (because there's no PIDfile), you have to jump through hoops to wait until the socket is ready before doing ExecPost? chmod.



Thu, 23 Oct 2014 18:49:39 GMT - Antoine Martin: owner changed

There are several places where xpra hardcodes


I don't think that is the right choice of words:


This is set to 660 on mmap sockets


If you intend to use mmap across users, please see the mmap-group option.

600 on remote sockets


I assume that you are talking about the unix domain sockets taking the form ~/.xpra/$HOSTNAME-$DISPLAY? (it isn't intrinsically remote, you just see it as remote if you use ssh)

What are you proposing a solution? A new command line option? I can't think of another safe way of doing this.


Thu, 23 Oct 2014 19:48:20 GMT - skids:

There are several places where xpra hardcodes


I don't think that is the right choice of words:

Well, and lots of mkdirs, but those usually only happen once during the first run so they are easier to fix permanently. I should have said "permissions" rather than "umask" explicitly, sorry.

I understand, there's always a balancing act between safety and flexibility. Making default behavior secure and also making sure security-sensitive options come with adequate warning labels is pretty important these days.

That said, what's the point of having gids if everyone avoids using them?


This is set to 660 on mmap sockets


If you intend to use mmap across users, please see the mmap-group option.

600 on remote sockets


I assume that you are talking about the unix domain sockets taking the form ~/.xpra/$HOSTNAME-$DISPLAY? (it isn't intrinsically remote, you just see it as remote if you use ssh)

Yes, these are what I meant.

What are you proposing a solution? A new command line option? I can't think of another safe way of doing this.

I would say it would suffice to put them in a subdirectory without group permissions but install them with group permissions, because the subdirectory permissions could be persistently altered once it was created whereas the sockets are dodgy. But that would offer no "warning label" so an option would probably be the best bet, I agree.


Thu, 23 Oct 2014 19:52:05 GMT - Antoine Martin: owner, status changed; milestone set

Implementing a socket permission option doesn't look too hard.

I can't think of a command that has one, do you have any suggestions for the type of syntax we want to support? (ideally identical to an existing one) Something like --socket-permission=660 ?


Thu, 23 Oct 2014 20:18:07 GMT - skids:

I like --socket-permissions (note the s). I can't say there is much consistency across server configuration options -- this would bring you in line with postgres for one if that matters. I would suggest following systemd, but I just cannot bring myself to do it because they name everything badly. They have SocketMode? which, while I recognize UNIX traditionally calls file permissions "access modes" it's not one of the UNIX traditions I'm keen to carry forward given the ambiguity.


Fri, 16 Jan 2015 12:55:12 GMT - Antoine Martin: owner, status changed

Implemented in r8485, feedback would be much appreciated.

Note: the mmap-group option takes precedence if it is enabled, and will use the same value as before: 660.


Tue, 14 Apr 2015 16:40:04 GMT - Antoine Martin: status changed; resolution set

Not heard back, closing.


Sat, 23 Jan 2021 05:03:57 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/719