Re: [mosquitto-dev] [2.0.17] Warnings regarding user/group and readabili

[Greg Troxel <gdt@xxxxxxxxxx>]

Shan D via mosquitto-dev <mosquitto-dev@xxxxxxxxxxx> writes:

> Hi Roger and team,
>
> As I went through the changelogs I saw the following:
>
>>- Broker will log warnings if sensitive files are world readable/writable,
> or
>   if the owner/group is not the same as the user/group the broker is running
>   as. In future versions the broker will refuse to open these files.
>
> I have an ACL file, Users File, and my Broker configuration that I mount
> using either Docker Compose v2. Of course, I see the warning logs for the
> UID/GID and file permissions in the Broker now.
>
> My Question is what is the rationale behind this? This will only make the
> deployment logic harder for users.

The security model for pretty much everything requires that
configuration files that control access not be writable by other than
root and the user running mosquitto, and files with passwords not be
readable with others.

For example ssh is like this.

> What this implies is that all custom files will require me to have a user
> `mosquitto` (1883 ID) which I may not wish to have configured on the
> operating system in the first place and vice versa where the files
> generated by the docker container may be mounted on the host machine with
> users which might cause mismatches as well making the directory of the
> volumes requiring root access (because GID of root) which lot of users may
> not have in the first place.

That's a little hard to follow, but yes the standard install process
requires a uid and the config file owned by that.

I am not following "GID of root".  My installation, via pkgsrc on
NetBSD, uses "mosquitto" as the user and "mosquitto" as the group (with
uninteresting uid/gid assigned at package installation time).  My config
files are mode 640.

So there is no requirement to have gid 0 (which historically is "wheel",
not root) at all, and no need to have privileged access over NFS or
other remote filesystem.

> I would like to know if there are ways to make the deployment via Docker
> compatible post 2.0.17 release so that future compatibility is maintained
> if suddenly my configuration files get rejected.

This sounds like a bug in Docker that you can't do this easily.  The
pattern of a uid for a daemon is very normal.