This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]


Corinna Vinschen writes:
> You may be right here.  The problem is that we have two kinds of ACLs
> to handle, the ones created by Windows means, and the ones created
> by recent or older Cygwin versions.  It's rather bad that we can't
> distinguish them.

IÂthought that this was the point of the NULL SID ACL entries?

> But then, how do you check an arbitrary ACL for the effective rights
> it creates for all affected parties?  I may be missing some API function.
> but I don't see a Windows function generating some kind of effective
> ACL.  There's only the function AccessCheck() which gets a token and an
> ACL as input and then tells you the effective rights of the user with
> this token.  This gets very slow and complicated, very quickly.


> I hate to admit defeat, but it also seems that the method I used to
> handle real vs. effective rights just doesn't work as desired.  In
> theory we don't want the DENY ACEs having any effect before visiting the

I don't think the ACL rules on Windows are made for that due to the
early-out aspect of their semantics.

> This needs yet another rewrite, but this will take a lot longer than
> this first cut.  I guess we should create a new Cygwin release without
> this new ACL handling change for now to get the bugfixes out.

Yes, getting the fixes out and shelving the ACL part for some
re-thinking seems like a good idea.

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

Wavetables for the Waldorf Blofeld:

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]