Cygwin Everyone group permissions and Vista "shared files" (*not* shared folders)

[Barry Kelly-2]

Cygwin by default, tries to implement POSIX permissions using the NT ACL
system - fairly well described here:

  http://cygwin.com/cygwin-ug-net/ntsec.html

The way this feature is implemented interacts poorly with Vista,
however. A previous mailing (with reply) on this list that tried to
describe this issue is here:

  http://www.mail-archive.com/cygwin@.../msg83783.html
Reply:
  http://www.mail-archive.com/cygwin@.../msg83794.html

The Vista feature in question is "Shared Files", which is *not* the same
thing as a network share. Rather, it describes files which are shared
between *different* users of the *same* computer, rather than different
users in a network environment.

Vista comes with a saved search that tries to show all such "Shared
Files" in your profile directory, recursively; i.e. files that you would
reasonably expect to own, but are letting other users of the same
computer access. The saved search is located here:

  C:\Users\<user-name>\Searches\Shared By Me.search-ms

The way it appears to work is by looking for files and directories which
have access-allowed access control entries (ACEs) for the groups Users
or Everyone.

Unfortunately, Cygwin creates an ACE for the group Everyone, even with
umask 0077, or after chmod 0700 is applied. Specifically, this is what
it looks like using cacls:

                     Everyone:(special access:)
                              READ_CONTROL
                              FILE_READ_EA
                              FILE_READ_ATTRIBUTES

How can addition of this ACE be controlled or prevented by default for
Cygwin applications?

Thanks,

-- Barry

--
http://barrkel.blogspot.com/

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

[Corinna Vinschen-2]

On Sep  9 07:47, Barry Kelly wrote:

> Unfortunately, Cygwin creates an ACE for the group Everyone, even with
> umask 0077, or after chmod 0700 is applied. Specifically, this is what
> it looks like using cacls:
>
>                      Everyone:(special access:)
>                               READ_CONTROL
>                               FILE_READ_EA
>                               FILE_READ_ATTRIBUTES
>
> How can addition of this ACE be controlled or prevented by default for
> Cygwin applications?

It can't be prevented right now.  I added "don't create null
group/everyone ACEs to file ACLs" on my Cygwin 1.7 TODO list.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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

[Corinna Vinschen-2]

On Sep 29 18:52, Corinna Vinschen wrote:

> On Sep  9 07:47, Barry Kelly wrote:
> > Unfortunately, Cygwin creates an ACE for the group Everyone, even with
> > umask 0077, or after chmod 0700 is applied. Specifically, this is what
> > it looks like using cacls:
> >
> >                      Everyone:(special access:)
> >                               READ_CONTROL
> >                               FILE_READ_EA
> >                               FILE_READ_ATTRIBUTES
> >
> > How can addition of this ACE be controlled or prevented by default for
> > Cygwin applications?
>
> It can't be prevented right now.  I added "don't create null
> group/everyone ACEs to file ACLs" on my Cygwin 1.7 TODO list.

Fresh back from vacation I missed the crucial point here.  Sorry.

The real answer is:  It can't be prevented and there are no plans to add
code to prevent it, since these read permissions are required to get
POSIX-like permissions.

Unless, of course, you go without POSIX permissions entirely.  The
setting for this is the "nontsec" keyword in the environment variable
$CYGWIN until Cygwin 1.5.25(*), which has global scope, or the mount
point option "noacl" in /etc/fstab starting with Cygwin 1.7(**), which
has a per-mount point scope.  Using nontsec/noacl will result in getting
Windows default permissions instead of POSIX equivalent permissions.


Corinna


(*)  http://cygwin.com/cygwin-ug-net/using-cygwinenv.html
(**) Preliminary docs:
     http://cygwin.com/1.7/cygwin-ug-net/using.html#mount-table

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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

[charles5687]

Corinna Vinschen-2 wrote:
>
> On Sep 29 18:52, Corinna Vinschen wrote:
>
> The real answer is:  It can't be prevented and there are no plans to add
> code to prevent it, since these read permissions are required to get
> POSIX-like permissions.
>
>

I'm not sure I follow. Does this mean there are no plans to support
Windows Vista and every future release of Windows by extension? Are the
Cygwin devs at least aware of the serious problems with manipulating files
created by Cygwin (with share attributes) inside Vista's explorer?

Every file with these share attributes take 1000's of times longer to
delete,move,copy
because of their shared-ness-- this seems like an issue that should be
looked
into for a project whose primary mission is Windows interoperability. Any
Vista
issue with Cygwin should be considered a Cygwin issue by extension,
especially
serious usability issues like the above.

Now for the constructive part of my post: Is the following suggestion from
another thread on this issue not feasible to implement?

http://www.mail-archive.com/cygwin@.../msg84231.html

