On 2/26/2010 8:45 PM, Paul B. Henson wrote:
On Fri, 26 Feb 2010, David Dyer-Bennet wrote:

So, even if you're willing to completely discard 30 years of legacy
scripts and applications -- how to you propose that a NEW script or
application should be written so as to work in this brave new
environment?
[...]
And how should new utilities be written to take the place of the 30
years of work you're throwing out?  I don't yet see how it can be done.
First of all, you make a choice. Maybe the correct operation of some 30
year old script is most important to you. So you set an aclmode so it
works. But maybe making sure your sensitive data file doesn't get
accidentally exposed to the world via a unexpected hidden chmod in a 30
year old script is more important than that script working. So you set an
aclmode so your ACL doesn't get destroyed. It's your choice. Choice is
good.


I think of using ACLs to extend extra access beyond what the permission bits grant. Are you talking about using them to prevent things that the permission bits appear to grant? Because so long as they're only granting extended access, losing them can't expose anything. (It can still be tremendously inconvenient, of course; but I don't see that it can create unintended access.)

I'm serious about not seeing how it'd be possible to write new applications for this environment. Most especially, new applications that also worked in a POSIX environment. (Other than the brute force approach of completely separate code for the two environments.) It's not just a problem for existing code.

Second, you're not necessarily discarding all of those legacy
scripts/applications. You're just making sure they don't screw up your
ACL's. Take the example of the editor that chmod's a file and you don't
want it to (but it's a binary app and you can't make it stop). Configuring
zfs to ignore the chmod doesn't break the application. The editor continues
to edit fine. It just doesn't destroy your ACL. Win-win.

If there's some app/script for which changing permissions are essential to
its operation, but it only understands mode bits, either the security
provided by mode bits is sufficient, so you configure aclmode so it works.
Or the security provided by mode bits isn't sufficient, so you replace the
app/script with one that understands ACLs. Using the published ACL API. man
-s 2 acl ;). You can claim it might be a lot of work, but I'm not sure how
you could claim it can't be done.

The problem, of course, is old apps that think they're being especially careful about replicating permissions properly. That seems to be the scenario that breaks your ACLs. Is there any way for a a bash script to replicate permissions in an ACL environment? A Perl app? A C app? Especially one that's trying to be POSIX-portable?

--
David Dyer-Bennet, d...@dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to