[9fans] Re: Nix and Cgroups

[9fans] Re: Nix and Cgroups

[maxinehayes90]

[-- Attachment #1: Type: text/plain, Size: 2476 bytes --]

On Sunday, August 03, 2025, at 11:28 AM, tlaronde wrote:
> So I asked myself if there was some mean to do the reverse from
"starting as unprivileged and then promoting": starting as root and then
degrading to unprivileged, emerging back to root only when needed (hence
without having the burden to give a password).
This for the most part already exists, systemd when starting a daemon, if the daemon configuration file has a user specified, will drop to that user, though I'm sure I'm missing some crucial details. However, Ansible is more interesting as it implements this exact feature, though with some complexities and headaches. (https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_privilege_escalation.html#risks-and-limitations-of-become) Starting as root then dropping privileges during points in playbook execution is not often used as this feature is seldom beneficial. 

On Sunday, August 03, 2025, at 11:28 AM, tlaronde wrote:
> The only possible answer I was able to think of, would imply the
(Unix) sticky bits on some programs (whatever program having to
deal with configuration, compilation or even a special shell or
compilation script that will propagate "nobody" or "joe" to what
it calls and doing everything except installation).
I'm not sure what you mean, are you referring to using the setuid bit?

On Sunday, August 03, 2025, at 11:28 AM, tlaronde wrote:
> Now, comparing to Plan9 / Nix: I could imagine running a core with
lower privileges: a "vulcan" (typically a compilation/building core).
But would then be some sense in using the file modes to indicate this
kind of restricted privileges for a program? Or, when such programs
are binded in the namespace, offered by some server, accessing/exec'ing
the programs will launch automatically a dedicated CPU core, with lower
privileges?
This sounds a lot like a design for a build system where jobs are sent and workers are requested on demand. Koji, Fedora's build system works very similarly to this, though it is severely held back by the monolithic UNIX design. This is an area I would like to do more research on, more specifically nodes which are brought up on demand with the controls cleanly fitting into the current namespace.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T924b170304d49c32-Me0ce51a5090a402e99c86563
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 3411 bytes --]

Re: [9fans] Nix and Cgroups

[hiro]

> So I asked myself if there was some mean to do the reverse from
> "starting as unprivileged and then promoting": starting as root and then
> degrading to unprivileged

IIUC that's exactly how unix always worked,
plan9 otoh flipped it upside down, and so we start unprivileged.
i do think the plan9 way is superior.
check the sorry state of linux bolted-on "rootless" stuff. it all
feels so wrong.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T924b170304d49c32-M7aebc0fd15ce6787e611face
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Nix and Cgroups

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 795 bytes --]

I agree with hiro on this one, the plan 9 way makes more more sense to me.

On Fri, Aug 8, 2025 at 12:09 hiro <23hiro@gmail.com> wrote:

> > So I asked myself if there was some mean to do the reverse from
> > "starting as unprivileged and then promoting": starting as root and then
> > degrading to unprivileged
> 
> IIUC that's exactly how unix always worked,
> plan9 otoh flipped it upside down, and so we start unprivileged.
> i do think the plan9 way is superior.
> check the sorry state of linux bolted-on "rootless" stuff. it all
> feels so wrong.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T924b170304d49c32-M3afcd01b3387585cf5214fda
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 2070 bytes --]

Re: [9fans] Nix and Cgroups

[tlaronde]

On Fri, Aug 08, 2025 at 07:22:55PM +0200, hiro wrote:
> > So I asked myself if there was some mean to do the reverse from
> > "starting as unprivileged and then promoting": starting as root and then
> > degrading to unprivileged
> 
> IIUC that's exactly how unix always worked,
> plan9 otoh flipped it upside down, and so we start unprivileged.
> i do think the plan9 way is superior.
> check the sorry state of linux bolted-on "rootless" stuff. it all
> feels so wrong.

Not exactly, in my view. For the problem at hand (but dealing with
"packages" utilities as is), my problem was more why not setuid all
the compiler utilities with some "src" or "vulkan" unprivileged user,
so that even if someone launches the programs as root, they will not
work as root.

Link to the Cgroups: this is only a partial solution, since there is
more than what can be defined via the user. So the Nix possible
solution: that some programs be specifically with some defined
environment executing on a dedicated core.
-- 
        Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T924b170304d49c32-M86ce471e7c9503a9cc4f9bfc
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: Nix and Cgroups

[tlaronde]

