from:"Bryan"

On Tue, Apr 14, 2015 at 4:00 AM, Corinna Vinschen
corinna-cyg...@cygwin.com wrote:

 Orphaned SIDs shouldn't happen.  Disabling accounts, ok, but removing
 them?  I don't know.  So the question is, if there's no account with
 these SIDs anymore, why aren't these SIDs removed from the ACLs?
 It's not only Cygwin.  These SIDs also unnecessarily slow down each
 single access check of the OS.


In principal, I agree 100%.  Unfortunately, in some large enterprise
environments removal of orphaned SIDs rarely happens on a regular
basis.   The best way to manage this is typically to only delegate
access via groups and have those groups aligned to the file system
structure in some way (which tends to change less in practice than
company organizational structure).  Still, when you've got dozens of
people starting/leaving every week, per account permission are
occasionally established enumerating more a petabyte of data across
several sites to cleanup ACEs is certainly possible but not on the top
list of things to do (and mass alteration of ACLs carries some
liability to it).  Don't get me wrong, my anal retentive nature makes
me cringe when I see an orphaned SID; it's just the reality of the
situation.

That said, the origin of my question was actually not due to
unresolvable SIDs to due to removed accounts --- it was just the
easiest one to describe. The reason I noticed this is because we have
some NTFS assignments via local groups on a remote computers (and
those local groups then have nested Active Directory groups).  So the
ACE has REMOTECOMPUTER\Group vice DOMAIN\Group.  When Cygwin attempts
to retrieve information on these accounts, it seems to fail and causes
delays.  So with the newer versions of Cygwin, doing an 'ls -l' went
from 2 seconds to more than 30 seconds on some particular file
directories.

