On 9/2/2016 8:48 AM, Jeremy Harris wrote:
> On 01/09/16 19:42, Phillip Carroll wrote:
>> However, the description apparently means that if the transport requires
>> access to any file using a supplementary group membership of the default
>> exim user, then either the initgroups option or the group option must be
>> specified. If that is what it means, then instead of the presently
>> tortured English description, the doc should make that fact explicit in
>> more understandable English (prominently). In my humble opinion.
>
> Give us some suggested test, and I'll slam it right in.
>
After further reflection on this issue, I am inclined to view this as a
code bug instead of a documentation inadequacy. I am not a member of
Exim-dev list; therefore, I request reposting there.
First, Chapter 30, "The smtp transport" makes absolutely no mention of
either "initgroups" or "user" or "group". If necessary for normal *nix
behavior, this is precisely where initgroups is presently needed.
Next:
Chapter 55, section 2, contains the following:
> The processes that initially retain root privilege behave
> as follows:
>
The first bullet clearly spells out the reason for the need for the
code to call initgroups() after setting uid and gid to exim user.
(Although, it raises the question in my mind of why a library function
call should be discussed at all in a user document.):
> - A daemon process changes the gid to the Exim group and the uid
> to the Exim user after setting up one or more listening
> sockets. The initgroups() function is called, so that if the
> Exim user is in any additional groups, they will be used
> during message reception.
The second bullet is irrelevant to the discussion, as root has access to
anything:
>
> - A queue runner process retains root privilege throughout its
> execution. Its job is to fork a controlled sequence of
> delivery processes.
>
The third bullet lumps a bunch of things together. This requires really
careful reading to break out the handling of the various subprocesses:
> - A delivery process retains root privilege throughout most of its
> execution, but any actual deliveries (that is, the transports
> themselves) are run in subprocesses which always change to a
> non-root uid and gid. For local deliveries this is typically
> the uid and gid of the owner of the mailbox; for remote
> deliveries, the Exim uid and gid are used. Once all the
> delivery subprocesses have been run, a delivery process
> changes to the Exim uid and gid while doing post-delivery
> tidying up such as updating the retry database and generating
> bounce and warning messages.
(Subsequent bullets irrelevant)
The only fragment of bullet three relating to this discussion is:
"for remote deliveries, the Exim uid and gid are used".
While this wording admittedly doesn't state categorically that
initgroups() WILL be called, the sheer brevity of the statement and lack
of any explicit statement to the contrary certainly IMPLIES initgroups()
will be called. There is certainly no obvious reason from an external
user perspective for the code to deliberately go out of its way to
prevent access to data via group membership when (as explicitly
explained in the first bullet) it is so obviously normally expected *nix
behavior.
In summary, this seems an obvious BUG, with a workaround fortunately
provided by the initgroups transport option.
But, if thr current smtp transport design is unavoidable because of some
quirk of the internal code structure, then that fact should be explained
in detail in chapter 55, chapter 24, and chapter 30. It should be
explained that normal *nix group behavior does not apply to the smtp
transports "because ..." and explain that the initgroups option can be
used to workaround the issue. And, in that case, the default
configuration for remote_smtp should include the initgroups option and
an explanation as to why. And Chapter 30 should also discuss the need
for the initgroups option.
- Phil Carroll
