Hi Paul Thank you for pointing out the reason why umask 0 is used. I think it is reasonable. I think it would be a good thing if the caller could tell the umask to use, or alternatively use different functions. But I let other people handle that.
Your explanation shows that the vulnerability is in pcs only and the generic code is not vulnerable since the intention was not to use it for internal communication without further authentication or similar. Cheers // Ola On Sat, 10 Sept 2022 at 03:36, Paul Wise <p...@debian.org> wrote: > On Fri, 2022-09-09 at 22:41 +0200, Ola Lundqvist wrote: > > > I see that I was not clear what I meant with "in general" :-) > > Woops, sorry for the noise :) > > > 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. > > Agreed. > > > But I think Thin::Backends::UnixServer#connect is still insecure. > > It looks like the issue was introduced in this pull request: > > https://github.com/macournoyer/thin/pull/28 > > It sounds like unicorn might have the same issue as thin. > > Looking at the unicorn code, it sets the default umask to 0 > when the umask option is not set, so not quite as bad but still. > > The justification for the default umask of 0 in unicorn is: > > # Typically UNIX domain sockets are created with more liberal > # file permissions than the rest of the application. By default, > # we create UNIX domain sockets to be readable and writable by > # all local users to give them the same accessibility as > # locally-bound TCP listeners. > > So the choice of umask 0 is deliberate in unicorn and the thin folks > copied that choice and dropped the possibility of overriding it, > since they did't have an options argument for the function. > > Since UNIX domain sockets are often used for situations that are not > like localhost TCP sockets, that was probably the wrong choice, but > the unicorn/thin folks are likely from the web developer community, > which is mostly focused on HTTP and TCP and often use localhost for > development, so it was the right choice within their bubble. > > I feel like the APIs of both thin and unicorn need redesigning so that > the choice of umask to use must be made by the caller. Then the web > developer community can use 0 and others will choose a safe value. > > Really the web developer community shouldn't use 0 either but I expect > that convincing them of that might not be possible. > > I'm not sure how palatable the API change will be to thin/unicorn. > > -- > 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 | ---------------------------------------------------------------
