This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: The eternal uid issue


On Jul 23 10:06, D. Boland wrote:
> Hi Cygwin lovers,
> 
> After some weeks of serious compiling, researching, understanding, fixing, testing
> and compiling again, I managed to get the Sendmail source code compiled and working.
> 
> But I had to compromise in some critical areas. One of them is the uid issue.
> 
> * sendmail, procmail, mail.local assume that the id of the privileged user is '0'.
> 
> Within the current Cygwin DLL, this is '18'. So the maintainer of, let's say, the
> procmail code has to change a constant, named ROOT_uid to be 18 if compiled in
> cygwin. I had to do the same in Sendmails' own Mail Delivery Agent, 'mail.local'.

The port of procmail is old (2004), and not changed ever since.
This patch is old and wrong.

> But that's no real fix. That's a work-around. Cygwin is supposed to emulate Linux,
> so why not change the 'getuid' function to return '0' if the uid is '18'? This is
> exactly what all Linux source code expects, so we would never have to worry about it
> again.
> 
> Instead, maintainers constantly have to "correct" this "bug" in every new version of
> their source code.
> 
> The general idea behind this is "never to break user space", where the programs are
> seen as the users. Actually, it's Linus Torwalds's first rule of kernel programming
> and one can read here how serious he is about this:
> 
> https://lkml.org/lkml/2012/12/23/75

Doesn't work well with systemd...

> Isn't it about time to make this our First Directive also?

Not in relation to the uid.  In contrast to Linux we don't have the one
single root user.  We have potentially endless numbers of them, and one
of them, not necessarily SYSTEM, is used to run the service.  Keep in
mind that there may also be company policy in place which disallows
installing services under specific accounts unless absolutely necessary.

Therefore, while we mostly strive to make Cygwin accommodate user
space, we're not able to do it related to the root uid.

The right thing to do is to add Cygwin-required tweaks in the most
unobtrusive way you can come up with and send them upstream.  Cygwin is
by far not the only platform which requires upstream patches.  Most
portable projects have platform-specifc code.  Think of using pam for
authentication, socket options only available on some platforms and
more.  There is nothing inherently bad or wrong with that and upstream
maintainers striving for portability will take platform-specific changes
if they are nicely written and the maintainer can be convinced of the
necessity.

As for the root checks, if you *must* check for an administrative user
account, check if the group 544 is in the user token (getgroups(3),
getgrouplist(3)).

Other than that, there's often code checking file ownership, along
the lines of

  if (stat.st_uid != 0)
    ...

For Cygwin, convert these checks to something along the lines of

  if (stat.st_uid != getuid ())
    ...

Because it's basically the same thing, while allowing to run the
service under any account.

Even better, try to convince the upstream maintainer to change these
tests into a platform-specific function call, for instance:

  if (is_admin (stat.st_uid != 0))
    ...

int
is_admin (uid_t uid)
{
#ifdef __CYGWIN__
  return [getgrouplist(uid, ...) contains group 544];
#else [other platform]
  return [different test];
#else
  return uid == 0;
#endif
}


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: pgpt59ULodXAa.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]