Scope and Using devices

Robert Love rml at
Tue Jun 1 12:54:23 PDT 2004

On Tue, 2004-06-01 at 13:26 -0400, Joe Shaw wrote:

> The core problem of access control still exists, but really that problem
> exists no matter what.  If we want to do setting, we can probably either
> implement our own (I've done it for Red Carpet, so I'm starting to get
> good at it. ;) or reuse dbus's.  But I'd rather see it fixed somehow in
> the operating system, maybe using POSIX capabilities.  But I hope that
> Robert will be able to answer more to that than I could. :)

I agree that the access control should be solved at the correct level -
e.g. the kernel - and not elsewhere, either.

POSIX capabilities would be pretty nice.  They multiplex the current
root/non-root nightmare onto one of many per-task rights, such as

Problem is, capabilities need filesystem support - in place of the 1-bit
setuid flag, we need an (3*m)-bit capabilities mask for m capabilities.
I think I heard once that the estimate is 100-bits per file.

Not a big deal, but it is not in the kernel.  I think people have worked
on it in the past, but no one is currently working on it - the patches
are not up to date.

Plus, user-space tools are spotty and documentation is thin.  Current
system administrators have trouble with the current 12 permission bits
that UNIX defines.  Who knows what field day they will have with
managing all of the capabilities on a per-file basis.

Which leads us to what Joe and I have hacked on this morning ...

Apps can run as setuid root, drop all capabilities but the requested one
(s), and then set their uid's to the running (or any arbitrary) user.
This can be done as the very first lines of code in the program,
providing effectively the same results as if the filesystem supported

Joe and I have some test code that does the above.  It works.

This leaves the onus of solving the access control problem on the core
OS, where it belongs.

	Robert Love

hal mailing list
hal at

More information about the Hal mailing list