xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.

Opened 5 years ago

Closed 5 years ago

Last modified 17 months ago

#1635 closed defect (worksforme)

insecure umask 0000 on ubuntu server

Reported by: mattja Owned by: mattja
Priority: minor Milestone: 2.2
Component: platforms Version: trunk
Keywords: security Cc:


xterm started on the remote server (via winswitch) runs with umask 0000.
This has security impact as files/directories created by users are then world-writable.
Expected: some sensible default like 002 or 022.

Version: winswitch 0.12.23-1, xpra 2.1.1-r16658-1
Possible cause: winswitch server assumes umask will be set in /etc/bashrc.
That is true on Red Hat derived systems.
But it is not true on Ubuntu (tested 16.04 LTS) where I think umask is expected to be set by PAM session (pam_umask.so).

Perhaps related, the PAM file provided by /etc/pam.d/xpra
seems to assume a Red Hat style system and most of the PAM modules referenced there do not exist on a Ubuntu system.

Change History (4)

comment:1 Changed 5 years ago by Antoine Martin

Component: androidplatforms
Priority: majorcritical
Status: newassigned

The pam file is only used when we start sessions via the system wide proxy.
I assume that the umask is correctly set if we start sessions with --start-via-proxy=no?
Best way to fix this is to figure out the correct contents for /etc/pam.d/xpra for all Debian / Ubuntu distributions. Oh, that's going to be fun seeing the complete lack of any clear documentation on the subject.

comment:2 Changed 5 years ago by Antoine Martin

Owner: changed from Antoine Martin to mattja
Priority: criticalminor
Status: assignednew

Just tested on a bunch of Debian distros:

  • Debian 9 Stretch: default umask is set to 0022, also correctly set in the xpra session
  • Debian 8 Jessie: same as above
  • Ubuntu 17.04: same as above
  • Ubuntu 16.04: umask is 0002, but 0022 within the xpra session - which is more strict!

So, although the umask is different, it isn't set to 0000 and is in fact more strict.
The pam_umask module is yet another Ubuntu-only thing.
I've tried removing system-auth from the /etc/pam.d/xpra file and adding:

@include common-account
@include common-session
@include common-password

The pam open code succeeds but the umask is unchanged after the call. (common session includes: session optional pam_umask.so)

And... that's all I've got time for. It doesn't look like a big problem anyway since the umask is stricter.
Hopefully someone who understands what Ubuntu is doing in this area can fix this.

Last edited 5 years ago by Antoine Martin (previous) (diff)

comment:3 Changed 5 years ago by Antoine Martin

Resolution: worksforme
Status: newclosed

Not heard back, closing.

comment:4 Changed 17 months ago by migration script

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

Note: See TracTickets for help on using tickets.