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:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=pBmNh9s7afEVJUB0cxCE/zU3gLIwYCaYFGXX/0zal1ApEuqyqCELw
	VAC6d7Ii6Yv0wMotCKuukGfjhy7gWnWAegU0IimNcKvDTw2LViaHsqxaJNUSe5Xr
	BSCQY6FmfiuJRjN7Fm5UVTHr3zLLBvyzobCeaSeC6EUVf6VzDViiuo=
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:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=tT/mHY6vSQUKC2cYQ+Vav4+L73k=; b=xja3VdrNmmAZpDcQYycNU9+x2XG3
	EWMjt6V+Zr6TdORM26+z4fxyiEjUeJhXuq0rqDHQdgfk9/Pi9OmCOzqbLjeA5fu8
	7qnMHoH+g8tfYSukHrJ+KH9nDr6rBVQeOZpRDp/01eAdo9Rxk15YzfgIPAbC5x1U
	sSZ9cmSqpPu/ymA=
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-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-101.6 required=5.0 tests=AWL,BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=rights
X-HELO:	mout.kundenserver.de
Date:	Fri, 13 Apr 2018 14:29:59 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: [Bug] File permissions across domains
Message-ID:	<20180413122959.GB27440@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<874lkjt3dw DOT fsf AT Rainer DOT invalid> <20180411070312 DOT GK29703 AT calimero DOT vinschen DOT de> <20180411093443 DOT GM29703 AT calimero DOT vinschen DOT de> <87r2nlwtln DOT fsf AT Rainer DOT invalid> <20180412073805 DOT GS29703 AT calimero DOT vinschen DOT de> <87bmeo8cc7 DOT fsf AT Rainer DOT invalid>
MIME-Version:	1.0
In-Reply-To:	<87bmeo8cc7.fsf@Rainer.invalid>
User-Agent:	Mutt/1.9.2 (2017-12-15)
X-UI-Out-Filterresults:	notjunk:1;V01:K0:2tPqZ9sHQ6E=:owAhqx+5hX0MBa08U5FBXS 6oyTTtoKAVvOe1pDKc6oFFYPzGrYV2lk8PYBce4cRp2yLGU+/S/5AvFg8umjGj+R+7Fj8yT35 TdnVl2hHKza4EspSTiuZ1HKZ9tSPcZX1poeenFYAoCgjlwxUxSu+YkK6q9bmZFM/aLVurrWWF ApKOvGwb4p5lE9U8+9C1x8SxRgI4UQk/uqg66x6sxkO+G+GyqhVTPPi4zpvrETCgtInaMWnLq FqpPwucQ75lm1t+qro3FTiVQB18a1jsKHYq1oGm3q/BHiq/rkC3eN+ZNwdqEQvuepc0fnVuyI QyrnygjSNn2h3MV6kjGXfsYKjlaQcsUVsjZu2uS9NI068HwhAkuBuzA1u3exPm+BEa739NhFV BxK+4xAR17GRtBUjchaLK6JRxkTVPlNgAwgcDAyfBzc64J1kT6fH4+LNZwH7r3x5HfHRj6hke Pc9hV+27BXHzt40NSRWJQBFCm/wCJSyZEg0JcYmKnjftrg6L9OET82eJ8Xsb9qWQ88AuG9nEE /bOBdtZbwNnrMmgLZP/z4JGCkIZHNtNid4JXi8UbwSOBZvDRQvbdsEqAdG4KIus1VCmPw3cLu 9RD78Ctraiaw/qtER0Ud61XNFN3g0vCKMREZ47hGK7jmrQX2C83WsZlMBAa14ePxxbpwpAdr3 N5b3RpZmGB5pTECX4rWlsQx0++aTVyzAVDubg4XcTSwZfk/GPE2J4DapkJUDwxI4bscLFKNFt QBqqE9EISUrSUvfVbl3SYAXYjnwgvYeBlu7WtQ==

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

On Apr 12 21:16, Achim Gratz wrote:
> Corinna Vinschen writes:
> > I inspected the source code which handles this kind of thing.  What it
> > does is to ask Windows for permissions of SID X on file Y, using AuthZ.
>=20
> That seems to be working correctly.  For all old domain SID I've looked
> at, they've been prefixed by 0x7FFF0000 when seen by the new domain
> machine, so both the SID and conversion of uid/gid works correctly.  If
> it didn't I'd not be able to see my homedir and other stuff too.

That's not what I was talking about.  Of course the SIDs are correct,
but that has nothing to do with file permission evaluation.  AuthZ
is only doing the latter.

> > See sec_acl.cc, line 1127ff.  This calls a function
> > authz_get_user_attribute which in turn calls a method
> > authz_ctx::get_user_attribute, sec_helper.cc, line 811ff.
> >
> > This method checks if the owner of the file is the current user.  Given
> > this test is done using SIDs, not Cygwin uids, this should be you, *iff*
> > you're logged in as the same user on both machines at the time you
> > created the above output.  This in turn should create the Authz context
> > for the current user from the current process token and the subsequent
> > AuthzAccessCheck should give the same result on both machines.
>=20
> I've looked briefly at the source code, but I don't really see what's
> going on.

It's dirt easy:

1. fetch an AuthZ context for the current user from the current
   process token:

     AuthzInitializeContextFromToken

2. Ask AuthZ for the permissions on file Y:

     AuthzAccessCheck

authz_ctx::get_user_attribute is really only a few lines.

> While poking around, I noticed that the error/bug is far more
> specific than I thought:
>=20
> The merging of the access rights bestowed by access groups is working
> correctly if the file is not owned by the current user, but fails if
> it's owned by the current user.  I have a second account that I must use
> for doing anything administrative and it's also in the old domain.

Ok.  However, MSDN explicitely suggests to fetch the AuthZ context
from the current user token, if the idea is to ask for the permissions
of the current user.  It's much less costly than calling
AuthzInitializeContextFromSid.

Is your account an admin account by any chance?  If so, does it work if
you run in an elevated shell?

I'm reluctant to switch to AuthzInitializeContextFromSid all the time
for the reasons outlined above.

> > One reason could be that you're member of OLD+cygwinupload only on the
> > old machine, while this group is not in your current process token when
> > logged in on your NEW machine.  You should check your token.  In terms
> > of group membership an `id' call should suffice.  But there may be
> > other differences in the token.
>=20
> That all seems to be correct as far as I can tell.

I don't understand what you're trying to say here.  Are there
differences or not?

> > If that's not the problem, you will have to debug this, because
> > only you have access to this environment.
>=20
> Given the sheer size of the function I'd appreciate if you could point
> out on which line the decision is made whether the file is owned by me
> or not.

I pointed pretty much exactly at the lines in question.  The decision is
made in authz_ctx::get_user_attribute, as is the AuthZ call to ask for
the actual permissions, just two AuthZ calls and a mere 50 lines of
code.

Only if the owner SID is not the current user,
authz_ctx::get_user_attribute calls authz_ctx_cache::context, just
a few lines above, and also only about 30 lines of code.

Worst of all, there are comments!


Corinna

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

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

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

iQIyBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlrQoscACgkQ9TYGna5E
T6AmxQ/4m33JJ/GceV9zpHD+z0mGyLyltFsUZ421rccGAXYyE4RsH8gfnC2xuG3U
ityhzfwsk7ZYD3BLNGq2WqyxNgLDeeEpT9dQEffaby69HFJs9Bhb5Ut6duNgm/4f
aU3dqkcYwtPwQG7ncmBBO5mbat/dWCSxytfZ8cFKpMgeljds+zj9Wob1mZWSjDs3
EBu6NGEKBdZKYz45go8/dJUe8CXc5PQRCX8dlNx82SaLtSURyYmIdUoNvMA9y021
rc4TtS3bmO409aogMM1vFvcNTDxaQ6UBhDAy9wYgYXmimUFqnZ0rdiQEFhb6kxFb
r+6OH7E/iMtcAexGezJHkMIAuin0H6bFxsUUaIHjLzxnWm2GZYdIrwBt/PhqgObT
/lxvoOcxM8YgBwFYBfHT7BXa60hSdijof517OZ1NclfvzH5j7X5V1yhDKPirmNFP
pBlSzt7Y/KY+k0CDa8JOi21AKvrsw9gcib5Kb4XRev5+uAdkHcU08ybL+jpIInAh
FSUNZrahOVYIJTZKvwf+u5lmCBPhw5nEE5/0OE56S45GV/RRPW2AQRBin7YK02WJ
kvjZg1lnsXSKx+ZobiQ1ELGn28fZIfUlxPe4S6JBXnT8OSJF6Llvz5K8+xvqif/b
wnEQBcECDQcp8EA/JdT9jJBXyKyoZc+mez39cocscLgs5+ZGww==
=a+LH
-----END PGP SIGNATURE-----

--qcHopEYAB45HaUaB--

- Raw text -