On 03.01.2015 15:24, Hendrik Boom wrote:

> It looks as if this whole discussion is in the direction of building
> a capability architecture on top of Linux.

I wouldn't call that capabilities - that, IMHO, is an entirely
orthogonal concept. (one which I don't particularily like). Instead I'm
attempting to use some kind of virtualization approach for further
isolating things.

> I'm not sure this isn't a much greater change than imposing systemd.

Well, I'm trying to find a solution where that's not the case.
IMHO, our current ideas can easily support both the old-fashioned
unix approach, and the device-virtualizing one in parallel. Of course,
it would need some additional (maybe dist-specific) logic - but that's
still to be worked out.

> If you want such a thing, better to switch to an OS that does this
> natively, such as, perhaps, inferno.

That would be an _entirely_ different OS. I certainly dont wanna
reinvent Plan9 or Inferno, but just try to use some of their concepts
where applicable in GNU/Linux.

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

Yes, I know, that could be confusing. That's why it should be optional
and only enabled on per-service and per-user basis. Of course, we would
need some tool which constructs proper namespaces for debugging purposes.

OTOH, this would also call for using chroot-based namespaces, so root
can always easily have a look at the session namespace.

For example: we've got a session 1234 for user foo, it's namespace
could be constructed at '/ns/session/foo/1234' which looks pretty much
like normal /, but with special mounts for that session. User processes
of that session would be chroot'ed to that directory.

Of course, all these things should be optional, vdev just should provide
the necessary namespacing / mapping capabilities, which can be used by
an session manager, which then handles all these things.

> No. It's privileges that should determine what I have access to, not
> my namespace.

Sure. I dont intend to change that (in fact that was one of the things
which took some time for me to understand plan9 world).

My intention behind that is not access control, but device name
virtualization, for easier userland configuration - an entirely
optional feature.

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

Good point. That scenario is also interesting for access control
(beyond usual file modes) - would/should new/other device suddenly
appear and others disappear ?

In fact, I would try not to use su in usual operations - instead move
privileged operations to separate services, so even daily system
administration doesn't require su at all.

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

ACK. That way, applications still have the chance to write buffers.


cu
--
Enrico Weigelt,
metux IT consulting
+49-151-27565287