Skip to content

Capability vs. CapabilityFlags or How to raise all inheritable capabilities in the ambient set. #1434

Closed
@rusty-snake

Description

@rusty-snake

Capabilities (as well as namespaces, we discussed elsewhere) are bitflags in C/Linux. Some system calls do take/return an actual set while others take/return only a single bit. rustix uses bitflags types for the first and enum types for the later (increased typesafety).
For capabilities in rustix there is a Capability enum with opinionated names used for bounding and ambient sets where the underlying system calls take only one capability and a CapabilityFlags bitflags with original names used for inheritable/effective/permitted sets where the underlying system calls operate on sets.
I understand that rustix does not want to abstract these one/set semantic away and stick closer to the actual system calls. However the types should be unified.
What I mean with this is that 1. the names should be the same (e.g. CHOWN vs. ChangeOwnership) and 2. there must be easy convert functions between thoses two:

  • Capability -> CapabilityFlags, easy you just need a new CapabilityFlags with just one bit set.
  • CapabilityFlags -> Capability, likely as an iterator?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions