public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* File Permissions - Yet Another Question / Clarification
@ 2015-04-01 19:56 Bryan Berns
  2015-04-01 20:35 ` Andrey Repin
  0 siblings, 1 reply; 11+ messages in thread
From: Bryan Berns @ 2015-04-01 19:56 UTC (permalink / raw)
  To: cygwin

I finally am moving my user community to Cygwin 1.7.35 at work and
having some issues with ssh not thinking user's ssh keys are owned by
the user.  I indeed can see that their directory listings do not show
their userid as having read,write, or execute to *any* of their files.

In short, just wanted to make sure behavior like that demonstrated
below is "by design".  In particular, I find it odd that "Domain
Users" is the only entity that is listed as having permissions despite
not being in the DACL at all.  On the plus side, the startup speed is
much, much faster than before and we no longer need to worry about
maintaining our HUGE passwd and groups files.  Any thoughts are
appreciated.  I've read the ntsec page and still digesting all
information...

@ umask
77
@ whoami
bernsbj
@ touch mytestfile
@ ls -l mytestfile
----rwx---+ 1 bernsbj Domain Users 0 Apr  1 15:38 mytestfile
@ icacls mytestfile
mytestfile MYDOMAIN\bernsbj:(I)(F)
          BUILTIN\Administrators:(I)(F)
         OTHERDOMAIN\Domain Admins:(I)(F)

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: File Permissions - Yet Another Question / Clarification
  2015-04-01 19:56 File Permissions - Yet Another Question / Clarification Bryan Berns
@ 2015-04-01 20:35 ` Andrey Repin
  2015-04-01 21:33   ` Bryan Berns
  0 siblings, 1 reply; 11+ messages in thread
From: Andrey Repin @ 2015-04-01 20:35 UTC (permalink / raw)
  To: Bryan Berns, cygwin

Greetings, Bryan Berns!

> I finally am moving my user community to Cygwin 1.7.35 at work and
> having some issues with ssh not thinking user's ssh keys are owned by
> the user.  I indeed can see that their directory listings do not show
> their userid as having read,write, or execute to *any* of their files.

Have you tried to read the relevant FAQ article before posting in the list?

Faq entry 4.40.
Why does public key authentication with ssh fail after updating to Cygwin 1.7.34?
http://cygwin.com/faq.html#faq.using.ssh-pubkey-stops-working

> In short, just wanted to make sure behavior like that demonstrated
> below is "by design".  In particular, I find it odd that "Domain
> Users" is the only entity that is listed as having permissions despite
> not being in the DACL at all.  On the plus side, the startup speed is
> much, much faster than before and we no longer need to worry about
> maintaining our HUGE passwd and groups files.  Any thoughts are
> appreciated.  I've read the ntsec page and still digesting all
> information...

> @ umask
> 77
> @ whoami
> bernsbj
> @ touch mytestfile
> @ ls -l mytestfile
> ----rwx---+ 1 bernsbj Domain Users 0 Apr  1 15:38 mytestfile
> @ icacls mytestfile
> mytestfile MYDOMAIN\bernsbj:(I)(F)
>           BUILTIN\Administrators:(I)(F)
>          OTHERDOMAIN\Domain Admins:(I)(F)

That doesn't help understanding your issue, unfortunately.
If reading FAQ doesn't help, please provide the output of mount and pwd at the
very least.

> --
> Problem reports:       http://cygwin.com/problems.html
> FAQ:                   http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


-- 
With best regards,
Andrey Repin
Wednesday, April 1, 2015 23:19:05

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: File Permissions - Yet Another Question / Clarification
  2015-04-01 20:35 ` Andrey Repin
@ 2015-04-01 21:33   ` Bryan Berns
  2015-04-02  1:35     ` Andrey Repin
  0 siblings, 1 reply; 11+ messages in thread
From: Bryan Berns @ 2015-04-01 21:33 UTC (permalink / raw)
  To: cygwin

Andrey,

Sorry for not being more clear -- yes, I had read the FAQ on SSH.  I
was taking the problem up a level to the more obvious weirdness
demonstrated by the resultant files on a simple "touch".  Why would
Cygwin report that 'Domain Users' --- a group not in the DACL at all
--- as being able to R/W/X on the files?

The relevant mount is this:
K: on /cygdrive/k type netapp (text,posix=0,user,noumount,auto)

Note: It is indeed on a NetApp that is using NTFS mode.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: File Permissions - Yet Another Question / Clarification
  2015-04-01 21:33   ` Bryan Berns
@ 2015-04-02  1:35     ` Andrey Repin
  2015-04-02 13:01       ` Bryan Berns
  0 siblings, 1 reply; 11+ messages in thread
From: Andrey Repin @ 2015-04-02  1:35 UTC (permalink / raw)
  To: Bryan Berns, cygwin

Greetings, Bryan Berns!

> Sorry for not being more clear -- yes, I had read the FAQ on SSH.  I
> was taking the problem up a level to the more obvious weirdness
> demonstrated by the resultant files on a simple "touch".  Why would
> Cygwin report that 'Domain Users' --- a group not in the DACL at all
> --- as being able to R/W/X on the files?

This is still not helping.
"Domain Users" is, supposedly, your user's primary group.
The group "rwx" bits are not necessarily refer to the group owner, when ACL is
present on a file. Please refer back to the FAQ and the linked documentation
entry for further explanation.

> The relevant mount is this:
> K: on /cygdrive/k type netapp (text,posix=0,user,noumount,auto)

> Note: It is indeed on a NetApp that is using NTFS mode.

NetApp drives are known to have all kind of weird behavior.
Details are in the list archives.

Also, :
> --
> Problem reports:       http://cygwin.com/problems.html
> FAQ:                   http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html


-- 
With best regards,
Andrey Repin
Thursday, April 2, 2015 04:26:12

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: File Permissions - Yet Another Question / Clarification
  2015-04-02  1:35     ` Andrey Repin
@ 2015-04-02 13:01       ` Bryan Berns
  2015-04-02 15:35         ` Andrey Repin
  0 siblings, 1 reply; 11+ messages in thread
From: Bryan Berns @ 2015-04-02 13:01 UTC (permalink / raw)
  To: cygwin

I'll try to reproduce the issue on a standard NTFS volume -- although
I would image Cygwin is just decoding the same DACL that ICACLS is
returning.  The other oddity is why it's not recognizing *me* as
having any permissions.

In the particular case of SSH, is there any way to make SSH ignore
these permissions?  I understand the importance / value of the check
it's doing, but in our situation, it's not necessary... and obviously
causing us pain given the permission weirdness.  Removing the
administrative groups would be undesirable for us since they assist in
our administrative team doing home directory moves across sites.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: File Permissions - Yet Another Question / Clarification
  2015-04-02 13:01       ` Bryan Berns
@ 2015-04-02 15:35         ` Andrey Repin
  2015-04-02 18:27           ` Bryan Berns
  0 siblings, 1 reply; 11+ messages in thread
From: Andrey Repin @ 2015-04-02 15:35 UTC (permalink / raw)
  To: Bryan Berns, cygwin

Greetings, Bryan Berns!

> I'll try to reproduce the issue on a standard NTFS volume -- although
> I would image Cygwin is just decoding the same DACL that ICACLS is
> returning.  The other oddity is why it's not recognizing *me* as
> having any permissions.

getfacl may shed additional light.

> In the particular case of SSH, is there any way to make SSH ignore
> these permissions?

Thanks, I laughed.

> I understand the importance / value of the check
> it's doing, but in our situation, it's not necessary...

You never know when it is necessary. Security is a tough mistress.

> and obviously
> causing us pain given the permission weirdness.  Removing the
> administrative groups would be undesirable for us since they assist in
> our administrative team doing home directory moves across sites.

Administrators can access anything they want regardless of permissions, if
they really need to do it.
This is not a valid argument.

And leaving the context out of the reply doesn't help the discussion at all.


-- 
With best regards,
Andrey Repin
Thursday, April 2, 2015 18:29:18

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: File Permissions - Yet Another Question / Clarification
  2015-04-02 15:35         ` Andrey Repin
@ 2015-04-02 18:27           ` Bryan Berns
  2015-04-02 18:41             ` Achim Gratz
  0 siblings, 1 reply; 11+ messages in thread
From: Bryan Berns @ 2015-04-02 18:27 UTC (permalink / raw)
  To: cygwin

Andrey,

>> In the particular case of SSH, is there any way to make SSH ignore
>> these permissions?

> Thanks, I laughed.

Thanks for the less-than-helpful response.  A "no" would have sufficed
if that is indeed the case.

>> and obviously
>> causing us pain given the permission weirdness.  Removing the
>> administrative groups would be undesirable for us since they assist in
>> our administrative team doing home directory moves across sites.

> Administrators can access anything they want regardless of permissions, if
> they really need to do it.
> This is not a valid argument.

In the real world in large corporations with focus on security,
"Administrators" is typically a tiered or least privilege arrangement.
All administrators are not created equally.

Thanks,

Bryan

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: File Permissions - Yet Another Question / Clarification
  2015-04-02 18:27           ` Bryan Berns
@ 2015-04-02 18:41             ` Achim Gratz
  2015-04-02 19:03               ` Bryan Berns
  0 siblings, 1 reply; 11+ messages in thread
From: Achim Gratz @ 2015-04-02 18:41 UTC (permalink / raw)
  To: cygwin

Bryan Berns writes:
> In the real world in large corporations with focus on security,
> "Administrators" is typically a tiered or least privilege arrangement.

He's talking about "Administrators" the SID (group).

In any case, I'd start with a throwaway share (or save the permissions
with subinacl if I had to use a live one).  Then remove the inherited /
default DACL from a subdirectory:

mkdir sub
setfacl -k sub
setfacl -b sub

Then check how this behaves w.r.t. POSIX permissions and file ownership.
Populate this directory with files and check those, too.  The ~/.ssh
directory and their content shouldn't have any DACL on them in any case
if you c want to be sure it works the way sshd is wanting it to.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: File Permissions - Yet Another Question / Clarification
  2015-04-02 18:41             ` Achim Gratz
@ 2015-04-02 19:03               ` Bryan Berns
  2015-04-02 22:20                 ` Andrey Repin
  2015-04-03  2:57                 ` Bryan Berns
  0 siblings, 2 replies; 11+ messages in thread
From: Bryan Berns @ 2015-04-02 19:03 UTC (permalink / raw)
  To: cygwin

> He's talking about "Administrators" the SID (group).

Interesting.  Given the built-in Administrators group doesn't often
[directly] play into permissions on remote systems or cross-system
permission models, I'm not sure where he was going with that.
Regardless, I'll consider it water under the bridge.

> In any case, I'd start with a throwaway share (or save the permissions
> with subinacl if I had to use a live one).  Then remove the inherited /
> default DACL from a subdirectory:
>
> mkdir sub
> setfacl -k sub
> setfacl -b sub
>
> Then check how this behaves w.r.t. POSIX permissions and file ownership.
> Populate this directory with files and check those, too.  The ~/.ssh
> directory and their content shouldn't have any DACL on them in any case
> if you c want to be sure it works the way sshd is wanting it to.
>
>
> Regards,
> Achim.

Thanks for advice -- I will give it a shot and dive in deeper.   I
think I have two problems I'm interesting in understanding more /
resolving: 1) why doesn't Cygwin think my user has permissions to the
files and 2) how can I get SSH to believe the two "admin" groups on my
files are acceptable.  I'm not optimistic I'm going to get SSH to
change it's behavior so I may need to recompile it to avoid the
check.... which is obviously not desirable from a maintainability
standpoint.

Appreciatively,

Bryan

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: File Permissions - Yet Another Question / Clarification
  2015-04-02 19:03               ` Bryan Berns
@ 2015-04-02 22:20                 ` Andrey Repin
  2015-04-03  2:57                 ` Bryan Berns
  1 sibling, 0 replies; 11+ messages in thread
From: Andrey Repin @ 2015-04-02 22:20 UTC (permalink / raw)
  To: Bryan Berns, cygwin