As Achim alluded, 'noacl' may be be the way to go for us, but I was
just asking the question in the even there was a configurable setting
or a feature enhancement that could be integrated to deal with these
scenarios.  Of course, 'noacl' seems to mark group / other masks as
readable so apps that do permissions checks on these files will return
inaccurate results :-(.

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

Re: Making Cygwin More Tolerant of Orphaned SIDs?

On Tue, Apr 14, 2015 at 4:00 AM, Corinna Vinschen

 The problem is that Cygwin, or any other tool trying to resolve SIDs
 doesn't know a SID won't resolve before it tried.  And then it's an
 OS function which takes its time.  It's like checking for network
 machines providing shares.  Sometimes this test takes ages, but in
 this case, fortunately, you see that it takes ages in Explorer as
 well.

 As for ACLs, you can alleviate the problem somewhat by running cygserver
 on the machine, which allows to cache SIDs for all processes.  So only
 the first process trying the SID will take time, followup processes will
 get the cached results from cygserver.

 Other than that, except for ignoring ACLs entirely (noacl) I have
 no idea how to solve this problem differently.

Yes, I understand there's nothing Cygwin can do beforehand -- that
means sense.  I guess what I'm saying is that Cygwin doesn't appear to
be caching SIDs in certain scenarios.

For example, I create a whole bunch of files (like 5000),  I use
icacls to append a new ACE.  Then I do a 'time ls -l
/cygdrive/c/somedir/*'.  Takes four seconds.  In the same Cygwin
session, I remove the local group (net localgroup testgroup /delete).
 I do the same 'time ls -l /cygdrive/c/somedir/*'.  Takes 20 seconds.
Subsequent runs in the also take 20 seconds.  Since I'm able to
continue to see the slowdown in the same session, cygserver wouldn't
help right?

Is the above expected?  If not and it's something you're willing to
take a look at, I can certainly come up with a little script to
demonstrate the issue.

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

Re: Making Cygwin More Tolerant of Orphaned SIDs?

On Tue, Apr 14, 2015 at 10:53 AM, Corinna Vinschen
corinna-cyg...@cygwin.com wrote:
 On Apr 14 07:24, Bryan Berns wrote:
 On Tue, Apr 14, 2015 at 4:00 AM, Corinna Vinschen
 
  The problem is that Cygwin, or any other tool trying to resolve SIDs
  doesn't know a SID won't resolve before it tried.  And then it's an
  OS function which takes its time.  It's like checking for network
  machines providing shares.  Sometimes this test takes ages, but in
  this case, fortunately, you see that it takes ages in Explorer as
  well.
 
  As for ACLs, you can alleviate the problem somewhat by running cygserver
  on the machine, which allows to cache SIDs for all processes.  So only
  the first process trying the SID will take time, followup processes will
  get the cached results from cygserver.
 
  Other than that, except for ignoring ACLs entirely (noacl) I have
  no idea how to solve this problem differently.

 Yes, I understand there's nothing Cygwin can do beforehand -- that
 means sense.  I guess what I'm saying is that Cygwin doesn't appear to
 be caching SIDs in certain scenarios.

 For example, I create a whole bunch of files (like 5000),  I use
 icacls to append a new ACE.  Then I do a 'time ls -l
 /cygdrive/c/somedir/*'.  Takes four seconds.  In the same Cygwin
 session, I remove the local group (net localgroup testgroup /delete).
  I do the same 'time ls -l /cygdrive/c/somedir/*'.  Takes 20 seconds.
 Subsequent runs in the also take 20 seconds.  Since I'm able to
 continue to see the slowdown in the same session, cygserver wouldn't
 help right?

 Is the above expected?

 Yes.  Without cygserver, caching only works from parent to child process.
 One run of ls can't cache data for a parallel run of ls in trhe same
 session.  As, btw., explained in the documentation:

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

Alright, I'll give it a shot when I get back to my lab.  I suspect it
shouldn't take an additional 16 seconds to attempt to lookup account
information (and fail) on my two node test network so I'm curious how
much this will cut the time by.
If I setup cygserver with all the --no options set (reference:
https://cygwin.com/cygwin-ug-net/using-cygserver.html) since I don't
want any accidental cross-user information sharing, will that
effectively only provide the SID caching functionality or is there
other functionality to be wary of?

Thanks for everything!

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

Re: Making Cygwin More Tolerant of Orphaned SIDs?

On Tue, Apr 14, 2015 at 2:23 PM, Corinna Vinschen
corinna-cyg...@cygwin.com wrote:
On Apr 14 12:44, Bryan Berns wrote:
On Tue, Apr 14, 2015 at 10:53 AM, Corinna Vinschen
corinna-cyg...@cygwin.com wrote:
On Apr 14 07:24, Bryan Berns wrote:
For example, I create a whole bunch of files (like 5000), I use
icacls to append a new ACE. Then I do a 'time ls -l
/cygdrive/c/somedir/*'. Takes four seconds. In the same Cygwin
session, I remove the local group (net localgroup testgroup /delete).
I do the same 'time ls -l /cygdrive/c/somedir/*'. Takes 20 seconds.
Subsequent runs in the also take 20 seconds. Since I'm able to
continue to see the slowdown in the same session, cygserver wouldn't
help right?

Is the above expected?

Yes. Without cygserver, caching only works from parent to child process.
One run of ls can't cache data for a parallel run of ls in trhe same
session. As, btw., explained in the documentation:

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

Alright, I'll give it a shot when I get back to my lab. I suspect it
shouldn't take an additional 16 seconds to attempt to lookup account
information (and fail) on my two node test network so I'm curious how
much this will cut the time by.
If I setup cygserver with all the --no options set (reference:
https://cygwin.com/cygwin-ug-net/using-cygserver.html) since I don't
want any accidental cross-user information sharing, will that
effectively only provide the SID caching functionality or is there
other functionality to be wary of?

You don't have to disable anything. Just don't set the debug option
to avoid logging passwd entries.

Finally tested with cygserver (temporarily with debug on so I can see
what's going on). I can definitely see the one entry returned when I
run 'ls -l' over my whole collection of files while my test group
(LocalGroupTest) is still present. Sample log as follows:

/home/corinna/src/cygwin/cygwin-2.0.0/prerelease/cygwin-2.0.0-0.4.i686/src/newlib-cygwin/winsup/cygserver/pwdgrp.cc,
line 167: Request account information returns
BERNS-TEST+LocalGroupTest:S-1-5-21-1187188735-1394039937-4283913392-1011:197619:
error 0

If I delete the group while cygserver is running, the results continue
to be speedy. However, as soon as I delete the group and restart
cygserver, things go south. Performance is even worse than without
cygserver and there are entries for EVERY file that 'ls' is hitting
even though they all have the same group in the ACL so it appears the
'Unknown' users/groups are not being cached. Sample log as follows
(one of thousands of lines):

Request account information returns
Unknown+User:*:4294967295:4294967295:U-Unknown\User,S-1-5-21-1187188735-1394039937-4283913392:/:/sbin/nologin
error 0

Thoughts?

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

Making Cygwin More Tolerant of Orphaned SIDs?

2015-04-13 Thread Bryan Berns

Based on some rudimentary performance tests, it would appear that
Cygwin may repeatedly try to lookup information on a SID form an ACE
if cannot find a corresponding account which will undoubtedly
occur for orphaned SIDs.  If the volume being read is remote, this can
result in some massive slowdowns if there are many files in the
directory.  Is there any way to augment this behavior?

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

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-3

2015-04-13 Thread Bryan Berns

 On Apr 12 17:19, Bryan Berns wrote:
 On Sun, Apr 12, 2015 at 3:17 PM, Corinna Vinschen
 corinna-cyg...@cygwin.com wrote:

 V:\icacls touch-from-3
 touch-from-3 DOMAIN\Administrator:(R,W,D,WDAC,WO)
  DOMAIN\Domain Users:(R)
  Everyone:(R)
  BUILTIN\Administrators:(F)
  NT AUTHORITY\SYSTEM:(F)
  NT AUTHORITY\Authenticated Users:(M)
  BUILTIN\Users:(RX)

 I don't believe this is an ACL created by Cygwin 2.0.0 at all.
 It's missing the NULL deny ACE.

Now that I'm testing again, I think you're right; I had an older
installation on my backup drive try that I think somehow tainted one
of my sessions.  I'll include version information in my output in the
future.  Sorry!

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

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-3

2015-04-12 Thread Bryan Berns

On Sun, Apr 12, 2015 at 3:17 PM, Corinna Vinschen
corinna-cyg...@cygwin.com wrote:
 Hi Cygwin friends and users,


 New 2.0.0-0.3 test release.  It's supposed to fix the pty chmod problem
 reported in https://cygwin.com/ml/cygwin/2015-04/msg00240.html


Just a note: In 2.0.0-0.2, creating a file using touch on the root of
one of my drives resulted in the with the Windows GUI Security tabs
complaining about ACE order on the resultant file.  In 2.0.0-0.3,
Windows does not complain and the ACL looks quite a bit different
(shown below).  Not sure if this is a problem or not --- just wanted
to report the difference in case your fix had an unintended side
affect.  Given my heart skips a beat when I see DENY ACEs, I like the
new behavior behavior better.

V:\icacls v:
v: BUILTIN\Administrators:(OI)(CI)(F)
   NT AUTHORITY\SYSTEM:(OI)(CI)(F)
   NT AUTHORITY\Authenticated Users:(OI)(CI)(M)
   BUILTIN\Users:(OI)(CI)(RX)

Output from file created from 2.0.0-0.3:

V:\icacls touch-from-3
touch-from-3 DOMAIN\Administrator:(R,W,D,WDAC,WO)
 DOMAIN\Domain Users:(R)
 Everyone:(R)
 BUILTIN\Administrators:(F)
 NT AUTHORITY\SYSTEM:(F)
 NT AUTHORITY\Authenticated Users:(M)
 BUILTIN\Users:(RX)

Successfully processed 1 files; Failed processing 0 files

Output from file created from 2.0.0-0.2:

V:\icacls touch-from-2
touch-from-2 NULL SID:(DENY)(Rc,S,WEA,X,DC)
 DOMAIN\Administrator:(R,W,D,WDAC,WO)
 DOMAIN\Domain Users:(DENY)(S,X)
 NT AUTHORITY\Authenticated Users:(DENY)(S,X)
 BUILTIN\Users:(DENY)(S,X)
 DOMAIN\Domain Users:(RX)
 NT AUTHORITY\Authenticated Users:(RX,W)
 NT AUTHORITY\SYSTEM:(RX,W)
 BUILTIN\Administrators:(RX,W)
 BUILTIN\Users:(RX)
 Everyone:(R)

Successfully processed 1 files; Failed processing 0 files

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

Re: [TESTERS needed] New POSIX permission handling

2015-04-11 Thread Bryan Berns

That means, even if SYSTEM or Administrators have full access to the
file, the POSIX permssion bits will not reflect that fact.  And while
other users get access denied based on the mask value, SYSTEM and
Administrators will never get access denied based on the mask.

 If you want to put this to better use in larger settings it would seem
 preferrable if it was possible to define a list of users to treat this
 way in fstab.

 Nope, sorry, no configuration for this.  Either it's handled without
 any exception, or for SYSTEM only, or for SYSTEM+Admins.  But either
 way, we're doing it the same way on every system.

Damn.  I was about to reply with Achim's exact same thought --- like a
file in /etc with a list of SIDs.  I can empathize with Corinna's veto
though -- having a hundred tweak-able settings in Cygwin is
unmaintainable for the general populous.  I may apply a local patch to
extend this ability myself because Cygwin has become rather unusable
for users with home's on our network drives (given all the programs
that attempt to do sanity checks on group perms).

That said, I appreciate what has been integrated --- it will help in
several scenarios.  I will test the release this weekend.  Thanks for
all the hard work!

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

Re: Robocopy

2015-04-03 Thread Bryan Berns

On Thu, Apr 2, 2015 at 1:47 PM, Houder hou...@xs4all.nl wrote:
 2015/04/02 19:13:56 ERROR 5 (0x0005) Copying File 
 E:\Cygwin\home\jvdwater\.bash_history
 Access is denied.
 Waiting 30 seconds... Retrying...
 New File 689.bash_history

ROBOCOPY is very reliable and it's actually what I use to have folks
install Cygwin on our enterprise systems (i.e. I setup a master
replica of the install and they ROBOCOPY it down to their machines).
It works without fail unless they have a files in use.  If you throw
in /R:0, do you see any other files with access denied?  Might be a
good datapoint to confirm it's everything and not something specify
about bash_history.

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

Re: Should cygwin's setup*.exe be signed using Sign Tool?

 Has Cygwin considered signing the installer using Sign Tool? More info:
   
 https://msdn.microsoft.com/en-us/library/windows/desktop/aa387764%28v=vs.85%29.aspx
   
 http://blog.didierstevens.com/2008/12/31/howto-add-a-digital-signature-to-executables/

 I believe signing it this way would eliminate the unknown publisher; it 
 would also protect the many people who don't follow the current 
 signature-checking process.  This would create a strong barrier against code 
 subversion after release.

 The signed executable could also be signed using the current process, so you 
 don't need to *eliminate* any capability.  I can't provide a patch to do 
 this, obviously :-).

 --- David A. Wheeler

Ultimately, this is probably a Corinna question since I believe she
compiles the setup executable, but I'll provide my general input as an
software developer.

Firstly, the tools to sign an executable are certainly available as
part of the Windows SDK which is freely downloadable -- so no problem
there.   However, we would have to determine which publicly trusted
certificate to use (using a self-signed cert would likely produce the
same message) and is signing the executable the *right* thing to do.
Since the setup executable is responsible for running a whole bunch of
community contributed post-install executables as part of the
installation process, I'm not sure whether it'd be advisable to stamp
a particular individual's name or company's name on the executive
installer (e.g. Red Hat, for example).  If a tainted executable was
uploaded into the package repository and subsequently flagged, the
certificate authority may have to revoke the certificate which is
never good for publicity of the signer.  For most pieces of software,
the maintainer or the maintainers company's can very confidently vouch
for the content of the installation package and executables within it.
In the Cygwin world, this accountability is a little more distributed
between the package maintainers and source code contributors.  That
said, I have the upmost respect for the package maintainers and I've
never had any security problems with the Cygwin packages other than
stupid antivirus false positives and some dirty limericks that got
installed (my HR department didn't like that).

So that's my two cents.  For all I know the *real* reason it's not
signed is nobody had asked for it.

- 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

Re: File Permissions - Yet Another Question / Clarification

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

Re: File Permissions - Yet Another Question / Clarification

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

Re: File Permissions - Yet Another Question / Clarification

 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

Re: File Permissions - Yet Another Question / Clarification

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

Re: File Permissions - Yet Another Question / Clarification

2015-04-01 Thread Bryan Berns

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

File Permissions - Yet Another Question / Clarification

2015-04-01 Thread 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.

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

Re: Compatibility of binaries built with one version of cygwin with other versions of cygwin

2015-03-27 Thread Bryan Berns

Guaranteed might be a strong word - especially given the lack of a
guarantor; probably depends on whether the programmer has had to
workaround any nuances in the Cygwin library that may have changed in
later versions.  I think the library function exports have been the
same for awhile and I've personally had pretty good lucking simply
dropping in a new DLL file without issues.

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

Too Many Permissions Stripped In 1.7.35?

I honestly haven't read up exactly how Cygwin interprets NTFS
ACL/ACEs, but I remember seeing on the mailing list that a change was
made in 1.7.35 was made to permission handling.  It is preferable in
my organization that the SYSTEM account always have full control the
local file system.  When using chmod under 1.7.35, it looks like
permissions for SYSTEM get stripped (as well as some others).  Is this
the desired behavior?  If so, I'll workaround it somehow but just
wanted to verify before we release this much anticipated Active
Directory optimized version.  For context, I'm running as the default
Domain Administrator on a fresh install of Windows 8.1.

@@ Testing With 1.7.34 @@

$ uname -a
CYGWIN_NT-6.3 BERNS-WINDOWS 1.7.34(0.285/5/3) 2015-02-04 12:14 x86_64 Cygwin

$ mkdir TEST-34

$ chmod 750 TEST-34

$ icacls TEST-34
TEST-34 DOMAIN\Administrator:(F)
DOMAIN\Domain Users:(RX)
Everyone:(Rc,S,RA)
BUILTIN\Administrators:(OI)(CI)(F)
NT AUTHORITY\SYSTEM:(OI)(CI)(F)
BUILTIN\Users:(OI)(CI)(RX)
NT AUTHORITY\Authenticated Users:(M)
NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(M)
CREATOR OWNER:(OI)(CI)(IO)(F)
CREATOR GROUP:(OI)(CI)(IO)(RX)
Everyone:(OI)(CI)(IO)(RX)
Successfully processed 1 files; Failed processing 0 files

@@ Testing With 1.7.35 @@

$ uname -a
CYGWIN_NT-6.3 BERNS-WINDOWS 1.7.35(0.286/5/3) 2015-02-25 13:13 x86_64 Cygwin

$ mkdir TEST-35

$ chmod 750 TEST-35

$ icacls TEST-35
TEST-35 DOMAIN\Administrator:(F)
DOMAIN\Domain Users:(RX)
Everyone:(Rc,S,RA)
BUILTIN\Administrators:(OI)(CI)(RX)
NT AUTHORITY\SYSTEM:(OI)(CI)(RX)
BUILTIN\Users:(OI)(CI)(RX)
NT AUTHORITY\Authenticated Users:(RX)
NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)
CREATOR OWNER:(OI)(CI)(IO)(RX)
CREATOR GROUP:(OI)(CI)(IO)(RX)
Everyone:(OI)(CI)(IO)(RX)
Successfully processed 1 files; Failed processing 0 files

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

Re: Too Many Permissions Stripped In 1.7.35?

 That's not really a goal.  The SYSTEM permissions are kind of useless
 anyway, given that SYSTEM has permissions to read and write all files
 anyway.  I don't see that a rule to add SYSTEM permissions to all files
 accomplishes anything which isn't already available anyway.

I don't think this is true; see below when running as the system account:

V:\echo %USERNAME%
BERNS-WINDOWS$
V:\icacls V:\Test
V:\Test DOMAIN\Administrator:(OI)(CI)(F)
Successfully processed 1 files; Failed processing 0 files
V:\cd V:\Test
Access is denied.
V:\

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

Re: Too Many Permissions Stripped In 1.7.35?

 You just have to enable the SeBackupName and SeRestoreName privs.
 Try in Cygwin.  It does that automatically.

 For cases where you need to stick to the Windows ACLs, use noacl
 mounts.

Understood --- I can probably set SeBackupPrivilege /
SeRestorePrivilege as 'RequiredPriveleges' for the services that
depend on the system account having access via the ACLs.  Not being
used quite in the spirit of those privileges (i.e. for
backup/restore), but doable.  We'll also have to revise our
permissions model on our network filers since before running 'chmod
700' on a file wouldn't blow away our various administrative groups.

Like I said originally, just wanted to verify it was desired behavior
and it sounds like it is.  Thanks!

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

Re: Too Many Permissions Stripped In 1.7.35?

 That's an administrator account, not SYSTEM.

The BERNS-WINDOWS$ is the account the process was being run under
(launched via psexec -i -s) and is indeed the system account.  I ran
icacls just to display the current ACL on the directory (which does
not include the system account for the purpose of the test).  Sorry
for not being more clear. Regardless, Corinna clarified her assertion
was dependent on enabling Backup/Restore privileges for the process at
hand.

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

Re: Too Many Permissions Stripped In 1.7.35?