The kernel object namespace and Win32, part 2
来源:互联网 发布:防蓝光护眼软件 编辑:程序博客网 时间:2024/06/05 04:40
Last time, I talked about how the kernel object namespace intersects with the Win32 world as of how things stood in NT4 (and Windows 2000 when Terminal Server is disabled).
Although the object namespace model used in these operating systems worked well, some cracks began to appear in it with the introduction of Terminal Server as a mainstream product (and later, RunAs).
There are basically two problems that are imposed by Terminal Server:
- Many programs are designed to run as “singleton” programs, but in multi-session environments like Terminal Server, it is desirable to allow each session to run an instance of such programs. The classic way to enforce singleton behavior like this is to create a named kernel object at startup, and check to see if the object already existed before the program tried to create it. Without alterations to how the object namespace presented to Win32 functions, this would prevent singleton applications from working under Terminal Server.
- Drive letters and other “DOS Devices” symbolic links need to become “sessionized”, because the “glass terminal” (physical computer console) typically has things like COM1 or LPT1 pointing to physical serial ports or printer ports, whereas Terminal Server sessions might be using device redirection to point those device names to serial ports or printer ports on the Terminal Server client machine.
The solution to this problem was partitioning the view of the kernel object namespace provided to Win32 based on Terminal Server session id. This is done with the use of a set of symbolic links and object directories.
The basic idea is that session zero continues to use the \BaseNamedObjects object directory, as how things used to work on downlevel systems. In this object directory, there are a couple of new symbolic links:
- \Local, which points to the session local namespace. For session zero, this symbolic link typically points to \BaseNamedObjects. For other sessions, it points to a “sessionized” namespace, such as \Sessions\<Terminal-Server-Session-ID>\BaseNamedObjects.
- \Global, which always points to the session zero namespace (the “global” namespace). This always points to \BaseNamedObjects for all sessions.
- \Session, which points to \Sessions\BNOLINKS. This latter symbolic link is not documented (except to say that it is “reserved for system use”), but its function is to allow one session (with the appropriate access granted to it) to create objects in an arbitrary session local namespace, by using a path in the form \Session\<Terminal-Server-Session-ID>\ObjectName. \Sessions\BNOLINKS is an object directory which contains a set of symbolic link objects, each named after a Terminal Server session ID. These links point to the appropriate “sessionized” BaseNamedObjects directory for each session (such as \BaseNamedObjects for session zero, \Sessions\1\BaseNamedObjects for session 1, and soforth).
For sessions other than session zero, a BasedNamedObjects directory named in the form of \Sessions\<Terminal-Server-Session-ID>\BaseNamedObjects is created. This is the session local namespace for that session, and it is what is linked to via the “\Local” symbolic link. Additionally, a corresponding symbolic link in \Sessions\BNOLINKS is created so that the (undocumented) “\Session” link works for the new session.
This scheme allows for maximum compatibility with pre-Terminal Server applications which are not aware of the “session isolation” concept, and need some help in order to have their named objects placed in a “sessionized” location where they will not conflict with other user sessions. A means for programs that truly need globally-accessible object names is also provided (the magical \Global prefix symbolic link), which is typically used by services and user-level UI applications that need to communicate with their privileged service counterpart.
In addition to the session isolation of kernel object names, “DOS device” names also became isolated based on Terminal Server session ID. The way this works differs between Windows 2000 and future OS versions, though; I’ll cover it in the next installment of this series. The basic idea for Windows 2000 is that each session got its own directory for DOS device names, but Windows XP and beyond go one step further to better accomodate the “runas” case.
- The kernel object namespace and Win32, part 2
- The kernel object namespace and Win32, part 1
- The kernel object namespace and Win32, part 3
- Memory access ordering part 2 - barriers and the Linux kernel
- 《DLL for Win32/MFC》Part 1, The Win32 DLL Object
- ACL/CreateMapping/Kernel Object Namespace
- Debugging the kernel using Ftrace - part 2
- [win32] How to use WIN32 Event Kernel Object
- The Linux Kernel: Configuring the Kernel (Part 1)
- Object-Oriented JavaScript Part 2: How the prototype works
- The Kernel Newbie Corner: Kernel Debugging with proc "Sequence" Files--Part 2
- 内核对象命名空间(Kernel object namespace)
- Inside the Windows Vista Kernel: Part 1
- Debugging the kernel using Ftrace - part 1
- Peering Inside the PE: A Tour of the Win32 Portable Executable File Format - Part 2
- 《DLL for Win32/MFC》Part 4, MFC DLL Object
- Item 32. Name Lookup and the Interface Principle part 2
- Win32 Series - The GDI Bitmap Object
- ListView用法
- The kernel object namespace and Win32, part 1
- HDU 2845 Beans
- Tomcat 部署详解
- kibana查询语法
- The kernel object namespace and Win32, part 2
- J2EE初步
- 微信企业号开发01 - 获取corpid 和 corpsecret
- iOS中的动画
- 将树莓派作为自己的软件代码托管服务器!!!
- ListView中item点击事件失效的解决办法
- 红黑树(RB-tree)比AVL树的优势在哪?
- 对研发人员的全新认识
- The kernel object namespace and Win32, part 3