This is the mail archive of the cygwin-apps 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] |
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 -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Attachment:
pgpWvYet9NXiH.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |