I have a little more time to work through what you originally wrote,
sans certain assumptions I had when I originally responded.
(And I didn't intend to post this off-list, so I'm posting it again, on list.
Note -- if you aren't sure how to code some simple test routines using the C
functions, let me know, and I'll post an example or two.)
On Sat, Jan 11, 2014 at 8:50 AM, Bob Goldberg <bobg.h...@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
Note that the man page says
------------------
If setfacl is used on a file system which does not support ACLs, set‐
facl operates on the file mode permission bits. If the ACL does not fit
completely in the permission bits, setfacl modifies the file mode per‐
mission bits to reflect the ACL as closely as possible, writes an error
message to standard error, and returns with an exit status greater than
0.
------------------
Now that's not being perfectly explicit, but it points in a certain direction.
To be perfectly certain what is happening in debian, you'll need to
look at the code, and try some snippets with some of the routines that
come up when you do a
man -k permissions
and so forth. Of course, you'll need to do the experiments as a user
that you are sure won't have hidden keyloggers and such in the
background, since you'll be sudo-ing or su-ing to root for certain
parts of the tests.
And then you'll need to take your results to an appropriate dev list
and ask questions.
Frankly, I am still surprised that you express surprise at the results
and are looking for something different. (What you are looking for, I
can't tell.)
> 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::---
As near as I could tell then, and as near as I can tell now, it's
doing exactly what you told it to do.
> So - Is there a way to force ACL perms to dictate the effective rights??
Are you perhaps looking for tools that tell you more detail than you
are seeing? You might have a point, there.
> FWIW:
> it APPEARS to me that the acl access check algorithm will not allow this.
> however - since the entire acl sub-system was "meant to increase granularity
> of permissions" - shouldn't acl ALWAYS override unix perms? is this a bug in
> the ACL algorithm?
The only way I can parse this question is the reason I made the
assumptions that colored my original response. Anyway, if you don't
understand why
after using, for example
man 2 access
man 3 eaccess
(both of which come up when you man -k permssions), I'll see if I can
remember which library calls get you a good look at the binary
permissions.
Remember that "ls -l" and "stat" have a rather restricted format for
reporting permissions, a format that did not consider the possibility
that rwx permissions would need to be reportable for more than other,
and effective/real user/group.
> === 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 !!
There is a reason for that. I remember reading about it when I
participated on the misc@openbsd list, but I don't remember the
specifics beyond that there are certain kinds of attacks that can be
closed off more effectively that way. Don't go ask on that list,
however, at least not without doing an awful lot more digging than you
have. The archives can be found on marc.info and other places if
general web searches don't turn it up for you.
> But my managers (members of group: chadm) must have full permissions in all
> sftp users' home dir's.
I see what you are trying to do and I still think it's a bad idea.
> So NEITHER my sftp user, NOR my managing group have write access to the home
> directory !?!?
Not unless you get the permissions set up in a way that the sftp
server can recognize as safe. Safety first.
And, yes, that conflicts with your desire to let the manager users
play at will in your users' home directories.
> (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.)
Questions --
Are the users supposed to be able to log in via ssh, and
when they do, are you trying to provide the same file system as under
sftp?
Is there some reason you wouldn't want to put a symbolic link to
their sftp home in their regular login home directory? I mean, if they
can ssh in and do anything useful, surely they can use cd and such
commands.
(And I'm pretty sure I wouldn't want to grant manager privileges to
any users that couldn't handle ssh logins and basic shell commands.
It's a question of willingness to learn rules and follow them, and a
question of statistical behavior, relative to understanding
administrative tasks.)
You might want to consider the file system structure sourceforge uses
for inspiration, BTW.
> [...]
>
--
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/CAAr43iOfofOw6=niajyo8-6tpnj-g1wykpzwwnh+-g9xdw6...@mail.gmail.com