Specifically, "I suggested that Cygwin changes it's
attribute handling to leave out the local/None and Everyone groups
completely, whenever they have no access permissions."

What is the technical problem with implementing that for Vista? Does
this break POSIX permissions? I would think that it's a reasonable
suggestion, but I'm no expert on Cygwin. It would be nice to actually
have this option looked into, and maybe come up with another plan.
Cygwin will not get any easier to use for Vista and future Windows 7
users if the problem is not fixed at some point in time (I don't consider
dropping UNIX/POSIX permissions with `nontsec`/`noacl` to be a "fix").

- Charles
--
View this message in context: http://www.nabble.com/Cygwin-Everyone-group-permissions-and-Vista-%22shared-files%22-%28*not*-shared-folders%29-tp19386749p20415300.html
Sent from the Cygwin list mailing list archive at Nabble.com.


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

[charles5687]

Corinna Vinschen-2 wrote:

On Sep 29 18:52, Corinna Vinschen wrote: The real answer is: It can't be prevented and there are no plans to add code to prevent it, since these read permissions are required to get POSIX-like permissions.

I'm not sure I follow. Does this mean there are no plans to support Windows Vista and every future release of Windows by extension? Are the Cygwin devs at least aware of the serious problems with manipulating files created by Cygwin (with share attributes) inside Vista's explorer?

Every file with these share attributes take 1000's of times longer to delete,move,copy because of their shared-ness-- this seems like an issue that should be looked into for a project whose primary mission is Windows interoperability. Any Vista issue with Cygwin should be considered a Cygwin issue by extension, especially serious usability issues like the above.

Now for the constructive part of my post: Is the following suggestion from another thread on this issue not feasible to implement?

http://www.mail-archive.com/[e-mail]/msg84231.html

Specifically, "I suggested that Cygwin changes it's attribute handling to leave out the local/None and Everyone groups completely, whenever they have no access permissions."

What is the technical problem with implementing that for Vista? Does this break POSIX permissions? I would think that it's a reasonable suggestion, but I'm no expert on Cygwin. It would be nice to actually have this option looked into, and maybe come up with another plan. Cygwin will not get any easier to use for Vista and future Windows 7 users if the problem is not fixed at some point in time (I don't consider dropping UNIX/POSIX permissions with `nontsec`/`noacl` to be a "fix").

- Charles

[Corinna Vinschen-2]

On Nov  9 23:13, charles5687 wrote:
> Corinna Vinschen-2 wrote:
> > The real answer is:  It can't be prevented and there are no plans to add
> > code to prevent it, since these read permissions are required to get
> > POSIX-like permissions.
>
> I'm not sure I follow. Does this mean there are no plans to support
> Windows Vista and every future release of Windows by extension? Are the

Huh?

> Cygwin devs at least aware of the serious problems with manipulating files
> created by Cygwin (with share attributes) inside Vista's explorer?

Yes.  But it's a minor problem.  It only affects files in the user's
Windows homepath.  All the rest of your drive(s) are not affected at
all.  And you should better create a Cygwin specific home dir anyway.

> Every file with these share attributes take 1000's of times longer to
> delete,move,copy
> because of their shared-ness-- this seems like an issue that should be
> looked
> into for a project whose primary mission is Windows interoperability. Any

You got something wrong.  POSIX compliance is the primary mission.
Windows interoperability is a nice extra.

> Vista
> issue with Cygwin should be considered a Cygwin issue by extension,
> especially
> serious usability issues like the above.

So much for your opinion.  In my opinion it's a terrible move by
Microsoft to slow down every operation in the user's homepath so much
just to look for the "Everyone" ACE and to visualize it's existence.
Independently from Cygwin.

> Now for the constructive part of my post: Is the following suggestion from
> another thread on this issue not feasible to implement?
>
> http://www.mail-archive.com/cygwin@.../msg84231.html
>
> Specifically, "I suggested that Cygwin changes it's
> attribute handling to leave out the local/None and Everyone groups
> completely, whenever they have no access permissions."

No, it's not feasible.  If you leave out the Everyone ACE, the
permissions are not POSIX-like anymore.  Leaving out means that others
have no permissions at all.  Not even to see the permissions.  That's
not correct from a POSIX POV.  Even if others don't have rwx
permissions, they need at least FILE_READ_ATTRIBUTES and READ_DAC
permissions.  This requires to have an Everyone ACE.

And this is not a Cygwin-only problem, install SUA(*) and see what it
does with respect to POSIX permissions and Everyone ACEs...


Corinna


(*) "Subsystem for UNIX-based Applications", comes with Vista
    Ultimate/Enterprise and Windows 2008.


--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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

[Barry Kelly-2]

Corinna Vinschen wrote:

> No, it's not feasible.  If you leave out the Everyone ACE, the
> permissions are not POSIX-like anymore.  Leaving out means that others
> have no permissions at all.  Not even to see the permissions.  That's
> not correct from a POSIX POV.

> Even if others don't have rwx
> permissions, they need at least FILE_READ_ATTRIBUTES and READ_DAC
> permissions.  This requires to have an Everyone ACE.

Why can't we have a security toggle that leaves out the Everyone ACE,
and the POSIX subsystem interprets failure to read the DACL as no
permissions?

Cygwin still needs to handle with files created by other users and
programs that it doesn't have permission to view the permissions of, so
the second half of this requirement is already present.

I, for one, use Cygwin not primarily as a POSIX emulation layer, but as
my main Windows user interface. IMHO in this situation, being posixly
correct is a handicap that Cygwin could do without, at the user's
choice.

-- Barry

--
http://barrkel.blogspot.com/

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

[Larry Hall (Cygwin-X)]

Barry Kelly wrote:

> Corinna Vinschen wrote:
>
>> No, it's not feasible.  If you leave out the Everyone ACE, the
>> permissions are not POSIX-like anymore.  Leaving out means that others
>> have no permissions at all.  Not even to see the permissions.  That's
>> not correct from a POSIX POV.
>
>> Even if others don't have rwx
>> permissions, they need at least FILE_READ_ATTRIBUTES and READ_DAC
>> permissions.  This requires to have an Everyone ACE.
>
> Why can't we have a security toggle that leaves out the Everyone ACE,
> and the POSIX subsystem interprets failure to read the DACL as no
> permissions?
>
> Cygwin still needs to handle with files created by other users and
> programs that it doesn't have permission to view the permissions of, so
> the second half of this requirement is already present.
>
> I, for one, use Cygwin not primarily as a POSIX emulation layer, but as
> my main Windows user interface. IMHO in this situation, being posixly
> correct is a handicap that Cygwin could do without, at the user's
> choice.

So what about the "nontsec" option doesn't address your need then?
<http://cygwin.com/cygwin-ug-net/using-cygwinenv.html>

--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      [phone] - RFK Office
216 Dalton Rd.                          [phone] - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

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

[Barry Kelly-2]

Larry Hall (Cygwin) wrote:

> Barry Kelly wrote:
> > Corinna Vinschen wrote:
> >
> > I, for one, use Cygwin not primarily as a POSIX emulation layer, but as
> > my main Windows user interface. IMHO in this situation, being posixly
> > correct is a handicap that Cygwin could do without, at the user's
> > choice.
>
> So what about the "nontsec" option doesn't address your need then?

It disables NT ACL manipulation via chmod, chown and chgrp.

I have different users on my machines for various reasons, and
permissions are sometimes a problem. Concrete real-life example: on my
laptop I have a "presenter" user who has extra-large fonts, so that
folks can see code samples etc. during presentations. However, the code
samples themselves are created and edited using the normal user, and
often end up inaccessible - i.e. read-only - to the presenter user.

I have a simple utility called reset-permissions that uses chown and
chmod to recursively reset permissions to a known good state in the
directories specified as arguments. This works well enough that I don't
have to panic over file rights in the middle of a presentation.

I could write my own chown and chmod, perhaps in terms of cacls, perhaps
with custom utilities for more precise ACLs. I'd rather not have to
reimplement those utilities though.

-- Barry

--
http://barrkel.blogspot.com/

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

[Larry Hall (Cygwin-X)]

Barry Kelly wrote:

> Larry Hall (Cygwin) wrote:
>
>> Barry Kelly wrote:
>>> Corinna Vinschen wrote:
>>>
>>> I, for one, use Cygwin not primarily as a POSIX emulation layer, but as
>>> my main Windows user interface. IMHO in this situation, being posixly
>>> correct is a handicap that Cygwin could do without, at the user's
>>> choice.
>> So what about the "nontsec" option doesn't address your need then?
>
> It disables NT ACL manipulation via chmod, chown and chgrp.

Understood.  But this is allowed under SUSV3.  Cygwin has getfacl/setfacl
to manipulate ACLs directly, pretty much like cacls.  But what you're
proposing, I believe, is permissible under SUSV3 too for chmod and friends.
It just comes down to SHTDI <http://cygwin.com/acronyms/#SHTDI>.  It's
also fair to say that this is not a primary goal of Cygwin so it's unlikely
to be a priority with the Cygwin development team.  If this is a
priority to you, then it will probably happen sooner if you jump in and
provide some patches.  That's not an order (could I actually do that? ;-) )
I just wanted to properly set your expectations for this. :-)

--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      [phone] - RFK Office
216 Dalton Rd.                          [phone] - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

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

[Corinna Vinschen-2]

On Nov 13 15:28, Larry Hall (Cygwin) wrote:

