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 personally happen to like Plan 9's and inferno's approach to computing,
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.

> 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

-Jude

On Sat, Jan 3, 2015 at 9:24 AM, Hendrik Boom <hendrik@???> wrote:

> On Sat, Jan 03, 2015 at 01:27:38AM -0500, Jude Nelson wrote:
> > Hi Enrico,
> >
> > > I dont believe ACLs are a good idea anyways. They introduce yet another
> > > (orthogonal) dimension to the system, so heavily increase management
> > > complexity. For example, it's hard to trace problems that way, if /dev
> > > layout heavily depends on the calling process.
> >
> > I don't disagree with you, especially since namespacing will be necessary
> > when the same device node in each session must refer to a different
> > device. However, as I mentioned in an earlier email, solving the problem
> > of per-process access control by giving each session its own namespace
> > isn't always viable, particularly on OpenBSD (which has no
> containerization
> > support beyond chroot, and chroot isn't particularly useful for
> containing
> > processes). It's also not clear to me that the maintenance burden would
> be
> > reduced versus using ACLs, since a strategy for populating a given
> > session's /dev and keeping it up-to-date with hotplug events would
> probably
> > be comparably complex to vdev's ACL system (and this is on top of the
> > container lifecycle management code you'd have to write).
>
> 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.
>
> 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?
>
> But yes, of course, my home directory should switch to root's.
>
> No. It's privileges that should determine what I have access to, not
> my namespace.
>
> >
> > Also, you shouldn't have to use vdev's ACLs if you don't want to :) It's
> > perfectly valid to have vdev report all device nodes by default and take
> no
> > filtering actions, just like how udev would (definitely makes tracing
> > problems easier). I would never want to force you or anyone to use ACLs
> if
> > you didn't need them, since they're only one mechanism of many that can
> be
> > used to achieve the same end.
> >
> > > I'd rather raise the question whether that's useful at all.
> >
> > There was an LWN article on this a while back [2]. The examples provided
> > there are as follows:
> > * If the login program could revoke() the tty device node before
> prompting
> > the password, this attack vector would be removed (assuming the revoke()
> > implementation didn't affect file descriptors in the calling process).
> > This also applies to X11, which could revoke() the video device file
> prior
> > to setting it up.
>
> What if I'm currently logged in through a ssh shell and using
> that connection to su into another user's account? Is there a
> relevant tty to revoke?
>
> > * Suppose a process has open files in a filesystem you're trying to
> > unmount. You could revoke all files in the filesystem prior to trying to
> > umount() it.
> >
> > I can think of other ways to solve these problems without revoke() (e.g.
> > fuser will tell you who's accessing a file, allowing you to take further
> > actions like killing the offending processes); maybe that's why it didn't
> > make it into the kernel?
>
> Finding out which processes are accessing a file and manually shutting
> them down cleanly might be a lot safer than either revoking or killing the
> processes.
>
> -- hendrik
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>