On Fri, Aug 08, 2025 at 04:06:15PM +0000, maxinehayes90@gmail.com wrote:
> On Sunday, August 03, 2025, at 11:28 AM, tlaronde wrote:
> > So I asked myself if there was some mean to do the reverse from
> "starting as unprivileged and then promoting": starting as root and then
> degrading to unprivileged, emerging back to root only when needed (hence
> without having the burden to give a password).
> This for the most part already exists, systemd when starting a daemon, if the daemon configuration file has a user specified, will drop to that user, though I'm sure I'm missing some crucial details. However, Ansible is more interesting as it implements this exact feature, though with some complexities and headaches. (https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_privilege_escalation.html#risks-and-limitations-of-become) Starting as root then dropping privileges during points in playbook execution is not often used as this feature is seldom beneficial. 
> 
> On Sunday, August 03, 2025, at 11:28 AM, tlaronde wrote:
> > The only possible answer I was able to think of, would imply the
> (Unix) sticky bits on some programs (whatever program having to
> deal with configuration, compilation or even a special shell or
> compilation script that will propagate "nobody" or "joe" to what
> it calls and doing everything except installation).
> I'm not sure what you mean, are you referring to using the setuid bit?
> 
> On Sunday, August 03, 2025, at 11:28 AM, tlaronde wrote:
> > Now, comparing to Plan9 / Nix: I could imagine running a core with
> lower privileges: a "vulcan" (typically a compilation/building core).
> But would then be some sense in using the file modes to indicate this
> kind of restricted privileges for a program? Or, when such programs
> are binded in the namespace, offered by some server, accessing/exec'ing
> the programs will launch automatically a dedicated CPU core, with lower
> privileges?
> This sounds a lot like a design for a build system where jobs are sent and workers are requested on demand. Koji, Fedora's build system works very similarly to this, though it is severely held back by the monolithic UNIX design. This is an area I would like to do more research on, more specifically nodes which are brought up on demand with the controls cleanly fitting into the current namespace.

We are facing what I call a "logical refractor": the Unix design (that
made perfect sense with the hardware at disposal when it was designed)
leads to assume in some areas that there is whether light or no light.

But when sending light to some problem ("logical refractor"), the ray
sometimes hit one spot, sometimes another etc. and the final image is
blurred.

The solution has been to try to correct the special cases after the
problem. While a better solution is to conclude that there is no one
"light", but this object is composite: several different wavelengths
that react differently with the problem. And to start not with one
ray of light, but with several monochromatic rays of light handled
each according to its properties allowing to, finally combine all to
the one spot on the image.

This is for me why Ron's approach with Nix hits the bull-eye: not one
complex uniq kernel handling cores, but several core-kernels
collaborating.

So for compilation, there could be dedicated cores running a kernel
with a special "environment" (to be all-encompassing about the policy
to apply to resources).

-- 
        Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T924b170304d49c32-Mb3abb4b2c56f16c3ec56f0be
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Nix and Cgroups

[Maxine Hayes]

[-- Attachment #1: Type: text/plain, Size: 1773 bytes --]

This is beginning to sound like a rootless container, but done more
correctly.  The issue with setuid is that misusage may result in a security
nightmare, at least for temporary privilege escalation.

On Fri, Aug 8, 2025, 2:52 PM <tlaronde@kergis.com> wrote:

> On Fri, Aug 08, 2025 at 07:22:55PM +0200, hiro wrote:
> > > So I asked myself if there was some mean to do the reverse from
> > > "starting as unprivileged and then promoting": starting as root and
> then
> > > degrading to unprivileged
> >
> > IIUC that's exactly how unix always worked,
> > plan9 otoh flipped it upside down, and so we start unprivileged.
> > i do think the plan9 way is superior.
> > check the sorry state of linux bolted-on "rootless" stuff. it all
> > feels so wrong.
> 
> Not exactly, in my view. For the problem at hand (but dealing with
> "packages" utilities as is), my problem was more why not setuid all
> the compiler utilities with some "src" or "vulkan" unprivileged user,
> so that even if someone launches the programs as root, they will not
> work as root.
> 
> Link to the Cgroups: this is only a partial solution, since there is
> more than what can be defined via the user. So the Nix possible
> solution: that some programs be specifically with some defined
> environment executing on a dedicated core.
> --
> Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
>              http://www.kergis.com/
>             http://kertex.kergis.com/
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C



------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T924b170304d49c32-M2f2fc7e65815f625a4ba4639
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 3743 bytes --]

Re: [9fans] Re: Nix and Cgroups

[Maxine Hayes]

[-- Attachment #1: Type: text/plain, Size: 4821 bytes --]

On Fri, Aug 8, 2025, 3:25 PM <tlaronde@kergis.com> wrote:

> On Fri, Aug 08, 2025 at 04:06:15PM +0000, maxinehayes90@gmail.com wrote:
> > On Sunday, August 03, 2025, at 11:28 AM, tlaronde wrote:
> > > So I asked myself if there was some mean to do the reverse from
> > "starting as unprivileged and then promoting": starting as root and then
> > degrading to unprivileged, emerging back to root only when needed (hence
> > without having the burden to give a password).
> > This for the most part already exists, systemd when starting a daemon,
> if the daemon configuration file has a user specified, will drop to that
> user, though I'm sure I'm missing some crucial details. However, Ansible is
> more interesting as it implements this exact feature, though with some
> complexities and headaches. (
> https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_privilege_escalation.html#risks-and-limitations-of-become)
> Starting as root then dropping privileges during points in playbook
> execution is not often used as this feature is seldom beneficial.
> >
> > On Sunday, August 03, 2025, at 11:28 AM, tlaronde wrote:
> > > The only possible answer I was able to think of, would imply the
> > (Unix) sticky bits on some programs (whatever program having to
> > deal with configuration, compilation or even a special shell or
> > compilation script that will propagate "nobody" or "joe" to what
> > it calls and doing everything except installation).
> > I'm not sure what you mean, are you referring to using the setuid bit?
> >
> > On Sunday, August 03, 2025, at 11:28 AM, tlaronde wrote:
> > > Now, comparing to Plan9 / Nix: I could imagine running a core with
> > lower privileges: a "vulcan" (typically a compilation/building core).
> > But would then be some sense in using the file modes to indicate this
> > kind of restricted privileges for a program? Or, when such programs
> > are binded in the namespace, offered by some server, accessing/exec'ing
> > the programs will launch automatically a dedicated CPU core, with lower
> > privileges?
> > This sounds a lot like a design for a build system where jobs are sent
> and workers are requested on demand. Koji, Fedora's build system works very
> similarly to this, though it is severely held back by the monolithic UNIX
> design. This is an area I would like to do more research on, more
> specifically nodes which are brought up on demand with the controls cleanly
> fitting into the current namespace.
> 
> We are facing what I call a "logical refractor": the Unix design (that
> made perfect sense with the hardware at disposal when it was designed)
> leads to assume in some areas that there is whether light or no light.
> 
> But when sending light to some problem ("logical refractor"), the ray
> sometimes hit one spot, sometimes another etc. and the final image is
> blurred.
> 
> The solution has been to try to correct the special cases after the
> problem. While a better solution is to conclude that there is no one
> "light", but this object is composite: several different wavelengths
> that react differently with the problem. And to start not with one
> ray of light, but with several monochromatic rays of light handled
> each according to its properties allowing to, finally combine all to
> the one spot on the image.
> 
> This is for me why Ron's approach with Nix hits the bull-eye: not one
> complex uniq kernel handling cores, but several core-kernels
> collaborating.
> 
> So for compilation, there could be dedicated cores running a kernel
> with a special "environment" (to be all-encompassing about the policy
> to apply to resources).
> 
> --
> Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
>              http://www.kergis.com/
>             http://kertex.kergis.com/
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C


I'm aware, different designs have their niches they excel at, in some
domains they are the best solution, one can infer that using different
designs together is optimal; much like tools in a toolbox.

From my understanding so far the idea is to run specialized kernels on
dedicated cores on the same machine. This sounds like a reimagined
microkernel design and technically, abstractly, Plan 9 already operates in
this fashion; file servers act as a "kernel" with a "special environment",
a namespace, and these "kernels" communicate with each other using a
unifying protocol 9p. The "policies" for these resources are handled using
file permissions and factotum.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T924b170304d49c32-M6facc5121714955676e7f32b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 7123 bytes --]

Re: [9fans] Nix and Cgroups

[hiro]

on linux you need root to bind. this makes namespaces (and thus
containers) a big pain.
user namespaces is the hack around it. it makes unintended privilege
escalation a breeze.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T924b170304d49c32-M792caa5ca33a87ec4d6009f0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Nix and Cgroups

[Daniel Maslowski via 9fans]

[-- Attachment #1: Type: text/plain, Size: 2049 bytes --]

For reference, this is systems security 101; the context being Multi-Level
Security (MLS):
https://en.wikipedia.org/wiki/Bell%E2%80%93LaPadula_model is a model for
confidentiality, whereas Biba and Clark-Wilson are rather integrity models.
Those are the reference models from the 70ies and 80ies.
The articles on Wikipedia are not too great, so you may wish to look into
e.g. Matt Bishops's course material. I couldn't find them right away. He's
written the widely referenced books on computer security, which you will
find.

A very general intro:
https://www.cse.psu.edu/~gxt29/teaching/cs447s19/slides/01basicsOfSecurity.pdf
More going into detail, this one is rather lengthy:
https://ccss.usc.edu/523/F24-DSci523-Lec10.pdf

There are many approaches to access controls, abbreviated as *AC, such as
DAC - https://en.wikipedia.org/wiki/Discretionary_access_control -, and you
may be thinking of that. This will lead you to looking into
https://en.wikipedia.org/wiki/Capability-based_security which essentially
means that access to resources is granted by delegation / passing. Beware
of the confused deputy problem.

In the context of build systems, you likely want a sandbox that has very
limited access to resources, merely reading source files, executing
designated toolchains, and writing artifacts (outputs). That in itself,
however, is not sufficient. Controlling what happens around the sandbox is
key; see also every attempt to poison software seen over the last years by
attacking build services and registries.

Cheers
Daniel

On Sat, 9 Aug 2025, 02:32 hiro, <23hiro@gmail.com> wrote:

> on linux you need root to bind. this makes namespaces (and thus
> containers) a big pain.
> user namespaces is the hack around it. it makes unintended privilege
> escalation a breeze.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T924b170304d49c32-M6e9e5898f0c4cda980c9a318
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 3963 bytes --]

Re: [9fans] Nix and Cgroups

[Steve Simon]

please bear with me,
but is it an interesting idea to consider the linux vmx instance that Ron has implemented as something like a special (linux) nix application processor?

the idea would be to run a subsystem fully connected to the host but with an arbitrary environment: plan9,  linux, maybe bsd if someone is interested…, maybe win64 if someone is masochistic enough…

-Steve


 
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T924b170304d49c32-M6b765eb3fee248fe1043769d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Nix and Cgroups

[hiro]

i think the word virtualization suffices to describe this principle.
processor is not so meaningful

On Sat, Aug 9, 2025 at 7:53 AM Steve Simon <steve@quintile.net> wrote:
> 
> 
> please bear with me,
> but is it an interesting idea to consider the linux vmx instance that Ron has implemented as something like a special (linux) nix application processor?
> 
> the idea would be to run a subsystem fully connected to the host but with an arbitrary environment: plan9,  linux, maybe bsd if someone is interested…, maybe win64 if someone is masochistic enough…
> 
> -Steve
> 

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T924b170304d49c32-Mfd77b62ffd5c1422e75839d0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Nix and Cgroups

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 1258 bytes --]

note that you can cpu from plan 9 to bsd as well, if bsd is running as a
guest on 9front. bsd recently took a change to make my Go cpud work (hmm,
was this freebsd? Think so).

My point being that we can start to run individual programs as guests on
9front, when porting is probably impossible. texpls might be one such
program.

On Sat, Aug 9, 2025 at 8:59 AM hiro <23hiro@gmail.com> wrote:

> i think the word virtualization suffices to describe this principle.
> processor is not so meaningful
>
> On Sat, Aug 9, 2025 at 7:53 AM Steve Simon <steve@quintile.net> wrote:
> >
> >
> > please bear with me,
> > but is it an interesting idea to consider the linux vmx instance that
> Ron has implemented as something like a special (linux) nix application
> processor?
> >
> > the idea would be to run a subsystem fully connected to the host but
> with an arbitrary environment: plan9,  linux, maybe bsd if someone is
> interested…, maybe win64 if someone is masochistic enough…
> >
> > -Steve
> >

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T924b170304d49c32-Mecebbc1d42ae905c4deadcb3
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 2698 bytes --]

