Re: permissions: can you force ACL to be effective over unix perms?
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.hahc@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.
Reply to: