[RFC,1/9] ntsync: Introduce the ntsync driver and character device.

  ntsync uses a misc device as the simplest and least intrusive uAPI interface.

Each file description on the device represents an isolated NT instance, intended
to correspond to a single NT virtual machine.

Signed-off-by: Elizabeth Figura <zfigura@codeweavers.com>
---
 drivers/misc/Kconfig  |  9 ++++++++
 drivers/misc/Makefile |  1 +
 drivers/misc/ntsync.c | 53 +++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 63 insertions(+)
 create mode 100644 drivers/misc/ntsync.c
  

On Wed, Jan 24, 2024, at 01:40, Elizabeth Figura wrote:
> ntsync uses a misc device as the simplest and least intrusive uAPI interface.
>
> Each file description on the device represents an isolated NT instance, intended
> to correspond to a single NT virtual machine.
>
> Signed-off-by: Elizabeth Figura <zfigura@codeweavers.com>

I'm looking at the ioctl interface to ensure it's well-formed.

Your patches look ok from that perspective, but there are a
few minor things I would check for consistency here:

> +
> +static const struct file_operations ntsync_fops = {
> +	.owner		= THIS_MODULE,
> +	.open		= ntsync_char_open,
> +	.release	= ntsync_char_release,
> +	.unlocked_ioctl	= ntsync_char_ioctl,
> +	.compat_ioctl	= ntsync_char_ioctl,
> +	.llseek		= no_llseek,
> +};

The .compat_ioctl pointer should point to compat_ptr_ioctl()
since the actual ioctl commands all take pointers instead
of interpreting the argument as a number.

On x86 and arm64 this won't make a difference as compat_ptr()
is a nop.

     Arnd
  

On Wednesday, 24 January 2024 01:38:52 CST Arnd Bergmann wrote:
> On Wed, Jan 24, 2024, at 01:40, Elizabeth Figura wrote:
> > ntsync uses a misc device as the simplest and least intrusive uAPI interface.
> >
> > Each file description on the device represents an isolated NT instance, intended
> > to correspond to a single NT virtual machine.
> >
> > Signed-off-by: Elizabeth Figura <zfigura@codeweavers.com>
> 
> I'm looking at the ioctl interface to ensure it's well-formed.
> 
> Your patches look ok from that perspective, but there are a
> few minor things I would check for consistency here:
> 
> > +
> > +static const struct file_operations ntsync_fops = {
> > +	.owner		= THIS_MODULE,
> > +	.open		= ntsync_char_open,
> > +	.release	= ntsync_char_release,
> > +	.unlocked_ioctl	= ntsync_char_ioctl,
> > +	.compat_ioctl	= ntsync_char_ioctl,
> > +	.llseek		= no_llseek,
> > +};
> 
> The .compat_ioctl pointer should point to compat_ptr_ioctl()
> since the actual ioctl commands all take pointers instead
> of interpreting the argument as a number.
> 
> On x86 and arm64 this won't make a difference as compat_ptr()
> is a nop.

Thanks; will fix.
  

On Tue, Jan 23, 2024 at 4:59 PM Elizabeth Figura
<zfigura@codeweavers.com> wrote:
>
> ntsync uses a misc device as the simplest and least intrusive uAPI interface.
>
> Each file description on the device represents an isolated NT instance, intended
> to correspond to a single NT virtual machine.

If I understand this text right, and if I understood the code right,
you're saying that each open instance of the device represents an
entire universe of NT synchronization objects, and no security or
isolation is possible between those objects.  For single-process use,
this seems fine.  But fork() will be a bit odd (although NT doesn't
really believe in fork, so maybe this is fine).

Except that NT has *named* semaphores and such.  And I'm pretty sure
I've written GUI programs that use named synchronization objects (IIRC
they were events, and this was a *very* common pattern, regularly
discussed in MSDN, usenet, etc) to detect whether another instance of
the program is running.  And this all works on real Windows because
sessions have sufficiently separated namespaces, and the security all
works out about as any other security on Windows, etc.  But
implementing *that* on top of this
file-description-plus-integer-equals-object will be fundamentally
quite subject to one buggy program completely clobbering someone
else's state.

Would it make sense and scale appropriately for an NT synchronization
*object* to be a Linux open file description?  Then SCM_RIGHTS could
pass them around, an RPC server could manage *named* objects, and
they'd generally work just like other "Object Manager" objects like,
say, files.

--Andy
  

On Wednesday, 24 January 2024 15:26:15 CST Andy Lutomirski wrote:
> On Tue, Jan 23, 2024 at 4:59 PM Elizabeth Figura
> <zfigura@codeweavers.com> wrote:
> >
> > ntsync uses a misc device as the simplest and least intrusive uAPI interface.
> >
> > Each file description on the device represents an isolated NT instance, intended
> > to correspond to a single NT virtual machine.
> 
> If I understand this text right, and if I understood the code right,
> you're saying that each open instance of the device represents an
> entire universe of NT synchronization objects, and no security or
> isolation is possible between those objects.  For single-process use,
> this seems fine.  But fork() will be a bit odd (although NT doesn't
> really believe in fork, so maybe this is fine).
> 
> Except that NT has *named* semaphores and such.  And I'm pretty sure
> I've written GUI programs that use named synchronization objects (IIRC
> they were events, and this was a *very* common pattern, regularly
> discussed in MSDN, usenet, etc) to detect whether another instance of
> the program is running.  And this all works on real Windows because
> sessions have sufficiently separated namespaces, and the security all
> works out about as any other security on Windows, etc.  But
> implementing *that* on top of this
> file-description-plus-integer-equals-object will be fundamentally
> quite subject to one buggy program completely clobbering someone
> else's state.
> 
> Would it make sense and scale appropriately for an NT synchronization
> *object* to be a Linux open file description?  Then SCM_RIGHTS could
> pass them around, an RPC server could manage *named* objects, and
> they'd generally work just like other "Object Manager" objects like,
> say, files.

It's a sensible concern. I think when I discussed this with Alexandre
Julliard (the Wine maintainer, CC'd) the conclusion was this wasn't
something we were concerned about.

While the current model *does* allow for processes to arbitrarily mess
with each other, accidentally or not, I think we're not concerned with
the scope of that than we are about implementing a whole scheduler in
user space.

For one, you can't corrupt the wineserver state this way—wineserver
being sort of like a dedicated process that handles many of the things
that a kernel would, and so sometimes needs to set or reset events, or
perform NTSYNC_IOC_KILL_MUTEX, but never relies on ntsync object state.
Whereas trying to implement a scheduler in user space would involve the
wineserver taking locks, and hence other processes could deadlock.

For two, it's probably a lot harder to mess with that internal state
accidentally.

[There is also a potential problem where some broken applications
create a million (literally) sync objects. Making these into files runs
into NOFILE. We did specifically push distributions and systemd to
increase those limits because an older solution *did* use eventfds and
*did* run into those limits. Since that push was successful I don't
know if this is *actually* a concern anymore, but avoiding files is
probably not a bad thing either.]

--Zeb
  

On Wednesday, 24 January 2024 16:56:23 CST Elizabeth Figura wrote:
> On Wednesday, 24 January 2024 15:26:15 CST Andy Lutomirski wrote:
> 
> > On Tue, Jan 23, 2024 at 4:59 PM Elizabeth Figura
> > <zfigura@codeweavers.com> wrote:
> > 
> > >
> > >
> > > ntsync uses a misc device as the simplest and least intrusive uAPI
> > > interface.
> >
> > >
> > >
> > > Each file description on the device represents an isolated NT instance,
> > > intended to correspond to a single NT virtual machine.
> > 
> > 
> > If I understand this text right, and if I understood the code right,
> > you're saying that each open instance of the device represents an
> > entire universe of NT synchronization objects, and no security or
> > isolation is possible between those objects.  For single-process use,
> > this seems fine.  But fork() will be a bit odd (although NT doesn't
> > really believe in fork, so maybe this is fine).
> > 
> > Except that NT has *named* semaphores and such.  And I'm pretty sure
> > I've written GUI programs that use named synchronization objects (IIRC
> > they were events, and this was a *very* common pattern, regularly
> > discussed in MSDN, usenet, etc) to detect whether another instance of
> > the program is running.  And this all works on real Windows because
> > sessions have sufficiently separated namespaces, and the security all
> > works out about as any other security on Windows, etc.  But
> > implementing *that* on top of this
> > file-description-plus-integer-equals-object will be fundamentally
> > quite subject to one buggy program completely clobbering someone
> > else's state.
> > 
> > Would it make sense and scale appropriately for an NT synchronization
> > *object* to be a Linux open file description?  Then SCM_RIGHTS could
> > pass them around, an RPC server could manage *named* objects, and
> > they'd generally work just like other "Object Manager" objects like,
> > say, files.
> 
> 
> It's a sensible concern. I think when I discussed this with Alexandre
> Julliard (the Wine maintainer, CC'd) the conclusion was this wasn't
> something we were concerned about.
> 
> While the current model *does* allow for processes to arbitrarily mess
> with each other, accidentally or not, I think we're not concerned with
> the scope of that than we are about implementing a whole scheduler in
> user space.
> 
> For one, you can't corrupt the wineserver state this way—wineserver
> being sort of like a dedicated process that handles many of the things
> that a kernel would, and so sometimes needs to set or reset events, or
> perform NTSYNC_IOC_KILL_MUTEX, but never relies on ntsync object state.
> Whereas trying to implement a scheduler in user space would involve the
> wineserver taking locks, and hence other processes could deadlock.
> 
> For two, it's probably a lot harder to mess with that internal state
> accidentally.
> 
> [There is also a potential problem where some broken applications
> create a million (literally) sync objects. Making these into files runs
> into NOFILE. We did specifically push distributions and systemd to
> increase those limits because an older solution *did* use eventfds and
> *did* run into those limits. Since that push was successful I don't
> know if this is *actually* a concern anymore, but avoiding files is
> probably not a bad thing either.]

Of course, looking at it from a kernel maintainer's perspective, it wouldn't 
be insane to do this anyway. If we at some point do start to care about cross-
process isolation in this way, or if another NT emulator wants to use this 
interface and does care about cross-process isolation, it'll be necessary. At 
least it'd make sense to make them separate files even if we don't implement 
granular permission handling just yet.

The main question is, is NOFILE a realistic concern, and what other problems 
might there be, in terms of making these heavier objects? Besides memory usage 
I can't think of any, but of course I don't have much knowledge of this area.

Alternatively, maybe there's another more lightweight way to store per-process 
data?
  

Elizabeth Figura <zfigura@codeweavers.com> writes:

> On Wednesday, 24 January 2024 15:26:15 CST Andy Lutomirski wrote:
>> On Tue, Jan 23, 2024 at 4:59 PM Elizabeth Figura
>> <zfigura@codeweavers.com> wrote:
>> >
>> > ntsync uses a misc device as the simplest and least intrusive uAPI interface.
>> >
>> > Each file description on the device represents an isolated NT instance, intended
>> > to correspond to a single NT virtual machine.
>> 
>> If I understand this text right, and if I understood the code right,
>> you're saying that each open instance of the device represents an
>> entire universe of NT synchronization objects, and no security or
>> isolation is possible between those objects.  For single-process use,
>> this seems fine.  But fork() will be a bit odd (although NT doesn't
>> really believe in fork, so maybe this is fine).
>> 
>> Except that NT has *named* semaphores and such.  And I'm pretty sure
>> I've written GUI programs that use named synchronization objects (IIRC
>> they were events, and this was a *very* common pattern, regularly
>> discussed in MSDN, usenet, etc) to detect whether another instance of
>> the program is running.  And this all works on real Windows because
>> sessions have sufficiently separated namespaces, and the security all
>> works out about as any other security on Windows, etc.  But
>> implementing *that* on top of this
>> file-description-plus-integer-equals-object will be fundamentally
>> quite subject to one buggy program completely clobbering someone
>> else's state.
>> 
>> Would it make sense and scale appropriately for an NT synchronization
>> *object* to be a Linux open file description?  Then SCM_RIGHTS could
>> pass them around, an RPC server could manage *named* objects, and
>> they'd generally work just like other "Object Manager" objects like,
>> say, files.
>
> It's a sensible concern. I think when I discussed this with Alexandre
> Julliard (the Wine maintainer, CC'd) the conclusion was this wasn't
> something we were concerned about.
>
> While the current model *does* allow for processes to arbitrarily mess
> with each other, accidentally or not, I think we're not concerned with
> the scope of that than we are about implementing a whole scheduler in
> user space.

I may have misunderstood something in that dicussion then, because it
would definitely be a concern. It's OK for a process to be able to mess
up the state of any object that it has an NT handle to, but it shouldn't
be possible to mess up the state of unrelated objects in other processes
simply by passing the wrong integer id.

The concern is not so much about a malicious process going out of its
way to corrupt others, because it could do that through the NT API just
as well. But if a wayward pointer corrupts the client-side handle cache,
that shouldn't take down the entire session.
  

On Thu, Jan 25, 2024, at 04:42, Elizabeth Figura wrote:
> On Wednesday, 24 January 2024 16:56:23 CST Elizabeth Figura wrote:
>> On Wednesday, 24 January 2024 15:26:15 CST Andy Lutomirski wrote:
>> > On Tue, Jan 23, 2024 at 4:59 PM Elizabeth Figura <zfigura@codeweavers.com> wrote:
>> 
>> [There is also a potential problem where some broken applications
>> create a million (literally) sync objects. Making these into files runs
>> into NOFILE. We did specifically push distributions and systemd to
>> increase those limits because an older solution *did* use eventfds and
>> *did* run into those limits. Since that push was successful I don't
>> know if this is *actually* a concern anymore, but avoiding files is
>> probably not a bad thing either.]
>
> Of course, looking at it from a kernel maintainer's perspective, it wouldn't 
> be insane to do this anyway. If we at some point do start to care about cross-
> process isolation in this way, or if another NT emulator wants to use this 
> interface and does care about cross-process isolation, it'll be necessary. At 
> least it'd make sense to make them separate files even if we don't implement 
> granular permission handling just yet.

I can think of a few other possible benefits of going with
per-mutex file descriptors:

- being able to use poll() for waiting on them individually in
  combination with other file descriptor based events (socket,
  signalfd, pidfd, ...)

- replacing your logic around xarray with something a bit
  simpler. As far as I can tell, your code is all correct here,
  but it would be easier to understand if it looked more like
  other code I'm familiar with.

> The main question is, is NOFILE a realistic concern, and what other problems 
> might there be, in terms of making these heavier objects? Besides memory usage 
> I can't think of any, but of course I don't have much knowledge of this area.

I would think that RLIMIT_NOFILE is a sensible way of
managing this, at least this way it's possible to prevent
exhausting memory with too many mutexes, but still raising
the limit if you need more than whatever default one might
come up with.

     Arnd
  

On Thursday, 25 January 2024 10:47:49 CST Arnd Bergmann wrote:
> On Thu, Jan 25, 2024, at 04:42, Elizabeth Figura wrote:
> > On Wednesday, 24 January 2024 16:56:23 CST Elizabeth Figura wrote:
> >> On Wednesday, 24 January 2024 15:26:15 CST Andy Lutomirski wrote:
> >> > On Tue, Jan 23, 2024 at 4:59 PM Elizabeth Figura 
<zfigura@codeweavers.com> wrote:
> >> [There is also a potential problem where some broken applications
> >> create a million (literally) sync objects. Making these into files runs
> >> into NOFILE. We did specifically push distributions and systemd to
> >> increase those limits because an older solution *did* use eventfds and
> >> *did* run into those limits. Since that push was successful I don't
> >> know if this is *actually* a concern anymore, but avoiding files is
> >> probably not a bad thing either.]
> > 
> > Of course, looking at it from a kernel maintainer's perspective, it
> > wouldn't be insane to do this anyway. If we at some point do start to
> > care about cross- process isolation in this way, or if another NT
> > emulator wants to use this interface and does care about cross-process
> > isolation, it'll be necessary. At least it'd make sense to make them
> > separate files even if we don't implement granular permission handling
> > just yet.
> 
> I can think of a few other possible benefits of going with
> per-mutex file descriptors:
> 
> - being able to use poll() for waiting on them individually in
>   combination with other file descriptor based events (socket,
>   signalfd, pidfd, ...)

I can say for sure this isn't going to be useful for Wine, at least not with 
the current design.

It also doesn't really mesh well with the NT design in the first place. 
NTSYNC_IOC_WAIT_ANY differs from poll() in two major ways: it consumes state 
of most object types, and (as coded here) it needs the owner thread ID to be 
specifically passed for mutexes.


Anyway, as Alexandre has informed me I clearly have misunderstood our 
requirements, so I'm going to try to put together something using files 
instead.
  

On Wed, Jan 24, 2024 at 7:42 PM Elizabeth Figura
<zfigura@codeweavers.com> wrote:
>
> On Wednesday, 24 January 2024 16:56:23 CST Elizabeth Figura wrote:
> > On Wednesday, 24 January 2024 15:26:15 CST Andy Lutomirski wrote:
> >
> > > On Tue, Jan 23, 2024 at 4:59 PM Elizabeth Figura
> > > <zfigura@codeweavers.com> wrote:
> > >
> > > >
> > > >
> > > > ntsync uses a misc device as the simplest and least intrusive uAPI
> > > > interface.
> > >
> > > >
> > > >
> > > > Each file description on the device represents an isolated NT instance,
> > > > intended to correspond to a single NT virtual machine.
> > >
> > >
> > > If I understand this text right, and if I understood the code right,
> > > you're saying that each open instance of the device represents an
> > > entire universe of NT synchronization objects, and no security or
> > > isolation is possible between those objects.  For single-process use,
> > > this seems fine.  But fork() will be a bit odd (although NT doesn't
> > > really believe in fork, so maybe this is fine).
> > >
> > > Except that NT has *named* semaphores and such.  And I'm pretty sure
> > > I've written GUI programs that use named synchronization objects (IIRC
> > > they were events, and this was a *very* common pattern, regularly
> > > discussed in MSDN, usenet, etc) to detect whether another instance of
> > > the program is running.  And this all works on real Windows because
> > > sessions have sufficiently separated namespaces, and the security all
> > > works out about as any other security on Windows, etc.  But
> > > implementing *that* on top of this
> > > file-description-plus-integer-equals-object will be fundamentally
> > > quite subject to one buggy program completely clobbering someone
> > > else's state.
> > >
> > > Would it make sense and scale appropriately for an NT synchronization
> > > *object* to be a Linux open file description?  Then SCM_RIGHTS could
> > > pass them around, an RPC server could manage *named* objects, and
> > > they'd generally work just like other "Object Manager" objects like,
> > > say, files.
> >
> >
> > It's a sensible concern. I think when I discussed this with Alexandre
> > Julliard (the Wine maintainer, CC'd) the conclusion was this wasn't
> > something we were concerned about.
> >
> > While the current model *does* allow for processes to arbitrarily mess
> > with each other, accidentally or not, I think we're not concerned with
> > the scope of that than we are about implementing a whole scheduler in
> > user space.
> >
> > For one, you can't corrupt the wineserver state this way—wineserver
> > being sort of like a dedicated process that handles many of the things
> > that a kernel would, and so sometimes needs to set or reset events, or
> > perform NTSYNC_IOC_KILL_MUTEX, but never relies on ntsync object state.
> > Whereas trying to implement a scheduler in user space would involve the
> > wineserver taking locks, and hence other processes could deadlock.
> >
> > For two, it's probably a lot harder to mess with that internal state
> > accidentally.
> >
> > [There is also a potential problem where some broken applications
> > create a million (literally) sync objects. Making these into files runs
> > into NOFILE. We did specifically push distributions and systemd to
> > increase those limits because an older solution *did* use eventfds and
> > *did* run into those limits. Since that push was successful I don't
> > know if this is *actually* a concern anymore, but avoiding files is
> > probably not a bad thing either.]
>
> Of course, looking at it from a kernel maintainer's perspective, it wouldn't
> be insane to do this anyway. If we at some point do start to care about cross-
> process isolation in this way, or if another NT emulator wants to use this
> interface and does care about cross-process isolation, it'll be necessary At
> least it'd make sense to make them separate files even if we don't implement
> granular permission handling just yet.

I'm not convinced that any complexity at all beyond using individual
files is needed for granular permission handling.  Unless something
actually needs permission bits on different files pointing at the same
sync object (which I believe NT supports, but it's sort of an odd
concept and I'm not immediately convinced that anything uses it),
merely having individual files ought to do the trick.  Handling of who
has permission to open a given named object can live in a daemon, and
I'd guess that Wine even already implements this.

And keeping everything together gives me flashbacks of Windows 95 and
Mac OS pre-X.  Sure, in principle the software wasn't malicious, but
there was no shortage whatsoever of buggy crap out there, and systems
were quite unstable.  Even just:

CreateSemaphore();
fork();
sleep a few seconds;
exit();

seems like it could corrupt the shared namespace world.  (Obviously no
one would ever do that, right?)

Also, handle leaks:

while(true) {
  make a subprocess, which creates a semaphore and crashes;
}

>
> The main question is, is NOFILE a realistic concern, and what other problems
> might there be, in terms of making these heavier objects? Besides memory usage
> I can't think of any, but of course I don't have much knowledge of this area.

Years ago there was some discussion of making struct file
lighter-weight for light-weight things that aren't files.  And, in any
case, even the little integer indices in your code aren't free -- they
just aren't accounted as files.

And struct file isn't *that* bad.  I bet it's not dramatically bigger,
or even smaller, than whatever the Windows kernel stores for a
semaphore handle.

--Andy
  

On Thursday, 25 January 2024 12:55:04 CST Andy Lutomirski wrote:
> On Wed, Jan 24, 2024 at 7:42 PM Elizabeth Figura
> <zfigura@codeweavers.com> wrote:
> >
> > On Wednesday, 24 January 2024 16:56:23 CST Elizabeth Figura wrote:
> > > On Wednesday, 24 January 2024 15:26:15 CST Andy Lutomirski wrote:
> > >
> > > > On Tue, Jan 23, 2024 at 4:59 PM Elizabeth Figura
> > > > <zfigura@codeweavers.com> wrote:
> > > >
> > > > >
> > > > >
> > > > > ntsync uses a misc device as the simplest and least intrusive uAPI
> > > > > interface.
> > > >
> > > > >
> > > > >
> > > > > Each file description on the device represents an isolated NT instance,
> > > > > intended to correspond to a single NT virtual machine.
> > > >
> > > >
> > > > If I understand this text right, and if I understood the code right,
> > > > you're saying that each open instance of the device represents an
> > > > entire universe of NT synchronization objects, and no security or
> > > > isolation is possible between those objects.  For single-process use,
> > > > this seems fine.  But fork() will be a bit odd (although NT doesn't
> > > > really believe in fork, so maybe this is fine).
> > > >
> > > > Except that NT has *named* semaphores and such.  And I'm pretty sure
> > > > I've written GUI programs that use named synchronization objects (IIRC
> > > > they were events, and this was a *very* common pattern, regularly
> > > > discussed in MSDN, usenet, etc) to detect whether another instance of
> > > > the program is running.  And this all works on real Windows because
> > > > sessions have sufficiently separated namespaces, and the security all
> > > > works out about as any other security on Windows, etc.  But
> > > > implementing *that* on top of this
> > > > file-description-plus-integer-equals-object will be fundamentally
> > > > quite subject to one buggy program completely clobbering someone
> > > > else's state.
> > > >
> > > > Would it make sense and scale appropriately for an NT synchronization
> > > > *object* to be a Linux open file description?  Then SCM_RIGHTS could
> > > > pass them around, an RPC server could manage *named* objects, and
> > > > they'd generally work just like other "Object Manager" objects like,
> > > > say, files.
> > >
> > >
> > > It's a sensible concern. I think when I discussed this with Alexandre
> > > Julliard (the Wine maintainer, CC'd) the conclusion was this wasn't
> > > something we were concerned about.
> > >
> > > While the current model *does* allow for processes to arbitrarily mess
> > > with each other, accidentally or not, I think we're not concerned with
> > > the scope of that than we are about implementing a whole scheduler in
> > > user space.
> > >
> > > For one, you can't corrupt the wineserver state this way—wineserver
> > > being sort of like a dedicated process that handles many of the things
> > > that a kernel would, and so sometimes needs to set or reset events, or
> > > perform NTSYNC_IOC_KILL_MUTEX, but never relies on ntsync object state.
> > > Whereas trying to implement a scheduler in user space would involve the
> > > wineserver taking locks, and hence other processes could deadlock.
> > >
> > > For two, it's probably a lot harder to mess with that internal state
> > > accidentally.
> > >
> > > [There is also a potential problem where some broken applications
> > > create a million (literally) sync objects. Making these into files runs
> > > into NOFILE. We did specifically push distributions and systemd to
> > > increase those limits because an older solution *did* use eventfds and
> > > *did* run into those limits. Since that push was successful I don't
> > > know if this is *actually* a concern anymore, but avoiding files is
> > > probably not a bad thing either.]
> >
> > Of course, looking at it from a kernel maintainer's perspective, it wouldn't
> > be insane to do this anyway. If we at some point do start to care about cross-
> > process isolation in this way, or if another NT emulator wants to use this
> > interface and does care about cross-process isolation, it'll be necessary. At
> > least it'd make sense to make them separate files even if we don't implement
> > granular permission handling just yet.
> 
> I'm not convinced that any complexity at all beyond using individual
> files is needed for granular permission handling.  Unless something
> actually needs permission bits on different files pointing at the same
> sync object (which I believe NT supports, but it's sort of an odd
> concept and I'm not immediately convinced that anything uses it),
> merely having individual files ought to do the trick.  Handling of who
> has permission to open a given named object can live in a daemon, and
> I'd guess that Wine even already implements this.

This is mostly correct. NT has file descriptors and descriptions (the
former is called a "handle"), though unlike Unix access bits are
specific to the *descriptor* (handle). I don't know if anything uses 
it, but we do currently implement that basic functionality, so I can't
say that nothing does either.

So inasmuch as access to someone else's object is a concern, access to
your object with bits you don't have permission for could be a concern
along the same lines. However, from conversation with Alexandre I
believe it'd be fine to just implement those checks in user space.

> And keeping everything together gives me flashbacks of Windows 95 and
> Mac OS pre-X.  Sure, in principle the software wasn't malicious, but
> there was no shortage whatsoever of buggy crap out there, and systems
> were quite unstable.  Even just:
> 
> CreateSemaphore();
> fork();
> sleep a few seconds;
> exit();
> 
> seems like it could corrupt the shared namespace world.  (Obviously no
> one would ever do that, right?)
> 
> Also, handle leaks:
> 
> while(true) {
>   make a subprocess, which creates a semaphore and crashes;
> }

For whatever it's worth, this particular thing wouldn't be a concern;
Wine's "kernel" daemon already has to detect when a process dies and
close all its outstanding handles.