Re: Link-layer header type for unix domain sockets (UDS)

[František Kučera <konference () frantovo cz>]

Dne 24. 03. 19 v 19:18 Guy Harris napsal(a):
> So perhaps we need separate link-layer header types for "arbitrary 
> segment of a stream" (which would require TCP-like processing) and 
> "datagram"?

UDS are bit weird from the layer point of view, because they are like 
TCP or UDP but on the other hand, there is nothing like IP under them. 
So it is a question whether UDS should be considered a link-layer or 
something above it.

And what if some application uses both kinds of UDS (stream and 
datagram)? Because the link-layer number is in the global header, these 
two kinds of sockets could not be combined in a single capture file. 
(but I can have TCP, UDP and e.g. SCTP in a single file)

Maybe it would be better to have one link-layer header type for all UDS 
and then a) define another layer above this one (like TCP and UDP above 
IP) or b) have in this link-layer all fields for all kinds of UDS.

> Information in addition to raw payload would be:
>
>         name of the socket, if any (with Linux abstract sockets being handled);

The abstract names start with null byte (\0) and consists of all the 
remaining characters (including null bytes) up to the limit. (at least 
according to the Michael Kerrisk's book :-) So it could be treated in 
both cases just as 108 bytes (in Linux). In other systems it might 
differ - According to the Open Group: 
<http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_un.h.html#tag_13_67_04>:

> The size of sun_path has intentionally been left undefined. This is 
because different implementations use different sizes.
> For example, 4.3 BSD uses a size of 108, and 4.4 BSD uses a size of 
104. Since most implementations originate from BSD versions, the size is 
typically in the range 92 to 108.
> Applications should not assume a particular length for sun_path or 
assume that it can hold {_POSIX_PATH_MAX} bytes (256).

BTW: the header should be fixed-size or could have some 
optional/variable fields?

>         credentials of the peers;
>
>         security label, on OSes supporting that;
>
>         control message data (including but not necessarily limited to file descriptors being passed over the socket 
> with SCM_RIGHTS).
Great idea!
> Note that not all OSes support the same set of control-message types, and they might not use the same values for the same 
> control-message type #define, so we'd probably want to assign our own values for control-message types.  SCM_RIGHTS *might* be 1 
> on all UN*Xes, but that's probably the only one that would be.  In Linux 4.20.3's socket.h, we have
>
>         #define SCM_RIGHTS      0x01            /* rw: access rights (array of int) */
>         #define SCM_CREDENTIALS 0x02            /* rw: struct ucred             */
>         #define SCM_SECURITY    0x03            /* rw: security label           */
>
> and in macOS High Sierra's we have
>
>         #define SCM_RIGHTS              0x01    /* access rights (array of int) */
>         #define SCM_TIMESTAMP           0x02    /* timestamp (struct timeval) */
>         #define SCM_CREDS               0x03    /* process creds (struct cmsgcred) */
>         #define SCM_TIMESTAMP_MONOTONIC 0x04    /* timestamp (uint64_t) */
>
> and in a just-svn-updated FreeBSD checkout we have
>
>         #define SCM_RIGHTS      0x01            /* access rights (array of int) */
>         #define SCM_TIMESTAMP   0x02            /* timestamp (struct timeval) */
>         #define SCM_CREDS       0x03            /* process creds (struct cmsgcred) */
>         #define SCM_BINTIME     0x04            /* timestamp (struct bintime) */
>         #define SCM_REALTIME    0x05            /* timestamp (struct timespec) */
>         #define SCM_MONOTONIC   0x06            /* timestamp (struct timespec) */
>         #define SCM_TIME_INFO   0x07            /* timestamp info */
>
> and so on.
>
> For SOCK_STREAM sockets and Linux SOCK_SEQPACKET sockets, some information, such as the socket name and information about the peers, would 
> probably be provided with a special initial "packet" or "packets" at the beginning of the capture, as they're 
> connection-oriented.

Like TCP or SCTP. There should be a way how to track connection so one 
can e.g. filter all packets where socket = "/run/my.sock". This will be 
IMHO common use case. Other common filtering might be by UID or PID. In 
TCP there are port numbers in each packet. In UDS the PID and FD might 
work in similar way?

>    For SOCK_DGRAM sockets, that would be provided for every packet, as I don't think you need to connect to send on one 
> of them.
I think so, like UDP.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers