Hi Hendrik,

> 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.

I think for some applications (like dealing with medical records), this is
a legal requirement.

On Linux at least, locking a user with CAP_SYS_PTRACE out of a userspace
filesystem is impossible, since in the extreme the user can always ptrace
it and override its behavior. In vdev's case, even though it's possible to
create an ACL that prevents even root from seeing devices via the VFS, a
privileged user could still get past it. I'll be sure to document this--I
wouldn't want users to get lulled into a false sense of security.

-Jude

On Sun, Jan 4, 2015 at 11:33 AM, Hendrik Boom <hendrik@???>
wrote:

> 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
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>