delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2008/08/04/21:32:29

X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Message-ID: <4897AD74.8020606@cwilson.fastmail.fm>
Date: Mon, 04 Aug 2008 21:31:32 -0400
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.16) Gecko/20080708 Thunderbird/2.0.0.16 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: CSIH patch (Re: Unable to run sshd under a domain sshd_server account [SOLVED])
References: <3B3EFBD49B94AD4DBB7B7097257A8046DD020D AT FDSVAST06SXCH01 DOT flooddata DOT net> <Pine DOT GSO DOT 4 DOT 63 DOT 0805121820090 DOT 11953 AT access1 DOT cims DOT nyu DOT edu> <20080513073720 DOT GA22193 AT calimero DOT vinschen DOT de> <3B3EFBD49B94AD4DBB7B7097257A8046DD02FC AT FDSVAST06SXCH01 DOT flooddata DOT net> <20080616210105 DOT GI731 AT calimero DOT vinschen DOT de> <20080616211352 DOT GK731 AT calimero DOT vinschen DOT de> <48821B9F DOT 6070907 AT cwilson DOT fastmail DOT fm> <20080719171235 DOT GO5675 AT calimero DOT vinschen DOT de> <488252B5 DOT 8000501 AT cwilson DOT fastmail DOT fm> <20080720122754 DOT GP5675 AT calimero DOT vinschen DOT de> <20080720134054 DOT GQ5675 AT calimero DOT vinschen DOT de>
In-Reply-To: <20080720134054.GQ5675@calimero.vinschen.de>
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

Corinna Vinschen wrote:
>> Along these lines, yes.  I also think that using the cyg_server/
>> cron_server/sshd_server account should be preferred over SYSTEM on XP
>> and earlier systems, at least if they are domain member machines.  Maybe
>> simply like this:  The test should run on any OS, but if none of the
>> accounts exists, the fallback for XP and earlier is SYSTEM.  IIUC, that's
>> not quite what $csih_FORCE_PRIVILEGED_USER is for.  Yes?  No?

Correct -- csih_FORCE_PRIVILEGED_USER means FORCE; you're asking for a 
gentle default behavior.

I've modified the behavior on NT/2k/XP when not 
$csih_FORCE_PRIVILEGED_USER, so that if a 'known' privileged user 
exists, then it is used. Otherwise, SYSTEM; no new users will be created.

However, on NT/2k/XP the $csih_FORCE_PRIVILEGED_USER behavior is 
unchagned: if a privileged user already exists it will be used (as 
above) -- but if one does NOT exist, one will be created and used. And 
failure to create it is a script failure.

> I tried the above script change on a XP domain member machine and
> with csih_FORCE_PRIVILEGED_USER set to yes.  It works, it's just a
> bit bumpy:
> 
>   *** Info: This script plans to use 'cyg_server'.
>   *** Info: 'cyg_server' will not be able to log on interactively, but will only
>   *** Info: be used by registered services.
> 
> The message is incorrect.

Fixed.

>   *** Query: Do you want to use different name? (yes/no) no
>   mkpasswd (273): [2221] The user name could not be found.
> 
> I'm not sure why is mkpasswd is called here, but it's called with -l
> only so it can't find the domain account.  Can this test be skipped
> if the user has been directly taken from /etc/passwd?

Well, I *think* it is now skipped because that code path doesn't get 
activated now, if the user was found (in /etc/passwd OR in localSAM).

Now, you only hit that line if you just created the user: which only 
happens if it existed neither in the SAM nor in /etc/passwd. And, since 
you just created it -- locally -- it obviously exists in the SAM /now/ 
-- but not yet in /etc/passwd.  How do you add an entry to /etc/passwd 
for a user in the local SAM?  mkpasswd -l.

I added some comments at the appropriate places to make this clearer.

> Btw., there's a test for the administrators group in /etc/passwd.
> This test is not necessary.  The only reason to have the admins
> group in /etc/passwd is to print file ownership correctly.  It doesn't
> have any other value.

I don't see this. I see testing /etc/passwd for the (local) 
Administrator USER, and testing /etc/group for the Administrators GROUP, 
but not /etc/passwd <-> Administrators GROUP.

More info please?


Please try current CVS:
http://cygwin.com/cgi-bin/cvsweb.cgi/~checkout~/csih/cygwin-service-installation-helper.sh?rev=1.10&cvsroot=cygwin-apps

or
http://tinyurl.com/5ex7bl

--
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