Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm 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 Date: Tue, 18 May 2004 22:41:20 -0400 From: "Pierre A. Humblet" To: cygwin AT cygwin DOT com Cc: cy DOT 20 DOT superconductor AT xoxy DOT net Subject: Re: Issue with 'test' command and network shares on non-domain network Message-ID: <20040519024120.GA695529@hpn5170x> Mail-Followup-To: "Pierre A. Humblet" , cygwin AT cygwin DOT com, cy DOT 20 DOT superconductor AT xoxy DOT net References: <40AA928C DOT 7040608 AT ntlworld DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40AA928C.7040608@ntlworld.com> User-Agent: Mutt/1.4.1i On Tue, May 18, 2004 at 11:47:40PM +0100, cy DOT 20 DOT superconductor AT xoxy DOT net 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/