[ros-dev] Re: registry TODO

[Mike Nordell]

If it seems I come down a bit hard on the proposal, I can only blame
language barriers. My intention is only to illuminate some of the pitfalls I
think are inherent in a dynamic load system as the proposed.

Boaz Harrosh wrote:

> What I think of doing is:
>   keep the boot registry as is (more less).

This is, I believe, not an area open for discussion. It is as it is. If this
is correct, then basically all of HKLM\SYSTEM (and linked keys) are
off-limit.

> Put in on wine/wine/config a
> key system that enables a "plugin" system of registry loaders/savers.

A couple of questions:

SAM? How is security supposed to be handled using this approach - assuming
SAM is to handle the security (which I must assume, else I'm against this)?

Links? Especially links pointing to another "handler".

Volatile keys?

> Builtin plugins are current format and Windows binary format. Other
> formats could be easily implemented; candidates could be XML, MySQL etc...

Having seen the amount of registry lookups the NT5.0 (aka Windows 2000)
Explorer does just for viewing a single directory, I suspect running that
over an SQL client to a server (or even parsing a local XML file) one might
be in for a treat making making Windows XP on Bochs, on a 486, look fast.

I might also point out the fact that registry-handling is currently done
entirely from kernel mode, with unrestricted access rights. Would you trust
an XML parser or an SQL client these unrestricted rights? I know for certain
I wouldn't.

One could, theoretically, solve this by having such things run as services
(in user-mode, and under restricted accounts), and have the kernel call out
to them using RPC (how to establish trust between the kernel and such
serices? LPC is out of the question I think) - opening the door for
effectively making a system look hung if one of the servers this would
depend upon was unavailable. Again, think Explorer.exe and its gazillion
registry accesses.

> The system I thought of would also save the hives and sub trees, to the
> files/plugins it was loaded from.

If a plugin has started handling a key, it would (obviously) have to handle
all sub-keys too - even if delegating deeper down.

> Each plugin could also implement a
> write behind so Data don't get lost in case of a crash or power lost.

If this is to be a serious proposal, it would have to provide loggin
mechanisms. As it would be basically impossible to hold data consistency
across networks, SQL servers and stuff, the data would have to be stored in
a log on the boot volume (if for nothing else, to assure correct order of
updates).

> Good point with the on demand-loading/cache of keys. It should be done
> this way.

It might seem reasonable at first, but saying it _should_ be this way
without any data to back it up seems a bit premature. I haven't seen any
empirical data to back it up, and no testing for what happens when e.g. any
other part of the system encounters a catastrophic failure (the "system" is
now extended to include network, routers and even remote SQL servers).

I suspect (with a bit of experience in the area) that this might actually be
completely unsatisfactory, and that it in fact should grab the whole hive(s)
from the remote storage, storing it/them locally, to allow for network
outages without hanging the whole system or crashing apps.

> So in summary:
> 1. Implement a Memory registry with plugin drivers and mount semantics.

Please define "Memory registry". Please keep in mind that the registry on
Windows machines are nowadays (especially if you install .NET) of such a
size as to require more storage than you needed RAM to boot NT4, why I
suspect it needs to be swappable/discardable.

> This driver goes here, that driver mounts there.
> 2. Implement 2 basic drivers: Wine builtin format, Windows binary format.

I don't know what "Wine builtin format" is, neither do I know how it fits
the NT security model. Could you elaborate?

> 3. Enable dynamic load of external drivers.

If this is to be handled as suggested, by a registry branch below
wine/wine/config, it means that branch would have to be locked down to only
allow administrator write/modify (maybe even read) access. It also opens the
door for serious malice, in case a malicious service registers the RPC
service before one of the intended services got to do its work, and...

Basically, I urge you to seriously reconsider your proposal while thinking
of every aspect you can imagine (and then a few more). I think the
intentions are good, and I like the basic ideas, but at the same time I
suspect the effort and all the implications might have been underestimated.
Especially the security problems.

> The Initial registry system is always loaded from system.reg builtin
> format which is also the "fstab" file of the registry. At minimum every
> thing is exactly like now one (two) files builtin format, and that's it.
> At the maximum it can be highly object oriented with per user, per
> application, per group management.

I assume you know how MS handles this, by downloading a roaming registry
from a DC to the local machine? Knowing the unreliability of networks, and
other non-local media (compared to local media, even if that fails too) I
nowadays have grown to think MS did the right choice in having the hives
downloaded to the local machine when logging on.


/Mike