Mail Archives: cygwin/2004/05/18/22:44:45
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/
- Raw text -