On Fri, Aug 08, 2025 at 04:06:15PM +0000, [email protected] 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
