From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64213 invoked by alias); 10 Jan 2019 17:57:25 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 64203 invoked by uid 89); 10 Jan 2019 17:57:25 -0000 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 Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (212.227.17.13) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 10 Jan 2019 17:57:23 +0000 Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue106 [212.227.15.183]) with ESMTPSA (Nemesis) id 1M4Ja3-1ghNSo2rDN-000LYA; Thu, 10 Jan 2019 18:57:19 +0100 Received: by calimero.vinschen.de (Postfix, from userid 500) id A2A4CA806D1; Thu, 10 Jan 2019 18:57:18 +0100 (CET) Date: Thu, 10 Jan 2019 17:57:00 -0000 From: Corinna Vinschen To: Charles Hedrick Cc: "cygwin@cygwin.com" Subject: Re: user/group mapping for NFS Message-ID: <20190110175718.GN593@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: Charles Hedrick , "cygwin@cygwin.com" References: <0562D98D-714A-4620-878E-B37282E8F688@rutgers.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="e5bfZ/T2xnjpUIbw" Content-Disposition: inline In-Reply-To: <0562D98D-714A-4620-878E-B37282E8F688@rutgers.edu> User-Agent: Mutt/1.10.1 (2018-07-13) X-SW-Source: 2019-01/txt/msg00063.txt.bz2 --e5bfZ/T2xnjpUIbw Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 3205 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+" and "Unix_Group+" 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" Content-length: 833 -----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--