Hi Paul I see that I was not clear what I meant with "in general" :-)
In the fix for pcs https://github.com/ClusterLabs/pcs/commit/de068e2066e377d1cc77edf25aed0198e4c77f7b you can see a comment that there is a change from umask(0) to umask(0x077) It was this umask(0) (in Thin::Backends::UnixServer#connect) I was referring to as "in general". I mean the fix is to override this more generic function that is obviously not secure enough. Here I found how the generic source code looks like: https://rubydoc.info/gems/thin/1.3.1/Thin%2FBackends%2FUnixServer:connect You can see the umask(0) there. That is what I think is insecure, not pcs itself. It looks like pcs code was not vulnerable because what I missed to check was whether this source code was present in buster. It was not as someone have concluded. But I think Thin::Backends::UnixServer#connect is still insecure. Cheers // Ola On Tue, 6 Sept 2022 at 03:09, Paul Wise <p...@debian.org> wrote: > On Mon, 2022-09-05 at 21:38 +0200, Ola Lundqvist wrote: > > > I agree that it is good to fix the pcs package, but shouldn't we fix > > the default umask in general? > > I would argue that the default umask is insecure. > > bookworm login sets new user home directories to secure permissions: > > $ grep -E 'HOME_MODE\s*[0-9]' /etc/login.defs > #HOME_MODE 0700 > > This somewhat mitigates, but not completely, the umask being insecure: > > $ grep -E 'UMASK\s*[0-9]' /etc/login.defs > UMASK 022 > > I can't find any bugs open about changing the default umask, > but it was mentioned in replies to the recent adduser thread: > > https://lists.debian.org/msgid-search/yiejaly0ny0+0...@torres.zugschlus.de > > -- > bye, > pabs > > https://wiki.debian.org/PaulWise > -- --- Inguza Technology AB --- MSc in Information Technology ---- | o...@inguza.com o...@debian.org | | http://inguza.com/ Mobile: +46 (0)70-332 1551 | ---------------------------------------------------------------
