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:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=uwZCYsxjZxJmkATforSAzPThMTP9aLVeprVz/az5NoQ5l2y80VJtB
	GQQP802sDz5Xu3dW6y9NbnNtSadzDl9fG+mydtaR1THMUmlRkSZtt+gyPs5qoTkc
	WBLa8BYHtNyAGLJgqwy36bRQ8kR8xvqCkS44ZytOhoD2NGTWxoddms=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Thu, 26 Nov 2015 14:30:12 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: No support for ACLs on network shares?
Message-ID: <20151126133012.GM2755@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <5652E58A DOT 2030605 AT codespunk DOT com> <89802969 DOT 20151123140802 AT yandex DOT ru> <56530687 DOT 3090905 AT codespunk DOT com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="PEkEgRdBLZYkpbX2"
Content-Disposition: inline
In-Reply-To: <56530687.3090905@codespunk.com>
User-Agent: Mutt/1.5.23 (2014-03-12)

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

On Nov 23 04:28, Matt D. wrote:
> Andrey,
>=20
> My samba server is configured to use winbind and when inspecting the file
> using explorer properties, the SIDs resolve correctly as:
>=20
> "NAME (HOSTNAME\username)"
>=20
> where "NAME" is my name on the unix account and "username" is my login.
>=20
> The problem is that Cygwin isn't aware of this SID since it's the user I =
log
> in as to the remove server and isn't a local SID.

I don't know why that occurs.  I'd have expected to see something like
UnixUser+number at least.  However, the above is not the situation you
use winbind for.  Winbind maps Windows user accounts to Unix accounts,
but in the above case it's a real Unix account, not one of the mappings
used by Winbind.

Your case is tricky.  Windows doesn't care for the account, unless
you open the security tab in the properties dialog.  In that case
Explorer knows the share it's looking up and so knows which server
to ask for the account information.  In Cygwin this works differently.
Given the current flow of information, the account functions in Cygwin
only get told something like "please return a passwd entry for SID
S-1-x-y-z".  The functions don't know in which scenario the request
is performed, so it only asks the local machine for the SID, and the
local machine only looks into its own SAM, or in an AD environment
it's DC.  If those don't know the account, Cygwin has to handle this
account as unknown.  ANother way to dereference an account is by
utilizing the user mapping per RFC 2307 as outlined in
https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-samba
The method described therein allows to map the Unix account to your
local Windows account, so from Cygwin's POV the files belong to your
Windows user.


Corinna

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

--PEkEgRdBLZYkpbX2
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWVwlkAAoJEPU2Bp2uRE+gynsQAJfTaUwcgMNjE53mpOrbFds+
BPFBkOwcpqWM5SvnZYoqyBeUaDWjpmtANFKj5NQS4YzveSCrJBBOMWFa/sUepPo6
xq0wh2/shLX59/f6VWMgVbz0mMo1sixVx6Xb6HfI1RfmktDEKPI9DtyT4V0b1GBT
ZQK0Z0KRttSnfh1Dv58FHFN9InrJnJES5RBm+cDLrtjjTix5x9lBlbxKMUf2MwDz
lrzgKF/xKqvF4Pw0gqlcrf9TdQMB8e9HfAvHbwj6LdE8BHZvqE4tC/igpD5mFWGE
10zTz4IfLcHQo4YIOxKoHBG8zH+IFNKxTSOh363NH392dDn3Shf4Rky0clnoLpD8
k6OQEydfXlURfEPi+3jCib5Vhv1YMV0ikfzIWJeNP2tN1+vYFkQFamjO/SyDb5LJ
A49QnvLiHrAaYE8e6P/PqpEiMKOj23jJsXM+wJtLXu3rgdcIwrTOrSKpgpsdMy9F
BxdZr7wRJH9HfCfmZk6adylk3xEgSqPxm2p59DAoAnBqnmqIgXAVHXGJjrAqkrUY
YlVL9jkpwwM4LRWTguIkPvAubQbJ9y8zxn7CgNwZu9+AGFxNJwScTHoOEqf9khbw
xZM55JQ4zIbhDwsGEG5bli4lYYA1xHfQ322Xj+8XqXum1Cddhrf5I1V0nl3zdvwm
gU7bBGCl0mm42XZogJmU
=O1Wn
-----END PGP SIGNATURE-----

--PEkEgRdBLZYkpbX2--