<zamfofex>Hello, everyone! Apologies in advance for the long message! Has anyone here ever investigated Google’s Zircon? I was reading about it the other day (a year ago or so), and it feels like it has a really neat approach for handling the filesystem and its permissions. <zamfofex>In particular, it seems to me (from my limited understanding) that whenever a process opens a file from a path, the call is delegated to the parent process, and so are all operations on that file, kinda like ‘chroot’ and FUSE combined. <zamfofex>I think the idea being that it is, then, easier for the user to segregate file permission for processes. (Not to mention the benefits of having arbitrary byte streams between child processes and their respective parent process.) <zamfofex>It seems to me that, in modern computing, it is more likely that a user will be wanting to prevent distrusted (or misbehaving) programs from accessing files that are not necessary for them to function (limiting access to config files to their specific programs), rather than trying to prevent other system users from accessing them. <zamfofex>It feels like being able to separate file permission and access on a *per process* basis is *as generally useful* as separating permission on a *per user* basis. Also, on home computers, I’d say that *per process* separation is a lot more useful, given that, most of the time, there is at most one person that uses the computer, or all people using <zamfofex>I’m not sure how feasible it would be to have a similar thing in Hurd (I’m probably just being too wishful), but I hope someone might have found these musings interesting, at least, I guess. ***Server sets mode: +nt
***Server sets mode: +nt
<wleslie>I haven't kept up with it, but having the parent process control the child's filesystem sounds like a convenient attack vector, not too different from the existing strandhogg exploits or LD_PRELOAD attacks <wleslie>I had assumed Zircon = fuchsia++ and that it would have a capability model, and so the filesystem(s) available would be first class <wleslie>though I guess "we baked in ambient filesystem inheritance" and "we can supply the filesystem to the child at process creation" are two different ways of reading that ***wleslie_ is now known as wleslie
***janneke_ is now known as janneke