shared_info::init_obcaseinsensitive implemented incorrectly

shared_info::init_obcaseinsensitive implemented incorrectly

[Nick Lowe]

Dear Cygwin Developers,

shared_info::init_obcaseinsensitive in shared.cc has, in my opinion,
been implemented incorrectly.

The value of the obcaseinsensitive value in the registry only
represents how the object manager will be on next reboot and not its
present state. Cygwin uses it as if it represents the present state,
however. This is likely to be true, but is not guaranteed to be.

To determine the present state, first get the system root path via either:

1) Querying the %SystemRoot% environment variable via
RtlExpandEnvironmentStrings_U and change it with
RtlDosPathNameToNtPathName_U (alternatively
RtlDosPathNameToNtPathName_U_WithStatus in Vista and later).

2) Querying the symbolic link target of \SystemRoot via
NtQuerySymbolicLinkObject. (Requires administrative rights.)

Then, check for existence of the uppercase form of the path with
NtQueryAttributesFile ensuring, obviously, that the
OBJ_CASE_INSENSITIVE flag is not set.

If the the NTSTATUS value is successful, the object manager is running
with case insensitivity, if not its running with case sensitivity.

With regards,

Nick Lowe

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: shared_info::init_obcaseinsensitive implemented incorrectly

[Nick Lowe]

Grr, I hit send before finishing writing this. I meant to write:

"Then, check for existence of the uppercase or lowercase form of the
path (choose appropriate casing based on the existing casing) with
NtQueryAttributesFile ensuring, obviously, that the
OBJ_CASE_INSENSITIVE flag is not set."

Cheers,

Nick

On Tue, Feb 21, 2012 at 8:59 AM, Nick Lowe <nick.lowe@gmail.com> wrote:
> Dear Cygwin Developers,
>
> shared_info::init_obcaseinsensitive in shared.cc has, in my opinion,
> been implemented incorrectly.
>
> The value of the obcaseinsensitive value in the registry only
> represents how the object manager will be on next reboot and not its
> present state. Cygwin uses it as if it represents the present state,
> however. This is likely to be true, but is not guaranteed to be.
>
> To determine the present state, first get the system root path via either:
>
> 1) Querying the %SystemRoot% environment variable via
> RtlExpandEnvironmentStrings_U and change it with
> RtlDosPathNameToNtPathName_U (alternatively
> RtlDosPathNameToNtPathName_U_WithStatus in Vista and later).
>
> 2) Querying the symbolic link target of \SystemRoot via
> NtQuerySymbolicLinkObject. (Requires administrative rights.)
>
> Then, check for existence of the uppercase form of the path with
> NtQueryAttributesFile ensuring, obviously, that the
> OBJ_CASE_INSENSITIVE flag is not set.
>
> If the the NTSTATUS value is successful, the object manager is running
> with case insensitivity, if not its running with case sensitivity.
>
> With regards,
>
> Nick Lowe

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: shared_info::init_obcaseinsensitive implemented incorrectly

[Corinna Vinschen]

On Feb 21 08:59, Nick Lowe wrote:
> Dear Cygwin Developers,
> 
> shared_info::init_obcaseinsensitive in shared.cc has, in my opinion,
> been implemented incorrectly.
> 
> The value of the obcaseinsensitive value in the registry only
> represents how the object manager will be on next reboot and not its
> present state. Cygwin uses it as if it represents the present state,
> however. This is likely to be true, but is not guaranteed to be.
> 
> To determine the present state, first get the system root path via either:
> 
> 1) Querying the %SystemRoot% environment variable via
> RtlExpandEnvironmentStrings_U and change it with
> RtlDosPathNameToNtPathName_U (alternatively
> RtlDosPathNameToNtPathName_U_WithStatus in Vista and later).
> 
> 2) Querying the symbolic link target of \SystemRoot via
> NtQuerySymbolicLinkObject. (Requires administrative rights.)
> 
> Then, check for existence of the uppercase form of the path with
> NtQueryAttributesFile ensuring, obviously, that the
> OBJ_CASE_INSENSITIVE flag is not set.
> 
> If the the NTSTATUS value is successful, the object manager is running
> with case insensitivity, if not its running with case sensitivity.

