[ITP] libsuexec 1.0
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the Cygwin-apps