>> Can the user in (3) fix the permissions from Windows? no, not under my proposal.
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.
>> 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.
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
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.
My proposal also generalizes to other permissions autoconversion
problems:
* Future ACL translation stupidity that will happen as more bizarre
ACL mechanisms are invented, or underspecified parts of current
spec make different choices in different OS's.
- POSIX <-> NFSv4, Darwin <-> NFSv4
If Apple provides a Darwin <-> NFSv4 translation that's silly, a
match for Darwin NFS client IP's in the share string could put
these clients into a tagged ACL group.
- AFP <-> NFSv4
ACL's can be tagged by protocol for new weird protocols. If [new
protocol]'s ACLs are a subset of NFSv4 ACL's, then they can be
implemented by the bridge and apply to users who don't go through
the bridge. The [new protocol] bridge will have an ACLspace all
to itself, within which it can be certain nothing but itself will
change ACL's, so it can rely on never having to read NFSv4 ACL's
that do not match the subset it would feel inclined to write.
Unix users will get an everything:everyone or 777 warning that
someone else is managing the ACLspace. Yet, Unix users can
descend into its private subtrees and muck around with ACL's, and
the Unix changes will still get enforced.
It's easy to search for all the changes made by Unix, vs all the
changes made by [new protocol] bridge, and see if some are
important. It's easy to delete all of them at once if someone
shouldn't have been mucking arond from unix, or if the [new
protocol] bridge was unleashed on a dataset that wasn't dedicated
to it and made a mess.
This is a case where the [new protocol] bridge is using the ACL's
for two related but slightly-orthogonal purposes: to enforce
security, and to store metadata. My proposal separates the two.
- SMB <-> NFSv4, NFSv4 <-> NFSv4
I get that the NFSv4 ACL's are supposed to match Windows
perfectly, but if that turns out to be untrue, Linux and Windows
clients could be put in separate ACL groups even though they're
both, in theory, using NFSv4 ACL's.
* zones running large software packages that have bizarre or
misguided ACL behavior
ACL's are complicated enough that a lot of programmers will get
them wrong. If you have a large, assertion-riddled app that will
shit itself if it doesn't see the ACL's it expects, or autoset or
autoremove ACL's, or does other stupid things with ACL's, you can
put it into a zone and configure an ACL tag on the zone,
segregating its ACL-writing from the rest of the system.
Yet, its restrictions are still respected. If the app were setting
ACL's that don't give enough permission, it wouldn't work. but it
may have hardcoded crap that stupidly opens up ACL's, or refuses to
work if ACL's aren't as open as it thinks they should be. Now you
can fake it out whenever it calls getacl, but set other ACL's kept
secret from it and still return permission denied when you like.
* (optional)
a backup mechanism. If you make the choice ``global zone ignores
ACLgroups with 'zoned' bit set'', then you can run backups in the
global zone that won't be stopped by ACL's set by the inner zones,
however you can still limit your backup process's access by adding
zoned=0 ACL's.
>> chpacl '(unix)' chmod -R A- .
nw> Huh?
I think you are confused because you didn't read my proposal because
it was too long, or the examples I wrote weren't easy to understand.
however if I try to repeat it in small pieces, I think it'll just be
even longer and harder to understand than the original.
What's more, if you don't agree that the current autotranslation
sucks, confuses people, and leaks unintended information, then the
only way I could convince you to pay attention to me is with a talent
for brevity that I just don't have, so beyond this I think I'll drop
it.
pgpzW7nDIVFAy.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
