Make Worker#user support different process primary group and log file group

Make Worker#user support different process primary group and log file group

[Jeremy Evans]

This patch allows Worker#user to accept the group argument as an array
of two strings, the first string being the process primary group, and
the second string being the group that owns the log files.  This can
help when you have a large number of applications that use unique
primary groups, and want to have a user with the ability to read the log
files for any of the applications, especially if you are on an operating
system that only supports a small number of groups per user.

Thanks,
Jeremy

From 780bd79d2f1fd40e7daae969ff482c3fd9d58ad7 Mon Sep 17 00:00:00 2001
From: Jeremy Evans <code@jeremyevans.net>
Date: Thu, 13 Sep 2018 11:16:38 -0700
Subject: [PATCH] Make Worker#user support different process primary group and
 log file group

Previously, Unicorn always used the process's primary group as the
the group of the log file.  However, there are reasons to use a
separate group for the log files, such as when you have many
applications where each application uses it's own user and primary
group, but you want to be able to have a user read the log files
for all applications.  Some operating systems have a fairly small
limit on the number of groups per user, and it may not be feasible
to have a user be in the primary group for all applications.
a primary group
---
 lib/unicorn/worker.rb | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/lib/unicorn/worker.rb b/lib/unicorn/worker.rb
index 68de17e..5ddf379 100644
--- a/lib/unicorn/worker.rb
+++ b/lib/unicorn/worker.rb
@@ -122,6 +122,11 @@ def close # :nodoc:
   # the +after_fork+ hook after any privileged functions need to be
   # run (e.g. to set per-worker CPU affinity, niceness, etc)
   #
+  # +group+ can be specified as a string, or as an array of two
+  # strings.  If an array of two strings is given, the first string
+  # is used as the primary group of the process, and the second is
+  # used as the group of the log files.
+  #
   # Any and all errors raised within this method will be propagated
   # directly back to the caller (usually the +after_fork+ hook.
   # These errors commonly include ArgumentError for specifying an
@@ -134,8 +139,17 @@ def user(user, group = nil, chroot = false)
     # insufficient because modern systems have fine-grained
     # capabilities.  Let the caller handle any and all errors.
     uid = Etc.getpwnam(user).uid
-    gid = Etc.getgrnam(group).gid if group
-    Unicorn::Util.chown_logs(uid, gid)
+
+    if group
+      if group.is_a?(Array)
+        group, log_group = group
+        log_gid = Etc.getgrnam(log_group).gid
+      end
+      gid = Etc.getgrnam(group).gid
+      log_gid ||= gid
+    end
+
+    Unicorn::Util.chown_logs(uid, log_gid)
     if gid && Process.egid != gid
       Process.initgroups(user, gid)
       Process::GID.change_privilege(gid)
-- 
2.17.1

Re: Make Worker#user support different process primary group and log file group

[Eric Wong]

Jeremy Evans <code@jeremyevans.net> wrote:
> This patch allows Worker#user to accept the group argument as an array
> of two strings, the first string being the process primary group, and
> the second string being the group that owns the log files.  This can
> help when you have a large number of applications that use unique
> primary groups, and want to have a user with the ability to read the log
> files for any of the applications, especially if you are on an operating
> system that only supports a small number of groups per user.

Fwiw, I don't understand why there's a blurb here for an
isolated patch when your commit message below is is sufficient :)

Along the same lines, "--cover-letter" in git-format-patch(1)
isn't necessary for single patches, either, but they help with a
multi-patch series.

> Subject: [PATCH] Make Worker#user support different process primary group and
>  log file group
> 
> Previously, Unicorn always used the process's primary group as the
> the group of the log file.  However, there are reasons to use a
> separate group for the log files, such as when you have many
> applications where each application uses it's own user and primary
> group, but you want to be able to have a user read the log files
> for all applications.  Some operating systems have a fairly small
> limit on the number of groups per user, and it may not be feasible
> to have a user be in the primary group for all applications.
> a primary group

Anyways, this featureseems acceptable.  Pushed to master as
47fddb53aa0b7763f353ba515cf3fb5b2059f4f7

Thanks