On 7/17/2024 4:09 PM, Joshua M. Clulow
via illumos-developer wrote:
On Wed, 17 Jul 2024 at 06:29, Lonnie via illumos-developer
<developer@lists.illumos.org> wrote:
1. As Illumos is designed for zones (VMs), I am wondering if there are driver and service zones implemented such that if a driver crashes then it does not heavily impact the OS in operation? From what I understand so far, the drivers and system wide services are installed in the Global-Zone which makes me think of the Xen Type-1 Hypervisor in which these things are installed in their Dom0 which is similar to the Illumos Global-Zone (GZ)
It's not so much that illumos is designed _for_ zones or VMs, as that
we have first class features in the OS that support those things.
Aside from those features, illumos is a UNIX operating system with a
monolithic kernel. Drivers are generally kernel modules, though there
are limited areas in which drivers can be implemented in user mode
software; e.g., ugen(4D) allows for user mode USB drivers, and one of
the FUSE ports would allow for a user mode file system. That said,
because our consolidation can ship both kernel and user mode software,
we can indeed relatively easily move some things into daemons where
they might have ended up in the kernel in other systems.
We ship a lot of daemons for different purposes, supervised by smf(7)
and in may cases deprivileged by rbac(7) and privileges(7) features in
the OS. In most or all cases, these daemons could crash and restart
without necessarily bringing down other parts of the system. If a
daemon restart does cause unavailability, you could definitely file
that as a bug to fix.
2. Another crazy thought that I had was about the possibly of investigating what it might take to (fork illumos for an experiment) and try to remove the dependencies on a hierarchal tree-based filesystem and to implement a type of "Property-Graph Database (PGDb)" filesystem. The rationale here is that a hierarchal tree-based filesystem can easily be represented as well but that a PGDb filesystem also allows for assigning new types of attributes to files, blocks, objects, users, etc. and thus allowing for granular security on users at the application level. Users can be allowed/disallowed to see/access application/files/block/objects and only authorized applications are "mapped" to a particular user.
I think it's unlikely that we would move away from a hierarchical file
system. It's really at the core of a lot of UNIX abstractions. We
tend to focus on mandatory access control through privileges(7) and
rbac(7) mechanisms. Individual users, or processes, can be restricted
from seeing quite a lot of other things occuring on the computer in
other accounts, etc, by removing privileges from their processes.
They can be prevented from making network connections, or seeing other
processes in /proc, etc. We're always interested in new security and
sandboxing features, but would generally like them to build on and fit
in with the existing designs where possible. The core team is happy
to help with design advice if someone wants to put together an illumos
project discussion (IPD) document that covers a new sandboxing
feature; see: https://github.com/illumos/ipd.
ZFS, our primary file system, has extensive support for extended
attributes. It also has rich support for NFSv4 ACLs, which allow for
fine-grained permissions in the regular file system; see acl(7) for
more details. There is also support for other more complex
attributes, such as marking things totally immutable; see fgetattr(3C)
and chmod(1) for more details.
3. I could see that when a user does a login, then a blank empty zones is set up at which time their configured files, directories are mapped in to their container zone and allowed applications are only used. The users cannot escape their zone and does not have access to the rest of the system unless privilege's are elevated. I know that "zlogin" can do this from the GZ, but perhaps automatically and full console since graphic display will be needed.
You could achieve a lot of automatic provisioning for users on login
through some combination of NSS and PAM modules and
distribution-specific control software. I don't think this would
really be a core illumos feature, at least to begin with, but there's
a lot of mechanism that could help you get there!
Graphics is obviously something of an uncharted challenge. As I
mentioned in your OmniOS thread, our DRM/KMS software needs work to be
brought up to date, and there are probably new facilities that we
would then need to add to the core OS to provide a richer graphical
console experience. It's also possible that you could, once DRM is
sorted out, drive a lot of that from distribution-specific software
like X11, or a port of DirectFB2, etc, without needing much or any
additional core OS support.
4. One need that may be a challenge to get done will be the need for a enable/disable consoles such that a local users could use a hot-key (API call) to switch between zone consoles which would include graphics, audio, etc. This would be akin to running multiple VirtualBox OSs, or VMware Guests in which you can step through the guest graphic tabs in fullscreen mode, perhaps. I am seeking to replicate that idea in Illumos to step through guests (maybe in Bhyve or native zones) that are in their own configured zone which is the thought.
This is mostly the same as my comments on graphics above. Some work
will be required specifically on improving the graphical/desktop
support we have, as part of a project like that.
I am not sure how these things might be approached and/or tackled in illumos but wanted to start investigating them one by one and build up at the project evolves.
I suspect most of what you want to do, you could get started by
prototyping on top of facilities that exist already! I can't stress
enough that if you want the graphics stuff to work out, I would work
on that first, as I think it's the biggest risk/unknown in your plans
so far.
Well, I thought that I would ask these questions here since they are more kernel related than OS configuration related and hope that you also find them interesting although may have already been considered in the past well.
We generally try to keep the illumos developer list focused on
specific bits of in-progress development (questions about how to
proceed, code and design reviews), or about specific bugs or issues,
etc. Generally we would do broad, exploratory ideation on the
illumos-discuss list.
Cheers.