package gvisor.common

Mouse Melon logoGet desktop application:
View/edit binary Protocol Buffers messages

message ContextData

common.proto:77

Used in: container.Start, sentry.CloneInfo, sentry.ExecveInfo, sentry.ExitNotifyParentInfo, sentry.TaskExit, syscall.Accept, syscall.Bind, syscall.Chdir, syscall.Chroot, syscall.Clone, syscall.Close, syscall.Connect, syscall.Dup, syscall.Eventfd, syscall.Execve, syscall.Fcntl, syscall.Fork, syscall.InotifyAddWatch, syscall.InotifyInit, syscall.InotifyRmWatch, syscall.Open, syscall.Pipe, syscall.Prlimit, syscall.Read, syscall.Setid, syscall.Setresid, syscall.Signalfd, syscall.Socket, syscall.SocketPair, syscall.Syscall, syscall.TimerfdCreate, syscall.TimerfdGetTime, syscall.TimerfdSetTime, syscall.Write

message Credentials

common.proto:67

Used in: ContextData

message Handshake

common.proto:63

Handshake message is used when establishing a connection. Version information is exchanged to determine if the communication can proceed. Each side reports a single version of the protocol that it supports. If they can't support the version reported by the peer, they must close the connection. If the peer version is higher (newer), it should continue to communicate, making the peer responsible to send messages that are compatible with your version. If the peer can't support it, the peer should close the connection. In short: 1. sentry and remote exchange versions 2. sentry continues if remote >= min(sentry) 3. remote continues if sentry >= min(remote) Suppose that peer A is at version 1 and peer B is at 2. Peer A sees that B is at a newer version and continues with communication. Peer B will see that A is at version 1 (older) and will check if it can send messages that are compatible with version 1. If yes, then the communication can continue. If not, A should close the connection. Here are 2 practical examples: 1. New field added to the header: this requires a change in protocol version (e.g. 1 => 2). However, if not essential to communication, the new field can be ignored by a peer that is still using version 1. Sentry version 1, remote version 2: remote doesn't get the new field, but can still receive messages. Sentry version 2, remote version 1: remote gets the new field, but ignores it since it's not aware the field exists yet. Note that remote must rely on header length to determine where the payload is. 2. Change in message format for batching: this requires a change in protocol version (2 => 3). Batching can only be used if both sides can handle it. Sentry version 2, remote version 3: remote gets a message at a time. If it still can do that, remote can accept that sentry is in version 2. Sentry version 3, remote version 2: remote is not able to process batched messages. If the sentry can still produce one message at a time the communication can continue, otherwise the sentry should close the connection. Note that addition of new message types do not require version changes. Server implementations should gracefully handle messages that it doesn't understand. Similarly, payload for message can change following protobuf rules for compatibilty. For example, adding new fields to a protobuf type doesn't require version bump.

enum MessageType

common.proto:99

MessageType describes the payload of a message sent to the remote process. LINT.IfChange