PMDAATTRIBUTE(3)

💖 PMDAATTRIBUTE 💖

ok so this is pmdaAttribute(3) from the Library Functions Manual — she's a PCP girlie, a real one, and she's about to tell your PMDA everything it needs to know about who just walked in the door. bestie, let's get into it ✨

---

🌸 NAME 🌸

pmdaAttribute — literally just here to inform a PMDA about client connection attributes 🫶

---

✨ C SYNOPSIS ✨

first, the vibes (includes):

#include <pcp/pmapi.h>
#include <pcp/pmda.h>

then the signature, no cap:

int pmdaAttribute(int context, int key, char *value, int length,
                  pmdaExt *pmda);

and the link line, do not forget her:

cc ... -lpcp_pmda -lpcp

---

🦋 DESCRIPTION 🦋

okay so. part of the Performance Metrics Domain Agent (PMDA) API (peep PMDA(3) if you're new here 💅), and pmdaAttribute is the generic callback for responding to client connection attributes. and what are those, you ask? they're the client credential info — think user ID, group ID, that whole situation. it's giving "who dis" but polite.

a PMDA that wants to support connection attributes has to bring its own private pmdaAttribute callback and assign it to version.six.attribute of the pmdaInterface structure. then you write your own custom logic for whichever attribute key-value pairs you actually care about. main character energy only for the ones you need 🎀

every single attribute is tied to a specific client context, and those are uniquely identified by the ctx first argument. so yes, the PMDA needs to keep track of client connections AND disconnections — that's what the pmdaSetEndContextCallBack(3) interface is for. also, the pmdaGetContext(3) interface might be particularly helpful here, just saying. iykyk.

all attributes come through as key-value pairs, and the value is always passed as a null-terminated string of given length. yes, even the numeric ones like user ID. yes, it's a string. we don't make the rules, we just slay within them 😭

the attributes you'll see most: PCP_ATTR_USERID and PCP_ATTR_GROUPID. but others may optionally get passed too (like PCP_ATTR_USERNAME) if they happen to be available. and some attributes get consumed by pmcd and never get passed through to PMDAs at all — PCP_ATTR_PASSWORD is the big one there. the complete list of every possible attribute lives in the headers listed above, and they're all prefixed with PCP_ATTR. go look, it's fine, we'll wait 🌈

---

💀 CAVEAT 💀

the PMDA must be using PMDA_INTERFACE_6 or later, as specified in the call to pmdaDSO(3) or pmdaDaemon(3). no interface 6, no attribute party. periodt.

---

🔥 DIAGNOSTICS 🔥

pmdaAttribute should return zero on success, or a negative return code to say "yeah something went sideways handling this attribute".

okay this part matters so listen up bestie: that return code cannot be used to indicate a client should be disallowed access. you can't do it that way, no ma'am. that kind of functionality has to be performed by the agent in response to callbacks for the client in question — using PM_ERR_PERMISSION for those specific callbacks, for that specific client. in other words, errors will be passed to PMCD, but there's no guarantee that the error will be returned to the client and result in termination of the client, for example. don't build your security model on it, fr fr 💀

---

🎀 SEE ALSO 🎀

• PMAPI(3)
• PMDA(3)
• pmdaDaemon(3)
• pmdaDSO(3)
• pmdaMain(3)
• pmdaGetContext(3)

---

and that's the whole page, bestie!! this one came straight from Performance Co-Pilot (that's PCP, the PMDAATTRIBUTE(3) one) 💖 go forth and track those contexts responsibly, you absolute icon 👑✨