Re: CVS permissions problem with network drive

Re: CVS permissions problem with network drive

[Charles Wilson]

I'm not sure how NTSEC/noNTSEC permissions and SAMBA interact.  My short
tests show that I can create and delete files and directories on a *SMB*
share (hosted on WinNT, not a SAMBA share hosted on linux/unix/etc).  

However, even in my tests, these files and directories are created
read-only, and chmod fails. (Yet I can still delete the
files/directories).

$ cd //host/share
$ umask
002

# FILES

$ touch foo
$ ld -l foo
-r--r--r--   1 1002     None            0 Dec 12 15:21 foo
$ chmod +w foo
chmod: foo: Permission denied
$ chmod 666 foo
chmod: foo: Permission denied
$ rm foo
$ ls -l foo
ls: foo: No such file or directory

# DIRECTORIES

$ mkdir foo
$ ls -ld foo
dr-xr-xr-x   1 1002     None            0 Dec 12 15:19 foo
$ chmod +w foo
chmod: foo: Permission denied
$ chmod 777 foo
chmod: foo: Permission denied
$ cd foo
$ touch bar
touch: bar: Permission denied
$ cd //host/share
$ rmdir foo
$ ls -l foo
ls: foo: No such file or directory

Since even in these simple cases, permissions and 'writeability' fails
on SMB shares, I am not surprised that CVS also fails on SMB shares.

Corinna, oh-expert-of-all-that-is-nt-security, can you shed some light
on this situation?  I've hunted around in the docs but can't seem to
find anything related to SMB, other than the symlink issue.

--Chuck


mbresnahan1@mmm.com wrote:
> 
> bash-2.04$ ls -ld /g/xapp/users/uscpw084/cvsroot
>    0 d---------   1 1772     None            0 Dec  8 16:26
> /g/xapp/users/uscpw084/cvsroot/
> bash-2.04$ ls -ld /g/xapp/users/uscpw084/cvsroot/CVSROOT
>    0 d---------   1 1772     None            0 Dec  8 16:11
> /g/xapp/users/uscpw084/cvsroot/CVSROOT/
> bash-2.04$ ls -ld /g/xapp/users/uscpw084/cvsroot/CVSROOT/
>    0 d---------   1 1772     None            0 Dec  8 16:11
> /g/xapp/users/uscpw084/cvsroot/CVSROOT//
> 
> Note that, using bash, I can cd to /g/xapp/users/uscpw084/cvsroot and
> create a directory there.  Bash doesn't think there is a permissions
> problem.  It's only CVS that has a problem as far as I've seen.
> 
> "Charles S. Wilson" <cwilson@ece.gatech.edu> on 12/08/2000 06:46:50 PM
> 
> To:   Mike J. Bresnahan/US-Corporate/3M/US@3M-Corporate
> cc:   cygwin@cygwin.com
> Subject:  Re: CVS permissions problem with network drive
> 
> Michael Bresnahan wrote:
> > bash-2.04$ /usr/bin/cvs.exe co OrderStatus
> > cvs.exe [checkout aborted]: /g/xapp/users/uscpw084/cvsroot/CVSROOT:
> > Permission denied
> >
> > I'm fairly sure I have the security setup correctly, because the direct
> > NT port of CVS does not have a problem accessing the repository.
> 
> Actually, this means very little.  There are differences in the way
> cygwin and NT(native) deal with SMB shares.  Please show:
> 
> ls -ld /g/xapp/users/uscpw084/cvsroot
> ls -ld /g/xapp/users/uscpw084/cvsroot/CVSROOT
> ls -ld /g/xapp/users/uscpw084/cvsroot/CVSROOT/
> 
> > The repository is on a HPUX 11 box
> 
> Oh, now hold on just a minute. So this isn't windows peer-to-peer file
> sharing.  Now, you've thrown SAMBA into the mix, which is ALSO different
> from NT(native) SMB, w.r.t. file permissions.
> 
> It looks to me as if your problem isn't CVS, but a misunderstanding as
> to how permissions on samba shares are dealt with from cygwin clients.
> Please search the archives..."samba" "permissions"
> 
> --Chuck

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: CVS permissions problem with network drive

[Corinna Vinschen]

On Tuesday 12 December 2000 21:29, Charles Wilson wrote:
> I'm not sure how NTSEC/noNTSEC permissions and SAMBA interact.  My
> short tests show that I can create and delete files and directories
> on a *SMB* share (hosted on WinNT, not a SAMBA share hosted on
> linux/unix/etc).

