This is the mail archive of the
mailing list for the Cygwin project.
Re: Shares with strange ACL settings
- From: Achim Gratz <Stromeko at nexgo dot de>
- To: cygwin at cygwin dot com
- Date: Fri, 14 Aug 2015 20:25:11 +0200
- Subject: Re: Shares with strange ACL settings
- Authentication-results: sourceware.org; auth=none
- References: <20150812152601 dot GL13029 at calimero dot vinschen dot de> <loom dot 20150812T172703-7 at post dot gmane dot org> <20150812155817 dot GN13029 at calimero dot vinschen dot de> <878u9g9y6b dot fsf at Rainer dot invalid> <20150812183220 dot GO13029 at calimero dot vinschen dot de> <87vbck8h92 dot fsf at Rainer dot invalid> <20150813163302 dot GB28349 at calimero dot vinschen dot de> <20150813175302 dot GD28349 at calimero dot vinschen dot de> <20150814082959 dot GE28349 at calimero dot vinschen dot de> <loom dot 20150814T125223-728 at post dot gmane dot org> <20150814134552 dot GG28349 at calimero dot vinschen dot de>
Corinna Vinschen writes:
> Cool, thanks for your quick feedback.
Thanks for the snapshot!
> We should just be aware that this is ultimately a kludge. I think I now
> finally understand what would have to be done to get a generic solution
> which results in correct POSIX permission evaluation for any current
> user and any file ACL. However, from some preliminary testing it seems
> the generic solution has at least two downsides:
> - It's slow (AuthZ code, setting up and breaking down user/group contexts
> for each checked file...)
> - It would always contact the AD when trying to fetch info for AD users,
> which is bad for remote machines not or slowly connected to the AD server.
I think we've came to the same conclusion (modulo the question of
whether AuthZ would be usable for this) some time ago. My personal take
on this is that the "kludge" is likely better than both what we had
before and the result of the pre-snapshot ACL evaluation. If that also
solves the problem of denying oneself file access by simply copying a
file with carefully crafted ACL, then I would say it's good enough for
most circumstances. Probably not good enough to pass the Perl filemode
tests during build, but they have some problems in their design anyway.
> Anyway, this isn't pressing so it would be nice if you keep on
As I said, I need some time next week to switch things into a mode where
problems could potentially show up. I don't expect any, but I don't
pretend to understand all the edge cases completely either.
> I'm planning to update to 2.2.1 only after a certain pipe problem just
> discussed on the #cygwin IRC channel is either fixed or settled any
> other way,
> Btw., can you please also check /proc/cpuinfo?
Yes, I have both AMD and Intel machines I can test this with.
> As discussed, Cygwin's emulation fell short on L3 cache info. I now
> added code to fetch L3 cache info as well as correct processor topology
> information on Intel CPUs. For AMD CPUs the topology and cache
> info was already fine. Linux does not show L3 cache info for AMD CPUs
> afaics, so I also didn't add that to Cygwin.
I can't test this with a new enough kernel for AMD, but perhaps someone
is testing some new iron/OS combination and I can get that information
from them. For Intel since some time the L3 cache size is shown (older
kernels would show you the per-node L2 cache size IIRC).
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf Blofeld V1.15B11:
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple