[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.2

[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.2

[Corinna Vinschen]

Hi Cygwin friends and users,


I released a new TEST version of Cygwin, 2.3.0-0.2.

Difference to -0.1 is a fix for a minor problem in kernel object ACL
handling, probably unnoticed by most.

So the -0.1 release message still applies:

This is the "new POSIX ACL handling reloaded" release.

In local testing I successfully integrated AuthZ into the current Cygwin
code to generate more correct user permissions by being able to generate
effective permissions for arbitrary users.

This success convinced me that it might be possible to pick up the POSIX
permission rewrite originally targeted for the 2.0.0 release and try to
update it using AuthZ and generally revamp it to reflect effective
permissions better.

My local testing looks good, but this is a major change, so this code
really needs a lot more testing in various scenarios.  Especially
some Windows ACLs created in corporate environments are often a hard
nut to crack, and the example from

https://cygwin.com/ml/cygwin/2015-04/msg00513.html

which was the ultimate downfall of the original implementation is
the stuff which needs some good testing.

There's, as usual, a downside: AuthZ leans a bit to the slow side.
Cygwin caches information already gathered once on a per-process basis,
but in locally crafted worst case scenarios (`ls' on lots of file owned
by lots of different users and groups) the slowdown may be up to 25%.
But that's really just a worst case, in the usual scenarios the slowdown
should be mostly unnoticable.

To alleviate the problem, the AuthZ code is fortunately only called for
non-Cygwin ACLs and Cygwin ACLs created before this release.  Within a
pure Cygwin environment (e.g., some build directory only used with
Cygwin tools) AuthZ should be practically unused.

Apart from the aforementioned code changes to "just do it right", there
are two additional changes I implemented for this new POSIX ACL revamp
release:

- I reverted the questionable change I added to 2.0.0-0.7 in terms of
  chmod group permission handling.  The original description of this
  change was:

    If you have a non-trivial ACL with secondary accounts and thus a
    mask value, chmod is supposed to change only the mask, not the
    permissions of the primary group.  However, if the primary group has
    few permissions to begin with, the result is really surprising.  ls
    -l would, e.g., show read/write perms for the group, but the group
    might still have only read perms.

    Personally I find this chmod behaviour really, really bad, so I took
    the liberty to change it in a way which gives a much less surprising
    result:  If you call chmod on a non-trivial ACL, the group
    permissions will be used for the primary group and the mask.

- setfacl(1) now accepts the combination of the -b and -k options, just as
  on Linux (here's looking at you Achim ;)).

As for the description what this implementation strives for, please see
http://linux.die.net/man/5/acl

All changes in this release so far:

============================================================================

What's new:
-----------

- New, unified implementation of POSIX permission and ACL handling.  The
  new ACLs now store the POSIX ACL MASK/CLASS_OBJ permission mask, and
  they allow to inherit the S_ISGID bit.  ACL inheritance now really
  works as desired, in a limited, but theoretically equivalent fashion
  even for non-Cygwin processes.

  To accommodate Windows default ACLs, the new code ignores SYSTEM and
  Administrators group permissions when computing the MASK/CLASS_OBJ
  permission mask on old ACLs, and it doesn't deny access to SYSTEM and
  Administrators group based on the value of MASK/CLASS_OBJ when
  creating the new ACLs.

  The new code now handles the S_ISGID bit on directories as on Linux:
  Setting S_ISGID on a directory causes new files and subdirs created
  within to inherit its group, rather than the primary group of the user
  who created the file.  This only works for files and directories
  created by Cygwin processes.

- posix_madvise(POSIX_MADV_WILLNEED) now utilizes OS functionality available
  starting with Windows 8/Server 2012.  Still a no-op on older systems.

- posix_madvise(POSIX_MADV_DONTNEED) now utilizes OS functionality available
  starting with Windows 8.1/Server 2012R2.  Still a no-op on older systems.

- sysconf() now supports returning CPU cache information:
  _SC_LEVEL1_ICACHE_SIZE, _SC_LEVEL1_ICACHE_ASSOC, _SC_LEVEL1_ICACHE_LINESIZE,
  _SC_LEVEL1_DCACHE_SIZE, _SC_LEVEL1_DCACHE_ASSOC, _SC_LEVEL1_DCACHE_LINESIZE,
  _SC_LEVEL2_CACHE_SIZE, _SC_LEVEL2_CACHE_ASSOC, _SC_LEVEL2_CACHE_LINESIZE,
  _SC_LEVEL3_CACHE_SIZE, _SC_LEVEL3_CACHE_ASSOC, _SC_LEVEL3_CACHE_LINESIZE,
  _SC_LEVEL4_CACHE_SIZE, _SC_LEVEL4_CACHE_ASSOC, _SC_LEVEL4_CACHE_LINESIZE


What changed:
-------------

- setfacl(1) now allows to use the -b and -k option combined to allow reducing
  an ACL to only reflect standard POSIX permissions.


Bug Fixes
---------

- Fix a hang when stracing a forking or spawning process without activating
  stracing of child processes.
  Addresses: https://cygwin.com/ml/cygwin/2015-08/msg00390.html

- Fix long-standing potential SEGV on 32 bit Cygwin when the dynamic loader
  for OS functions fails to load a function on Windows 7 or later.
  Addresses: No actual bug report known.

- sysconf _SC_NPROCESSORS_CONF and _SC_NPROCESSORS_ONLN now handle more than
  64 CPUs on Windows 7 and later.

============================================================================


Have fun,
Corinna

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

--
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.3.0-0.2

[Achim Gratz]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> I released a new TEST version of Cygwin, 2.3.0-0.2.
> 
> Difference to -0.1 is a fix for a minor problem in kernel object ACL
> handling, probably unnoticed by most.

Both these versions have a new problem with UID/GID mapping from AD, my user
account should list as

uid=1124017(gratz) gid=1049089(Domain Users) groups=1049089(Domain Users),...

but gets listed as

uid=1124017(DOM+User(75441)) gid=1124017
groups=1124017,1049089(DOM+Group(513)),...

So somehow the UID ends up in the GID list and the UID and some well-known
GID get translated as if they were from a foreign domain.  The getent passwd
output from both versions is the same as the release versions.


Regards,
Achim.


--
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.3.0-0.2

[Corinna Vinschen]

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

On Sep  4 14:36, Achim Gratz wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > I released a new TEST version of Cygwin, 2.3.0-0.2.
> > 
> > Difference to -0.1 is a fix for a minor problem in kernel object ACL
> > handling, probably unnoticed by most.
> 
> Both these versions have a new problem with UID/GID mapping from AD, my user
> account should list as
> 
> uid=1124017(gratz) gid=1049089(Domain Users) groups=1049089(Domain Users),...
> 
> but gets listed as
> 
> uid=1124017(DOM+User(75441)) gid=1124017
> groups=1124017,1049089(DOM+Group(513)),...
> 
> So somehow the UID ends up in the GID list and the UID and some well-known
> GID get translated as if they were from a foreign domain.  The getent passwd
> output from both versions is the same as the release versions.

I have no idea what that is.  There's no change at all between 2.2.1
and this 2.3.0 test release in terms of account handling.  Not at all.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.2

[Achim Gratz]

Corinna Vinschen writes:
> I have no idea what that is.  There's no change at all between 2.2.1
> and this 2.3.0 test release in terms of account handling.  Not at all.

…but switching back to v2.2.1 cleared that up.  I can't look at it in
any detail right now or during the next two weeks.  I've only tested it
on 32bit in case that makes a difference (however unlikely).


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

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

--
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.3.0-0.2

[Corinna Vinschen]

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

On Sep  4 20:51, Achim Gratz wrote:
> Corinna Vinschen writes:
> > I have no idea what that is.  There's no change at all between 2.2.1
> > and this 2.3.0 test release in terms of account handling.  Not at all.
> 
> …but switching back to v2.2.1 cleared that up.  I can't look at it in
> any detail right now or during the next two weeks.  I've only tested it
> on 32bit in case that makes a difference (however unlikely).

Not in my case, no.  I specificially installed 2.3.0-0.2 on both,
32 and 64 bit, and in both cases the output from `id' looks
perfectly normal:

$ $ id
uid=1049577(corinna) gid=1049701(vinschen) groups=1049701(vinschen),559(Performance Log Users),545(Users),14(REMOTE INTERACTIVE LOGON),4(INTERACTIVE),11(Authenticated Users),15(This Organization),66048(LOCAL),1049089(Domain Users),70145(Authentication authority asserted identity),1049148(Denied RODC Password Replication Group),401408(Medium Mandatory Level)

I also looked through the changes between 2.2.1 and 2.3.0-0.2 (in the
cygwin-acl branch since I didn't merge the POSIX ACL changes back into
master yet) and there's no change touching user and group SID<->uid/gid
mapping.  It's a complete mystery to me how anything in 2.3.0-0.2 might
be the culprit of what you observe.

Any chance you can bisect the cygwin-acl branch between commit
a669484b81f1b1b26fbc74c74fba0f2c05b77f5d and commit
f1c298977e1078a7ad23970f34c3bd56ce863df0
?


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]