Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.4
On Dec 21 14:22, Thomas Wolff wrote: > On 23.10.2015 14:25, Corinna Vinschen wrote: > >On Oct 23 14:22, Corinna Vinschen wrote: > >>On Oct 23 11:06, Achim Gratz wrote: > >>>I don't have much time to test it right now (and won't have any time at all > >>>next week), but so far things look good. The problem with the 0.2 test > >>>version with UID/GID mapping and not recognizing the primary domain in some > >>>cases is gone (might have been a fluke anyway). Correlating the output > >>>from > >>>getfacl and icacls still requires some mental gymnastics, but I didn't find > >>>any obvious errors in the mode bits and ACL so far, which means that things > >>>like rsync (and some file tests) will now return the correct results for > >>>the > >>>cases I've looked at. > >>You won't believe how grateful I am having you testing this. Thank you! > >> > >>Would you mind to read the comment at the start of sec_acl.cc? > >https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/sec_acl.cc;hb=a8ec1e804ee9ba2d6f8304731e593dcf167c9836#l27 > > > >>I'd be > >>very interested in learning if the description is meaningful enough to > >>other developers. I also fear we need to have an improved documentation > >>explaining how this works and what NOT to do, e.g., reorder ACLs :| > Sorry for the late response... > The description is mostly meaningful. Just the coexistence of X and X_OBJ > entries isn't self-explanatory. I think I don't quite understand what you mean. As the developer I'm working under the assumption that the posix ACL description is known (not wanting to explain this from scratch in the sources). - USER_OBJ refers to the owner of the file. Only one such entry exists and is equivalent to the POSIX permission bits for the owner. - GROUP_OBJ refers to the owning group of the file. Only one such entry exsist, same as for USER_OBJ. - USER is an entry for a secondary user. There can be an arbitrary number up to a system-defined maximum of them. E.g, Peter is owner of the file, so he's the one refered to by the USER_OBJ entry. Paul has an additonal entry in the ACL with, say, rw- perms. Paul's permissions are given by a USER entry "user:paul:rw-". - GROUP is an entry for a secondary group. Any number up to a system-defined maximum entries are possible. E.g, the owner is Paul (USER_OBJ), the group is Users (GROUP_OBJ), there's an additional entry for the Administrators group giving them Full Access. This one is a GROUP entry "group:Administrators:rwx". Does this make it clearer? Is there still something missing in the source comment? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.4
On 23.10.2015 14:25, Corinna Vinschen wrote: On Oct 23 14:22, Corinna Vinschen wrote: On Oct 23 11:06, Achim Gratz wrote: I don't have much time to test it right now (and won't have any time at all next week), but so far things look good. The problem with the 0.2 test version with UID/GID mapping and not recognizing the primary domain in some cases is gone (might have been a fluke anyway). Correlating the output from getfacl and icacls still requires some mental gymnastics, but I didn't find any obvious errors in the mode bits and ACL so far, which means that things like rsync (and some file tests) will now return the correct results for the cases I've looked at. You won't believe how grateful I am having you testing this. Thank you! Would you mind to read the comment at the start of sec_acl.cc? https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/sec_acl.cc;hb=a8ec1e804ee9ba2d6f8304731e593dcf167c9836#l27 I'd be very interested in learning if the description is meaningful enough to other developers. I also fear we need to have an improved documentation explaining how this works and what NOT to do, e.g., reorder ACLs :| Sorry for the late response... The description is mostly meaningful. Just the coexistence of X and X_OBJ entries isn't self-explanatory. -- Thomas -- 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.4
Corinna Vinschen writes: > Ok, thanks a lot. I'm just wondering if I should really push this to > stable state, given the fact that I won't be available starting next > week until 2016-01-06. Well, that looks like it might be a common schedule for other folks as well, so you might just hold off until next year with the release. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs -- 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.4
On Dec 6 15:29, Achim Gratz wrote: > Corinna Vinschen writes: > >> VPN access with the worst possible terrestrial roundtrip has been tested > >> for the same case now and goes from 52s to ~1700s or a factor of 33. So > >> roundtrip delay adds an additional factor of about 3, but the server > >> response time seems to play the dominant role even in that scenario. > > > > Uhm... is that good or bad now?!? Do you still think adding this > > functionality is a good idea? > > For most of the things I did it worked OK, so I still think AuthZ should > be used. Ok, thanks a lot. I'm just wondering if I should really push this to stable state, given the fact that I won't be available starting next week until 2016-01-06. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgprA2ar5qOin.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.4
Corinna Vinschen writes: >> VPN access with the worst possible terrestrial roundtrip has been tested >> for the same case now and goes from 52s to ~1700s or a factor of 33. So >> roundtrip delay adds an additional factor of about 3, but the server >> response time seems to play the dominant role even in that scenario. > > Uhm... is that good or bad now?!? Do you still think adding this > functionality is a good idea? For most of the things I did it worked OK, so I still think AuthZ should be used. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves -- 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.4
On Dec 6 10:58, Achim Gratz wrote: > Achim Gratz writes: > > On my local laptop things look a bit different, a small ~5% subset of the > > test above goes from 20s to 200s and a different larger ~10% subset from 50s > > to 500s. While that hurts, the more usual case with many files from the > > same user doesn't feel any slower at the moment. The access through VPN > > will be interesting, though... > > VPN access with the worst possible terrestrial roundtrip has been tested > for the same case now and goes from 52s to ~1700s or a factor of 33. So > roundtrip delay adds an additional factor of about 3, but the server > response time seems to play the dominant role even in that scenario. Uhm... is that good or bad now?!? Do you still think adding this functionality is a good idea? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgps4NDyDNd7L.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.4
Achim Gratz writes: > On my local laptop things look a bit different, a small ~5% subset of the > test above goes from 20s to 200s and a different larger ~10% subset from 50s > to 500s. While that hurts, the more usual case with many files from the > same user doesn't feel any slower at the moment. The access through VPN > will be interesting, though... VPN access with the worst possible terrestrial roundtrip has been tested for the same case now and goes from 52s to ~1700s or a factor of 33. So roundtrip delay adds an additional factor of about 3, but the server response time seems to play the dominant role even in that scenario. 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
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.4
On Oct 27 10:53, Achim Gratz wrote: > Am 27.10.2015 um 10:27 schrieb Corinna Vinschen: > >>That test is almost as bad as it can ever get. Given that enumerating all > >>AD accouts with mkpasswd takes about 2 hours and I'm doing something very > >>similar here, I'm not even surprised. I was more surprised to see the > >>server go so fast, but my guess is that it can use jumbo frames to talk to > >>the AD. > > > >Ok, so you don't seem to think this is a major drawback. > > I didn't say I would not like to see it run faster. Me neither. No wonder Windows largely skips showing effective permissions unless explicitely requested by the user. > But considering the > alternatives, working correctly all the times at the current speed seems to > cover my more typical uses a lot better. Ok. > >No worries. I'm mulling over the idea to release 2.3.0 this week > >without the new ACL handling code to get the latest fixes out of the > >door first and push this stuff into a 2.4.0 release in November. > > As long as you keep reminding us which snapshot has the new ACL handling > code, that is OK with me. I guess you should better use the latest test releases, which I'll always build with the new ACL handling. The snapshots are rather for quick&dirty testing the latest changes. > I will want to push out the snapshot in a week or > two and remove some of my workarounds for ACL corrections and/or noacl > mounted directories in order to see if these things are working now for > real. Cool. I'm looking forward to it. > >>>Given the above result, I'm wondering if we can afford using AuthZ at > >>>all. OTOH I don't see any other way to get the correct POSIX permissions > >>>from a non-Cygwin ACL :( > >> > >>If you really want fast but incorrect there's always the "noacl" mount > >>option. > > > >Right. OTOH, maybe we could enhance the "acl" mount option? > > > >"acl" -> "quickacl" -> "noacl"? > > Let's worry about that middle ground scenario when the ACL code has proven > itself. The danger here is that the edge cases that will make problems are > not easy to spot before you run into them Good point. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpkGgOyyiDjx.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.4
Am 27.10.2015 um 10:27 schrieb Corinna Vinschen: That test is almost as bad as it can ever get. Given that enumerating all AD accouts with mkpasswd takes about 2 hours and I'm doing something very similar here, I'm not even surprised. I was more surprised to see the server go so fast, but my guess is that it can use jumbo frames to talk to the AD. Ok, so you don't seem to think this is a major drawback. I didn't say I would not like to see it run faster. But considering the alternatives, working correctly all the times at the current speed seems to cover my more typical uses a lot better. No worries. I'm mulling over the idea to release 2.3.0 this week without the new ACL handling code to get the latest fixes out of the door first and push this stuff into a 2.4.0 release in November. As long as you keep reminding us which snapshot has the new ACL handling code, that is OK with me. I will want to push out the snapshot in a week or two and remove some of my workarounds for ACL corrections and/or noacl mounted directories in order to see if these things are working now for real. Given the above result, I'm wondering if we can afford using AuthZ at all. OTOH I don't see any other way to get the correct POSIX permissions >from a non-Cygwin ACL :( If you really want fast but incorrect there's always the "noacl" mount option. Right. OTOH, maybe we could enhance the "acl" mount option? "acl" -> "quickacl" -> "noacl"? Let's worry about that middle ground scenario when the ACL code has proven itself. The danger here is that the edge cases that will make problems are not easy to spot before you run into them -- Achim. (on the road :-) -- 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.4
On Oct 26 17:03, Achim Gratz wrote: > Am 26.10.2015 um 11:07 schrieb Corinna Vinschen: > >Erm, really? I tested this locally with a directory with hundreds > >of files, each of which belonged to another user or group, and that > >resulted in a 25% slowdown. Not 1000%. Oh boy. > > That test is almost as bad as it can ever get. Given that enumerating all > AD accouts with mkpasswd takes about 2 hours and I'm doing something very > similar here, I'm not even surprised. I was more surprised to see the > server go so fast, but my guess is that it can use jumbo frames to talk to > the AD. Ok, so you don't seem to think this is a major drawback. > >>While that hurts, the more usual case with many files from the > >>same user doesn't feel any slower at the moment. The access through VPN > >>will be interesting, though... > > > >Did you try this in the meantime? > > No, sorry. No worries. I'm mulling over the idea to release 2.3.0 this week without the new ACL handling code to get the latest fixes out of the door first and push this stuff into a 2.4.0 release in November. > >Given the above result, I'm wondering if we can afford using AuthZ at > >all. OTOH I don't see any other way to get the correct POSIX permissions > >from a non-Cygwin ACL :( > > If you really want fast but incorrect there's always the "noacl" mount > option. Right. OTOH, maybe we could enhance the "acl" mount option? "acl" -> "quickacl" -> "noacl"? > -- > Achim. > > (on the road :-) https://www.youtube.com/watch?v=qRKNw477onU Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpO0WoeU8GvR.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.4
Am 26.10.2015 um 11:07 schrieb Corinna Vinschen: Erm, really? I tested this locally with a directory with hundreds of files, each of which belonged to another user or group, and that resulted in a 25% slowdown. Not 1000%. Oh boy. That test is almost as bad as it can ever get. Given that enumerating all AD accouts with mkpasswd takes about 2 hours and I'm doing something very similar here, I'm not even surprised. I was more surprised to see the server go so fast, but my guess is that it can use jumbo frames to talk to the AD. While that hurts, the more usual case with many files from the same user doesn't feel any slower at the moment. The access through VPN will be interesting, though... Did you try this in the meantime? No, sorry. Given the above result, I'm wondering if we can afford using AuthZ at all. OTOH I don't see any other way to get the correct POSIX permissions from a non-Cygwin ACL :( If you really want fast but incorrect there's always the "noacl" mount option. -- Achim. (on the road :-) -- 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.4
On Oct 23 14:01, Achim Gratz wrote: > Corinna Vinschen cygwin.com> writes: > > There's, as usual, a downside: AuthZ leans a bit to the slow side. > > It's not too bad, as long as your network connection is fast (and fast means > short roundtrip time for an AD query). If I take each page fault as > reported by time as a proxy for an AD access, then it needs about three > times more roundtrips to the AD. > > On a server with almost perfect connectivity to the AD that increases the > wall-time of listing a very large directory with directories/files from many > users (about a quarter of all users in the AD, and not all from the local > domain) from 8 to 10 minutes. The CPU time as well as the network traffic > is neglible in both cases. > > On my local laptop things look a bit different, a small ~5% subset of the > test above goes from 20s to 200s and a different larger ~10% subset from 50s > to 500s. Erm, really? I tested this locally with a directory with hundreds of files, each of which belonged to another user or group, and that resulted in a 25% slowdown. Not 1000%. Oh boy. > While that hurts, the more usual case with many files from the > same user doesn't feel any slower at the moment. The access through VPN > will be interesting, though... Did you try this in the meantime? Given the above result, I'm wondering if we can afford using AuthZ at all. OTOH I don't see any other way to get the correct POSIX permissions from a non-Cygwin ACL :( Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpg6I0ufAUj_.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.4
Corinna Vinschen cygwin.com> writes: > There's, as usual, a downside: AuthZ leans a bit to the slow side. It's not too bad, as long as your network connection is fast (and fast means short roundtrip time for an AD query). If I take each page fault as reported by time as a proxy for an AD access, then it needs about three times more roundtrips to the AD. On a server with almost perfect connectivity to the AD that increases the wall-time of listing a very large directory with directories/files from many users (about a quarter of all users in the AD, and not all from the local domain) from 8 to 10 minutes. The CPU time as well as the network traffic is neglible in both cases. On my local laptop things look a bit different, a small ~5% subset of the test above goes from 20s to 200s and a different larger ~10% subset from 50s to 500s. While that hurts, the more usual case with many files from the same user doesn't feel any slower at the moment. The access through VPN will be interesting, though... 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.4
On Oct 23 14:22, Corinna Vinschen wrote: > On Oct 23 11:06, Achim Gratz wrote: > > I don't have much time to test it right now (and won't have any time at all > > next week), but so far things look good. The problem with the 0.2 test > > version with UID/GID mapping and not recognizing the primary domain in some > > cases is gone (might have been a fluke anyway). Correlating the output from > > getfacl and icacls still requires some mental gymnastics, but I didn't find > > any obvious errors in the mode bits and ACL so far, which means that things > > like rsync (and some file tests) will now return the correct results for the > > cases I've looked at. > > You won't believe how grateful I am having you testing this. Thank you! > > Would you mind to read the comment at the start of sec_acl.cc? https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/sec_acl.cc;hb=a8ec1e804ee9ba2d6f8304731e593dcf167c9836#l27 > I'd be > very interested in learning if the description is meaningful enough to > other developers. I also fear we need to have an improved documentation > explaining how this works and what NOT to do, e.g., reorder ACLs :| Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpegQDYsJPrx.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.4
On Oct 23 11:06, Achim Gratz wrote: > I don't have much time to test it right now (and won't have any time at all > next week), but so far things look good. The problem with the 0.2 test > version with UID/GID mapping and not recognizing the primary domain in some > cases is gone (might have been a fluke anyway). Correlating the output from > getfacl and icacls still requires some mental gymnastics, but I didn't find > any obvious errors in the mode bits and ACL so far, which means that things > like rsync (and some file tests) will now return the correct results for the > cases I've looked at. You won't believe how grateful I am having you testing this. Thank you! Would you mind to read the comment at the start of sec_acl.cc? I'd be very interested in learning if the description is meaningful enough to other developers. I also fear we need to have an improved documentation explaining how this works and what NOT to do, e.g., reorder ACLs :| Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpiBfEl4OWg_.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.4
I don't have much time to test it right now (and won't have any time at all next week), but so far things look good. The problem with the 0.2 test version with UID/GID mapping and not recognizing the primary domain in some cases is gone (might have been a fluke anyway). Correlating the output from getfacl and icacls still requires some mental gymnastics, but I didn't find any obvious errors in the mode bits and ACL so far, which means that things like rsync (and some file tests) will now return the correct results for the cases I've looked at. 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