This is the mail archive of the cygwin 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: Testers needed: New passwd/group handling in Cygwin


On Feb 14 13:11, Warren Young wrote:
> 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..."

Nah, I'm not *always* cynical.

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

Actually, high on my wishlist is more active maintainers for the distro.
We have a couple of maintainers of very important packages which only
show up very sporadically lately, which is pretty frustrating.


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

Hmm.

> >>"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."
> [...]
> Better?

Yes.  Thanks a lot.  I grabbed all of this including your followup
change shamelessly and added it to the text.

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

Perhaps.

> It seems to me that we really only need a single Boolean setting:
> 
>     ignore_db=true

No, that's not right.  We have two mechanisms implemented you can
choose three out of four possible combinations:

  files only
  db only
  files, then db

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

The third combination is to prevent Cygwin from reading /etc/passwd
and /etc/group at all.  It drops any check for existence, too, which
is one code point less which has to run for each getpwXXX/getgrXXX
invocation.

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

I'm open to discuss this.  We can switch from nssswitch.conf to
nscd.conf, but our settings will still not match the role-model,
so it's kind of a name-reuse only, either way.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: pgpZO3JkJ5CYM.pgp
Description: PGP signature


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