On Sat, Jan 03, 2015 at 04:01:55PM -0500, Jude Nelson wrote:
> Hi Hendrik,
>
> > It looks as if this whole discussion is in the direction of building a
> > capability architecture on top of Linux. I'm not sure this isn't a
> > much greater change than imposing systemd. If you want such a thing,
> > better to switch to an OS that does this natively, such as, perhaps,
> > inferno.
>
> In terms of development methodologies, the difference between me and the
> systemd developers is that I'm taking care to design vdev and my other
> projects (like runfs) to be easily replaced, and to be used independently
> of one another. For example, vdev's public API *is* the filesystem--there
> will never be a dbus interface or a libvdev, since programs interact with
> vdev only through filesystem operations. This makes it easy to replace
> vdev with something else, even a static /dev, since as long as the
> requisite files are in the right places, other programs won't notice the
> difference. The vdev-specific behavior (per-process access control) is
> pure policy, not mechanism--it affects the users and admins, not the
> program logic.

I understand. Still worried about strangeness others may build on top
of vdev, but that's their concern, not yours.

>
> I personally happen to like Plan 9's and inferno's approach to computing,

So do I.

> but I never want to see it imposed on anyone who didn't want it. As such,
> I wouldn't want vdev to be tightly integrated into the OS, nor would I want
> there to be vdev-specific APIs that encourage ecosystem lock-in. vdev
> should be an add-on for those who want it, but it should be structured so
> that other programs in the layers above it (like the desktop environment)
> can't couple themselves to it to force its adoption.

Good. Thanks for the clarification.

>
> > It is very convenient within Linux to be able to switch to superuser
> > mode using su or sudu to perform an administrative action when needed,
> > without the entire namespace changing drastically. What? Suddenly
> > all my device names have changed? How do I know what I was having
> > trouble with as an ordinary user? Or else, if nothing changes, What?
> > as root I still can't access the devices I need that the ordinary user
> > couldn't name?
>
> Your concerns are well-received--vdev shouldn't take away the superuser's
> privileges if you don't want it to. vdev will offer at least three ways to
> implement a privileges-oriented approach to device access:
> * disable ACLs, making vdev behave like udev does today
> * have vdev create all device nodes "beneath" its mountpoint with sensible
> ownership/permissions, so that if you stop vdev, you'll see a static /dev
> that reflects the current state of your devices;
> * add an ACL that lets the superuser see everything

In VAX/VMS there was a feature that could in theory be useful,
though I've never seen it actually used. Fila permissions could
forbid the root user from reading the file. This might be useful
for dire secrets. Even the sysadmin couldn't back up that file.

-- hendrik