I have to ask, why is this in the kernel at all?
I wish this hadn't gotten past Linus. It seems to be poorly
thought out. Even now, years (?) later, there is disagreement
over the basic algorithms. Who even uses this stuff?
IMHO this feature is even a security risk. Normally, a program
that needs capability bits gets them all. If a non-root user
runs the program, it will fail at the first privileged call.
Now, with the bits separate, failure can occur mid-way through
the program. This can leave the system in a half-way state.
This IRIX-like system suffers from a granularity problem.
What reasonable way is there to split capabilities? The DG-UX
system doesn't have to answer this question because there is
a nice 1:1 mapping between capability bits and the real world.
(Done right, you need lots of bits. Done wrong... why bother?)
Remember what this whole system is supposed to do. UID values
were to _not_ grant power. This works great if, like DG-UX,
the OS reserves some bits for use outside the kernel. If you
don't do this, you have TWO INCOMPATIBLE SECURITY SYSTEMS
operating at the same time. The kernel-only distinction is a
serious error, obviously made because of the strong desire to
avoid dealing with the user-defined bit allocation issue.
Now, explain all this to a typical business admin, considering:
1. the complex and non-intuitive formulas
2. the lack of a 1:1 mapping to the real world
3. basic incompatibility with the UID system
4. UID still grants power, via user-space access control
Never mind the users! Just explain this to a common admin!
At best we have an unused feature. At worst we have a security
disaster waiting to happen. How about starting over? Really, it
would be nice to see this ill-defined system ripped out.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:26 EST