Mail Archives: cygwin/2014/02/14/15:11:55
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
- Raw text -