> On April 23, 2015, 9:16 p.m., Ben Mahler wrote:
> > 3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp, line 730
> > <https://reviews.apache.org/r/33491/diff/1/?file=940552#file940552line730>
> >
> >     I'm curious why you look at EPERM here, but not in the call to 
> > `::setgid` above and `::setuid` below? Is it possible for only some of 
> > these calls to fail with EPERM?
> 
> James Peach wrote:
>     If you do a ``setgid`` to your current GID, it succeeds and does nothing, 
> but ``initgroups`` ends up calling ``setgroups`` which fails with EPERM. If 
> you were trying to switch to a different user and you were not already 
> privileged, the ``setgid`` would already have failed.

I see, in that case, could we express it in the structure of the code more 
explicitly? Is there an easy way to capture whether we need to perform the 
operation? For example:

```
inline Try<Nothing> su(const std::string& user)
{
  Result<gid_t> gid = os::getgid(user);
  Result<uid_t> uid = os::getuid(user);

  if (gid.isError() || gid.isNone()) {
    return Error("Failed to getgid: " +
        (gid.isError() ? gid.error() : "unknown user"));
  } else if (uid.isError() || uid.isNone()) {
    return Error("Failed to getuid: " +
        (uid.isError() ? uid.error() : "unknown user"));
  }

  if (gid.get() != ::getgid()) {
    if (::setgid(gid.get()) == -1) {
      return ErrnoError("Failed to set gid");
    }
  
    if (::initgroups(user.c_str(), gid.get()) == -1) {
      return ErrnoError("Failed to set supplementary groups");
    }
  }

  if (uid.get() != ::getuid()) {
    if (::setuid(uid.get())) {
      return ErrnoError("Failed to setuid");
    }
  }

  return Nothing();
}
```

How does this interact with real, effective, and saved set-group/set-user IDs?


- Ben


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33491/#review81404
-----------------------------------------------------------


On April 23, 2015, 8:16 p.m., James Peach wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/33491/
> -----------------------------------------------------------
> 
> (Updated April 23, 2015, 8:16 p.m.)
> 
> 
> Review request for mesos, Ben Mahler and Timothy St. Clair.
> 
> 
> Bugs: MESOS-719
>     https://issues.apache.org/jira/browse/MESOS-719
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Make sure we call initgroups(3) after calling setgid(2) so that the
> auxiliary groups for the su'd user are set.
> 
> This is particularly important for docker support because it lets
> you add your mesos user to the docker group so it can talk to docker
> through /var/run/docker.sock (which is owned by a docker group by
> default in most installations.) Without initgroups, the Mesos user
> only has its primary GID set.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp 
> 02db3c587e3f9a40282405e9496bde30e251f8bb 
> 
> Diff: https://reviews.apache.org/r/33491/diff/
> 
> 
> Testing
> -------
> 
> Ran "make check" on CentOS 7 & and OS X 10.10.3.
> 
> 
> Thanks,
> 
> James Peach
> 
>

Reply via email to