delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2019/01/10/12:57:35

X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
:list-unsubscribe:list-subscribe:list-archive:list-post
:list-help:sender:date:from:to:cc:subject:message-id:reply-to
:references:mime-version:content-type:in-reply-to; q=dns; s=
default; b=l3Q6Cv8R8EbkR8m2g82EKJ61T6oRIbzwSbDK+Ld+FLKR79akU4gyG
KxNu5t3bAPPVVB4qMe7ULxsfb+OYbRSewQFb72Y3qDfd/DSO4Hj3urL24LVtCEto
03ZEXveBhoDVEvhrQmxxPfoVGoe86dRv/yhW+liPMi07oSlvlwo5Fw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
:list-unsubscribe:list-subscribe:list-archive:list-post
:list-help:sender:date:from:to:cc:subject:message-id:reply-to
:references:mime-version:content-type:in-reply-to; s=default;
bh=XFwVcilUszLjpTfk9i0LdN7IdYc=; b=uk4Efurvg4dEWIBvUJkCq3BYM+UV
fzAf3Y6bow3+PFZNoNKy/u211IHVnuv3aqSdMW9jtQj3M8nZXTQqUYxksRMkfDJL
snnUZVhKwb3Sw3fXN36ThAt2eluCFH5HRpX5yLb3HZOIsIZWU7MgHtZNHrlp/cxV
gtyXW97k5nvX89Y=
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
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-100.9 required=5.0 tests=BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=Charles, charles, H*F:D*cygwin.com, our
X-HELO: mout.kundenserver.de
Date: Thu, 10 Jan 2019 18:57:18 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: Charles Hedrick <hedrick AT rutgers DOT edu>
Cc: "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Subject: Re: user/group mapping for NFS
Message-ID: <20190110175718.GN593@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: Charles Hedrick <hedrick AT rutgers DOT edu>, "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
References: <0562D98D-714A-4620-878E-B37282E8F688 AT rutgers DOT edu>
MIME-Version: 1.0
In-Reply-To: <0562D98D-714A-4620-878E-B37282E8F688@rutgers.edu>
User-Agent: Mutt/1.10.1 (2018-07-13)

--e5bfZ/T2xnjpUIbw
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Charles,

On Jan 10 15:24, Charles Hedrick wrote:
> We have a system that is doing a Kerberized NFS mount of directories
> on Linux. We have our LDAP system set up as a mapping server, with
> samaccountname added to users so that the Windows mount command does
> the mount as the right user.
>=20
> ls -l causes a query that looks like
> (&(objectClass=3DposixAccount)(uidNumber=3D26780))" attrs=3D=E2=80=9Cuid=
=E2=80=9D. We sent
> back a response. If there=E2=80=99s a local account for the user, =E2=80=
=9Cls -l=E2=80=9D
> shows them. But we only have loal accounts for people who actually use
> the Windows box. I=E2=80=99d like =E2=80=9Cls -l=E2=80=9D to work for eve=
ryone.

Sorry, I don't understand the problem, maybe because I'm looking at it
from the other side.

ls -l calls stat(2).  Stat(2) on NFS returns the uids and gids returned
by a stat(2) call on the NFS server.  ls -l then calls (basically)
getpwuid(3)/getgrgid(3) which in turn ask the account server via LDAP;
differently, depending on the server being AD or non-AD LDAP.

If there's no mapping from a uidNumber/gidNumber to a SID in AD, nor a
mapping from uidNumber/gidNumber to an account name ("uid" for users,
"cn" for groups) in LDAP, Cygwin will create a mapping in memory on the
fly.  Example:

  $ ls -l foo
  -rwxr-xr-x 1 Unix_User+4 Unix_Group+7 47456 Oct 30  2015 foo

So the fake account names are "Unix_User+<uid>" and "Unix_Group+<gid>"
The Cygwin uids/gids follow a certain computation rule (details don't
matter here) which is used for Samba accounts as well.  Ultimately
the in-memory passwd and group entries look like this:

  $ getent passwd Unix_User+4
  Unix_User+4:*:4278190084:4278190084:U-Unix_User\4,S-1-22-1-4:/:/sbin/nolo=
gin
  $ getent group Unix_Group+7
  Unix_Group+7:S-1-22-2-7:4278190087:

> It appears that cygwin generates SIDs for entries in /etc/passwd.

No, it generates the info on the fly in memory.  In fact, if there's
info in /etc/passwd or /etc/group, and if /etc/nsswitch.conf is set up
to actually _use_ these files (*), you can override the user name to
something more readable:

  $ echo 'MyUser:*:4278190084:4278190084:U-Unix_User\4,S-1-22-1-4:/:/sbin/n=
ologin' >> /etc/passwd
  $ echo 'MyGroup:S-1-22-2-7:4278190087:' >> /etc/group

  [exit from Cygwin terminal, start a new one]

  $ ls -l foo
  -rwxr-xr-x 1 MyUser MyGroup 47456 Oct 30  2015 foo

For the more exact details how to use /etc/nsswitch.conf and how the
mapping is performed, see

(*) https://cygwin.com/cygwin-ug-net/ntsec.html

> How can I make it do that for kid=E2=80=99s returned from LDAP? I=E2=80=
=99m willing to
> generate SIDs and put them in LDAP, but it doesn=E2=80=99t look like Cygw=
in is
> asking for a SID.

Well, it should.  What happens is this:  After asking the non-AD LDAP
server for the account name, it asks the account fetching algorithm for
that name from scratch.  This depends on the /etc/nsswitch.conf
settings, of course (*).  Assuming "passwd: files db", it first checks
the local /etc/passwd file for a matching entry for that account name,
then the OS, preferring AD on an AD member machine, then local SAM.

Does this help?


Corinna

--=20
Corinna Vinschen
Cygwin Maintainer

--e5bfZ/T2xnjpUIbw
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlw3h34ACgkQ9TYGna5E
T6A4kQ//YLTQ/Mac8xmERrLkdApKLCDJfFHgMri6GugTFs5YGqiL/jhx9cBhAInX
0HzDddVeXwvdI8Q/qF436hDmfFN0pERy1grTF9Ahen4CDD00dVMHgVwm6S//KJ01
L87bJdIQjrZtfu84cZHBkdPqiE8QjNVZC8NSccbAS7Il0d7bYIqRFSD+VagCjcU8
0wUO0KnOUpAPb7zsGE76OozXHFw/foC2I7ot1WVuabvtry7Sj+ZYlfYXgauHHLIe
jiR1oUuX3kCFbsV65q2j/VWhTZQXLFVHIoDQHubqQYfm51U8G98c8htBLBI32fbF
/+TT6Sn6QRlKXIftpS2GCzeNvfss8NE4YjYeQQ+ECOqotOI3ehWwJQ2Xa/cHuknL
MAZHSxsUrQCZFO6K/vuEQqPQGOyEz2LQxhhRdfgNYBe8rBlwhrWJAqOJdTlIq2on
ScS9gkzJmYI1qfxL2+4rhkQVpxNs4rClrIDm6197hEjOt8Jrf12eOT81V5kGoydI
nuYpvJ6OMP/6oOyPB5MHyXnDFpj8gwM9tsNpEOy66w/oQpnUN0AQXO9tTwMpPEBA
gg7R/17LfnljrMqpHacijVt9GJJCRpUZDpnn58v8M5O3LdMaSl1ruthBUmZ5fZvS
f1jde6FoCrbw0WNK42ncGgipTe2f2T2jXU80GpjeNbKxYY56K3w=
=eukR
-----END PGP SIGNATURE-----

--e5bfZ/T2xnjpUIbw--

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019