Sorry, but that's much too complicated.  This code is supposed to be
fast.  And the obcaseinsensitive setting in the registry is not
something which is going to be changed a lot.  And those who change it
know that it only has an effect after reboot, so they will reboot soon.
I'm perfectly fine with the fact that Cygwin will not be quite right
until the next reboot in this case.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: shared_info::init_obcaseinsensitive implemented incorrectly

[Nick Lowe]

OK, fair enough, it is an edge case... I am a stickler for correctness! :P

Looking at previous threads though actually, I notice that the
following is documented by Microsoft regarding the obcaseinsensitive
value:

"If this setting is enabled, case insensitivity is enforced for all
directory objects, symbolic links, and IO objects, including file
objects. Disabling this setting does not allow the Win32 subsystem to
become case sensitive."

You could just get away with therefore, in theory, a call to
NtOpenSymbolicLinkObject for \SYSTEMROOT. If it fails because it
cannot be found, you know that the system is running with case
sensitivity, otherwise, it is case sensitive.

Regards,

Nick

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: shared_info::init_obcaseinsensitive implemented incorrectly

[Nick Lowe]

I have just tested this and it works. It is faster, simpler and has
less overheads than querying the registry for a potentially stale
value.

Just call NtOpenSymbolicLinkObject for \SYSTEMROOT with a
DesiredAccess of 0 and no attributes flags in the OBJECT_ATTRIBUTES
structure.

This will fail with STATUS_ACCESS_DENIED if the system is running with
case insensitivity and STATUS_OBJECT_NAME_NOT_FOUND if running with
case sensitivity.

For correctness, on the off chance that a successful NTSTATUS value is
returned, the system is running with case insensitivity and the handle
must be closed.

Regards,

Nick

On Tue, Feb 21, 2012 at 9:52 AM, Nick Lowe <nick.lowe@gmail.com> wrote:
> OK, fair enough, it is an edge case... I am a stickler for correctness! :P
>
> Looking at previous threads though actually, I notice that the
> following is documented by Microsoft regarding the obcaseinsensitive
> value:
>
> "If this setting is enabled, case insensitivity is enforced for all
> directory objects, symbolic links, and IO objects, including file
> objects. Disabling this setting does not allow the Win32 subsystem to
> become case sensitive."
>
> You could just get away with therefore, in theory, a call to
> NtOpenSymbolicLinkObject for \SYSTEMROOT. If it fails because it
> cannot be found, you know that the system is running with case
> sensitivity, otherwise, it is case sensitive.
>
> Regards,
>
> Nick

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: shared_info::init_obcaseinsensitive implemented incorrectly

[Corinna Vinschen]

On Feb 21 10:26, Nick Lowe wrote:
> I have just tested this and it works. It is faster, simpler and has
> less overheads than querying the registry for a potentially stale
> value.
> 
> Just call NtOpenSymbolicLinkObject for \SYSTEMROOT with a
> DesiredAccess of 0 and no attributes flags in the OBJECT_ATTRIBUTES
> structure.
> 
> This will fail with STATUS_ACCESS_DENIED if the system is running with
> case insensitivity and STATUS_OBJECT_NAME_NOT_FOUND if running with
> case sensitivity.
> 
> For correctness, on the off chance that a successful NTSTATUS value is

That's not an off-chance.  It works for all admin accounts.

> returned, the system is running with case insensitivity and the handle
> must be closed.

Just call NtOpenDirectoryObject on \\SYSTEMROOT, rather than
NtOpenSymbolicLinkObject.  NtOpenDirectoryObject will never succeed,
rather it returns STATUS_OBJECT_TYPE_MISMATCH on a case insensitive
system and STATUS_OBJECT_NAME_NOT_FOUND on a case sensitive system.

And then there's Windows 2000 which is always case sensitive.  But I
documented to require the registry key for least surprise, see
http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-casesensitive

I'm going to add this to the Cygwin DLL, but right now I have to
debug another problem.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: shared_info::init_obcaseinsensitive implemented incorrectly

[Nick Lowe]

I really should subscribe to get individual messages and not just the
digest so that I can reply properly. Sorry!

> Just call NtOpenDirectoryObject on \\SYSTEMROOT, rather than NtOpenSymbolicLinkObject.

I would have thought that NtOpenSymbolicLinkObject would have been the
more correct approach as the object expected is a symbolic link. No?

>That's not an off-chance.  It works for all admin accounts.

Hmm, strange. Unless the query (0x1) symbolic link specific access
right is specified, I always get STATUS_ACCESS_DENIED. With it
specified, it succeeds as an administrator or fails otherwise.
(I have only tested this under 64-bit Windows 7.)

Regards,

Nick

On Tue, Feb 21, 2012 at 10:26 AM, Nick Lowe <nick.lowe@gmail.com> wrote:
> I have just tested this and it works. It is faster, simpler and has
> less overheads than querying the registry for a potentially stale
> value.
>
> Just call NtOpenSymbolicLinkObject for \SYSTEMROOT with a
> DesiredAccess of 0 and no attributes flags in the OBJECT_ATTRIBUTES
> structure.
>
> This will fail with STATUS_ACCESS_DENIED if the system is running with
> case insensitivity and STATUS_OBJECT_NAME_NOT_FOUND if running with
> case sensitivity.
>
> For correctness, on the off chance that a successful NTSTATUS value is
> returned, the system is running with case insensitivity and the handle
> must be closed.
>
> Regards,
>
> Nick
>
> On Tue, Feb 21, 2012 at 9:52 AM, Nick Lowe <nick.lowe@gmail.com> wrote:
>> OK, fair enough, it is an edge case... I am a stickler for correctness! :P
>>
>> Looking at previous threads though actually, I notice that the
>> following is documented by Microsoft regarding the obcaseinsensitive
>> value:
>>
>> "If this setting is enabled, case insensitivity is enforced for all
>> directory objects, symbolic links, and IO objects, including file
>> objects. Disabling this setting does not allow the Win32 subsystem to
>> become case sensitive."
>>
>> You could just get away with therefore, in theory, a call to
>> NtOpenSymbolicLinkObject for \SYSTEMROOT. If it fails because it
>> cannot be found, you know that the system is running with case
>> sensitivity, otherwise, it is case sensitive.
>>
>> Regards,
>>
>> Nick

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: shared_info::init_obcaseinsensitive implemented incorrectly

[Corinna Vinschen]

Please, don't http://cygwin.com/acronyms/#TOFU


On Feb 21 11:34, Nick Lowe wrote:
> I really should subscribe to get individual messages and not just the
> digest so that I can reply properly. Sorry!
> 
> > Just call NtOpenDirectoryObject on \\SYSTEMROOT, rather than NtOpenSymbolicLinkObject.
> 
> I would have thought that NtOpenSymbolicLinkObject would have been the
> more correct approach as the object expected is a symbolic link. No?

Depends on what you define as correct.  Since you only call the function
to find out the state of case sensitivity and don't need the handle,
why not use a function which you know fails in a specific way?

> >That's not an off-chance.  It works for all admin accounts.
> 
> Hmm, strange. Unless the query (0x1) symbolic link specific access
> right is specified, I always get STATUS_ACCESS_DENIED. With it
> specified, it succeeds as an administrator or fails otherwise.

I missed that.  You're right, with a 0 access mask it fails with
STATUS_ACCESS_DENIED.  Well, it works one way or the other, right? :)


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: shared_info::init_obcaseinsensitive implemented incorrectly

[Corinna Vinschen]

On Feb 21 12:55, Corinna Vinschen wrote:
> 
> 
> Please, don't http://cygwin.com/acronyms/#TOFU
> 
> 
> On Feb 21 11:34, Nick Lowe wrote:
> > I really should subscribe to get individual messages and not just the
> > digest so that I can reply properly. Sorry!
> > 
> > > Just call NtOpenDirectoryObject on \\SYSTEMROOT, rather than NtOpenSymbolicLinkObject.
> > 
> > I would have thought that NtOpenSymbolicLinkObject would have been the
> > more correct approach as the object expected is a symbolic link. No?
> 
> Depends on what you define as correct.  Since you only call the function
> to find out the state of case sensitivity and don't need the handle,
> why not use a function which you know fails in a specific way?
> 
> > >That's not an off-chance.  It works for all admin accounts.
> > 
> > Hmm, strange. Unless the query (0x1) symbolic link specific access
> > right is specified, I always get STATUS_ACCESS_DENIED. With it
> > specified, it succeeds as an administrator or fails otherwise.
> 
> I missed that.  You're right, with a 0 access mask it fails with
> STATUS_ACCESS_DENIED.  Well, it works one way or the other, right? :)

I applied a matching patch:

  http://cygwin.com/ml/cygwin-cvs/2012-q1/msg00115.html


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple