[ITP] libsuexec 1.0

Corinna Vinschen corinna-cygwin@cygwin.com
Sat Aug 16 11:16:00 GMT 2014

On Aug 16 12:50, Achim Gratz wrote:
> Corinna Vinschen writes:
> >> So if I'm a member of the administrators group those programs will use
> >> administrative rights while delivering mail to my inbox even though they
> >> don't need to?  That doesn't sound desirable to me in any way.
> >
> > No, they won't.  The lib just converts the uid of the current user to 0
> > within the application to keep it blissfully ignorant.  This allows to
> > run applications claiming uid 0 is something special from SYSTEM or
> > cyg_server as service, without the need to patch the sources.  It's
> > not exactly a bad idea for such services if it makes them work, I think.
> Good, I haven't checked the sources so I'll believe it.  Actually I've
> been thinking before that maybe it was a good idea to map group 544 to
> euid 0 (so that shells would be showing # as prompt without extra
> nudging), but I came to the conclusion that it probably makes more
> trouble than it's worth.  Maybe I revisit that question some time…

uid/gid == 0 is *only* used by applications which are in the server
and switch-user-context business.

It's kind of a bad idea anyway, and I'm constantly puzzled why there
are so many applications out there using this test.  Applications *not*
running with certain privileges will not be able to use certain functions
anyway.  The inability to use certain function is in 99% of the cases
indication enough that the application is running in a low-privilege
context and not running as a system-wide service.

So, while it's kind of nice from a compatibility POV to use uid/gid 0 in
certain scenarios, it doesn't make much sense most of the time.
Especially not on a system which *is* capabiliy based rather than
uid/gid==0 based.  This is a problem on other sytems as well.  Even on
Linux capabilities are getting more and more important and the uid/gid
loses its meaning.

> But anyway, I stick to my earlier assessment that this functionality
> should be incorporated into applications that need it on the source
> level, gnulib-style.  That shim is small emough so that the resulting
> duplication doesn't matter.  I can't think of a good reason to have that
> as a DLL on the other hand (other than if you'd wanted to shim at
> runtime, which is IMHO a bad idea).

Point taken.  Maybe it should be provided as a static lib only.  The
size added to the executable is, in fact, negligible.

> > Postfix for Cygwin would be *so* nice.  Sigh.  It would also be nice to
> > get Exim running on 64 bit.  But either way, sendmail is still kind of a
> > de-facto standard, so it's not bad to get it into the distro, just as
> > Fedora comes with sendmail, postfix, exim, etc.  Choice is good.
> The idea of exposing that server to the world doesn't sound exactly
> appealing to me.

Heh :)  So you're going to provide a postfix port really soon now?


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin-apps/attachments/20140816/e2e84d7d/attachment.sig>

More information about the Cygwin-apps mailing list