Re: post b20.1: How to disable umask and access UNC path

Re: post b20.1: How to disable umask and access UNC path

[Earnie Boyd]

--- igoresha@iwmail.com wrote:
> But should NT Security support be off by default?

It will be when the b21 product becomes available.  The snapshots have it on by
default so that it will get tested.

> And in any case does the fact that new code does not work accross network
> should be considered as a bug?
> I.e. if I make a new file of a different computer it
> should be created under the ownership of the account under which I connected
> to that computer and not the account under which I logged in localy.
> 

Hmm.  How are you connecting to a different computer to create the file?  Is
that via the "Map Drive" function?  Couldn't that be considered an "NFS
mounted" directory in unix?  Files created via NFS mounts have the properties
of the user for that host not the host and owner of the filesystem.

Note, these questions are hypothetical and have nothing to do with the real
code.  In reality I don't know the answer to the question.
===
Earnie Boyd < mailto:earnie_boyd@yahoo.com >

Newbies, please visit
< http://www.freeyellow.com/members5/gw32/index.html >

(If you respond to the list, then please don't cc me)
_________________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com


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

Re: post b20.1: How to disable umask and access UNC path

[Earnie Boyd]

--- igoresha@iwmail.com wrote:
> But should NT Security support be off by default?

It will be when the b21 product becomes available.  The snapshots have it on by
default so that it will get tested.

> And in any case does the fact that new code does not work accross network
> should be considered as a bug?
> I.e. if I make a new file of a different computer it
> should be created under the ownership of the account under which I connected
> to that computer and not the account under which I logged in localy.
> 

Hmm.  How are you connecting to a different computer to create the file?  Is
that via the "Map Drive" function?  Couldn't that be considered an "NFS
mounted" directory in unix?  Files created via NFS mounts have the properties
of the user for that host not the host and owner of the filesystem.

Note, these questions are hypothetical and have nothing to do with the real
code.  In reality I don't know the answer to the question.
===
Earnie Boyd < mailto:earnie_boyd@yahoo.com >

Newbies, please visit
< http://www.freeyellow.com/members5/gw32/index.html >

(If you respond to the list, then please don't cc me)
_________________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com


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

Re: post b20.1: How to disable umask and access UNC path

[Earnie Boyd]

To use this dll without the new NT Security coding SET CYGWIN=nontsec ...

Earnie

--- igoresha@iwmail.com wrote:
> Hello!
> 
> I played with a recent (1999.08.03) coolview binaries from Sergey Okhapkin
> which, I suppose, contain latest cygwin1.dll and have found that umask
> finally works.
> Unfortunately permitions it uses on new files are not suitable for me and I
> wish to disable the new umask support. The reason:
> I use cygwin on NT workstation that is not a domain member where I am member
> of Administrator group and often I access files on another coputer which 
> is a domain member and where I am NOT an administrator. I have the same
> account name and password so it is not a problem to access
> //domain-mmeber/share
> but then with umask 007 after 
> cd //domain-mmeber/share
> touch x
> I have the following permitions for x:
> Account Unknown: Special Access(RWDPO)
> <domain-name>\Administrators: Special Access(RWDPO)
> Everyone: Special Access ()
> System: Full Control
> 
> I do not like that "Account Unknown:"
> and second I do not like to have 
> "System: Full Control" by default.
> 
> It also missed a backup group from the parent directory
> so new files will not be backuped (which IMHO is just an unaceptable change).
> 
> So how can I return to the parent directory permition 
> inheritance in a post b20.1 world?
> 
> Also, what is a right way to access UNC path under new 
> /cygdrive procedure?
> I tried 
> /cygdrive/host/share
> /cygdrive//host/share
> but it seems that only old
> //host/share
> works.
> 
> Regards, Igor Boukanov
> 
> PS. My CYGWIN is
> tty noglob binmode
> 
> 
> 
> 
> 
> -----------------------------------------------------
> Get free email from CMP at http://www.cmpnetmail.com/
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> 
> 

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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

Re: post b20.1: How to disable umask and access UNC path

[Corinna Vinschen]

igoresha@iwmail.com wrote:
> [...]
> And in any case does the fact that new code does not work accross network should be considered as a bug?
> I.e. if I make a new file of a different computer it
> should be created under the ownership of the account under which I connected to that computer and not the account under which I logged in locally.

This is a illegal implication. You have accessed the other computer via
smb. This has NOTHING to do with NT security. The correct behaviour is
to use the SID under which you are logged into the NT network and in
your example it's the SID of your local login. The resulting `Unknown'
account on the other computer is a logical consequence because it has
no access to your local SAM. Moreover, what you do is possible but not
correct in a NT domain. You should login as domain user when you work
in a domain. If you use your local login you are mixing two worlds and
you have to live with the results.

Regards,
Corinna

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

Re: post b20.1: How to disable umask and access UNC path

[igoresha]

 ---- Chris Faylor wrote: 
> If I'm understanding what you're saying correctly, then you've just
> outlined the solution to the problem -- use "net use" to allocate the
> remote share to a logical drive.  Doesn't cygwin work correctly in
> that context?
No: it changes security on remote shares using local account information.

In any case as it seems to me the simplest solution is to have an additional option to limit ntsec only to local drives. Otherwise one has to impose NFS semantic on something that is quite orthogonal to it.
And to do it in a reasonable way is hard...

Regards, Igor Boukanov

-----------------------------------------------------
Get free email from CMP at http://www.cmpnetmail.com/

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

Re: post b20.1: How to disable umask and access UNC path

[igoresha]

 ---- Earnie Boyd wrote: 
 > Hmm.  How are you connecting to a different computer to create the file?  Is
> that via the "Map Drive" function?  
In my particular case I use
net use \\ip-address\share-name password /user:username
or simply 
net use \\ip-address\share-name 
in the case if username and password are the same.

In that way you can connect to an arbitratry compuetrs
any number of times (well, number of drive letters) 
simultaneously under different names.

>Couldn't that be considered an "NFS
> mounted" directory in unix?  Files created via NFS mounts have the properties
> of the user for that host not the host and owner of the filesystem.

In NT by default files on a remote computer are ownerd under a user name you use to connect to the remote system. So it is just opposite to NFS and IMO this is the only reasonable behavior in NT world.

Regards, Igor Boukanov


-----------------------------------------------------
Get free email from CMP at http://www.cmpnetmail.com/

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

Re: post b20.1: How to disable umask and access UNC path

[Corinna Vinschen]

igoresha@iwmail.com wrote:
> [...]
> In NT by default files on a remote computer are ownerd under a user name you use to connect to the remote system. So it is just opposite to NFS and IMO this is the only reasonable behavior in NT world.

To say it in Chris Faylor's words:

Patches are gratefully accepted.

Regards,
Corinna

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

post b20.1: How to disable umask and access UNC path

[igoresha]

Hello!

I played with a recent (1999.08.03) coolview binaries from Sergey Okhapkin which, I suppose, contain latest cygwin1.dll and have found that umask finally works.
Unfortunately permitions it uses on new files are not suitable for me and I wish to disable the new umask support. The reason:
I use cygwin on NT workstation that is not a domain member where I am member of Administrator group and often I access files on another coputer which 
is a domain member and where I am NOT an administrator. I have the same account name and password so it is not a problem to access
//domain-mmeber/share
but then with umask 007 after 
cd //domain-mmeber/share
touch x
I have the following permitions for x:
Account Unknown: Special Access(RWDPO)
<domain-name>\Administrators: Special Access(RWDPO)
Everyone: Special Access ()
System: Full Control

I do not like that "Account Unknown:"
and second I do not like to have 
"System: Full Control" by default.

It also missed a backup group from the parent directory
so new files will not be backuped (which IMHO is just an unaceptable change).

So how can I return to the parent directory permition 
inheritance in a post b20.1 world?

Also, what is a right way to access UNC path under new 
/cygdrive procedure?
I tried 
/cygdrive/host/share
/cygdrive//host/share
but it seems that only old
//host/share
works.

Regards, Igor Boukanov

PS. My CYGWIN is
tty noglob binmode





-----------------------------------------------------
Get free email from CMP at http://www.cmpnetmail.com/

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

Re: post b20.1: How to disable umask and access UNC path

[Chris Faylor]

On Mon, Aug 16, 1999 at 08:22:17AM -0400, igoresha@iwmail.com wrote:
>> igoresha@iwmail.com wrote:
>> > [...]
>> > And in any case does the fact that new code does not work accross network should be considered as a bug?
>> > I.e. if I make a new file of a different computer it
>> > should be created under the ownership of the account under which I connected to that computer and not the account under which I logged in locally.
>> 
>> This is a illegal implication. You have accessed the other computer via
>> smb. This has NOTHING to do with NT security. The correct behaviour is
>> to use the SID under which you are logged into the NT network and in
>> your example it's the SID of your local login. The resulting `Unknown'
>> account on the other computer is a logical consequence because it has
>> no access to your local SAM. Moreover, what you do is possible but not
>> correct in a NT domain. You should login as domain user when you work
>> in a domain. If you use your local login you are mixing two worlds and
>> you have to live with the results.
>
>But under NT4 you can always type 
>net use x: \\ip-address\share password /user:user-name
>
>then you will be logged to ip-address computer regardless of your
>domain membership under account you specify.  Then when you create
>files on "x:" via win32 calls those files by default will be owned by
>account under which you logged to ip-address, not under you local
>account.  This IMHO should be the way ntsec support is implemented in
>CYGWIN.

If I'm understanding what you're saying correctly, then you've just
outlined the solution to the problem -- use "net use" to allocate the
remote share to a logical drive.  Doesn't cygwin work correctly in
that context?

-chris

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

Re: post b20.1: How to disable umask and access UNC path

[igoresha]

But should NT Security support be off by default?
And in any case does the fact that new code does not work accross network should be considered as a bug?
I.e. if I make a new file of a different computer it
should be created under the ownership of the account under which I connected to that computer and not the account under which I logged in localy.

Regards, Igor Boukanov

Earnie Boyd wrote: 
> 
> To use this dll without the new NT Security coding SET CYGWIN=nontsec ...
> 
> Earnie
> 
> --- igoresha@iwmail.com wrote:
> > Hello!
> > 
> > I played with a recent (1999.08.03) coolview binaries from Sergey Okhapkin
> > which, I suppose, contain latest cygwin1.dll and have found that umask
> > finally works.
> > Unfortunately permitions it uses on new files are not suitable for me and I
> > wish to disable the new umask support. The reason:
> > I use cygwin on NT workstation that is not a domain member where I am member
> > of Administrator group and often I access files on another coputer which 
> > is a domain member and where I am NOT an administrator. I have the same
> > account name and password so it is not a problem to access
> > //domain-mmeber/share
> > but then with umask 007 after 
> > cd //domain-mmeber/share
> > touch x
> > I have the following permitions for x:
> > Account Unknown: Special Access(RWDPO)
> > <domain-name>\Administrators: Special Access(RWDPO)
> > Everyone: Special Access ()
> > System: Full Control
> > 
> > I do not like that "Account Unknown:"
> > and second I do not like to have 
> > "System: Full Control" by default.
> > 
> > It also missed a backup group from the parent directory
> > so new files will not be backuped (which IMHO is just an unaceptable change).
> > 
> > So how can I return to the parent directory permition 
> > inheritance in a post b20.1 world?
> > 
> > Also, what is a right way to access UNC path under new 
> > /cygdrive procedure?
> > I tried 
> > /cygdrive/host/share
> > /cygdrive//host/share
> > but it seems that only old
> > //host/share
> > works.
> > 
> > Regards, Igor Boukanov
> > 
> > PS. My CYGWIN is
> > tty noglob binmode
> > 
> > 
> > 
> > 
> > 
> > -----------------------------------------------------
> > Get free email from CMP at http://www.cmpnetmail.com/
> > 
> > --
> > Want to unsubscribe from this list?
> > Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> > 
> > 
> 
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> 
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> 


-----------------------------------------------------
Get free email from CMP at http://www.cmpnetmail.com/

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

Re: post b20.1: How to disable umask and access UNC path

[igoresha]

> igoresha@iwmail.com wrote:
> > [...]
> > And in any case does the fact that new code does not work accross network should be considered as a bug?
> > I.e. if I make a new file of a different computer it
> > should be created under the ownership of the account under which I connected to that computer and not the account under which I logged in locally.
> 
> This is a illegal implication. You have accessed the other computer via
> smb. This has NOTHING to do with NT security. The correct behaviour is
> to use the SID under which you are logged into the NT network and in
> your example it's the SID of your local login. The resulting `Unknown'
> account on the other computer is a logical consequence because it has
> no access to your local SAM. Moreover, what you do is possible but not
> correct in a NT domain. You should login as domain user when you work
> in a domain. If you use your local login you are mixing two worlds and
> you have to live with the results.

But under NT4 you can always type 
net use x: \\ip-address\share password /user:user-name

then you will be logged to ip-address computer regardless of your domain membership under
account you specify. 
Then when you create files on "x:" via win32 calls 
those files by default will be owned by account under which you logged to ip-address, not under you local account. This IMHO should be the way ntsec support is implemented in CYGWIN. 

Regards, Igor Boukanov


-----------------------------------------------------
Get free email from CMP at http://www.cmpnetmail.com/

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

Re: post b20.1: How to disable umask and access UNC path

[Chris Faylor]

On Mon, Aug 16, 1999 at 01:51:24PM -0400, igoresha@iwmail.com wrote:
> ---- Chris Faylor wrote: 
>> If I'm understanding what you're saying correctly, then you've just
>> outlined the solution to the problem -- use "net use" to allocate the
>> remote share to a logical drive.  Doesn't cygwin work correctly in
>> that context?
>No: it changes security on remote shares using local account information.
>
>In any case as it seems to me the simplest solution is to have an
>additional option to limit ntsec only to local drives.  Otherwise one
>has to impose NFS semantic on something that is quite orthogonal to it.
>And to do it in a reasonable way is hard...

Ah.  In that case, Corinna had some insightful comments earlier in the
thread.  I won't repeat them.

-chris

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

Re: post b20.1: How to disable umask and access UNC path

[Chris Faylor]

On Mon, Aug 16, 1999 at 01:51:24PM -0400, igoresha@iwmail.com wrote:
> ---- Chris Faylor wrote: 
>> If I'm understanding what you're saying correctly, then you've just
>> outlined the solution to the problem -- use "net use" to allocate the
>> remote share to a logical drive.  Doesn't cygwin work correctly in
>> that context?
>No: it changes security on remote shares using local account information.
>
>In any case as it seems to me the simplest solution is to have an
>additional option to limit ntsec only to local drives.  Otherwise one
>has to impose NFS semantic on something that is quite orthogonal to it.
>And to do it in a reasonable way is hard...

Ah.  In that case, Corinna had some insightful comments earlier in the
thread.  I won't repeat them.

-chris

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

Re: post b20.1: How to disable umask and access UNC path

[igoresha]

 ---- Chris Faylor wrote: 
> If I'm understanding what you're saying correctly, then you've just
> outlined the solution to the problem -- use "net use" to allocate the
> remote share to a logical drive.  Doesn't cygwin work correctly in
> that context?
No: it changes security on remote shares using local account information.

In any case as it seems to me the simplest solution is to have an additional option to limit ntsec only to local drives. Otherwise one has to impose NFS semantic on something that is quite orthogonal to it.
And to do it in a reasonable way is hard...

Regards, Igor Boukanov

-----------------------------------------------------
Get free email from CMP at http://www.cmpnetmail.com/

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

Re: post b20.1: How to disable umask and access UNC path

[Chris Faylor]

On Mon, Aug 16, 1999 at 08:22:17AM -0400, igoresha@iwmail.com wrote:
>> igoresha@iwmail.com wrote:
>> > [...]
>> > And in any case does the fact that new code does not work accross network should be considered as a bug?
>> > I.e. if I make a new file of a different computer it
>> > should be created under the ownership of the account under which I connected to that computer and not the account under which I logged in locally.
>> 
>> This is a illegal implication. You have accessed the other computer via
>> smb. This has NOTHING to do with NT security. The correct behaviour is
>> to use the SID under which you are logged into the NT network and in
>> your example it's the SID of your local login. The resulting `Unknown'
>> account on the other computer is a logical consequence because it has
>> no access to your local SAM. Moreover, what you do is possible but not
>> correct in a NT domain. You should login as domain user when you work
>> in a domain. If you use your local login you are mixing two worlds and
>> you have to live with the results.
>
>But under NT4 you can always type 
>net use x: \\ip-address\share password /user:user-name
>
>then you will be logged to ip-address computer regardless of your
>domain membership under account you specify.  Then when you create
>files on "x:" via win32 calls those files by default will be owned by
>account under which you logged to ip-address, not under you local
>account.  This IMHO should be the way ntsec support is implemented in
>CYGWIN.

If I'm understanding what you're saying correctly, then you've just
outlined the solution to the problem -- use "net use" to allocate the
remote share to a logical drive.  Doesn't cygwin work correctly in
that context?

-chris

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

Re: post b20.1: How to disable umask and access UNC path

[Corinna Vinschen]

igoresha@iwmail.com wrote:
> [...]
> In NT by default files on a remote computer are ownerd under a user name you use to connect to the remote system. So it is just opposite to NFS and IMO this is the only reasonable behavior in NT world.

To say it in Chris Faylor's words:

Patches are gratefully accepted.

Regards,
Corinna

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

Re: post b20.1: How to disable umask and access UNC path

[igoresha]

 ---- Earnie Boyd wrote: 
 > Hmm.  How are you connecting to a different computer to create the file?  Is
> that via the "Map Drive" function?  
In my particular case I use
net use \\ip-address\share-name password /user:username
or simply 
net use \\ip-address\share-name 
in the case if username and password are the same.

In that way you can connect to an arbitratry compuetrs
any number of times (well, number of drive letters) 
simultaneously under different names.

>Couldn't that be considered an "NFS
> mounted" directory in unix?  Files created via NFS mounts have the properties
> of the user for that host not the host and owner of the filesystem.

In NT by default files on a remote computer are ownerd under a user name you use to connect to the remote system. So it is just opposite to NFS and IMO this is the only reasonable behavior in NT world.

Regards, Igor Boukanov


-----------------------------------------------------
Get free email from CMP at http://www.cmpnetmail.com/

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

Re: post b20.1: How to disable umask and access UNC path

[igoresha]

> igoresha@iwmail.com wrote:
> > [...]
> > And in any case does the fact that new code does not work accross network should be considered as a bug?
> > I.e. if I make a new file of a different computer it
> > should be created under the ownership of the account under which I connected to that computer and not the account under which I logged in locally.
> 
> This is a illegal implication. You have accessed the other computer via
> smb. This has NOTHING to do with NT security. The correct behaviour is
> to use the SID under which you are logged into the NT network and in
> your example it's the SID of your local login. The resulting `Unknown'
> account on the other computer is a logical consequence because it has
> no access to your local SAM. Moreover, what you do is possible but not
> correct in a NT domain. You should login as domain user when you work
> in a domain. If you use your local login you are mixing two worlds and
> you have to live with the results.

But under NT4 you can always type 
net use x: \\ip-address\share password /user:user-name

then you will be logged to ip-address computer regardless of your domain membership under
account you specify. 
Then when you create files on "x:" via win32 calls 
those files by default will be owned by account under which you logged to ip-address, not under you local account. This IMHO should be the way ntsec support is implemented in CYGWIN. 

Regards, Igor Boukanov


-----------------------------------------------------
Get free email from CMP at http://www.cmpnetmail.com/

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

Re: post b20.1: How to disable umask and access UNC path

[Corinna Vinschen]

igoresha@iwmail.com wrote:
> [...]
> And in any case does the fact that new code does not work accross network should be considered as a bug?
> I.e. if I make a new file of a different computer it
> should be created under the ownership of the account under which I connected to that computer and not the account under which I logged in locally.

This is a illegal implication. You have accessed the other computer via
smb. This has NOTHING to do with NT security. The correct behaviour is
to use the SID under which you are logged into the NT network and in
your example it's the SID of your local login. The resulting `Unknown'
account on the other computer is a logical consequence because it has
no access to your local SAM. Moreover, what you do is possible but not
correct in a NT domain. You should login as domain user when you work
in a domain. If you use your local login you are mixing two worlds and
you have to live with the results.

Regards,
Corinna

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

Re: post b20.1: How to disable umask and access UNC path

[igoresha]

But should NT Security support be off by default?
And in any case does the fact that new code does not work accross network should be considered as a bug?
I.e. if I make a new file of a different computer it
should be created under the ownership of the account under which I connected to that computer and not the account under which I logged in localy.

Regards, Igor Boukanov

Earnie Boyd wrote: 
> 
> To use this dll without the new NT Security coding SET CYGWIN=nontsec ...
> 
> Earnie
> 
> --- igoresha@iwmail.com wrote:
> > Hello!
> > 
> > I played with a recent (1999.08.03) coolview binaries from Sergey Okhapkin
> > which, I suppose, contain latest cygwin1.dll and have found that umask
> > finally works.
> > Unfortunately permitions it uses on new files are not suitable for me and I
> > wish to disable the new umask support. The reason:
> > I use cygwin on NT workstation that is not a domain member where I am member
> > of Administrator group and often I access files on another coputer which 
> > is a domain member and where I am NOT an administrator. I have the same
> > account name and password so it is not a problem to access
> > //domain-mmeber/share
> > but then with umask 007 after 
> > cd //domain-mmeber/share
> > touch x
> > I have the following permitions for x:
> > Account Unknown: Special Access(RWDPO)
> > <domain-name>\Administrators: Special Access(RWDPO)
> > Everyone: Special Access ()
> > System: Full Control
> > 
> > I do not like that "Account Unknown:"
> > and second I do not like to have 
> > "System: Full Control" by default.
> > 
> > It also missed a backup group from the parent directory
> > so new files will not be backuped (which IMHO is just an unaceptable change).
> > 
> > So how can I return to the parent directory permition 
> > inheritance in a post b20.1 world?
> > 
> > Also, what is a right way to access UNC path under new 
> > /cygdrive procedure?
> > I tried 
> > /cygdrive/host/share
> > /cygdrive//host/share
> > but it seems that only old
> > //host/share
> > works.
> > 
> > Regards, Igor Boukanov
> > 
> > PS. My CYGWIN is
> > tty noglob binmode
> > 
> > 
> > 
> > 
> > 
> > -----------------------------------------------------
> > Get free email from CMP at http://www.cmpnetmail.com/
> > 
> > --
> > Want to unsubscribe from this list?
> > Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> > 
> > 
> 
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> 
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> 


-----------------------------------------------------
Get free email from CMP at http://www.cmpnetmail.com/

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

Re: post b20.1: How to disable umask and access UNC path

[Earnie Boyd]

To use this dll without the new NT Security coding SET CYGWIN=nontsec ...

Earnie

--- igoresha@iwmail.com wrote:
> Hello!
> 
> I played with a recent (1999.08.03) coolview binaries from Sergey Okhapkin
> which, I suppose, contain latest cygwin1.dll and have found that umask
> finally works.
> Unfortunately permitions it uses on new files are not suitable for me and I
> wish to disable the new umask support. The reason:
> I use cygwin on NT workstation that is not a domain member where I am member
> of Administrator group and often I access files on another coputer which 
> is a domain member and where I am NOT an administrator. I have the same
> account name and password so it is not a problem to access
> //domain-mmeber/share
> but then with umask 007 after 
> cd //domain-mmeber/share
> touch x
> I have the following permitions for x:
> Account Unknown: Special Access(RWDPO)
> <domain-name>\Administrators: Special Access(RWDPO)
> Everyone: Special Access ()
> System: Full Control
> 
> I do not like that "Account Unknown:"
> and second I do not like to have 
> "System: Full Control" by default.
> 
> It also missed a backup group from the parent directory
> so new files will not be backuped (which IMHO is just an unaceptable change).
> 
> So how can I return to the parent directory permition 
> inheritance in a post b20.1 world?
> 
> Also, what is a right way to access UNC path under new 
> /cygdrive procedure?
> I tried 
> /cygdrive/host/share
> /cygdrive//host/share
> but it seems that only old
> //host/share
> works.
> 
> Regards, Igor Boukanov
> 
> PS. My CYGWIN is
> tty noglob binmode
> 
> 
> 
> 
> 
> -----------------------------------------------------
> Get free email from CMP at http://www.cmpnetmail.com/
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> 
> 

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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

post b20.1: How to disable umask and access UNC path

[igoresha]

Hello!

I played with a recent (1999.08.03) coolview binaries from Sergey Okhapkin which, I suppose, contain latest cygwin1.dll and have found that umask finally works.
Unfortunately permitions it uses on new files are not suitable for me and I wish to disable the new umask support. The reason:
I use cygwin on NT workstation that is not a domain member where I am member of Administrator group and often I access files on another coputer which 
is a domain member and where I am NOT an administrator. I have the same account name and password so it is not a problem to access
//domain-mmeber/share
but then with umask 007 after 
cd //domain-mmeber/share
touch x
I have the following permitions for x:
Account Unknown: Special Access(RWDPO)
<domain-name>\Administrators: Special Access(RWDPO)
Everyone: Special Access ()
System: Full Control

I do not like that "Account Unknown:"
and second I do not like to have 
"System: Full Control" by default.

It also missed a backup group from the parent directory
so new files will not be backuped (which IMHO is just an unaceptable change).

So how can I return to the parent directory permition 
inheritance in a post b20.1 world?

Also, what is a right way to access UNC path under new 
/cygdrive procedure?
I tried 
/cygdrive/host/share
/cygdrive//host/share
but it seems that only old
//host/share
works.

Regards, Igor Boukanov

PS. My CYGWIN is
tty noglob binmode





-----------------------------------------------------
Get free email from CMP at http://www.cmpnetmail.com/

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