On Sun, Jan 30, 2022 at 12:28:06PM -0500, Wietse Venema wrote:
> > > We could redesign the master.cf 'private' field, so that for
> > > UNIX-domain sockets:
> > >
> > > master.cf directory mode
> > > y private 0700 (no change)
> > > n protected 0710 (was: public)
> > > x public local policy
> > >
> > > Postfix sockets are moved from the 'public' to the 'protected'
> > > directory, and the 'public' directory no longer contains any Postfix
> > > sockets.
> > >
> > > Then we can remove the 'public' directory from /etc/postfix/postfix-files,
> > > and leave the dirctory owner/group and permissions up to local
> > > policy. Each application can have its own subdirectory under 'public'
> > > with permissions that allow access to only that app and postfix.
> > >
> > > With inet sockets, 'y' and 'n' behave as before, and 'x' behaves
> > > like 'n'.
> >
> > Seems mostly reasonable for Postfix 3.8. The "dovecot" auth socket is
> > typically in "public" IIRC. It would probably now be "protected", and I
>
> Why? Why force third-party code to change pathnames?
Exactly. I should been more clear, the "dovecot" socket is a currently
protected directory. Perhaps not exposing a local "password oracle"
this way is intentional?
So I was wondering whether the directory currently named "public" should
remain (permission-wise) protected, with the new (permission-wise)
unprotected directly named something else?
If we ignore legacy, then indeed an unprotected "public" makes sense,
and it could have variously restricted (by local policy) sub-directories.
And then "dovecot" might have lived uner "public/dovecot/" or
"public/auth/", ...
Anyway, whatever we do, it would indeed be best to avoid forcing config
changes on the dovecot side to keep things working.
--
Viktor.
