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.
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.
There are several places where xpra hardcodes
I don't think that is the right choice of words:
- "several": only the two places that you found and the script file
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.
- we don't "hardcode" as much as make it secure, you don't want any use on the system accessing your data.. that's usually considered to be a bad idea.
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 themmap-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.
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
?
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.
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
.
Not heard back, closing.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/719