On 11/15/2010 9:26 AM, Corinna Vinschen wrote:
> The 64 bit kernel was developed after the XP 5.1 kernel. The resulting
> 64 bit-clean 5.2 kernel was then used for XP 64, 2K3 32 and 64 bit. The
> numbering makes a lot of sense, given the history. And so, obviously,
> XP 64 shares the new behaviour in some respect(*) with 2K3.
>
> (*) The SYSTEM user restriction when starting a service is just one
> difference. There are more. For instance, the new SO_REUSEADDR
> socket binding behaviour, or the fact that \Device\PhysicalMemory is
> not accessible from user space anymore.
Thanks for the info.
So, it looks there are two issues:
#1a) csih_is_nt2003 -- defined as "Windows Server 2003 or above" -- as
currently implemented, isn't. It's kernel=5.2 or above, which also
includes XP64.
#1b) csih_is_xp is actually ok (it returns true for XP64 only because it
will return true for ANY os with kernel >= 5.1 -- so 5.2 satisfies.
#2) using csih_is_nt2003 as a proxy for "SYSTEM user doesn't have full
access" is bad.
I propose to update csih as follows, in two steps:
Step #1:
Add a new capability check function:
'csih_local_system_user_is_restricted'
that simply checks for kernel >= 5.2. That is, it acts like today's
csih_is_nt2003.
Update csih_is_nt2003 to print a warning message
'Warning: script may be using csih_is_nt2003 as a proxy for whether the
Local System user account has expected privileges. If so, the script
should use the new csih_local_system_user_is_restricted function instead.'
... wait six months. Hopefully that will be sufficient for all current
clients of csih (exim, ssh, cron, inetutils...) to update ...
Step #2
Update csih_is_nt2003 to check explicitly for XP64 (using
winProductName) and exclude it.
Does that sound like a good plan?
--
Chuck
