Re: [ITP] Inetutils 1.9.4
Hi Corinna, Corinna Vinschen wrote: Hi Daniel, On Feb 13 07:56, D. Boland wrote: Hi Corinna, Corinna Vinschen wrote: On Feb 7 18:55, D. Boland wrote: Some programs in the inetutils suite are packaged already: * hostname * whois * tftp * tftp-server So I added these on the 'required' lines. They are not actually *required* to run inetd, right? Does it really make sense to add them as require packages then? They belong to the package. A user expects them in there and would have to piece the package back together. Why does it make sense to leave them out? These tools are provided separately in many Linux distros for quite some time, and while those tools can be started by inetd, inetd doesn't require them and they don't require inetd (xinetd is perfectly capable of replacing inetd). I don't see why this makes sense. The ping, hostname, whois and tftp programs *do* belong to the inetutils package, right? But if you insist, i'll comply. Also, the following include files are needed: * /usr/include/netinet/icmp6.h * /usr/include/netinet/ip_var.h There has been discussion on including the icmp6.h file in Cygwin 2.3.0. Can you check if icmp6.h from FreeBSD https://svnweb.freebsd.org/base/head/sys/netinet/icmp6.h?revision=279531=co does the trick when copied to /usr/include/netinet? If so, I add this file to the repo. If I use the FreeBSD version I get: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I../lib -I../lib -I../libinetutils -I../libicmp-O2 -pipe -Wimplicit-function-declaration -MT ping6.o -MD -MP -MF .deps/ping6.Tpo -c -o ping6.o ping6.c ping6.c: In function 'ping_init': ping6.c:844:37: error: 'ICMP6_FILTER' undeclared (first use in this function) setsockopt (fd, IPPROTO_ICMPV6, ICMP6_FILTER, , sizeof (filter)); That won't work. Ever. Using RAW sockets requires administrator privileges. Apart from that, WinSock setsockopt does not at all support settings for the IPPROTO_ICMPV6 protocol family. That's what the 32 bit ping package OK. I'll leave the ping6 program out. I took a (not so) quick glance over the binary packages and there are some problems: - etc/defaults/etc/init.src.sh has 000 perms. I'll fix that. - etc/defaults/etc/shells collides with the already provided file from the base-files package. I'll remove it. - usr/bin/inetutils-server-config installs inetd and syslogd in one go. That's a no no. There should be two installation scripts since you can't expect that a user who wants one service also wants the other one. Some people would probably like to stick to the Windows logging, or install syslog-ng. - Apropos syslog-ng: syslogd potentially collides with syslog-ng. However, instead of reusing the existing /usr/bin/syslogd-config script, your new scripts don't check for an existing syslog-ng installation at all. I'll create inetutils-inetd-config and inetutils-syslogd-config. The latter will check for syslog-ng existance. - You removed the etc/defaults/etc/xinetd.d files. I'll put them in. - You removed the /usr/bin/iu-config file, which was specificially created to allow running under the cyg_server account for the known reasons of being able to switch the user context(*). Your scripts enforce file ownership and service start under the SYSTEM account. That's why the csih package exists for service installation scripts to use for stuff like that. Please have a look into the old /usr/bin/iu-config file. I'll restore the iu-config script. - usr/bin/ping collides with the ping package. I'll remove ping. - sbin/ifconfig is mostly non-functional since Cygwin doesn't support most of the functionality. Do you really want to maintain it? - usr/bin/traceroute is non-functional: $ traceroute.exe www.wdr.de traceroute to e2636.g.akamaiedge.net (104.90.150.230), 64 hops max traceroute: socket: Operation not permitted That's because you're not in Administrator mode. Ping (from Atzeri's package) does the same. The error message ultimately comes from the 'sendto' function, which is in cygwin1.dll - What also irritates me is that almost none of the patches from the former package made it into your version. Did you actually check the patches from the current 1.9.1 source package and made sure that they are really not required anymore, especially concerning O_BINARY/O_TEXT mode, authentication, exception handling, and, generally, backward compatibility? What surprised me was the sheer number of patches. A whopping 573 of them. Are they bug-fixes? Features? Shouldn't both be sent upstream? What about the dont-mess-with-userspace rule? You once told me that "we mostly strive to make Cygwin accommodate user space". I'm not sure if I want to adopt inetutils with all these patches. It feels like a can of worms. I cannot find any explanations for the patches in the README files. Those patches are going to haunt me. I am a systems-programmer for 20 years
Re: [ITP] Inetutils 1.9.4
Hi Corinna, Corinna Vinschen wrote: On Feb 7 18:55, D. Boland wrote: Hi group, At Corinna's request, I re-intend to package the new version of Inetutils, version 1.9.4: http://cygwin.boland.nl/x86_64/release/inetutils/inetutils-1.9.4-2-src.tar.xz [...] Some programs in the inetutils suite are packaged already: * hostname * whois * tftp * tftp-server So I added these on the 'required' lines. They are not actually *required* to run inetd, right? Does it really make sense to add them as require packages then? They belong to the package. A user expects them in there and would have to piece the package back together. Why does it make sense to leave them out? Also, the following include files are needed: * /usr/include/netinet/icmp6.h * /usr/include/netinet/ip_var.h There has been discussion on including the icmp6.h file in Cygwin 2.3.0. Can you check if icmp6.h from FreeBSD https://svnweb.freebsd.org/base/head/sys/netinet/icmp6.h?revision=279531=co does the trick when copied to /usr/include/netinet? If so, I add this file to the repo. If I use the FreeBSD version I get: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I../lib -I../lib -I../libinetutils -I../libicmp-O2 -pipe -Wimplicit-function-declaration -MT ping6.o -MD -MP -MF .deps/ping6.Tpo -c -o ping6.o ping6.c ping6.c: In function 'ping_init': ping6.c:844:37: error: 'ICMP6_FILTER' undeclared (first use in this function) setsockopt (fd, IPPROTO_ICMPV6, ICMP6_FILTER, , sizeof (filter)); ^ Daniel
[ITP] Inetutils 1.9.4
Hi group, At Corinna's request, I re-intend to package the new version of Inetutils, version 1.9.4: http://cygwin.boland.nl/x86_64/release/inetutils/inetutils-1.9.4-2-src.tar.xz Package inetutils - category: Net requires: bash libgcc1 hostname whois tftp cygwin sdesc: "Common networking client programs" ldesc: "inetutils provides common networking clients and servers, including the inetd super-server, telnetd and telnet, ftpd and ftp, talkd and talk, uucpd (but no uucp client), and syslogd." Package inetutils-server category: Net requires: bash crypt libgcc1 inetutils tcp_wrappers tfpt-server sdesc: "Common networking server programs" ldesc: "inetutils provides common networking clients and servers, including the inetd super-server, telnetd and telnet, ftpd and ftp, talkd and talk, uucpd (but no uucp client), and syslogd." Sub-packages Some programs in the inetutils suite are packaged already: * hostname * whois * tftp * tftp-server So I added these on the 'required' lines. Source-dependencies --- To build the source code, the following packages are needed: * help2man * libcrypt-devel * libfakesu * tftp Also, the following include files are needed: * /usr/include/netinet/icmp6.h * /usr/include/netinet/ip_var.h There has been discussion on including the icmp6.h file in Cygwin 2.3.0. ip_var.h is needed for the MAX_IPOPTLEN constant. This could be added to the ip.h file as is done in Linux. Good-to-go's are welcome! Daniel
Re: network installation problems (again)
Thomas Wolff wrote: Am 01.01.2016 um 09:44 schrieb D. Boland: Thomas Wolff wrote: Hi, I am again having problems to install cygwin on a network drive. It's in the same network I had similar problems before: http://cygwin.com/ml/cygwin-apps/2009-11/msg00034.html which were then resolved after a while. The client machines are now new, running Windows 7. Domain server is the old one. My description log of actions and popup errors is attached below. There was no way to install on the network. I could install to the C: drive and move that over to the network where it would then run. Happy new year, y'all! You shouldn't try to install Cygwin on a network share and execute it locally. That's like installing and running Linux on a Samba share. If you want to use a single Cygwin distro on all computers in your network, you should install it on the target host, including the openssh daemon. Then on the client machines, you use Putty to log on to the host. I need Cygwin on the network clients, not on a server (and this has been working for years, just with occasional install problems). Also (if I understand your first sentence correctly), I did not try to install centrally for client use, but to install on a client for that client's use, just on a network drive. And in fact that's the only option on that system which is a lab network and the local (C:) drives are cleared after each reboot. -- Thomas So you're kind of hacking into your lab computers, right? :-) I noticed something in your original output: --- Fehler --- Directory H:\tmp does not exist, would you like me to create it? --- Ja Nein --- And: --- Cygwin Setup --- Cannot open log file L:\TGI\cygwin/var/log/setup.log for writing --- OK --- That's strange. Setup tries to install on different disks. Does the network share change each time you log on? Daniel
Re: network installation problems (again)
Thomas Wolff wrote: Hi, I am again having problems to install cygwin on a network drive. It's in the same network I had similar problems before: http://cygwin.com/ml/cygwin-apps/2009-11/msg00034.html which were then resolved after a while. The client machines are now new, running Windows 7. Domain server is the old one. My description log of actions and popup errors is attached below. There was no way to install on the network. I could install to the C: drive and move that over to the network where it would then run. Happy new year, y'all! You shouldn't try to install Cygwin on a network share and execute it locally. That's like installing and running Linux on a Samba share. If you want to use a single Cygwin distro on all computers in your network, you should install it on the target host, including the openssh daemon. Then on the client machines, you use Putty to log on to the host. Daniel
Updated: sendmail 8.14.9-2
Version 8.14.9-2 of "sendmail" has been uploaded. General purpose internetwork email routing facility that supports many kinds of mail-transfer and delivery methods, including SMTP, SMTPS (STARTTLS), SMTPA (AUTH) used for email transport over the internet. -- v. 8.14.9-2 * sendmail-config: fixed nslookup bug * added define(`confTO_IDENT', `0s') to cf/sendmail.mc: Sendmail timeouts if remote client has identd firewalled. * sendmail-config: fixed chown error when using 'setuid' command without previous 'install' command (Win2003) * sendmail-config: error non-existant 'mail' group when using 'setuid' command * permissions error when creating /etc/mail/virtusertable.db * /etc/mail was created group-writable permissions * added /etc/sasl2/Sendmail.conf * added /etc/mail/relay-domains * /var/run should be gid 544 (Administrators) and group-writable *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain.com cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
[ANNOUNCEMENT] Updated: sendmail 8.14.9-2
Version 8.14.9-2 of "sendmail" has been uploaded. General purpose internetwork email routing facility that supports many kinds of mail-transfer and delivery methods, including SMTP, SMTPS (STARTTLS), SMTPA (AUTH) used for email transport over the internet. -- v. 8.14.9-2 * sendmail-config: fixed nslookup bug * added define(`confTO_IDENT', `0s') to cf/sendmail.mc: Sendmail timeouts if remote client has identd firewalled. * sendmail-config: fixed chown error when using 'setuid' command without previous 'install' command (Win2003) * sendmail-config: error non-existant 'mail' group when using 'setuid' command * permissions error when creating /etc/mail/virtusertable.db * /etc/mail was created group-writable permissions * added /etc/sasl2/Sendmail.conf * added /etc/mail/relay-domains * /var/run should be gid 544 (Administrators) and group-writable *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain.com cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ITP] Inetutils 1.9.4
Corinna Vinschen wrote:
On Nov 2 10:57, Corinna Vinschen wrote:
{Forgot to CC Gernot, sorry]
On Nov 2 10:56, Corinna Vinschen wrote:
On Nov 2 08:02, D. Boland wrote:
Marco Atzeri wrote:
On 01/11/2015 15:19, D. Boland wrote:
Marco Atzeri wrote:
Arghh! I also forgot I had to install (copy) some missing include files.
Thanks for checking this.
I got these from the glibc-2.21 source code:
Please use BSD files, not glibc, for licensing reasons.
/usr/include/arpa/tftp.h
tftp has this
https://cygwin.com/packages/x86_64/tftp/tftp-5.2-1
/usr/include/netinet/icmp6.h
not yet included
https://cygwin.com/cgi-bin2/package-grep.cgi?grep=icmp6.h=x86_64
The MAX_IPOPTLEN constant is in ip_var.h. I got that from OpenBSD source:
I applied ther matching patch to the Cygwin repository.
So... Do I have the GTG?
Daniel
Re: [ITP] Inetutils 1.9.4
Marco Atzeri wrote: On 01/11/2015 00:02, D. Boland wrote: Marco Atzeri wrote: Have you forgot to update Fakesu package or there is a wrong include ? Regards Marco Oops, sorry about that. I forgot to update. I just updated libfakesu to version 1.2.0-0 Sincerely, Daniel Hi Daniel, with that is still failing a bit later on 64bit: gcc -std=gnu99 -O2 -pipe -Wimplicit-function-declaration -o tftp tftp.o ../libinetutils/libinetutils.a ../lib/libgnu.a -lutil /usr/lib/libfakesu.a gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I../lib -I../lib -I../libinetutils -I../libicmp -DPATH_CONSOLE=\"/dev/console\" -DPATH_CP=\"/usr/bin/cp\" -DPATH_INETDCONF=\"/etc/inetd.conf\" -DPATH_INETDDIR=\"/etc/inetd.d\" -DPATH_INETDPID=\"/var/run/inetd.pid\" -DPATH_LOGCONF=\"/etc/syslog.conf\" -DPATH_LOGCONFD=\"/etc/syslog.d\" -DPATH_LOGIN=\"/usr/bin/login\" -DPATH_LOGPID=\"/var/run/syslog.pid\" -DPATH_NOLOGIN=\"/etc/nologin\" -DPATH_RLOGIN=\"/usr/bin/rlogin\" -DPATH_RSH=\"/usr/bin/rsh\" -DPATH_UUCICO=\"/usr/sbin/uucp/uucico\" -O2 -pipe -Wimplicit-function-declaration -MT traceroute.o -MD -MP -MF .deps/traceroute.Tpo -c -o traceroute.o traceroute.c traceroute.c:110:14: error: 'MAX_IPOPTLEN' undeclared here (not in a function) char ip_opts[MAX_IPOPTLEN]; ^ traceroute.c: In function 'get_hostname': traceroute.c:461:5: warning: return discards 'const' qualifier from pointer target type return info->h_name; ^ Makefile:1691: recipe for target 'traceroute.o' failed make[2]: *** [traceroute.o] Error 1 Arghh! I also forgot I had to install (copy) some missing include files. Thanks for checking this. I got these from the glibc-2.21 source code: /usr/include/arpa/tftp.h /usr/include/netinet/icmp6.h The MAX_IPOPTLEN constant is in ip_var.h. I got that from OpenBSD source: /usr/include/netinet/ip_var.h The latter I also needed for my Sendmail package. Also, the following Cygwin packages are required to compile the source code: help2man perl-Locale-gettext After this, it should compile. Are these files included in any Cygwin package? Is there an elegant way to include these in my source package? Daniel
Re: [ITP] Inetutils 1.9.4
Marco Atzeri wrote: On 01/11/2015 15:19, D. Boland wrote: Marco Atzeri wrote: Arghh! I also forgot I had to install (copy) some missing include files. Thanks for checking this. I got these from the glibc-2.21 source code: /usr/include/arpa/tftp.h tftp has this https://cygwin.com/packages/x86_64/tftp/tftp-5.2-1 /usr/include/netinet/icmp6.h not yet included https://cygwin.com/cgi-bin2/package-grep.cgi?grep=icmp6.h=x86_64 The MAX_IPOPTLEN constant is in ip_var.h. I got that from OpenBSD source: /usr/include/netinet/ip_var.h The latter I also needed for my Sendmail package. Also, the following Cygwin packages are required to compile the source code: help2man perl-Locale-gettext After this, it should compile. Are these files included in any Cygwin package? Is there an elegant way to include these in my source package? So how do I do this? I could include icmp6.h and ip_var.h in the source package and conditionally install it to /usr/include in the 'src_compile' handler, previous to the 'make' command. I'll leave tftp out of the distribution. That subpackage of inetutils is maintained by Gernot Hiller. On the other hand, I'd be happy to adopt it... Cheers, Daniel
[ITP] Inetutils 1.9.4
Hi group, I intend to package the new version of Inetutils, version 1.9.4. Package inetutils - category: Net requires: bash libgcc1 hostname whois cygwin sdesc: "Common networking client programs" ldesc: "inetutils provides common networking clients and servers, including the inetd super-server, telnetd and telnet, ftpd and ftp, talkd and talk, uucpd (but no uucp client), and syslogd." Package inetutils-server category: Net requires: bash crypt libgcc1 inetutils tcp_wrappers sdesc: "Common networking server programs" ldesc: "inetutils provides common networking clients and servers, including the inetd super-server, telnetd and telnet, ftpd and ftp, talkd and talk, uucpd (but no uucp client), and syslogd." As you can see, I kept the 'hostname' and 'whois' programs out of the distribution, and added them on the 'required' line, see: https://cygwin.com/ml/cygwin-apps/2015-07/msg00046.html I guess I could have just announced the update, but since I am adopting the package, maybe I should submit it for approval first: http://cygwin.boland.nl/x86/release/inetutils/ Good-to-go's are welcome! Daniel
[ANNOUNCEMENT] Updated: libfakesu 1.2.0
Version 1.2.0-0 of "libfakesu" has been uploaded. This library simulates the Unix root user. It is meant to make porting Unix programs to Cygwin easier. Many Unix daemon programs, such as Apache, Sendmail and Procmail, start up as root but change to an unprivileged user ID. By including this library, any Cygwin super-user (member of the 'Administrators' group) will be represented with user id '0' to your program. Version 1.2.0 * added the following functions: fstatat * addedd the /usr/bin/fakesu command for finding occurrances of the uid functions implemented in libfakesu * split fakesu.h into separate include files, so patching can be automated with sed. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain.com cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ITP] Inetutils 1.9.4
Marco Atzeri wrote: $ cygcheck -c libfakesu Cygwin Package Information Package VersionStatus libfakesu1.1.0-0OK $ cygcheck -l libfakesu /usr/include/fakesu.h /usr/lib/libfakesu.a /usr/share/doc/libfakesu/LICENSE /usr/share/doc/libfakesu/README Have you forgot to update Fakesu package or there is a wrong include ? Regards Marco Oops, sorry about that. I forgot to update. I just updated libfakesu to version 1.2.0-0 Sincerely, Daniel
Re: Procmail stackdumps
gjnospam2014-cygwi...@yahoo.com schreef op 20-8-2015 om 11:23:
Hi,
I have a problem with a procmail recipe which previously worked but now
doesn't, and causes procmail to generate a stackdump.
:0
# * ^Subject:.* something or other
{
:0 BW
* ^KeyWord
{
:0 b
NUM_FOUND=|${PMD_DIR}/numOfMatches
:0 b
SEARCH_NAME=|${PMD_DIR}/searchName
}
# :0 hfw
# | $FORMAIL -i "Subject: $SEARCH_NAME found $NUM_FOUND_FOUND matches"
}
Interestingly, each of the recipes in the inner block works perfectly
individually (i.e. if I comment out the other one), but when they follow one
another like that I get the following in my procmail log:
2 [main] procmail 1812 fork: child -1 - forked process 468 died
unexpectedly, retry 0, exit code 0xC12D, errno 11
16015111 [main] procmail 1776 fixup_mmaps_after_fork: ReadProcessMemory failed
for MAP_PRIVATE address 0x7FDF906, Win32 error 998
16017947 [main] procmail 1776 C:\cygwin64\bin\procmail.exe: *** fatal error in
forked process - recreate_mmaps_after_fork_failed
16020300 [main] procmail 1776 cygwin_exception::open_stackdumpfile: Dumping
stack trace to procmail.exe.stackdump
16084774 [main] procmail 1812 fork: child -1 - forked process 1776 died
unexpectedly, retry 0, exit code 0x100, errno 11
procmail: Terminating prematurely whilst waiting for fork
Folder: **Bounced**0
but only after waiting an inordinately long time and applying ctrl-c to
procmail.
The stackdump file is created before that, I can see that happening, and
contains:
Stack trace:
FrameFunctionArgs
022F368 0018007201E (001802110C0, 00180210E86, 0008000, 022E1F0)
022F368 00180046EA2 (022F258, 001801E4EF0, 022FB00, 022F368)
022F368 00180046EE2 (000, 022EF38, 0008000, 001004102A8)
022F368 00180047454 (002, 0018004, 0018004, 000)
022F368 00180048920 (001004183AC, 00100418DD4, 022F358, 000778DFFFC)
022F368 001800C62E9 (00077A9B799, 03A2C20, 03A27B0, 03A27B0)
00077B65468 00077A9B108 (000, 022F490, 000, 000)
00077B65468 00077AA1E5A (00077AA4071, 022FB00, 000, 000)
000 00077AA1937 (000, 7FD7000, 000, 000)
000 00077A8C34E (000, 7FD7000, 000, 000)
End of stack trace
Even if I put the recipes into separate blocks (still within the outer block,
but in two separate blocks) the problem occurs. I'm baffled.
Yours, sincerely,
Baffled
Hi Baffled,
Sorry for the delay. I'll look into it.
Daniel
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Inetutils 1.9.4
Hi group, I am working on the release of the recently adopted inetutils package. I noticed that parts of this package are being released seperately: PROGRAM PACKAGE MAINTAINER whois whois David R. hostnamehostnameChristian F. Should/can I adopt these packages too? Cheers, Daniel
[ITA] inetutils
I noticed that the package is orphaned. I 'd like to adopt it. Cheers, Daniel Boland
Re: [ITP] Sendmail 8.14.9
Hi Group, I have considered your suggestions, and changed the package accordingly: http://cygwin.boland.nl/x86/release/sendmail/ * I added the following man pages to the Alternatives system: mailq(1), newaliases(1), aliases(5), sendmail(8). * I separated the following functions from the postinstall script and put them in the /usr/bin/sendmail script: - Creation of user and group accounts. - Installation of services. - Setting alternatives to manual mode * I removed the formatted man pages in /usr/share/man/cat*, and added troff versions in /usr/share/man/man*. * I moved the config files to the designated location /etc/defaults/etc Also, for Sendmail to be able to log, the syslogd from the inetutils-server package has to be installed. I noticed that the inetutils package is orphaned. Could I adopt it? Cincerely, Daniel D. Boland wrote: Hi group, I intend to package the Cygwin version of Sendmail, version 8.14.9. sdesc: The Mail Transfer Agent ldesc: General purpose internetwork email routing facility that supports many kinds of mail-transfer and delivery methods, including SMTP, SMTPS (STARTTLS), SMTPA (AUTH) used for email transport over the internet. category: Mail requires: m4 procmail tcp_wrappers cyrus-sasl cygrunsrv cygwin version: 18.14.9-0 http://cygwin.boland.nl/x86/release/sendmail/ All GTG's are welcome. Cheers, Daniel -- Sent by my Altair 8800 -- boland automatisering Deimanstraat 354 2522 BV Den Haag mailto:i...@boland.nl http://www.boland.nl phoneto:+31 (0)70 3900941 -
Re: [ITP] Sendmail 8.14.9
Corinna Vinschen wrote: Hi Daniel, On Nov 15 19:40, D. Boland wrote: BTW: The procmail package is also affected. Its postinstall script creates a local group 'mail' using 'net localgroup ...'. This should be changed, IMO. Ouch, I didn't see that when I GTGed the package :( Yes, that should definitely be changed for the same reasons. I uploaded version 15 of the Procmail 3.22 package (see my announcement in the cygwin group). Thanks. Just FYI for the next time: You sent the announcement message to the wrong mailing list. Announcements should go to the (moderated) cygwin-announce mailing list, without the leading [ANNOUNCEMENT] in the subject line. After approval, they go to the cygwin-announce ML and are automatically bounced to the cygwin ML with the leading [ANNOUNCEMENT] text. The last time I did that, all my subsequent posts where seen as spam and I had to ask the postmaster to unblock my emails. The postmaster (Faylor) wrote that announce at cygwin is a spam trap and I shouldn't post there. I *did* have the leading [ANNOUNCEMENT] in the subject text. Could that be the problem? D.
SSH key for upload access
Name: Daniel Boland Package: procmail BEGIN SSH2 PUBLIC KEY Comment: 2048-bit RSA, converted by daniel@dimension from OpenSSH B3NzaC1yc2EDAQABAAABAQDVlIM8TfGSHpmiAwsSEhICBk7CWSTHkH+3hQDO25 jpVcbcsL3+ETIjXENz8Ik3gxZbO9l5AFMZWKx3wjK1ev5SbIQ3u7vRZOjWMLmTBOgMTh19 Bn9uDd/2l0cKTrb4x2lm9GWpkh9CN1at0wgohMFLi6v/x3L17Bn54YToin+sGBkh6djJio 0bt0P7SpdwgOFGSYdQbxAvmPhXi5RMO9VKXkCud2taoOac4IxtaEgiTi8CuoVWwDlQ4uLo JHljGr5vH4Ap7W5MGVN00GnQ/pp7uOR3CRHsel8Hjx5w2/yBIIwAcm5sEpL6CkuKVPLEQQ yl6Wn/xZAvcoYZSjL6+Mkn END SSH2 PUBLIC KEY
Re: [ITP] Sendmail 8.14.9
Hi Corinna, Corinna Vinschen wrote: On Nov 3 18:16, Christian Franke wrote: Corinna Vinschen wrote: On Nov 2 13:43, Christian Franke wrote: D. Boland wrote: Christian Franke wrote: The following should IMO never be done in a postinstall script: - Creation of user and group accounts. - Installation of services. - Setting alternatives to manual mode (/usr/sbin/alternatives --set ...) Please consider moving the above to the sendmail-config script. All steps in postinstall are necessary for running Sendmail. Note that the above steps are re-done on each package update. The installation of sendmail does not imply that the user wants to run it immediately. These are important points. For other services we never create the accounts without the user explicitely requesting them by calling the service-config script. The other problem is that you don't know if creating the a local account is the right thing to do. In many companies there are restrictions on creating a local account and a domain account has to be created instead. Your config script has to take that into account by checking if a matching user account exists already or to ask the user if it should be created. BTW: The procmail package is also affected. Its postinstall script creates a local group 'mail' using 'net localgroup ...'. This should be changed, IMO. Ouch, I didn't see that when I GTGed the package :( Yes, that should definitely be changed for the same reasons. I uploaded version 15 of the Procmail 3.22 package (see my announcement in the cygwin group). The group-creation is now done in the procmail-config script. The default group 'mail' can optionally be changed to another one. Cheers, Daniel
[ANNOUNCEMENT] Updated Procmail 3.22-15
I updated the Procmail 3.22-14 package. The difference with the previous version: * Split the postinstall.sh script into two parts. The second part is now contained in the /usr/bin/procmail-config script. * The new /usr/bin/procmail-config script contains installation steps for automatically creating a new local group, called 'mail'. * The config script also contains an option to create another group instead of the default 'mail' group. Cheers, Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ITP] Sendmail 8.14.9
Hi Corinna, Corinna Vinschen wrote: On Nov 3 18:16, Christian Franke wrote: Corinna Vinschen wrote: On Nov 2 13:43, Christian Franke wrote: D. Boland wrote: Christian Franke wrote: The following should IMO never be done in a postinstall script: - Creation of user and group accounts. - Installation of services. - Setting alternatives to manual mode (/usr/sbin/alternatives --set ...) Please consider moving the above to the sendmail-config script. All steps in postinstall are necessary for running Sendmail. Note that the above steps are re-done on each package update. The installation of sendmail does not imply that the user wants to run it immediately. These are important points. For other services we never create the accounts without the user explicitely requesting them by calling the service-config script. The other problem is that you don't know if creating the a local account is the right thing to do. In many companies there are restrictions on creating a local account and a domain account has to be created instead. Your config script has to take that into account by checking if a matching user account exists already or to ask the user if it should be created. BTW: The procmail package is also affected. Its postinstall script creates a local group 'mail' using 'net localgroup ...'. This should be changed, IMO. Ouch, I didn't see that when I GTGed the package :( Yes, that should definitely be changed for the same reasons. I understand. I'll come up with an elegant solution for procmail ASAP. D.
Re: [ITP] Sendmail 8.14.9
Hi Christian,
Christian Franke wrote:
D. Boland wrote:
Hi group,
I intend to package the Cygwin version of Sendmail, version 8.14.9.
category: Mail
requires: bash libdb4.8 libgcc1 libopenssl100 libsasl2_3 libwrap0
inetutils-server
m4 procmail tcp_wrappers cyrus-sasl cygrunsrv
sdesc: The Mail Transfer Agent (mail server)
ldesc: General purpose internetwork email routing facility that supports
many kinds
of mail-transfer and delivery methods, including SMTP, SMTPS (STARTTLS),
SMTPA
(AUTH) used for email transport over the internet.
I've implementented the alternatives mechanism, so it can be installed
alongside
other Mail Transfer Agents, such as Exim, Postfix or ssmtp.
Please handle also the following man pages via alternatives:
mailq(1), newaliases(1), aliases(5), sendmail(8).
These definitely will be in conflict with upcoming postfix package. Use
e.g. aliases.sendmail.5.gz as the real filename (as done on Fedora).
See also https://cygwin.com/ml/cygwin-apps/2014-10/msg00010.html and its
attachment.
Is it possible for the Postfix package to not override the 'sendmail' man page?
That
way one can compare the two programs without having to switch like this:
/usr/sbin/alternatives --set mta /usr/sbin/postfix
man sendmail
/usr/sbin/alternatives --set mta /usr/libexec/sendmail
man sendmail
Further suggestions:
The following should IMO never be done in a postinstall script:
- Creation of user and group accounts.
- Installation of services.
- Setting alternatives to manual mode (/usr/sbin/alternatives --set ...)
Please consider moving the above to the sendmail-config script.
All steps in postinstall are necessary for running Sendmail. The sendmail-config
script contains steps where user-intervention is needed.
I'll move the '--set' instruction to the 'sendmail-config' script.
I will provide a pre-remove script that rolls back user-creation and
service-installation.
- Remove formatted man pages in /usr/share/man/cat*, add troff versions
in /usr/share/man/man*.
I will comply, but consider the following. Making man pages smear lines of text
across the entire width of the screen makes the text unreadable and the layout
ugly,
especially with the omnipresent wide-screen displays nowadays.
- Move /etc/mail/FILE.default to /etc/defaults/etc/mail/FILE,
(post)install the files to /etc/mail if not existing, (pre)remove later
if not changed. The cygport function make_etc_defaults is your friend :-)
- Try to provide a debug package. Try to add this to CFLAGS:
-ggdb -fdebug-prefix-map=${B}=/usr/src/debug/${PF}
Cygport may or may not handle the remaining details then.
I'll try that.
Cincerely,
Daniel
[ITP] Sendmail 8.14.9
Hi group, I intend to package the Cygwin version of Sendmail, version 8.14.9. category: Mail requires: bash libdb4.8 libgcc1 libopenssl100 libsasl2_3 libwrap0 inetutils-server m4 procmail tcp_wrappers cyrus-sasl cygrunsrv sdesc: The Mail Transfer Agent (mail server) ldesc: General purpose internetwork email routing facility that supports many kinds of mail-transfer and delivery methods, including SMTP, SMTPS (STARTTLS), SMTPA (AUTH) used for email transport over the internet. I've implementented the alternatives mechanism, so it can be installed alongside other Mail Transfer Agents, such as Exim, Postfix or ssmtp. http://cygwin.boland.nl/x86/release/sendmail/ Daniel
[ITP] Sendmail 8.14.9
Hi group, I intend to package the Cygwin version of Sendmail, version 8.14.9. category: Mail requires: bash libdb4.8 libgcc1 libopenssl100 libsasl2_3 libwrap0 inetutils-server m4 procmail tcp_wrappers cyrus-sasl cygrunsrv sdesc: The Mail Transfer Agent (mail server) ldesc: General purpose internetwork email routing facility that supports many kinds of mail-transfer and delivery methods, including SMTP, SMTPS (STARTTLS), SMTPA (AUTH) used for email transport over the internet. I've implementented the alternatives mechanism, so it can be installed alongside other Mail Transfer Agents, such as Exim, Postfix or ssmtp. http://cygwin.boland.nl/x86/release/sendmail/ Daniel
Re: MTA packaging (exim, postfix, sendmail, ssmtp)
Hi Yaakov, Yaakov Selkowitz wrote: Corinna, Christian, Daniel, Pierre, Because MTAs must be user-configured, and we certainly don't want to lose the selection during package upgrades, the alternatives cannot be handled in package postinst/prerm. I think the only way to make this work is for each MTA config script to handle these instead by including the following snippets in the respective MTA config scripts. Please review this carefully in case I missed anything. sendmail: /usr/sbin/alternatives --install /usr/sbin/sendmail mta /usr/sbin/sendmail-real.exe 0 \ --slave /usr/lib/sendmail mta-sendmail /usr/sbin/sendmail-real.exe \ --slave /usr/bin/mailq mta-mailq /usr/sbin/sendmail-real.exe \ --slave /usr/bin/newaliases mta-newaliases /usr/sbin/sendmail-real.exe \ --slave /usr/bin/rmail mta-rmail /usr/sbin/sendmail-real.exe /usr/sbin/alternatives --set mta /usr/sbin/sendmail-real.exe Thanks. I will use these with a slight modification. My source code is currently being used on Cygwin, Ubuntu, Lubuntu, Kubuntu, Debian and Suze. So I already had to come up with a solution which would work for all of these systems. My solution is to install the Sendmail binary into /usr/libexec. This works beautifully, because now the shared namespace /usr/sbin/sendmail can be overwritten, without removing the actual binary. Sincerely, Daniel
Re: command line smtp client / command line email?
Hi Marilo, Marilo wrote: what are my options for a command line smtp client in cygwin? I'd want to specify smtp server and from address. I'd like TLS/SSL to be supported by the command sendmail , doesn't look like it exists on cygwin and I know on *nix it shuts down any postfix server so I guess it mighttry to shut down any smtp server I have running. heirloom mailx looks good, but doesn't exist for cygwin. I can't see anything for sending an email from/in cygwin I almost finished porting Sendmail for Cygwin. It does not shut down Exim or Postfix, but it needs an open port 25 to the outside. Most ISP's don't allow this. The 'email' program can be configured to use the SMTPA (AUTH) port 465 of your ISP. I've been using it for over a year now. No corrupt message body yet. Cheers, Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ITP] libfakesu 1.0
Hi Christian,
Christian Franke wrote:
D. Boland wrote:
Christian Franke wrote:
D. Boland wrote:
http://cygwin.boland.nl/x86/release/libfakesu/
A few notes regarding cygfakesu.c:
uid_t root_uid = 18;
gid_t root_gid = 544;
uid_t my_uid = -1;
gid_t my_gid = -1;
struct passwd my_pw;
struct group my_grp;
char str255[255];
...
uid_t uid_get(uid_t uid){
...
gid_t gid_get(gid_t gid){
...
etc...
Variables and functions not exported by the fakesu.h file should be
declared as static. Note that the cygfakesu.def file has no effect when
generating a static lib.
I added 'static' for un-exported symbols. Removed cygfakesu.def.
Thanks.
BTW: All these variables except root_uid/gid are not needed as static
globals:
my_uid is only used to pass the uid from uid_get/set() to get/set(e)uid().
my_pw and str255 are only needed because su_getpwnam() calls
getpwnam_r() instead of getpwnam().
I did that to avoid writing into 'external' memory. Would calling getpwnam
directly
be thread-safe?
etc.
int su_setgroups(int size, const gid_t *list){
...
gid_t l[s];
...
return setgroups(size, l);
setgroups() 2nd parameter expects a type compatible to 'pointer to const
git_t'
The type of 'l' is 'pointer to array of git_t' :-)
(cosmetic in C, compilation would fail in C++):
I added typecasting, like this:
return setgroups(size, (gid_t *) l);
No cast is needed, simply remove the '' operator:
return setgroups(size, l);
Remember that a C array is implicitly converted to 'pointer to first
element' in many cases, including the above.
Another unrelated suggestion:
Add defines to fakesu.h for other uid/gid related functions which are
not implemented by fakesu:
#define setreuid(a,b) getruid_MISSING(a,b)
#define getpwnam_r(a,b,c,d,e) getpwnam_r_MISSING(a,b,c,d,e)
...
I'll implement the missing functions.
Daniel
Re: [ITP] libfakesu 1.0
Hi Christian,
Christian Franke wrote:
D. Boland wrote:
http://cygwin.boland.nl/x86/release/libfakesu/
A few notes regarding cygfakesu.c:
uid_t root_uid = 18;
gid_t root_gid = 544;
uid_t my_uid = -1;
gid_t my_gid = -1;
struct passwd my_pw;
struct group my_grp;
char str255[255];
...
uid_t uid_get(uid_t uid){
...
gid_t gid_get(gid_t gid){
...
etc...
Variables and functions not exported by the fakesu.h file should be
declared as static. Note that the cygfakesu.def file has no effect when
generating a static lib.
I added 'static' for un-exported symbols. Removed cygfakesu.def.
$ gcc -Wall cygfakesu.c
...
cygfakesu.c:52:2: warning: implicit declaration of function âgetuidâ
[-Wimplicit-function-declaration]
...
Include of unistd.h is missing.
Added it.
int su_setgroups(int size, const gid_t *list){
...
gid_t l[s];
...
return setgroups(size, l);
setgroups() 2nd parameter expects a type compatible to 'pointer to const
git_t'
The type of 'l' is 'pointer to array of git_t' :-)
(cosmetic in C, compilation would fail in C++):
I added typecasting, like this:
return setgroups(size, (gid_t *) l);
Would that satisfy c++?
Anyway, thanks for pointing it out.
Daniel
Re: [ITP] libfakesu 1.0
Hi Corinna,
Corinna Vinschen wrote:
Daniel,
On Aug 25 15:07, Ken Brown wrote:
On 8/25/2014 2:58 PM, D. Boland wrote:
Hi Achim,
Achim Gratz wrote:
D. Boland writes:
It's waiting for upload at:
http://cygwin.boland.nl/x86/release/libfakesu/
cygmake install PREFIX=${D}/usr
You wouldn't need to do this if your Makefile was using $(DESTDIR) for
supporting staged builds. Otherwise, packaging looks OK to me -- GTG.
I changed the Makefile to use DESTDIR.
I also uploaded the fakesu release files via sftp, but I can't seem to
create the
!ready file. If I do:
put /dev/null -o !ready
I get:
Uploading /dev/null to /x86/-o
/dev/null is not a regular file
sftp doesn't support put -o, according to its man page. The upload
instructions recommend using lftp.
did you try Ken's tip in the meantime? I still don't see the new
package in the release area...
Ahhh I'm back! My email was being blocked.
I followed Ken's tip. It worked. fakesu has already been added to the
distribution.
Daniel
Re: MTA packaging (exim, postfix, sendmail, ssmtp)
Hi Yaakov,
Yaakov Selkowitz wrote:
Corinna, Christian, Daniel, Pierre,
While I'm working out the details of allowing all your MTA packages to
coexist, it would be helpful if you could clarify under what
circumstances, if any, you expect that your MTA could function as
/usr/sbin/sendmail for the purposes of sending outgoing mail without any
configuration on the part of users.
Sendmail needs to be started as a service. If you mean the Cygwin user (she who
installs Sendmail), I included a postinstall script. It installs the 'CYGWIN
sendmail' service, creates the Sendmail unprivileged user ('smmsp') and sets
permissions, needed by sendmail. Permissions are set on the following
directories
and files:
/usr/sbin/sendmail.exe
/var/empty (only if sshd is not installed)
/etc/mail/
/var/spool/clientmqueue
/var/spool/mqueue
Also, I included a /usr/bin/sendmail-config script, which checks the full
hostname
of the box. If the hostname cannot be used as a fully qualified domain name, the
script suggests to change the Primary DNS suffix of the box.
If you mean the e-mail user who sends mail, no configuration is needed.
My source package will also be compiled by Ubuntu, Suze and Raspbian (Raspberry
PI)
users. These OS-es are very likely to use alternatives also.
To avoid overriding any symlinks, I am considering changing the Makefile, so it
will
install the binaries and system binaries like so:
/usr/sbin - /usr/libexec
/usr/bin - only if non-existant
Your thoughts on this?
Daniel
Re: [ITP] libfakesu 1.0
Hi Achim,
Achim Gratz wrote:
D. Boland writes:
It's waiting for upload at:
http://cygwin.boland.nl/x86/release/libfakesu/
cygmake install PREFIX=${D}/usr
You wouldn't need to do this if your Makefile was using $(DESTDIR) for
supporting staged builds. Otherwise, packaging looks OK to me -- GTG.
I changed the Makefile to use DESTDIR.
I also uploaded the fakesu release files via sftp, but I can't seem to create
the
!ready file. If I do:
put /dev/null -o !ready
I get:
Uploading /dev/null to /x86/-o
/dev/null is not a regular file
Daniel
Re: [ITP] Sendmail 8.14.9
Hi Yaakov, Yaakov Selkowitz wrote: On 2014-08-22 13:19, D. Boland wrote: On Aug 22 07:43, D. Boland wrote: I re-packaged Sendmail with cygport. See: http://cygwin.boland.nl/x86/release/sendmail/ Packaging looks good in theory. Unfortunately we have a problem. On inspection of your binary package I noticed that we have conflicts with exim and ssmtp packages: [snip] What we'll have to do to fix this problem is to convert all three packages to use alternatives. The alternatives package exists and is already used by a couple of other packages which would otherwise conflict, so there's precendent. And on Fedora, the various mail packages all use alternatives, too, to install their packages in parallel and conflict-free. [snip] You already guessed it. I don't like it. It's getting very messy this way. Not doing this properly will be even more messy, I assure you. I'm sorry for the following rant, [snip] Rants and flamewars really aren't helpful. The FOSS ecosystem not only allows for the possibility of alternative solutions, but thrives on it. So while we probably agree that sendmail is the first and in some ways a de-facto standard (at least in terms of program names and paths), and is certainly worthy of consideration for our distribution, it does not negate the legitimacy of exim/postfix/ssmtp/etc. Ok, that being out of the way: I am running out of time, and I still have to do the 64bit version. Running out of time for what? Keep in mind that being a package maintainer is more than just shipping a release and forgetting about it; given the nature of this package in particular, there are certainly going to be issues that come up from users. Dealing with this is part of the commitment of being a package maintainer. That being said, the more time we spend upfront doing this right should help mitigate even worse problems down the road should we not. Also, the 32-bit and 64-bit versions should be done together, particularly as we're going to have to rebuild other packages to make these all coexist. Therefore, it would be helpful if you could start working on the 64-bit ports in the meantime. Thanks for letting me have my rant. I put in my time and I will continue to do so. I think Sendmail, and for that matter, Redhat are worth it. You guys were the original believers in open source software, putting your own time and resources on the line. I still have an original 6.1 version running for 14 years now. Never crashed, never had problems. I've read the 'alternatives' documentation and it looks nasty: link groups, master link, slave link, automatic mode, manual mode... alternatives really isn't that hard to understand, and we'll help coordinate a working configuration for all the potentially conflicting MTAs. Why not let the user choose one program? Putting both Exim and Sendmail on one box is confusing, to say the least. Sendmail is very tough to understand. You don't want another (very similar looking) mail exchanger to add to the confusion. Cygwin's setup*.exe does not support the concept of conflicts (one package blocking others from being installed), nor does it prevent file clobbering if multiple packages provide the same file. Since there is no way to stop multiple MTAs from being installed, it is necessary to insure that they do so properly. Besides, at least in Fedora, it is possible to install multiple MTAs without conflicts. You really put me on the spot here. Will Sendmail suffer? Will it dream? This needs to be handled properly, that's all, and that can take time. If Pierre doesn't respond soon, we can step in to help with exim. So I will not be left alone with this. That's a relief. I'll wait with the uploading. In the mean time I'll update the Procmail and Sendmail code to use the new 'fakesu' lib. About the 64bit version: Are there any things I have to be careful of? Like crosscompiling? Or is it a matter of just straight forward compiling on a 64bit Cygwin machine? Daniel
[ITP] libfakesu 1.0
Hi Group, I intend to package this new Cygwin library. It was renamed due to name conflicts. See the following thread for more information: http://cygwin.com/ml/cygwin-apps/2014-08/msg00102.html It's waiting for upload at: http://cygwin.boland.nl/x86/release/libfakesu/ Daniel
Re: [ITP] Sendmail 8.14.9
Hi Corinna, On Aug 22 07:43, D. Boland wrote: I re-packaged Sendmail with cygport. See: http://cygwin.boland.nl/x86/release/sendmail/ Packaging looks good in theory. Unfortunately we have a problem. On inspection of your binary package I noticed that we have conflicts with exim and ssmtp packages: - /usr/bin/mailq and /usr/bin/newaliases are provided by exim and your sendmail package. - /usr/sbin/sendmail is either a binary (sendmail itself) or it will be installed as symlink by either /usr/bin/exim-config or /usr/sbin/ssmtp-config. If Christian Franke's postfix port will ever fly, we have YA sendmail, mailq, and newaliases symlinks to worry about. Exim is Pierre's package and 32 bit only, ssmtp is my package (I had to take over because the previous maintainer disappeared) and exists for both architectures. What we'll have to do to fix this problem is to convert all three packages to use alternatives. The alternatives package exists and is already used by a couple of other packages which would otherwise conflict, so there's precendent. And on Fedora, the various mail packages all use alternatives, too, to install their packages in parallel and conflict-free. And no, I'm not overly familiar with alternatives myself, but I will convert my ssmtp package ASAP. Pierre, any chance you could convert exim pretty quickly as well? Otherwise sendmail is hanging in a limbo... You already guessed it. I don't like it. It's getting very messy this way. Amateur hour is near... I'm sorry for the following rant, but I am inclined to defend Sendmail's honour in the name of its creator, the great Eric Allman. I am pissed off at those programs. Let them use their own names! I have to rename my library, but these 'postfix', 'exim' and 'ssmtp' apparitions shamelessly use Sendmail's program names. As Yaakov puts it in my 'libsuexec' thread: Deliberately inciting confusion isn't a good thing. I always wondered why Exim looks so damn similar to Sendmail. So, let's face it: there is only one Real mail exchanger, and its name is Sendmail. These other programs are cheap rip-offs, created by professional spammers te get past its rigorous rules. I've been studying these clones for quite some years via their MIME headers and they can't do the job alone. Show me a version of Exim running on a server somewhere and I'll show you a version of Sendmail in the same domain which does the actual mail exchanging to the outside world. Mail exchanging is not about putting text on the wire. Any text editor can do that. Real mail exchanging is about spam control through MIME headers and the clones really suck at them. Ok, that being out of the way: I am running out of time, and I still have to do the 64bit version. I've read the 'alternatives' documentation and it looks nasty: link groups, master link, slave link, automatic mode, manual mode... Why not let the user choose one program? Putting both Exim and Sendmail on one box is confusing, to say the least. Sendmail is very tough to understand. You don't want another (very similar looking) mail exchanger to add to the confusion. You really put me on the spot here. Will Sendmail suffer? Will it dream? Cincerely, Daniel
Re: [ITP] libsuexec 1.0
Hi Achim, Achim Gratz wrote: D. Boland writes: I still think you should name it differently. Marco has already mixed it up with Apache suexec⦠The idea kind of was to mix it up, so people will know what it does. Apache suexec is concerned with running new processes as a different user, so both the su and the exec part of the name make sense. Your library is concerned with inserting itself into certain calls to swap uid/gid so programs expecting a fixed mapping of some uid/gid to certain capabilities (roughly associated with the concept of a root user) work without the actual source getting patched on a system where those assumptions aren't true. Looks like different thing to me and giving it a different name surely wouldn't hurt. Ok, got the point. But the su part must stay. Because it's the super-user who needs to be simulated. Soo: susim? simsu? fakesu? Suggestions are welcome... D.
Re: [ITP] libsuexec 1.0
Achim Gratz wrote: D. Boland writes: fakesu? I'd go with fakeid personally. But that's a joke that's probably too hard to get⦠so fakesu is also good. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra So it's settled. I will roll with fakesu. I'll re-post. Anyone know why my upload-key activation is taking so long? Or were y'all waiting for me to change my mind... Daniel
cygport: keepdir directive doesn't work
Hi group, When creating a package, I need some empty directories in the release, but cygport install removes them. I tried both 'keepdir' and 'keepdirs', but to no avail. I'm using version 0.16.0-1. Cheers, Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: HEADSUP: OpenSSH 6.7 drops tcpwrapper support
Hi Corinna, Corinna Vinschen wrote: Hi folks, Just a HEADSUP to all of you actively using the tcp_wrappers/libwrap functionality in sshd: Starting with the next OpenSSH version 6.7, which will be released soon, upstream removed support for tcp_wrappers/libwrap from the sources. While that's bad from a compatibility point of view, the upstream developers are adamant about this change for security reasons. Can you point me to any documentation about this? Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygport: keepdir directive doesn't work
Hi Achim,
Achim Gratz wrote:
D. Boland writes:
When creating a package, I need some empty directories in the release, but
cygport
install removes them.
I tried both 'keepdir' and 'keepdirs', but to no avail. I'm using version
0.16.0-1.
These need to specified with the path as installed, not as built.
Thanks, I was using relative paths and also tried the ${D} variable, but it's
absolute paths, like '/var/spool'
D.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ITA] Procmail 3.22
Hi Corinna, Corinna Vinschen wrote: Some users are running fetchmail/procmail/mutt without the detour over using an MTA, for instance: $ grep mda ~/.fetchmailrc mda /usr/bin/procmail -d %T Will this still work as expected, even if the user is member of the admin group? Keep in mind that Windows XP/2003 are not providing UAC at all, and even on UAC-providing systems, it might be switched off. I implemented the ipv6 patch. Here's the new release candidate: http://cygwin.boland.nl/x86/release/procmail/ I tested fetchmail, the way you indicate. It works fine, both for admin and non-admin users. Procmail always acts as the mailbox (calling) user. That's why Sendmail changes user two times, instead of one: root - smmsp - corinna By the way: this combination of fetchmail and procmail is nice. What program do you use to read the downloaded e-mail? By the way 2: to be shure: does your procmail put the e-mails in /var/spool/mail? And can you paste me the output of ls -l /var/spool/mail? Daniel
SSH key for upload access
Name: Daniel Boland Package: procmail BEGIN SSH2 PUBLIC KEY Comment: 2048-bit RSA, converted by daniel@dimension from OpenSSH B3NzaC1yc2EDAQABAAABAQDQCiyKsZZIrVQ937mkmSTea59jV/tb4rfAri22AZ OhpmKHPclPSQ1NUbV6lD1GxXZWzg/7oDV9KvQYb6jUVJkhSqeQq2uUUO0l7qVFhJrtJT3y iOo0bBM95dWWZVtjjIajZ+6Mb7OLXuAAE/LgW8DF4xVNC1QuRIfecK4q1UI+KDiB0jFuB0 HUJVHnOd/eNQmPO9mMfaNfW3d2IkboqpgIBSz+KsjIJsVHxwQEYcpP6dcJRmmwX5cwT+ry QGVnR39L53W5vPdtNQcOoL+44nXeZkltTmmIwAhs8cdtegFV9v5SygnSfUxEGK83xgagAc 6ygFSh6eFgiQI8apM2kCSn END SSH2 PUBLIC KEY
Re: [ITP] libsuexec 1.0
Hi Corinna, Corinna Vinschen wrote: * I put the license under the 'Open Source Definition' license and added a reference to the complete license text. Uh, that's a bit of a problem. The text under http://opensource.org/docs/osd/ does *not* constitute a license by itself. It just describes what a license has to define to become an OSS license. For blessed OSS licenses, see http://opensource.org/licenses/. For a simple lib like this I'd suggest http://opensource.org/licenses/BSD-2-Clause or http://opensource.org/licenses/LGPL-3.0 http://cygwin.boland.nl/x86/release/libsuexec/ A LICENSE file parallel to usr/share/doc/README containing the license text would be nice. I changed the license to LGPL 2.1. It has the nice short text to paste in my sources :-). I also updated the procmail package. It has Cygwin version 14 now. Finally, I sent my public key, so now I will wait for activation. Thanks, Daniel
Re: [ITP] libsuexec 1.0
Hi Achim, Achim Gratz wrote: D. Boland writes: Thanks for all the critiques and suggestions regarding this new library. I have made changes accordingly. I still think you should name it differently. Marco has already mixed it up with Apache suexec⦠The idea kind of was to mix it up, so people will know what it does. I noticed that you and other people already declare the user switching technique half dead. It's a brilliant idea, you know. Because of its simplicity. It's even patented. By referring to the Apache executable I give the technique the glory and attention it deserves. So most people are thinking 'Capabilities' nowadays... Sigh. This will only steer admins away from finding out how user switching works and applying it. Instead they will just run entire server processes as admin-users. Sincerely, Daniel
Re: [ITP] libsuexec 1.0
Hi group, Thanks for all the critiques and suggestions regarding this new library. I have made changes accordingly. * The term 'capabilities' has been removed from the hints file, since that is not what the library is about or for. * Also the term 'multi-root' has been removed from the hints file. I think the new description in the hints file now accurately covers what the library does. * Not all functions in the library were declared. They are now. * I added a readme file. * I removed the dynamic library. This library will be static only. * I put the license under the 'Open Source Definition' license and added a reference to the complete license text. http://cygwin.boland.nl/x86/release/libsuexec/ GTS's are welcome. Daniel
[ITP] libsuexec 1.0
Hi group, This is not an existing package, but a spin-off project from porting Sendmail and Procmail to Cygwin. These programs, as you may or may not know, rely heavily on the setuid mechanism (impersonating as another user). More formally, this is called 'running as an unprivileged user' in Linux and 'privilege separation' in OpenBSD. In Cygwin, this mechanism is already implemented in the ssh daemon. Sendmail takes this idea to the extreme. It starts up as the root user and waits for connections. On connection, it starts the 'queue runner' program as an unprivileged user called 'smmsp', which handles the conversation with the remote e-mail client. If the incoming e-mail has to be delivered locally (stored on disk), the queue runner starts the procmail program, which in turn switches to the actual user the e-mail is meant for and stores it in the user's inbox. So, for instance sending an e-mail to myself involves switching through three users: root - smmsp - daniel The problem --- Up to WinXP and Win2002, porting source code for Cygwin which performed this switching of users, wasn't a big problem. In Windows, it is the 'SYSTEM' user which starts up most services, thus in effect acting as the Unix 'root' user. The difference is that SYSTEM has uid '18', while root has uid '0' in Unix. So, if porting from Unix to Cygwin one could just look for all occurances of uid '0' and replace them with '18'. Actually, this technique has been used to create the current Cygwin port of the Procmail program. As of Win7 and Win2003 this will no longer work. For security reasons, the privilege needed to impersonate another user (called 'SeCreateTokenPrivilege') has been removed from the SYSTEM user. Services (daemons) who need impersonation now have to be started by non-SYSTEM users, which have been put in the 'Administrators' group and granted the SeCreateTokenPrivilege. This works for most suid software, like the Apache webserver, but not for Sendmail and Procmail. Both programs *enforce* what is called the Capabilities model. This means that both programs actually check if they are ran by root and if not, refuse to deliver e-mail. So, simply replacing '0' with '18' in the source code has no effect. The solution The solution to this problem turns out to be very simple and elegant: *tell* Sendmail and Procmail who is the root user by overriding functions which involve getting or setting user id's. For instance: make the getuid() function return '0' when the actual user id is '18' and make the setuid() function change to uid '18' if the requested uid is '0'. Take this idea one step further and Sendmail and Procmail become 'multi-root aware'. I created this library to do exacly that. On startup it assumes the root user id is '18' (SYSTEM) and the root group id is '544' (Administrators). It overrides the original getuid(), getgid(), etc. functions to return '0' if the actual uid/gid are '18' or '544'. The library makes its program 'multi-root aware' by checking if the non-SYSTEM user is a member of the 'Administrators' group and if so, simply replacing *its* uid and gid to be '0'. This totally satisfies Sendmail and Procmail. More importantly: I didn't have to change a single line in their source code (which would have been an awful lot), because the library is doing the swapping of uids/gids in the background. To use this library, put '#include suexec.h' and '-lsuexec' at a strategic location in your source code and Makefile. To make your program 'multi-root' aware and even do suid and/or sugid, place a call to 'suexec(argv[0])' in your 'main' function and set the suid and/or sgid bits on the resulting binary. http://cygwin.boland.nl/x86/release/libsuexec/ All GTG's are welcome... Cincerely, Daniel
Re: [ITA] Procmail 3.22
Hi Corinna, Corinna Vinschen wrote: [...] I forgot the prep stage. I re-made the binary package and its source package with cygport (nice program btw): http://cygwin.boland.nl/x86/release/procmail/ I had to cheat a little (see 'src_compile' in .cygport file) because the source has to be compiled with a library, called 'suexec'. In there are the function overrides to make 'multi-root' and suid/guid possible. To make the Procmail and Sendmail packages completely 'clean' I would like to ITP this library as a new package. Definitely. If a library is a prerequisite for the package, you should ITP it before we upload any dependent package. If the build is ok, it's more or less preapproved if it's GTG. I'm just a bit puzzled. Isn't suexec an application, and isn't it part of apache, usually? Also, since when is procmail dependent on suexec? It isn't on Fedora and they certainly use almost all of procmail's features... You are right, suexec is an Apache program. I created this library myself and borrowed the name from Apache. It solves the impersonation problem by making procmail 'multi-root' aware. I wrote a small article on it in my ITP of libsuexec. Oh, and while I was looking I found this: The original procmail 3.22 sources are not IPv6-enabled. Would you mind to add the Fedora patch(*) for that, too? I will. Daniel
[ITP] libsuexec 1.0
Hi group, This is not an existing package, but a spin-off project from porting Sendmail and Procmail to Cygwin. These programs, as you may or may not know, rely heavily on the setuid mechanism (impersonating as another user). More formally, this is called 'running as an unprivileged user' in Linux and 'privilege separation' in OpenBSD. In Cygwin, this mechanism is already implemented in the ssh daemon. Sendmail takes this idea to the extreme. It starts up as the root user and waits for connections. On connection, it starts the 'queue runner' program as an unprivileged user called 'smmsp', which handles the conversation with the remote e-mail client. If the incoming e-mail has to be delivered locally (stored on disk), the queue runner starts the procmail program, which in turn switches to the actual user the e-mail is meant for and stores it in the user's inbox. So, for instance sending an e-mail to myself involves switching through three users: root - smmsp - daniel The problem --- Up to WinXP and Win2002, porting source code for Cygwin which performed this switching of users, wasn't a big problem. In Windows, it is the 'SYSTEM' user which starts up most services, thus in effect acting as the Unix 'root' user. The difference is that SYSTEM has uid '18', while root has uid '0' in Unix. So, if porting from Unix to Cygwin one could just look for all occurances of uid '0' and replace them with '18'. Actually, this technique has been used to create the current Cygwin port of the Procmail program. As of Win7 and Win2003 this will no longer work. For security reasons, the privilege needed to impersonate another user (called 'SeCreateTokenPrivilege') has been removed from the SYSTEM user. Services (daemons) who need impersonation now have to be started by non-SYSTEM users, which have been put in the 'Administrators' group and granted the SeCreateTokenPrivilege. This works for most suid software, like the Apache webserver, but not for Sendmail and Procmail. Both programs *enforce* what is called the Capabilities model. This means that both programs actually check if they are ran by root and if not, refuse to deliver e-mail. So, simply replacing '0' with '18' in the source code has no effect. The solution The solution to this problem turns out to be very simple and elegant: *tell* Sendmail and Procmail who is the root user by overriding functions which involve getting or setting user id's. For instance: make the getuid() function return '0' when the actual user id is '18' and make the setuid() function change to uid '18' if the requested uid is '0'. Take this idea one step further and Sendmail and Procmail become 'multi-root aware'. I created this library to do exacly that. On startup it assumes the root user id is '18' (SYSTEM) and the root group id is '544' (Administrators). It overrides the original getuid(), getgid(), etc. functions to return '0' if the actual uid/gid are '18' or '544'. The library makes its program 'multi-root aware' by checking if the non-SYSTEM user is a member of the 'Administrators' group and if so, simply replacing *its* uid and gid to be '0'. This totally satisfies Sendmail and Procmail. More importantly: I didn't have to change a single line in their source code (which would have been an awful lot), because the library is doing the swapping of uids/gids in the background. To use this library, put '#include suexec.h' and '-lsuexec' at a strategic location in your source code and Makefile. To make your program 'multi-root' aware and even do suid and/or sugid, place a call to 'suexec(argv[0])' in your 'main' function and set the suid and/or sgid bits on the resulting binary. http://cygwin.boland.nl/x86/release/libsuexec/ All GTG's are welcome... Cincerely, Daniel
Re: [ITP] libsuexec 1.0
Hi Achim, Achim Gratz wrote: In Windows, it is the 'SYSTEM' user which starts up most services, thus in effect acting as the Unix 'root' user. The difference is that SYSTEM has uid '18', while root has uid '0' in Unix. No, there are much larger differences between a capability based system and this. With capabilities, whatever you call a root user might not even exist and if it does, it might not have the capabilities you're associating with root on a classical UNIX system. I am fully aware that I am touching a very sensitive subject here. I shouldn't have mentioned the word 'Capabilities'. But I sense something deeper here. Correct me if I'm wrong, but do you really love Unix? I think not. There is no such thing as a classical Unix system. There is only Unix. Prove to me that you really love Unix. So, if porting from Unix to Cygwin one could just look for all occurances of uid '0' and replace them with '18'. Actually, this technique has been used to create the current Cygwin port of the Procmail program. That's a long winded way of saying that these programs are not capability-aware. I will remove the term from my hints file. As of Win7 and Win2003 this will no longer work. For security reasons, the privilege needed to impersonate another user (called 'SeCreateTokenPrivilege') has been removed from the SYSTEM user. Services (daemons) who need impersonation now have to be started by non-SYSTEM users, which have been put in the 'Administrators' group and granted the SeCreateTokenPrivilege. This works for most suid software, like the Apache webserver, but not for Sendmail and Procmail. Both programs *enforce* what is called the Capabilities model. This means that both programs actually check if they are ran by root and if not, refuse to deliver e-mail. So, simply replacing '0' with '18' in the source code has no effect. No, actually they have no idea what a capability is and use the UID as a proxy for certain capabilities. Which is wrong when actual capabilities come into play. The solution The solution to this problem turns out to be very simple and elegant: *tell* Sendmail and Procmail who is the root user by overriding functions which involve getting or setting user id's. For instance: make the getuid() function return '0' when the actual user id is '18' and make the setuid() function change to uid '18' if the requested uid is '0'. Take this idea one step further and Sendmail and Procmail become 'multi-root aware'. Except that SYSTEM is not root. Depending on what capabilities those programs actually expect from root it may or may not have them. And I wish you'd stop talking about multi-root, there is no such thing and never will be, since there is no root at all. No root at all?? You're stuck on words. Root is a type of super-user and SYSTEM is also. Don't be tight. Prove to me that you really love Unix. I created this library to do exacly that. On startup it assumes the root user id is '18' (SYSTEM) and the root group id is '544' (Administrators). It overrides the original getuid(), getgid(), etc. functions to return '0' if the actual uid/gid are '18' or '544'. The library makes its program 'multi-root aware' by checking if the non-SYSTEM user is a member of the 'Administrators' group and if so, simply replacing *its* uid and gid to be '0'. This totally satisfies Sendmail and Procmail. 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. Nope. They will not use administrative rights. The opposite is true. You, as a member of the Admin group, need those extra rights so procmail can deliver as an *unprivileged* user. If procmail or sendmail 'see' that they have been started by a non-super-user, they will refuse to switch to the unprivileged user and deliver e-mail. More importantly: I didn't have to change a single line in their source code (which would have been an awful lot), because the library is doing the swapping of uids/gids in the background. As much as I had to patch it up in a time long ago I'd rather have sendmail die as it's way past its best-before-use date, but then I wasn't planning on using it anyway. To use this library, put '#include suexec.h' and '-lsuexec' at a strategic location in your source code and Makefile. To make your program 'multi-root' aware and even do suid and/or sugid, place a call to 'suexec(argv[0])' in your 'main' function and set the suid and/or sgid bits on the resulting binary. http://cygwin.boland.nl/x86/release/libsuexec/ This library doesn't do anything su-like or exec, so I think it is misnamed. All GTG's are welcome... At the very least you're missing a proper license. But
Re: [ITA] Procmail 3.22
Hi Corinna, Corinna Vinschen wrote: procmail works from sendmail in a multi-user scenario on Fedora without this tool. Why does this solution not work for Cygwin? Disregard this question. The expression multi-root totally puzzeled me. Let's follow up with the libsuexec ITP. Kuhl!! I will remove the reference to 'Capabilities' and correct the other stuff you mentioned in the ITP thread of libsuexec. So 'multi-root' is not comprehensible. Can you dig into your creative self and come up with someting I can use in my readme? Cincerely, Daniel
Re: [ITA] Procmail 3.22
Corinna Vinschen wrote: Hi Daniel, On Aug 14 21:05, D. Boland wrote: Hi group, I intend to adopt the Cygwin package for the procmail program, version 3.22. The original maintainer, Jason Tishler has given me permission to do so. The difference with previous Cygwin releases is that the procmail program has been made 'multiple root' aware and suid/guid, provided that it is started by a privileged user. This was needed to make procmail work together with Sendmail, which I intend to package (see next post). sdesc: Mail processing program ldesc: The procmail program is used by Red Hat Linux for all local mail delivery. In addition to just delivering mail, procmail can be used for automatic filtering, presorting, and other mail handling jobs. Procmail is also the basis for the SmartList mailing list processor. category: Mail requires: bash cygwin version: 3.22-11 version is not a valid tag in setup.hint. Also, the 64 bit release is already at version 3.22-13, so your version shoud bump to a higher release number. Got it. I'm working on the 32-bit version first. How do I cross-compile? http://cygwin.boland.nl/x86/release/procmail/ New packages are supposed to use cygport packaging. Please see my former 64 bit procmail package procmail-3.22-13-src.tar.bz2, it's already using cygport. Note: after making from source, use 'make install-suid' and make install.man to install. These steps should be part of the src_install() function in the cygport file. I was testing your 64-bit release, but I got errors: $ cygport procmail.cygport compile Compiling procmail-3.22-13.i686 /usr/share/cygport/lib/syntax.cygpart: regel 136: /home/daniel/Downloads/procmail-3.22-13/procmail-3.22-13.i686/log/procmail-3.22-13-compile.log: No such file or directory Daniel
Re: [ITA] Procmail 3.22
Hi Corinna, Corinna Vinschen wrote: Works for me. Did you forget the `prep' stage? $ cygport procmail.cygport prep Preparing procmail-3.22-13.x86_64 *** Info: gnupg must be installed in order to check signatures. Unpacking source procmail-3.22.tar.gz *** Info: applying patch procmail.patch: patching file Makefile patching file Makefile.1 patching file config.h patching file src/Makefile.0 patching file src/autoconf patching file src/cstdio.c patching file src/foldinfo.c patching file src/includes.h patching file src/formisc.h Preparing working source directory $ cygport procmail.cygport compile [...] I forgot the prep stage. I re-made the binary package and its source package with cygport (nice program btw): http://cygwin.boland.nl/x86/release/procmail/ I had to cheat a little (see 'src_compile' in .cygport file) because the source has to be compiled with a library, called 'suexec'. In there are the function overrides to make 'multi-root' and suid/guid possible. To make the Procmail and Sendmail packages completely 'clean' I would like to ITP this library as a new package. Cincerely, Daniel
[ITA] Procmail 3.22
Hi group, I intend to adopt the Cygwin package for the procmail program, version 3.22. The original maintainer, Jason Tishler has given me permission to do so. The difference with previous Cygwin releases is that the procmail program has been made 'multiple root' aware and suid/guid, provided that it is started by a privileged user. This was needed to make procmail work together with Sendmail, which I intend to package (see next post). sdesc: Mail processing program ldesc: The procmail program is used by Red Hat Linux for all local mail delivery. In addition to just delivering mail, procmail can be used for automatic filtering, presorting, and other mail handling jobs. Procmail is also the basis for the SmartList mailing list processor. category: Mail requires: bash cygwin version: 3.22-11 http://cygwin.boland.nl/x86/release/procmail/ Note: after making from source, use 'make install-suid' and make install.man to install. All GTG's are welcome. Cheers, Daniel
[ITP] Sendmail 8.14.9
Hi group, I intend to package the Cygwin version of Sendmail, version 8.14.9. sdesc: The Mail Transfer Agent ldesc: General purpose internetwork email routing facility that supports many kinds of mail-transfer and delivery methods, including SMTP, SMTPS (STARTTLS), SMTPA (AUTH) used for email transport over the internet. category: Mail requires: m4 procmail tcp_wrappers cyrus-sasl cygrunsrv cygwin version: 18.14.9-0 http://cygwin.boland.nl/x86/release/sendmail/ All GTG's are welcome. Cheers, Daniel
Posting ITA/ITP
Hi group, I'm trying to post to gmane.os.cygwin.applications, but I get an NNTP error: 'gmane.os.cygwin.applications is unidirectional' Should I post to another newsgroup? Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Impending ITP of Sendmail
Jason Tishler wrote: Daniel, On Mon, Aug 11, 2014 at 12:46:54PM +0200, Corinna Vinschen wrote: On Aug 9 22:41, D. Boland wrote: [snip] To accomplished this, procmail would have to be modified slightly. From the Cygwin website, I can see that procmail is maintained bij Jason Tishler. I need these modifications for Sendmail to work. I remember Corinna mentioning that the package is old and needs to be updated. Maybe it is orphaned? In that case I'd be happy to adopt it. Jason, ping? I already built procmail for x86_64 becasue Jason hadn't much time way back when. Dependent on his current workload he might be glad to hand over procmail. Yes, you are welcome to adopt procmail. Thanks, Jason Thank you, Jason. Now I can unleash the ancient, though awesome power of Sendmail onto the Cygwin world. ;-) Cheers, Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Impending ITP of Sendmail
Hi group, I have the Sendmail port ready. I will anounce my intent to package it soon. There is one thing, though. Sendmail relies heavily on the procmail program. The problem is that the procmail package as it is now, is not multiple root aware. It also is not able to do suid at the moment. To accomplished this, procmail would have to be modified slightly. From the Cygwin website, I can see that procmail is maintained bij Jason Tishler. I need these modifications for Sendmail to work. I remember Corinna mentioning that the package is old and needs to be updated. Maybe it is orphaned? In that case I'd be happy to adopt it. Cincerely, Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: syslog function: Bad file descriptor
Hi Corinna, Corinna Vinschen wrote: On Aug 5 22:35, D. Boland wrote: Corinna Vinschen wrote: Can you produce another strace for the overwriting case (non-R/O aliases) for comparison? Also, can you do the same strace with no syslogd running? It might be necessary to create a few test versions of Cygwin with more debug output, but let's please see these straces first. I attached all three of them in a zipped file. Thanks. I got it now. AFAICS it's a bug in sendmail. Take a look into your newaliases.strace.txt file. Start at line 260 (stripping off timestamp, thread and process info): 260: normalize_posix_path: src /dev/log Here the syslog() function tries to open a connection to a syslogd listening on /dev/log. 282: cygwin_socket: 3 = socket(1, 2 (flags 0x0), 0) Socket created, file descriptor is 3. 296: connect_syslogd: found /dev/log, fd = 3, type = DGRAM Yes, there's a listener on /dev/log. Now Cygwin stores the info that fd 3 is the connection to the syslog daemon. 332: close: close(3) And at line 332, a file descriptor close orgy starts. sendmail closes all descriptors from 3 to 255. This obviously closes fd 3, but how's Cygwin's syslog() function to know? 2263: open: 3 = open(/etc/mail/aliases, 0x8000) Uh oh! Now fd 3 is reused for the aliases file. Things certainly go downhill. 2651: writev: -1 = writev(3, 0x2287F0, 2), errno 9 This is syslog trying to write the log to the descriptor it knows is connected to /dev/log. Fortunately the aliases file is R/O at this point, but it's pretty much working as designed. Syslog() doesn't know the application broke its connection to the syslog daemon. It dutyfully writes to the syslog descriptor it knows about. As for using a file descriptor inside of syslog, that's perfectly valid behaviour, see http://pubs.opengroup.org/onlinepubs/9699919799/functions/closelog.html: The openlog() and syslog() functions may allocate a file descriptor. Without looking into the sources, I'd assume there's a closelog() call missing prior to the descriptor close orgy. This closelog() call should fix the problem. It is exactly as you say. I found the close() orgy and put a closelog() prior to it. Now it works perfectly without corrupting the aliases file (writable to sendmail). I'm asking myself if this closing of 253 file descriptors is a sensible thing to do. What would Sendmail be trying to accomplish there? It comments Be shure we have enough file descriptors. And: in 4.4BSD, the table ([of fd's]) can be huge; impose a reasonable limit. Bizarre. Could it be that incoming e-mail is such a volatile process that previous opened file descriptors are not closed quick enough? This feels like a crude hack. Can you give your opinion on this? Thanks for the quick response the time you put into this. Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
syslog function: Bad file descriptor
Hi group, I'm still working on getting Sendmail working for Cygwin. I'm almost done, the devil is in the details... I'm getting the 'Bad file descriptor' system error after building the mail aliases database. The building itself is done successful, but logging the event to the system log fails with this message. Somehow the two are connected. The alias database (aliases.db) is built from a plain text file (aliases). If I leave the aliases file writable to the sendmail user, I find that the error message strings have been put right into the alias text-file: $ cat /etc/mail/aliases 21sendmail: PID 1848: alias database /etc/mail/aliases rebuilt by smmspsenet: root news: root webmaster: root www: root ftp: root abuse: root noc: root security: root root: SYSTEM 22sendmail: PID 1848: /etc/mail/aliases: 9 aliases, longest 6 bytes, 82 bytes total If I make the 'aliases' file read-only, then the file is not corrupted, but the error occurs. Cheers, Daniel Here's the strace output. I copied the lines between two subsequent calls to 'syslog': strace /usr/sbin/sendmail -bi syslog: Bad file descriptor 145 16951672 [main] sendmail 1104 write: 28 = write(1, 0x2007EFB0, 28) 131 16951803 [main] sendmail 1104 cygpsid::debug_print: get_sids_info: owner SID = S-1-5-21-1659004503-813497703-854245398-1028 56 16951859 [main] sendmail 1104 cygpsid::debug_print: get_sids_info: group SID = S-1-5-21-1659004503-813497703-854245398-1029 55 16951914 [main] sendmail 1104 get_info_from_sd: ACL 0x120, uid 1028, gid 1029 74 16951988 [main] sendmail 1104 fhandler_base::fstat_helper: 0 = fstat (\??\C:\cygwin\etc\mail\aliases, 0x228A10) st_size=183, st_mode=0x8120, st_ino=1970324837070571st_atim=53E0FB5C.120ACC80 st_ctim=53E0FB59.1859C3C0 st_mtim=53E0FB4E.205C2E00 st_birthtim=53DE6678.2B7D5340 68 16952056 [main] sendmail 1104 fstat64: 0 = fstat(3, 0x228A10) 76 16952132 [main] sendmail 1104 read: read(3, 0x2008EFB8, 65536) blocking 73 16952205 [main] sendmail 1104 fhandler_base::read: returning 183, binary mode 50 16952255 [main] sendmail 1104 read: 183 = read(3, 0x2008EFB8, 65536) 333 16952588 [main] sendmail 1104 fhandler_disk_file::pread: 16384 = pread(0x2004D9D4, 16384, 32768) 63 16952651 [main] sendmail 1104 pread: 16384 = pread(6, 0x2004D9D4, 16384, 32768) 345 16952996 [main] sendmail 1104 fhandler_disk_file::pread: 16384 = pread(0x2009EFFC, 16384, 16384) 58 16953054 [main] sendmail 1104 pread: 16384 = pread(6, 0x2009EFFC, 16384, 16384) 2580 16955634 [main] sendmail 1104 read: read(3, 0x2008EFB8, 65536) blocking 69 16955703 [main] sendmail 1104 fhandler_base::read: returning 0, binary mode 48 16955751 [main] sendmail 1104 read: 0 = read(3, 0x2008EFB8, 65536) /etc/mail/aliases: 13 aliases, longest 10 bytes, 144 bytes total 196 16955947 [main] sendmail 1104 write: 65 = write(1, 0x2007EFB0, 65) 53 16956000 [main] sendmail 1104 vsyslog: 0x6 %s 243 16956243 [main] sendmail 1104 open: open(/dev/null, 0x10601) 51 16956294 [main] sendmail 1104 normalize_posix_path: src /dev/null 71 16956365 [main] sendmail 1104 normalize_posix_path: /dev/null = normalize_posix_path (/dev/null) 50 16956415 [main] sendmail 1104 mount_info::conv_to_win32_path: conv_to_win32_path (/dev/null) 48 16956463 [main] sendmail 1104 mount_info::conv_to_win32_path: src_path /dev/null, dst \Device\Null, flags 0x2, rc 0 64 16956527 [main] sendmail 1104 build_fh_pc: fh 0x612AEC2C, dev 00010003 51 16956578 [main] sendmail 1104 fhandler_base::open: (\Device\Null, 0x18601) 61 16956639 [main] sendmail 1104 fhandler_base::set_flags: flags 0x18601, supplied_bin 0x1 51 16956690 [main] sendmail 1104 fhandler_base::set_flags: O_TEXT/O_BINARY set in flags 0x1 50 16956740 [main] sendmail 1104 fhandler_base::set_flags: filemode set to binary 48 16956788 [main] sendmail 1104 fhandler_base::open: 0x0 = NtCreateFile (0x60C, 0x40120080, \Device\Null, io, NULL, 0x0, 0x7, 0x3, 0x4020, NULL, 0) 52 16956840 [main] sendmail 1104 fhandler_base::open: 1 = fhandler_base::open(\Device\Null, 0x18601) 51 16956891 [main] sendmail 1104 open: 7 = open(/dev/null, 0x18601) 190 16957081 [main] sendmail 1104 _cygwin_istext_for_stdio: fd 7: opened as binary 1045 16958126 [main] sendmail 1104 write: write(7, 0x227B50, 10) 49 16958175 [main] sendmail 1104 write: 10 = write(7, 0x227B50, 10) 169 16958344 [main] sendmail 1104 getpid: 1104 = getpid() 555 16958899 [main] sendmail 1104 write: write(7, 0x227B50, 10) 47 16958946 [main] sendmail 1104 write: 10 = write(7, 0x227B50, 10) 688 16959634 [main] sendmail 1104 write: write(7, 0x227B70, 64) 49 16959683 [main] sendmail 1104 write: 64 = write(7, 0x227B70, 64) 256 16959939 [main] sendmail 1104 close: close(7) 440 16960379 [main] sendmail 1104 fhandler_base::close: closing '/dev/null' handle 0x60C 36 16960415 [main] sendmail 1104 close: 0 = close(7) 616 16961031 [main] sendmail 1104 getpid: 1104 = getpid() 51 16961082 [main]
Re: syslog function: Bad file descriptor
Larry Hall (Cygwin) wrote: On 08/05/2014 12:28 PM, D. Boland wrote: Hi group, I'm still working on getting Sendmail working for Cygwin. I'm almost done, the devil is in the details... I'm getting the 'Bad file descriptor' system error after building the mail aliases database. The building itself is done successful, but logging the event to the system log fails with this message. Did you mention whether you've installed and configured some syslog service? I have syslogd running from the 'inetutils-server' package. D. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: syslog function: Bad file descriptor
Corinna Vinschen wrote: Can you produce another strace for the overwriting case (non-R/O aliases) for comparison? Also, can you do the same strace with no syslogd running? It might be necessary to create a few test versions of Cygwin with more debug output, but let's please see these straces first. I attached all three of them in a zipped file. By the way: my previous strace outputs where from an older version of cygwin1.dll. I put a recent one in and did the attached traces: CYGWIN_NT-5.1 dimension 1.7.31s(0.272/5/3) 20140716 11:15:29 i686 Cygwin Daniel sendmail-test.tar.gz Description: GNU Zip compressed data -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Simplify AD integration?
Andrey Repin wrote: Greetings, D. Boland! I am not only a man of legacy, but also a very opinionated one. So give me some slack when I say: the whole thing is insane. This would mean that from now on, I have to use constructs like ~+daniel ~+SYSTEM in a Linux shell?? Bizarre. No, you don't have. Default domain users are unprefixed, and the chance you would use internal accounts for something like shell access is exactly zero. For the god's sake, read the thread before posting into it. Everything has been discussed no more than two days ago. Yes, yes, I know. I wanted to react from the heart, without the intellectual baggage of knowing the technical intricacies behind the problem. D. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: The eternal uid issue
Corinna Vinschen wrote: On Jul 29 15:36, D. Boland wrote: Corinna Vinschen wrote: The permissions of the home folder are set to 01777 by default (S_ISVTX bit!). Since we can't rely on central administration for Cygwin, this allows a user to create her own homedir automatically at first start of a Cygwin shell. You might consider to disable this full patch check in sendmail for Cygwin. Is there some configuration flag, maybe? If I make the 'Users' group owner of the /home folder and remove the world-writable bit, Sendmail doesn't complain anymore. I found out that everybody who is logged on, will be put in the 'Users' group anyway. Uhm... that works for you, but you can't rely on that for a sendmail package. You'd have to deal with the default 01777 /home as well. Yes, yes, I know. Cygwin shouldn't want to lock their users out of their own system. Sendmail is a real b^ch with security. This project cost me 2 1/2 weeks straight, trying to figure out a way to accomodate its strict impersonation rules on a system which has multiple root users. But I did it. No hacking in the sendmail source code. Anyway, today I tested it succesfully on my Win7 machine (32bit Cygwin), but no complaining from Sendmail, even with a home folder which is group- and world writable. Strange. Cincerely, Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Simplify AD integration?
Corinna Vinschen wrote: So I'd like to ask a few questions to which I'd like to have some brief answers, kind of like a poll, to get a better idea how we should proceed: 1. Shall we remove the leading '+' from the builtin account names or shall we keep it? 2. Shall we stick to '+' as the separator char or choose another one? If so, which one? 3. Shall we keep the `db_prefix' variability or choose one of the prefixing methods and stick to it? If so, which one, auto, primary, or always? I'm a legacy man. So I would say keep the MS symbol and use it like this \daniel, \SYSTEM, etc. Bonus question: 4. Should Cygwin downcase all usernames when generating the Cygwin username, so, if your Windows username is 'Ralph', your Cygwin username will be 'ralph'? When in the Cywin domain, do like Cygwin. So, downcasing. Cheers, Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Simplify AD integration?
Eric Blake wrote: On 07/31/2014 07:26 AM, D. Boland wrote: Corinna Vinschen wrote: So I'd like to ask a few questions to which I'd like to have some brief answers, kind of like a poll, to get a better idea how we should proceed: 1. Shall we remove the leading '+' from the builtin account names or shall we keep it? 2. Shall we stick to '+' as the separator char or choose another one? If so, which one? 3. Shall we keep the `db_prefix' variability or choose one of the prefixing methods and stick to it? If so, which one, auto, primary, or always? I'm a legacy man. So I would say keep the MS symbol and use it like this \daniel, \SYSTEM, etc. But you'd have to write that as '\daniel' or \\daniel in the shell, and you also cripple tilde expansion. That's why we already ruled out :, \, and / as non-starters, as mentioned elsewhere in this thread. I am not only a man of legacy, but also a very opinionated one. So give me some slack when I say: the whole thing is insane. This would mean that from now on, I have to use constructs like ~+daniel ~+SYSTEM in a Linux shell?? Bizarre. On the other hand, for the sake of progress, but keeping legacy there would be only one acceptable solution: use the tilde symbol. A user could then be referred to as: ~daniel. This already works in the shell and it is also done by the Apache webserver. If I want to go my personal web space I can type: http://localhost/~daniel/ Come to think of it: IMAP does this too! I have been coding for an IMAP project, and if you want to fetch somebody's mail, you'd have to use ~corinna to display the contents of her INBOX. Cheers, Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: The eternal uid issue
Corinna Vinschen wrote: The permissions of the home folder are set to 01777 by default (S_ISVTX bit!). Since we can't rely on central administration for Cygwin, this allows a user to create her own homedir automatically at first start of a Cygwin shell. You might consider to disable this full patch check in sendmail for Cygwin. Is there some configuration flag, maybe? If I make the 'Users' group owner of the /home folder and remove the world-writable bit, Sendmail doesn't complain anymore. I found out that everybody who is logged on, will be put in the 'Users' group anyway. Regards, Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: The eternal uid issue
Hi Corinna, Corinna Vinschen wrote: Still, are you using setuid method 1 or another method? Is your home dir the default /home/$USER as created from inside the Cygwin environment? Any chance your home dir has an unusual ACL? Did you set up sshd as service? If not, you might consider to do that so you can check what happens when switching to the smmsp account. Run ssh-host-config as admin, install the service. Create an authorized_keys file for the smmsp user (run ssh-user-config under smmsp for instance), then start the service. Now login to the smmsp user account using public key authentication, admin-enabled vs. non-admin as above(*), and observe the permissions ls or stat show you for your home dir. Are they really different? If so, let's see the strace output again. Argh! I checked the /home folder and it was indeed group and world writable. After setting it to 0755 sendmail had no issues anymore. Sendmail checks permissions on the entire path. I cannot remember setting it 0777, so something else must have set it. Regarding the suid method: You mean method 1, 2 and 3 in the Using Windows security in Cygwin article, right? I have nothing special set up, so it uses the default method 1. As to the sshd, I had it set up as a service already. Thanks again for your help. I will announce the Sendmail release soon. Cincerely, Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: The deprecated uid issue: use caps
Hi Linda, Linda Walsh wrote: D. Boland wrote: Linda Walsh wrote: D. Boland wrote: 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'. Isn't it about time to make this our First Directive also? I thought sendmail used capabilities? Isn't it about time none of them used a fixed 'uid', but used capabilities? I thought hard coding a Uid was going out with the dodo bird? You didn't get the point. We create a kernel on which Linux software runs. We don't dictate how software should be written. You are missing the point. MS privilege model is the MS version of the linux capability model. MS didn't get it wrong, linux has been slow to adopt, but MS had linux capabilities 10 years before linux did. Several other people have tried to explain that the way to go is to use the minimum priviledge model. For example, almost ALL user have the unreadable directory traversal priv/capability. To enforce it cost alot in execution time on Windows (as it would under cygwin). Another priviledge is to impersonate another user; sendmail would likely need such a privilege. Another is to ignore file-permissions. It would be questionable whether or not sendmail needed that. Sendmail was using capabilities back in 2000 when I brought a basic non-reciprocal action bug in the capability code to the attention of Ted Tso, he told me and others that I didn't know what I was talking about and they were following POSIX and my find was irrelevant under POSIX. About 10 days later there was a day-zero exploit involving the bug in the defective code using sendmail's capability usage as the vector. The result was kernel caps being disabled for the next few years until the cap-code could be reviewed by more eyes and knew what to look for. So I'm pretty sure sendmail has had code to extensively run solely off of capabilities and has had it for some time. I'd be surprised if it was removed. Linux software that uses the capability model is likely to not have these problems. But saying that any random linux software with security bugs from the past should work on cygwin, seems like a ridiculous stance to take. You can set capabilities on files processes and network sockets. Linux file systems with extended attributes or alternate data forks (2 names for the same thing), can and do support SETCAP on linux files that works just like SETUID, but for capabilities. MS only supports the capability model and uses it to implement their Admin or privileged user model. They don't support the less secure setuid model that linux is moving away from. Does this help clarify the issue ? Thanks for disagreeing. You are completely right. Sendmail seems to demand a much more restrictive impersonation policy than Windows offers. That's why I can't get the thing to work. It constantly tests if certain actions are allowed and if so, it just refuses to deliver e-mail. I'll look into this capabilities thing, but I do not intend to change anything significant in the Sendmail code. Maybe the folks at Proofpoint will switch to it one day. Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: The eternal uid issue
Corinna Vinschen wrote: Oh, hang on. Is this using the default setuid method 1 and is your home dir on a remote share, by any chance? No. All file locations are local (C:\). I'll send you the output later on. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: The eternal uid issue
Hi Corinna, Thanks for the reply. Corinna Vinschen wrote: On Jul 23 13:35, D. Boland wrote: Corinna Vinschen wrote: 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. Thanks for your lengthly and detailed answer. I appreciate that. But don't you think upstream maintainers will raise at least one eyebrow if we propose code that makes any user who starts the program the root/admin user? You suggest only those who are in the admin group. But that will soon be any service that starts up. You're getting this wrong. Cygwin is not the OS. We do not make every user an admin since we're in no position to do that. We can't give the user any more rights the OS is already giving the user. Yes, Cygwin is not the OS. But to the user-software, it re-presents the OS as if it were Linux. That's what an emulator does. The idea of such a test is to make the test independent of the actual uid. There are two cases. One is to check if the user has admin rights to perform certain actions, the other is to check if a file ownership is safe. A safe ownership is one where the file belongs to the user running the service. On Linux or BSD systems that's usually the root user, in our case it's some arbitrary user account. The check is basically the same. It actually is my solution to running Sendmail: create the Sendmail user, called 'smmsp' and make it an Administrator, so it can impersonate users on my system. But I don't like my solution, because this would mean I have to create an admin-user for any Linux service that I install. So now my Cygwin setup would be crowded with highly privileged daemons, listening, waiting to get hacked. That's what the cyg_server account is meant for. It's the one account which has the right to change the user context even when using method 1 from the setuid overview of the User's Guide. Other services don't need this permissions, they just have to have the right to create certain objects. Cygserver is such a service, for instance. It's perfectly fine for cygserver to run under SYSTEM or, FWIW, any other account with local administrative privileges. The more elegant solution would be to create only one secondary privileged user, let's call it 'root' ;-). Now Sendmail can start as root, switch to the totally *unprivileged* 'smmsp' user and receive mail. Of course the real bonus is that these unprivileged users wouldn't need passwords, since they are impersonated, not logged on. These would consequently be *super-secure* users, because it is impossible to login with an empty password. Same thing with cyg_server. Why is this related to the uid issue? I already tested the second solution. I found out that if I assign my 'root' user the '0' id in /etc/passwd, it actually works. I was delighted, because I could roll-back all these weird changes I put in the Sendmail/procmail/mail.local source to fix the getuid != 0 problem. Yes, you can do that and it was always possible, but it requires unnecessary user changes. Also, passwd and group files are going to become entirely superfluous at one point, and there's not a single account which is translated to uid 0 on the fly. There simply isn't one. That's my point. All Linux software expects one. So Cygwin has to provide one. Otherwise, the emulation breaks. Sendmail, for instance, is filled to the brim with uid checks, all assuming that there is a '0' account. Its whole idea of security is based around it. Below a sample: $ grep -r getuid * sendmail/deliver.c: if (RealUid != 0 RealUid != getuid()) sendmail/deliver.c:(int) getuid(), (int) geteuid(), sendmail/deliver.c: ret = safefile(m-m_mailer, getuid(), getgid(), sendmail/deliver.c: (int) getuid(), (int) geteuid(), sendmail/main.c:RealUid = getuid(); sendmail/main.c: (geteuid() != getuid() || getegid() != getgid())); sendmail/main.c: (int) geteuid(), (int) getuid(), sendmail/main.c: (int) geteuid(), (int) getuid()); sendmail/main.c: (int) geteuid(), (int) getuid()); sendmail/main.c:if (dp == EX_OK UseMSP (geteuid() == 0 || getuid() == 0)) sendmail/main.c: (int) getuid(), (int) getgid(), sendmail/main.c:(getuid() != RunAsUid sendmail/main.c
Re: The eternal uid issue
Hi Christopher, Thanks for your reply. Christopher Faylor wrote: On Wed, Jul 23, 2014 at 08:08:07PM +0400, Andrey Repin wrote: Greetings, D. Boland! Cygwin security will be done for in the long run. Why not make the leap and show MS admins/developers how it should be done? You really think they are all idiots?... Like, really? Sure, why not. MS admins/developers are all idiots who are apparently supposed to be taught by Cygwin developers who have been getting it wrong for many years until being correct by the OP. To the OP: If you want to start a dialog, do research and ask questions. Don't just assume that you understand everything and can provide insight that no one else has thought of. cgf I didn't say 'idiots', but I did LOL at Andrey's suggestion. Andrey, I'm beginning to like you. By the way, your english really isn't that bad. What I meant was that MS dicided to take away impersonation privileges from the SYSTEM user, without educating admins/developers about the new model or alternatives for SYSTEM. I searched the web extensively for an explanation on the newly imposed restriction. I didn't find one yet. Only vague advice to not start services using the local System account: Minimize the use of the Local System account on the site servers and site systems by not installing other services that use the Local System account. This ensures that other processes cannot take advantage of the enhanced privileges of the systems computer account, accessing Configuration Manager 2007 files and data through those other systems. -- source: http://technet.microsoft.com/en-us/library/bb680595.aspx So I have to assume that it was to enhance Windows security. That is not far-fetched, since the SYSTEM user is totally unrestricted and not suited to be exposed directly to users from the outside. I also have to assume that what they mean by not installing other services that use the Local System account is to create a new user and running a service on behalf of it. Here's how they explain how to configure MS SQL Server (which uses impersonation), but without explaining the underlying security model for services: http://msdn.microsoft.com/en-us/library/ms143504.aspx The only reference I can find about the service security model are the terms minimum rights and minimum privileges. In Linux, the daemon security model is well-known and can be implemented by running as an 'unprivileged user'. Sendmail uses this idea extensively. Again, the only option I have at this moment is to run the Sendmail user (smmsp) as an Administrator, so it can do impersonation. But this does *not* constitute 'minimum privileges', nor does this make the Sendmail user run as an 'unprivileged user'. The preferred solution is to only *start* Sendmail with a privileged user, let's say 'cyg_server'. Now Sendmail can switch to the 'smmsp' user and be running totally unprivileged, only having access to its mail queue directory. But after configuring Sendmail this way, it starts to complain about not having access permissions, because it detects it was not started with the root user (getuid != 0). So, my original question was: can the Cygwin function 'getuid' be made to return '0' if the program is running as the SYSTEM user? But because SYSTEM cannot be used anymore, Corinna suggests to use 'cyg_server' instead and put checks for administrator rights in the Sendmail source. In my reply to her in this thread, I rephrased my question: can the Cygwin function 'getuid' be made to return '0' if the program is running as the SYSTEM user or is running with administrator rights? Cincerely, Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: The eternal uid issue
Hi Corinna,
Corinna Vinschen wrote:
But this only introduces a new function which she has to put into multiple
locations
of the original code. So again, why not just modify the 'getuid' function in
cygwin1.dll to return '0' if the current user is actually SYSTEM or one of
the
administrators?
Then you have rock-solid emulation. I would not have to modify a single
line of
code.
You're kidding, right?
Haha. I must admit that I was not kidding. I got stuck with the idea that
there can
only be one.
What about code like this:
struct stat st;
stat(foo, st);
if (st.st_uid != getuid ())
/*error*/
else
/*do something*/
I'm not saying that this is overly elegant coding, but just as you
expect that getuid() returns 0 for any admin, other applications will
expect that getuid() reflects reality.
Why don't you just override getuid in your application to serve the
applications needs?
#ifdef __CYGWIN__
#define getuid() CYG_getuid()
#endif
[...]
#ifdef __CYGWIN__
#undef getuid
uid_t
CYG_getuid ()
{
/* Return 0 for any admin user. */
if (/*getgroups() contains group 544*/)
return 0;
return getuid ();
}
But be careful. Just because there are multiple users with admin
permissions, that doesn't mean they all want their mail in the same
mailbox for user 0...
Thanks for the overloading code. I already tested it. Now I can leave the
Sendmail
code (almost) unchanged. Thanks also for the time you put into this. I hope the
RedHat people pay you well.
I have Sendmail ready to be released, but only the 'crude' version (running as
an
admin user). I'd like to go for the preferred solution (starting as admin,
switching
to unprivileged). The uid issue is sorted. But to get it there, I have one final
problem to solve.
Sendmail checks if the user's home directories are group- or world writable. It
does
this with 'stat'. If Sendmail is running in 'crude' mode (main program and
children
running as the Sendmail 'smmsp' user, made admin), stat returns the right file
mode
for my home directory (rwxr-xr-x). The email is delivered.
If I have Sendmail running in preferred mode (main program as cyg_server,
children
running as 'smmsp', removed from admin group), stat returns the wrong mode
(rwxrwxrwx). As a consequence, Sendmail refuses to deliver email.
Can I do anything about this?
Cincerely,
Daniel
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
The eternal uid issue
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'. 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 Isn't it about time to make this our First Directive also? Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: The eternal uid issue
Linda Walsh wrote: D. Boland wrote: 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'. Isn't it about time to make this our First Directive also? I thought sendmail used capabilities? Isn't it about time none of them used a fixed 'uid', but used capabilities? I thought hard coding a Uid was going out with the dodo bird? You didn't get the point. We create a kernel on which Linux software runs. We don't dictate how software should be written. Regards, Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: The eternal uid issue
Hi Corinna, Corinna Vinschen wrote: 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. Thanks for your lengthly and detailed answer. I appreciate that. But don't you think upstream maintainers will raise at least one eyebrow if we propose code that makes any user who starts the program the root/admin user? You suggest only those who are in the admin group. But that will soon be any service that starts up. It actually is my solution to running Sendmail: create the Sendmail user, called 'smmsp' and make it an Administrator, so it can impersonate users on my system. But I don't like my solution, because this would mean I have to create an admin-user for any Linux service that I install. So now my Cygwin setup would be crowded with highly privileged daemons, listening, waiting to get hacked. The more elegant solution would be to create only one secondary privileged user, let's call it 'root' ;-). Now Sendmail can start as root, switch to the totally *unprivileged* 'smmsp' user and receive mail. Of course the real bonus is that these unprivileged users wouldn't need passwords, since they are impersonated, not logged on. These would consequently be *super-secure* users, because it is impossible to login with an empty password. Why is this related to the uid issue? I already tested the second solution. I found out that if I assign my 'root' user the '0' id in /etc/passwd, it actually works. I was delighted, because I could roll-back all these weird changes I put in the Sendmail/procmail/mail.local source to fix the getuid != 0 problem. If we go with this MS-imposed idea of putting services in admin-context, Cygwin security will be done for in the long run. Why not make the leap and show MS admins/developers how it should be done? Sincerely, Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: Cygwin 1.7.31-1
Hi Corinna, Corinna Vinschen wrote: [Now with correct subject, sorry] Hi Cygwin friends and users, I just released Cygwin 1.7.31-1. This is mostely a bugfix release. $ uname -a CYGWIN_NT-5.1 dimension 1.7.31s(0.272/5/3) 20140716 11:15:29 i686 Cygwin With the snapshot in place, the ftp client hangs indefinitely after entering the password. Switching back to my old Cygwin DLL, it works again. Greetings, Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: Cygwin 1.7.31-1
Hi Warren, Warren Young wrote: On 7/21/2014 06:19, D. Boland wrote: With the snapshot in place, the ftp client hangs indefinitely after entering the password. Switching back to my old Cygwin DLL, it works again. Which FTP client is that? The ftp.exe that comes with Windows, the ftp.exe from Cygwin's inetutils (?) package, or some other FTP client? I used the ftp program from the inetutils package. D. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Minires truncates host names
Hi Corinna, Corinna Vinschen wrote: It works. As you can see, this is done on a WinXP machine. I could also test on a Win7 machine. I don't have Win8 or Win8.1. That's fine. Thanks a lot for confirming again that Pierre's patch works and the latest Cygwin DLL is doing the right thing here. Out of curiosity, did you manage to build sendmail on 64 bit Cygwin yet? No, only the 32bit one yet. I need to have it working smoothly before the start of the upcoming school year. I'm a Linux teacher in Holland. And more importantly, are you going to become Cygwin maintainer for the sendmail package? This would be way cool. I'd be delighted! Is there some infos I should read? Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Minires truncates host names
Hi Corinna, Corinna Vinschen wrote: Hi Daniel, On Jul 17 22:29, D. Boland wrote: Hi Corinna, Corinna Vinschen wrote: On Jul 17 20:14, D. Boland wrote: Just letting you know how it went with the Resolver (miniedit). The error, pointed out by you, solved the problem. Did you read my previous reply? Do *not* use the minres lib. Use the Cygwin resolver. There's no minires lib on 64 bit anymore and the 32 bit runtime minres is only maintained for backward compatibility. Yes, I read it. I just don't like to swap my current Cygwin DLL. I will test it proper on a fresh Cygwin system on another computer. When will the fix be released? With 1.7.31 in the next few days. But there are still the developer snapshots for testing. Here's the deal: If you test a developer snapshot you can make sure that the next release will fix the problem. If you don't test the snapshot you won't have that privilege and the functionality will still be broken up to the next release. Simple. Ok, I put in the new Cygwin1.dll from the latest 32bit developer snapshot: $ uname -a CYGWIN_NT-5.1 dimension 1.7.31s(0.272/5/3) 20140716 11:15:29 i686 Cygwin Then, I removed /usr/lib/resolv.a, so the call is explicitly done on the new Cygwin DLL. I removed the complete source code from my /usr/local/src directory, re-extracted the sendmail source, made and installed. So now the test-output of the sendmail rule check_mail looks like this: $ echo check_mail dan...@cygwin.com | /usr/sbin/sendmail -d8.20 -bt dns_getcanonname(dimension, trymx=1) dns_getcanonname: trying dimension.sassenheim.dmz (A) Resolv: querydomain dimension sassenheim.dmz type 1 Resolv: query dimension.sassenheim.dmz type 1 Resolv: DnsQuery: 0 (Windows) Resolv: dimension.sassenheim.dmz Section 1 Type 1 Windows Record Length 4 YES dns_getcanonname: dimension.sassenheim.dmz readcf: option TrustedUser may cause problems on systems which do not support fchown() if UseMSP is not set. ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter ruleset address check_mail input: daniel @ cygwin . com Basic_check_mail input: daniel @ cygwin . com tls_client input: $| MAIL TLS_connection input: TLS_connection returns: tls_client returns: CanonAddr input: daniel @ cygwin . com canonify input: daniel @ cygwin . com Canonify2 input: daniel @ cygwin . com dns_getcanonname(cygwin.com, trymx=1) dns_getcanonname: trying cygwin.com. (A) Resolv: querydomain cygwin.com type 1 Resolv: query cygwin.com. type 1 Resolv: DnsQuery: 0 (Windows) Resolv: cygwin.com Section 1 Type 1 Windows Record Length 4 Resolv: ns2.redhat.com Section 3 Type 1 Windows Record Length 4 Resolv: ns1.redhat.com Section 3 Type 1 Windows Record Length 4 Resolv: ns3.redhat.com Section 3 Type 1 Windows Record Length 4 YES dns_getcanonname: cygwin.com Canonify2returns: daniel @ cygwin . com . canonify returns: daniel @ cygwin . com . Parse0 input: daniel @ cygwin . com . Parse0 returns: daniel @ cygwin . com . CanonAddrreturns: daniel @ cygwin . com . Basic_check_mail returns: @ daniel @ cygwin . com check_mail returns: @ daniel @ cygwin . com It works. As you can see, this is done on a WinXP machine. I could also test on a Win7 machine. I don't have Win8 or Win8.1. Greetings, Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Minires truncates host names
Hi Pierre, Pierre A. Humblet wrote: You are right, there is a bug in res_querydomain, Line 737 *(ptr++ - 1) = '.'; should be *ptr++ = '.'; I would also add a debug printf at the top of the function: DPRINTF(statp-options RES_DEBUG, querydomain \%s\ \%s\ type %d\n, Name, DomName, Type); Unfortunately I am not setup to build Cygwin so I can't test the above nor submit a proper patch. Just letting you know how it went with the Resolver (miniedit). The error, pointed out by you, solved the problem. Now I have an even bigger problem. Sendmail works perfectly. But only on my XP machine. As of Windows Vista, MS decided to remove certain privileges from the SYSTEM user. As a consequence, SYSTEM is no longer able to perform the 'setuid' function. This is very much needed, since local mail has to be delivered by a mail delivery agent, like procmail, running under the recipient's credentials. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Minires truncates host names
Hi Corinna, Corinna Vinschen wrote: On Jul 17 20:14, D. Boland wrote: Hi Pierre, Pierre A. Humblet wrote: You are right, there is a bug in res_querydomain, Line 737 *(ptr++ - 1) = '.'; should be *ptr++ = '.'; I would also add a debug printf at the top of the function: DPRINTF(statp-options RES_DEBUG, querydomain \%s\ \%s\ type %d\n, Name, DomName, Type); Unfortunately I am not setup to build Cygwin so I can't test the above nor submit a proper patch. Just letting you know how it went with the Resolver (miniedit). The error, pointed out by you, solved the problem. Did you read my previous reply? Do *not* use the minres lib. Use the Cygwin resolver. There's no minires lib on 64 bit anymore and the 32 bit runtime minres is only maintained for backward compatibility. Yes, I read it. I just don't like to swap my current Cygwin DLL. I will test it proper on a fresh Cygwin system on another computer. When will the fix be released? Now I have an even bigger problem. Sendmail works perfectly. But only on my XP machine. As of Windows Vista, MS decided to remove certain privileges from the SYSTEM user. You might have to read the user's manual in the long run ;) https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview I did read it. Very well written, I might add. It looked very complicated at first but when I read it, it made my problem very clear. Other services are set up so that they use another account called cyg_server. See, for instance, how ssh-host-config helps an admin to set this up. The csih package helper script is lending you a hand when creating such service installer scripts. See also https://cygwin.com/faq/faq.html#faq.using.sshd-in-domain I must say, I am not a big fan of this csih thang. It totally obfuscates what I am doing with my Cygwin server as an administrator. Also, it creates the cyg_server user, which just mimicks what the SYSTEM user used to do. Maybe it should have been called root? The SYSTEM user was/is also regarded as the root user by other softwares from the Unix world. It's in the procmail source code (#define ROOT_uid 18). I searched for MS's position on this issue. I found this article: http://technet.microsoft.com/en-us/library/bb457125.aspx In the section about the SeTcbPrivilege, which the cyg_server user needs to log in as another user, it reads: - The default settings are taken from the Windows XP Professional Local Computer policy. Act as part of the operating system (SeTcbPrivilege) Allows a process to assume the identity of any user and thus gain access to the resources that the user is authorized to access. Typically, only low-level authentication services require this privilege. Default setting: Not assigned. Note that potential access is not limited to what is associated with the user by default; the calling process might request that arbitrary additional privileges be added to the access token. The calling process might also build an access token that does not provide a primary identity for tracking events in the audit log. When a service requires this privilege, configure the service to log on using the Local System account, which has the privilege inherently. Do not create a separate account and assign the privilege to it. - I cannot believe that MS just disabled this privilege in the newer Windows versions, without providing an alternative. So now I'm trying the LocalService user... Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Minires truncates host names
Hi Corinna, Corinna Vinschen wrote: I've checked that in. I also changed the debug output to print Resolv instead of Minires to make sure that people don't think they are stil using the external Minres lib. How can I test the new code? I've tried updating with the Cygwin install program, but the error is still there. $ uname -a CYGWIN_NT-5.1 dimension 1.7.30(0.272/5/3) 2014-05-23 10:36 i686 Cygwin Also, I'm afraid I'm not done yet. Sendmail passes the dot as the root domain, which I think is legitimate: res_querydomain(cygwin.com, ., ... Is there a way for me to test the resolver code? Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Minires truncates host names
Pierre A. Humblet wrote: To me it looks like the string was already truncated when it was passed to the function. You can test e.g. by using exim -d+resolver -bt dan...@cygwin.com It's wonderful that you got sendmail to work. Pierre Thanks for the swift reply! I looked at Sendmails' source code. Here's the snippet which produces the output from my first email. It's taken from the file sendmail/domain.c: sm_dprintf(dns_getcanonname: trying %s.%s (%s)\n, host, *dp, # if NETINET6 qtype == T_ ? : # endif /* NETINET6 */ qtype == T_A ? A : qtype == T_MX ? MX : ???); errno = 0; ret = res_querydomain(host, *dp, C_IN, qtype, answer.qb2, sizeof(answer.qb2)); As you can see, it first prints the host to be looked up, and then passes the string unaltered to res_querydomain. I will create a source release, so it can be tested. Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: rebaseall breaks some packages(?)
Hi Katsumi, Katsumi Yamaoka wrote: However, those reinstallations cause some other programs to not work. For those other programs, rebaseall does help. Though it breaks bzr, emacs-w3m, etc. again. It's annoying. Thanks in advance for your help. Regards, I agree. It's annoying. See this post also: http://cygwin.com/ml/cygwin/2009-11/msg00894.html I'm a developer of Windows software for 15 years now, and my clients never had to rebase my binaries. I'm also a Linux teacher and I use Cygwin in class. My students (100+) repeatedly got these errors, so I switched to an improved version of apt-cyg, which does not rebase. I'm a happy teacher now. What's the deal with this rebasing anyway? Every compiler has a built-in mechanism to create unique offsets. Windows itself also rebases binaries at load-time. On the other hand, why not rebase at compile-time? Rebasing should not be the responsibility of the user, but of the developer. See this article: http://harshdeep.wordpress.com/2007/05/14/thou-shalt-rebase-thy-dll/ Hmm.. This turned out to be a rant. I'm sorry for hijacking your thread. Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Minires truncates host names
Hi Pierre, Pierre A. Humblet wrote: You are right, there is a bug in res_querydomain, Line 737 *(ptr++ - 1) = '.'; should be *ptr++ = '.'; I would also add a debug printf at the top of the function: DPRINTF(statp-options RES_DEBUG, querydomain \%s\ \%s\ type %d\n, Name, DomName, Type); Unfortunately I am not setup to build Cygwin so I can't test the above nor submit a proper patch. I downloaded the source code from your site: ftp://ftp.franken.de/pub/support/win32/develop/gnuwin32/cygwin/porters/Humblet_Pierre_A/V1.5/minires-0.97-src.tar.gz After a 'make', I get multiple warnings and errors, for example: resolver.h:48:6: fout: conflicting types for `dprintf´ void dprintf(char * format, ...); ^ In file included from /usr/include/string.h:10:0, from resolver.h:16, from minires.c:14: /usr/include/stdio.h:337:5: note: previous declaration of `dprintf´ was here int _EXFUN(dprintf, (int, const char *__restrict, ...) ^ Looks like the dprintf function is already defined in stdio.h. Are you using gcc? Greetings, Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Minires truncates host names
Hi Group, I finally got Sendmail ported to Cygwin. But when looking up valid hostnames from sender addresses, Minires fails. Here's the output, testing one of Sendmails' rules. $ echo check_mail dan...@cygwin.com | /usr/sbin/sendmail -d8.20 -bt readcf: option TrustedUser may cause problems on systems which do not support fchown() if UseMSP is not set. ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter ruleset address check_mail input: daniel @ cygwin . com Basic_check_mail input: daniel @ cygwin . com tls_client input: $| MAIL TLS_connection input: TLS_connection returns: tls_client returns: CanonAddr input: daniel @ cygwin . com canonify input: daniel @ cygwin . com Canonify2 input: daniel @ cygwin . com dns_getcanonname(cygwin.com, trymx=1) dns_getcanonname: trying cygwin.com. (A) Minires: query cygwin.co. type 1 Minires: DnsQuery: 9003 (Windows) NO: errno=0, h_errno=1 Canonify2returns: daniel @ cygwin . com canonify returns: daniel @ cygwin . com Parse0 input: daniel @ cygwin . com Parse0 returns: daniel @ cygwin . com CanonAddrreturns: daniel @ cygwin . com Basic_check_mail returns: $# error $@ 5 . 1 . 8 $: 553 Domain of sender address does not exist check_mail returns: $# error $@ 5 . 1 . 8 $: 553 Domain of sender address does not exist As can be seen, Minires queries cygwin.co., not cygwin.com. Is this a bug? Is there a way to test Minires lookups outside of Sendmail? Greetings, Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Cygrunsrv crashes when setting STDERR to /dev/null
Hi group, I have Apache running via cygrunsrv on a WinXP system. It works fine. Apache can even do a setuid on startup, so a 'ps -ef' looks like this: UID PIDPPID TTYSTIME COMMAND httpd16041308 ?14:26:47 /usr/local/apache/bin/httpd SYSTEM13081400 ?14:26:47 /usr/local/apache/bin/httpd httpd 8961308 ?14:26:47 /usr/local/apache/bin/httpd httpd 5361308 ?14:26:47 /usr/local/apache/bin/httpd httpd 6121308 ?14:26:47 /usr/local/apache/bin/httpd httpd 5601308 ?14:26:47 /usr/local/apache/bin/httpd As you can see, I have it running as 'httpd', an unprivileged user, which I created without password and removed from the 'Users' group, so it cannot login. Unfortunately, this doesn't work on a Win7 system. If I try the same configuration in a Win7 system, the following message is logged in logs/error_log and the Service won't start: [alert] (1)Operation not permitted: setuid: unable to change to uid: 1006 So, I set a password for the 'httpd' user and configured the Service to log on as that user. This works, but now I cannot use cygrunsrv's -1 or -2 switches for redirecting STDOUT and STDERR anymore. cygrunsrv crashes if I set either one of them to /dev/null. If I unset them, it works. Can anybody help? Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: vi stealing SYSTEM-owned permissions and ownership
Again, thanks for the input. I's now about three weeks later. I made all of my students re-install Apache in: /cygdrive/c/Apache2 and made them symlink this location on: /usr/local/apache For me, Achim Gratz's comment on the Program Files folder made perfect sense: If you are operating as a normal user on this folder, you aren't actually editing the files you think you see there, the whole contents is virtualized by UAC and redirected to your own personal copy on edit. If you want to keep your sanity, do not place anything that you intend to edit / change as a normal user into system directories on Win7 (that includes Cygwin itself). I am also a software developer, and most of my releases are installed on MS Citrix servers for remote desktop connections. I initially made the mistake to put all files in the Programs Files folder, including the executable, the database and configuration files (.ini). This works fine on a stand-alone XP/Win7 PC, but in a Citrix environment this crashes the application, because of lacking write permissions on the .ini files. Then I found out about the Application Data folder. Releasing my database and .ini files to that folder solved the problem. MS has an article about it: http://msdn.microsoft.com/en-us/library/windows/apps/jj553522.aspx This would mean that in order to install Windows native and avoid virtualization of the conf files the Apache Group should release Apache for Windows into both Program Files and Application Data: Program Files - bin error icons include lib manual modules Application Data cgi-bin conf htdocs logs proxy Thanks again for the comments, Daniel -- Sent by my Altair 8800 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: SV: SV: Some first questions.
Dear Gert, I'm sorry, but this is too much for me. I don't have that much time. I suspect that the build script for Cygwin contains a bug, because of the undefined reference to `WinMain@16' error. Impossible to solve without changing it. What about contacting the author of the build scripts? Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: vi stealing SYSTEM-owned permissions and ownership
Achim Gratz wrote: D. Boland writes: I think I have new information on the stealing of ownership. Below test has been performed on the Apache folder, placed in the Windows Program Files folder by the Apache msi installer: /cygdrive/c/Program Files (x86)/Apache Group/Apache2/ But if I perform the same test in my Cygwin home directory, vi behaves beautifully. So, I was thinking this difference must be related to the Windows ACL assigments on the Program Files folder. If you are operating as a normal user on this folder, you aren't actually editing the files you think you see there, the whole contents is virtualized by UAC and redirected to your own personal copy on edit. If you want to keep your sanity, do not place anything that you intend to edit / change as a normal user into system directories on Win7 (that includes Cygwin itself). http://msdn.microsoft.com/en-us/library/bb756960.aspx Regards, Achim. Thanks for this input. So Apache should be put in a folder, outside the windows special folders, like: /cygdrive/c/Apache2 This seems to be the default for most open source distributions: cygwin, perl, msys, mingw, even xampp. I am still wondering, though, why the Apache Foundation wants it in the Program Files folder. You all are right in saying that the Apache .msi is a hybrid configuration. I guess, maybe it's better to just use the Apache installation provided by CygWin... I also found out about cygrunsrv. This makes Linux daemons run Windows-native. Very nice. Thanks again for your input, Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: SV: Some first questions.
Mr. Anderson, Sorry, I couldn't resist. I saw the Matrix movie recently ;-) Thanks for the extended output you sent me privately, but maybe it's better to keep this public, because others want to know of your progress, too. I wanted to try to compile the Husky software myself. So I went to the Husky sourcefourge page. I downloaded the 1.9-current file: husky-all-1.9-w32mvcdll-20131030.zip When I unzipped it to my /usr/src/husky-all-1.9 folder, I saw that it where all precompiled win32 binaries. Why do you need to compile the sources? Greetings, Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: SV: Some first questions.
Gert Koefoed Andersen wrote: I have compiled lot of sources on linux systems and got now errors here but on cygwin on my windows 7 32bit things not like to work for me. What I ever I have done for it, like: Cd /cygdrive/k/huskysrc/smapi Or copied it to /src/src/huskysrc Cd /usr/src/huskysrc/smapi Make Make install And it ends by error for ld not found some files and others. Output from cygwin terminal by the error: gcc 1stchar.o -o 1stchar /usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../libcygwin.a(libcmain.o): I funktionen main: /usr/src/debug/cygwin-1.7.25-1/winsup/cygwin/lib/libcmain.c:39: undefined reference to `WinMain@16' collect2: fejl: ld returnerede afslutningskoden 1 builtin: recipe for target '1stchar' failed make: *** [1stchar] Error 1 I know this error (unknown reference to WinMain). You get it when you try to compile a module. A module has no main function (like a program has). You need to compile it with option -c. Like: gcc -c lstchar.o -o lstchar Maybe you can add the extra option in the Makefile? I must say, this kind of error occurs only in poorly made distributions, so this will be a difficult build... HTH, Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: vi stealing SYSTEM-owned permissions and ownership
Thanks for the input, guys. I think I have new information on the stealing of ownership. Below test has been performed on the Apache folder, placed in the Windows Program Files folder by the Apache msi installer: /cygdrive/c/Program Files (x86)/Apache Group/Apache2/ But if I perform the same test in my Cygwin home directory, vi behaves beautifully. So, I was thinking this difference must be related to the Windows ACL assigments on the Program Files folder. Maybe vi is confused within this folder, because it is a system folder which recursively forces extra permissions on its subfolders. This means I could solve the issue by telling the Apache installer to put the files in a neutral folder, like: /cygdrive/c/apache/ But then the question would stay, nagging in my mind: why would vi be confused and nano (and notepad.exe by the way) not? Also, Larry Hall pointed out: When I looked at the information provided, I was left with the distinct impression that the 'vi' in use was not a Cygwin version. The fact that the file edited with it had no POSIX permissions was a red flag for me. I initially used the original version of vi that came with the standard distro of Cygwin. When I noticed the problem, I installed vim and went on, testing with that. I really, really would like to persue this issue some more in the direction Larry points to. Cincerely, Daniel D. Boland wrote: Meanwhile, I accidentally found sort of a solution: deleting the file without write permissions on the containing folder, restores the permissions set by Administrator. As Administrator: chmod 0700 . touch test.txt chown SYSTEM:apache test.txt chmod 0770 test.txt Results in: -rwxrwx---+ 1 SYSTEM apache 0 2 nov 13:26 test.txt As normal user: Edit the file with vi. After, permissions will look like: --+ 1 Daniel None 9 2 nov 13:29 test.txt $ getfacl.exe test.txt # file: test.txt # owner: Daniel # group: None user::--- group::--- group:SYSTEM:rwx group:Administrators:rwx group:Gebruikers:r-x group:apache:rwx mask:rwx other:--- To solve this, simply delete the file: rm test.txt The file is not deleted because of 0700 on the containing folder. But the original permissions, set by Admin are restored!! -rwxrwx---+ 1 SYSTEM apache 9 2 nov 13:29 test.txt $ getfacl.exe test.txt # file: test.txt # owner: SYSTEM # group: apache user::rwx group::rwx group:Administrators:rwx group:Gebruikers:r-x mask:rwx other:--- -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: vi stealing SYSTEM-owned permissions and ownership
Andrey Repin wrote: Greetings, D. Boland! Your main problem is that you are trying to break into native Windows ACL system with Cygwin tools. And not only that, you also trying to wrest native ACLs into POSIX permissions, and expect native applications to work fine afterward. Which can be done theoretically, but in reality is a real big headache to maintain. You are speaking of Cygwin as if it's some kind of quick hack. This is not the case. Most of the tools are of the GNU software collection, which is high quality software. ACL is also available on other Linux flavours, and they don't have to wrest it into POSIX. Also, one could say that ACL is a superset of the POSIX model. It uses POSIX's idea of users, groups and others, but then offers the posibility to add more users and groups for more elaborate schemes. The headache starts when one actually starts using these extra posibilities. If you truly want to show your students their Windows systems from the command line, I suggest you learn Windows command line. If not very robust, it is nonetheless rich, and allow for many operations normally performed from GUI, and some operations, that can not be done from GUI, either without much complication or at all. In the case mentioned below, the net tool should come in handy. As well as sc tool. I could just give my students an iMac, but these are not used in IT production infrastructures. Windows (business/government) and Linux/Unix (ISP's) are. The Windows command line is frustrating to work on. For instance, their implementation of autocompleting with the tab-key sucks. In stead of really simplifying and improving on DOS, MS comes up with more weird tools like PowerShell. Now you have to be a programmer to use the command-line. Also, forcing someone to use vi over more sane editors is a torture which no one deserve. Haha, yes. But if my students have to administer remote production-machines, most of the time they have no other option. I want them to succeed where others fail. Sorry for my terrible english... No problem. Sincerely, Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Some first questions.
Gert Koefoed Andersen wrote: Hello list. I have some first questions for cygwin works on windows 7 by compile sources I normally just fine compile on my linux systems but not like to compile well and by cygwin. The sources I trying to compile is been packed on linux with tar archiwing program so I can get the sources over to windows 7 and cygwin. So it is then this then. 1. where is the best place to unpack the sources for compile by cygwin. My windows cygwin is installed on c:\cygwin and by installing cygwin is the cygwin download sources been put at k:\cygwinsrc. 2. if the extra sources is best to be places at k:\cygwin, then is it then best to handle them for cygwin ? 3. Then is it that - the sources have makefiles .cyg and other compilers + some main configs like Makefile and huskymak.cfg. When I have copied the file makefile.cyg to makefile.cfg and then have this file in the main home dir for example - \...\husky\smapi\ and then is got in to \smapi source dir and then run make to compile the sources for smapi goes it fine to I getting a error of gcc -mno-cygwin and then error 2 of it not can find some file it should make and when I checking out for the file is it where it should be by not compile to make a .o files for more compile finish. Regards, Gert There is a standard location for sources, as is for libraries and includes. In Cygwin it's /usr/src. In some other Linuxes it's /usr/local/src. I have been compiling lots of source distributions over the years. I am not aware that you have to move or copy Makefiles. As far as I know you just need to: cd /usr/src/yournewapp ./configure make make install With the last command, all configuration files are automatically put in the right folders. HTH, Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
vi stealing SYSTEM-owned permissions and ownership
Hi group, I'm a Linux teacher at a school for vocational education in the Netherlands. I use Cyqwin to help my students overcome their fear of the command line by showing them their Windows systems through the eyes of Linux. I had them install Apache and then configure it in Cygwin using vi. As of Windows 8, the Apache installation sometimes fails, because of permission issues. Installing As administrator solves the problem. This is fine with me because in other Linuxes, Apache is installed as root by default. After installation, permissions in the Apache conf directory look like this: drwx--+ 1 SYSTEM SYSTEM 0 28 okt 20:43 . drwx--+ 1 SYSTEM SYSTEM 0 2 nov 13:10 .. -rwx--+ 1 SYSTEM SYSTEM 35142 26 okt 18:07 httpd.conf -rwx--+ 1 SYSTEM SYSTEM 34770 7 okt 23:29 httpd.default.conf -rwx--+ 1 SYSTEM SYSTEM 13340 3 okt 07:59 magic -rwx--+ 1 SYSTEM SYSTEM 13340 21 nov 2004 magic.default -rwx--+ 1 SYSTEM SYSTEM 54599 3 okt 07:59 mime.types -rwx--+ 1 SYSTEM SYSTEM 54599 17 mrt 2012 mime.types.default -rwx--+ 1 SYSTEM SYSTEM 9390 5 feb 2013 openssl.cnf -rwx--+ 1 SYSTEM SYSTEM 11050 3 okt 07:59 ssl.conf -rwx--+ 1 SYSTEM SYSTEM 11030 7 okt 23:29 ssl.default.conf To emulate the Unix permissions model, I had my students add a group in Windows, named apache, making themselves a member and then import it using the mkgroup command. After a chgrp and chmod on the entire Apache folder, the conf directory looks like this: drwxrwx---+ 1 SYSTEM apache 0 28 okt 20:43 . drwxrwx---+ 1 SYSTEM apache 0 2 nov 13:10 .. -rwxrwx---+ 1 SYSTEM apache 35142 26 okt 18:07 httpd.conf -rwxrwx---+ 1 SYSTEM apache 34770 7 okt 23:29 httpd.default.conf -rwxrwx---+ 1 SYSTEM apache 13340 3 okt 07:59 magic -rwxrwx---+ 1 SYSTEM apache 13340 21 nov 2004 magic.default -rwxrwx---+ 1 SYSTEM apache 54599 3 okt 07:59 mime.types -rwxrwx---+ 1 SYSTEM apache 54599 17 mrt 2012 mime.types.default -rwxrwx---+ 1 SYSTEM apache 9390 5 feb 2013 openssl.cnf -rwxrwx---+ 1 SYSTEM apache 11050 3 okt 07:59 ssl.conf -rwxrwx---+ 1 SYSTEM apache 11030 7 okt 23:29 ssl.default.conf My students can now administer Apache without running Cygwin As administrator. Also, this is extremely useful in real-time business situations. It enables my students to grant Apache admin permissions to other users by putting them in the apache group, without giving them full admin access on the entire system. But here's the problem. After editing the httpd.conf file with vi, the permissions on the httpd.conf file are changed to: --+ 1 Daniel None 35142 2 nov 13:20 httpd.conf This should not be. I tested this on my RedHat and OpenBSD systems, and there are no changes in ownership or permissions after editing with vi. After fiddling with chown, chgrp, chmod, getfacl, setfacl and icacl for a few hours, I finally installed nano. Nano behaved. It did not alter anything except the contents of the file. But I want my students to learn vi, so having them install nano is not an option. I think the problem is vi. Vi deletes the original file and creates a new one with the changed contents, without resetting the original ownership and permissions. See also this post: http://unix.stackexchange.com/questions/58880/how-does-vim-steal-root-owned-files Can somebody shed some light on this? Meanwhile, I accidentally found sort of a solution: deleting the file without write permissions on the containing folder, restores the permissions set by Administrator. As Administrator: chmod 0700 . touch test.txt chown SYSTEM:apache test.txt chmod 0770 test.txt Results in: -rwxrwx---+ 1 SYSTEM apache 0 2 nov 13:26 test.txt As normal user: Edit the file with vi. After, permissions will look like: --+ 1 Daniel None 9 2 nov 13:29 test.txt $ getfacl.exe test.txt # file: test.txt # owner: Daniel # group: None user::--- group::--- group:SYSTEM:rwx group:Administrators:rwx group:Gebruikers:r-x group:apache:rwx mask:rwx other:--- To solve this, simply delete the file: rm test.txt The file is not deleted because of 0700 on the containing folder. But the original permissions, set by Admin are restored!! -rwxrwx---+ 1 SYSTEM apache 9 2 nov 13:29 test.txt $ getfacl.exe test.txt # file: test.txt # owner: SYSTEM # group: apache user::rwx group::rwx group:Administrators:rwx group:Gebruikers:r-x mask:rwx other:--- -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: vi stealing SYSTEM-owned permissions and ownership
Brian S. Wilson wrote: I'm a Linux teacher at a school for vocational education in the Netherlands. I use Cyqwin to help my students overcome their fear of the command line by showing them their Windows systems through the eyes of Linux. ... After a chgrp and chmod on the entire Apache folder, the conf directory looks like this: drwxrwx---+ 1 SYSTEM apache 0 28 okt 20:43 . drwxrwx---+ 1 SYSTEM apache 0 2 nov 13:10 .. -rwxrwx---+ 1 SYSTEM apache 35142 26 okt 18:07 httpd.conf -rwxrwx---+ 1 SYSTEM apache 34770 7 okt 23:29 httpd.default.conf -rwxrwx---+ 1 SYSTEM apache 13340 3 okt 07:59 magic -rwxrwx---+ 1 SYSTEM apache 13340 21 nov 2004 magic.default -rwxrwx---+ 1 SYSTEM apache 54599 3 okt 07:59 mime.types -rwxrwx---+ 1 SYSTEM apache 54599 17 mrt 2012 mime.types.default -rwxrwx---+ 1 SYSTEM apache 9390 5 feb 2013 openssl.cnf -rwxrwx---+ 1 SYSTEM apache 11050 3 okt 07:59 ssl.conf -rwxrwx---+ 1 SYSTEM apache 11030 7 okt 23:29 ssl.default.conf My students can now administer Apache without running Cygwin As administrator. Your statement may not be quite accurate. The Cygwin Apache instance appears to be running as the SYSTEM user since that is the file owner, but your students can administer the files because they are members of the apache group. I can't really tell which user id is running your Apache process because I don't know how you are actually starting the Apache process. Most production Apache instances do not run as the root user since this is a security risk. If my guess about the Apache process owner is correct, please make your students aware that if someone hacks their Cygwin Apache servers, the hacker may gain the same user access rights as the user id actually running the Apache process. The Apache process owner would normally be a unique user account with no login or access privileges to protect the server from successful attacks (just because your Apache files are owned by SYSTEM, Apache could be started under another, less privileged, user id for better protection; but it is common practice to have the file owner also be the user id that normally executes the file). It is common to see a nobody user as the owner of Apache in production systems. I've spent some time over several years trying to figure out how to get Apache working as a nobody user under Cygwin. I've never succeeded in getting it to work properly, and my comments to this board have not yielded an answered. I don't think it is possible to make Apache work this way under Cygwin, but your students should be made aware of this difference. If anyone is aware of how to get Apache working using a restricted nobody user id under Cygwin, please respond (or start a new thread). Your concern is very real, I thought about that also. First, in my student-setup, Apache is not running under Cygwin. I used the .msi distribution, available on the Apache website. This installs Apache as a native Windows Service, and it can be configured using the Windows Services Control Panel. As to running as the SYSTEM user, I agree with you. In Linux, Apache is started by root, and then immediately switches to the nobody user, so it is unable to touch or even see the outside of its ServerRoot. In Windows, this mechanism does not work. That is why the User and Group directives are left out of the httpd.conf file in the Windows distribution. I now have Apache running under the username Daemon which I created using the standard Windows Users Control Panel. I put this user in my apache group like this: net localgroup apache Daemon /add The tricky part was assigning the following permissions to the Daemon user: * Log on as a service * Act as part of the operating system I did this in the Local Security Settings Control Panel, which can be found in the System Administration Control Panel. It is also possible to bring it up by running secpol.msc from the Start menu. Finally, I configured Apache to run as user Daemon in the Services control panel (services.msc). Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
