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


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

Re: [ITA] inetutils-1.5-1


Okay, this is round #2. New packages are here:

http://cygwin.cwilson.fastmail.fm/ITP/inetutils-1.5-2.tar.bz2
http://cygwin.cwilson.fastmail.fm/ITP/inetutils-1.5-2-src.tar.bz2

Now depends on csih, so new setup.hint (with trimmed-down ldesc):

===== setup.hint =====
sdesc: "Common networking clients and servers"
ldesc: "inetutils provides common networking clients and
servers, including the inetd super-server, telnetd and
telnet, ftpd and ftp, rshd and rsh, rlogind and rlogin,
talkd and talk, tftpd and tftp, rexecd (but no rexec),
uucpd (but no uucp client), rcp, and syslogd."
category: Net
requires: cygwin terminfo csih
===== setup.hint =====

Changes since last post:
1) all inetd.conf services are disabled by default (but do not explicitly reference tcpd/tcp_wrappers).


NOTE: I decided NOT to make iu-config super-smart. It does NOT
a) ask about each service and offer to enable/disable it, NOR
b) automagically update existing inetd.conf files from referencing "in.telnetd" to "telnetd".
In both cases, the reason was: no matter how smart I make iu-config, the pre/postinstall scripts will never be able to tell if inetd.conf was "automatically" modified, or manually modified -- and "different" means "never updated from new /etc/defaults/". I figured THAT was a worse outcome than simply requiring:
c) if you've already manually modified inetd.conf, you need to do so again, or
d) if you want something different than the default behavior, you should manually establish it.


2) incorporated Corinna's security patch for rcpd (from 1.3.2-40). Also applied a similar fix to rexecd.

3) updated inetutils.OLD-README to 1.3.2-40's README (from 1.3.2-37).

4) preparing for disabling --install-as-service option. It's not disabled YET, but all it will take is a single #define and it's gone.

5) other documentation updates, related to these changes. Also, officially deprecated the "install as a service on its own (e.g. --install-as-service). It will (always?) allow operation in this mode if already installed, but eventually the --install-as-service will go away, leaving only cygrunsrv and init as viable mechanisms.

6) inetd.exe from 1.5-2 will honor inetd.exe-1.3.2's registry key, if present. This only applies if inetd-1.3.2 had previously been installed as a service using --install-as-service.

7) rewrote iu-config to use csih facilities -- also, now offers to install inetd as a service (via cygrunsrv). Note the -p option, which allows on NT/2k/XP systems to use a special privileged user, just like on WinServer2003/2008/Vista/etc.
http://cygwin.cwilson.fastmail.fm/ITP/iu-config


8) rewrote syslogd-config to use csih facilities
http://cygwin.cwilson.fastmail.fm/ITP/syslogd-config

9) new motd <g>

New problems:
=============================
While testing the csih privileged user stuff (and the iu-config -p option), I found that while inetd was perfectly happy to run under the privileged user, some of the slave servers (ftpd, rshd, ...) did not operate as well as they did under LocalSystem.


In particular, I couldn't even log in using ftpd. rshd did not honor .rhosts settings -- but did authenticate with password. Telnetd was fine. I think these have to do with hardcoded "ROOT_UID" stuff. Sergey's original port simply substituted root tests like:

if (!uid) { ... }

with

  #ifdef __CYGWIN__
  #define ROOT_UID 18
  #else
  #define ROOT_UID 0
  #endif

if (uid == ROOT_UID) { ... }

Obviously, that's no good with special privileged users (and would also break if we started using NetworkService or LocalService accounts).

These issues are, as far as I know, also present in the existing 1.3.2-X series, so they are not regressions, and probably shouldn't prevent uploading 1.5-2 as an "official" *test* release -- assuming the necessary approvals and GTGs for this 1.5-2 packageset and for the new csih package are forthcoming...

I'll look into fixing these newly discovered issues with the slave servers in -3 or later -- suggestions as to the "correct" fix? Should I create a special function "accountHasRootLikeCapabilities(some uid)" and use that? What would this function look like?

--
Chuck


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