Restrict access to Time Machine Disk?

Jake, I've been playing with this idea since I read your post last night. After a couple of hours of tinkering with Airport Utility, Keychain Access, and the Finder's "Connect As..." feature, I am convinced it is possible - but not practical. The process appears to be rather fragile. And if you forgot how you configured it, it would be a nightmare to sort out the permissions issues that would result.

All I can suggest is submit an Enhancement Request via the following Feedback forms:

Airport Extreme Feedback:
http://www.apple.com/feedback/airportextreme.html

Mac OS X Feedback:
http://www.apple.com/feedback/macosx.html

Cheers!

I don't have the hardware you mention and don't know how the features you mention are set up, so can only speak generally, but it might be possible to restrict, somewhat, access to the keychain password by storing the password in the system keychain rather than the users' keychains (from which the password will have to be deleted), then restrict access to the system keychain so that regular users can't access it (since automatic password access is approved on a per-programme basis, without the last step, users invoking the programme would still get to use the password).

The gist is that since automatic backups are performed as "root", permissions that restrict access by the user will not prevent the backups from being made. However, by the same token, any "admin" user will still be able to override the restriction and access the bundles. Conversely, without knowing the sparse image password, non-admin users won't be able to browse even their own TimeMachine backups.

It might also be possible to restrict access at the level of the share/volume, sparse bundle, or the volume encoded on the sparse bundle, but I'm inclined to think that restriction at the password level would be preferable...

Edit: Of course, if this strategy would depend on there not being anything stored in the system keychain that users would need access to.

Hmm, two points come to mind (again, with the caveat that I don't have any of the equipment and can't test or check anything).

..." I think the reason this doesn't work as we'd expect is that it would kill the ability of TM to back up to the network disk when logged in as anything other than the Admin user."...

I don't think that's right -- if the password is stored in the "System" keychain, it shouldn't matter whether or not anyone is logged in. Just to make sure we aren't talking about different things, I was referring to the "System" keychain, not any individual users' keychain, including "admin" users or the "root" user. A user's login keychain would not normally be unlocked (requiring the user's password) unless they log in, but the system should have access to the "System" keychain whenever it needs it.

..." Even if I could hide just that particular share in the Finder sidebar, I'd be happy with that."...

That raises an important point that I had previously overlooked -- initially, when I had raised the possibility of restricting file access to the backup itself, I suggested that restricting access to the password would be better. However, upon further consideration, it would probably be preferable to do both, because while restricting access to the password would limit users' ability to mount the share and look at backups whenever they felt like it, it might not prevent them from browsing backups while the system has mounted the remote volume and is in the process of performing the backup. That too would depend on how things are mounted (which I have no way of checking).

Just something to keep in mind while you are experimenting...

"because while restricting access to the password would limit users' ability to mount the share and look at backups whenever they felt like it, it might not prevent them from browsing backups while the system has mounted the remote volume and is in the process of performing the backup."

biovizer, that is exactly what I was thinking when I read your first post. Unfortunately I'm at work now and am not in a position to test this on my config. If I remember, I'll try later. But, I think that this is the chink in the armour.

Yeah, unfortunately, as I said earlier, I really can only speculate.

Normally, "owners" is enabled on "TimeMachine" backup volumes so even if a user tried to access the backup volume during a backup, they technically should only be able access their own files and those that are accessible to everyone so it might not be an issue at all.

But if other computers also back up to the same remote drive, then a user on one machine might be able to mount the sparse bundle for another machine and access the files of the user with the corresponding ' uid' on the other machine. Again, I say "might" because I don't know how "TimeMachine" handles these situations or what sort of permissions are used. Depending on how the system mounts the share, the ownership of everything might end up being mapped to "root" and depending on permissions, users may not have sufficient privileges to see or mount anything.

I think the OP will probably just have to run some tests, but I imagine there would be a number of places (share, sparse bundle, volume on sparse bundle or subfolders) where a block can be put in place with "permissions".