[ros-kernel] Re: File system struct

[Phillip S. <ps...@cf...>]

At 01:56 AM 5/1/2002 +0200, you wrote:
>At 05.33 30/04/2002, you wrote:
>>As for implementing /proc in the posix subsystem vs. the kernel, why 
>>should it be implemented in the kernel if it is only going to be seen by 
>>the posix subsystem?
>
>because it's a filesystem. Why don't you implement named pipes and 
>mailslots in user mode inside kernel32 and csrss? what's the difference?

ALL subsystems, and native applications see named pipes and mailslots, even 
kernel mode drivers.  They don't see /proc, only posix apps do, that's the 
difference.

>And I don't want to explain yet another time why /proc and /dev should be 
>visible to all subsystems. Let's just say they could all benefit from it. 
>Just like they should all benefit from NT security, Windows device 
>management (try, just for fun, to read a floppy disk under any Unix - try 
>Solaris for added fun), DDI drivers, etc.

/dev CAN't be visible to anything but posix applications, because only 
posix applications have any concept of what /dev is.  Win32 apps only 
understand that devices are files with special names, such as COM1, and 
native apps understand that they are device objects in the \Devices 
directory.  A posix /dev directory contains device nodes, which do not 
exist in the NT kernel, and therefore, the kernel can not export to user 
mode.  For this reason, devnodes have to be implemented in the posix 
subsystem.

While the /dev and /proc directories themselves can not be directly visible 
to native and win32 apps, some equivalents can be.  For instance, /dev/null 
is seen by win32 as the NUL device.  /dev/fd0 is seen as \\.\Floppy0, and 
so on.  On the other hand, you talked about it being useful for a win32 app 
to have access to /proc/pid/fd/0 to read from stdin, but this simply can 
not be done, because NT and win32 have no concept of file descriptors.  In 
posix, open files have integer descriptors starting from 0, and numbers 0, 
1, and 2 are reserved for stdin/out/err, but NT has opaque HANDLEs to all 
sorts of objects, not just files, and there are no reserved HANDLE values 
for stdin/out/err.  BTW: win32 apps can open the CON or CONIN$ or CONOUT$ 
files to get a handle to their console for IO, but they still get the 
console, even if stdin or out has been redirected.  I think that this 
should be fixed in ReactOS to return the handle that stdin/out has been 
redirected to.


>I think I already explained this:
>  1. introduce a new file information class (FilePosixInformation) for 
> attributes common to all Unix filesystems (owner, primary group, access 
> bitmask, file type bits). File attributes specific to some filesystems 
> (sparse, immutable, append-only, compressed, etc.) will be retrieved and 
> set through NtFsControlFile()

This is the sort of kludge/compromise that I was talking about.  If this 
were done, then posix apps and native/win32 apps would not see the files in 
the same way.  A posix app could chmod() a file to be read-only, but win32 
would not see it being marked read-only.  Conversely a win32 app could set 
the ACL of a file go grant read-only access to someone, who then logs into 
the posix subsystem, only to wonder why they can't write to it when the 
mode bits say they can ( because noone updated the FilePosixInformtion 
class when the ACL changed ).  Another problem is what if someone does an 
mknod() to create a device node?  What does win32 see this file as?  Just a 
useless 0 byte file?  Or would win32 be able to somehow open the device 
node, and get a real device?

>  2. Microsoft, amazingly, supports and documents translation between 
> Windows SIDs and POSIX uids and gids. Refer to the PSDK for details
>  3. while NT ACLs cannot be translated into access masks, the inverse is 
> true. We have two cases here:
>  3.1. POSIX app accessing Windows filesystem. All required fields, except 
> user id, group id and mode, can be retrieved without interpolation. For 
> files without an ACL, S_IRWXU | S_IRWXG | S_IRWXO will be returned as 
> access mask (that is, the file is freely accessible). Otherwise, the user 
> and group id are translated from the owner SID and the primary group SID. 
> If the ACL has a structure compatible with access masks, it is translated 
> directly, else a null mask can be returned, or a mask can be built 
> euristically. When the access mask is changed, the existing ACL on the 
> file is dropped and replaced with an ACL that is compatible with the 
> access mask (this is the standard behavior on ACL-enabled Unix systems)

OK, you have sold me on this point, the chmod mask can be emulated, but 
that means it is the posix subsystem that does the emulation, it wouldn't 
be stored in special attribute of the file.

>  3.2. Windows app accessing Unix filesystem. File attributes are 
> translated into the nearest equivalents (file name beginning with dot -> 
> hidden, ext2 immutable attribute -> read-only, etc.). Access masks are 
> translated into the equivalent ACLs and viceversa. But, if an ACL cannot 
> be translated into an access mask, an error is returned. The biggest 
> problem is that there's no reliable way to translate from user ids and 
> group ids to SIDs. It could be implemented by extending the LSA, but is 
> it worth it? The solution is simple: don't use Unix filesystems. Support 
> them for compatibility only. And implement special filesystems, like 
> /proc, /dev, but also named pipes and mailslots, with NT security semantics

We aren't running on a posix filesystem, we are running on an NT 
filesystem.  If you want to emulate win32 on posix, then that's what WINE 
is for, the goal of ReactOS is to provide an actual NT system.  I for one 
certainly don't want to give up ACLs.

>  4. make the ACL editors recognize both standards for ACE order in a 
> DACL: POSIX and Win32
>
>>If you are ever on irc, we could discuss this in #ReactOS.
>
>sounds fine. What server?

irc.openprojects.net.