oddjobd.conf(5)

💖 oddjobd.conf — the file-formats-manual girlie 💖

okay bestie, so this is oddjobd.conf(5), from the File Formats Manual section, and it's literally the whole personality of your oddjobd server's config. let's get into it 🫶

---

✨ NAME ✨

oddjobd.conf — configuration for oddjobd 💅

---

🌸 DESCRIPTION 🌸

so the /etc/oddjobd.conf config file is the main character here. it tells you which services the oddjobd server provides over the D-Bus, plus the authorization rules which get enforced in addition to the ones the system message bus already enforces. no cap, double the gatekeeping 🚪✨

this config file is an XML document, obviously. the top-level element type is <oddjobconfig>, and it holds one or more <service> elements. each <service> describes a service that's gonna be provided on the system-wide message bus. 🦋

each <object> describes an object path that the specified service will recognize. plot twist: the object path may include wildcards, and if it does, any call to an object whose path name matches that specified path gets accepted. an object contains one or more <interface> elements, and each one describes a group of methods described in <method> elements. it's giving nesting dolls 🪆

each <method> element must specify the method name as the value for its name attribute. it may also include a <helper> element — that's where you put the name of an executable to run as its exec attribute, plus the number of arguments that'll be expected from the D-Bus client and passed to the helper as its argument_count attribute. 📝

lowkey important: the <helper>'s exec attribute can include one or more command line arguments, separated from the executable by whitespace. and a <helper> may also carry attributes saying:

• whether or not the invoking user's name should be prepended to the list of arguments received as part of the D-Bus request — that's prepend_user_name, and the recognized values are "yes" or "no" 👀
• whether that set of arguments should be passed into the helper via stdin (which is the default) or on its command line — that's argument_passing_method, with recognized values "stdin" and "cmdline" 🎀

any of <oddjobconfig>, <service>, <object>, <interface>, or <method> elements can also include authorization elements: <allow> and <deny>. 💜

each <allow> or <deny> rule specifies some combination of a user name and/or a UID range that the invoking user has to match for the rule to apply. a rule can also specify the caller's SELinux context, user, role, or execution domain, and it can be applied or not applied based on whether or not policy is being enforced. iykyk 🧚

here's the order of operations, and it matters so pay attention bestie:

1. all <deny> rules for the method are checked first
2. then all of its <allow> rules
3. if no matches are found, the <deny> rules for the containing <interface> element get checked
4. then that interface's <allow> rules
5. and so on, up the chain
6. if all the ACLs get searched and no matches turn up, access is denied 🚫

not me stressing the fallthrough order — it's literally the whole vibe check of your security model. memorize it fr fr.

the oddjobd server will automatically supply the information used by the D-Bus introspection mechanism on behalf of your objects — but only if the client requesting that info is allowed to invoke the Introspect method of the org.freedesktop.DBus.Introspectable interface provided by the object. so like, no permission, no peek behind the curtain 🙈

oh and! the config file may also indicate that the contents of other files should be read by the configuration parser, using an <include> element. 🌈

---

⭐ EXAMPLES ⭐

here's an example file, adorable honestly:

<?xml version="1.0"?>
<oddjobconfig/>

another one, and this one's serving:

<?xml version="1.0"?>
<oddjobconfig>
 <allow user="wally"/>
 <service name="com.redhat.oddjob">
  <allow user="polly"/>
  <object name="/com/redhat/oddjob">
   <allow user="holly"/>
   <interface name="com.redhat.oddjob">
    <allow user="bob"/>
    <method name="pwd">
     <helper exec="/bin/pwd" argument_count="0" prepend_user_name="no"/>
     <allow user="jimmy"/>
     <allow user="billy"/>
     <allow min_uid="0" max_uid="1000"/>
    </method>
    <method name="reboot">
     <helper exec="/sbin/reboot" argument_count="0"/>
    </method>
    <method name="flush-nscd">
     <helper exec="/sbin/nscd -i passwd -i group -i hosts" argument_count="0"/>
    </method>
   </interface>
   <interface name="org.freedesktop.DBus.Introspectable">
    <allow min_uid="0" max_uid="0"/>
   </interface>
  </object>
 </service>
 <include ignore_missing="yes">/etc/oddjobd-local.conf</include>
 <include ignore_missing="yes">/etc/oddjobd.conf.d/*.conf</include>
</oddjobconfig>

and another 🎀:

<?xml version="1.0"?>
<oddjobconfig>
 <service name="com.example.management">
  <object name="/com/example/power">
   <interface name="com.example.shutdown">
    <method name="reboot">
     <allow user="root"/>
     <helper exec="/sbin/reboot" argument_count="0"/>
    </method>
   </interface>
   <interface name="org.freedesktop.DBus.Introspectable">
    <allow min_uid="0" max_uid="0"/>
   </interface>
  </object>
  <object name="/com/example/power">
   <interface name="com.example.shutdown">
    <method name="poweroff">
     <allow user="root"/>
     <helper exec="/sbin/poweroff" argument_count="0"/>
    </method>
   </interface>
   <interface name="org.freedesktop.DBus.Introspectable">
    <allow min_uid="0" max_uid="0"/>
   </interface>
  </object>
 </service>
</oddjobconfig>

---

👑 SEE ALSO 👑

go read these next, they're the extended universe fr:

• oddjob_request(1)
• oddjob.conf(5)
• oddjobd(8)

---

and that's the whole page bestie!! 💖✨ this one shipped as part of the oddjob Manual, dated 24 June 2015. slay, ate, no crumbs. periodt. 💅🎀🦋