On Thu, Sep 30, 2010 at 08:14:24PM -0400, Miles Nordin wrote:
> >> Can the user in (3) fix the permissions from Windows?
>
> no, not under my proposal.
Let's give it a whirld anyways:
> but it sounds like currently people cannot ``fix'' permissions through
> the quirky autotranslation anyway, certainly not to the point where
> neither unix nor windows users are confused: windows users are always
> confused, and unix users don't get to see all the permissions.
No, that's not right. Today you can fix permissions from any NFSv4
client that exports an NFSv4-style ACL interface to users. You can fix
permissions from Windows. You can fix permissions a local Solaris
shell. You can also fix permissions from NFSv3 clients (but you get
POSIX Draft -> ZFS translated ACLs, which are confusing because they
tend to result in DENY ACEs being scattered all over). You can also
chmod, but you lose your ACL if you do that.
> >> Now what?
>
> set the unix perms to 777 as a sign to the unix people to either (a)
> leave it alone, or (b) learn to use 'chmod A...'. This will actually
> work: it's not a hand-waving hypothetical that just doesn't play out.
I would think that 777 would invite chmods. I think you are handwaving.
> What I provide, which we don't have now, is a way to make:
>
> /tub/dataset/a subtree
>
> -rwxrwxrwx in old unix
> [working, changeable permissions] in windows
>
> /tub/dataset/b subtree
>
> -rw-r--r-- in old unix
> [everything: everyone] in windows, but unix permissions
> still enforced
>
> this means:
>
> * unix writers and windows writers can cooperate even within a single
> dataset
>
> * an intuitive warning sign when non-native permissions are in effect,
>
> * fewer leaked-data surprises
I don't understand what exactly you're proposing. You've not said
anything about how chmod is to be handled.
> If you accept that the autotranslation between the two permissions
> regimes is total shit, which it is, then what I offer is the best oyu
> can hope for.
If I could understand what you're proposing I might agree, who knows.
But I do think there's other possibilities, some probably better than
what you propose (whatever that is).
Here's a crazy alternative that might work (or not): allow users to
pre-configure named ACLs where the names are {owner, group, mode}.
E.g., we could have:
.zfs/ACLs/<user>/[<group>:][d|-]<permissions>[.inherit]
^ ^^^ ^
| | |
+-- owned by | |
<user> +-- applies to |
directory |
or other |
objects |
|
see below
When chmod()ing an object... ZFS would search for the most specific
matching file in .zfs/ACLs/ and, if found, would replace the chmod()ed
object's ACL with that of the .zfs/ACLs/... file found. The .inherit
suffix would indicate that if the chmod() target's parent directory has
inherittable ACEs then they will be groupmasked and added to the ACEs
from the .zfs/ACLs/... file to produce a final ACL.
E.g., a chmod(0644) of /a/b/c/foo (say, a file owned by 'joe' with group
'staff', with /, /a, /a/b, and /a/b/c all being datasets), where c has
inherittable ACEs would cause ZFS to search for
.zfs/ACLs/joe/staff:-rw-r--r--.inherit, .zfs/ACLs/joe/-rw-r--r--.inherit,
zfs/ACLs/joe/staff:-rw-r--r--, and .zfs/ACLs/joe/-rw-r--r--, first in
/a/b/c, then /a/b, then /a, then /.
I said this is "crazy". Is it? I think it probably is. This would
almost certainly prove to be a hard-to-use design. Users would need to
be educated in order to not be surprised... OTOH, it puts much more
control in the hands of the user. These named ACLs could be inheritted
from parent datasets as a way to avoid having to set them up too many
times. And with the .inherit twist it probably has enough granularity
of control to be useful (particularly if users are dataset-happy).
Finally, these could even be managed remotely.
I see zero chance of such a design being adopted.
It'd be better, IMO, to go for non-POSIX-equivalent groupmasking and
translations of POSIX mode_t and POSIX Draft ACLs to ZFS ACLs. For
example: take the current translations, remove all owner@ and group DENY
ACEs, then sort any remaining user DENY ACEs to be first, and any
everyone@ DENY ACEs to be last. The results would surely be surprising
to some users, but the kinds of mode_t and POSIX Draft ACLs where
surprise is likely are rare.
That's two alternatives right there.
Nico
--
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
