Subject: Re: Issue with 'test' command and network shares on non-domain network
From: "Pierre A. Humblet" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Tue, 18 May 2004 22:41:20 -0400

On Tue, May 18, 2004 at 11:47:40PM +0100, [email-masked] wrote:
> Hello all,
> 
> I've been seeing a problem with permissions checks using v. 1.5.9 of 
> cygwin on network shares on machines which are not part of a domain with 
> smbntsec set,  any command that performs an explicit access check seems 
> to always think that access  is denied.
> 
> I'll pick the 'test' command as an example but it isn't the only command 
> that suffers the problem. I have the SIDs of the remote machine's users 
> and groups in /etc/passwd and /etc/group, so ls -l shows up meaningful 
> file owners and permissions etc. This means I have more than one user 
> SID mapped onto the same UID (which doesn't seem to bother cygwin). The 
> problem occurs with commands that do an explicit access check like 
> 'test' and 'rm', these all fail (e.g. rm always thinks files are write 
> protected), this is something that didn't use to happen in Cygwin 1.3 
> (ish). 
> 
> The way Cygwin performs access control checks seems to have changed over 
> the past year or two, I've been doing some digging and this is my 
> understanding of the problem: in older versions when cygwin wanted to 
> perform an permissions check, it used to stat the file, call 
> get_nt_attribute, and presumably calculate permissions mapping itself 
> using the mapped uid and gid in /etc/passwd and /etc/group, newer 
> versions call the win32 function _AccessCheck_ using the process token. 
> This is fine for the local machine or another machine on the same 
> domain, but doesn't work for machines with a "workgroup" type 
> relationship using network shares, because (as far as I can tell) this 
> requires a different user token (because I am "logged on" to the remote 
> machine via the share using a user on the remote machine) which appears 
> to be rather difficult to obtain. Previously this sort of functionality 
> could be made to work by filling in the remote machine's SIDs/UIDs in 
> the local /etc/passwd.
> 
> As a result of this 'test' gives misleading results and 'rm' complains 
> it can't delete a file you've just created because it thinks it is 
> write-protected. So for example although ls -l will accurately reflect 
> the executable bits set for a file, test -x will fail because of the 
> failed _AccessCheck_ call. So now it seems I will have to turn smbntsec 
> off to stop basic things like being able to delete a file that has just 
> been created from going wrong.
> 
> Is there anything that can be done to switch to old-style access checks, 
> or some way of making the new system work in a non-domain network 
> environment ?

It's correct that AccessCheck is now used in the implementation of the 
"access" system call (only). "access" is called by /bin/test and by the
built-in test in bash and sh, but not by rm nor by other common utilies, AFAIK.
You can verify that with "strace some_utility file | fgrep access".
If rm fails, something else must be going on.

Please try the following:
1) Create a remote file with smbntsec off
2) ls -l it
3) cacls it and the directory it's in
4) rm it
5) Recreate the same file with smbntsec on
6) ls -l it
7) cacls it
8) strace -o trace.txt rm it
Send us the outputs of 2, 3, 6, 7 as well as trace.txt, if you can't
explain what's going on.

Pierre

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/