DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	 q=dns; s=default; b=cOoGKqsfAlETvINbL65RbWZv6aYPBZfu7UPvXrCQx2h
	GUCQd4lEljWbh0d4mCeFohbYAbopjln/eoq7WexCo86STVdnn0BAfp66O1pQPjz6
	2ReWp9XpmOmwTp9n0IFdyrgAX1yLcAtAM0+Wv/lpn9JAK4AcVwDG+2zWlp6vCm9U
	=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Message-ID: <52FE786F.9040203@etr-usa.com>
Date: Fri, 14 Feb 2014 13:11:27 -0700
From: Warren Young <warren AT etr-usa DOT com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Testers needed:  New passwd/group handling in Cygwin
References: <20140213143849 DOT GH2246 AT calimero DOT vinschen DOT de> <52FD63BC DOT 60800 AT etr-usa DOT com> <20140214104243 DOT GY2246 AT calimero DOT vinschen DOT de>
In-Reply-To: <20140214104243.GY2246@calimero.vinschen.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 2/14/2014 03:42, Corinna Vinschen wrote:
> On Feb 13 17:30, Warren Young wrote:
>> On 2/13/2014 07:38, Corinna Vinschen wrote:
>
>>>    Apart from power shell scripting or inventing new CLI tools, these
>>>    attributes can be changed using the "Attribute Editor" tab in the user
>>>    properties dialog of the "Active Directory Users and Computers"
>>>    MMC snap-in.
>>
>> A week ago, we were talking about possible Cygwin
>> {user,group}{add,mod} programs, modeled on Linux's.  Was that simply
>> shelved once "net user" and MMC were found to be sufficient?
>
> Huh?  "Apart from [...] or inventing new CLI tools, [...]"
>                          ^^^^^^^^^^^^^^^^^^^^^^^^^^

I wasn't sure how to interpret that.  It could be read as an unfulfilled 
possibility or as dismissing a ridiculous idea.  i.e. "Apart from 
rewriting Cygwin in Erlang..."

>> If, magically, such programs were to appear from outside the Cygwin
>> core dev group, would that be a good thing or a bad thing?
>
> It would be a really great thing!

Okay.  I thought you might feel proprietary about such tools.  "I know 
how it needs to be written, so I'm going to be the one to write it, 
right after the other 59 bazillion things on my wishlist."

>> I know I'm bikeshedding, but "unix" seems like a pretty vague
>> attribute name here.
>
> Really, I'm open to suggestions to have a better keyword, but it
> should make very clear that this is not your Cygwin uid/gid.

Okay, netfsuid, then.

>> "All" processes?
>
> You are absolutely right, but, please, suggest a better wording.

"If you create or change /etc/nsswitch.conf, you need to restart all 
Cygwin processes that need to see the change.  If the process you want 
to see the change is a child of another process, you need to restart all 
of that process's parents, too."

"For example, if you run Vim inside the default Cygwin Terminal, Vim is 
a child of your shell, which is a child of mintty.exe.  If you edit 
/etc/nsswitch.conf in that Vim instance, your shell won't immediately 
see the change, nor will Vim if you restart it from that same shell 
instance.  This is because both are getting their nsswitch information 
from their ancestor, mintty.exe.  You need to start a fresh terminal 
window for the change to take effect."

"By contrast, if you leave that Cygwin Terminal window open after making 
the change to /etc/nsswitch.conf, then restart a Cygwin service like 
cron, cron will see the change, because it is not a child of mintty.exe 
or any other Cygwin process. (Technically, it is a child of cygrunsrv, 
but that instance also restarts when you restart the service.)"

"The reason we point all this out is that the requirements for 
restarting things are not quite as stringent as when you replace 
cygwin1.dll. If you have three process trees, you have three independent 
copies of the nsswitch information.  You do not need to restart any of 
them for a new process tree to see the changes, but until each restarts, 
they will not see the change."


Better?

You could stop with the first paragraph, but I think the following 
exposition helps.

> What entry would you find in passwd which you
> didn't already find in SAM or via the implemented automatisms
> for unknown SIDs?

That makes sense.

Is nsswitch.conf the right thing, then?  Are we borrowing that mechanism 
just because it exists and looks close enough?

It seems to me that we really only need a single Boolean setting:

     ignore_db=true

If this is true, it uses files only.  If false, DB is the sole source of 
truth if /etc/{passwd,group} are missing, or it is a fallback source of 
truth if those files are present.

Does this help us get to a world where we configure this in nscd.conf, 
as cgf proposed?

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