Greetings, Bryan Berns!

>> He's talking about "Administrators" the SID (group).

> Interesting.  Given the built-in Administrators group doesn't often
> [directly] play into permissions on remote systems or cross-system
> permission models, I'm not sure where he was going with that.
> Regardless, I'll consider it water under the bridge.

"Domain Admins" group is a member of local Administrators group.
In properly set corporate environment, administrators that require management
access to client systems are also automatically added to this group.

>> In any case, I'd start with a throwaway share (or save the permissions
>> with subinacl if I had to use a live one).  Then remove the inherited /
>> default DACL from a subdirectory:
>>
>> mkdir sub
>> setfacl -k sub
>> setfacl -b sub
>>
>> Then check how this behaves w.r.t. POSIX permissions and file ownership.
>> Populate this directory with files and check those, too.  The ~/.ssh
>> directory and their content shouldn't have any DACL on them in any case
>> if you c want to be sure it works the way sshd is wanting it to.
>>
>>
>> Regards,
>> Achim.

> Thanks for advice -- I will give it a shot and dive in deeper.   I
> think I have two problems I'm interesting in understanding more /
> resolving:
> 1) why doesn't Cygwin think my user has permissions to the files and

I already told you at least one way to check it further.
Given my shallow understanding of Cygwin internals, I'm sure there's more
ways to look at it.
Or you can go straight to strace and gdb.

> 2) how can I get SSH to believe the two "admin" groups on my
> files are acceptable.

This one is simple: They are not acceptable in any way.
And insisting on this point is not going to get any appreciation any time
soon.


-- 
With best regards,
Andrey Repin
Friday, April 3, 2015 01:09:48

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: File Permissions - Yet Another Question / Clarification
  2015-04-02 19:03               ` Bryan Berns
  2015-04-02 22:20                 ` Andrey Repin
@ 2015-04-03  2:57                 ` Bryan Berns
  1 sibling, 0 replies; 11+ messages in thread
From: Bryan Berns @ 2015-04-03  2:57 UTC (permalink / raw)
  To: cygwin

Replying to myself on this topic in case anyone else is interested.

> 2) how can I get SSH to believe the two "admin" groups on my
> files are acceptable.  I'm not optimistic I'm going to get SSH to
> change it's behavior so I may need to recompile it to avoid the
> check.... which is obviously not desirable from a maintainability
> standpoint.

The applicable check at work here is check_ntsec() and the several
lines after within authfile.c in the openssh package.  I confirmed
there is no elegant way to avoid or externally augment these checks as
it's currently programmed without patching and recompiling (or using
something like Microsoft Detours to fake out the external call to
pathconf() which is called by check_ntsec() -- very ugly).

I completely agree with the general guidance that these are important
checks as it prevents the user from accidentally exposing their
private keys.  In our environment, the check is returning a false
positive given our home directory permissions are tightly controlled
(immutable by end users, in fact) and some cross-domain administrative
groups are used to delegate control of the directories to certain
authorized personnel. Eliminating these groups from the DACL and
granting these personnel Backup/Restore rights on the entire filer
(hundreds of terabytes) is not a secure solution for us.  I'm guessing
others in a large corporate environment may find themselves in a
similar scenario.

I was able to modify the check to work for our scenario and recompile.
Obviously this isn't the ideal solution, but it looks like it's our
only path forward.

I still have to figure out why file ownership isn't recorded properly
--- if I figure that out, I'll let everyone know as well.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2015-04-03  2:57 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-04-01 19:56 File Permissions - Yet Another Question / Clarification Bryan Berns
2015-04-01 20:35 ` Andrey Repin
2015-04-01 21:33   ` Bryan Berns
2015-04-02  1:35     ` Andrey Repin
2015-04-02 13:01       ` Bryan Berns
2015-04-02 15:35         ` Andrey Repin
2015-04-02 18:27           ` Bryan Berns
2015-04-02 18:41             ` Achim Gratz
2015-04-02 19:03               ` Bryan Berns
2015-04-02 22:20                 ` Andrey Repin
2015-04-03  2:57                 ` Bryan Berns

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).