insecure umask 0000 on ubuntu server

[mattja]

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.

[Antoine Martin]

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

[Antoine Martin]

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.