Can you confirm a security hole in file sharing?

Question

I have found a very annoying security hole, and I wonder if it is unique to my setup. I have my mini set up with file sharing turned on. It has 5 accounts, one administrator, rest ordinary users. My login for the administrative user on my laptop is the same as on the mini. I have not turned on "Back to my Mac."
From my laptop I navigate to the mini using either (a) the network panel in finder, (b) the local IP (afp://192.168.0.xxx), or the global IP (afp://64.xxx.xxx.xxx). (My router is set up to forward the appropriate ports to the mini's local IP). I mount the administrative user's home directory under apple file sharing. Now I have full access to these files. I DO NOT SAVE THE PASSWORD IN KEYCHAIN. All this is as it should be.
Now I eject the administrator disk.
From now on (until I reboot my laptop), I can mount that same disk without a password!
Can someone confirm?

Answer 1

{quote:title=William Lloyd wrote:}This is not a security hole.{quote}
While I can understand that some may consider Kerberos automagically creating what is essentially a keychain without the users express knowledge or consent a "feature", I definitely consider it a bug and a huge security hole.
The kerberos ticket should not live longer then the user is actually connected to the machine. Currently, if the user clicks the Disconnect button the Kerberos ticket lives on and any future connections to that server will user that ticket. This is not what users (especially novice to intermediate) would expect. If the user clicks the Disconnect button, then they would expect that they are completely disconnected and any further connections to that server would require authentication. Otherwise they leave their machine wide open, hense the security hole.
The other thing that makes this so nasty is that if the OS decides not to use kerberos, for whatever reason, the behavior is different. It behaves as the user would expect. Clicking Disconnect does completely disconnect you from the server and any future connections will require authentication. So at a minimum there is a dangerous inconsistency in behavior between when the OS uses Kerberos and when it doesn't. That, at a minimum, should be fixed.