Viktor Dukhovni:
> 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?
It works as it is NOW, and it it needs to improved, THEN they can pick
a subdirectory under 'public'. But there is no need to to do that
immediately when we remove POSTFIX sockets from the public directory.
> 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?
It could become mode 755, with dedicated per-app subdirectories and
custom permissions.
> 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/", ...
They can do that later. There is no need to do such things immediately
remove POSTFIX sockets from the public directory.
Wietse
> Anyway, whatever we do, it would indeed be best to avoid forcing config
> changes on the dovecot side to keep things working.
>
> --
> Viktor.
>
