CVS permissions problem with network drive

Corinna Vinschen cygwin@cygwin.com
Thu Dec 14 03:12:00 GMT 2000


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



More information about the Cygwin mailing list