On 15/01/14 00:13, Joel Rees wrote: > Caveat. I don't have the patience to work with ACLs, mostly because I > can't see how they could really work without bringing a system to its > knees. > > On Tue, Jan 14, 2014 at 8:04 AM, Bob Goldberg <bobg.h...@gmail.com> wrote: >> [...] >>> I may be wrong here, but how could ACLs override the native >>> permissions system randomly without opening tons of new opportunities >>> for discovering vulnerabilities? >> <snipped>
> > (I still, for example, didn't understand why each login user should > have his/its own associated group. Seemed like such a waste at the > time. Did not understand that allocating a user/group pair is > basically zero overhead over just allocating a user and sticking the > user in some general group like "user" or "admin". Didn't understand > that the advantage I thought I saw in using primary groups to collect > users into such groups was a mirage. Rambling here.) Private (primary) groups can be useful, I'm not sure what you mean by mirage but they do have problems that ACL don't. Non-teamplayer e.g:- chmod u-rwx,g-rx $someFile <snipped> I don't want to confuse or inflame the issue, as a result of Jon Dowlands recent post in this thread (he's correct I've had to reconsider what I posted. ACL's *can* modify/override UNIX permissions, though it's not that simple. It is not random, anarchaic or more insecure than UNIX permissions and groups. I'm trying to put together an unambiguous explanation of the benefits of ACL and retraction/clarification of my original post, and understand the OP's problem. Just doesn't look like I'm going to finish it tonight/this morning :( - I'm working through the OP's problem, but I still don't understand some parts of it (I'll post more questions later) and agree with you (Joel) that it doesn't "seem" to be the best approach. ACLs yes, the rest of the approach I'm not sure I properly understand (and so far I can't recreate Bob's problem. Kind regards. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52d543f0.9050...@gmail.com
