Re: permissions: can you force ACL to be effective over unix perms?
On Sat, Jan 11, 2014 at 8:50 AM, Bob Goldberg <bobg.hahc@gmail.com> wrote:
> running wheezy.
>
> I have a dir w/ unix perm = 750
> IE:
> root@wheezy:/home/chtest/home# ls -l
> drwxr-s--- 3 root chadm 4096 Jan 9 14:12 ftptest
>
> I added an acl g perm using: # setfacl -m g:chadm:rwx ftptest
> this, unfortunately, changes unix perm to = 770
> IE: V
> drwxrWs---+ 3 root chadm 4096 Jan 9 14:12 ftptest
>
> I then re-removed unix g w perm: # chmod g-w ftptest
> IE:
> drwxr-s---+ 3 root chadm 4096 Jan 9 14:12 ftptest
>
> This action causes unix perms to OVERRIDE acl perms - NOT what I want:
> IE:
> root@wheezy:/home/chtest/home# getfacl ftptest
> # file: ftptest
> # owner: root
> # group: chadm
> # flags: -s-
> user::rwx
> group::r-x vvvvvvvv
> group:chadm:rWx #effective:r-x
> mask::r-x ^^^^^^^^
> other::---
>
>
> 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.)
> 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.)
> 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? (Granularity is, itself, a problem,
as near as I can tell, although I know I'm going to get a lot of flack
from certain participants in this list for saying so.)
> is this a bug in
> the ACL algorithm?
8-o
> === 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?
> 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.
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.)
> 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?
> (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.)
> 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 !?!?
>
> TIA - Bob
>
*** MSWindows is a null argument. ***
(Do you understand why?)
I strongly recommend the shared directory approach for sharing, and if
your managers really insist on having access to things they shouldn't
have, set sudo up to give them that access (and nothing else), and use
some appropriate aliases and indirecting scripts so they can sense
their importance without understanding that they are just using sudo
to override their own systems' security. ("Oh, cool! I have this
little tool called "eavesdrop" that allows me to peek into all the
users' home directories!" Or whatever.)
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, .... )
--
Joel Rees
Be careful where you see conspiracy.
Look first in your own heart.
Reply to: