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: List-Subscribe: List-Archive: List-Post: List-Help: , 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 To: Charles Hedrick Cc: "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 , "cygwin AT cygwin DOT com" References: <0562D98D-714A-4620-878E-B37282E8F688 AT rutgers DOT 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) --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+" 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" -----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--