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? > > > ACLs DO OVERRIDE the native permissions - that's THE WHOLE POINT OF HAVING > THEM !! They DO NOT do so "randomly" - man setfacl, and see that, ACLs are > VERY explicit in how they override system perms. Actually, the man pages seem a little ambiguous to me, at precisely the point where you want to find a bug and I want to see the system utilities trying to provide ACL behavior without blowing holes in the permissions wide enough to sail aircraft carriers through. >> > is this a bug in >> > the ACL algorithm? >> >> 8-o >> > > not sure what's surprising here. Never mind my surprise. It doesn't seem to help you. > [...] >> > I'm using [openssh] internal-sftp to chroot users to their home dir. >> > internal-sftp's chroot DEMANDS that all dir's leading to home MUST be >> > root-owned, and NO g-w permissions !! >> >> Do you understand why? > > do i understand WHY? > > maybe i don't fully understand why. though to be blunt - i don't entirely > care why. You should. > [...] >> Nevertheless, sudo offers a solution to that false problem that is far >> more to the point. As long as you are careful not to take the easy >> route and put all the managers in the (unix) sudo group (or wheel, or >> root, etc.) > > sudo is NOT a solution. Well, that cuts off my best offer at a solution to your problem. > The whole point of ACLs is to provide a greater > level of detail in addressing problems of permission-ing. Thus you don't > have to give NON-admin users ANY access to admin level commands (ie: sudo). > > Further, my users don't know linux - they are simply using an sftp client to > talk to this server. You can't "sudo" inside an sftp client. > >> >> > So NEITHER my sftp user, NOR my managing group have write access to the >> > home >> > directory !?!? >> >> Are you really sure your managers want to do that? > > > absolutely - I WANT THEM TO DO THAT! > they are "sftp managers" - I WANT them to manage the contents of sftp-users' > home dir's ! > > Sorry for not making this point more clear. Well, now I'm wondering if you are having problems making sure they can access their own ftp home directories. Initially, I thought you were trying to provide them access to other users' home directories. My apologies if I misunderstood. >> > (yes, i know i can create another sub-dir they can get at, but i don't >> > want >> > to - that's sloppy, and un-intuitive.) >> >> It's not sloppy, and it's only counter-intuitive to people who don't >> understand security. (IMO, perhaps, but I have pretty strong reasons >> for saying so.) > > > it IS sloppy AND counter-intuitive TO linux noob users who don't understand > why they can't write files directly to their own private "home" dir. There was a time I thought it was sloppy. I didn't really understand Unix permissions, and I wasn't familiar with making sudo work for me. (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.) > This entire exercise is one I undertook ONLY because of my concerns over > security, and privacy, and my need and desire to provide not only a secure > environment, but a FRIENDLY (intuitive) one also. If you are having trouble giving them access to their own ftp home directories, I'm thinking that's not something to solve with ACLs. >> > This SEEMS like such a simple task. And it PAINS me to no end, that this >> > task would be relatively easy to implement under windoze - but seems >> > impossible to solve under linux !!??? >> > ...sup w/ dat !?!? >> > >> >> *** MSWindows is a null argument. *** >> > > at least we agree on that. :-) Do we? >> (Do you understand why?) >> > > why are you asking me why again? Microsoft built their empire providing tools that fool the users into believing they are doing things they are not doing. 80% good at getting the immediate visible results people want to see, not even 20% at the underlying stuff that is necessary to make the results usable on an on-going basis. Which is great for the support after-market. In other words, just because MSWindows has the buttons to push, you shouldn't believe that they have actually provided what you assert above that they provided. > [...] -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- 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/CAAr43iMsi8yKzrRrXeqkc=vhtqlsh-yquix17muhggs4byc...@mail.gmail.com