[simias]

Are you sure? If it is it sounds like a possible security issue. Time is pretty sensitive as soon as certificates are involved. Many auth systems assume the clock is properly synchronized across the system.

If that's true IMO that's the security issue, not the arguably strange behaviour of sudo in a situation that should never occur.

[dazzawazza]

well from the terminal

   $ date 010101011970
   date: bind: Permission denied
   date: settimeofday (timeval): Operation not permitted
   [15:45:41][[e-mail]:~]

From System Preferences you can indeed set the date back to 1970:

   $ date
   Fri  2 Jan 1970 00:56:44 BST
   [00:56:44][[e-mail]:~]

but there is a little lock that you might need to unlock (with a user password).

This does seem like a security issue on OSX.

[adestefan]

That little lock icon is the same as running sudo from the command line. If the user is listed as an Administrator, then they're also able to sudo.

[pschastain]

Changing back 01/01/1970 via Date & Time preferences doesn't need authentication, but the exploit still didn't work, at least for me.

[acdha]

> Changing back 01/01/1970 via Date & Time preferences doesn't need authentication

This is not true but it can be confusing if you've authenticated at all recently due to a grace period like sudo's.

[nwh]

I've never unlocked that panel, and I've rebooted recently, and still didn't need authentication. Are you sure that's as right?

[adestefan]

The authentication for changing things via the System Preferences system is independent of sudo and "sticks" across reboots.

[glitch]

Is your account an Administrator account? Normal users are just Standard accounts and not Administrators.