SD_BUS_GET_NAME_CREDS(3)

✨ SD_BUS_GET_NAME_CREDS(3) ✨

okay so this is the sd_bus_get_name_creds manual page, and it's literally all about snooping on bus client credentials (in the cute, sanctioned-by-the-API way, bestie 💖).

---

🦋 NAME 🦋

sd_bus_get_name_creds, sd_bus_get_owner_creds — query bus client credentials 👑

---

🌸 SYNOPSIS 🌸

#include <systemd/sd-bus.h>

int sd_bus_get_name_creds(sd_bus *bus, const char *name, uint64_t mask,
                          sd_bus_creds **creds);

int sd_bus_get_owner_creds(sd_bus *bus, uint64_t mask,
                           sd_bus_creds **creds);

---

💅 DESCRIPTION 💅

So sd_bus_get_name_creds() is the one that queries the credentials of the bus client identified by name. The mask parameter is a combo of SD_BUS_CREDS_* flags that tell it which credential info the caller is interested in. (Peep sd_bus_creds_new_from_pid(3) for the full list of possible flags, iykyk.) On success, creds contains a brand-new sd_bus_creds instance with all the requested information in it. Ownership of this instance belongs to the caller, and you should free it once you no longer need it by calling sd_bus_creds_unref(3) — no leaving it lying around, bestie 🧚.

And sd_bus_get_owner_creds() queries the credentials of the creator of the given bus. The mask and creds parameters behave exactly the same as in sd_bus_get_name_creds() 💫.

---

🔥 RETURN VALUE 🔥

On success, these functions return a non-negative integer. On failure, they return a negative errno-style error code. Periodt.

💀 Errors 💀

Returned errors may indicate the following problems:

• -EINVAL — an argument is invalid 🙈.
• -ENOPKG — the bus cannot be resolved 😭.
• -EPERM — the bus has already been started 💀.
• -ECHILD — the bus was created in a different process, library or module instance 👀.
• -ENOMEM — memory allocation failed, tragic fr fr.

---

🎀 NOTES 🎀

Functions described here are available as a shared library, which can be compiled against and linked to with the libsystemd pkg-config(1) file 🌈.

All functions listed here are thread-agnostic, and only a single thread may operate on a given object at any given time. Different threads may access the same object at different times, though — and multiple independent objects may be used from different threads in parallel. Slay, but respect the rules 🫶.

The code described here uses getenv(3), which is declared to be not multi-thread-safe. That means the code calling the functions described here must not call setenv(3) from a parallel thread. It is recommended to only do calls to setenv() from an early phase of the program when no other threads have been started. Basically: keep your environment setup early and don't be messy about it 😌.

no cap, the setenv(3) warning is the real main character here — parallel setenv() calls are a whole vibe check fail.

---

⭐ HISTORY ⭐

sd_bus_get_name_creds() and sd_bus_get_owner_creds() were added in version 221 🎉.

---

🌟 SEE ALSO 🌟

systemd(1), sd-bus(3), sd_bus_creds_unref(3) 🌸

---

later bestie! this page is from systemd 261.3, and it's the SD_BUS_GET_NAME_CREDS(3) page — go query those credentials responsibly 💜🦋