You want to change the time zone? Eto Akta Gamat!
by Michael S. Kaplan, published on 2006/09/16 03:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/09/16/755152.aspx
(Bonus geek points for anyone who can identify the language and meaning of the end of the title without searching the web for it!)
When you want to change the time zone, you have to have enough permission to do so.
And it is more than just having the permissions, it is also adding a special privilege to your application before it can set things up, as described in this topic.
Now which privilege do you need?
Well, in Windows 2000, XP, and Server 2003, the application must have the SE_SYSTEMTIME_NAME privilege before calling SetTimeZoneInformation.
In Vista, the application must have the new SE_TIME_ZONE_NAME privilege before calling either SetTimeZoneInformation or the new SetDynamicTimeZoneInformation function.
This information is in the updated help topics. However, the reasoning behind the change is not.
For that I had to contact Geoff Pease (knowledgable shell developer and the unofficial "Father Time" owner of most of what involves times zones and time on Windows). Geoff had the scoop on the intent of the new privilege:
The old CPL only let those with SE_SYSTEMTIME be able to open the CPL. Someone decided to give everyone the right to change their time zone independent of setting the current time (security vulnerability). So they added the SE_TIME_ZONE to separate the "powers" and thus give everyone the ability to enable that privilege by default.
And so, yhis one SE_SYSTEMTIME_NAME privilege gives permission in prior versions for both the time zone and the system time, and if you want to grant yourself permission, you must basically be an admin on the machine. Windows is telling you, in other words, Eto akta Gamat.
But in truth, the problems one can cause by changing the system time that lead to potential security issues do not really apply to the time zone setting. So the new SE_TIME_ZONE_NAME, which most people can grant themselves, is sll you need in Vista.
Now the SetTimeZoneInformation help topic in the Platform SDK has the same code sample that is has always had in it, so it tries to set the SE_SYSTEMTIME_NAME privilege, which can lead to a bit of confusion if one is running on Vista and wondering why the code is failing with an ERROR_PRIVILEGE_NOT_HELD error (1314).
One could argue that SE_SYSTEMTIME_NAME should imply SE_TIME_ZONE_NAME and if one did argue that, I would not disagree. But that is not what is currently happening, so you have to use that new privelege on Vista. Though as a bonus at least you are more likely to be able to now then you were before!
Just something to keep in mind if you run into problems....
And be sure to let me know if you earned those bonus geek points. Eto Akta Gamat! :-)
This post brought to you by ඎ (U+0d83, a.k.a. SINHALA LETTER IRUUYANNA)
David Lashley on 16 Sep 2006 3:37 AM:
The Devine Language - 'Not without my permission' - The Fifth Element.
What can I say - I just love SiFi miovies!!
Stuart Ballard on 16 Sep 2006 10:06 AM:
I'm disappointed that I was beaten to it, but pleased that I can point out that in fact the correct translation is "*Never* without my permission" ;)
Michael S. Kaplan on 16 Sep 2006 1:01 PM:
Hi Stuart --
Yes, that is right. There is also the fact that David called it the "Devine" language -- presuably the language of the crossdresser
Devine? :-)
The funny part is that we do not know what the full translation of "Eto Akta Gamat" is -- Bruce asked the priest what "Akta Gamat! " meant and the priest gave the answer you did. Makds you wonder what "Eto" means in the divine language, don't it?
Either way, both of you get some geek points for knowing the reference....
Michael Dunn_ on 16 Sep 2006 2:08 PM:
The snippet from Geoff Pease makes it sound like some random person went and added a new privilege, but there's more to it than that. The old CPL has two problems:
1. You can't even run the CPL unless you are admin, because the CPL tries to get the SE_SYSTEMTIME_NAME privilege right away. So normal users can't use the CPL even if all they want to do is look at the calendar (which is really what people want to do most of the time).
2. People with locked-down laptops can't change the time zone when they travel.
#1 was remedied by adding a new bit of UI when you double-click the tray clock, but fixing #2 was the reason for the new priv.
Michael S. Kaplan on 16 Sep 2006 2:29 PM:
Yes, that is all true. But would there have been harm in allowing applications granted SE_SYSTEMTIME_NAME to also have implicit SE_TIME_ZONE_NAME type privileges, for the sake of backcompat?
Improvements should never regress the experience....
Michael Dunn_ on 16 Sep 2006 7:02 PM:
I'm gonna have to punt on that question, since I know little about how privs work internally. Are there any other privs that imply other privs like that?
Maurits on 17 Sep 2006 6:03 AM:
> Someone decided to give everyone the right to change their time zone independent of setting the current time (security vulnerability)
Security vulnerability??
On *nix systems, anybody can set their own TZ variable, even per-process. Haven't heard of any security vulnerabilities related to setting a lousy time zone.
Setting the time, sure...
Where's the security vulnerability possibilities in setting the user's time zone?
Michael S. Kaplan on 17 Sep 2006 7:59 AM:
There is not -- the security vulnerability refers to the time, not the time zone. That is why they have been separated in Vista.
ReallyEvilCanine on 18 Sep 2006 3:15 AM:
> Where's the security vulnerability possibilities in setting the user's time zone?
You see a security hole with being able to change time but not time zone? An otherwise locked-down machine which has its system clock tied to a time server can be sent through a time machine by changing the global TZ and rebooting. If I do local work or modifications to a local database and then sync to the main db server there's no way to prove the entries weren't done at the time shown.
Michael S. Kaplan on 18 Sep 2006 3:30 AM:
Actually, you are mistaken. NT does its work with UTC -- so time zones are just syntactic sugar that display UTC in as more palatable form.
This is very different from Win9x, where time zones are a much bigger concern since everything is stored in local time.
Adam on 18 Sep 2006 7:01 AM:
ReallyEvilCanine > Maurits was talking about chaning the current user's time zone, not the system one.
Seeing as a users TZ setting doesn't affect the values the user sees as returned by time() (or any of its Win32 or high-resolution equivalents), and won't even affect the TZ seen (or the TZ-dependent values as returned by localtime() or equivalents) by any processes not owned by the user (e.g. system processes, or other users' session - handy if there are multiple users on a system who are in different timezones), then unless the database runs as the user, *and* stores local dates/times, *and* does not remember the current TZ or UTC offset, then this won't be a problem.
(If you're using a database that does all this, but are expecting to get any kind of security from it, you've got big problems....)
What does it even mean for "the system" to have a timezone anyway? Yeah, it kind of makes sense for DOS & Win9x, where the system wasn't really multiuser in any meaningful way, and wasn't really remotely log-in-able, but on NT and Unix systems, it's a bit abstract.
Mike Dimmick on 18 Sep 2006 8:11 AM:
The security implication isn't really a vulnerability, it's just that Kerberos logon tickets incorporate a timestamp and duration of validity. The valid duration is quite short to prevent replay attacks. These timestamps are generated by the client when asking for a ticket and validated by the server; if the request is no longer valid according to the server's clock, the server rejects the request and the user cannot log on.
In practice this means that the workstations' clocks need to be kept closely in sync with the logon server. In Active Directory domains, a DC is a time source and the workstations and member servers get their time, by default, from a DC. The DCs should be synchronised with some external time source - for our single DC (yes, I know, we should have at least two) we synchronise with our ISPs NTP server.
Maurits on 18 Sep 2006 11:20 AM:
Ah, parsing error on my part... "security vulnerability" modifies "setting the current time", not "setting the time zone."
I apologize.
Michael S. Kaplan on 18 Sep 2006 12:01 PM:
I could add some parentheses if that would help? :-)
Please consider a
donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.
referenced by
go to newer or older post, or back to index or month or day