This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: base-[files|password] for 1.7
On Jul 28 14:55, Pierre A. Humblet wrote:
> Looks like without argument the new mk{passwd/group} will dump the entire
> passwd/group from the domain server. Some companies have tens of thousands
> of names and that's why they weren't called with -l -d by default but with -l -c
>
> The -c switch would only create an entry for the current user or the current primary group
> WITHOUT contacting the domain server. mkpasswd could do a good job for passwd
> using only local info but mkgroup could not find the group name, so it was
> calling it "mkgroup-l-d" .
I thought it's a good idea to have the domain by default. It's a bit
strange that a machine is running in a domain but as soon as another
user logs in, the passwd and possibly group information for this user
is missing.
Even if we drop back to using mkpasswd -l -c, I don't think it makes
sense to run mkgroup in a domain environment without fetching all
domain groups.
> The new mkgroup also has a -c option, which gets the current primary
> group name. That's great, but does it contact the server? If so, how
No. The -c options only open the user token and fetch the name
information from a call to LookupAccountName(NULL, ...). Since the
user information for the current user is cached on the local machine,
there's no server access.
> does it behave when a domain user installs cygwin while not connected
> to the domain server? That case generated complaints in the past.
Not for -c, but in the default case it will take some time until it
times out and won't print the domain groups. Since that's only an
actual issue at installation time, where's the problem?
> I also noticed that the new mkpasswd -c does not put a guess about the full user name
> in the comment field
> old -c:
> p-humblet:unused_by_nt/2000/xp:11068:11031:p-humblet,U-W...
> new -c
> p-humblet:unused:11068:11031: U-W... <== no p-humblet
> {old,new} -d
> p-humblet:unused:11068:11031:Pierre Humblet,U-W...
Why do you need that? I was contemplating the idea to drop this
entirely. I even contemplated the idea to remove the U-domain\user
entry from pw_gecos, plus the extra functionality in the
extract_nt_dom_user function in sec_auth.cc. I rearranged it to use
the SID from the passwd entry and to call LookupAccountSid first.
In theory there's no good reason to use that U-domain\user entry at all.
Extracting this information from the SID only makes much more sense,
IMHO.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat