On Fri, Aug 8, 2025, 3:25 PM <[email protected]> wrote: > 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
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