> Barry Kelly wrote:
>> Larry Hall (Cygwin) wrote:
>>> Barry Kelly wrote:
>>>> Corinna Vinschen wrote:
>>>>
>>>> I, for one, use Cygwin not primarily as a POSIX emulation layer, but as
>>>> my main Windows user interface. IMHO in this situation, being posixly
>>>> correct is a handicap that Cygwin could do without, at the user's
>>>> choice.
>>> So what about the "nontsec" option doesn't address your need then?
>> It disables NT ACL manipulation via chmod, chown and chgrp.
>
> Understood.  But this is allowed under SUSV3.  Cygwin has getfacl/setfacl

Erm... I'm not sure what SUSv3 has to do with that.

I really don't like the idea to make excemptions just for a small part
of the harddisk which gets mistreated by Microsoft.  Don't do Cygwin
stuff in your Windows home dir, create a Cygwin specific home dir
instead.

If that's not feasible, switch off ntsec and you get standard Windows
permissions.  If the standard Windows permissions are not as you need
them, don't rely on Cygwin's chown/chmod. rather change the inheritence
settings of the parent directory according to your needs.  Then you get
the required permissions right from the start.  Nothing against using
chown/chmod in some border cases, Berry, but in your situation they are
just a workaround for bad permission settings.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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

[Larry Hall (Cygwin-X)]

Corinna Vinschen wrote:

> On Nov 13 15:28, Larry Hall (Cygwin) wrote:
>> Barry Kelly wrote:
>>> Larry Hall (Cygwin) wrote:
>>>> Barry Kelly wrote:
>>>>> Corinna Vinschen wrote:
>>>>>
>>>>> I, for one, use Cygwin not primarily as a POSIX emulation layer, but as
>>>>> my main Windows user interface. IMHO in this situation, being posixly
>>>>> correct is a handicap that Cygwin could do without, at the user's
>>>>> choice.
>>>> So what about the "nontsec" option doesn't address your need then?
>>> It disables NT ACL manipulation via chmod, chown and chgrp.
>> Understood.  But this is allowed under SUSV3.  Cygwin has getfacl/setfacl
>
> Erm... I'm not sure what SUSv3 has to do with that.

<http://www.opengroup.org/onlinepubs/009695399/>, second paragraph.
Perhaps I'm misreading it but to me this says that chmod and friends
may or may not opt to change access control beyond the realm of the
literal mode.  Cygwin's doesn't and that's perfectly valid.

> I really don't like the idea to make excemptions just for a small part
> of the harddisk which gets mistreated by Microsoft.  Don't do Cygwin
> stuff in your Windows home dir, create a Cygwin specific home dir
> instead.
>
> If that's not feasible, switch off ntsec and you get standard Windows
> permissions.  If the standard Windows permissions are not as you need
> them, don't rely on Cygwin's chown/chmod. rather change the inheritence
> settings of the parent directory according to your needs.  Then you get
> the required permissions right from the start.  Nothing against using
> chown/chmod in some border cases, Berry, but in your situation they are
> just a workaround for bad permission settings.

I'm not in disagreement here.  Obviously anything that someone decided
to try here would have to meet the performance criteria.  To me, it seems
easier to use other available tools to manipulate files in the nontsec
environment.  And don't get me started on Vista's "shared" debacle! ;-)

--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      [phone] - RFK Office
216 Dalton Rd.                          [phone] - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

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

[Barry Kelly-2]

Corinna Vinschen wrote:

> If that's not feasible, switch off ntsec and you get standard Windows
> permissions.  If the standard Windows permissions are not as you need
> them, don't rely on Cygwin's chown/chmod. rather change the inheritence
> settings of the parent directory according to your needs.  Then you get
> the required permissions right from the start.  Nothing against using
> chown/chmod in some border cases, Berry, but in your situation they are
> just a workaround for bad permission settings.

I guess I will just have to reimplement chown and chmod, it seems.

PS: I don't know what it is that makes some people get my name wrong,
but there you go.

-- Barry

--
http://barrkel.blogspot.com/

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

[Larry Hall (Cygwin-X)]

Barry Kelly wrote:

> Corinna Vinschen wrote:
>
>> If that's not feasible, switch off ntsec and you get standard Windows
>> permissions.  If the standard Windows permissions are not as you need
>> them, don't rely on Cygwin's chown/chmod. rather change the inheritence
>> settings of the parent directory according to your needs.  Then you get
>> the required permissions right from the start.  Nothing against using
>> chown/chmod in some border cases, Berry, but in your situation they are
>> just a workaround for bad permission settings.
>
> I guess I will just have to reimplement chown and chmod, it seems.

Perhaps you're better off with the available tools for ACLs?  Just a
thought.

> PS: I don't know what it is that makes some people get my name wrong,
> but there you go.

Don't let it get you down Berry.

--
Lerry ;-)


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