From mboxrd@z Thu Jan 1 00:00:00 1970 From: Corinna Vinschen To: cygwin Subject: Re: CVS permissions problem with network drive Date: Thu, 14 Dec 2000 03:12:00 -0000 Message-id: <00121412122502.24469@cygbert> References: <00121323361311.05746@cygbert> <3A387132.ABEF6CAD@ece.gatech.edu> X-SW-Source: 2000-12/msg00614.html On Thursday 14 December 2000 08:05, Charles Wilson wrote: > > Corinna Vinschen wrote: > > Could you please send me (to my personal account) straces of > > `touch foo' and `chmod 666 foo'? Gzipped would be nice. > > You are NOT going to believe this. I believe _everything_ while debugging a problem! ;-) Unfortunately I can only interpret what I see in the strace so I will ignore the permission difference for now. > $ id > uid=1000(cwilson) gid=513(None) groups=513(None) > $ umask > 002 > $ cd //belgarion/Common > $ strace touch foo > ~/touch_foo.txt > $ ls -l foo > -rw-rw-rw- 1 csw_belg None 0 Dec 14 01:54 foo Let's talk about that `touch'. I already wondered why the owner of the file isn't your account but an account on the SMB host. This is ok for Samba but this isn't what I expect on NT. I dived into the strace output and catched the following... the following... (come on now, don't bridle!) line: 5761 479925 [main] touch 1632 seterrno_from_win_error: /cygnus/netrel/src/cygwin-1.1.6-1/winsup/cygwin/security.cc:598 errno 1307 Errno 1307: "This security ID may not be assigned as the owner of this object." AFAICS this happens because you don't have appropriate permissions on the SMB host. I first thought that might be related to not being a member of the admins group on the client side but I tried it explicitly with a standard user account and everything went fine. Then I tried it the other way around, using an account on the SMB host which isn't member of the admins group. Now I could reproduce your effect. I then called `getfacl foo' to look into the ACL (seriously: I had to have another look into the security tab in explorer, too): > getfacl foo # file: foo # owner: 1004 <-- This is the host account! # group: 513 <-- while this is `None' of the client! user::--- <-- oh, the owner has no explicit permissions. user:1001:rw- <-- This is my client account (note the permissions) group::--- <-- The client `None' group group:513:r-- <-- The host `None' group group:545:rwx <-- host group `Users', permission inherited from the directory mask::--- other::r-- So the joke is, you _have_ the permissions you want but you're not the owner. And now each application which checks the permissions explicitly or tries to change the permissions will get a problem. > $ strace chmod 666 foo > ~/chmod_666_foo.txt > $ ls -l > -r--r--r-- 1 csw_belg None 0 Dec 14 01:57 foo The related strace shows the obvious. After being unable to set the correct owner you get a simple "Permission denied" error. Boring. Either add your host account to a well known group which has the `Take ownership' user right (only admins by default) or add that right to the group or *sigh* switch of ntsec when accessing SMB shares. This seems to be a general problem with ntsec. I fear I will have to add an option or some additional check code to ntsec. Thanks for playing my lab rat, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:cygwin@cygwin.com Red Hat, Inc. -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe@sourceware.cygnus.com