delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2008/03/18/11:33:53

X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Message-Id: <1205857963.32092.1243064787@webmail.messagingengine.com>
From: "Charles Wilson" <cygwin AT cwilson DOT fastmail DOT fm>
To: cygwin AT cygwin DOT com
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
Subject: RE: inetutils-1.5-2 test release
Date: Tue, 18 Mar 2008 12:32:43 -0400
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

> The test release of inetutils installs fine with setup.
> I tested it with my original xinetd setup (replacing the in.* daemons with the new ones).
> 
> Authentication via ftpd does not seem to work in the new release:
> ...
> 530 Login incorrect.

This is odd. ftpd works for me
  1) on XP SP2, where inetd is installed as a service on its own,
  running under the local system account
  2) on XP SP2, where inetd is installed as a service using cygrunsrv,
  running under the local system account
  3) on XP SP2, where inetd is invoked via sysvinit's init process
  (/etc/rc.d/inetd), and were init is running under the local system
  account

However, ftpd does not work if inetd is running under
sshd_server/cyg_server/other_privileged_user -- so I assume it will not
yet work under vista.  But that issue is not a regression, AFAICT. What
are the details of your installation?  I don't need full cygcheck, just
OS ver, user that inetd is running as, whether inetd is installed as a
service on its own, under cygrunsrv, or via sysvinit's init service (and
the user under which init is running), and an `ls -l' listing of /etc.

> Remote commands via the new rsh do not seem to work:
> >rsh vzell AT xp DOT de DOT oracle DOT com ls
> /bin/rsh: must be setuid root.

Hm. again, this works for me -- unless inetd is running under a
"privileged user". This is because rshd contains code to check the UID
(against '18' == LocalSystem; it doesn't know how to deal with other
privileged UIDs. But again -- the old rshd had the same limitation in
the code, so I am a bit confused as to how it worked for you, before.
Unless xinetd was running under LocalSystem, but inetd is not?

> Last question. What is .talkrc for ? I get the following in /var/log/messages when running talk. The man page says nothing.
> Mar 18 13:30:37 localhost talkd: PID 2132: can't open config file /home/vzell/.talkrc: No such file or directory

You're right, this is not documented at all.

2001-10-25  Sergey Poznyakoff

        Talkd essencially rewritten. New feature: system-wide and
        user-specific access-control lists allow for controlling
        who and from where is able to request talks.

Somebody also mentioned that error message (note the date):
http://lists.gnu.org/archive/html/bug-inetutils/2002-09/msg00037.html
but it was never corrected.

Anyway, it seems that .talkrc is intended for per-user access control,
like the `talkd --acl FILE' option is for site-wide access control. 
  -a, --acl FILE         read site-wide ACLs from FILE
The format of the site-wide acl file and the per-user acl file is the
same -- because it is parsed by the same code. However, the format isn't
documented at all, either.

Perusing the code, it looks like the format is:

allow|deny <RE> <INET> [<INET> [<INET> ...]

where one of allow/deny is required
<RE> is a regular expression (regcomp() style) that is applied to the
caller's username. Whether "Extended" RE patterns are allowed depends on
the system implementation of regcomp.
<INET> is a network address. It appears that any of these formats work:
  192.168.1.0/255.255.255.0 
  192.168.1.0/24
  192.168.1.2
  any
but no dns lookups are possible. Both <RE> and (one of the) <INET> have
to match for the specified rule (allow or deny) to apply. The default
behavior is:

allow * any

I'll look into silencing that "error" message.

BTW, I hadn't even gotten around to announcing this as an official test
release yet. You're really on the ball...

--
Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019