> PS: just one warning from my last bits of memories of VMS-days: it's
> pretty important that priviledges are some sort of orthogonal and
> don't have (too much) unexpected side effects in allowing other
> operations too. I remember that e.g. just the signle "READALL"
> priviledge (allowed to read-only access all files, pretty handy for
> operator's processes running disk backups) was sufficient to be
> misused to get all other privildges you'd like to have (first get
> CMEXEC or CMKRNL, then SETPRIV, then everything else; or some simiar
> sequence...).
Yes this is a problem. However, I don't think we should abandon
fine-grained capabilities even if we can promote one capabilities to
others. The capabilities you can obtain by being able to write to any
file on the filesystem depends on the system. I can build a system
where you wouldn't be able to do much with that privilege because all
files you wanted to overwrite were immutable and not covered by that
particular capability. You have to be careful when designing a
capability-based _system_ to make sure that the partitioning
implemented by the kernel is enforceable. Only when it is impossible
to enforce this under any circumstance should it be considered a bug
IMHO. Those who don't want to make the necessary changes to their
system to make the partitioning work will probably accept that some
capabilities can be promoted to others.
astor
-- Alexander Kjeldaas, Guardian Networks AS, Trondheim, Norway http://www.guardian.no/- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu