ATTN: daemon maintainers -- proposed csih changes [Was: Re: [ITP] tftp-hpa 5.0]

[Charles Wilson <cygwin at cwilson dot fastmail dot fm>]

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