Re: [9fans] Nix and Cgroups

[Edouard Klein]

Hi Thierry,

Sorry, I'm catching the discussion a bit late. I think you should study
the design of GNU Guix.

It solves your dll problem by using content-addressable storage. For
example, my fish links to:

ldd (which fish ) | grep libc
libc.so.6 =>
/gnu/store/mprrfhb2cq6dwsxf6pgj1zmjincd4x5h-glibc-2.41/lib/../lib/libc.so.6

whereas my bash links to:
ldd (which bash ) | grep libc
        libc.so.6 => /gnu/store/hw6g2kjayxnqi8rwpnmpraalxi0djkxc-glibc-2.39/lib/libc.so.6 

because I updated the former when I updated my home environment, and I
have yet to update my whole system.

The hash before the package name is the hash of (the source-code + the
hash of all the dependencies) so that if any bit changes, deep down in the
dependency of your compiler's compiler, your hash changes as
well.

The way this works seamlessly is by creating a bunch of symlinks in your
PATH, it is ugly, and I think Plan 9 style user namespace would be
immensely better.


To address your second point about building privilege, guix solves this
by building software in a completely isolated container (this is for
reproducibility as well as security). This build is managed by a build
daemon that was recently made rootless

https://hpc.guix.info/blog/2025/03/build-daemon-drops-its-privileges/

still, the container machinery has many ugly edge cases, and under Plan
9 those would be handled by namespacing.

All-in-all, I think GNU Guix is the cleanest Linux distro out there (no
systemd, by the way), and while it is not as clean as Plan 9, that's
mainly because it lacks most of the affordance of Plan 9's kernel w.r.t.
namespaces.



<tlaronde@kergis.com> writes:

> I stumbled upon this by accident, but I think it is also one example
> showing that both Plan9 and Nix are a good solution, because "simple",
> to complex problems leading to too many features in one kernel.
>
> Cgroups stands for "Control groups", and is a feature implemented in
> the Linux kernel and that aims to allow a policy of resources usage
> (CPU, memory and so on) for a group of processes.
>
> It rings at least two bells for me:
>
> 1) From the Wikipedia page: "Both versions of cgroup act through
> a pseudo-filesystem": the Plan9 principle to push the Unix underlying
> principle of "a lot of things appear as files" to its completeness
> has invaded a lot of Unix kernels as can be seen here. One can add
> that the concept of namespaces is a simple way of setting a define
> set of resources to processes;
>
> 2) The problem is still that there is only one kernel, with features
> that are supposed to fit them (processes) all. Instead of trying to
> handle the complexity in one kernel, the solution to keep a
> kernel simple but with running different kernels on different cores
> seem far simpler.
>
> On a related thread of thought (comparing Unix and Plan9), having to
> update an Unix node I faced once again the "dll hell" (the dynamically
> shared libraries on Unix are only slightly better than the dll hell on
> Windows, since, contrary to what was/is advertised, the naming of the
> libraries or the administration of third party softwares generally
> involve, to play it safe, when one wants to upgrade some software
> depending on some shared libraries, to upgrade all the programs using
> this shared library because the packaging system insists that
> only one version of the dso exist on the system---mainly because to
> keep track of some "package" installed, since different versions would
> try to put some files at the very same place, there is only one
> version allowed.
>
> When a browser depends on gazillions of shared libraries,
> even upgrading one tiny thing in a corner leads to hours or even days
> of rebuilding...
>
> But this nuisance is not the problem I wanted to discuss. The problem
> at foot is that, generally, external software is added in root reserved
> directories.
>
> So, whether you run everything as root, including
> compiling, to avoid having to type the password other and other
> again when installing; or you compile as an unprivileged user and
> promote to root only when installing---but then the process halts at
> every installation to ask for the password.
>
> I know that one solution is to build everything in an unprivileged
> sandbox. But it takes time to get it right, and to use the packages
> created one has to be sure that everything fits the outside the
> sandbox environment.
>
> So I asked myself if there was some mean to do the reverse from
> "starting as unprivileged and then promoting": starting as root and then
> degrading to unprivileged, emerging back to root only when needed (hence
> without having the burden to give a password).
>
> The only possible answer I was able to think of, would imply the
> (Unix) sticky bits on some programs (whatever program having to
> deal with configuration, compilation or even a special shell or
> compilation script that will propagate "nobody" or "joe" to what
> it calls and doing everything except installation).
>
> Now, comparing to Plan9 / Nix: I could imagine running a core with
> lower privileges: a "vulcan" (typically a compilation/building core).
> But would then be some sense in using the file modes to indicate this
> kind of restricted privileges for a program? Or, when such programs
> are binded in the namespace, offered by some server, accessing/exec'ing
> the programs will launch automatically a dedicated CPU core, with lower
> privileges?
>
> If someone has thoughts about these subjects, or can point me to
> existing related papers, I will with gratitude read these contributions!

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T924b170304d49c32-M4225b7025cbe89281dcdc203
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription