Re: [zfs-discuss] tagged ACL groups: let's just keep digging until we come out the other side
On Sat, Oct 09, 2010 at 09:52:51PM -0700, Richard Elling wrote: > Are we living in the past? > > In the bad old days, UNIX systems spoke NFS and Windows systems spoke > CIFS. The cost of creating a file system was expensive -- slices, > partitions, etc. > > With ZFS, file systems (datasets) are relatively inexpensive. > > So, are we putting too many constraints into a system (ZFS) which is > busy trying to remove constraints? Is it reasonable to expect that > ZPL is the only kind of "file system" ZFS customers need? Is it high > time for a ZCIFS dataset? I don't quite understand what you mean. ZPL is just a POSIX layer. It _happens_ to be used not just by the system call layer in Solaris, but also by the SMB and NFS servers, but you could also imagine the SMB and NFS servers using the DMU directly while maintaining on-disk compatibility with the ZPL. Not using the ZPL does not necessitate having a different on-disk format, or different semantics. Now, if you were asking about dataset properties that make a dataset behave more like what Windows expects or more like what Unix expects, that's different, but that wouldn't require junking the ZPL. Nico -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] tagged ACL groups: let's just keep digging until we come out the other side
Are we living in the past? In the bad old days, UNIX systems spoke NFS and Windows systems spoke CIFS. The cost of creating a file system was expensive -- slices, partitions, etc. With ZFS, file systems (datasets) are relatively inexpensive. So, are we putting too many constraints into a system (ZFS) which is busy trying to remove constraints? Is it reasonable to expect that ZPL is the only kind of "file system" ZFS customers need? Is it high time for a ZCIFS dataset? -- richard ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] tagged ACL groups: let's just keep digging until we come out the other side
On Wed, Oct 06, 2010 at 05:19:25PM -0400, Miles Nordin wrote: > > "nw" == Nicolas Williams writes: > > nw> *You* stated that your proposal wouldn't allow Windows users > nw> full control over file permissions. > > me: I have a proposal > > you: op! OP op, wait! DOES YOUR PROPOSAL blah blah WINDOWS blah blah > COMPLETELY AND EXACTLY LIKE THE CURRENT ONE. > > me: no, but what it does is... The correct quote is: "no, not under my proposal." That's from a post from you on September 30, 2010, with Message-Id: . That was a direct answer to a direct question. Now, maybe you wish to change your view. That'd be fine. Do not, however, imply that I'm liar though, not if you want to be taken seriously. Please re-write your proposal _clearly_ and refrain from personal attacks. Cheers, Nico -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] tagged ACL groups: let's just keep digging until we come out the other side
> "nw" == Nicolas Williams writes: nw> *You* stated that your proposal wouldn't allow Windows users nw> full control over file permissions. me: I have a proposal you: op! OP op, wait! DOES YOUR PROPOSAL blah blah WINDOWS blah blah COMPLETELY AND EXACTLY LIKE THE CURRENT ONE. me: no, but what it does is... you: well then I don't even have to read it. It's unacceptable because $BLEH. me: untrue. My proposal handles $BLEH just fine. you: you just said it didn't! me: well, it does. Please read it. you: I read it and I don't understand it. Anyway it doesn't handle $BLEH so it's no good. This is not really working, and concision is the problem. so, I now, today, state: My proposal allows Windows users full control over file permissions. nw> Yes, that may be. I encourage you to find a clearer way to nw> express your proposal. So far, it's just us talking. I think I'll wait and see if anyone besides you reads it. If so, maybe they can ask questions that help me clarify it. If no one does, it's probably not interesting here anyway. pgp4wuhrA1SzN.pgp Description: PGP signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] tagged ACL groups: let's just keep digging until we come out the other side
On Wed, Oct 06, 2010 at 04:38:02PM -0400, Miles Nordin wrote: > > "nw" == Nicolas Williams writes: > > nw> The current system fails closed > > wrong. > > $ touch t0 > $ chmod 444 t0 > $ chmod A0+user:$(id -nu):write_data:allow t0 > $ ls -l t0 > -r--r--r--+ 1 carton carton 0 Oct 6 20:22 t0 > > now go to an NFSv3 client: > $ ls -l t0 > -r--r--r-- 1 carton 405 0 2010-10-06 16:26 t0 > $ echo lala > t0 > $ > > wide open. The system does what the ACL says. The mode fails to accurately represent the actual access because... the mode can't. Now, we could have chosen (and still could choose to) represent the presence of ACEs for subjects other than owner@/group@/everyone@ by using the group bits of the mode to represent the maximal set of permissions granted. But I don't consider the above "failing open". > nw> You seem to be in denial. You continue to ignore the > nw> constraint that Windows clients must be able to fully control > nw> permissions in spite of their inability to perceive and modify > nw> file modes. > > You remain unshakably certain that this is true of my proposal in > spite of the fact that you've said clearly that you don't understand > my proposal. That's bad science. *You* stated that your proposal wouldn't allow Windows users full control over file permissions. > It may be my fault that you don't understand it: maybe I need to write > something shorter but just as expressive to fit within mailing list > attention spans, or maybe my examples are unclear. However that > doesn't mean that I'm in denial nor make you right---that just makes > me annoying. Yes, that may be. I encourage you to find a clearer way to express your proposal. Nico -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] tagged ACL groups: let's just keep digging until we come out the other side
> "nw" == Nicolas Williams writes:
nw> The current system fails closed
wrong.
$ touch t0
$ chmod 444 t0
$ chmod A0+user:$(id -nu):write_data:allow t0
$ ls -l t0
-r--r--r--+ 1 carton carton 0 Oct 6 20:22 t0
now go to an NFSv3 client:
$ ls -l t0
-r--r--r-- 1 carton 405 0 2010-10-06 16:26 t0
$ echo lala > t0
$
wide open.
NFSv3 and SMB sharing the same dataset is a use-case you claim to
accomodate. This case fails open once Windows users start adding
'allow' ACL's. It's not a corner case; it's a design that fails open.
>> ever had 777 it would send a SIGWTF to any AFS-unaware
>> graybeards
nw> A signal?! How would that work when the entity doing a chmod
nw> is on a remote NFS client?
please find SIGWTF under 'kill -l' and you might understand what I
meant.
nw> You seem to be in denial. You continue to ignore the
nw> constraint that Windows clients must be able to fully control
nw> permissions in spite of their inability to perceive and modify
nw> file modes.
You remain unshakably certain that this is true of my proposal in
spite of the fact that you've said clearly that you don't understand
my proposal. That's bad science.
It may be my fault that you don't understand it: maybe I need to write
something shorter but just as expressive to fit within mailing list
attention spans, or maybe my examples are unclear. However that
doesn't mean that I'm in denial nor make you right---that just makes
me annoying.
--
READ CAREFULLY. By reading this fortune, you agree, on behalf of your employer,
to release me from all obligations and waivers arising from any and all
NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap,
browsewrap, confidentiality, non-disclosure, non-compete and acceptable use
policies ("BOGUS AGREEMENTS") that I have entered into with your employer, its
partners, licensors, agents and assigns, in perpetuity, without prejudice to my
ongoing rights and privileges. You further represent that you have the
authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
pgpvrZFYgaHat.pgp
Description: PGP signature
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] tagged ACL groups: let's just keep digging until we come out the other side
On Mon, Oct 04, 2010 at 02:28:18PM -0400, Miles Nordin wrote: > > "nw" == Nicolas Williams writes: > > nw> I would think that 777 would invite chmods. I think you are > nw> handwaving. > > it is how AFS worked. Since no file on a normal unix box besides /tmp But would the AFS experience translate into double plus happiness for us? > ever had 777 it would send a SIGWTF to any AFS-unaware graybeards that > stumbled onto the directory, alerting them that they needed to go > learn something and come back. A signal?! How would that work when the entity doing a chmod is on a remote NFS client? > I understand that everything:everyone on windows doesn't send SIGWTF, > but 777 on unix for AFS sites it did. You realize it's not > hypothetical, right? AFS was actually implemented, widely, and > there's experience with it. Yes... but I'm skeptical about the universality of that experience's applicability. Specifically: I don't think it could work for us. AFS developers had fewer constraints than Solaris developers. It is no surprise that they were able to find happy solutions to these sorts of problems long ago. OpenAFS has a Windows native client and an Explorer shell extension (which surely handles chmod?). However, we don't have the luxury of telling customers to install third-party (possibly ours, whatever) Windows native clients for protocols other than SMB, nor can we tell them to install Explorer shell extensions. Solaris' SMB server needs to work out of the box and without the limitations implied by having a separate ACL and mode (well, we have that now, but we always compute a new mode from the new ACL when ACLs are changed). > If they failed to act on the SIGWTF, the overall system enforced the > tighter of the unix permissions and the AFS ACL, so it fails closed. > The current system fails open. The current system fails closed (by discarding the ACL and replacing it with a new one based entirely on the new mode). > Also AFS did no translation between unix permissions and AFS ACL's so > it was easy to undo such a mistake when it happened: double-check the > AFS ACL is not too wide on the directories where you see unix people > mucking around in case the muckers were responding to a real problem, > then set the unix modes back to 777. Right, but with SMB in the picture we don't have this luxury. You seem unwilling to accept that one constraint. > nw> When chmod()ing an object... ZFS would search for the most > nw> specific matching file in .zfs/ACLs/ and, if found, would > nw> replace the chmod()ed object's ACL with that of the > nw> .zfs/ACLs/... file found. The .inherit suffix would indicate > nw> that if the chmod() target's parent directory has inherittable > nw> ACEs then they will be groupmasked and added to the ACEs from > nw> the .zfs/ACLs/... file to produce a final ACL. > > This proposal, like the current situation, seems to make chmod > configurable to act like ``not chmod'' which IMHO is exactly what's > unpopular about the current regime. You've tried to leave chmod To some degree, yes. It's different though, and might conceivably be acceptable, though I don't think it will be (I was illustrating potential alternatives). But I really like one thing about it: most apps shouldn't care about ACL contents, they should care about context-specific permissions changes. In a directory containing shared documents the intention should typically be "share with all these people", while in home directories the intention should typically be "don't share with anyone" (but this will vary; e.g., ~/.ssh/authorized_keys needs to be reachable and readable by everyone). Add in executable versus not- executable, and you have a pretty complete picture -- just a few "named" ACLs at most, per-dataset. If we could replace chmod(2) with a version that takes actual names for pre-configured ACLs, _that_ would be great. But we can't for the same reason that we can't remove chmod(2): it's a widely used interface. > active on windows trees and guess at the intent of whoever invokes > chmod, providing no warning that you're secretly doing > ``approximately'' what he asked for rather than exactly. Maybe that > flies on Windows, but on Unix people expect more precision: thorough > abstractions that survive corner cases and have good exception > handling. Look, mode is a pretty lame hammer -- ACLs are far, far more granular-- but it's a hammer that many apps use. Given the lack of granularity of modes, I think an approximation of intent is the best we can do. Consider: both, aclmode=discard and aclmode=groupmask behaviors can be considered to be what the user intended. How do you know if the user intended for other users and groups to retain access limited to the group bits of a new mode? You can't, not without asking the user. So aclmode=discard is certainly an approximation of user intent, and so aclmode=groupmask must be considered an approximation
Re: [zfs-discuss] tagged ACL groups: let's just keep digging until we come out the other side
> "nw" == Nicolas Williams writes: nw> I would think that 777 would invite chmods. I think you are nw> handwaving. it is how AFS worked. Since no file on a normal unix box besides /tmp ever had 777 it would send a SIGWTF to any AFS-unaware graybeards that stumbled onto the directory, alerting them that they needed to go learn something and come back. I understand that everything:everyone on windows doesn't send SIGWTF, but 777 on unix for AFS sites it did. You realize it's not hypothetical, right? AFS was actually implemented, widely, and there's experience with it. If they failed to act on the SIGWTF, the overall system enforced the tighter of the unix permissions and the AFS ACL, so it fails closed. The current system fails open. Also AFS did no translation between unix permissions and AFS ACL's so it was easy to undo such a mistake when it happened: double-check the AFS ACL is not too wide on the directories where you see unix people mucking around in case the muckers were responding to a real problem, then set the unix modes back to 777. nw> When chmod()ing an object... ZFS would search for the most nw> specific matching file in .zfs/ACLs/ and, if found, would nw> replace the chmod()ed object's ACL with that of the nw> .zfs/ACLs/... file found. The .inherit suffix would indicate nw> that if the chmod() target's parent directory has inherittable nw> ACEs then they will be groupmasked and added to the ACEs from nw> the .zfs/ACLs/... file to produce a final ACL. This proposal, like the current situation, seems to make chmod configurable to act like ``not chmod'' which IMHO is exactly what's unpopular about the current regime. You've tried to leave chmod active on windows trees and guess at the intent of whoever invokes chmod, providing no warning that you're secretly doing ``approximately'' what he asked for rather than exactly. Maybe that flies on Windows, but on Unix people expect more precision: thorough abstractions that survive corner cases and have good exception handling. The problem is not that Unix people refuse to learn about Windows permissions to accomodate windows, or that they are too stupid to understand the 'chmod A...' stuff in the manpage. They will learn if you ask them to learn. The problem is that you don't ask them. The repeated complaint is that when OTHER USERS hamfist a bunch of stuff with chmod: (1) they destroy the correct ACLs that were put on those files by people who do know wtf is going on. The ACL's are hard to get right, and there's no simple way for the people who understand ACL's to undo the damage caused by blind chmod'ing (2) it's insecure because it doesn't reliably implement the will of the unaware person invoking chmod and gives that person no warning. AFS had neither problem, nor my proposal. NFSv4 as-built has both. pgpsBzUloiCYg.pgp Description: PGP signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] tagged ACL groups: let's just keep digging until we come out the other side
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
>
> -rwxrwxrwxin 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//[:][d|-][.inherit]
^ ^^^ ^
|| |
+-- owned by | |
+-- 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/mailm
Re: [zfs-discuss] tagged ACL groups: let's just keep digging until we come out the other side
> 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. > > Then your proposal is a non-starter. Support for > multiple remote > filesystem access protocols is key for ZFS and > Solaris. > > The impedance mismatches between these various > protocols means that we > need to make some trade-offs. In this case I think > the business (as > well as the engineers involved) would assert that > being a good SMB > server is critical, and that being able to > authoritatively edit file > permissions via SMB clients is part of what it means > to be a good SMB > server. > > Now, you could argue that we should being aclmode > back and let the user > choose which trade-offs to make. And you might > propose new values for > aclmode or enhancements to the groupmask setting of > aclmode. > > > 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. > > Thus the current behavior is the same as the old > aclmode=discard > setting. > > > >> 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. > That's not an option, not for a default behavior > anyways. > > Nico One question: Casper, where are you? The guy that did fine-grained permissions IMO ought to have an idea of how to do something with ACLs that's both safe and unsurprising for the various sorts of clients. -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] tagged ACL groups: let's just keep digging until we come out the other side
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. Then your proposal is a non-starter. Support for multiple remote filesystem access protocols is key for ZFS and Solaris. The impedance mismatches between these various protocols means that we need to make some trade-offs. In this case I think the business (as well as the engineers involved) would assert that being a good SMB server is critical, and that being able to authoritatively edit file permissions via SMB clients is part of what it means to be a good SMB server. Now, you could argue that we should being aclmode back and let the user choose which trade-offs to make. And you might propose new values for aclmode or enhancements to the groupmask setting of aclmode. > 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. Thus the current behavior is the same as the old aclmode=discard setting. > >> 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. That's not an option, not for a default behavior anyways. Nico -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] tagged ACL groups: let's just keep digging until we come out the other side
>> 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 -rwxrwxrwxin 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 ag
Re: [zfs-discuss] tagged ACL groups: let's just keep digging until we come out the other side
On Thu, Sep 30, 2010 at 03:28:14PM -0500, Nicolas Williams wrote: > Consider this chronologically-ordered sequence of events: > > 1) File is created via Windows, gets SMB/ZFS/NFSv4-style ACL, including >inherittable ACEs. A mode computed from this ACL might be 664, say. > > 2) A Unix user does chmod(644) on that file, and one way or another this >effectively reduces permissions otherwise granted by the ACL. > > 3) Another Windows user now fails to get write perm that they should >have, so they complain, and then the owner tries to view/change the >ACL from a Windows desktop. > > Now what? > > Can the user in (3) fix the permissions from Windows? For that to be > possible the mode must implicitly get recomputed when the ACL is > modified. Also, even if in (3) the user can fix the perms from Windows because we'd recompute the mode from the ACL, the user wouldn't be able to see the "effective" ACL (as "reduced" by the mode_t that Windows can't see). The only way to address that is... to do groupmasking. And that gets us back to the problems we had with groupmasking. Nico -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] tagged ACL groups: let's just keep digging until we come out the other side
On Thu, Sep 30, 2010 at 02:55:26PM -0400, Miles Nordin wrote: > > "nw" == Nicolas Williams writes: > nw> Keep in mind that Windows lacks a mode_t. We need to interop > nw> with Windows. If a Windows user cannot completely change file > nw> perms because there's a mode_t completely out of their > nw> reach... they'll be frustrated. > > well...AIUI this already works very badly, so keep that in mind, too. > > In AFS this is handled by most files having 777, and we could do the > same if we had an AND-based system. This is both less frustrating and > more self-documenting than the current system. > > In an AND-based system, some unix users will be able to edit the > windows permissions with 'chmod A...'. In shops using older unixes > where users can only set mode bits, the rule becomes ``enforced > permissions are the lesser of what Unix people and Windows people > apply.'' This rule is easy to understand, not frustrating, and > readily encourages ad-hoc cooperation (``can you please set > everything-everyone on your subtree? we'll handle it in unix.'' / > ``can you please set 777 on your subtree? or 770 group windows? we > want to add windows silly-sid-permissions.''). This is a big step > better than existing systems with subtrees where Unix and Windows > users are forced to cooperate. Consider this chronologically-ordered sequence of events: 1) File is created via Windows, gets SMB/ZFS/NFSv4-style ACL, including inherittable ACEs. A mode computed from this ACL might be 664, say. 2) A Unix user does chmod(644) on that file, and one way or another this effectively reduces permissions otherwise granted by the ACL. 3) Another Windows user now fails to get write perm that they should have, so they complain, and then the owner tries to view/change the ACL from a Windows desktop. Now what? Can the user in (3) fix the permissions from Windows? For that to be possible the mode must implicitly get recomputed when the ACL is modified. What if (2) happens again? But, OK, this is a problem no matter what, whether we do groupmasking, discard, or keep mode separate from the ACL and AND the two. ZFS does, in fact, keep a separate mode, and it does recompute it when ACLs are modified. So this may just be a matter of doing the AND thing and not touching the ACL on chmod. Is that what you have in mind? > It would certainly work much better than the current system, where you > look at your permissions and don't have any idea whether you've got > more, less, or exactly the same permission as what your software is > telling you: the crappy autotranslation teaches users that all bets > are off. No, currently you look at permissions that they reflect the ACL (with the group bits being the max of all non-owner@ and non-everyone@ ACEs). > It would be nice if, under my proposal, we could delete the unix > tagspace entirely: > > chpacl '(unix)' chmod -R A- . Huh? > but unfortunately, deletion of ACL's is special-cased by Solaris's > chmod to ``rewrite ACL's that match the UNIX permissions bits,'' so it > would probably have to stay special-cased in a tagspace system. Nico -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] tagged ACL groups: let's just keep digging until we come out the other side
> "nw" == Nicolas Williams writes: nw> Keep in mind that Windows lacks a mode_t. We need to interop nw> with Windows. If a Windows user cannot completely change file nw> perms because there's a mode_t completely out of their nw> reach... they'll be frustrated. well...AIUI this already works very badly, so keep that in mind, too. In AFS this is handled by most files having 777, and we could do the same if we had an AND-based system. This is both less frustrating and more self-documenting than the current system. In an AND-based system, some unix users will be able to edit the windows permissions with 'chmod A...'. In shops using older unixes where users can only set mode bits, the rule becomes ``enforced permissions are the lesser of what Unix people and Windows people apply.'' This rule is easy to understand, not frustrating, and readily encourages ad-hoc cooperation (``can you please set everything-everyone on your subtree? we'll handle it in unix.'' / ``can you please set 777 on your subtree? or 770 group windows? we want to add windows silly-sid-permissions.''). This is a big step better than existing systems with subtrees where Unix and Windows users are forced to cooperate. It would certainly work much better than the current system, where you look at your permissions and don't have any idea whether you've got more, less, or exactly the same permission as what your software is telling you: the crappy autotranslation teaches users that all bets are off. It would be nice if, under my proposal, we could delete the unix tagspace entirely: chpacl '(unix)' chmod -R A- . but unfortunately, deletion of ACL's is special-cased by Solaris's chmod to ``rewrite ACL's that match the UNIX permissions bits,'' so it would probably have to stay special-cased in a tagspace system. pgpzWtQEMyslr.pgp Description: PGP signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] tagged ACL groups: let's just keep digging until we come out the other side (was: zfs proerty aclmode gone in 147?)
On Wed, Sep 29, 2010 at 05:21:51PM -0500, Nicolas Williams wrote: > On Wed, Sep 29, 2010 at 03:09:22PM -0700, Ralph Böhme wrote: > > > Keep in mind that Windows lacks a mode_t. We need to > > > interop with Windows. > > > > Oh my, I see. Another itch to scratch. Now at least Windows users are > > happy while me and mabye others are not. > > Yes. Pardon me for forgetting to mention this earlier. There's so many > wrinkles here... But this is one of the biggers; I should not have s/biggers/biggest/ > forgotten it. > > Nico > -- > ___ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] tagged ACL groups: let's just keep digging until we come out the other side (was: zfs proerty aclmode gone in 147?)
On Wed, Sep 29, 2010 at 03:09:22PM -0700, Ralph Böhme wrote: > > Keep in mind that Windows lacks a mode_t. We need to > > interop with Windows. > > Oh my, I see. Another itch to scratch. Now at least Windows users are > happy while me and mabye others are not. Yes. Pardon me for forgetting to mention this earlier. There's so many wrinkles here... But this is one of the biggers; I should not have forgotten it. Nico -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] tagged ACL groups: let's just keep digging until we come out the other side (was: zfs proerty aclmode gone in 147?)
> Keep in mind that Windows lacks a mode_t. We need to > interop with Windows. Oh my, I see. Another itch to scratch. Now at least Windows users are happy while me and mabye others are not. -r -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] tagged ACL groups: let's just keep digging until we come out the other side (was: zfs proerty aclmode gone in 147?)
Keep in mind that Windows lacks a mode_t. We need to interop with Windows. If a Windows user cannot completely change file perms because there's a mode_t completely out of their reach... they'll be frustrated. Thus an ACL-and-mode model where both are applied doesn't work. It'd be nice, but it won't work. The mode has to be entirely encoded by the ACL. But we can't resort to interesting encoding tricks as Windows users won't understand them. Nico -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
