Re: permissions: can you force ACL to be effective over unix perms?

Joel;

i'm confused by your comments, which i'll address individually; with apologies in advance to the group for length, and content:

On Fri, Jan 10, 2014 at 6:41 PM, Joel Rees <joel.rees@gmail.com> wrote:

On Sat, Jan 11, 2014 at 8:50 AM, Bob Goldberg <bobg.hahc@gmail.com> wrote:
>
> So - Is there a way to force ACL perms to dictate the effective rights??

It seems to me that I would want to understand the answer to this
question before I try to use ACLs. Which means that, if I had to use
ACLs for work, I would tell the boss I need a block of time to make a
set of throw-away users and groups to test the results of things, to
make sure that I understand the results I get.

(Bosses who can't accept that kind of answer aren't fit to be bosses,
but that observation only helps one to find a way to do the necessary
job without taking the undeserved insults to heart. Or to tell the
boss he can have his job if things get really, really bad.)

1) the REASON i'm asking the question above (which is explicitly about ACLs) - IS BECAUSE I ALREADY HAVE SOME understanding of ACLs, but have a question pertaining to specific functionality/behavior. I'm asking the question because I'VE ALREADY GOT test users which i'm using as my test-lab to attempt to answer my own questions.

2) I think you misunderstand my use of "managers" - these are NOT my bosses - these are managers that work under me and on which, I WANT to impose certain working behaviors.

> FWIW:
> it APPEARS to me that the acl access check algorithm will not allow this.

I don't think you are understanding your results. (But I may be wrong.
I don't use ACLs.)

i'm ALMOST speechless.

1) i think my question implicitly shows I DO UNDERSTAND my results. My question relates directly to how ACLs are effecting my results. Further it shows what I think the crux of my problem is - illustrating that I have made an attempt to do considerable research on the problem.

2) "you don't use ACLs" ???? then why are you even responding, if you don't understand the topic on which i'm querying ????

You may question the sanity of my underlying premise, or goal - and that is welcome - but CONSTRUCTIVE criticism is appreciated.

> however - since the entire acl sub-system was "meant to increase granularity
> of permissions" - shouldn't acl ALWAYS override unix perms?

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.

> is this a bug in
> the ACL algorithm?

8-o

not sure what's surprising here.

I've laid out my understanding of ACLs, and by the stated intent of the ACL sub-system (in the dpkg desc.), my results appear to demonstrate a divergence in observed behavior, from my interpretation of the stated intent.

The whole point of my email, is asking the community to either show me where I'm wrong, or confirm that I may have found a bug; and/or to tell me how to do this, assuming my understanding is correct.

> === end of my question; begin additional info ===
>
> because I KNOW someone will want to know why this is a problem - here's why,
> and I hope you're not sorry you asked !! :-)
>
> 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. My desire to work around this default behavior would seem to already IMPLY i don't fully know why. I don't see my desires as being detrimental to the security that openssh provides, because i'm enhancing security with ACL - though i'm sure openssh doesn't know that. :)

PLUS: There's a difference between chroot'ing a user, which REQUIRES a complete root environment; and internal-sftp's chroot'ing, which was added to sftp to explicitly avoid the need for a complete root environment.

IF A USER IS INTERNAL-SFTP-chroot'ed TO HIS HOME DIR, NO, I don't see why they shouldn't have write access to it.

if a managing group is not chroot'ed at all, NO, I do NOT see why that group shouldn't be able to have write access [as a group] inside a directory tree which chroot's other users whose group membership is unrelated.

regardless of why openssh works how it works - this doesn't change the fact that ACLs appear to have a bug in the underlying reason for their existence.

> But my managers (members of group: chadm) must have full permissions in all
> sftp users' home dir's.

Managers sometimes make really unreasonable demands. And sometimes
they make impossible demands.

again - these managers work under me - I'M THE ONE imposing these demands - which are hardly impossible. I've already even shown one solution - AND explained why I dislike that solution.

I apologize for not explaining this better, I can see how my statement was misunderstood.

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. 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.

> (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.

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.

> 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 you understand why?)

why are you asking me why again? are you trying to help me answer my questions, or imply your superior knowledge is off limits to me unless i understand all the inner reasoning's?

I don't have to know how a car works to drive it.

I'm just trying to use ACLs to solve my problem. I don't need to know the inner logic of windoze or why that was a null argument.

in fact, IT WASN'T AN ARGUMENT AT ALL! - that whole paragraph was a joke! I would NEVER host an ftp server on such an insecure, unreliable O/S !! Hence my denigrating reference.

Otherwise, take the time and go back and make sure that you understand
the results of your initial experiments, even if it means "service
overtime". (Or if the boss has been getting too much service overtime
from you, .... )

I DID take the time - as can be seen in the explicit specificity of my question, and accompanying details supporting my suppositions.

===========

Joel -

I try to tread very carefully in forums where the people providing answers and advise are not being paid to do so. They help out others from their own generosity of their time and knowledge.

I've re-read my response MANY times, and hope that it's not erroneously strong in the tone i've used.

from the content and tone of your comments, it APPEARS:

- you attempt to speak on a topic which you admit, you have no experience with (ACLs).

- you "answer" with nebulous questions that seem intended to demonstrate your superior knowledge in the area, but provide no details to backup whatever you're implying.

I apologize in advance if i've misinterpreted, but there isn't one thing you've said in your reply, that enlightens me, furthers my knowledge on the topic, or points me toward other resource(s) that do either of those things. Nor does it ask for further clarification in area's I may have failed to communicate well.

I spent a lot of time trying to make sure my post, and its use of everyone's time, was as concise, and to the point as possible. I provided LIGHT background about my scenario to give perspective.

I intended this question's scope to focus on the ACL problem i'm having. Maybe by attempting to provide background perspective, I've called into question my underlying thought process (which i welcome), but then I didn't provide enough justification to support how i got there.

I have, in other threads, tried to find the best way to accomplish my end goal. It seemed that this might be the best solution. I am always open to being wrong.

If you're telling me i'm wrong, you're not explaining how or why i'm wrong.

- Bob