SAMBA supports access control lists but it doesn't support
creating files with your Windows identity of course. So
it uses the identity of the Linux user you used for logon.

> However, even in my tests, these files and directories are created
> read-only, and chmod fails. (Yet I can still delete the
> files/directories).
>
> $ cd //host/share
> $ umask
> 002
>
> # FILES
>
> $ touch foo
> $ ld -l foo
> -r--r--r--   1 1002     None            0 Dec 12 15:21 foo
> $ chmod +w foo
> chmod: foo: Permission denied
> $ chmod 666 foo
> chmod: foo: Permission denied
> $ rm foo
> $ ls -l foo
> ls: foo: No such file or directory
>
> # DIRECTORIES
>
> $ mkdir foo
> $ ls -ld foo
> dr-xr-xr-x   1 1002     None            0 Dec 12 15:19 foo
> $ chmod +w foo
> chmod: foo: Permission denied
> $ chmod 777 foo
> chmod: foo: Permission denied
> $ cd foo
> $ touch bar
> touch: bar: Permission denied
> $ cd //host/share
> $ rmdir foo
> $ ls -l foo
> ls: foo: No such file or directory
>
> Since even in these simple cases, permissions and 'writeability'
> fails on SMB shares, I am not surprised that CVS also fails on SMB
> shares.
>
> Corinna, oh-expert-of-all-that-is-nt-security, can you shed some
> light on this situation?

Chuck, I would really like to do this but it works for me.
If I only would know the difference between your and my system...

I tried the same scenario as you above. `cvaio' is a W2K box.

$ cd //cvaio/corinna
$ umask
2

# FILES

$ ls -l foo
-rw-rw-r--   1 corinna  root            0 Dec 13 09:52 foo
$ chmod 666 foo
$ ls -l foo
-rw-rw-rw-   1 corinna  root            0 Dec 13 09:52 foo

# DIRECTORIES

$ mkdir foo
$ ls -ld foo
drwxrwxr-x   1 corinna  root            0 Dec 13 09:53 foo
$ chmod 777 foo
$ ls -ld foo
drwxrwxrwx   1 corinna  root            0 Dec 13 09:53 foo
$ cd foo
$ pwd
//corinna/corinna/foo

So far the Windows SMB tests. Let's have a look to Samba now.

The same as above but on a Samba share. `cygbert' is a Linux box
running Samba 2.0.7

$ cd //cygbert/corinna

# FILES

$ touch foo
$ ls -l foo
-rw-r--r--   1 2000     1201            0 Dec 13 09:58 foo
/cygbert/corinna[59]$ chmod 666 foo
chmod: foo: Permission denied
/cygbert/corinna[60]$ ls -l foo
-rw-r--r--   1 2000     1201            0 Dec 13 09:58 foo

Ok, let's forget the directories here. Why does `chmod' fail
on the Samba share? You see the missing names in the `ls -l'
output? Ok, the reason is that the user and group ids are
not mentioned in your /etc/passwd. What's the meaning of
`2000' and `1201' here? Samba creates SIDs from UIDs and GIDs
by using it's own system SID (created when smbd is started for
the first time) and computing the RID as follows:

	users-RID = 1000 + 2 * Linux-UID
	group-RID = 1001 + 2 * Linux-GID

In the above example 2000 means UID=500 (1000 + 2 * 500 = 2000)
and 1201 means GID 100 (1001 + 2 * 100 = 1201)

You can avoid the above `Permission denied' problem by adding
the Linux user and group to /etc/passwd and /etc/group:

Next obvious question: Where to get the SID of my Linux box???
Answer: locate `MACHINE.SID'.

In my example:

/etc/passwd:
cv_cyg::2000:1201:Corinna on Cygbert,S-1-5-21-2995888091-1469122872-890212507-2000:/e:/bin/tcsh

/etc/group:
user_cyg:S-1-5-21-2995888091-1469122872-890212507-1201:1201:

Which results in the following change when trying the above
example again:

$ touch foo
$ ls -l foo
-rw-r--r--   1 cv_cyg   user_cyg        0 Dec 13 11:09 foo
$ chmod 666 foo
$ ls -l foo
-rw-rw-rw-   1 cv_cyg   user_cyg        0 Dec 13 11:09 foo

BUT: Don't expect to be able to use all permission variations on
a Samba share. For some reason Samba changes the permission bits
silently to a "useful" (from it's own point of view) combination.
Example:

$ chmod 702 foo
$ ls -l foo
-rwxrw-rw-   1 cv_cyg   user_cyg        0 Dec 13 11:09 foo

Weird, isn't it? In brief:
- No write and exec permissions without read permissions.
- User permissions >= group permissions >= world permissions.

Hope, that helps,
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

Re: CVS permissions problem with network drive

[Charles Wilson]

Corinna Vinschen wrote:
> 
> Chuck, I would really like to do this but it works for me.
> If I only would know the difference between your and my system...

One difference is that the 'cwilson' user has different UID's on the
local and remote system (1000 on local, 1002 on remote).  After adding
this line to my local /etc/passwd (ignore linewrapping):

csw_belg::1002:513:Charles Wilson on
Belgarion,S-1-5-21-144006512-467950226-1660491571-1002://belgarion/ehlana/Users/cwilson:/bin/bash

Now, at least, ls on the remote system shows 'csw_belg' as owner -- of
the NEW file -- instead of '1002'.  I notice that your (Corinna's)
username on your remote system is 'corinna' -- just as it is 'corinna'
on your local system -- is that because your UID is the same on both
systems?  Could that difference cause the disparity in our results? 
(Also, I notice that 'corinna' is a member of the 'root'
(Administrators?) group on the remote system).

$ cd //belgarion/Common
$ umask
002
$ id
uid=1000(cwilson) gid=513(None) groups=513(None)

# FILES (corinna's answers also listed below)

$ touch foo
$ ls -l foo
    -r--r--r--   1 csw_belg None            0 Dec 13 13:43 foo
### -rw-rw-r--   1 corinna  root            0 Dec 13 09:52 foo

$ chmod 666 foo
chmod: foo: Permission denied
$ ls -l foo
    -r--r--r--   1 csw_belg None            0 Dec 13 13:43 foo
### -rw-rw-rw-   1 corinna  root            0 Dec 13 09:52 foo

--Chuck

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: CVS permissions problem with network drive

[Corinna Vinschen]

On Wednesday 13 December 2000 19:52, Charles Wilson wrote:
> One difference is that the 'cwilson' user has different UID's on the
> local and remote system (1000 on local, 1002 on remote).  After
> adding this line to my local /etc/passwd (ignore linewrapping):
>
> csw_belg::1002:513:Charles Wilson on
> Belgarion,S-1-5-21-144006512-467950226-1660491571-1002://belgarion/eh
>lana/Users/cwilson:/bin/bash
>
> Now, at least, ls on the remote system shows 'csw_belg' as owner --
> of the NEW file -- instead of '1002'.  I notice that your (Corinna's)
> username on your remote system is 'corinna' -- just as it is
> 'corinna' on your local system -- is that because your UID is the
> same on both systems?  Could that difference cause the disparity in
> our results? (Also, I notice that 'corinna' is a member of the 'root'
> (Administrators?) group on the remote system).

Yes, I changed my passwd and group files so that in /etc/passwd
`Adminstrator' (RID 500) is mapped to `root' (UID 0) and in
/etc/group `Adminstrators' (S-1-5-32-544) is mapped to `root' (GID 0).
My `corinna' user entry in /etc/passwd contains contains GID 0 as
well, so I'm member of the `root' group in Cygwin (and member of
the `Administrators' group in NT of course, too). I did this on
both systems for convenience.

However, this shouldn't result in the different behaviour.
The usernames are identical but the RIDs on both systems are
different (1000 and 1003). A `ls -l' on an already existing file
shows according to that:

$ cd //cvaio/corinna
$ ls -l x.c
-rw-rw-r--   1 1003     root         1132 Nov  7 16:55 x.c

while the touch uses the correct SID of the source system:

$ touch foo
$ ls -l foo
-rw-rw-r--   1 corinna  root            0 Dec 13 23:27 foo

Could you please send me (to my personal account) straces of
`touch foo' and `chmod 666 foo'? Gzipped would be nice.

Would you mind to use a special test DLL later, potentially?
Perhaps the current trace output isn't sufficient to find the
reason.

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

Re: CVS permissions problem with network drive

[Charles Wilson]

[-- Attachment #1: Type: text/plain, Size: 1137 bytes --]

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.

$ 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

## when using strace, the file is created with permission=666

$ rm foo
$ touch foo
$ ls -l foo
-r--r--r--   1 csw_belg None            0 Dec 14 01:57 foo

## without strace, the file is created with permission=444
## neither one is the correct value, 664, according to my umask.

$ strace chmod 666 foo > ~/chmod_666_foo.txt
$ ls -l
-r--r--r--   1 csw_belg None            0 Dec 14 01:57 foo

touch_foo.txt, chmod_666_foo.txt, and cygcheck.txt are tar.gz'ed and
attached.

> Would you mind to use a special test DLL later, potentially?
> Perhaps the current trace output isn't sufficient to find the
> reason.

Sure, no problem.

--Chuck
corinna.tar.gz
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com


[-- Attachment #2: corinna.tar.gz --]
[-- Type: application/x-gzip, Size: 19162 bytes --]

Re: CVS permissions problem with network drive

[Corinna Vinschen]

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

Re: CVS permissions problem with network drive

[Charles S. Wilson]

Corinna Vinschen wrote:
> 
> 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.

Hmmm...

The host account 'cwilson' is a member of 'Power Users', so I added
'Take Ownership' user right to that group.  Then, I logged off/on on the
host machine, and logged off/on on the client machine.

no change in behavior -- still '-r--r--r--'.

Then, I added 'cwilson' on the host machine to the host's Administrators
group.  logon/logoff on host/client.  

works. '-rw-rw-r--'.

It appears that 'Take Ownership' is not sufficient.  What other rights
are being used -- because I'd rather not add my host account to the
Administrators group on a permanent basis.

> 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,

No problem.

--Chuck

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: CVS permissions problem with network drive

[Corinna Vinschen]

On Thursday 14 December 2000 17:32, Charles S. Wilson wrote:
> It appears that 'Take Ownership' is not sufficient.  What other
> rights are being used -- because I'd rather not add my host account
> to the Administrators group on a permanent basis.

If that doesn't work for you, I don't know. I haven't checked each
single user right. I think there's no provision made in the NT concept
to provide this functionality on a general base. The special feature
for getting what you want is provided by the domain concept eventually.
So, if you boxes are part of a domain and your user account is a
domain account, this will work for sure.

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

Re: CVS permissions problem with network drive

[Charles S. Wilson]

Corinna Vinschen wrote:
> 
> On Thursday 14 December 2000 17:32, Charles S. Wilson wrote:
> > It appears that 'Take Ownership' is not sufficient.  What other
> > rights are being used -- because I'd rather not add my host account
> > to the Administrators group on a permanent basis.
> 
> If that doesn't work for you, I don't know. I haven't checked each
> single user right. I think there's no provision made in the NT concept
> to provide this functionality on a general base. The special feature
> for getting what you want is provided by the domain concept eventually.
> So, if you boxes are part of a domain and your user account is a
> domain account, this will work for sure.

The necessary right appears to be "Restore Files and Directories"
(SeRestorePrivilege).  At least the following did not work:

host user cwilson: member of 'Power Users', no additional rights
  but this DID work:
host user cwilson: membero of 'Power Users' + SeRestorePrivilege.

(It's possible the necessary rights are SeRestorePrivilege + the rights
granted by Power User status, as opposed to normal User).

So: In order to access a CVS repository on an SMB share exported by an
NT host, the user's account on the host must have the SeRestorePrivilege
right.  However, this is dangerous:

The holder of this right is permitted to circumvent NTFS file- and
directory-level access permissions to restore any files on the computer.
It also permits the users to restore NTFS security attributes, including
the file's owner information. Note that utilities such as SCOPY also
take advantage of this capability and can be used to circumvent security
policy. Assign this right with caution.

--Chuck

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: CVS permissions problem with network drive

[Charles S. Wilson]

"Charles S. Wilson" wrote:
> 
> The necessary right appears to be "Restore Files and Directories"
> (SeRestorePrivilege).  At least the following did not work:
> 
> host user cwilson: member of 'Power Users', no additional rights
>   but this DID work:
> host user cwilson: membero of 'Power Users' + SeRestorePrivilege.
> 
> (It's possible the necessary rights are SeRestorePrivilege + the rights
> granted by Power User status, as opposed to normal User).
>

Dadgummit.  Looks like I spoke too soon.  It is true that the preceeding
combination of rights will allow 'touch foo' to create a file with the
desired permissions (umask = 002 ---> -rw-rw-r-- foo) but I'm still
prevented from THEN doing a 'chmod 777 foo'.
 
> So: In order to access a CVS repository on an SMB share exported by an
> NT host, the user's account on the host must have the SeRestorePrivilege
> right.  However, this is dangerous:

This is bull.  Ignore.

--Chuck

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: CVS permissions problem with network drive

[Corinna Vinschen]

On Sunday 17 December 2000 09:16, Charles S. Wilson wrote:
> "Charles S. Wilson" wrote:
> > The necessary right appears to be "Restore Files and Directories"
> > (SeRestorePrivilege).  At least the following did not work:
> >
> > host user cwilson: member of 'Power Users', no additional rights
> >   but this DID work:
> > host user cwilson: membero of 'Power Users' + SeRestorePrivilege.
> >
> > (It's possible the necessary rights are SeRestorePrivilege + the
> > rights granted by Power User status, as opposed to normal User).
>
> Dadgummit.  Looks like I spoke too soon.  It is true that the
> preceeding combination of rights will allow 'touch foo' to create a
> file with the desired permissions (umask = 002 ---> -rw-rw-r-- foo)
> but I'm still prevented from THEN doing a 'chmod 777 foo'.
>
> > So: In order to access a CVS repository on an SMB share exported by
> > an NT host, the user's account on the host must have the
> > SeRestorePrivilege right.  However, this is dangerous:
>
> This is bull.  Ignore.

No, this isn't bull! You are right. You only did it the half way.

If _both_ accounts (your local account and the remote account used
for the SMB connection) have the SeRestorePrivilge user right everything
works as expected.

Thanks for the hint, Chuck.

However, giving this permission remains dangerous for the reasons you
explained in your previous mail. So the correct way in terms of NT
security is still using domains and domain accounts.

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

Re: CVS permissions problem with network drive

[Charles S. Wilson]

Corinna Vinschen wrote:

> > > So: In order to access a CVS repository on an SMB share exported by
> > > an NT host, the user's account on the host must have the
> > > SeRestorePrivilege right.  However, this is dangerous:
> >
> > This is bull.  Ignore.
> 
> No, this isn't bull! You are right. You only did it the half way.
> 
> If _both_ accounts (your local account and the remote account used
> for the SMB connection) have the SeRestorePrivilge user right everything
> works as expected.

Confirmed.

> 
> Thanks for the hint, Chuck.
> 
> However, giving this permission remains dangerous for the reasons you
> explained in your previous mail. So the correct way in terms of NT
> security is still using domains and domain accounts.

Well, in my case, the 'correct way' is not possible -- I don't have a
domain or domain controller.  Just a W2K machine and an NT Workstation,
both members of the same Workgroup.

So, there are three possibilities:

1) Use domains and domain user accounts
2) turn off ntsec
3) add 'SeRestorePrivilege' to both the client machine user account and
the host machine user account.  This is dangerous because it basically
eliminates all file security on both machines, as far as that user is
concerned.  And, this extends to NON-cygwin programs run by that user.  

If #1 is not possible, then #2 is better than #3 (what's the point of
maintaining the *form* of ntsec when it has no *function*?  #3 vitiates
all file security anyway, so why bother with ntsec?)  If you set
nontsec, you lose unixish file security for cygwin programs but at least
you keep the Windows security intact (such as it is).

Unfortunately, both #2 and #3 affect behavior both locally and on file
shares.  It would be nice if ntsec behaved 'nontsec'-like when accessing
shares when the user accounts involved are not domain accounts.  That
way, I could continue to use ntsec for most stuff (local file access)
but share access 'just works' with less strict file security.  Does that
describe the 'extra checks' you said you needed to add, Corinna?

--Chuck

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: CVS permissions problem with network drive

[Corinna Vinschen]

On Sunday 17 December 2000 20:45, Charles S. Wilson wrote:
> It would be nice if ntsec behaved 'nontsec'-like when
> accessing shares when the user accounts involved are not domain
> accounts.  That way, I could continue to use ntsec for most stuff
> (local file access) but share access 'just works' with less strict
> file security.  Does that describe the 'extra checks' you said you
> needed to add, Corinna?

You got it. Unfortunately, I have no idea how to do this check
whether someone is a domain user with reasonable cost.

Currently I would prefer a simple check to ignore SMB mounts
completely which results in the typical faked permissions as
on FAT partitions. This could be controlled by an additional
CYGWIN flag, perhaps.

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

Re: CVS permissions problem with network drive

[Charles S. Wilson]

Corinna Vinschen wrote:
> 
> Currently I would prefer a simple check to ignore SMB mounts
> completely which results in the typical faked permissions as
> on FAT partitions. This could be controlled by an additional
> CYGWIN flag, perhaps.

Sounds reasonable to me.  CYGWIN=smbfakeperm ?  CYGWIN=nodomain ?

--Chuck

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: CVS permissions problem with network drive

[Robert Collins]

----- Original Message ----- 
From: "Charles S. Wilson" <cwilson@ece.gatech.edu>
To: "Corinna Vinschen" <cygwin@cygwin.com>
> Corinna Vinschen wrote:
> > 
> 
> Sounds reasonable to me.  CYGWIN=smbfakeperm ?  CYGWIN=nodomain ?
> 

CYGWIN=SMBisBroken ?


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: CVS permissions problem with network drive

[Christopher Faylor]

On Tue, Dec 19, 2000 at 03:08:45PM +1300, Robert Collins wrote:
>----- Original Message ----- 
>From: "Charles S. Wilson" <cwilson@ece.gatech.edu>
>To: "Corinna Vinschen" <cygwin@cygwin.com>
>> Corinna Vinschen wrote:
>> > 
>> 
>> Sounds reasonable to me.  CYGWIN=smbfakeperm ?  CYGWIN=nodomain ?
>> 
>
>CYGWIN=SMBisBroken ?

CYGWIN=ilikepie ?

Nah.  Too much of a possibility of misinterpretation.

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: CVS permissions problem with network drive

[Corinna Vinschen]

On Tuesday 19 December 2000 03:42, Christopher Faylor wrote:
> On Tue, Dec 19, 2000 at 03:08:45PM +1300, Robert Collins wrote:
> >----- Original Message -----
> >From: "Charles S. Wilson" <cwilson@ece.gatech.edu>
> >To: "Corinna Vinschen" <cygwin@cygwin.com>
> >
> >> Corinna Vinschen wrote:
> >>
> >>
> >> Sounds reasonable to me.  CYGWIN=smbfakeperm ?  CYGWIN=nodomain ?
> >
> >CYGWIN=SMBisBroken ?
>
> CYGWIN=ilikepie ?
>
> Nah.  Too much of a possibility of misinterpretation.

I know, this is somewhat dry but I have decided to use [no]smbntsec.

What I'm curious about is what do you think should be the default?
Personally I would prefer to have smbntsec off by default but to
have it on by default would match the current behaviour.

Opinions?

Corinna


-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: CVS permissions problem with network drive

[Christopher Faylor]

On Tue, Dec 19, 2000 at 01:52:33PM +0100, Corinna Vinschen wrote:
>On Tuesday 19 December 2000 03:42, Christopher Faylor wrote:
>> On Tue, Dec 19, 2000 at 03:08:45PM +1300, Robert Collins wrote:
>> >----- Original Message -----
>> >From: "Charles S. Wilson" <cwilson@ece.gatech.edu>
>> >To: "Corinna Vinschen" <cygwin@cygwin.com>
>> >
>> >> Corinna Vinschen wrote:
>> >>
>> >>
>> >> Sounds reasonable to me.  CYGWIN=smbfakeperm ?  CYGWIN=nodomain ?
>> >
>> >CYGWIN=SMBisBroken ?
>>
>> CYGWIN=ilikepie ?
>>
>> Nah.  Too much of a possibility of misinterpretation.
>
>I know, this is somewhat dry but I have decided to use [no]smbntsec.
>
>What I'm curious about is what do you think should be the default?
>Personally I would prefer to have smbntsec off by default but to
>have it on by default would match the current behaviour.
>
>Opinions?

Actually, shouldn't this be a mount option rather than a cygwin setting?
In fact, maybe a

mount -n c:\foo /foo	# use NTSEC semantics

would be sort of nice.

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: CVS permissions problem with network drive

[Charles S. Wilson]

Christopher Faylor wrote:
> 
> Actually, shouldn't this be a mount option rather than a cygwin setting?
> In fact, maybe a
> 
> mount -n c:\foo /foo    # use NTSEC semantics
> 
> would be sort of nice.

Yes, it would.  But, how would 

cp foo //bar/baz

be hamdled?  Besides, this is something you'd configure one way or the
other for all SMB shares -- either you're a domain user or you're not. 
So, it probably shouldn't be set on a per-share or per-mount basis, but
rather it should be set globally for a particular user/installation.  

--Chuck

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: CVS permissions problem with network drive

[Christopher Faylor]

On Tue, Dec 19, 2000 at 11:47:25AM -0500, Charles S. Wilson wrote:
>Christopher Faylor wrote:
>>Actually, shouldn't this be a mount option rather than a cygwin
>>setting?  In fact, maybe a
>>
>>mount -n c:\foo /foo    # use NTSEC semantics
>>
>>would be sort of nice.
>
>Yes, it would.  But, how would
>
>cp foo //bar/baz
>
>be handled?

It would use the default or we could still use a CYGWIN environment
variable.

I just tried doing a 'mount //foo/bar //foo/bar' but that didn't work.

>Besides, this is something you'd configure one way or the other for all
>SMB shares -- either you're a domain user or you're not.  So, it
>probably shouldn't be set on a per-share or per-mount basis, but rather
>it should be set globally for a particular user/installation.

Isn't it possible that you could have different shares mounted from
different systems with different requirements?  That's why I was
suggesting a mount option.

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: CVS permissions problem with network drive

[Corinna Vinschen]

On Tuesday 19 December 2000 18:28, Christopher Faylor wrote:
> On Tue, Dec 19, 2000 at 11:47:25AM -0500, Charles S. Wilson wrote:
> >Christopher Faylor wrote:
> >>Actually, shouldn't this be a mount option rather than a cygwin
> >>setting?  In fact, maybe a
> >>
> >>mount -n c:\foo /foo    # use NTSEC semantics
> >>
> >>would be sort of nice.
> >
> >Yes, it would.  But, how would
> >
> >cp foo //bar/baz
> >
> >be handled?
>
> It would use the default or we could still use a CYGWIN environment
> variable.
>
> I just tried doing a 'mount //foo/bar //foo/bar' but that didn't
> work.
>
> >Besides, this is something you'd configure one way or the other for
> > all SMB shares -- either you're a domain user or you're not.  So,
> > it probably shouldn't be set on a per-share or per-mount basis, but
> > rather it should be set globally for a particular
> > user/installation.
>
> Isn't it possible that you could have different shares mounted from
> different systems with different requirements?  That's why I was
> suggesting a mount option.

That's a point. Nevertheless I will check in the global [no]smbntsec
option solution now. It's simple enough so that a later enhancement
using a mount option isn't hard at all.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

RE: CVS permissions problem with network drive

[Andrew Dalgleish]

> -----Original Message-----
> From: Corinna Vinschen [ mailto:cygwin@cygwin.com ]
> Sent: Wednesday, 20 December 2000 06:47
> To: cygwin@cygwin.com
> Subject: Re: CVS permissions problem with network drive

> That's a point. Nevertheless I will check in the global [no]smbntsec
> option solution now. It's simple enough so that a later enhancement
> using a mount option isn't hard at all.

On WinNT, Win2k you can test if the user is logged into a domain by
checking the environment.
I expect I will probably add something like this to my startup batch
file.
if "%COMPUTERNAME%"=="%USERDOMAIN%" set CYGWIN=%CYGWIN% [no]smbntsec

I normally do use a domain, but occasionally I do refer to non-domain
mounts.
It is rare enough that I don't think permissions would be an issue for
me,
but a mount option sounds nice.

Regards,
Andrew Dalgleish

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: CVS permissions problem with network drive

[Corinna Vinschen]

On Tuesday 19 December 2000 17:03, Larry Hall (RFK Partners, Inc) wrote:
> At 09:12 AM 12/19/2000, Earnie Boyd wrote:
> >On by default would be less confusing.
>
> I would have assumed off would generate less confusion since that
> should "just work", where on requires special configuration.  If
> that's the case, I'd vote for off by default, with the only goal
> being to keep list traffic to a minimum on this subject.  Of course,
> we won't know if that goal is actually met until after the change is
> made and a default selected!;-)

Correct. You'll never know beforehand...

> Here's another question.  Should the outcome of this option be
> decided by a popular vote or an electoral?  Ugh!;-)

Just trying to give the impression of democracy ;-)

I think Earnie is right. I will check it in now with smbntsec=on
by default.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: CVS permissions problem with network drive

[Larry Hall (RFK Partners, Inc)]

At 09:12 AM 12/19/2000, Earnie Boyd wrote:
> > What I'm curious about is what do you think should be the default?
> > Personally I would prefer to have smbntsec off by default but to
> > have it on by default would match the current behaviour.
> > 
> > Opinions?
> > 
>
>On by default would be less confusing.
>
>Cheers,
>
>=====
>Earnie Boyd


I would have assumed off would generate less confusion since that should 
"just work", where on requires special configuration.  If that's the case,
I'd vote for off by default, with the only goal being to keep list traffic
to a minimum on this subject.  Of course, we won't know if that goal is 
actually met until after the change is made and a default selected!;-)

Here's another question.  Should the outcome of this option be decided by
a popular vote or an electoral?  Ugh!;-)


Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: CVS permissions problem with network drive

[Earnie Boyd]

--- Corinna Vinschen <cygwin@cygwin.com> wrote:
> On Tuesday 19 December 2000 03:42, Christopher Faylor wrote:
> > On Tue, Dec 19, 2000 at 03:08:45PM +1300, Robert Collins wrote:
> > >----- Original Message -----
> > >From: "Charles S. Wilson" <cwilson@ece.gatech.edu>
> > >To: "Corinna Vinschen" <cygwin@cygwin.com>
> > >
> > >> Corinna Vinschen wrote:
> > >>
> > >>
> > >> Sounds reasonable to me.  CYGWIN=smbfakeperm ?  CYGWIN=nodomain ?
> > >
> > >CYGWIN=SMBisBroken ?
> >
> > CYGWIN=ilikepie ?
> >
> > Nah.  Too much of a possibility of misinterpretation.
> 
> I know, this is somewhat dry but I have decided to use [no]smbntsec.
> 

How about [no]ntsec=smb.  I would then do `CYGWIN=ntsec nontsec=smb'.  This
makes more sense to me.

> What I'm curious about is what do you think should be the default?
> Personally I would prefer to have smbntsec off by default but to
> have it on by default would match the current behaviour.
> 
> Opinions?
> 

On by default would be less confusing.

Cheers,

=====
Earnie Boyd
mailto:earnie_boyd@yahoo.com

---         < http://earniesystems.safeshopper.com >         ---
--- Cygwin: POSIX on Windows < http://gw32.freeyellow.com/ > ---
---   Minimalist GNU for Windows < http://www.mingw.org/ >   ---

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: CVS permissions problem with network drive

[Charles S. Wilson]

Michael Bresnahan wrote:
> bash-2.04$ /usr/bin/cvs.exe co OrderStatus
> cvs.exe [checkout aborted]: /g/xapp/users/uscpw084/cvsroot/CVSROOT:
> Permission denied
> 
> I'm fairly sure I have the security setup correctly, because the direct
> NT port of CVS does not have a problem accessing the repository.

Actually, this means very little.  There are differences in the way
cygwin and NT(native) deal with SMB shares.  Please show:

ls -ld /g/xapp/users/uscpw084/cvsroot
ls -ld /g/xapp/users/uscpw084/cvsroot/CVSROOT
ls -ld /g/xapp/users/uscpw084/cvsroot/CVSROOT/

> The repository is on a HPUX 11 box 

Oh, now hold on just a minute. So this isn't windows peer-to-peer file
sharing.  Now, you've thrown SAMBA into the mix, which is ALSO different
from NT(native) SMB, w.r.t. file permissions.

It looks to me as if your problem isn't CVS, but a misunderstanding as
to how permissions on samba shares are dealt with from cygwin clients. 
Please search the archives..."samba" "permissions"

--Chuck

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

CVS permissions problem with network drive

[Michael Bresnahan]

I am having a permissions problem with CVS when the repository is on a
network drive.  I recieve the following diagnostics:

bash-2.04$ /usr/bin/cvs.exe co OrderStatus
cvs.exe [checkout aborted]: /g/xapp/users/uscpw084/cvsroot/CVSROOT:
Permission denied

I'm fairly sure I have the security setup correctly, because the direct
NT port of CVS does not have a problem accessing the repository.

The repository is on a HPUX 11 box and is mounted onto the G: drive of
NT box via the "Map network drive" feature of NT Explorer.  The G: drive
is then mounted inside cygwin as /g.

I am using:
    cvs 1.11
    NT 4.0sp4

Any help would be greatly apprieciated.

Mike Bresnahan



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com