xpra icon
Bug tracker and wiki

Opened 5 years ago

Closed 5 years ago

#719 closed enhancement (fixed)

Hardcoded umasks limit some use cases

Reported by: skids Owned by: skids
Priority: minor Milestone: 0.15
Component: server Version: trunk
Keywords: chmod umask socket Cc:

Description

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.

Change History (6)

comment:1 Changed 5 years ago by Antoine Martin

Owner: changed from Antoine Martin to skids

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
  • 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.


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.

comment:2 Changed 5 years ago by skids

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 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.

comment:3 Changed 5 years ago by Antoine Martin

Milestone: 0.15
Owner: changed from skids to Antoine Martin
Status: newassigned

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 ?

comment:4 Changed 5 years ago by 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.

comment:5 Changed 5 years ago by Antoine Martin

Owner: changed from Antoine Martin to skids
Status: assignednew

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.

comment:6 Changed 5 years ago by Antoine Martin

Resolution: fixed
Status: newclosed

Not heard back, closing.

Note: See TracTickets for help on using tickets.