Mac OS X Tiger to support Fast Logout and Autosave, Access Control Lists

[AppleInsider]

According to sources privy to pre-release builds of Apple's Mac OS X 10.4 "Tiger" operating system, the release will feature "Fast Logout and Autosave" technology and support for Access Control Lists file-based permissions, AppleInsider has learned.

Fast Logout and Autosave

Fast logout and autosave is a performance-related feature designed to improve the user experience of Mac OS X Tiger.

Presently, closing windows in Mac OS X an expensive operation, especially if the application must prompt the user about unsaved changes for each document window. Tiger's fast logout and autosave feature will improve logout, shutdown, and restart operations by reducing the number of confirmation dialogs presented to the user, all the while protecting the user's unsaved data in open applications.

During a logout, shutdown, or restart operation, Tiger will determine whether an application should post a confirmation dialog for unsaved changes or perform an auto-save event. If the application performs an auto-save event, data will be saved to a special location on the system and the user will be logged out of Mac OS X. The next time the user logs in, the system relaunches each application with auto-saved documents and reconstructs the documents as their state immediately before the last logout.

According to sources, most of the applications that will ship with Tiger will already support Fast Logout and Autosave. On the other hand, third party developers will need to update their applications to gain the benefits of the new feature.

Access Control Lists

Tiger will also introduce support for Access Control Lists (ACLs)—a robust system for implementing file-based permissions that offer many improvements over the existing BSD permissions currently used by the Mac OS X file systems.

Among the improvements delivered by ACL's is support for ownership of files and directories by a group, enhanced interoperability with Samba and Windows, and support for multiple owners of a file or directory, each with potentially different permissions.

Additionally, ACL's will add support for static inheritance of file permissions from a parent directory and provide more control over a file than just read/write/execute permissions.
ACLs are a common feature of enterprise computing because they provide flexible and highly configurable rights management for servers. The technology also removes many of the limitations of the existing BSD permissions by allowing access to files and directories by multiple groups and users. In addition, it lets the system administrator grant specific rights to each user and group without requiring the creation of special new groups.

[ View this article at AppleInsider.com ]

[wrldwzrd89]

Yay for ACL support! I've been waiting for Apple to upgrade the permissions system, and adding ACLs seems like the perfect way to do it.

[MPMoriarty]

So ACL are better than Mac OS X's current file permission system?

[wrldwzrd89]

Originally posted by MPMoriarty
So ACL are better than Mac OS X's current file permission system?

Yes, absolutely. ACLs allow for much more permissions customization than is possible with the current system. For example, an ACL can allow a file to be owned by more than one group - something not possible with the current system.

[hmmfe]

Hurrah for ACLs. I hope this is evidence of a serious effort on Apple's part to create a server and client OS that can funtion in most small to mid-sized businesses. For the most part, they are there already. ACLs were big on my list as the current permissions were too restrictive. Now, make mounting of shares easier (more intuitive) and we've got a winner on the OS side.

It is funny, I read that 2003 Small Business Server is a huge hit. Personally, I think it is horrible (although I find 2003 Server a fine OS). Apple has all the right parts; with a little polish it could compete very well with SBS2003.

I guess I'm still smarting over my company's decision to ditching Panther Server/ OS X in favor of SBS2003/ XP...

[MPMoriarty]

I wonder if Apple is going to have to enhance the GET INFO panel to adjust for ACL settings.

[dstranathan]

Does the current Tiger Beta have any signs of ACLs?

[sjk]

Originally posted by AppleInsider
ACL's will add support for static inheritance of file permissions from a parent directory and provide more control over a file than just read/write/execute permissions.

Sounds like that inheritance can work like a per-directory umask, probably obviating the need for the seriously limited global umask. Cool.

What I'd really like is an automatic way to ensure consistent file permissions when installing software. Too many third party apps are installed with world writable directories, as running "find /Applications -type d -mode 777 -ls" will reveal.

[zzen]

I would just like to clarify that:

a) the old file permissions (4byte 7777-style) are not BSD file permissions but rather general UNIX file permissions

b) FreeBSD (and possibly other BSDs?) feature ACL for quite a while now

It's quite probable that the Tiger ACLs are actually fetched from FreeBSD in my opinion. Especially since Jordan K. Hubbard is at Apple.

[wrldwzrd89]

Originally posted by zzen
I would just like to clarify that:

a) the old file permissions (4byte 7777-style) are not BSD file permissions but rather general UNIX file permissions

b) FreeBSD (and possibly other BSDs?) feature ACL for quite a while now

It's quite probable that the Tiger ACLs are actually fetched from FreeBSD in my opinion. Especially since Jon K. Hubbard is at Apple.

Don't you think Apple should have put ACL support in Panther, then, if ACLs were available from *BSD?

[zzen]

Originally posted by wrldwzrd89
Don't you think Apple should have put ACL support in Panther, then, if ACLs were available from *BSD?

Well, yes and no. As far as I can tell, ACLs are part of FreeBSD since version 5.0, which was released in January 2003. (The current version is 5.2.1)

It wasn't a newest thing under the sun at that time, but the FreeBSD implementation was quite fresh and Apple was left with about half a years time to copy it to Darwin. Which is not much. A safer and better strategy is to wait and see how the FreeBSD implementation lives up, wait for one or two versions before the bugs get ironed out and then introduce it into Darwin. And leave ample time for testing and debugging, since an error in the file permissions implementation could be very fatal.

The question is why didn't they put ACLs in one of the incremental updates like 10.3.5. First of all, I am not sure if/how many apps the ACL will or will not break (probably just some disk maintenance apps), second, I guess they like to keep all the aces for paid upgrades.

[nguyenhm16]

ACLs require both kernel support and support in the userland applications. Kernel support is probably fairly straightforward. Well, actually, maybe not so straightforward depending on how amenable HFS+ is to ACLs.

However, updating all the commmand-line and GUI tools, as well as any frameworks or other-more-than-bare-UNIX APIs to support ACLs is a lot of work.

[wrldwzrd89]

Originally posted by nguyenhm16
ACLs require both kernel support and support in the userland applications. Kernel support is probably fairly straightforward. Well, actually, maybe not so straightforward depending on how amenable HFS+ is to ACLs.

However, updating all the commmand-line and GUI tools, as well as any frameworks or other-more-than-bare-UNIX APIs to support ACLs is a lot of work.

Thanks for the info zzen and nguyenhm16. I guess Apple made the right choice by waiting until Tiger to deploy ACL support.

[rok]

okay, getting off of ACLs for a second, i had a sudden realization with regards to the fast logout mentioned above, when combined with the better .mac syncing mentioned earlier this week...

what if you could combine the two to sync your current SESSION with .mac. that way, when you went to ANY other mac, or your home mac, provided you have the same software installed there, you could choose "resume session closed on "name_of_mac_here" as of "time_date"?) then you could either just start your own home session, or you could seamlessly resume your work right where you left off.

this type of seamless "any station is my station" has typically been reserved for the closed high-speed, central server network system. but what if apple brought it right home to the common person? no more backing files up to disk, or manually copying them to idisk, or emailing them home for further work... just encrypt it and logout of your workplace work, and your mac, mac os x and .mac handle everything else. heck, throw in a "remote desktop express" for only one-to-one linkup between two computers, and you never have to be away from your data...

mind you, i don't really WANT something to make it easier to work at home AND work, but i find i keep doing it, so why not make it easier???

[hmurchison]

Very cool idea Rok. I hope we head in that general direction.

[zzen]

Originally posted by rok
what if you could combine the two to sync your current SESSION with .mac. that way, when you went to ANY other mac, provided you have the same software installed there, you could choose "resume session closed on "name_of_mac_here" as of "time_date"?

Well, rok, as much as it sounds really cool, I don't think that's ever going to be possible, not without a MAJOR rewrite of the whole OS. There is a reason why this feature is limited to "high-end central server systems" as you write -- you boot the client always off the server and you can guarantee the same available resources (applications, disks etc.)

First, the way I suppose fast logout will work:
1) it will make a list of running applications
2) it will tell each of the applications to return the list of unsaved documents
3) for each of the documents, it will tell the respective application to compute a difference between the actual state of the document and the last saved copy on the disk. These differences will be store in a folder and upon the next login, all those respective applications will be opened and told to reconstruct the current document from the on-disk copy and the difference saved in the session.

Let's see. If you would allow to synchronize between more computers, here are a few problems

* You never have the same applications installed. Never. Not the very same version, configuration, plugins, exact same preferences, kernel extensions etc.

* You have an iMovie project opened. You fast-logout. A few tens of megabytes are written to disk as the difference. You go to work, resume the session -- and expect to have the whole 2gigabyte project accessible?

Or if you have a huge Photoshop file opened? Or DVD project?

I think you see where I am heading. You need to share the same physical disk space (or synchronize the whole disk structure) in order for these sessions to work. I don't think it's possible otherwise.

[kim kap sol]

zzen brings good points...some of which I was about to mention.

I think a safer bet would be Home on iPod.

Bring iPod to work, plug iPod in, user shows up in user list, pick user, work, Fast Logout, unplug iPod, bring iPod home, plug iPod in, user shows up in user list, pick user, work.

There's still an issue of not having the app or the exact version of the app in question...but I think it could work if the app was on the iPod and that app superseded other apps in priority launching order.

[zzen]

Originally posted by kim kap sol
I think a safer bet would be Home on iPod.

Of course you can still tell iMovie to save your 2GB project somewhere outside of your Home (and thus the iPod) so the problem stays the same.

I really can't envision any other way than complete HD structure syncing.

[rok]

Originally posted by kim kap sol
zzen brings good points...some of which I was about to mention.

I think a safer bet would be Home on iPod.

Bring iPod to work, plug iPod in, user shows up in user list, pick user, work, Fast Logout, unplug iPod, bring iPod home, plug iPod in, user shows up in user list, pick user, work.

There's still an issue of not having the app or the exact version of the app in question...but I think it could work if the app was on the iPod and that app superseded other apps in priority launching order.

you may be right, but assuming the large ipod just keeps getting a larger and larger hard drive, isn't it theoreticallly possible to also carry around a copy of your apps to use as well? the only drawback to that idea would be that the ipod isn't really meant for sustained disk usage. but if the apps could be loaded to a temporary ram disk from the ipod on any machine other than your main one, which then gets ditched on logout... but then you'd only have seveeraal gigs of ram disk to work with in that scenario.

ah hell, perhaps it's a pipe dream, but i have to say i like the IDEA of it, anyway... steve, MAKE IT HAPPEN.

[murk]

I haven't heard any other mention of Autosave in Tiger besides the AI article. Is it actually included?

[MPMoriarty]

Originally posted by murk
I haven't heard any other mention of Autosave in Tiger besides the AI article. Is it actually included?

Yes, I agree that it's odd we haven't heard much more about these features. Maybe someone with a Tiger build could enlighten us.

Mike

[MPMoriarty]

I have a question, though...

I don't really understand what Access Control Lists are or how they differ much from the current file system permissions setup currently in Panther.

When Steve announced this at WWDC '04 the audience seemed very happy. What is it? And what features does it bring?

Mike

[zzen]

Originally posted by MPMoriarty
I have a question, though...

I don't really understand what Access Control Lists are or how they differ much from the current file system permissions setup currently in Panther.

When Steve announced this at WWDC '04 the audience seemed very happy. What is it? And what features does it bring?
Mike

It was already said above. The ACLs make finer, more detailed permissions possible. In the old permissions style, you could have a single user as an owner of the file and single group as group the file belongs to. You could define permissions (read, write, execute) to each of these 3 entities.

With ACLs, you can have pretty much any number of owners of a file or any number of groups the file belongs to. For example, you can make a file unreadable in general and read-only for one group of users and read/write for another group of users - a task which was hardly possible now.

For more detail see
http://csrc.nist.gov/publications/ni...-7/node27.html
or
http://en.wikipedia.org/wiki/Access_Control_List

[zzen]

Originally posted by nguyenhm16
ACLs require both kernel support and support in the userland applications. Kernel support is probably fairly straightforward. Well, actually, maybe not so straightforward depending on how amenable HFS+ is to ACLs.

However, updating all the commmand-line and GUI tools, as well as any frameworks or other-more-than-bare-UNIX APIs to support ACLs is a lot of work.

Well, actually, no.

The POSIX.6 defined access control list has 3 mandatory entries: an owner entry (called the file owner class), an owner group entry (called the file group class), and a world entry. This allows the three entries of the permission bit mechanism (owner, group, and other) to also be considered an ACL, and hence, compatible with the POSIX.6 specified ACL interfaces. Calls made to modify these ACL entries will also modify the corresponding file permission bits. Likewise, calls made to modify the file permission bits will also modify the corresponding ACL entries. This is intended to support backward compatibility with the large pool of existing applications that use the interfaces to the file permission bit mechanism.

Source: http://csrc.nist.gov/publications/ni...-7/node27.html

[Amorph]

Originally posted by zzen
Well, actually, no.

Unless by "support" he meant "fully support." The backward compatibility is certainly welcome, but there's no particular reason to be satisfied with that. Fully ACL-savvy command-line tools would be terrific and useful feature, and also a significant amount of work.

[othello]

I am hoping for a GUI to set 'groups' in ACL's...