June 2007 Archives

The new ACL Explorer... or not?

| 0 Comments | 0 TrackBacks

The time has come to retire the old ACL Explorer.

Some of you who know me and heard me speak on the current ACL Explorer for DFS (the soon-to-be-retired technology behind PASS) know I haven't been too pleased with it. This is not a slight against those who worked on it, in fact, one of the biggest user interface problems with it today was my own doing (showing the username instead of the more cryptic UID number for "user_obj", which gave users confidence in attempting to remove the user and thus cause issues when it was actually the file owner that got sacked).

What's missing from this blog is a rant about what else needs to go from the current design. I don't need to convince anyone to proceed, so I'll spare you.

Even if I loved it, there's no way we could keep it as is. The switch to the new PASS (GPFS - we hope) will require some major rework to use the ACLs supplied with it. To compound the issue further, the NFSv4 style permissions we hope to use with GPFS have a number of potential confusion issues, no less are:

  1. You now have 14 permission types (11 actually do something in GPFS; 2 of those must be set together) instead of the 6 in DFS
  2. You may have multiple entries for the same user or group
  3. Order matters; change the order, and the semantics can change drastically
  4. Each entry can be a DENY or an ALLOW entry; I expect the DENY concept may be strange to some
  5. The IETF's recommended translation from the UNIX mode permissions or POSIX draft ACL permissions are extremely verbose, fragile, incompatible with NTFS based ACL tools (from whence these permissions were derived) and very confusing to the average user; each entry from a POSIX ACL (like DFS) will result in 2 or 3 entries in NFSv4.
  6. If this isn't enough, GPFS also supports a more conventional POSIX ACL. While you can set a filesystem to only support one or the other, there remain subtle means to create POSIX ACLs under the covers and be none-the-wiser (they read like NFSv4 but act like POSIX).

Wow! Are we really going through with this? Do we have to? Well there are some very fine reasons for going this route. Including the fact that the added complexity bring greater flexibility. We make great use of it. Various file sharing and group collaboration environments wouldn't be possible in a filesystem without it. The whole notion of having both a "read-only group" (which is not the world) and "editors group" is impossible with simple UNIX mode permissions. I fear the large part of the confusion is the verbosity in the language used to express these permission patterns. Specifically, EVERY FILE MUST RECORD EVERY PERMISSION TYPE, not just those that are different between one folder and its contained objects. Luckily, an Access Control List (ACL) allows you to only list those entities with whom you have any business in stressing how they may access your content.

One folder-based access control system that demonstrates a simpler way to express and ultimately understand all variances later is the NCSA httpd Web server's .htaccess based config files (which was inherited by the Apache httpd Web server we use on most of our servers). Not every folder needs an .htaccess file. Folders that do automatically apply their "overrides" of the previous folder's configuration recursively to all descendant folders. If one where to set one permission setting at one level, then "update it" with more specific settings at a lower level, you only had two files to examine later to know the whole story. A quick "find" could reveal which folders had the files. File permissions tend to require a lot more processing (by computers if not also by humans, which tends to be more the latter in most cases) to get to the same level of understanding.

What's that you say? "But you can't set .htaccess restrictions to individual files?" Sure you can! Use the <files> stanza to apply restrictions to specific files, or also use a ~ to specify file name patterns. It is only as complex as you make it.

So looking forward, I see both hope and a great burden to achieve a good user interface to set how file permissions may be observed and altered by the user from the defaults we choose. Since we provide the primary interface, we can set the complex patterns on disk based on the simpler expressions given to and taken from the user; why not say "Read only" vs "Read/Write" in place of rxcts vs rwxmDcCtTs? Furthermore, I think the time may be coming when the idea of having an "Explorer" for permissions may be obsolete. What is the goal you wish to achieve? The tool you use should be able to set most permissions. Files uploaded to your www folder as opposed to a private folder should be set with the appropriate default permissions. Tools that exist or we may create to help construct Web sites, dynamic content and storage files, sharing spaces and the like should be able to manipulate the file permissions as needed to achieve their effect. The PASS Explorer "File Sharing" feature does this now in combination with a custom set of user managed groups. It may be time for the burden of ACL setting to be done by separate tools via an API of some kind, be it CGI parameters POSTed to a web form, a C library call, some sort of RPC, or what have you. It just has to be simple enough for our little team to implement successfully within our time constraints.

It could also be that we should finalize the merge of ACL Explorer into PASS Explorer. Why "explore" ACLs? They are no more interesting (unless you are a computer geek) than the content they protect, and they tend to only be interesting when they cause you a problem (they are in your way or not enough in someone else's way). There, you would use the "properties" or "info" buttons to see more about the file. Or perhaps they deserve their own "permissions" button directly on the interface.

By "finalizing" the merge, I mean removing the "separateness" of ACL Explorer having to be a separate tool with a separate folder tree navigation interface. There should be allowance for multiple entry points to each application and multiple paths people may take between them. For example, if a help desk wanted to email a link to a user as to where they could fix their access problem and not be distracted by other bells and whistles involved in downloading, making photo galleries, etc. It could very well be all functionality of the ACL tools in PASS Explorer would be a separate tool, served from a separate domain and separate set of executables. It just doesn't have to look that way.

Some application of User Managed Groups would make sense here, such as what the PASS Explorer "File Sharing" function provides. It may also make sense to allow the user to read the group membership right from the interface (for small groups, large groups like psu.facstaff or access may need to be "too big to read"; and for groups not under FERPA protection). If they are the UMG owner or admin, provide a link to the UMG management site.

Another issue I'd like to address is the separate means of Web-based access control and File-based access control. Try as we might, we cannot completely merge the two. However, I suppose the proper interface could direct the user in the proper direction of not only what content should be there and how to set the permissions properly, but what sharing expectation to have. For example, the long standing notion that the "www" in www.personal.psu.edu meant "the world (can see it)" and "personal" meant "this is content about and by an individual, not necessarily for (only)" may be dissolving in this "Web2.0" world - *. I suspect it may be good to have the "www" folder be "special" in the interface, as well as www_protected (as part of the protected.personal pilot). When you navigate into such a folder, a new "Web permissions" button emerges and summons the proper tool to set your public (default allow to the world; for adding self-contained .htaccess/.htpasswd user/password pair-based restrictions) or protected (default allow only to the self; for granting access to Penn State WebAccess authenticated users, groups and roles). Same thing for group shared Web spaces, departmental, courses and clubs. We've been a big fan of letting the users learn on their own and take on the technology they understand (using a high bar and some tutorials). Perhaps the time has come to drop the bar and provide everyone the tools to perform the simple and common actions by the simple efforts. Let the more complicated options remain possible. This is some Perl philosophy I'd like to apply here.

* - Blog services, which are perhaps the closest "Web2.0" equivalent to the personal Web page of the "Web1.0" era, tend to have a privacy control built in. For example, Live Journal has a form field select box on the blog draft form labeled "Show this entry to:" with the options "Everyone (Public)", "Friends", "Just Me (Private)". Perhaps we should have something about as simple for the blogs interface to protected.personal? Perhaps selecting "friends" should prompt you to pick your group of friends (if you haven't already done so) or select which group of friends if you have multiples.

Finally, in this theme of "building the better user interface" why question the user's intuition? Why not build around it? Most users have a great file-system with a very intuitive privacy model and world-wide interoperability. Can you guess what it is? It's called MIME over SMTP. Attaching files to email has become the single most widely used and among the easiest to understand model for file sharing and transfer. Often times (especially those exploiting their expansive, ever growing gmail quota) it is also used for storage. Those of us in IT are quick to say, "don't do that!" or "well, it's ok to send small files, but please stop sending your multi-gigabyte files over email!" Maybe the new access model should be based on email? When the attached file is sent to another psu.edu address from WebMail, perhaps it should leverage a "local" file-system (like PASS) and automatically set the proper sharing permissions. The receiving user would "get the file in their email" just like a normal attachment and be able to "download the file from WebMail" the same way. If it is going outside of PSU, then let it fly, or provide a link back to a site along with authentication instructions to download the file. Whatever it is, it cannot complicate the user experience any further if it is to succeed in replacing MIMEoSMTPfs.

Sleights of hand such as this may be best performed on a protocol enhancement level, where other institutions and ISPs may join in with the SMTP bandwidth savings. SMTP is already cluttered enough from the plagues of SPAM and SMTP transmitted viruses and this can only help (so says the optimist). There's also the compatibility issue, but hopefully the required extension to SMTP would prompt the recipient peer for a response to the new code word, failure would return 502 "I don't recognize that command" and result it fail-back to the old way.

Will it be secure? Not sure that's needed. Note, I'm trying to solve the user-experience problem of privacy (saying who is allowed to get to it normally), not security (actually encrypting it or using other techniques to prevent the "bad guys" from breaking in). Scary as it is, most of HIPPA appears to be written in terms of this notion of "privacy" vs "security". It may be possible to also express security as well over the wire. The end user experience is another challenge altogether since "security" is usually assumed until someone from the "geek squad" busts in the room screaming "fire". Note that this is all to replace clear-text MIME over SMTP; PGP & S/MIME already has the security bit solved (just not the large file storage/delivery bit).

Please don't read this as a suggestion that we should replace ACL Explorer with a hack on file attachments in WebMail, it is a suggested alternate route to allow the user to take.

At the Web Conference (2007) I plan on unveiling a prototype of a new ACL Explorer demonstrating a few user interface techniques that I am both pondering in using and were easy enough for me to implement at this stage of the game. Please let me know if you are interested in checking it out and/or discussing with me what direction we should take with this important part of the PASS migration. Sharing your comments here is also greatly appreciated.

Search This Blog

Full Text  Tag