Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • D dbus
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 33
    • Merge requests 33
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • dbus
  • dbus
  • Issues
  • #185

Closed
Open
Created Jul 24, 2017 by Bugzilla Migration User@bugzilla-migration

Containers (#100344): message filtering/policy

Submitted by Simon McVittie

Assigned to Simon McVittie

Link to original bug (#101902)

Description

+++ This bug was initially created as a clone of Bug #100344 +++

Bug #101354 does not let container managers arrange for messages to be filtered. This is part of the wish-list for Bug #100344, because it would eventually let us get rid of flatpak-dbus-proxy.

Design sketch:

  • New named parameter:

    Allow: a(usos)
        Array of tuples (flags: u, bus name: s, object path: o, interface: s)
    
        If this parameter is given, it sets the messages and operations
        that are allowed.
    
        An empty array allows sending method calls to the message
        bus, and receiving exactly one reply or error for each method call
        successfully sent (unless it was NO_REPLY). It also allows
        receiving method calls from connections that are not in a container,
        and sending exactly one reply or error for each method call
        received (unless it was NO_REPLY). It does not allow receiving
        broadcast signals. This is the most restrictive possible policy.
    
        [TODO: Does it allow receiving unicast signals from connections
        that are not in a container?]
    
        Each array entry is a /rule/ which allows additional operations
        according to its flags. If the bus name is the empty string,
        it matches all bus names (and hence all possible connections).
        If the interface is the empty string, it matches messages with
        any interface or no interface. If the object path is "/" and
        the OBJECT_PATH_IS_SUBTREE flag is present, it matches messages
        with any object path or no object path.
    
            SEE:
                The connection may call GetNameOwner(), NameHasOwner(),
                GetConnectionCredentials(), etc. to inspect connections
                that are in the queue to own the given bus name.
                The object path and interface are ignored when checking
                for SEE access.
            CALL_METHODS:
                The connection may send method call messages to
                connections that are in the queue to own the given
                bus name. Implies SEE.
            RECEIVE_BROADCASTS (or RECEIVE_SIGNALS?):
                The connection may receive broadcasts (or all signals?)
                from connections that are in the queue to own the given
                bus name, if they match the given object path and
                interface.
            TALK: alias for SEE | CALL_METHODS | RECEIVE_whatever
            BUS_NAME_IS_SUBTREE:
                The bus name is matched in the same way as arg0namespace
                in signal match rules, instead of as an exact match.
            OBJECT_PATH_IS_SUBTREE:
                In addition to messages that match exactly, the object
                path matches messages with an object path that has
                additional components. For example, "/foo" matches messages
                with object path "/foo" or "/foo/bar" but not "/foolish".
                Note that this is not identical to arg0path in signal
                match rules.
            SEND_UNIX_FDS, RECEIVE_UNIX_FDS:
                The connection may send, receive messages that contain
                Unix fds and match the given bus name, object path and
                interface.
            OWN_BUS_NAME:
                The connection may use RequestName and ReleaseName
                to own the given bus name. Implies SEE and TALK.
                The object path must be "/" and the interface must
                be "".
    
        Not giving this parameter is equivalent to providing policies
        that allow the confined connection to send and receive every
        message, own every bus name, etc. This is the least restrictive
        possible policy.
  • o.fd.Containers.GrantAccess(a(uos): rules) Rules are as above, but bus name is implicitly the caller's unique name

  • o.fd.Containers.RevokeAccess(a(uos): rules) Rules are as for GrantAccess. If a rule was added more than once, each revocation removes one of the identical copies.

Version: git master

Depends on

  • Bug 105656
  • Bug 105657
  • Bug 105658
  • Bug 105659
  • Bug 105660
  • Bug 101354

Blocking

  • Bug 100344
  • Bug 105661
Assignee
Assign to
Time tracking