Unix Domain Socket path for IPC between LaunchDaemon and LaunchAgent

Question

Created 1w

Replies 4

Boosts 0

Participants 2

Hello,

I am working on a cross-platform application where IPC between a LaunchDaemon and a LaunchAgent is implemented via Unix domain sockets. On macOS, the socket path length is restricted to 104 characters. What is the Apple-recommended directory for these sockets to ensure the path remains under the limit while allowing a non-sandboxed agent to communicate with a root daemon? Standard paths like $TMPDIR are often too long for this purpose.

Thank you in advance!

Answered by DTS Engineer in 878343022

On macOS, the socket path length is restricted to 104 characters

That’s not quite right. While sockaddr_un has a fairly short limit, a Unix domain socket address actually supports a path length up to 253 bytes, which is SOCK_MAXADDRLEN minus the two byte header containing sun_family and sun_len. However, sockaddr_un is defined such that sun_path is 104.

So, if you’re happy to do some gnarly pointer play, you can use longer paths, long enough to allow them to live within an app group container.

Oh, wait, you said not sandboxed. Well, in that case, you don’t need to put them in an app group container, but you can still take advantage of the long path support.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Boost

Answer 1

DTS Engineer OP

Apple

1w

Recommended

On macOS, the socket path length is restricted to 104 characters

That’s not quite right. While sockaddr_un has a fairly short limit, a Unix domain socket address actually supports a path length up to 253 bytes, which is SOCK_MAXADDRLEN minus the two byte header containing sun_family and sun_len. However, sockaddr_un is defined such that sun_path is 104.

So, if you’re happy to do some gnarly pointer play, you can use longer paths, long enough to allow them to live within an app group container.

Oh, wait, you said not sandboxed. Well, in that case, you don’t need to put them in an app group container, but you can still take advantage of the long path support.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 2

___Pavel___ OP

6d

Thank you for response!

Our IPC implementation is based on Boost.Asio, and I am encountering the sockaddr_un size limitation when using the user's home directory. I am considering using NSTemporaryDirectory() instead. Are there any guarantees the path returned by this function will always fit within the buffer sockaddr_un? Additionally, are there any other locations for IPC sockets that avoid this path length restriction?

Thank you in advance!

0

Answer 3

DTS Engineer OP

Apple

5d

Accepted Answer

Our IPC implementation is based on

I find it strange that this is limited to sockaddr_un. macOS is not unusual in longer paths; I don’t know about Linux, but pretty much all the BSDs work this way.

Are there any guarantees the path returned by this function will always fit within the buffer sockaddr_un?

I’ve never seen such a guarantee.

are there any other locations for IPC sockets that avoid this path length restriction?

The traditional location for this stuff is /var/run. See the hier man page. But if you do use that, choose an appropriately unique file name to avoid collisions with the system and other third-party products. Typically that means using reverse DNS or embedding your company or product name in the file name.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 4

___Pavel___ OP

2d

thank you!

0