Имя объекта

Всем привет!

Может ли быть в имени объекта два или более бэкслеша подряд?
Если да, приведите примеры, пожалуйста.

 

Я лично такого не видел. Теоретическую возможность существования таких имён ты можешь легко проверить. Для этого нужно взять имя существующего файла (например, \??\C:\boot.ini), изменить его соответствующим образом (например, \??\C:\\boot.ini) и попробовать открыть через ZwOpenFile(). Если открытие пройдёт успешно и будет открыт именно тот файл, который ожидался, значит такие именно вполне могут существовать, в противном случае, если I/O Manager вернёт что-то типа STATUS_OBJECT_PATH_SYNTAX_BAD или типа того, - нет, такие имена просто не имеют смысла.

 

Благодарю за ответ. Проверить конечно можно. Меня интересует немного другое - могут ли быть такие ситуации и для других объектов, не только для файлов.

 

Парсер имён объектов для всех типов объектов используется один и тот же.

 

Может быть, встречал такое.

 

Приведи пример, что ли, да поподробнее - какое имя, какого объекта, тип объекта, какая была реакция у парсеров ядра и т.д.

 

Файловый объект, 2 слеша в пути было, а вот операцию уже не помню толи репарсинг, толи просто открытие, суть в том что операция была завершена успешно.

 

Ну вот и ответ, значит да.

 

А зачем же его выносить отдельным callback'ом тогда ? При открытии ключа реестра можно указать несколько бэкслешей-разделителей (но не всегда, есть свои особенности).

Код из WKR (разбор имени для ключей реестра):

Код (Text):

1.     while (*(RemainingName->Buffer) == OBJ_NAME_PATH_SEPARATOR) {
2.         RemainingName->Buffer++;
3.         RemainingName->Length -= sizeof(WCHAR);
4.         RemainingName->MaximumLength -= sizeof(WCHAR);
5.     }

 

Во-первых, метод ParseProcedure не для всех типов определён, во-вторых помимо этого есть и другая обработка имени, если не ошибаюсь, то где-то в ObpLookupObjectName() всё действо и происходит.

 

Функция ObpLookupObjectName, если текущий родительский объект не является директорией, вызывает ParseProcedure:

Код (Text):

1. Status = (*ObjectHeader->Type->TypeInfo.ParseProcedure)( RootDirectory,
2.                                                                              ObjectType,
3.                                                                              AccessState,
4.                                                                              AccessCheckMode,
5.                                                                              Attributes,
6.                                                                              ObjectName,
7.                                                                              &RemainingName,
8.                                                                              ParseContext,
9.                                                                              SecurityQos,
10.                                                                              &Object );

Эта логика применима для всех объектов, которые могут содержать дочерние. Остальные должны лежать в директориях. Если у объекта нет ParseProcedure и есть еще компоненты пути (т.е. идет попытка открытия или создания), то функция ObpLookupObjectName вернет STATUS_INVALID_HANDLE.
У реестра, как писал выше, очень специфичный парсер путей со своими хэш-таблицами и странностями.
Беглый поиск по сорцам WRK дает следующий список типов с "нестандартными" разборщиками путей:
- ключ реестра
- файл/устройство (именно этот разборщик посылает IRP_MJ_CREATE)
- WindowStation
- символические ссылки

 

Не то написал) В общем: объект либо должен быть последним элементом в пути, либо являться директорией, либо иметь ParseProcedure. В ином случае, функция ObpLookupObjectName(...) вернет ошибку.

А по теме: функция ObCreateObjectType экспортируется из ядра. Это означает, что я могу написать свой тип, реализовать ParseProcedure и обрабатывать бекслеши и прочие символы как мне будет удобно.