This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

man7

1 - Linux cli command ALTER_LANGUAGE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_LANGUAGE and provides detailed information about the command ALTER_LANGUAGE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_LANGUAGE.

NAME 🖥️ ALTER_LANGUAGE 🖥️

change the definition of a procedural language

SYNOPSIS

ALTER [ PROCEDURAL ] LANGUAGE name RENAME TO new_name
ALTER [ PROCEDURAL ] LANGUAGE name OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }

DESCRIPTION

ALTER LANGUAGE changes the definition of a procedural language. The only functionality is to rename the language or assign a new owner. You must be superuser or owner of the language to use ALTER LANGUAGE.

PARAMETERS

name

Name of a language

new_name

The new name of the language

new_owner

The new owner of the language

COMPATIBILITY

There is no ALTER LANGUAGE statement in the SQL standard.

SEE ALSO

CREATE LANGUAGE (CREATE_LANGUAGE(7)), DROP LANGUAGE (DROP_LANGUAGE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

2 - Linux cli command path_resolution

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command path_resolution and provides detailed information about the command path_resolution, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the path_resolution.

NAME 🖥️ path_resolution 🖥️

how a pathname is resolved to a file

DESCRIPTION

Some UNIX/Linux system calls have as parameter one or more filenames. A filename (or pathname) is resolved as follows.

Step 1: start of the resolution process

If the pathname starts with the ‘/’ character, the starting lookup directory is the root directory of the calling process. A process inherits its root directory from its parent. Usually this will be the root directory of the file hierarchy. A process may get a different root directory by use of the chroot(2) system call, or may temporarily use a different root directory by using openat2(2) with the RESOLVE_IN_ROOT flag set.

A process may get an entirely private mount namespace in case it—or one of its ancestors—was started by an invocation of the clone(2) system call that had the CLONE_NEWNS flag set. This handles the ‘/’ part of the pathname.

If the pathname does not start with the ‘/’ character, the starting lookup directory of the resolution process is the current working directory of the process — or in the case of openat(2)-style system calls, the dfd argument (or the current working directory if AT_FDCWD is passed as the dfd argument). The current working directory is inherited from the parent, and can be changed by use of the chdir(2) system call.

Pathnames starting with a ‘/’ character are called absolute pathnames. Pathnames not starting with a ‘/’ are called relative pathnames.

Step 2: walk along the path

Set the current lookup directory to the starting lookup directory. Now, for each nonfinal component of the pathname, where a component is a substring delimited by ‘/’ characters, this component is looked up in the current lookup directory.

If the process does not have search permission on the current lookup directory, an EACCES error is returned (“Permission denied”).

If the component is not found, an ENOENT error is returned (“No such file or directory”).

If the component is found, but is neither a directory nor a symbolic link, an ENOTDIR error is returned (“Not a directory”).

If the component is found and is a directory, we set the current lookup directory to that directory, and go to the next component.

If the component is found and is a symbolic link, we first resolve this symbolic link (with the current lookup directory as starting lookup directory). Upon error, that error is returned. If the result is not a directory, an ENOTDIR error is returned. If the resolution of the symbolic link is successful and returns a directory, we set the current lookup directory to that directory, and go to the next component. Note that the resolution process here can involve recursion if the prefix (‘dirname’) component of a pathname contains a filename that is a symbolic link that resolves to a directory (where the prefix component of that directory may contain a symbolic link, and so on). In order to protect the kernel against stack overflow, and also to protect against denial of service, there are limits on the maximum recursion depth, and on the maximum number of symbolic links followed. An ELOOP error is returned when the maximum is exceeded (“Too many levels of symbolic links”).

As currently implemented on Linux, the maximum number of symbolic links that will be followed while resolving a pathname is 40. Before Linux 2.6.18, the limit on the recursion depth was 5. Starting with Linux 2.6.18, this limit was raised to 8. In Linux 4.2, the kernel’s pathname-resolution code was reworked to eliminate the use of recursion, so that the only limit that remains is the maximum of 40 resolutions for the entire pathname.

The resolution of symbolic links during this stage can be blocked by using openat2(2), with the RESOLVE_NO_SYMLINKS flag set.

Step 3: find the final entry

The lookup of the final component of the pathname goes just like that of all other components, as described in the previous step, with two differences: (i) the final component need not be a directory (at least as far as the path resolution process is concerned—it may have to be a directory, or a nondirectory, because of the requirements of the specific system call), and (ii) it is not necessarily an error if the component is not found—maybe we are just creating it. The details on the treatment of the final entry are described in the manual pages of the specific system calls.

. and ..

By convention, every directory has the entries “.” and “..”, which refer to the directory itself and to its parent directory, respectively.

The path resolution process will assume that these entries have their conventional meanings, regardless of whether they are actually present in the physical filesystem.

One cannot walk up past the root: “/..” is the same as “/”.

Mount points

After a mount dev path command, the pathname “path” refers to the root of the filesystem hierarchy on the device “dev”, and no longer to whatever it referred to earlier.

One can walk out of a mounted filesystem: “path/..” refers to the parent directory of “path”, outside of the filesystem hierarchy on “dev”.

Traversal of mount points can be blocked by using openat2(2), with the RESOLVE_NO_XDEV flag set (though note that this also restricts bind mount traversal).

Trailing slashes

If a pathname ends in a ‘/’, that forces resolution of the preceding component as in Step 2: the component preceding the slash either exists and resolves to a directory or it names a directory that is to be created immediately after the pathname is resolved. Otherwise, a trailing ‘/’ is ignored.

If the last component of a pathname is a symbolic link, then it depends on the system call whether the file referred to will be the symbolic link or the result of path resolution on its contents. For example, the system call lstat(2) will operate on the symbolic link, while stat(2) operates on the file pointed to by the symbolic link.

Length limit

There is a maximum length for pathnames. If the pathname (or some intermediate pathname obtained while resolving symbolic links) is too long, an ENAMETOOLONG error is returned (“Filename too long”).

Empty pathname

In the original UNIX, the empty pathname referred to the current directory. Nowadays POSIX decrees that an empty pathname must not be resolved successfully. Linux returns ENOENT in this case.

Permissions

The permission bits of a file consist of three groups of three bits; see chmod(1) and stat(2). The first group of three is used when the effective user ID of the calling process equals the owner ID of the file. The second group of three is used when the group ID of the file either equals the effective group ID of the calling process, or is one of the supplementary group IDs of the calling process (as set by setgroups(2)). When neither holds, the third group is used.

Of the three bits used, the first bit determines read permission, the second write permission, and the last execute permission in case of ordinary files, or search permission in case of directories.

Linux uses the fsuid instead of the effective user ID in permission checks. Ordinarily the fsuid will equal the effective user ID, but the fsuid can be changed by the system call setfsuid(2).

(Here “fsuid” stands for something like “filesystem user ID”. The concept was required for the implementation of a user space NFS server at a time when processes could send a signal to a process with the same effective user ID. It is obsolete now. Nobody should use setfsuid(2).)

Similarly, Linux uses the fsgid (“filesystem group ID”) instead of the effective group ID. See setfsgid(2).

Bypassing permission checks: superuser and capabilities

On a traditional UNIX system, the superuser (root, user ID 0) is all-powerful, and bypasses all permissions restrictions when accessing files.

On Linux, superuser privileges are divided into capabilities (see capabilities(7)). Two capabilities are relevant for file permissions checks: CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH. (A process has these capabilities if its fsuid is 0.)

The CAP_DAC_OVERRIDE capability overrides all permission checking, but grants execute permission only when at least one of the file’s three execute permission bits is set.

The CAP_DAC_READ_SEARCH capability grants read and search permission on directories, and read permission on ordinary files.

SEE ALSO

readlink(2), capabilities(7), credentials(7), symlink(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

3 - Linux cli command provider-kdfssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command provider-kdfssl and provides detailed information about the command provider-kdfssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the provider-kdfssl.

NAME 🖥️ provider-kdfssl 🖥️

kdf - The KDF library <-> provider functions

SYNOPSIS

#include <openssl/core_dispatch.h> #include <openssl/core_names.h> /* * None of these are actual functions, but are displayed like this for * the function signatures for functions that are offered as function * pointers in OSSL_DISPATCH arrays. */ /* Context management */ void *OSSL_FUNC_kdf_newctx(void *provctx); void OSSL_FUNC_kdf_freectx(void *kctx); void *OSSL_FUNC_kdf_dupctx(void *src); /* Encryption/decryption */ int OSSL_FUNC_kdf_reset(void *kctx); int OSSL_FUNC_kdf_derive(void *kctx, unsigned char *key, size_t keylen, const OSSL_PARAM params[]); /* KDF parameter descriptors */ const OSSL_PARAM *OSSL_FUNC_kdf_gettable_params(void *provctx); const OSSL_PARAM *OSSL_FUNC_kdf_gettable_ctx_params(void *kcxt, void *provctx); const OSSL_PARAM *OSSL_FUNC_kdf_settable_ctx_params(void *kcxt, void *provctx); /* KDF parameters */ int OSSL_FUNC_kdf_get_params(OSSL_PARAM params[]); int OSSL_FUNC_kdf_get_ctx_params(void *kctx, OSSL_PARAM params[]); int OSSL_FUNC_kdf_set_ctx_params(void *kctx, const OSSL_PARAM params[]);

DESCRIPTION

This documentation is primarily aimed at provider authors. See provider (7) for further information.

The KDF operation enables providers to implement KDF algorithms and make them available to applications via the API functions EVP_KDF_CTX_reset (3), and EVP_KDF_derive (3).

All “functions” mentioned here are passed as function pointers between libcrypto and the provider in OSSL_DISPATCH (3) arrays via OSSL_ALGORITHM (3) arrays that are returned by the provider’s provider_query_operation() function (see “Provider Functions” in provider-base (7)).

All these “functions” have a corresponding function type definition named OSSL_FUNC_{name}_fn, and a helper function to retrieve the function pointer from an OSSL_DISPATCH (3) element named OSSL_FUNC_{name}. For example, the “function” OSSL_FUNC_kdf_newctx() has these:

typedef void *(OSSL_FUNC_kdf_newctx_fn)(void *provctx); static ossl_inline OSSL_FUNC_kdf_newctx_fn OSSL_FUNC_kdf_newctx(const OSSL_DISPATCH *opf);

OSSL_DISPATCH (3) array entries are identified by numbers that are provided as macros in openssl-core_dispatch.h (7), as follows:

OSSL_FUNC_kdf_newctx OSSL_FUNC_KDF_NEWCTX OSSL_FUNC_kdf_freectx OSSL_FUNC_KDF_FREECTX OSSL_FUNC_kdf_dupctx OSSL_FUNC_KDF_DUPCTX OSSL_FUNC_kdf_reset OSSL_FUNC_KDF_RESET OSSL_FUNC_kdf_derive OSSL_FUNC_KDF_DERIVE OSSL_FUNC_kdf_get_params OSSL_FUNC_KDF_GET_PARAMS OSSL_FUNC_kdf_get_ctx_params OSSL_FUNC_KDF_GET_CTX_PARAMS OSSL_FUNC_kdf_set_ctx_params OSSL_FUNC_KDF_SET_CTX_PARAMS OSSL_FUNC_kdf_gettable_params OSSL_FUNC_KDF_GETTABLE_PARAMS OSSL_FUNC_kdf_gettable_ctx_params OSSL_FUNC_KDF_GETTABLE_CTX_PARAMS OSSL_FUNC_kdf_settable_ctx_params OSSL_FUNC_KDF_SETTABLE_CTX_PARAMS

A KDF algorithm implementation may not implement all of these functions. In order to be a consistent set of functions, at least the following functions must be implemented: OSSL_FUNC_kdf_newctx(), OSSL_FUNC_kdf_freectx(), OSSL_FUNC_kdf_set_ctx_params(), OSSL_FUNC_kdf_derive(). All other functions are optional.

Context Management Functions

OSSL_FUNC_kdf_newctx() should create and return a pointer to a provider side structure for holding context information during a KDF operation. A pointer to this context will be passed back in a number of the other KDF operation function calls. The parameter provctx is the provider context generated during provider initialisation (see provider (7)).

OSSL_FUNC_kdf_freectx() is passed a pointer to the provider side KDF context in the kctx parameter. If it receives NULL as kctx value, it should not do anything other than return. This function should free any resources associated with that context.

OSSL_FUNC_kdf_dupctx() should duplicate the provider side KDF context in the kctx parameter and return the duplicate copy.

Encryption/Decryption Functions

OSSL_FUNC_kdf_reset() initialises a KDF operation given a provider side KDF context in the kctx parameter.

OSSL_FUNC_kdf_derive() performs the KDF operation after processing the params as per OSSL_FUNC_kdf_set_ctx_params(). The kctx parameter contains a pointer to the provider side context. The resulting key of the desired keylen should be written to key. If the algorithm does not support the requested keylen the function must return error.

KDF Parameters

See OSSL_PARAM (3) for further details on the parameters structure used by these functions.

OSSL_FUNC_kdf_get_params() gets details of parameter values associated with the provider algorithm and stores them in params.

OSSL_FUNC_kdf_set_ctx_params() sets KDF parameters associated with the given provider side KDF context kctx to params. Any parameter settings are additional to any that were previously set. Passing NULL for params should return true.

OSSL_FUNC_kdf_get_ctx_params() retrieves gettable parameter values associated with the given provider side KDF context kctx and stores them in params. Passing NULL for params should return true.

OSSL_FUNC_kdf_gettable_params(), OSSL_FUNC_kdf_gettable_ctx_params(), and OSSL_FUNC_kdf_settable_ctx_params() all return constant OSSL_PARAM (3) arrays as descriptors of the parameters that OSSL_FUNC_kdf_get_params(), OSSL_FUNC_kdf_get_ctx_params(), and OSSL_FUNC_kdf_set_ctx_params() can handle, respectively. OSSL_FUNC_kdf_gettable_ctx_params() and OSSL_FUNC_kdf_settable_ctx_params() will return the parameters associated with the provider side context kctx in its current state if it is not NULL. Otherwise, they return the parameters associated with the provider side algorithm provctx.

Parameters currently recognised by built-in KDFs are as follows. Not all parameters are relevant to, or are understood by all KDFs:

“size” (OSSL_KDF_PARAM_SIZE) <unsigned integer>
Gets the output size from the associated KDF ctx. If the algorithm produces a variable amount of output, SIZE_MAX should be returned. If the input parameters required to calculate the fixed output size have not yet been supplied, 0 should be returned indicating an error.

“key” (OSSL_KDF_PARAM_KEY) <octet string>
Sets the key in the associated KDF ctx.

“secret” (OSSL_KDF_PARAM_SECRET) <octet string>
Sets the secret in the associated KDF ctx.

“pass” (OSSL_KDF_PARAM_PASSWORD) <octet string>
Sets the password in the associated KDF ctx.

“cipher” (OSSL_KDF_PARAM_CIPHER) <UTF8 string>

“digest” (OSSL_KDF_PARAM_DIGEST) <UTF8 string>

“mac” (OSSL_KDF_PARAM_MAC) <UTF8 string>

Sets the name of the underlying cipher, digest or MAC to be used. It must name a suitable algorithm for the KDF that’s being used.

“maclen” (OSSL_KDF_PARAM_MAC_SIZE) <octet string>
Sets the length of the MAC in the associated KDF ctx.

“properties” (OSSL_KDF_PARAM_PROPERTIES) <UTF8 string>
Sets the properties to be queried when trying to fetch the underlying algorithm. This must be given together with the algorithm naming parameter to be considered valid.

“iter” (OSSL_KDF_PARAM_ITER) <unsigned integer>
Sets the number of iterations in the associated KDF ctx.

“mode” (OSSL_KDF_PARAM_MODE) <UTF8 string>
Sets the mode in the associated KDF ctx.

“pkcs5” (OSSL_KDF_PARAM_PKCS5) <integer>
Enables or disables the SP800-132 compliance checks. A mode of 0 enables the compliance checks. The checks performed are:

- the iteration count is at least 1000.

- the salt length is at least 128 bits.

- the derived key length is at least 112 bits.

“ukm” (OSSL_KDF_PARAM_UKM) <octet string>

Sets an optional random string that is provided by the sender called “partyAInfo”. In CMS this is the user keying material.

“cekalg” (OSSL_KDF_PARAM_CEK_ALG) <UTF8 string>
Sets the CEK wrapping algorithm name in the associated KDF ctx.

“n” (OSSL_KDF_PARAM_SCRYPT_N) <unsigned integer>
Sets the scrypt work factor parameter N in the associated KDF ctx.

“r” (OSSL_KDF_PARAM_SCRYPT_R) <unsigned integer>
Sets the scrypt work factor parameter r in the associated KDF ctx.

“p” (OSSL_KDF_PARAM_SCRYPT_P) <unsigned integer>
Sets the scrypt work factor parameter p in the associated KDF ctx.

“maxmem_bytes” (OSSL_KDF_PARAM_SCRYPT_MAXMEM) <unsigned integer>
Sets the scrypt work factor parameter maxmem in the associated KDF ctx.

“prefix” (OSSL_KDF_PARAM_PREFIX) <octet string>
Sets the prefix string using by the TLS 1.3 version of HKDF in the associated KDF ctx.

“label” (OSSL_KDF_PARAM_LABEL) <octet string>
Sets the label string using by the TLS 1.3 version of HKDF in the associated KDF ctx.

“data” (OSSL_KDF_PARAM_DATA) <octet string>
Sets the context string using by the TLS 1.3 version of HKDF in the associated KDF ctx.

“info” (OSSL_KDF_PARAM_INFO) <octet string>
Sets the optional shared info in the associated KDF ctx.

“seed” (OSSL_KDF_PARAM_SEED) <octet string>
Sets the IV in the associated KDF ctx.

“xcghash” (OSSL_KDF_PARAM_SSHKDF_XCGHASH) <octet string>
Sets the xcghash in the associated KDF ctx.

“session_id” (OSSL_KDF_PARAM_SSHKDF_SESSION_ID) <octet string>
Sets the session ID in the associated KDF ctx.

“type” (OSSL_KDF_PARAM_SSHKDF_TYPE) <UTF8 string>
Sets the SSH KDF type parameter in the associated KDF ctx. There are six supported types:

EVP_KDF_SSHKDF_TYPE_INITIAL_IV_CLI_TO_SRV
The Initial IV from client to server. A single char of value 65 (ASCII char ‘A’).

EVP_KDF_SSHKDF_TYPE_INITIAL_IV_SRV_TO_CLI
The Initial IV from server to client A single char of value 66 (ASCII char ‘B’).

EVP_KDF_SSHKDF_TYPE_ENCRYPTION_KEY_CLI_TO_SRV
The Encryption Key from client to server A single char of value 67 (ASCII char ‘C’).

EVP_KDF_SSHKDF_TYPE_ENCRYPTION_KEY_SRV_TO_CLI
The Encryption Key from server to client A single char of value 68 (ASCII char ‘D’).

EVP_KDF_SSHKDF_TYPE_INTEGRITY_KEY_CLI_TO_SRV
The Integrity Key from client to server A single char of value 69 (ASCII char ‘E’).

EVP_KDF_SSHKDF_TYPE_INTEGRITY_KEY_SRV_TO_CLI
The Integrity Key from client to server A single char of value 70 (ASCII char ‘F’).

“constant” (OSSL_KDF_PARAM_CONSTANT) <octet string>
Sets the constant value in the associated KDF ctx.

“id” (OSSL_KDF_PARAM_PKCS12_ID) <integer>
Sets the intended usage of the output bits in the associated KDF ctx. It is defined as per RFC 7292 section B.3.

RETURN VALUES

OSSL_FUNC_kdf_newctx() and OSSL_FUNC_kdf_dupctx() should return the newly created provider side KDF context, or NULL on failure.

OSSL_FUNC_kdf_derive(), OSSL_FUNC_kdf_get_params(), OSSL_FUNC_kdf_get_ctx_params() and OSSL_FUNC_kdf_set_ctx_params() should return 1 for success or 0 on error.

OSSL_FUNC_kdf_gettable_params(), OSSL_FUNC_kdf_gettable_ctx_params() and OSSL_FUNC_kdf_settable_ctx_params() should return a constant OSSL_PARAM (3) array, or NULL if none is offered.

NOTES

The KDF life-cycle is described in life_cycle-kdf (7). Providers should ensure that the various transitions listed there are supported. At some point the EVP layer will begin enforcing the listed transitions.

SEE ALSO

provider (7), life_cycle-kdf (7), EVP_KDF (3).

HISTORY

The provider KDF interface was introduced in OpenSSL 3.0.

COPYRIGHT

Copyright 2020-2022 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

4 - Linux cli command sem_overview

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command sem_overview and provides detailed information about the command sem_overview, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the sem_overview.

NAME 🖥️ sem_overview 🖥️

overview of POSIX semaphores

DESCRIPTION

POSIX semaphores allow processes and threads to synchronize their actions.

A semaphore is an integer whose value is never allowed to fall below zero. Two operations can be performed on semaphores: increment the semaphore value by one (sem_post(3)); and decrement the semaphore value by one (sem_wait(3)). If the value of a semaphore is currently zero, then a sem_wait(3) operation will block until the value becomes greater than zero.

POSIX semaphores come in two forms: named semaphores and unnamed semaphores.

Named semaphores
A named semaphore is identified by a name of the form /somename; that is, a null-terminated string of up to NAME_MAX*-4* (i.e., 251) characters consisting of an initial slash, followed by one or more characters, none of which are slashes. Two processes can operate on the same named semaphore by passing the same name to sem_open(3).

The sem_open(3) function creates a new named semaphore or opens an existing named semaphore. After the semaphore has been opened, it can be operated on using sem_post(3) and sem_wait(3). When a process has finished using the semaphore, it can use sem_close(3) to close the semaphore. When all processes have finished using the semaphore, it can be removed from the system using sem_unlink(3).

Unnamed semaphores (memory-based semaphores)
An unnamed semaphore does not have a name. Instead the semaphore is placed in a region of memory that is shared between multiple threads (a thread-shared semaphore) or processes (a process-shared semaphore). A thread-shared semaphore is placed in an area of memory shared between the threads of a process, for example, a global variable. A process-shared semaphore must be placed in a shared memory region (e.g., a System V shared memory segment created using shmget(2), or a POSIX shared memory object built created using shm_open(3)).

Before being used, an unnamed semaphore must be initialized using sem_init(3). It can then be operated on using sem_post(3) and sem_wait(3). When the semaphore is no longer required, and before the memory in which it is located is deallocated, the semaphore should be destroyed using sem_destroy(3).

The remainder of this section describes some specific details of the Linux implementation of POSIX semaphores.

Versions

Before Linux 2.6, Linux supported only unnamed, thread-shared semaphores. On a system with Linux 2.6 and a glibc that provides the NPTL threading implementation, a complete implementation of POSIX semaphores is provided.

Persistence

POSIX named semaphores have kernel persistence: if not removed by sem_unlink(3), a semaphore will exist until the system is shut down.

Linking

Programs using the POSIX semaphores API must be compiled with cc -pthread to link against the real-time library, librt.

Accessing named semaphores via the filesystem

On Linux, named semaphores are created in a virtual filesystem, normally mounted under /dev/shm, with names of the form **sem.somename. (This is the reason that semaphore names are limited to NAME_MAX-4 rather than NAME_MAX characters.)

Since Linux 2.6.19, ACLs can be placed on files under this directory, to control object permissions on a per-user and per-group basis.

NOTES

System V semaphores (semget(2), semop(2), etc.) are an older semaphore API. POSIX semaphores provide a simpler, and better designed interface than System V semaphores; on the other hand POSIX semaphores are less widely available (especially on older systems) than System V semaphores.

EXAMPLES

An example of the use of various POSIX semaphore functions is shown in sem_wait(3).

SEE ALSO

sem_close(3), sem_destroy(3), sem_getvalue(3), sem_init(3), sem_open(3), sem_post(3), sem_unlink(3), sem_wait(3), pthreads(7), shm_overview(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

5 - Linux cli command EVP_CIPHER-SEEDssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_CIPHER-SEEDssl and provides detailed information about the command EVP_CIPHER-SEEDssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_CIPHER-SEEDssl.

NAME 🖥️ EVP_CIPHER-SEEDssl 🖥️

SEED - The SEED EVP_CIPHER implementations

DESCRIPTION

Support for SEED symmetric encryption using the EVP_CIPHER API.

Algorithm Names

The following algorithms are available in the legacy provider:

“SEED-CBC” or “SEED”

“SEED-ECB”

“SEED-OFB” or “SEED-OFB128”

“SEED-CFB” or “SEED-CFB128”

Parameters

This implementation supports the parameters described in “PARAMETERS” in EVP_EncryptInit (3).

SEE ALSO

provider-cipher (7), OSSL_PROVIDER-legacy (7)

COPYRIGHT

Copyright 2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

6 - Linux cli command provider-keymgmtssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command provider-keymgmtssl and provides detailed information about the command provider-keymgmtssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the provider-keymgmtssl.

NAME 🖥️ provider-keymgmtssl 🖥️

keymgmt - The KEYMGMT library <-> provider functions

SYNOPSIS

#include <openssl/core_dispatch.h> /* * None of these are actual functions, but are displayed like this for * the function signatures for functions that are offered as function * pointers in OSSL_DISPATCH arrays. */ /* Key object (keydata) creation and destruction */ void *OSSL_FUNC_keymgmt_new(void *provctx); void OSSL_FUNC_keymgmt_free(void *keydata); /* Generation, a more complex constructor */ void *OSSL_FUNC_keymgmt_gen_init(void *provctx, int selection, const OSSL_PARAM params[]); int OSSL_FUNC_keymgmt_gen_set_template(void *genctx, void *template); int OSSL_FUNC_keymgmt_gen_set_params(void *genctx, const OSSL_PARAM params[]); const OSSL_PARAM *OSSL_FUNC_keymgmt_gen_settable_params(void *genctx, void *provctx); void *OSSL_FUNC_keymgmt_gen(void *genctx, OSSL_CALLBACK *cb, void *cbarg); void OSSL_FUNC_keymgmt_gen_cleanup(void *genctx); /* Key loading by object reference, also a constructor */ void *OSSL_FUNC_keymgmt_load(const void *reference, size_t *reference_sz); /* Key object information */ int OSSL_FUNC_keymgmt_get_params(void *keydata, OSSL_PARAM params[]); const OSSL_PARAM *OSSL_FUNC_keymgmt_gettable_params(void *provctx); int OSSL_FUNC_keymgmt_set_params(void *keydata, const OSSL_PARAM params[]); const OSSL_PARAM *OSSL_FUNC_keymgmt_settable_params(void *provctx); /* Key object content checks */ int OSSL_FUNC_keymgmt_has(const void *keydata, int selection); int OSSL_FUNC_keymgmt_match(const void *keydata1, const void *keydata2, int selection); /* Discovery of supported operations */ const char *OSSL_FUNC_keymgmt_query_operation_name(int operation_id); /* Key object import and export functions */ int OSSL_FUNC_keymgmt_import(void *keydata, int selection, const OSSL_PARAM params[]); const OSSL_PARAM *OSSL_FUNC_keymgmt_import_types(int selection); const OSSL_PARAM *OSSL_FUNC_keymgmt_import_types_ex(void *provctx, int selection); int OSSL_FUNC_keymgmt_export(void *keydata, int selection, OSSL_CALLBACK *param_cb, void *cbarg); const OSSL_PARAM *OSSL_FUNC_keymgmt_export_types(int selection); const OSSL_PARAM *OSSL_FUNC_keymgmt_export_types_ex(void *provctx, int selection); /* Key object duplication, a constructor */ void *OSSL_FUNC_keymgmt_dup(const void *keydata_from, int selection); /* Key object validation */ int OSSL_FUNC_keymgmt_validate(const void *keydata, int selection, int checktype);

DESCRIPTION

The KEYMGMT operation doesn’t have much public visibility in OpenSSL libraries, it’s rather an internal operation that’s designed to work in tandem with operations that use private/public key pairs.

Because the KEYMGMT operation shares knowledge with the operations it works with in tandem, they must belong to the same provider. The OpenSSL libraries will ensure that they do.

The primary responsibility of the KEYMGMT operation is to hold the provider side key data for the OpenSSL library EVP_PKEY structure.

All “functions” mentioned here are passed as function pointers between libcrypto and the provider in OSSL_DISPATCH (3) arrays via OSSL_ALGORITHM (3) arrays that are returned by the provider’s provider_query_operation() function (see “Provider Functions” in provider-base (7)).

All these “functions” have a corresponding function type definition named OSSL_FUNC_{name}_fn, and a helper function to retrieve the function pointer from a OSSL_DISPATCH (3) element named OSSL_FUNC_{name}. For example, the “function” OSSL_FUNC_keymgmt_new() has these:

typedef void *(OSSL_FUNC_keymgmt_new_fn)(void *provctx); static ossl_inline OSSL_FUNC_keymgmt_new_fn OSSL_FUNC_keymgmt_new(const OSSL_DISPATCH *opf);

OSSL_DISPATCH (3) arrays are indexed by numbers that are provided as macros in openssl-core_dispatch.h (7), as follows:

OSSL_FUNC_keymgmt_new OSSL_FUNC_KEYMGMT_NEW OSSL_FUNC_keymgmt_free OSSL_FUNC_KEYMGMT_FREE OSSL_FUNC_keymgmt_gen_init OSSL_FUNC_KEYMGMT_GEN_INIT OSSL_FUNC_keymgmt_gen_set_template OSSL_FUNC_KEYMGMT_GEN_SET_TEMPLATE OSSL_FUNC_keymgmt_gen_set_params OSSL_FUNC_KEYMGMT_GEN_SET_PARAMS OSSL_FUNC_keymgmt_gen_settable_params OSSL_FUNC_KEYMGMT_GEN_SETTABLE_PARAMS OSSL_FUNC_keymgmt_gen OSSL_FUNC_KEYMGMT_GEN OSSL_FUNC_keymgmt_gen_cleanup OSSL_FUNC_KEYMGMT_GEN_CLEANUP OSSL_FUNC_keymgmt_load OSSL_FUNC_KEYMGMT_LOAD OSSL_FUNC_keymgmt_get_params OSSL_FUNC_KEYMGMT_GET_PARAMS OSSL_FUNC_keymgmt_gettable_params OSSL_FUNC_KEYMGMT_GETTABLE_PARAMS OSSL_FUNC_keymgmt_set_params OSSL_FUNC_KEYMGMT_SET_PARAMS OSSL_FUNC_keymgmt_settable_params OSSL_FUNC_KEYMGMT_SETTABLE_PARAMS OSSL_FUNC_keymgmt_query_operation_name OSSL_FUNC_KEYMGMT_QUERY_OPERATION_NAME OSSL_FUNC_keymgmt_has OSSL_FUNC_KEYMGMT_HAS OSSL_FUNC_keymgmt_validate OSSL_FUNC_KEYMGMT_VALIDATE OSSL_FUNC_keymgmt_match OSSL_FUNC_KEYMGMT_MATCH OSSL_FUNC_keymgmt_import OSSL_FUNC_KEYMGMT_IMPORT OSSL_FUNC_keymgmt_import_types OSSL_FUNC_KEYMGMT_IMPORT_TYPES OSSL_FUNC_keymgmt_import_types_ex OSSL_FUNC_KEYMGMT_IMPORT_TYPES_EX OSSL_FUNC_keymgmt_export OSSL_FUNC_KEYMGMT_EXPORT OSSL_FUNC_keymgmt_export_types OSSL_FUNC_KEYMGMT_EXPORT_TYPES OSSL_FUNC_keymgmt_export_types_ex OSSL_FUNC_KEYMGMT_EXPORT_TYPES_EX OSSL_FUNC_keymgmt_dup OSSL_FUNC_KEYMGMT_DUP

Key Objects

A key object is a collection of data for an asymmetric key, and is represented as keydata in this manual.

The exact contents of a key object are defined by the provider, and it is assumed that different operations in one and the same provider use the exact same structure to represent this collection of data, so that for example, a key object that has been created using the KEYMGMT interface that we document here can be passed as is to other provider operations, such as OP_signature_sign_init() (see provider-signature (7)).

With some of the KEYMGMT functions, it’s possible to select a specific subset of data to handle, governed by the bits in a selection indicator. The bits are:

OSSL_KEYMGMT_SELECT_PRIVATE_KEY
Indicating that the private key data in a key object should be considered.

OSSL_KEYMGMT_SELECT_PUBLIC_KEY
Indicating that the public key data in a key object should be considered.

OSSL_KEYMGMT_SELECT_DOMAIN_PARAMETERS
Indicating that the domain parameters in a key object should be considered.

OSSL_KEYMGMT_SELECT_OTHER_PARAMETERS
Indicating that other parameters in a key object should be considered. Other parameters are key parameters that don’t fit any other classification. In other words, this particular selector bit works as a last resort bit bucket selector.

Some selector bits have also been combined for easier use:

OSSL_KEYMGMT_SELECT_ALL_PARAMETERS
Indicating that all key object parameters should be considered, regardless of their more granular classification. This is a combination of OSSL_KEYMGMT_SELECT_DOMAIN_PARAMETERS and OSSL_KEYMGMT_SELECT_OTHER_PARAMETERS.

OSSL_KEYMGMT_SELECT_KEYPAIR
Indicating that both the whole key pair in a key object should be considered, i.e. the combination of public and private key. This is a combination of OSSL_KEYMGMT_SELECT_PRIVATE_KEY and OSSL_KEYMGMT_SELECT_PUBLIC_KEY.

OSSL_KEYMGMT_SELECT_ALL
Indicating that everything in a key object should be considered.

The exact interpretation of those bits or how they combine is left to each function where you can specify a selector.

It’s left to the provider implementation to decide what is reasonable to do with regards to received selector bits and how to do it. Among others, an implementation of OSSL_FUNC_keymgmt_match() might opt to not compare the private half if it has compared the public half, since a match of one half implies a match of the other half.

Constructing and Destructing Functions

OSSL_FUNC_keymgmt_new() should create a provider side key object. The provider context provctx is passed and may be incorporated in the key object, but that is not mandatory.

OSSL_FUNC_keymgmt_free() should free the passed keydata.

OSSL_FUNC_keymgmt_gen_init(), OSSL_FUNC_keymgmt_gen_set_template(), OSSL_FUNC_keymgmt_gen_set_params(), OSSL_FUNC_keymgmt_gen_settable_params(), OSSL_FUNC_keymgmt_gen() and OSSL_FUNC_keymgmt_gen_cleanup() work together as a more elaborate context based key object constructor.

OSSL_FUNC_keymgmt_gen_init() should create the key object generation context and initialize it with selections, which will determine what kind of contents the key object to be generated should get. The params, if not NULL, should be set on the context in a manner similar to using OSSL_FUNC_keymgmt_set_params().

OSSL_FUNC_keymgmt_gen_set_template() should add template to the context genctx. The template is assumed to be a key object constructed with the same KEYMGMT, and from which content that the implementation chooses can be used as a template for the key object to be generated. Typically, the generation of a DSA or DH key would get the domain parameters from this template.

OSSL_FUNC_keymgmt_gen_set_params() should set additional parameters from params in the key object generation context genctx.

OSSL_FUNC_keymgmt_gen_settable_params() should return a constant array of descriptor OSSL_PARAM (3), for parameters that OSSL_FUNC_keymgmt_gen_set_params() can handle.

OSSL_FUNC_keymgmt_gen() should perform the key object generation itself, and return the result. The callback cb should be called at regular intervals with indications on how the key object generation progresses.

OSSL_FUNC_keymgmt_gen_cleanup() should clean up and free the key object generation context genctx

OSSL_FUNC_keymgmt_load() creates a provider side key object based on a reference object with a size of reference_sz bytes, that only the provider knows how to interpret, but that may come from other operations. Outside the provider, this reference is simply an array of bytes.

At least one of OSSL_FUNC_keymgmt_new(), OSSL_FUNC_keymgmt_gen() and OSSL_FUNC_keymgmt_load() are mandatory, as well as OSSL_FUNC_keymgmt_free() and OSSL_FUNC_keymgmt_has(). Additionally, if OSSL_FUNC_keymgmt_gen() is present, OSSL_FUNC_keymgmt_gen_init() and OSSL_FUNC_keymgmt_gen_cleanup() must be present as well.

Key Object Information Functions

OSSL_FUNC_keymgmt_get_params() should extract information data associated with the given keydata, see “Common Information Parameters”.

OSSL_FUNC_keymgmt_gettable_params() should return a constant array of descriptor OSSL_PARAM (3), for parameters that OSSL_FUNC_keymgmt_get_params() can handle.

If OSSL_FUNC_keymgmt_gettable_params() is present, OSSL_FUNC_keymgmt_get_params() must also be present, and vice versa.

OSSL_FUNC_keymgmt_set_params() should update information data associated with the given keydata, see “Common Information Parameters”.

OSSL_FUNC_keymgmt_settable_params() should return a constant array of descriptor OSSL_PARAM (3), for parameters that OSSL_FUNC_keymgmt_set_params() can handle.

If OSSL_FUNC_keymgmt_settable_params() is present, OSSL_FUNC_keymgmt_set_params() must also be present, and vice versa.

Key Object Checking Functions

OSSL_FUNC_keymgmt_query_operation_name() should return the name of the supported algorithm for the operation operation_id. This is similar to provider_query_operation() (see provider-base (7)), but only works as an advisory. If this function is not present, or returns NULL, the caller is free to assume that there’s an algorithm from the same provider, of the same name as the one used to fetch the keymgmt and try to use that.

OSSL_FUNC_keymgmt_has() should check whether the given keydata contains the subsets of data indicated by the selector. A combination of several selector bits must consider all those subsets, not just one. An implementation is, however, free to consider an empty subset of data to still be a valid subset. For algorithms where some selection is not meaningful such as OSSL_KEYMGMT_SELECT_DOMAIN_PARAMETERS for RSA keys the function should just return 1 as the selected subset is not really missing in the key.

OSSL_FUNC_keymgmt_validate() should check if the keydata contains valid data subsets indicated by selection. Some combined selections of data subsets may cause validation of the combined data. For example, the combination of OSSL_KEYMGMT_SELECT_PRIVATE_KEY and OSSL_KEYMGMT_SELECT_PUBLIC_KEY (or OSSL_KEYMGMT_SELECT_KEYPAIR for short) is expected to check that the pairwise consistency of keydata is valid. The checktype parameter controls what type of check is performed on the subset of data. Two types of check are defined: OSSL_KEYMGMT_VALIDATE_FULL_CHECK and OSSL_KEYMGMT_VALIDATE_QUICK_CHECK. The interpretation of how much checking is performed in a full check versus a quick check is key type specific. Some providers may have no distinction between a full check and a quick check. For algorithms where some selection is not meaningful such as OSSL_KEYMGMT_SELECT_DOMAIN_PARAMETERS for RSA keys the function should just return 1 as there is nothing to validate for that selection.

OSSL_FUNC_keymgmt_match() should check if the data subset indicated by selection in keydata1 and keydata2 match. It is assumed that the caller has ensured that keydata1 and keydata2 are both owned by the implementation of this function.

Key Object Import, Export and Duplication Functions

OSSL_FUNC_keymgmt_import() should import data indicated by selection into keydata with values taken from the OSSL_PARAM (3) array params.

OSSL_FUNC_keymgmt_export() should extract values indicated by selection from keydata, create an OSSL_PARAM (3) array with them and call param_cb with that array as well as the given cbarg.

OSSL_FUNC_keymgmt_import_types() and OSSL_FUNC_keymgmt_import_types_ex() should return a constant array of descriptor OSSL_PARAM (3) for data indicated by selection, for parameters that OSSL_FUNC_keymgmt_import() can handle. Either OSSL_FUNC_keymgmt_import_types() or OSSL_FUNC_keymgmt_import_types_ex(), must be implemented, if OSSL_FUNC_keymgmt_import_types_ex() is implemented, then it is preferred over OSSL_FUNC_keymgmt_import_types(). Providers that are supposed to be backward compatible with OpenSSL 3.0 or 3.1 must continue to implement OSSL_FUNC_keymgmt_import_types().

OSSL_FUNC_keymgmt_export_types() and OSSL_FUNC_keymgmt_export_types_ex() should return a constant array of descriptor OSSL_PARAM (3) for data indicated by selection, that the OSSL_FUNC_keymgmt_export() callback can expect to receive. Either OSSL_FUNC_keymgmt_export_types() or OSSL_FUNC_keymgmt_export_types_ex(), must be implemented, if OSSL_FUNC_keymgmt_export_types_ex() is implemented, then it is preferred over OSSL_FUNC_keymgmt_export_types(). Providers that are supposed to be backward compatible with OpenSSL 3.0 or 3.1 must continue to implement OSSL_FUNC_keymgmt_export_types().

OSSL_FUNC_keymgmt_dup() should duplicate data subsets indicated by selection or the whole key data keydata_from and create a new provider side key object with the data.

Common Information Parameters

See OSSL_PARAM (3) for further details on the parameters structure.

Common information parameters currently recognised by all built-in keymgmt algorithms are as follows:

“bits” (OSSL_PKEY_PARAM_BITS) <integer>
The value should be the cryptographic length of the cryptosystem to which the key belongs, in bits. The definition of cryptographic length is specific to the key cryptosystem.

“max-size” (OSSL_PKEY_PARAM_MAX_SIZE) <integer>
The value should be the maximum size that a caller should allocate to safely store a signature (called sig in provider-signature (7)), the result of asymmetric encryption / decryption (out in provider-asym_cipher (7), a derived secret (secret in provider-keyexch (7), and similar data). Providers need to implement this parameter in order to properly support various use cases such as CMS signing. Because an EVP_KEYMGMT method is always tightly bound to another method (signature, asymmetric cipher, key exchange, …) and must be of the same provider, this number only needs to be synchronised with the dimensions handled in the rest of the same provider.

“security-bits” (OSSL_PKEY_PARAM_SECURITY_BITS) <integer>
The value should be the number of security bits of the given key. Bits of security is defined in SP800-57.

“mandatory-digest” (OSSL_PKEY_PARAM_MANDATORY_DIGEST) <UTF8 string>
If there is a mandatory digest for performing a signature operation with keys from this keymgmt, this parameter should get its name as value. When EVP_PKEY_get_default_digest_name() queries this parameter and it’s filled in by the implementation, its return value will be 2. If the keymgmt implementation fills in the value "" or "UNDEF", EVP_PKEY_get_default_digest_name (3) will place the string "UNDEF" into its argument mdname. This signifies that no digest should be specified with the corresponding signature operation.

“default-digest” (OSSL_PKEY_PARAM_DEFAULT_DIGEST) <UTF8 string>
If there is a default digest for performing a signature operation with keys from this keymgmt, this parameter should get its name as value. When EVP_PKEY_get_default_digest_name (3) queries this parameter and it’s filled in by the implementation, its return value will be 1. Note that if OSSL_PKEY_PARAM_MANDATORY_DIGEST is responded to as well, EVP_PKEY_get_default_digest_name (3) ignores the response to this parameter. If the keymgmt implementation fills in the value "" or "UNDEF", EVP_PKEY_get_default_digest_name (3) will place the string "UNDEF" into its argument mdname. This signifies that no digest has to be specified with the corresponding signature operation, but may be specified as an option.

RETURN VALUES

OSSL_FUNC_keymgmt_new() and OSSL_FUNC_keymgmt_dup() should return a valid reference to the newly created provider side key object, or NULL on failure.

OSSL_FUNC_keymgmt_import(), OSSL_FUNC_keymgmt_export(), OSSL_FUNC_keymgmt_get_params() and OSSL_FUNC_keymgmt_set_params() should return 1 for success or 0 on error.

OSSL_FUNC_keymgmt_validate() should return 1 on successful validation, or 0 on failure.

OSSL_FUNC_keymgmt_has() should return 1 if all the selected data subsets are contained in the given keydata or 0 otherwise.

OSSL_FUNC_keymgmt_query_operation_name() should return a pointer to a string matching the requested operation, or NULL if the same name used to fetch the keymgmt applies.

OSSL_FUNC_keymgmt_gettable_params() and OSSL_FUNC_keymgmt_settable_params() OSSL_FUNC_keymgmt_import_types(), OSSL_FUNC_keymgmt_import_types_ex(), OSSL_FUNC_keymgmt_export_types(), OSSL_FUNC_keymgmt_export_types_ex() should always return a constant OSSL_PARAM (3) array.

SEE ALSO

EVP_PKEY_get_size (3), EVP_PKEY_get_bits (3), EVP_PKEY_get_security_bits (3), provider (7), EVP_PKEY-X25519 (7), EVP_PKEY-X448 (7), EVP_PKEY-ED25519 (7), EVP_PKEY-ED448 (7), EVP_PKEY-EC (7), EVP_PKEY-RSA (7), EVP_PKEY-DSA (7), EVP_PKEY-DH (7)

HISTORY

The KEYMGMT interface was introduced in OpenSSL 3.0.

Functions OSSL_FUNC_keymgmt_import_types_ex(), and OSSL_FUNC_keymgmt_export_types_ex() were added with OpenSSL 3.2.

COPYRIGHT

Copyright 2019-2024 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

7 - Linux cli command credentials

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command credentials and provides detailed information about the command credentials, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the credentials.

NAME 🖥️ credentials 🖥️

process identifiers

DESCRIPTION

Process ID (PID)

Each process has a unique nonnegative integer identifier that is assigned when the process is created using fork(2). A process can obtain its PID using getpid(2). A PID is represented using the type pid_t (defined in <sys/types.h>).

PIDs are used in a range of system calls to identify the process affected by the call, for example: kill(2), ptrace(2), setpriority(2), setpgid(2), setsid(2), sigqueue(3), and waitpid(2).

A process’s PID is preserved across an execve(2).

Parent process ID (PPID)

A process’s parent process ID identifies the process that created this process using fork(2). A process can obtain its PPID using getppid(2). A PPID is represented using the type pid_t.

A process’s PPID is preserved across an execve(2).

Process group ID and session ID

Each process has a session ID and a process group ID, both represented using the type pid_t. A process can obtain its session ID using getsid(2), and its process group ID using getpgrp(2).

A child created by fork(2) inherits its parent’s session ID and process group ID. A process’s session ID and process group ID are preserved across an execve(2).

Sessions and process groups are abstractions devised to support shell job control. A process group (sometimes called a “job”) is a collection of processes that share the same process group ID; the shell creates a new process group for the process(es) used to execute single command or pipeline (e.g., the two processes created to execute the command “ls | wc” are placed in the same process group). A process’s group membership can be set using setpgid(2). The process whose process ID is the same as its process group ID is the process group leader for that group.

A session is a collection of processes that share the same session ID. All of the members of a process group also have the same session ID (i.e., all of the members of a process group always belong to the same session, so that sessions and process groups form a strict two-level hierarchy of processes.) A new session is created when a process calls setsid(2), which creates a new session whose session ID is the same as the PID of the process that called setsid(2). The creator of the session is called the session leader.

All of the processes in a session share a controlling terminal. The controlling terminal is established when the session leader first opens a terminal (unless the O_NOCTTY flag is specified when calling open(2)). A terminal may be the controlling terminal of at most one session.

At most one of the jobs in a session may be the foreground job; other jobs in the session are background jobs. Only the foreground job may read from the terminal; when a process in the background attempts to read from the terminal, its process group is sent a SIGTTIN signal, which suspends the job. If the TOSTOP flag has been set for the terminal (see termios(3)), then only the foreground job may write to the terminal; writes from background jobs cause a SIGTTOU signal to be generated, which suspends the job. When terminal keys that generate a signal (such as the interrupt key, normally control-C) are pressed, the signal is sent to the processes in the foreground job.

Various system calls and library functions may operate on all members of a process group, including kill(2), killpg(3), getpriority(2), setpriority(2), ioprio_get(2), ioprio_set(2), waitid(2), and waitpid(2). See also the discussion of the F_GETOWN, F_GETOWN_EX, F_SETOWN, and F_SETOWN_EX operations in fcntl(2).

User and group identifiers

Each process has various associated user and group IDs. These IDs are integers, respectively represented using the types uid_t and gid_t (defined in <sys/types.h>).

On Linux, each process has the following user and group identifiers:

  • Real user ID and real group ID. These IDs determine who owns the process. A process can obtain its real user (group) ID using getuid(2) (getgid(2)).

  • Effective user ID and effective group ID. These IDs are used by the kernel to determine the permissions that the process will have when accessing shared resources such as message queues, shared memory, and semaphores. On most UNIX systems, these IDs also determine the permissions when accessing files. However, Linux uses the filesystem IDs described below for this task. A process can obtain its effective user (group) ID using geteuid(2) (getegid(2)).

  • Saved set-user-ID and saved set-group-ID. These IDs are used in set-user-ID and set-group-ID programs to save a copy of the corresponding effective IDs that were set when the program was executed (see execve(2)). A set-user-ID program can assume and drop privileges by switching its effective user ID back and forth between the values in its real user ID and saved set-user-ID. This switching is done via calls to seteuid(2), setreuid(2), or setresuid(2). A set-group-ID program performs the analogous tasks using setegid(2), setregid(2), or setresgid(2). A process can obtain its saved set-user-ID (set-group-ID) using getresuid(2) (getresgid(2)).

  • Filesystem user ID and filesystem group ID (Linux-specific). These IDs, in conjunction with the supplementary group IDs described below, are used to determine permissions for accessing files; see path_resolution(7) for details. Whenever a process’s effective user (group) ID is changed, the kernel also automatically changes the filesystem user (group) ID to the same value. Consequently, the filesystem IDs normally have the same values as the corresponding effective ID, and the semantics for file-permission checks are thus the same on Linux as on other UNIX systems. The filesystem IDs can be made to differ from the effective IDs by calling setfsuid(2) and setfsgid(2).

  • Supplementary group IDs. This is a set of additional group IDs that are used for permission checks when accessing files and other shared resources. Before Linux 2.6.4, a process can be a member of up to 32 supplementary groups; since Linux 2.6.4, a process can be a member of up to 65536 supplementary groups. The call sysconf(_SC_NGROUPS_MAX) can be used to determine the number of supplementary groups of which a process may be a member. A process can obtain its set of supplementary group IDs using getgroups(2).

A child process created by fork(2) inherits copies of its parent’s user and groups IDs. During an execve(2), a process’s real user and group ID and supplementary group IDs are preserved; the effective and saved set IDs may be changed, as described in execve(2).

Aside from the purposes noted above, a process’s user IDs are also employed in a number of other contexts:

  • when determining the permissions for sending signals (see kill(2));

  • when determining the permissions for setting process-scheduling parameters (nice value, real time scheduling policy and priority, CPU affinity, I/O priority) using setpriority(2), sched_setaffinity(2), sched_setscheduler(2), sched_setparam(2), sched_setattr(2), and ioprio_set(2);

  • when checking resource limits (see getrlimit(2));

  • when checking the limit on the number of inotify instances that the process may create (see inotify(7)).

Modifying process user and group IDs

Subject to rules described in the relevant manual pages, a process can use the following APIs to modify its user and group IDs:

setuid(2) (
setgid(2)) Modify the process’s real (and possibly effective and saved-set) user (group) IDs.

seteuid(2) (
setegid(2)) Modify the process’s effective user (group) ID.

setfsuid(2) (
setfsgid(2)) Modify the process’s filesystem user (group) ID.

setreuid(2) (
setregid(2)) Modify the process’s real and effective (and possibly saved-set) user (group) IDs.

setresuid(2) (
setresgid(2)) Modify the process’s real, effective, and saved-set user (group) IDs.

setgroups(2)
Modify the process’s supplementary group list.

Any changes to a process’s effective user (group) ID are automatically carried over to the process’s filesystem user (group) ID. Changes to a process’s effective user or group ID can also affect the process “dumpable” attribute, as described in prctl(2).

Changes to process user and group IDs can affect the capabilities of the process, as described in capabilities(7).

STANDARDS

Process IDs, parent process IDs, process group IDs, and session IDs are specified in POSIX.1. The real, effective, and saved set user and groups IDs, and the supplementary group IDs, are specified in POSIX.1.

The filesystem user and group IDs are a Linux extension.

NOTES

Various fields in the /proc/pid/status file show the process credentials described above. See proc(5) for further information.

The POSIX threads specification requires that credentials are shared by all of the threads in a process. However, at the kernel level, Linux maintains separate user and group credentials for each thread. The NPTL threading implementation does some work to ensure that any change to user or group credentials (e.g., calls to setuid(2), setresuid(2)) is carried through to all of the POSIX threads in a process. See nptl(7) for further details.

SEE ALSO

bash(1), csh(1), groups(1), id(1), newgrp(1), ps(1), runuser(1), setpriv(1), sg(1), su(1), access(2), execve(2), faccessat(2), fork(2), getgroups(2), getpgrp(2), getpid(2), getppid(2), getsid(2), kill(2), setegid(2), seteuid(2), setfsgid(2), setfsuid(2), setgid(2), setgroups(2), setpgid(2), setresgid(2), setresuid(2), setsid(2), setuid(2), waitpid(2), euidaccess(3), initgroups(3), killpg(3), tcgetpgrp(3), tcgetsid(3), tcsetpgrp(3), group(5), passwd(5), shadow(5), capabilities(7), namespaces(7), path_resolution(7), pid_namespaces(7), pthreads(7), signal(7), system_data_types(7), unix(7), user_namespaces(7), sudo(8)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

8 - Linux cli command icmp

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command icmp and provides detailed information about the command icmp, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the icmp.

NAME 🖥️ icmp 🖥️

Linux IPv4 ICMP kernel module.

DESCRIPTION

This kernel protocol module implements the Internet Control Message Protocol defined in RFC 792. It is used to signal error conditions and for diagnosis. The user doesn’t interact directly with this module; instead it communicates with the other protocols in the kernel and these pass the ICMP errors to the application layers. The kernel ICMP module also answers ICMP requests.

A user protocol may receive ICMP packets for all local sockets by opening a raw socket with the protocol IPPROTO_ICMP. See raw(7) for more information. The types of ICMP packets passed to the socket can be filtered using the ICMP_FILTER socket option. ICMP packets are always processed by the kernel too, even when passed to a user socket.

Linux limits the rate of ICMP error packets to each destination. ICMP_REDIRECT and ICMP_DEST_UNREACH are also limited by the destination route of the incoming packets.

/proc interfaces

ICMP supports a set of /proc interfaces to configure some global IP parameters. The parameters can be accessed by reading or writing files in the directory /proc/sys/net/ipv4/. Most of these parameters are rate limitations for specific ICMP types. Linux 2.2 uses a token bucket filter to limit ICMPs. The value is the timeout in jiffies until the token bucket filter is cleared after a burst. A jiffy is a system dependent unit, usually 10ms on i386 and about 1ms on alpha and ia64.

icmp_destunreach_rate (Linux 2.2 to Linux 2.4.9)
Maximum rate to send ICMP Destination Unreachable packets. This limits the rate at which packets are sent to any individual route or destination. The limit does not affect sending of ICMP_FRAG_NEEDED packets needed for path MTU discovery.

icmp_echo_ignore_all (since Linux 2.2)
If this value is nonzero, Linux will ignore all ICMP_ECHO requests.

icmp_echo_ignore_broadcasts (since Linux 2.2)
If this value is nonzero, Linux will ignore all ICMP_ECHO packets sent to broadcast addresses.

icmp_echoreply_rate (Linux 2.2 to Linux 2.4.9)
Maximum rate for sending ICMP_ECHOREPLY packets in response to ICMP_ECHOREQUEST packets.

icmp_errors_use_inbound_ifaddr (Boolean; default: disabled; since Linux 2.6.12)
If disabled, ICMP error messages are sent with the primary address of the exiting interface.

If enabled, the message will be sent with the primary address of the interface that received the packet that caused the ICMP error. This is the behavior that many network administrators will expect from a router. And it can make debugging complicated network layouts much easier.

Note that if no primary address exists for the interface selected, then the primary address of the first non-loopback interface that has one will be used regardless of this setting.

icmp_ignore_bogus_error_responses (Boolean; default: disabled; since Linux 2.2)
Some routers violate RFC1122 by sending bogus responses to broadcast frames. Such violations are normally logged via a kernel warning. If this parameter is enabled, the kernel will not give such warnings, which will avoid log file clutter.

icmp_paramprob_rate (Linux 2.2 to Linux 2.4.9)
Maximum rate for sending ICMP_PARAMETERPROB packets. These packets are sent when a packet arrives with an invalid IP header.

icmp_ratelimit (integer; default: 1000; since Linux 2.4.10)
Limit the maximum rates for sending ICMP packets whose type matches icmp_ratemask (see below) to specific targets. 0 to disable any limiting, otherwise the minimum space between responses in milliseconds.

icmp_ratemask (integer; default: see below; since Linux 2.4.10)
Mask made of ICMP types for which rates are being limited.

Significant bits: IHGFEDCBA9876543210
Default mask: 0000001100000011000 (0x1818)

Bit definitions (see the Linux kernel source file include/linux/icmp.h):

0 Echo Reply
3 Destination Unreachable *
4 Source Quench *
5 Redirect
8 Echo Request
B Time Exceeded *
C Parameter Problem *
D Timestamp Request
E Timestamp Reply
F Info Request
G Info Reply
H Address Mask Request
I Address Mask Reply

The bits marked with an asterisk are rate limited by default (see the default mask above).

icmp_timeexceed_rate (Linux 2.2 to Linux 2.4.9)
Maximum rate for sending ICMP_TIME_EXCEEDED packets. These packets are sent to prevent loops when a packet has crossed too many hops.

ping_group_range (two integers; default: see below; since Linux 2.6.39)
Range of the group IDs (minimum and maximum group IDs, inclusive) that are allowed to create ICMP Echo sockets. The default is “1 0”, which means no group is allowed to create ICMP Echo sockets.

VERSIONS

Support for the ICMP_ADDRESS request was removed in Linux 2.2.

Support for ICMP_SOURCE_QUENCH was removed in Linux 2.2.

NOTES

As many other implementations don’t support IPPROTO_ICMP raw sockets, this feature should not be relied on in portable programs.

ICMP_REDIRECT packets are not sent when Linux is not acting as a router. They are also accepted only from the old gateway defined in the routing table and the redirect routes are expired after some time.

The 64-bit timestamp returned by ICMP_TIMESTAMP is in milliseconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC).

Linux ICMP internally uses a raw socket to send ICMPs. This raw socket may appear in netstat(8) output with a zero inode.

SEE ALSO

ip(7), rdisc(8)

RFC 792 for a description of the ICMP protocol.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

9 - Linux cli command EVP_KEYMGMT-X448ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KEYMGMT-X448ssl and provides detailed information about the command EVP_KEYMGMT-X448ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KEYMGMT-X448ssl.

NAME 🖥️ EVP_KEYMGMT-X448ssl 🖥️

X25519, EVP_PKEY-X448, EVP_PKEY-ED25519, EVP_PKEY-ED448, EVP_KEYMGMT-X25519, EVP_KEYMGMT-X448, EVP_KEYMGMT-ED25519, EVP_KEYMGMT-ED448 - EVP_PKEY X25519, X448, ED25519 and ED448 keytype and algorithm support

DESCRIPTION

The X25519, X448, ED25519 and ED448 keytypes are implemented in OpenSSL’s default and FIPS providers. These implementations support the associated key, containing the public key pub and the private key priv.

Keygen Parameters

“dhkem-ikm” (OSSL_PKEY_PARAM_DHKEM_IKM) <octet string>
DHKEM requires the generation of a keypair using an input key material (seed). Use this to specify the key material used for generation of the private key. This value should not be reused for other purposes. It should have a length of at least 32 for X25519, and 56 for X448. This is only supported by X25519 and X448.

Use EVP_PKEY_CTX_set_params() after calling EVP_PKEY_keygen_init().

Common X25519, X448, ED25519 and ED448 parameters

In addition to the common parameters that all keytypes should support (see “Common parameters” in provider-keymgmt (7)), the implementation of these keytypes support the following.

“group” (OSSL_PKEY_PARAM_GROUP_NAME) <UTF8 string>
This is only supported by X25519 and X448. The group name must be “x25519” or “x448” respectively for those algorithms. This is only present for consistency with other key exchange algorithms and is typically not needed.

“pub” (OSSL_PKEY_PARAM_PUB_KEY) <octet string>
The public key value.

“priv” (OSSL_PKEY_PARAM_PRIV_KEY) <octet string>
The private key value.

“encoded-pub-key” (OSSL_PKEY_PARAM_ENCODED_PUBLIC_KEY) <octet string>
Used for getting and setting the encoding of a public key for the X25519 and X448 key types. Public keys are expected be encoded in a format as defined by RFC7748.

ED25519 and ED448 parameters

“mandatory-digest” (OSSL_PKEY_PARAM_MANDATORY_DIGEST) <UTF8 string>
The empty string, signifying that no digest may be specified.

CONFORMING TO

RFC 8032

RFC 8410

EXAMPLES

An EVP_PKEY context can be obtained by calling:

EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “X25519”, NULL); EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “X448”, NULL); EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “ED25519”, NULL); EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “ED448”, NULL);

An X25519 key can be generated like this:

pkey = EVP_PKEY_Q_keygen(NULL, NULL, “X25519”);

An X448, ED25519, or ED448 key can be generated likewise.

SEE ALSO

EVP_KEYMGMT (3), EVP_PKEY (3), provider-keymgmt (7), EVP_KEYEXCH-X25519 (7), EVP_KEYEXCH-X448 (7), EVP_SIGNATURE-ED25519 (7), EVP_SIGNATURE-ED448 (7)

COPYRIGHT

Copyright 2020-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

10 - Linux cli command DROP_VIEW

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_VIEW and provides detailed information about the command DROP_VIEW, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_VIEW.

NAME 🖥️ DROP_VIEW 🖥️

remove a view

SYNOPSIS

DROP VIEW [ IF EXISTS ] name [, ...] [ CASCADE | RESTRICT ]

DESCRIPTION

DROP VIEW drops an existing view. To execute this command you must be the owner of the view.

PARAMETERS

IF EXISTS

Do not throw an error if the view does not exist. A notice is issued in this case.

name

The name (optionally schema-qualified) of the view to remove.

CASCADE

Automatically drop objects that depend on the view (such as other views), and in turn all objects that depend on those objects (see Section 5.14).

RESTRICT

Refuse to drop the view if any objects depend on it. This is the default.

EXAMPLES

This command will remove the view called kinds:

DROP VIEW kinds;

COMPATIBILITY

This command conforms to the SQL standard, except that the standard only allows one view to be dropped per command, and apart from the IF EXISTS option, which is a PostgreSQL extension.

SEE ALSO

ALTER VIEW (ALTER_VIEW(7)), CREATE VIEW (CREATE_VIEW(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

11 - Linux cli command urn

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command urn and provides detailed information about the command urn, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the urn.

NAME 🖥️ urn 🖥️

uniform resource identifier (URI), including a URL or URN

SYNOPSIS

URI = [ absoluteURI | relativeURI ] [ “#”  fragment ]

absoluteURI = *scheme * “:” ( hierarchical_part | opaque_part )

relativeURI = ( net_path | absolute_path | relative_path ) [ “?”  query ]

scheme = “http” | “ftp” | “gopher” | “mailto” | “news” | “telnet” | “file” | “ftp” | “man” | “info” | “whatis” | “ldap” | “wais” | …

hierarchical_part = ( net_path | absolute_path ) [ “?”  query ]

net_path = “//”  authority [ absolute_path ]

absolute_path = “/”  path_segments

relative_path = relative_segment [ absolute_path ]

DESCRIPTION

A Uniform Resource Identifier (URI) is a short string of characters identifying an abstract or physical resource (for example, a web page). A Uniform Resource Locator (URL) is a URI that identifies a resource through its primary access mechanism (e.g., its network “location”), rather than by name or some other attribute of that resource. A Uniform Resource Name (URN) is a URI that must remain globally unique and persistent even when the resource ceases to exist or becomes unavailable.

URIs are the standard way to name hypertext link destinations for tools such as web browsers. The string “http://www.kernel.org” is a URL (and thus it is also a URI). Many people use the term URL loosely as a synonym for URI (though technically URLs are a subset of URIs).

URIs can be absolute or relative. An absolute identifier refers to a resource independent of context, while a relative identifier refers to a resource by describing the difference from the current context. Within a relative path reference, the complete path segments “.” and “..” have special meanings: “the current hierarchy level” and “the level above this hierarchy level”, respectively, just like they do in UNIX-like systems. A path segment which contains a colon character can’t be used as the first segment of a relative URI path (e.g., “this:that”), because it would be mistaken for a scheme name; precede such segments with ./ (e.g., “./this:that”). Note that descendants of MS-DOS (e.g., Microsoft Windows) replace devicename colons with the vertical bar ("|") in URIs, so “C:” becomes “C|”.

A fragment identifier, if included, refers to a particular named portion (fragment) of a resource; text after a ‘#’ identifies the fragment. A URI beginning with ‘#’ refers to that fragment in the current resource.

Usage

There are many different URI schemes, each with specific additional rules and meanings, but they are intentionally made to be as similar as possible. For example, many URL schemes permit the authority to be the following format, called here an ip_server (square brackets show what’s optional):

*ip_server = *[user [ : password ] @ ] host [ : port]

This format allows you to optionally insert a username, a user plus password, and/or a port number. The host is the name of the host computer, either its name as determined by DNS or an IP address (numbers separated by periods). Thus the URI <http://fred:[email protected]:8080/> logs into a web server on host example.com as fred (using fredpassword) using port 8080. Avoid including a password in a URI if possible because of the many security risks of having a password written down. If the URL supplies a username but no password, and the remote server requests a password, the program interpreting the URL should request one from the user.

Here are some of the most common schemes in use on UNIX-like systems that are understood by many tools. Note that many tools using URIs also have internal schemes or specialized schemes; see those tools’ documentation for information on those schemes.

http - Web (HTTP) server

http://ip_server/path
http://ip_server/path?query

This is a URL accessing a web (HTTP) server. The default port is 80. If the path refers to a directory, the web server will choose what to return; usually if there is a file named “index.html” or “index.htm” its content is returned, otherwise, a list of the files in the current directory (with appropriate links) is generated and returned. An example is <http://lwn.net>.

A query can be given in the archaic “isindex” format, consisting of a word or phrase and not including an equal sign (=). A query can also be in the longer “GET” format, which has one or more query entries of the form key=value separated by the ampersand character (&). Note that key can be repeated more than once, though it’s up to the web server and its application programs to determine if there’s any meaning to that. There is an unfortunate interaction with HTML/XML/SGML and the GET query format; when such URIs with more than one key are embedded in SGML/XML documents (including HTML), the ampersand (&) has to be rewritten as &. Note that not all queries use this format; larger forms may be too long to store as a URI, so they use a different interaction mechanism (called POST) which does not include the data in the URI. See the Common Gateway Interface specification at for more information.

ftp - File Transfer Protocol (FTP)

ftp://ip_server/path

This is a URL accessing a file through the file transfer protocol (FTP). The default port (for control) is 21. If no username is included, the username “anonymous” is supplied, and in that case many clients provide as the password the requestor’s Internet email address. An example is <ftp://ftp.is.co.za/rfc/rfc1808.txt>.

gopher - Gopher server

gopher://ip_server/gophertype selector
gopher://ip_server/gophertype selector%09search
gopher://ip_server/gophertype selector%09search%09gopher+_string

The default gopher port is 70. gophertype is a single-character field to denote the Gopher type of the resource to which the URL refers. The entire path may also be empty, in which case the delimiting “/” is also optional and the gophertype defaults to “1”.

selector is the Gopher selector string. In the Gopher protocol, Gopher selector strings are a sequence of octets which may contain any octets except 09 hexadecimal (US-ASCII HT or tab), 0A hexadecimal (US-ASCII character LF), and 0D (US-ASCII character CR).

mailto - Email address

mailto:email-address

This is an email address, usually of the form name@hostname. See mailaddr(7) for more information on the correct format of an email address. Note that any % character must be rewritten as %25. An example is <mailto:[email protected]>.

news - Newsgroup or News message

news:newsgroup-name
news:message-id

A newsgroup-name is a period-delimited hierarchical name, such as “comp.infosystems.www.misc”. If <newsgroup-name> is “*” (as in <news:*>), it is used to refer to “all available news groups”. An example is <news:comp.lang.ada>.

A message-id corresponds to the Message-ID of IETF RFC 1036, without the enclosing “<” and “>”; it takes the form unique@full_domain_name. A message identifier may be distinguished from a news group name by the presence of the “@” character.

telnet - Telnet login

telnet://ip_server/

The Telnet URL scheme is used to designate interactive text services that may be accessed by the Telnet protocol. The final “/” character may be omitted. The default port is 23. An example is <telnet://melvyl.ucop.edu/>.

file - Normal file

file://ip_server/path_segments
file:path_segments

This represents a file or directory accessible locally. As a special case, ip_server can be the string “localhost” or the empty string; this is interpreted as “the machine from which the URL is being interpreted”. If the path is to a directory, the viewer should display the directory’s contents with links to each containee; not all viewers currently do this. KDE supports generated files through the URL <file:/cgi-bin>. If the given file isn’t found, browser writers may want to try to expand the filename via filename globbing (see glob(7) and glob(3)).

The second format (e.g., <file:/etc/passwd>) is a correct format for referring to a local file. However, older standards did not permit this format, and some programs don’t recognize this as a URI. A more portable syntax is to use an empty string as the server name, for example, <file:///etc/passwd>; this form does the same thing and is easily recognized by pattern matchers and older programs as a URI. Note that if you really mean to say “start from the current location”, don’t specify the scheme at all; use a relative address like <../test.txt>, which has the side-effect of being scheme-independent. An example of this scheme is <file:///etc/passwd>.

man - Man page documentation

man:command-name
man:command-name(section)

This refers to local online manual (man) reference pages. The command name can optionally be followed by a parenthesis and section number; see man(7) for more information on the meaning of the section numbers. This URI scheme is unique to UNIX-like systems (such as Linux) and is not currently registered by the IETF. An example is <man:ls(1)>.

info - Info page documentation

info:virtual-filename
info:virtual-filename#nodename
info:(virtual-filename)
info:(virtual-filename)nodename

This scheme refers to online info reference pages (generated from texinfo files), a documentation format used by programs such as the GNU tools. This URI scheme is unique to UNIX-like systems (such as Linux) and is not currently registered by the IETF. As of this writing, GNOME and KDE differ in their URI syntax and do not accept the other’s syntax. The first two formats are the GNOME format; in nodenames all spaces are written as underscores. The second two formats are the KDE format; spaces in nodenames must be written as spaces, even though this is forbidden by the URI standards. It’s hoped that in the future most tools will understand all of these formats and will always accept underscores for spaces in nodenames. In both GNOME and KDE, if the form without the nodename is used the nodename is assumed to be “Top”. Examples of the GNOME format are <info:gcc> and <info:gcc#G++_and_GCC>. Examples of the KDE format are <info:(gcc)> and <info:(gcc)G++ and GCC>.

whatis - Documentation search

whatis:string

This scheme searches the database of short (one-line) descriptions of commands and returns a list of descriptions containing that string. Only complete word matches are returned. See whatis(1). This URI scheme is unique to UNIX-like systems (such as Linux) and is not currently registered by the IETF.

ghelp - GNOME help documentation

ghelp:name-of-application

This loads GNOME help for the given application. Note that not much documentation currently exists in this format.

ldap - Lightweight Directory Access Protocol

ldap://hostport
ldap://hostport/
ldap://hostport/dn
ldap://hostport/dn?attributes
ldap://hostport/dn?attributes?scope
ldap://hostport/dn?attributes?scope?filter
ldap://hostport/dn?attributes?scope?filter?extensions

This scheme supports queries to the Lightweight Directory Access Protocol (LDAP), a protocol for querying a set of servers for hierarchically organized information (such as people and computing resources). See RFC 2255 for more information on the LDAP URL scheme. The components of this URL are:

hostport
the LDAP server to query, written as a hostname optionally followed by a colon and the port number. The default LDAP port is TCP port 389. If empty, the client determines which the LDAP server to use.

dn
the LDAP Distinguished Name, which identifies the base object of the LDAP search (see RFC 2253 section 3).

attributes
a comma-separated list of attributes to be returned; see RFC 2251 section 4.1.5. If omitted, all attributes should be returned.

scope
specifies the scope of the search, which can be one of “base” (for a base object search), “one” (for a one-level search), or “sub” (for a subtree search). If scope is omitted, “base” is assumed.

filter
specifies the search filter (subset of entries to return). If omitted, all entries should be returned. See RFC 2254 section 4.

extensions
a comma-separated list of type=value pairs, where the =value portion may be omitted for options not requiring it. An extension prefixed with a ‘!’ is critical (must be supported to be valid), otherwise it is noncritical (optional).

LDAP queries are easiest to explain by example. Here’s a query that asks ldap.itd.umich.edu for information about the University of Michigan in the U.S.:

ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US

To just get its postal address attribute, request:

ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US?postalAddress

To ask a host.com at port 6666 for information about the person with common name (cn) “Babs Jensen” at University of Michigan, request:

ldap://host.com:6666/o=University%20of%20Michigan,c=US??sub?(cn=Babs%20Jensen)

wais - Wide Area Information Servers

wais://hostport/database
wais://hostport/database?search
wais://hostport/database/wtype/wpath

This scheme designates a WAIS database, search, or document (see IETF RFC 1625 for more information on WAIS). Hostport is the hostname, optionally followed by a colon and port number (the default port number is 210).

The first form designates a WAIS database for searching. The second form designates a particular search of the WAIS database database. The third form designates a particular document within a WAIS database to be retrieved. wtype is the WAIS designation of the type of the object and wpath is the WAIS document-id.

other schemes

There are many other URI schemes. Most tools that accept URIs support a set of internal URIs (e.g., Mozilla has the about: scheme for internal information, and the GNOME help browser has the toc: scheme for various starting locations). There are many schemes that have been defined but are not as widely used at the current time (e.g., prospero). The nntp: scheme is deprecated in favor of the news: scheme. URNs are to be supported by the urn: scheme, with a hierarchical name space (e.g., urn:ietf:… would identify IETF documents); at this time URNs are not widely implemented. Not all tools support all schemes.

Character encoding

URIs use a limited number of characters so that they can be typed in and used in a variety of situations.

The following characters are reserved, that is, they may appear in a URI but their use is limited to their reserved purpose (conflicting data must be escaped before forming the URI):

; / ? : @ & = + $ ,

Unreserved characters may be included in a URI. Unreserved characters include uppercase and lowercase Latin letters, decimal digits, and the following limited set of punctuation marks and symbols:

- _ . ! ~ * ' ( )

All other characters must be escaped. An escaped octet is encoded as a character triplet, consisting of the percent character “%” followed by the two hexadecimal digits representing the octet code (you can use uppercase or lowercase letters for the hexadecimal digits). For example, a blank space must be escaped as “%20”, a tab character as “%09”, and the “&” as “%26”. Because the percent “%” character always has the reserved purpose of being the escape indicator, it must be escaped as “%25”. It is common practice to escape space characters as the plus symbol (+) in query text; this practice isn’t uniformly defined in the relevant RFCs (which recommend %20 instead) but any tool accepting URIs with query text should be prepared for them. A URI is always shown in its “escaped” form.

Unreserved characters can be escaped without changing the semantics of the URI, but this should not be done unless the URI is being used in a context that does not allow the unescaped character to appear. For example, “%7e” is sometimes used instead of “~” in an HTTP URL path, but the two are equivalent for an HTTP URL.

For URIs which must handle characters outside the US ASCII character set, the HTML 4.01 specification (section B.2) and IETF RFC 3986 (last paragraph of section 2.5) recommend the following approach:

  1. translate the character sequences into UTF-8 (IETF RFC 3629)—see utf-8(7)—and then

  2. use the URI escaping mechanism, that is, use the %HH encoding for unsafe octets.

Writing a URI

When written, URIs should be placed inside double quotes (e.g., “http://www.kernel.org”), enclosed in angle brackets (e.g., <http://lwn.net>), or placed on a line by themselves. A warning for those who use double-quotes: never move extraneous punctuation (such as the period ending a sentence or the comma in a list) inside a URI, since this will change the value of the URI. Instead, use angle brackets instead, or switch to a quoting system that never includes extraneous characters inside quotation marks. This latter system, called the ’new’ or ’logical’ quoting system by “Hart’s Rules” and the “Oxford Dictionary for Writers and Editors”, is preferred practice in Great Britain and in various European languages. Older documents suggested inserting the prefix “URL:” just before the URI, but this form has never caught on.

The URI syntax was designed to be unambiguous. However, as URIs have become commonplace, traditional media (television, radio, newspapers, billboards, etc.) have increasingly used abbreviated URI references consisting of only the authority and path portions of the identified resource (e.g., <www.w3.org/Addressing>). Such references are primarily intended for human interpretation rather than machine, with the assumption that context-based heuristics are sufficient to complete the URI (e.g., hostnames beginning with “www” are likely to have a URI prefix of “http://” and hostnames beginning with “ftp” likely to have a prefix of “ftp://”). Many client implementations heuristically resolve these references. Such heuristics may change over time, particularly when new schemes are introduced. Since an abbreviated URI has the same syntax as a relative URL path, abbreviated URI references cannot be used where relative URIs are permitted, and can be used only when there is no defined base (such as in dialog boxes). Don’t use abbreviated URIs as hypertext links inside a document; use the standard format as described here.

STANDARDS

(IETF RFC 2396), (HTML 4.0).

NOTES

Any tool accepting URIs (e.g., a web browser) on a Linux system should be able to handle (directly or indirectly) all of the schemes described here, including the man: and info: schemes. Handling them by invoking some other program is fine and in fact encouraged.

Technically the fragment isn’t part of the URI.

For information on how to embed URIs (including URLs) in a data format, see documentation on that format. HTML uses the format <A HREF="uri"> text </A>. Texinfo files use the format @uref{uri}. Man and mdoc have the recently added UR macro, or just include the URI in the text (viewers should be able to detect :// as part of a URI).

The GNOME and KDE desktop environments currently vary in the URIs they accept, in particular in their respective help browsers. To list man pages, GNOME uses <toc:man> while KDE uses <man:(index)>, and to list info pages, GNOME uses <toc:info> while KDE uses <info:(dir)> (the author of this man page prefers the KDE approach here, though a more regular format would be even better). In general, KDE uses <file:/cgi-bin/> as a prefix to a set of generated files. KDE prefers documentation in HTML, accessed via the <file:/cgi-bin/helpindex>. GNOME prefers the ghelp scheme to store and find documentation. Neither browser handles file: references to directories at the time of this writing, making it difficult to refer to an entire directory with a browsable URI. As noted above, these environments differ in how they handle the info: scheme, probably the most important variation. It is expected that GNOME and KDE will converge to common URI formats, and a future version of this man page will describe the converged result. Efforts to aid this convergence are encouraged.

Security

A URI does not in itself pose a security threat. There is no general guarantee that a URL, which at one time located a given resource, will continue to do so. Nor is there any guarantee that a URL will not locate a different resource at some later point in time; such a guarantee can be obtained only from the person(s) controlling that namespace and the resource in question.

It is sometimes possible to construct a URL such that an attempt to perform a seemingly harmless operation, such as the retrieval of an entity associated with the resource, will in fact cause a possibly damaging remote operation to occur. The unsafe URL is typically constructed by specifying a port number other than that reserved for the network protocol in question. The client unwittingly contacts a site that is in fact running a different protocol. The content of the URL contains instructions that, when interpreted according to this other protocol, cause an unexpected operation. An example has been the use of a gopher URL to cause an unintended or impersonating message to be sent via a SMTP server.

Caution should be used when using any URL that specifies a port number other than the default for the protocol, especially when it is a number within the reserved space.

Care should be taken when a URI contains escaped delimiters for a given protocol (for example, CR and LF characters for telnet protocols) that these are not unescaped before transmission. This might violate the protocol, but avoids the potential for such characters to be used to simulate an extra operation or parameter in that protocol, which might lead to an unexpected and possibly harmful remote operation to be performed.

It is clearly unwise to use a URI that contains a password which is intended to be secret. In particular, the use of a password within the “userinfo” component of a URI is strongly recommended against except in those rare cases where the “password” parameter is intended to be public.

BUGS

Documentation may be placed in a variety of locations, so there currently isn’t a good URI scheme for general online documentation in arbitrary formats. References of the form <file:///usr/doc/ZZZ> don’t work because different distributions and local installation requirements may place the files in different directories (it may be in /usr/doc, or /usr/local/doc, or /usr/share, or somewhere else). Also, the directory ZZZ usually changes when a version changes (though filename globbing could partially overcome this). Finally, using the file: scheme doesn’t easily support people who dynamically load documentation from the Internet (instead of loading the files onto a local filesystem). A future URI scheme may be added (e.g., “userdoc:”) to permit programs to include cross-references to more detailed documentation without having to know the exact location of that documentation. Alternatively, a future version of the filesystem specification may specify file locations sufficiently so that the file: scheme will be able to locate documentation.

Many programs and file formats don’t include a way to incorporate or implement links using URIs.

Many programs can’t handle all of these different URI formats; there should be a standard mechanism to load an arbitrary URI that automatically detects the users’ environment (e.g., text or graphics, desktop environment, local user preferences, and currently executing tools) and invokes the right tool for any URI.

SEE ALSO

lynx(1), man2html(1), mailaddr(7), utf-8(7)

IETF RFC 2255

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

12 - Linux cli command time

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command time and provides detailed information about the command time, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the time.

NAME 🖥️ time 🖥️

overview of time and timers

DESCRIPTION

Real time and process time

Real time is defined as time measured from some fixed point, either from a standard point in the past (see the description of the Epoch and calendar time below), or from some point (e.g., the start) in the life of a process (elapsed time).

Process time is defined as the amount of CPU time used by a process. This is sometimes divided into user and system components. User CPU time is the time spent executing code in user mode. System CPU time is the time spent by the kernel executing in system mode on behalf of the process (e.g., executing system calls). The time(1) command can be used to determine the amount of CPU time consumed during the execution of a program. A program can determine the amount of CPU time it has consumed using times(2), getrusage(2), or clock(3).

The hardware clock

Most computers have a (battery-powered) hardware clock which the kernel reads at boot time in order to initialize the software clock. For further details, see rtc(4) and hwclock(8).

The software clock, HZ, and jiffies

The accuracy of various system calls that set timeouts, (e.g., select(2), sigtimedwait(2)) and measure CPU time (e.g., getrusage(2)) is limited by the resolution of the software clock, a clock maintained by the kernel which measures time in jiffies. The size of a jiffy is determined by the value of the kernel constant HZ.

The value of HZ varies across kernel versions and hardware platforms. On i386 the situation is as follows: on kernels up to and including Linux 2.4.x, HZ was 100, giving a jiffy value of 0.01 seconds; starting with Linux 2.6.0, HZ was raised to 1000, giving a jiffy of 0.001 seconds. Since Linux 2.6.13, the HZ value is a kernel configuration parameter and can be 100, 250 (the default) or 1000, yielding a jiffies value of, respectively, 0.01, 0.004, or 0.001 seconds. Since Linux 2.6.20, a further frequency is available: 300, a number that divides evenly for the common video frame rates (PAL, 25 Hz; NTSC, 30 Hz).

The times(2) system call is a special case. It reports times with a granularity defined by the kernel constant USER_HZ. User-space applications can determine the value of this constant using sysconf(_SC_CLK_TCK).

System and process clocks; time namespaces

The kernel supports a range of clocks that measure various kinds of elapsed and virtual (i.e., consumed CPU) time. These clocks are described in clock_gettime(2). A few of the clocks are settable using clock_settime(2). The values of certain clocks are virtualized by time namespaces; see time_namespaces(7).

High-resolution timers

Before Linux 2.6.21, the accuracy of timer and sleep system calls (see below) was also limited by the size of the jiffy.

Since Linux 2.6.21, Linux supports high-resolution timers (HRTs), optionally configurable via CONFIG_HIGH_RES_TIMERS. On a system that supports HRTs, the accuracy of sleep and timer system calls is no longer constrained by the jiffy, but instead can be as accurate as the hardware allows (microsecond accuracy is typical of modern hardware). You can determine whether high-resolution timers are supported by checking the resolution returned by a call to clock_getres(2) or looking at the “resolution” entries in /proc/timer_list.

HRTs are not supported on all hardware architectures. (Support is provided on x86, ARM, and PowerPC, among others.)

The Epoch

UNIX systems represent time in seconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC).

A program can determine the calendar time via the clock_gettime(2) CLOCK_REALTIME clock, which returns time (in seconds and nanoseconds) that have elapsed since the Epoch; time(2) provides similar information, but only with accuracy to the nearest second. The system time can be changed using clock_settime(2).

Broken-down time

Certain library functions use a structure of type tm to represent broken-down time, which stores time value separated out into distinct components (year, month, day, hour, minute, second, etc.). This structure is described in tm(3type), which also describes functions that convert between calendar time and broken-down time. Functions for converting between broken-down time and printable string representations of the time are described in ctime(3), strftime(3), and strptime(3).

Sleeping and setting timers

Various system calls and functions allow a program to sleep (suspend execution) for a specified period of time; see nanosleep(2), clock_nanosleep(2), and sleep(3).

Various system calls allow a process to set a timer that expires at some point in the future, and optionally at repeated intervals; see alarm(2), getitimer(2), timerfd_create(2), and timer_create(2).

Timer slack

Since Linux 2.6.28, it is possible to control the “timer slack” value for a thread. The timer slack is the length of time by which the kernel may delay the wake-up of certain system calls that block with a timeout. Permitting this delay allows the kernel to coalesce wake-up events, thus possibly reducing the number of system wake-ups and saving power. For more details, see the description of PR_SET_TIMERSLACK in prctl(2).

SEE ALSO

date(1), time(1), timeout(1), adjtimex(2), alarm(2), clock_gettime(2), clock_nanosleep(2), getitimer(2), getrlimit(2), getrusage(2), gettimeofday(2), nanosleep(2), stat(2), time(2), timer_create(2), timerfd_create(2), times(2), utime(2), adjtime(3), clock(3), clock_getcpuclockid(3), ctime(3), ntp_adjtime(3), ntp_gettime(3), pthread_getcpuclockid(3), sleep(3), strftime(3), strptime(3), timeradd(3), usleep(3), rtc(4), time_namespaces(7), hwclock(8)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

13 - Linux cli command CREATE_TABLE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_TABLE and provides detailed information about the command CREATE_TABLE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_TABLE.

NAME 🖥️ CREATE_TABLE 🖥️

define a new table

SYNOPSIS

CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } | UNLOGGED ] TABLE [ IF NOT EXISTS ] table_name ( [
  { column_name data_type [ STORAGE { PLAIN | EXTERNAL | EXTENDED | MAIN | DEFAULT } ] [ COMPRESSION compression_method ] [ COLLATE collation ] [ column_constraint [ ... ] ]
    | table_constraint
    | LIKE source_table [ like_option ... ] }
    [, ... ]
] )
[ INHERITS ( parent_table [, ... ] ) ]
[ PARTITION BY { RANGE | LIST | HASH } ( { column_name | ( expression ) } [ COLLATE collation ] [ opclass ] [, ... ] ) ]
[ USING method ]
[ WITH ( storage_parameter [= value] [, ... ] ) | WITHOUT OIDS ]
[ ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP } ]
[ TABLESPACE tablespace_name ]

CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } | UNLOGGED ] TABLE [ IF NOT EXISTS ] table_name
    OF type_name [ (
  { column_name [ WITH OPTIONS ] [ column_constraint [ ... ] ]
    | table_constraint }
    [, ... ]
) ]
[ PARTITION BY { RANGE | LIST | HASH } ( { column_name | ( expression ) } [ COLLATE collation ] [ opclass ] [, ... ] ) ]
[ USING method ]
[ WITH ( storage_parameter [= value] [, ... ] ) | WITHOUT OIDS ]
[ ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP } ]
[ TABLESPACE tablespace_name ]

CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } | UNLOGGED ] TABLE [ IF NOT EXISTS ] table_name
    PARTITION OF parent_table [ (
  { column_name [ WITH OPTIONS ] [ column_constraint [ ... ] ]
    | table_constraint }
    [, ... ]
) ] { FOR VALUES partition_bound_spec | DEFAULT }
[ PARTITION BY { RANGE | LIST | HASH } ( { column_name | ( expression ) } [ COLLATE collation ] [ opclass ] [, ... ] ) ]
[ USING method ]
[ WITH ( storage_parameter [= value] [, ... ] ) | WITHOUT OIDS ]
[ ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP } ]
[ TABLESPACE tablespace_name ]

where column_constraint is:

[ CONSTRAINT constraint_name ]
{ NOT NULL |
  NULL |
  CHECK ( expression ) [ NO INHERIT ] |
  DEFAULT default_expr |
  GENERATED ALWAYS AS ( generation_expr ) STORED |
  GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY [ ( sequence_options ) ] |
  UNIQUE [ NULLS [ NOT ] DISTINCT ] index_parameters |
  PRIMARY KEY index_parameters |
  REFERENCES reftable [ ( refcolumn ) ] [ MATCH FULL | MATCH PARTIAL | MATCH SIMPLE ]
    [ ON DELETE referential_action ] [ ON UPDATE referential_action ] }
[ DEFERRABLE | NOT DEFERRABLE ] [ INITIALLY DEFERRED | INITIALLY IMMEDIATE ]

and table_constraint is:

[ CONSTRAINT constraint_name ]
{ CHECK ( expression ) [ NO INHERIT ] |
  UNIQUE [ NULLS [ NOT ] DISTINCT ] ( column_name [, ... ] ) index_parameters |
  PRIMARY KEY ( column_name [, ... ] ) index_parameters |
  EXCLUDE [ USING index_method ] ( exclude_element WITH operator [, ... ] ) index_parameters [ WHERE ( predicate ) ] |
  FOREIGN KEY ( column_name [, ... ] ) REFERENCES reftable [ ( refcolumn [, ... ] ) ]
    [ MATCH FULL | MATCH PARTIAL | MATCH SIMPLE ] [ ON DELETE referential_action ] [ ON UPDATE referential_action ] }
[ DEFERRABLE | NOT DEFERRABLE ] [ INITIALLY DEFERRED | INITIALLY IMMEDIATE ]

and like_option is:

{ INCLUDING | EXCLUDING } { COMMENTS | COMPRESSION | CONSTRAINTS | DEFAULTS | GENERATED | IDENTITY | INDEXES | STATISTICS | STORAGE | ALL }

and partition_bound_spec is:

IN ( partition_bound_expr [, ...] ) |
FROM ( { partition_bound_expr | MINVALUE | MAXVALUE } [, ...] )
  TO ( { partition_bound_expr | MINVALUE | MAXVALUE } [, ...] ) |
WITH ( MODULUS numeric_literal, REMAINDER numeric_literal )

index_parameters in UNIQUE, PRIMARY KEY, and EXCLUDE constraints are:

[ INCLUDE ( column_name [, ... ] ) ]
[ WITH ( storage_parameter [= value] [, ... ] ) ]
[ USING INDEX TABLESPACE tablespace_name ]

exclude_element in an EXCLUDE constraint is:

{ column_name | ( expression ) } [ COLLATE collation ] [ opclass [ ( opclass_parameter = value [, ... ] ) ] ] [ ASC | DESC ] [ NULLS { FIRST | LAST } ]

referential_action in a FOREIGN KEY/REFERENCES constraint is:

{ NO ACTION | RESTRICT | CASCADE | SET NULL [ ( column_name [, ... ] ) ] | SET DEFAULT [ ( column_name [, ... ] ) ] }

DESCRIPTION

CREATE TABLE will create a new, initially empty table in the current database. The table will be owned by the user issuing the command.

If a schema name is given (for example, CREATE TABLE myschema.mytable …) then the table is created in the specified schema. Otherwise it is created in the current schema. Temporary tables exist in a special schema, so a schema name cannot be given when creating a temporary table. The name of the table must be distinct from the name of any other relation (table, sequence, index, view, materialized view, or foreign table) in the same schema.

CREATE TABLE also automatically creates a data type that represents the composite type corresponding to one row of the table. Therefore, tables cannot have the same name as any existing data type in the same schema.

The optional constraint clauses specify constraints (tests) that new or updated rows must satisfy for an insert or update operation to succeed. A constraint is an SQL object that helps define the set of valid values in the table in various ways.

There are two ways to define constraints: table constraints and column constraints. A column constraint is defined as part of a column definition. A table constraint definition is not tied to a particular column, and it can encompass more than one column. Every column constraint can also be written as a table constraint; a column constraint is only a notational convenience for use when the constraint only affects one column.

To be able to create a table, you must have USAGE privilege on all column types or the type in the OF clause, respectively.

PARAMETERS

TEMPORARY or TEMP

If specified, the table is created as a temporary table. Temporary tables are automatically dropped at the end of a session, or optionally at the end of the current transaction (see ON COMMIT below). The default search_path includes the temporary schema first and so identically named existing permanent tables are not chosen for new plans while the temporary table exists, unless they are referenced with schema-qualified names. Any indexes created on a temporary table are automatically temporary as well.

The autovacuum daemon cannot access and therefore cannot vacuum or analyze temporary tables. For this reason, appropriate vacuum and analyze operations should be performed via session SQL commands. For example, if a temporary table is going to be used in complex queries, it is wise to run ANALYZE on the temporary table after it is populated.

Optionally, GLOBAL or LOCAL can be written before TEMPORARY or TEMP. This presently makes no difference in PostgreSQL and is deprecated; see Compatibility below.

UNLOGGED

If specified, the table is created as an unlogged table. Data written to unlogged tables is not written to the write-ahead log (see Chapter 30), which makes them considerably faster than ordinary tables. However, they are not crash-safe: an unlogged table is automatically truncated after a crash or unclean shutdown. The contents of an unlogged table are also not replicated to standby servers. Any indexes created on an unlogged table are automatically unlogged as well.

If this is specified, any sequences created together with the unlogged table (for identity or serial columns) are also created as unlogged.

IF NOT EXISTS

Do not throw an error if a relation with the same name already exists. A notice is issued in this case. Note that there is no guarantee that the existing relation is anything like the one that would have been created.

table_name

The name (optionally schema-qualified) of the table to be created.

OF type_name

Creates a typed table, which takes its structure from the specified composite type (name optionally schema-qualified). A typed table is tied to its type; for example the table will be dropped if the type is dropped (with DROP TYPE … CASCADE).

When a typed table is created, then the data types of the columns are determined by the underlying composite type and are not specified by the CREATE TABLE command. But the CREATE TABLE command can add defaults and constraints to the table and can specify storage parameters.

column_name

The name of a column to be created in the new table.

data_type

The data type of the column. This can include array specifiers. For more information on the data types supported by PostgreSQL, refer to Chapter 8.

COLLATE collation

The COLLATE clause assigns a collation to the column (which must be of a collatable data type). If not specified, the column data types default collation is used.

STORAGE { PLAIN | EXTERNAL | EXTENDED | MAIN | DEFAULT }

This form sets the storage mode for the column. This controls whether this column is held inline or in a secondary TOAST table, and whether the data should be compressed or not. PLAIN must be used for fixed-length values such as integer and is inline, uncompressed. MAIN is for inline, compressible data. EXTERNAL is for external, uncompressed data, and EXTENDED is for external, compressed data. Writing DEFAULT sets the storage mode to the default mode for the columns data type. EXTENDED is the default for most data types that support non-PLAIN storage. Use of EXTERNAL will make substring operations on very large text and bytea values run faster, at the penalty of increased storage space. See Section 73.2 for more information.

COMPRESSION compression_method

The COMPRESSION clause sets the compression method for the column. Compression is supported only for variable-width data types, and is used only when the columns storage mode is main or extended. (See ALTER TABLE (ALTER_TABLE(7)) for information on column storage modes.) Setting this property for a partitioned table has no direct effect, because such tables have no storage of their own, but the configured value will be inherited by newly-created partitions. The supported compression methods are pglz and lz4. (lz4 is available only if –with-lz4 was used when building PostgreSQL.) In addition, compression_method can be default to explicitly specify the default behavior, which is to consult the default_toast_compression setting at the time of data insertion to determine the method to use.

INHERITS ( parent_table [, … ] )

The optional INHERITS clause specifies a list of tables from which the new table automatically inherits all columns. Parent tables can be plain tables or foreign tables.

Use of INHERITS creates a persistent relationship between the new child table and its parent table(s). Schema modifications to the parent(s) normally propagate to children as well, and by default the data of the child table is included in scans of the parent(s).

If the same column name exists in more than one parent table, an error is reported unless the data types of the columns match in each of the parent tables. If there is no conflict, then the duplicate columns are merged to form a single column in the new table. If the column name list of the new table contains a column name that is also inherited, the data type must likewise match the inherited column(s), and the column definitions are merged into one. If the new table explicitly specifies a default value for the column, this default overrides any defaults from inherited declarations of the column. Otherwise, any parents that specify default values for the column must all specify the same default, or an error will be reported.

CHECK constraints are merged in essentially the same way as columns: if multiple parent tables and/or the new table definition contain identically-named CHECK constraints, these constraints must all have the same check expression, or an error will be reported. Constraints having the same name and expression will be merged into one copy. A constraint marked NO INHERIT in a parent will not be considered. Notice that an unnamed CHECK constraint in the new table will never be merged, since a unique name will always be chosen for it.

Column STORAGE settings are also copied from parent tables.

If a column in the parent table is an identity column, that property is not inherited. A column in the child table can be declared identity column if desired.

PARTITION BY { RANGE | LIST | HASH } ( { column_name | ( expression ) } [ opclass ] [, …] )

The optional PARTITION BY clause specifies a strategy of partitioning the table. The table thus created is called a partitioned table. The parenthesized list of columns or expressions forms the partition key for the table. When using range or hash partitioning, the partition key can include multiple columns or expressions (up to 32, but this limit can be altered when building PostgreSQL), but for list partitioning, the partition key must consist of a single column or expression.

Range and list partitioning require a btree operator class, while hash partitioning requires a hash operator class. If no operator class is specified explicitly, the default operator class of the appropriate type will be used; if no default operator class exists, an error will be raised. When hash partitioning is used, the operator class used must implement support function 2 (see Section 38.16.3 for details).

A partitioned table is divided into sub-tables (called partitions), which are created using separate CREATE TABLE commands. The partitioned table is itself empty. A data row inserted into the table is routed to a partition based on the value of columns or expressions in the partition key. If no existing partition matches the values in the new row, an error will be reported.

Partitioned tables do not support EXCLUDE constraints; however, you can define these constraints on individual partitions.

See Section 5.11 for more discussion on table partitioning.

PARTITION OF parent_table { FOR VALUES partition_bound_spec | DEFAULT }

Creates the table as a partition of the specified parent table. The table can be created either as a partition for specific values using FOR VALUES or as a default partition using DEFAULT. Any indexes, constraints and user-defined row-level triggers that exist in the parent table are cloned on the new partition.

The partition_bound_spec must correspond to the partitioning method and partition key of the parent table, and must not overlap with any existing partition of that parent. The form with IN is used for list partitioning, the form with FROM and TO is used for range partitioning, and the form with WITH is used for hash partitioning.

partition_bound_expr is any variable-free expression (subqueries, window functions, aggregate functions, and set-returning functions are not allowed). Its data type must match the data type of the corresponding partition key column. The expression is evaluated once at table creation time, so it can even contain volatile expressions such as CURRENT_TIMESTAMP.

When creating a list partition, NULL can be specified to signify that the partition allows the partition key column to be null. However, there cannot be more than one such list partition for a given parent table. NULL cannot be specified for range partitions.

When creating a range partition, the lower bound specified with FROM is an inclusive bound, whereas the upper bound specified with TO is an exclusive bound. That is, the values specified in the FROM list are valid values of the corresponding partition key columns for this partition, whereas those in the TO list are not. Note that this statement must be understood according to the rules of row-wise comparison (Section 9.24.5). For example, given PARTITION BY RANGE (x,y), a partition bound FROM (1, 2) TO (3, 4) allows x=1 with any y>=2, x=2 with any non-null y, and x=3 with any y<4.

The special values MINVALUE and MAXVALUE may be used when creating a range partition to indicate that there is no lower or upper bound on the columns value. For example, a partition defined using FROM (MINVALUE) TO (10) allows any values less than 10, and a partition defined using FROM (10) TO (MAXVALUE) allows any values greater than or equal to 10.

When creating a range partition involving more than one column, it can also make sense to use MAXVALUE as part of the lower bound, and MINVALUE as part of the upper bound. For example, a partition defined using FROM (0, MAXVALUE) TO (10, MAXVALUE) allows any rows where the first partition key column is greater than 0 and less than or equal to 10. Similarly, a partition defined using FROM (a, MINVALUE) TO (b, MINVALUE) allows any rows where the first partition key column starts with “a”.

Note that if MINVALUE or MAXVALUE is used for one column of a partitioning bound, the same value must be used for all subsequent columns. For example, (10, MINVALUE, 0) is not a valid bound; you should write (10, MINVALUE, MINVALUE).

Also note that some element types, such as timestamp, have a notion of “infinity”, which is just another value that can be stored. This is different from MINVALUE and MAXVALUE, which are not real values that can be stored, but rather they are ways of saying that the value is unbounded. MAXVALUE can be thought of as being greater than any other value, including “infinity” and MINVALUE as being less than any other value, including “minus infinity”. Thus the range FROM (infinity) TO (MAXVALUE) is not an empty range; it allows precisely one value to be stored — “infinity”.

If DEFAULT is specified, the table will be created as the default partition of the parent table. This option is not available for hash-partitioned tables. A partition key value not fitting into any other partition of the given parent will be routed to the default partition.

When a table has an existing DEFAULT partition and a new partition is added to it, the default partition must be scanned to verify that it does not contain any rows which properly belong in the new partition. If the default partition contains a large number of rows, this may be slow. The scan will be skipped if the default partition is a foreign table or if it has a constraint which proves that it cannot contain rows which should be placed in the new partition.

When creating a hash partition, a modulus and remainder must be specified. The modulus must be a positive integer, and the remainder must be a non-negative integer less than the modulus. Typically, when initially setting up a hash-partitioned table, you should choose a modulus equal to the number of partitions and assign every table the same modulus and a different remainder (see examples, below). However, it is not required that every partition have the same modulus, only that every modulus which occurs among the partitions of a hash-partitioned table is a factor of the next larger modulus. This allows the number of partitions to be increased incrementally without needing to move all the data at once. For example, suppose you have a hash-partitioned table with 8 partitions, each of which has modulus 8, but find it necessary to increase the number of partitions to 16. You can detach one of the modulus-8 partitions, create two new modulus-16 partitions covering the same portion of the key space (one with a remainder equal to the remainder of the detached partition, and the other with a remainder equal to that value plus 8), and repopulate them with data. You can then repeat this – perhaps at a later time – for each modulus-8 partition until none remain. While this may still involve a large amount of data movement at each step, it is still better than having to create a whole new table and move all the data at once.

A partition must have the same column names and types as the partitioned table to which it belongs. Modifications to the column names or types of a partitioned table will automatically propagate to all partitions. CHECK constraints will be inherited automatically by every partition, but an individual partition may specify additional CHECK constraints; additional constraints with the same name and condition as in the parent will be merged with the parent constraint. Defaults may be specified separately for each partition. But note that a partitions default value is not applied when inserting a tuple through a partitioned table.

Rows inserted into a partitioned table will be automatically routed to the correct partition. If no suitable partition exists, an error will occur.

Operations such as TRUNCATE which normally affect a table and all of its inheritance children will cascade to all partitions, but may also be performed on an individual partition.

Note that creating a partition using PARTITION OF requires taking an ACCESS EXCLUSIVE lock on the parent partitioned table. Likewise, dropping a partition with DROP TABLE requires taking an ACCESS EXCLUSIVE lock on the parent table. It is possible to use ALTER TABLE ATTACH/DETACH PARTITION to perform these operations with a weaker lock, thus reducing interference with concurrent operations on the partitioned table.

LIKE source_table [ like_option … ]

The LIKE clause specifies a table from which the new table automatically copies all column names, their data types, and their not-null constraints.

Unlike INHERITS, the new table and original table are completely decoupled after creation is complete. Changes to the original table will not be applied to the new table, and it is not possible to include data of the new table in scans of the original table.

Also unlike INHERITS, columns and constraints copied by LIKE are not merged with similarly named columns and constraints. If the same name is specified explicitly or in another LIKE clause, an error is signaled.

The optional like_option clauses specify which additional properties of the original table to copy. Specifying INCLUDING copies the property, specifying EXCLUDING omits the property. EXCLUDING is the default. If multiple specifications are made for the same kind of object, the last one is used. The available options are:

INCLUDING COMMENTS

Comments for the copied columns, constraints, and indexes will be copied. The default behavior is to exclude comments, resulting in the copied columns and constraints in the new table having no comments.

INCLUDING COMPRESSION

Compression method of the columns will be copied. The default behavior is to exclude compression methods, resulting in columns having the default compression method.

INCLUDING CONSTRAINTS

CHECK constraints will be copied. No distinction is made between column constraints and table constraints. Not-null constraints are always copied to the new table.

INCLUDING DEFAULTS

Default expressions for the copied column definitions will be copied. Otherwise, default expressions are not copied, resulting in the copied columns in the new table having null defaults. Note that copying defaults that call database-modification functions, such as nextval, may create a functional linkage between the original and new tables.

INCLUDING GENERATED

Any generation expressions of copied column definitions will be copied. By default, new columns will be regular base columns.

INCLUDING IDENTITY

Any identity specifications of copied column definitions will be copied. A new sequence is created for each identity column of the new table, separate from the sequences associated with the old table.

INCLUDING INDEXES

Indexes, PRIMARY KEY, UNIQUE, and EXCLUDE constraints on the original table will be created on the new table. Names for the new indexes and constraints are chosen according to the default rules, regardless of how the originals were named. (This behavior avoids possible duplicate-name failures for the new indexes.)

INCLUDING STATISTICS

Extended statistics are copied to the new table.

INCLUDING STORAGE

STORAGE settings for the copied column definitions will be copied. The default behavior is to exclude STORAGE settings, resulting in the copied columns in the new table having type-specific default settings. For more on STORAGE settings, see Section 73.2.

INCLUDING ALL

INCLUDING ALL is an abbreviated form selecting all the available individual options. (It could be useful to write individual EXCLUDING clauses after INCLUDING ALL to select all but some specific options.)

The LIKE clause can also be used to copy column definitions from views, foreign tables, or composite types. Inapplicable options (e.g., INCLUDING INDEXES from a view) are ignored.

CONSTRAINT constraint_name

An optional name for a column or table constraint. If the constraint is violated, the constraint name is present in error messages, so constraint names like col must be positive can be used to communicate helpful constraint information to client applications. (Double-quotes are needed to specify constraint names that contain spaces.) If a constraint name is not specified, the system generates a name.

NOT NULL

The column is not allowed to contain null values.

NULL

The column is allowed to contain null values. This is the default.

This clause is only provided for compatibility with non-standard SQL databases. Its use is discouraged in new applications.

CHECK ( expression ) [ NO INHERIT ]

The CHECK clause specifies an expression producing a Boolean result which new or updated rows must satisfy for an insert or update operation to succeed. Expressions evaluating to TRUE or UNKNOWN succeed. Should any row of an insert or update operation produce a FALSE result, an error exception is raised and the insert or update does not alter the database. A check constraint specified as a column constraint should reference that columns value only, while an expression appearing in a table constraint can reference multiple columns.

Currently, CHECK expressions cannot contain subqueries nor refer to variables other than columns of the current row (see Section 5.4.1). The system column tableoid may be referenced, but not any other system column.

A constraint marked with NO INHERIT will not propagate to child tables.

When a table has multiple CHECK constraints, they will be tested for each row in alphabetical order by name, after checking NOT NULL constraints. (PostgreSQL versions before 9.5 did not honor any particular firing order for CHECK constraints.)

DEFAULT default_expr

The DEFAULT clause assigns a default data value for the column whose column definition it appears within. The value is any variable-free expression (in particular, cross-references to other columns in the current table are not allowed). Subqueries are not allowed either. The data type of the default expression must match the data type of the column.

The default expression will be used in any insert operation that does not specify a value for the column. If there is no default for a column, then the default is null.

GENERATED ALWAYS AS ( generation_expr ) STORED

This clause creates the column as a generated column. The column cannot be written to, and when read the result of the specified expression will be returned.

The keyword STORED is required to signify that the column will be computed on write and will be stored on disk.

The generation expression can refer to other columns in the table, but not other generated columns. Any functions and operators used must be immutable. References to other tables are not allowed.

GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY [ ( sequence_options ) ]

This clause creates the column as an identity column. It will have an implicit sequence attached to it and the column in new rows will automatically have values from the sequence assigned to it. Such a column is implicitly NOT NULL.

The clauses ALWAYS and BY DEFAULT determine how explicitly user-specified values are handled in INSERT and UPDATE commands.

In an INSERT command, if ALWAYS is selected, a user-specified value is only accepted if the INSERT statement specifies OVERRIDING SYSTEM VALUE. If BY DEFAULT is selected, then the user-specified value takes precedence. See INSERT(7) for details. (In the COPY command, user-specified values are always used regardless of this setting.)

In an UPDATE command, if ALWAYS is selected, any update of the column to any value other than DEFAULT will be rejected. If BY DEFAULT is selected, the column can be updated normally. (There is no OVERRIDING clause for the UPDATE command.)

The optional sequence_options clause can be used to override the options of the sequence. See CREATE SEQUENCE (CREATE_SEQUENCE(7)) for details.

UNIQUE [ NULLS [ NOT ] DISTINCT ] (column constraint)
UNIQUE [ NULLS [ NOT ] DISTINCT ] ( column_name [, … ] ) [ INCLUDE ( column_name [, …]) ] (table constraint)

The UNIQUE constraint specifies that a group of one or more columns of a table can contain only unique values. The behavior of a unique table constraint is the same as that of a unique column constraint, with the additional capability to span multiple columns. The constraint therefore enforces that any two rows must differ in at least one of these columns.

For the purpose of a unique constraint, null values are not considered equal, unless NULLS NOT DISTINCT is specified.

Each unique constraint should name a set of columns that is different from the set of columns named by any other unique or primary key constraint defined for the table. (Otherwise, redundant unique constraints will be discarded.)

When establishing a unique constraint for a multi-level partition hierarchy, all the columns in the partition key of the target partitioned table, as well as those of all its descendant partitioned tables, must be included in the constraint definition.

Adding a unique constraint will automatically create a unique btree index on the column or group of columns used in the constraint.

The optional INCLUDE clause adds to that index one or more columns that are simply “payload”: uniqueness is not enforced on them, and the index cannot be searched on the basis of those columns. However they can be retrieved by an index-only scan. Note that although the constraint is not enforced on included columns, it still depends on them. Consequently, some operations on such columns (e.g., DROP COLUMN) can cause cascaded constraint and index deletion.

PRIMARY KEY (column constraint)
PRIMARY KEY ( column_name [, … ] ) [ INCLUDE ( column_name [, …]) ] (table constraint)

The PRIMARY KEY constraint specifies that a column or columns of a table can contain only unique (non-duplicate), nonnull values. Only one primary key can be specified for a table, whether as a column constraint or a table constraint.

The primary key constraint should name a set of columns that is different from the set of columns named by any unique constraint defined for the same table. (Otherwise, the unique constraint is redundant and will be discarded.)

PRIMARY KEY enforces the same data constraints as a combination of UNIQUE and NOT NULL. However, identifying a set of columns as the primary key also provides metadata about the design of the schema, since a primary key implies that other tables can rely on this set of columns as a unique identifier for rows.

When placed on a partitioned table, PRIMARY KEY constraints share the restrictions previously described for UNIQUE constraints.

Adding a PRIMARY KEY constraint will automatically create a unique btree index on the column or group of columns used in the constraint.

The optional INCLUDE clause adds to that index one or more columns that are simply “payload”: uniqueness is not enforced on them, and the index cannot be searched on the basis of those columns. However they can be retrieved by an index-only scan. Note that although the constraint is not enforced on included columns, it still depends on them. Consequently, some operations on such columns (e.g., DROP COLUMN) can cause cascaded constraint and index deletion.

EXCLUDE [ USING index_method ] ( exclude_element WITH operator [, … ] ) index_parameters [ WHERE ( predicate ) ]

The EXCLUDE clause defines an exclusion constraint, which guarantees that if any two rows are compared on the specified column(s) or expression(s) using the specified operator(s), not all of these comparisons will return TRUE. If all of the specified operators test for equality, this is equivalent to a UNIQUE constraint, although an ordinary unique constraint will be faster. However, exclusion constraints can specify constraints that are more general than simple equality. For example, you can specify a constraint that no two rows in the table contain overlapping circles (see Section 8.8) by using the && operator. The operator(s) are required to be commutative.

Exclusion constraints are implemented using an index, so each specified operator must be associated with an appropriate operator class (see Section 11.10) for the index access method index_method. Each exclude_element defines a column of the index, so it can optionally specify a collation, an operator class, operator class parameters, and/or ordering options; these are described fully under CREATE INDEX (CREATE_INDEX(7)).

The access method must support amgettuple (see Chapter 64); at present this means GIN cannot be used. Although its allowed, there is little point in using B-tree or hash indexes with an exclusion constraint, because this does nothing that an ordinary unique constraint doesnt do better. So in practice the access method will always be GiST or SP-GiST.

The predicate allows you to specify an exclusion constraint on a subset of the table; internally this creates a partial index. Note that parentheses are required around the predicate.

REFERENCES reftable [ ( refcolumn ) ] [ MATCH matchtype ] [ ON DELETE referential_action ] [ ON UPDATE referential_action ] (column constraint)
FOREIGN KEY ( column_name [, … ] ) REFERENCES reftable [ ( refcolumn [, … ] ) ] [ MATCH matchtype ] [ ON DELETE referential_action ] [ ON UPDATE referential_action ] (table constraint)

These clauses specify a foreign key constraint, which requires that a group of one or more columns of the new table must only contain values that match values in the referenced column(s) of some row of the referenced table. If the refcolumn list is omitted, the primary key of the reftable is used. Otherwise, the refcolumn list must refer to the columns of a non-deferrable unique or primary key constraint or be the columns of a non-partial unique index. The user must have REFERENCES permission on the referenced table (either the whole table, or the specific referenced columns). The addition of a foreign key constraint requires a SHARE ROW EXCLUSIVE lock on the referenced table. Note that foreign key constraints cannot be defined between temporary tables and permanent tables.

A value inserted into the referencing column(s) is matched against the values of the referenced table and referenced columns using the given match type. There are three match types: MATCH FULL, MATCH PARTIAL, and MATCH SIMPLE (which is the default). MATCH FULL will not allow one column of a multicolumn foreign key to be null unless all foreign key columns are null; if they are all null, the row is not required to have a match in the referenced table. MATCH SIMPLE allows any of the foreign key columns to be null; if any of them are null, the row is not required to have a match in the referenced table. MATCH PARTIAL is not yet implemented. (Of course, NOT NULL constraints can be applied to the referencing column(s) to prevent these cases from arising.)

In addition, when the data in the referenced columns is changed, certain actions are performed on the data in this tables columns. The ON DELETE clause specifies the action to perform when a referenced row in the referenced table is being deleted. Likewise, the ON UPDATE clause specifies the action to perform when a referenced column in the referenced table is being updated to a new value. If the row is updated, but the referenced column is not actually changed, no action is done. Referential actions other than the NO ACTION check cannot be deferred, even if the constraint is declared deferrable. There are the following possible actions for each clause:

NO ACTION

Produce an error indicating that the deletion or update would create a foreign key constraint violation. If the constraint is deferred, this error will be produced at constraint check time if there still exist any referencing rows. This is the default action.

RESTRICT

Produce an error indicating that the deletion or update would create a foreign key constraint violation. This is the same as NO ACTION except that the check is not deferrable.

CASCADE

Delete any rows referencing the deleted row, or update the values of the referencing column(s) to the new values of the referenced columns, respectively.

SET NULL [ ( column_name [, … ] ) ]

Set all of the referencing columns, or a specified subset of the referencing columns, to null. A subset of columns can only be specified for ON DELETE actions.

SET DEFAULT [ ( column_name [, … ] ) ]

Set all of the referencing columns, or a specified subset of the referencing columns, to their default values. A subset of columns can only be specified for ON DELETE actions. (There must be a row in the referenced table matching the default values, if they are not null, or the operation will fail.)

If the referenced column(s) are changed frequently, it might be wise to add an index to the referencing column(s) so that referential actions associated with the foreign key constraint can be performed more efficiently.

DEFERRABLE
NOT DEFERRABLE

This controls whether the constraint can be deferred. A constraint that is not deferrable will be checked immediately after every command. Checking of constraints that are deferrable can be postponed until the end of the transaction (using the SET CONSTRAINTS command). NOT DEFERRABLE is the default. Currently, only UNIQUE, PRIMARY KEY, EXCLUDE, and REFERENCES (foreign key) constraints accept this clause. NOT NULL and CHECK constraints are not deferrable. Note that deferrable constraints cannot be used as conflict arbitrators in an INSERT statement that includes an ON CONFLICT DO UPDATE clause.

INITIALLY IMMEDIATE
INITIALLY DEFERRED

If a constraint is deferrable, this clause specifies the default time to check the constraint. If the constraint is INITIALLY IMMEDIATE, it is checked after each statement. This is the default. If the constraint is INITIALLY DEFERRED, it is checked only at the end of the transaction. The constraint check time can be altered with the SET CONSTRAINTS command.

USING method

This optional clause specifies the table access method to use to store the contents for the new table; the method needs be an access method of type TABLE. See Chapter 63 for more information. If this option is not specified, the default table access method is chosen for the new table. See default_table_access_method for more information.

WITH ( storage_parameter [= value] [, … ] )

This clause specifies optional storage parameters for a table or index; see Storage Parameters below for more information. For backward-compatibility the WITH clause for a table can also include OIDS=FALSE to specify that rows of the new table should not contain OIDs (object identifiers), OIDS=TRUE is not supported anymore.

WITHOUT OIDS

This is backward-compatible syntax for declaring a table WITHOUT OIDS, creating a table WITH OIDS is not supported anymore.

ON COMMIT

The behavior of temporary tables at the end of a transaction block can be controlled using ON COMMIT. The three options are:

PRESERVE ROWS

No special action is taken at the ends of transactions. This is the default behavior.

DELETE ROWS

All rows in the temporary table will be deleted at the end of each transaction block. Essentially, an automatic TRUNCATE is done at each commit. When used on a partitioned table, this is not cascaded to its partitions.

DROP

The temporary table will be dropped at the end of the current transaction block. When used on a partitioned table, this action drops its partitions and when used on tables with inheritance children, it drops the dependent children.

TABLESPACE tablespace_name

The tablespace_name is the name of the tablespace in which the new table is to be created. If not specified, default_tablespace is consulted, or temp_tablespaces if the table is temporary. For partitioned tables, since no storage is required for the table itself, the tablespace specified overrides default_tablespace as the default tablespace to use for any newly created partitions when no other tablespace is explicitly specified.

USING INDEX TABLESPACE tablespace_name

This clause allows selection of the tablespace in which the index associated with a UNIQUE, PRIMARY KEY, or EXCLUDE constraint will be created. If not specified, default_tablespace is consulted, or temp_tablespaces if the table is temporary.

Storage Parameters

The WITH clause can specify storage parameters for tables, and for indexes associated with a UNIQUE, PRIMARY KEY, or EXCLUDE constraint. Storage parameters for indexes are documented in CREATE INDEX (CREATE_INDEX(7)). The storage parameters currently available for tables are listed below. For many of these parameters, as shown, there is an additional parameter with the same name prefixed with toast., which controls the behavior of the tables secondary TOAST table, if any (see Section 73.2 for more information about TOAST). If a table parameter value is set and the equivalent toast. parameter is not, the TOAST table will use the tables parameter value. Specifying these parameters for partitioned tables is not supported, but you may specify them for individual leaf partitions.

fillfactor (integer)

The fillfactor for a table is a percentage between 10 and 100. 100 (complete packing) is the default. When a smaller fillfactor is specified, INSERT operations pack table pages only to the indicated percentage; the remaining space on each page is reserved for updating rows on that page. This gives UPDATE a chance to place the updated copy of a row on the same page as the original, which is more efficient than placing it on a different page, and makes heap-only tuple updates more likely. For a table whose entries are never updated, complete packing is the best choice, but in heavily updated tables smaller fillfactors are appropriate. This parameter cannot be set for TOAST tables.

toast_tuple_target (integer)

The toast_tuple_target specifies the minimum tuple length required before we try to compress and/or move long column values into TOAST tables, and is also the target length we try to reduce the length below once toasting begins. This affects columns marked as External (for move), Main (for compression), or Extended (for both) and applies only to new tuples. There is no effect on existing rows. By default this parameter is set to allow at least 4 tuples per block, which with the default block size will be 2040 bytes. Valid values are between 128 bytes and the (block size - header), by default 8160 bytes. Changing this value may not be useful for very short or very long rows. Note that the default setting is often close to optimal, and it is possible that setting this parameter could have negative effects in some cases. This parameter cannot be set for TOAST tables.

parallel_workers (integer)

This sets the number of workers that should be used to assist a parallel scan of this table. If not set, the system will determine a value based on the relation size. The actual number of workers chosen by the planner or by utility statements that use parallel scans may be less, for example due to the setting of max_worker_processes.

autovacuum_enabled, toast.autovacuum_enabled (boolean)

Enables or disables the autovacuum daemon for a particular table. If true, the autovacuum daemon will perform automatic VACUUM and/or ANALYZE operations on this table following the rules discussed in Section 25.1.6. If false, this table will not be autovacuumed, except to prevent transaction ID wraparound. See Section 25.1.5 for more about wraparound prevention. Note that the autovacuum daemon does not run at all (except to prevent transaction ID wraparound) if the autovacuum parameter is false; setting individual tables storage parameters does not override that. Therefore there is seldom much point in explicitly setting this storage parameter to true, only to false.

vacuum_index_cleanup, toast.vacuum_index_cleanup (enum)

Forces or disables index cleanup when VACUUM is run on this table. The default value is AUTO. With OFF, index cleanup is disabled, with ON it is enabled, and with AUTO a decision is made dynamically, each time VACUUM runs. The dynamic behavior allows VACUUM to avoid needlessly scanning indexes to remove very few dead tuples. Forcibly disabling all index cleanup can speed up VACUUM very significantly, but may also lead to severely bloated indexes if table modifications are frequent. The INDEX_CLEANUP parameter of VACUUM, if specified, overrides the value of this option.

vacuum_truncate, toast.vacuum_truncate (boolean)

Enables or disables vacuum to try to truncate off any empty pages at the end of this table. The default value is true. If true, VACUUM and autovacuum do the truncation and the disk space for the truncated pages is returned to the operating system. Note that the truncation requires ACCESS EXCLUSIVE lock on the table. The TRUNCATE parameter of VACUUM, if specified, overrides the value of this option.

autovacuum_vacuum_threshold, toast.autovacuum_vacuum_threshold (integer)

Per-table value for autovacuum_vacuum_threshold parameter.

autovacuum_vacuum_scale_factor, toast.autovacuum_vacuum_scale_factor (floating point)

Per-table value for autovacuum_vacuum_scale_factor parameter.

autovacuum_vacuum_insert_threshold, toast.autovacuum_vacuum_insert_threshold (integer)

Per-table value for autovacuum_vacuum_insert_threshold parameter. The special value of -1 may be used to disable insert vacuums on the table.

autovacuum_vacuum_insert_scale_factor, toast.autovacuum_vacuum_insert_scale_factor (floating point)

Per-table value for autovacuum_vacuum_insert_scale_factor parameter.

autovacuum_analyze_threshold (integer)

Per-table value for autovacuum_analyze_threshold parameter.

autovacuum_analyze_scale_factor (floating point)

Per-table value for autovacuum_analyze_scale_factor parameter.

autovacuum_vacuum_cost_delay, toast.autovacuum_vacuum_cost_delay (floating point)

Per-table value for autovacuum_vacuum_cost_delay parameter.

autovacuum_vacuum_cost_limit, toast.autovacuum_vacuum_cost_limit (integer)

Per-table value for autovacuum_vacuum_cost_limit parameter.

autovacuum_freeze_min_age, toast.autovacuum_freeze_min_age (integer)

Per-table value for vacuum_freeze_min_age parameter. Note that autovacuum will ignore per-table autovacuum_freeze_min_age parameters that are larger than half the system-wide autovacuum_freeze_max_age setting.

autovacuum_freeze_max_age, toast.autovacuum_freeze_max_age (integer)

Per-table value for autovacuum_freeze_max_age parameter. Note that autovacuum will ignore per-table autovacuum_freeze_max_age parameters that are larger than the system-wide setting (it can only be set smaller).

autovacuum_freeze_table_age, toast.autovacuum_freeze_table_age (integer)

Per-table value for vacuum_freeze_table_age parameter.

autovacuum_multixact_freeze_min_age, toast.autovacuum_multixact_freeze_min_age (integer)

Per-table value for vacuum_multixact_freeze_min_age parameter. Note that autovacuum will ignore per-table autovacuum_multixact_freeze_min_age parameters that are larger than half the system-wide autovacuum_multixact_freeze_max_age setting.

autovacuum_multixact_freeze_max_age, toast.autovacuum_multixact_freeze_max_age (integer)

Per-table value for autovacuum_multixact_freeze_max_age parameter. Note that autovacuum will ignore per-table autovacuum_multixact_freeze_max_age parameters that are larger than the system-wide setting (it can only be set smaller).

autovacuum_multixact_freeze_table_age, toast.autovacuum_multixact_freeze_table_age (integer)

Per-table value for vacuum_multixact_freeze_table_age parameter.

log_autovacuum_min_duration, toast.log_autovacuum_min_duration (integer)

Per-table value for log_autovacuum_min_duration parameter.

user_catalog_table (boolean)

Declare the table as an additional catalog table for purposes of logical replication. See Section 49.6.2 for details. This parameter cannot be set for TOAST tables.

NOTES

PostgreSQL automatically creates an index for each unique constraint and primary key constraint to enforce uniqueness. Thus, it is not necessary to create an index explicitly for primary key columns. (See CREATE INDEX (CREATE_INDEX(7)) for more information.)

Unique constraints and primary keys are not inherited in the current implementation. This makes the combination of inheritance and unique constraints rather dysfunctional.

A table cannot have more than 1600 columns. (In practice, the effective limit is usually lower because of tuple-length constraints.)

EXAMPLES

Create table films and table distributors:

CREATE TABLE films ( code char(5) CONSTRAINT firstkey PRIMARY KEY, title: varchar(40) NOT NULL, did integer NOT NULL, date_prod date, kind varchar(10), len interval hour to minute );

CREATE TABLE distributors (
     did    integer PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY,
     name   varchar(40) NOT NULL CHECK (name <> )
);

Create a table with a 2-dimensional array:

CREATE TABLE array_int ( vector int[][] );

Define a unique table constraint for the table films. Unique table constraints can be defined on one or more columns of the table:

CREATE TABLE films ( code char(5), title: varchar(40), did integer, date_prod date, kind varchar(10), len interval hour to minute, CONSTRAINT production UNIQUE(date_prod) );

Define a check column constraint:

CREATE TABLE distributors ( did integer CHECK (did > 100), name varchar(40) );

Define a check table constraint:

CREATE TABLE distributors ( did integer, name varchar(40), CONSTRAINT con1 CHECK (did > 100 AND name <> ) );

Define a primary key table constraint for the table films:

CREATE TABLE films ( code char(5), title: varchar(40), did integer, date_prod date, kind varchar(10), len interval hour to minute, CONSTRAINT code_title PRIMARY KEY(code,title) );

Define a primary key constraint for table distributors. The following two examples are equivalent, the first using the table constraint syntax, the second the column constraint syntax:

CREATE TABLE distributors ( did integer, name varchar(40), PRIMARY KEY(did) );

CREATE TABLE distributors (
    did     integer PRIMARY KEY,
    name    varchar(40)
);

Assign a literal constant default value for the column name, arrange for the default value of column did to be generated by selecting the next value of a sequence object, and make the default value of modtime be the time at which the row is inserted:

CREATE TABLE distributors ( name varchar(40) DEFAULT Luso Films, did integer DEFAULT nextval(distributors_serial), modtime timestamp DEFAULT current_timestamp );

Define two NOT NULL column constraints on the table distributors, one of which is explicitly given a name:

CREATE TABLE distributors ( did integer CONSTRAINT no_null NOT NULL, name varchar(40) NOT NULL );

Define a unique constraint for the name column:

CREATE TABLE distributors ( did integer, name varchar(40) UNIQUE );

The same, specified as a table constraint:

CREATE TABLE distributors ( did integer, name varchar(40), UNIQUE(name) );

Create the same table, specifying 70% fill factor for both the table and its unique index:

CREATE TABLE distributors ( did integer, name varchar(40), UNIQUE(name) WITH (fillfactor=70) ) WITH (fillfactor=70);

Create table circles with an exclusion constraint that prevents any two circles from overlapping:

CREATE TABLE circles ( c circle, EXCLUDE USING gist (c WITH &&) );

Create table cinemas in tablespace diskvol1:

CREATE TABLE cinemas ( id serial, name text, location text ) TABLESPACE diskvol1;

Create a composite type and a typed table:

CREATE TYPE employee_type AS (name text, salary numeric);

CREATE TABLE employees OF employee_type (
    PRIMARY KEY (name),
    salary WITH OPTIONS DEFAULT 1000
);

Create a range partitioned table:

CREATE TABLE measurement ( logdate date not null, peaktemp int, unitsales int ) PARTITION BY RANGE (logdate);

Create a range partitioned table with multiple columns in the partition key:

CREATE TABLE measurement_year_month ( logdate date not null, peaktemp int, unitsales int ) PARTITION BY RANGE (EXTRACT(YEAR FROM logdate), EXTRACT(MONTH FROM logdate));

Create a list partitioned table:

CREATE TABLE cities ( city_id bigserial not null, name text not null, population bigint ) PARTITION BY LIST (left(lower(name), 1));

Create a hash partitioned table:

CREATE TABLE orders ( order_id bigint not null, cust_id bigint not null, status text ) PARTITION BY HASH (order_id);

Create partition of a range partitioned table:

CREATE TABLE measurement_y2016m07 PARTITION OF measurement ( unitsales DEFAULT 0 ) FOR VALUES FROM (2016-07-01) TO (2016-08-01);

Create a few partitions of a range partitioned table with multiple columns in the partition key:

CREATE TABLE measurement_ym_older PARTITION OF measurement_year_month FOR VALUES FROM (MINVALUE, MINVALUE) TO (2016, 11);

CREATE TABLE measurement_ym_y2016m11
    PARTITION OF measurement_year_month
    FOR VALUES FROM (2016, 11) TO (2016, 12);

CREATE TABLE measurement_ym_y2016m12
    PARTITION OF measurement_year_month
    FOR VALUES FROM (2016, 12) TO (2017, 01);

CREATE TABLE measurement_ym_y2017m01
    PARTITION OF measurement_year_month
    FOR VALUES FROM (2017, 01) TO (2017, 02);

Create partition of a list partitioned table:

CREATE TABLE cities_ab PARTITION OF cities ( CONSTRAINT city_id_nonzero CHECK (city_id != 0) ) FOR VALUES IN (a, b);

Create partition of a list partitioned table that is itself further partitioned and then add a partition to it:

CREATE TABLE cities_ab PARTITION OF cities ( CONSTRAINT city_id_nonzero CHECK (city_id != 0) ) FOR VALUES IN (a, b) PARTITION BY RANGE (population);

CREATE TABLE cities_ab_10000_to_100000
    PARTITION OF cities_ab FOR VALUES FROM (10000) TO (100000);

Create partitions of a hash partitioned table:

CREATE TABLE orders_p1 PARTITION OF orders FOR VALUES WITH (MODULUS 4, REMAINDER 0); CREATE TABLE orders_p2 PARTITION OF orders FOR VALUES WITH (MODULUS 4, REMAINDER 1); CREATE TABLE orders_p3 PARTITION OF orders FOR VALUES WITH (MODULUS 4, REMAINDER 2); CREATE TABLE orders_p4 PARTITION OF orders FOR VALUES WITH (MODULUS 4, REMAINDER 3);

Create a default partition:

CREATE TABLE cities_partdef PARTITION OF cities DEFAULT;

COMPATIBILITY

The CREATE TABLE command conforms to the SQL standard, with exceptions listed below.

Temporary Tables

Although the syntax of CREATE TEMPORARY TABLE resembles that of the SQL standard, the effect is not the same. In the standard, temporary tables are defined just once and automatically exist (starting with empty contents) in every session that needs them. PostgreSQL instead requires each session to issue its own CREATE TEMPORARY TABLE command for each temporary table to be used. This allows different sessions to use the same temporary table name for different purposes, whereas the standards approach constrains all instances of a given temporary table name to have the same table structure.

The standards definition of the behavior of temporary tables is widely ignored. PostgreSQLs behavior on this point is similar to that of several other SQL databases.

The SQL standard also distinguishes between global and local temporary tables, where a local temporary table has a separate set of contents for each SQL module within each session, though its definition is still shared across sessions. Since PostgreSQL does not support SQL modules, this distinction is not relevant in PostgreSQL.

For compatibilitys sake, PostgreSQL will accept the GLOBAL and LOCAL keywords in a temporary table declaration, but they currently have no effect. Use of these keywords is discouraged, since future versions of PostgreSQL might adopt a more standard-compliant interpretation of their meaning.

The ON COMMIT clause for temporary tables also resembles the SQL standard, but has some differences. If the ON COMMIT clause is omitted, SQL specifies that the default behavior is ON COMMIT DELETE ROWS. However, the default behavior in PostgreSQL is ON COMMIT PRESERVE ROWS. The ON COMMIT DROP option does not exist in SQL.

Non-Deferred Uniqueness Constraints

When a UNIQUE or PRIMARY KEY constraint is not deferrable, PostgreSQL checks for uniqueness immediately whenever a row is inserted or modified. The SQL standard says that uniqueness should be enforced only at the end of the statement; this makes a difference when, for example, a single command updates multiple key values. To obtain standard-compliant behavior, declare the constraint as DEFERRABLE but not deferred (i.e., INITIALLY IMMEDIATE). Be aware that this can be significantly slower than immediate uniqueness checking.

Column Check Constraints

The SQL standard says that CHECK column constraints can only refer to the column they apply to; only CHECK table constraints can refer to multiple columns. PostgreSQL does not enforce this restriction; it treats column and table check constraints alike.

EXCLUDE Constraint

The EXCLUDE constraint type is a PostgreSQL extension.

Foreign Key Constraints

The ability to specify column lists in the foreign key actions SET DEFAULT and SET NULL is a PostgreSQL extension.

It is a PostgreSQL extension that a foreign key constraint may reference columns of a unique index instead of columns of a primary key or unique constraint.

NULL “Constraint”

The NULL “constraint” (actually a non-constraint) is a PostgreSQL extension to the SQL standard that is included for compatibility with some other database systems (and for symmetry with the NOT NULL constraint). Since it is the default for any column, its presence is simply noise.

Constraint Naming

The SQL standard says that table and domain constraints must have names that are unique across the schema containing the table or domain. PostgreSQL is laxer: it only requires constraint names to be unique across the constraints attached to a particular table or domain. However, this extra freedom does not exist for index-based constraints (UNIQUE, PRIMARY KEY, and EXCLUDE constraints), because the associated index is named the same as the constraint, and index names must be unique across all relations within the same schema.

Currently, PostgreSQL does not record names for NOT NULL constraints at all, so they are not subject to the uniqueness restriction. This might change in a future release.

Inheritance

Multiple inheritance via the INHERITS clause is a PostgreSQL language extension. SQL:1999 and later define single inheritance using a different syntax and different semantics. SQL:1999-style inheritance is not yet supported by PostgreSQL.

Zero-Column Tables

PostgreSQL allows a table of no columns to be created (for example, CREATE TABLE foo();). This is an extension from the SQL standard, which does not allow zero-column tables. Zero-column tables are not in themselves very useful, but disallowing them creates odd special cases for ALTER TABLE DROP COLUMN, so it seems cleaner to ignore this spec restriction.

Multiple Identity Columns

PostgreSQL allows a table to have more than one identity column. The standard specifies that a table can have at most one identity column. This is relaxed mainly to give more flexibility for doing schema changes or migrations. Note that the INSERT command supports only one override clause that applies to the entire statement, so having multiple identity columns with different behaviors is not well supported.

Generated Columns

The option STORED is not standard but is also used by other SQL implementations. The SQL standard does not specify the storage of generated columns.

LIKE Clause

While a LIKE clause exists in the SQL standard, many of the options that PostgreSQL accepts for it are not in the standard, and some of the standards options are not implemented by PostgreSQL.

WITH Clause

The WITH clause is a PostgreSQL extension; storage parameters are not in the standard.

Tablespaces

The PostgreSQL concept of tablespaces is not part of the standard. Hence, the clauses TABLESPACE and USING INDEX TABLESPACE are extensions.

Typed Tables

Typed tables implement a subset of the SQL standard. According to the standard, a typed table has columns corresponding to the underlying composite type as well as one other column that is the “self-referencing column”. PostgreSQL does not support self-referencing columns explicitly.

PARTITION BY Clause

The PARTITION BY clause is a PostgreSQL extension.

PARTITION OF Clause

The PARTITION OF clause is a PostgreSQL extension.

SEE ALSO

ALTER TABLE (ALTER_TABLE(7)), DROP TABLE (DROP_TABLE(7)), CREATE TABLE AS (CREATE_TABLE_AS(7)), CREATE TABLESPACE (CREATE_TABLESPACE(7)), CREATE TYPE (CREATE_TYPE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

14 - Linux cli command postgresql-common

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command postgresql-common and provides detailed information about the command postgresql-common, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the postgresql-common.

NAME 🖥️ postgresql-common 🖥️

wrapper for PostgreSQL client commands

SYNOPSIS

client-program [–cluster version/cluster] […]

(client-program: psql, createdb, dropuser, and all other client programs installed in /usr/lib/postgresql/version/bin).

DESCRIPTION

This program is run only as a link to names which correspond to PostgreSQL programs in /usr/lib/postgresql/version/bin. It determines the configured cluster and database for the user and calls the appropriate version of the desired program to connect to that cluster and database, supplying any specified options to that command.

The target cluster is selected by the following means, in descending order of precedence:

  • explicit specification with the –host option

  • explicit specification with the –cluster option

  • if the PGHOST environment variable is set, no further cluster selection is performed. The default PostgreSQL version and port number (from the command line, the environment variable PGPORT, or default 5432) will be used.

  • explicit specification with the PGCLUSTER environment variable

  • if a port is given (either via -p, –port, or PGPORT), and no host is given, the local cluster matching that port number is used

  • matching entry in ~/.postgresqlrc (see postgresqlrc (5)), if that file exists

  • matching entry in /etc/postgresql-common/user_clusters (see user_clusters (5)), if that file exists

  • If only one cluster exists on the local system, that one will be selected.

  • If several clusters exist on the local system, the one listening on the default port 5432 will be selected.

If none of these rules match, pg_wrapper does not set any environment variables and the program called will likely error out with a message like “could not connect to server: Connection refused”.

For psql, pg_archivecleanup, and pg_isready, pg_wrapper will always use the binary from the newest PostgreSQL version installed, as these are downwards compatible. If the cluster version is older than 9.2, the newest considered binary version is 14.

Note that pg_wrapper needs to be able to read the server config to get the port number to connect to. If a non-standard port is configured in a place that pg_wrapper cannot read, connecting will fail. This particularly holds if the port was configured via ALTER SYSTEM in postgresql.auto.conf and pg_wrapper is invoked as any user other than postgres and root.

OPTIONS

–cluster version/cluster

–cluster version/host:[port]

cluster is either the name of a cluster on the local system, or takes the form host:port for a remote cluster. If port is left empty (i. e. you just specify host:), it defaults to 5432.

ENVIRONMENT

PGCLUSTER
If $PGCLUSTER is set, its value (of the form version/cluster) specifies the desired cluster, similar to the –cluster option. However, if –cluster is specified, it overrides the value of $PGCLUSTER.

PG_CLUSTER_CONF_ROOT
This specifies an alternative base directory for cluster configurations. This is usually /etc/postgresql/, but for testing/development purposes you can change this to point to e. g. your home directory, so that you can use the postgresql-common tools without root privileges.

PGSYSCONFDIR
This is the location of PostgreSQL’s and postgresql-common’s global configuration (e. g. pg_service.conf, user_clusters (5)). The default is /etc/postgresql-common/.

FILES

/etc/postgresql-common/user_clusters
stores the default cluster and database for users and groups as set by the administrators.

$HOME/.postgresqlrc
stores defaults set by the user himself.

SEE ALSO

user_clusters (5), postgresqlrc (5)

AUTHOR

Martin Pitt <[email protected]>

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

15 - Linux cli command ALTER_SCHEMA

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_SCHEMA and provides detailed information about the command ALTER_SCHEMA, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_SCHEMA.

NAME 🖥️ ALTER_SCHEMA 🖥️

change the definition of a schema

SYNOPSIS

ALTER SCHEMA name RENAME TO new_name
ALTER SCHEMA name OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }

DESCRIPTION

ALTER SCHEMA changes the definition of a schema.

You must own the schema to use ALTER SCHEMA. To rename a schema you must also have the CREATE privilege for the database. To alter the owner, you must be able to SET ROLE to the new owning role, and that role must have the CREATE privilege for the database. (Note that superusers have all these privileges automatically.)

PARAMETERS

name

The name of an existing schema.

new_name

The new name of the schema. The new name cannot begin with pg_, as such names are reserved for system schemas.

new_owner

The new owner of the schema.

COMPATIBILITY

There is no ALTER SCHEMA statement in the SQL standard.

SEE ALSO

CREATE SCHEMA (CREATE_SCHEMA(7)), DROP SCHEMA (DROP_SCHEMA(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

16 - Linux cli command EVP_MD-commonssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_MD-commonssl and provides detailed information about the command EVP_MD-commonssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_MD-commonssl.

NAME 🖥️ EVP_MD-commonssl 🖥️

common - The OpenSSL EVP_MD implementations, common things

DESCRIPTION

All the OpenSSL EVP_MD implementations understand the following OSSL_PARAM (3) entries that are gettable with EVP_MD_get_params (3), as well as these:

“blocksize” (OSSL_DIGEST_PARAM_BLOCK_SIZE) <unsigned integer>
The digest block size. The length of the “blocksize” parameter should not exceed that of a size_t. This value can also be retrieved with EVP_MD_get_block_size (3).

“size” (OSSL_DIGEST_PARAM_SIZE) <unsigned integer>
The digest output size. The length of the “size” parameter should not exceed that of a size_t. This value can also be retrieved with EVP_MD_get_size (3).

“flags” (OSSL_DIGEST_PARAM_FLAGS) <unsigned integer>
Diverse flags that describe exceptional behaviour for the digest. These flags are described in “DESCRIPTION” in EVP_MD_meth_set_flags (3). The length of the “flags” parameter should equal that of an unsigned long int. This value can also be retrieved with EVP_MD_get_flags (3).

SEE ALSO

EVP_MD_get_params (3), provider-digest (7)

COPYRIGHT

Copyright 2020-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

17 - Linux cli command EVP_MD-WHIRLPOOLssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_MD-WHIRLPOOLssl and provides detailed information about the command EVP_MD-WHIRLPOOLssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_MD-WHIRLPOOLssl.

NAME 🖥️ EVP_MD-WHIRLPOOLssl 🖥️

WHIRLPOOL - The WHIRLPOOL EVP_MD implementation

DESCRIPTION

Support for computing WHIRLPOOL digests through the EVP_MD API.

Identity

This implementation is only available with the legacy provider, and is identified with the name “WHIRLPOOL”.

Gettable Parameters

This implementation supports the common gettable parameters described in EVP_MD-common (7).

SEE ALSO

provider-digest (7), OSSL_PROVIDER-default (7)

COPYRIGHT

Copyright 2020 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

18 - Linux cli command uri

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command uri and provides detailed information about the command uri, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the uri.

NAME 🖥️ uri 🖥️

uniform resource identifier (URI), including a URL or URN

SYNOPSIS

URI = [ absoluteURI | relativeURI ] [ “#”  fragment ]

absoluteURI = *scheme * “:” ( hierarchical_part | opaque_part )

relativeURI = ( net_path | absolute_path | relative_path ) [ “?”  query ]

scheme = “http” | “ftp” | “gopher” | “mailto” | “news” | “telnet” | “file” | “ftp” | “man” | “info” | “whatis” | “ldap” | “wais” | …

hierarchical_part = ( net_path | absolute_path ) [ “?”  query ]

net_path = “//”  authority [ absolute_path ]

absolute_path = “/”  path_segments

relative_path = relative_segment [ absolute_path ]

DESCRIPTION

A Uniform Resource Identifier (URI) is a short string of characters identifying an abstract or physical resource (for example, a web page). A Uniform Resource Locator (URL) is a URI that identifies a resource through its primary access mechanism (e.g., its network “location”), rather than by name or some other attribute of that resource. A Uniform Resource Name (URN) is a URI that must remain globally unique and persistent even when the resource ceases to exist or becomes unavailable.

URIs are the standard way to name hypertext link destinations for tools such as web browsers. The string “http://www.kernel.org” is a URL (and thus it is also a URI). Many people use the term URL loosely as a synonym for URI (though technically URLs are a subset of URIs).

URIs can be absolute or relative. An absolute identifier refers to a resource independent of context, while a relative identifier refers to a resource by describing the difference from the current context. Within a relative path reference, the complete path segments “.” and “..” have special meanings: “the current hierarchy level” and “the level above this hierarchy level”, respectively, just like they do in UNIX-like systems. A path segment which contains a colon character can’t be used as the first segment of a relative URI path (e.g., “this:that”), because it would be mistaken for a scheme name; precede such segments with ./ (e.g., “./this:that”). Note that descendants of MS-DOS (e.g., Microsoft Windows) replace devicename colons with the vertical bar ("|") in URIs, so “C:” becomes “C|”.

A fragment identifier, if included, refers to a particular named portion (fragment) of a resource; text after a ‘#’ identifies the fragment. A URI beginning with ‘#’ refers to that fragment in the current resource.

Usage

There are many different URI schemes, each with specific additional rules and meanings, but they are intentionally made to be as similar as possible. For example, many URL schemes permit the authority to be the following format, called here an ip_server (square brackets show what’s optional):

*ip_server = *[user [ : password ] @ ] host [ : port]

This format allows you to optionally insert a username, a user plus password, and/or a port number. The host is the name of the host computer, either its name as determined by DNS or an IP address (numbers separated by periods). Thus the URI <http://fred:[email protected]:8080/> logs into a web server on host example.com as fred (using fredpassword) using port 8080. Avoid including a password in a URI if possible because of the many security risks of having a password written down. If the URL supplies a username but no password, and the remote server requests a password, the program interpreting the URL should request one from the user.

Here are some of the most common schemes in use on UNIX-like systems that are understood by many tools. Note that many tools using URIs also have internal schemes or specialized schemes; see those tools’ documentation for information on those schemes.

http - Web (HTTP) server

http://ip_server/path
http://ip_server/path?query

This is a URL accessing a web (HTTP) server. The default port is 80. If the path refers to a directory, the web server will choose what to return; usually if there is a file named “index.html” or “index.htm” its content is returned, otherwise, a list of the files in the current directory (with appropriate links) is generated and returned. An example is <http://lwn.net>.

A query can be given in the archaic “isindex” format, consisting of a word or phrase and not including an equal sign (=). A query can also be in the longer “GET” format, which has one or more query entries of the form key=value separated by the ampersand character (&). Note that key can be repeated more than once, though it’s up to the web server and its application programs to determine if there’s any meaning to that. There is an unfortunate interaction with HTML/XML/SGML and the GET query format; when such URIs with more than one key are embedded in SGML/XML documents (including HTML), the ampersand (&) has to be rewritten as &. Note that not all queries use this format; larger forms may be too long to store as a URI, so they use a different interaction mechanism (called POST) which does not include the data in the URI. See the Common Gateway Interface specification at for more information.

ftp - File Transfer Protocol (FTP)

ftp://ip_server/path

This is a URL accessing a file through the file transfer protocol (FTP). The default port (for control) is 21. If no username is included, the username “anonymous” is supplied, and in that case many clients provide as the password the requestor’s Internet email address. An example is <ftp://ftp.is.co.za/rfc/rfc1808.txt>.

gopher - Gopher server

gopher://ip_server/gophertype selector
gopher://ip_server/gophertype selector%09search
gopher://ip_server/gophertype selector%09search%09gopher+_string

The default gopher port is 70. gophertype is a single-character field to denote the Gopher type of the resource to which the URL refers. The entire path may also be empty, in which case the delimiting “/” is also optional and the gophertype defaults to “1”.

selector is the Gopher selector string. In the Gopher protocol, Gopher selector strings are a sequence of octets which may contain any octets except 09 hexadecimal (US-ASCII HT or tab), 0A hexadecimal (US-ASCII character LF), and 0D (US-ASCII character CR).

mailto - Email address

mailto:email-address

This is an email address, usually of the form name@hostname. See mailaddr(7) for more information on the correct format of an email address. Note that any % character must be rewritten as %25. An example is <mailto:[email protected]>.

news - Newsgroup or News message

news:newsgroup-name
news:message-id

A newsgroup-name is a period-delimited hierarchical name, such as “comp.infosystems.www.misc”. If <newsgroup-name> is “*” (as in <news:*>), it is used to refer to “all available news groups”. An example is <news:comp.lang.ada>.

A message-id corresponds to the Message-ID of IETF RFC 1036, without the enclosing “<” and “>”; it takes the form unique@full_domain_name. A message identifier may be distinguished from a news group name by the presence of the “@” character.

telnet - Telnet login

telnet://ip_server/

The Telnet URL scheme is used to designate interactive text services that may be accessed by the Telnet protocol. The final “/” character may be omitted. The default port is 23. An example is <telnet://melvyl.ucop.edu/>.

file - Normal file

file://ip_server/path_segments
file:path_segments

This represents a file or directory accessible locally. As a special case, ip_server can be the string “localhost” or the empty string; this is interpreted as “the machine from which the URL is being interpreted”. If the path is to a directory, the viewer should display the directory’s contents with links to each containee; not all viewers currently do this. KDE supports generated files through the URL <file:/cgi-bin>. If the given file isn’t found, browser writers may want to try to expand the filename via filename globbing (see glob(7) and glob(3)).

The second format (e.g., <file:/etc/passwd>) is a correct format for referring to a local file. However, older standards did not permit this format, and some programs don’t recognize this as a URI. A more portable syntax is to use an empty string as the server name, for example, <file:///etc/passwd>; this form does the same thing and is easily recognized by pattern matchers and older programs as a URI. Note that if you really mean to say “start from the current location”, don’t specify the scheme at all; use a relative address like <../test.txt>, which has the side-effect of being scheme-independent. An example of this scheme is <file:///etc/passwd>.

man - Man page documentation

man:command-name
man:command-name(section)

This refers to local online manual (man) reference pages. The command name can optionally be followed by a parenthesis and section number; see man(7) for more information on the meaning of the section numbers. This URI scheme is unique to UNIX-like systems (such as Linux) and is not currently registered by the IETF. An example is <man:ls(1)>.

info - Info page documentation

info:virtual-filename
info:virtual-filename#nodename
info:(virtual-filename)
info:(virtual-filename)nodename

This scheme refers to online info reference pages (generated from texinfo files), a documentation format used by programs such as the GNU tools. This URI scheme is unique to UNIX-like systems (such as Linux) and is not currently registered by the IETF. As of this writing, GNOME and KDE differ in their URI syntax and do not accept the other’s syntax. The first two formats are the GNOME format; in nodenames all spaces are written as underscores. The second two formats are the KDE format; spaces in nodenames must be written as spaces, even though this is forbidden by the URI standards. It’s hoped that in the future most tools will understand all of these formats and will always accept underscores for spaces in nodenames. In both GNOME and KDE, if the form without the nodename is used the nodename is assumed to be “Top”. Examples of the GNOME format are <info:gcc> and <info:gcc#G++_and_GCC>. Examples of the KDE format are <info:(gcc)> and <info:(gcc)G++ and GCC>.

whatis - Documentation search

whatis:string

This scheme searches the database of short (one-line) descriptions of commands and returns a list of descriptions containing that string. Only complete word matches are returned. See whatis(1). This URI scheme is unique to UNIX-like systems (such as Linux) and is not currently registered by the IETF.

ghelp - GNOME help documentation

ghelp:name-of-application

This loads GNOME help for the given application. Note that not much documentation currently exists in this format.

ldap - Lightweight Directory Access Protocol

ldap://hostport
ldap://hostport/
ldap://hostport/dn
ldap://hostport/dn?attributes
ldap://hostport/dn?attributes?scope
ldap://hostport/dn?attributes?scope?filter
ldap://hostport/dn?attributes?scope?filter?extensions

This scheme supports queries to the Lightweight Directory Access Protocol (LDAP), a protocol for querying a set of servers for hierarchically organized information (such as people and computing resources). See RFC 2255 for more information on the LDAP URL scheme. The components of this URL are:

hostport
the LDAP server to query, written as a hostname optionally followed by a colon and the port number. The default LDAP port is TCP port 389. If empty, the client determines which the LDAP server to use.

dn
the LDAP Distinguished Name, which identifies the base object of the LDAP search (see RFC 2253 section 3).

attributes
a comma-separated list of attributes to be returned; see RFC 2251 section 4.1.5. If omitted, all attributes should be returned.

scope
specifies the scope of the search, which can be one of “base” (for a base object search), “one” (for a one-level search), or “sub” (for a subtree search). If scope is omitted, “base” is assumed.

filter
specifies the search filter (subset of entries to return). If omitted, all entries should be returned. See RFC 2254 section 4.

extensions
a comma-separated list of type=value pairs, where the =value portion may be omitted for options not requiring it. An extension prefixed with a ‘!’ is critical (must be supported to be valid), otherwise it is noncritical (optional).

LDAP queries are easiest to explain by example. Here’s a query that asks ldap.itd.umich.edu for information about the University of Michigan in the U.S.:

ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US

To just get its postal address attribute, request:

ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US?postalAddress

To ask a host.com at port 6666 for information about the person with common name (cn) “Babs Jensen” at University of Michigan, request:

ldap://host.com:6666/o=University%20of%20Michigan,c=US??sub?(cn=Babs%20Jensen)

wais - Wide Area Information Servers

wais://hostport/database
wais://hostport/database?search
wais://hostport/database/wtype/wpath

This scheme designates a WAIS database, search, or document (see IETF RFC 1625 for more information on WAIS). Hostport is the hostname, optionally followed by a colon and port number (the default port number is 210).

The first form designates a WAIS database for searching. The second form designates a particular search of the WAIS database database. The third form designates a particular document within a WAIS database to be retrieved. wtype is the WAIS designation of the type of the object and wpath is the WAIS document-id.

other schemes

There are many other URI schemes. Most tools that accept URIs support a set of internal URIs (e.g., Mozilla has the about: scheme for internal information, and the GNOME help browser has the toc: scheme for various starting locations). There are many schemes that have been defined but are not as widely used at the current time (e.g., prospero). The nntp: scheme is deprecated in favor of the news: scheme. URNs are to be supported by the urn: scheme, with a hierarchical name space (e.g., urn:ietf:… would identify IETF documents); at this time URNs are not widely implemented. Not all tools support all schemes.

Character encoding

URIs use a limited number of characters so that they can be typed in and used in a variety of situations.

The following characters are reserved, that is, they may appear in a URI but their use is limited to their reserved purpose (conflicting data must be escaped before forming the URI):

; / ? : @ & = + $ ,

Unreserved characters may be included in a URI. Unreserved characters include uppercase and lowercase Latin letters, decimal digits, and the following limited set of punctuation marks and symbols:

- _ . ! ~ * ' ( )

All other characters must be escaped. An escaped octet is encoded as a character triplet, consisting of the percent character “%” followed by the two hexadecimal digits representing the octet code (you can use uppercase or lowercase letters for the hexadecimal digits). For example, a blank space must be escaped as “%20”, a tab character as “%09”, and the “&” as “%26”. Because the percent “%” character always has the reserved purpose of being the escape indicator, it must be escaped as “%25”. It is common practice to escape space characters as the plus symbol (+) in query text; this practice isn’t uniformly defined in the relevant RFCs (which recommend %20 instead) but any tool accepting URIs with query text should be prepared for them. A URI is always shown in its “escaped” form.

Unreserved characters can be escaped without changing the semantics of the URI, but this should not be done unless the URI is being used in a context that does not allow the unescaped character to appear. For example, “%7e” is sometimes used instead of “~” in an HTTP URL path, but the two are equivalent for an HTTP URL.

For URIs which must handle characters outside the US ASCII character set, the HTML 4.01 specification (section B.2) and IETF RFC 3986 (last paragraph of section 2.5) recommend the following approach:

  1. translate the character sequences into UTF-8 (IETF RFC 3629)—see utf-8(7)—and then

  2. use the URI escaping mechanism, that is, use the %HH encoding for unsafe octets.

Writing a URI

When written, URIs should be placed inside double quotes (e.g., “http://www.kernel.org”), enclosed in angle brackets (e.g., <http://lwn.net>), or placed on a line by themselves. A warning for those who use double-quotes: never move extraneous punctuation (such as the period ending a sentence or the comma in a list) inside a URI, since this will change the value of the URI. Instead, use angle brackets instead, or switch to a quoting system that never includes extraneous characters inside quotation marks. This latter system, called the ’new’ or ’logical’ quoting system by “Hart’s Rules” and the “Oxford Dictionary for Writers and Editors”, is preferred practice in Great Britain and in various European languages. Older documents suggested inserting the prefix “URL:” just before the URI, but this form has never caught on.

The URI syntax was designed to be unambiguous. However, as URIs have become commonplace, traditional media (television, radio, newspapers, billboards, etc.) have increasingly used abbreviated URI references consisting of only the authority and path portions of the identified resource (e.g., <www.w3.org/Addressing>). Such references are primarily intended for human interpretation rather than machine, with the assumption that context-based heuristics are sufficient to complete the URI (e.g., hostnames beginning with “www” are likely to have a URI prefix of “http://” and hostnames beginning with “ftp” likely to have a prefix of “ftp://”). Many client implementations heuristically resolve these references. Such heuristics may change over time, particularly when new schemes are introduced. Since an abbreviated URI has the same syntax as a relative URL path, abbreviated URI references cannot be used where relative URIs are permitted, and can be used only when there is no defined base (such as in dialog boxes). Don’t use abbreviated URIs as hypertext links inside a document; use the standard format as described here.

STANDARDS

(IETF RFC 2396), (HTML 4.0).

NOTES

Any tool accepting URIs (e.g., a web browser) on a Linux system should be able to handle (directly or indirectly) all of the schemes described here, including the man: and info: schemes. Handling them by invoking some other program is fine and in fact encouraged.

Technically the fragment isn’t part of the URI.

For information on how to embed URIs (including URLs) in a data format, see documentation on that format. HTML uses the format <A HREF="uri"> text </A>. Texinfo files use the format @uref{uri}. Man and mdoc have the recently added UR macro, or just include the URI in the text (viewers should be able to detect :// as part of a URI).

The GNOME and KDE desktop environments currently vary in the URIs they accept, in particular in their respective help browsers. To list man pages, GNOME uses <toc:man> while KDE uses <man:(index)>, and to list info pages, GNOME uses <toc:info> while KDE uses <info:(dir)> (the author of this man page prefers the KDE approach here, though a more regular format would be even better). In general, KDE uses <file:/cgi-bin/> as a prefix to a set of generated files. KDE prefers documentation in HTML, accessed via the <file:/cgi-bin/helpindex>. GNOME prefers the ghelp scheme to store and find documentation. Neither browser handles file: references to directories at the time of this writing, making it difficult to refer to an entire directory with a browsable URI. As noted above, these environments differ in how they handle the info: scheme, probably the most important variation. It is expected that GNOME and KDE will converge to common URI formats, and a future version of this man page will describe the converged result. Efforts to aid this convergence are encouraged.

Security

A URI does not in itself pose a security threat. There is no general guarantee that a URL, which at one time located a given resource, will continue to do so. Nor is there any guarantee that a URL will not locate a different resource at some later point in time; such a guarantee can be obtained only from the person(s) controlling that namespace and the resource in question.

It is sometimes possible to construct a URL such that an attempt to perform a seemingly harmless operation, such as the retrieval of an entity associated with the resource, will in fact cause a possibly damaging remote operation to occur. The unsafe URL is typically constructed by specifying a port number other than that reserved for the network protocol in question. The client unwittingly contacts a site that is in fact running a different protocol. The content of the URL contains instructions that, when interpreted according to this other protocol, cause an unexpected operation. An example has been the use of a gopher URL to cause an unintended or impersonating message to be sent via a SMTP server.

Caution should be used when using any URL that specifies a port number other than the default for the protocol, especially when it is a number within the reserved space.

Care should be taken when a URI contains escaped delimiters for a given protocol (for example, CR and LF characters for telnet protocols) that these are not unescaped before transmission. This might violate the protocol, but avoids the potential for such characters to be used to simulate an extra operation or parameter in that protocol, which might lead to an unexpected and possibly harmful remote operation to be performed.

It is clearly unwise to use a URI that contains a password which is intended to be secret. In particular, the use of a password within the “userinfo” component of a URI is strongly recommended against except in those rare cases where the “password” parameter is intended to be public.

BUGS

Documentation may be placed in a variety of locations, so there currently isn’t a good URI scheme for general online documentation in arbitrary formats. References of the form <file:///usr/doc/ZZZ> don’t work because different distributions and local installation requirements may place the files in different directories (it may be in /usr/doc, or /usr/local/doc, or /usr/share, or somewhere else). Also, the directory ZZZ usually changes when a version changes (though filename globbing could partially overcome this). Finally, using the file: scheme doesn’t easily support people who dynamically load documentation from the Internet (instead of loading the files onto a local filesystem). A future URI scheme may be added (e.g., “userdoc:”) to permit programs to include cross-references to more detailed documentation without having to know the exact location of that documentation. Alternatively, a future version of the filesystem specification may specify file locations sufficiently so that the file: scheme will be able to locate documentation.

Many programs and file formats don’t include a way to incorporate or implement links using URIs.

Many programs can’t handle all of these different URI formats; there should be a standard mechanism to load an arbitrary URI that automatically detects the users’ environment (e.g., text or graphics, desktop environment, local user preferences, and currently executing tools) and invokes the right tool for any URI.

SEE ALSO

lynx(1), man2html(1), mailaddr(7), utf-8(7)

IETF RFC 2255

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

19 - Linux cli command iso-8859-1

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso-8859-1 and provides detailed information about the command iso-8859-1, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso-8859-1.

NAME 🖥️ iso-8859-1 🖥️

1 - ISO/IEC 8859-1 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-1 encodes the characters used in many West European languages.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-1 characters

The following table displays the characters in ISO/IEC 8859-1 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-1 is also known as Latin-1.

SEE ALSO

ascii(7), charsets(7), cp1252(7), iso_8859-15(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

20 - Linux cli command EVP_KEYEXCH-X448ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KEYEXCH-X448ssl and provides detailed information about the command EVP_KEYEXCH-X448ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KEYEXCH-X448ssl.

NAME 🖥️ EVP_KEYEXCH-X448ssl 🖥️

X25519, EVP_KEYEXCH-X448 - X25519 and X448 Key Exchange algorithm support

DESCRIPTION

Key exchange support for the X25519 and X448 key types.

Key exchange parameters

“pad” (OSSL_EXCHANGE_PARAM_PAD) <unsigned integer>
See “Common Key Exchange parameters” in provider-keyexch (7).

EXAMPLES

Keys for the host and peer can be generated as shown in “Examples” in EVP_PKEY-X25519 (7).

The code to generate a shared secret is identical to “Examples” in EVP_KEYEXCH-DH (7).

SEE ALSO

EVP_PKEY-FFC (7), EVP_PKEY-DH (7) EVP_PKEY (3), provider-keyexch (7), provider-keymgmt (7), OSSL_PROVIDER-default (7), OSSL_PROVIDER-FIPS (7),

COPYRIGHT

Copyright 2020 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

21 - Linux cli command systemd.syntax

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command systemd.syntax and provides detailed information about the command systemd.syntax, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the systemd.syntax.

NAME 🖥️ systemd.syntax 🖥️

General syntax of systemd configuration files

INTRODUCTION

This page describes the basic principles of configuration files used by systemd(1) and related programs for:

·

systemd unit files, see systemd.unit(5), systemd.service(5), systemd.socket(5), systemd.device(5), systemd.mount(5), systemd.automount(5), systemd.swap(5), systemd.target(5), systemd.path(5), systemd.timer(5), systemd.slice(5), systemd.scope(5)

·

link files, see systemd.link(5)

·

netdev and network files, see systemd.netdev(5), systemd.network(5)

·

daemon config files, see systemd-system.conf(5), systemd-user.conf(5), logind.conf(5), journald.conf(5), journal-remote.conf(5), journal-upload.conf(5), systemd-sleep.conf(5), timesyncd.conf(5)

·

nspawn files, see systemd.nspawn(5)

The syntax is inspired by XDG Desktop Entry Specification[1] .desktop files, which are in turn inspired by Microsoft Windows .ini files.

Each file is a plain text file divided into sections, with configuration entries in the style key=value. Whitespace immediately before or after the “=” is ignored. Empty lines and lines starting with “#” or “;” are ignored, which may be used for commenting.

Lines ending in a backslash are concatenated with the following line while reading and the backslash is replaced by a space character. This may be used to wrap long lines. The limit on line length is very large (currently 1 MB), but it is recommended to avoid such long lines and use multiple directives, variable substitution, or other mechanism as appropriate for the given file type. When a comment line or lines follow a line ending with a backslash, the comment block is ignored, so the continued line is concatenated with whatever follows the comment block.

[Section A] KeyOne=value 1 KeyTwo=value 2

# a comment

[Section B]
Setting="something" "some thing" "..."
KeyTwo=value 2 \
       value 2 continued

[Section C]
KeyThree=value 3\
# this line is ignored
; this line is ignored too
       value 3 continued

Boolean arguments used in configuration files can be written in various formats. For positive settings the strings 1, yes, true and on are equivalent. For negative settings, the strings 0, no, false and off are equivalent.

Time span values encoded in configuration files can be written in various formats. A stand-alone number specifies a time in seconds. If suffixed with a time unit, the unit is honored. A concatenation of multiple values with units is supported, in which case the values are added up. Example: “50” refers to 50 seconds; “2min 200ms” refers to 2 minutes and 200 milliseconds, i.e. 120200 ms. The following time units are understood: “s”, “min”, “h”, “d”, “w”, “ms”, “us”. For details see systemd.time(7).

Various settings are allowed to be specified more than once, in which case the interpretation depends on the setting. Often, multiple settings form a list, and setting to an empty value “resets”, which means that previous assignments are ignored. When this is allowed, it is mentioned in the description of the setting. Note that using multiple assignments to the same value makes the file incompatible with parsers for the XDG .desktop file format.

QUOTING

For settings where quoting is allowed, the following general rules apply: double quotes ("…") and single quotes (…) may be used to wrap a whole item (the opening quote may appear only at the beginning or after whitespace that is not quoted, and the closing quote must be followed by whitespace or the end of line), in which case everything until the next matching quote becomes part of the same item. Quotes themselves are removed. C-style escapes are supported. The table below contains the list of known escape patterns. Only escape patterns which match the syntax in the table are allowed; other patterns may be added in the future and unknown patterns will result in a warning. In particular, any backslashes should be doubled. Finally, a trailing backslash (") may be used to merge lines, as described above. UTF-8 is accepted, and hence typical unicode characters do not need to be escaped.

Table 1. Supported escapes

LiteralActual value
""bell
""backspace
" "form feed
" "newline
" "carriage return
" "tab
" "vertical tab
"\"backslash
"\""double quotation mark
"\"single quotation mark
"\s"space
"\xxx"character number xx in hexadecimal encoding
"\nnn"character number nnn in octal encoding
"\unnnn"unicode code point nnnn in hexadecimal encoding
"\Unnnnnnnn"unicode code point nnnnnnnn in hexadecimal encoding

SEE ALSO

systemd.time(7)

NOTES

XDG Desktop Entry Specification

https://standards.freedesktop.org/desktop-entry-spec/latest/

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

22 - Linux cli command go-remote

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command go-remote and provides detailed information about the command go-remote, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the go-remote.

NAME 🖥️ go-remote 🖥️

tool for managing Go source code

DESCRIPTION

An import path (see go-importpath(1)) denotes a package stored in the local file system. Certain import paths also describe how to obtain the source code for the package using a revision control system.

A few common code hosting sites have special syntax:

BitBucket (Mercurial)
import “bitbucket.org/user/project” import “bitbucket.org/user/project/sub/directory”

GitHub (Git)
import “github.com/user/project” import “github.com/user/project/sub/directory”

Google Code Project Hosting (Git, Mercurial, Subversion)
import “code.google.com/p/project” import “code.google.com/p/project/sub/directory”

import “code.google.com/p/project.subrepository” import “code.google.com/p/project.subrepository/sub/directory”

Launchpad (Bazaar)
import “launchpad.net/project” import “launchpad.net/project/series” import “launchpad.net/project/series/sub/directory”

import “launchpad.net/~user/project/branch” import “launchpad.net/~user/project/branch/sub/directory”

For code hosted on other servers, import paths may either be qualified with the version control type, or the go tool can dynamically fetch the import path over https/http and discover where the code resides from a <meta> tag in the HTML.

To declare the code location, an import path of the form

repository.vcs/path

specifies the given repository, with or without the .vcs suffix, using the named version control system, and then the path inside that repository. The supported version control systems are:

Bazaar
.bzr

Git
.git

Mercurial
.hg

Subversion
.svn

For example,

import “example.org/user/foo.hg”

denotes the root directory of the Mercurial repository at example.org/user/foo or foo.hg, and

import “example.org/repo.git/foo/bar”

denotes the foo/bar directory of the Git repository at example.com/repo or repo.git.

When a version control system supports multiple protocols, each is tried in turn when downloading. For example, a Git download tries git://, then https://, then http://.

If the import path is not a known code hosting site and also lacks a version control qualifier, the go tool attempts to fetch the import over https/http and looks for a <meta> tag in the document’s HTML <head>.

The meta tag has the form:

<meta name=“go-import” content=“import-prefix vcs repo-root”>

The import-prefix is the import path corresponding to the repository root. It must be a prefix or an exact match of the package being fetched with “go get”. If it’s not an exact match, another http request is made at the prefix to verify the <meta> tags match.

The vcs is one of “git”, “hg”, “svn”, etc,

The repo-root is the root of the version control system containing a scheme and not containing a .vcs qualifier.

For example,

import “example.org/pkg/foo”

will result in the following request(s):

https://example.org/pkg/foo?go-get=1 (preferred) http://example.org/pkg/foo?go-get=1 (fallback)

If that page contains the meta tag

<meta name=“go-import” content=“example.org git https://code.org/r/p/exproj">

the go tool will verify that https://example.org/?go-get=1 contains the same meta tag and then git clone https://code.org/r/p/exproj into GOPATH/src/example.org.

New downloaded packages are written to the first directory listed in the GOPATH environment variable (see go-path(1)).

The go command attempts to download the version of the package appropriate for the Go release being used. See go-install(1) for more.

AUTHOR

This manual page was written by Michael Stapelberg <[email protected]>, for the Debian project (and may be used by others).

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

23 - Linux cli command DROP_TABLE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_TABLE and provides detailed information about the command DROP_TABLE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_TABLE.

NAME 🖥️ DROP_TABLE 🖥️

remove a table

SYNOPSIS

DROP TABLE [ IF EXISTS ] name [, ...] [ CASCADE | RESTRICT ]

DESCRIPTION

DROP TABLE removes tables from the database. Only the table owner, the schema owner, and superuser can drop a table. To empty a table of rows without destroying the table, use DELETE or TRUNCATE.

DROP TABLE always removes any indexes, rules, triggers, and constraints that exist for the target table. However, to drop a table that is referenced by a view or a foreign-key constraint of another table, CASCADE must be specified. (CASCADE will remove a dependent view entirely, but in the foreign-key case it will only remove the foreign-key constraint, not the other table entirely.)

PARAMETERS

IF EXISTS

Do not throw an error if the table does not exist. A notice is issued in this case.

name

The name (optionally schema-qualified) of the table to drop.

CASCADE

Automatically drop objects that depend on the table (such as views), and in turn all objects that depend on those objects (see Section 5.14).

RESTRICT

Refuse to drop the table if any objects depend on it. This is the default.

EXAMPLES

To destroy two tables, films and distributors:

DROP TABLE films, distributors;

COMPATIBILITY

This command conforms to the SQL standard, except that the standard only allows one table to be dropped per command, and apart from the IF EXISTS option, which is a PostgreSQL extension.

SEE ALSO

ALTER TABLE (ALTER_TABLE(7)), CREATE TABLE (CREATE_TABLE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

24 - Linux cli command charsets

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command charsets and provides detailed information about the command charsets, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the charsets.

NAME 🖥️ charsets 🖥️

character set standards and internationalization

DESCRIPTION

This manual page gives an overview on different character set standards and how they were used on Linux before Unicode became ubiquitous. Some of this information is still helpful for people working with legacy systems and documents.

Standards discussed include such as ASCII, GB 2312, ISO/IEC 8859, JIS, KOI8-R, KS, and Unicode.

The primary emphasis is on character sets that were actually used by locale character sets, not the myriad others that could be found in data from other systems.

ASCII

ASCII (American Standard Code For Information Interchange) is the original 7-bit character set, originally designed for American English. Also known as US-ASCII. It is currently described by the ISO/IEC 646:1991 IRV (International Reference Version) standard.

Various ASCII variants replacing the dollar sign with other currency symbols and replacing punctuation with non-English alphabetic characters to cover German, French, Spanish, and others in 7 bits emerged. All are deprecated; glibc does not support locales whose character sets are not true supersets of ASCII.

As Unicode, when using UTF-8, is ASCII-compatible, plain ASCII text still renders properly on modern UTF-8 using systems.

ISO/IEC 8859

ISO/IEC 8859 is a series of 15 8-bit character sets, all of which have ASCII in their low (7-bit) half, invisible control characters in positions 128 to 159, and 96 fixed-width graphics in positions 160–255.

Of these, the most important is ISO/IEC 8859-1 (“Latin Alphabet No. 1” / Latin-1). It was widely adopted and supported by different systems, and is gradually being replaced with Unicode. The ISO/IEC 8859-1 characters are also the first 256 characters of Unicode.

Console support for the other ISO/IEC 8859 character sets is available under Linux through user-mode utilities (such as setfont(8)) that modify keyboard bindings and the EGA graphics table and employ the “user mapping” font table in the console driver.

Here are brief descriptions of each character set:

ISO/IEC 8859-1 (Latin-1)
Latin-1 covers many European languages such as Albanian, Basque, Danish, English, Faroese, Galician, Icelandic, Irish, Italian, Norwegian, Portuguese, Spanish, and Swedish. The lack of the ligatures Dutch IJ/ij, French œ, and „German“ quotation marks was considered tolerable.

ISO/IEC 8859-2 (Latin-2)
Latin-2 supports many Latin-written Central and East European languages such as Bosnian, Croatian, Czech, German, Hungarian, Polish, Slovak, and Slovene. Replacing Romanian ș/ț with ş/ţ was considered tolerable.

ISO/IEC 8859-3 (Latin-3)
Latin-3 was designed to cover of Esperanto, Maltese, and Turkish, but ISO/IEC 8859-9 later superseded it for Turkish.

ISO/IEC 8859-4 (Latin-4)
Latin-4 introduced letters for North European languages such as Estonian, Latvian, and Lithuanian, but was superseded by ISO/IEC 8859-10 and ISO/IEC 8859-13.

ISO/IEC 8859-5
Cyrillic letters supporting Bulgarian, Byelorussian, Macedonian, Russian, Serbian, and (almost completely) Ukrainian. It was never widely used, see the discussion of KOI8-R/KOI8-U below.

ISO/IEC 8859-6
Was created for Arabic. The ISO/IEC 8859-6 glyph table is a fixed font of separate letter forms, but a proper display engine should combine these using the proper initial, medial, and final forms.

ISO/IEC 8859-7
Was created for Modern Greek in 1987, updated in 2003.

ISO/IEC 8859-8
Supports Modern Hebrew without niqud (punctuation signs). Niqud and full-fledged Biblical Hebrew were outside the scope of this character set.

ISO/IEC 8859-9 (Latin-5)
This is a variant of Latin-1 that replaces Icelandic letters with Turkish ones.

ISO/IEC 8859-10 (Latin-6)
Latin-6 added the Inuit (Greenlandic) and Sami (Lappish) letters that were missing in Latin-4 to cover the entire Nordic area.

ISO/IEC 8859-11
Supports the Thai alphabet and is nearly identical to the TIS-620 standard.

ISO/IEC 8859-12
This character set does not exist.

ISO/IEC 8859-13 (Latin-7)
Supports the Baltic Rim languages; in particular, it includes Latvian characters not found in Latin-4.

ISO/IEC 8859-14 (Latin-8)
This is the Celtic character set, covering Old Irish, Manx, Gaelic, Welsh, Cornish, and Breton.

ISO/IEC 8859-15 (Latin-9)
Latin-9 is similar to the widely used Latin-1 but replaces some less common symbols with the Euro sign and French and Finnish letters that were missing in Latin-1.

ISO/IEC 8859-16 (Latin-10)
This character set covers many Southeast European languages, and most importantly supports Romanian more completely than Latin-2.

KOI8-R / KOI8-U

KOI8-R is a non-ISO character set popular in Russia before Unicode. The lower half is ASCII; the upper is a Cyrillic character set somewhat better designed than ISO/IEC 8859-5. KOI8-U, based on KOI8-R, has better support for Ukrainian. Neither of these sets are ISO/IEC 2022 compatible, unlike the ISO/IEC 8859 series.

Console support for KOI8-R is available under Linux through user-mode utilities that modify keyboard bindings and the EGA graphics table, and employ the “user mapping” font table in the console driver.

GB 2312

GB 2312 is a mainland Chinese national standard character set used to express simplified Chinese. Just like JIS X 0208, characters are mapped into a 94x94 two-byte matrix used to construct EUC-CN. EUC-CN is the most important encoding for Linux and includes ASCII and GB 2312. Note that EUC-CN is often called as GB, GB 2312, or CN-GB.

Big5

Big5 was a popular character set in Taiwan to express traditional Chinese. (Big5 is both a character set and an encoding.) It is a superset of ASCII. Non-ASCII characters are expressed in two bytes. Bytes 0xa1–0xfe are used as leading bytes for two-byte characters. Big5 and its extension were widely used in Taiwan and Hong Kong. It is not ISO/IEC 2022 compliant.

JIS X 0208

JIS X 0208 is a Japanese national standard character set. Though there are some more Japanese national standard character sets (like JIS X 0201, JIS X 0212, and JIS X 0213), this is the most important one. Characters are mapped into a 94x94 two-byte matrix, whose each byte is in the range 0x21–0x7e. Note that JIS X 0208 is a character set, not an encoding. This means that JIS X 0208 itself is not used for expressing text data. JIS X 0208 is used as a component to construct encodings such as EUC-JP, Shift_JIS, and ISO/IEC 2022-JP. EUC-JP is the most important encoding for Linux and includes ASCII and JIS X 0208. In EUC-JP, JIS X 0208 characters are expressed in two bytes, each of which is the JIS X 0208 code plus 0x80.

KS X 1001

KS X 1001 is a Korean national standard character set. Just as JIS X 0208, characters are mapped into a 94x94 two-byte matrix. KS X 1001 is used like JIS X 0208, as a component to construct encodings such as EUC-KR, Johab, and ISO/IEC 2022-KR. EUC-KR is the most important encoding for Linux and includes ASCII and KS X 1001. KS C 5601 is an older name for KS X 1001.

ISO/IEC 2022 and ISO/IEC 4873

The ISO/IEC 2022 and ISO/IEC 4873 standards describe a font-control model based on VT100 practice. This model is (partially) supported by the Linux kernel and by xterm(1). Several ISO/IEC 2022-based character encodings have been defined, especially for Japanese.

There are 4 graphic character sets, called G0, G1, G2, and G3, and one of them is the current character set for codes with high bit zero (initially G0), and one of them is the current character set for codes with high bit one (initially G1). Each graphic character set has 94 or 96 characters, and is essentially a 7-bit character set. It uses codes either 040–0177 (041–0176) or 0240–0377 (0241–0376). G0 always has size 94 and uses codes 041–0176.

Switching between character sets is done using the shift functions ^N (SO or LS1), ^O (SI or LS0), ESC n (LS2), ESC o (LS3), ESC N (SS2), ESC O (SS3), ESC ~ (LS1R), ESC } (LS2R), ESC | (LS3R). The function LSn makes character set Gn the current one for codes with high bit zero. The function LSnR makes character set Gn the current one for codes with high bit one. The function SSn makes character set Gn (n=2 or 3) the current one for the next character only (regardless of the value of its high order bit).

A 94-character set is designated as Gn character set by an escape sequence ESC ( xx (for G0), ESC ) xx (for G1), ESC * xx (for G2), ESC + xx (for G3), where xx is a symbol or a pair of symbols found in the ISO/IEC 2375 International Register of Coded Character Sets. For example, ESC ( @ selects the ISO/IEC 646 character set as G0, ESC ( A selects the UK standard character set (with pound instead of number sign), ESC ( B selects ASCII (with dollar instead of currency sign), ESC ( M selects a character set for African languages, ESC ( ! A selects the Cuban character set, and so on.

A 96-character set is designated as Gn character set by an escape sequence ESC - xx (for G1), ESC . xx (for G2) or ESC / xx (for G3). For example, ESC - G selects the Hebrew alphabet as G1.

A multibyte character set is designated as Gn character set by an escape sequence ESC $ xx or ESC $ ( xx (for G0), ESC $ ) xx (for G1), ESC $ * xx (for G2), ESC $ + xx (for G3). For example, ESC $ ( C selects the Korean character set for G0. The Japanese character set selected by ESC $ B has a more recent version selected by ESC & @ ESC $ B.

ISO/IEC 4873 stipulates a narrower use of character sets, where G0 is fixed (always ASCII), so that G1, G2, and G3 can be invoked only for codes with the high order bit set. In particular, ^N and ^O are not used anymore, ESC ( xx can be used only with xx=B, and ESC ) xx, ESC * xx, ESC + xx are equivalent to ESC - xx, ESC . xx, ESC / xx, respectively.

TIS-620

TIS-620 is a Thai national standard character set and a superset of ASCII. In the same fashion as the ISO/IEC 8859 series, Thai characters are mapped into 0xa1–0xfe.

Unicode

Unicode (ISO/IEC 10646) is a standard which aims to unambiguously represent every character in every human language. Unicode’s structure permits 20.1 bits to encode every character. Since most computers don’t include 20.1-bit integers, Unicode is usually encoded as 32-bit integers internally and either a series of 16-bit integers (UTF-16) (needing two 16-bit integers only when encoding certain rare characters) or a series of 8-bit bytes (UTF-8).

Linux represents Unicode using the 8-bit Unicode Transformation Format (UTF-8). UTF-8 is a variable length encoding of Unicode. It uses 1 byte to code 7 bits, 2 bytes for 11 bits, 3 bytes for 16 bits, 4 bytes for 21 bits, 5 bytes for 26 bits, 6 bytes for 31 bits.

Let 0,1,x stand for a zero, one, or arbitrary bit. A byte 0xxxxxxx stands for the Unicode 00000000 0xxxxxxx which codes the same symbol as the ASCII 0xxxxxxx. Thus, ASCII goes unchanged into UTF-8, and people using only ASCII do not notice any change: not in code, and not in file size.

A byte 110xxxxx is the start of a 2-byte code, and 110xxxxx 10yyyyyy is assembled into 00000xxx xxyyyyyy. A byte 1110xxxx is the start of a 3-byte code, and 1110xxxx 10yyyyyy 10zzzzzz is assembled into xxxxyyyy yyzzzzzz. (When UTF-8 is used to code the 31-bit ISO/IEC 10646 then this progression continues up to 6-byte codes.)

For most texts in ISO/IEC 8859 character sets, this means that the characters outside of ASCII are now coded with two bytes. This tends to expand ordinary text files by only one or two percent. For Russian or Greek texts, this expands ordinary text files by 100%, since text in those languages is mostly outside of ASCII. For Japanese users this means that the 16-bit codes now in common use will take three bytes. While there are algorithmic conversions from some character sets (especially ISO/IEC 8859-1) to Unicode, general conversion requires carrying around conversion tables, which can be quite large for 16-bit codes.

Note that UTF-8 is self-synchronizing: 10xxxxxx is a tail, any other byte is the head of a code. Note that the only way ASCII bytes occur in a UTF-8 stream, is as themselves. In particular, there are no embedded NULs (‘�’) or ‘/’s that form part of some larger code.

Since ASCII, and, in particular, NUL and ‘/’, are unchanged, the kernel does not notice that UTF-8 is being used. It does not care at all what the bytes it is handling stand for.

Rendering of Unicode data streams is typically handled through “subfont” tables which map a subset of Unicode to glyphs. Internally the kernel uses Unicode to describe the subfont loaded in video RAM. This means that in the Linux console in UTF-8 mode, one can use a character set with 512 different symbols. This is not enough for Japanese, Chinese, and Korean, but it is enough for most other purposes.

SEE ALSO

iconv(1), ascii(7), iso_8859-1(7), unicode(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

25 - Linux cli command latin9

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command latin9 and provides detailed information about the command latin9, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the latin9.

NAME 🖥️ latin9 🖥️

15 - ISO/IEC 8859-15 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-15 encodes the characters used in many West European languages and adds the Euro sign.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-15 characters

The following table displays the characters in ISO/IEC 8859-15 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-15 is also known as Latin-9 (or sometimes as Latin-0).

SEE ALSO

ascii(7), charsets(7), cp1252(7), iso_8859-1(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

26 - Linux cli command cp1251

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command cp1251 and provides detailed information about the command cp1251, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the cp1251.

NAME 🖥️ cp1251 🖥️

CP 1251 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The Windows Code Pages include several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). CP 1251 encodes the characters used in Cyrillic scripts.

CP 1251 characters

The following table displays the characters in CP 1251 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

CP 1251 is also known as Windows Cyrillic.

SEE ALSO

ascii(7), charsets(7), cp1252(7), iso_8859-5(7), koi8-r(7), koi8-u(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

27 - Linux cli command SELECT

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command SELECT and provides detailed information about the command SELECT, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the SELECT.

NAME 🖥️ SELECT 🖥️

retrieve rows from a table or view

SYNOPSIS

[ WITH [ RECURSIVE ] with_query [, ...] ]
SELECT [ ALL | DISTINCT [ ON ( expression [, ...] ) ] ]
    [ { * | expression [ [ AS ] output_name ] } [, ...] ]
    [ FROM from_item [, ...] ]
    [ WHERE condition ]
    [ GROUP BY [ ALL | DISTINCT ] grouping_element [, ...] ]
    [ HAVING condition ]
    [ WINDOW window_name AS ( window_definition ) [, ...] ]
    [ { UNION | INTERSECT | EXCEPT } [ ALL | DISTINCT ] select ]
    [ ORDER BY expression [ ASC | DESC | USING operator ] [ NULLS { FIRST | LAST } ] [, ...] ]
    [ LIMIT { count | ALL } ]
    [ OFFSET start [ ROW | ROWS ] ]
    [ FETCH { FIRST | NEXT } [ count ] { ROW | ROWS } { ONLY | WITH TIES } ]
    [ FOR { UPDATE | NO KEY UPDATE | SHARE | KEY SHARE } [ OF table_name [, ...] ] [ NOWAIT | SKIP LOCKED ] [...] ]

where from_item can be one of:

    [ ONLY ] table_name [ * ] [ [ AS ] alias [ ( column_alias [, ...] ) ] ]
                [ TABLESAMPLE sampling_method ( argument [, ...] ) [ REPEATABLE ( seed ) ] ]
    [ LATERAL ] ( select ) [ [ AS ] alias [ ( column_alias [, ...] ) ] ]
    with_query_name [ [ AS ] alias [ ( column_alias [, ...] ) ] ]
    [ LATERAL ] function_name ( [ argument [, ...] ] )
                [ WITH ORDINALITY ] [ [ AS ] alias [ ( column_alias [, ...] ) ] ]
    [ LATERAL ] function_name ( [ argument [, ...] ] ) [ AS ] alias ( column_definition [, ...] )
    [ LATERAL ] function_name ( [ argument [, ...] ] ) AS ( column_definition [, ...] )
    [ LATERAL ] ROWS FROM( function_name ( [ argument [, ...] ] ) [ AS ( column_definition [, ...] ) ] [, ...] )
                [ WITH ORDINALITY ] [ [ AS ] alias [ ( column_alias [, ...] ) ] ]
    from_item join_type from_item { ON join_condition | USING ( join_column [, ...] ) [ AS join_using_alias ] }
    from_item NATURAL join_type from_item
    from_item CROSS JOIN from_item

and grouping_element can be one of:

    ( )
    expression
    ( expression [, ...] )
    ROLLUP ( { expression | ( expression [, ...] ) } [, ...] )
    CUBE ( { expression | ( expression [, ...] ) } [, ...] )
    GROUPING SETS ( grouping_element [, ...] )

and with_query is:

    with_query_name [ ( column_name [, ...] ) ] AS [ [ NOT ] MATERIALIZED ] ( select | values | insert | update | delete )
        [ SEARCH { BREADTH | DEPTH } FIRST BY column_name [, ...] SET search_seq_col_name ]
        [ CYCLE column_name [, ...] SET cycle_mark_col_name [ TO cycle_mark_value DEFAULT cycle_mark_default ] USING cycle_path_col_name ]

TABLE [ ONLY ] table_name [ * ]

DESCRIPTION

SELECT retrieves rows from zero or more tables. The general processing of SELECT is as follows:

1.

All queries in the WITH list are computed. These effectively serve as temporary tables that can be referenced in the FROM list. A WITH query that is referenced more than once in FROM is computed only once, unless specified otherwise with NOT MATERIALIZED. (See WITH Clause below.)

2.

All elements in the FROM list are computed. (Each element in the FROM list is a real or virtual table.) If more than one element is specified in the FROM list, they are cross-joined together. (See FROM Clause below.)

3.

If the WHERE clause is specified, all rows that do not satisfy the condition are eliminated from the output. (See WHERE Clause below.)

4.

If the GROUP BY clause is specified, or if there are aggregate function calls, the output is combined into groups of rows that match on one or more values, and the results of aggregate functions are computed. If the HAVING clause is present, it eliminates groups that do not satisfy the given condition. (See GROUP BY Clause and HAVING Clause below.) Although query output columns are nominally computed in the next step, they can also be referenced (by name or ordinal number) in the GROUP BY clause.

5.

The actual output rows are computed using the SELECT output expressions for each selected row or row group. (See SELECT List below.)

6.

SELECT DISTINCT eliminates duplicate rows from the result. SELECT DISTINCT ON eliminates rows that match on all the specified expressions. SELECT ALL (the default) will return all candidate rows, including duplicates. (See DISTINCT Clause below.)

7.

Using the operators UNION, INTERSECT, and EXCEPT, the output of more than one SELECT statement can be combined to form a single result set. The UNION operator returns all rows that are in one or both of the result sets. The INTERSECT operator returns all rows that are strictly in both result sets. The EXCEPT operator returns the rows that are in the first result set but not in the second. In all three cases, duplicate rows are eliminated unless ALL is specified. The noise word DISTINCT can be added to explicitly specify eliminating duplicate rows. Notice that DISTINCT is the default behavior here, even though ALL is the default for SELECT itself. (See UNION Clause, INTERSECT Clause, and EXCEPT Clause below.)

8.

If the ORDER BY clause is specified, the returned rows are sorted in the specified order. If ORDER BY is not given, the rows are returned in whatever order the system finds fastest to produce. (See ORDER BY Clause below.)

9.

If the LIMIT (or FETCH FIRST) or OFFSET clause is specified, the SELECT statement only returns a subset of the result rows. (See LIMIT Clause below.)

10.

If FOR UPDATE, FOR NO KEY UPDATE, FOR SHARE or FOR KEY SHARE is specified, the SELECT statement locks the selected rows against concurrent updates. (See The Locking Clause below.)

You must have SELECT privilege on each column used in a SELECT command. The use of FOR NO KEY UPDATE, FOR UPDATE, FOR SHARE or FOR KEY SHARE requires UPDATE privilege as well (for at least one column of each table so selected).

PARAMETERS

WITH Clause

The WITH clause allows you to specify one or more subqueries that can be referenced by name in the primary query. The subqueries effectively act as temporary tables or views for the duration of the primary query. Each subquery can be a SELECT, TABLE, VALUES, INSERT, UPDATE or DELETE statement. When writing a data-modifying statement (INSERT, UPDATE or DELETE) in WITH, it is usual to include a RETURNING clause. It is the output of RETURNING, not the underlying table that the statement modifies, that forms the temporary table that is read by the primary query. If RETURNING is omitted, the statement is still executed, but it produces no output so it cannot be referenced as a table by the primary query.

A name (without schema qualification) must be specified for each WITH query. Optionally, a list of column names can be specified; if this is omitted, the column names are inferred from the subquery.

If RECURSIVE is specified, it allows a SELECT subquery to reference itself by name. Such a subquery must have the form

non_recursive_term UNION [ ALL | DISTINCT ] recursive_term

where the recursive self-reference must appear on the right-hand side of the UNION. Only one recursive self-reference is permitted per query. Recursive data-modifying statements are not supported, but you can use the results of a recursive SELECT query in a data-modifying statement. See Section 7.8 for an example.

Another effect of RECURSIVE is that WITH queries need not be ordered: a query can reference another one that is later in the list. (However, circular references, or mutual recursion, are not implemented.) Without RECURSIVE, WITH queries can only reference sibling WITH queries that are earlier in the WITH list.

When there are multiple queries in the WITH clause, RECURSIVE should be written only once, immediately after WITH. It applies to all queries in the WITH clause, though it has no effect on queries that do not use recursion or forward references.

The optional SEARCH clause computes a search sequence column that can be used for ordering the results of a recursive query in either breadth-first or depth-first order. The supplied column name list specifies the row key that is to be used for keeping track of visited rows. A column named search_seq_col_name will be added to the result column list of the WITH query. This column can be ordered by in the outer query to achieve the respective ordering. See Section 7.8.2.1 for examples.

The optional CYCLE clause is used to detect cycles in recursive queries. The supplied column name list specifies the row key that is to be used for keeping track of visited rows. A column named cycle_mark_col_name will be added to the result column list of the WITH query. This column will be set to cycle_mark_value when a cycle has been detected, else to cycle_mark_default. Furthermore, processing of the recursive union will stop when a cycle has been detected. cycle_mark_value and cycle_mark_default must be constants and they must be coercible to a common data type, and the data type must have an inequality operator. (The SQL standard requires that they be Boolean constants or character strings, but PostgreSQL does not require that.) By default, TRUE and FALSE (of type boolean) are used. Furthermore, a column named cycle_path_col_name will be added to the result column list of the WITH query. This column is used internally for tracking visited rows. See Section 7.8.2.2 for examples.

Both the SEARCH and the CYCLE clause are only valid for recursive WITH queries. The with_query must be a UNION (or UNION ALL) of two SELECT (or equivalent) commands (no nested UNIONs). If both clauses are used, the column added by the SEARCH clause appears before the columns added by the CYCLE clause.

The primary query and the WITH queries are all (notionally) executed at the same time. This implies that the effects of a data-modifying statement in WITH cannot be seen from other parts of the query, other than by reading its RETURNING output. If two such data-modifying statements attempt to modify the same row, the results are unspecified.

A key property of WITH queries is that they are normally evaluated only once per execution of the primary query, even if the primary query refers to them more than once. In particular, data-modifying statements are guaranteed to be executed once and only once, regardless of whether the primary query reads all or any of their output.

However, a WITH query can be marked NOT MATERIALIZED to remove this guarantee. In that case, the WITH query can be folded into the primary query much as though it were a simple sub-SELECT in the primary querys FROM clause. This results in duplicate computations if the primary query refers to that WITH query more than once; but if each such use requires only a few rows of the WITH querys total output, NOT MATERIALIZED can provide a net savings by allowing the queries to be optimized jointly. NOT MATERIALIZED is ignored if it is attached to a WITH query that is recursive or is not side-effect-free (i.e., is not a plain SELECT containing no volatile functions).

By default, a side-effect-free WITH query is folded into the primary query if it is used exactly once in the primary querys FROM clause. This allows joint optimization of the two query levels in situations where that should be semantically invisible. However, such folding can be prevented by marking the WITH query as MATERIALIZED. That might be useful, for example, if the WITH query is being used as an optimization fence to prevent the planner from choosing a bad plan. PostgreSQL versions before v12 never did such folding, so queries written for older versions might rely on WITH to act as an optimization fence.

See Section 7.8 for additional information.

FROM Clause

The FROM clause specifies one or more source tables for the SELECT. If multiple sources are specified, the result is the Cartesian product (cross join) of all the sources. But usually qualification conditions are added (via WHERE) to restrict the returned rows to a small subset of the Cartesian product.

The FROM clause can contain the following elements:

table_name

The name (optionally schema-qualified) of an existing table or view. If ONLY is specified before the table name, only that table is scanned. If ONLY is not specified, the table and all its descendant tables (if any) are scanned. Optionally, * can be specified after the table name to explicitly indicate that descendant tables are included.

alias

A substitute name for the FROM item containing the alias. An alias is used for brevity or to eliminate ambiguity for self-joins (where the same table is scanned multiple times). When an alias is provided, it completely hides the actual name of the table or function; for example given FROM foo AS f, the remainder of the SELECT must refer to this FROM item as f not foo. If an alias is written, a column alias list can also be written to provide substitute names for one or more columns of the table.

TABLESAMPLE sampling_method ( argument [, …] ) [ REPEATABLE ( seed ) ]

A TABLESAMPLE clause after a table_name indicates that the specified sampling_method should be used to retrieve a subset of the rows in that table. This sampling precedes the application of any other filters such as WHERE clauses. The standard PostgreSQL distribution includes two sampling methods, BERNOULLI and SYSTEM, and other sampling methods can be installed in the database via extensions.

The BERNOULLI and SYSTEM sampling methods each accept a single argument which is the fraction of the table to sample, expressed as a percentage between 0 and 100. This argument can be any real-valued expression. (Other sampling methods might accept more or different arguments.) These two methods each return a randomly-chosen sample of the table that will contain approximately the specified percentage of the tables rows. The BERNOULLI method scans the whole table and selects or ignores individual rows independently with the specified probability. The SYSTEM method does block-level sampling with each block having the specified chance of being selected; all rows in each selected block are returned. The SYSTEM method is significantly faster than the BERNOULLI method when small sampling percentages are specified, but it may return a less-random sample of the table as a result of clustering effects.

The optional REPEATABLE clause specifies a seed number or expression to use for generating random numbers within the sampling method. The seed value can be any non-null floating-point value. Two queries that specify the same seed and argument values will select the same sample of the table, if the table has not been changed meanwhile. But different seed values will usually produce different samples. If REPEATABLE is not given then a new random sample is selected for each query, based upon a system-generated seed. Note that some add-on sampling methods do not accept REPEATABLE, and will always produce new samples on each use.

select

A sub-SELECT can appear in the FROM clause. This acts as though its output were created as a temporary table for the duration of this single SELECT command. Note that the sub-SELECT must be surrounded by parentheses, and an alias can be provided in the same way as for a table. A VALUES command can also be used here.

with_query_name

A WITH query is referenced by writing its name, just as though the querys name were a table name. (In fact, the WITH query hides any real table of the same name for the purposes of the primary query. If necessary, you can refer to a real table of the same name by schema-qualifying the tables name.) An alias can be provided in the same way as for a table.

function_name

Function calls can appear in the FROM clause. (This is especially useful for functions that return result sets, but any function can be used.) This acts as though the functions output were created as a temporary table for the duration of this single SELECT command. If the functions result type is composite (including the case of a function with multiple OUT parameters), each attribute becomes a separate column in the implicit table.

When the optional WITH ORDINALITY clause is added to the function call, an additional column of type bigint will be appended to the functions result column(s). This column numbers the rows of the functions result set, starting from 1. By default, this column is named ordinality.

An alias can be provided in the same way as for a table. If an alias is written, a column alias list can also be written to provide substitute names for one or more attributes of the functions composite return type, including the ordinality column if present.

Multiple function calls can be combined into a single FROM-clause item by surrounding them with ROWS FROM( … ). The output of such an item is the concatenation of the first row from each function, then the second row from each function, etc. If some of the functions produce fewer rows than others, null values are substituted for the missing data, so that the total number of rows returned is always the same as for the function that produced the most rows.

If the function has been defined as returning the record data type, then an alias or the key word AS must be present, followed by a column definition list in the form ( column_name data_type [, … ]). The column definition list must match the actual number and types of columns returned by the function.

When using the ROWS FROM( … ) syntax, if one of the functions requires a column definition list, its preferred to put the column definition list after the function call inside ROWS FROM( … ). A column definition list can be placed after the ROWS FROM( … ) construct only if theres just a single function and no WITH ORDINALITY clause.

To use ORDINALITY together with a column definition list, you must use the ROWS FROM( … ) syntax and put the column definition list inside ROWS FROM( … ).

join_type

One of

·

[ INNER ] JOIN

·

LEFT [ OUTER ] JOIN

·

RIGHT [ OUTER ] JOIN

·

FULL [ OUTER ] JOIN

For the INNER and OUTER join types, a join condition must be specified, namely exactly one of ON join_condition, USING (join_column [, …]), or NATURAL. See below for the meaning.

A JOIN clause combines two FROM items, which for convenience we will refer to as “tables”, though in reality they can be any type of FROM item. Use parentheses if necessary to determine the order of nesting. In the absence of parentheses, JOINs nest left-to-right. In any case JOIN binds more tightly than the commas separating FROM-list items. All the JOIN options are just a notational convenience, since they do nothing you couldnt do with plain FROM and WHERE.

LEFT OUTER JOIN returns all rows in the qualified Cartesian product (i.e., all combined rows that pass its join condition), plus one copy of each row in the left-hand table for which there was no right-hand row that passed the join condition. This left-hand row is extended to the full width of the joined table by inserting null values for the right-hand columns. Note that only the JOIN clauses own condition is considered while deciding which rows have matches. Outer conditions are applied afterwards.

Conversely, RIGHT OUTER JOIN returns all the joined rows, plus one row for each unmatched right-hand row (extended with nulls on the left). This is just a notational convenience, since you could convert it to a LEFT OUTER JOIN by switching the left and right tables.

FULL OUTER JOIN returns all the joined rows, plus one row for each unmatched left-hand row (extended with nulls on the right), plus one row for each unmatched right-hand row (extended with nulls on the left).

ON join_condition

join_condition is an expression resulting in a value of type boolean (similar to a WHERE clause) that specifies which rows in a join are considered to match.

USING ( join_column [, …] ) [ AS join_using_alias ]

A clause of the form USING ( a, b, … ) is shorthand for ON left_table.a = right_table.a AND left_table.b = right_table.b …. Also, USING implies that only one of each pair of equivalent columns will be included in the join output, not both.

If a join_using_alias name is specified, it provides a table alias for the join columns. Only the join columns listed in the USING clause are addressable by this name. Unlike a regular alias, this does not hide the names of the joined tables from the rest of the query. Also unlike a regular alias, you cannot write a column alias list — the output names of the join columns are the same as they appear in the USING list.

NATURAL

NATURAL is shorthand for a USING list that mentions all columns in the two tables that have matching names. If there are no common column names, NATURAL is equivalent to ON TRUE.

CROSS JOIN

CROSS JOIN is equivalent to INNER JOIN ON (TRUE), that is, no rows are removed by qualification. They produce a simple Cartesian product, the same result as you get from listing the two tables at the top level of FROM, but restricted by the join condition (if any).

LATERAL

The LATERAL key word can precede a sub-SELECT FROM item. This allows the sub-SELECT to refer to columns of FROM items that appear before it in the FROM list. (Without LATERAL, each sub-SELECT is evaluated independently and so cannot cross-reference any other FROM item.)

LATERAL can also precede a function-call FROM item, but in this case it is a noise word, because the function expression can refer to earlier FROM items in any case.

A LATERAL item can appear at top level in the FROM list, or within a JOIN tree. In the latter case it can also refer to any items that are on the left-hand side of a JOIN that it is on the right-hand side of.

When a FROM item contains LATERAL cross-references, evaluation proceeds as follows: for each row of the FROM item providing the cross-referenced column(s), or set of rows of multiple FROM items providing the columns, the LATERAL item is evaluated using that row or row sets values of the columns. The resulting row(s) are joined as usual with the rows they were computed from. This is repeated for each row or set of rows from the column source table(s).

The column source table(s) must be INNER or LEFT joined to the LATERAL item, else there would not be a well-defined set of rows from which to compute each set of rows for the LATERAL item. Thus, although a construct such as X RIGHT JOIN LATERAL Y is syntactically valid, it is not actually allowed for Y to reference X.

WHERE Clause

The optional WHERE clause has the general form

WHERE condition

where condition is any expression that evaluates to a result of type boolean. Any row that does not satisfy this condition will be eliminated from the output. A row satisfies the condition if it returns true when the actual row values are substituted for any variable references.

GROUP BY Clause

The optional GROUP BY clause has the general form

GROUP BY [ ALL | DISTINCT ] grouping_element [, …]

GROUP BY will condense into a single row all selected rows that share the same values for the grouped expressions. An expression used inside a grouping_element can be an input column name, or the name or ordinal number of an output column (SELECT list item), or an arbitrary expression formed from input-column values. In case of ambiguity, a GROUP BY name will be interpreted as an input-column name rather than an output column name.

If any of GROUPING SETS, ROLLUP or CUBE are present as grouping elements, then the GROUP BY clause as a whole defines some number of independent grouping sets. The effect of this is equivalent to constructing a UNION ALL between subqueries with the individual grouping sets as their GROUP BY clauses. The optional DISTINCT clause removes duplicate sets before processing; it does not transform the UNION ALL into a UNION DISTINCT. For further details on the handling of grouping sets see Section 7.2.4.

Aggregate functions, if any are used, are computed across all rows making up each group, producing a separate value for each group. (If there are aggregate functions but no GROUP BY clause, the query is treated as having a single group comprising all the selected rows.) The set of rows fed to each aggregate function can be further filtered by attaching a FILTER clause to the aggregate function call; see Section 4.2.7 for more information. When a FILTER clause is present, only those rows matching it are included in the input to that aggregate function.

When GROUP BY is present, or any aggregate functions are present, it is not valid for the SELECT list expressions to refer to ungrouped columns except within aggregate functions or when the ungrouped column is functionally dependent on the grouped columns, since there would otherwise be more than one possible value to return for an ungrouped column. A functional dependency exists if the grouped columns (or a subset thereof) are the primary key of the table containing the ungrouped column.

Keep in mind that all aggregate functions are evaluated before evaluating any “scalar” expressions in the HAVING clause or SELECT list. This means that, for example, a CASE expression cannot be used to skip evaluation of an aggregate function; see Section 4.2.14.

Currently, FOR NO KEY UPDATE, FOR UPDATE, FOR SHARE and FOR KEY SHARE cannot be specified with GROUP BY.

HAVING Clause

The optional HAVING clause has the general form

HAVING condition

where condition is the same as specified for the WHERE clause.

HAVING eliminates group rows that do not satisfy the condition. HAVING is different from WHERE: WHERE filters individual rows before the application of GROUP BY, while HAVING filters group rows created by GROUP BY. Each column referenced in condition must unambiguously reference a grouping column, unless the reference appears within an aggregate function or the ungrouped column is functionally dependent on the grouping columns.

The presence of HAVING turns a query into a grouped query even if there is no GROUP BY clause. This is the same as what happens when the query contains aggregate functions but no GROUP BY clause. All the selected rows are considered to form a single group, and the SELECT list and HAVING clause can only reference table columns from within aggregate functions. Such a query will emit a single row if the HAVING condition is true, zero rows if it is not true.

Currently, FOR NO KEY UPDATE, FOR UPDATE, FOR SHARE and FOR KEY SHARE cannot be specified with HAVING.

WINDOW Clause

The optional WINDOW clause has the general form

WINDOW window_name AS ( window_definition ) [, …]

where window_name is a name that can be referenced from OVER clauses or subsequent window definitions, and window_definition is

[ existing_window_name ] [ PARTITION BY expression [, …] ] [ ORDER BY expression [ ASC | DESC | USING operator ] [ NULLS { FIRST | LAST } ] [, …] ] [ frame_clause ]

If an existing_window_name is specified it must refer to an earlier entry in the WINDOW list; the new window copies its partitioning clause from that entry, as well as its ordering clause if any. In this case the new window cannot specify its own PARTITION BY clause, and it can specify ORDER BY only if the copied window does not have one. The new window always uses its own frame clause; the copied window must not specify a frame clause.

The elements of the PARTITION BY list are interpreted in much the same fashion as elements of a GROUP BY clause, except that they are always simple expressions and never the name or number of an output column. Another difference is that these expressions can contain aggregate function calls, which are not allowed in a regular GROUP BY clause. They are allowed here because windowing occurs after grouping and aggregation.

Similarly, the elements of the ORDER BY list are interpreted in much the same fashion as elements of a statement-level ORDER BY clause, except that the expressions are always taken as simple expressions and never the name or number of an output column.

The optional frame_clause defines the window frame for window functions that depend on the frame (not all do). The window frame is a set of related rows for each row of the query (called the current row). The frame_clause can be one of

{ RANGE | ROWS | GROUPS } frame_start [ frame_exclusion ] { RANGE | ROWS | GROUPS } BETWEEN frame_start AND frame_end [ frame_exclusion ]

where frame_start and frame_end can be one of

UNBOUNDED PRECEDING offset PRECEDING CURRENT ROW offset FOLLOWING UNBOUNDED FOLLOWING

and frame_exclusion can be one of

EXCLUDE CURRENT ROW EXCLUDE GROUP EXCLUDE TIES EXCLUDE NO OTHERS

If frame_end is omitted it defaults to CURRENT ROW. Restrictions are that frame_start cannot be UNBOUNDED FOLLOWING, frame_end cannot be UNBOUNDED PRECEDING, and the frame_end choice cannot appear earlier in the above list of frame_start and frame_end options than the frame_start choice does — for example RANGE BETWEEN CURRENT ROW AND offset PRECEDING is not allowed.

The default framing option is RANGE UNBOUNDED PRECEDING, which is the same as RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW; it sets the frame to be all rows from the partition start up through the current rows last peer (a row that the windows ORDER BY clause considers equivalent to the current row; all rows are peers if there is no ORDER BY). In general, UNBOUNDED PRECEDING means that the frame starts with the first row of the partition, and similarly UNBOUNDED FOLLOWING means that the frame ends with the last row of the partition, regardless of RANGE, ROWS or GROUPS mode. In ROWS mode, CURRENT ROW means that the frame starts or ends with the current row; but in RANGE or GROUPS mode it means that the frame starts or ends with the current rows first or last peer in the ORDER BY ordering. The offset PRECEDING and offset FOLLOWING options vary in meaning depending on the frame mode. In ROWS mode, the offset is an integer indicating that the frame starts or ends that many rows before or after the current row. In GROUPS mode, the offset is an integer indicating that the frame starts or ends that many peer groups before or after the current rows peer group, where a peer group is a group of rows that are equivalent according to the windows ORDER BY clause. In RANGE mode, use of an offset option requires that there be exactly one ORDER BY column in the window definition. Then the frame contains those rows whose ordering column value is no more than offset less than (for PRECEDING) or more than (for FOLLOWING) the current rows ordering column value. In these cases the data type of the offset expression depends on the data type of the ordering column. For numeric ordering columns it is typically of the same type as the ordering column, but for datetime ordering columns it is an interval. In all these cases, the value of the offset must be non-null and non-negative. Also, while the offset does not have to be a simple constant, it cannot contain variables, aggregate functions, or window functions.

The frame_exclusion option allows rows around the current row to be excluded from the frame, even if they would be included according to the frame start and frame end options. EXCLUDE CURRENT ROW excludes the current row from the frame. EXCLUDE GROUP excludes the current row and its ordering peers from the frame. EXCLUDE TIES excludes any peers of the current row from the frame, but not the current row itself. EXCLUDE NO OTHERS simply specifies explicitly the default behavior of not excluding the current row or its peers.

Beware that the ROWS mode can produce unpredictable results if the ORDER BY ordering does not order the rows uniquely. The RANGE and GROUPS modes are designed to ensure that rows that are peers in the ORDER BY ordering are treated alike: all rows of a given peer group will be in the frame or excluded from it.

The purpose of a WINDOW clause is to specify the behavior of window functions appearing in the querys SELECT list or ORDER BY clause. These functions can reference the WINDOW clause entries by name in their OVER clauses. A WINDOW clause entry does not have to be referenced anywhere, however; if it is not used in the query it is simply ignored. It is possible to use window functions without any WINDOW clause at all, since a window function call can specify its window definition directly in its OVER clause. However, the WINDOW clause saves typing when the same window definition is needed for more than one window function.

Currently, FOR NO KEY UPDATE, FOR UPDATE, FOR SHARE and FOR KEY SHARE cannot be specified with WINDOW.

Window functions are described in detail in Section 3.5, Section 4.2.8, and Section 7.2.5.

SELECT List

The SELECT list (between the key words SELECT and FROM) specifies expressions that form the output rows of the SELECT statement. The expressions can (and usually do) refer to columns computed in the FROM clause.

Just as in a table, every output column of a SELECT has a name. In a simple SELECT this name is just used to label the column for display, but when the SELECT is a sub-query of a larger query, the name is seen by the larger query as the column name of the virtual table produced by the sub-query. To specify the name to use for an output column, write AS output_name after the columns expression. (You can omit AS, but only if the desired output name does not match any PostgreSQL keyword (see Appendix C). For protection against possible future keyword additions, it is recommended that you always either write AS or double-quote the output name.) If you do not specify a column name, a name is chosen automatically by PostgreSQL. If the columns expression is a simple column reference then the chosen name is the same as that columns name. In more complex cases a function or type name may be used, or the system may fall back on a generated name such as ?column?.

An output columns name can be used to refer to the columns value in ORDER BY and GROUP BY clauses, but not in the WHERE or HAVING clauses; there you must write out the expression instead.

Instead of an expression, * can be written in the output list as a shorthand for all the columns of the selected rows. Also, you can write table_name.* as a shorthand for the columns coming from just that table. In these cases it is not possible to specify new names with AS; the output column names will be the same as the table columns names.

According to the SQL standard, the expressions in the output list should be computed before applying DISTINCT, ORDER BY, or LIMIT. This is obviously necessary when using DISTINCT, since otherwise its not clear what values are being made distinct. However, in many cases it is convenient if output expressions are computed after ORDER BY and LIMIT; particularly if the output list contains any volatile or expensive functions. With that behavior, the order of function evaluations is more intuitive and there will not be evaluations corresponding to rows that never appear in the output. PostgreSQL will effectively evaluate output expressions after sorting and limiting, so long as those expressions are not referenced in DISTINCT, ORDER BY or GROUP BY. (As a counterexample, SELECT f(x) FROM tab ORDER BY 1 clearly must evaluate f(x) before sorting.) Output expressions that contain set-returning functions are effectively evaluated after sorting and before limiting, so that LIMIT will act to cut off the output from a set-returning function.

Note

PostgreSQL versions before 9.6 did not provide any guarantees about the timing of evaluation of output expressions versus sorting and limiting; it depended on the form of the chosen query plan.

DISTINCT Clause

If SELECT DISTINCT is specified, all duplicate rows are removed from the result set (one row is kept from each group of duplicates). SELECT ALL specifies the opposite: all rows are kept; that is the default.

SELECT DISTINCT ON ( expression [, …] ) keeps only the first row of each set of rows where the given expressions evaluate to equal. The DISTINCT ON expressions are interpreted using the same rules as for ORDER BY (see above). Note that the “first row” of each set is unpredictable unless ORDER BY is used to ensure that the desired row appears first. For example:

SELECT DISTINCT ON (location) location, time, report FROM weather_reports ORDER BY location, time DESC;

retrieves the most recent weather report for each location. But if we had not used ORDER BY to force descending order of time values for each location, wed have gotten a report from an unpredictable time for each location.

The DISTINCT ON expression(s) must match the leftmost ORDER BY expression(s). The ORDER BY clause will normally contain additional expression(s) that determine the desired precedence of rows within each DISTINCT ON group.

Currently, FOR NO KEY UPDATE, FOR UPDATE, FOR SHARE and FOR KEY SHARE cannot be specified with DISTINCT.

UNION Clause

The UNION clause has this general form:

select_statement UNION [ ALL | DISTINCT ] select_statement

select_statement is any SELECT statement without an ORDER BY, LIMIT, FOR NO KEY UPDATE, FOR UPDATE, FOR SHARE, or FOR KEY SHARE clause. (ORDER BY and LIMIT can be attached to a subexpression if it is enclosed in parentheses. Without parentheses, these clauses will be taken to apply to the result of the UNION, not to its right-hand input expression.)

The UNION operator computes the set union of the rows returned by the involved SELECT statements. A row is in the set union of two result sets if it appears in at least one of the result sets. The two SELECT statements that represent the direct operands of the UNION must produce the same number of columns, and corresponding columns must be of compatible data types.

The result of UNION does not contain any duplicate rows unless the ALL option is specified. ALL prevents elimination of duplicates. (Therefore, UNION ALL is usually significantly quicker than UNION; use ALL when you can.) DISTINCT can be written to explicitly specify the default behavior of eliminating duplicate rows.

Multiple UNION operators in the same SELECT statement are evaluated left to right, unless otherwise indicated by parentheses.

Currently, FOR NO KEY UPDATE, FOR UPDATE, FOR SHARE and FOR KEY SHARE cannot be specified either for a UNION result or for any input of a UNION.

INTERSECT Clause

The INTERSECT clause has this general form:

select_statement INTERSECT [ ALL | DISTINCT ] select_statement

select_statement is any SELECT statement without an ORDER BY, LIMIT, FOR NO KEY UPDATE, FOR UPDATE, FOR SHARE, or FOR KEY SHARE clause.

The INTERSECT operator computes the set intersection of the rows returned by the involved SELECT statements. A row is in the intersection of two result sets if it appears in both result sets.

The result of INTERSECT does not contain any duplicate rows unless the ALL option is specified. With ALL, a row that has m duplicates in the left table and n duplicates in the right table will appear min(m,n) times in the result set. DISTINCT can be written to explicitly specify the default behavior of eliminating duplicate rows.

Multiple INTERSECT operators in the same SELECT statement are evaluated left to right, unless parentheses dictate otherwise. INTERSECT binds more tightly than UNION. That is, A UNION B INTERSECT C will be read as A UNION (B INTERSECT C).

Currently, FOR NO KEY UPDATE, FOR UPDATE, FOR SHARE and FOR KEY SHARE cannot be specified either for an INTERSECT result or for any input of an INTERSECT.

EXCEPT Clause

The EXCEPT clause has this general form:

select_statement EXCEPT [ ALL | DISTINCT ] select_statement

select_statement is any SELECT statement without an ORDER BY, LIMIT, FOR NO KEY UPDATE, FOR UPDATE, FOR SHARE, or FOR KEY SHARE clause.

The EXCEPT operator computes the set of rows that are in the result of the left SELECT statement but not in the result of the right one.

The result of EXCEPT does not contain any duplicate rows unless the ALL option is specified. With ALL, a row that has m duplicates in the left table and n duplicates in the right table will appear max(m-n,0) times in the result set. DISTINCT can be written to explicitly specify the default behavior of eliminating duplicate rows.

Multiple EXCEPT operators in the same SELECT statement are evaluated left to right, unless parentheses dictate otherwise. EXCEPT binds at the same level as UNION.

Currently, FOR NO KEY UPDATE, FOR UPDATE, FOR SHARE and FOR KEY SHARE cannot be specified either for an EXCEPT result or for any input of an EXCEPT.

ORDER BY Clause

The optional ORDER BY clause has this general form:

ORDER BY expression [ ASC | DESC | USING operator ] [ NULLS { FIRST | LAST } ] [, …]

The ORDER BY clause causes the result rows to be sorted according to the specified expression(s). If two rows are equal according to the leftmost expression, they are compared according to the next expression and so on. If they are equal according to all specified expressions, they are returned in an implementation-dependent order.

Each expression can be the name or ordinal number of an output column (SELECT list item), or it can be an arbitrary expression formed from input-column values.

The ordinal number refers to the ordinal (left-to-right) position of the output column. This feature makes it possible to define an ordering on the basis of a column that does not have a unique name. This is never absolutely necessary because it is always possible to assign a name to an output column using the AS clause.

It is also possible to use arbitrary expressions in the ORDER BY clause, including columns that do not appear in the SELECT output list. Thus the following statement is valid:

SELECT name FROM distributors ORDER BY code;

A limitation of this feature is that an ORDER BY clause applying to the result of a UNION, INTERSECT, or EXCEPT clause can only specify an output column name or number, not an expression.

If an ORDER BY expression is a simple name that matches both an output column name and an input column name, ORDER BY will interpret it as the output column name. This is the opposite of the choice that GROUP BY will make in the same situation. This inconsistency is made to be compatible with the SQL standard.

Optionally one can add the key word ASC (ascending) or DESC (descending) after any expression in the ORDER BY clause. If not specified, ASC is assumed by default. Alternatively, a specific ordering operator name can be specified in the USING clause. An ordering operator must be a less-than or greater-than member of some B-tree operator family. ASC is usually equivalent to USING < and DESC is usually equivalent to USING >. (But the creator of a user-defined data type can define exactly what the default sort ordering is, and it might correspond to operators with other names.)

If NULLS LAST is specified, null values sort after all non-null values; if NULLS FIRST is specified, null values sort before all non-null values. If neither is specified, the default behavior is NULLS LAST when ASC is specified or implied, and NULLS FIRST when DESC is specified (thus, the default is to act as though nulls are larger than non-nulls). When USING is specified, the default nulls ordering depends on whether the operator is a less-than or greater-than operator.

Note that ordering options apply only to the expression they follow; for example ORDER BY x, y DESC does not mean the same thing as ORDER BY x DESC, y DESC.

Character-string data is sorted according to the collation that applies to the column being sorted. That can be overridden at need by including a COLLATE clause in the expression, for example ORDER BY mycolumn COLLATE “en_US”. For more information see Section 4.2.10 and Section 24.2.

LIMIT Clause

The LIMIT clause consists of two independent sub-clauses:

LIMIT { count | ALL } OFFSET start

The parameter count specifies the maximum number of rows to return, while start specifies the number of rows to skip before starting to return rows. When both are specified, start rows are skipped before starting to count the count rows to be returned.

If the count expression evaluates to NULL, it is treated as LIMIT ALL, i.e., no limit. If start evaluates to NULL, it is treated the same as OFFSET 0.

SQL:2008 introduced a different syntax to achieve the same result, which PostgreSQL also supports. It is:

OFFSET start { ROW | ROWS } FETCH { FIRST | NEXT } [ count ] { ROW | ROWS } { ONLY | WITH TIES }

In this syntax, the start or count value is required by the standard to be a literal constant, a parameter, or a variable name; as a PostgreSQL extension, other expressions are allowed, but will generally need to be enclosed in parentheses to avoid ambiguity. If count is omitted in a FETCH clause, it defaults to 1. The WITH TIES option is used to return any additional rows that tie for the last place in the result set according to the ORDER BY clause; ORDER BY is mandatory in this case, and SKIP LOCKED is not allowed. ROW and ROWS as well as FIRST and NEXT are noise words that dont influence the effects of these clauses. According to the standard, the OFFSET clause must come before the FETCH clause if both are present; but PostgreSQL is laxer and allows either order.

When using LIMIT, it is a good idea to use an ORDER BY clause that constrains the result rows into a unique order. Otherwise you will get an unpredictable subset of the querys rows — you might be asking for the tenth through twentieth rows, but tenth through twentieth in what ordering? You dont know what ordering unless you specify ORDER BY.

The query planner takes LIMIT into account when generating a query plan, so you are very likely to get different plans (yielding different row orders) depending on what you use for LIMIT and OFFSET. Thus, using different LIMIT/OFFSET values to select different subsets of a query result will give inconsistent results unless you enforce a predictable result ordering with ORDER BY. This is not a bug; it is an inherent consequence of the fact that SQL does not promise to deliver the results of a query in any particular order unless ORDER BY is used to constrain the order.

It is even possible for repeated executions of the same LIMIT query to return different subsets of the rows of a table, if there is not an ORDER BY to enforce selection of a deterministic subset. Again, this is not a bug; determinism of the results is simply not guaranteed in such a case.

The Locking Clause

FOR UPDATE, FOR NO KEY UPDATE, FOR SHARE and FOR KEY SHARE are locking clauses; they affect how SELECT locks rows as they are obtained from the table.

The locking clause has the general form

FOR lock_strength [ OF table_name [, …] ] [ NOWAIT | SKIP LOCKED ]

where lock_strength can be one of

UPDATE NO KEY UPDATE SHARE KEY SHARE

For more information on each row-level lock mode, refer to Section 13.3.2.

To prevent the operation from waiting for other transactions to commit, use either the NOWAIT or SKIP LOCKED option. With NOWAIT, the statement reports an error, rather than waiting, if a selected row cannot be locked immediately. With SKIP LOCKED, any selected rows that cannot be immediately locked are skipped. Skipping locked rows provides an inconsistent view of the data, so this is not suitable for general purpose work, but can be used to avoid lock contention with multiple consumers accessing a queue-like table. Note that NOWAIT and SKIP LOCKED apply only to the row-level lock(s) — the required ROW SHARE table-level lock is still taken in the ordinary way (see Chapter 13). You can use LOCK with the NOWAIT option first, if you need to acquire the table-level lock without waiting.

If specific tables are named in a locking clause, then only rows coming from those tables are locked; any other tables used in the SELECT are simply read as usual. A locking clause without a table list affects all tables used in the statement. If a locking clause is applied to a view or sub-query, it affects all tables used in the view or sub-query. However, these clauses do not apply to WITH queries referenced by the primary query. If you want row locking to occur within a WITH query, specify a locking clause within the WITH query.

Multiple locking clauses can be written if it is necessary to specify different locking behavior for different tables. If the same table is mentioned (or implicitly affected) by more than one locking clause, then it is processed as if it was only specified by the strongest one. Similarly, a table is processed as NOWAIT if that is specified in any of the clauses affecting it. Otherwise, it is processed as SKIP LOCKED if that is specified in any of the clauses affecting it.

The locking clauses cannot be used in contexts where returned rows cannot be clearly identified with individual table rows; for example they cannot be used with aggregation.

When a locking clause appears at the top level of a SELECT query, the rows that are locked are exactly those that are returned by the query; in the case of a join query, the rows locked are those that contribute to returned join rows. In addition, rows that satisfied the query conditions as of the query snapshot will be locked, although they will not be returned if they were updated after the snapshot and no longer satisfy the query conditions. If a LIMIT is used, locking stops once enough rows have been returned to satisfy the limit (but note that rows skipped over by OFFSET will get locked). Similarly, if a locking clause is used in a cursors query, only rows actually fetched or stepped past by the cursor will be locked.

When a locking clause appears in a sub-SELECT, the rows locked are those returned to the outer query by the sub-query. This might involve fewer rows than inspection of the sub-query alone would suggest, since conditions from the outer query might be used to optimize execution of the sub-query. For example,

SELECT * FROM (SELECT * FROM mytable FOR UPDATE) ss WHERE col1 = 5;

will lock only rows having col1 = 5, even though that condition is not textually within the sub-query.

Previous releases failed to preserve a lock which is upgraded by a later savepoint. For example, this code:

BEGIN; SELECT * FROM mytable WHERE key = 1 FOR UPDATE; SAVEPOINT s; UPDATE mytable SET … WHERE key = 1; ROLLBACK TO s;

would fail to preserve the FOR UPDATE lock after the ROLLBACK TO. This has been fixed in release 9.3.

Caution

It is possible for a SELECT command running at the READ COMMITTED transaction isolation level and using ORDER BY and a locking clause to return rows out of order. This is because ORDER BY is applied first. The command sorts the result, but might then block trying to obtain a lock on one or more of the rows. Once the SELECT unblocks, some of the ordering column values might have been modified, leading to those rows appearing to be out of order (though they are in order in terms of the original column values). This can be worked around at need by placing the FOR UPDATE/SHARE clause in a sub-query, for example

SELECT * FROM (SELECT * FROM mytable FOR UPDATE) ss ORDER BY column1;

Note that this will result in locking all rows of mytable, whereas FOR UPDATE at the top level would lock only the actually returned rows. This can make for a significant performance difference, particularly if the ORDER BY is combined with LIMIT or other restrictions. So this technique is recommended only if concurrent updates of the ordering columns are expected and a strictly sorted result is required.

At the REPEATABLE READ or SERIALIZABLE transaction isolation level this would cause a serialization failure (with an SQLSTATE of 40001), so there is no possibility of receiving rows out of order under these isolation levels.

TABLE Command

The command

TABLE name

is equivalent to

SELECT * FROM name

It can be used as a top-level command or as a space-saving syntax variant in parts of complex queries. Only the WITH, UNION, INTERSECT, EXCEPT, ORDER BY, LIMIT, OFFSET, FETCH and FOR locking clauses can be used with TABLE; the WHERE clause and any form of aggregation cannot be used.

EXAMPLES

To join the table films with the table distributors:

SELECT f.title, f.did, d.name, f.date_prod, f.kind FROM distributors d JOIN films f USING (did);

       title:     | did |     name     | date_prod  |   kind
-------------------+-----+--------------+------------+----------
 The Third Man     | 101 | British Lion | 1949-12-23 | Drama
 The African Queen | 101 | British Lion | 1951-08-11 | Romantic
 ...

To sum the column len of all films and group the results by kind:

SELECT kind, sum(len) AS total FROM films GROUP BY kind;

   kind   | total
----------+-------
 Action   | 07:34
 Comedy   | 02:58
 Drama    | 14:28
 Musical  | 06:42
 Romantic | 04:38

To sum the column len of all films, group the results by kind and show those group totals that are less than 5 hours:

SELECT kind, sum(len) AS total FROM films GROUP BY kind HAVING sum(len) < interval 5 hours;

   kind   | total
----------+-------
 Comedy   | 02:58
 Romantic | 04:38

The following two examples are identical ways of sorting the individual results according to the contents of the second column (name):

SELECT * FROM distributors ORDER BY name; SELECT * FROM distributors ORDER BY 2;

 did |       name
-----+------------------
 109 | 20th Century Fox
 110 | Bavaria Atelier
 101 | British Lion
 107 | Columbia
 102 | Jean Luc Godard
 113 | Luso films
 104 | Mosfilm
 103 | Paramount
 106 | Toho
 105 | United Artists
 111 | Walt Disney
 112 | Warner Bros.
 108 | Westward

The next example shows how to obtain the union of the tables distributors and actors, restricting the results to those that begin with the letter W in each table. Only distinct rows are wanted, so the key word ALL is omitted.

distributors: actors: did | name id | name —–+————– —-+—————- 108 | Westward 1 | Woody Allen 111 | Walt Disney 2 | Warren Beatty 112 | Warner Bros. 3 | Walter Matthau … …

SELECT distributors.name
    FROM distributors
    WHERE distributors.name LIKE W%
UNION
SELECT actors.name
    FROM actors
    WHERE actors.name LIKE W%;

      name
----------------
 Walt Disney
 Walter Matthau
 Warner Bros.
 Warren Beatty
 Westward
 Woody Allen

This example shows how to use a function in the FROM clause, both with and without a column definition list:

CREATE FUNCTION distributors(int) RETURNS SETOF distributors AS $$ SELECT * FROM distributors WHERE did = $1; $$ LANGUAGE SQL;

SELECT * FROM distributors(111);
 did |    name
-----+-------------
 111 | Walt Disney

CREATE FUNCTION distributors_2(int) RETURNS SETOF record AS $$
    SELECT * FROM distributors WHERE did = $1;
$$ LANGUAGE SQL;

SELECT * FROM distributors_2(111) AS (f1 int, f2 text);
 f1  |     f2
-----+-------------
 111 | Walt Disney

Here is an example of a function with an ordinality column added:

SELECT * FROM unnest(ARRAY[a,b,c,d,e,f]) WITH ORDINALITY; unnest | ordinality ——–+———- a | 1 b | 2 c | 3 d | 4 e | 5 f | 6 (6 rows)

This example shows how to use a simple WITH clause:

WITH t AS ( SELECT random() as x FROM generate_series(1, 3) ) SELECT * FROM t UNION ALL SELECT * FROM t; x ——————– 0.534150459803641 0.520092216785997 0.0735620250925422 0.534150459803641 0.520092216785997 0.0735620250925422

Notice that the WITH query was evaluated only once, so that we got two sets of the same three random values.

This example uses WITH RECURSIVE to find all subordinates (direct or indirect) of the employee Mary, and their level of indirectness, from a table that shows only direct subordinates:

WITH RECURSIVE employee_recursive(distance, employee_name, manager_name) AS ( SELECT 1, employee_name, manager_name FROM employee WHERE manager_name = Mary UNION ALL SELECT er.distance + 1, e.employee_name, e.manager_name FROM employee_recursive er, employee e WHERE er.employee_name = e.manager_name ) SELECT distance, employee_name FROM employee_recursive;

Notice the typical form of recursive queries: an initial condition, followed by UNION, followed by the recursive part of the query. Be sure that the recursive part of the query will eventually return no tuples, or else the query will loop indefinitely. (See Section 7.8 for more examples.)

This example uses LATERAL to apply a set-returning function get_product_names() for each row of the manufacturers table:

SELECT m.name AS mname, pname FROM manufacturers m, LATERAL get_product_names(m.id) pname;

Manufacturers not currently having any products would not appear in the result, since it is an inner join. If we wished to include the names of such manufacturers in the result, we could do:

SELECT m.name AS mname, pname FROM manufacturers m LEFT JOIN LATERAL get_product_names(m.id) pname ON true;

COMPATIBILITY

Of course, the SELECT statement is compatible with the SQL standard. But there are some extensions and some missing features.

Omitted FROM Clauses

PostgreSQL allows one to omit the FROM clause. It has a straightforward use to compute the results of simple expressions:

SELECT 2+2;

 ?column?
----------
        4

Some other SQL databases cannot do this except by introducing a dummy one-row table from which to do the SELECT.

Empty SELECT Lists

The list of output expressions after SELECT can be empty, producing a zero-column result table. This is not valid syntax according to the SQL standard. PostgreSQL allows it to be consistent with allowing zero-column tables. However, an empty list is not allowed when DISTINCT is used.

Omitting the AS Key Word

In the SQL standard, the optional key word AS can be omitted before an output column name whenever the new column name is a valid column name (that is, not the same as any reserved keyword). PostgreSQL is slightly more restrictive: AS is required if the new column name matches any keyword at all, reserved or not. Recommended practice is to use AS or double-quote output column names, to prevent any possible conflict against future keyword additions.

In FROM items, both the standard and PostgreSQL allow AS to be omitted before an alias that is an unreserved keyword. But this is impractical for output column names, because of syntactic ambiguities.

Omitting Sub-SELECT Aliases in FROM

According to the SQL standard, a sub-SELECT in the FROM list must have an alias. In PostgreSQL, this alias may be omitted.

ONLY and Inheritance

The SQL standard requires parentheses around the table name when writing ONLY, for example SELECT * FROM ONLY (tab1), ONLY (tab2) WHERE …. PostgreSQL considers these parentheses to be optional.

PostgreSQL allows a trailing * to be written to explicitly specify the non-ONLY behavior of including child tables. The standard does not allow this.

(These points apply equally to all SQL commands supporting the ONLY option.)

TABLESAMPLE Clause Restrictions

The TABLESAMPLE clause is currently accepted only on regular tables and materialized views. According to the SQL standard it should be possible to apply it to any FROM item.

Function Calls in FROM

PostgreSQL allows a function call to be written directly as a member of the FROM list. In the SQL standard it would be necessary to wrap such a function call in a sub-SELECT; that is, the syntax FROM func(…) alias is approximately equivalent to FROM LATERAL (SELECT func(…)) alias. Note that LATERAL is considered to be implicit; this is because the standard requires LATERAL semantics for an UNNEST() item in FROM. PostgreSQL treats UNNEST() the same as other set-returning functions.

Namespace Available to GROUP BY and ORDER BY

In the SQL-92 standard, an ORDER BY clause can only use output column names or numbers, while a GROUP BY clause can only use expressions based on input column names. PostgreSQL extends each of these clauses to allow the other choice as well (but it uses the standards interpretation if there is ambiguity). PostgreSQL also allows both clauses to specify arbitrary expressions. Note that names appearing in an expression will always be taken as input-column names, not as output-column names.

SQL:1999 and later use a slightly different definition which is not entirely upward compatible with SQL-92. In most cases, however, PostgreSQL will interpret an ORDER BY or GROUP BY expression the same way SQL:1999 does.

Functional Dependencies

PostgreSQL recognizes functional dependency (allowing columns to be omitted from GROUP BY) only when a tables primary key is included in the GROUP BY list. The SQL standard specifies additional conditions that should be recognized.

LIMIT and OFFSET

The clauses LIMIT and OFFSET are PostgreSQL-specific syntax, also used by MySQL. The SQL:2008 standard has introduced the clauses OFFSET … FETCH {FIRST|NEXT} … for the same functionality, as shown above in LIMIT Clause. This syntax is also used by IBM DB2. (Applications written for Oracle frequently use a workaround involving the automatically generated rownum column, which is not available in PostgreSQL, to implement the effects of these clauses.)

FOR NO KEY UPDATE, FOR UPDATE, FOR SHARE, FOR KEY SHARE

Although FOR UPDATE appears in the SQL standard, the standard allows it only as an option of DECLARE CURSOR. PostgreSQL allows it in any SELECT query as well as in sub-SELECTs, but this is an extension. The FOR NO KEY UPDATE, FOR SHARE and FOR KEY SHARE variants, as well as the NOWAIT and SKIP LOCKED options, do not appear in the standard.

Data-Modifying Statements in WITH

PostgreSQL allows INSERT, UPDATE, and DELETE to be used as WITH queries. This is not found in the SQL standard.

Nonstandard Clauses

DISTINCT ON ( … ) is an extension of the SQL standard.

ROWS FROM( … ) is an extension of the SQL standard.

The MATERIALIZED and NOT MATERIALIZED options of WITH are extensions of the SQL standard.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

28 - Linux cli command string_copying

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command string_copying and provides detailed information about the command string_copying, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the string_copying.

NAME 🖥️ string_copying 🖥️

copying strings and character sequences

SYNOPSIS

Strings

// Chain-copy a string.
char *stpcpy(char *restrict dst, const char *restrict src);
// Copy/catenate a string.
char *strcpy(char *restrict dst, const char *restrict src);
char *strcat(char *restrict dst, const char *restrict src);
// Chain-copy a string with truncation.
char *stpecpy(char *dst, char end[0], const char *restrict src);
// Copy/catenate a string with truncation.
ssize_t strtcpy(char dst[restrict .dsize], const char *restrict src,
 size_t dsize);
size_t strlcpy(char dst[restrict .dsize], const char *restrict src,
 size_t dsize);
size_t strlcat(char dst[restrict .dsize], const char *restrict src,
 size_t dsize);

Null-padded character sequences

// Fill a fixed-size buffer with characters from a string
// and pad with null bytes.
char *strncpy(char dst[restrict .dsize], const char *restrict src,
 size_t dsize);
char *stpncpy(char dst[restrict .dsize], const char *restrict src,
 size_t dsize);
// Chain-copy a null-padded character sequence into a character sequence.
mempcpy(dst, src, strnlen(src, NITEMS(src)));
// Chain-copy a null-padded character sequence into a string.
stpcpy(mempcpy(dst, src, strnlen(src, NITEMS(src))), "");
// Catenate a null-padded character sequence into a string.
char *strncat(char *restrict dst, const char src[restrict .ssize],
 size_t ssize);
// Duplicate a null-padded character sequence into a string.
char *strndup(const char src[.ssize], size_t ssize);

Known-length character sequences

// Chain-copy a known-length character sequence.
void *mempcpy(void dst[restrict .len], const void src[restrict .len],
 size_t len);
// Chain-copy a known-length character sequence into a string.
stpcpy(mempcpy(dst, src, len), "");

DESCRIPTION

Terms (and abbreviations)

*string *(str)
is a sequence of zero or more non-null characters followed by a null character.

character sequence
is a sequence of zero or more non-null characters. A program should never use a character sequence where a string is required. However, with appropriate care, a string can be used in the place of a character sequence.

null-padded character sequence
Character sequences can be contained in fixed-size buffers, which contain padding null bytes after the character sequence, to fill the rest of the buffer without affecting the character sequence; however, those padding null bytes are not part of the character sequence. Don’t confuse null-padded with null-terminated: null-padded means 0 or more padding null bytes, while null-terminated means exactly 1 terminating null character.

known-length character sequence
Character sequence delimited by its length. It may be a slice of a larger character sequence, or even of a string.

*length *(len)
is the number of non-null characters in a string or character sequence. It is the return value of strlen(str) and of strnlen(buf, size).

size
refers to the entire buffer where the string or character sequence is contained.

end
is the name of a pointer to one past the last element of a buffer. It is equivalent to &str[size]. It is used as a sentinel value, to be able to truncate strings or character sequences instead of overrunning the containing buffer.

copy
This term is used when the writing starts at the first element pointed to by dst.

catenate
This term is used when a function first finds the terminating null character in dst, and then starts writing at that position.

chain
This term is used when it’s the programmer who provides a pointer to the terminating null character in the string dst (or one after the last character in a character sequence), and the function starts writing at that location. The function returns a pointer to the new location of the terminating null character (or one after the last character in a character sequence) after the call, so that the programmer can use it to chain such calls.

duplicate
Allocate a new buffer where a copy is placed.

Copy, catenate, and chain-copy

Originally, there was a distinction between functions that copy and those that catenate. However, newer functions that copy while allowing chaining cover both use cases with a single API. They are also algorithmically faster, since they don’t need to search for the terminating null character of the existing string. However, functions that catenate have a much simpler use, so if performance is not important, it can make sense to use them for improving readability.

The pointer returned by functions that allow chaining is a byproduct of the copy operation, so it has no performance costs. Functions that return such a pointer, and thus can be chained, have names of the form *stp*(), since it’s common to name the pointer just p.

Chain-copying functions that truncate should accept a pointer to the end of the destination buffer, and have names of the form *stpe*(). This allows not having to recalculate the remaining size after each call.

Truncate or not?

The first thing to note is that programmers should be careful with buffers, so they always have the correct size, and truncation is not necessary.

In most cases, truncation is not desired, and it is simpler to just do the copy. Simpler code is safer code. Programming against programming mistakes by adding more code just adds more points where mistakes can be made.

Nowadays, compilers can detect most programmer errors with features like compiler warnings, static analyzers, and _FORTIFY_SOURCE (see ftm(7)). Keeping the code simple helps these overflow-detection features be more precise.

When validating user input, code should normally not truncate, but instead fail and prevent the copy at all.

In some cases, however, it makes sense to truncate.

Functions that truncate:

  • stpecpy()

  • strtcpy()

  • strlcpy(3bsd) and strlcat(3bsd) are similar, but have important performance problems; see BUGS.

  • stpncpy(3) and strncpy(3) also truncate, but they don’t write strings, but rather null-padded character sequences.

Null-padded character sequences

For historic reasons, some standard APIs and file formats, such as utmpx(5) and tar(1), use null-padded character sequences in fixed-size buffers. To interface with them, specialized functions need to be used.

To copy bytes from strings into these buffers, use strncpy(3) or stpncpy(3).

To read a null-padded character sequence, use strnlen(src, NITEMS(src)), and then you can treat it as a known-length character sequence; or use strncat(3) or strndup(3) directly.

Known-length character sequences

The simplest character sequence copying function is mempcpy(3). It requires always knowing the length of your character sequences, for which structures can be used. It makes the code much faster, since you always know the length of your character sequences, and can do the minimal copies and length measurements. mempcpy(3) copies character sequences, so you need to explicitly set the terminating null character if you need a string.

In programs that make considerable use of strings or character sequences, and need the best performance, using overlapping character sequences can make a big difference. It allows holding subsequences of a larger character sequence, while not duplicating memory nor using time to do a copy.

However, this is delicate, since it requires using character sequences. C library APIs use strings, so programs that use character sequences will have to take care of differentiating strings from character sequences.

To copy a known-length character sequence, use mempcpy(3).

To copy a known-length character sequence into a string, use stpcpy(mempcpy(dst, src, len), “”).

A string is also accepted as input, because mempcpy(3) asks for the length, and a string is composed of a character sequence of the same length plus a terminating null character.

String vs character sequence

Some functions only operate on strings. Those require that the input src is a string, and guarantee an output string (even when truncation occurs). Functions that catenate also require that dst holds a string before the call. List of functions:

stpcpy(3)

  • strcpy(3), strcat(3)

  • stpecpy()

  • strtcpy()

  • strlcpy(3bsd), strlcat(3bsd)

Other functions require an input string, but create a character sequence as output. These functions have confusing names, and have a long history of misuse. List of functions:

stpncpy(3)

  • strncpy(3)

Other functions operate on an input character sequence, and create an output string. Functions that catenate also require that dst holds a string before the call. strncat(3) has an even more misleading name than the functions above. List of functions:

strncat(3)

  • strndup(3)

Other functions operate on an input character sequence to create an output character sequence. List of functions:

  • mempcpy(3)

Functions

stpcpy(3)
Copy the input string into a destination string. The programmer is responsible for allocating a buffer large enough. It returns a pointer suitable for chaining.

strcpy(3)
strcat(3)
Copy and catenate the input string into a destination string. The programmer is responsible for allocating a buffer large enough. The return value is useless.

stpcpy(3) is a faster alternative to these functions.

stpecpy()
Chain-copy the input string into a destination string. If the destination buffer, limited by a pointer to its end, isn’t large enough to hold the copy, the resulting string is truncated (but it is guaranteed to be null-terminated). It returns a pointer suitable for chaining. Truncation needs to be detected only once after the last chained call.

This function is not provided by any library; see EXAMPLES for a reference implementation.

strtcpy()
Copy the input string into a destination string. If the destination buffer isn’t large enough to hold the copy, the resulting string is truncated (but it is guaranteed to be null-terminated). It returns the length of the string, or -1 if it truncated.

This function is not provided by any library; see EXAMPLES for a reference implementation.

strlcpy(3bsd)
strlcat(3bsd)
Copy and catenate the input string into a destination string. If the destination buffer, limited by its size, isn’t large enough to hold the copy, the resulting string is truncated (but it is guaranteed to be null-terminated). They return the length of the total string they tried to create.

Check BUGS before using these functions.

strtcpy() and stpecpy() are better alternatives to these functions.

stpncpy(3)
Copy the input string into a destination null-padded character sequence in a fixed-size buffer. If the destination buffer, limited by its size, isn’t large enough to hold the copy, the resulting character sequence is truncated. Since it creates a character sequence, it doesn’t need to write a terminating null character. It’s impossible to distinguish truncation by the result of the call, from a character sequence that just fits the destination buffer; truncation should be detected by comparing the length of the input string with the size of the destination buffer.

strncpy(3)
This function is identical to stpncpy(3) except for the useless return value.

stpncpy(3) is a more useful alternative to this function.

strncat(3)
Catenate the input character sequence, contained in a null-padded fixed-size buffer, into a destination string. The programmer is responsible for allocating a buffer large enough. The return value is useless.

Do not confuse this function with strncpy(3); they are not related at all.

stpcpy(mempcpy(dst, src, strnlen(src, NITEMS(src))), “”) is a faster alternative to this function.

strndup(3)
Duplicate the input character sequence, contained in a null-padded fixed-size buffer, into a newly allocated destination string.

The string must be freed with free(3).

mempcpy(3)
Copy the input character sequence, limited by its length, into a destination character sequence. The programmer is responsible for allocating a buffer large enough. It returns a pointer suitable for chaining.

RETURN VALUE

stpcpy(3)
A pointer to the terminating null character in the destination string.

stpecpy()
A pointer to the terminating null character in the destination string, on success. On error, NULL is returned, and errno is set to indicate the error.

mempcpy(3)
stpncpy(3)
A pointer to one after the last character in the destination character sequence.

strtcpy()
The length of the string, on success. On error, -1 is returned, and errno is set to indicate the error.

strlcpy(3bsd)
strlcat(3bsd)
The length of the total string that they tried to create (as if truncation didn’t occur).

strcpy(3)
strcat(3)
strncpy(3)
strncat(3)
The dst pointer, which is useless.

strndup(3)
The newly allocated string.

ERRORS

Most of these functions don’t set errno.

stpecpy()
strtcpy()

ENOBUFS
dsize was 0.

E2BIG
The string has been truncated.

strndup(3)

ENOMEM
Insufficient memory available to allocate duplicate string.

NOTES

The Linux kernel has an internal function for copying strings, strscpy(9), which is identical to strtcpy(), except that it returns -E2BIG instead of -1 and it doesn’t set errno.

CAVEATS

Don’t mix chain calls to truncating and non-truncating functions. It is conceptually wrong unless you know that the first part of a copy will always fit. Anyway, the performance difference will probably be negligible, so it will probably be more clear if you use consistent semantics: either truncating or non-truncating. Calling a non-truncating function after a truncating one is necessarily wrong.

BUGS

All catenation functions share the same performance problem: Shlemiel the painter. As a mitigation, compilers are able to transform some calls to catenation functions into normal copy functions, since strlen(dst) is usually a byproduct of the previous copy.

strlcpy(3) and strlcat(3) need to read the entire src string, even if the destination buffer is small. This makes them vulnerable to Denial of Service (DoS) attacks if an attacker can control the length of the src string. And if not, they’re still unnecessarily slow.

EXAMPLES

The following are examples of correct use of each of these functions.

stpcpy(3)
p = buf; p = stpcpy(p, “Hello “); p = stpcpy(p, “world”); p = stpcpy(p, “!”); len = p - buf; puts(buf);

strcpy(3)
strcat(3)
strcpy(buf, “Hello “); strcat(buf, “world”); strcat(buf, “!”); len = strlen(buf); puts(buf);

stpecpy()
end = buf + NITEMS(buf); p = buf; p = stpecpy(p, end, “Hello “); p = stpecpy(p, end, “world”); p = stpecpy(p, end, “!”); if (p == NULL) { len = NITEMS(buf) - 1; goto toolong; } len = p - buf; puts(buf);

strtcpy()
len = strtcpy(buf, “Hello world!”, NITEMS(buf)); if (len == -1) goto toolong; puts(buf);

strlcpy(3bsd)
strlcat(3bsd)
if (strlcpy(buf, “Hello “, NITEMS(buf)) >= NITEMS(buf)) goto toolong; if (strlcat(buf, “world”, NITEMS(buf)) >= NITEMS(buf)) goto toolong; len = strlcat(buf, “!”, NITEMS(buf)); if (len >= NITEMS(buf)) goto toolong; puts(buf);

stpncpy(3)
p = stpncpy(u->ut_user, “alx”, NITEMS(u->ut_user)); if (NITEMS(u->ut_user) < strlen(“alx”)) goto toolong; len = p - u->ut_user; fwrite(u->ut_user, 1, len, stdout);

strncpy(3)
strncpy(u->ut_user, “alx”, NITEMS(u->ut_user)); if (NITEMS(u->ut_user) < strlen(“alx”)) goto toolong; len = strnlen(u->ut_user, NITEMS(u->ut_user)); fwrite(u->ut_user, 1, len, stdout);

mempcpy(dst, src, strnlen(src, NITEMS(src)))
char buf[NITEMS(u->ut_user)]; p = buf; p = mempcpy(p, u->ut_user, strnlen(u->ut_user, NITEMS(u->ut_user))); len = p - buf; fwrite(buf, 1, len, stdout);

stpcpy(mempcpy(dst, src, strnlen(src, NITEMS(src))), “”)
char buf[NITEMS(u->ut_user) + 1]; p = buf; p = mempcpy(p, u->ut_user, strnlen(u->ut_user, NITEMS(u->ut_user))); p = stpcpy(p, “”); len = p - buf; puts(buf);

strncat(3)
char buf[NITEMS(u->ut_user) + 1]; strcpy(buf, “”); strncat(buf, u->ut_user, NITEMS(u->ut_user)); len = strlen(buf); puts(buf);

strndup(3)
buf = strndup(u->ut_user, NITEMS(u->ut_user)); len = strlen(buf); puts(buf); free(buf);

mempcpy(3)
p = buf; p = mempcpy(p, “Hello “, 6); p = mempcpy(p, “world”, 5); p = mempcpy(p, “!”, 1); len = p - buf; fwrite(buf, 1, len, stdout);

stpcpy(mempcpy(dst, src, len), “”)
p = buf; p = mempcpy(p, “Hello “, 6); p = mempcpy(p, “world”, 5); p = mempcpy(p, “!”, 1); p = stpcpy(p, “”); len = p - buf; puts(buf);

Implementations

Here are reference implementations for functions not provided by libc.

/* This code is in the public domain. */
char *
stpecpy(char *dst, char end[0], const char *restrict src)
{
    size_t  dlen;
    if (dst == NULL)
        return NULL;
    dlen = strtcpy(dst, src, end - dst);
    return (dlen == -1) ? NULL : dst + dlen;
}
ssize_t
strtcpy(char *restrict dst, const char *restrict src, size_t dsize)
{
    bool    trunc;
    size_t  dlen, slen;
    if (dsize == 0) {
        errno = ENOBUFS;
        return -1;
    }
    slen = strnlen(src, dsize);
    trunc = (slen == dsize);
    dlen = slen - trunc;
    stpcpy(mempcpy(dst, src, dlen), "");
    if (trunc)
        errno = E2BIG;
    return trunc ? -1 : slen;
}

SEE ALSO

bzero(3), memcpy(3), memccpy(3), mempcpy(3), stpcpy(3), strlcpy(3bsd), strncat(3), stpncpy(3), string(3)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

29 - Linux cli command complex

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command complex and provides detailed information about the command complex, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the complex.

NAME 🖥️ complex 🖥️

basics of complex mathematics

LIBRARY

Math library (libm, -lm)

SYNOPSIS

#include <complex.h>

DESCRIPTION

Complex numbers are numbers of the form z = a+b*i, where a and b are real numbers and i = sqrt(-1), so that i*i = -1.

There are other ways to represent that number. The pair (a,b) of real numbers may be viewed as a point in the plane, given by X- and Y-coordinates. This same point may also be described by giving the pair of real numbers (r,phi), where r is the distance to the origin O, and phi the angle between the X-axis and the line Oz. Now z = r*exp(i*phi) = r*(cos(phi)+i*sin(phi)).

The basic operations are defined on z = a+b*i and w = c+d*i as:

addition: z+w = (a+c) + (b+d)*i
multiplication: z*w = (a*c - b*d) + (a*d + b*c)*i
division: z/w = ((a*c + b*d)/(c*c + d*d)) + ((b*c - a*d)/(c*c + d*d))*i

Nearly all math function have a complex counterpart but there are some complex-only functions.

EXAMPLES

Your C-compiler can work with complex numbers if it supports the C99 standard. The imaginary unit is represented by I.

/* check that exp(i * pi) == -1 */
#include <math.h>        /* for atan */
#include <stdio.h>
#include <complex.h>
int
main(void)
{
    double pi = 4 * atan(1.0);
    double complex z = cexp(I * pi);
    printf("%f + %f * i

“, creal(z), cimag(z)); }

SEE ALSO

cabs(3), cacos(3), cacosh(3), carg(3), casin(3), casinh(3), catan(3), catanh(3), ccos(3), ccosh(3), cerf(3), cexp(3), cexp2(3), cimag(3), clog(3), clog10(3), clog2(3), conj(3), cpow(3), cproj(3), creal(3), csin(3), csinh(3), csqrt(3), ctan(3), ctanh(3)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

30 - Linux cli command latin2

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command latin2 and provides detailed information about the command latin2, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the latin2.

NAME 🖥️ latin2 🖥️

2 - ISO/IEC 8859-2 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-2 encodes the Latin characters used in many Central and East European languages.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-2 characters

The following table displays the characters in ISO/IEC 8859-2 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-2 is also known as Latin-2.

SEE ALSO

ascii(7), charsets(7), iso_8859-1(7), iso_8859-16(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

31 - Linux cli command mount_namespaces

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command mount_namespaces and provides detailed information about the command mount_namespaces, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the mount_namespaces.

NAME 🖥️ mount_namespaces 🖥️

overview of Linux mount namespaces

DESCRIPTION

For an overview of namespaces, see namespaces(7).

Mount namespaces provide isolation of the list of mounts seen by the processes in each namespace instance. Thus, the processes in each of the mount namespace instances will see distinct single-directory hierarchies.

The views provided by the /proc/pid/mounts, /proc/pid/mountinfo, and /proc/pid/mountstats files (all described in proc(5)) correspond to the mount namespace in which the process with the PID pid resides. (All of the processes that reside in the same mount namespace will see the same view in these files.)

A new mount namespace is created using either clone(2) or unshare(2) with the CLONE_NEWNS flag. When a new mount namespace is created, its mount list is initialized as follows:

  • If the namespace is created using clone(2), the mount list of the child’s namespace is a copy of the mount list in the parent process’s mount namespace.

  • If the namespace is created using unshare(2), the mount list of the new namespace is a copy of the mount list in the caller’s previous mount namespace.

Subsequent modifications to the mount list (mount(2) and umount(2)) in either mount namespace will not (by default) affect the mount list seen in the other namespace (but see the following discussion of shared subtrees).

SHARED SUBTREES

After the implementation of mount namespaces was completed, experience showed that the isolation that they provided was, in some cases, too great. For example, in order to make a newly loaded optical disk available in all mount namespaces, a mount operation was required in each namespace. For this use case, and others, the shared subtree feature was introduced in Linux 2.6.15. This feature allows for automatic, controlled propagation of mount(2) and umount(2) events between namespaces (or, more precisely, between the mounts that are members of a peer group that are propagating events to one another).

Each mount is marked (via mount(2)) as having one of the following propagation types:

MS_SHARED
This mount shares events with members of a peer group. mount(2) and umount(2) events immediately under this mount will propagate to the other mounts that are members of the peer group. Propagation here means that the same mount(2) or umount(2) will automatically occur under all of the other mounts in the peer group. Conversely, mount(2) and umount(2) events that take place under peer mounts will propagate to this mount.

MS_PRIVATE
This mount is private; it does not have a peer group. mount(2) and umount(2) events do not propagate into or out of this mount.

MS_SLAVE
mount(2) and umount(2) events propagate into this mount from a (master) shared peer group. mount(2) and umount(2) events under this mount do not propagate to any peer.

Note that a mount can be the slave of another peer group while at the same time sharing mount(2) and umount(2) events with a peer group of which it is a member. (More precisely, one peer group can be the slave of another peer group.)

MS_UNBINDABLE
This is like a private mount, and in addition this mount can’t be bind mounted. Attempts to bind mount this mount (mount(2) with the MS_BIND flag) will fail.

When a recursive bind mount (mount(2) with the MS_BIND and MS_REC flags) is performed on a directory subtree, any bind mounts within the subtree are automatically pruned (i.e., not replicated) when replicating that subtree to produce the target subtree.

For a discussion of the propagation type assigned to a new mount, see NOTES.

The propagation type is a per-mount-point setting; some mounts may be marked as shared (with each shared mount being a member of a distinct peer group), while others are private (or slaved or unbindable).

Note that a mount’s propagation type determines whether mount(2) and umount(2) of mounts immediately under the mount are propagated. Thus, the propagation type does not affect propagation of events for grandchildren and further removed descendant mounts. What happens if the mount itself is unmounted is determined by the propagation type that is in effect for the parent of the mount.

Members are added to a peer group when a mount is marked as shared and either:

  1. the mount is replicated during the creation of a new mount namespace; or

  2. a new bind mount is created from the mount.

In both of these cases, the new mount joins the peer group of which the existing mount is a member.

A new peer group is also created when a child mount is created under an existing mount that is marked as shared. In this case, the new child mount is also marked as shared and the resulting peer group consists of all the mounts that are replicated under the peers of parent mounts.

A mount ceases to be a member of a peer group when either the mount is explicitly unmounted, or when the mount is implicitly unmounted because a mount namespace is removed (because it has no more member processes).

The propagation type of the mounts in a mount namespace can be discovered via the “optional fields” exposed in /proc/pid/mountinfo. (See proc(5) for details of this file.) The following tags can appear in the optional fields for a record in that file:

shared:X
This mount is shared in peer group X. Each peer group has a unique ID that is automatically generated by the kernel, and all mounts in the same peer group will show the same ID. (These IDs are assigned starting from the value 1, and may be recycled when a peer group ceases to have any members.)

master:X
This mount is a slave to shared peer group X.

propagate_from:X (since Linux 2.6.26)
This mount is a slave and receives propagation from shared peer group X. This tag will always appear in conjunction with a master:X tag. Here, X is the closest dominant peer group under the process’s root directory. If X is the immediate master of the mount, or if there is no dominant peer group under the same root, then only the master:X field is present and not the propagate_from:X field. For further details, see below.

unbindable
This is an unbindable mount.

If none of the above tags is present, then this is a private mount.

MS_SHARED and MS_PRIVATE example

Suppose that on a terminal in the initial mount namespace, we mark one mount as shared and another as private, and then view the mounts in /proc/self/mountinfo:

sh1# mount --make-shared /mntS
sh1# mount --make-private /mntP
sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
77 61 8:17 / /mntS rw,relatime shared:1
83 61 8:15 / /mntP rw,relatime

From the /proc/self/mountinfo output, we see that /mntS is a shared mount in peer group 1, and that /mntP has no optional tags, indicating that it is a private mount. The first two fields in each record in this file are the unique ID for this mount, and the mount ID of the parent mount. We can further inspect this file to see that the parent mount of /mntS and /mntP is the root directory, /, which is mounted as private:

sh1# cat /proc/self/mountinfo | awk '$1 == 61' | sed 's/ - .*//'
61 0 8:2 / / rw,relatime

On a second terminal, we create a new mount namespace where we run a second shell and inspect the mounts:

$ PS1='sh2# ' sudo unshare -m --propagation unchanged sh
sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
222 145 8:17 / /mntS rw,relatime shared:1
225 145 8:15 / /mntP rw,relatime

The new mount namespace received a copy of the initial mount namespace’s mounts. These new mounts maintain the same propagation types, but have unique mount IDs. (The –propagation unchanged option prevents unshare(1) from marking all mounts as private when creating a new mount namespace, which it does by default.)

In the second terminal, we then create submounts under each of /mntS and /mntP and inspect the set-up:

sh2# mkdir /mntS/a
sh2# mount /dev/sdb6 /mntS/a
sh2# mkdir /mntP/b
sh2# mount /dev/sdb7 /mntP/b
sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
222 145 8:17 / /mntS rw,relatime shared:1
225 145 8:15 / /mntP rw,relatime
178 222 8:22 / /mntS/a rw,relatime shared:2
230 225 8:23 / /mntP/b rw,relatime

From the above, it can be seen that /mntS/a was created as shared (inheriting this setting from its parent mount) and /mntP/b was created as a private mount.

Returning to the first terminal and inspecting the set-up, we see that the new mount created under the shared mount /mntS propagated to its peer mount (in the initial mount namespace), but the new mount created under the private mount /mntP did not propagate:

sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
77 61 8:17 / /mntS rw,relatime shared:1
83 61 8:15 / /mntP rw,relatime
179 77 8:22 / /mntS/a rw,relatime shared:2

MS_SLAVE example

Making a mount a slave allows it to receive propagated mount(2) and umount(2) events from a master shared peer group, while preventing it from propagating events to that master. This is useful if we want to (say) receive a mount event when an optical disk is mounted in the master shared peer group (in another mount namespace), but want to prevent mount(2) and umount(2) events under the slave mount from having side effects in other namespaces.

We can demonstrate the effect of slaving by first marking two mounts as shared in the initial mount namespace:

sh1# mount --make-shared /mntX
sh1# mount --make-shared /mntY
sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
132 83 8:23 / /mntX rw,relatime shared:1
133 83 8:22 / /mntY rw,relatime shared:2

On a second terminal, we create a new mount namespace and inspect the mounts:

sh2# unshare -m --propagation unchanged sh
sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
168 167 8:23 / /mntX rw,relatime shared:1
169 167 8:22 / /mntY rw,relatime shared:2

In the new mount namespace, we then mark one of the mounts as a slave:

sh2# mount --make-slave /mntY
sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
168 167 8:23 / /mntX rw,relatime shared:1
169 167 8:22 / /mntY rw,relatime master:2

From the above output, we see that /mntY is now a slave mount that is receiving propagation events from the shared peer group with the ID 2.

Continuing in the new namespace, we create submounts under each of /mntX and /mntY:

sh2# mkdir /mntX/a
sh2# mount /dev/sda3 /mntX/a
sh2# mkdir /mntY/b
sh2# mount /dev/sda5 /mntY/b

When we inspect the state of the mounts in the new mount namespace, we see that /mntX/a was created as a new shared mount (inheriting the “shared” setting from its parent mount) and /mntY/b was created as a private mount:

sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
168 167 8:23 / /mntX rw,relatime shared:1
169 167 8:22 / /mntY rw,relatime master:2
173 168 8:3 / /mntX/a rw,relatime shared:3
175 169 8:5 / /mntY/b rw,relatime

Returning to the first terminal (in the initial mount namespace), we see that the mount /mntX/a propagated to the peer (the shared /mntX), but the mount /mntY/b was not propagated:

sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
132 83 8:23 / /mntX rw,relatime shared:1
133 83 8:22 / /mntY rw,relatime shared:2
174 132 8:3 / /mntX/a rw,relatime shared:3

Now we create a new mount under /mntY in the first shell:

sh1# mkdir /mntY/c
sh1# mount /dev/sda1 /mntY/c
sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
132 83 8:23 / /mntX rw,relatime shared:1
133 83 8:22 / /mntY rw,relatime shared:2
174 132 8:3 / /mntX/a rw,relatime shared:3
178 133 8:1 / /mntY/c rw,relatime shared:4

When we examine the mounts in the second mount namespace, we see that in this case the new mount has been propagated to the slave mount, and that the new mount is itself a slave mount (to peer group 4):

sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
168 167 8:23 / /mntX rw,relatime shared:1
169 167 8:22 / /mntY rw,relatime master:2
173 168 8:3 / /mntX/a rw,relatime shared:3
175 169 8:5 / /mntY/b rw,relatime
179 169 8:1 / /mntY/c rw,relatime master:4

MS_UNBINDABLE example

One of the primary purposes of unbindable mounts is to avoid the “mount explosion” problem when repeatedly performing bind mounts of a higher-level subtree at a lower-level mount. The problem is illustrated by the following shell session.

Suppose we have a system with the following mounts:

# mount | awk '{print $1, $2, $3}'
/dev/sda1 on /
/dev/sdb6 on /mntX
/dev/sdb7 on /mntY

Suppose furthermore that we wish to recursively bind mount the root directory under several users’ home directories. We do this for the first user, and inspect the mounts:

# mount --rbind / /home/cecilia/
# mount | awk '{print $1, $2, $3}'
/dev/sda1 on /
/dev/sdb6 on /mntX
/dev/sdb7 on /mntY
/dev/sda1 on /home/cecilia
/dev/sdb6 on /home/cecilia/mntX
/dev/sdb7 on /home/cecilia/mntY

When we repeat this operation for the second user, we start to see the explosion problem:

# mount --rbind / /home/henry
# mount | awk '{print $1, $2, $3}'
/dev/sda1 on /
/dev/sdb6 on /mntX
/dev/sdb7 on /mntY
/dev/sda1 on /home/cecilia
/dev/sdb6 on /home/cecilia/mntX
/dev/sdb7 on /home/cecilia/mntY
/dev/sda1 on /home/henry
/dev/sdb6 on /home/henry/mntX
/dev/sdb7 on /home/henry/mntY
/dev/sda1 on /home/henry/home/cecilia
/dev/sdb6 on /home/henry/home/cecilia/mntX
/dev/sdb7 on /home/henry/home/cecilia/mntY

Under /home/henry, we have not only recursively added the /mntX and /mntY mounts, but also the recursive mounts of those directories under /home/cecilia that were created in the previous step. Upon repeating the step for a third user, it becomes obvious that the explosion is exponential in nature:

# mount --rbind / /home/otto
# mount | awk '{print $1, $2, $3}'
/dev/sda1 on /
/dev/sdb6 on /mntX
/dev/sdb7 on /mntY
/dev/sda1 on /home/cecilia
/dev/sdb6 on /home/cecilia/mntX
/dev/sdb7 on /home/cecilia/mntY
/dev/sda1 on /home/henry
/dev/sdb6 on /home/henry/mntX
/dev/sdb7 on /home/henry/mntY
/dev/sda1 on /home/henry/home/cecilia
/dev/sdb6 on /home/henry/home/cecilia/mntX
/dev/sdb7 on /home/henry/home/cecilia/mntY
/dev/sda1 on /home/otto
/dev/sdb6 on /home/otto/mntX
/dev/sdb7 on /home/otto/mntY
/dev/sda1 on /home/otto/home/cecilia
/dev/sdb6 on /home/otto/home/cecilia/mntX
/dev/sdb7 on /home/otto/home/cecilia/mntY
/dev/sda1 on /home/otto/home/henry
/dev/sdb6 on /home/otto/home/henry/mntX
/dev/sdb7 on /home/otto/home/henry/mntY
/dev/sda1 on /home/otto/home/henry/home/cecilia
/dev/sdb6 on /home/otto/home/henry/home/cecilia/mntX
/dev/sdb7 on /home/otto/home/henry/home/cecilia/mntY

The mount explosion problem in the above scenario can be avoided by making each of the new mounts unbindable. The effect of doing this is that recursive mounts of the root directory will not replicate the unbindable mounts. We make such a mount for the first user:

# mount --rbind --make-unbindable / /home/cecilia

Before going further, we show that unbindable mounts are indeed unbindable:

# mkdir /mntZ
# mount --bind /home/cecilia /mntZ
mount: wrong fs type, bad option, bad superblock on /home/cecilia,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail or so.

Now we create unbindable recursive bind mounts for the other two users:

# mount --rbind --make-unbindable / /home/henry
# mount --rbind --make-unbindable / /home/otto

Upon examining the list of mounts, we see there has been no explosion of mounts, because the unbindable mounts were not replicated under each user’s directory:

# mount | awk '{print $1, $2, $3}'
/dev/sda1 on /
/dev/sdb6 on /mntX
/dev/sdb7 on /mntY
/dev/sda1 on /home/cecilia
/dev/sdb6 on /home/cecilia/mntX
/dev/sdb7 on /home/cecilia/mntY
/dev/sda1 on /home/henry
/dev/sdb6 on /home/henry/mntX
/dev/sdb7 on /home/henry/mntY
/dev/sda1 on /home/otto
/dev/sdb6 on /home/otto/mntX
/dev/sdb7 on /home/otto/mntY

Propagation type transitions

The following table shows the effect that applying a new propagation type (i.e., mount –make-xxxx) has on the existing propagation type of a mount. The rows correspond to existing propagation types, and the columns are the new propagation settings. For reasons of space, “private” is abbreviated as “priv” and “unbindable” as “unbind”.

make-sharedmake-slavemake-privmake-unbind
sharedsharedslave/priv [1]privunbind
slaveslave+sharedslave [2]privunbind
slave+sharedslave+sharedslaveprivunbind
privatesharedpriv [2]privunbind
unbindablesharedunbind [2]privunbind

Note the following details to the table:

[1]
If a shared mount is the only mount in its peer group, making it a slave automatically makes it private.

[2]
Slaving a nonshared mount has no effect on the mount.

Bind (MS_BIND) semantics

Suppose that the following command is performed:

mount --bind A/a B/b

Here, A is the source mount, B is the destination mount, a is a subdirectory path under the mount point A, and b is a subdirectory path under the mount point B. The propagation type of the resulting mount, B/b, depends on the propagation types of the mounts A and B, and is summarized in the following table.

source(A)
sharedprivateslaveunbind
_
dest(B)sharedsharedsharedslave+sharedinvalid
nonsharedsharedprivateslaveinvalid

Note that a recursive bind of a subtree follows the same semantics as for a bind operation on each mount in the subtree. (Unbindable mounts are automatically pruned at the target mount point.)

For further details, see Documentation/filesystems/sharedsubtree.rst in the kernel source tree.

Move (MS_MOVE) semantics

Suppose that the following command is performed:

mount --move A B/b

Here, A is the source mount, B is the destination mount, and b is a subdirectory path under the mount point B. The propagation type of the resulting mount, B/b, depends on the propagation types of the mounts A and B, and is summarized in the following table.

source(A)
sharedprivateslaveunbind
_
dest(B)sharedsharedsharedslave+sharedinvalid
nonsharedsharedprivateslaveunbindable

Note: moving a mount that resides under a shared mount is invalid.

For further details, see Documentation/filesystems/sharedsubtree.rst in the kernel source tree.

Mount semantics

Suppose that we use the following command to create a mount:

mount device B/b

Here, B is the destination mount, and b is a subdirectory path under the mount point B. The propagation type of the resulting mount, B/b, follows the same rules as for a bind mount, where the propagation type of the source mount is considered always to be private.

Unmount semantics

Suppose that we use the following command to tear down a mount:

umount A

Here, A is a mount on B/b, where B is the parent mount and b is a subdirectory path under the mount point B. If B is shared, then all most-recently-mounted mounts at b on mounts that receive propagation from mount B and do not have submounts under them are unmounted.

The /proc/ pid /mountinfo propagate_from tag

The propagate_from:X tag is shown in the optional fields of a /proc/pid/mountinfo record in cases where a process can’t see a slave’s immediate master (i.e., the pathname of the master is not reachable from the filesystem root directory) and so cannot determine the chain of propagation between the mounts it can see.

In the following example, we first create a two-link master-slave chain between the mounts /mnt, /tmp/etc, and /mnt/tmp/etc. Then the chroot(1) command is used to make the /tmp/etc mount point unreachable from the root directory, creating a situation where the master of /mnt/tmp/etc is not reachable from the (new) root directory of the process.

First, we bind mount the root directory onto /mnt and then bind mount /proc at /mnt/proc so that after the later chroot(1) the proc(5) filesystem remains visible at the correct location in the chroot-ed environment.

# mkdir -p /mnt/proc
# mount --bind / /mnt
# mount --bind /proc /mnt/proc

Next, we ensure that the /mnt mount is a shared mount in a new peer group (with no peers):

# mount --make-private /mnt  # Isolate from any previous peer group
# mount --make-shared /mnt
# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
239 61 8:2 / /mnt ... shared:102
248 239 0:4 / /mnt/proc ... shared:5

Next, we bind mount /mnt/etc onto /tmp/etc:

# mkdir -p /tmp/etc
# mount --bind /mnt/etc /tmp/etc
# cat /proc/self/mountinfo | egrep '/mnt|/tmp/' | sed 's/ - .*//'
239 61 8:2 / /mnt ... shared:102
248 239 0:4 / /mnt/proc ... shared:5
267 40 8:2 /etc /tmp/etc ... shared:102

Initially, these two mounts are in the same peer group, but we then make the /tmp/etc a slave of /mnt/etc, and then make /tmp/etc shared as well, so that it can propagate events to the next slave in the chain:

# mount --make-slave /tmp/etc
# mount --make-shared /tmp/etc
# cat /proc/self/mountinfo | egrep '/mnt|/tmp/' | sed 's/ - .*//'
239 61 8:2 / /mnt ... shared:102
248 239 0:4 / /mnt/proc ... shared:5
267 40 8:2 /etc /tmp/etc ... shared:105 master:102

Then we bind mount /tmp/etc onto /mnt/tmp/etc. Again, the two mounts are initially in the same peer group, but we then make /mnt/tmp/etc a slave of /tmp/etc:

# mkdir -p /mnt/tmp/etc
# mount --bind /tmp/etc /mnt/tmp/etc
# mount --make-slave /mnt/tmp/etc
# cat /proc/self/mountinfo | egrep '/mnt|/tmp/' | sed 's/ - .*//'
239 61 8:2 / /mnt ... shared:102
248 239 0:4 / /mnt/proc ... shared:5
267 40 8:2 /etc /tmp/etc ... shared:105 master:102
273 239 8:2 /etc /mnt/tmp/etc ... master:105

From the above, we see that /mnt is the master of the slave /tmp/etc, which in turn is the master of the slave /mnt/tmp/etc.

We then chroot(1) to the /mnt directory, which renders the mount with ID 267 unreachable from the (new) root directory:

# chroot /mnt

When we examine the state of the mounts inside the chroot-ed environment, we see the following:

# cat /proc/self/mountinfo | sed 's/ - .*//'
239 61 8:2 / / ... shared:102
248 239 0:4 / /proc ... shared:5
273 239 8:2 /etc /tmp/etc ... master:105 propagate_from:102

Above, we see that the mount with ID 273 is a slave whose master is the peer group 105. The mount point for that master is unreachable, and so a propagate_from tag is displayed, indicating that the closest dominant peer group (i.e., the nearest reachable mount in the slave chain) is the peer group with the ID 102 (corresponding to the /mnt mount point before the chroot(1) was performed).

STANDARDS

Linux.

HISTORY

Linux 2.4.19.

NOTES

The propagation type assigned to a new mount depends on the propagation type of the parent mount. If the mount has a parent (i.e., it is a non-root mount point) and the propagation type of the parent is MS_SHARED, then the propagation type of the new mount is also MS_SHARED. Otherwise, the propagation type of the new mount is MS_PRIVATE.

Notwithstanding the fact that the default propagation type for new mount is in many cases MS_PRIVATE, MS_SHARED is typically more useful. For this reason, systemd(1) automatically remounts all mounts as MS_SHARED on system startup. Thus, on most modern systems, the default propagation type is in practice MS_SHARED.

Since, when one uses unshare(1) to create a mount namespace, the goal is commonly to provide full isolation of the mounts in the new namespace, unshare(1) (since util-linux 2.27) in turn reverses the step performed by systemd(1), by making all mounts private in the new namespace. That is, unshare(1) performs the equivalent of the following in the new mount namespace:

mount --make-rprivate /

To prevent this, one can use the –propagation unchanged option to unshare(1).

An application that creates a new mount namespace directly using clone(2) or unshare(2) may desire to prevent propagation of mount events to other mount namespaces (as is done by unshare(1)). This can be done by changing the propagation type of mounts in the new namespace to either MS_SLAVE or MS_PRIVATE, using a call such as the following:

mount(NULL, "/", MS_SLAVE | MS_REC, NULL);

For a discussion of propagation types when moving mounts (MS_MOVE) and creating bind mounts (MS_BIND), see Documentation/filesystems/sharedsubtree.rst.

Restrictions on mount namespaces

Note the following points with respect to mount namespaces:

[1]
Each mount namespace has an owner user namespace. As explained above, when a new mount namespace is created, its mount list is initialized as a copy of the mount list of another mount namespace. If the new namespace and the namespace from which the mount list was copied are owned by different user namespaces, then the new mount namespace is considered less privileged.

[2]
When creating a less privileged mount namespace, shared mounts are reduced to slave mounts. This ensures that mappings performed in less privileged mount namespaces will not propagate to more privileged mount namespaces.

[3]
Mounts that come as a single unit from a more privileged mount namespace are locked together and may not be separated in a less privileged mount namespace. (The unshare(2) CLONE_NEWNS operation brings across all of the mounts from the original mount namespace as a single unit, and recursive mounts that propagate between mount namespaces propagate as a single unit.)

In this context, “may not be separated” means that the mounts are locked so that they may not be individually unmounted. Consider the following example:

$ sudo sh
# mount --bind /dev/null /etc/shadow
# cat /etc/shadow       # Produces no output

The above steps, performed in a more privileged mount namespace, have created a bind mount that obscures the contents of the shadow password file, /etc/shadow. For security reasons, it should not be possible to umount(2) that mount in a less privileged mount namespace, since that would reveal the contents of /etc/shadow.

Suppose we now create a new mount namespace owned by a new user namespace. The new mount namespace will inherit copies of all of the mounts from the previous mount namespace. However, those mounts will be locked because the new mount namespace is less privileged. Consequently, an attempt to umount(2) the mount fails as show in the following step:

# unshare --user --map-root-user --mount \
               strace -o /tmp/log \
               umount /mnt/dir
umount: /etc/shadow: not mounted.
# grep '^umount' /tmp/log
umount2("/etc/shadow", 0)     = -1 EINVAL (Invalid argument)

The error message from mount(8) is a little confusing, but the strace(1) output reveals that the underlying umount2(2) system call failed with the error EINVAL, which is the error that the kernel returns to indicate that the mount is locked.

Note, however, that it is possible to stack (and unstack) a mount on top of one of the inherited locked mounts in a less privileged mount namespace:

# echo 'aaaaa' > /tmp/a    # File to mount onto /etc/shadow
# unshare --user --map-root-user --mount \
    sh -c 'mount --bind /tmp/a /etc/shadow; cat /etc/shadow'
aaaaa
# umount /etc/shadow

The final umount(8) command above, which is performed in the initial mount namespace, makes the original /etc/shadow file once more visible in that namespace.

[4]
Following on from point [3], note that it is possible to umount(2) an entire subtree of mounts that propagated as a unit into a less privileged mount namespace, as illustrated in the following example.

First, we create new user and mount namespaces using unshare(1). In the new mount namespace, the propagation type of all mounts is set to private. We then create a shared bind mount at /mnt, and a small hierarchy of mounts underneath that mount.

$ PS1='ns1# ' sudo unshare --user --map-root-user \
                       --mount --propagation private bash
ns1# echo $$        # We need the PID of this shell later
778501
ns1# mount --make-shared --bind /mnt /mnt
ns1# mkdir /mnt/x
ns1# mount --make-private -t tmpfs none /mnt/x
ns1# mkdir /mnt/x/y
ns1# mount --make-private -t tmpfs none /mnt/x/y
ns1# grep /mnt /proc/self/mountinfo | sed 's/ - .*//'
986 83 8:5 /mnt /mnt rw,relatime shared:344
989 986 0:56 / /mnt/x rw,relatime
990 989 0:57 / /mnt/x/y rw,relatime

Continuing in the same shell session, we then create a second shell in a new user namespace and a new (less privileged) mount namespace and check the state of the propagated mounts rooted at /mnt.

ns1# PS1='ns2# ' unshare --user --map-root-user \
                       --mount --propagation unchanged bash
ns2# grep /mnt /proc/self/mountinfo | sed 's/ - .*//'
1239 1204 8:5 /mnt /mnt rw,relatime master:344
1240 1239 0:56 / /mnt/x rw,relatime
1241 1240 0:57 / /mnt/x/y rw,relatime

Of note in the above output is that the propagation type of the mount /mnt has been reduced to slave, as explained in point [2]. This means that submount events will propagate from the master /mnt in “ns1”, but propagation will not occur in the opposite direction.

From a separate terminal window, we then use nsenter(1) to enter the mount and user namespaces corresponding to “ns1”. In that terminal window, we then recursively bind mount /mnt/x at the location /mnt/ppp.

$ PS1='ns3# ' sudo nsenter -t 778501 --user --mount
ns3# mount --rbind --make-private /mnt/x /mnt/ppp
ns3# grep /mnt /proc/self/mountinfo | sed 's/ - .*//'
986 83 8:5 /mnt /mnt rw,relatime shared:344
989 986 0:56 / /mnt/x rw,relatime
990 989 0:57 / /mnt/x/y rw,relatime
1242 986 0:56 / /mnt/ppp rw,relatime
1243 1242 0:57 / /mnt/ppp/y rw,relatime shared:518

Because the propagation type of the parent mount, /mnt, was shared, the recursive bind mount propagated a small subtree of mounts under the slave mount /mnt into “ns2”, as can be verified by executing the following command in that shell session:

ns2# grep /mnt /proc/self/mountinfo | sed 's/ - .*//'
1239 1204 8:5 /mnt /mnt rw,relatime master:344
1240 1239 0:56 / /mnt/x rw,relatime
1241 1240 0:57 / /mnt/x/y rw,relatime
1244 1239 0:56 / /mnt/ppp rw,relatime
1245 1244 0:57 / /mnt/ppp/y rw,relatime master:518

While it is not possible to umount(2) a part of the propagated subtree (/mnt/ppp/y) in “ns2”, it is possible to umount(2) the entire subtree, as shown by the following commands:

ns2# umount /mnt/ppp/y
umount: /mnt/ppp/y: not mounted.
ns2# umount -l /mnt/ppp | sed 's/ - .*//'      # Succeeds...
ns2# grep /mnt /proc/self/mountinfo
1239 1204 8:5 /mnt /mnt rw,relatime master:344
1240 1239 0:56 / /mnt/x rw,relatime
1241 1240 0:57 / /mnt/x/y rw,relatime

[5]
The mount(2) flags MS_RDONLY, MS_NOSUID, MS_NOEXEC, and the “atime” flags (MS_NOATIME, MS_NODIRATIME, MS_RELATIME) settings become locked when propagated from a more privileged to a less privileged mount namespace, and may not be changed in the less privileged mount namespace.

This point is illustrated in the following example where, in a more privileged mount namespace, we create a bind mount that is marked as read-only. For security reasons, it should not be possible to make the mount writable in a less privileged mount namespace, and indeed the kernel prevents this:

$ sudo mkdir /mnt/dir
$ sudo mount --bind -o ro /some/path /mnt/dir
$ sudo unshare --user --map-root-user --mount \
               mount -o remount,rw /mnt/dir
mount: /mnt/dir: permission denied.

[6]
A file or directory that is a mount point in one namespace that is not a mount point in another namespace, may be renamed, unlinked, or removed (rmdir(2)) in the mount namespace in which it is not a mount point (subject to the usual permission checks). Consequently, the mount point is removed in the mount namespace where it was a mount point.

Previously (before Linux 3.18), attempting to unlink, rename, or remove a file or directory that was a mount point in another mount namespace would result in the error EBUSY. That behavior had technical problems of enforcement (e.g., for NFS) and permitted denial-of-service attacks against more privileged users (i.e., preventing individual files from being updated by bind mounting on top of them).

EXAMPLES

See pivot_root(2).

SEE ALSO

unshare(1), clone(2), mount(2), mount_setattr(2), pivot_root(2), setns(2), umount(2), unshare(2), proc(5), namespaces(7), user_namespaces(7), findmnt(8), mount(8), pam_namespace(8), pivot_root(8), umount(8)

Documentation/filesystems/sharedsubtree.rst in the kernel source tree.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

32 - Linux cli command rtld-audit

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command rtld-audit and provides detailed information about the command rtld-audit, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the rtld-audit.

NAME 🖥️ rtld-audit 🖥️

audit - auditing API for the dynamic linker

SYNOPSIS

#define _GNU_SOURCE /* See feature_test_macros(7) */
#include <link.h>

DESCRIPTION

The GNU dynamic linker (run-time linker) provides an auditing API that allows an application to be notified when various dynamic linking events occur. This API is very similar to the auditing interface provided by the Solaris run-time linker. The necessary constants and prototypes are defined by including <link.h>.

To use this interface, the programmer creates a shared library that implements a standard set of function names. Not all of the functions need to be implemented: in most cases, if the programmer is not interested in a particular class of auditing event, then no implementation needs to be provided for the corresponding auditing function.

To employ the auditing interface, the environment variable LD_AUDIT must be defined to contain a colon-separated list of shared libraries, each of which can implement (parts of) the auditing API. When an auditable event occurs, the corresponding function is invoked in each library, in the order that the libraries are listed.

la_version()

unsigned int la_version(unsigned int version);

This is the only function that must be defined by an auditing library: it performs the initial handshake between the dynamic linker and the auditing library. When invoking this function, the dynamic linker passes, in version, the highest version of the auditing interface that the linker supports.

A typical implementation of this function simply returns the constant LAV_CURRENT, which indicates the version of <link.h> that was used to build the audit module. If the dynamic linker does not support this version of the audit interface, it will refuse to activate this audit module. If the function returns zero, the dynamic linker also does not activate this audit module.

In order to enable backwards compatibility with older dynamic linkers, an audit module can examine the version argument and return an earlier version than LAV_CURRENT, assuming the module can adjust its implementation to match the requirements of the previous version of the audit interface. The la_version function should not return the value of version without further checks because it could correspond to an interface that does not match the <link.h> definitions used to build the audit module.

la_objsearch()

char *la_objsearch(const char *name, uintptr_t *cookie,
 unsigned int flag);

The dynamic linker invokes this function to inform the auditing library that it is about to search for a shared object. The name argument is the filename or pathname that is to be searched for. cookie identifies the shared object that initiated the search. flag is set to one of the following values:

LA_SER_ORIG
This is the original name that is being searched for. Typically, this name comes from an ELF DT_NEEDED entry, or is the filename argument given to dlopen(3).

LA_SER_LIBPATH
name was created using a directory specified in LD_LIBRARY_PATH.

LA_SER_RUNPATH
name was created using a directory specified in an ELF DT_RPATH or DT_RUNPATH list.

LA_SER_CONFIG
name was found via the ldconfig(8) cache (/etc/ld.so.cache).

LA_SER_DEFAULT
name was found via a search of one of the default directories.

LA_SER_SECURE
name is specific to a secure object (unused on Linux).

As its function result, la_objsearch() returns the pathname that the dynamic linker should use for further processing. If NULL is returned, then this pathname is ignored for further processing. If this audit library simply intends to monitor search paths, then name should be returned.

la_activity()

void la_activity( uintptr_t *cookie, unsigned int flag);

The dynamic linker calls this function to inform the auditing library that link-map activity is occurring. cookie identifies the object at the head of the link map. When the dynamic linker invokes this function, flag is set to one of the following values:

LA_ACT_ADD
New objects are being added to the link map.

LA_ACT_DELETE
Objects are being removed from the link map.

LA_ACT_CONSISTENT
Link-map activity has been completed: the map is once again consistent.

la_objopen()

unsigned int la_objopen(struct link_map *map, Lmid_t lmid,
 uintptr_t *cookie);

The dynamic linker calls this function when a new shared object is loaded. The map argument is a pointer to a link-map structure that describes the object. The lmid field has one of the following values

LM_ID_BASE
Link map is part of the initial namespace.

LM_ID_NEWLM
Link map is part of a new namespace requested via dlmopen(3).

cookie is a pointer to an identifier for this object. The identifier is provided to later calls to functions in the auditing library in order to identify this object. This identifier is initialized to point to object’s link map, but the audit library can change the identifier to some other value that it may prefer to use to identify the object.

As its return value, la_objopen() returns a bit mask created by ORing zero or more of the following constants, which allow the auditing library to select the objects to be monitored by la_symbind*():

LA_FLG_BINDTO
Audit symbol bindings to this object.

LA_FLG_BINDFROM
Audit symbol bindings from this object.

A return value of 0 from la_objopen() indicates that no symbol bindings should be audited for this object.

la_objclose()

unsigned int la_objclose(uintptr_t *cookie);

The dynamic linker invokes this function after any finalization code for the object has been executed, before the object is unloaded. The cookie argument is the identifier obtained from a previous invocation of la_objopen().

In the current implementation, the value returned by la_objclose() is ignored.

la_preinit()

void la_preinit(uintptr_t *cookie);

The dynamic linker invokes this function after all shared objects have been loaded, before control is passed to the application (i.e., before calling main()). Note that main() may still later dynamically load objects using dlopen(3).

la_symbind*()

uintptr_t la_symbind32(Elf32_Sym *sym, unsigned int ndx,
 uintptr_t *refcook, uintptr_t *defcook,
 unsigned int *flags, const char *symname);
uintptr_t la_symbind64(Elf64_Sym *sym, unsigned int ndx,
 uintptr_t *refcook, uintptr_t *defcook,
 unsigned int *flags, const char *symname);

The dynamic linker invokes one of these functions when a symbol binding occurs between two shared objects that have been marked for auditing notification by la_objopen(). The la_symbind32() function is employed on 32-bit platforms; the la_symbind64() function is employed on 64-bit platforms.

The sym argument is a pointer to a structure that provides information about the symbol being bound. The structure definition is shown in <elf.h>. Among the fields of this structure, st_value indicates the address to which the symbol is bound.

The ndx argument gives the index of the symbol in the symbol table of the bound shared object.

The refcook argument identifies the shared object that is making the symbol reference; this is the same identifier that is provided to the la_objopen() function that returned LA_FLG_BINDFROM. The defcook argument identifies the shared object that defines the referenced symbol; this is the same identifier that is provided to the la_objopen() function that returned LA_FLG_BINDTO.

The symname argument points a string containing the name of the symbol.

The flags argument is a bit mask that both provides information about the symbol and can be used to modify further auditing of this PLT (Procedure Linkage Table) entry. The dynamic linker may supply the following bit values in this argument:

LA_SYMB_DLSYM
The binding resulted from a call to dlsym(3).

LA_SYMB_ALTVALUE
A previous la_symbind*() call returned an alternate value for this symbol.

By default, if the auditing library implements la_pltenter() and la_pltexit() functions (see below), then these functions are invoked, after la_symbind(), for PLT entries, each time the symbol is referenced. The following flags can be ORed into *flags to change this default behavior:

LA_SYMB_NOPLTENTER
Don’t call la_pltenter() for this symbol.

LA_SYMB_NOPLTEXIT
Don’t call la_pltexit() for this symbol.

The return value of la_symbind32() and la_symbind64() is the address to which control should be passed after the function returns. If the auditing library is simply monitoring symbol bindings, then it should return sym->st_value. A different value may be returned if the library wishes to direct control to an alternate location.

la_pltenter()

The precise name and argument types for this function depend on the hardware platform. (The appropriate definition is supplied by <link.h>.) Here is the definition for x86-32:

Elf32_Addr la_i86_gnu_pltenter(Elf32_Sym *sym, unsigned int ndx,
 uintptr_t *refcook, uintptr_t *defcook,
 La_i86_regs *regs, unsigned int *flags,
 const char *symname, long *framesizep);

This function is invoked just before a PLT entry is called, between two shared objects that have been marked for binding notification.

The sym, ndx, refcook, defcook, and symname are as for la_symbind*().

The regs argument points to a structure (defined in <link.h>) containing the values of registers to be used for the call to this PLT entry.

The flags argument points to a bit mask that conveys information about, and can be used to modify subsequent auditing of, this PLT entry, as for la_symbind*().

The framesizep argument points to a long int buffer that can be used to explicitly set the frame size used for the call to this PLT entry. If different la_pltenter() invocations for this symbol return different values, then the maximum returned value is used. The la_pltexit() function is called only if this buffer is explicitly set to a suitable value.

The return value of la_pltenter() is as for la_symbind*().

la_pltexit()

The precise name and argument types for this function depend on the hardware platform. (The appropriate definition is supplied by <link.h>.) Here is the definition for x86-32:

unsigned int la_i86_gnu_pltexit(Elf32_Sym *sym, unsigned int ndx,
 uintptr_t *refcook, uintptr_t *defcook,
 const La_i86_regs *inregs, La_i86_retval *outregs,
 const char *symname);

This function is called when a PLT entry, made between two shared objects that have been marked for binding notification, returns. The function is called just before control returns to the caller of the PLT entry.

The sym, ndx, refcook, defcook, and symname are as for la_symbind*().

The inregs argument points to a structure (defined in <link.h>) containing the values of registers used for the call to this PLT entry. The outregs argument points to a structure (defined in <link.h>) containing return values for the call to this PLT entry. These values can be modified by the caller, and the changes will be visible to the caller of the PLT entry.

In the current GNU implementation, the return value of la_pltexit() is ignored.

VERSIONS

This API is very similar to the Solaris API described in the Solaris Linker and Libraries Guide, in the chapter Runtime Linker Auditing Interface.

STANDARDS

None.

NOTES

Note the following differences from the Solaris dynamic linker auditing API:

  • The Solaris la_objfilter() interface is not supported by the GNU implementation.

  • The Solaris la_symbind32() and la_pltexit() functions do not provide a symname argument.

  • The Solaris la_pltexit() function does not provide inregs and outregs arguments (but does provide a retval argument with the function return value).

BUGS

In glibc versions up to and include 2.9, specifying more than one audit library in LD_AUDIT results in a run-time crash. This is reportedly fixed in glibc 2.10.

EXAMPLES

#include <link.h>
#include <stdio.h>
unsigned int
la_version(unsigned int version)
{
    printf("la_version(): version = %u; LAV_CURRENT = %u

“, version, LAV_CURRENT); return LAV_CURRENT; } char * la_objsearch(const char *name, uintptr_t *cookie, unsigned int flag) { printf(“la_objsearch(): name = %s; cookie = %p”, name, cookie); printf(”; flag = %s “, (flag == LA_SER_ORIG) ? “LA_SER_ORIG” : (flag == LA_SER_LIBPATH) ? “LA_SER_LIBPATH” : (flag == LA_SER_RUNPATH) ? “LA_SER_RUNPATH” : (flag == LA_SER_DEFAULT) ? “LA_SER_DEFAULT” : (flag == LA_SER_CONFIG) ? “LA_SER_CONFIG” : (flag == LA_SER_SECURE) ? “LA_SER_SECURE” : “???”); return name; } void la_activity (uintptr_t *cookie, unsigned int flag) { printf(“la_activity(): cookie = %p; flag = %s “, cookie, (flag == LA_ACT_CONSISTENT) ? “LA_ACT_CONSISTENT” : (flag == LA_ACT_ADD) ? “LA_ACT_ADD” : (flag == LA_ACT_DELETE) ? “LA_ACT_DELETE” : “???”); } unsigned int la_objopen(struct link_map *map, Lmid_t lmid, uintptr_t *cookie) { printf(“la_objopen(): loading "%s"; lmid = %s; cookie=%p “, map->l_name, (lmid == LM_ID_BASE) ? “LM_ID_BASE” : (lmid == LM_ID_NEWLM) ? “LM_ID_NEWLM” : “???”, cookie); return LA_FLG_BINDTO | LA_FLG_BINDFROM; } unsigned int la_objclose (uintptr_t *cookie) { printf(“la_objclose(): %p “, cookie); return 0; } void la_preinit(uintptr_t *cookie) { printf(“la_preinit(): %p “, cookie); } uintptr_t la_symbind32(Elf32_Sym *sym, unsigned int ndx, uintptr_t *refcook, uintptr_t *defcook, unsigned int *flags, const char *symname) { printf(“la_symbind32(): symname = %s; sym->st_value = %p “, symname, sym->st_value); printf(” ndx = %u; flags = %#x”, ndx, *flags); printf(”; refcook = %p; defcook = %p “, refcook, defcook); return sym->st_value; } uintptr_t la_symbind64(Elf64_Sym *sym, unsigned int ndx, uintptr_t *refcook, uintptr_t *defcook, unsigned int *flags, const char *symname) { printf(“la_symbind64(): symname = %s; sym->st_value = %p “, symname, sym->st_value); printf(” ndx = %u; flags = %#x”, ndx, *flags); printf(”; refcook = %p; defcook = %p “, refcook, defcook); return sym->st_value; } Elf32_Addr la_i86_gnu_pltenter(Elf32_Sym *sym, unsigned int ndx, uintptr_t *refcook, uintptr_t *defcook, La_i86_regs *regs, unsigned int *flags, const char *symname, long *framesizep) { printf(“la_i86_gnu_pltenter(): %s (%p) “, symname, sym->st_value); return sym->st_value; }

SEE ALSO

ldd(1), dlopen(3), ld.so(8), ldconfig(8)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

33 - Linux cli command systemd.directives

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command systemd.directives and provides detailed information about the command systemd.directives, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the systemd.directives.

NAME 🖥️ systemd.directives 🖥️

Index of configuration directives

UNIT DIRECTIVES

Directives for configuring units, used in unit files.

Accept=

systemd.socket(5)

AccuracySec=

systemd.timer(5)

After=

systemd.unit(5)

Alias=

systemd.unit(5)

AllowIsolate=

systemd.unit(5)

AllowedCPUs=

systemd.resource-control(5)

AllowedMemoryNodes=

systemd.resource-control(5)

Also=

systemd.unit(5)

AmbientCapabilities=

systemd.exec(5)

AppArmorProfile=

systemd.exec(5)

AssertACPower=

systemd.unit(5)

AssertArchitecture=

systemd.unit(5)

AssertCPUFeature=

systemd.unit(5)

AssertCPUPressure=

systemd.unit(5)

AssertCPUs=

systemd.unit(5)

AssertCapability=

systemd.unit(5)

AssertControlGroupController=

systemd.unit(5)

AssertCredential=

systemd.unit(5)

AssertDirectoryNotEmpty=

systemd.unit(5)

AssertEnvironment=

systemd.unit(5)

AssertFileIsExecutable=

systemd.unit(5)

AssertFileNotEmpty=

systemd.unit(5)

AssertFirstBoot=

systemd.unit(5)

AssertGroup=

systemd.unit(5)

AssertHost=

systemd.unit(5)

AssertIOPressure=

systemd.unit(5)

AssertKernelCommandLine=

systemd.unit(5)

AssertKernelVersion=

systemd.unit(5)

AssertMemory=

systemd.unit(5)

AssertMemoryPressure=

systemd.unit(5)

AssertNeedsUpdate=

systemd.unit(5)

AssertOSRelease=

systemd.unit(5)

AssertPathExists=

systemd.unit(5)

AssertPathExistsGlob=

systemd.unit(5)

AssertPathIsDirectory=

systemd.unit(5)

AssertPathIsEncrypted=

systemd.unit(5)

AssertPathIsMountPoint=

systemd.unit(5)

AssertPathIsReadWrite=

systemd.unit(5)

AssertPathIsSymbolicLink=

systemd.unit(5)

AssertSecurity=

systemd.unit(5)

AssertUser=

systemd.unit(5)

AssertVirtualization=

systemd.unit(5)

BPFProgram=

systemd.resource-control(5)

Backlog=

systemd.socket(5)

Before=

systemd.unit(5)

BindIPv6Only=

systemd.socket(5)

BindPaths=

systemd.exec(5)

BindReadOnlyPaths=

systemd.exec(5)

BindToDevice=

systemd.socket(5)

BindsTo=

systemd.unit(5)

Broadcast=

systemd.socket(5)

BusName=

systemd.service(5)

CPUAccounting=

systemd.resource-control(5)

CPUAffinity=

systemd.exec(5)

CPUQuota=

systemd.resource-control(5)

CPUQuotaPeriodSec=

systemd.resource-control(5)

CPUSchedulingPolicy=

systemd.exec(5)

CPUSchedulingPriority=

systemd.exec(5)

CPUSchedulingResetOnFork=

systemd.exec(5)

CPUWeight=

systemd.resource-control(5)

CacheDirectory=

systemd.exec(5)

CacheDirectoryMode=

systemd.exec(5)

CapabilityBoundingSet=

systemd.exec(5)

CollectMode=

systemd.unit(5)

ConditionACPower=

systemd.unit(5)

ConditionArchitecture=

systemd.unit(5)

ConditionCPUFeature=

systemd.unit(5)

ConditionCPUPressure=

systemd.unit(5)

ConditionCPUs=

systemd.unit(5)

ConditionCapability=

systemd.unit(5)

ConditionControlGroupController=

systemd.unit(5)

ConditionCredential=

systemd.unit(5)

ConditionDirectoryNotEmpty=

systemd.unit(5)

ConditionEnvironment=

systemd.unit(5)

ConditionFileIsExecutable=

systemd.unit(5)

ConditionFileNotEmpty=

systemd.unit(5)

ConditionFirmware=

systemd.unit(5)

ConditionFirstBoot=

systemd.unit(5)

ConditionGroup=

systemd.unit(5)

ConditionHost=

systemd.unit(5)

ConditionIOPressure=

systemd.unit(5)

ConditionKernelCommandLine=

systemd.unit(5)

ConditionKernelVersion=

systemd.unit(5)

ConditionMemory=

systemd.unit(5)

ConditionMemoryPressure=

systemd.unit(5)

ConditionNeedsUpdate=

systemd.unit(5)

ConditionOSRelease=

systemd.unit(5)

ConditionPathExists=

systemd.unit(5)

ConditionPathExistsGlob=

systemd.unit(5)

ConditionPathIsDirectory=

systemd.unit(5)

ConditionPathIsEncrypted=

systemd.unit(5)

ConditionPathIsMountPoint=

systemd.unit(5)

ConditionPathIsReadWrite=

systemd.unit(5)

ConditionPathIsSymbolicLink=

systemd.unit(5)

ConditionSecurity=

systemd.unit(5)

ConditionUser=

systemd.unit(5)

ConditionVirtualization=

systemd.unit(5)

ConfigurationDirectory=

systemd.exec(5)

ConfigurationDirectoryMode=

systemd.exec(5)

Conflicts=

systemd.unit(5)

CoredumpFilter=

systemd.exec(5)

CoredumpReceive=

systemd.resource-control(5)

DefaultDependencies=

systemd.unit(5)

DefaultInstance=

systemd.unit(5)

DefaultStartupMemoryLow=

systemd.resource-control(5)

DeferAcceptSec=

systemd.socket(5)

Delegate=

systemd.resource-control(5)

DelegateSubgroup=

systemd.resource-control(5)

Description=

systemd.unit(5)

DeviceAllow=

systemd.resource-control(5)

DevicePolicy=

systemd.resource-control(5)

DirectoryMode=

systemd.automount(5), systemd.mount(5), systemd.path(5), systemd.socket(5)

DirectoryNotEmpty=

systemd.path(5)

DisableControllers=

systemd.resource-control(5)

Documentation=

systemd.unit(5)

DynamicUser=

systemd.exec(5)

Environment=

systemd.exec(5)

EnvironmentFile=

systemd.exec(5)

ExecCondition=

systemd.service(5)

ExecPaths=

systemd.exec(5)

ExecReload=

systemd.service(5)

ExecSearchPath=

systemd.exec(5)

ExecStart=

systemd.service(5)

ExecStartPost=

systemd.service(5), systemd.socket(5)

ExecStartPre=

systemd.service(5), systemd.socket(5)

ExecStop=

systemd.service(5)

ExecStopPost=

systemd.service(5), systemd.socket(5)

ExecStopPre=

systemd.socket(5)

ExitType=

systemd.service(5)

ExtensionDirectories=

systemd.exec(5)

ExtensionImagePolicy=

systemd.exec(5)

ExtensionImages=

systemd.exec(5)

ExtraOptions=

systemd.automount(5)

FailureAction=

systemd.unit(5)

FailureActionExitStatus=

systemd.unit(5)

FileDescriptorName=

systemd.socket(5)

FileDescriptorStoreMax=

systemd.service(5)

FileDescriptorStorePreserve=

systemd.service(5)

FinalKillSignal=

systemd.kill(5)

FixedRandomDelay=

systemd.timer(5)

FlushPending=

systemd.socket(5)

ForceUnmount=

systemd.mount(5)

FreeBind=

systemd.socket(5)

Group=

systemd.exec(5)

GuessMainPID=

systemd.service(5)

IOAccounting=

systemd.resource-control(5)

IODeviceLatencyTargetSec=

systemd.resource-control(5)

IODeviceWeight=

systemd.resource-control(5)

IOReadBandwidthMax=

systemd.resource-control(5)

IOReadIOPSMax=

systemd.resource-control(5)

IOSchedulingClass=

systemd.exec(5)

IOSchedulingPriority=

systemd.exec(5)

IOWeight=

systemd.resource-control(5)

IOWriteBandwidthMax=

systemd.resource-control(5)

IOWriteIOPSMax=

systemd.resource-control(5)

IPAccounting=

systemd.resource-control(5)

IPAddressAllow=

systemd.resource-control(5)

IPAddressDeny=

systemd.resource-control(5)

IPCNamespacePath=

systemd.exec(5)

IPEgressFilterPath=

systemd.resource-control(5)

IPIngressFilterPath=

systemd.resource-control(5)

IPTOS=

systemd.socket(5)

IPTTL=

systemd.socket(5)

IgnoreOnIsolate=

systemd.unit(5)

IgnoreSIGPIPE=

systemd.exec(5)

ImportCredential=

systemd.exec(5)

InaccessiblePaths=

systemd.exec(5)

JobRunningTimeoutSec=

systemd.unit(5)

JobTimeoutAction=

systemd.unit(5)

JobTimeoutRebootArgument=

systemd.unit(5)

JobTimeoutSec=

systemd.unit(5)

JoinsNamespaceOf=

systemd.unit(5)

KeepAlive=

systemd.socket(5)

KeepAliveIntervalSec=

systemd.socket(5)

KeepAliveProbes=

systemd.socket(5)

KeepAliveTimeSec=

systemd.socket(5)

KeyringMode=

systemd.exec(5)

KillMode=

systemd.kill(5)

KillSignal=

systemd.kill(5)

LazyUnmount=

systemd.mount(5)

LimitAS=

systemd.exec(5)

LimitCORE=

systemd.exec(5)

LimitCPU=

systemd.exec(5)

LimitDATA=

systemd.exec(5)

LimitFSIZE=

systemd.exec(5)

LimitLOCKS=

systemd.exec(5)

LimitMEMLOCK=

systemd.exec(5)

LimitMSGQUEUE=

systemd.exec(5)

LimitNICE=

systemd.exec(5)

LimitNOFILE=

systemd.exec(5)

LimitNPROC=

systemd.exec(5)

LimitRSS=

systemd.exec(5)

LimitRTPRIO=

systemd.exec(5)

LimitRTTIME=

systemd.exec(5)

LimitSIGPENDING=

systemd.exec(5)

LimitSTACK=

systemd.exec(5)

ListenDatagram=

systemd.socket(5)

ListenFIFO=

systemd.socket(5)

ListenMessageQueue=

systemd.socket(5)

ListenNetlink=

systemd.socket(5)

ListenSequentialPacket=

systemd.socket(5)

ListenSpecial=

systemd.socket(5)

ListenStream=

systemd.socket(5)

ListenUSBFunction=

systemd.socket(5)

LoadCredential=

systemd.exec(5)

LoadCredentialEncrypted=

systemd.exec(5)

LockPersonality=

systemd.exec(5)

LogExtraFields=

systemd.exec(5)

LogFilterPatterns=

systemd.exec(5)

LogLevelMax=

systemd.exec(5)

LogNamespace=

systemd.exec(5)

LogRateLimitBurst=

systemd.exec(5)

LogRateLimitIntervalSec=

systemd.exec(5)

LogsDirectory=

systemd.exec(5)

LogsDirectoryMode=

systemd.exec(5)

MakeDirectory=

systemd.path(5)

ManagedOOMMemoryPressure=

systemd.resource-control(5)

ManagedOOMMemoryPressureLimit=

systemd.resource-control(5)

ManagedOOMPreference=

systemd.resource-control(5)

ManagedOOMSwap=

systemd.resource-control(5)

Mark=

systemd.socket(5)

MaxConnections=

systemd.socket(5)

MaxConnectionsPerSource=

systemd.socket(5)

MemoryAccounting=

systemd.resource-control(5)

MemoryDenyWriteExecute=

systemd.exec(5)

MemoryHigh=

systemd.resource-control(5)

MemoryKSM=

systemd.exec(5)

MemoryLow=

systemd.resource-control(5)

MemoryMax=

systemd.resource-control(5)

MemoryMin=

systemd.resource-control(5)

MemoryPressureThresholdSec=

systemd.resource-control(5)

MemoryPressureWatch=

systemd.resource-control(5)

MemorySwapMax=

systemd.resource-control(5)

MemoryZSwapMax=

systemd.resource-control(5)

MemoryZSwapWriteback=

systemd.resource-control(5)

MessageQueueMaxMessages=

systemd.socket(5)

MessageQueueMessageSize=

systemd.socket(5)

MountAPIVFS=

systemd.exec(5)

MountFlags=

systemd.exec(5)

MountImagePolicy=

systemd.exec(5)

MountImages=

systemd.exec(5)

NFTSet=

systemd.resource-control(5)

NUMAMask=

systemd.exec(5)

NUMAPolicy=

systemd.exec(5)

NetworkNamespacePath=

systemd.exec(5)

Nice=

systemd.exec(5)

NoDelay=

systemd.socket(5)

NoExecPaths=

systemd.exec(5)

NoNewPrivileges=

systemd.exec(5)

NonBlocking=

systemd.service(5)

NotifyAccess=

systemd.service(5)

OOMPolicy=

systemd.scope(5), systemd.service(5)

OOMScoreAdjust=

systemd.exec(5)

OnActiveSec=

systemd.timer(5)

OnBootSec=

systemd.timer(5)

OnCalendar=

systemd.timer(5)

OnClockChange=

systemd.timer(5)

OnFailure=

systemd.unit(5)

OnFailureJobMode=

systemd.unit(5)

OnStartupSec=

systemd.timer(5)

OnSuccess=

systemd.unit(5)

OnSuccessJobMode=

systemd.unit(5)

OnTimezoneChange=

systemd.timer(5)

OnUnitActiveSec=

systemd.timer(5)

OnUnitInactiveSec=

systemd.timer(5)

OpenFile=

systemd.service(5)

Options=

systemd.mount(5), systemd.swap(5)

PAMName=

systemd.exec(5)

PIDFile=

systemd.service(5)

PartOf=

systemd.unit(5)

PassCredentials=

systemd.socket(5)

PassEnvironment=

systemd.exec(5)

PassFileDescriptorsToExec=

systemd.socket(5)

PassPacketInfo=

systemd.socket(5)

PassSecurity=

systemd.socket(5)

PathChanged=

systemd.path(5)

PathExists=

systemd.path(5)

PathExistsGlob=

systemd.path(5)

PathModified=

systemd.path(5)

Persistent=

systemd.timer(5)

Personality=

systemd.exec(5)

PipeSize=

systemd.socket(5)

PollLimitBurst=

systemd.socket(5)

PollLimitIntervalSec=

systemd.socket(5)

Priority=

systemd.socket(5), systemd.swap(5)

PrivateDevices=

systemd.exec(5)

PrivateIPC=

systemd.exec(5)

PrivateMounts=

systemd.exec(5)

PrivateNetwork=

systemd.exec(5)

PrivateTmp=

systemd.exec(5)

PrivateUsers=

systemd.exec(5)

ProcSubset=

systemd.exec(5)

PropagatesReloadTo=

systemd.unit(5)

PropagatesStopTo=

systemd.unit(5)

ProtectClock=

systemd.exec(5)

ProtectControlGroups=

systemd.exec(5)

ProtectHome=

systemd.exec(5)

ProtectHostname=

systemd.exec(5)

ProtectKernelLogs=

systemd.exec(5)

ProtectKernelModules=

systemd.exec(5)

ProtectKernelTunables=

systemd.exec(5)

ProtectProc=

systemd.exec(5)

ProtectSystem=

systemd.exec(5)

RandomizedDelaySec=

systemd.timer(5)

ReadOnlyPaths=

systemd.exec(5)

ReadWriteOnly=

systemd.mount(5)

ReadWritePaths=

systemd.exec(5)

RebootArgument=

systemd.unit(5)

ReceiveBuffer=

systemd.socket(5)

RefuseManualStart=

systemd.unit(5)

RefuseManualStop=

systemd.unit(5)

ReloadPropagatedFrom=

systemd.unit(5)

ReloadSignal=

systemd.service(5)

RemainAfterElapse=

systemd.timer(5)

RemainAfterExit=

systemd.service(5)

RemoveIPC=

systemd.exec(5)

RemoveOnStop=

systemd.socket(5)

RequiredBy=

systemd.unit(5)

Requires=

systemd.unit(5)

RequiresMountsFor=

systemd.unit(5)

Requisite=

systemd.unit(5)

Restart=

systemd.service(5)

RestartForceExitStatus=

systemd.service(5)

RestartKillSignal=

systemd.kill(5)

RestartMaxDelaySec=

systemd.service(5)

RestartMode=

systemd.service(5)

RestartPreventExitStatus=

systemd.service(5)

RestartSec=

systemd.service(5)

RestartSteps=

systemd.service(5)

RestrictAddressFamilies=

systemd.exec(5)

RestrictFileSystems=

systemd.exec(5)

RestrictNamespaces=

systemd.exec(5)

RestrictNetworkInterfaces=

systemd.resource-control(5)

RestrictRealtime=

systemd.exec(5)

RestrictSUIDSGID=

systemd.exec(5)

ReusePort=

systemd.socket(5)

RootDirectory=

systemd.exec(5)

RootDirectoryStartOnly=

systemd.service(5)

RootEphemeral=

systemd.exec(5)

RootHash=

systemd.exec(5)

RootHashSignature=

systemd.exec(5)

RootImage=

systemd.exec(5)

RootImageOptions=

systemd.exec(5)

RootImagePolicy=

systemd.exec(5)

RootVerity=

systemd.exec(5)

RuntimeDirectory=

systemd.exec(5)

RuntimeDirectoryMode=

systemd.exec(5)

RuntimeDirectoryPreserve=

systemd.exec(5)

RuntimeMaxSec=

systemd.scope(5), systemd.service(5)

RuntimeRandomizedExtraSec=

systemd.scope(5), systemd.service(5)

SELinuxContext=

systemd.exec(5)

SELinuxContextFromNet=

systemd.socket(5)

SecureBits=

systemd.exec(5)

SendBuffer=

systemd.socket(5)

SendSIGHUP=

systemd.kill(5)

SendSIGKILL=

systemd.kill(5)

Service=

systemd.socket(5)

SetCredential=

systemd.exec(5)

SetCredentialEncrypted=

systemd.exec(5)

SetLoginEnvironment=

systemd.exec(5)

Slice=

systemd.resource-control(5)

SloppyOptions=

systemd.mount(5)

SmackLabel=

systemd.socket(5)

SmackLabelIPIn=

systemd.socket(5)

SmackLabelIPOut=

systemd.socket(5)

SmackProcessLabel=

systemd.exec(5)

SocketBindAllow=

systemd.resource-control(5)

SocketBindDeny=

systemd.resource-control(5)

SocketGroup=

systemd.socket(5)

SocketMode=

systemd.socket(5)

SocketProtocol=

systemd.socket(5)

SocketUser=

systemd.socket(5)

Sockets=

systemd.service(5)

SourcePath=

systemd.unit(5)

StandardError=

systemd.exec(5)

StandardInput=

systemd.exec(5)

StandardInputData=

systemd.exec(5)

StandardInputText=

systemd.exec(5)

StandardOutput=

systemd.exec(5)

StartLimitAction=

systemd.unit(5)

StartLimitBurst=

systemd.unit(5)

StartLimitIntervalSec=

systemd.unit(5)

StartupAllowedCPUs=

systemd.resource-control(5)

StartupAllowedMemoryNodes=

systemd.resource-control(5)

StartupCPUWeight=

systemd.resource-control(5)

StartupIOWeight=

systemd.resource-control(5)

StartupMemoryHigh=

systemd.resource-control(5)

StartupMemoryLow=

systemd.resource-control(5)

StartupMemoryMax=

systemd.resource-control(5)

StartupMemorySwapMax=

systemd.resource-control(5)

StartupMemoryZSwapMax=

systemd.resource-control(5)

StateDirectory=

systemd.exec(5)

StateDirectoryMode=

systemd.exec(5)

StopPropagatedFrom=

systemd.unit(5)

StopWhenUnneeded=

systemd.unit(5)

SuccessAction=

systemd.unit(5)

SuccessActionExitStatus=

systemd.unit(5)

SuccessExitStatus=

systemd.service(5)

SupplementaryGroups=

systemd.exec(5)

SurviveFinalKillSignal=

systemd.unit(5)

Symlinks=

systemd.socket(5)

SyslogFacility=

systemd.exec(5)

SyslogIdentifier=

systemd.exec(5)

SyslogLevel=

systemd.exec(5)

SyslogLevelPrefix=

systemd.exec(5)

SystemCallArchitectures=

systemd.exec(5)

SystemCallErrorNumber=

systemd.exec(5)

SystemCallFilter=

systemd.exec(5)

SystemCallLog=

systemd.exec(5)

TCPCongestion=

systemd.socket(5)

TTYColumns=

systemd.exec(5)

TTYPath=

systemd.exec(5)

TTYReset=

systemd.exec(5)

TTYRows=

systemd.exec(5)

TTYVHangup=

systemd.exec(5)

TTYVTDisallocate=

systemd.exec(5)

TasksAccounting=

systemd.resource-control(5)

TasksMax=

systemd.resource-control(5)

TemporaryFileSystem=

systemd.exec(5)

TimeoutAbortSec=

systemd.service(5)

TimeoutCleanSec=

systemd.exec(5)

TimeoutIdleSec=

systemd.automount(5)

TimeoutSec=

systemd.mount(5), systemd.service(5), systemd.socket(5), systemd.swap(5)

TimeoutStartFailureMode=

systemd.service(5)

TimeoutStartSec=

systemd.service(5)

TimeoutStopFailureMode=

systemd.service(5)

TimeoutStopSec=

systemd.service(5)

TimerSlackNSec=

systemd.exec(5)

Timestamping=

systemd.socket(5)

Transparent=

systemd.socket(5)

TriggerLimitBurst=

systemd.path(5), systemd.socket(5)

TriggerLimitIntervalSec=

systemd.path(5), systemd.socket(5)

Type=

systemd.mount(5), systemd.service(5)

UMask=

systemd.exec(5)

USBFunctionDescriptors=

systemd.service(5)

USBFunctionStrings=

systemd.service(5)

Unit=

systemd.path(5), systemd.timer(5)

UnsetEnvironment=

systemd.exec(5)

UpheldBy=

systemd.unit(5)

Upholds=

systemd.unit(5)

User=

systemd.exec(5)

UtmpIdentifier=

systemd.exec(5)

UtmpMode=

systemd.exec(5)

WakeSystem=

systemd.timer(5)

WantedBy=

systemd.unit(5)

Wants=

systemd.unit(5)

WantsMountsFor=

systemd.unit(5)

WatchdogSec=

systemd.service(5)

WatchdogSignal=

systemd.kill(5)

What=

systemd.mount(5), systemd.swap(5)

Where=

systemd.automount(5), systemd.mount(5)

WorkingDirectory=

systemd.exec(5)

Writable=

systemd.socket(5)

OPTIONS ON THE KERNEL COMMAND LINE

Kernel boot options for configuring the behaviour of the systemd process.

-b

kernel-command-line(7), systemd(1)

1

kernel-command-line(7), systemd(1)

2

kernel-command-line(7), systemd(1)

3

kernel-command-line(7), systemd(1)

4

kernel-command-line(7), systemd(1)

5

kernel-command-line(7), systemd(1)

S

kernel-command-line(7), systemd(1)

bond=

systemd-network-generator.service(8)

bootdev=

systemd-network-generator.service(8)

bridge=

systemd-network-generator.service(8)

debug

kernel-command-line(7), systemd(1)

domain=

kernel-command-line(7), systemd-resolved.service(8)

emergency

kernel-command-line(7), systemd(1)

fsck.mode=

kernel-command-line(7), [email protected](8)

fsck.repair=

kernel-command-line(7), [email protected](8)

fstab=

kernel-command-line(7), systemd-fstab-generator(8)

ifname=

kernel-command-line(7), systemd-network-generator.service(8)

ip=

systemd-network-generator.service(8)

locale.LANG=

kernel-command-line(7), systemd(1)

locale.LANGUAGE=

kernel-command-line(7), systemd(1)

locale.LC_ADDRESS=

kernel-command-line(7), systemd(1)

locale.LC_COLLATE=

kernel-command-line(7), systemd(1)

locale.LC_CTYPE=

kernel-command-line(7), systemd(1)

locale.LC_IDENTIFICATION=

kernel-command-line(7), systemd(1)

locale.LC_MEASUREMENT=

kernel-command-line(7), systemd(1)

locale.LC_MESSAGES=

kernel-command-line(7), systemd(1)

locale.LC_MONETARY=

kernel-command-line(7), systemd(1)

locale.LC_NAME=

kernel-command-line(7), systemd(1)

locale.LC_NUMERIC=

kernel-command-line(7), systemd(1)

locale.LC_PAPER=

kernel-command-line(7), systemd(1)

locale.LC_TELEPHONE=

kernel-command-line(7), systemd(1)

locale.LC_TIME=

kernel-command-line(7), systemd(1)

luks.crypttab=

kernel-command-line(7), systemd-cryptsetup-generator(8)

luks.data=

systemd-cryptsetup-generator(8)

luks.key=

kernel-command-line(7), systemd-cryptsetup-generator(8)

luks.name=

kernel-command-line(7), systemd-cryptsetup-generator(8)

luks.options=

kernel-command-line(7), systemd-cryptsetup-generator(8)

luks.uuid=

kernel-command-line(7), systemd-cryptsetup-generator(8)

luks=

kernel-command-line(7), systemd-cryptsetup-generator(8)

modules_load=

kernel-command-line(7), systemd-modules-load.service(8)

mount.usr=

kernel-command-line(7), systemd-fstab-generator(8)

mount.usrflags=

kernel-command-line(7), systemd-fstab-generator(8)

mount.usrfstype=

kernel-command-line(7), systemd-fstab-generator(8)

nameserver=

kernel-command-line(7), systemd-network-generator.service(8), systemd-resolved.service(8)

net.ifname_policy=

kernel-command-line(7), systemd-network-generator.service(8), systemd-udevd.service(8)

net.ifnames=

kernel-command-line(7), systemd-udevd.service(8)

net.naming_scheme=

kernel-command-line(7), systemd-udevd.service(8)

noresume

systemd-hibernate-resume-generator(8)

plymouth.enable=

kernel-command-line(7)

quiet

kernel-command-line(7), systemd(1)

quotacheck.mode=

kernel-command-line(7), systemd-quotacheck.service(8)

rd.emergency

kernel-command-line(7), systemd(1)

rd.fstab=

kernel-command-line(7), systemd-fstab-generator(8)

rd.luks.crypttab=

kernel-command-line(7), systemd-cryptsetup-generator(8)

rd.luks.data=

systemd-cryptsetup-generator(8)

rd.luks.key=

kernel-command-line(7), systemd-cryptsetup-generator(8)

rd.luks.name=

kernel-command-line(7), systemd-cryptsetup-generator(8)

rd.luks.options=

kernel-command-line(7), systemd-cryptsetup-generator(8)

rd.luks.uuid=

kernel-command-line(7), systemd-cryptsetup-generator(8)

rd.luks=

kernel-command-line(7), systemd-cryptsetup-generator(8)

rd.modules_load=

kernel-command-line(7), systemd-modules-load.service(8)

rd.peerdns=

systemd-network-generator.service(8)

rd.rescue

kernel-command-line(7), systemd(1)

rd.route=

systemd-network-generator.service(8)

rd.systemd.gpt_auto

systemd-gpt-auto-generator(8)

rd.systemd.gpt_auto=

kernel-command-line(7)

rd.systemd.image_policy=

kernel-command-line(7), systemd-gpt-auto-generator(8)

rd.systemd.mount-extra=

systemd-fstab-generator(8)

rd.systemd.swap-extra=

systemd-fstab-generator(8)

rd.systemd.unit=

kernel-command-line(7), systemd(1)

rd.systemd.verity=

kernel-command-line(7), systemd-veritysetup-generator(8)

rd.udev.blockdev_read_only

kernel-command-line(7), systemd-udevd.service(8)

rd.udev.children_max=

kernel-command-line(7), systemd-udevd.service(8)

rd.udev.event_timeout=

kernel-command-line(7), systemd-udevd.service(8)

rd.udev.exec_delay=

kernel-command-line(7), systemd-udevd.service(8)

rd.udev.log_level=

kernel-command-line(7), systemd-udevd.service(8)

rd.udev.timeout_signal=

kernel-command-line(7), systemd-udevd.service(8)

rd.veritytab=

kernel-command-line(7)

rescue

kernel-command-line(7), systemd(1)

resume=

kernel-command-line(7), systemd-hibernate-resume-generator(8)

resume_offset=

kernel-command-line(7), systemd-hibernate-resume-generator(8)

resumeflags=

kernel-command-line(7), systemd-hibernate-resume-generator(8)

ro

kernel-command-line(7), systemd-gpt-auto-generator(8)

root=

kernel-command-line(7), systemd-fstab-generator(8), systemd-gpt-auto-generator(8)

rootflags=

kernel-command-line(7), systemd-fstab-generator(8), systemd-gpt-auto-generator(8)

rootfstype=

kernel-command-line(7), systemd-fstab-generator(8), systemd-gpt-auto-generator(8)

roothash=

kernel-command-line(7), systemd-fstab-generator(8), systemd-veritysetup-generator(8)

rw

kernel-command-line(7), systemd-gpt-auto-generator(8)

s

kernel-command-line(7), systemd(1)

single

kernel-command-line(7), systemd(1)

systemd.allow_userspace_verity=

kernel-command-line(7)

systemd.battery_check=

kernel-command-line(7), systemd-battery-check.service(8)

systemd.clock_usec=

kernel-command-line(7)

systemd.condition_first_boot=

kernel-command-line(7)

systemd.condition_needs_update=

kernel-command-line(7)

systemd.confirm_spawn

kernel-command-line(7), systemd(1)

systemd.cpu_affinity=

kernel-command-line(7)

systemd.crash_action=

kernel-command-line(7), systemd(1)

systemd.crash_chvt

kernel-command-line(7), systemd(1)

systemd.crash_shell

kernel-command-line(7), systemd(1)

systemd.debug_shell

kernel-command-line(7)

systemd.default_debug_tty=

kernel-command-line(7)

systemd.default_device_timeout_sec=

kernel-command-line(7)

systemd.default_standard_error=

kernel-command-line(7), systemd(1)

systemd.default_standard_output=

kernel-command-line(7), systemd(1)

systemd.default_timeout_start_sec=

kernel-command-line(7)

systemd.dump_core

kernel-command-line(7), systemd(1)

systemd.early_core_pattern=

kernel-command-line(7)

systemd.firstboot=

homectl(1), kernel-command-line(7), systemd-firstboot(1)

systemd.getty_auto=

kernel-command-line(7), systemd-getty-generator(8)

systemd.gpt_auto

systemd-gpt-auto-generator(8)

systemd.gpt_auto=

kernel-command-line(7)

systemd.hostname=

kernel-command-line(7)

systemd.image_policy=

kernel-command-line(7), systemd-gpt-auto-generator(8)

systemd.import_credentials=

kernel-command-line(7), systemd(1)

systemd.journald.forward_to_console=

kernel-command-line(7), systemd-journald.service(8)

systemd.journald.forward_to_kmsg=

kernel-command-line(7), systemd-journald.service(8)

systemd.journald.forward_to_syslog=

kernel-command-line(7), systemd-journald.service(8)

systemd.journald.forward_to_wall=

kernel-command-line(7), systemd-journald.service(8)

systemd.journald.max_level_console=

systemd-journald.service(8)

systemd.journald.max_level_kmsg=

systemd-journald.service(8)

systemd.journald.max_level_socket=

systemd-journald.service(8)

systemd.journald.max_level_store=

systemd-journald.service(8)

systemd.journald.max_level_syslog=

systemd-journald.service(8)

systemd.journald.max_level_wall=

systemd-journald.service(8)

systemd.log_color

kernel-command-line(7), systemd(1)

systemd.log_level=

kernel-command-line(7), systemd(1)

systemd.log_location

systemd(1)

systemd.log_location=

kernel-command-line(7)

systemd.log_ratelimit_kmsg

kernel-command-line(7), systemd(1)

systemd.log_target=

kernel-command-line(7), systemd(1)

systemd.log_tid

systemd(1)

systemd.log_time

systemd(1)

systemd.machine_id=

kernel-command-line(7), systemd(1)

systemd.mask=

kernel-command-line(7)

systemd.mount-extra=

systemd-fstab-generator(8)

systemd.random_seed=

kernel-command-line(7)

systemd.reload_limit_burst=

kernel-command-line(7)

systemd.reload_limit_interval_sec=

kernel-command-line(7)

systemd.restore_state=

kernel-command-line(7), [email protected](8), systemd-rfkill.service(8)

systemd.run=

kernel-command-line(7)

systemd.run_failure_action=

kernel-command-line(7)

systemd.run_success_action=

kernel-command-line(7)

systemd.service_watchdogs

kernel-command-line(7)

systemd.service_watchdogs=

systemd(1)

systemd.set_credential=

kernel-command-line(7), systemd(1)

systemd.set_credential_binary=

kernel-command-line(7), systemd(1)

systemd.setenv=

kernel-command-line(7), systemd(1)

systemd.show_status

kernel-command-line(7), systemd(1)

systemd.ssh_auto=

kernel-command-line(7), systemd-ssh-generator(8)

systemd.ssh_listen=

kernel-command-line(7), systemd-ssh-generator(8)

systemd.status_unit_format=

kernel-command-line(7), systemd(1)

systemd.swap-extra=

systemd-fstab-generator(8)

systemd.swap=

systemd-fstab-generator(8), systemd-gpt-auto-generator(8)

systemd.tpm2_wait=

kernel-command-line(7)

systemd.tty.columns.tty=

kernel-command-line(7)

systemd.tty.rows.tty=

kernel-command-line(7)

systemd.tty.term.tty=

kernel-command-line(7)

systemd.unit=

kernel-command-line(7), systemd(1)

systemd.verity.root_options=

kernel-command-line(7)

systemd.verity=

kernel-command-line(7), systemd-veritysetup-generator(8)

systemd.verity_root_data=

kernel-command-line(7), systemd-veritysetup-generator(8)

systemd.verity_root_hash=

kernel-command-line(7), systemd-veritysetup-generator(8)

systemd.verity_root_options=

systemd-veritysetup-generator(8)

systemd.verity_usr_data=

kernel-command-line(7), systemd-veritysetup-generator(8)

systemd.verity_usr_hash=

kernel-command-line(7), systemd-veritysetup-generator(8)

systemd.verity_usr_options=

kernel-command-line(7), systemd-veritysetup-generator(8)

systemd.volatile=

kernel-command-line(7), systemd-fstab-generator(8)

systemd.wants=

kernel-command-line(7)

systemd.watchdog_device=

kernel-command-line(7)

systemd.watchdog_pre_sec=

kernel-command-line(7)

systemd.watchdog_pretimeout_governor=

kernel-command-line(7)

systemd.watchdog_sec=

kernel-command-line(7)

udev.blockdev_read_only

kernel-command-line(7), systemd-udevd.service(8)

udev.children_max=

kernel-command-line(7), systemd-udevd.service(8)

udev.event_timeout=

kernel-command-line(7), systemd-udevd.service(8)

udev.exec_delay=

kernel-command-line(7), systemd-udevd.service(8)

udev.log_level=

kernel-command-line(7), systemd-udevd.service(8)

udev.timeout_signal=

kernel-command-line(7), systemd-udevd.service(8)

usrhash=

kernel-command-line(7), systemd-fstab-generator(8), systemd-veritysetup-generator(8)

vconsole.font=

kernel-command-line(7)

vconsole.font_map=

kernel-command-line(7)

vconsole.font_unimap=

kernel-command-line(7)

vconsole.keymap=

kernel-command-line(7)

vconsole.keymap_toggle=

kernel-command-line(7)

veritytab=

kernel-command-line(7)

vlan=

systemd-network-generator.service(8)

SMBIOS TYPE 11 VARIABLES

Data passed from VMM to system via SMBIOS Type 11.

io.systemd.boot.kernel-cmdline-extra=

smbios-type-11(7)

io.systemd.credential.binary:

smbios-type-11(7)

io.systemd.credential:

smbios-type-11(7)

io.systemd.stub.kernel-cmdline-extra=

smbios-type-11(7)

ENVIRONMENT VARIABLES

Environment variables understood by the systemd manager and other programs and environment variable-compatible settings.

$CACHE_DIRECTORY

systemd.exec(5)

$CONFIGURATION_DIRECTORY

systemd.exec(5)

$CREDENTIALS_DIRECTORY

systemd.exec(5), systemd.generator(7)

$EMAIL

pam_systemd(8)

$ENCRYPTED_CREDENTIALS_DIRECTORY

systemd.generator(7)

$EXIT_CODE

systemd.exec(5)

$EXIT_STATUS

systemd.exec(5)

$FDSTORE

systemd.exec(5)

$HOME

systemd.exec(5)

$INVOCATION_ID

systemd.exec(5)

$JOURNAL_STREAM

systemd.exec(5)

$LANG

pam_systemd(8), systemd.exec(5)

$LISTEN_FDNAMES

sd_listen_fds(3), systemd(1), systemd-socket-activate(1), systemd.exec(5)

$LISTEN_FDS

sd_listen_fds(3), systemd(1), systemd-socket-activate(1), systemd.exec(5)

$LISTEN_PID

sd_listen_fds(3), systemd(1), systemd-socket-activate(1), systemd.exec(5)

$LOGNAME

systemd.exec(5)

$LOGS_DIRECTORY

systemd.exec(5)

$LOG_NAMESPACE

systemd.exec(5)

$MAINPID

systemd.exec(5)

$MANAGERPID

systemd.exec(5)

$MEMORY_PRESSURE_WATCH

systemd.exec(5)

$MEMORY_PRESSURE_WRITE

systemd.exec(5)

$MONITOR_EXIT_CODE

systemd.exec(5)

$MONITOR_EXIT_STATUS

systemd.exec(5)

$MONITOR_INVOCATION_ID

systemd.exec(5)

$MONITOR_SERVICE_RESULT

systemd.exec(5)

$MONITOR_UNIT

systemd.exec(5)

$NOTIFY_SOCKET

sd_notify(3), systemd(1), systemd.exec(5)

$PATH

systemd.exec(5)

$PIDFILE

systemd.exec(5)

$PREVLEVEL

runlevel(8)

$REMOTE_ADDR

systemd.exec(5)

$REMOTE_PORT

systemd.exec(5)

$RUNLEVEL

runlevel(8)

$RUNTIME_DIRECTORY

systemd.exec(5)

$SERVICE_RESULT

systemd.exec(5)

$SHELL

systemd.exec(5)

$STATE_DIRECTORY

systemd.exec(5)

$SYSTEMD_ARCHITECTURE

systemd.generator(7)

$SYSTEMD_COLORS

homectl(1), importctl(1), journalctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), systemctl(1), systemd(1), systemd-analyze(1), systemd-inhibit(1), systemd-nspawn(1), systemd-tmpfiles(8), timedatectl(1), userdbctl(1)

$SYSTEMD_CONFIDENTIAL_VIRTUALIZATION

systemd.generator(7)

$SYSTEMD_DEBUGGER

coredumpctl(1)

$SYSTEMD_EDITOR

systemctl(1)

$SYSTEMD_ENVIRONMENT_GENERATOR_PATH

systemd(1)

$SYSTEMD_EXEC_PID

systemd.exec(5)

$SYSTEMD_FIRST_BOOT

systemd.generator(7)

$SYSTEMD_GENERATOR_PATH

systemd(1)

$SYSTEMD_GETTY_AUTO

systemd-getty-generator(8)

$SYSTEMD_HOME=

pam_systemd_home(8)

$SYSTEMD_HOME_SUSPEND=

pam_systemd_home(8)

$SYSTEMD_IN_INITRD

systemd.generator(7)

$SYSTEMD_LESS

homectl(1), importctl(1), journalctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), systemctl(1), systemd(1), systemd-analyze(1), systemd-inhibit(1), systemd-nspawn(1), systemd-tmpfiles(8), timedatectl(1), userdbctl(1)

$SYSTEMD_LESSCHARSET

homectl(1), importctl(1), journalctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), systemctl(1), systemd(1), systemd-analyze(1), systemd-inhibit(1), systemd-nspawn(1), systemd-tmpfiles(8), timedatectl(1), userdbctl(1)

$SYSTEMD_LOG_COLOR

homectl(1), importctl(1), journalctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), systemctl(1), systemd(1), systemd-analyze(1), systemd-inhibit(1), systemd-nspawn(1), systemd-socket-activate(1), systemd-tmpfiles(8), timedatectl(1), userdbctl(1)

$SYSTEMD_LOG_LEVEL

homectl(1), importctl(1), journalctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), systemctl(1), systemd(1), systemd-analyze(1), systemd-inhibit(1), systemd-nspawn(1), systemd-socket-activate(1), systemd-tmpfiles(8), timedatectl(1), userdbctl(1)

$SYSTEMD_LOG_LOCATION

homectl(1), importctl(1), journalctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), systemctl(1), systemd(1), systemd-analyze(1), systemd-inhibit(1), systemd-nspawn(1), systemd-socket-activate(1), systemd-tmpfiles(8), timedatectl(1), userdbctl(1)

$SYSTEMD_LOG_RATELIMIT_KMSG

homectl(1), importctl(1), journalctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), systemd(1), systemd-analyze(1), systemd-inhibit(1), systemd-nspawn(1), timedatectl(1), userdbctl(1)

$SYSTEMD_LOG_TARGET

homectl(1), importctl(1), journalctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), systemctl(1), systemd(1), systemd-analyze(1), systemd-inhibit(1), systemd-nspawn(1), systemd-socket-activate(1), systemd-tmpfiles(8), timedatectl(1), userdbctl(1)

$SYSTEMD_LOG_TID

homectl(1), importctl(1), journalctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), systemd(1), systemd-analyze(1), systemd-inhibit(1), systemd-nspawn(1), timedatectl(1), userdbctl(1)

$SYSTEMD_LOG_TIME

homectl(1), importctl(1), journalctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), systemctl(1), systemd(1), systemd-analyze(1), systemd-inhibit(1), systemd-nspawn(1), systemd-socket-activate(1), systemd-tmpfiles(8), timedatectl(1), userdbctl(1)

$SYSTEMD_NSS_RESOLVE_CACHE

nss-resolve(8)

$SYSTEMD_NSS_RESOLVE_NETWORK

nss-resolve(8)

$SYSTEMD_NSS_RESOLVE_SYNTHESIZE

nss-resolve(8)

$SYSTEMD_NSS_RESOLVE_TRUST_ANCHOR

nss-resolve(8)

$SYSTEMD_NSS_RESOLVE_VALIDATE

nss-resolve(8)

$SYSTEMD_NSS_RESOLVE_ZONE

nss-resolve(8)

$SYSTEMD_PAGER

homectl(1), importctl(1), journalctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), systemctl(1), systemd(1), systemd-analyze(1), systemd-inhibit(1), systemd-nspawn(1), systemd-tmpfiles(8), timedatectl(1), userdbctl(1)

$SYSTEMD_PAGERSECURE

homectl(1), importctl(1), journalctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), systemctl(1), systemd(1), systemd-analyze(1), systemd-inhibit(1), systemd-nspawn(1), systemd-tmpfiles(8), timedatectl(1), userdbctl(1)

$SYSTEMD_RANDOM_SEED_CREDIT

systemd-random-seed.service(8)

$SYSTEMD_SCOPE

systemd.generator(7)

$SYSTEMD_UNIT_PATH

systemd(1)

$SYSTEMD_URLIFY

homectl(1), importctl(1), journalctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), systemctl(1), systemd(1), systemd-analyze(1), systemd-inhibit(1), systemd-nspawn(1), systemd-tmpfiles(8), timedatectl(1), userdbctl(1)

$SYSTEMD_VIRTUALIZATION

systemd.generator(7)

$TERM

systemd.exec(5)

$TRIGGER_PATH

systemd.exec(5)

$TRIGGER_TIMER_MONOTONIC_USEC

systemd.exec(5)

$TRIGGER_TIMER_REALTIME_USEC

systemd.exec(5)

$TRIGGER_UNIT

systemd.exec(5)

$TZ

pam_systemd(8)

$USER

systemd.exec(5)

$WATCHDOG_PID

sd_watchdog_enabled(3), systemd.exec(5)

$WATCHDOG_USEC

sd_watchdog_enabled(3), systemd.exec(5)

$XDG_CONFIG_DIRS

systemd(1)

$XDG_CONFIG_HOME

systemd(1)

$XDG_DATA_DIRS

systemd(1)

$XDG_DATA_HOME

systemd(1)

$XDG_RUNTIME_DIR

pam_systemd(8), systemd.exec(5)

$XDG_SEAT

pam_systemd(8)

$XDG_SESSION_CLASS

pam_systemd(8)

$XDG_SESSION_DESKTOP

pam_systemd(8)

$XDG_SESSION_ID

pam_systemd(8)

$XDG_SESSION_TYPE

pam_systemd(8)

$XDG_VTNR

pam_systemd(8)

ANSI_COLOR=

os-release(5)

ARCHITECTURE=

os-release(5)

BUG_REPORT_URL=

os-release(5)

BUILD_ID=

os-release(5)

CHASSIS=

machine-info(5)

CONFEXT_LEVEL=

os-release(5)

CONFEXT_SCOPE=

os-release(5)

CPE_NAME=

os-release(5)

DEFAULT_HOSTNAME=

os-release(5)

DEPLOYMENT=

machine-info(5)

DOCUMENTATION_URL=

os-release(5)

HARDWARE_MODEL=

machine-info(5)

HARDWARE_VENDOR=

machine-info(5)

HOME_URL=

os-release(5)

ICON_NAME=

machine-info(5)

ID=

os-release(5)

ID_LIKE=

os-release(5)

IMAGE_ID=

os-release(5)

IMAGE_VERSION=

os-release(5)

LOCATION=

machine-info(5)

LOGO=

os-release(5)

NAME=

os-release(5)

PORTABLE_PREFIXES=

os-release(5)

PRETTY_HOSTNAME=

machine-info(5)

PRETTY_NAME=

os-release(5)

PRIVACY_POLICY_URL=

os-release(5)

SUPPORT_END=

os-release(5)

SUPPORT_URL=

os-release(5)

SYSEXT_LEVEL=

os-release(5)

SYSEXT_SCOPE=

os-release(5)

VARIANT=

os-release(5)

VARIANT_ID=

os-release(5)

VENDOR_NAME=

os-release(5)

VENDOR_URL=

os-release(5)

VERSION=

os-release(5)

VERSION_CODENAME=

os-release(5)

VERSION_ID=

os-release(5)

SYSTEM CREDENTIALS

System credentials understood by the system and service manager and various other components:

cryptenroll.fido2-pin

systemd-cryptenroll(1)

cryptenroll.new-passphrase

systemd-cryptenroll(1)

cryptenroll.new-tpm2-pin

systemd-cryptenroll(1)

cryptenroll.passphrase

systemd-cryptenroll(1)

cryptenroll.pkcs11-pin

systemd-cryptenroll(1)

cryptenroll.tpm2-pin

systemd-cryptenroll(1)

cryptsetup.fido2-pin

systemd-cryptsetup(8), systemd.system-credentials(7)

cryptsetup.luks2-pin

systemd-cryptsetup(8), systemd.system-credentials(7)

cryptsetup.passphrase

systemd-cryptsetup(8), systemd.system-credentials(7)

cryptsetup.pkcs11-pin

systemd-cryptsetup(8), systemd.system-credentials(7)

cryptsetup.tpm2-pin

systemd-cryptsetup(8), systemd.system-credentials(7)

firstboot.keymap

systemd-firstboot(1), systemd.system-credentials(7)

firstboot.locale

systemd-firstboot(1), systemd.system-credentials(7)

firstboot.locale-messages

systemd-firstboot(1), systemd.system-credentials(7)

firstboot.timezone

systemd-firstboot(1), systemd.system-credentials(7)

fstab.extra

systemd-fstab-generator(8), systemd.system-credentials(7)

getty.ttys.container

systemd-getty-generator(8), systemd.system-credentials(7)

getty.ttys.serial

systemd-getty-generator(8), systemd.system-credentials(7)

home.create.*

homectl(1), systemd.system-credentials(7)

journal.forward_to_socket

systemd-journald.service(8), systemd.system-credentials(7)

journal.storage

systemd-journald.service(8), systemd.system-credentials(7)

login.issue

systemd.system-credentials(7)

login.motd

systemd.system-credentials(7)

network.conf.*

systemd-network-generator.service(8), systemd.system-credentials(7)

network.dns

systemd-resolved.service(8), systemd.system-credentials(7)

network.hosts

systemd.system-credentials(7)

network.link.*

systemd-network-generator.service(8), systemd.system-credentials(7)

network.netdev.*

systemd-network-generator.service(8), systemd.system-credentials(7)

network.network.*

systemd-network-generator.service(8), systemd.system-credentials(7)

network.search_domains

systemd-resolved.service(8), systemd.system-credentials(7)

network.wireguard.*

systemd.system-credentials(7)

passwd.hashed-password.user

systemd-sysusers(8)

passwd.hashed-password.root

systemd-firstboot(1), systemd.system-credentials(7)

passwd.plaintext-password.user

systemd-sysusers(8)

passwd.plaintext-password.root

systemd-firstboot(1), systemd.system-credentials(7)

passwd.shell.user

systemd-sysusers(8)

passwd.shell.root

systemd-firstboot(1), systemd.system-credentials(7)

ssh.authorized_keys.root

systemd.system-credentials(7)

ssh.listen

systemd-ssh-generator(8), systemd.system-credentials(7)

sysctl.extra

systemd-sysctl.service(8), systemd.system-credentials(7)

system.hostname

systemd.system-credentials(7)

system.machine_id

systemd(1), systemd.system-credentials(7)

systemd.extra-unit.*

systemd-debug-generator(8), systemd.system-credentials(7)

systemd.unit-dropin.*

systemd-debug-generator(8), systemd.system-credentials(7)

sysusers.extra

systemd-sysusers(8), systemd.system-credentials(7)

tmpfiles.extra

systemd-tmpfiles(8), systemd.system-credentials(7)

udev.conf.*

systemd.system-credentials(7)

udev.rules.*

systemd.system-credentials(7)

vconsole.font

systemd.system-credentials(7)

vconsole.font_map

systemd.system-credentials(7)

vconsole.font_unimap

systemd.system-credentials(7)

vconsole.keymap

systemd.system-credentials(7)

vconsole.keymap_toggle

systemd.system-credentials(7)

vmm.notify_socket

systemd(1), systemd.system-credentials(7)

EFI VARIABLES

EFI variables understood by systemd-boot(7) and other programs.

LoaderBootCountPath

systemd-boot(7)

LoaderConfigConsoleMode

systemd-boot(7)

LoaderConfigTimeout

systemd-boot(7)

LoaderConfigTimeoutOneShot

systemd-boot(7)

LoaderDevicePartUUID

systemd-boot(7), systemd-stub(7)

LoaderEntries

systemd-boot(7)

LoaderEntryDefault

systemd-boot(7)

LoaderEntryLastBooted

systemd-boot(7)

LoaderEntryOneShot

systemd-boot(7)

LoaderEntrySelected

systemd-boot(7)

LoaderFeatures

systemd-boot(7)

LoaderFirmwareInfo

systemd-boot(7), systemd-stub(7)

LoaderFirmwareType

systemd-boot(7), systemd-stub(7)

LoaderImageIdentifier

systemd-boot(7), systemd-stub(7)

LoaderInfo

systemd-boot(7)

LoaderSystemToken

systemd-boot(7)

LoaderTimeExecUSec

systemd-boot(7)

LoaderTimeInitUSec

systemd-boot(7)

LoaderTimeMenuUsec

systemd-boot(7)

StubInfo

systemd-stub(7)

StubPcrInitRDConfExts

systemd-stub(7)

StubPcrInitRDSysExts

systemd-stub(7)

StubPcrKernelImage

systemd-stub(7)

StubPcrKernelParameters

systemd-stub(7)

HOME AREA/USER ACCOUNT DIRECTIVES

Directives for configuring home areas and user accounts via systemd-homed.service(8).

DefaultFileSystemType=

homed.conf(5)

DefaultStorage=

homed.conf(5)

UDEV DIRECTIVES

Directives for configuring systemd units through the udev database.

$$

udev(7)

$attr{file}

udev(7)

$devnode

udev(7)

$devpath

udev(7)

$driver

udev(7)

$env{key}

udev(7)

$id

udev(7)

$kernel

udev(7)

$links

udev(7)

$major

udev(7)

$minor

udev(7)

$name

udev(7)

$number

udev(7)

$parent

udev(7)

$result

udev(7)

$root

udev(7)

$sys

udev(7)

“%%”

udev(7)

%E{key}

udev(7)

“%M”

udev(7)

“%N”

udev(7)

“%P”

udev(7)

“%S”

udev(7)

“%b”

udev(7)

%c

udev(7)

%k

udev(7)

“%m”

udev(7)

“%n”

udev(7)

“%p”

udev(7)

%r

udev(7)

%s{file}

udev(7)

ACTION

udev(7)

ATTRS{filename}

udev(7)

ATTR{filename}

udev(7)

CONST{key}

udev(7)

DEVPATH

udev(7)

DRIVER

udev(7)

DRIVERS

udev(7)

ENV{key}

udev(7)

GOTO

udev(7)

GROUP

udev(7)

ID_AUTOSEAT

sd-login(3)

ID_FOR_SEAT

sd-login(3)

ID_MODEL=

systemd.device(5)

ID_MODEL_FROM_DATABASE=

systemd.device(5)

ID_SEAT

sd-login(3)

IMPORT{type}

udev(7)

KERNEL

udev(7)

KERNELS

udev(7)

LABEL

udev(7)

MODE

udev(7)

NAME

udev(7)

OPTIONS

udev(7)

OWNER

udev(7)

PROGRAM

udev(7)

RESULT

udev(7)

RUN{type}

udev(7)

SECLABEL{module}

udev(7)

SUBSYSTEM

udev(7)

SUBSYSTEMS

udev(7)

SYMLINK

udev(7)

SYSCTL{kernel parameter}

udev(7)

SYSTEMD_ALIAS=

systemd.device(5)

SYSTEMD_MOUNT_OPTIONS=

systemd-mount(1)

SYSTEMD_MOUNT_WHERE=

systemd-mount(1)

SYSTEMD_READY=

systemd.device(5)

SYSTEMD_USER_WANTS=

systemd.device(5)

SYSTEMD_WANTS=

systemd.device(5)

TAG

udev(7)

TAGS

udev(7)

TEST{octal mode mask}

udev(7)

db_persist

udev(7)

link_priority=

udev(7)

log_level=

udev(7)

nowatch

udev(7)

static_node=

udev(7)

string_escape=

udev(7)

watch

udev(7)

NETWORK DIRECTIVES

Directives for configuring network links through the net-setup-link udev builtin and networks through systemd-networkd.

ARP=

systemd.network(5)

ARPAllTargets=

systemd.netdev(5)

ARPIPTargets=

systemd.netdev(5)

ARPIntervalSec=

systemd.netdev(5)

ARPMissedMax=

systemd.netdev(5)

ARPValidate=

systemd.netdev(5)

AckFilter=

systemd.network(5)

Activate=

systemd.netdev(5)

ActivationPolicy=

systemd.network(5)

ActiveSlave=

systemd.network(5)

AdActorSystem=

systemd.netdev(5)

AdActorSystemPriority=

systemd.netdev(5)

AdSelect=

systemd.netdev(5)

AdUserPortKey=

systemd.netdev(5)

AddPrefixRoute=

systemd.network(5)

Address=

systemd.network(5)

AddressAutoconfiguration=

systemd.network(5)

Advertise=

systemd.link(5)

AgeingTimeSec=

systemd.netdev(5)

Aggregation=

systemd.netdev(5)

Alias=

systemd.link(5)

AllMulticast=

systemd.network(5)

AllSlavesActive=

systemd.netdev(5)

AllowList=

systemd.network(5)

AllowLocalRemote=

systemd.netdev(5)

AllowPortToBeRoot=

systemd.network(5)

AllowedIPs=

systemd.netdev(5)

AlternativeName=

systemd.link(5)

AlternativeNamesPolicy=

systemd.link(5)

Announce=

systemd.network(5)

Anonymize=

systemd.network(5)

Architecture=

systemd.link(5), systemd.netdev(5), systemd.network(5)

Assign=

systemd.network(5)

AssignToLoopback=

systemd.netdev(5)

AssociatedWith=

systemd.network(5)

AutoJoin=

systemd.network(5)

AutoNegotiation=

systemd.link(5)

AutoNegotiationFlowControl=

systemd.link(5)

AutoRateIngress=

systemd.network(5)

BSSID=

systemd.network(5)

Bands=

systemd.network(5)

Bandwidth=

systemd.network(5)

BatmanAdvanced=

systemd.network(5)

BindCarrier=

systemd.network(5)

BindToInterface=

systemd.network(5)

BitRate=

systemd.network(5)

BitsPerSecond=

systemd.link(5)

Blackhole=

systemd.network(5)

Bond=

systemd.network(5)

BootFilename=

systemd.network(5)

BootServerAddress=

systemd.network(5)

BootServerName=

systemd.network(5)

Bridge=

systemd.network(5)

BridgeLoopAvoidance=

systemd.netdev(5)

Broadcast=

systemd.network(5)

BroadcastMulticastQueueLength=

systemd.netdev(5)

BroadcastQueueThreshold=

systemd.netdev(5)

Buckets=

systemd.network(5)

BufferBytes=

systemd.network(5)

BurstBytes=

systemd.network(5)

BusErrorReporting=

systemd.network(5)

CEThresholdSec=

systemd.network(5)

Cache=

resolved.conf(5)

CacheFromLocalhost=

resolved.conf(5)

CeilBufferBytes=

systemd.network(5)

CeilRate=

systemd.network(5)

ClassId=

systemd.network(5)

ClassicDataLengthCode=

systemd.network(5)

ClientIdentifier=

systemd.network(5)

CoalescePacketRateHigh=

systemd.link(5)

CoalescePacketRateLow=

systemd.link(5)

CoalescePacketRateSampleIntervalSec=

systemd.link(5)

CombinedChannels=

systemd.link(5)

CompensationMode=

systemd.network(5)

ConfigureWithoutCarrier=

systemd.network(5)

ConnectionRetrySec=

timesyncd.conf(5)

CopyDSCP=

systemd.netdev(5)

Cost=

systemd.network(5)

Credential=

systemd.link(5), systemd.netdev(5), systemd.network(5)

DHCP=

systemd.network(5)

DHCPPrefixDelegation=

systemd.network(5)

DHCPServer=

systemd.network(5)

DHCPv6Client=

systemd.network(5)

DNS=

resolved.conf(5), systemd.network(5)

DNSDefaultRoute=

systemd.network(5)

DNSLifetimeSec=

systemd.network(5)

DNSOverTLS=

resolved.conf(5), systemd.network(5)

DNSSEC=

resolved.conf(5), systemd.network(5)

DNSSECNegativeTrustAnchors=

systemd.network(5)

DNSStubListener=

resolved.conf(5)

DNSStubListenerExtra=

resolved.conf(5)

DUIDRawData=

networkd.conf(5), systemd.network(5)

DUIDType=

networkd.conf(5), systemd.network(5)

DataBitRate=

systemd.network(5)

DataPhaseBufferSegment1=

systemd.network(5)

DataPhaseBufferSegment2=

systemd.network(5)

DataPropagationSegment=

systemd.network(5)

DataSamplePoint=

systemd.network(5)

DataSyncJumpWidth=

systemd.network(5)

DataTimeQuantaNSec=

systemd.network(5)

DefaultClass=

systemd.network(5)

DefaultLeaseTimeSec=

systemd.network(5)

DefaultPVID=

systemd.netdev(5)

DefaultRouteOnDevice=

systemd.network(5)

DefaultVirtualQueue=

systemd.network(5)

DelayJitterSec=

systemd.network(5)

DelaySec=

systemd.network(5)

DenyList=

systemd.network(5)

Description=

systemd.link(5), systemd.netdev(5), systemd.network(5)

Destination=

systemd.network(5)

DestinationPort=

systemd.netdev(5), systemd.network(5)

DiscoverPathMTU=

systemd.netdev(5)

DistributedArpTable=

systemd.netdev(5)

Domains=

resolved.conf(5), systemd.network(5)

DownDelaySec=

systemd.netdev(5)

Driver=

systemd.link(5), systemd.network(5)

Duplex=

systemd.link(5)

DuplicateAddressDetection=

systemd.network(5)

DuplicateRate=

systemd.network(5)

DynamicTransmitLoadBalancing=

systemd.netdev(5)

ECN=

systemd.network(5)

ERSPANDirection=

systemd.netdev(5)

ERSPANHardwareId=

systemd.netdev(5)

ERSPANIndex=

systemd.netdev(5)

ERSPANVersion=

systemd.netdev(5)

EgressQOSMaps=

systemd.netdev(5)

EgressUntagged=

systemd.network(5)

EmitDNS=

systemd.network(5)

EmitDomains=

systemd.network(5)

EmitLLDP=

systemd.network(5)

EmitLPR=

systemd.network(5)

EmitNTP=

systemd.network(5)

EmitPOP3=

systemd.network(5)

EmitRouter=

systemd.network(5)

EmitSIP=

systemd.network(5)

EmitSMTP=

systemd.network(5)

EmitTimezone=

systemd.network(5)

Encapsulation=

systemd.netdev(5)

EncapsulationLimit=

systemd.netdev(5)

EncapsulationType=

systemd.netdev(5)

Encrypt=

systemd.netdev(5)

Endpoint=

systemd.netdev(5)

EtherType=

systemd.netdev(5)

External=

systemd.netdev(5)

FDBAgeingSec=

systemd.netdev(5)

FDMode=

systemd.network(5)

FDNonISO=

systemd.network(5)

FOUDestinationPort=

systemd.netdev(5)

FOUSourcePort=

systemd.netdev(5)

FailOverMACPolicy=

systemd.netdev(5)

FallbackDNS=

resolved.conf(5)

FallbackLeaseLifetimeSec=

systemd.network(5)

FallbackNTP=

timesyncd.conf(5)

Family=

systemd.network(5)

FastLeave=

systemd.network(5)

FastOpenNoCookie=

systemd.network(5)

FirewallMark=

systemd.netdev(5), systemd.network(5)

Firmware=

systemd.link(5), systemd.netdev(5), systemd.network(5)

Flags=

systemd.netdev(5)

FlowIsolationMode=

systemd.network(5)

FlowLabel=

systemd.netdev(5)

FlowLimit=

systemd.network(5)

Flows=

systemd.network(5)

FooOverUDP=

systemd.netdev(5)

ForwardDelaySec=

systemd.netdev(5)

Fragmentation=

systemd.netdev(5)

From=

systemd.network(5)

GVRP=

systemd.netdev(5)

Gateway=

systemd.network(5)

GatewayBandwidthDown=

systemd.netdev(5)

GatewayBandwidthUp=

systemd.netdev(5)

GatewayMode=

systemd.netdev(5)

GatewayOnLink=

systemd.network(5)

GenericProtocolExtension=

systemd.netdev(5)

GenericRIO=

systemd.network(5)

GenericReceiveOffload=

systemd.link(5)

GenericReceiveOffloadHardware=

systemd.link(5)

GenericSegmentOffloadMaxBytes=

systemd.link(5)

GenericSegmentOffloadMaxSegments=

systemd.link(5)

GenericSegmentationOffload=

systemd.link(5)

GratuitousARP=

systemd.netdev(5)

Group=

systemd.netdev(5), systemd.network(5)

GroupForwardMask=

systemd.netdev(5)

GroupPolicyExtension=

systemd.netdev(5)

HairPin=

systemd.network(5)

Handle=

systemd.network(5)

HelloTimeSec=

systemd.netdev(5)

HomeAddress=

systemd.network(5)

HomeAgent=

systemd.network(5)

HomeAgentLifetimeSec=

systemd.network(5)

HomeAgentPreference=

systemd.network(5)

HopLimit=

systemd.network(5)

HopPenalty=

systemd.netdev(5)

Host=

systemd.link(5), systemd.netdev(5), systemd.network(5)

Hostname=

systemd.network(5)

IAID=

systemd.network(5)

IPDoNotFragment=

systemd.netdev(5)

IPMasquerade=

systemd.network(5)

IPProtocol=

systemd.network(5)

IPServiceType=

systemd.network(5)

IPVLAN=

systemd.network(5)

IPVTAP=

systemd.network(5)

IPoIB=

systemd.network(5)

IPv4AcceptLocal=

systemd.network(5)

IPv4Forwarding=

networkd.conf(5), systemd.network(5)

IPv4LLRoute=

systemd.network(5)

IPv4LLStartAddress=

systemd.network(5)

IPv4ProxyARP=

systemd.network(5)

IPv4ProxyARPPrivateVLAN=

systemd.network(5)

IPv4ReversePathFilter=

systemd.network(5)

IPv4RouteLocalnet=

systemd.network(5)

IPv6AcceptRA=

systemd.network(5)

IPv6DuplicateAddressDetection=

systemd.network(5)

IPv6FlowLabel=

systemd.netdev(5)

IPv6Forwarding=

networkd.conf(5), systemd.network(5)

IPv6HopLimit=

systemd.network(5)

IPv6LinkLocalAddressGenerationMode=

systemd.network(5)

IPv6MTUBytes=

systemd.network(5)

IPv6OnlyMode=

systemd.network(5)

IPv6OnlyPreferredSec=

systemd.network(5)

IPv6Preference=

systemd.network(5)

IPv6PrivacyExtensions=

networkd.conf(5), systemd.network(5)

IPv6ProxyNDP=

systemd.network(5)

IPv6ProxyNDPAddress=

systemd.network(5)

IPv6RapidDeploymentPrefix=

systemd.netdev(5)

IPv6RetransmissionTimeSec=

systemd.network(5)

IPv6SendRA=

systemd.network(5)

IPv6StableSecretAddress=

systemd.network(5)

ISATAP=

systemd.netdev(5)

Id=

systemd.netdev(5), systemd.network(5)

IgnoreCarrierLoss=

systemd.network(5)

IgnoreDontFragment=

systemd.netdev(5)

IgnoreUserspaceMulticastGroup=

systemd.netdev(5), systemd.network(5)

ImportProperty=

systemd.link(5)

IncomingInterface=

systemd.network(5)

Independent=

systemd.netdev(5)

IngressQOSMaps=

systemd.netdev(5)

InheritInnerProtocol=

systemd.netdev(5)

InitialAdvertisedReceiveWindow=

systemd.network(5)

InitialCongestionWindow=

systemd.network(5)

InitialQuantumBytes=

systemd.network(5)

InputKey=

systemd.netdev(5)

InterfaceId=

systemd.netdev(5)

IntervalSec=

systemd.network(5)

InvertRule=

systemd.network(5)

Isolated=

systemd.network(5)

KeepCarrier=

systemd.netdev(5)

KeepConfiguration=

systemd.network(5)

KeepMaster=

systemd.network(5)

KernelCommandLine=

systemd.link(5), systemd.netdev(5), systemd.network(5)

KernelVersion=

systemd.link(5), systemd.netdev(5), systemd.network(5)

Key=

systemd.netdev(5)

KeyFile=

systemd.netdev(5)

KeyId=

systemd.netdev(5)

Kind=

systemd.link(5), systemd.netdev(5), systemd.network(5)

L2MissNotification=

systemd.netdev(5)

L3MasterDevice=

systemd.network(5)

L3MissNotification=

systemd.netdev(5)

LACPTransmitRate=

systemd.netdev(5)

LLDP=

systemd.network(5)

LLMNR=

resolved.conf(5), systemd.network(5)

LPR=

systemd.network(5)

Label=

systemd.network(5)

LargeReceiveOffload=

systemd.link(5)

LatencySec=

systemd.network(5)

Layer2SpecificHeader=

systemd.netdev(5)

LearnPacketIntervalSec=

systemd.netdev(5)

Learning=

systemd.network(5)

LifetimeSec=

systemd.network(5)

LimitBytes=

systemd.network(5)

LinkLayerAddress=

systemd.network(5)

LinkLocalAddressing=

systemd.network(5)

LinkState=

systemd.link(5), systemd.network(5)

ListenOnly=

systemd.network(5)

ListenPort=

systemd.netdev(5), systemd.network(5)

Local=

systemd.netdev(5)

Loopback=

systemd.network(5)

LooseBinding=

systemd.netdev(5)

LossRate=

systemd.network(5)

MACAddress=

systemd.link(5), systemd.netdev(5), systemd.network(5)

MACAddressPolicy=

systemd.link(5)

MACSpoofCheck=

systemd.link(5), systemd.network(5)

MACVLAN=

systemd.network(5)

MACVTAP=

systemd.network(5)

MACsec=

systemd.network(5)

MDI=

systemd.link(5)

MIIMonitorSec=

systemd.netdev(5)

MPUBytes=

systemd.network(5)

MTUBytes=

systemd.link(5), systemd.netdev(5), systemd.network(5)

MUDURL=

systemd.network(5)

MVRP=

systemd.netdev(5)

MacLearning=

systemd.netdev(5)

ManageForeignNextHops=

networkd.conf(5)

ManageForeignRoutes=

networkd.conf(5)

ManageForeignRoutingPolicyRules=

networkd.conf(5)

ManageTemporaryAddress=

systemd.network(5)

Managed=

systemd.network(5)

MaxAgeSec=

systemd.netdev(5)

MaxAttempts=

systemd.network(5)

MaxLeaseTimeSec=

systemd.network(5)

MaxPacketBytes=

systemd.network(5)

MaximumFDBEntries=

systemd.netdev(5)

MaximumRate=

systemd.network(5)

MemoryLimitBytes=

systemd.network(5)

Metric=

systemd.network(5)

MinLinks=

systemd.netdev(5)

Mode=

systemd.netdev(5), systemd.network(5)

MultiPathRoute=

systemd.network(5)

MultiQueue=

systemd.netdev(5)

Multicast=

systemd.network(5)

MulticastDNS=

resolved.conf(5), systemd.network(5)

MulticastFlood=

systemd.network(5)

MulticastGroupAddress=

systemd.network(5)

MulticastIGMPVersion=

systemd.netdev(5)

MulticastQuerier=

systemd.netdev(5)

MulticastRouter=

systemd.network(5)

MulticastSnooping=

systemd.netdev(5)

MulticastToUnicast=

systemd.network(5)

NAT=

systemd.network(5)

NFTSet=

systemd.network(5)

NTP=

systemd.network(5), timesyncd.conf(5)

NTupleFilter=

systemd.link(5)

Name=

systemd.dnssd(5), systemd.link(5), systemd.netdev(5), systemd.network(5)

NamePolicy=

systemd.link(5)

NeighborSuppression=

systemd.network(5)

NetLabel=

systemd.network(5)

NextHop=

systemd.network(5)

OnLink=

systemd.network(5)

OneShot=

systemd.network(5)

OriginalName=

systemd.link(5)

OriginatorIntervalSec=

systemd.netdev(5)

OrphanMask=

systemd.network(5)

OtherChannels=

systemd.link(5)

OtherInformation=

systemd.network(5)

OutgoingInterface=

systemd.network(5)

OutputKey=

systemd.netdev(5)

OverheadBytes=

systemd.network(5)

POP3=

systemd.network(5)

PVID=

systemd.network(5)

Pacing=

systemd.network(5)

PacketInfo=

systemd.netdev(5)

PacketLimit=

systemd.network(5)

PacketNumber=

systemd.netdev(5)

PacketsPerSlave=

systemd.netdev(5)

Parent=

systemd.network(5)

PartitionKey=

systemd.netdev(5)

Path=

systemd.link(5), systemd.network(5)

PeakRate=

systemd.network(5)

Peer=

systemd.netdev(5), systemd.network(5)

PeerNotifyDelaySec=

systemd.netdev(5)

PeerPort=

systemd.netdev(5)

PeerSessionId=

systemd.netdev(5)

PeerTunnelId=

systemd.netdev(5)

PermanentMACAddress=

systemd.link(5), systemd.network(5)

PersistLeases=

systemd.network(5)

PersistentKeepalive=

systemd.netdev(5)

PerturbPeriodSec=

systemd.network(5)

PhaseBufferSegment1=

systemd.network(5)

PhaseBufferSegment2=

systemd.network(5)

PhysicalDevice=

systemd.netdev(5)

PollIntervalMaxSec=

timesyncd.conf(5)

PollIntervalMinSec=

timesyncd.conf(5)

PoolOffset=

systemd.network(5)

PoolSize=

systemd.network(5)

Port=

systemd.dnssd(5), systemd.link(5), systemd.netdev(5)

PortRange=

systemd.netdev(5)

PreferredLifetime=

systemd.network(5)

PreferredLifetimeSec=

systemd.network(5)

PreferredSource=

systemd.network(5)

Prefix=

systemd.network(5)

PrefixAllowList=

systemd.network(5)

PrefixDelegationHint=

systemd.network(5)

PrefixDenyList=

systemd.network(5)

PresharedKey=

systemd.netdev(5)

PresharedKeyFile=

systemd.netdev(5)

PresumeAck=

systemd.network(5)

PrimaryReselectPolicy=

systemd.netdev(5)

PrimarySlave=

systemd.network(5)

Priority=

systemd.dnssd(5), systemd.netdev(5), systemd.network(5)

PriorityMap=

systemd.network(5)

PriorityQueueingPreset=

systemd.network(5)

PrivateKey=

systemd.netdev(5)

PrivateKeyFile=

systemd.netdev(5)

Promiscuous=

systemd.network(5)

PropagationSegment=

systemd.network(5)

Property=

systemd.link(5), systemd.network(5)

Protocol=

systemd.netdev(5), systemd.network(5)

ProxyARP=

systemd.network(5)

ProxyARPWiFi=

systemd.network(5)

PublicKey=

systemd.netdev(5)

QualityOfService=

systemd.link(5), systemd.network(5)

QuantumBytes=

systemd.network(5)

QueryReceiveSideScaling=

systemd.link(5), systemd.network(5)

QuickAck=

systemd.network(5)

RTTSec=

systemd.network(5)

RapidCommit=

systemd.network(5)

Rate=

systemd.network(5)

RateToQuantum=

systemd.network(5)

ReachableTimeSec=

systemd.network(5)

ReadEtcHosts=

resolved.conf(5)

ReceiveChecksumOffload=

systemd.link(5)

ReceivePacketSteeringCPUMask=

systemd.link(5)

ReceiveQueues=

systemd.link(5)

ReceiveVLANCTAGFilter=

systemd.link(5)

ReceiveVLANCTAGHardwareAcceleration=

systemd.link(5)

ReduceARPProxy=

systemd.netdev(5)

RelayAgentCircuitId=

systemd.network(5)

RelayAgentRemoteId=

systemd.network(5)

RelayTarget=

systemd.network(5)

Remote=

systemd.netdev(5)

RemoteChecksumRx=

systemd.netdev(5)

RemoteChecksumTx=

systemd.netdev(5)

ReorderHeader=

systemd.netdev(5)

RequestAddress=

systemd.network(5)

RequestBroadcast=

systemd.network(5)

RequestOptions=

systemd.network(5)

RequiredFamilyForOnline=

systemd.network(5)

RequiredForOnline=

systemd.network(5)

ResendIGMP=

systemd.netdev(5)

ResolveUnicastSingleLabel=

resolved.conf(5)

RestartSec=

systemd.network(5)

RetransmitSec=

systemd.network(5)

RootDistanceMaxSec=

timesyncd.conf(5)

Route=

systemd.network(5)

RouteAllowList=

systemd.network(5)

RouteDenyList=

systemd.network(5)

RouteMTUBytes=

systemd.network(5)

RouteMetric=

systemd.netdev(5), systemd.network(5)

RouteShortCircuit=

systemd.netdev(5)

RouteTable=

networkd.conf(5), systemd.netdev(5), systemd.network(5)

Router=

systemd.network(5)

RouterAllowList=

systemd.network(5)

RouterDenyList=

systemd.network(5)

RouterLifetimeSec=

systemd.network(5)

RouterPreference=

systemd.network(5)

RoutesToDNS=

systemd.network(5)

RoutesToNTP=

systemd.network(5)

RoutingAlgorithm=

systemd.netdev(5)

RxBufferSize=

systemd.link(5)

RxChannels=

systemd.link(5)

RxCoalesceHighSec=

systemd.link(5)

RxCoalesceIrqSec=

systemd.link(5)

RxCoalesceLowSec=

systemd.link(5)

RxCoalesceSec=

systemd.link(5)

RxFlowControl=

systemd.link(5)

RxJumboBufferSize=

systemd.link(5)

RxMaxCoalescedFrames=

systemd.link(5)

RxMaxCoalescedHighFrames=

systemd.link(5)

RxMaxCoalescedIrqFrames=

systemd.link(5)

RxMaxCoalescedLowFrames=

systemd.link(5)

RxMiniBufferSize=

systemd.link(5)

SIP=

systemd.network(5)

SMTP=

systemd.network(5)

SR-IOVVirtualFunctions=

systemd.link(5)

SSID=

systemd.network(5)

STP=

systemd.netdev(5)

SamplePoint=

systemd.network(5)

SaveIntervalSec=

timesyncd.conf(5)

Scope=

systemd.network(5)

SendDecline=

systemd.network(5)

SendHostname=

systemd.network(5)

SendOption=

systemd.network(5)

SendRelease=

systemd.network(5)

SendVendorOption=

systemd.network(5)

SerializeTunneledPackets=

systemd.netdev(5)

ServerAddress=

systemd.network(5)

ServerPort=

systemd.network(5)

SessionId=

systemd.netdev(5)

SocketPriority=

systemd.network(5)

Source=

systemd.network(5)

SourceMACAddress=

systemd.netdev(5)

SourcePort=

systemd.network(5)

SpeedMeter=

networkd.conf(5)

SpeedMeterIntervalSec=

networkd.conf(5)

SplitGSO=

systemd.network(5)

StatisticsBlockCoalesceSec=

systemd.link(5)

StrictBands=

systemd.network(5)

SubType=

systemd.dnssd(5)

SubnetId=

systemd.network(5)

SuppressInterfaceGroup=

systemd.network(5)

SuppressPrefixLength=

systemd.network(5)

SyncJumpWidth=

systemd.network(5)

TCP6SegmentationOffload=

systemd.link(5)

TCPAdvertisedMaximumSegmentSize=

systemd.network(5)

TCPCongestionControlAlgorithm=

systemd.network(5)

TCPRetransmissionTimeoutSec=

systemd.network(5)

TCPSegmentationOffload=

systemd.link(5)

TOS=

systemd.netdev(5)

TTL=

systemd.netdev(5)

Table=

systemd.netdev(5), systemd.network(5)

TargetSec=

systemd.network(5)

Termination=

systemd.network(5)

TimeQuantaNSec=

systemd.network(5)

Timezone=

systemd.network(5)

To=

systemd.network(5)

Token=

systemd.network(5)

TransmitChecksumOffload=

systemd.link(5)

TransmitHashPolicy=

systemd.netdev(5)

TransmitQueueLength=

systemd.link(5)

TransmitQueues=

systemd.link(5)

TransmitVLANCTAGHardwareAcceleration=

systemd.link(5)

TransmitVLANSTAGHardwareAcceleration=

systemd.link(5)

TripleSampling=

systemd.network(5)

Trust=

systemd.link(5), systemd.network(5)

Tunnel=

systemd.network(5)

TunnelId=

systemd.netdev(5)

TxBufferSize=

systemd.link(5)

TxChannels=

systemd.link(5)

TxCoalesceHighSec=

systemd.link(5)

TxCoalesceIrqSec=

systemd.link(5)

TxCoalesceLowSec=

systemd.link(5)

TxCoalesceSec=

systemd.link(5)

TxFlowControl=

systemd.link(5)

TxMaxCoalescedFrames=

systemd.link(5)

TxMaxCoalescedHighFrames=

systemd.link(5)

TxMaxCoalescedIrqFrames=

systemd.link(5)

TxMaxCoalescedLowFrames=

systemd.link(5)

TxtData=

systemd.dnssd(5)

TxtText=

systemd.dnssd(5)

Type=

systemd.dnssd(5), systemd.link(5), systemd.netdev(5), systemd.network(5)

TypeOfService=

systemd.network(5)

UDP6ZeroChecksumRx=

systemd.netdev(5)

UDP6ZeroChecksumTx=

systemd.netdev(5)

UDPChecksum=

systemd.netdev(5)

UDPDestinationPort=

systemd.netdev(5)

UDPSourcePort=

systemd.netdev(5)

UnicastFlood=

systemd.network(5)

Unmanaged=

systemd.network(5)

UnsetProperty=

systemd.link(5)

UpDelaySec=

systemd.netdev(5)

UplinkInterface=

systemd.network(5)

Use6RD=

systemd.network(5)

UseAdaptiveRxCoalesce=

systemd.link(5)

UseAdaptiveTxCoalesce=

systemd.link(5)

UseAddress=

systemd.network(5)

UseAutonomousPrefix=

systemd.network(5)

UseBPDU=

systemd.network(5)

UseCaptivePortal=

systemd.network(5)

UseDNS=

systemd.network(5)

UseDelegatedPrefix=

systemd.network(5)

UseDomains=

networkd.conf(5), systemd.network(5)

UseForEncoding=

systemd.netdev(5)

UseGateway=

systemd.network(5)

UseHopLimit=

systemd.network(5)

UseHostname=

systemd.network(5)

UseMTU=

systemd.network(5)

UseNTP=

systemd.network(5)

UseOnLinkPrefix=

systemd.network(5)

UsePREF64=

systemd.network(5)

UseRawPacketSize=

systemd.network(5)

UseReachableTime=

systemd.network(5)

UseRedirect=

systemd.network(5)

UseRetransmissionTime=

systemd.network(5)

UseRoutePrefix=

systemd.network(5)

UseRoutes=

systemd.network(5)

UseSIP=

systemd.network(5)

UseTimezone=

systemd.network(5)

User=

systemd.netdev(5), systemd.network(5)

UserClass=

systemd.network(5)

VLAN=

systemd.network(5)

VLANFiltering=

systemd.netdev(5)

VLANId=

systemd.link(5), systemd.network(5)

VLANProtocol=

systemd.link(5), systemd.netdev(5), systemd.network(5)

VNI=

systemd.netdev(5), systemd.network(5)

VNetHeader=

systemd.netdev(5)

VRF=

systemd.network(5)

VXLAN=

systemd.network(5)

ValidLifetimeSec=

systemd.network(5)

VendorClass=

systemd.network(5)

VendorClassIdentifier=

systemd.network(5)

VirtualFunction=

systemd.link(5), systemd.network(5)

VirtualQueues=

systemd.network(5)

Virtualization=

systemd.link(5), systemd.netdev(5), systemd.network(5)

WDS=

systemd.netdev(5)

WLANInterfaceType=

systemd.network(5)

WakeOnLan=

systemd.link(5)

WakeOnLanPassword=

systemd.link(5)

Wash=

systemd.network(5)

Weight=

systemd.dnssd(5), systemd.network(5)

WithoutRA=

systemd.network(5)

Xfrm=

systemd.network(5)

JOURNAL FIELDS

Fields in the journal events with a well known meaning.

CODE_FILE=

systemd.journal-fields(7)

CODE_FUNC=

systemd.journal-fields(7)

CODE_LINE=

systemd.journal-fields(7)

COREDUMP=

systemd-coredump(8)

COREDUMP_CGROUP=

systemd-coredump(8)

COREDUMP_CMDLINE=

systemd-coredump(8)

COREDUMP_COMM=

systemd-coredump(8)

COREDUMP_CONTAINER_CMDLINE=

systemd-coredump(8)

COREDUMP_CWD=

systemd-coredump(8)

COREDUMP_ENVIRON=

systemd-coredump(8)

COREDUMP_EXE=

systemd-coredump(8)

COREDUMP_FILENAME=

systemd-coredump(8)

COREDUMP_GID=

systemd-coredump(8)

COREDUMP_HOSTNAME=

systemd-coredump(8)

COREDUMP_OPEN_FDS=

systemd-coredump(8)

COREDUMP_OWNER_UID=

systemd-coredump(8)

COREDUMP_PACKAGE_JSON=

systemd-coredump(8)

COREDUMP_PACKAGE_NAME=

systemd-coredump(8)

COREDUMP_PACKAGE_VERSION=

systemd-coredump(8)

COREDUMP_PID=

systemd-coredump(8)

COREDUMP_PROC_AUXV=

systemd-coredump(8)

COREDUMP_PROC_CGROUP=

systemd-coredump(8)

COREDUMP_PROC_LIMITS=

systemd-coredump(8)

COREDUMP_PROC_MAPS=

systemd-coredump(8)

COREDUMP_PROC_MOUNTINFO=

systemd-coredump(8)

COREDUMP_PROC_STATUS=

systemd-coredump(8)

COREDUMP_RLIMIT=

systemd-coredump(8)

COREDUMP_ROOT=

systemd-coredump(8)

COREDUMP_SESSION=

systemd-coredump(8)

COREDUMP_SIGNAL=

systemd-coredump(8)

COREDUMP_SIGNAL_NAME=

systemd-coredump(8)

COREDUMP_SLICE=

systemd-coredump(8)

COREDUMP_TIMESTAMP=

systemd-coredump(8)

COREDUMP_TRUNCATED=

systemd-coredump(8)

COREDUMP_UID=

systemd-coredump(8)

COREDUMP_UNIT=

systemd-coredump(8), systemd.journal-fields(7)

COREDUMP_USER_UNIT=

systemd-coredump(8), systemd.journal-fields(7)

DOCUMENTATION=

systemd.journal-fields(7)

ERRNO=

systemd.journal-fields(7)

INVOCATION_ID=

systemd.journal-fields(7)

MESSAGE=

systemd-coredump(8), systemd.journal-fields(7)

MESSAGE_ID=

systemd.journal-fields(7)

OBJECT_AUDIT_LOGINUID=

systemd.journal-fields(7)

OBJECT_AUDIT_SESSION=

systemd.journal-fields(7)

OBJECT_CMDLINE=

systemd.journal-fields(7)

OBJECT_COMM=

systemd.journal-fields(7)

OBJECT_EXE=

systemd.journal-fields(7)

OBJECT_GID=

systemd.journal-fields(7)

OBJECT_PID=

systemd.journal-fields(7)

OBJECT_SYSTEMD_CGROUP=

systemd.journal-fields(7)

OBJECT_SYSTEMD_INVOCATION_ID=

systemd.journal-fields(7)

OBJECT_SYSTEMD_OWNER_UID=

systemd.journal-fields(7)

OBJECT_SYSTEMD_SESSION=

systemd.journal-fields(7)

OBJECT_SYSTEMD_UNIT=

systemd.journal-fields(7)

OBJECT_SYSTEMD_USER_UNIT=

systemd.journal-fields(7)

OBJECT_UID=

systemd.journal-fields(7)

PRIORITY=

systemd.journal-fields(7)

SYSLOG_FACILITY=

systemd.journal-fields(7)

SYSLOG_IDENTIFIER=

systemd.journal-fields(7)

SYSLOG_PID=

systemd.journal-fields(7)

SYSLOG_RAW=

systemd.journal-fields(7)

SYSLOG_TIMESTAMP=

systemd.journal-fields(7)

TID=

systemd.journal-fields(7)

UNIT=

systemd.journal-fields(7)

USER_INVOCATION_ID=

systemd.journal-fields(7)

USER_UNIT=

systemd.journal-fields(7)

_AUDIT_LOGINUID=

systemd.journal-fields(7)

_AUDIT_SESSION=

systemd.journal-fields(7)

_BOOT_ID=

systemd.journal-fields(7)

_CAP_EFFECTIVE=

systemd.journal-fields(7)

_CMDLINE=

systemd.journal-fields(7)

_COMM=

systemd.journal-fields(7)

_EXE=

systemd.journal-fields(7)

_GID=

systemd.journal-fields(7)

_HOSTNAME=

systemd.journal-fields(7)

_KERNEL_DEVICE=

systemd.journal-fields(7)

_KERNEL_SUBSYSTEM=

systemd.journal-fields(7)

_LINE_BREAK=

systemd.journal-fields(7)

_MACHINE_ID=

systemd.journal-fields(7)

_NAMESPACE=

systemd.journal-fields(7)

_PID=

systemd.journal-fields(7)

_RUNTIME_SCOPE=

systemd.journal-fields(7)

_SELINUX_CONTEXT=

systemd.journal-fields(7)

_SOURCE_REALTIME_TIMESTAMP=

systemd.journal-fields(7)

_STREAM_ID=

systemd.journal-fields(7)

_SYSTEMD_CGROUP=

systemd.journal-fields(7)

_SYSTEMD_INVOCATION_ID=

systemd.journal-fields(7)

_SYSTEMD_OWNER_UID=

systemd.journal-fields(7)

_SYSTEMD_SESSION=

systemd.journal-fields(7)

_SYSTEMD_SLICE=

systemd.journal-fields(7)

_SYSTEMD_UNIT=

systemd.journal-fields(7)

_SYSTEMD_USER_SLICE=

systemd.journal-fields(7)

_SYSTEMD_USER_UNIT=

systemd.journal-fields(7)

_TRANSPORT=

systemd.journal-fields(7)

_UDEV_DEVLINK=

systemd.journal-fields(7)

_UDEV_DEVNODE=

systemd.journal-fields(7)

_UDEV_SYSNAME=

systemd.journal-fields(7)

_UID=

systemd.journal-fields(7)

__CURSOR=

systemd.journal-fields(7)

__MONOTONIC_TIMESTAMP=

systemd.journal-fields(7)

__REALTIME_TIMESTAMP=

systemd.journal-fields(7)

__SEQNUM=

systemd.journal-fields(7)

__SEQNUM_ID=

systemd.journal-fields(7)

PAM CONFIGURATION DIRECTIVES

Directives for configuring PAM behaviour.

class=

pam_systemd(8)

debug

pam_systemd(8), pam_systemd_home(8), pam_systemd_loadkey(8)

default-capability-ambient-set=

pam_systemd(8)

default-capability-bounding-set=

pam_systemd(8)

desktop=

pam_systemd(8)

keyname=

pam_systemd_loadkey(8)

suspend=

pam_systemd_home(8)

systemd.cpu_weight=

pam_systemd(8)

systemd.io_weight=

pam_systemd(8)

systemd.memory_max=

pam_systemd(8)

systemd.runtime_max_sec=

pam_systemd(8)

systemd.tasks_max=

pam_systemd(8)

type=

pam_systemd(8)

/ETC/CRYPTTAB, /ETC/VERITYTAB AND /ETC/FSTAB OPTIONS

Options which influence mounted filesystems and encrypted volumes.

_netdev

crypttab(5), systemd.mount(5), veritytab(5)

auto

systemd.mount(5), systemd.swap(5)

bitlk

crypttab(5)

check-at-most-once

veritytab(5)

cipher=

crypttab(5)

data-block-size=

veritytab(5)

data-blocks=

veritytab(5)

discard

crypttab(5)

fec-device=

veritytab(5)

fec-offset=

veritytab(5)

fec-roots=

veritytab(5)

fido2-cid=

crypttab(5)

fido2-device=

crypttab(5)

fido2-rp=

crypttab(5)

format=

veritytab(5)

hash-block-size=

veritytab(5)

hash-offset=

veritytab(5)

hash=

crypttab(5), veritytab(5)

header=

crypttab(5)

headless=

crypttab(5)

ignore-corruption

veritytab(5)

ignore-zero-blocks

veritytab(5)

key-slot=

crypttab(5)

keyfile-erase

crypttab(5)

keyfile-offset=

crypttab(5)

keyfile-size=

crypttab(5)

keyfile-timeout=

crypttab(5)

link-volume-key=

crypttab(5)

luks

crypttab(5)

no-read-workqueue

crypttab(5)

no-write-workqueue

crypttab(5)

noauto

crypttab(5), systemd.mount(5), systemd.swap(5), veritytab(5)

nofail

crypttab(5), systemd.mount(5), systemd.swap(5), veritytab(5)

offset=

crypttab(5)

panic-on-corruption

veritytab(5)

password-echo=

crypttab(5)

pkcs11-uri=

crypttab(5)

plain

crypttab(5)

read-only

crypttab(5)

readonly

crypttab(5)

restart-on-corruption

veritytab(5)

root-hash-signature=

veritytab(5)

salt=

veritytab(5)

same-cpu-crypt

crypttab(5)

sector-size=

crypttab(5)

size=

crypttab(5)

skip=

crypttab(5)

submit-from-crypt-cpus

crypttab(5)

superblock=

veritytab(5)

swap

crypttab(5)

tcrypt

crypttab(5)

tcrypt-hidden

crypttab(5)

tcrypt-keyfile=

crypttab(5)

tcrypt-system

crypttab(5)

tcrypt-veracrypt

crypttab(5)

timeout=

crypttab(5)

tmp=

crypttab(5)

token-timeout=

crypttab(5)

tpm2-device=

crypttab(5)

tpm2-measure-bank=

crypttab(5)

tpm2-measure-pcr=

crypttab(5)

tpm2-pcrlock=

crypttab(5)

tpm2-pcrs=

crypttab(5)

tpm2-pin=

crypttab(5)

tpm2-signature=

crypttab(5)

tries=

crypttab(5)

try-empty-password=

crypttab(5)

uuid=

veritytab(5)

veracrypt-pim=

crypttab(5)

verify

crypttab(5)

x-initrd.attach

crypttab(5), veritytab(5)

x-initrd.mount

systemd.mount(5)

x-systemd.after=

systemd.mount(5)

x-systemd.automount

systemd.mount(5)

x-systemd.before=

systemd.mount(5)

x-systemd.device-bound=

systemd.mount(5)

x-systemd.device-timeout=

crypttab(5), systemd.mount(5), systemd.swap(5)

x-systemd.growfs

systemd.mount(5)

x-systemd.idle-timeout=

systemd.mount(5)

x-systemd.makefs

systemd.mount(5), systemd.swap(5)

x-systemd.mount-timeout=

systemd.mount(5)

x-systemd.pcrfs

systemd.mount(5)

x-systemd.required-by=

systemd.mount(5)

x-systemd.requires-mounts-for=

systemd.mount(5)

x-systemd.requires=

systemd.mount(5)

x-systemd.rw-only

systemd.mount(5)

x-systemd.wanted-by=

systemd.mount(5)

x-systemd.wants-mounts-for=

systemd.mount(5)

SYSTEMD.NSPAWN(5) DIRECTIVES

Directives for configuring systemd-nspawn containers.

AmbientCapability=

systemd.nspawn(5)

Bind=

systemd.nspawn(5)

BindReadOnly=

systemd.nspawn(5)

BindUser=

systemd.nspawn(5)

Boot=

systemd.nspawn(5)

Bridge=

systemd.nspawn(5)

CPUAffinity=

systemd.nspawn(5)

Capability=

systemd.nspawn(5)

DropCapability=

systemd.nspawn(5)

Environment=

systemd.nspawn(5)

Ephemeral=

systemd.nspawn(5)

Hostname=

systemd.nspawn(5)

IPVLAN=

systemd.nspawn(5)

Inaccessible=

systemd.nspawn(5)

Interface=

systemd.nspawn(5)

KillSignal=

systemd.nspawn(5)

LimitAS=

systemd.nspawn(5)

LimitCORE=

systemd.nspawn(5)

LimitCPU=

systemd.nspawn(5)

LimitDATA=

systemd.nspawn(5)

LimitFSIZE=

systemd.nspawn(5)

LimitLOCKS=

systemd.nspawn(5)

LimitMEMLOCK=

systemd.nspawn(5)

LimitMSGQUEUE=

systemd.nspawn(5)

LimitNICE=

systemd.nspawn(5)

LimitNOFILE=

systemd.nspawn(5)

LimitNPROC=

systemd.nspawn(5)

LimitRSS=

systemd.nspawn(5)

LimitRTPRIO=

systemd.nspawn(5)

LimitRTTIME=

systemd.nspawn(5)

LimitSIGPENDING=

systemd.nspawn(5)

LimitSTACK=

systemd.nspawn(5)

LinkJournal=

systemd.nspawn(5)

MACVLAN=

systemd.nspawn(5)

MachineID=

systemd.nspawn(5)

NoNewPrivileges=

systemd.nspawn(5)

NotifyReady=

systemd.nspawn(5)

OOMScoreAdjust=

systemd.nspawn(5)

Overlay=

systemd.nspawn(5)

OverlayReadOnly=

systemd.nspawn(5)

Parameters=

systemd.nspawn(5)

Personality=

systemd.nspawn(5)

PivotRoot=

systemd.nspawn(5)

Port=

systemd.nspawn(5)

Private=

systemd.nspawn(5)

PrivateUsers=

systemd.nspawn(5)

PrivateUsersOwnership=

systemd.nspawn(5)

ProcessTwo=

systemd.nspawn(5)

ReadOnly=

systemd.nspawn(5)

ResolvConf=

systemd.nspawn(5)

SuppressSync=

systemd.nspawn(5)

SystemCallFilter=

systemd.nspawn(5)

TemporaryFileSystem=

systemd.nspawn(5)

Timezone=

systemd.nspawn(5)

User=

systemd.nspawn(5)

VirtualEthernet=

systemd.nspawn(5)

VirtualEthernetExtra=

systemd.nspawn(5)

Volatile=

systemd.nspawn(5)

WorkingDirectory=

systemd.nspawn(5)

Zone=

systemd.nspawn(5)

PROGRAM CONFIGURATION OPTIONS

Directives for configuring the behaviour of the systemd process and other tools through configuration files.

AllowHibernation=

systemd-sleep.conf(5)

AllowHybridSleep=

systemd-sleep.conf(5)

AllowSuspend=

systemd-sleep.conf(5)

AllowSuspendThenHibernate=

systemd-sleep.conf(5)

Audit=

journald.conf(5)

CPUAffinity=

systemd-system.conf(5)

CapabilityBoundingSet=

systemd-system.conf(5)

Compress=

coredump.conf(5), journald.conf(5)

CrashAction=

systemd-system.conf(5)

CrashChangeVT=

systemd-system.conf(5)

CrashShell=

systemd-system.conf(5)

CtrlAltDelBurstAction=

systemd-system.conf(5)

DefaultCPUAccounting=

systemd-system.conf(5)

DefaultDeviceTimeoutSec=

systemd-system.conf(5)

DefaultEnvironment=

systemd-system.conf(5)

DefaultIOAccounting=

systemd-system.conf(5)

DefaultIPAccounting=

systemd-system.conf(5)

DefaultLimitAS=

systemd-system.conf(5)

DefaultLimitCORE=

systemd-system.conf(5)

DefaultLimitCPU=

systemd-system.conf(5)

DefaultLimitDATA=

systemd-system.conf(5)

DefaultLimitFSIZE=

systemd-system.conf(5)

DefaultLimitLOCKS=

systemd-system.conf(5)

DefaultLimitMEMLOCK=

systemd-system.conf(5)

DefaultLimitMSGQUEUE=

systemd-system.conf(5)

DefaultLimitNICE=

systemd-system.conf(5)

DefaultLimitNOFILE=

systemd-system.conf(5)

DefaultLimitNPROC=

systemd-system.conf(5)

DefaultLimitRSS=

systemd-system.conf(5)

DefaultLimitRTPRIO=

systemd-system.conf(5)

DefaultLimitRTTIME=

systemd-system.conf(5)

DefaultLimitSIGPENDING=

systemd-system.conf(5)

DefaultLimitSTACK=

systemd-system.conf(5)

DefaultMemoryAccounting=

systemd-system.conf(5)

DefaultMemoryPressureDurationSec=

oomd.conf(5)

DefaultMemoryPressureLimit=

oomd.conf(5)

DefaultMemoryPressureThresholdSec=

systemd-system.conf(5)

DefaultMemoryPressureWatch=

systemd-system.conf(5)

DefaultOOMPolicy=

systemd-system.conf(5)

DefaultOOMScoreAdjust=

systemd-system.conf(5)

DefaultRestartSec=

systemd-system.conf(5)

DefaultSmackProcessLabel=

systemd-system.conf(5)

DefaultStandardError=

systemd-system.conf(5)

DefaultStandardOutput=

systemd-system.conf(5)

DefaultStartLimitBurst=

systemd-system.conf(5)

DefaultStartLimitIntervalSec=

systemd-system.conf(5)

DefaultTasksAccounting=

systemd-system.conf(5)

DefaultTasksMax=

systemd-system.conf(5)

DefaultTimeoutAbortSec=

systemd-system.conf(5)

DefaultTimeoutStartSec=

systemd-system.conf(5)

DefaultTimeoutStopSec=

systemd-system.conf(5)

DefaultTimerAccuracySec=

systemd-system.conf(5)

DumpCore=

systemd-system.conf(5)

ExternalSizeMax=

coredump.conf(5)

ForwardToConsole=

journald.conf(5)

ForwardToKMsg=

journald.conf(5)

ForwardToSocket=

journald.conf(5)

ForwardToSyslog=

journald.conf(5)

ForwardToWall=

journald.conf(5)

HandleHibernateKey=

logind.conf(5)

HandleHibernateKeyLongPress=

logind.conf(5)

HandleLidSwitch=

logind.conf(5)

HandleLidSwitchDocked=

logind.conf(5)

HandleLidSwitchExternalPower=

logind.conf(5)

HandlePowerKey=

logind.conf(5)

HandlePowerKeyLongPress=

logind.conf(5)

HandleRebootKey=

logind.conf(5)

HandleRebootKeyLongPress=

logind.conf(5)

HandleSuspendKey=

logind.conf(5)

HandleSuspendKeyLongPress=

logind.conf(5)

HibernateDelaySec=

systemd-sleep.conf(5)

HibernateKeyIgnoreInhibited=

logind.conf(5)

HibernateMode=

systemd-sleep.conf(5)

HoldoffTimeoutSec=

logind.conf(5)

IdleAction=

logind.conf(5)

IdleActionSec=

logind.conf(5)

InhibitDelayMaxSec=

logind.conf(5)

InhibitorsMax=

logind.conf(5)

JournalSizeMax=

coredump.conf(5)

KExecWatchdogSec=

systemd-system.conf(5)

KeepFree=

coredump.conf(5), journal-remote.conf(5)

KillExcludeUsers=

logind.conf(5)

KillOnlyUsers=

logind.conf(5)

KillUserProcesses=

logind.conf(5)

LidSwitchIgnoreInhibited=

logind.conf(5)

LineMax=

journald.conf(5)

LogColor=

systemd-system.conf(5)

LogLevel=

systemd-system.conf(5)

LogLocation=

systemd-system.conf(5)

LogTarget=

systemd-system.conf(5)

LogTime=

systemd-system.conf(5)

ManagerEnvironment=

systemd-system.conf(5)

MaxFileSec=

journald.conf(5)

MaxFileSize=

journal-remote.conf(5)

MaxFiles=

journal-remote.conf(5)

MaxLevelConsole=

journald.conf(5)

MaxLevelKMsg=

journald.conf(5)

MaxLevelSocket=

journald.conf(5)

MaxLevelStore=

journald.conf(5)

MaxLevelSyslog=

journald.conf(5)

MaxLevelWall=

journald.conf(5)

MaxRetentionSec=

journald.conf(5)

MaxUse=

coredump.conf(5), journal-remote.conf(5)

MemorySleepMode=

systemd-sleep.conf(5)

NAutoVTs=

logind.conf(5)

NUMAMask=

systemd-system.conf(5)

NUMAPolicy=

systemd-system.conf(5)

NetworkTimeoutSec=

journal-upload.conf(5)

NoNewPrivileges=

systemd-system.conf(5)

PowerKeyIgnoreInhibited=

logind.conf(5)

ProcessSizeMax=

coredump.conf(5)

ProtectSystem=

systemd-system.conf(5)

RateLimitBurst=

journald.conf(5)

RateLimitIntervalSec=

journald.conf(5)

ReadKMsg=

journald.conf(5)

RebootKeyIgnoreInhibited=

logind.conf(5)

RebootWatchdogSec=

systemd-system.conf(5)

ReloadLimitBurst=

systemd-system.conf(5)

ReloadLimitIntervalSec=

systemd-system.conf(5)

RemoveIPC=

logind.conf(5)

ReserveVT=

logind.conf(5)

RuntimeDirectoryInodesMax=

logind.conf(5)

RuntimeDirectorySize=

logind.conf(5)

RuntimeKeepFree=

journald.conf(5)

RuntimeMaxFileSize=

journald.conf(5)

RuntimeMaxFiles=

journald.conf(5)

RuntimeMaxUse=

journald.conf(5)

RuntimeWatchdogPreGovernor=

systemd-system.conf(5)

RuntimeWatchdogPreSec=

systemd-system.conf(5)

RuntimeWatchdogSec=

systemd-system.conf(5)

Seal=

journal-remote.conf(5), journald.conf(5)

ServerCertificateFile=

journal-remote.conf(5), journal-upload.conf(5)

ServerKeyFile=

journal-remote.conf(5), journal-upload.conf(5)

SessionsMax=

logind.conf(5)

ShowStatus=

systemd-system.conf(5)

SleepOperation=

logind.conf(5)

SplitMode=

journal-remote.conf(5), journald.conf(5)

StatusUnitFormat=

systemd-system.conf(5)

StopIdleSessionSec=

logind.conf(5)

Storage=

coredump.conf(5), journald.conf(5), pstore.conf(5)

SuspendEstimationSec=

systemd-sleep.conf(5)

SuspendKeyIgnoreInhibited=

logind.conf(5)

SuspendState=

systemd-sleep.conf(5)

SwapUsedLimit=

oomd.conf(5)

SyncIntervalSec=

journald.conf(5)

SystemCallArchitectures=

systemd-system.conf(5)

SystemKeepFree=

journald.conf(5)

SystemMaxFileSize=

journald.conf(5)

SystemMaxFiles=

journald.conf(5)

SystemMaxUse=

journald.conf(5)

TTYPath=

journald.conf(5)

TargetSolution=

iocost.conf(5)

TimerSlackNSec=

systemd-system.conf(5)

TrustedCertificateFile=

journal-remote.conf(5), journal-upload.conf(5)

URL=

journal-upload.conf(5)

Unlink=

pstore.conf(5)

UserStopDelaySec=

logind.conf(5)

WatchdogDevice=

systemd-system.conf(5)

children_max=

udev.conf(5)

event_timeout=

udev.conf(5)

exec_delay=

udev.conf(5)

resolve_names=

udev.conf(5)

timeout_signal=

udev.conf(5)

udev_log=

udev.conf(5)

COMMAND LINE OPTIONS

Command-line options accepted by programs in the systemd suite.

–accept

systemd-socket-activate(1)

–accept-cached

systemd-ask-password(1)

–access-mode

homectl(1)

–acquired

busctl(1)

–action

udevadm(8)

–activatable

busctl(1)

–address

busctl(1)

–adjust-system-clock

timedatectl(1)

–after

systemctl(1)

–after-cursor

journalctl(1), systemd-journal-upload.service(8)

–all

coredumpctl(1), journalctl(1), loginctl(1), machinectl(1), networkctl(1), systemctl(1), systemd-cgls(1), systemd-storagetm.service(8), timedatectl(1), ukify(1)

–all-architectures

bootctl(1)

–allow-interactive-authorization

busctl(1)

–allow-null

systemd-creds(1)

–ambient-capability

systemd-nspawn(1)

–any

systemd-networkd-wait-online.service(8)

–app-specific

systemd-id128(1)

–append

systemd-measure(1)

–architecture

systemd-repart(8)

–are-updates-enabled

resolvectl(1)

–as-pid2

systemd-nspawn(1)

–attach

systemd-dissect(1)

–attr-match[=FILE[=VALUE]]

udevadm(8)

–attr-nomatch[=FILE[=VALUE]]

udevadm(8)

–attribute-walk

udevadm(8)

–augment-creds

busctl(1)

–auto-login

homectl(1)

–auto-resize-mode

homectl(1)

–auto-start

busctl(1)

–automount

systemd-mount(1)

–automount-property

systemd-mount(1)

–avatar

homectl(1)

–background

run0(1), systemd-nspawn(1), systemd-run(1)

–backing

udevadm(8)

–bank

systemd-measure(1), systemd-pcrphase.service(8)

–base-time

systemd-analyze(1)

–basename

systemd-vpick(1)

–batch

systemd-cgtop(1)

–before

systemctl(1)

–bind

systemd-nspawn(1)

–bind-device

systemd-mount(1)

–bind-ro

systemd-nspawn(1)

–bind-user

systemd-nspawn(1)

–blob

homectl(1)

**–boot[=[ID][±offset]|all]

journalctl(1), systemd-nspawn(1), systemd-tmpfiles(8)

–boot-loader-entry

systemctl(1)

–boot-loader-menu

systemctl(1)

–boot-path

bootctl(1), kernel-install(8)

–booted

systemd-notify(1)

–bus-path

systemd-stdio-bridge(1)

–cache

resolvectl(1)

–can-factory-reset

systemd-repart(8)

–capability

systemd-nspawn(1)

–capability-ambient-set

homectl(1)

–capability-bounding-set

homectl(1)

–capsule

busctl(1), systemctl(1), systemd-run(1)

–case-sensitive[=BOOLEAN]

journalctl(1)

–cat

portablectl(1)

–cat-config

systemd-binfmt.service(8), systemd-sysctl.service(8), systemd-sysusers(8), systemd-tmpfiles(8)

–catalog

journalctl(1)

–cert

systemd-journal-gatewayd.service(8), systemd-journal-remote.service(8), systemd-journal-upload.service(8)

–certificate

systemd-measure(1), systemd-repart(8)

–cgroup-id

systemd-cgls(1)

–chain

userdbctl(1)

–chdir

run0(1), systemd-nspawn(1)

–check-inhibitors

systemctl(1)

–children-max

systemd-udevd.service(8), udevadm(8)

–chroot

systemd-detect-virt(1)

–cifs-domain

homectl(1)

–cifs-extra-mount-options

homectl(1)

–cifs-service

homectl(1)

–cifs-user-name

homectl(1)

–class

importctl(1), resolvectl(1)

–clean

portablectl(1), systemd-tmpfiles(8)

–cleanup-db

udevadm(8)

–cmdline

systemd-measure(1), ukify(1)

–cname

resolvectl(1)

–collect

systemd-mount(1), systemd-run(1), varlinkctl(1)

–commit

systemd-machine-id-setup(1)

–component

systemd-sysupdate(8)

–components

systemd-pcrlock(8)

–compress

systemd-journal-remote.service(8)

–config

ukify(1)

–confirm-spawn

systemd(1)

–connections-max

systemd-socket-proxyd(8)

–console

systemd-nspawn(1), systemd-tty-ask-password-agent(1)

–container

systemd-detect-virt(1)

–continuous

systemd-bsod.service(8)

–copy

portablectl(1), systemd-firstboot(1)

–copy-from

systemd-dissect(1), systemd-repart(8)

–copy-keymap

systemd-firstboot(1)

–copy-locale

systemd-firstboot(1)

–copy-root-password

systemd-firstboot(1)

–copy-root-shell

systemd-firstboot(1)

–copy-source

systemd-repart(8)

–copy-timezone

systemd-firstboot(1)

–copy-to

systemd-dissect(1)

–cpu

systemd-cgtop(1)

–cpu-affinity

systemd-nspawn(1)

–cpu-weight

homectl(1)

–crash-action

systemd(1)

–crash-shell

systemd(1)

–crash-vt

systemd(1)

–create

systemd-tmpfiles(8)

–credential

systemd-ask-password(1)

–current

systemd-measure(1)

–cursor

journalctl(1), systemd-journal-upload.service(8)

–cursor-file

journalctl(1)

–cvm

systemd-detect-virt(1)

–daemon

systemd-udevd.service(8)

–datagram

systemd-socket-activate(1)

–debug

systemd-udevd.service(8), udevadm(8)

–debugger

coredumpctl(1)

–debugger-arguments

coredumpctl(1)

–default-standard-error

systemd(1)

–default-standard-output

systemd(1)

–defer-partitions

systemd-repart(8)

–definitions

systemd-repart(8), systemd-sysupdate(8)

–delay

systemd-cgtop(1)

–delete-root-password

systemd-firstboot(1)

–depth

systemd-cgtop(1)

–description

run0(1), systemd-mount(1), systemd-run(1)

–destination

busctl(1)

–detach

systemd-dissect(1)

–device

udevadm(8)

–device-id-of-file

udevadm(8)

–devicetree

ukify(1)

–diff

systemd-delta(1)

–directory

coredumpctl(1), journalctl(1), systemd-journal-gatewayd.service(8), systemd-journal-upload.service(8), systemd-nspawn(1)

–disable-updates

resolvectl(1)

–discard

systemd-dissect(1), systemd-repart(8)

–discover

systemd-dissect(1), systemd-mount(1)

–disk-size

homectl(1)

–disk-usage

journalctl(1)

–dmesg

journalctl(1)

–drop-caches

homectl(1)

–drop-capability

systemd-nspawn(1)

–drop-in

networkctl(1), systemctl(1)

–dry-run

bootctl(1), systemctl(1), systemd-oomd.service(8), systemd-repart(8), systemd-sysusers(8), systemd-tmpfiles(8), udevadm(8)

–dtb

systemd-measure(1)

–dump-bus-properties

systemd(1)

–dump-catalog

journalctl(1)

–dump-configuration-items

systemd(1)

–dump-core

systemd(1)

–echo

systemd-ask-password(1)

–efi-boot-option-description

bootctl(1)

–email-address

homectl(1)

–emoji

systemd-ask-password(1)

–empty

systemd-repart(8)

–enable

portablectl(1)

–enable-updates

resolvectl(1)

–enforce-password-policy

homectl(1)

–entry-token

bootctl(1), kernel-install(8), systemd-pcrlock(8)

–ephemeral

systemd-nspawn(1)

–esp-path

bootctl(1), kernel-install(8)

–event-timeout

systemd-udevd.service(8)

–exclude-identifier

journalctl(1)

–exclude-partitions

systemd-repart(8)

–exclude-prefix

systemd-tmpfiles(8)

–exec

systemd-notify(1)

–exec-delay

systemd-udevd.service(8)

–exit

udevadm(8)

–exit-idle-time

systemd-socket-proxyd(8)

–exit-if-exists

udevadm(8)

–expand-environment

systemd-run(1)

–expect-reply

busctl(1)

–export

udevadm(8)

–export-db

udevadm(8)

–export-format

homectl(1)

–export-prefix

udevadm(8)

–extension

portablectl(1)

–facility

journalctl(1)

–factory-reset

systemd-repart(8)

–fail

systemctl(1)

–failed

systemctl(1)

–fd

systemd-notify(1)

–fdname

systemd-notify(1), systemd-socket-activate(1)

–fido2-credential-algorithm

homectl(1), systemd-cryptenroll(1)

–fido2-device

homectl(1), systemd-cryptenroll(1)

–fido2-with-client-pin

homectl(1), systemd-cryptenroll(1)

–fido2-with-user-presence

homectl(1), systemd-cryptenroll(1)

–fido2-with-user-verification

homectl(1), systemd-cryptenroll(1)

–field

coredumpctl(1), journalctl(1)

–fields

journalctl(1)

–file

coredumpctl(1), journalctl(1), systemd-journal-gatewayd.service(8), systemd-journal-upload.service(8)

–file-system

systemd-pcrphase.service(8)

–firmware-setup

systemctl(1)

–flush

journalctl(1)

–follow

journalctl(1), systemd-journal-upload.service(8)

–force

importctl(1), journalctl(1), machinectl(1), portablectl(1), poweroff(8), systemctl(1), systemd-firstboot(1), systemd-pcrlock(8), systemd-sysext(8)

–format

importctl(1)

–from-pattern

systemd-analyze(1)

–fs-type

homectl(1)

–fsck

systemd-dissect(1), systemd-mount(1)

–full

busctl(1), journalctl(1), loginctl(1), machinectl(1), networkctl(1), systemctl(1), systemd-cgls(1), systemd-mount(1)

–fuzz

systemd-analyze(1)

–generate-crypttab

systemd-repart(8)

–generate-fstab

systemd-repart(8)

–generators

systemd-analyze(1)

–getter

systemd-journal-remote.service(8)

–gid

systemd-run(1)

–global

systemctl(1), systemd-analyze(1)

–gnutls-log

systemd-journal-remote.service(8)

–graceful

bootctl(1), systemd-pcrphase.service(8), systemd-tmpfiles(8)

–grep

journalctl(1)

–group

run0(1)

–growfs

systemd-dissect(1)

–halt

poweroff(8), shutdown(8)

–header

journalctl(1)

–help

bootctl(1), busctl(1), coredumpctl(1), homectl(1), hostnamectl(1), importctl(1), journalctl(1), kernel-install(8), localectl(1), loginctl(1), machinectl(1), networkctl(1), oomctl(1), portablectl(1), poweroff(8), resolvectl(1), run0(1), runlevel(8), shutdown(8), systemctl(1), systemd(1), systemd-ac-power(1), systemd-analyze(1), systemd-ask-password(1), systemd-battery-check.service(8), systemd-binfmt.service(8), systemd-bless-boot.service(8), systemd-bsod.service(8), systemd-cat(1), systemd-cgls(1), systemd-cgtop(1), systemd-creds(1), systemd-cryptenroll(1), systemd-delta(1), systemd-detect-virt(1), systemd-dissect(1), systemd-escape(1), systemd-firstboot(1), systemd-hwdb(8), systemd-id128(1), systemd-inhibit(1), systemd-journal-gatewayd.service(8), systemd-journal-remote.service(8), systemd-journal-upload.service(8), systemd-machine-id-setup(1), systemd-measure(1), systemd-mount(1), systemd-networkd-wait-online.service(8), systemd-notify(1), systemd-nspawn(1), systemd-oomd.service(8), systemd-path(1), systemd-pcrlock(8), systemd-pcrphase.service(8), systemd-repart(8), systemd-run(1), systemd-socket-activate(1), systemd-socket-proxyd(8), systemd-stdio-bridge(1), systemd-storagetm.service(8), systemd-suspend.service(8), systemd-sysctl.service(8), systemd-sysext(8), systemd-sysupdate(8), systemd-sysusers(8), systemd-tmpfiles(8), systemd-tty-ask-password-agent(1), systemd-udevd.service(8), systemd-vpick(1), telinit(8), timedatectl(1), udevadm(8), ukify(1), userdbctl(1), varlinkctl(1)

–home-dir

homectl(1)

–host

busctl(1), homectl(1), hostnamectl(1), importctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), systemctl(1), systemd-analyze(1), systemd-mount(1), systemd-run(1), timedatectl(1)

–hostname

systemd-firstboot(1), systemd-nspawn(1)

–icon

systemd-ask-password(1)

–icon-name

homectl(1)

–id

systemd-ask-password(1)

–identifier

journalctl(1), systemd-cat(1)

–identity

homectl(1)

–ignore

systemd-networkd-wait-online.service(8)

–ignore-failure

systemd-run(1)

–image

bootctl(1), coredumpctl(1), journalctl(1), kernel-install(8), systemctl(1), systemd-analyze(1), systemd-firstboot(1), systemd-machine-id-setup(1), systemd-nspawn(1), systemd-repart(8), systemd-sysupdate(8), systemd-sysusers(8), systemd-tmpfiles(8)

–image-path

homectl(1)

–image-policy

bootctl(1), coredumpctl(1), journalctl(1), kernel-install(8), systemctl(1), systemd-analyze(1), systemd-dissect(1), systemd-machine-id-setup(1), systemd-nspawn(1), systemd-repart(8), systemd-sysext(8), systemd-sysupdate(8), systemd-sysusers(8), systemd-tmpfiles(8)

–in-memory

systemd-dissect(1)

–inaccessible

systemd-nspawn(1)

–include-partitions

systemd-repart(8)

–inetd

systemd-socket-activate(1)

–initialized

udevadm(8)

–initialized-match

udevadm(8)

–initialized-nomatch

udevadm(8)

–initrd

systemd-measure(1), ukify(1)

–inline

systemd-sysusers(8)

–install-source

bootctl(1)

–instance

systemd-escape(1)

–instances-max

systemd-sysupdate(8)

–interface

resolvectl(1), systemd-networkd-wait-online.service(8)

–interval

journalctl(1)

–io-weight

homectl(1)

–ipv4

systemd-networkd-wait-online.service(8)

–ipv6

systemd-networkd-wait-online.service(8)

–iterations

systemd-analyze(1), systemd-cgtop(1)

–job-mode

systemctl(1)

–json

bootctl(1), busctl(1), coredumpctl(1), homectl(1), hostnamectl(1), importctl(1), kernel-install(8), loginctl(1), networkctl(1), resolvectl(1), systemd-analyze(1), systemd-creds(1), systemd-dissect(1), systemd-id128(1), systemd-measure(1), systemd-pcrlock(8), systemd-repart(8), systemd-sysext(8), systemd-sysupdate(8), udevadm(8), ukify(1), userdbctl(1), varlinkctl(1)

–keep-download

importctl(1)

–keep-unit

systemd-nspawn(1)

–kernel

udevadm(8)

–kernel-command-line

systemd-firstboot(1)

–key

systemd-journal-gatewayd.service(8), systemd-journal-remote.service(8), systemd-journal-upload.service(8)

–key-file

systemd-repart(8)

–keymap

systemd-firstboot(1)

–keyname

systemd-ask-password(1)

–kill-processes

homectl(1)

–kill-signal

systemd-nspawn(1)

–kill-value

systemctl(1)

–kill-whom

loginctl(1), machinectl(1), systemctl(1)

–language

homectl(1)

–legend

resolvectl(1), systemctl(1)

–level-prefix

systemd-cat(1)

–lines

journalctl(1), loginctl(1), machinectl(1), networkctl(1), systemctl(1)

–link-journal

systemd-nspawn(1)

–linux

systemd-measure(1), ukify(1)

–list

busctl(1), systemd-detect-virt(1), systemd-dissect(1), systemd-inhibit(1), systemd-mount(1), systemd-tty-ask-password-agent(1)

–list-boots

journalctl(1)

–list-catalog

journalctl(1)

–list-cvm

systemd-detect-virt(1)

–listen

systemd-socket-activate(1)

–listen-http

systemd-journal-remote.service(8)

–listen-https

systemd-journal-remote.service(8)

–listen-raw

systemd-journal-remote.service(8)

–load-credential

systemd-nspawn(1)

–load-credentials

udevadm(8)

–locale

systemd-firstboot(1)

–locale-messages

systemd-firstboot(1)

–location

homectl(1), systemd-pcrlock(8)

–locked

homectl(1)

–log-color

systemd(1)

–log-level

systemd(1), udevadm(8)

–log-location

systemd(1)

–log-target

systemd(1)

–log-time

systemd(1)

–login-background

homectl(1)

–loop-ref

systemd-dissect(1)

–low

systemd-ac-power(1)

–luks-cipher

homectl(1)

–luks-cipher-mode

homectl(1)

–luks-discard

homectl(1)

–luks-extra-mount-options

homectl(1)

–luks-offline-discard

homectl(1)

–luks-pbkdf-force-iterations

homectl(1)

–luks-pbkdf-hash-algorithm

homectl(1)

–luks-pbkdf-memory-cost

homectl(1)

–luks-pbkdf-parallel-threads

homectl(1)

–luks-pbkdf-time-cost

homectl(1)

–luks-pbkdf-type

homectl(1)

–luks-sector-size

homectl(1)

–luks-volume-key-size

homectl(1)

–machine

busctl(1), homectl(1), hostnamectl(1), importctl(1), journalctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), run0(1), systemctl(1), systemd-analyze(1), systemd-cgls(1), systemd-cgtop(1), systemd-mount(1), systemd-nspawn(1), systemd-run(1), systemd-stdio-bridge(1), timedatectl(1)

–machine-id

systemd(1), systemd-firstboot(1), systemd-pcrphase.service(8)

–make-archive

systemd-dissect(1)

–make-ddi

systemd-repart(8)

–make-entry-directory

bootctl(1), kernel-install(8)

–man

systemd-analyze(1)

–mangle

systemd-escape(1)

–marked

systemctl(1)

–match

busctl(1)

–max-addresses

machinectl(1)

–measure

ukify(1)

–member-of

homectl(1)

–memory-high

homectl(1)

–memory-max

homectl(1)

–merge

journalctl(1), systemd-journal-gatewayd.service(8), systemd-journal-upload.service(8)

–message

systemctl(1)

–microcode

ukify(1)

–mkdir

machinectl(1), systemctl(1), systemd-dissect(1)

–mode

systemd-inhibit(1)

–monitor

timedatectl(1)

–more

varlinkctl(1)

–mount

systemd-dissect(1)

–mtree

systemd-dissect(1)

–mtree-hash

systemd-dissect(1)

–multiple

systemd-ask-password(1)

–multiplexer

userdbctl(1)

–mutable

systemd-sysext(8)

–name

systemd-creds(1), udevadm(8)

–name-match[=NAME]

udevadm(8)

–namespace

journalctl(1), systemd-cat(1), systemd-journal-upload.service(8)

–network

resolvectl(1)

–network-bridge

systemd-nspawn(1)

–network-interface

systemd-nspawn(1)

–network-ipvlan

systemd-nspawn(1)

–network-macvlan

systemd-nspawn(1)

–network-namespace-path

systemd-nspawn(1)

–network-veth

systemd-nspawn(1)

–network-veth-extra

systemd-nspawn(1)

–network-zone

systemd-nspawn(1)

–newline

systemd-creds(1)

–nice

homectl(1), run0(1), systemd-run(1)

–no-ask-password

homectl(1), hostnamectl(1), importctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), run0(1), systemctl(1), systemd-mount(1), systemd-run(1), timedatectl(1)

–no-block

portablectl(1), systemctl(1), systemd-mount(1), systemd-notify(1), systemd-run(1)

–no-convert

localectl(1)

–no-full

journalctl(1)

–no-hostname

journalctl(1)

–no-legend

busctl(1), coredumpctl(1), homectl(1), importctl(1), kernel-install(8), loginctl(1), machinectl(1), networkctl(1), portablectl(1), systemd-analyze(1), systemd-creds(1), systemd-dissect(1), systemd-id128(1), systemd-inhibit(1), systemd-mount(1), systemd-repart(8), systemd-sysext(8), systemd-sysupdate(8), userdbctl(1)

–no-measure

ukify(1)

–no-new-privileges

systemd-nspawn(1)

–no-output

systemd-ask-password(1)

–no-pager

bootctl(1), busctl(1), coredumpctl(1), homectl(1), importctl(1), journalctl(1), kernel-install(8), localectl(1), loginctl(1), machinectl(1), networkctl(1), oomctl(1), portablectl(1), resolvectl(1), systemctl(1), systemd-analyze(1), systemd-binfmt.service(8), systemd-cgls(1), systemd-creds(1), systemd-delta(1), systemd-dissect(1), systemd-id128(1), systemd-inhibit(1), systemd-measure(1), systemd-mount(1), systemd-nspawn(1), systemd-path(1), systemd-pcrlock(8), systemd-repart(8), systemd-sysctl.service(8), systemd-sysext(8), systemd-sysupdate(8), systemd-sysusers(8), systemd-tmpfiles(8), timedatectl(1), udevadm(8), userdbctl(1), varlinkctl(1)

–no-reload

networkctl(1), portablectl(1), systemctl(1), systemd-sysext(8)

–no-sign-kernel

ukify(1)

–no-style

udevadm(8)

–no-summary

udevadm(8)

–no-sync

poweroff(8)

–no-tail

journalctl(1)

–no-tty

systemd-ask-password(1)

–no-variables

bootctl(1)

–no-wall

poweroff(8), shutdown(8), systemctl(1), telinit(8)

–no-warn

systemctl(1)

–no-wtmp

poweroff(8)

–nodev

homectl(1)

–noexec

homectl(1), systemd-sysext(8)

–nosuid

homectl(1)

–not-after

homectl(1), systemd-creds(1)

–not-before

homectl(1)

–notify-ready

systemd-nspawn(1)

–now

machinectl(1), portablectl(1), systemctl(1)

–nqn

systemd-storagetm.service(8)

–nv-index

systemd-pcrlock(8)

–oci-bundle

systemd-nspawn(1)

–offline

homectl(1), systemd-analyze(1), systemd-repart(8)

–on-active

systemd-run(1)

–on-boot

systemd-run(1)

–on-calendar

systemd-run(1)

–on-clock-change

systemd-run(1)

–on-startup

systemd-run(1)

–on-timezone-change

systemd-run(1)

–on-unit-active

systemd-run(1)

–on-unit-inactive

systemd-run(1)

–oneway

varlinkctl(1)

–oom-score-adjust

systemd-nspawn(1)

–operational-state

systemd-networkd-wait-online.service(8)

–options

systemd-mount(1)

–order

systemd-analyze(1), systemd-cgtop(1)

–os-release

ukify(1)

–osrel

systemd-measure(1)

–output

coredumpctl(1), journalctl(1), loginctl(1), machinectl(1), systemctl(1), systemd-journal-remote.service(8), ukify(1), userdbctl(1)

–output-fields

journalctl(1)

–overlay

systemd-nspawn(1)

–overlay-ro

systemd-nspawn(1)

–owner

systemd-mount(1)

–pager-end

journalctl(1)

–parent-match[=NAME]

udevadm(8)

–password

systemd-cryptenroll(1)

–password-change-inactive

homectl(1)

–password-change-max

homectl(1)

–password-change-min

homectl(1)

–password-change-now

homectl(1)

–password-change-warn

homectl(1)

–password-hint

homectl(1)

–path

systemd-escape(1), udevadm(8)

–path-property

systemd-run(1)

–pcr

systemd-pcrlock(8), systemd-pcrphase.service(8)

–pcr-banks

ukify(1)

–pcr-private-key

ukify(1)

–pcr-public-key

ukify(1)

–pcrlock

systemd-pcrlock(8)

–pcrpkey

systemd-measure(1), ukify(1)

–personality

systemd-nspawn(1)

–phase

systemd-measure(1)

–phases

ukify(1)

–pid

systemd-notify(1)

–ping

udevadm(8)

–pipe

systemd-nspawn(1), systemd-run(1)

–pivot-root

systemd-nspawn(1)

–pkcs11-token-uri

homectl(1), systemd-cryptenroll(1)

–plain

systemctl(1)

–plymouth

systemd-tty-ask-password-agent(1)

–policy

systemd-pcrlock(8)

–port

systemd-nspawn(1)

–poweroff

poweroff(8), shutdown(8)

–prefix

systemd-sysctl.service(8), systemd-tmpfiles(8)

–preset-mode

systemctl(1)

–pretty

hostnamectl(1), systemd-creds(1), systemd-id128(1), systemd-repart(8)

–print

systemd-machine-id-setup(1), systemd-vpick(1), udevadm(8)

–print-boot-path

bootctl(1)

–print-esp-path

bootctl(1)

–print-root-device

bootctl(1)

–prioritized-subsystem

udevadm(8)

–priority

journalctl(1), systemd-cat(1)

–private-key

systemd-measure(1), systemd-repart(8)

–private-key-source

systemd-measure(1), systemd-repart(8)

–private-network

systemd-nspawn(1)

–private-users

systemd-detect-virt(1), systemd-nspawn(1)

–private-users-ownership

systemd-nspawn(1)

–profile

portablectl(1), systemd-analyze(1)

–prompt

systemd-firstboot(1)

–prompt-hostname

systemd-firstboot(1)

–prompt-keymap

systemd-firstboot(1)

–prompt-locale

systemd-firstboot(1)

–prompt-root-password

systemd-firstboot(1)

–prompt-root-shell

systemd-firstboot(1)

–prompt-timezone

systemd-firstboot(1)

–property

loginctl(1), machinectl(1), run0(1), systemctl(1), systemd-mount(1), systemd-nspawn(1), systemd-run(1), timedatectl(1), udevadm(8)

–property-match[=KEY=VALUE]

udevadm(8)

–protocol

resolvectl(1)

–pty

systemd-run(1)

–public-key

systemd-measure(1)

–purge

systemd-tmpfiles(8)

–query

systemd-tty-ask-password-agent(1), udevadm(8)

–quiet

bootctl(1), busctl(1), coredumpctl(1), importctl(1), journalctl(1), machinectl(1), portablectl(1), systemctl(1), systemd-analyze(1), systemd-creds(1), systemd-detect-virt(1), systemd-mount(1), systemd-networkd-wait-online.service(8), systemd-nspawn(1), systemd-run(1), udevadm(8)

–rate-limit-burst

homectl(1)

–rate-limit-interval

homectl(1)

–raw

resolvectl(1), systemd-cgtop(1)

–raw-description

systemd-pcrlock(8)

–read-only

importctl(1), machinectl(1), systemctl(1), systemd-dissect(1), systemd-nspawn(1)

–ready

systemd-notify(1)

–real-name

homectl(1)

–realm

homectl(1)

–rebalance-weight

homectl(1)

–reboot

poweroff(8), shutdown(8), systemd-sysupdate(8)

–reboot-argument

systemctl(1)

–recovery-key

homectl(1), systemd-cryptenroll(1)

–recovery-pin

systemd-pcrlock(8)

–recursive

systemctl(1), systemd-cgtop(1)

–recursive-errors

systemd-analyze(1)

–register

systemd-nspawn(1)

–relax-single-label

resolvectl(1)

–relinquish-var

journalctl(1)

–reload

udevadm(8)

–reloading

systemd-notify(1)

–remain-after-exit

systemd-run(1)

–remove

systemd-tmpfiles(8)

–removed

udevadm(8)

–replace

systemd-sysusers(8), systemd-tmpfiles(8)

–require

systemd-analyze(1)

–reset

systemd-firstboot(1)

–resolv-conf

systemd-nspawn(1)

–resolve

systemd-vpick(1)

–resolve-names

systemd-udevd.service(8), udevadm(8)

–reverse

coredumpctl(1), journalctl(1), systemctl(1)

–rlimit

homectl(1), systemd-nspawn(1)

–rmdir

systemd-dissect(1)

–root

bootctl(1), coredumpctl(1), journalctl(1), kernel-install(8), systemctl(1), systemd-analyze(1), systemd-firstboot(1), systemd-hwdb(8), systemd-machine-id-setup(1), systemd-repart(8), systemd-sysext(8), systemd-sysupdate(8), systemd-sysusers(8), systemd-tmpfiles(8), udevadm(8)

–root-hash

systemd-dissect(1), systemd-nspawn(1)

–root-hash-sig

systemd-dissect(1), systemd-nspawn(1)

–root-password

systemd-firstboot(1)

–root-password-file

systemd-firstboot(1)

–root-password-hashed

systemd-firstboot(1)

–root-shell

systemd-firstboot(1)

–rotate

journalctl(1)

–runner

machinectl(1)

–runtime

networkctl(1), portablectl(1), systemctl(1)

–same-dir

systemd-run(1)

–save-state

systemd-journal-upload.service(8)

–sbat

systemd-measure(1), ukify(1)

–scope

systemd-run(1)

–seal

systemd-journal-remote.service(8)

–search

resolvectl(1)

–section

ukify(1)

–sector-size

systemd-repart(8)

–secureboot-certificate

ukify(1)

–secureboot-certificate-dir

ukify(1)

–secureboot-certificate-name

ukify(1)

–secureboot-certificate-validity

ukify(1)

–secureboot-private-key

ukify(1)

–security-policy

systemd-analyze(1)

–seed

systemd-repart(8)

–selinux-apifs-context

systemd-nspawn(1)

–selinux-context

systemd-nspawn(1)

–send-sighup

systemd-run(1)

–seqpacket

systemd-socket-activate(1)

–service

userdbctl(1)

–service-address

resolvectl(1)

–service-txt

resolvectl(1)

–service-type

systemd-run(1)

–service-watchdogs

systemd(1)

–session-launcher

homectl(1)

–session-type

homectl(1)

–set-credential

systemd-nspawn(1)

–setenv

homectl(1), machinectl(1), run0(1), systemd-nspawn(1), systemd-run(1), systemd-socket-activate(1)

–settings

systemd-nspawn(1)

–settle

udevadm(8)

–setup-keys

journalctl(1)

–setup-machine-id

systemd-firstboot(1)

–shell

homectl(1), systemd-run(1)

–show

shutdown(8)

–show-cursor

journalctl(1)

–show-machine

busctl(1)

–show-status

systemd(1)

–show-transaction

systemctl(1)

–show-types

systemctl(1)

–sign-kernel

ukify(1)

–signal

loginctl(1), machinectl(1), systemctl(1)

–signing-engine

ukify(1)

–signtool

ukify(1)

–since

coredumpctl(1), journalctl(1)

–size

busctl(1), systemd-repart(8)

–skel

homectl(1)

–slice

run0(1), systemd-nspawn(1), systemd-run(1)

–slice-inherit

run0(1), systemd-run(1)

–smart-relinquish-var

journalctl(1)

–socket-property

systemd-run(1)

–splash

systemd-measure(1), ukify(1)

–split

systemd-repart(8)

–split-mode

systemd-journal-remote.service(8)

–ssh-authorized-keys

homectl(1)

–stale-data

resolvectl(1)

–start-exec-queue

udevadm(8)

–state

systemctl(1)

–static

hostnamectl(1)

–stats

networkctl(1)

–status

systemd-notify(1)

–stderr-priority

systemd-cat(1)

–stdin

systemctl(1)

–stop-delay

homectl(1)

–stop-exec-queue

udevadm(8)

–stopping

systemd-notify(1)

–storage

homectl(1)

–strict

systemd-hwdb(8), systemd-sysctl.service(8)

–subsystem-match[=SUBSYSTEM]

udevadm(8)

–subsystem-nomatch[=SUBSYSTEM]

udevadm(8)

–suffix

systemd-escape(1), systemd-path(1), systemd-vpick(1)

–summary

ukify(1)

–suppress-sync

systemd-nspawn(1)

–sync

journalctl(1), systemd-sysupdate(8)

–synthesize

resolvectl(1), userdbctl(1)

–sysname-match[=NAME]

udevadm(8)

–system

busctl(1), journalctl(1), systemctl(1), systemd(1), systemd-analyze(1), systemd-creds(1), systemd-journal-gatewayd.service(8), systemd-journal-upload.service(8), systemd-mount(1), systemd-run(1), systemd-stdio-bridge(1)

–system-call-filter

systemd-nspawn(1)

–table

systemd-analyze(1)

–tag-match[=TAG]

udevadm(8)

–tasks-max

homectl(1)

–template

systemd-escape(1), systemd-nspawn(1)

–test

systemd(1)

–threshold

systemd-analyze(1)

–timeout

busctl(1), systemd-ask-password(1), systemd-networkd-wait-online.service(8), udevadm(8)

–timeout-idle-sec

systemd-mount(1)

–timeout-signal

systemd-udevd.service(8)

–timer-property

systemd-run(1)

–timestamp

systemctl(1), systemd-creds(1)

–timezone

homectl(1), systemd-firstboot(1), systemd-nspawn(1)

–tldr

systemd-analyze(1), systemd-binfmt.service(8), systemd-sysctl.service(8), systemd-sysusers(8), systemd-tmpfiles(8)

–tmpfs

systemd-mount(1), systemd-nspawn(1)

–to-pattern

systemd-analyze(1)

–tools

ukify(1)

–tpm2-device

systemd-creds(1), systemd-cryptenroll(1), systemd-measure(1), systemd-pcrphase.service(8), systemd-repart(8)

–tpm2-device-key

systemd-cryptenroll(1), systemd-repart(8)

–tpm2-pcrlock

systemd-cryptenroll(1), systemd-repart(8)

–tpm2-pcrs

systemd-creds(1), systemd-cryptenroll(1), systemd-repart(8)

–tpm2-public-key

systemd-creds(1), systemd-cryptenroll(1), systemd-repart(8)

–tpm2-public-key-pcrs

systemd-creds(1), systemd-cryptenroll(1), systemd-repart(8)

–tpm2-seal-key-handle

systemd-cryptenroll(1), systemd-repart(8)

–tpm2-signature

systemd-creds(1), systemd-cryptenroll(1)

–tpm2-with-pin

systemd-cryptenroll(1)

–transcode

systemd-creds(1)

–transient

hostnamectl(1)

–tree

udevadm(8)

–truncate-newline

journalctl(1)

–trust

systemd-journal-gatewayd.service(8), systemd-journal-remote.service(8), systemd-journal-upload.service(8)

–trust-anchor

resolvectl(1)

–tty

systemd-bsod.service(8)

–type

resolvectl(1), systemctl(1), systemd-delta(1), systemd-mount(1), systemd-vpick(1), udevadm(8)

–ucode

systemd-measure(1)

–udev

udevadm(8)

–uid

homectl(1), machinectl(1), systemd-creds(1), systemd-notify(1), systemd-run(1)

–umask

homectl(1)

–umount

systemd-dissect(1), systemd-mount(1)

–uname

systemd-measure(1), ukify(1)

–unescape

systemd-escape(1)

–unique

busctl(1)

–unit

journalctl(1), run0(1), systemd(1), systemd-analyze(1), systemd-cgls(1), systemd-run(1)

–unlock-fido2-device

systemd-cryptenroll(1)

–unlock-key-file

systemd-cryptenroll(1)

–unlock-tpm2-device

systemd-cryptenroll(1)

–unregister

systemd-binfmt.service(8)

–until

coredumpctl(1), journalctl(1)

–update-catalog

journalctl(1)

–url

systemd-journal-remote.service(8), systemd-journal-upload.service(8)

–user

busctl(1), journalctl(1), run0(1), systemctl(1), systemd(1), systemd-analyze(1), systemd-creds(1), systemd-journal-gatewayd.service(8), systemd-journal-upload.service(8), systemd-mount(1), systemd-nspawn(1), systemd-run(1), systemd-stdio-bridge(1), systemd-tmpfiles(8)

–user-unit

journalctl(1), systemd-cgls(1)

–usr

systemd-hwdb(8)

–utc

journalctl(1)

–uuid

systemd-id128(1), systemd-nspawn(1), udevadm(8)

–vacuum-files

journalctl(1)

–vacuum-size

journalctl(1)

–vacuum-time

journalctl(1)

–validate

resolvectl(1), systemd-dissect(1)

–value

loginctl(1), machinectl(1), systemctl(1), systemd-id128(1), timedatectl(1), udevadm(8)

–verbose

busctl(1), kernel-install(8), systemd-ac-power(1), udevadm(8)

–verify

importctl(1), journalctl(1), systemd-sysupdate(8)

–verify-key

journalctl(1)

–verity-data

systemd-dissect(1), systemd-nspawn(1)

–version

bootctl(1), busctl(1), coredumpctl(1), homectl(1), hostnamectl(1), importctl(1), journalctl(1), kernel-install(8), localectl(1), loginctl(1), machinectl(1), networkctl(1), oomctl(1), portablectl(1), resolvectl(1), run0(1), systemctl(1), systemd(1), systemd-ac-power(1), systemd-analyze(1), systemd-battery-check.service(8), systemd-binfmt.service(8), systemd-bless-boot.service(8), systemd-bsod.service(8), systemd-cat(1), systemd-cgls(1), systemd-cgtop(1), systemd-creds(1), systemd-cryptenroll(1), systemd-delta(1), systemd-detect-virt(1), systemd-dissect(1), systemd-escape(1), systemd-firstboot(1), systemd-id128(1), systemd-inhibit(1), systemd-journal-gatewayd.service(8), systemd-journal-remote.service(8), systemd-journal-upload.service(8), systemd-machine-id-setup(1), systemd-measure(1), systemd-mount(1), systemd-networkd-wait-online.service(8), systemd-notify(1), systemd-nspawn(1), systemd-oomd.service(8), systemd-path(1), systemd-pcrlock(8), systemd-pcrphase.service(8), systemd-repart(8), systemd-run(1), systemd-socket-activate(1), systemd-socket-proxyd(8), systemd-stdio-bridge(1), systemd-storagetm.service(8), systemd-suspend.service(8), systemd-sysctl.service(8), systemd-sysext(8), systemd-sysupdate(8), systemd-sysusers(8), systemd-tmpfiles(8), systemd-tty-ask-password-agent(1), systemd-udevd.service(8), systemd-vpick(1), timedatectl(1), udevadm(8), ukify(1), userdbctl(1), varlinkctl(1)

–vm

systemd-detect-virt(1)

–volatile

systemd-nspawn(1)

–wait

systemctl(1), systemd-run(1)

–wait-daemon[

udevadm(8)

–wait-for-initialization[=SECONDS]

udevadm(8)

–wall

systemd-tty-ask-password-agent(1)

–watch

systemd-tty-ask-password-agent(1)

–watch-bind

busctl(1)

–welcome

systemd-firstboot(1)

–what

systemctl(1), systemd-inhibit(1)

–when

systemctl(1)

–who

systemd-inhibit(1)

–why

systemd-inhibit(1)

–wipe-slot

systemd-cryptenroll(1)

–with

systemd-dissect(1)

–with-dependencies

systemctl(1)

–with-dropin

userdbctl(1)

–with-key

systemd-creds(1)

–with-nss

userdbctl(1)

–with-varlink

userdbctl(1)

–working-directory

systemd-run(1)

–wtmp-only

poweroff(8)

–xattr

systemd-cgls(1)

–xml-interface

busctl(1)

–zone

resolvectl(1)

-1

coredumpctl(1), systemd-cgtop(1)

-4

resolvectl(1), systemd-networkd-wait-online.service(8)

-6

resolvectl(1), systemd-networkd-wait-online.service(8)

-A

coredumpctl(1), systemd-mount(1), systemd-vpick(1), udevadm(8)

-B

systemd-vpick(1)

-C

busctl(1), importctl(1), systemctl(1), systemd-repart(8), systemd-run(1), systemd-sysupdate(8)

-D

coredumpctl(1), journalctl(1), run0(1), systemd-journal-gatewayd.service(8), systemd-journal-upload.service(8), systemd-nspawn(1), systemd-udevd.service(8)

-E

homectl(1), machinectl(1), systemd-nspawn(1), systemd-run(1), systemd-socket-activate(1), systemd-tmpfiles(8), udevadm(8)

-EE

homectl(1)

-F

coredumpctl(1), journalctl(1)

-G

homectl(1), systemd-mount(1), systemd-run(1)

-H

busctl(1), homectl(1), hostnamectl(1), importctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), shutdown(8), systemctl(1), systemd-analyze(1), systemd-creds(1), systemd-mount(1), systemd-run(1), timedatectl(1)

-I

resolvectl(1)

-L

systemd-nspawn(1)

-M

busctl(1), homectl(1), hostnamectl(1), importctl(1), journalctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), systemctl(1), systemd-analyze(1), systemd-cgls(1), systemd-cgtop(1), systemd-dissect(1), systemd-mount(1), systemd-nspawn(1), systemd-run(1), systemd-stdio-bridge(1), timedatectl(1)

-N

importctl(1), journalctl(1), systemd-udevd.service(8), udevadm(8), userdbctl(1)

-P

homectl(1), importctl(1), machinectl(1), shutdown(8), systemctl(1), systemd-cgtop(1), systemd-id128(1), systemd-nspawn(1), systemd-repart(8), systemd-run(1), timedatectl(1), udevadm(8)

-R

bootctl(1), resolvectl(1), udevadm(8)

-S

coredumpctl(1), importctl(1), journalctl(1), systemd-nspawn(1), systemd-repart(8), systemd-run(1), systemd-vpick(1), udevadm(8)

-T

journalctl(1), systemctl(1), systemd-creds(1), systemd-mount(1)

-U

coredumpctl(1), journalctl(1), systemd-dissect(1), systemd-nspawn(1)

-V

machinectl(1), resolvectl(1), systemd-vpick(1)

-Z

systemd-nspawn(1)

-a

journalctl(1), loginctl(1), machinectl(1), networkctl(1), resolvectl(1), systemctl(1), systemd-dissect(1), systemd-id128(1), systemd-nspawn(1), systemd-socket-activate(1), systemd-storagetm.service(8), timedatectl(1), udevadm(8)

-b

homectl(1), journalctl(1), systemd-cgtop(1), systemd-nspawn(1), udevadm(8)

-c

homectl(1), journalctl(1), resolvectl(1), shutdown(8), systemd-bsod.service(8), systemd-cgls(1), systemd-cgtop(1), systemd-detect-virt(1), systemd-socket-proxyd(8), systemd-udevd.service(8), udevadm(8)

-dPATH

homectl(1), poweroff(8), resolvectl(1), systemd-cgtop(1), systemd-run(1), systemd-socket-activate(1), systemd-udevd.service(8), udevadm(8)

-e

journalctl(1), systemd-ask-password(1), systemd-udevd.service(8), udevadm(8)

-f

journalctl(1), poweroff(8), resolvectl(1), systemctl(1)

-g

journalctl(1), run0(1), udevadm(8)

-h

bootctl(1), busctl(1), coredumpctl(1), homectl(1), hostnamectl(1), importctl(1), journalctl(1), kernel-install(8), localectl(1), loginctl(1), machinectl(1), networkctl(1), oomctl(1), portablectl(1), resolvectl(1), run0(1), shutdown(8), systemctl(1), systemd(1), systemd-ac-power(1), systemd-analyze(1), systemd-ask-password(1), systemd-battery-check.service(8), systemd-binfmt.service(8), systemd-bless-boot.service(8), systemd-bsod.service(8), systemd-cat(1), systemd-cgls(1), systemd-cgtop(1), systemd-creds(1), systemd-cryptenroll(1), systemd-delta(1), systemd-detect-virt(1), systemd-dissect(1), systemd-escape(1), systemd-firstboot(1), systemd-hwdb(8), systemd-id128(1), systemd-inhibit(1), systemd-journal-gatewayd.service(8), systemd-journal-remote.service(8), systemd-journal-upload.service(8), systemd-machine-id-setup(1), systemd-measure(1), systemd-mount(1), systemd-networkd-wait-online.service(8), systemd-notify(1), systemd-nspawn(1), systemd-oomd.service(8), systemd-path(1), systemd-pcrlock(8), systemd-pcrphase.service(8), systemd-repart(8), systemd-run(1), systemd-socket-activate(1), systemd-socket-proxyd(8), systemd-stdio-bridge(1), systemd-storagetm.service(8), systemd-suspend.service(8), systemd-sysctl.service(8), systemd-sysext(8), systemd-sysupdate(8), systemd-sysusers(8), systemd-tmpfiles(8), systemd-tty-ask-password-agent(1), systemd-udevd.service(8), systemd-vpick(1), timedatectl(1), udevadm(8), ukify(1), userdbctl(1), varlinkctl(1)

-i

journalctl(1), resolvectl(1), systemctl(1), systemd-cgtop(1), systemd-networkd-wait-online.service(8), systemd-nspawn(1)

-j

busctl(1), homectl(1), hostnamectl(1), importctl(1), loginctl(1), resolvectl(1), systemd-id128(1), systemd-nspawn(1), varlinkctl(1)

-k

journalctl(1), shutdown(8), systemd-cgls(1), systemd-cgtop(1), udevadm(8)

-l

busctl(1), journalctl(1), loginctl(1), machinectl(1), networkctl(1), resolvectl(1), systemctl(1), systemd-cgls(1), systemd-dissect(1), systemd-mount(1), systemd-socket-activate(1), udevadm(8)

-m

importctl(1), journalctl(1), resolvectl(1), systemd-cgtop(1), systemd-dissect(1), systemd-escape(1), systemd-journal-gatewayd.service(8), systemd-journal-upload.service(8), systemd-sysupdate(8), udevadm(8)

-n

coredumpctl(1), journalctl(1), loginctl(1), machinectl(1), networkctl(1), poweroff(8), systemctl(1), systemd-ask-password(1), systemd-cgtop(1), systemd-nspawn(1), udevadm(8)

-o

coredumpctl(1), journalctl(1), loginctl(1), machinectl(1), systemctl(1), systemd-journal-remote.service(8), systemd-mount(1), systemd-networkd-wait-online.service(8)

-p

bootctl(1), journalctl(1), loginctl(1), machinectl(1), portablectl(1), poweroff(8), resolvectl(1), systemctl(1), systemd-cat(1), systemd-cgtop(1), systemd-creds(1), systemd-escape(1), systemd-id128(1), systemd-mount(1), systemd-nspawn(1), systemd-run(1), systemd-stdio-bridge(1), systemd-vpick(1), timedatectl(1), udevadm(8)

-q

bootctl(1), busctl(1), coredumpctl(1), importctl(1), journalctl(1), machinectl(1), portablectl(1), systemctl(1), systemd-analyze(1), systemd-creds(1), systemd-detect-virt(1), systemd-mount(1), systemd-networkd-wait-online.service(8), systemd-nspawn(1), systemd-run(1), udevadm(8)

-r

coredumpctl(1), journalctl(1), resolvectl(1), shutdown(8), systemctl(1), systemd-cgtop(1), systemd-detect-virt(1), systemd-dissect(1), systemd-hwdb(8), systemd-run(1), udevadm(8)

-s

loginctl(1), machinectl(1), networkctl(1), systemctl(1), systemd-hwdb(8), systemd-repart(8), systemd-udevd.service(8), udevadm(8), userdbctl(1)

-t

journalctl(1), resolvectl(1), systemctl(1), systemd-cat(1), systemd-cgtop(1), systemd-delta(1), systemd-mount(1), systemd-run(1), systemd-udevd.service(8), systemd-vpick(1), udevadm(8)

-u

journalctl(1), resolvectl(1), run0(1), systemd-cgls(1), systemd-dissect(1), systemd-escape(1), systemd-id128(1), systemd-journal-upload.service(8), systemd-mount(1), systemd-nspawn(1), systemd-run(1), udevadm(8)

-v

kernel-install(8), resolvectl(1), systemd-ac-power(1), systemd-detect-virt(1), udevadm(8)

-w

poweroff(8), udevadm(8)

-x

bootctl(1), journalctl(1), resolvectl(1), systemd-cgls(1), systemd-dissect(1), systemd-nspawn(1), udevadm(8)

-y

udevadm(8)

Bonding

systemd.network(5)

CAN

systemd.network(5)

IPv4

systemd.link(5), systemd.network(5)

IPv6

systemd.link(5), systemd.network(5)

K

homectl(1), importctl(1), journalctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), systemctl(1), systemd(1), systemd-analyze(1), systemd-inhibit(1), systemd-nspawn(1), systemd-tmpfiles(8), timedatectl(1), userdbctl(1)

Master

systemd.network(5)

Other

systemd.network(5)

X

homectl(1), importctl(1), journalctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), systemctl(1), systemd(1), systemd-analyze(1), systemd-inhibit(1), systemd-nspawn(1), systemd-tmpfiles(8), timedatectl(1), userdbctl(1)

allow-discards

integritytab(5)

arp

systemd.link(5)

attach

[email protected](8), [email protected](8)

audit

systemd.journal-fields(7)

aui

systemd.link(5)

auto

systemd-sysext(8), systemd.resource-control(5)

bad

systemd-bless-boot.service(8)

besteffort

systemd.network(5)

bnc

systemd.link(5)

broadcast

systemd.link(5)

cat

journalctl(1)

check-new

systemd-sysupdate(8)

cleanup

bootctl(1)

closed

systemd.resource-control(5)

colon-delimited

systemd.link(5), systemd.network(5)

components

systemd-sysupdate(8)

data-device=

integritytab(5)

database

systemd.link(5)

detach

[email protected](8), [email protected](8)

diffserv3

systemd.network(5)

diffserv4

systemd.network(5)

diffserv8

systemd.network(5)

dot-delimited

systemd.link(5), systemd.network(5)

driver

systemd.journal-fields(7)

dst-host

systemd.network(5)

dual-dst-host

systemd.network(5)

dual-src-host

systemd.network(5)

ephemeral

systemd-sysext(8)

ephemeral-import

systemd-sysext(8)

eui64

systemd.network(5)

export

journalctl(1)

fibre

systemd.link(5)

flows

systemd.network(5)

force

loader.conf(5)

good

systemd-bless-boot.service(8)

help

[email protected](8), [email protected](8)

hibernate

systemd-suspend.service(8)

hosts

systemd.network(5)

hybrid-sleep

systemd-suspend.service(8)

hyphen-delimited

systemd.link(5), systemd.network(5)

if-safe

loader.conf(5)

import

systemd-sysext(8)

indeterminate

systemd-bless-boot.service(8)

install

bootctl(1)

integrity-algorithm=

integritytab(5)

is-installed

bootctl(1)

journal

systemd.journal-fields(7)

journal-commit-time=

integritytab(5)

journal-watermark=

integritytab(5)

json

journalctl(1)

json-pretty

journalctl(1)

json-seq

journalctl(1)

json-sse

journalctl(1)

keep

systemd.link(5)

kernel

systemd.journal-fields(7), systemd.link(5)

kernel-identify

bootctl(1)

kernel-inspect

bootctl(1)

link-layer

networkd.conf(5)

link-layer-time[:TIME]

networkd.conf(5)

list

bootctl(1), systemd-sysext(8), systemd-sysupdate(8)

mac

systemd.link(5)

magic

systemd.link(5)

manual

loader.conf(5)

merge

systemd-sysext(8)

mii

systemd.link(5)

mode=

integritytab(5)

multicast

systemd.link(5)

no

systemd-sysext(8)

none

systemd.link(5), systemd.network(5)

nspawn

machinectl(1)

off

loader.conf(5)

onboard

systemd.link(5)

path

systemd.link(5)

pending

systemd-sysupdate(8)

persistent

systemd.link(5)

phy

systemd.link(5)

precedence

systemd.network(5)

prefixstable[:ADDRESS][,UUID]

systemd.network(5)

pretty

systemctl(1)

random

systemd.link(5)

random-seed

bootctl(1)

reboot

systemd-sysupdate(8)

reboot-to-firmware

bootctl(1)

refresh

systemd-sysext(8)

remove

bootctl(1)

secureon

systemd.link(5)

set-default

bootctl(1)

set-oneshot

bootctl(1)

set-timeout

bootctl(1)

set-timeout-oneshot

bootctl(1)

short

journalctl(1)

short-delta

journalctl(1)

short-full

journalctl(1)

short-iso

journalctl(1)

short-iso-precise

journalctl(1)

short-monotonic

journalctl(1)

short-precise

journalctl(1)

short-unix

journalctl(1)

slot

systemd.link(5)

src-host

systemd.network(5)

**static:**ADDRESS

systemd.network(5)

status

bootctl(1), systemd-bless-boot.service(8), systemd-sysext(8)

stdout

systemd.journal-fields(7)

strict

systemd.resource-control(5)

suspend

systemd-suspend.service(8)

suspend-then-hibernate

systemd-suspend.service(8)

syslog

systemd.journal-fields(7)

tp

systemd.link(5)

triple

systemd.network(5)

unicast

systemd.link(5)

unix

systemctl(1)

unlink

bootctl(1)

unmerge

systemd-sysext(8)

update

bootctl(1), systemd-sysupdate(8)

us

systemctl(1)

us+utc

systemctl(1)

utc

systemctl(1)

uuid

networkd.conf(5)

vacuum

systemd-sysupdate(8)

vendor

networkd.conf(5)

verbose

journalctl(1)

vmspawn

machinectl(1)

with-unit

journalctl(1)

yes

systemd-sysext(8)

μs

systemctl(1)

μs+utc

systemctl(1)

CONSTANTS

Various constants used and/or defined by systemd.

-1

sd_journal_get_fd(3), sd_login_monitor_new(3)

h

sd_bus_message_read_basic(3)

s

sd_bus_message_read_basic(3)

y

sd_bus_message_read_basic(3)

-

systemd.resource-control(5)

-0

journalctl(1)

-1

journalctl(1), sd_event_run(3), sd_event_wait(3), sd_journal_get_fd(3)

-E2BIG

sd_journal_get_data(3), sd_journal_query_unique(3)

-EADDRINUSE

sd_bus_request_name(3)

-EADDRNOTAVAIL

sd_journal_get_data(3), sd_journal_query_unique(3)

-EAGAIN

sd_hwdb_get(3)

-EALREADY

sd_bus_request_name(3)

-EBADF

sd_bus_set_fd(3), sd_event_add_inotify(3), sd_pid_get_owner_uid(3)

-EBADMSG

sd_bus_message_open_container(3), sd_bus_message_read(3), sd_bus_message_read_array(3), sd_bus_message_read_basic(3), sd_bus_message_read_strv(3), sd_bus_message_seal(3), sd_bus_message_skip(3), sd_event_add_memory_pressure(3), sd_journal_get_data(3), sd_journal_query_unique(3)

-EBUSY

sd_bus_message_open_container(3), sd_bus_message_read(3), sd_bus_process(3), sd_bus_track_new(3), sd_event_add_child(3), sd_event_add_memory_pressure(3), sd_event_add_signal(3), sd_event_run(3), sd_event_wait(3)

-ECHILD

sd_bus_add_node_enumerator(3), sd_bus_add_object(3), sd_bus_add_object_manager(3), sd_bus_attach_event(3), sd_bus_call(3), sd_bus_can_send(3), sd_bus_close(3), sd_bus_emit_signal(3), sd_bus_enqueue_for_read(3), sd_bus_get_fd(3), sd_bus_get_n_queued_read(3), sd_bus_get_name_creds(3), sd_bus_get_name_machine_id(3), sd_bus_is_open(3), sd_bus_list_names(3), sd_bus_negotiate_fds(3), sd_bus_process(3), sd_bus_query_sender_creds(3), sd_bus_request_name(3), sd_bus_send(3), sd_bus_set_address(3), sd_bus_set_close_on_exit(3), sd_bus_set_connected_signal(3), sd_bus_set_description(3), sd_bus_set_exit_on_disconnect(3), sd_bus_set_fd(3), sd_bus_set_sender(3), sd_bus_set_server(3), sd_bus_set_watch_bind(3), sd_bus_slot_set_floating(3), sd_bus_start(3), sd_bus_wait(3), sd_event_add_child(3), sd_event_add_defer(3), sd_event_add_inotify(3), sd_event_add_io(3), sd_event_add_memory_pressure(3), sd_event_add_signal(3), sd_event_add_time(3), sd_event_exit(3), sd_event_get_fd(3), sd_event_now(3), sd_event_run(3), sd_event_set_signal_exit(3), sd_event_set_watchdog(3), sd_event_source_get_pending(3), sd_event_source_set_description(3), sd_event_source_set_enabled(3), sd_event_source_set_floating(3), sd_event_source_set_prepare(3), sd_event_source_set_priority(3), sd_event_source_set_ratelimit(3), sd_event_wait(3), sd_journal_get_data(3), sd_journal_open(3), sd_journal_query_unique(3)

-ECONNRESET

sd_bus_call(3), sd_bus_process(3), sd_bus_send(3)

-EDOM

sd_event_add_child(3), sd_event_add_inotify(3), sd_event_add_io(3), sd_event_add_memory_pressure(3), sd_event_add_signal(3), sd_event_add_time(3), sd_event_source_get_pending(3), sd_event_source_set_exit_on_failure(3), sd_event_source_set_prepare(3), sd_event_source_set_ratelimit(3)

-EEXIST

sd_bus_add_object(3), sd_bus_message_set_destination(3), sd_bus_request_name(3)

-EHOSTDOWN

sd_event_add_memory_pressure(3)

-EINVAL

sd_bus_add_node_enumerator(3), sd_bus_add_object(3), sd_bus_add_object_manager(3), sd_bus_call(3), sd_bus_creds_get_pid(3), sd_bus_creds_new_from_pid(3), sd_bus_default(3), sd_bus_emit_signal(3), sd_bus_error(3), sd_bus_error_add_map(3), sd_bus_get_fd(3), sd_bus_get_name_creds(3), sd_bus_get_name_machine_id(3), sd_bus_interface_name_is_valid(3), sd_bus_list_names(3), sd_bus_message_append(3), sd_bus_message_append_array(3), sd_bus_message_append_basic(3), sd_bus_message_append_string_memfd(3), sd_bus_message_append_strv(3), sd_bus_message_at_end(3), sd_bus_message_copy(3), sd_bus_message_get_cookie(3), sd_bus_message_get_monotonic_usec(3), sd_bus_message_get_signature(3), sd_bus_message_get_type(3), sd_bus_message_new(3), sd_bus_message_new_method_call(3), sd_bus_message_new_method_error(3), sd_bus_message_new_signal(3), sd_bus_message_open_container(3), sd_bus_message_read(3), sd_bus_message_read_array(3), sd_bus_message_read_basic(3), sd_bus_message_read_strv(3), sd_bus_message_rewind(3), sd_bus_message_seal(3), sd_bus_message_sensitive(3), sd_bus_message_set_destination(3), sd_bus_message_set_expect_reply(3), sd_bus_message_skip(3), sd_bus_message_verify_type(3), sd_bus_negotiate_fds(3), sd_bus_process(3), sd_bus_query_sender_creds(3), sd_bus_reply_method_error(3), sd_bus_reply_method_return(3), sd_bus_request_name(3), sd_bus_send(3), sd_bus_set_address(3), sd_bus_set_description(3), sd_bus_set_exit_on_disconnect(3), sd_bus_set_fd(3), sd_bus_set_method_call_timeout(3), sd_bus_set_server(3), sd_bus_slot_set_description(3), sd_bus_slot_set_destroy_callback(3), sd_bus_slot_set_floating(3), sd_bus_start(3), sd_bus_track_add_name(3), sd_bus_track_new(3), sd_bus_wait(3), sd_device_get_syspath(3), sd_event_add_child(3), sd_event_add_defer(3), sd_event_add_inotify(3), sd_event_add_io(3), sd_event_add_memory_pressure(3), sd_event_add_signal(3), sd_event_add_time(3), sd_event_exit(3), sd_event_get_fd(3), sd_event_now(3), sd_event_run(3), sd_event_set_signal_exit(3), sd_event_set_watchdog(3), sd_event_source_get_pending(3), sd_event_source_set_description(3), sd_event_source_set_destroy_callback(3), sd_event_source_set_enabled(3), sd_event_source_set_exit_on_failure(3), sd_event_source_set_floating(3), sd_event_source_set_prepare(3), sd_event_source_set_priority(3), sd_event_source_set_ratelimit(3), sd_event_wait(3), sd_hwdb_get(3), sd_hwdb_new(3), sd_journal_get_data(3), sd_journal_query_unique(3), sd_login_monitor_new(3), sd_machine_get_class(3), sd_path_lookup(3), sd_pid_get_owner_uid(3), sd_seat_get_active(3), sd_session_is_active(3), sd_uid_get_state(3)

-EIO

sd_bus_error(3), sd_journal_get_data(3), sd_journal_query_unique(3)

-ELOOP

sd_bus_call(3)

-EMFILE

sd_event_new(3)

-ENOBUFS

sd_bus_send(3), sd_journal_get_data(3), sd_journal_query_unique(3)

-ENODATA

sd_bus_creds_get_pid(3), sd_bus_message_get_cookie(3), sd_bus_message_get_monotonic_usec(3), sd_bus_negotiate_fds(3), sd_bus_set_address(3), sd_bus_set_description(3), sd_event_exit(3), sd_pid_get_owner_uid(3), sd_seat_get_active(3), sd_session_is_active(3), sd_uid_get_state(3)

-ENOENT

sd_device_get_syspath(3), sd_hwdb_get(3), sd_hwdb_new(3), sd_id128_get_machine(3), sd_journal_get_data(3), sd_journal_query_unique(3)

-ENOEXEC

sd_event_source_set_ratelimit(3)

-ENOMEDIUM

sd_bus_default(3), sd_id128_get_machine(3)

-ENOMEM

sd_bus_add_node_enumerator(3), sd_bus_add_object(3), sd_bus_add_object_manager(3), sd_bus_call(3), sd_bus_creds_get_pid(3), sd_bus_creds_new_from_pid(3), sd_bus_default(3), sd_bus_emit_signal(3), sd_bus_error(3), sd_bus_error_add_map(3), sd_bus_get_name_creds(3), sd_bus_get_name_machine_id(3), sd_bus_list_names(3), sd_bus_message_append(3), sd_bus_message_append_array(3), sd_bus_message_append_basic(3), sd_bus_message_append_string_memfd(3), sd_bus_message_append_strv(3), sd_bus_message_copy(3), sd_bus_message_new(3), sd_bus_message_new_method_call(3), sd_bus_message_new_method_error(3), sd_bus_message_new_signal(3), sd_bus_message_open_container(3), sd_bus_message_skip(3), sd_bus_new(3), sd_bus_reply_method_error(3), sd_bus_reply_method_return(3), sd_bus_send(3), sd_bus_set_description(3), sd_bus_slot_set_description(3), sd_bus_track_add_name(3), sd_bus_track_new(3), sd_event_add_child(3), sd_event_add_defer(3), sd_event_add_inotify(3), sd_event_add_io(3), sd_event_add_memory_pressure(3), sd_event_add_signal(3), sd_event_add_time(3), sd_event_new(3), sd_event_source_get_pending(3), sd_event_source_set_description(3), sd_event_source_set_enabled(3), sd_event_source_set_prepare(3), sd_event_source_set_priority(3), sd_get_seats(3), sd_hwdb_new(3), sd_journal_get_data(3), sd_login_monitor_new(3), sd_machine_get_class(3), sd_path_lookup(3), sd_pid_get_owner_uid(3), sd_seat_get_active(3), sd_session_is_active(3), sd_uid_get_state(3)

-ENOMSG

sd_bus_message_seal(3)

-ENOPKG

sd_bus_add_node_enumerator(3), sd_bus_add_object(3), sd_bus_add_object_manager(3), sd_bus_can_send(3), sd_bus_emit_signal(3), sd_bus_get_fd(3), sd_bus_get_name_creds(3), sd_bus_get_name_machine_id(3), sd_bus_list_names(3), sd_bus_negotiate_fds(3), sd_bus_set_address(3), sd_bus_set_description(3), sd_bus_set_exit_on_disconnect(3), sd_bus_set_fd(3), sd_bus_set_method_call_timeout(3), sd_bus_set_server(3), sd_bus_start(3), sd_id128_get_machine(3)

-ENOSYS

sd_event_add_inotify(3), sd_id128_get_machine(3)

-ENOTCONN

sd_bus_call(3), sd_bus_can_send(3), sd_bus_get_fd(3), sd_bus_list_names(3), sd_bus_message_new(3), sd_bus_message_new_method_call(3), sd_bus_message_new_method_error(3), sd_bus_message_new_signal(3), sd_bus_process(3), sd_bus_query_sender_creds(3), sd_bus_reply_method_error(3), sd_bus_reply_method_return(3), sd_bus_request_name(3), sd_bus_send(3), sd_bus_set_server(3), sd_bus_wait(3)

-ENOTTY

sd_event_add_memory_pressure(3)

-ENXIO

sd_bus_creds_get_pid(3), sd_bus_message_append(3), sd_bus_message_append_array(3), sd_bus_message_append_basic(3), sd_bus_message_append_string_memfd(3), sd_bus_message_append_strv(3), sd_bus_message_copy(3), sd_bus_message_open_container(3), sd_bus_message_read(3), sd_bus_message_read_basic(3), sd_bus_message_read_strv(3), sd_bus_message_skip(3), sd_bus_set_description(3), sd_bus_slot_set_description(3), sd_event_new(3), sd_event_source_set_description(3), sd_id128_get_machine(3), sd_machine_get_class(3), sd_path_lookup(3), sd_seat_get_active(3), sd_session_is_active(3), sd_uid_get_state(3)

-EOPNOTSUPP

sd_bus_creds_new_from_pid(3), sd_bus_message_new_method_call(3), sd_bus_message_read_array(3), sd_bus_send(3), sd_event_add_child(3), sd_event_add_memory_pressure(3), sd_event_add_time(3), sd_event_now(3), sd_path_lookup(3)

-EOVERFLOW

sd_event_add_time(3)

-EPERM

sd_bus_get_fd(3), sd_bus_get_name_creds(3), sd_bus_message_append(3), sd_bus_message_append_array(3), sd_bus_message_append_basic(3), sd_bus_message_append_string_memfd(3), sd_bus_message_append_strv(3), sd_bus_message_at_end(3), sd_bus_message_copy(3), sd_bus_message_new_method_call(3), sd_bus_message_new_method_error(3), sd_bus_message_open_container(3), sd_bus_message_read_array(3), sd_bus_message_read_strv(3), sd_bus_message_rewind(3), sd_bus_message_set_destination(3), sd_bus_message_set_expect_reply(3), sd_bus_message_skip(3), sd_bus_message_verify_type(3), sd_bus_negotiate_fds(3), sd_bus_query_sender_creds(3), sd_bus_reply_method_error(3), sd_bus_reply_method_return(3), sd_bus_set_address(3), sd_bus_set_description(3), sd_bus_set_fd(3), sd_bus_set_sender(3), sd_bus_set_server(3), sd_bus_start(3), sd_event_add_io(3), sd_id128_get_machine(3)

-EPROTONOSUPPORT

sd_journal_get_data(3), sd_journal_query_unique(3)

-EPROTOTYPE

sd_bus_add_object(3)

-ESOCKTNOSUPPORT

sd_bus_default(3)

-ESRCH

sd_bus_creds_new_from_pid(3), sd_bus_emit_signal(3), sd_bus_request_name(3), sd_pid_get_owner_uid(3)

-ESTALE

sd_bus_message_append(3), sd_bus_message_append_array(3), sd_bus_message_append_basic(3), sd_bus_message_append_string_memfd(3), sd_bus_message_append_strv(3), sd_bus_message_copy(3), sd_bus_message_open_container(3), sd_bus_slot_set_floating(3), sd_event_add_child(3), sd_event_add_defer(3), sd_event_add_inotify(3), sd_event_add_io(3), sd_event_add_memory_pressure(3), sd_event_add_signal(3), sd_event_add_time(3), sd_event_exit(3), sd_event_run(3), sd_event_source_get_pending(3), sd_event_source_set_prepare(3), sd_event_source_set_priority(3), sd_event_wait(3), sd_journal_get_realtime_usec(3)

-ETIMEDOUT

sd_bus_call(3)

-EUCLEAN

sd_id128_get_machine(3)

-EUNATCH

sd_bus_track_add_name(3)

/org/freedesktop/systemd1

org.freedesktop.systemd1(5)

0

kernel-install(8), org.freedesktop.resolve1(5), sd_bus_add_object(3), sd_bus_error(3), sd_event_add_time(3), sd_journal_add_match(3), systemctl(1), systemd-analyze(1), systemd.net-naming-scheme(7), systemd.netdev(5), systemd.resource-control(5), tmpfiles.d(5), udev_device_get_syspath(3), udev_device_has_tag(3), udev_enumerate_add_match_subsystem(3), udev_enumerate_scan_devices(3), udev_monitor_filter_update(3), udev_monitor_receive_device(3), udevadm(8)

0657fd6d-a4ab-43c4-84e5-0933c84b4f4f

systemd-gpt-auto-generator(8)

0755

systemd.exec(5)

0x0000000000000002

systemd-gpt-auto-generator(8)

0x1000000000000000

systemd-gpt-auto-generator(8)

0x8000000000000000

systemd-gpt-auto-generator(8)

0xFF

sd-id128(3)

0xFFFF

sd_uid_get_state(3)

0xFFFFFFFF

sd_uid_get_state(3)

1

journalctl(1), sd_bus_add_object(3), systemctl(1), systemd-analyze(1), systemd-oomd.service(8), systemd-tmpfiles(8), systemd.net-naming-scheme(7), systemd.network(5), systemd.scope(5), systemd.service(5), udev_device_get_syspath(3)

10

systemd-journald.service(8)

11

systemd-analyze(1)

12

systemd-analyze(1)

128

systemd.resource-control(5)

19532

systemd-journal-upload.service(8)

2

journalctl(1), systemctl(1), systemd.network(5)

3

systemctl(1)

3b8f8425-20e0-4f3b-907f-1a25a76f98e8

systemd-gpt-auto-generator(8)

4

systemctl(1)

443

resolvectl(1)

4a67b082-0a4c-41cf-b6c7-440b29bb8c4f

systemd-bless-boot.service(8), systemd-gpt-auto-generator(8)

4d21b016-b534-45c2-a9fb-5c16e091fd2d

systemd-gpt-auto-generator(8)

4f68bce3-e8cd-4db1-96e7-fbcaf984b709

repart.d(5), systemd-gpt-auto-generator(8)

65

systemd-tmpfiles(8)

73

systemd-tmpfiles(8)

77

kernel-install(8)

7ec6f557-3bc5-4aca-b293-16ef5df639d1

systemd-gpt-auto-generator(8)

8cf2644b-4b0b-428f-9387-6d876050dc67

systemd-repart(8)

933ac7e1-2eb4-4f13-b844-0e14e2aef915

systemd-gpt-auto-generator(8)

:

systemd.resource-control(5)

A

tmpfiles.d(5)

ACTION

udev_device_new_from_syspath(3)

AF_INET

journald.conf(5), org.freedesktop.machine1(5), org.freedesktop.resolve1(5), sd_is_fifo(3), systemd-ssh-generator(8), systemd.exec(5), systemd.resource-control(5), systemd.socket(5)

AF_INET6

journald.conf(5), org.freedesktop.machine1(5), org.freedesktop.resolve1(5), sd_is_fifo(3), systemd-ssh-generator(8), systemd.exec(5), systemd.resource-control(5), systemd.socket(5)

AF_NETLINK

systemd.exec(5), systemd.socket(5)

AF_PACKET

systemd.exec(5), systemd.socket(5)

AF_UNIX

busctl(1), crypttab(5), daemon(7), journald.conf(5), machinectl(1), nss-resolve(8), pam_systemd(8), sd_is_fifo(3), sd_notify(3), sd_pid_get_owner_uid(3), systemctl(1), systemd(1), systemd-journal-gatewayd.service(8), systemd-journal-remote.service(8), systemd-repart(8), systemd-ssh-generator(8), systemd-ssh-proxy(1), systemd.exec(5), systemd.link(5), systemd.netdev(5), systemd.service(5), systemd.socket(5), varlinkctl(1)

AF_UNSPEC

org.freedesktop.resolve1(5), sd_is_fifo(3)

AF_VSOCK

journald.conf(5), org.freedesktop.hostname1(5), sd_notify(3), systemd(1), systemd-ssh-generator(8), systemd-ssh-proxy(1), systemd.socket(5), systemd.special(7), systemd.system-credentials(7)

ALLOW_INTERACTIVE_AUTHORIZATION

sd_bus_message_set_expect_reply(3), sd_bus_set_description(3)

AND

systemd.exec(5)

ANY

resolvectl(1)

B

tmpfiles.d(5)

BLKDISCARD

systemd-repart(8)

BUS_MESSAGE_NO_REPLY_EXPECTED

sd_bus_call(3)

C

tmpfiles.d(5)

CAP_AUDIT_CONTROL

systemd-nspawn(1)

CAP_AUDIT_WRITE

systemd-nspawn(1)

CAP_BLOCK_SUSPEND

homectl(1), pam_systemd(8)

CAP_CHOWN

systemd-nspawn(1)

CAP_DAC_OVERRIDE

systemd-nspawn(1), systemd.exec(5)

CAP_DAC_READ_SEARCH

systemd-nspawn(1)

CAP_FOWNER

systemd-nspawn(1), systemd-tmpfiles(8)

CAP_FSETID

systemd-nspawn(1)

CAP_IPC_OWNER

systemd-nspawn(1)

CAP_KILL

systemd-nspawn(1)

CAP_LEASE

systemd-nspawn(1)

CAP_LINUX_IMMUTABLE

systemd-nspawn(1)

CAP_MKNOD

systemd-nspawn(1), systemd.exec(5)

CAP_NET_ADMIN

systemd-nspawn(1)

CAP_NET_BIND_SERVICE

systemd-nspawn(1)

CAP_NET_BROADCAST

systemd-nspawn(1)

CAP_NET_RAW

systemd-nspawn(1)

CAP_SETFCAP

systemd-nspawn(1)

CAP_SETGID

systemd-nspawn(1)

CAP_SETPCAP

systemd-nspawn(1)

CAP_SETUID

systemd-nspawn(1)

CAP_SYSLOG

systemd.exec(5)

CAP_SYS_ADMIN

org.freedesktop.systemd1(5), sd_bus_add_object(3), systemd-nspawn(1), systemd.exec(5)

CAP_SYS_BOOT

systemd-nspawn(1)

CAP_SYS_CHROOT

systemd-nspawn(1)

CAP_SYS_MODULE

systemd.exec(5)

CAP_SYS_NICE

systemd-nspawn(1)

CAP_SYS_PTRACE

systemd-nspawn(1), systemd.exec(5)

CAP_SYS_RAWIO

systemd.exec(5)

CAP_SYS_RESOURCE

systemd-nspawn(1)

CAP_SYS_TIME

systemd.exec(5)

CAP_SYS_TTY_CONFIG

systemd-nspawn(1)

CAP_WAKE_ALARM

homectl(1), pam_systemd(8), systemd.exec(5)

CLOCK_BOOTTIME

sd-event(3), sd_event_add_time(3), sd_event_now(3), systemd.timer(5)

CLOCK_BOOTTIME_ALARM

sd-event(3), sd_event_add_time(3), sd_event_now(3)

CLOCK_MONOTONIC

org.freedesktop.login1(5), org.freedesktop.systemd1(5), sd-event(3), sd_bus_get_fd(3), sd_bus_message_get_monotonic_usec(3), sd_event_add_time(3), sd_event_now(3), sd_journal_get_cutoff_realtime_usec(3), sd_journal_get_fd(3), sd_journal_get_realtime_usec(3), sd_journal_seek_head(3), sd_login_monitor_new(3), sd_notify(3), systemd.journal-fields(7), systemd.service(5), systemd.timer(5)

CLOCK_REALTIME

org.freedesktop.login1(5), org.freedesktop.systemd1(5), org.freedesktop.timedate1(5), sd-event(3), sd_bus_message_get_monotonic_usec(3), sd_event_add_time(3), sd_event_now(3), sd_journal_get_cutoff_realtime_usec(3), sd_journal_get_realtime_usec(3), sd_journal_seek_head(3), sd_session_is_active(3), sd_uid_get_state(3), systemd.journal-fields(7), systemd.special(7), systemd.timer(5)

CLOCK_REALTIME_ALARM

sd-event(3), sd_event_add_time(3), sd_event_now(3)

CLONE_NEWNS

systemd.exec(5)

DEVPATH

udev_device_new_from_syspath(3)

DHCPDECLINE

systemd.network(5)

EACCES

systemd.exec(5)

EOPNOTSUPP

sd_event_add_child(3)

EPERM

systemd.exec(5)

EPIPE

systemd-journald.service(8)

EPOLLERR

sd_event_add_io(3), sd_notify(3)

EPOLLET

sd-event(3), sd_event_add_io(3)

EPOLLHUP

sd_event_add_io(3), sd_notify(3)

EPOLLIN

sd_event_add_io(3), sd_event_get_fd(3)

EPOLLOUT

sd_event_add_io(3)

EPOLLPRI

sd_event_add_io(3)

EPOLLRDHUP

sd_event_add_io(3)

ESC

systemctl(1)

EUCLEAN

sd-bus-errors(3), systemd.exec(5)

EXIT_ADDRESS_FAMILIES

systemd.exec(5)

EXIT_APPARMOR_PROFILE

systemd.exec(5)

EXIT_BPF

systemd.exec(5)

EXIT_CACHE_DIRECTORY

systemd.exec(5)

EXIT_CAPABILITIES

systemd.exec(5)

EXIT_CGROUP

systemd.exec(5)

EXIT_CHDIR

systemd.exec(5)

EXIT_CHOWN

systemd.exec(5)

EXIT_CHROOT

systemd.exec(5)

EXIT_CONFIGURATION_DIRECTORY

systemd.exec(5)

EXIT_CONFIRM

systemd.exec(5)

EXIT_CPUAFFINITY

systemd.exec(5)

EXIT_CREDENTIALS

systemd.exec(5)

EXIT_EXEC

systemd.exec(5)

EXIT_FAILURE

sd_bus_set_exit_on_disconnect(3), systemd-tmpfiles(8), systemd.exec(5)

EXIT_FDS

systemd.exec(5)

EXIT_GROUP

systemd.exec(5)

EXIT_INVALIDARGUMENT

systemd.exec(5)

EXIT_IOPRIO

systemd.exec(5)

EXIT_KEYRING

systemd.exec(5)

EXIT_LIMITS

systemd.exec(5)

EXIT_LOGS_DIRECTORY

systemd.exec(5)

EXIT_MEMORY

systemd.exec(5)

EXIT_NAMESPACE

systemd.exec(5)

EXIT_NETWORK

systemd.exec(5)

EXIT_NICE

systemd.exec(5)

EXIT_NOPERMISSION

systemd.exec(5)

EXIT_NOTCONFIGURED

systemd.exec(5)

EXIT_NOTIMPLEMENTED

systemd.exec(5)

EXIT_NOTINSTALLED

systemd.exec(5)

EXIT_NOTRUNNING

systemd.exec(5)

EXIT_NO_NEW_PRIVILEGES

systemd.exec(5)

EXIT_NUMA_POLICY

systemd.exec(5)

EXIT_OOM_ADJUST

systemd.exec(5)

EXIT_PAM

systemd.exec(5)

EXIT_PERSONALITY

systemd.exec(5)

EXIT_RUNTIME_DIRECTORY

systemd.exec(5)

EXIT_SECCOMP

systemd.exec(5)

EXIT_SECUREBITS

systemd.exec(5)

EXIT_SELINUX_CONTEXT

systemd.exec(5)

EXIT_SETSCHEDULER

systemd.exec(5)

EXIT_SETSID

systemd.exec(5)

EXIT_SIGNAL_MASK

systemd.exec(5)

EXIT_SMACK_PROCESS_LABEL

systemd.exec(5)

EXIT_STATE_DIRECTORY

systemd.exec(5)

EXIT_STDERR

systemd.exec(5)

EXIT_STDIN

systemd.exec(5)

EXIT_STDOUT

systemd.exec(5)

EXIT_SUCCESS

systemd.exec(5)

EXIT_TIMERSLACK

systemd.exec(5)

EXIT_USER

systemd.exec(5)

EX_CANTCREAT

systemd-tmpfiles(8), systemd.exec(5)

EX_CONFIG

systemd.exec(5)

EX_DATAERR

systemd-tmpfiles(8), systemd.exec(5)

EX_IOERR

systemd.exec(5)

EX_NOHOST

systemd.exec(5)

EX_NOINPUT

systemd.exec(5)

EX_NOPERM

systemd.exec(5)

EX_NOUSER

systemd.exec(5)

EX_OSERR

systemd.exec(5)

EX_OSFILE

systemd.exec(5)

EX_PROTOCOL

systemd.exec(5)

EX_SOFTWARE

systemd.exec(5)

EX_TEMPFAIL

systemd.exec(5)

EX_UNAVAILABLE

systemd.exec(5)

EX_USAGE

systemd.exec(5)

FD_CLOEXEC

sd_listen_fds(3)

IFF_UP

org.freedesktop.resolve1(5)

IN

resolvectl(1)

INIT_PROCESS

systemd.exec(5)

IN_ACCESS

sd_event_add_inotify(3)

IN_ATTRIB

sd_event_add_inotify(3)

IN_CLOSE_WRITE

sd_event_add_inotify(3)

IN_MASK_ADD

sd_event_add_inotify(3)

IN_ONESHOT

sd_event_add_inotify(3)

IPPROTO_SCTP

systemd.socket(5)

IPPROTO_UDPLITE

systemd.socket(5)

IPV6_FREEBIND

daemon(7), systemd.socket(5)

IPV6_RECVPKTINFO

systemd.socket(5)

IPV6_TRANSPARENT

systemd.socket(5)

IPV6_UNICAST_HOPS

systemd.socket(5)

IP_FREEBIND

daemon(7), systemd.socket(5)

IP_PKTINFO

systemd.socket(5)

IP_TOS

systemd.socket(5)

IP_TRANSPARENT

systemd.socket(5)

IP_TTL

systemd.socket(5)

LINE_MAX - 8

sd_journal_print(3)

LOCK_EX

systemd-pcrphase.service(8)

LOCK_SH

systemd-pcrphase.service(8)

LOGIN_PROCESS

systemd.exec(5)

LOG_ALERT

sd_journal_print(3), sd_journal_stream_fd(3)

LOG_CRIT

sd_journal_print(3), sd_journal_stream_fd(3)

LOG_DEBUG

sd_event_add_memory_pressure(3), sd_journal_print(3), sd_journal_stream_fd(3)

LOG_EMERG

sd_journal_print(3), sd_journal_stream_fd(3)

LOG_ERR

sd_journal_print(3), sd_journal_stream_fd(3)

LOG_INFO

sd_journal_print(3), sd_journal_stream_fd(3)

LOG_NOTICE

sd_journal_print(3), sd_journal_stream_fd(3)

LOG_WARNING

sd_journal_print(3), sd_journal_stream_fd(3)

M

tmpfiles.d(5)

MAP_ANON

systemd.exec(5)

MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1

systemd-coredump(8)

MSDOS_SUPER_MAGIC

file-hierarchy(7)

MS_NOSUID

systemd.exec(5)

MS_SLAVE

systemd.exec(5)

NETLINK_PKTINFO

systemd.socket(5)

NL

systemctl(1)

NO_ADDRESS

org.freedesktop.resolve1(5)

NO_AUTO_START

sd_bus_message_set_expect_reply(3)

NO_REPLY_EXPECTED

sd_bus_message_set_expect_reply(3)

NUL

crypttab(5), journald.conf(5), pam_systemd(8), sd-id128(3), sd_bus_creds_get_pid(3), sd_bus_message_append(3), sd_bus_message_append_basic(3), sd_bus_message_append_string_memfd(3), sd_bus_message_append_strv(3), sd_bus_message_read(3), sd_bus_message_read_array(3), sd_bus_path_encode(3), sd_event_source_set_description(3), sd_hwdb_get(3), sd_id128_to_string(3), sd_journal_add_match(3), sd_path_lookup(3), systemd-ask-password(1), systemd-journald.service(8), systemd-nspawn(1), systemd.exec(5), systemd.journal-fields(7), systemd.network(5), systemd.socket(5), systemd.unit(5), udev(7), udev_device_has_tag(3)

NULL

sd-login(3), sd_bus_add_match(3), sd_bus_add_node_enumerator(3), sd_bus_add_object(3), sd_bus_add_object_manager(3), sd_bus_attach_event(3), sd_bus_call(3), sd_bus_can_send(3), sd_bus_close(3), sd_bus_creds_get_pid(3), sd_bus_creds_new_from_pid(3), sd_bus_default(3), sd_bus_emit_signal(3), sd_bus_error(3), sd_bus_get_current_handler(3), sd_bus_interface_name_is_valid(3), sd_bus_is_open(3), sd_bus_list_names(3), sd_bus_message_append(3), sd_bus_message_append_array(3), sd_bus_message_append_basic(3), sd_bus_message_append_strv(3), sd_bus_message_at_end(3), sd_bus_message_copy(3), sd_bus_message_dump(3), sd_bus_message_get_signature(3), sd_bus_message_get_type(3), sd_bus_message_new(3), sd_bus_message_new_method_call(3), sd_bus_message_new_method_error(3), sd_bus_message_new_signal(3), sd_bus_message_open_container(3), sd_bus_message_read(3), sd_bus_message_read_array(3), sd_bus_message_read_basic(3), sd_bus_message_read_strv(3), sd_bus_message_rewind(3), sd_bus_message_seal(3), sd_bus_message_sensitive(3), sd_bus_message_set_destination(3), sd_bus_message_set_expect_reply(3), sd_bus_message_skip(3), sd_bus_message_verify_type(3), sd_bus_new(3), sd_bus_path_encode(3), sd_bus_process(3), sd_bus_query_sender_creds(3), sd_bus_reply_method_error(3), sd_bus_reply_method_return(3), sd_bus_request_name(3), sd_bus_send(3), sd_bus_set_address(3), sd_bus_set_description(3), sd_bus_set_exit_on_disconnect(3), sd_bus_set_method_call_timeout(3), sd_bus_set_property(3), sd_bus_set_sender(3), sd_bus_set_server(3), sd_bus_slot_get_bus(3), sd_bus_slot_ref(3), sd_bus_slot_set_description(3), sd_bus_slot_set_destroy_callback(3), sd_bus_slot_set_floating(3), sd_bus_slot_set_userdata(3), sd_bus_start(3), sd_bus_track_add_name(3), sd_bus_track_new(3), sd_device_ref(3), sd_event_add_child(3), sd_event_add_defer(3), sd_event_add_inotify(3), sd_event_add_io(3), sd_event_add_memory_pressure(3), sd_event_add_signal(3), sd_event_add_time(3), sd_event_exit(3), sd_event_new(3), sd_event_run(3), sd_event_source_get_event(3), sd_event_source_set_description(3), sd_event_source_set_destroy_callback(3), sd_event_source_set_enabled(3), sd_event_source_set_floating(3), sd_event_source_set_prepare(3), sd_event_source_set_userdata(3), sd_event_source_unref(3), sd_event_wait(3), sd_get_seats(3), sd_hwdb_get(3), sd_hwdb_new(3), sd_id128_to_string(3), sd_is_fifo(3), sd_journal_get_cutoff_realtime_usec(3), sd_journal_get_data(3), sd_journal_get_realtime_usec(3), sd_journal_get_seqnum(3), sd_journal_has_runtime_files(3), sd_journal_open(3), sd_journal_print(3), sd_journal_query_unique(3), sd_journal_stream_fd(3), sd_listen_fds(3), sd_login_monitor_new(3), sd_machine_get_class(3), sd_path_lookup(3), sd_pid_get_owner_uid(3), sd_seat_get_active(3), sd_session_is_active(3), sd_uid_get_state(3), sd_watchdog_enabled(3), udev_device_get_syspath(3), udev_device_has_tag(3), udev_device_new_from_syspath(3), udev_enumerate_new(3), udev_enumerate_scan_devices(3), udev_list_entry(3), udev_monitor_new_from_netlink(3), udev_monitor_receive_device(3), udev_new(3)

OP

systemd-analyze(1)

OR

systemd.exec(5)

O_DSYNC

systemd-nspawn(1)

O_NOCTTY

daemon(7)

O_NONBLOCK

sd_event_add_io(3), sd_journal_stream_fd(3), systemd.service(5)

O_PATH

sd_event_add_inotify(3)

O_RDONLY

org.freedesktop.systemd1(5)

O_RDWR

org.freedesktop.systemd1(5)

O_SYNC

systemd-nspawn(1)

P

systemd.net-naming-scheme(7)

PACKET_AUXDATA

systemd.socket(5)

PAM_SUCCESS

pam_systemd(8)

PID

sd_pid_get_owner_uid(3)

PIDFD

sd_pid_get_owner_uid(3)

POLLERR

systemd.service(5)

POLLHUP

systemd.service(5)

POLLIN

sd_bus_get_fd(3), sd_event_add_memory_pressure(3), sd_event_get_fd(3), sd_journal_get_fd(3), sd_login_monitor_new(3)

POLLOUT

sd_bus_get_fd(3), sd_journal_get_fd(3), sd_login_monitor_new(3)

POLLPRI

sd_event_add_memory_pressure(3)

PROT_EXEC

file-hierarchy(7), systemd.exec(5)

PROT_WRITE

systemd.exec(5)

PR_SET_NO_NEW_PRIVS

systemd-nspawn(1), systemd.nspawn(5)

READY=1

systemd(1)

RLIMIT_NICE

systemd-nspawn(1)

RLIMIT_NOFILE

daemon(7), systemd-nspawn(1)

RLIMIT_NPROC

systemd-nspawn(1)

SCHED_DEADLINE

systemd.exec(5)

SCHED_FIFO

systemd.exec(5)

SCHED_RR

systemd.exec(5)

SCM_CREDENTIALS

systemd-socket-proxyd(8)

SCM_RIGHTS

systemd-socket-proxyd(8)

SCM_SECURITY

systemd-socket-proxyd(8)

SD_BUS_ARGS(…)

sd_bus_add_object(3)

SD_BUS_ARGS()

sd_bus_add_object(3)

SD_BUS_CREDS_AUDIT_LOGIN_UID

sd_bus_creds_new_from_pid(3)

SD_BUS_CREDS_AUDIT_SESSION_ID

sd_bus_creds_new_from_pid(3)

SD_BUS_CREDS_AUGMENT

sd_bus_creds_new_from_pid(3)

SD_BUS_CREDS_BOUNDING_CAPS

sd_bus_creds_new_from_pid(3)

SD_BUS_CREDS_CGROUP

sd_bus_creds_new_from_pid(3)

SD_BUS_CREDS_CMDLINE

sd_bus_creds_new_from_pid(3)

SD_BUS_CREDS_COMM

sd_bus_creds_new_from_pid(3)

SD_BUS_CREDS_DESCRIPTION

sd_bus_creds_new_from_pid(3)

SD_BUS_CREDS_EFFECTIVE_CAPS

sd_bus_creds_new_from_pid(3)

SD_BUS_CREDS_EGID

sd_bus_creds_new_from_pid(3)

SD_BUS_CREDS_EUID

sd_bus_creds_new_from_pid(3)

SD_BUS_CREDS_EXE

sd_bus_creds_new_from_pid(3)

SD_BUS_CREDS_FSGID

sd_bus_creds_new_from_pid(3)

SD_BUS_CREDS_FSUID

sd_bus_creds_new_from_pid(3)

SD_BUS_CREDS_GID

sd_bus_creds_new_from_pid(3)

SD_BUS_CREDS_INHERITABLE_CAPS

sd_bus_creds_new_from_pid(3)

SD_BUS_CREDS_OWNER_UID

sd_bus_creds_new_from_pid(3)

SD_BUS_CREDS_PERMITTED_CAPS

sd_bus_creds_new_from_pid(3)

SD_BUS_CREDS_PID

sd_bus_creds_new_from_pid(3)

SD_BUS_CREDS_PIDFD

sd_bus_creds_new_from_pid(3)

SD_BUS_CREDS_PPID

sd_bus_creds_new_from_pid(3)

SD_BUS_CREDS_SELINUX_CONTEXT

sd_bus_creds_new_from_pid(3)

SD_BUS_CREDS_SESSION

sd_bus_creds_new_from_pid(3)

SD_BUS_CREDS_SGID

sd_bus_creds_new_from_pid(3)

SD_BUS_CREDS_SLICE

sd_bus_creds_new_from_pid(3)

SD_BUS_CREDS_SUID

sd_bus_creds_new_from_pid(3)

SD_BUS_CREDS_SUPPLEMENTARY_GIDS

sd_bus_creds_new_from_pid(3)

SD_BUS_CREDS_TID

sd_bus_creds_new_from_pid(3)

SD_BUS_CREDS_TID_COMM

sd_bus_creds_new_from_pid(3)

SD_BUS_CREDS_TTY

sd_bus_creds_new_from_pid(3)

SD_BUS_CREDS_UID

sd_bus_creds_new_from_pid(3)

SD_BUS_CREDS_UNIQUE_NAME

sd_bus_creds_new_from_pid(3), sd_bus_negotiate_fds(3)

SD_BUS_CREDS_UNIT

sd_bus_creds_new_from_pid(3)

SD_BUS_CREDS_USER_SLICE

sd_bus_creds_new_from_pid(3)

SD_BUS_CREDS_USER_UNIT

sd_bus_creds_new_from_pid(3)

SD_BUS_CREDS_WELL_KNOWN_NAMES

sd_bus_creds_new_from_pid(3), sd_bus_negotiate_fds(3)

SD_BUS_ERROR_ACCESS_DENIED

sd-bus-errors(3)

SD_BUS_ERROR_ADDRESS_IN_USE

sd-bus-errors(3)

SD_BUS_ERROR_AUTH_FAILED

sd-bus-errors(3)

SD_BUS_ERROR_BAD_ADDRESS

sd-bus-errors(3)

SD_BUS_ERROR_DISCONNECTED

sd-bus-errors(3)

SD_BUS_ERROR_FAILED

sd-bus-errors(3)

SD_BUS_ERROR_FILE_EXISTS

sd-bus-errors(3)

SD_BUS_ERROR_FILE_NOT_FOUND

sd-bus-errors(3)

SD_BUS_ERROR_INCONSISTENT_MESSAGE

sd-bus-errors(3)

SD_BUS_ERROR_INTERACTIVE_AUTHORIZATION_REQUIRED

sd-bus-errors(3)

SD_BUS_ERROR_INVALID_ARGS

sd-bus-errors(3)

SD_BUS_ERROR_INVALID_SIGNATURE

sd-bus-errors(3)

SD_BUS_ERROR_IO_ERROR

sd-bus-errors(3)

SD_BUS_ERROR_LIMITS_EXCEEDED

sd-bus-errors(3)

SD_BUS_ERROR_MAKE_CONST(name, message**)**

sd_bus_error(3)

SD_BUS_ERROR_MAKE_CONST()

sd_bus_error(3)

SD_BUS_ERROR_MAP(name, code**)**

sd_bus_error_add_map(3)

SD_BUS_ERROR_MAP()

sd_bus_error_add_map(3)

SD_BUS_ERROR_MAP_END

sd_bus_error_add_map(3)

SD_BUS_ERROR_MATCH_RULE_INVALID

sd-bus-errors(3)

SD_BUS_ERROR_MATCH_RULE_NOT_FOUND

sd-bus-errors(3)

SD_BUS_ERROR_NAME_HAS_NO_OWNER

sd-bus-errors(3)

SD_BUS_ERROR_NOT_SUPPORTED

sd-bus-errors(3), sd_bus_message_new_method_error(3)

SD_BUS_ERROR_NO_MEMORY

sd-bus-errors(3), sd_bus_error(3)

SD_BUS_ERROR_NO_NETWORK

sd-bus-errors(3)

SD_BUS_ERROR_NO_REPLY

sd-bus-errors(3)

SD_BUS_ERROR_NO_SERVER

sd-bus-errors(3)

SD_BUS_ERROR_NULL

sd_bus_call(3), sd_bus_error(3)

SD_BUS_ERROR_PROPERTY_READ_ONLY

sd-bus-errors(3)

SD_BUS_ERROR_SERVICE_UNKNOWN

sd-bus-errors(3)

SD_BUS_ERROR_TIMEOUT

sd-bus-errors(3)

SD_BUS_ERROR_UNIX_PROCESS_ID_UNKNOWN

sd-bus-errors(3)

SD_BUS_ERROR_UNKNOWN_INTERFACE

sd-bus-errors(3)

SD_BUS_ERROR_UNKNOWN_METHOD

sd-bus-errors(3)

SD_BUS_ERROR_UNKNOWN_OBJECT

sd-bus-errors(3)

SD_BUS_ERROR_UNKNOWN_PROPERTY

sd-bus-errors(3)

SD_BUS_MESSAGE_DUMP_SUBTREE_ONLY

sd_bus_message_dump(3)

SD_BUS_MESSAGE_DUMP_WITH_HEADER

sd_bus_message_dump(3)

SD_BUS_MESSAGE_METHOD_CALL

sd_bus_message_get_type(3), sd_bus_message_new(3)

SD_BUS_MESSAGE_METHOD_ERROR

sd_bus_message_get_type(3), sd_bus_message_new(3)

SD_BUS_MESSAGE_METHOD_RETURN

sd_bus_message_get_type(3), sd_bus_message_new(3)

SD_BUS_MESSAGE_SIGNAL

sd_bus_message_get_type(3), sd_bus_message_new(3)

SD_BUS_METHOD(member, signature**,** result**,** handler**,** flags**)**

sd_bus_add_object(3)

SD_BUS_METHOD()

sd_bus_add_object(3)

SD_BUS_METHOD_WITH_ARGS(member, args**,** result**,** handler**,** flags**)**

sd_bus_add_object(3)

SD_BUS_METHOD_WITH_ARGS()

sd_bus_add_object(3)

SD_BUS_METHOD_WITH_ARGS_OFFSET(member, args**,** result**,** handler**,** offset**,** flags**)**

sd_bus_add_object(3)

SD_BUS_METHOD_WITH_ARGS_OFFSET()

sd_bus_add_object(3)

SD_BUS_METHOD_WITH_NAMES(member, signature**,** in_names**,** result**,** out_names**,** handler**,** flags**)**

sd_bus_add_object(3)

SD_BUS_METHOD_WITH_NAMES()

sd_bus_add_object(3)

SD_BUS_METHOD_WITH_NAMES_OFFSET(member, signature**,** in_names**,** result**,** out_names**,** handler**,** offset**,** flags**)**

sd_bus_add_object(3)

SD_BUS_METHOD_WITH_NAMES_OFFSET()

sd_bus_add_object(3)

SD_BUS_METHOD_WITH_OFFSET(member, signature**,** result**,** handler**,** offset**,** flags**)**

sd_bus_add_object(3)

SD_BUS_METHOD_WITH_OFFSET()

sd_bus_add_object(3)

SD_BUS_NAME_ALLOW_REPLACEMENT

sd_bus_request_name(3)

SD_BUS_NAME_QUEUE

sd_bus_request_name(3)

SD_BUS_NAME_REPLACE_EXISTING

sd_bus_request_name(3)

SD_BUS_NO_ARGS

sd_bus_add_object(3)

SD_BUS_NO_RESULT

sd_bus_add_object(3)

SD_BUS_PARAM(name)

sd_bus_add_object(3)

SD_BUS_PARAM()

sd_bus_add_object(3)

SD_BUS_PROPERTY(member, signature**,** get**,** offset**,** flags**)**

sd_bus_add_object(3)

SD_BUS_PROPERTY()

sd_bus_add_object(3)

SD_BUS_RESULT(…)

sd_bus_add_object(3)

SD_BUS_RESULT()

sd_bus_add_object(3)

SD_BUS_SIGNAL(member, signature**,** flags**)**

sd_bus_add_object(3)

SD_BUS_SIGNAL()

sd_bus_add_object(3)

SD_BUS_SIGNAL_WITH_ARGS(member, args**,** flags**)**

sd_bus_add_object(3)

SD_BUS_SIGNAL_WITH_ARGS()

sd_bus_add_object(3)

SD_BUS_SIGNAL_WITH_NAMES(member, signature**,** names**,** flags**)**

sd_bus_add_object(3)

SD_BUS_SIGNAL_WITH_NAMES()

sd_bus_add_object(3)

SD_BUS_TYPE

sd_bus_can_send(3)

SD_BUS_TYPE_ARRAY

sd_bus_message_append(3), sd_bus_message_open_container(3), sd_bus_message_read(3)

SD_BUS_TYPE_BOOLEAN

sd_bus_message_append(3), sd_bus_message_append_basic(3), sd_bus_message_read(3), sd_bus_message_read_basic(3)

SD_BUS_TYPE_BYTE

sd_bus_message_append(3), sd_bus_message_append_basic(3), sd_bus_message_read(3), sd_bus_message_read_basic(3)

SD_BUS_TYPE_DICT_ENTRY

sd_bus_message_open_container(3)

SD_BUS_TYPE_DICT_ENTRY_BEGIN

sd_bus_message_append(3), sd_bus_message_read(3)

SD_BUS_TYPE_DICT_ENTRY_END

sd_bus_message_append(3), sd_bus_message_read(3)

SD_BUS_TYPE_DOUBLE

sd_bus_message_append(3), sd_bus_message_append_basic(3), sd_bus_message_read(3), sd_bus_message_read_basic(3)

SD_BUS_TYPE_INT16

sd_bus_message_append(3), sd_bus_message_append_basic(3), sd_bus_message_read(3), sd_bus_message_read_basic(3)

SD_BUS_TYPE_INT32

sd_bus_message_append(3), sd_bus_message_append_basic(3), sd_bus_message_read(3), sd_bus_message_read_basic(3)

SD_BUS_TYPE_INT64

sd_bus_message_append(3), sd_bus_message_append_basic(3), sd_bus_message_read(3), sd_bus_message_read_basic(3)

SD_BUS_TYPE_OBJECT_PATH

sd_bus_message_append(3), sd_bus_message_append_basic(3), sd_bus_message_read(3), sd_bus_message_read_basic(3)

SD_BUS_TYPE_SIGNATURE

sd_bus_message_append(3), sd_bus_message_append_basic(3), sd_bus_message_read(3), sd_bus_message_read_basic(3)

SD_BUS_TYPE_STRING

sd_bus_message_append(3), sd_bus_message_append_basic(3), sd_bus_message_read(3), sd_bus_message_read_basic(3)

SD_BUS_TYPE_STRUCT

sd_bus_message_open_container(3)

SD_BUS_TYPE_STRUCT_BEGIN

sd_bus_message_append(3), sd_bus_message_read(3)

SD_BUS_TYPE_STRUCT_END

sd_bus_message_append(3), sd_bus_message_read(3)

SD_BUS_TYPE_UINT16

sd_bus_message_append(3), sd_bus_message_append_basic(3), sd_bus_message_read(3), sd_bus_message_read_basic(3)

SD_BUS_TYPE_UINT32

sd_bus_message_append(3), sd_bus_message_append_basic(3), sd_bus_message_read(3), sd_bus_message_read_basic(3)

SD_BUS_TYPE_UINT64

sd_bus_message_append(3), sd_bus_message_append_basic(3), sd_bus_message_read(3), sd_bus_message_read_basic(3)

SD_BUS_TYPE_UNIX_FD

sd_bus_message_append(3), sd_bus_message_append_basic(3), sd_bus_message_read(3), sd_bus_message_read_basic(3), sd_bus_negotiate_fds(3)

SD_BUS_TYPE_VARIANT

sd_bus_message_append(3), sd_bus_message_open_container(3), sd_bus_message_read(3)

SD_BUS_VTABLE_ABSOLUTE_OFFSET

sd_bus_add_object(3)

SD_BUS_VTABLE_CAPABILITY(capability)

sd_bus_add_object(3)

SD_BUS_VTABLE_DEPRECATED

sd_bus_add_object(3)

SD_BUS_VTABLE_END

sd_bus_add_object(3)

SD_BUS_VTABLE_HIDDEN

sd_bus_add_object(3)

SD_BUS_VTABLE_METHOD_NO_REPLY

sd_bus_add_object(3)

SD_BUS_VTABLE_PROPERTY_CONST

sd_bus_add_object(3)

SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE

sd_bus_add_object(3)

SD_BUS_VTABLE_PROPERTY_EMITS_INVALIDATION

sd_bus_add_object(3)

SD_BUS_VTABLE_PROPERTY_EXPLICIT

sd_bus_add_object(3)

SD_BUS_VTABLE_SENSITIVE

sd_bus_add_object(3)

SD_BUS_VTABLE_START(flags)

sd_bus_add_object(3)

SD_BUS_VTABLE_START()

sd_bus_add_object(3)

SD_BUS_VTABLE_UNPRIVILEGED

sd_bus_add_object(3)

SD_BUS_WRITABLE_PROPERTY(member, signature**,** get**,** set**,** offset**,** flags**)**

sd_bus_add_object(3)

SD_BUS_WRITABLE_PROPERTY()

sd_bus_add_object(3)

SD_EVENT_ARMED

sd_event_wait(3)

SD_EVENT_EXITING

sd_event_wait(3)

SD_EVENT_FINISHED

sd_event_wait(3)

SD_EVENT_INITIAL

sd_event_wait(3)

SD_EVENT_OFF

sd_event_add_child(3), sd_event_add_defer(3), sd_event_add_io(3), sd_event_add_memory_pressure(3), sd_event_add_signal(3), sd_event_add_time(3), sd_event_source_set_enabled(3), sd_event_source_set_ratelimit(3), sd_event_source_unref(3)

SD_EVENT_ON

sd_event_add_child(3), sd_event_add_defer(3), sd_event_add_inotify(3), sd_event_add_io(3), sd_event_add_signal(3), sd_event_add_time(3), sd_event_source_set_enabled(3)

SD_EVENT_ONESHOT

sd_event_add_child(3), sd_event_add_defer(3), sd_event_add_inotify(3), sd_event_add_time(3), sd_event_source_set_enabled(3)

SD_EVENT_PENDING

sd_event_wait(3)

SD_EVENT_PREPARING

sd_event_wait(3)

SD_EVENT_PRIORITY_IDLE

sd_event_source_set_priority(3)

SD_EVENT_PRIORITY_IMPORTANT

sd_event_source_set_priority(3)

SD_EVENT_PRIORITY_NORMAL

sd_event_source_set_priority(3)

SD_EVENT_RUNNING

sd_event_wait(3)

SD_EVENT_SIGNAL_PROCMASK

sd_event_add_signal(3)

SD_GPT_ESP

systemd-gpt-auto-generator(8)

SD_GPT_FLAG_NO_AUTO

systemd-gpt-auto-generator(8)

SD_GPT_FLAG_NO_BLOCK_IO_PROTOCOL

systemd-gpt-auto-generator(8)

SD_GPT_FLAG_READ_ONLY

systemd-gpt-auto-generator(8)

SD_GPT_HOME

systemd-gpt-auto-generator(8)

SD_GPT_ROOT_ALPHA

systemd-gpt-auto-generator(8)

SD_GPT_ROOT_ARC

systemd-gpt-auto-generator(8)

SD_GPT_ROOT_ARM

systemd-gpt-auto-generator(8)

SD_GPT_ROOT_ARM64

systemd-gpt-auto-generator(8)

SD_GPT_ROOT_IA64

systemd-gpt-auto-generator(8)

SD_GPT_ROOT_LOONGARCH64

systemd-gpt-auto-generator(8)

SD_GPT_ROOT_MIPS

systemd-gpt-auto-generator(8)

SD_GPT_ROOT_MIPS64

systemd-gpt-auto-generator(8)

SD_GPT_ROOT_MIPS64_LE

systemd-gpt-auto-generator(8)

SD_GPT_ROOT_MIPS_LE

systemd-gpt-auto-generator(8)

SD_GPT_ROOT_PARISC

systemd-gpt-auto-generator(8)

SD_GPT_ROOT_PPC

systemd-gpt-auto-generator(8)

SD_GPT_ROOT_PPC64

systemd-gpt-auto-generator(8)

SD_GPT_ROOT_PPC64_LE

systemd-gpt-auto-generator(8)

SD_GPT_ROOT_RISCV32

systemd-gpt-auto-generator(8)

SD_GPT_ROOT_RISCV64

systemd-gpt-auto-generator(8)

SD_GPT_ROOT_S390

systemd-gpt-auto-generator(8)

SD_GPT_ROOT_S390X

systemd-gpt-auto-generator(8)

SD_GPT_ROOT_TILEGX

systemd-gpt-auto-generator(8)

SD_GPT_ROOT_X86

systemd-gpt-auto-generator(8)

SD_GPT_ROOT_X86_64

systemd-gpt-auto-generator(8)

SD_GPT_SRV

systemd-gpt-auto-generator(8)

SD_GPT_SWAP

systemd-gpt-auto-generator(8)

SD_GPT_TMP

systemd-gpt-auto-generator(8)

SD_GPT_USR_ALPHA

systemd-gpt-auto-generator(8)

SD_GPT_USR_ARC

systemd-gpt-auto-generator(8)

SD_GPT_USR_ARM

systemd-gpt-auto-generator(8)

SD_GPT_USR_IA64

systemd-gpt-auto-generator(8)

SD_GPT_USR_LOONGARCH64

systemd-gpt-auto-generator(8)

SD_GPT_USR_MIPS64_LE

systemd-gpt-auto-generator(8)

SD_GPT_USR_MIPS_LE

systemd-gpt-auto-generator(8)

SD_GPT_USR_PARISC

systemd-gpt-auto-generator(8)

SD_GPT_USR_PPC

systemd-gpt-auto-generator(8)

SD_GPT_USR_PPC64

systemd-gpt-auto-generator(8)

SD_GPT_USR_PPC64_LE

systemd-gpt-auto-generator(8)

SD_GPT_USR_RISCV32

systemd-gpt-auto-generator(8)

SD_GPT_USR_RISCV64

systemd-gpt-auto-generator(8)

SD_GPT_USR_S390

systemd-gpt-auto-generator(8)

SD_GPT_USR_S390X

systemd-gpt-auto-generator(8)

SD_GPT_USR_TILEGX

systemd-gpt-auto-generator(8)

SD_GPT_USR_X86

systemd-gpt-auto-generator(8)

SD_GPT_VAR

systemd-gpt-auto-generator(8)

SD_GPT_XBOOTLDR

systemd-gpt-auto-generator(8)

SD_HOMED_UPDATE_OFFLINE

org.freedesktop.home1(5)

SD_ID128_ALLF

sd-id128(3), sd_id128_get_machine(3), sd_id128_randomize(3)

SD_ID128_CONST_STR(id)

sd-id128(3)

SD_ID128_FORMAT_STR

sd-id128(3), sd_id128_to_string(3)

SD_ID128_FORMAT_VAL(id)

sd-id128(3)

SD_ID128_MAKE(v0, v1**,** v2**,** v3**,** v4**,** v5**,** v6**,** v7**,** v8**,** v9**,** vA**,** vB**,** vC**,** vD**,** vE**,** vF**)**

sd-id128(3)

SD_ID128_MAKE_STR(v0, v1**,** v2**,** v3**,** v4**,** v5**,** v6**,** v7**,** v8**,** v9**,** vA**,** vB**,** vC**,** vD**,** vE**,** vF**)**

sd-id128(3)

SD_ID128_MAKE_UUID_STR(v0, v1**,** v2**,** v3**,** v4**,** v5**,** v6**,** v7**,** v8**,** v9**,** vA**,** vB**,** vC**,** vD**,** vE**,** vF**)**

sd-id128(3)

SD_ID128_NULL

sd-id128(3), sd_bus_set_server(3), sd_id128_get_machine(3), sd_id128_randomize(3)

SD_ID128_STRING_MAX

sd_id128_to_string(3)

SD_ID128_UUID_FORMAT_STR

sd-id128(3)

SD_JOURNAL_ALL_NAMESPACES

sd_journal_open(3)

SD_JOURNAL_APPEND

sd_journal_get_fd(3)

SD_JOURNAL_CURRENT_USER

sd_journal_open(3)

SD_JOURNAL_INCLUDE_DEFAULT_NAMESPACE

sd_journal_open(3)

SD_JOURNAL_INVALIDATE

sd_journal_get_fd(3)

SD_JOURNAL_LOCAL_ONLY

sd_journal_get_usage(3), sd_journal_open(3)

SD_JOURNAL_NOP

sd_journal_get_fd(3)

SD_JOURNAL_OS_ROOT

sd_journal_open(3)

SD_JOURNAL_RUNTIME_ONLY

sd_journal_open(3)

SD_JOURNAL_SUPPRESS_LOCATION

sd_journal_print(3)

SD_JOURNAL_SYSTEM

sd_journal_open(3)

SD_JOURNAL_TAKE_DIRECTORY_FD

sd_journal_open(3)

SD_LISTEN_FDS_START

sd_listen_fds(3)

SD_LOGIND_KEXEC_REBOOT

org.freedesktop.login1(5)

SD_LOGIND_ROOT_CHECK_INHIBITORS

org.freedesktop.login1(5)

SD_LOGIND_SOFT_REBOOT

org.freedesktop.login1(5)

SD_LOGIND_SOFT_REBOOT_IF_NEXTROOT_SET_UP

org.freedesktop.login1(5)

SD_PATH_BINFMT

sd_path_lookup(3)

SD_PATH_CATALOG

sd_path_lookup(3)

SD_PATH_MODULES_LOAD

sd_path_lookup(3)

SD_PATH_SEARCH_BINARIES

sd_path_lookup(3)

SD_PATH_SEARCH_BINARIES_DEFAULT

sd_path_lookup(3)

SD_PATH_SEARCH_CONFIGURATION

sd_path_lookup(3)

SD_PATH_SEARCH_CONFIGURATION_FACTORY

sd_path_lookup(3)

SD_PATH_SEARCH_LIBRARY_ARCH

sd_path_lookup(3)

SD_PATH_SEARCH_LIBRARY_PRIVATE

sd_path_lookup(3)

SD_PATH_SEARCH_SHARED

sd_path_lookup(3)

SD_PATH_SEARCH_STATE_FACTORY

sd_path_lookup(3)

SD_PATH_SYSCTL

sd_path_lookup(3)

SD_PATH_SYSTEMD_SEARCH_NETWORK

sd_path_lookup(3)

SD_PATH_SYSTEMD_SEARCH_SYSTEM_ENVIRONMENT_GENERATOR

sd_path_lookup(3)

SD_PATH_SYSTEMD_SEARCH_SYSTEM_GENERATOR

sd_path_lookup(3)

SD_PATH_SYSTEMD_SEARCH_SYSTEM_UNIT

sd_path_lookup(3)

SD_PATH_SYSTEMD_SEARCH_USER_ENVIRONMENT_GENERATOR

sd_path_lookup(3)

SD_PATH_SYSTEMD_SEARCH_USER_GENERATOR

sd_path_lookup(3)

SD_PATH_SYSTEMD_SEARCH_USER_UNIT

sd_path_lookup(3)

SD_PATH_SYSTEMD_SHUTDOWN

sd_path_lookup(3)

SD_PATH_SYSTEMD_SLEEP

sd_path_lookup(3)

SD_PATH_SYSTEMD_SYSTEM_CONF

sd_path_lookup(3)

SD_PATH_SYSTEMD_SYSTEM_ENVIRONMENT_GENERATOR

sd_path_lookup(3)

SD_PATH_SYSTEMD_SYSTEM_GENERATOR

sd_path_lookup(3)

SD_PATH_SYSTEMD_SYSTEM_PRESET

sd_path_lookup(3)

SD_PATH_SYSTEMD_SYSTEM_UNIT

sd_path_lookup(3)

SD_PATH_SYSTEMD_USER_CONF

sd_path_lookup(3)

SD_PATH_SYSTEMD_USER_ENVIRONMENT_GENERATOR

sd_path_lookup(3)

SD_PATH_SYSTEMD_USER_GENERATOR

sd_path_lookup(3)

SD_PATH_SYSTEMD_USER_PRESET

sd_path_lookup(3)

SD_PATH_SYSTEMD_USER_UNIT

sd_path_lookup(3)

SD_PATH_SYSTEMD_UTIL

sd_path_lookup(3)

SD_PATH_SYSTEM_BINARIES

sd_path_lookup(3)

SD_PATH_SYSTEM_CONFIGURATION

sd_path_lookup(3)

SD_PATH_SYSTEM_CONFIGURATION_FACTORY

sd_path_lookup(3)

SD_PATH_SYSTEM_INCLUDE

sd_path_lookup(3)

SD_PATH_SYSTEM_LIBRARY_ARCH

sd_path_lookup(3)

SD_PATH_SYSTEM_LIBRARY_PRIVATE

sd_path_lookup(3)

SD_PATH_SYSTEM_RUNTIME

sd_path_lookup(3)

SD_PATH_SYSTEM_RUNTIME_LOGS

sd_path_lookup(3)

SD_PATH_SYSTEM_SHARED

sd_path_lookup(3)

SD_PATH_SYSTEM_STATE_CACHE

sd_path_lookup(3)

SD_PATH_SYSTEM_STATE_FACTORY

sd_path_lookup(3)

SD_PATH_SYSTEM_STATE_LOGS

sd_path_lookup(3)

SD_PATH_SYSTEM_STATE_PRIVATE

sd_path_lookup(3)

SD_PATH_SYSTEM_STATE_SPOOL

sd_path_lookup(3)

SD_PATH_SYSUSERS

sd_path_lookup(3)

SD_PATH_TEMPORARY

sd_path_lookup(3)

SD_PATH_TEMPORARY_LARGE

sd_path_lookup(3)

SD_PATH_TMPFILES

sd_path_lookup(3)

SD_PATH_USER

sd_path_lookup(3)

SD_PATH_USER_BINARIES

sd_path_lookup(3)

SD_PATH_USER_CONFIGURATION

sd_path_lookup(3)

SD_PATH_USER_DESKTOP

sd_path_lookup(3)

SD_PATH_USER_DOCUMENTS

sd_path_lookup(3)

SD_PATH_USER_DOWNLOAD

sd_path_lookup(3)

SD_PATH_USER_LIBRARY_ARCH

sd_path_lookup(3)

SD_PATH_USER_LIBRARY_PRIVATE

sd_path_lookup(3)

SD_PATH_USER_MUSIC

sd_path_lookup(3)

SD_PATH_USER_PICTURES

sd_path_lookup(3)

SD_PATH_USER_PUBLIC

sd_path_lookup(3)

SD_PATH_USER_RUNTIME

sd_path_lookup(3)

SD_PATH_USER_SHARED

sd_path_lookup(3)

SD_PATH_USER_STATE_CACHE

sd_path_lookup(3)

SD_PATH_USER_STATE_PRIVATE

sd_path_lookup(3)

SD_PATH_USER_TEMPLATES

sd_path_lookup(3)

SD_PATH_USER_VIDEOS

sd_path_lookup(3)

SD_WARNING

sd_journal_stream_fd(3)

SEQNUM

udev_device_new_from_syspath(3)

SHM_EXEC

systemd.exec(5)

SIGABRT

systemd-udevd.service(8), systemd.kill(5), systemd.service(5)

SIGCHLD

sd_event_add_child(3)

SIGCONT

systemd.kill(5)

SIGHUP

daemon(7), org.freedesktop.hostname1(5), systemd(1), systemd-resolved.service(8), systemd.kill(5), systemd.service(5)

SIGINT

loginctl(1), machinectl(1), sd_event_set_signal_exit(3), systemctl(1), systemd(1), systemd.service(5), systemd.special(7)

SIGKILL

sd_event_add_child(3), systemd-nspawn(1), systemd-oomd.service(8), systemd-soft-reboot.service(8), systemd-udevd.service(8), systemd.kill(5), systemd.mount(5), systemd.resource-control(5), systemd.service(5), systemd.socket(5), systemd.swap(5)

SIGPIPE

systemd-journald.service(8), systemd.exec(5), systemd.service(5)

SIGPWR

systemd(1)

SIGQUIT

systemd.kill(5)

SIGRTMAX-…

org.freedesktop.systemd1(5)

SIGRTMIN+0

systemd(1)

SIGRTMIN+1

resolvectl(1), systemd(1), systemd-resolved.service(8)

SIGRTMIN+13

systemd(1)

SIGRTMIN+14

systemd(1)

SIGRTMIN+15

systemd(1)

SIGRTMIN+16

systemd(1)

SIGRTMIN+17

systemd(1)

SIGRTMIN+2

systemd(1)

SIGRTMIN+20

systemd(1)

SIGRTMIN+21

systemd(1)

SIGRTMIN+22

systemd(1)

SIGRTMIN+23

systemd(1)

SIGRTMIN+24

systemd(1)

SIGRTMIN+25

systemd(1)

SIGRTMIN+26

systemd(1)

SIGRTMIN+27

systemd(1)

SIGRTMIN+28

systemd(1)

SIGRTMIN+3

systemd(1), systemd-nspawn(1)

SIGRTMIN+4

systemd(1)

SIGRTMIN+5

systemd(1)

SIGRTMIN+6

systemd(1)

SIGRTMIN+7

systemd(1)

SIGRTMIN+…

org.freedesktop.systemd1(5)

SIGSTOP

loginctl(1), machinectl(1), systemctl(1)

SIGSYS

systemd.exec(5)

SIGTERM

daemon(7), loginctl(1), machinectl(1), org.freedesktop.systemd1(5), sd_event_exit(3), sd_event_set_signal_exit(3), systemctl(1), systemd(1), systemd-nspawn(1), systemd-soft-reboot.service(8), systemd.kill(5), systemd.mount(5), systemd.service(5), systemd.socket(5), systemd.special(7), systemd.swap(5)

SIGUSR1

journald.conf(5), systemd(1), systemd-journald.service(8), systemd-resolved.service(8)

SIGUSR2

resolvectl(1), systemd(1), systemd-resolved.service(8)

SIGWINCH

systemd(1)

SIG_DFL

daemon(7)

SOCK_DGRAM

sd_is_fifo(3), sd_notify(3), systemd(1), systemd-socket-activate(1), systemd.socket(5)

SOCK_RAW

systemd.socket(5)

SOCK_SEQPACKET

sd_notify(3), systemd(1), systemd-socket-activate(1), systemd.exec(5), systemd.socket(5)

SOCK_STREAM

sd_is_fifo(3), systemd-socket-activate(1), systemd-ssh-proxy(1), systemd.socket(5)

SO_BINDTODEVICE

systemd.socket(5)

SO_BROADCAST

systemd.socket(5)

SO_KEEPALIVE

systemd.socket(5)

SO_MARK

systemd.socket(5)

SO_PASSCRED

systemd.socket(5)

SO_PASSSEC

systemd.socket(5)

SO_PEERCRED

systemd-socket-proxyd(8)

SO_PEERGROUPS

systemd-socket-proxyd(8)

SO_PEERPIDFD

systemd-socket-proxyd(8)

SO_PEERSEC

systemd-socket-proxyd(8)

SO_PRIORITY

systemd.netdev(5), systemd.network(5), systemd.socket(5)

SO_RCVBUF

systemd.socket(5)

SO_REUSEPORT

systemd.socket(5)

SO_SNDBUF

systemd.socket(5)

SO_TIMESTAMP

systemd.socket(5)

SO_TIMESTAMPNS

systemd.socket(5)

SUBSYSTEM

udev_device_new_from_syspath(3)

SYSTEMD_LOG_LEVEL=debug,console:info

homectl(1), importctl(1), journalctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), systemctl(1), systemd(1), systemd-analyze(1), systemd-inhibit(1), systemd-nspawn(1), systemd-tmpfiles(8), timedatectl(1), userdbctl(1)

S_IFREG

org.freedesktop.systemd1(5)

S_IRUSR

org.freedesktop.systemd1(5)

TAB

systemctl(1)

TCP_DEFER_ACCEPT

systemd.socket(5)

TCP_KEEPINTVL

systemd.socket(5)

TEMPFAIL

systemd.service(5)

TFD_TIMER_CANCEL_ON_SET

org.freedesktop.timedate1(5)

TIOCSTI

systemd-nspawn(1)

U+0000

systemd.exec(5)

U+FEFF

systemd.exec(5)

UINT32_MAX

org.freedesktop.hostname1(5)

UINT64_MAX

org.freedesktop.home1(5), org.freedesktop.hostname1(5), sd_bus_get_fd(3), sd_bus_wait(3), sd_event_add_time(3)

UNIT64_MAX

org.freedesktop.hostname1(5)

USER_PROCESS

systemd.exec(5)

VMADDR_CID_ANY

org.freedesktop.machine1(5)

WCONTINUED

sd_event_add_child(3)

WEXITED

sd_event_add_child(3)

WSTOPPED

sd_event_add_child(3)

X

systemd.net-naming-scheme(7)

_NSIG

daemon(7)

_SC_ARG_MAX

systemctl(1)

_SD_BUS_CREDS_ALL

sd_bus_creds_new_from_pid(3)

a

systemd.net-naming-scheme(7), tmpfiles.d(5)

abcmABM

tmpfiles.d(5)

activating

systemctl(1)

active

systemctl(1)

alert

homectl(1), importctl(1), journalctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), systemctl(1), systemd(1), systemd-analyze(1), systemd-inhibit(1), systemd-nspawn(1), systemd-tmpfiles(8), timedatectl(1), userdbctl(1)

all

journalctl(1), systemctl(1), systemd.exec(5), udevadm(8)

alpha

repart.d(5), systemd.exec(5)

any

systemd.resource-control(5)

application/json

systemd-journal-gatewayd.service(8)

application/vnd.fdo.journal

systemd-journal-gatewayd.service(8)

arc

repart.d(5)

argv[0]

systemd.service(5)

arm

repart.d(5), systemd.exec(5)

arm-be

systemd.exec(5)

arm64

repart.d(5), systemd-system.conf(5), systemd.dnssd(5), systemd.exec(5), systemd.link(5), systemd.unit(5), sysupdate.d(5), sysusers.d(5), tmpfiles.d(5)

arm64-be

systemd.exec(5)

auto

homectl(1), importctl(1), journalctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), systemctl(1), systemd(1), systemd-analyze(1), systemd-inhibit(1), systemd-nspawn(1), systemd-tmpfiles(8), timedatectl(1), userdbctl(1)

b

systemd.net-naming-scheme(7), tmpfiles.d(5), udev_device_new_from_syspath(3)

b921b045-1df0-41c3-af44-4c6f280d3fae

systemd-gpt-auto-generator(8)

background

pam_systemd(8)

background-light

pam_systemd(8)

bad-setting

systemctl(1)

basic.target

systemd-soft-reboot.service(8)

bc13c2ff-59e6-4262-a352-b275fd6f7172

systemd-gpt-auto-generator(8)

bind4

systemd.resource-control(5)

bind6

systemd.resource-control(5)

boot

sysupdate.d(5)

c

systemd.net-naming-scheme(7), tmpfiles.d(5), udev_device_new_from_syspath(3)

c12a7328-f81f-11d2-ba4b-00a0c93ec93b

systemd-gpt-auto-generator(8)

cache

systemctl(1)

cgroup

systemd.exec(5)

cgroup/bind4

systemd.resource-control(5)

cgroup/bind6

systemd.resource-control(5)

configuration

systemctl(1)

connect4

systemd.resource-control(5)

connect6

systemd.resource-control(5)

console

homectl(1), importctl(1), journalctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), systemctl(1), systemd(1), systemd-analyze(1), systemd-inhibit(1), systemd-nspawn(1), systemd-tmpfiles(8), timedatectl(1), userdbctl(1)

console-prefixed

homectl(1), importctl(1), journalctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), systemctl(1), systemd(1), systemd-analyze(1), systemd-inhibit(1), systemd-nspawn(1), systemd-tmpfiles(8), timedatectl(1), userdbctl(1)

const

sd_bus_add_object(3)

continue

systemd.scope(5), systemd.service(5)

control-group

systemd.kill(5)

crit

homectl(1), importctl(1), journalctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), systemctl(1), systemd(1), systemd-analyze(1), systemd-inhibit(1), systemd-nspawn(1), systemd-tmpfiles(8), timedatectl(1), userdbctl(1)

d

systemd.net-naming-scheme(7), tmpfiles.d(5)

deactivating

systemctl(1)

debug

homectl(1), importctl(1), journalctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), systemctl(1), systemd(1), systemd-analyze(1), systemd-inhibit(1), systemd-nspawn(1), systemd-tmpfiles(8), timedatectl(1), userdbctl(1)

default

systemd.exec(5)

device

systemd.resource-control(5)

directory

sysupdate.d(5)

early

udevadm(8)

egress

systemd.resource-control(5)

elf-headers

systemd.exec(5)

emerg

homectl(1), importctl(1), journalctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), systemctl(1), systemd(1), systemd-analyze(1), systemd-inhibit(1), systemd-nspawn(1), systemd-tmpfiles(8), timedatectl(1), userdbctl(1)

en

systemd.net-naming-scheme(7)

enter-initrd

ukify(1)

err

homectl(1), importctl(1), journalctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), systemctl(1), systemd(1), systemd-analyze(1), systemd-inhibit(1), systemd-nspawn(1), systemd-tmpfiles(8), timedatectl(1), userdbctl(1)

error

sd_bus_message_new_method_error(3), systemctl(1), systemd(1)

esp

repart.d(5), systemd.exec(5), sysupdate.d(5)

ext2

systemd.exec(5)

ext4

systemd.exec(5)

f

systemd.net-naming-scheme(7)

failed

systemctl(1), systemd.unit(5)

false

sd_bus_error(3)

fdstore

systemctl(1)

getsockopt

systemd.resource-control(5)

greeter

pam_systemd(8)

h

tmpfiles.d(5)

home

repart.d(5), systemd.exec(5)

host

systemd-journal-remote.service(8)

https

systemd-journal-upload.service(8)

i

systemd.net-naming-scheme(7)

ia64

repart.d(5)

ib

systemd.net-naming-scheme(7)

inactive

systemctl(1), systemd.unit(5)

infinity

systemd-socket-proxyd(8), systemd.exec(5)

info

homectl(1), importctl(1), journalctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), systemctl(1), systemd(1), systemd-analyze(1), systemd-inhibit(1), systemd-nspawn(1), systemd-tmpfiles(8), timedatectl(1), userdbctl(1)

ingress

systemd.resource-control(5)

invalidates

sd_bus_add_object(3)

io.systemd.DropIn

systemd-userdbd.service(8), userdbctl(1)

io.systemd.DynamicUser

userdbctl(1)

io.systemd.Home

userdbctl(1)

io.systemd.Machine

userdbctl(1)

io.systemd.MountFileSystem

systemd-mountfsd.service(8)

io.systemd.Multiplexer

systemd-userdbd.service(8), userdbctl(1)

io.systemd.NameServiceSwitch

systemd-userdbd.service(8), userdbctl(1)

io.systemd.NamespaceResource

systemd-nsresourced.service(8)

ipc

systemd.exec(5)

ipv4

systemd.resource-control(5)

ipv6

systemd.resource-control(5)

journal

homectl(1), importctl(1), journalctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), systemctl(1), systemd(1), systemd-analyze(1), systemd-inhibit(1), systemd-nspawn(1), systemd-tmpfiles(8), timedatectl(1), userdbctl(1)

journal-or-kmsg

homectl(1), importctl(1), journalctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), systemctl(1), systemd(1), systemd-analyze(1), systemd-inhibit(1), systemd-nspawn(1), systemd-tmpfiles(8), timedatectl(1), userdbctl(1)

keep

systemd.net-naming-scheme(7)

keep-caps

systemd.exec(5)

kernel.modules_disabled

systemd.exec(5)

kill

systemd.scope(5), systemd.service(5)

kmsg

homectl(1), importctl(1), journalctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), systemctl(1), systemd(1), systemd-analyze(1), systemd-inhibit(1), systemd-nspawn(1), systemd-tmpfiles(8), timedatectl(1), userdbctl(1)

late

udevadm(8)

latest

systemd.net-naming-scheme(7)

leave-initrd

ukify(1)

libsystemd

libsystemd(3), sd-bus(3), sd-bus-errors(3), sd-daemon(3), sd-device(3), sd-event(3), sd-hwdb(3), sd-id128(3), sd-journal(3), sd-login(3), sd_booted(3), sd_bus_add_match(3), sd_bus_add_node_enumerator(3), sd_bus_add_object(3), sd_bus_add_object_manager(3), sd_bus_attach_event(3), sd_bus_call(3), sd_bus_call_method(3), sd_bus_can_send(3), sd_bus_close(3), sd_bus_creds_get_pid(3), sd_bus_creds_new_from_pid(3), sd_bus_default(3), sd_bus_emit_signal(3), sd_bus_enqueue_for_read(3), sd_bus_error(3), sd_bus_error_add_map(3), sd_bus_get_current_handler(3), sd_bus_get_fd(3), sd_bus_get_name_creds(3), sd_bus_get_name_machine_id(3), sd_bus_interface_name_is_valid(3), sd_bus_is_open(3), sd_bus_list_names(3), sd_bus_message_append(3), sd_bus_message_append_array(3), sd_bus_message_append_basic(3), sd_bus_message_append_string_memfd(3), sd_bus_message_append_strv(3), sd_bus_message_at_end(3), sd_bus_message_copy(3), sd_bus_message_dump(3), sd_bus_message_get_cookie(3), sd_bus_message_get_monotonic_usec(3), sd_bus_message_get_signature(3), sd_bus_message_get_type(3), sd_bus_message_new(3), sd_bus_message_new_method_call(3), sd_bus_message_new_method_error(3), sd_bus_message_new_signal(3), sd_bus_message_open_container(3), sd_bus_message_read(3), sd_bus_message_rewind(3), sd_bus_message_seal(3), sd_bus_message_sensitive(3), sd_bus_message_set_destination(3), sd_bus_message_set_expect_reply(3), sd_bus_message_skip(3), sd_bus_message_verify_type(3), sd_bus_negotiate_fds(3), sd_bus_new(3), sd_bus_path_encode(3), sd_bus_process(3), sd_bus_query_sender_creds(3), sd_bus_reply_method_error(3), sd_bus_reply_method_return(3), sd_bus_request_name(3), sd_bus_send(3), sd_bus_set_address(3), sd_bus_set_close_on_exit(3), sd_bus_set_connected_signal(3), sd_bus_set_description(3), sd_bus_set_exit_on_disconnect(3), sd_bus_set_fd(3), sd_bus_set_method_call_timeout(3), sd_bus_set_property(3), sd_bus_set_sender(3), sd_bus_set_server(3), sd_bus_set_watch_bind(3), sd_bus_slot_get_bus(3), sd_bus_slot_ref(3), sd_bus_slot_set_description(3), sd_bus_slot_set_destroy_callback(3), sd_bus_slot_set_floating(3), sd_bus_slot_set_userdata(3), sd_bus_start(3), sd_bus_track_add_name(3), sd_bus_track_new(3), sd_bus_wait(3), sd_device_get_syspath(3), sd_event_add_child(3), sd_event_add_defer(3), sd_event_add_inotify(3), sd_event_add_io(3), sd_event_add_memory_pressure(3), sd_event_add_signal(3), sd_event_add_time(3), sd_event_exit(3), sd_event_get_fd(3), sd_event_new(3), sd_event_now(3), sd_event_run(3), sd_event_set_signal_exit(3), sd_event_set_watchdog(3), sd_event_source_get_event(3), sd_event_source_get_pending(3), sd_event_source_set_description(3), sd_event_source_set_destroy_callback(3), sd_event_source_set_enabled(3), sd_event_source_set_exit_on_failure(3), sd_event_source_set_floating(3), sd_event_source_set_prepare(3), sd_event_source_set_priority(3), sd_event_source_set_ratelimit(3), sd_event_source_set_userdata(3), sd_event_source_unref(3), sd_event_wait(3), sd_get_seats(3), sd_hwdb_get(3), sd_hwdb_new(3), sd_id128_get_machine(3), sd_id128_randomize(3), sd_id128_to_string(3), sd_is_fifo(3), sd_journal_add_match(3), sd_journal_enumerate_fields(3), sd_journal_get_catalog(3), sd_journal_get_cursor(3), sd_journal_get_cutoff_realtime_usec(3), sd_journal_get_data(3), sd_journal_get_fd(3), sd_journal_get_realtime_usec(3), sd_journal_get_seqnum(3), sd_journal_get_usage(3), sd_journal_has_runtime_files(3), sd_journal_next(3), sd_journal_open(3), sd_journal_print(3), sd_journal_query_unique(3), sd_journal_seek_head(3), sd_journal_stream_fd(3), sd_listen_fds(3), sd_login_monitor_new(3), sd_machine_get_class(3), sd_notify(3), sd_path_lookup(3), sd_pid_get_owner_uid(3), sd_seat_get_active(3), sd_session_is_active(3), sd_uid_get_state(3), sd_watchdog_enabled(3)

link-local

systemd.resource-control(5)

linux-generic

repart.d(5), sysupdate.d(5)

loaded

systemctl(1)

localhost

systemd.resource-control(5)

lock-screen

pam_systemd(8)

logs

systemctl(1)

loongarch64

repart.d(5)

m

systemd.resource-control(5), tmpfiles.d(5)

m68k

systemd.exec(5)

manager

pam_systemd(8)

manager-early

pam_systemd(8)

masked

systemctl(1)

max_equalizers=N+1

systemd.network(5)

min

tmpfiles.d(5)

mips-le

repart.d(5)

mips64-le

repart.d(5)

mips64-le-n32

systemd.exec(5)

mips64-n32

systemd.exec(5)

mixed

systemd.kill(5)

mnt

systemd.exec(5)

more

varlinkctl(1)

ms

tmpfiles.d(5)

multi

systemd.resource-control(5)

multicast

systemd.resource-control(5)

n

systemd.net-naming-scheme(7)

name

udevadm(8)

native

systemd.exec(5)

net

systemd.exec(5)

never

udevadm(8)

no

systemd.service(5)

nobody

systemd-nspawn(1)

noexec

systemd.exec(5)

none

systemd-journal-remote.service(8), systemd.kill(5)

not-found

systemctl(1)

notice

homectl(1), importctl(1), journalctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), systemctl(1), systemd(1), systemd-analyze(1), systemd-inhibit(1), systemd-nspawn(1), systemd-tmpfiles(8), timedatectl(1), userdbctl(1)

null

homectl(1), importctl(1), journalctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), systemctl(1), systemd(1), systemd-analyze(1), systemd-inhibit(1), systemd-nspawn(1), systemd-tmpfiles(8), timedatectl(1), userdbctl(1)

o

systemd.net-naming-scheme(7)

oneway

varlinkctl(1)

org.freedesktop.DBus.Deprecated

sd_bus_add_object(3)

org.freedesktop.DBus.Introspectable.Introspect

busctl(1), sd_bus_add_node_enumerator(3), sd_bus_add_object(3)

org.freedesktop.DBus.Method.NoReply

sd_bus_add_object(3)

org.freedesktop.DBus.ObjectManager

sd_bus_add_object_manager(3), sd_bus_emit_signal(3)

org.freedesktop.DBus.ObjectManager.GetManagedObjects

sd_bus_add_node_enumerator(3)

org.freedesktop.DBus.Peer

sd_bus_get_name_machine_id(3)

org.freedesktop.DBus.Properties

sd_bus_emit_signal(3), sd_bus_set_property(3)

org.freedesktop.DBus.Properties.PropertiesChanged

sd_bus_add_object(3)

org.freedesktop.DBus.Property.EmitsChangedSignal

sd_bus_add_object(3)

org.freedesktop.locale1.set-keyboard

org.freedesktop.locale1(5)

org.freedesktop.locale1.set-locale

org.freedesktop.locale1(5)

org.freedesktop.resolve1.Aborted

org.freedesktop.resolve1(5)

org.freedesktop.resolve1.CNameLoop

org.freedesktop.resolve1(5)

org.freedesktop.resolve1.DnsError.NXDOMAIN

org.freedesktop.resolve1(5)

org.freedesktop.resolve1.DnsError.REFUSED

org.freedesktop.resolve1(5)

org.freedesktop.resolve1.DnssecFailed

org.freedesktop.resolve1(5)

org.freedesktop.resolve1.InvalidReply

org.freedesktop.resolve1(5)

org.freedesktop.resolve1.LinkBusy

org.freedesktop.resolve1(5)

org.freedesktop.resolve1.NetworkDown

org.freedesktop.resolve1(5)

org.freedesktop.resolve1.NoNameServers

org.freedesktop.resolve1(5)

org.freedesktop.resolve1.NoSuchLink

org.freedesktop.resolve1(5)

org.freedesktop.resolve1.NoSuchRR

org.freedesktop.resolve1(5)

org.freedesktop.resolve1.NoSuchService

org.freedesktop.resolve1(5)

org.freedesktop.resolve1.NoTrustAnchor

org.freedesktop.resolve1(5)

org.freedesktop.resolve1.ResourceRecordTypeUnsupported

org.freedesktop.resolve1(5)

org.freedesktop.systemd1.Explicit

sd_bus_add_object(3)

org.freedesktop.systemd1.Privileged

sd_bus_add_object(3)

p

systemd.net-naming-scheme(7)

parisc

repart.d(5)

partition

sysupdate.d(5)

path

udevadm(8)

phys_port_name

systemd.net-naming-scheme(7)

pid

systemd.exec(5)

post_bind4

systemd.resource-control(5)

post_bind6

systemd.resource-control(5)

ppc

repart.d(5), systemd.exec(5)

ppc-le

systemd.exec(5)

ppc64

repart.d(5), systemd.exec(5)

ppc64-le

repart.d(5), systemd.exec(5)

private-anonymous

systemd.exec(5)

private-dax

systemd.exec(5)

private-file-backed

systemd.exec(5)

private-huge

systemd.exec(5)

process

systemd.kill(5)

property

udevadm(8)

r

systemd.net-naming-scheme(7), systemd.resource-control(5)

random

systemd-repart(8)

ready

ukify(1)

recvmsg4

systemd.resource-control(5)

recvmsg6

systemd.resource-control(5)

regular-file

sysupdate.d(5)

reloading

systemctl(1)

restart

systemd.service(5)

return

sd_bus_error(3)

riscv32

repart.d(5)

riscv64

repart.d(5)

root

repart.d(5), systemd.exec(5), sysupdate.d(5)

root-riscv64

repart.d(5)

root-secondary

repart.d(5)

root-secondary-verity

repart.d(5)

root-secondary-verity-sig

repart.d(5)

root-verity

repart.d(5)

root-verity-sig

repart.d(5)

root-x86-64

repart.d(5)

root-{arch}

repart.d(5)

root-{arch}-verity

repart.d(5)

root-{arch}-verity-sig

repart.d(5)

runtime

systemctl(1)

rw

systemd.exec(5), systemd.service(5)

rwm

systemd.exec(5)

rwxrwxrwx

systemd-mount(1)

s

systemd.net-naming-scheme(7), tmpfiles.d(5)

s390

repart.d(5), systemd.exec(5)

s390x

repart.d(5), systemd.exec(5)

sch_teql

systemd.network(5)

sendmsg4

systemd.resource-control(5)

sendmsg6

systemd.resource-control(5)

setsockopt

systemd.resource-control(5)

shared-anonymous

systemd.exec(5)

shared-dax

systemd.exec(5)

shared-file-backed

systemd.exec(5)

shared-huge

systemd.exec(5)

simple

systemd-run(1)

sl

systemd.net-naming-scheme(7)

sock_create

systemd.resource-control(5)

sock_ops

systemd.resource-control(5)

srv

repart.d(5), systemd.exec(5)

state

systemctl(1)

stdio

sd_bus_message_dump(3)

stop

systemd.scope(5), systemd.service(5)

subvolume

sysupdate.d(5)

swap

repart.d(5)

symlink

udevadm(8)

sysctl

systemd.resource-control(5)

sysinit

ukify(1)

syslog

homectl(1), importctl(1), journalctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), systemctl(1), systemd(1), systemd-analyze(1), systemd-inhibit(1), systemd-nspawn(1), systemd-tmpfiles(8), timedatectl(1), userdbctl(1)

tar

sysupdate.d(5)

tcp

resolvectl(1), systemd.resource-control(5)

text/event-stream

systemd-journal-gatewayd.service(8)

text/plain

systemd-journal-gatewayd.service(8)

tilegx

repart.d(5)

tmp

repart.d(5), systemd.exec(5)

tmpfs

systemd-mount(1), systemd.exec(5)

true

sd_bus_add_object(3), systemd-oomd.service(8)

u

systemd.net-naming-scheme(7)

udev_hwdb

libudev(3)

udev_queue

libudev(3)

udp

systemd.resource-control(5)

url-file

sysupdate.d(5)

url-tar

sysupdate.d(5)

us

tmpfiles.d(5)

user

pam_systemd(8), systemd.exec(5)

user-early

pam_systemd(8)

user-incomplete

pam_systemd(8)

usr

repart.d(5), systemd.exec(5)

usr-secondary

repart.d(5)

usr-secondary-verity

repart.d(5)

usr-secondary-verity-sig

repart.d(5)

usr-verity

repart.d(5)

usr-verity-sig

repart.d(5)

usr-x86-64

repart.d(5)

usr-{arch}

repart.d(5)

usr-{arch}-verity

repart.d(5)

usr-{arch}-verity-sig

repart.d(5)

uts

systemd.exec(5)

v

systemd.net-naming-scheme(7)

v238

systemd.net-naming-scheme(7)

v239

systemd.net-naming-scheme(7)

v240

systemd.net-naming-scheme(7)

v241

systemd.net-naming-scheme(7)

v243

systemd.net-naming-scheme(7)

v245

systemd.net-naming-scheme(7)

v247

systemd.net-naming-scheme(7)

v249

systemd.net-naming-scheme(7)

v250

systemd.net-naming-scheme(7)

v251

systemd.net-naming-scheme(7)

v252

systemd.net-naming-scheme(7)

v253

systemd.net-naming-scheme(7)

v254

systemd.net-naming-scheme(7)

v255

systemd.net-naming-scheme(7)

var

repart.d(5), systemd.exec(5)

w

systemd.resource-control(5), tmpfiles.d(5)

warning

homectl(1), importctl(1), journalctl(1), localectl(1), loginctl(1), machinectl(1), portablectl(1), systemctl(1), systemd(1), systemd-analyze(1), systemd-inhibit(1), systemd-nspawn(1), systemd-tmpfiles(8), timedatectl(1), userdbctl(1)

wl

systemd.net-naming-scheme(7)

ww

systemd.net-naming-scheme(7)

x

systemd.net-naming-scheme(7)

x32

systemd.exec(5)

x86

repart.d(5), systemd-system.conf(5), systemd.dnssd(5), systemd.exec(5), systemd.link(5), systemd.unit(5), sysupdate.d(5), sysusers.d(5), tmpfiles.d(5)

x86-64

repart.d(5), systemd-system.conf(5), systemd.dnssd(5), systemd.exec(5), systemd.link(5), systemd.unit(5), sysupdate.d(5), sysusers.d(5), tmpfiles.d(5)

xbootldr

repart.d(5), systemd.exec(5), sysupdate.d(5)

yes

systemd.resource-control(5), systemd.service(5)

DNS RESOURCE RECORD TYPES

A

resolvectl(1)

AAAA

resolvectl(1)

CNAME

resolvectl(1)

DNAME

resolvectl(1)

DNSKEY

dnssec-trust-anchors.d(5)

DS

dnssec-trust-anchors.d(5)

MX

resolvectl(1)

OPENPGP

resolvectl(1)

OPENPGPKEY

resolvectl(1)

PTR

resolvectl(1)

SRV

org.freedesktop.resolve1(5), resolvectl(1), systemd.dnssd(5)

TLSA

resolvectl(1)

TXT

org.freedesktop.resolve1(5), resolvectl(1)

MISCELLANEOUS OPTIONS AND DIRECTIVES

Other configuration elements which dont fit in any of the above groups.

$LISTEN_FDS

systemd-journal-remote.service(8)

$SUDO_GID

run0(1)

$SUDO_UID

run0(1)

$SUDO_USER

run0(1)

$TERM

run0(1)

A

tmpfiles.d(5)

A+

tmpfiles.d(5)

C

tmpfiles.d(5)

C+

tmpfiles.d(5)

Cmdline=

ukify(1)

CopyBlocks=

repart.d(5)

CopyFiles=

repart.d(5)

CurrentSymlink=

sysupdate.d(5)

D

tmpfiles.d(5)

DefaultSubvolume=

repart.d(5)

DeviceTree=

ukify(1)

Encrypt=

repart.d(5)

EncryptedVolume=

repart.d(5)

ExcludeFiles=

repart.d(5)

ExcludeFilesTarget=

repart.d(5)

FactoryReset=

repart.d(5)

Flags=

repart.d(5)

Format=

repart.d(5)

GrowFileSystem=

repart.d(5)

H

tmpfiles.d(5)

ID_NET_LABEL_ONBOARD=

systemd.net-naming-scheme(7)

ID_NET_NAME_ALLOW=

systemd.net-naming-scheme(7)

ID_NET_NAME_ALLOW_sysfsattr=BOOL

systemd.net-naming-scheme(7)

ID_NET_NAME_MAC=

systemd.net-naming-scheme(7)

ID_NET_NAME_ONBOARD=

systemd.net-naming-scheme(7)

ID_NET_NAME_PATH=

systemd.net-naming-scheme(7)

ID_NET_NAME_SLOT=

systemd.net-naming-scheme(7)

Initrd=

ukify(1)

InstancesMax=

sysupdate.d(5)

L

tmpfiles.d(5)

L+

tmpfiles.d(5)

Label=

repart.d(5)

Linux=

ukify(1)

MakeDirectories=

repart.d(5)

MatchPartitionType=

sysupdate.d(5)

MatchPattern=

sysupdate.d(5)

Microcode=

ukify(1)

MinVersion=

sysupdate.d(5)

Minimize=

repart.d(5)

Mode=

sysupdate.d(5)

MountPoint=

repart.d(5)

NoAuto=

repart.d(5)

OSRelease=

ukify(1)

PCRBanks=

ukify(1)

PCRPKey=

ukify(1)

PCRPrivateKey=

ukify(1)

PCRPublicKey=

ukify(1)

PaddingMaxBytes=

repart.d(5)

PaddingMinBytes=

repart.d(5)

PaddingWeight=

repart.d(5)

PartitionFlags=

sysupdate.d(5)

PartitionGrowFileSystem=

sysupdate.d(5)

PartitionNoAuto=

sysupdate.d(5)

PartitionUUID=

sysupdate.d(5)

Path=

sysupdate.d(5)

PathRelativeTo=

sysupdate.d(5)

Phases=

ukify(1)

Priority=

repart.d(5)

ProtectVersion=

sysupdate.d(5)

Q

tmpfiles.d(5)

R

tmpfiles.d(5)

ReadOnly=

repart.d(5), sysupdate.d(5)

RemoveTemporary=

sysupdate.d(5)

SBAT=

ukify(1)

SecureBootCertificate=

ukify(1)

SecureBootCertificateDir=

ukify(1)

SecureBootCertificateName=

ukify(1)

SecureBootCertificateValidity=

ukify(1)

SecureBootPrivateKey=

ukify(1)

SecureBootSigningTool=

ukify(1)

SignKernel=

ukify(1)

SigningEngine=

ukify(1)

SizeMaxBytes=

repart.d(5)

SizeMinBytes=

repart.d(5)

Splash=

ukify(1)

SplitName=

repart.d(5)

Subvolumes=

repart.d(5)

T

tmpfiles.d(5)

TriesDone=

sysupdate.d(5)

TriesLeft=

sysupdate.d(5)

Type=

repart.d(5), sysupdate.d(5)

UUID=

repart.d(5)

Uname=

ukify(1)

Verify=

sysupdate.d(5)

Verity=

repart.d(5)

VerityDataBlockSizeBytes=

repart.d(5)

VerityHashBlockSizeBytes=

repart.d(5)

VerityMatchKey=

repart.d(5)

Weight=

repart.d(5)

X

tmpfiles.d(5)

Z

tmpfiles.d(5)

a

tmpfiles.d(5)

a+

tmpfiles.d(5)

b

tmpfiles.d(5)

b+

tmpfiles.d(5)

c

tmpfiles.d(5)

c+

tmpfiles.d(5)

d

tmpfiles.d(5)

e

tmpfiles.d(5)

equivalent

systemd-delta(1)

extended

systemd-delta(1)

f

tmpfiles.d(5)

f+

tmpfiles.d(5)

g

sysusers.d(5)

h

tmpfiles.d(5)

io.systemd.boot.kernel-cmdline-extra

systemd-boot(7)

io.systemd.stub.kernel-cmdline-extra

systemd-stub(7)

m

sysusers.d(5)

masked

systemd-delta(1)

overridden

systemd-delta(1)

p

tmpfiles.d(5)

p+

tmpfiles.d(5)

q

tmpfiles.d(5)

r

sysusers.d(5), tmpfiles.d(5)

redirected

systemd-delta(1)

t

tmpfiles.d(5)

u

sysusers.d(5)

udev.conf.*

udevadm(8)

udev.rules.*

udevadm(8)

unchanged

systemd-delta(1)

user.coredump.comm

systemd-coredump(8)

user.coredump.exe

systemd-coredump(8)

user.coredump.gid

systemd-coredump(8)

user.coredump.hostname

systemd-coredump(8)

user.coredump.pid

systemd-coredump(8)

user.coredump.rlimit

systemd-coredump(8)

user.coredump.signal

systemd-coredump(8)

user.coredump.timestamp

systemd-coredump(8)

user.coredump.uid

systemd-coredump(8)

v

tmpfiles.d(5)

w

tmpfiles.d(5)

w+

tmpfiles.d(5)

x

tmpfiles.d(5)

z

tmpfiles.d(5)

SPECIFIERS

Short strings which are substituted in configuration directives.

“%%”

repart.d(5), systemd-system.conf(5), systemd.automount(5), systemd.dnssd(5), systemd.mount(5), systemd.swap(5), systemd.unit(5), sysupdate.d(5), sysusers.d(5), tmpfiles.d(5)

“%A”

repart.d(5), systemd-system.conf(5), systemd.dnssd(5), systemd.link(5), systemd.unit(5), sysupdate.d(5), sysusers.d(5), tmpfiles.d(5)

“%B”

repart.d(5), systemd-system.conf(5), systemd.dnssd(5), systemd.link(5), systemd.unit(5), sysupdate.d(5), sysusers.d(5), tmpfiles.d(5)

“%C”

systemd.unit(5), tmpfiles.d(5)

“%D”

systemd.unit(5)

“%E”

systemd.unit(5)

“%G”

systemd-system.conf(5), systemd.unit(5), tmpfiles.d(5)

“%H”

repart.d(5), systemd-system.conf(5), systemd.dnssd(5), systemd.link(5), systemd.unit(5), sysupdate.d(5), sysusers.d(5), tmpfiles.d(5)

“%I”

systemd.unit(5)

“%J”

systemd.unit(5)

“%L”

systemd.unit(5), tmpfiles.d(5)

“%M”

repart.d(5), systemd-system.conf(5), systemd.dnssd(5), systemd.link(5), systemd.unit(5), sysupdate.d(5), sysusers.d(5), tmpfiles.d(5)

“%N”

systemd.unit(5)

“%P”

systemd.unit(5)

“%S”

systemd.unit(5), tmpfiles.d(5)

“%T”

repart.d(5), systemd-system.conf(5), systemd.link(5), systemd.unit(5), sysupdate.d(5), sysusers.d(5), tmpfiles.d(5)

“%U”

repart.d(5), systemd-system.conf(5), systemd.unit(5), tmpfiles.d(5)

“%V”

repart.d(5), systemd-system.conf(5), systemd.link(5), systemd.unit(5), sysupdate.d(5), sysusers.d(5), tmpfiles.d(5)

“%W”

repart.d(5), systemd-system.conf(5), systemd.dnssd(5), systemd.link(5), systemd.unit(5), sysupdate.d(5), sysusers.d(5), tmpfiles.d(5)

“%Y”

systemd.unit(5)

“%a”

repart.d(5), systemd-system.conf(5), systemd.dnssd(5), systemd.link(5), systemd.unit(5), sysupdate.d(5), sysusers.d(5), tmpfiles.d(5)

“%b”

repart.d(5), systemd-system.conf(5), systemd.dnssd(5), systemd.link(5), systemd.unit(5), sysupdate.d(5), sysusers.d(5), tmpfiles.d(5)

“%d”

systemd.unit(5)

“%f”

systemd.unit(5)

“%g”

systemd-system.conf(5), systemd.unit(5), tmpfiles.d(5)

“%h”

systemd-system.conf(5), systemd.unit(5), tmpfiles.d(5)

“%i”

systemd.unit(5)

“%j”

systemd.unit(5)

“%l”

repart.d(5), systemd-system.conf(5), systemd.link(5), systemd.unit(5), sysupdate.d(5), sysusers.d(5), tmpfiles.d(5)

“%m”

repart.d(5), systemd-system.conf(5), systemd.dnssd(5), systemd.link(5), systemd.unit(5), sysupdate.d(5), sysusers.d(5), tmpfiles.d(5)

“%n”

repart.d(5), systemd.unit(5)

“%o”

repart.d(5), systemd-system.conf(5), systemd.dnssd(5), systemd.link(5), systemd.unit(5), sysupdate.d(5), sysusers.d(5), tmpfiles.d(5)

“%p”

systemd.unit(5)

“%q”

systemd.link(5), systemd.unit(5)

“%s”

systemd-system.conf(5), systemd.unit(5)

“%t”

repart.d(5), systemd.unit(5), tmpfiles.d(5)

“%u”

systemd-system.conf(5), systemd.unit(5), tmpfiles.d(5)

“%v”

repart.d(5), systemd-system.conf(5), systemd.dnssd(5), systemd.link(5), systemd.unit(5), sysupdate.d(5), sysusers.d(5), tmpfiles.d(5)

“%w”

repart.d(5), systemd-system.conf(5), systemd.dnssd(5), systemd.link(5), systemd.unit(5), sysupdate.d(5), sysusers.d(5), tmpfiles.d(5)

“%y”

systemd.unit(5)

FILES AND DIRECTORIES

Paths and file names referred to in the documentation.

/

file-hierarchy(7), repart.d(5), systemd-gpt-auto-generator(8), systemd-nspawn(1), systemd-remount-fs.service(8), systemd-repart(8), systemd-stub(7), systemd.nspawn(5), systemd.special(7), systemd.unit(5), tmpfiles.d(5)

$XDG_CONFIG_DIRS/systemd/user/

systemd.unit(5)

$XDG_DATA_DIRS/systemd/user/

systemd.unit(5)

$XDG_DATA_HOME/systemd/user/

systemd.unit(5)

$XDG_RUNTIME_DIR/systemd/generator/

systemd.unit(5)

$XDG_RUNTIME_DIR/systemd/generator.early/

systemd.unit(5)

$XDG_RUNTIME_DIR/systemd/generator.late/

systemd.unit(5)

$XDG_RUNTIME_DIR/systemd/transient/

systemd.unit(5)

$XDG_RUNTIME_DIR/systemd/user/

systemd.unit(5)

$XDG_RUNTIME_DIR/systemd/user.control/

systemd.unit(5)

$XDG_RUNTIME_DIR/user-tmpfiles.d/*.conf

tmpfiles.d(5)

-.mount

systemd.special(7)

-.slice

systemd.special(7)

/.extra/confext/

systemd-stub(7)

/.extra/confext/*.confext.raw

systemd-stub(7)

/.extra/credentials/

systemd-stub(7)

/.extra/credentials/*.cred

systemd-stub(7)

/.extra/global_credentials/

systemd-stub(7)

/.extra/global_credentials/*.cred

systemd-stub(7)

/.extra/sysext/

systemd-stub(7), systemd-sysext(8)

/.extra/sysext/*.sysext.raw

systemd-stub(7)

/.extra/tpm2-pcr-pkey.pem

systemd-stub(7)

/.extra/tpm2-pcr-public-key.pem

systemd-stub(7)

/.extra/tpm2-pcr-signature.json

systemd-stub(7)

/EFI/Linux/

systemd-boot(7)

/EFI/systemd/drivers/

systemd-boot(7)

/SHA256SUMS

sysupdate.d(5)

/SHA256SUMS.gpg

sysupdate.d(5)

/bin/

file-hierarchy(7), org.freedesktop.systemd1(5), systemd-nspawn(1), systemd.service(5)

/bin/bash

homectl(1)

/bin/echo

systemd.service(5)

/bin/ls

systemd-cat(1)

/bin/sh

machinectl(1), run0(1), sysusers.d(5)

/boot/

bootctl(1), file-hierarchy(7), kernel-install(8), systemd-boot(7), systemd-gpt-auto-generator(8), systemd-nspawn(1), systemd.exec(5)

/boot/efi/

bootctl(1), kernel-install(8), systemd-boot(7)

/dev/

file-hierarchy(7), kernel-command-line(7), systemd(1), systemd-debug-generator(8), systemd-nspawn(1), systemd-remount-fs.service(8), systemd.device(5), systemd.exec(5), systemd.generator(7), systemd.journal-fields(7), systemd.resource-control(5), udev(7), udevadm(8)

/dev/block/

systemd.resource-control(5)

/dev/block/$major:$minor

systemd-gpt-auto-generator(8)

/dev/char/

systemd.resource-control(5)

/dev/console

journald.conf(5), systemd-getty-generator(8), systemd-nspawn(1), systemd-tty-ask-password-agent(1), systemd.exec(5)

/dev/disk/by-label/…

systemd-fstab-generator(8)

/dev/disk/by-loop-ref/…

systemd-dissect(1)

/dev/disk/by-uuid/…

systemd-fstab-generator(8)

/dev/full

systemd.resource-control(5)

/dev/hidraw1

crypttab(5), homectl(1), systemd-cryptenroll(1)

/dev/initctl

systemd(1), systemd-initctl.service(8)

/dev/kmsg

journald.conf(5), systemd-journald.service(8), systemd.exec(5), systemd.generator(7)

/dev/log

systemctl(1), systemd-journald.service(8)

/dev/loop-control

systemd.exec(5)

/dev/mapper/

crypttab(5), integritytab(5), repart.d(5), veritytab(5)

/dev/mapper/home

systemd-gpt-auto-generator(8)

/dev/mapper/root

systemd-fstab-generator(8), systemd-gpt-auto-generator(8)

/dev/mapper/srv

systemd-gpt-auto-generator(8)

/dev/mapper/swap

systemd-gpt-auto-generator(8)

/dev/mapper/tmp

systemd-gpt-auto-generator(8)

/dev/mapper/usr

systemd-fstab-generator(8)

/dev/mapper/var

systemd-gpt-auto-generator(8)

/dev/mem

systemd.exec(5)

/dev/net/tun

systemd.netdev(5)

/dev/null

binfmt.d(5), coredump.conf(5), daemon(7), dnssec-trust-anchors.d(5), environment.d(5), homed.conf(5), hwdb(7), iocost.conf(5), journal-remote.conf(5), journal-upload.conf(5), journald.conf(5), kernel-install(8), logind.conf(5), modules-load.d(5), networkctl(1), networkd.conf(5), oomd.conf(5), org.freedesktop.systemd1(5), pstore.conf(5), resolved.conf(5), sd_event_add_memory_pressure(3), sysctl.d(5), systemctl(1), systemd-sleep.conf(5), systemd-system.conf(5), systemd.environment-generator(7), systemd.exec(5), systemd.generator(7), systemd.link(5), systemd.netdev(5), systemd.network(5), systemd.preset(5), systemd.resource-control(5), systemd.unit(5), sysusers.d(5), timesyncd.conf(5), tmpfiles.d(5), udev(7)

/dev/nvme0n1

bootctl(1)

/dev/nvme0n1p5

bootctl(1)

/dev/port

systemd.exec(5)

/dev/random

systemd.exec(5), systemd.resource-control(5)

/dev/rtc0

systemd.exec(5)

/dev/rtc1

systemd.exec(5)

/dev/sda

systemd.exec(5)

/dev/sda5

systemd.resource-control(5)

/dev/shm/

file-hierarchy(7), systemd.exec(5)

/dev/tpmrm0

crypttab(5), systemd-creds(1), systemd-cryptenroll(1), systemd-measure(1), systemd-pcrphase.service(8), systemd.exec(5), systemd.special(7)

/dev/tty7

sd_device_get_syspath(3)

/dev/tty9

systemd-debug-generator(8)

/dev/urandom

crypttab(5), systemd-random-seed.service(8), systemd.resource-control(5)

/dev/watchdog0

systemd-system.conf(5)

/dev/zero

systemd.exec(5), systemd.resource-control(5)

/devices/virtual/tty/tty7

sd_device_get_syspath(3)

/efi/

bootctl(1), file-hierarchy(7), kernel-install(8), systemd-boot(7), systemd-gpt-auto-generator(8), systemd-nspawn(1), systemd.exec(5)

/etc/

binfmt.d(5), coredump.conf(5), environment.d(5), file-hierarchy(7), homed.conf(5), hwdb(7), iocost.conf(5), journal-remote.conf(5), journal-upload.conf(5), journald.conf(5), kernel-command-line(7), logind.conf(5), machine-id(5), machinectl(1), modules-load.d(5), networkctl(1), networkd.conf(5), nss-myhostname(8), oomd.conf(5), org.freedesktop.systemd1(5), os-release(5), portablectl(1), pstore.conf(5), resolved.conf(5), sysctl.d(5), systemctl(1), systemd-delta(1), systemd-firstboot(1), systemd-fstab-generator(8), systemd-machine-id-commit.service(8), systemd-machine-id-setup(1), systemd-modules-load.service(8), systemd-mountfsd.service(8), systemd-nspawn(1), systemd-sleep.conf(5), systemd-sysext(8), systemd-system.conf(5), systemd-sysusers(8), systemd-timedated.service(8), systemd-update-done.service(8), systemd-volatile-root.service(8), systemd.dnssd(5), systemd.environment-generator(7), systemd.exec(5), systemd.generator(7), systemd.link(5), systemd.mount(5), systemd.netdev(5), systemd.network(5), systemd.preset(5), systemd.unit(5), timesyncd.conf(5), tmpfiles.d(5), udev(7)

/etc/.updated

systemd-update-done.service(8)

/etc/adjtime

timedatectl(1)

/etc/binfmt.d/*.conf

binfmt.d(5)

/etc/credstore/

systemd.exec(5)

/etc/credstore.encrypted/

systemd.exec(5)

/etc/cryptsetup-keys.d/

crypttab(5), systemd-cryptsetup(8)

/etc/crypttab

crypttab(5), systemd-cryptenroll(1), systemd-cryptsetup(8), systemd-cryptsetup-generator(8), systemd-gpt-auto-generator(8), systemd-system.conf(5)

/etc/dnssec-trust-anchors.d/

dnssec-trust-anchors.d(5)

/etc/dnssec-trust-anchors.d/*.negative

dnssec-trust-anchors.d(5)

/etc/dnssec-trust-anchors.d/*.positive

dnssec-trust-anchors.d(5)

/etc/environment

environment.d(5)

/etc/environment.d/*.conf

environment.d(5)

/etc/extension-release.d/extension-release.IMAGE

os-release(5), systemd-sysext(8)

/etc/extension-release.d/extension-release.IMAGE

systemd.exec(5)

/etc/extensions/

systemd-sysext(8)

/etc/fstab

crypttab(5), kernel-command-line(7), org.freedesktop.systemd1(5), systemd(1), systemd-dissect(1), [email protected](8), systemd-fstab-generator(8), systemd-gpt-auto-generator(8), systemd-mount(1), systemd-pcrphase.service(8), systemd-remount-fs.service(8), systemd-system.conf(5), systemd.automount(5), systemd.generator(7), systemd.mount(5), systemd.special(7), systemd.swap(5)

/etc/group

nss-systemd(8), systemd-nspawn(1), systemd-tmpfiles(8), systemd.exec(5), sysusers.d(5), userdbctl(1)

/etc/gshadow

nss-systemd(8)

/etc/hostname

hostname(5), kernel-command-line(7), machine-info(5), org.freedesktop.hostname1(5), systemd-hostnamed.service(8), systemd.system-credentials(7)

/etc/hosts

nss-myhostname(8), nss-resolve(8), org.freedesktop.hostname1(5), org.freedesktop.resolve1(5), resolvectl(1), resolved.conf(5), systemd-resolved.service(8), systemd.system-credentials(7)

/etc/init.d/

systemd-sysv-generator(8)

/etc/initrd-release

bootup(7), os-release(5)

/etc/integritytab

integritytab(5), systemd-integritysetup-generator(8)

/etc/issue.d/50-provision.conf

systemd.system-credentials(7)

/etc/kernel/

ukify(1)

/etc/kernel/cmdline

kernel-install(8), systemd-firstboot(1)

/etc/kernel/devicetree

kernel-install(8)

/etc/kernel/entry-token

bootctl(1), kernel-install(8)

/etc/kernel/install.conf

kernel-install(8)

/etc/kernel/install.conf.d/*.conf

kernel-install(8)

/etc/kernel/install.d/

kernel-install(8)

/etc/kernel/install.d/*.install

kernel-install(8)

/etc/kernel/tries

kernel-install(8), systemd-boot(7)

/etc/kernel/uki.conf

kernel-install(8), ukify(1)

/etc/locale.conf

locale.conf(5), localectl(1), systemd(1)

/etc/localtime

localtime(5), systemd-nspawn(1), systemd.network(5), systemd.nspawn(5), timedatectl(1)

/etc/machine-id

kernel-install(8), machine-id(5), org.freedesktop.machine1(5), sd_bus_get_name_machine_id(3), sd_id128_get_machine(3), systemd(1), systemd-machine-id-commit.service(8), systemd-machine-id-setup(1), systemd-nspawn(1), systemd-pcrlock(8), systemd.pcrlock(5), systemd.unit(5)

/etc/machine-info

machine-info(5), org.freedesktop.hostname1(5), systemd-hostnamed.service(8), systemd.link(5), systemd.unit(5)

/etc/modules-load.d/program.conf

modules-load.d(5)

/etc/modules-load.d/*.conf

modules-load.d(5)

/etc/modules-load.d/bridge.conf

sysctl.d(5)

/etc/motd

systemd-repart(8)

/etc/motd.d/50-provision.conf

systemd.system-credentials(7)

/etc/nsswitch.conf

nss-myhostname(8), nss-mymachines(8), nss-resolve(8), nss-systemd(8)

/etc/os-release

kernel-install(8), os-release(5), repart.d(5), systemd-nspawn(1), systemd-system.conf(5), systemd-sysupdate(8), systemd.dnssd(5), systemd.link(5), systemd.unit(5), sysupdate.d(5), sysusers.d(5), tmpfiles.d(5)

/etc/pam.d/

pam_systemd_loadkey(8)

/etc/passwd

homectl(1), nss-systemd(8), systemd-firstboot(1), systemd-nspawn(1), systemd-tmpfiles(8), systemd.exec(5), sysusers.d(5), userdbctl(1)

/etc/pcrlock.d/

systemd-pcrlock(8)

/etc/pcrlock.d/*.pcrlock

systemd.pcrlock(5)

/etc/pcrlock.d/*.pcrlock.d/*.pcrlock

systemd.pcrlock(5)

/etc/pki/pesign

ukify(1)

/etc/portables/

portablectl(1)

/etc/rc.local

systemd-rc-local-generator(8)

/etc/repart.d/*.conf

repart.d(5), systemd-repart(8)

/etc/resolv.conf

org.freedesktop.resolve1(5), resolvectl(1), resolved.conf(5), systemd-nspawn(1), systemd-resolved.service(8), systemd.network(5), systemd.nspawn(5)

/etc/shadow

nss-systemd(8), systemd-firstboot(1)

/etc/skel/

homectl(1)

/etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf.in

systemd-ssh-proxy(1)

/etc/ssl/ca/trusted.pem

systemd-journal-remote.service(8), systemd-journal-upload.service(8)

/etc/ssl/certs/journal-remote.pem

systemd-journal-remote.service(8)

/etc/ssl/certs/journal-upload.pem

systemd-journal-upload.service(8)

/etc/ssl/private/journal-remote.pem

systemd-journal-remote.service(8)

/etc/ssl/private/journal-upload.pem

systemd-journal-upload.service(8)

/etc/sysctl.d/

systemd-soft-reboot.service(8)

/etc/sysctl.d/*.conf

sysctl.d(5)

/etc/sysctl.d/20-rp_filter.conf

sysctl.d(5)

/etc/sysctl.d/50-coredump.conf

systemd-sysctl.service(8)

/etc/sysctl.d/bridge.conf

sysctl.d(5)

/etc/sysctl.d/domain-name.conf

sysctl.d(5)

/etc/system-update

systemd-system-update-generator(8), systemd.offline-updates(7), systemd.special(7)

/etc/systemd/

coredump.conf(5), crypttab(5), homed.conf(5), iocost.conf(5), journal-remote.conf(5), journal-upload.conf(5), journald.conf(5), logind.conf(5), networkd.conf(5), oomd.conf(5), pstore.conf(5), resolved.conf(5), systemd-creds(1), systemd-cryptenroll(1), systemd-sleep.conf(5), systemd-system.conf(5), timesyncd.conf(5)

/etc/systemd/*.conf.d/

coredump.conf(5), homed.conf(5), iocost.conf(5), journal-remote.conf(5), journal-upload.conf(5), journald.conf(5), logind.conf(5), networkd.conf(5), oomd.conf(5), pstore.conf(5), resolved.conf(5), systemd-sleep.conf(5), systemd-system.conf(5), timesyncd.conf(5)

/etc/systemd/coredump.conf

coredump.conf(5), systemd-coredump(8)

/etc/systemd/coredump.conf.d/*.conf

coredump.conf(5), systemd-coredump(8)

/etc/systemd/dnssd

systemd.dnssd(5)

/etc/systemd/homed.conf

homed.conf(5)

/etc/systemd/homed.conf.d/*.conf

homed.conf(5)

/etc/systemd/import-pubring.gpg

importctl(1), sysupdate.d(5)

/etc/systemd/iocost.conf

iocost.conf(5)

/etc/systemd/iocost.conf.d/*.conf

iocost.conf(5)

/etc/systemd/journal-remote.conf

journal-remote.conf(5), systemd-journal-upload.service(8)

/etc/systemd/journal-remote.conf.d/*.conf

journal-remote.conf(5)

/etc/systemd/journal-upload.conf

journal-upload.conf(5), systemd-journal-upload.service(8)

/etc/systemd/journal-upload.conf.d/*.conf

journal-upload.conf(5)

/etc/systemd/journald.conf

journald.conf(5), systemd-journald.service(8)

/etc/systemd/journald.conf.d/*.conf

journald.conf(5)

/etc/systemd/journald@NAMESPACE.conf

journald.conf(5), systemd-journald.service(8)

/etc/systemd/logind.conf

logind.conf(5), systemd-analyze(1)

/etc/systemd/logind.conf.d/*.conf

logind.conf(5)

/etc/systemd/network

systemd-networkd.service(8), systemd.link(5), systemd.netdev(5), systemd.network(5)

/etc/systemd/network/*.network

systemd-resolved.service(8)

/etc/systemd/networkd.conf

networkd.conf(5)

/etc/systemd/networkd.conf.d/*.conf

networkd.conf(5)

/etc/systemd/nspawn/

machinectl(1), systemd-nspawn(1), systemd.nspawn(5)

/etc/systemd/oomd.conf

oomd.conf(5)

/etc/systemd/oomd.conf.d/*.conf

oomd.conf(5)

/etc/systemd/portable/profile/

portablectl(1)

/etc/systemd/pstore.conf

pstore.conf(5), systemd-pstore.service(8)

/etc/systemd/pstore.conf.d/*.conf

pstore.conf(5), systemd-pstore.service(8)

/etc/systemd/resolved.conf

org.freedesktop.resolve1(5), resolvectl(1), resolved.conf(5), systemd-resolved.service(8)

/etc/systemd/resolved.conf.d/*.conf

resolved.conf(5)

/etc/systemd/sleep.conf

systemd-sleep.conf(5), systemd-suspend.service(8)

/etc/systemd/sleep.conf.d/*.conf

systemd-sleep.conf(5)

/etc/systemd/system/

systemctl(1), systemd.unit(5)

/etc/systemd/system-environment-generators/

systemd.environment-generator(7)

/etc/systemd/system-generators/

systemd.generator(7)

/etc/systemd/system-preset/

systemd.preset(5)

/etc/systemd/system-preset/*.preset

systemd.preset(5)

/etc/systemd/system.attached

org.freedesktop.systemd1(5), portablectl(1), systemd.unit(5)

/etc/systemd/system.conf

org.freedesktop.systemd1(5), systemd-system.conf(5)

/etc/systemd/system.conf.d/*.conf

systemd-system.conf(5)

/etc/systemd/system.control/

systemd.unit(5)

/etc/systemd/system/ctrl-alt-del.service

systemd.unit(5)

/etc/systemd/system/httpd.service

systemd.unit(5)

/etc/systemd/system/httpd.service.d/local.conf

systemd.unit(5)

/etc/systemd/system/[email protected]/50-network.conf

systemd-nspawn(1)

/etc/systemd/timesyncd.conf

timesyncd.conf(5)

/etc/systemd/timesyncd.conf.d/*.conf

timesyncd.conf(5)

/etc/systemd/ukify.conf

ukify(1)

/etc/systemd/user/

systemd.unit(5)

/etc/systemd/user-environment-generators/

systemd.environment-generator(7)

/etc/systemd/user-generators/

systemd.generator(7)

/etc/systemd/user-preset/*.preset

systemd.preset(5)

/etc/systemd/user.conf

systemd-system.conf(5)

/etc/systemd/user.conf.d/*.conf

systemd-system.conf(5)

/etc/sysupdate.component.d/*.conf

systemd-sysupdate(8)

/etc/sysupdate.*.d/

systemd-sysupdate(8)

/etc/sysupdate.d/*.conf

systemd-sysupdate(8), sysupdate.d(5)

/etc/sysusers.d

sysusers.d(5)

/etc/sysusers.d/*.conf

sysusers.d(5)

/etc/sysusers.d/00-overrides.conf

systemd-sysusers(8)

/etc/sysusers.d/radvd.conf

systemd-sysusers(8)

/etc/tmpfiles.d

tmpfiles.d(5)

/etc/tmpfiles.d/*.conf

tmpfiles.d(5)

/etc/udev/hwdb.bin

hwdb(7)

/etc/udev/hwdb.d

hwdb(7)

/etc/udev/hwdb.d/50-net-naming-allowlist.hwdb

systemd.net-naming-scheme(7)

/etc/udev/hwdb.d/50-net-naming-denylist.hwdb

systemd.net-naming-scheme(7)

/etc/udev/rules.d

udev(7)

/etc/udev/rules.d/99-bridge.rules

sysctl.d(5)

/etc/udev/udev.conf

udev.conf(5)

/etc/udev/udev.conf.d/*.conf

udev.conf(5)

/etc/userdb/

nss-systemd(8), systemd-userdbd.service(8), userdbctl(1)

/etc/vconsole.conf

localectl(1), systemd-firstboot(1)

/etc/verity.d/

kernel-command-line(7), systemd-mountfsd.service(8)

/etc/veritytab

veritytab(5)

/etc/xdg

systemd.unit(5)

/etc/xdg/systemd/user

systemd.unit(5)

/etc/xdg/user-dirs.conf

sd_path_lookup(3)

/home/

[email protected](5), file-hierarchy(7), homectl(1), homed.conf(5), repart.d(5), systemctl(1), systemd-gpt-auto-generator(8), systemd-repart(8), systemd.exec(5), systemd.generator(7), systemd.image-policy(7), systemd.unit(5), tmpfiles.d(5)

/home/$USER

homectl(1)

/home/$USER.home

homectl(1)

/home/$USER.homedir

homectl(1)

/home/*.home

homectl(1)

/home/*.homedir

homectl(1)

/home/lennart

systemd.automount(5)

/lib/

file-hierarchy(7), org.freedesktop.systemd1(5), systemd-nspawn(1)

/lib64/

file-hierarchy(7)

/loader/addons/*.addon.efi

systemd-stub(7)

/loader/credentials/

systemd-pcrlock(8), systemd-stub(7)

/loader/credentials/*.cred

systemd-stub(7)

/loader/entries/

systemd-boot(7)

/loader/keys/NAME

loader.conf(5), systemd-boot(7)

/loader/loader.conf

systemd-boot(7)

/loader/random-seed

systemd-boot(7)

/log/

systemd.exec(5)

/mysql-password

systemd-creds(1)

/opt/

systemd-sysext(8), systemd.exec(5), systemd.image-policy(7)

/org/freedesktop/LogControl1

org.freedesktop.LogControl1(5)

/proc/

busctl(1), file-hierarchy(7), sd-login(3), sd_bus_creds_get_pid(3), sd_bus_creds_new_from_pid(3), sd_event_add_inotify(3), sd_id128_get_machine(3), sd_is_fifo(3), sd_pid_get_owner_uid(3), systemctl(1), systemd(1), systemd-coredump(8), systemd-remount-fs.service(8), systemd.exec(5), systemd.generator(7), systemd.socket(5), tmpfiles.d(5)

/proc/$PID/ns/ipc

systemd.exec(5)

/proc/$PID/ns/net

systemd-nspawn(1), systemd.exec(5)

/proc/1/cmdline

systemd.unit(5)

/proc/acpi

systemd.exec(5)

/proc/cmdline

kernel-command-line(7), kernel-install(8), systemd(1), systemd-pcrlock(8), systemd.unit(5)

/proc/crypto

homectl(1)

/proc/devices

systemd.resource-control(5)

/proc/fs

systemd.exec(5)

/proc/irq

systemd.exec(5)

/proc/kallsyms

systemd.exec(5)

/proc/kcore

systemd.exec(5)

/proc/kmsg

systemd.exec(5)

/proc/latency_stats

systemd.exec(5)

/proc/pressure/memory

sd_event_add_memory_pressure(3)

/proc/self/cgroup

systemd-coredump(8)

/proc/self/fd

daemon(7)

/proc/self/mountinfo

systemd.mount(5)

/proc/self/oom_score_adj

systemd-nspawn(1)

/proc/self/sessionid

pam_systemd(8)

/proc/sys/

file-hierarchy(7), systemd-nspawn(1), systemd-soft-reboot.service(8), systemd-sysctl.service(8), systemd.exec(5)

/proc/sys/kernel/core_pattern

systemd-sysctl.service(8)

/proc/sys/kernel/domainname

sysctl.d(5)

/proc/sys/kernel/hostname

org.freedesktop.hostname1(5)

/proc/sys/kernel/modules_disabled

systemd.exec(5)

/proc/sys/kernel/random/boot_id

org.freedesktop.hostname1(5), sd_id128_get_machine(3)

/proc/sys/net/ipv4/conf/enp3s0.200/forwarding

sysctl.d(5)

/proc/sys/net/ipv4/ip_default_ttl

systemd.netdev(5)

/proc/sys/net/ipv4/tcp_keepalive_time

systemd.socket(5)

/proc/sys/net/ipv6/bindv6only

systemd.socket(5)

/proc/sysrq-trigger

systemd.exec(5)

/proc/timer_stats

systemd.exec(5)

/root/

file-hierarchy(7), systemd.exec(5)

/root/.ssh/authorized_keys

systemd.system-credentials(7), tmpfiles.d(5)

/run/

binfmt.d(5), coredump.conf(5), crypttab(5), environment.d(5), file-hierarchy(7), homed.conf(5), iocost.conf(5), journal-remote.conf(5), journal-upload.conf(5), journald.conf(5), logind.conf(5), modules-load.d(5), networkctl(1), networkd.conf(5), oomd.conf(5), org.freedesktop.systemd1(5), pstore.conf(5), resolved.conf(5), sd-login(3), sd_notify(3), sysctl.d(5), systemctl(1), systemd-delta(1), systemd-journald.service(8), systemd-modules-load.service(8), systemd-mountfsd.service(8), systemd-nspawn(1), systemd-poweroff.service(8), systemd-sleep.conf(5), systemd-soft-reboot.service(8), systemd-system.conf(5), systemd-timedated.service(8), systemd.dnssd(5), systemd.environment-generator(7), systemd.exec(5), systemd.generator(7), systemd.link(5), systemd.netdev(5), systemd.network(5), systemd.preset(5), systemd.service(5), systemd.unit(5), timesyncd.conf(5), tmpfiles.d(5), udev(7)

/run/binfmt.d/*.conf

binfmt.d(5)

/run/capsules/NAME/

[email protected](5)

/run/confexts/

systemd-sysext(8)

/run/credentials/@initrd/

systemd(1)

/run/credstore/

systemd.exec(5)

/run/credstore.encrypted/

systemd.exec(5)

/run/cryptsetup-keys.d/

crypttab(5), systemd-cryptsetup(8)

/run/dnssec-trust-anchors.d/

dnssec-trust-anchors.d(5)

/run/dnssec-trust-anchors.d/*.negative

dnssec-trust-anchors.d(5)

/run/dnssec-trust-anchors.d/*.positive

dnssec-trust-anchors.d(5)

/run/environment.d/*.conf

environment.d(5)

/run/extensions/

systemd-sysext(8)

/run/host/home/

systemd-nspawn(1)

/run/host/incoming/

systemd.exec(5)

/run/host/os-release

os-release(5), systemd.exec(5)

/run/host/unix-export/

systemd-ssh-generator(8)

/run/host/unix-export/ssh

systemd-ssh-generator(8)

/run/host/userdb/

nss-systemd(8), systemd-userdbd.service(8), userdbctl(1)

/run/kernel/install.conf

kernel-install(8)

/run/kernel/install.conf.d/*.conf

kernel-install(8)

/run/log/

file-hierarchy(7), sd_journal_get_seqnum(3)

/run/log/journal/

journalctl(1), journald.conf(5), sd_journal_open(3), systemd-journald.service(8)

/run/log/systemd/tpm2-measure.log

systemd-pcrlock(8), systemd-pcrphase.service(8)

/run/machine-id

systemd-machine-id-setup(1)

/run/media/system/

systemd-mount(1)

/run/modules-load.d/*.conf

modules-load.d(5)

/run/netns

systemd-nspawn(1)

/run/nextroot/

org.freedesktop.systemd1(5), systemd-soft-reboot.service(8)

/run/nologin

shutdown(8), systemd-user-sessions.service(8)

/run/pcrlock.d/

systemd-pcrlock(8)

/run/pcrlock.d/*.pcrlock

systemd.pcrlock(5)

/run/pcrlock.d/*.pcrlock.d/*.pcrlock

systemd.pcrlock(5)

/run/portables/

portablectl(1)

/run/repart.d/*.conf

repart.d(5), systemd-repart(8)

/run/screens

tmpfiles.d(5)

/run/ssh-unix-local/socket

systemd-ssh-generator(8)

/run/sysctl.d/*.conf

sysctl.d(5)

/run/sysctl.d/50-coredump.conf

systemd-sysctl.service(8)

/run/system/nspawn/

systemd.nspawn(5)

/run/systemd/

coredump.conf(5), crypttab(5), homed.conf(5), iocost.conf(5), journal-remote.conf(5), journal-upload.conf(5), journald.conf(5), logind.conf(5), networkd.conf(5), oomd.conf(5), pstore.conf(5), resolved.conf(5), systemd-creds(1), systemd-cryptenroll(1), systemd-sleep.conf(5), systemd-system.conf(5), timesyncd.conf(5)

/run/systemd/coredump.conf

coredump.conf(5)

/run/systemd/coredump.conf.d/*.conf

coredump.conf(5)

/run/systemd/dnssd

systemd.dnssd(5)

/run/systemd/generator

systemd.generator(7), systemd.unit(5)

/run/systemd/generator.early

systemd.generator(7), systemd.unit(5)

/run/systemd/generator.late

systemd.generator(7), systemd.unit(5)

/run/systemd/homed.conf

homed.conf(5)

/run/systemd/homed.conf.d/*.conf

homed.conf(5)

/run/systemd/journal-remote.conf

journal-remote.conf(5)

/run/systemd/journal-remote.conf.d/*.conf

journal-remote.conf(5)

/run/systemd/journal-upload.conf

journal-upload.conf(5)

/run/systemd/journal-upload.conf.d/*.conf

journal-upload.conf(5)

/run/systemd/journal/dev-log

systemd-journald.service(8)

/run/systemd/journal/socket

systemd-journald.service(8)

/run/systemd/journal/stdout

systemd-journald.service(8)

/run/systemd/journal/syslog

journald.conf(5)

/run/systemd/journald.conf

journald.conf(5)

/run/systemd/journald.conf.d/*.conf

journald.conf(5)

/run/systemd/journald@NAMESPACE.conf.d/*.conf

journald.conf(5)

/run/systemd/logind.conf

logind.conf(5)

/run/systemd/logind.conf.d/*.conf

logind.conf(5)

/run/systemd/network/

systemd-network-generator.service(8), systemd-networkd.service(8), systemd.link(5), systemd.netdev(5), systemd.network(5)

/run/systemd/networkd.conf

networkd.conf(5)

/run/systemd/networkd.conf.d/*.conf

networkd.conf(5)

/run/systemd/notify

systemd(1)

/run/systemd/nspawn/

systemd-nspawn(1), systemd.nspawn(5)

/run/systemd/oomd.conf

oomd.conf(5)

/run/systemd/oomd.conf.d/*.conf

oomd.conf(5)

/run/systemd/portables/

portablectl(1)

/run/systemd/private

systemd(1)

/run/systemd/propagate/

systemd.exec(5)

/run/systemd/pstore.conf

pstore.conf(5)

/run/systemd/pstore.conf.d/*.conf

pstore.conf(5)

/run/systemd/resolve/io.systemd.Resolve

nss-resolve(8), systemd-resolved.service(8)

/run/systemd/resolve/resolv.conf

org.freedesktop.resolve1(5), resolvectl(1), systemd-nspawn(1), systemd-resolved.service(8)

/run/systemd/resolve/stub-resolv.conf

systemd-nspawn(1), systemd-resolved.service(8)

/run/systemd/resolved.conf

resolved.conf(5)

/run/systemd/resolved.conf.d/*.conf

resolved.conf(5)

/run/systemd/sleep.conf

systemd-sleep.conf(5)

/run/systemd/sleep.conf.d/*.conf

systemd-sleep.conf(5)

/run/systemd/system/

sd_booted(3), systemctl(1), systemd.unit(5)

/run/systemd/system-environment-generators/

systemd.environment-generator(7)

/run/systemd/system-generators/

systemd.generator(7)

/run/systemd/system-preset/*.preset

systemd.preset(5)

/run/systemd/system.attached

org.freedesktop.systemd1(5), portablectl(1), systemd.unit(5)

/run/systemd/system.conf

systemd-system.conf(5)

/run/systemd/system.conf.d/*.conf

systemd-system.conf(5)

/run/systemd/system.control/

systemd.unit(5)

/run/systemd/systemd/

systemctl(1)

/run/systemd/timesync/synchronized

systemd-time-wait-sync.service(8), systemd-timesyncd.service(8)

/run/systemd/timesyncd.conf

timesyncd.conf(5)

/run/systemd/timesyncd.conf.d/*.conf

timesyncd.conf(5)

/run/systemd/tpm2-pcr-public-key.pem

systemd-stub(7)

/run/systemd/tpm2-pcr-signature.json

systemd-stub(7)

/run/systemd/tpm2-srk-public-key.

systemd-tpm2-setup.service(8)

/run/systemd/tpm2-srk-public-key.pem

systemd-tpm2-setup.service(8)

/run/systemd/tpm2-srk-public-key.tpm2_public

systemd-tpm2-setup.service(8)

/run/systemd/tpm2-srk-public-key.tpm2b_public

systemd-cryptenroll(1), systemd-tpm2-setup.service(8)

/run/systemd/transient/

systemd.unit(5)

/run/systemd/ukify.conf

ukify(1)

/run/systemd/user/

systemd.unit(5)

/run/systemd/user-environment-generators/

systemd.environment-generator(7)

/run/systemd/user-generators/

systemd.generator(7)

/run/systemd/user-preset/*.preset

systemd.preset(5)

/run/systemd/user.conf

systemd-system.conf(5)

/run/systemd/user.conf.d/*.conf

systemd-system.conf(5)

/run/systemd/volatile-root

systemd-gpt-auto-generator(8)

/run/sysupdate.component.d/*.conf

systemd-sysupdate(8)

/run/sysupdate.*.d/

systemd-sysupdate(8)

/run/sysupdate.d/*.conf

systemd-sysupdate(8), sysupdate.d(5)

/run/sysusers.d

sysusers.d(5)

/run/sysusers.d/*.conf

sysusers.d(5)

/run/tmpfiles.d

tmpfiles.d(5)

/run/tmpfiles.d/*.conf

tmpfiles.d(5)

/run/udev/rules.d

udev(7)

/run/udev/rules.d/50-foobar.rules

systemd.system-credentials(7), udevadm(8)

/run/udev/static_node-tags/tag

udev(7)

/run/udev/udev.conf

udev.conf(5)

/run/udev/udev.conf.d/*.conf

udev.conf(5)

/run/udev/udev.conf.d/50-foobar.conf

systemd.system-credentials(7), udevadm(8)

/run/user/

file-hierarchy(7), systemd.exec(5), [email protected](5)

/run/user/$UID

pam_systemd(8)

/run/userdb/

nss-systemd(8), systemd-nspawn(1), systemd-userdbd.service(8), userdbctl(1)

/run/utmp

runlevel(8)

/sbin/

file-hierarchy(7), org.freedesktop.systemd1(5)

/sbin/init

systemd(1)

/sbin/mkfs.type

[email protected](8)

/sbin/mkswap

[email protected](8)

/sbin/mount.ddi

systemd-dissect(1)

/srv/

file-hierarchy(7), repart.d(5), systemd-gpt-auto-generator(8), systemd-repart(8), systemd.image-policy(7)

/srv/webserver

systemd.unit(5)

/srv/www

systemd.unit(5)

/sys/

file-hierarchy(7), loginctl(1), org.freedesktop.login1(5), sd_device_get_syspath(3), sd_is_fifo(3), systemd(1), systemd-nspawn(1), systemd-remount-fs.service(8), systemd-soft-reboot.service(8), systemd-tmpfiles(8), systemd.device(5), systemd.exec(5), systemd.generator(7), systemd.journal-fields(7), systemd.socket(5), tmpfiles.d(5), udev_device_new_from_syspath(3), udevadm(8)

/sys/bus/pci/devices/0000:00:1f.6

sd_device_get_syspath(3)

/sys/class/subsystem/name/max_brightness

org.freedesktop.login1(5)

/sys/class/block/loopX/loop/backing_file

systemd-dissect(1)

/sys/class/dmi/id/

systemd.unit(5)

/sys/class/dmi/id/product_uuid

org.freedesktop.hostname1(5)

/sys/class/watchdog/watchdogX/pretimeout_available_governors

systemd-system.conf(5)

/sys/devices

udev_device_new_from_syspath(3)

/sys/devices/virtual/tty/tty7

sd_device_get_syspath(3)

/sys/firmware/dmi/entries/11-*/raw

smbios-type-11(7)

/sys/fs/bpf/

systemd.resource-control(5)

/sys/fs/cgroup/

file-hierarchy(7), sd-login(3), sd_pid_get_owner_uid(3), systemd(1), systemd-cgls(1), systemd.exec(5)

/sys/fs/cgroup/io.cost.

iocost.conf(5)

/sys/fs/cgroup/systemd

org.freedesktop.systemd1(5)

/sys/fs/cgroup/unified/

file-hierarchy(7)

/sys/fs/pstore/

systemd-pstore.service(8)

/sys/fs/selinux/

systemd-nspawn(1)

/sys/kernel/security/tpm0/binary_bios_measurements

systemd-pcrlock(8)

/sys/module/kernel/parameters/crash_kexec_post_notifiers

systemd-pstore.service(8)

/sys/module/printk/parameters/always_kmsg_dump

systemd-pstore.service(8)

/sys/power/disk

systemd-sleep.conf(5)

/sys/power/mem_sleep

systemd-sleep.conf(5)

/sys/power/resume

systemd-hibernate-resume.service(8)

/sys/power/resume_offset

systemd-hibernate-resume.service(8)

/sys/power/state

systemd-sleep.conf(5), systemd-suspend.service(8)

/sysroot

bootup(7), systemctl(1), systemd-fstab-generator(8), systemd-gpt-auto-generator(8), systemd-repart(8), systemd.special(7)

/sysroot/etc/fstab

bootup(7)

/system-update

systemd-system-update-generator(8), systemd.offline-updates(7), systemd.special(7)

/sysusr/

systemd.special(7)

/tmp/

crypttab(5), file-hierarchy(7), repart.d(5), systemd-sysext(8), systemd-system.conf(5), systemd-tmpfiles(8), systemd.exec(5), systemd.link(5), systemd.special(7), systemd.unit(5), sysupdate.d(5), sysusers.d(5), tmpfiles.d(5)

/upload

systemd-journal-remote.service(8)

/user.slice/user-1000.slice/[email protected]/

systemd.resource-control(5)

/usr/

binfmt.d(5), bootctl(1), bootup(7), coredump.conf(5), environment.d(5), file-hierarchy(7), homed.conf(5), iocost.conf(5), journal-remote.conf(5), journal-upload.conf(5), journald.conf(5), kernel-command-line(7), logind.conf(5), machinectl(1), modules-load.d(5), networkd.conf(5), oomd.conf(5), org.freedesktop.systemd1(5), portablectl(1), pstore.conf(5), repart.d(5), resolved.conf(5), sysctl.d(5), systemctl(1), systemd-dissect(1), systemd-fstab-generator(8), systemd-modules-load.service(8), systemd-nspawn(1), systemd-remount-fs.service(8), systemd-sleep.conf(5), systemd-sysext(8), systemd-system.conf(5), systemd-timedated.service(8), systemd-update-done.service(8), systemd-veritysetup-generator(8), systemd-volatile-root.service(8), systemd.exec(5), systemd.generator(7), systemd.image-policy(7), systemd.mount(5), systemd.network(5), systemd.special(7), systemd.unit(5), timesyncd.conf(5), udev(7)

/usr/bin/

file-hierarchy(7), org.freedesktop.systemd1(5), systemd.exec(5), systemd.service(5)

/usr/bin/mount

org.freedesktop.systemd1(5), systemctl(1)

/usr/bin/umount

org.freedesktop.systemd1(5), systemctl(1)

/usr/foo

systemd-repart(8)

/usr/include/

file-hierarchy(7)

/usr/include/stdlib.h

systemd-tmpfiles(8)

/usr/include/sysexits.h

systemd-tmpfiles(8)

/usr/lib/

binfmt.d(5), environment.d(5), file-hierarchy(7), hwdb(7), modules-load.d(5), sysctl.d(5), systemd-delta(1), systemd-mountfsd.service(8), systemd-timedated.service(8), systemd.dnssd(5), systemd.link(5), systemd.netdev(5), systemd.network(5), systemd.preset(5), systemd.unit(5), udev(7)

/usr/lib/binfmt.d/*.conf

binfmt.d(5)

/usr/lib/clock-epoch

systemd-timesyncd.service(8)

/usr/lib/confexts/

systemd-dissect(1), systemd-sysext(8)

/usr/lib/credstore/

systemd.exec(5)

/usr/lib/credstore.encrypted/

systemd.exec(5)

/usr/lib/dnssec-trust-anchors.d/

dnssec-trust-anchors.d(5)

/usr/lib/dnssec-trust-anchors.d/*.negative

dnssec-trust-anchors.d(5)

/usr/lib/dnssec-trust-anchors.d/*.positive

dnssec-trust-anchors.d(5)

/usr/lib/environment.d/*.conf

environment.d(5)

/usr/lib/extension-release.d/extension-release.IMAGE

os-release(5), systemd-sysext(8)

/usr/lib/extension-release.d/extension-release.IMAGE

systemd.exec(5)

/usr/lib/kernel/cmdline

kernel-install(8)

/usr/lib/kernel/devicetree

kernel-install(8)

/usr/lib/kernel/install.conf

kernel-install(8)

/usr/lib/kernel/install.conf.d/*.conf

kernel-install(8)

/usr/lib/kernel/install.d/

kernel-install(8)

/usr/lib/kernel/install.d/*.install

kernel-install(8)

/usr/lib/machines/

machinectl(1), systemd-dissect(1)

/usr/lib/modules/KERNEL_VERSION/vmlinuz

kernel-install(8), systemd.exec(5)

/usr/lib/modules-load.d/*.conf

modules-load.d(5)

/usr/lib/os-release

kernel-install(8), os-release(5), systemd-nspawn(1), systemd-sysext(8)

/usr/lib/pcrlock.d/

systemd-pcrlock(8)

/usr/lib/pcrlock.d/*.pcrlock

systemd.pcrlock(5)

/usr/lib/pcrlock.d/*.pcrlock.d/*.pcrlock

systemd.pcrlock(5)

/usr/lib/portables/

portablectl(1), systemd-dissect(1)

/usr/lib/repart.d/*.conf

repart.d(5), systemd-repart(8)

/usr/lib/sysctl.d/*.conf

sysctl.d(5)

/usr/lib/sysctl.d/50-coredump.conf

systemd-coredump(8), systemd-sysctl.service(8)

/usr/lib/systemd/

coredump.conf(5), crypttab(5), homed.conf(5), iocost.conf(5), journal-remote.conf(5), journal-upload.conf(5), journald.conf(5), logind.conf(5), networkd.conf(5), oomd.conf(5), pstore.conf(5), resolved.conf(5), systemd-creds(1), systemd-cryptenroll(1), systemd-sleep.conf(5), systemd-system.conf(5), timesyncd.conf(5)

/usr/lib/systemd/*.conf.d/

coredump.conf(5), homed.conf(5), iocost.conf(5), journal-remote.conf(5), journal-upload.conf(5), journald.conf(5), logind.conf(5), networkd.conf(5), oomd.conf(5), pstore.conf(5), resolved.conf(5), systemd-sleep.conf(5), systemd-system.conf(5), timesyncd.conf(5)

/usr/lib/systemd/boot/efi/linuxaa64.efi.stub

systemd-stub(7)

/usr/lib/systemd/boot/efi/linuxia32.efi.stub

systemd-stub(7)

/usr/lib/systemd/boot/efi/linuxx64.efi.stub

systemd-stub(7)

/usr/lib/systemd/coredump.conf

coredump.conf(5)

/usr/lib/systemd/coredump.conf.d/*.conf

coredump.conf(5)

/usr/lib/systemd/dnssd

systemd.dnssd(5)

/usr/lib/systemd/homed.conf

homed.conf(5)

/usr/lib/systemd/homed.conf.d/*.conf

homed.conf(5)

/usr/lib/systemd/import-pubring.gpg

importctl(1), sysupdate.d(5)

/usr/lib/systemd/journal-remote.conf

journal-remote.conf(5)

/usr/lib/systemd/journal-remote.conf.d/*.conf

journal-remote.conf(5)

/usr/lib/systemd/journal-upload.conf

journal-upload.conf(5)

/usr/lib/systemd/journal-upload.conf.d/*.conf

journal-upload.conf(5)

/usr/lib/systemd/journald.conf

journald.conf(5)

/usr/lib/systemd/journald.conf.d/*.conf

journald.conf(5)

/usr/lib/systemd/journald@NAMESPACE.conf.d/*.conf

journald.conf(5)

/usr/lib/systemd/logind.conf

logind.conf(5), systemd-analyze(1)

/usr/lib/systemd/logind.conf.d/*.conf

logind.conf(5)

/usr/lib/systemd/network

systemd-networkd.service(8), systemd.link(5), systemd.netdev(5), systemd.network(5)

/usr/lib/systemd/network/80-container-host0.network

systemd-nspawn(1)

/usr/lib/systemd/network/80-container-ve.network

systemd-nspawn(1)

/usr/lib/systemd/network/80-container-vz.network

systemd-nspawn(1)

/usr/lib/systemd/networkd.conf

networkd.conf(5)

/usr/lib/systemd/networkd.conf.d/*.conf

networkd.conf(5)

/usr/lib/systemd/ntp-units.d/

systemd-timedated.service(8)

/usr/lib/systemd/oomd.conf

oomd.conf(5)

/usr/lib/systemd/oomd.conf.d/*.conf

oomd.conf(5)

/usr/lib/systemd/portable/profile/

portablectl(1)

/usr/lib/systemd/portable/profile/default/service.conf

portablectl(1)

/usr/lib/systemd/pstore.conf

pstore.conf(5)

/usr/lib/systemd/pstore.conf.d/*.conf

pstore.conf(5)

/usr/lib/systemd/resolv.conf

systemd-nspawn(1), systemd-resolved.service(8)

/usr/lib/systemd/resolved.conf

resolved.conf(5)

/usr/lib/systemd/resolved.conf.d/*.conf

resolved.conf(5)

/usr/lib/systemd/sleep.conf

systemd-sleep.conf(5)

/usr/lib/systemd/sleep.conf.d/*.conf

systemd-sleep.conf(5)

/usr/lib/systemd/system/

systemctl(1), systemd(1), systemd.unit(5)

/usr/lib/systemd/system-boot-check-no-failures

systemd-boot-check-no-failures.service(8)

/usr/lib/systemd/system-environment-generators/

systemd.environment-generator(7)

/usr/lib/systemd/system-environment-generators/some-generator

systemd.environment-generator(7)

/usr/lib/systemd/system-generators/

systemd.generator(7)

/usr/lib/systemd/system-generators/systemd-bless-boot-generator

systemd-bless-boot-generator(8)

/usr/lib/systemd/system-generators/systemd-cryptsetup-generator

systemd-cryptsetup-generator(8)

/usr/lib/systemd/system-generators/systemd-debug-generator

systemd-debug-generator(8)

/usr/lib/systemd/system-generators/systemd-fstab-generator

systemd-fstab-generator(8)

/usr/lib/systemd/system-generators/systemd-getty-generator

systemd-getty-generator(8)

/usr/lib/systemd/system-generators/systemd-gpt-auto-generator

systemd-gpt-auto-generator(8)

/usr/lib/systemd/system-generators/systemd-hibernate-resume-generator

systemd-hibernate-resume-generator(8)

/usr/lib/systemd/system-generators/systemd-integritysetup-generator

systemd-integritysetup-generator(8)

/usr/lib/systemd/system-generators/systemd-rc-local-generator

systemd-rc-local-generator(8)

/usr/lib/systemd/system-generators/systemd-run-generator

systemd-run-generator(8)

/usr/lib/systemd/system-generators/systemd-ssh-generator

systemd-ssh-generator(8)

/usr/lib/systemd/system-generators/systemd-system-update-generator

systemd-system-update-generator(8)

/usr/lib/systemd/system-generators/systemd-sysv-generator

systemd-sysv-generator(8)

/usr/lib/systemd/system-generators/systemd-tpm2-generator

systemd-tpm2-generator(8)

/usr/lib/systemd/system-generators/systemd-veritysetup-generator

systemd-veritysetup-generator(8)

/usr/lib/systemd/system-pcrextend

systemd-pcrphase.service(8)

/usr/lib/systemd/system-preset/*.preset

systemd.preset(5)

/usr/lib/systemd/system-shutdown/

systemd-poweroff.service(8), systemd-soft-reboot.service(8)

/usr/lib/systemd/system-sleep

systemd-suspend.service(8)

/usr/lib/systemd/system.conf

systemd-system.conf(5)

/usr/lib/systemd/system.conf.d/*.conf

systemd-system.conf(5)

/usr/lib/systemd/system/httpd.service

systemd.unit(5)

/usr/lib/systemd/systemd

systemd(1)

/usr/lib/systemd/systemd-backlight

[email protected](8)

/usr/lib/systemd/systemd-battery-check

systemd-battery-check.service(8)

/usr/lib/systemd/systemd-binfmt

systemd-binfmt.service(8)

/usr/lib/systemd/systemd-bless-boot

systemd-bless-boot.service(8)

/usr/lib/systemd/systemd-bsod

systemd-bsod.service(8)

/usr/lib/systemd/systemd-coredump

systemd-coredump(8)

/usr/lib/systemd/systemd-fsck

[email protected](8)

/usr/lib/systemd/systemd-growfs

[email protected](8)

/usr/lib/systemd/systemd-hibernate-resume

systemd-hibernate-resume.service(8)

/usr/lib/systemd/systemd-homed

systemd-homed.service(8)

/usr/lib/systemd/systemd-hostnamed

systemd-hostnamed.service(8)

/usr/lib/systemd/systemd-importd

systemd-importd.service(8)

/usr/lib/systemd/systemd-initctl

systemd-initctl.service(8)

/usr/lib/systemd/systemd-integritysetup

[email protected](8)

/usr/lib/systemd/systemd-journal-gatewayd

systemd-journal-gatewayd.service(8)

/usr/lib/systemd/systemd-journal-remote

systemd-journal-remote.service(8)

/usr/lib/systemd/systemd-journal-upload

systemd-journal-upload.service(8)

/usr/lib/systemd/systemd-journald

systemd-journald.service(8)

/usr/lib/systemd/systemd-localed

systemd-localed.service(8)

/usr/lib/systemd/systemd-logind

systemd-logind.service(8)

/usr/lib/systemd/systemd-machined

systemd-machined.service(8)

/usr/lib/systemd/systemd-makefs

[email protected](8)

/usr/lib/systemd/systemd-measure

systemd-measure(1)

/usr/lib/systemd/systemd-modules-load

systemd-modules-load.service(8)

/usr/lib/systemd/systemd-mountfsd

systemd-mountfsd.service(8)

/usr/lib/systemd/systemd-network-generator

systemd-network-generator.service(8)

/usr/lib/systemd/systemd-networkd

systemd-networkd.service(8)

/usr/lib/systemd/systemd-networkd-wait-online

systemd-networkd-wait-online.service(8)

/usr/lib/systemd/systemd-nsresourced

systemd-nsresourced.service(8)

/usr/lib/systemd/systemd-oomd

systemd-oomd.service(8)

/usr/lib/systemd/systemd-pcrextend

systemd-pcrphase.service(8), varlinkctl(1)

/usr/lib/systemd/systemd-pcrlock

systemd-pcrlock(8)

/usr/lib/systemd/systemd-portabled

systemd-portabled.service(8)

/usr/lib/systemd/systemd-pstore

systemd-pstore.service(8)

/usr/lib/systemd/systemd-quotacheck

systemd-quotacheck.service(8)

/usr/lib/systemd/systemd-random-seed

systemd-random-seed.service(8)

/usr/lib/systemd/systemd-remount-fs

systemd-remount-fs.service(8)

/usr/lib/systemd/systemd-resolved

systemd-resolved.service(8)

/usr/lib/systemd/systemd-rfkill

systemd-rfkill.service(8)

/usr/lib/systemd/systemd-shutdown

systemd-poweroff.service(8)

/usr/lib/systemd/systemd-ssh-proxy

systemd-ssh-proxy(1)

/usr/lib/systemd/systemd-storagetm

systemd-storagetm.service(8)

/usr/lib/systemd/systemd-sysctl

systemd-sysctl.service(8)

/usr/lib/systemd/systemd-time-wait-sync

systemd-time-wait-sync.service(8)

/usr/lib/systemd/systemd-timedated

systemd-timedated.service(8)

/usr/lib/systemd/systemd-timesyncd

systemd-timesyncd.service(8)

/usr/lib/systemd/systemd-tpm2-setup

systemd-tpm2-setup.service(8)

/usr/lib/systemd/systemd-udevd

systemd-udevd.service(8)

/usr/lib/systemd/systemd-update-done

systemd-update-done.service(8)

/usr/lib/systemd/systemd-update-utmp

systemd-update-utmp.service(8)

/usr/lib/systemd/systemd-user-runtime-dir

[email protected](5)

/usr/lib/systemd/systemd-user-sessions

systemd-user-sessions.service(8)

/usr/lib/systemd/systemd-userdbd

systemd-userdbd.service(8)

/usr/lib/systemd/systemd-veritysetup

[email protected](8)

/usr/lib/systemd/systemd-volatile-root

systemd-volatile-root.service(8)

/usr/lib/systemd/timesyncd.conf

timesyncd.conf(5)

/usr/lib/systemd/timesyncd.conf.d/*.conf

timesyncd.conf(5)

/usr/lib/systemd/ukify.conf

ukify(1)

/usr/lib/systemd/user/

systemd.unit(5)

/usr/lib/systemd/user-environment-generators/

systemd.environment-generator(7)

/usr/lib/systemd/user-environment-generators/30-systemd-environment-d-generator

systemd-environment-d-generator(8)

/usr/lib/systemd/user-environment-generators/some-generator

systemd.environment-generator(7)

/usr/lib/systemd/user-generators/

systemd.generator(7)

/usr/lib/systemd/user-generators/systemd-xdg-autostart-generator

systemd-xdg-autostart-generator(8)

/usr/lib/systemd/user-preset/*.preset

systemd.preset(5)

/usr/lib/systemd/user.conf

systemd-system.conf(5)

/usr/lib/systemd/user.conf.d/*.conf

systemd-system.conf(5)

/usr/lib/sysupdate.component.d/*.conf

systemd-sysupdate(8)

/usr/lib/sysupdate.*.d/

systemd-sysupdate(8)

/usr/lib/sysupdate.d/*.conf

systemd-sysupdate(8), sysupdate.d(5)

/usr/lib/sysusers.d

sysusers.d(5)

/usr/lib/sysusers.d/*.conf

sysusers.d(5)

/usr/lib/sysusers.d/radvd.conf

systemd-sysusers(8)

/usr/lib/tmpfiles.d

tmpfiles.d(5)

/usr/lib/tmpfiles.d/*.conf

tmpfiles.d(5)

/usr/lib/tmpfiles.d/provision.conf

systemd.system-credentials(7)

/usr/lib/tmpfiles.d/systemd.conf

systemd-coredump(8)

/usr/lib/tmpfiles/systemd-pstore.conf

systemd-pstore.service(8)

/usr/lib/udev

udev(7)

/usr/lib/udev/hwdb.bin

hwdb(7)

/usr/lib/udev/hwdb.d

hwdb(7)

/usr/lib/udev/rules.d

udev(7)

/usr/lib/udev/udev.conf

udev.conf(5)

/usr/lib/udev/udev.conf.d/*.conf

udev.conf(5)

/usr/lib/userdb/

nss-systemd(8), systemd-userdbd.service(8), userdbctl(1)

/usr/lib64/

file-hierarchy(7)

/usr/lib64/firefox/firefox

coredumpctl(1)

/usr/local/

binfmt.d(5), coredump.conf(5), environment.d(5), homed.conf(5), iocost.conf(5), journal-remote.conf(5), journal-upload.conf(5), journald.conf(5), logind.conf(5), modules-load.d(5), networkd.conf(5), oomd.conf(5), pstore.conf(5), resolved.conf(5), sysctl.d(5), systemd-sleep.conf(5), systemd-system.conf(5), systemd.environment-generator(7), systemd.generator(7), systemd.link(5), systemd.network(5), systemd.unit(5), timesyncd.conf(5)

/usr/local/bin

systemd.exec(5), systemd.service(5)

/usr/local/lib/

binfmt.d(5), environment.d(5), modules-load.d(5), sysctl.d(5), systemd-timedated.service(8), systemd.dnssd(5)

/usr/local/lib/binfmt.d/*.conf

binfmt.d(5)

/usr/local/lib/confexts/

systemd-sysext(8)

/usr/local/lib/dnssec-trust-anchors.d/*.negative

dnssec-trust-anchors.d(5)

/usr/local/lib/dnssec-trust-anchors.d/*.positive

dnssec-trust-anchors.d(5)

/usr/local/lib/environment.d/*.conf

environment.d(5)

/usr/local/lib/kernel/install.conf

kernel-install(8)

/usr/local/lib/kernel/install.conf.d/*.conf

kernel-install(8)

/usr/local/lib/machines/

machinectl(1)

/usr/local/lib/modules-load.d/*.conf

modules-load.d(5)

/usr/local/lib/portables/

portablectl(1)

/usr/local/lib/repart.d/*.conf

repart.d(5)

/usr/local/lib/sysctl.d/*.conf

sysctl.d(5)

/usr/local/lib/systemd/

coredump.conf(5), homed.conf(5), iocost.conf(5), journal-remote.conf(5), journal-upload.conf(5), journald.conf(5), logind.conf(5), networkd.conf(5), oomd.conf(5), pstore.conf(5), resolved.conf(5), systemd-sleep.conf(5), systemd-system.conf(5), timesyncd.conf(5)

/usr/local/lib/systemd/*.conf.d/

coredump.conf(5), homed.conf(5), iocost.conf(5), journal-remote.conf(5), journal-upload.conf(5), journald.conf(5), logind.conf(5), networkd.conf(5), oomd.conf(5), pstore.conf(5), resolved.conf(5), systemd-sleep.conf(5), systemd-system.conf(5), timesyncd.conf(5)

/usr/local/lib/systemd/coredump.conf

coredump.conf(5)

/usr/local/lib/systemd/coredump.conf.d/*.conf

coredump.conf(5)

/usr/local/lib/systemd/dnssd

systemd.dnssd(5)

/usr/local/lib/systemd/homed.conf

homed.conf(5)

/usr/local/lib/systemd/homed.conf.d/*.conf

homed.conf(5)

/usr/local/lib/systemd/journal-remote.conf

journal-remote.conf(5)

/usr/local/lib/systemd/journal-remote.conf.d/*.conf

journal-remote.conf(5)

/usr/local/lib/systemd/journald.conf

journald.conf(5)

/usr/local/lib/systemd/journald.conf.d/*.conf

journald.conf(5)

/usr/local/lib/systemd/journald@NAMESPACE.conf.d/*.conf

journald.conf(5)

/usr/local/lib/systemd/logind.conf

logind.conf(5)

/usr/local/lib/systemd/logind.conf.d/*.conf

logind.conf(5)

/usr/local/lib/systemd/network

systemd.link(5), systemd.netdev(5), systemd.network(5)

/usr/local/lib/systemd/networkd.conf

networkd.conf(5)

/usr/local/lib/systemd/networkd.conf.d/*.conf

networkd.conf(5)

/usr/local/lib/systemd/oomd.conf

oomd.conf(5)

/usr/local/lib/systemd/oomd.conf.d/*.conf

oomd.conf(5)

/usr/local/lib/systemd/pstore.conf

pstore.conf(5)

/usr/local/lib/systemd/pstore.conf.d/*.conf

pstore.conf(5)

/usr/local/lib/systemd/resolved.conf

resolved.conf(5)

/usr/local/lib/systemd/resolved.conf.d/*.conf

resolved.conf(5)

/usr/local/lib/systemd/system

systemd(1), systemd.unit(5)

/usr/local/lib/systemd/system-environment-generators/

systemd.environment-generator(7)

/usr/local/lib/systemd/system-generators/

systemd.generator(7)

/usr/local/lib/systemd/system-preset/*.preset

systemd.preset(5)

/usr/local/lib/systemd/timesyncd.conf

timesyncd.conf(5)

/usr/local/lib/systemd/timesyncd.conf.d/*.conf

timesyncd.conf(5)

/usr/local/lib/systemd/ukify.conf

ukify(1)

/usr/local/lib/systemd/user/

systemd.unit(5)

/usr/local/lib/systemd/user-environment-generators/

systemd.environment-generator(7)

/usr/local/lib/systemd/user-generators/

systemd.generator(7)

/usr/local/lib/systemd/user-preset/*.preset

systemd.preset(5)

/usr/local/lib/sysupdate.d/*.conf

sysupdate.d(5)

/usr/local/lib/sysusers.d/*.conf

sysusers.d(5)

/usr/local/lib/tmpfiles.d/*.conf

tmpfiles.d(5)

/usr/local/lib/udev/rules.d

udev(7)

/usr/local/lib/udev/udev.conf

udev.conf(5)

/usr/local/lib/udev/udev.conf.d/*.conf

udev.conf(5)

/usr/local/pcrlock.d/

systemd-pcrlock(8)

/usr/local/pcrlock.d/*.pcrlock

systemd.pcrlock(5)

/usr/local/pcrlock.d/*.pcrlock.d/*.pcrlock

systemd.pcrlock(5)

/usr/local/sbin

systemd.exec(5)

/usr/local/share

systemd.unit(5)

/usr/local/share/systemd/user

systemd.unit(5)

/usr/local/share/user-tmpfiles.d/*.conf

tmpfiles.d(5)

/usr/sbin/

file-hierarchy(7), org.freedesktop.systemd1(5), systemd.exec(5)

/usr/sbin/nologin

sysusers.d(5)

/usr/share/

file-hierarchy(7), systemd.unit(5)

/usr/share/dbus-1/system-services/org.example.simple-dbus-service.service

systemd.service(5)

/usr/share/doc/

file-hierarchy(7)

/usr/share/factory/

file-hierarchy(7), tmpfiles.d(5)

/usr/share/factory/etc/

file-hierarchy(7)

/usr/share/factory/var/

file-hierarchy(7)

/usr/share/systemd/user

systemd.unit(5)

/usr/share/user-tmpfiles.d/

systemd-tmpfiles(8)

/usr/share/user-tmpfiles.d/*.conf

tmpfiles.d(5)

/usr/share/wayland-sessions

homectl(1)

/usr/share/xesssions/

homectl(1)

/usr/share/zoneinfo/

localtime(5)

/usr/share/zoneinfo/zone.tab

org.freedesktop.timedate1(5)

/var/

file-hierarchy(7), journald.conf(5), kernel-command-line(7), repart.d(5), systemctl(1), systemd-cryptenroll(1), systemd-fstab-generator(8), systemd-gpt-auto-generator(8), systemd-journald.service(8), systemd-nspawn(1), systemd-pcrlock(8), systemd-pcrphase.service(8), systemd-poweroff.service(8), systemd-random-seed.service(8), systemd-sysext(8), systemd-tpm2-setup.service(8), systemd-update-done.service(8), systemd-volatile-root.service(8), systemd.exec(5), systemd.generator(7), systemd.offline-updates(7), systemd.special(7), systemd.unit(5), tmpfiles.d(5)

/var/.updated

systemd-update-done.service(8)

/var/cache/

file-hierarchy(7), systemd.exec(5), systemd.unit(5), tmpfiles.d(5)

/var/cache/dnf/

tmpfiles.d(5)

/var/cache/krb5rcache/

tmpfiles.d(5)

/var/cache/private

systemd.exec(5)

/var/lib/

file-hierarchy(7), systemd.exec(5), systemd.unit(5), tmpfiles.d(5)

/var/lib/capsules/

[email protected](5)

/var/lib/confexts/

importctl(1), systemd-mountfsd.service(8), systemd-sysext(8)

/var/lib/container/

machinectl(1)

/var/lib/dbus/machine-id

machine-id(5)

/var/lib/extensions/

importctl(1), systemd-dissect(1), systemd-mountfsd.service(8), systemd-sysext(8)

/var/lib/extensions.mutable/

systemd-sysext(8)

/var/lib/extensions.mutable/etc/

systemd-sysext(8)

/var/lib/extensions.mutable/opt/

systemd-sysext(8)

/var/lib/extensions.mutable/usr/

systemd-sysext(8)

/var/lib/machines/

importctl(1), machinectl(1), org.freedesktop.import1(5), systemd-dissect(1), systemd-mountfsd.service(8), systemd-nspawn(1), systemd.nspawn(5), tmpfiles.d(5)

/var/lib/machines/myContainer

sysupdate.d(5)

/var/lib/machines/myContainer_@v

sysupdate.d(5)

/var/lib/machines/mymachine.raw.v/

systemd.v(7)

/var/lib/machines/mymachine.raw.v/mymachine_7.5.14_x86-64.raw

systemd.v(7)

/var/lib/machines/quux.raw.v/quux*.raw

systemd-vpick(1)

/var/lib/machines/waldo.v/waldo

systemd-vpick(1)

/var/lib/pcrlock.d/

systemd-pcrlock(8)

/var/lib/pcrlock.d/*.pcrlock

systemd.pcrlock(5)

/var/lib/pcrlock.d/*.pcrlock.d/*.pcrlock

systemd.pcrlock(5)

/var/lib/pcrlock.d/230-secureboot-policy.pcrlock.d/generated.pcrlock

systemd-pcrlock(8)

/var/lib/pcrlock.d/250-firmware-code-early.pcrlock.d/generated.pcrlock

systemd-pcrlock(8)

/var/lib/pcrlock.d/250-firmware-config-early.pcrlock.d/generated.pcrlock

systemd-pcrlock(8)

/var/lib/pcrlock.d/550-firmware-code-late.pcrlock.d/generated.pcrlock

systemd-pcrlock(8)

/var/lib/pcrlock.d/550-firmware-config-late.pcrlock.d/generated.pcrlock

systemd-pcrlock(8)

/var/lib/pcrlock.d/600-gpt.pcrlock.d/generated.pcrlock

systemd-pcrlock(8)

/var/lib/pcrlock.d/620-secureboot-authority.pcrlock.d/generated.pcrlock

systemd-pcrlock(8)

/var/lib/pcrlock.d/710-kernel-cmdline.pcrlock/generated.pcrlock

systemd-pcrlock(8)

/var/lib/pcrlock.d/720-kernel-initrd.pcrlock/generated.pcrlock

systemd-pcrlock(8)

/var/lib/pcrlock.d/820-machine-id.pcrlock

systemd-pcrlock(8)

/var/lib/pcrlock.d/830-root-file-system.pcrlock

systemd-pcrlock(8)

/var/lib/pcrlock.d/840-file-system-path.pcrlock

systemd-pcrlock(8)

/var/lib/portables/

importctl(1), portablectl(1), systemd-dissect(1), systemd-mountfsd.service(8)

/var/lib/private

systemd.exec(5)

/var/lib/systemd/

crypttab(5), systemd-creds(1), systemd-cryptenroll(1), systemd.exec(5)

/var/lib/systemd/backlight/

[email protected](8)

/var/lib/systemd/coredump/

coredump.conf(5), coredumpctl(1), systemd-coredump(8)

/var/lib/systemd/credential.secret

systemd-creds(1)

/var/lib/systemd/credentials.secret

systemd.exec(5)

/var/lib/systemd/ephemeral-trees/

systemd.exec(5)

/var/lib/systemd/home/

systemd-homed.service(8)

/var/lib/systemd/home/*.public

systemd-homed.service(8)

/var/lib/systemd/home/local.private

systemd-homed.service(8)

/var/lib/systemd/home/local.public

systemd-homed.service(8)

/var/lib/systemd/journal-upload/state

systemd-journal-upload.service(8)

/var/lib/systemd/pcrlock.json

systemd-pcrlock(8)

/var/lib/systemd/pstore/

pstore.conf(5), systemd-pstore.service(8)

/var/lib/systemd/random-seed

systemd-random-seed.service(8)

/var/lib/systemd/rfkill/

systemd-rfkill.service(8)

/var/lib/systemd/timesync/clock

systemd-timesyncd.service(8)

/var/lib/systemd/tpm2-srk-public-key.

systemd-tpm2-setup.service(8)

/var/lib/systemd/tpm2-srk-public-key.pem

systemd-tpm2-setup.service(8)

/var/lib/systemd/tpm2-srk-public-key.tpm2_public

systemd-tpm2-setup.service(8)

/var/lib/systemd/tpm2-srk-public-key.tpm2b_public

systemd-tpm2-setup.service(8)

/var/lock

systemctl(1)

/var/log/

file-hierarchy(7), sd_journal_get_seqnum(3), systemd.exec(5), systemd.unit(5), tmpfiles.d(5)

/var/log/journal/

coredumpctl(1), journalctl(1), journald.conf(5), sd_journal_open(3), systemd-journald.service(8), systemd-nspawn(1)

/var/log/journal/remote/

systemd-journal-remote.service(8)

/var/log/journal/remote/remote-some.host.journal

systemd-journal-remote.service(8)

/var/log/private

systemd.exec(5)

/var/run/

file-hierarchy(7), org.freedesktop.systemd1(5), systemctl(1), tmpfiles.d(5)

/var/spool/

file-hierarchy(7)

/var/tmp/

file-hierarchy(7), repart.d(5), systemd-gpt-auto-generator(8), systemd-nspawn(1), systemd-system.conf(5), systemd.exec(5), systemd.link(5), systemd.special(7), systemd.unit(5), sysupdate.d(5), sysusers.d(5), tmpfiles.d(5)

ESP/…/foo.efi.extra.d/*.addon.efi

systemd-stub(7)

ESP/…/foo.efi.extra.d/*.confext.raw

systemd-stub(7)

ESP/…/foo.efi.extra.d/*.cred

systemd-stub(7)

ESP/…/foo.efi.extra.d/*.raw

systemd-stub(7)

ESP/…/foo.efi.extra.d/*.sysext.raw

systemd-stub(7)

ESP/loader/addons/*.addon.efi

systemd-stub(7)

ESP/loader/credentials/*.cred

systemd-stub(7)

ESP/loader/entries/*.conf

loader.conf(5)

ESP/loader/loader.conf

loader.conf(5)

XBOOTLDR/loader/entries/*.conf

loader.conf(5)

automount.automount

systemd.automount(5), systemd.unit(5)

basic.target

systemd.special(7)

[email protected]

systemd.special(7)

bluetooth.target

systemd.special(7)

boot-complete.target

systemd.special(7)

bootctl

bootctl(1)

busctl

busctl(1)

capsule.slice

systemd.special(7)

capsule@NAME.service

[email protected](5)

coredumpctl

coredumpctl(1)

cryptsetup-pre.target

systemd.special(7)

cryptsetup.target

systemd.special(7)

ctrl-alt-del.target

systemd.special(7)

dbus.service

systemd.special(7)

dbus.socket

systemd.special(7)

default.target

systemd.special(7)

device.device

systemd.device(5), systemd.unit(5)

display-manager.service

systemd.special(7)

emergency.target

systemd.special(7)

exit.target

systemd.special(7)

factory-reset.target

systemd.special(7)

final.target

systemd.special(7)

first-boot-complete.target

systemd.special(7)

getty-pre.target

systemd.special(7)

getty.target

systemd.special(7)

graphical.target

systemd.special(7)

halt

poweroff(8)

halt.target

systemd.special(7)

hibernate.target

systemd.special(7)

homectl

homectl(1)

hostnamectl

hostnamectl(1)

hybrid-sleep.target

systemd.special(7)

importctl

importctl(1)

init

systemd(1)

init.scope

systemd.special(7)

initrd-fs.target

systemd.special(7)

initrd-root-device.target

systemd.special(7)

initrd-root-fs.target

systemd.special(7)

initrd-usr-fs.target

systemd.special(7)

initrd.target

systemd.special(7)

integritysetup-pre.target

systemd.special(7)

integritysetup.target

systemd.special(7)

journalctl

journalctl(1)

kbrequest.target

systemd.special(7)

kernel-install

kernel-install(8)

kexec.target

systemd.special(7)

libnss_myhostname.so.2

nss-myhostname(8)

libnss_mymachines.so.2

nss-mymachines(8)

libnss_resolve.so.2

nss-resolve(8)

libnss_systemd.so.2

nss-systemd(8)

link.link

systemd.link(5)

local-fs-pre.target

systemd.special(7)

local-fs.target

systemd.special(7)

localectl

localectl(1)

loginctl

loginctl(1)

machine.slice

systemd.special(7)

machinectl

machinectl(1)

machines.target

systemd.special(7)

mount.mount

systemd.exec(5), systemd.kill(5), systemd.mount(5), systemd.resource-control(5), systemd.unit(5)

multi-user.target

systemd.special(7)

netdev.netdev

systemd.netdev(5)

network.network

systemd.network(5)

network-online.target

systemd.special(7)

network-pre.target

systemd.special(7)

network.target

systemd.special(7)

network_service.dnssd

systemd.dnssd(5)

networkctl

networkctl(1)

nss-lookup.target

systemd.special(7)

nss-user-lookup.target

systemd.special(7)

oomctl

oomctl(1)

pam_systemd.so

pam_systemd(8)

pam_systemd_home.so

pam_systemd_home(8)

pam_systemd_loadkey.so

pam_systemd_loadkey(8)

path.path

systemd.path(5), systemd.unit(5)

paths.target

systemd.special(7)

pkg-config

libsystemd(3), libudev(3), sd-bus(3), sd-daemon(3), sd-device(3), sd-event(3), sd-hwdb(3), sd-id128(3), sd-journal(3), sd-login(3)

portablectl

portablectl(1)

poweroff

poweroff(8)

poweroff.target

systemd.special(7)

printer.target

systemd.special(7)

rc-local.service

systemd-rc-local-generator(8)

reboot

poweroff(8)

reboot.target

systemd.special(7)

remote-cryptsetup.target

systemd.special(7)

remote-fs-pre.target

systemd.special(7)

remote-fs.target

systemd.special(7)

remote-veritysetup.target

systemd.special(7)

rescue.target

systemd.special(7)

resolvectl

resolvectl(1)

rpcbind.target

systemd.special(7)

run0

run0(1)

runlevel

runlevel(8)

runlevel2.target

systemd.special(7)

runlevel3.target

systemd.special(7)

runlevel4.target

systemd.special(7)

runlevel5.target

systemd.special(7)

scope.scope

systemd.kill(5), systemd.resource-control(5), systemd.scope(5), systemd.unit(5)

service.service

systemd.exec(5), systemd.kill(5), systemd.resource-control(5), systemd.service(5), systemd.unit(5)

shutdown

shutdown(8)

shutdown.target

systemd.special(7)

sigpwr.target

systemd.special(7)

sleep.target

systemd.special(7)

slice.slice

systemd.resource-control(5), systemd.slice(5), systemd.unit(5)

slices.target

systemd.special(7)

smartcard.target

systemd.special(7)

socket.socket

systemd.exec(5), systemd.kill(5), systemd.resource-control(5), systemd.socket(5), systemd.unit(5)

sockets.target

systemd.special(7)

soft-reboot.target

systemd.special(7)

sound.target

systemd.special(7)

ssh-access.target

systemd.special(7)

storage-target-mode.target

systemd.special(7)

suspend-then-hibernate.target

systemd.special(7)

suspend.target

systemd.special(7)

swap.swap

systemd.exec(5), systemd.kill(5), systemd.resource-control(5), systemd.swap(5), systemd.unit(5)

swap.target

systemd.special(7)

sysinit.target

systemd.special(7)

syslog.socket

systemd.special(7)

system-systemd-cryptsetup.slice

systemd-cryptsetup(8)

system-update-cleanup.service

systemd.special(7)

system-update-pre.target

systemd.special(7)

system-update.target

systemd.special(7)

system.slice

systemd.special(7)

systemctl

systemctl(1)

systemd-ac-power

systemd-ac-power(1)

systemd-analyze

systemd-analyze(1)

systemd-ask-password

systemd-ask-password(1)

systemd-ask-password-console.path

systemd-ask-password-console.service(8)

systemd-ask-password-console.service

systemd-ask-password-console.service(8)

systemd-ask-password-wall.path

systemd-ask-password-console.service(8)

systemd-ask-password-wall.service

systemd-ask-password-console.service(8)

[email protected]

[email protected](8)

systemd-battery-check.service

systemd-battery-check.service(8)

systemd-binfmt.service

systemd-binfmt.service(8)

systemd-bless-boot.service

systemd-bless-boot.service(8)

systemd-boot-check-no-failures.service

systemd-boot-check-no-failures.service(8)

systemd-boot-random-seed.service

systemd-boot-random-seed.service(8)

systemd-bsod.service

systemd-bsod.service(8)

systemd-cat

systemd-cat(1)

systemd-cgls

systemd-cgls(1)

systemd-cgtop

systemd-cgtop(1)

systemd-confext

systemd-sysext(8)

systemd-confext.service

systemd-sysext(8)

systemd-coredump.socket

systemd-coredump(8)

[email protected]

systemd-coredump(8)

systemd-creds

systemd-creds(1)

systemd-cryptenroll

systemd-cryptenroll(1)

systemd-cryptsetup

systemd-cryptsetup(8)

[email protected]

systemd-cryptsetup(8)

systemd-delta

systemd-delta(1)

systemd-detect-virt

systemd-detect-virt(1)

systemd-dissect

systemd-dissect(1)

systemd-escape

systemd-escape(1)

systemd-firstboot

systemd-firstboot(1)

systemd-firstboot.service

systemd-firstboot(1)

systemd-fsck-root.service

[email protected](8)

systemd-fsck-usr.service

[email protected](8)

[email protected]

[email protected](8)

systemd-growfs-root.service

[email protected](8)

systemd-growfs@mountpoint.service

[email protected](8)

systemd-halt.service

systemd-poweroff.service(8)

systemd-hibernate-clear.service

systemd-hibernate-resume.service(8)

systemd-hibernate-resume.service

systemd-hibernate-resume.service(8)

systemd-hibernate.service

systemd-suspend.service(8)

systemd-homed.service

systemd-homed.service(8)

systemd-hostnamed.service

systemd-hostnamed.service(8)

systemd-hwdb

systemd-hwdb(8)

systemd-hybrid-sleep.service

systemd-suspend.service(8)

systemd-id128

systemd-id128(1)

systemd-importd.service

systemd-importd.service(8)

systemd-inhibit

systemd-inhibit(1)

systemd-initctl.service

systemd-initctl.service(8)

systemd-initctl.socket

systemd-initctl.service(8)

[email protected]

[email protected](8)

systemd-journal-gatewayd.service

systemd-journal-gatewayd.service(8)

systemd-journal-gatewayd.socket

systemd-journal-gatewayd.service(8)

systemd-journal-remote.service

systemd-journal-remote.service(8)

systemd-journal-remote.socket

systemd-journal-remote.service(8)

systemd-journal-upload.service

systemd-journal-upload.service(8)

systemd-journald-audit.socket

systemd-journald.service(8)

systemd-journald-dev-log.socket

systemd-journald.service(8)

[email protected]

systemd-journald.service(8)

systemd-journald.service

systemd-journald.service(8)

systemd-journald.socket

systemd-journald.service(8)

[email protected]

systemd-journald.service(8)

[email protected]

systemd-journald.service(8)

systemd-kexec.service

systemd-poweroff.service(8)

systemd-localed.service

systemd-localed.service(8)

systemd-logind.service

systemd-logind.service(8)

systemd-machine-id-commit.service

systemd-machine-id-commit.service(8)

systemd-machine-id-setup

systemd-machine-id-setup(1)

systemd-machined.service

systemd-machined.service(8)

systemd-makefs@device.service

[email protected](8)

systemd-mkswap@device.service

[email protected](8)

systemd-modules-load.service

systemd-modules-load.service(8)

systemd-mount

systemd-mount(1)

systemd-mountfsd.service

systemd-mountfsd.service(8)

systemd-network-generator.service

systemd-network-generator.service(8)

systemd-networkd-wait-online.service

systemd-networkd-wait-online.service(8)

[email protected]

systemd-networkd-wait-online.service(8)

systemd-networkd.service

systemd-networkd.service(8)

systemd-notify

systemd-notify(1)

systemd-nspawn

systemd-nspawn(1)

systemd-nsresourced.service

systemd-nsresourced.service(8)

systemd-oomd.service

systemd-oomd.service(8)

systemd-path

systemd-path(1)

systemd-pcrfs-root.service

systemd-pcrphase.service(8)

[email protected]

systemd-pcrphase.service(8)

systemd-pcrmachine.service

systemd-pcrphase.service(8)

systemd-pcrphase-initrd.service

systemd-pcrphase.service(8)

systemd-pcrphase-sysinit.service

systemd-pcrphase.service(8)

systemd-pcrphase.service

systemd-pcrphase.service(8)

systemd-portabled.service

systemd-portabled.service(8)

systemd-poweroff.service

systemd-poweroff.service(8)

systemd-pstore.service

systemd-pstore.service(8)

systemd-quotacheck.service

systemd-quotacheck.service(8)

systemd-random-seed.service

systemd-random-seed.service(8)

systemd-reboot.service

systemd-poweroff.service(8)

systemd-remount-fs.service

systemd-remount-fs.service(8)

systemd-repart

systemd-repart(8)

systemd-repart.service

systemd-repart(8)

systemd-resolved.service

systemd-resolved.service(8)

systemd-rfkill.service

systemd-rfkill.service(8)

systemd-rfkill.socket

systemd-rfkill.service(8)

systemd-run

systemd-run(1)

systemd-socket-activate

systemd-socket-activate(1)

systemd-socket-proxyd

systemd-socket-proxyd(8)

systemd-soft-reboot.service

systemd-soft-reboot.service(8)

systemd-stdio-bridge

systemd-stdio-bridge(1)

systemd-storagetm.service

systemd-storagetm.service(8)

systemd-suspend-then-hibernate.service

systemd-suspend.service(8)

systemd-suspend.service

systemd-suspend.service(8)

systemd-sysctl.service

systemd-sysctl.service(8)

systemd-sysext

systemd-sysext(8)

systemd-sysext.service

systemd-sysext(8)

systemd-sysupdate

systemd-sysupdate(8)

systemd-sysupdate.service

systemd-sysupdate(8)

systemd-sysusers

systemd-sysusers(8)

systemd-sysusers.service

systemd-sysusers(8)

systemd-time-wait-sync.service

systemd-time-wait-sync.service(8)

systemd-timedated.service

systemd-timedated.service(8)

systemd-timesyncd.service

systemd-timesyncd.service(8)

systemd-tmpfiles

systemd-tmpfiles(8)

systemd-tmpfiles-clean.service

systemd-tmpfiles(8)

systemd-tmpfiles-clean.timer

systemd-tmpfiles(8)

systemd-tmpfiles-setup-dev-early.service

systemd-tmpfiles(8)

systemd-tmpfiles-setup-dev.service

systemd-tmpfiles(8)

systemd-tmpfiles-setup.service

systemd-tmpfiles(8)

systemd-tpm2-setup.service

systemd-tpm2-setup.service(8)

systemd-tty-ask-password-agent

systemd-tty-ask-password-agent(1)

systemd-udev-settle.service

systemd-udev-settle.service(8)

systemd-udevd-control.socket

systemd-udevd.service(8)

systemd-udevd-kernel.socket

systemd-udevd.service(8)

systemd-udevd.service

systemd-udevd.service(8)

systemd-update-done.service

systemd-update-done.service(8)

systemd-update-utmp-runlevel.service

systemd-update-utmp.service(8)

systemd-update-utmp.service

systemd-update-utmp.service(8)

systemd-user-sessions.service

systemd-user-sessions.service(8)

systemd-userdbd.service

systemd-userdbd.service(8)

[email protected]

[email protected](8)

systemd-volatile-root.service

systemd-volatile-root.service(8)

systemd-vpick

systemd-vpick(1)

target.target

systemd.target(5), systemd.unit(5)

telinit

telinit(8)

time-set.target

systemd.special(7)

time-sync.target

systemd.special(7)

timedatectl

timedatectl(1)

timer.timer

systemd.timer(5), systemd.unit(5)

timers.target

systemd.special(7)

tpm2.target

systemd.special(7)

udevadm

udevadm(8)

ukify

ukify(1)

umount.target

systemd.special(7)

usb-gadget.target

systemd.special(7)

user-UID.slice

[email protected](5)

user-runtime-dir@UID.service

[email protected](5)

user.slice

systemd.special(7)

user@UID.service

[email protected](5)

userdbctl

userdbctl(1)

varlinkctl

varlinkctl(1)

veritysetup-pre.target

systemd.special(7)

veritysetup.target

systemd.special(7)

~/.config/environment.d/*.conf

environment.d(5)

~/.config/systemd/user/

systemd.unit(5)

~/.config/systemd/user.conf

systemd-system.conf(5)

~/.config/systemd/user.control/

systemd.unit(5)

~/.config/user-tmpfiles.d/*.conf

tmpfiles.d(5)

~/.local/share/user-tmpfiles.d/*.conf

tmpfiles.d(5)

D-BUS INTERFACES

Interfaces exposed over D-Bus.

org.freedesktop.DBus.ObjectManager

org.freedesktop.home1(5)

org.freedesktop.LogControl1

org.freedesktop.LogControl1(5)

org.freedesktop.home1.Home

org.freedesktop.home1(5)

org.freedesktop.home1.Manager

org.freedesktop.home1(5)

org.freedesktop.hostname1

org.freedesktop.hostname1(5)

org.freedesktop.import1.Manager

org.freedesktop.import1(5)

org.freedesktop.import1.Transfer

org.freedesktop.import1(5)

org.freedesktop.locale1

org.freedesktop.locale1(5)

org.freedesktop.login1.Manager

org.freedesktop.login1(5)

org.freedesktop.login1.Seat

org.freedesktop.login1(5)

org.freedesktop.login1.Session

org.freedesktop.login1(5)

org.freedesktop.login1.User

org.freedesktop.login1(5)

org.freedesktop.machine1.Machine

org.freedesktop.machine1(5)

org.freedesktop.machine1.Manager

org.freedesktop.machine1(5)

org.freedesktop.network1.DHCPServer

org.freedesktop.network1(5)

org.freedesktop.network1.DHCPv4Client

org.freedesktop.network1(5)

org.freedesktop.network1.DHCPv6Client

org.freedesktop.network1(5)

org.freedesktop.network1.Link

org.freedesktop.network1(5)

org.freedesktop.network1.Manager

org.freedesktop.network1(5)

org.freedesktop.network1.Network

org.freedesktop.network1(5)

org.freedesktop.oom1.Manager

org.freedesktop.oom1(5)

org.freedesktop.portable1.Image

org.freedesktop.portable1(5)

org.freedesktop.portable1.Manager

org.freedesktop.portable1(5)

org.freedesktop.resolve1.Link

org.freedesktop.resolve1(5)

org.freedesktop.resolve1.Manager

org.freedesktop.resolve1(5)

org.freedesktop.systemd1.Automount

org.freedesktop.systemd1(5)

org.freedesktop.systemd1.Device

org.freedesktop.systemd1(5)

org.freedesktop.systemd1.Job

org.freedesktop.systemd1(5)

org.freedesktop.systemd1.Manager

org.freedesktop.systemd1(5)

org.freedesktop.systemd1.Mount

org.freedesktop.systemd1(5)

org.freedesktop.systemd1.Path

org.freedesktop.systemd1(5)

org.freedesktop.systemd1.Scope

org.freedesktop.systemd1(5)

org.freedesktop.systemd1.Service

org.freedesktop.systemd1(5)

org.freedesktop.systemd1.Slice

org.freedesktop.systemd1(5)

org.freedesktop.systemd1.Socket

org.freedesktop.systemd1(5)

org.freedesktop.systemd1.Swap

org.freedesktop.systemd1(5)

org.freedesktop.systemd1.Timer

org.freedesktop.systemd1(5)

org.freedesktop.systemd1.Unit

org.freedesktop.systemd1(5)

org.freedesktop.timedate1

org.freedesktop.timedate1(5)

D-BUS METHODS

Methods exposed in the D-Bus interface.

Abandon()

org.freedesktop.systemd1(5)

AbandonScope()

org.freedesktop.systemd1(5)

Acquire()

org.freedesktop.home1(5)

AcquireHome()

org.freedesktop.home1(5)

Activate()

org.freedesktop.home1(5), org.freedesktop.login1(5)

ActivateHome()

org.freedesktop.home1(5)

ActivateHomeIfReferenced()

org.freedesktop.home1(5)

ActivateIfReferenced()

org.freedesktop.home1(5)

ActivateSession()

org.freedesktop.login1(5)

ActivateSessionOnSeat()

org.freedesktop.login1(5)

AddDependencyUnitFiles()

org.freedesktop.systemd1(5)

Attach()

org.freedesktop.portable1(5)

AttachDevice()

org.freedesktop.login1(5)

AttachImage()

org.freedesktop.portable1(5)

AttachImageWithExtensions()

org.freedesktop.portable1(5)

AttachProcesses()

org.freedesktop.systemd1(5)

AttachProcessesToUnit()

org.freedesktop.systemd1(5)

AttachWithExtensions()

org.freedesktop.portable1(5)

Authenticate()

org.freedesktop.home1(5)

AuthenticateHome()

org.freedesktop.home1(5)

BindMount()

org.freedesktop.machine1(5), org.freedesktop.systemd1(5)

BindMountMachine()

org.freedesktop.machine1(5)

BindMountUnit()

org.freedesktop.systemd1(5)

CanHalt()

org.freedesktop.login1(5)

CanHibernate()

org.freedesktop.login1(5)

CanHybridSleep()

org.freedesktop.login1(5)

CanPowerOff()

org.freedesktop.login1(5)

CanReboot()

org.freedesktop.login1(5)

CanRebootParameter()

org.freedesktop.login1(5)

CanRebootToBootLoaderEntry()

org.freedesktop.login1(5)

CanRebootToBootLoaderMenu()

org.freedesktop.login1(5)

CanRebootToFirmwareSetup()

org.freedesktop.login1(5)

CanSleep()

org.freedesktop.login1(5)

CanSuspend()

org.freedesktop.login1(5)

CanSuspendThenHibernate()

org.freedesktop.login1(5)

Cancel()

org.freedesktop.import1(5), org.freedesktop.systemd1(5)

CancelJob()

org.freedesktop.systemd1(5)

CancelScheduledShutdown()

org.freedesktop.login1(5)

CancelTransfer()

org.freedesktop.import1(5)

ChangePassword()

org.freedesktop.home1(5)

ChangePasswordHome()

org.freedesktop.home1(5)

Clean()

org.freedesktop.systemd1(5)

CleanPool()

org.freedesktop.machine1(5)

CleanUnit()

org.freedesktop.systemd1(5)

ClearJobs()

org.freedesktop.systemd1(5)

CloneImage()

org.freedesktop.machine1(5)

CopyFrom()

org.freedesktop.machine1(5)

CopyFromMachine()

org.freedesktop.machine1(5)

CopyFromMachineWithFlags()

org.freedesktop.machine1(5)

CopyFromWithFlags()

org.freedesktop.machine1(5)

CopyTo()

org.freedesktop.machine1(5)

CopyToMachine()

org.freedesktop.machine1(5)

CopyToMachineWithFlags()

org.freedesktop.machine1(5)

CopyToWithFlags()

org.freedesktop.machine1(5)

CreateHome()

org.freedesktop.home1(5)

CreateHomeEx()

org.freedesktop.home1(5)

CreateMachine()

org.freedesktop.machine1(5)

CreateMachineWithNetwork()

org.freedesktop.machine1(5)

CreateSession()

org.freedesktop.login1(5)

CreateSessionWithPIDFD()

org.freedesktop.login1(5)

Deactivate()

org.freedesktop.home1(5)

DeactivateAllHomes()

org.freedesktop.home1(5)

DeactivateHome()

org.freedesktop.home1(5)

Describe()

org.freedesktop.hostname1(5), org.freedesktop.network1(5)

DescribeLink()

org.freedesktop.network1(5)

Detach()

org.freedesktop.portable1(5)

DetachImage()

org.freedesktop.portable1(5)

DetachImageWithExtensions()

org.freedesktop.portable1(5)

DetachWithExtensions()

org.freedesktop.portable1(5)

DisableUnitFiles()

org.freedesktop.systemd1(5)

DisableUnitFilesWithFlags()

org.freedesktop.systemd1(5)

DisableUnitFilesWithFlagsAndInstallInfo()

org.freedesktop.systemd1(5)

Dump()

org.freedesktop.systemd1(5)

DumpByFileDescriptor()

org.freedesktop.oom1(5), org.freedesktop.systemd1(5)

DumpFileDescriptorStore()

org.freedesktop.systemd1(5)

DumpUnitFileDescriptorStore()

org.freedesktop.systemd1(5)

DumpUnitsMatchingPatterns()

org.freedesktop.systemd1(5)

DumpUnitsMatchingPatternsByFileDescriptor()

org.freedesktop.systemd1(5)

EnableUnitFiles()

org.freedesktop.systemd1(5)

EnableUnitFilesWithFlags()

org.freedesktop.systemd1(5)

EnqueueJob()

org.freedesktop.systemd1(5)

EnqueueMarkedJobs()

org.freedesktop.systemd1(5)

EnqueueUnitJob()

org.freedesktop.systemd1(5)

Exit()

org.freedesktop.systemd1(5)

ExportRaw()

org.freedesktop.import1(5)

ExportRawEx()

org.freedesktop.import1(5)

ExportTar()

org.freedesktop.import1(5)

ExportTarEx()

org.freedesktop.import1(5)

Fixate()

org.freedesktop.home1(5)

FixateHome()

org.freedesktop.home1(5)

FlushCaches()

org.freedesktop.resolve1(5)

FlushDevices()

org.freedesktop.login1(5)

ForceRenew()

org.freedesktop.network1(5)

ForceRenewLink()

org.freedesktop.network1(5)

Freeze()

org.freedesktop.systemd1(5)

FreezeUnit()

org.freedesktop.systemd1(5)

GetAddresses()

org.freedesktop.machine1(5)

GetAfter()

org.freedesktop.systemd1(5)

GetBefore()

org.freedesktop.systemd1(5)

GetDefaultTarget()

org.freedesktop.systemd1(5)

GetDynamicUsers()

org.freedesktop.systemd1(5)

GetHardwareSerial()

org.freedesktop.hostname1(5)

GetHomeByName()

org.freedesktop.home1(5)

GetHomeByUID()

org.freedesktop.home1(5)

GetImage()

org.freedesktop.machine1(5), org.freedesktop.portable1(5)

GetImageHostname()

org.freedesktop.machine1(5)

GetImageMachineID()

org.freedesktop.machine1(5)

GetImageMachineInfo()

org.freedesktop.machine1(5)

GetImageMetadata()

org.freedesktop.portable1(5)

GetImageMetadataWithExtensions()

org.freedesktop.portable1(5)

GetImageOSRelease()

org.freedesktop.machine1(5), org.freedesktop.portable1(5)

GetImageState()

org.freedesktop.portable1(5)

GetImageStateWithExtensions()

org.freedesktop.portable1(5)

GetJob()

org.freedesktop.systemd1(5)

GetJobAfter()

org.freedesktop.systemd1(5)

GetJobBefore()

org.freedesktop.systemd1(5)

GetLink()

org.freedesktop.resolve1(5)

GetLinkByIndex()

org.freedesktop.network1(5)

GetLinkByName()

org.freedesktop.network1(5)

GetMachine()

org.freedesktop.machine1(5)

GetMachineAddresses()

org.freedesktop.machine1(5)

GetMachineByPID()

org.freedesktop.machine1(5)

GetMachineOSRelease()

org.freedesktop.machine1(5)

GetMachineSSHInfo()

org.freedesktop.machine1(5)

GetMachineUIDShift()

org.freedesktop.machine1(5)

GetMetadata()

org.freedesktop.portable1(5)

GetMetadataWithExtensions()

org.freedesktop.portable1(5)

GetOSRelease()

org.freedesktop.machine1(5), org.freedesktop.portable1(5)

GetProcesses()

org.freedesktop.systemd1(5)

GetProductUUID()

org.freedesktop.hostname1(5)

GetSSHInfo()

org.freedesktop.machine1(5)

GetSeat()

org.freedesktop.login1(5)

GetSession()

org.freedesktop.login1(5)

GetSessionByPID()

org.freedesktop.login1(5)

GetState()

org.freedesktop.portable1(5)

GetStateWithExtensions()

org.freedesktop.portable1(5)

GetUIDShift()

org.freedesktop.machine1(5)

GetUnit()

org.freedesktop.systemd1(5)

GetUnitByControlGroup()

org.freedesktop.systemd1(5)

GetUnitByInvocationID()

org.freedesktop.systemd1(5)

GetUnitByPID()

org.freedesktop.systemd1(5)

GetUnitByPIDFD()

org.freedesktop.systemd1(5)

GetUnitFileLinks()

org.freedesktop.systemd1(5)

GetUnitFileState()

org.freedesktop.systemd1(5)

GetUnitProcesses()

org.freedesktop.systemd1(5)

GetUser()

org.freedesktop.login1(5)

GetUserByPID()

org.freedesktop.login1(5)

GetUserRecordByName()

org.freedesktop.home1(5)

GetUserRecordByUID()

org.freedesktop.home1(5)

Halt()

org.freedesktop.login1(5), org.freedesktop.systemd1(5)

HaltWithFlags()

org.freedesktop.login1(5)

Hibernate()

org.freedesktop.login1(5)

HibernateWithFlags()

org.freedesktop.login1(5)

HybridSleep()

org.freedesktop.login1(5)

HybridSleepWithFlags()

org.freedesktop.login1(5)

ImportFileSystem()

org.freedesktop.import1(5)

ImportFileSystemEx()

org.freedesktop.import1(5)

ImportRaw()

org.freedesktop.import1(5)

ImportRawEx()

org.freedesktop.import1(5)

ImportTar()

org.freedesktop.import1(5)

ImportTarEx()

org.freedesktop.import1(5)

Inhibit()

org.freedesktop.login1(5)

KExec()

org.freedesktop.systemd1(5)

Kill()

org.freedesktop.login1(5), org.freedesktop.machine1(5), org.freedesktop.systemd1(5)

KillMachine()

org.freedesktop.machine1(5)

KillSession()

org.freedesktop.login1(5)

KillUnit()

org.freedesktop.systemd1(5)

KillUser()

org.freedesktop.login1(5)

LinkUnitFiles()

org.freedesktop.systemd1(5)

ListHomes()

org.freedesktop.home1(5)

ListImages()

org.freedesktop.import1(5), org.freedesktop.machine1(5), org.freedesktop.portable1(5)

ListInhibitors()

org.freedesktop.login1(5)

ListJobs()

org.freedesktop.systemd1(5)

ListLinks()

org.freedesktop.network1(5)

ListMachines()

org.freedesktop.machine1(5)

ListSeats()

org.freedesktop.login1(5)

ListSessions()

org.freedesktop.login1(5)

ListSessionsEx()

org.freedesktop.login1(5)

ListTimezones()

org.freedesktop.timedate1(5)

ListTransfers()

org.freedesktop.import1(5)

ListTransfersEx()

org.freedesktop.import1(5)

ListUnitFiles()

org.freedesktop.systemd1(5)

ListUnitFilesByPatterns()

org.freedesktop.systemd1(5)

ListUnits()

org.freedesktop.systemd1(5)

ListUnitsByNames()

org.freedesktop.systemd1(5)

ListUnitsByPatterns()

org.freedesktop.systemd1(5)

ListUnitsFiltered()

org.freedesktop.systemd1(5)

ListUsers()

org.freedesktop.login1(5)

LoadUnit()

org.freedesktop.systemd1(5)

Lock()

org.freedesktop.home1(5), org.freedesktop.login1(5)

LockAllHomes()

org.freedesktop.home1(5)

LockHome()

org.freedesktop.home1(5)

LockSession()

org.freedesktop.login1(5)

LockSessions()

org.freedesktop.login1(5)

LookupDynamicUserByName()

org.freedesktop.systemd1(5)

LookupDynamicUserByUID()

org.freedesktop.systemd1(5)

MapFromMachineGroup()

org.freedesktop.machine1(5)

MapFromMachineUser()

org.freedesktop.machine1(5)

MapToMachineGroup()

org.freedesktop.machine1(5)

MapToMachineUser()

org.freedesktop.machine1(5)

MarkImageReadOnly()

org.freedesktop.machine1(5), org.freedesktop.portable1(5)

MarkReadOnly()

org.freedesktop.portable1(5)

MaskUnitFiles()

org.freedesktop.systemd1(5)

MountImage()

org.freedesktop.systemd1(5)

MountImageUnit()

org.freedesktop.systemd1(5)

OpenLogin()

org.freedesktop.machine1(5)

OpenMachineLogin()

org.freedesktop.machine1(5)

OpenMachinePTY()

org.freedesktop.machine1(5)

OpenMachineRootDirectory()

org.freedesktop.machine1(5)

OpenMachineShell()

org.freedesktop.machine1(5)

OpenPTY()

org.freedesktop.machine1(5)

OpenRootDirectory()

org.freedesktop.machine1(5)

OpenShell()

org.freedesktop.machine1(5)

PauseDeviceComplete()

org.freedesktop.login1(5)

PowerOff()

org.freedesktop.login1(5), org.freedesktop.systemd1(5)

PowerOffWithFlags()

org.freedesktop.login1(5)

PresetAllUnitFiles()

org.freedesktop.systemd1(5)

PresetUnitFiles()

org.freedesktop.systemd1(5)

PresetUnitFilesWithMode()

org.freedesktop.systemd1(5)

PullRaw()

org.freedesktop.import1(5)

PullRawEx()

org.freedesktop.import1(5)

PullTar()

org.freedesktop.import1(5)

PullTarEx()

org.freedesktop.import1(5)

QueueSignal()

org.freedesktop.systemd1(5)

QueueSignalUnit()

org.freedesktop.systemd1(5)

Realize()

org.freedesktop.home1(5)

RealizeHome()

org.freedesktop.home1(5)

Reattach()

org.freedesktop.portable1(5)

ReattachImage()

org.freedesktop.portable1(5)

ReattachImageWithExtensions()

org.freedesktop.portable1(5)

ReattachWithExtensions()

org.freedesktop.portable1(5)

Rebalance()

org.freedesktop.home1(5)

Reboot()

org.freedesktop.login1(5), org.freedesktop.systemd1(5)

RebootWithFlags()

org.freedesktop.login1(5)

Reconfigure()

org.freedesktop.network1(5)

ReconfigureLink()

org.freedesktop.network1(5)

ReenableUnitFiles()

org.freedesktop.systemd1(5)

Reexecute()

org.freedesktop.systemd1(5)

Ref()

org.freedesktop.home1(5), org.freedesktop.systemd1(5)

RefHome()

org.freedesktop.home1(5)

RefHomeUnrestricted()

org.freedesktop.home1(5)

RefUnit()

org.freedesktop.systemd1(5)

RefUnrestricted()

org.freedesktop.home1(5)

RegisterHome()

org.freedesktop.home1(5)

RegisterMachine()

org.freedesktop.machine1(5)

RegisterMachineWithNetwork()

org.freedesktop.machine1(5)

RegisterService()

org.freedesktop.resolve1(5)

Release()

org.freedesktop.home1(5)

ReleaseControl()

org.freedesktop.login1(5)

ReleaseDevice()

org.freedesktop.login1(5)

ReleaseHome()

org.freedesktop.home1(5)

ReleaseSession()

org.freedesktop.login1(5)

Reload()

org.freedesktop.network1(5), org.freedesktop.systemd1(5)

ReloadOrRestart()

org.freedesktop.systemd1(5)

ReloadOrRestartUnit()

org.freedesktop.systemd1(5)

ReloadOrTryRestart()

org.freedesktop.systemd1(5)

ReloadOrTryRestartUnit()

org.freedesktop.systemd1(5)

ReloadUnit()

org.freedesktop.systemd1(5)

Remove()

org.freedesktop.home1(5), org.freedesktop.portable1(5)

RemoveHome()

org.freedesktop.home1(5)

RemoveImage()

org.freedesktop.machine1(5), org.freedesktop.portable1(5)

RenameImage()

org.freedesktop.machine1(5)

Renew()

org.freedesktop.network1(5)

RenewLink()

org.freedesktop.network1(5)

ResetFailed()

org.freedesktop.systemd1(5)

ResetFailedUnit()

org.freedesktop.systemd1(5)

ResetServerFeatures()

org.freedesktop.resolve1(5)

ResetStatistics()

org.freedesktop.resolve1(5)

Resize()

org.freedesktop.home1(5)

ResizeHome()

org.freedesktop.home1(5)

ResolveAddress()

org.freedesktop.resolve1(5)

ResolveHostname()

org.freedesktop.resolve1(5)

ResolveRecord()

org.freedesktop.resolve1(5)

ResolveService()

org.freedesktop.resolve1(5)

Restart()

org.freedesktop.systemd1(5)

RestartUnit()

org.freedesktop.systemd1(5)

Revert()

org.freedesktop.resolve1(5)

RevertDNS()

org.freedesktop.network1(5)

RevertLink()

org.freedesktop.resolve1(5)

RevertLinkDNS()

org.freedesktop.network1(5)

RevertLinkNTP()

org.freedesktop.network1(5)

RevertNTP()

org.freedesktop.network1(5)

RevertUnitFiles()

org.freedesktop.systemd1(5)

ScheduleShutdown()

org.freedesktop.login1(5)

SetBrightness()

org.freedesktop.login1(5)

SetChassis()

org.freedesktop.hostname1(5)

SetClass()

org.freedesktop.login1(5)

SetDNS()

org.freedesktop.network1(5), org.freedesktop.resolve1(5)

SetDNSEx()

org.freedesktop.network1(5), org.freedesktop.resolve1(5)

SetDNSOverTLS()

org.freedesktop.network1(5), org.freedesktop.resolve1(5)

SetDNSSEC()

org.freedesktop.network1(5), org.freedesktop.resolve1(5)

SetDNSSECNegativeTrustAnchors()

org.freedesktop.network1(5), org.freedesktop.resolve1(5)

SetDefaultRoute()

org.freedesktop.network1(5), org.freedesktop.resolve1(5)

SetDefaultTarget()

org.freedesktop.systemd1(5)

SetDeployment()

org.freedesktop.hostname1(5)

SetDisplay()

org.freedesktop.login1(5)

SetDomains()

org.freedesktop.network1(5), org.freedesktop.resolve1(5)

SetEnvironment()

org.freedesktop.systemd1(5)

SetExitCode()

org.freedesktop.systemd1(5)

SetHostname()

org.freedesktop.hostname1(5)

SetIconName()

org.freedesktop.hostname1(5)

SetIdleHint()

org.freedesktop.login1(5)

SetImageLimit()

org.freedesktop.machine1(5), org.freedesktop.portable1(5)

SetLLMNR()

org.freedesktop.network1(5), org.freedesktop.resolve1(5)

SetLimit()

org.freedesktop.portable1(5)

SetLinkDNS()

org.freedesktop.network1(5), org.freedesktop.resolve1(5)

SetLinkDNSEx()

org.freedesktop.network1(5), org.freedesktop.resolve1(5)

SetLinkDNSOverTLS()

org.freedesktop.network1(5), org.freedesktop.resolve1(5)

SetLinkDNSSEC()

org.freedesktop.network1(5), org.freedesktop.resolve1(5)

SetLinkDNSSECNegativeTrustAnchors()

org.freedesktop.network1(5), org.freedesktop.resolve1(5)

SetLinkDefaultRoute()

org.freedesktop.network1(5), org.freedesktop.resolve1(5)

SetLinkDomains()

org.freedesktop.network1(5), org.freedesktop.resolve1(5)

SetLinkLLMNR()

org.freedesktop.network1(5), org.freedesktop.resolve1(5)

SetLinkMulticastDNS()

org.freedesktop.network1(5), org.freedesktop.resolve1(5)

SetLinkNTP()

org.freedesktop.network1(5)

SetLocalRTC()

org.freedesktop.timedate1(5)

SetLocale()

org.freedesktop.locale1(5)

SetLocation()

org.freedesktop.hostname1(5)

SetLockedHint()

org.freedesktop.login1(5)

SetMulticastDNS()

org.freedesktop.network1(5), org.freedesktop.resolve1(5)

SetNTP()

org.freedesktop.network1(5), org.freedesktop.timedate1(5)

SetPoolLimit()

org.freedesktop.machine1(5), org.freedesktop.portable1(5)

SetPrettyHostname()

org.freedesktop.hostname1(5)

SetProperties()

org.freedesktop.systemd1(5)

SetRebootParameter()

org.freedesktop.login1(5)

SetRebootToBootLoaderEntry()

org.freedesktop.login1(5)

SetRebootToBootLoaderMenu()

org.freedesktop.login1(5)

SetRebootToFirmwareSetup()

org.freedesktop.login1(5)

SetShowStatus()

org.freedesktop.systemd1(5)

SetStaticHostname()

org.freedesktop.hostname1(5)

SetTTY()

org.freedesktop.login1(5)

SetTime()

org.freedesktop.timedate1(5)

SetTimezone()

org.freedesktop.timedate1(5)

SetType()

org.freedesktop.login1(5)

SetUnitProperties()

org.freedesktop.systemd1(5)

SetUserLinger()

org.freedesktop.login1(5)

SetVConsoleKeyboard()

org.freedesktop.locale1(5)

SetWallMessage()

org.freedesktop.login1(5)

SetX11Keyboard()

org.freedesktop.locale1(5)

Sleep()

org.freedesktop.login1(5)

SoftReboot()

org.freedesktop.systemd1(5)

Start()

org.freedesktop.systemd1(5)

StartAuxiliaryScope()

org.freedesktop.systemd1(5)

StartTransientUnit()

org.freedesktop.systemd1(5)

StartUnit()

org.freedesktop.systemd1(5)

StartUnitReplace()

org.freedesktop.systemd1(5)

StartUnitWithFlags()

org.freedesktop.systemd1(5)

Stop()

org.freedesktop.systemd1(5)

StopUnit()

org.freedesktop.systemd1(5)

Subscribe()

org.freedesktop.systemd1(5)

Suspend()

org.freedesktop.login1(5)

SuspendThenHibernate()

org.freedesktop.login1(5)

SuspendThenHibernateWithFlags()

org.freedesktop.login1(5)

SuspendWithFlags()

org.freedesktop.login1(5)

SwitchRoot()

org.freedesktop.systemd1(5)

SwitchTo()

org.freedesktop.login1(5)

SwitchToNext()

org.freedesktop.login1(5)

SwitchToPrevious()

org.freedesktop.login1(5)

TakeControl()

org.freedesktop.login1(5)

TakeDevice()

org.freedesktop.login1(5)

Terminate()

org.freedesktop.login1(5), org.freedesktop.machine1(5)

TerminateMachine()

org.freedesktop.machine1(5)

TerminateSeat()

org.freedesktop.login1(5)

TerminateSession()

org.freedesktop.login1(5)

TerminateUser()

org.freedesktop.login1(5)

Thaw()

org.freedesktop.systemd1(5)

ThawUnit()

org.freedesktop.systemd1(5)

TryRestart()

org.freedesktop.systemd1(5)

TryRestartUnit()

org.freedesktop.systemd1(5)

Unlock()

org.freedesktop.home1(5), org.freedesktop.login1(5)

UnlockHome()

org.freedesktop.home1(5)

UnlockSession()

org.freedesktop.login1(5)

UnlockSessions()

org.freedesktop.login1(5)

UnmaskUnitFiles()

org.freedesktop.systemd1(5)

Unref()

org.freedesktop.systemd1(5)

UnrefUnit()

org.freedesktop.systemd1(5)

Unregister()

org.freedesktop.home1(5)

UnregisterHome()

org.freedesktop.home1(5)

UnregisterMachine()

org.freedesktop.machine1(5)

UnregisterService()

org.freedesktop.resolve1(5)

UnsetAndSetEnvironment()

org.freedesktop.systemd1(5)

UnsetEnvironment()

org.freedesktop.systemd1(5)

Unsubscribe()

org.freedesktop.systemd1(5)

Update()

org.freedesktop.home1(5)

UpdateEx()

org.freedesktop.home1(5)

UpdateHome()

org.freedesktop.home1(5)

UpdateHomeEx()

org.freedesktop.home1(5)

D-BUS PROPERTIES

Properties exposed in the D-Bus interface.

Accept

org.freedesktop.systemd1(5)

AccessSELinuxContext

org.freedesktop.systemd1(5)

AccuracyUSec

org.freedesktop.systemd1(5)

ActivationDetails

org.freedesktop.systemd1(5)

Active

org.freedesktop.login1(5)

ActiveEnterTimestamp

org.freedesktop.systemd1(5)

ActiveEnterTimestampMonotonic

org.freedesktop.systemd1(5)

ActiveExitTimestamp

org.freedesktop.systemd1(5)

ActiveExitTimestampMonotonic

org.freedesktop.systemd1(5)

ActiveSession

org.freedesktop.login1(5)

ActiveState

org.freedesktop.systemd1(5)

AddressState

org.freedesktop.network1(5)

AdministrativeState

org.freedesktop.network1(5)

After

org.freedesktop.systemd1(5)

AllowIsolate

org.freedesktop.systemd1(5)

AllowedCPUs

org.freedesktop.systemd1(5)

AllowedMemoryNodes

org.freedesktop.systemd1(5)

AmbientCapabilities

org.freedesktop.systemd1(5)

AppArmorProfile

org.freedesktop.systemd1(5)

Architecture

org.freedesktop.systemd1(5)

AssertResult

org.freedesktop.systemd1(5)

AssertTimestamp

org.freedesktop.systemd1(5)

AssertTimestampMonotonic

org.freedesktop.systemd1(5)

Asserts

org.freedesktop.systemd1(5)

Audit

org.freedesktop.login1(5)

AutoLogin

org.freedesktop.home1(5)

BPFProgram

org.freedesktop.systemd1(5)

Backlog

org.freedesktop.systemd1(5)

Before

org.freedesktop.systemd1(5)

BindIPv6Only

org.freedesktop.systemd1(5)

BindPaths

org.freedesktop.systemd1(5)

BindReadOnlyPaths

org.freedesktop.systemd1(5)

BindToDevice

org.freedesktop.systemd1(5)

BindsTo

org.freedesktop.systemd1(5)

BitRates

org.freedesktop.network1(5)

BlockIOAccounting

org.freedesktop.systemd1(5)

BlockIODeviceWeight

org.freedesktop.systemd1(5)

BlockIOReadBandwidth

org.freedesktop.systemd1(5)

BlockIOWeight

org.freedesktop.systemd1(5)

BlockIOWriteBandwidth

org.freedesktop.systemd1(5)

BlockInhibited

org.freedesktop.login1(5)

BootID

org.freedesktop.hostname1(5)

BootLoaderEntries

org.freedesktop.login1(5)

BoundBy

org.freedesktop.systemd1(5)

Broadcast

org.freedesktop.systemd1(5)

BusName

org.freedesktop.systemd1(5)

CPUAccounting

org.freedesktop.systemd1(5)

CPUAffinity

org.freedesktop.systemd1(5)

CPUAffinityFromNUMA

org.freedesktop.systemd1(5)

CPUQuotaPerSecUSec

org.freedesktop.systemd1(5)

CPUQuotaPeriodUSec

org.freedesktop.systemd1(5)

CPUSchedulingPolicy

org.freedesktop.systemd1(5)

CPUSchedulingPriority

org.freedesktop.systemd1(5)

CPUSchedulingResetOnFork

org.freedesktop.systemd1(5)

CPUShares

org.freedesktop.systemd1(5)

CPUUsageNSec

org.freedesktop.systemd1(5)

CPUWeight

org.freedesktop.systemd1(5)

CacheDirectory

org.freedesktop.systemd1(5)

CacheDirectoryMode

org.freedesktop.systemd1(5)

CacheDirectorySymlink

org.freedesktop.systemd1(5)

CacheStatistics

org.freedesktop.resolve1(5)

CanClean

org.freedesktop.systemd1(5)

CanFreeze

org.freedesktop.systemd1(5)

CanGraphical

org.freedesktop.login1(5)

CanIsolate

org.freedesktop.systemd1(5)

CanNTP

org.freedesktop.timedate1(5)

CanReload

org.freedesktop.systemd1(5)

CanStart

org.freedesktop.systemd1(5)

CanStop

org.freedesktop.systemd1(5)

CanTTY

org.freedesktop.login1(5)

CapabilityBoundingSet

org.freedesktop.systemd1(5)

CarrierState

org.freedesktop.network1(5)

Chassis

org.freedesktop.hostname1(5)

Class

org.freedesktop.login1(5), org.freedesktop.machine1(5)

CleanResult

org.freedesktop.systemd1(5)

CollectMode

org.freedesktop.systemd1(5)

ConditionResult

org.freedesktop.systemd1(5)

ConditionTimestamp

org.freedesktop.systemd1(5)

ConditionTimestampMonotonic

org.freedesktop.systemd1(5)

Conditions

org.freedesktop.systemd1(5)

ConfidentialVirtualization

org.freedesktop.systemd1(5)

ConfigurationDirectory

org.freedesktop.systemd1(5)

ConfigurationDirectoryMode

org.freedesktop.systemd1(5)

ConfirmSpawn

org.freedesktop.systemd1(5)

ConflictedBy

org.freedesktop.systemd1(5)

Conflicts

org.freedesktop.systemd1(5)

ConsistsOf

org.freedesktop.systemd1(5)

ControlGroup

org.freedesktop.systemd1(5)

ControlGroupId

org.freedesktop.systemd1(5)

ControlPID

org.freedesktop.systemd1(5)

Controller

org.freedesktop.systemd1(5)

CoredumpFilter

org.freedesktop.systemd1(5)

CoredumpReceive

org.freedesktop.systemd1(5)

CreationTimestamp

org.freedesktop.portable1(5)

CtrlAltDelBurstAction

org.freedesktop.systemd1(5)

CurrentDNSServer

org.freedesktop.resolve1(5)

CurrentDNSServerEx

org.freedesktop.resolve1(5)

DNS

org.freedesktop.resolve1(5)

DNSEx

org.freedesktop.resolve1(5)

DNSOverTLS

org.freedesktop.resolve1(5)

DNSSEC

org.freedesktop.resolve1(5)

DNSSECNegativeTrustAnchors

org.freedesktop.resolve1(5)

DNSSECStatistics

org.freedesktop.resolve1(5)

DNSSECSupported

org.freedesktop.resolve1(5)

DNSStubListener

org.freedesktop.resolve1(5)

DefaultBlockIOAccounting

org.freedesktop.systemd1(5)

DefaultCPUAccounting

org.freedesktop.systemd1(5)

DefaultDependencies

org.freedesktop.systemd1(5)

DefaultDeviceTimeoutUSec

org.freedesktop.systemd1(5)

DefaultHostname

org.freedesktop.hostname1(5)

DefaultIOAccounting

org.freedesktop.systemd1(5)

DefaultIPAccounting

org.freedesktop.systemd1(5)

DefaultLimitAS

org.freedesktop.systemd1(5)

DefaultLimitASSoft

org.freedesktop.systemd1(5)

DefaultLimitCORE

org.freedesktop.systemd1(5)

DefaultLimitCORESoft

org.freedesktop.systemd1(5)

DefaultLimitCPU

org.freedesktop.systemd1(5)

DefaultLimitCPUSoft

org.freedesktop.systemd1(5)

DefaultLimitDATA

org.freedesktop.systemd1(5)

DefaultLimitDATASoft

org.freedesktop.systemd1(5)

DefaultLimitFSIZE

org.freedesktop.systemd1(5)

DefaultLimitFSIZESoft

org.freedesktop.systemd1(5)

DefaultLimitLOCKS

org.freedesktop.systemd1(5)

DefaultLimitLOCKSSoft

org.freedesktop.systemd1(5)

DefaultLimitMEMLOCK

org.freedesktop.systemd1(5)

DefaultLimitMEMLOCKSoft

org.freedesktop.systemd1(5)

DefaultLimitMSGQUEUE

org.freedesktop.systemd1(5)

DefaultLimitMSGQUEUESoft

org.freedesktop.systemd1(5)

DefaultLimitNICE

org.freedesktop.systemd1(5)

DefaultLimitNICESoft

org.freedesktop.systemd1(5)

DefaultLimitNOFILE

org.freedesktop.systemd1(5)

DefaultLimitNOFILESoft

org.freedesktop.systemd1(5)

DefaultLimitNPROC

org.freedesktop.systemd1(5)

DefaultLimitNPROCSoft

org.freedesktop.systemd1(5)

DefaultLimitRSS

org.freedesktop.systemd1(5)

DefaultLimitRSSSoft

org.freedesktop.systemd1(5)

DefaultLimitRTPRIO

org.freedesktop.systemd1(5)

DefaultLimitRTPRIOSoft

org.freedesktop.systemd1(5)

DefaultLimitRTTIME

org.freedesktop.systemd1(5)

DefaultLimitRTTIMESoft

org.freedesktop.systemd1(5)

DefaultLimitSIGPENDING

org.freedesktop.systemd1(5)

DefaultLimitSIGPENDINGSoft

org.freedesktop.systemd1(5)

DefaultLimitSTACK

org.freedesktop.systemd1(5)

DefaultLimitSTACKSoft

org.freedesktop.systemd1(5)

DefaultMemoryAccounting

org.freedesktop.systemd1(5)

DefaultMemoryLow

org.freedesktop.systemd1(5)

DefaultMemoryMin

org.freedesktop.systemd1(5)

DefaultMemoryPressureThresholdUSec

org.freedesktop.systemd1(5)

DefaultMemoryPressureWatch

org.freedesktop.systemd1(5)

DefaultOOMPolicy

org.freedesktop.systemd1(5)

DefaultOOMScoreAdjust

org.freedesktop.systemd1(5)

DefaultRestartUSec

org.freedesktop.systemd1(5)

DefaultRoute

org.freedesktop.resolve1(5)

DefaultStandardError

org.freedesktop.systemd1(5)

DefaultStandardOutput

org.freedesktop.systemd1(5)

DefaultStartLimitBurst

org.freedesktop.systemd1(5)

DefaultStartLimitIntervalUSec

org.freedesktop.systemd1(5)

DefaultStartupMemoryLow

org.freedesktop.systemd1(5)

DefaultTasksAccounting

org.freedesktop.systemd1(5)

DefaultTasksMax

org.freedesktop.systemd1(5)

DefaultTimeoutAbortUSec

org.freedesktop.systemd1(5)

DefaultTimeoutStartUSec

org.freedesktop.systemd1(5)

DefaultTimeoutStopUSec

org.freedesktop.systemd1(5)

DefaultTimerAccuracyUSec

org.freedesktop.systemd1(5)

DeferAcceptUSec

org.freedesktop.systemd1(5)

DelayInhibited

org.freedesktop.login1(5)

Delegate

org.freedesktop.systemd1(5)

DelegateControllers

org.freedesktop.systemd1(5)

DelegateSubgroup

org.freedesktop.systemd1(5)

Deployment

org.freedesktop.hostname1(5)

Description

org.freedesktop.network1(5), org.freedesktop.systemd1(5)

Desktop

org.freedesktop.login1(5)

DeviceAllow

org.freedesktop.systemd1(5)

DevicePolicy

org.freedesktop.systemd1(5)

DirectoryMode

org.freedesktop.systemd1(5)

DisableControllers

org.freedesktop.systemd1(5)

Display

org.freedesktop.login1(5)

Docked

org.freedesktop.login1(5)

Documentation

org.freedesktop.systemd1(5)

Domains

org.freedesktop.resolve1(5)

DropInPaths

org.freedesktop.systemd1(5)

DynamicUser

org.freedesktop.systemd1(5)

EffectiveCPUs

org.freedesktop.systemd1(5)

EffectiveMemoryHigh

org.freedesktop.systemd1(5)

EffectiveMemoryMax

org.freedesktop.systemd1(5)

EffectiveMemoryNodes

org.freedesktop.systemd1(5)

EffectiveTasksMax

org.freedesktop.systemd1(5)

EnableWallMessages

org.freedesktop.login1(5)

Environment

org.freedesktop.systemd1(5)

EnvironmentFiles

org.freedesktop.systemd1(5)

ExecActivate

org.freedesktop.systemd1(5)

ExecCondition

org.freedesktop.systemd1(5)

ExecConditionEx

org.freedesktop.systemd1(5)

ExecDeactivate

org.freedesktop.systemd1(5)

ExecMainCode

org.freedesktop.systemd1(5)

ExecMainExitTimestamp

org.freedesktop.systemd1(5)

ExecMainExitTimestampMonotonic

org.freedesktop.systemd1(5)

ExecMainHandoffTimestamp

org.freedesktop.systemd1(5)

ExecMainHandoffTimestampMonotonic

org.freedesktop.systemd1(5)

ExecMainPID

org.freedesktop.systemd1(5)

ExecMainStartTimestamp

org.freedesktop.systemd1(5)

ExecMainStartTimestampMonotonic

org.freedesktop.systemd1(5)

ExecMainStatus

org.freedesktop.systemd1(5)

ExecMount

org.freedesktop.systemd1(5)

ExecPaths

org.freedesktop.systemd1(5)

ExecReload

org.freedesktop.systemd1(5)

ExecReloadEx

org.freedesktop.systemd1(5)

ExecRemount

org.freedesktop.systemd1(5)

ExecSearchPath

org.freedesktop.systemd1(5)

ExecStart

org.freedesktop.systemd1(5)

ExecStartEx

org.freedesktop.systemd1(5)

ExecStartPost

org.freedesktop.systemd1(5)

ExecStartPostEx

org.freedesktop.systemd1(5)

ExecStartPre

org.freedesktop.systemd1(5)

ExecStartPreEx

org.freedesktop.systemd1(5)

ExecStop

org.freedesktop.systemd1(5)

ExecStopEx

org.freedesktop.systemd1(5)

ExecStopPost

org.freedesktop.systemd1(5)

ExecStopPostEx

org.freedesktop.systemd1(5)

ExecStopPre

org.freedesktop.systemd1(5)

ExecUnmount

org.freedesktop.systemd1(5)

ExitCode

org.freedesktop.systemd1(5)

ExitType

org.freedesktop.systemd1(5)

ExtensionDirectories

org.freedesktop.systemd1(5)

ExtensionImagePolicy

org.freedesktop.systemd1(5)

ExtensionImages

org.freedesktop.systemd1(5)

ExtraOptions

org.freedesktop.systemd1(5)

FailureAction

org.freedesktop.systemd1(5)

FailureActionExitStatus

org.freedesktop.systemd1(5)

FallbackDNS

org.freedesktop.resolve1(5)

FallbackDNSEx

org.freedesktop.resolve1(5)

Features

org.freedesktop.systemd1(5)

FileDescriptorName

org.freedesktop.systemd1(5)

FileDescriptorStoreMax

org.freedesktop.systemd1(5)

FileDescriptorStorePreserve

org.freedesktop.systemd1(5)

FinalKillSignal

org.freedesktop.systemd1(5)

FinishTimestamp

org.freedesktop.systemd1(5)

FinishTimestampMonotonic

org.freedesktop.systemd1(5)

FirmwareDate

org.freedesktop.hostname1(5)

FirmwareTimestamp

org.freedesktop.systemd1(5)

FirmwareTimestampMonotonic

org.freedesktop.systemd1(5)

FirmwareVendor

org.freedesktop.hostname1(5)

FirmwareVersion

org.freedesktop.hostname1(5)

FixedRandomDelay

org.freedesktop.systemd1(5)

FlushPending

org.freedesktop.systemd1(5)

Following

org.freedesktop.systemd1(5)

ForceUnmount

org.freedesktop.systemd1(5)

FragmentPath

org.freedesktop.systemd1(5)

FreeBind

org.freedesktop.systemd1(5)

FreezerState

org.freedesktop.systemd1(5)

GID

org.freedesktop.login1(5), org.freedesktop.systemd1(5)

GeneratorsFinishTimestamp

org.freedesktop.systemd1(5)

GeneratorsFinishTimestampMonotonic

org.freedesktop.systemd1(5)

GeneratorsStartTimestamp

org.freedesktop.systemd1(5)

GeneratorsStartTimestampMonotonic

org.freedesktop.systemd1(5)

Group

org.freedesktop.systemd1(5)

GuessMainPID

org.freedesktop.systemd1(5)

HandleHibernateKey

org.freedesktop.login1(5)

HandleHibernateKeyLongPress

org.freedesktop.login1(5)

HandleLidSwitch

org.freedesktop.login1(5)

HandleLidSwitchDocked

org.freedesktop.login1(5)

HandleLidSwitchExternalPower

org.freedesktop.login1(5)

HandlePowerKey

org.freedesktop.login1(5)

HandlePowerKeyLongPress

org.freedesktop.login1(5)

HandleRebootKey

org.freedesktop.login1(5)

HandleRebootKeyLongPress

org.freedesktop.login1(5)

HandleSuspendKey

org.freedesktop.login1(5)

HandleSuspendKeyLongPress

org.freedesktop.login1(5)

HardwareModel

org.freedesktop.hostname1(5)

HardwareVendor

org.freedesktop.hostname1(5)

HoldoffTimeoutUSec

org.freedesktop.login1(5)

HomeURL

org.freedesktop.hostname1(5)

Hostname

org.freedesktop.hostname1(5)

HostnameSource

org.freedesktop.hostname1(5)

IOAccounting

org.freedesktop.systemd1(5)

IODeviceLatencyTargetUSec

org.freedesktop.systemd1(5)

IODeviceWeight

org.freedesktop.systemd1(5)

IOReadBandwidthMax

org.freedesktop.systemd1(5)

IOReadBytes

org.freedesktop.systemd1(5)

IOReadIOPSMax

org.freedesktop.systemd1(5)

IOReadOperations

org.freedesktop.systemd1(5)

IOSchedulingClass

org.freedesktop.systemd1(5)

IOSchedulingPriority

org.freedesktop.systemd1(5)

IOWeight

org.freedesktop.systemd1(5)

IOWriteBandwidthMax

org.freedesktop.systemd1(5)

IOWriteBytes

org.freedesktop.systemd1(5)

IOWriteIOPSMax

org.freedesktop.systemd1(5)

IOWriteOperations

org.freedesktop.systemd1(5)

IPAccounting

org.freedesktop.systemd1(5)

IPAddressAllow

org.freedesktop.systemd1(5)

IPAddressDeny

org.freedesktop.systemd1(5)

IPCNamespacePath

org.freedesktop.systemd1(5)

IPEgressBytes

org.freedesktop.systemd1(5)

IPEgressFilterPath

org.freedesktop.systemd1(5)

IPEgressPackets

org.freedesktop.systemd1(5)

IPIngressBytes

org.freedesktop.systemd1(5)

IPIngressFilterPath

org.freedesktop.systemd1(5)

IPIngressPackets

org.freedesktop.systemd1(5)

IPTOS

org.freedesktop.systemd1(5)

IPTTL

org.freedesktop.systemd1(5)

IPv4AddressState

org.freedesktop.network1(5)

IPv6AddressState

org.freedesktop.network1(5)

IconName

org.freedesktop.hostname1(5)

Id

org.freedesktop.import1(5), org.freedesktop.login1(5), org.freedesktop.machine1(5), org.freedesktop.systemd1(5)

IdleAction

org.freedesktop.login1(5)

IdleActionUSec

org.freedesktop.login1(5)

IdleHint

org.freedesktop.login1(5)

IdleSinceHint

org.freedesktop.login1(5)

IdleSinceHintMonotonic

org.freedesktop.login1(5)

IgnoreOnIsolate

org.freedesktop.systemd1(5)

IgnoreSIGPIPE

org.freedesktop.systemd1(5)

ImportCredential

org.freedesktop.systemd1(5)

InaccessiblePaths

org.freedesktop.systemd1(5)

InactiveEnterTimestamp

org.freedesktop.systemd1(5)

InactiveEnterTimestampMonotonic

org.freedesktop.systemd1(5)

InactiveExitTimestamp

org.freedesktop.systemd1(5)

InactiveExitTimestampMonotonic

org.freedesktop.systemd1(5)

InhibitDelayMaxUSec

org.freedesktop.login1(5)

InhibitorsMax

org.freedesktop.login1(5)

InitRDGeneratorsFinishTimestamp

org.freedesktop.systemd1(5)

InitRDGeneratorsFinishTimestampMonotonic

org.freedesktop.systemd1(5)

InitRDGeneratorsStartTimestamp

org.freedesktop.systemd1(5)

InitRDGeneratorsStartTimestampMonotonic

org.freedesktop.systemd1(5)

InitRDSecurityFinishTimestamp

org.freedesktop.systemd1(5)

InitRDSecurityFinishTimestampMonotonic

org.freedesktop.systemd1(5)

InitRDSecurityStartTimestamp

org.freedesktop.systemd1(5)

InitRDSecurityStartTimestampMonotonic

org.freedesktop.systemd1(5)

InitRDTimestamp

org.freedesktop.systemd1(5)

InitRDTimestampMonotonic

org.freedesktop.systemd1(5)

InitRDUnitsLoadFinishTimestamp

org.freedesktop.systemd1(5)

InitRDUnitsLoadFinishTimestampMonotonic

org.freedesktop.systemd1(5)

InitRDUnitsLoadStartTimestamp

org.freedesktop.systemd1(5)

InitRDUnitsLoadStartTimestampMonotonic

org.freedesktop.systemd1(5)

InvocationID

org.freedesktop.systemd1(5)

Job

org.freedesktop.systemd1(5)

JobRunningTimeoutUSec

org.freedesktop.systemd1(5)

JobTimeoutAction

org.freedesktop.systemd1(5)

JobTimeoutRebootArgument

org.freedesktop.systemd1(5)

JobTimeoutUSec

org.freedesktop.systemd1(5)

JobType

org.freedesktop.systemd1(5)

JoinsNamespaceOf

org.freedesktop.systemd1(5)

KExecWatchdogUSec

org.freedesktop.systemd1(5)

KeepAlive

org.freedesktop.systemd1(5)

KeepAliveIntervalUSec

org.freedesktop.systemd1(5)

KeepAliveProbes

org.freedesktop.systemd1(5)

KeepAliveTimeUSec

org.freedesktop.systemd1(5)

KernelName

org.freedesktop.hostname1(5)

KernelRelease

org.freedesktop.hostname1(5)

KernelTimestamp

org.freedesktop.systemd1(5)

KernelTimestampMonotonic

org.freedesktop.systemd1(5)

KernelVersion

org.freedesktop.hostname1(5)

KeyringMode

org.freedesktop.systemd1(5)

KillExcludeUsers

org.freedesktop.login1(5)

KillMode

org.freedesktop.systemd1(5)

KillOnlyUsers

org.freedesktop.login1(5)

KillSignal

org.freedesktop.systemd1(5)

KillUserProcesses

org.freedesktop.login1(5)

LLMNR

org.freedesktop.resolve1(5)

LLMNRHostname

org.freedesktop.resolve1(5)

LastTriggerUSec

org.freedesktop.systemd1(5)

LastTriggerUSecMonotonic

org.freedesktop.systemd1(5)

LazyUnmount

org.freedesktop.systemd1(5)

Leader

org.freedesktop.login1(5), org.freedesktop.machine1(5)

Leases

org.freedesktop.network1(5)

LidClosed

org.freedesktop.login1(5)

Limit

org.freedesktop.portable1(5)

LimitAS

org.freedesktop.systemd1(5)

LimitASSoft

org.freedesktop.systemd1(5)

LimitCORE

org.freedesktop.systemd1(5)

LimitCORESoft

org.freedesktop.systemd1(5)

LimitCPU

org.freedesktop.systemd1(5)

LimitCPUSoft

org.freedesktop.systemd1(5)

LimitDATA

org.freedesktop.systemd1(5)

LimitDATASoft

org.freedesktop.systemd1(5)

LimitExclusive

org.freedesktop.portable1(5)

LimitFSIZE

org.freedesktop.systemd1(5)

LimitFSIZESoft

org.freedesktop.systemd1(5)

LimitLOCKS

org.freedesktop.systemd1(5)

LimitLOCKSSoft

org.freedesktop.systemd1(5)

LimitMEMLOCK

org.freedesktop.systemd1(5)

LimitMEMLOCKSoft

org.freedesktop.systemd1(5)

LimitMSGQUEUE

org.freedesktop.systemd1(5)

LimitMSGQUEUESoft

org.freedesktop.systemd1(5)

LimitNICE

org.freedesktop.systemd1(5)

LimitNICESoft

org.freedesktop.systemd1(5)

LimitNOFILE

org.freedesktop.systemd1(5)

LimitNOFILESoft

org.freedesktop.systemd1(5)

LimitNPROC

org.freedesktop.systemd1(5)

LimitNPROCSoft

org.freedesktop.systemd1(5)

LimitRSS

org.freedesktop.systemd1(5)

LimitRSSSoft

org.freedesktop.systemd1(5)

LimitRTPRIO

org.freedesktop.systemd1(5)

LimitRTPRIOSoft

org.freedesktop.systemd1(5)

LimitRTTIME

org.freedesktop.systemd1(5)

LimitRTTIMESoft

org.freedesktop.systemd1(5)

LimitSIGPENDING

org.freedesktop.systemd1(5)

LimitSIGPENDINGSoft

org.freedesktop.systemd1(5)

LimitSTACK

org.freedesktop.systemd1(5)

LimitSTACKSoft

org.freedesktop.systemd1(5)

Linger

org.freedesktop.login1(5)

Listen

org.freedesktop.systemd1(5)

LoadCredential

org.freedesktop.systemd1(5)

LoadCredentialEncrypted

org.freedesktop.systemd1(5)

LoadError

org.freedesktop.systemd1(5)

LoadState

org.freedesktop.systemd1(5)

LoaderTimestamp

org.freedesktop.systemd1(5)

LoaderTimestampMonotonic

org.freedesktop.systemd1(5)

Local

org.freedesktop.import1(5)

LocalRTC

org.freedesktop.timedate1(5)

Locale

org.freedesktop.locale1(5)

Location

org.freedesktop.hostname1(5)

LockPersonality

org.freedesktop.systemd1(5)

LockedHint

org.freedesktop.login1(5)

LogExtraFields

org.freedesktop.systemd1(5)

LogFilterPatterns

org.freedesktop.systemd1(5)

LogLevel

org.freedesktop.LogControl1(5), org.freedesktop.systemd1(5)

LogLevelMax

org.freedesktop.systemd1(5)

LogNamespace

org.freedesktop.systemd1(5)

LogRateLimitBurst

org.freedesktop.systemd1(5)

LogRateLimitIntervalUSec

org.freedesktop.systemd1(5)

LogTarget

org.freedesktop.LogControl1(5), org.freedesktop.systemd1(5)

LogsDirectory

org.freedesktop.systemd1(5)

LogsDirectoryMode

org.freedesktop.systemd1(5)

LogsDirectorySymlink

org.freedesktop.systemd1(5)

MachineID

org.freedesktop.hostname1(5)

MainPID

org.freedesktop.systemd1(5)

MakeDirectory

org.freedesktop.systemd1(5)

ManagedOOMMemoryPressure

org.freedesktop.systemd1(5)

ManagedOOMMemoryPressureLimit

org.freedesktop.systemd1(5)

ManagedOOMPreference

org.freedesktop.systemd1(5)

ManagedOOMSwap

org.freedesktop.systemd1(5)

Mark

org.freedesktop.systemd1(5)

Markers

org.freedesktop.systemd1(5)

MatchDriver

org.freedesktop.network1(5)

MatchMAC

org.freedesktop.network1(5)

MatchName

org.freedesktop.network1(5)

MatchPath

org.freedesktop.network1(5)

MatchType

org.freedesktop.network1(5)

MaxConnections

org.freedesktop.systemd1(5)

MaxConnectionsPerSource

org.freedesktop.systemd1(5)

MemoryAccounting

org.freedesktop.systemd1(5)

MemoryAvailable

org.freedesktop.systemd1(5)

MemoryCurrent

org.freedesktop.systemd1(5)

MemoryDenyWriteExecute

org.freedesktop.systemd1(5)

MemoryHigh

org.freedesktop.systemd1(5)

MemoryKSM

org.freedesktop.systemd1(5)

MemoryLimit

org.freedesktop.systemd1(5)

MemoryLow

org.freedesktop.systemd1(5)

MemoryMax

org.freedesktop.systemd1(5)

MemoryMin

org.freedesktop.systemd1(5)

MemoryPeak

org.freedesktop.systemd1(5)

MemoryPressureThresholdUSec

org.freedesktop.systemd1(5)

MemoryPressureWatch

org.freedesktop.systemd1(5)

MemorySwapCurrent

org.freedesktop.systemd1(5)

MemorySwapMax

org.freedesktop.systemd1(5)

MemorySwapPeak

org.freedesktop.systemd1(5)

MemoryZSwapCurrent

org.freedesktop.systemd1(5)

MemoryZSwapMax

org.freedesktop.systemd1(5)

MemoryZSwapWriteback

org.freedesktop.systemd1(5)

MessageQueueMaxMessages

org.freedesktop.systemd1(5)

MessageQueueMessageSize

org.freedesktop.systemd1(5)

ModificationTimestamp

org.freedesktop.portable1(5)

MountAPIVFS

org.freedesktop.systemd1(5)

MountFlags

org.freedesktop.systemd1(5)

MountImagePolicy

org.freedesktop.systemd1(5)

MountImages

org.freedesktop.systemd1(5)

MulticastDNS

org.freedesktop.resolve1(5)

NAccepted

org.freedesktop.systemd1(5)

NAutoVTs

org.freedesktop.login1(5)

NConnections

org.freedesktop.systemd1(5)

NCurrentInhibitors

org.freedesktop.login1(5)

NCurrentSessions

org.freedesktop.login1(5)

NFTSet

org.freedesktop.systemd1(5)

NFailedJobs

org.freedesktop.systemd1(5)

NFailedUnits

org.freedesktop.systemd1(5)

NFileDescriptorStore

org.freedesktop.systemd1(5)

NInstalledJobs

org.freedesktop.systemd1(5)

NJobs

org.freedesktop.systemd1(5)

NNames

org.freedesktop.systemd1(5)

NRefused

org.freedesktop.systemd1(5)

NRestarts

org.freedesktop.systemd1(5)

NTP

org.freedesktop.timedate1(5)

NTPSynchronized

org.freedesktop.timedate1(5)

NUMAMask

org.freedesktop.systemd1(5)

NUMAPolicy

org.freedesktop.systemd1(5)

Name

org.freedesktop.login1(5), org.freedesktop.machine1(5), org.freedesktop.portable1(5)

Names

org.freedesktop.systemd1(5)

NamespaceId

org.freedesktop.network1(5)

NamespaceNSID

org.freedesktop.network1(5)

NeedDaemonReload

org.freedesktop.systemd1(5)

NetworkInterfaces

org.freedesktop.machine1(5)

NetworkNamespacePath

org.freedesktop.systemd1(5)

NextElapseUSecMonotonic

org.freedesktop.systemd1(5)

NextElapseUSecRealtime

org.freedesktop.systemd1(5)

Nice

org.freedesktop.systemd1(5)

NoDelay

org.freedesktop.systemd1(5)

NoExecPaths

org.freedesktop.systemd1(5)

NoNewPrivileges

org.freedesktop.systemd1(5)

NonBlocking

org.freedesktop.systemd1(5)

NotifyAccess

org.freedesktop.systemd1(5)

OOMPolicy

org.freedesktop.systemd1(5)

OOMScoreAdjust

org.freedesktop.systemd1(5)

OnClockChange

org.freedesktop.systemd1(5)

OnExternalPower

org.freedesktop.login1(5)

OnFailure

org.freedesktop.systemd1(5)

OnFailureJobMode

org.freedesktop.systemd1(5)

OnFailureOf

org.freedesktop.systemd1(5)

OnSuccess

org.freedesktop.systemd1(5)

OnSuccessJobMode

org.freedesktop.systemd1(5)

OnSuccessOf

org.freedesktop.systemd1(5)

OnTimezoneChange

org.freedesktop.systemd1(5)

OnlineState

org.freedesktop.network1(5)

OpenFile

org.freedesktop.systemd1(5)

OperatingSystemCPEName

org.freedesktop.hostname1(5)

OperatingSystemPrettyName

org.freedesktop.hostname1(5)

OperatingSystemSupportEnd

org.freedesktop.hostname1(5)

OperationalState

org.freedesktop.network1(5)

Options

org.freedesktop.systemd1(5)

PAMName

org.freedesktop.systemd1(5)

PIDFile

org.freedesktop.systemd1(5)

PartOf

org.freedesktop.systemd1(5)

PassCredentials

org.freedesktop.systemd1(5)

PassEnvironment

org.freedesktop.systemd1(5)

PassFileDescriptorsToExec

org.freedesktop.systemd1(5)

PassPacketInfo

org.freedesktop.systemd1(5)

PassSecurity

org.freedesktop.systemd1(5)

Path

org.freedesktop.portable1(5)

Paths

org.freedesktop.systemd1(5)

Perpetual

org.freedesktop.systemd1(5)

Persistent

org.freedesktop.systemd1(5)

Personality

org.freedesktop.systemd1(5)

PipeSize

org.freedesktop.systemd1(5)

PollLimitBurst

org.freedesktop.systemd1(5)

PollLimitIntervalUSec

org.freedesktop.systemd1(5)

PoolLimit

org.freedesktop.machine1(5), org.freedesktop.portable1(5)

PoolPath

org.freedesktop.machine1(5), org.freedesktop.portable1(5)

PoolUsage

org.freedesktop.machine1(5), org.freedesktop.portable1(5)

PreparingForShutdown

org.freedesktop.login1(5)

PreparingForSleep

org.freedesktop.login1(5)

PrettyHostname

org.freedesktop.hostname1(5)

Priority

org.freedesktop.systemd1(5)

PrivateDevices

org.freedesktop.systemd1(5)

PrivateIPC

org.freedesktop.systemd1(5)

PrivateMounts

org.freedesktop.systemd1(5)

PrivateNetwork

org.freedesktop.systemd1(5)

PrivateTmp

org.freedesktop.systemd1(5)

PrivateUsers

org.freedesktop.systemd1(5)

ProcSubset

org.freedesktop.systemd1(5)

Profiles

org.freedesktop.portable1(5)

Progress

org.freedesktop.import1(5), org.freedesktop.systemd1(5)

PropagatesReloadTo

org.freedesktop.systemd1(5)

PropagatesStopTo

org.freedesktop.systemd1(5)

ProtectClock

org.freedesktop.systemd1(5)

ProtectControlGroups

org.freedesktop.systemd1(5)

ProtectHome

org.freedesktop.systemd1(5)

ProtectHostname

org.freedesktop.systemd1(5)

ProtectKernelLogs

org.freedesktop.systemd1(5)

ProtectKernelModules

org.freedesktop.systemd1(5)

ProtectKernelTunables

org.freedesktop.systemd1(5)

ProtectProc

org.freedesktop.systemd1(5)

ProtectSystem

org.freedesktop.systemd1(5)

RTCTimeUSec

org.freedesktop.timedate1(5)

RandomizedDelayUSec

org.freedesktop.systemd1(5)

ReadOnly

org.freedesktop.portable1(5)

ReadOnlyPaths

org.freedesktop.systemd1(5)

ReadWriteOnly

org.freedesktop.systemd1(5)

ReadWritePaths

org.freedesktop.systemd1(5)

RebootArgument

org.freedesktop.systemd1(5)

RebootParameter

org.freedesktop.login1(5)

RebootToBootLoaderEntry

org.freedesktop.login1(5)

RebootToBootLoaderMenu

org.freedesktop.login1(5)

RebootToFirmwareSetup

org.freedesktop.login1(5)

RebootWatchdogUSec

org.freedesktop.systemd1(5)

ReceiveBuffer

org.freedesktop.systemd1(5)

Refs

org.freedesktop.systemd1(5)

RefuseManualStart

org.freedesktop.systemd1(5)

RefuseManualStop

org.freedesktop.systemd1(5)

ReloadPropagatedFrom

org.freedesktop.systemd1(5)

ReloadResult

org.freedesktop.systemd1(5)

ReloadSignal

org.freedesktop.systemd1(5)

RemainAfterElapse

org.freedesktop.systemd1(5)

RemainAfterExit

org.freedesktop.systemd1(5)

Remote

org.freedesktop.import1(5), org.freedesktop.login1(5)

RemoteHost

org.freedesktop.login1(5)

RemoteUser

org.freedesktop.login1(5)

RemoveIPC

org.freedesktop.login1(5), org.freedesktop.systemd1(5)

RemoveOnStop

org.freedesktop.systemd1(5)

RequiredBy

org.freedesktop.systemd1(5)

Requires

org.freedesktop.systemd1(5)

RequiresMountsFor

org.freedesktop.systemd1(5)

Requisite

org.freedesktop.systemd1(5)

RequisiteOf

org.freedesktop.systemd1(5)

ResolvConfMode

org.freedesktop.resolve1(5)

Restart

org.freedesktop.systemd1(5)

RestartForceExitStatus

org.freedesktop.systemd1(5)

RestartKillSignal

org.freedesktop.systemd1(5)

RestartMaxDelayUSec

org.freedesktop.systemd1(5)

RestartMode

org.freedesktop.systemd1(5)

RestartPreventExitStatus

org.freedesktop.systemd1(5)

RestartSteps

org.freedesktop.systemd1(5)

RestartUSec

org.freedesktop.systemd1(5)

RestartUSecNext

org.freedesktop.systemd1(5)

RestrictAddressFamilies

org.freedesktop.systemd1(5)

RestrictFileSystems

org.freedesktop.systemd1(5)

RestrictNamespaces

org.freedesktop.systemd1(5)

RestrictNetworkInterfaces

org.freedesktop.systemd1(5)

RestrictRealtime

org.freedesktop.systemd1(5)

RestrictSUIDSGID

org.freedesktop.systemd1(5)

Result

org.freedesktop.systemd1(5)

ReusePort

org.freedesktop.systemd1(5)

RootDirectory

org.freedesktop.machine1(5), org.freedesktop.systemd1(5)

RootDirectoryStartOnly

org.freedesktop.systemd1(5)

RootEphemeral

org.freedesktop.systemd1(5)

RootHash

org.freedesktop.systemd1(5)

RootHashPath

org.freedesktop.systemd1(5)

RootHashSignature

org.freedesktop.systemd1(5)

RootHashSignaturePath

org.freedesktop.systemd1(5)

RootImage

org.freedesktop.systemd1(5)

RootImageOptions

org.freedesktop.systemd1(5)

RootImagePolicy

org.freedesktop.systemd1(5)

RootVerity

org.freedesktop.systemd1(5)

RuntimeDirectory

org.freedesktop.systemd1(5)

RuntimeDirectoryInodesMax

org.freedesktop.login1(5)

RuntimeDirectoryMode

org.freedesktop.systemd1(5)

RuntimeDirectoryPreserve

org.freedesktop.systemd1(5)

RuntimeDirectorySize

org.freedesktop.login1(5)

RuntimeDirectorySymlink

org.freedesktop.systemd1(5)

RuntimeMaxUSec

org.freedesktop.systemd1(5)

RuntimePath

org.freedesktop.login1(5)

RuntimeRandomizedExtraUSec

org.freedesktop.systemd1(5)

RuntimeWatchdogPreGovernor

org.freedesktop.systemd1(5)

RuntimeWatchdogPreUSec

org.freedesktop.systemd1(5)

RuntimeWatchdogUSec

org.freedesktop.systemd1(5)

SELinuxContext

org.freedesktop.systemd1(5)

SSHAddress

org.freedesktop.machine1(5)

SSHPrivateKeyPath

org.freedesktop.machine1(5)

SameProcessGroup

org.freedesktop.systemd1(5)

ScheduledShutdown

org.freedesktop.login1(5)

Scope

org.freedesktop.login1(5)

ScopesMask

org.freedesktop.resolve1(5)

Seat

org.freedesktop.login1(5)

SecureBits

org.freedesktop.systemd1(5)

SecurityFinishTimestamp

org.freedesktop.systemd1(5)

SecurityFinishTimestampMonotonic

org.freedesktop.systemd1(5)

SecurityStartTimestamp

org.freedesktop.systemd1(5)

SecurityStartTimestampMonotonic

org.freedesktop.systemd1(5)

SendBuffer

org.freedesktop.systemd1(5)

SendSIGHUP

org.freedesktop.systemd1(5)

SendSIGKILL

org.freedesktop.systemd1(5)

Service

org.freedesktop.login1(5), org.freedesktop.machine1(5)

ServiceWatchdogs

org.freedesktop.systemd1(5)

Sessions

org.freedesktop.login1(5)

SessionsMax

org.freedesktop.login1(5)

SetCredential

org.freedesktop.systemd1(5)

SetCredentialEncrypted

org.freedesktop.systemd1(5)

SetLoginEnvironment

org.freedesktop.systemd1(5)

ShowStatus

org.freedesktop.systemd1(5)

ShutdownStartTimestamp

org.freedesktop.systemd1(5)

ShutdownStartTimestampMonotonic

org.freedesktop.systemd1(5)

SleepOperation

org.freedesktop.login1(5)

Slice

org.freedesktop.login1(5), org.freedesktop.systemd1(5)

SliceOf

org.freedesktop.systemd1(5)

SloppyOptions

org.freedesktop.systemd1(5)

SmackLabel

org.freedesktop.systemd1(5)

SmackLabelIPIn

org.freedesktop.systemd1(5)

SmackLabelIPOut

org.freedesktop.systemd1(5)

SmackProcessLabel

org.freedesktop.systemd1(5)

SocketBindAllow

org.freedesktop.systemd1(5)

SocketBindDeny

org.freedesktop.systemd1(5)

SocketGroup

org.freedesktop.systemd1(5)

SocketMode

org.freedesktop.systemd1(5)

SocketProtocol

org.freedesktop.systemd1(5)

SocketUser

org.freedesktop.systemd1(5)

SoftRebootsCount

org.freedesktop.systemd1(5)

SourcePath

org.freedesktop.network1(5), org.freedesktop.systemd1(5)

StandardError

org.freedesktop.systemd1(5)

StandardErrorFileDescriptorName

org.freedesktop.systemd1(5)

StandardInput

org.freedesktop.systemd1(5)

StandardInputData

org.freedesktop.systemd1(5)

StandardInputFileDescriptorName

org.freedesktop.systemd1(5)

StandardOutput

org.freedesktop.systemd1(5)

StandardOutputFileDescriptorName

org.freedesktop.systemd1(5)

StartLimitAction

org.freedesktop.systemd1(5)

StartLimitBurst

org.freedesktop.systemd1(5)

StartLimitIntervalUSec

org.freedesktop.systemd1(5)

StartupAllowedCPUs

org.freedesktop.systemd1(5)

StartupAllowedMemoryNodes

org.freedesktop.systemd1(5)

StartupBlockIOWeight

org.freedesktop.systemd1(5)

StartupCPUShares

org.freedesktop.systemd1(5)

StartupCPUWeight

org.freedesktop.systemd1(5)

StartupIOWeight

org.freedesktop.systemd1(5)

StartupMemoryHigh

org.freedesktop.systemd1(5)

StartupMemoryLow

org.freedesktop.systemd1(5)

StartupMemoryMax

org.freedesktop.systemd1(5)

StartupMemorySwapMax

org.freedesktop.systemd1(5)

StartupMemoryZSwapMax

org.freedesktop.systemd1(5)

State

org.freedesktop.home1(5), org.freedesktop.login1(5), org.freedesktop.machine1(5), org.freedesktop.network1(5), org.freedesktop.systemd1(5)

StateChangeTimestamp

org.freedesktop.systemd1(5)

StateChangeTimestampMonotonic

org.freedesktop.systemd1(5)

StateDirectory

org.freedesktop.systemd1(5)

StateDirectoryMode

org.freedesktop.systemd1(5)

StateDirectorySymlink

org.freedesktop.systemd1(5)

StaticHostname

org.freedesktop.hostname1(5)

StatusErrno

org.freedesktop.systemd1(5)

StatusText

org.freedesktop.systemd1(5)

StopIdleSessionUSec

org.freedesktop.login1(5)

StopPropagatedFrom

org.freedesktop.systemd1(5)

StopWhenUnneeded

org.freedesktop.systemd1(5)

SubState

org.freedesktop.systemd1(5)

SuccessAction

org.freedesktop.systemd1(5)

SuccessActionExitStatus

org.freedesktop.systemd1(5)

SuccessExitStatus

org.freedesktop.systemd1(5)

SupplementaryGroups

org.freedesktop.systemd1(5)

SurviveFinalKillSignal

org.freedesktop.systemd1(5)

Symlinks

org.freedesktop.systemd1(5)

SysFSPath

org.freedesktop.systemd1(5)

SyslogFacility

org.freedesktop.systemd1(5)

SyslogIdentifier

org.freedesktop.LogControl1(5), org.freedesktop.systemd1(5)

SyslogLevel

org.freedesktop.systemd1(5)

SyslogLevelPrefix

org.freedesktop.systemd1(5)

SyslogPriority

org.freedesktop.systemd1(5)

SystemCallArchitectures

org.freedesktop.systemd1(5)

SystemCallErrorNumber

org.freedesktop.systemd1(5)

SystemCallFilter

org.freedesktop.systemd1(5)

SystemCallLog

org.freedesktop.systemd1(5)

SystemState

org.freedesktop.systemd1(5)

TCPCongestion

org.freedesktop.systemd1(5)

TTY

org.freedesktop.login1(5)

TTYColumns

org.freedesktop.systemd1(5)

TTYPath

org.freedesktop.systemd1(5)

TTYReset

org.freedesktop.systemd1(5)

TTYRows

org.freedesktop.systemd1(5)

TTYVHangup

org.freedesktop.systemd1(5)

TTYVTDisallocate

org.freedesktop.systemd1(5)

Tainted

org.freedesktop.systemd1(5)

TasksAccounting

org.freedesktop.systemd1(5)

TasksCurrent

org.freedesktop.systemd1(5)

TasksMax

org.freedesktop.systemd1(5)

TemporaryFileSystem

org.freedesktop.systemd1(5)

TimeUSec

org.freedesktop.timedate1(5)

TimeoutAbortUSec

org.freedesktop.systemd1(5)

TimeoutCleanUSec

org.freedesktop.systemd1(5)

TimeoutIdleUSec

org.freedesktop.systemd1(5)

TimeoutStartFailureMode

org.freedesktop.systemd1(5)

TimeoutStartUSec

org.freedesktop.systemd1(5)

TimeoutStopFailureMode

org.freedesktop.systemd1(5)

TimeoutStopUSec

org.freedesktop.systemd1(5)

TimeoutUSec

org.freedesktop.systemd1(5)

TimerSlackNSec

org.freedesktop.systemd1(5)

TimersCalendar

org.freedesktop.systemd1(5)

TimersMonotonic

org.freedesktop.systemd1(5)

Timestamp

org.freedesktop.login1(5), org.freedesktop.machine1(5)

TimestampMonotonic

org.freedesktop.login1(5), org.freedesktop.machine1(5)

Timestamping

org.freedesktop.systemd1(5)

Timezone

org.freedesktop.timedate1(5)

TransactionStatistics

org.freedesktop.resolve1(5)

Transient

org.freedesktop.systemd1(5)

Transparent

org.freedesktop.systemd1(5)

TriggerLimitBurst

org.freedesktop.systemd1(5)

TriggerLimitIntervalUSec

org.freedesktop.systemd1(5)

TriggeredBy

org.freedesktop.systemd1(5)

Triggers

org.freedesktop.systemd1(5)

Type

org.freedesktop.import1(5), org.freedesktop.login1(5), org.freedesktop.portable1(5), org.freedesktop.systemd1(5)

UID

org.freedesktop.home1(5), org.freedesktop.login1(5), org.freedesktop.systemd1(5)

UMask

org.freedesktop.systemd1(5)

USBFunctionDescriptors

org.freedesktop.systemd1(5)

USBFunctionStrings

org.freedesktop.systemd1(5)

Unit

org.freedesktop.machine1(5), org.freedesktop.systemd1(5)

UnitFilePreset

org.freedesktop.systemd1(5)

UnitFileState

org.freedesktop.systemd1(5)

UnitPath

org.freedesktop.systemd1(5)

UnitsLoadFinishTimestamp

org.freedesktop.systemd1(5)

UnitsLoadFinishTimestampMonotonic

org.freedesktop.systemd1(5)

UnitsLoadStartTimestamp

org.freedesktop.systemd1(5)

UnitsLoadStartTimestampMonotonic

org.freedesktop.systemd1(5)

UnitsLoadTimestamp

org.freedesktop.systemd1(5)

UnitsLoadTimestampMonotonic

org.freedesktop.systemd1(5)

UnixRecord

org.freedesktop.home1(5)

UnsetEnvironment

org.freedesktop.systemd1(5)

UpheldBy

org.freedesktop.systemd1(5)

Upholds

org.freedesktop.systemd1(5)

Usage

org.freedesktop.portable1(5)

UsageExclusive

org.freedesktop.portable1(5)

User

org.freedesktop.login1(5), org.freedesktop.systemd1(5)

UserName

org.freedesktop.home1(5)

UserRecord

org.freedesktop.home1(5)

UserStopDelayUSec

org.freedesktop.login1(5)

UserspaceTimestamp

org.freedesktop.systemd1(5)

UserspaceTimestampMonotonic

org.freedesktop.systemd1(5)

UtmpIdentifier

org.freedesktop.systemd1(5)

UtmpMode

org.freedesktop.systemd1(5)

VConsoleKeymap

org.freedesktop.locale1(5)

VConsoleKeymapToggle

org.freedesktop.locale1(5)

VSockCID

org.freedesktop.hostname1(5), org.freedesktop.machine1(5)

VTNr

org.freedesktop.login1(5)

Verify

org.freedesktop.import1(5)

Version

org.freedesktop.systemd1(5)

Virtualization

org.freedesktop.systemd1(5)

WakeSystem

org.freedesktop.systemd1(5)

WallMessage

org.freedesktop.login1(5)

WantedBy

org.freedesktop.systemd1(5)

Wants

org.freedesktop.systemd1(5)

WantsMountsFor

org.freedesktop.systemd1(5)

WatchdogDevice

org.freedesktop.systemd1(5)

WatchdogLastPingTimestamp

org.freedesktop.systemd1(5)

WatchdogLastPingTimestampMonotonic

org.freedesktop.systemd1(5)

WatchdogSignal

org.freedesktop.systemd1(5)

WatchdogTimestamp

org.freedesktop.systemd1(5)

WatchdogTimestampMonotonic

org.freedesktop.systemd1(5)

WatchdogUSec

org.freedesktop.systemd1(5)

What

org.freedesktop.systemd1(5)

Where

org.freedesktop.systemd1(5)

WorkingDirectory

org.freedesktop.systemd1(5)

Writable

org.freedesktop.systemd1(5)

X11Layout

org.freedesktop.locale1(5)

X11Model

org.freedesktop.locale1(5)

X11Options

org.freedesktop.locale1(5)

X11Variant

org.freedesktop.locale1(5)

D-BUS SIGNALS

Signals emitted in the D-Bus interface.

JobNew()

org.freedesktop.systemd1(5)

JobRemoved()

org.freedesktop.systemd1(5)

Killed()

org.freedesktop.oom1(5)

Lock()

org.freedesktop.login1(5)

LogMessage()

org.freedesktop.import1(5)

MachineNew()

org.freedesktop.machine1(5)

MachineRemoved()

org.freedesktop.machine1(5)

PauseDevice()

org.freedesktop.login1(5)

PrepareForShutdown()

org.freedesktop.login1(5)

PrepareForShutdownWithMetadata()

org.freedesktop.login1(5)

PrepareForSleep()

org.freedesktop.login1(5)

ProgressUpdate()

org.freedesktop.import1(5)

Reloading()

org.freedesktop.systemd1(5)

RequestStop()

org.freedesktop.systemd1(5)

ResumeDevice()

org.freedesktop.login1(5)

SeatNew()

org.freedesktop.login1(5)

SeatRemoved()

org.freedesktop.login1(5)

SessionNew()

org.freedesktop.login1(5)

SessionRemoved()

org.freedesktop.login1(5)

StartupFinished()

org.freedesktop.systemd1(5)

TransferNew()

org.freedesktop.import1(5)

TransferRemoved()

org.freedesktop.import1(5)

UnitFilesChanged()

org.freedesktop.systemd1(5)

UnitNew()

org.freedesktop.systemd1(5)

UnitRemoved()

org.freedesktop.systemd1(5)

Unlock()

org.freedesktop.login1(5)

UserNew()

org.freedesktop.login1(5)

UserRemoved()

org.freedesktop.login1(5)

COLOPHON

This index contains 6293 entries in 24 sections, referring to 401 individual manual pages.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

34 - Linux cli command systemd.system-credentials

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command systemd.system-credentials and provides detailed information about the command systemd.system-credentials, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the systemd.system-credentials.

NAME 🖥️ systemd.system-credentials 🖥️

credentials - System Credentials

DESCRIPTION

System and Service Credentials[1] are data objects that may be passed into booted systems or system services as they are invoked. They can be acquired from various external sources, and propagated into the system and from there into system services. Credentials may optionally be encrypted with a machine-specific key and/or locked to the local TPM2 device, and are only decrypted when the consuming service is invoked.

System credentials may be used to provision and configure various aspects of the system. Depending on the consuming component credentials are only used on initial invocations or are needed for all invocations.

Credentials may be used for any kind of data, binary or text, and may carry passwords, secrets, certificates, cryptographic key material, identity information, configuration, and more.

WELL KNOWN SYSTEM CREDENTIALS

firstboot.keymap

The console key mapping to set (e.g. “de”). Read by systemd-firstboot(1), and only honoured if no console keymap has been configured before.

Added in version 252.

firstboot.locale, firstboot.locale-messages

The system locale to set (e.g. “de_DE.UTF-8”). Read by systemd-firstboot(1), and only honoured if no locale has been configured before. firstboot.locale sets “LANG”, while firstboot.locale-message sets “LC_MESSAGES”.

Added in version 252.

firstboot.timezone

The system timezone to set (e.g. “Europe/Berlin”). Read by systemd-firstboot(1), and only honoured if no system timezone has been configured before.

Added in version 252.

login.issue

The data of this credential is written to /etc/issue.d/50-provision.conf, if the file doesnt exist yet. agetty(8) reads this file and shows its contents at the login prompt of terminal logins. See issue(5) for details.

Consumed by /usr/lib/tmpfiles.d/provision.conf, see tmpfiles.d(5).

Added in version 252.

login.motd

The data of this credential is written to /etc/motd.d/50-provision.conf, if the file doesnt exist yet. pam_motd(8) reads this file and shows its contents as “message of the day” during terminal logins. See motd(5) for details.

Consumed by /usr/lib/tmpfiles.d/provision.conf, see tmpfiles.d(5).

Added in version 252.

network.hosts

The data of this credential is written to /etc/hosts, if the file doesnt exist yet. See hosts(5) for details.

Consumed by /usr/lib/tmpfiles.d/provision.conf, see tmpfiles.d(5).

Added in version 252.

network.dns, network.search_domains

DNS server information and search domains. Read by systemd-resolved.service(8).

Added in version 253.

network.conf.*, network.link.*, network.netdev.*, network.network.*

Configures network devices. Read by systemd-network-generator.service(8). These credentials should contain valid networkd.conf(5), systemd.link(5), systemd.netdev(5), systemd.network(5) configuration data. From each matching credential a separate file is created. Example: the contents of a credential network.link.50-foobar will be copied into a file 50-foobar.link.

Note that the resulting files are created world-readable, its hence recommended to not include secrets in these credentials, but supply them via separate credentials directly to systemd-networkd.service, e.g. network.wireguard.* as described below.

Added in version 256.

network.wireguard.*

Configures secrets for WireGuard netdevs. Read by systemd-networkd.service(8). For more information, refer to the [WireGuard] section of systemd.netdev(5).

Added in version 256.

passwd.hashed-password.root, passwd.plaintext-password.root

May contain the password (either in UNIX hashed format, or in plaintext) for the root users. Read by both systemd-firstboot(1) and systemd-sysusers(1), and only honoured if no root password has been configured before.

Added in version 252.

passwd.shell.root

The path to the shell program (e.g. “/bin/bash”) for the root user. Read by both systemd-firstboot(1) and systemd-sysusers(1), and only honoured if no root shell has been configured before.

Added in version 252.

ssh.authorized_keys.root

The data of this credential is written to /root/.ssh/authorized_keys, if the file doesnt exist yet. This allows provisioning SSH access for the systems root user.

Consumed by /usr/lib/tmpfiles.d/provision.conf, see tmpfiles.d(5).

Added in version 252.

ssh.listen

May be used to configure SSH sockets the system shall be reachable on. See systemd-ssh-generator(8) for details.

Added in version 256.

sysusers.extra

Additional sysusers.d(5) lines to process during boot.

Added in version 252.

sysctl.extra

Additional sysctl.d(5) lines to process during boot.

Added in version 252.

tmpfiles.extra

Additional tmpfiles.d(5) lines to process during boot.

Added in version 252.

fstab.extra

Additional mounts to establish at boot. For details, see systemd-fstab-generator(8).

Added in version 254.

vconsole.keymap, vconsole.keymap_toggle, vconsole.font, vconsole.font_map, vconsole.font_unimap

Console settings to apply, see systemd-vconsole-setup.service(8) for details.

Added in version 253.

getty.ttys.serial, getty.ttys.container

Used for spawning additional login prompts, see systemd-getty-generator(8) for details.

Added in version 254.

journal.forward_to_socket

Used by systemd-journald(8) to determine where to forward log messages for socket forwarding, see journald.conf(5) for details.

Added in version 256.

journal.storage

Used by systemd-journald(8) to determine where to store journal files, see journald.conf(5) for details.

Added in version 256.

vmm.notify_socket

Configures an sd_notify(3) compatible AF_VSOCK socket the service manager will report status information, ready notification and exit status on. For details see systemd(1).

Added in version 253.

system.machine_id

Takes a 128bit ID to initialize the machine ID from (if it is not set yet). Interpreted by the service manager (PID 1). For details see systemd(1).

Added in version 254.

system.hostname

Accepts a (transient) hostname to configure during early boot. The static hostname specified in /etc/hostname, if configured, takes precedence over this setting. Interpreted by the service manager (PID 1). For details see systemd(1).

Added in version 254.

home.create.*

Creates a home area for the specified user with the user record data passed in. For details see homectl(1).

Added in version 256.

cryptsetup.passphrase, cryptsetup.tpm2-pin, cryptsetup.fido2-pin, cryptsetup.pkcs11-pin, cryptsetup.luks2-pin

Specifies the passphrase/PINs to use for unlock encrypted storage volumes. For details see systemd-cryptsetup(8).

Added in version 256.

systemd.extra-unit.*, systemd.unit-dropin.*

These credentials specify extra units and drop-ins to add to the system. For details see systemd-debug-generator(8).

Added in version 256.

udev.conf.*, udev.rules.*

Configures udev configuration file and udev rules. Read by systemd-udev-load-credentials.service, which invokes udevadm control –load-credentials. These credentials directly translate to a matching udev.conf(5) or udev(7) rules file. Example: the contents of a credential udev.conf.50-foobar will be copied into a file /run/udev/udev.conf.d/50-foobar.conf, and udev.rules.50-foobar will be copied into a file /run/udev/rules.d/50-foobar.rules. See udev(7), udev.conf(5), and udevadm(8) for details.

Added in version 256.

SEE ALSO

systemd(1), kernel-command-line(7), smbios-type-11(7)

NOTES

System and Service Credentials

https://systemd.io/CREDENTIALS

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

35 - Linux cli command EVP_MD-NULLssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_MD-NULLssl and provides detailed information about the command EVP_MD-NULLssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_MD-NULLssl.

NAME 🖥️ EVP_MD-NULLssl 🖥️

NULL - The NULL EVP_MD implementation

DESCRIPTION

Support for a NULL digest through the EVP_MD API. This algorithm does nothing and returns 1 for its init, update and final methods.

Algorithm Name

The following algorithm is available in the default provider:

“NULL”

Gettable Parameters

This implementation supports the common gettable parameters described in EVP_MD-common (7).

SEE ALSO

EVP_MD_CTX_set_params (3), provider-digest (7), OSSL_PROVIDER-default (7)

COPYRIGHT

Copyright 2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

36 - Linux cli command EVP_PKEY-Siphashssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_PKEY-Siphashssl and provides detailed information about the command EVP_PKEY-Siphashssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_PKEY-Siphashssl.

NAME 🖥️ EVP_PKEY-Siphashssl 🖥️

HMAC, EVP_KEYMGMT-HMAC, EVP_PKEY-Siphash, EVP_KEYMGMT-Siphash, EVP_PKEY-Poly1305, EVP_KEYMGMT-Poly1305, EVP_PKEY-CMAC, EVP_KEYMGMT-CMAC - EVP_PKEY legacy MAC keytypes and algorithm support

DESCRIPTION

The HMAC and CMAC key types are implemented in OpenSSL’s default and FIPS providers. Additionally the Siphash and Poly1305 key types are implemented in the default provider. Performing MAC operations via an EVP_PKEY is considered legacy and are only available for backwards compatibility purposes and for a restricted set of algorithms. The preferred way of performing MAC operations is via the EVP_MAC APIs. See EVP_MAC_init (3).

For further details on using EVP_PKEY based MAC keys see EVP_SIGNATURE-HMAC (7), EVP_SIGNATURE-Siphash (7), EVP_SIGNATURE-Poly1305 (7) or EVP_SIGNATURE-CMAC (7).

Common MAC parameters

All the MAC keytypes support the following parameters.

“priv” (OSSL_PKEY_PARAM_PRIV_KEY) <octet string>
The MAC key value.

“properties” (OSSL_PKEY_PARAM_PROPERTIES) <UTF8 string>
A property query string to be used when any algorithms are fetched.

CMAC parameters

As well as the parameters described above, the CMAC keytype additionally supports the following parameters.

“cipher” (OSSL_PKEY_PARAM_CIPHER) <UTF8 string>
The name of a cipher to be used when generating the MAC.

“engine” (OSSL_PKEY_PARAM_ENGINE) <UTF8 string>
The name of an engine to be used for the specified cipher (if any).

Common MAC key generation parameters

MAC key generation is unusual in that no new key is actually generated. Instead a new provider side key object is created with the supplied raw key value. This is done for backwards compatibility with previous versions of OpenSSL.

“priv” (OSSL_PKEY_PARAM_PRIV_KEY) <octet string>
The MAC key value.

CMAC key generation parameters

In addition to the common MAC key generation parameters, the CMAC key generation additionally recognises the following.

“cipher” (OSSL_PKEY_PARAM_CIPHER) <UTF8 string>
The name of a cipher to be used when generating the MAC.

SEE ALSO

EVP_KEYMGMT (3), EVP_PKEY (3), provider-keymgmt (7)

COPYRIGHT

Copyright 2020 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

37 - Linux cli command GRANT

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command GRANT and provides detailed information about the command GRANT, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the GRANT.

NAME 🖥️ GRANT 🖥️

define access privileges

SYNOPSIS

GRANT { { SELECT | INSERT | UPDATE | DELETE | TRUNCATE | REFERENCES | TRIGGER }
    [, ...] | ALL [ PRIVILEGES ] }
    ON { [ TABLE ] table_name [, ...]
         | ALL TABLES IN SCHEMA schema_name [, ...] }
    TO role_specification [, ...] [ WITH GRANT OPTION ]
    [ GRANTED BY role_specification ]

GRANT { { SELECT | INSERT | UPDATE | REFERENCES } ( column_name [, ...] )
    [, ...] | ALL [ PRIVILEGES ] ( column_name [, ...] ) }
    ON [ TABLE ] table_name [, ...]
    TO role_specification [, ...] [ WITH GRANT OPTION ]
    [ GRANTED BY role_specification ]

GRANT { { USAGE | SELECT | UPDATE }
    [, ...] | ALL [ PRIVILEGES ] }
    ON { SEQUENCE sequence_name [, ...]
         | ALL SEQUENCES IN SCHEMA schema_name [, ...] }
    TO role_specification [, ...] [ WITH GRANT OPTION ]
    [ GRANTED BY role_specification ]

GRANT { { CREATE | CONNECT | TEMPORARY | TEMP } [, ...] | ALL [ PRIVILEGES ] }
    ON DATABASE database_name [, ...]
    TO role_specification [, ...] [ WITH GRANT OPTION ]
    [ GRANTED BY role_specification ]

GRANT { USAGE | ALL [ PRIVILEGES ] }
    ON DOMAIN domain_name [, ...]
    TO role_specification [, ...] [ WITH GRANT OPTION ]
    [ GRANTED BY role_specification ]

GRANT { USAGE | ALL [ PRIVILEGES ] }
    ON FOREIGN DATA WRAPPER fdw_name [, ...]
    TO role_specification [, ...] [ WITH GRANT OPTION ]
    [ GRANTED BY role_specification ]

GRANT { USAGE | ALL [ PRIVILEGES ] }
    ON FOREIGN SERVER server_name [, ...]
    TO role_specification [, ...] [ WITH GRANT OPTION ]
    [ GRANTED BY role_specification ]

GRANT { EXECUTE | ALL [ PRIVILEGES ] }
    ON { { FUNCTION | PROCEDURE | ROUTINE } routine_name [ ( [ [ argmode ] [ arg_name ] arg_type [, ...] ] ) ] [, ...]
         | ALL { FUNCTIONS | PROCEDURES | ROUTINES } IN SCHEMA schema_name [, ...] }
    TO role_specification [, ...] [ WITH GRANT OPTION ]
    [ GRANTED BY role_specification ]

GRANT { USAGE | ALL [ PRIVILEGES ] }
    ON LANGUAGE lang_name [, ...]
    TO role_specification [, ...] [ WITH GRANT OPTION ]
    [ GRANTED BY role_specification ]

GRANT { { SELECT | UPDATE } [, ...] | ALL [ PRIVILEGES ] }
    ON LARGE OBJECT loid [, ...]
    TO role_specification [, ...] [ WITH GRANT OPTION ]
    [ GRANTED BY role_specification ]

GRANT { { SET | ALTER SYSTEM } [, ... ] | ALL [ PRIVILEGES ] }
    ON PARAMETER configuration_parameter [, ...]
    TO role_specification [, ...] [ WITH GRANT OPTION ]
    [ GRANTED BY role_specification ]

GRANT { { CREATE | USAGE } [, ...] | ALL [ PRIVILEGES ] }
    ON SCHEMA schema_name [, ...]
    TO role_specification [, ...] [ WITH GRANT OPTION ]
    [ GRANTED BY role_specification ]

GRANT { CREATE | ALL [ PRIVILEGES ] }
    ON TABLESPACE tablespace_name [, ...]
    TO role_specification [, ...] [ WITH GRANT OPTION ]
    [ GRANTED BY role_specification ]

GRANT { USAGE | ALL [ PRIVILEGES ] }
    ON TYPE type_name [, ...]
    TO role_specification [, ...] [ WITH GRANT OPTION ]
    [ GRANTED BY role_specification ]

GRANT role_name [, ...] TO role_specification [, ...]
    [ WITH { ADMIN | INHERIT | SET } { OPTION | TRUE | FALSE } ]
    [ GRANTED BY role_specification ]

where role_specification can be:

    [ GROUP ] role_name
  | PUBLIC
  | CURRENT_ROLE
  | CURRENT_USER
  | SESSION_USER

DESCRIPTION

The GRANT command has two basic variants: one that grants privileges on a database object (table, column, view, foreign table, sequence, database, foreign-data wrapper, foreign server, function, procedure, procedural language, large object, configuration parameter, schema, tablespace, or type), and one that grants membership in a role. These variants are similar in many ways, but they are different enough to be described separately.

GRANT on Database Objects

This variant of the GRANT command gives specific privileges on a database object to one or more roles. These privileges are added to those already granted, if any.

The key word PUBLIC indicates that the privileges are to be granted to all roles, including those that might be created later. PUBLIC can be thought of as an implicitly defined group that always includes all roles. Any particular role will have the sum of privileges granted directly to it, privileges granted to any role it is presently a member of, and privileges granted to PUBLIC.

If WITH GRANT OPTION is specified, the recipient of the privilege can in turn grant it to others. Without a grant option, the recipient cannot do that. Grant options cannot be granted to PUBLIC.

If GRANTED BY is specified, the specified grantor must be the current user. This clause is currently present in this form only for SQL compatibility.

There is no need to grant privileges to the owner of an object (usually the user that created it), as the owner has all privileges by default. (The owner could, however, choose to revoke some of their own privileges for safety.)

The right to drop an object, or to alter its definition in any way, is not treated as a grantable privilege; it is inherent in the owner, and cannot be granted or revoked. (However, a similar effect can be obtained by granting or revoking membership in the role that owns the object; see below.) The owner implicitly has all grant options for the object, too.

The possible privileges are:

SELECT
INSERT
UPDATE
DELETE
TRUNCATE
REFERENCES
TRIGGER
CREATE
CONNECT
TEMPORARY
EXECUTE
USAGE
SET
ALTER SYSTEM

Specific types of privileges, as defined in Section 5.7.

TEMP

Alternative spelling for TEMPORARY.

ALL PRIVILEGES

Grant all of the privileges available for the objects type. The PRIVILEGES key word is optional in PostgreSQL, though it is required by strict SQL.

The FUNCTION syntax works for plain functions, aggregate functions, and window functions, but not for procedures; use PROCEDURE for those. Alternatively, use ROUTINE to refer to a function, aggregate function, window function, or procedure regardless of its precise type.

There is also an option to grant privileges on all objects of the same type within one or more schemas. This functionality is currently supported only for tables, sequences, functions, and procedures. ALL TABLES also affects views and foreign tables, just like the specific-object GRANT command. ALL FUNCTIONS also affects aggregate and window functions, but not procedures, again just like the specific-object GRANT command. Use ALL ROUTINES to include procedures.

GRANT on Roles

This variant of the GRANT command grants membership in a role to one or more other roles, and the modification of membership options SET, INHERIT, and ADMIN; see Section 22.3 for details. Membership in a role is significant because it potentially allows access to the privileges granted to a role to each of its members, and potentially also the ability to make changes to the role itself. However, the actual permissions conferred depend on the options associated with the grant. To modify that options of an existing membership, simply specify the membership with updated option values.

Each of the options described below can be set to either TRUE or FALSE. The keyword OPTION is accepted as a synonym for TRUE, so that WITH ADMIN OPTION is a synonym for WITH ADMIN TRUE. When altering an existing membership the omission of an option results in the current value being retained.

The ADMIN option allows the member to in turn grant membership in the role to others, and revoke membership in the role as well. Without the admin option, ordinary users cannot do that. A role is not considered to hold WITH ADMIN OPTION on itself. Database superusers can grant or revoke membership in any role to anyone. This option defaults to FALSE.

The INHERIT option controls the inheritance status of the new membership; see Section 22.3 for details on inheritance. If it is set to TRUE, it causes the new member to inherit from the granted role. If set to FALSE, the new member does not inherit. If unspecified when creating a new role membership, this defaults to the inheritance attribute of the new member.

The SET option, if it is set to TRUE, allows the member to change to the granted role using the SET ROLE command. If a role is an indirect member of another role, it can use SET ROLE to change to that role only if there is a chain of grants each of which has SET TRUE. This option defaults to TRUE.

To create an object owned by another role or give ownership of an existing object to another role, you must have the ability to SET ROLE to that role; otherwise, commands such as ALTER … OWNER TO or CREATE DATABASE … OWNER will fail. However, a user who inherits the privileges of a role but does not have the ability to SET ROLE to that role may be able to obtain full access to the role by manipulating existing objects owned by that role (e.g. they could redefine an existing function to act as a Trojan horse). Therefore, if a roles privileges are to be inherited but should not be accessible via SET ROLE, it should not own any SQL objects.

If GRANTED BY is specified, the grant is recorded as having been done by the specified role. A user can only attribute a grant to another role if they possess the privileges of that role. The role recorded as the grantor must have ADMIN OPTION on the target role, unless it is the bootstrap superuser. When a grant is recorded as having a grantor other than the bootstrap superuser, it depends on the grantor continuing to possess ADMIN OPTION on the role; so, if ADMIN OPTION is revoked, dependent grants must be revoked as well.

Unlike the case with privileges, membership in a role cannot be granted to PUBLIC. Note also that this form of the command does not allow the noise word GROUP in role_specification.

NOTES

The REVOKE command is used to revoke access privileges.

Since PostgreSQL 8.1, the concepts of users and groups have been unified into a single kind of entity called a role. It is therefore no longer necessary to use the keyword GROUP to identify whether a grantee is a user or a group. GROUP is still allowed in the command, but it is a noise word.

A user may perform SELECT, INSERT, etc. on a column if they hold that privilege for either the specific column or its whole table. Granting the privilege at the table level and then revoking it for one column will not do what one might wish: the table-level grant is unaffected by a column-level operation.

When a non-owner of an object attempts to GRANT privileges on the object, the command will fail outright if the user has no privileges whatsoever on the object. As long as some privilege is available, the command will proceed, but it will grant only those privileges for which the user has grant options. The GRANT ALL PRIVILEGES forms will issue a warning message if no grant options are held, while the other forms will issue a warning if grant options for any of the privileges specifically named in the command are not held. (In principle these statements apply to the object owner as well, but since the owner is always treated as holding all grant options, the cases can never occur.)

It should be noted that database superusers can access all objects regardless of object privilege settings. This is comparable to the rights of root in a Unix system. As with root, its unwise to operate as a superuser except when absolutely necessary.

If a superuser chooses to issue a GRANT or REVOKE command, the command is performed as though it were issued by the owner of the affected object. In particular, privileges granted via such a command will appear to have been granted by the object owner. (For role membership, the membership appears to have been granted by the bootstrap superuser.)

GRANT and REVOKE can also be done by a role that is not the owner of the affected object, but is a member of the role that owns the object, or is a member of a role that holds privileges WITH GRANT OPTION on the object. In this case the privileges will be recorded as having been granted by the role that actually owns the object or holds the privileges WITH GRANT OPTION. For example, if table t1 is owned by role g1, of which role u1 is a member, then u1 can grant privileges on t1 to u2, but those privileges will appear to have been granted directly by g1. Any other member of role g1 could revoke them later.

If the role executing GRANT holds the required privileges indirectly via more than one role membership path, it is unspecified which containing role will be recorded as having done the grant. In such cases it is best practice to use SET ROLE to become the specific role you want to do the GRANT as.

Granting permission on a table does not automatically extend permissions to any sequences used by the table, including sequences tied to SERIAL columns. Permissions on sequences must be set separately.

See Section 5.7 for more information about specific privilege types, as well as how to inspect objects privileges.

EXAMPLES

Grant insert privilege to all users on table films:

GRANT INSERT ON films TO PUBLIC;

Grant all available privileges to user manuel on view kinds:

GRANT ALL PRIVILEGES ON kinds TO manuel;

Note that while the above will indeed grant all privileges if executed by a superuser or the owner of kinds, when executed by someone else it will only grant those permissions for which the someone else has grant options.

Grant membership in role admins to user joe:

GRANT admins TO joe;

COMPATIBILITY

According to the SQL standard, the PRIVILEGES key word in ALL PRIVILEGES is required. The SQL standard does not support setting the privileges on more than one object per command.

PostgreSQL allows an object owner to revoke their own ordinary privileges: for example, a table owner can make the table read-only to themselves by revoking their own INSERT, UPDATE, DELETE, and TRUNCATE privileges. This is not possible according to the SQL standard. The reason is that PostgreSQL treats the owners privileges as having been granted by the owner to themselves; therefore they can revoke them too. In the SQL standard, the owners privileges are granted by an assumed entity “_SYSTEM”. Not being “_SYSTEM”, the owner cannot revoke these rights.

According to the SQL standard, grant options can be granted to PUBLIC; PostgreSQL only supports granting grant options to roles.

The SQL standard allows the GRANTED BY option to specify only CURRENT_USER or CURRENT_ROLE. The other variants are PostgreSQL extensions.

The SQL standard provides for a USAGE privilege on other kinds of objects: character sets, collations, translations.

In the SQL standard, sequences only have a USAGE privilege, which controls the use of the NEXT VALUE FOR expression, which is equivalent to the function nextval in PostgreSQL. The sequence privileges SELECT and UPDATE are PostgreSQL extensions. The application of the sequence USAGE privilege to the currval function is also a PostgreSQL extension (as is the function itself).

Privileges on databases, tablespaces, schemas, languages, and configuration parameters are PostgreSQL extensions.

SEE ALSO

REVOKE(7), ALTER DEFAULT PRIVILEGES (ALTER_DEFAULT_PRIVILEGES(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

38 - Linux cli command CREATE_OPERATOR_FAMILY

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_OPERATOR_FAMILY and provides detailed information about the command CREATE_OPERATOR_FAMILY, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_OPERATOR_FAMILY.

NAME 🖥️ CREATE_OPERATOR_FAMILY 🖥️

define a new operator family

SYNOPSIS

CREATE OPERATOR FAMILY name USING index_method

DESCRIPTION

CREATE OPERATOR FAMILY creates a new operator family. An operator family defines a collection of related operator classes, and perhaps some additional operators and support functions that are compatible with these operator classes but not essential for the functioning of any individual index. (Operators and functions that are essential to indexes should be grouped within the relevant operator class, rather than being “loose” in the operator family. Typically, single-data-type operators are bound to operator classes, while cross-data-type operators can be loose in an operator family containing operator classes for both data types.)

The new operator family is initially empty. It should be populated by issuing subsequent CREATE OPERATOR CLASS commands to add contained operator classes, and optionally ALTER OPERATOR FAMILY commands to add “loose” operators and their corresponding support functions.

If a schema name is given then the operator family is created in the specified schema. Otherwise it is created in the current schema. Two operator families in the same schema can have the same name only if they are for different index methods.

The user who defines an operator family becomes its owner. Presently, the creating user must be a superuser. (This restriction is made because an erroneous operator family definition could confuse or even crash the server.)

Refer to Section 38.16 for further information.

PARAMETERS

name

The name of the operator family to be created. The name can be schema-qualified.

index_method

The name of the index method this operator family is for.

COMPATIBILITY

CREATE OPERATOR FAMILY is a PostgreSQL extension. There is no CREATE OPERATOR FAMILY statement in the SQL standard.

SEE ALSO

ALTER OPERATOR FAMILY (ALTER_OPERATOR_FAMILY(7)), DROP OPERATOR FAMILY (DROP_OPERATOR_FAMILY(7)), CREATE OPERATOR CLASS (CREATE_OPERATOR_CLASS(7)), ALTER OPERATOR CLASS (ALTER_OPERATOR_CLASS(7)), DROP OPERATOR CLASS (DROP_OPERATOR_CLASS(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

39 - Linux cli command latin6

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command latin6 and provides detailed information about the command latin6, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the latin6.

NAME 🖥️ latin6 🖥️

10 - ISO/IEC 8859-10 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-10 encodes the characters used in Nordic languages.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-10 characters

The following table displays the characters in ISO/IEC 8859-10 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-10 is also known as Latin-6.

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

40 - Linux cli command ROLLBACK_TO_SAVEPOINT

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ROLLBACK_TO_SAVEPOINT and provides detailed information about the command ROLLBACK_TO_SAVEPOINT, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ROLLBACK_TO_SAVEPOINT.

NAME 🖥️ ROLLBACK_TO_SAVEPOINT 🖥️

roll back to a savepoint

SYNOPSIS

ROLLBACK [ WORK | TRANSACTION ] TO [ SAVEPOINT ] savepoint_name

DESCRIPTION

Roll back all commands that were executed after the savepoint was established and then start a new subtransaction at the same transaction level. The savepoint remains valid and can be rolled back to again later, if needed.

ROLLBACK TO SAVEPOINT implicitly destroys all savepoints that were established after the named savepoint.

PARAMETERS

savepoint_name

The savepoint to roll back to.

NOTES

Use RELEASE SAVEPOINT to destroy a savepoint without discarding the effects of commands executed after it was established.

Specifying a savepoint name that has not been established is an error.

Cursors have somewhat non-transactional behavior with respect to savepoints. Any cursor that is opened inside a savepoint will be closed when the savepoint is rolled back. If a previously opened cursor is affected by a FETCH or MOVE command inside a savepoint that is later rolled back, the cursor remains at the position that FETCH left it pointing to (that is, the cursor motion caused by FETCH is not rolled back). Closing a cursor is not undone by rolling back, either. However, other side-effects caused by the cursors query (such as side-effects of volatile functions called by the query) are rolled back if they occur during a savepoint that is later rolled back. A cursor whose execution causes a transaction to abort is put in a cannot-execute state, so while the transaction can be restored using ROLLBACK TO SAVEPOINT, the cursor can no longer be used.

EXAMPLES

To undo the effects of the commands executed after my_savepoint was established:

ROLLBACK TO SAVEPOINT my_savepoint;

Cursor positions are not affected by savepoint rollback:

BEGIN;

DECLARE foo CURSOR FOR SELECT 1 UNION SELECT 2;

SAVEPOINT foo;

FETCH 1 FROM foo;
 ?column?
----------
        1

ROLLBACK TO SAVEPOINT foo;

FETCH 1 FROM foo;
 ?column?
----------
        2

COMMIT;

COMPATIBILITY

The SQL standard specifies that the key word SAVEPOINT is mandatory, but PostgreSQL and Oracle allow it to be omitted. SQL allows only WORK, not TRANSACTION, as a noise word after ROLLBACK. Also, SQL has an optional clause AND [ NO ] CHAIN which is not currently supported by PostgreSQL. Otherwise, this command conforms to the SQL standard.

SEE ALSO

BEGIN(7), COMMIT(7), RELEASE SAVEPOINT (RELEASE_SAVEPOINT(7)), ROLLBACK(7), SAVEPOINT(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

41 - Linux cli command DROP_CONVERSION

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_CONVERSION and provides detailed information about the command DROP_CONVERSION, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_CONVERSION.

NAME 🖥️ DROP_CONVERSION 🖥️

remove a conversion

SYNOPSIS

DROP CONVERSION [ IF EXISTS ] name [ CASCADE | RESTRICT ]

DESCRIPTION

DROP CONVERSION removes a previously defined conversion. To be able to drop a conversion, you must own the conversion.

PARAMETERS

IF EXISTS

Do not throw an error if the conversion does not exist. A notice is issued in this case.

name

The name of the conversion. The conversion name can be schema-qualified.

CASCADE
RESTRICT

These key words do not have any effect, since there are no dependencies on conversions.

EXAMPLES

To drop the conversion named myname:

DROP CONVERSION myname;

COMPATIBILITY

There is no DROP CONVERSION statement in the SQL standard, but a DROP TRANSLATION statement that goes along with the CREATE TRANSLATION statement that is similar to the CREATE CONVERSION statement in PostgreSQL.

SEE ALSO

ALTER CONVERSION (ALTER_CONVERSION(7)), CREATE CONVERSION (CREATE_CONVERSION(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

42 - Linux cli command CREATE_TABLE_AS

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_TABLE_AS and provides detailed information about the command CREATE_TABLE_AS, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_TABLE_AS.

NAME 🖥️ CREATE_TABLE_AS 🖥️

define a new table from the results of a query

SYNOPSIS

CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } | UNLOGGED ] TABLE [ IF NOT EXISTS ] table_name
    [ (column_name [, ...] ) ]
    [ USING method ]
    [ WITH ( storage_parameter [= value] [, ... ] ) | WITHOUT OIDS ]
    [ ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP } ]
    [ TABLESPACE tablespace_name ]
    AS query
    [ WITH [ NO ] DATA ]

DESCRIPTION

CREATE TABLE AS creates a table and fills it with data computed by a SELECT command. The table columns have the names and data types associated with the output columns of the SELECT (except that you can override the column names by giving an explicit list of new column names).

CREATE TABLE AS bears some resemblance to creating a view, but it is really quite different: it creates a new table and evaluates the query just once to fill the new table initially. The new table will not track subsequent changes to the source tables of the query. In contrast, a view re-evaluates its defining SELECT statement whenever it is queried.

CREATE TABLE AS requires CREATE privilege on the schema used for the table.

PARAMETERS

GLOBAL or LOCAL

Ignored for compatibility. Use of these keywords is deprecated; refer to CREATE TABLE (CREATE_TABLE(7)) for details.

TEMPORARY or TEMP

If specified, the table is created as a temporary table. Refer to CREATE TABLE (CREATE_TABLE(7)) for details.

UNLOGGED

If specified, the table is created as an unlogged table. Refer to CREATE TABLE (CREATE_TABLE(7)) for details.

IF NOT EXISTS

Do not throw an error if a relation with the same name already exists; simply issue a notice and leave the table unmodified.

table_name

The name (optionally schema-qualified) of the table to be created.

column_name

The name of a column in the new table. If column names are not provided, they are taken from the output column names of the query.

USING method

This optional clause specifies the table access method to use to store the contents for the new table; the method needs be an access method of type TABLE. See Chapter 63 for more information. If this option is not specified, the default table access method is chosen for the new table. See default_table_access_method for more information.

WITH ( storage_parameter [= value] [, … ] )

This clause specifies optional storage parameters for the new table; see Storage Parameters in the CREATE TABLE (CREATE_TABLE(7)) documentation for more information. For backward-compatibility the WITH clause for a table can also include OIDS=FALSE to specify that rows of the new table should contain no OIDs (object identifiers), OIDS=TRUE is not supported anymore.

WITHOUT OIDS

This is backward-compatible syntax for declaring a table WITHOUT OIDS, creating a table WITH OIDS is not supported anymore.

ON COMMIT

The behavior of temporary tables at the end of a transaction block can be controlled using ON COMMIT. The three options are:

PRESERVE ROWS

No special action is taken at the ends of transactions. This is the default behavior.

DELETE ROWS

All rows in the temporary table will be deleted at the end of each transaction block. Essentially, an automatic TRUNCATE is done at each commit.

DROP

The temporary table will be dropped at the end of the current transaction block.

TABLESPACE tablespace_name

The tablespace_name is the name of the tablespace in which the new table is to be created. If not specified, default_tablespace is consulted, or temp_tablespaces if the table is temporary.

query

A SELECT, TABLE, or VALUES command, or an EXECUTE command that runs a prepared SELECT, TABLE, or VALUES query.

WITH [ NO ] DATA

This clause specifies whether or not the data produced by the query should be copied into the new table. If not, only the table structure is copied. The default is to copy the data.

NOTES

This command is functionally similar to SELECT INTO (SELECT_INTO(7)), but it is preferred since it is less likely to be confused with other uses of the SELECT INTO syntax. Furthermore, CREATE TABLE AS offers a superset of the functionality offered by SELECT INTO.

EXAMPLES

Create a new table films_recent consisting of only recent entries from the table films:

CREATE TABLE films_recent AS SELECT * FROM films WHERE date_prod >= 2002-01-01;

To copy a table completely, the short form using the TABLE command can also be used:

CREATE TABLE films2 AS TABLE films;

Create a new temporary table films_recent, consisting of only recent entries from the table films, using a prepared statement. The new table will be dropped at commit:

PREPARE recentfilms(date) AS SELECT * FROM films WHERE date_prod > $1; CREATE TEMP TABLE films_recent ON COMMIT DROP AS EXECUTE recentfilms(2002-01-01);

COMPATIBILITY

CREATE TABLE AS conforms to the SQL standard. The following are nonstandard extensions:

·

The standard requires parentheses around the subquery clause; in PostgreSQL, these parentheses are optional.

·

In the standard, the WITH [ NO ] DATA clause is required; in PostgreSQL it is optional.

·

PostgreSQL handles temporary tables in a way rather different from the standard; see CREATE TABLE (CREATE_TABLE(7)) for details.

·

The WITH clause is a PostgreSQL extension; storage parameters are not in the standard.

·

The PostgreSQL concept of tablespaces is not part of the standard. Hence, the clause TABLESPACE is an extension.

SEE ALSO

CREATE MATERIALIZED VIEW (CREATE_MATERIALIZED_VIEW(7)), CREATE TABLE (CREATE_TABLE(7)), EXECUTE(7), SELECT(7), SELECT INTO (SELECT_INTO(7)), VALUES(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

43 - Linux cli command glob

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command glob and provides detailed information about the command glob, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the glob.

NAME 🖥️ glob 🖥️

globbing pathnames

DESCRIPTION

Long ago, in UNIX V6, there was a program /etc/glob that would expand wildcard patterns. Soon afterward this became a shell built-in.

These days there is also a library routine glob(3) that will perform this function for a user program.

The rules are as follows (POSIX.2, 3.13).

Wildcard matching

A string is a wildcard pattern if it contains one of the characters ‘?’, ‘*’, or ‘[’. Globbing is the operation that expands a wildcard pattern into the list of pathnames matching the pattern. Matching is defined by:

A ‘?’ (not between brackets) matches any single character.

A ‘*’ (not between brackets) matches any string, including the empty string.

Character classes

An expression “[…]” where the first character after the leading ‘[’ is not an ‘!’ matches a single character, namely any of the characters enclosed by the brackets. The string enclosed by the brackets cannot be empty; therefore ‘]’ can be allowed between the brackets, provided that it is the first character. (Thus, “[][!]” matches the three characters ‘[’, ‘]’, and ‘!’.)

Ranges

There is one special convention: two characters separated by ‘-’ denote a range. (Thus, “[A-Fa-f0-9]” is equivalent to “[ABCDEFabcdef0123456789]”.) One may include ‘-’ in its literal meaning by making it the first or last character between the brackets. (Thus, “[]-]” matches just the two characters ‘]’ and ‘-’, and “[–0]” matches the three characters ‘-’, ‘.’, and ‘0’, since ‘/’ cannot be matched.)

Complementation

An expression “[!…]” matches a single character, namely any character that is not matched by the expression obtained by removing the first ‘!’ from it. (Thus, “[!]a-]” matches any single character except ‘]’, ‘a’, and ‘-’.)

One can remove the special meaning of ‘?’, ‘*’, and ‘[’ by preceding them by a backslash, or, in case this is part of a shell command line, enclosing them in quotes. Between brackets these characters stand for themselves. Thus, “*[[?**” matches the four characters ‘[’, ‘?’, ‘*’, and ‘.

Pathnames

Globbing is applied on each of the components of a pathname separately. A ‘/’ in a pathname cannot be matched by a ‘?’ or ‘*’ wildcard, or by a range like “[.-0]”. A range containing an explicit ‘/’ character is syntactically incorrect. (POSIX requires that syntactically incorrect patterns are left unchanged.)

If a filename starts with a ‘.’, this character must be matched explicitly. (Thus, rm * will not remove .profile, and tar c * will not archive all your files; tar c . is better.)

Empty lists

The nice and simple rule given above: “expand a wildcard pattern into the list of matching pathnames” was the original UNIX definition. It allowed one to have patterns that expand into an empty list, as in

    xv -wait 0 *.gif *.jpg

where perhaps no *.gif files are present (and this is not an error). However, POSIX requires that a wildcard pattern is left unchanged when it is syntactically incorrect, or the list of matching pathnames is empty. With bash one can force the classical behavior using this command:

shopt -s nullglob

(Similar problems occur elsewhere. For example, where old scripts have

rm `find . -name "*~"`

new scripts require

rm -f nosuchfile `find . -name "*~"`

to avoid error messages from rm called with an empty argument list.)

NOTES

Regular expressions

Note that wildcard patterns are not regular expressions, although they are a bit similar. First of all, they match filenames, rather than text, and secondly, the conventions are not the same: for example, in a regular expression ‘*’ means zero or more copies of the preceding thing.

Now that regular expressions have bracket expressions where the negation is indicated by a ‘^’, POSIX has declared the effect of a wildcard pattern “[^…]” to be undefined.

Character classes and internationalization

Of course ranges were originally meant to be ASCII ranges, so that “[ -%]” stands for “[ !”#$%]" and “[a-z]” stands for “any lowercase letter”. Some UNIX implementations generalized this so that a range X-Y stands for the set of characters with code between the codes for X and for Y. However, this requires the user to know the character coding in use on the local system, and moreover, is not convenient if the collating sequence for the local alphabet differs from the ordering of the character codes. Therefore, POSIX extended the bracket notation greatly, both for wildcard patterns and for regular expressions. In the above we saw three types of items that can occur in a bracket expression: namely (i) the negation, (ii) explicit single characters, and (iii) ranges. POSIX specifies ranges in an internationally more useful way and adds three more types:

(iii) Ranges X-Y comprise all characters that fall between X and Y (inclusive) in the current collating sequence as defined by the LC_COLLATE category in the current locale.

(iv) Named character classes, like

[:alnum:]  [:alpha:]  [:blank:]  [:cntrl:]
[:digit:]  [:graph:]  [:lower:]  [:print:]
[:punct:]  [:space:]  [:upper:]  [:xdigit:]

so that one can say “[[:lower:]]” instead of “[a-z]”, and have things work in Denmark, too, where there are three letters past ‘z’ in the alphabet. These character classes are defined by the LC_CTYPE category in the current locale.

(v) Collating symbols, like “[.ch.]” or “[.a-acute.]”, where the string between “[.” and “.]” is a collating element defined for the current locale. Note that this may be a multicharacter element.

(vi) Equivalence class expressions, like “[=a=]”, where the string between “[=” and “=]” is any collating element from its equivalence class, as defined for the current locale. For example, “[[=a=]]” might be equivalent to “[aáàäâ]”, that is, to “[a[.a-acute.][.a-grave.][.a-umlaut.][.a-circumflex.]]”.

SEE ALSO

sh(1), fnmatch(3), glob(3), locale(7), regex(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

44 - Linux cli command groff_mom

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command groff_mom and provides detailed information about the command groff_mom, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the groff_mom.

Name

groff_mom - modern macros for document composition with GNU roff

Synopsis

groff -mom [*option *. . .] [*file *. . .] groff -m mom [*option *. . .] [*file *. . .]

Description

mom is a macro set for groff, designed primarily to prepare documents for PDF and PostScript output. mom provides macros in two categories: typesetting and document processing. The former provide access to groff’s typesetting capabilities in ways that are simpler to master than groff’s requests and escape sequences. The latter provide highly customizable markup tags that allow the user to design and output professional-looking documents with a minimum of typesetting intervention.

Files processed with

produce PDF documents. The documents include a PDF outline that appears in the navigation pane panel of document viewers, and may contain clickable internal and external links.

Normally. groff’s native PDF driver,

is used to generate the output. When pdfmom is given the “-T ps” option, it still produces PDF, but processing is delegated to pdfroff, which uses groff’s PostScript driver,

Not all PDF features are available when -T ps is given; its primary use is to allow processing of files with embedded PostScript images.

Files processed with groff -mom (or -m mom) format for the device specified with the -T option. (In this installation, ps is the default output device.)

mom comes with her own comprehensive documentation in HTML. A PDF manual, “Producing PDFs with groff and mom”, discusses preparation of PDF documents with mom in detail.

Files

/usr/share/groff/1.23.0/tmac/mom.tmac
is a wrapper enabling the package to be loaded with “groff -m mom”.

/usr/share/groff/1.23.0/tmac/om.tmac
implements the package.

/usr/share/doc/groff-base/html/mom/toc.html
is the entry point to the HTML documentation.

/usr/share/doc/groff-base/pdf/mom-pdf.pdf
is “Producing PDFs with groff and mom”, by Deri James and Peter Schaffter.

/usr/share/doc/groff-base/examples/mom/*.mom
are examples of mom usage.

Reference

Escape sequences

begin using an initialized colour inline

move backward in a line

\[BOLDER]
invoke pseudo bold inline (related to macro .SETBOLDER)

\[BOLDERX]
off pseudo bold inline (related to macro .SETBOLDER)

move characters pairs closer together inline (related to macro .KERN)

\[COND]
invoke pseudo condensing inline (related to macro .CONDENSE)

\[CONDX]
off pseudo condensing inline (related to macro .CONDENSE)

pseudo-condensed superscript

temporarily move downward in a line

\[EN-MARK]
mark initial line of a range of line numbers (for use with line numbered endnotes)

\[EXT]
invoke pseudo extending inline (related to macro .EXTEND)

\[EXTX]
off pseudo condensing inline (related to macro .EXTEND)

pseudo extended superscript

move characters pairs further apart inline (related to macro .KERN)

move forward in a line

\[LEADER]
insert leaders at the end of a line

\[RULE]
draw a full measure rule

change the point size inline (related to macro .PT_SIZE)

\[SLANT]
invoke pseudo italic inline (related to macro .SETSLANT)

\[SLANTX]
off pseudo italic inline (related to macro .SETSLANT)

string tabs (mark tab positions inline)

superscript

\[TB+]
inline escape for .TN (Tab Next)

invoke underlining inline (fixed width fonts only)

temporarily move upward in a line

Macros

.AUTOLEAD
set the linespacing relative to the point size

.B_MARGIN
set a bottom margin

.BR
break a justified line

.CENTER
set line-by-line quad centre

.CONDENSE
set the amount to pseudo condense

.EL
break a line without advancing on the page

.EXTEND
set the amount to pseudo extend

.FALLBACK_FONT
establish a fallback font (for missing fonts)

.FAM
alias to .FAMILY

**.FAMILY **<family>
set the family type

.FT
set the font style (roman, italic, etc.)

.HI [* <measure> *]
hanging indent

.HY
automatic hyphenation on/off

.HY_SET
set automatic hyphenation parameters

.IB [* <left measure> <right measure> *]
indent both

.IBX [ CLEAR ]
exit indent both

.IL [* <measure> *]
indent left

.ILX [ CLEAR ]
exit indent left

.IQ [ CLEAR ]
quit any/all indents

.IR [* <measure> *]
indent right

.IRX [ CLEAR ]
exit indent right

.JUSTIFY
justify text to both margins

.KERN
automatic character pair kerning on/off

.L_MARGIN
set a left margin (page offset)

.LEFT
set line-by-line quad left

.LL
set a line length

.LS
set a linespacing (leading)

.PAGE
set explicit page dimensions and margins

.PAGEWIDTH
set a custom page width

.PAGELENGTH
set a custom page length

.PAPER* <paper_type>*
set common paper sizes (letter, A4, etc)

.PT_SIZE
set the point size

.QUAD
“justify” text left, centre, or right

.R_MARGIN
set a right margin

.RIGHT
set line-by-line quad right

.SETBOLDER
set the amount of emboldening

.SETSLANT
set the degree of slant

.SPREAD
force justify a line

.SS
set the sentence space size

.T_MARGIN
set a top margin

.TI [* <measure> *]
temporary left indent

.WS
set the minimum word space size

Documentation of details

Details of inline escape sequences in alphabetical order

begin using an initialized colour inline

move backward in a line

\[BOLDER]
\[BOLDERX]
Emboldening on/off

\[BOLDER] begins emboldening type. \[BOLDERX] turns the feature off. Both are inline escape sequences; therefore, they should not appear as separate lines, but rather be embedded in text lines, like this:

Alternatively, if you wanted the whole line emboldened, you should do

Once \[BOLDER] is invoked, it remains in effect until turned off.

Note: If you’re using the document processing macros with .PRINTSTYLE TYPEWRITE, mom ignores \[BOLDER] requests.

move characters pairs closer together inline (related to macro .KERN)

\[COND]
\[CONDX]
Pseudo-condensing on/off

\[COND] begins pseudo-condensing type. \[CONDX] turns the feature off. Both are inline escape sequences; therefore, they should not appear as separate lines, but rather be embedded in text lines, like this:

\[COND] remains in effect until you turn it off with \[CONDX].

IMPORTANT: You must turn \[COND] off before making any changes to the point size of your type, either via the .PT_SIZE macro or with the \s inline escape sequence. If you wish the new point size to be pseudo-condensed, simply reinvoke \[COND] afterward. Equally, \[COND] must be turned off before changing the condense percentage with .CONDENSE.

Note: If you’re using the document processing macros with .PRINTSTYLE TYPEWRITE, mom ignores \[COND] requests.

pseudo-condensed superscript

temporarily move downward in a line

\[EN-MARK]
mark initial line of a range of line numbers (for use with line numbered endnotes)

\[EXT]
\[EXTX]
Pseudo-extending on/off

\[EXT] begins pseudo-extending type. \[EXTX] turns the feature off. Both are inline escape sequences; therefore, they should not appear as separate lines, but rather be embedded in text lines, like this:

\[EXT] remains in effect until you turn it off with \[EXTX].

IMPORTANT: You must turn \[EXT] off before making any changes to the point size of your type, either via the .PT_SIZE macro or with the \s inline escape sequence. If you wish the new point size to be pseudo-extended, simply reinvoke \[EXT] afterward. Equally, \[EXT] must be turned off before changing the extend percentage with .EXTEND.

Note: If you are using the document processing macros with .PRINTSTYLE TYPEWRITE, mom ignores \[EXT] requests.

pseudo extended superscript

move characters pairs further apart inline (related to macro .KERN)

move forward in a line

\[LEADER]
insert leaders at the end of a line

\[RULE]
draw a full measure rule

change the point size inline (related to macro .PT_SIZE)

\[SLANT]
\[SLANTX]
Pseudo italic on/off

\[SLANT] begins pseudo-italicizing type. \[SLANTX] turns the feature off. Both are inline escape sequences; therefore, they should not appear as separate lines, but rather be embedded in text lines, like this:

Alternatively, if you wanted the whole line pseudo-italicized, you’d do

Once \[SLANT] is invoked, it remains in effect until turned off.

Note: If you’re using the document processing macros with .PRINTSTYLE TYPEWRITE, mom underlines pseudo-italics by default. To change this behaviour, use the special macro .SLANT_MEANS_SLANT.

Mark positions of string tabs

The quad direction must be LEFT or JUSTIFY (see .QUAD and .JUSTIFY) or the no-fill mode set to LEFT in order for these inlines to function properly. Please see IMPORTANT, below.

String tabs need to be marked off with inline escape sequences before being set up with the .ST macro. Any input line may contain string tab markers. <number>, above, means the numeric identifier of the tab.

The following shows a sample input line with string tab markers.

*[ST1]De minimus*[ST1X] non curat*[ST2]lex*[ST2X].

String tab 1 begins at the start of the line and ends after the word time. String tab 2 starts at good and ends after men. Inline escape sequences (e.g., font or point size changes, or horizontal movements, including padding) are taken into account when mom determines the position and length of string tabs.

Up to nineteen string tabs may be marked (not necessarily all on the same line, of course), and they must be numbered between 1 and 19.

Once string tabs have been marked in input lines, they have to be set with .ST, after which they may be called, by number, with .TAB.

Note: Lines with string tabs marked off in them are normal input lines, i.e. they get printed, just like any input line. If you want to set up string tabs without the line printing, use the .SILENT macro.

IMPORTANT: Owing to the way groff processes input lines and turns them into output lines, it is not possible for mom to guess the correct starting position of string tabs marked off in lines that are centered or set flush right.

Equally, she cannot guess the starting position if a line is fully justified and broken with .SPREAD.

In other words, in order to use string tabs, LEFT must be active, or, if .QUAD LEFT or JUSTIFY are active, the line on which the string tabs are marked must be broken manually with .BR (but not .SPREAD).

To circumvent this behaviour, I recommend using the PAD to set up string tabs in centered or flush right lines. Say, for example, you want to use a string tab to underscore the text of a centered line with a rule. Rather than this,

.CENTER *[ST1]A line of text*[ST1X]

45 - Linux cli command ALTER_OPERATOR_CLASS

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_OPERATOR_CLASS and provides detailed information about the command ALTER_OPERATOR_CLASS, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_OPERATOR_CLASS.

NAME 🖥️ ALTER_OPERATOR_CLASS 🖥️

change the definition of an operator class

SYNOPSIS

ALTER OPERATOR CLASS name USING index_method
    RENAME TO new_name

ALTER OPERATOR CLASS name USING index_method
    OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }

ALTER OPERATOR CLASS name USING index_method
    SET SCHEMA new_schema

DESCRIPTION

ALTER OPERATOR CLASS changes the definition of an operator class.

You must own the operator class to use ALTER OPERATOR CLASS. To alter the owner, you must be able to SET ROLE to the new owning role, and that role must have CREATE privilege on the operator classs schema. (These restrictions enforce that altering the owner doesnt do anything you couldnt do by dropping and recreating the operator class. However, a superuser can alter ownership of any operator class anyway.)

PARAMETERS

name

The name (optionally schema-qualified) of an existing operator class.

index_method

The name of the index method this operator class is for.

new_name

The new name of the operator class.

new_owner

The new owner of the operator class.

new_schema

The new schema for the operator class.

COMPATIBILITY

There is no ALTER OPERATOR CLASS statement in the SQL standard.

SEE ALSO

CREATE OPERATOR CLASS (CREATE_OPERATOR_CLASS(7)), DROP OPERATOR CLASS (DROP_OPERATOR_CLASS(7)), ALTER OPERATOR FAMILY (ALTER_OPERATOR_FAMILY(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

46 - Linux cli command DROP_INDEX

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_INDEX and provides detailed information about the command DROP_INDEX, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_INDEX.

NAME 🖥️ DROP_INDEX 🖥️

remove an index

SYNOPSIS

DROP INDEX [ CONCURRENTLY ] [ IF EXISTS ] name [, ...] [ CASCADE | RESTRICT ]

DESCRIPTION

DROP INDEX drops an existing index from the database system. To execute this command you must be the owner of the index.

PARAMETERS

CONCURRENTLY

Drop the index without locking out concurrent selects, inserts, updates, and deletes on the indexs table. A normal DROP INDEX acquires an ACCESS EXCLUSIVE lock on the table, blocking other accesses until the index drop can be completed. With this option, the command instead waits until conflicting transactions have completed.

There are several caveats to be aware of when using this option. Only one index name can be specified, and the CASCADE option is not supported. (Thus, an index that supports a UNIQUE or PRIMARY KEY constraint cannot be dropped this way.) Also, regular DROP INDEX commands can be performed within a transaction block, but DROP INDEX CONCURRENTLY cannot. Lastly, indexes on partitioned tables cannot be dropped using this option.

For temporary tables, DROP INDEX is always non-concurrent, as no other session can access them, and non-concurrent index drop is cheaper.

IF EXISTS

Do not throw an error if the index does not exist. A notice is issued in this case.

name

The name (optionally schema-qualified) of an index to remove.

CASCADE

Automatically drop objects that depend on the index, and in turn all objects that depend on those objects (see Section 5.14).

RESTRICT

Refuse to drop the index if any objects depend on it. This is the default.

EXAMPLES

This command will remove the index title_idx:

DROP INDEX title_idx;

COMPATIBILITY

DROP INDEX is a PostgreSQL language extension. There are no provisions for indexes in the SQL standard.

SEE ALSO

CREATE INDEX (CREATE_INDEX(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

47 - Linux cli command CREATE_TEXT_SEARCH_PARSER

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_TEXT_SEARCH_PARSER and provides detailed information about the command CREATE_TEXT_SEARCH_PARSER, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_TEXT_SEARCH_PARSER.

NAME 🖥️ CREATE_TEXT_SEARCH_PARSER 🖥️

define a new text search parser

SYNOPSIS

CREATE TEXT SEARCH PARSER name (
    START = start_function ,
    GETTOKEN = gettoken_function ,
    END = end_function ,
    LEXTYPES = lextypes_function
    [, HEADLINE = headline_function ]
)

DESCRIPTION

CREATE TEXT SEARCH PARSER creates a new text search parser. A text search parser defines a method for splitting a text string into tokens and assigning types (categories) to the tokens. A parser is not particularly useful by itself, but must be bound into a text search configuration along with some text search dictionaries to be used for searching.

If a schema name is given then the text search parser is created in the specified schema. Otherwise it is created in the current schema.

You must be a superuser to use CREATE TEXT SEARCH PARSER. (This restriction is made because an erroneous text search parser definition could confuse or even crash the server.)

Refer to Chapter 12 for further information.

PARAMETERS

name

The name of the text search parser to be created. The name can be schema-qualified.

start_function

The name of the start function for the parser.

gettoken_function

The name of the get-next-token function for the parser.

end_function

The name of the end function for the parser.

lextypes_function

The name of the lextypes function for the parser (a function that returns information about the set of token types it produces).

headline_function

The name of the headline function for the parser (a function that summarizes a set of tokens).

The function names can be schema-qualified if necessary. Argument types are not given, since the argument list for each type of function is predetermined. All except the headline function are required.

The arguments can appear in any order, not only the one shown above.

COMPATIBILITY

There is no CREATE TEXT SEARCH PARSER statement in the SQL standard.

SEE ALSO

ALTER TEXT SEARCH PARSER (ALTER_TEXT_SEARCH_PARSER(7)), DROP TEXT SEARCH PARSER (DROP_TEXT_SEARCH_PARSER(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

48 - Linux cli command EVP_KDF-KRB5KDFssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KDF-KRB5KDFssl and provides detailed information about the command EVP_KDF-KRB5KDFssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KDF-KRB5KDFssl.

NAME 🖥️ EVP_KDF-KRB5KDFssl 🖥️

KRB5KDF - The RFC3961 Krb5 KDF EVP_KDF implementation

DESCRIPTION

Support for computing the KRB5KDF KDF through the EVP_KDF API.

The EVP_KDF-KRB5KDF algorithm implements the key derivation function defined in RFC 3961, section 5.1 and is used by Krb5 to derive session keys. Three inputs are required to perform key derivation: a cipher, (for example AES-128-CBC), the initial key, and a constant.

Identity

“KRB5KDF” is the name for this implementation; it can be used with the EVP_KDF_fetch() function.

Supported parameters

The supported parameters are:

“properties” (OSSL_KDF_PARAM_PROPERTIES) <UTF8 string>

“cipher” (OSSL_KDF_PARAM_CIPHER) <UTF8 string>

“key” (OSSL_KDF_PARAM_KEY) <octet string>

These parameters work as described in “PARAMETERS” in EVP_KDF (3).

“constant” (OSSL_KDF_PARAM_CONSTANT) <octet string>
This parameter sets the constant value for the KDF. If a value is already set, the contents are replaced.

NOTES

A context for KRB5KDF can be obtained by calling:

EVP_KDF *kdf = EVP_KDF_fetch(NULL, “KRB5KDF”, NULL); EVP_KDF_CTX *kctx = EVP_KDF_CTX_new(kdf);

The output length of the KRB5KDF derivation is specified via the keylen parameter to the EVP_KDF_derive (3) function, and MUST match the key length for the chosen cipher or an error is returned. Moreover, the constant’s length must not exceed the block size of the cipher. Since the KRB5KDF output length depends on the chosen cipher, calling EVP_KDF_CTX_get_kdf_size (3) to obtain the requisite length returns the correct length only after the cipher is set. Prior to that EVP_MAX_KEY_LENGTH is returned. The caller must allocate a buffer of the correct length for the chosen cipher, and pass that buffer to the EVP_KDF_derive (3) function along with that length.

EXAMPLES

This example derives a key using the AES-128-CBC cipher:

EVP_KDF *kdf; EVP_KDF_CTX *kctx; unsigned char key[16] = “01234…”; unsigned char constant[] = “Im a constant”; unsigned char out[16]; size_t outlen = sizeof(out); OSSL_PARAM params[4], *p = params; kdf = EVP_KDF_fetch(NULL, “KRB5KDF”, NULL); kctx = EVP_KDF_CTX_new(kdf); EVP_KDF_free(kdf); *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_CIPHER, SN_aes_128_cbc, strlen(SN_aes_128_cbc)); *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_KEY, key, (size_t)16); *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_CONSTANT, constant, strlen(constant)); *p = OSSL_PARAM_construct_end(); if (EVP_KDF_derive(kctx, out, outlen, params) <= 0) /* Error */ EVP_KDF_CTX_free(kctx);

CONFORMING TO

RFC 3961

SEE ALSO

EVP_KDF (3), EVP_KDF_CTX_free (3), EVP_KDF_CTX_get_kdf_size (3), EVP_KDF_derive (3), “PARAMETERS” in EVP_KDF (3)

HISTORY

This functionality was added in OpenSSL 3.0.

COPYRIGHT

Copyright 2016-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

49 - Linux cli command EVP_RAND-TEST-RANDssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_RAND-TEST-RANDssl and provides detailed information about the command EVP_RAND-TEST-RANDssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_RAND-TEST-RANDssl.

NAME 🖥️ EVP_RAND-TEST-RANDssl 🖥️

TEST-RAND - The test EVP_RAND implementation

DESCRIPTION

Support for a test generator through the EVP_RAND API. This generator is for test purposes only, it does not generate random numbers.

Identity

“TEST-RAND” is the name for this implementation; it can be used with the EVP_RAND_fetch() function.

Supported parameters

The supported parameters are:

“state” (OSSL_RAND_PARAM_STATE) <integer>
These parameter works as described in “PARAMETERS” in EVP_RAND (3).

“strength” (OSSL_RAND_PARAM_STRENGTH) <unsigned integer>

“reseed_requests” (OSSL_DRBG_PARAM_RESEED_REQUESTS) <unsigned integer>

“reseed_time_interval” (OSSL_DRBG_PARAM_RESEED_TIME_INTERVAL) <integer>

“max_request” (OSSL_DRBG_PARAM_RESEED_REQUESTS) <unsigned integer>

“min_entropylen” (OSSL_DRBG_PARAM_MIN_ENTROPYLEN) <unsigned integer>

“max_entropylen” (OSSL_DRBG_PARAM_MAX_ENTROPYLEN) <unsigned integer>

“min_noncelen” (OSSL_DRBG_PARAM_MIN_NONCELEN) <unsigned integer>

“max_noncelen” (OSSL_DRBG_PARAM_MAX_NONCELEN) <unsigned integer>

“max_perslen” (OSSL_DRBG_PARAM_MAX_PERSLEN) <unsigned integer>

“max_adinlen” (OSSL_DRBG_PARAM_MAX_ADINLEN) <unsigned integer>

“reseed_counter” (OSSL_DRBG_PARAM_RESEED_COUNTER) <unsigned integer>

These parameters work as described in “PARAMETERS” in EVP_RAND (3), except that they can all be set as well as read.

“test_entropy” (OSSL_RAND_PARAM_TEST_ENTROPY) <octet string>
Sets the bytes returned when the test generator is sent an entropy request. The current position is remembered across generate calls. If there are insufficient data present to satisfy a call, an error is returned.

“test_nonce” (OSSL_RAND_PARAM_TEST_NONCE) <octet string>
Sets the bytes returned when the test generator is sent a nonce request. Each nonce request will return all of the bytes.

“generate” (OSSL_RAND_PARAM_GENERATE) <integer>
If this parameter is zero, it will only emit the nonce and entropy data supplied via the aforementioned parameters. Otherwise, low quality non-cryptographic pseudorandom output is produced. This parameter defaults to zero.

NOTES

A context for a test generator can be obtained by calling:

EVP_RAND *rand = EVP_RAND_fetch(NULL, “TEST-RAND”, NULL); EVP_RAND_CTX *rctx = EVP_RAND_CTX_new(rand, NULL);

EXAMPLES

EVP_RAND *rand; EVP_RAND_CTX *rctx; unsigned char bytes[100]; OSSL_PARAM params[4], *p = params; unsigned char entropy[1000] = { … }; unsigned char nonce[20] = { … }; unsigned int strength = 48; rand = EVP_RAND_fetch(NULL, “TEST-RAND”, NULL); rctx = EVP_RAND_CTX_new(rand, NULL); EVP_RAND_free(rand); *p++ = OSSL_PARAM_construct_uint(OSSL_RAND_PARAM_STRENGTH, &strength); *p++ = OSSL_PARAM_construct_octet_string(OSSL_RAND_PARAM_TEST_ENTROPY, entropy, sizeof(entropy)); *p++ = OSSL_PARAM_construct_octet_string(OSSL_RAND_PARAM_TEST_NONCE, nonce, sizeof(nonce)); *p = OSSL_PARAM_construct_end(); EVP_RAND_instantiate(rctx, strength, 0, NULL, 0, params); EVP_RAND_generate(rctx, bytes, sizeof(bytes), strength, 0, NULL, 0); EVP_RAND_CTX_free(rctx);

SEE ALSO

EVP_RAND (3), “PARAMETERS” in EVP_RAND (3)

HISTORY

This functionality was added in OpenSSL 3.0.

COPYRIGHT

Copyright 2020-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

50 - Linux cli command DROP_ACCESS_METHOD

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_ACCESS_METHOD and provides detailed information about the command DROP_ACCESS_METHOD, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_ACCESS_METHOD.

NAME 🖥️ DROP_ACCESS_METHOD 🖥️

remove an access method

SYNOPSIS

DROP ACCESS METHOD [ IF EXISTS ] name [ CASCADE | RESTRICT ]

DESCRIPTION

DROP ACCESS METHOD removes an existing access method. Only superusers can drop access methods.

PARAMETERS

IF EXISTS

Do not throw an error if the access method does not exist. A notice is issued in this case.

name

The name of an existing access method.

CASCADE

Automatically drop objects that depend on the access method (such as operator classes, operator families, and indexes), and in turn all objects that depend on those objects (see Section 5.14).

RESTRICT

Refuse to drop the access method if any objects depend on it. This is the default.

EXAMPLES

Drop the access method heptree:

DROP ACCESS METHOD heptree;

COMPATIBILITY

DROP ACCESS METHOD is a PostgreSQL extension.

SEE ALSO

CREATE ACCESS METHOD (CREATE_ACCESS_METHOD(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

51 - Linux cli command gitnamespaces

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command gitnamespaces and provides detailed information about the command gitnamespaces, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the gitnamespaces.

NAME 🖥️ gitnamespaces 🖥️

Git namespaces

SYNOPSIS

GIT_NAMESPACE=<namespace> git upload-pack
GIT_NAMESPACE=<namespace> git receive-pack

DESCRIPTION

Git supports dividing the refs of a single repository into multiple namespaces, each of which has its own branches, tags, and HEAD. Git can expose each namespace as an independent repository to pull from and push to, while sharing the object store, and exposing all the refs to operations such as git-gc(1).

Storing multiple repositories as namespaces of a single repository avoids storing duplicate copies of the same objects, such as when storing multiple branches of the same source. The alternates mechanism provides similar support for avoiding duplicates, but alternates do not prevent duplication between new objects added to the repositories without ongoing maintenance, while namespaces do.

To specify a namespace, set the GIT_NAMESPACE environment variable to the namespace. For each ref namespace, Git stores the corresponding refs in a directory under refs/namespaces/. For example, GIT_NAMESPACE=foo will store refs under refs/namespaces/foo/. You can also specify namespaces via the –namespace option to git(1).

Note that namespaces which include a / will expand to a hierarchy of namespaces; for example, GIT_NAMESPACE=foo/bar will store refs under refs/namespaces/foo/refs/namespaces/bar/. This makes paths in GIT_NAMESPACE behave hierarchically, so that cloning with GIT_NAMESPACE=foo/bar produces the same result as cloning with GIT_NAMESPACE=foo and cloning from that repo with GIT_NAMESPACE=bar. It also avoids ambiguity with strange namespace paths such as foo/refs/heads/, which could otherwise generate directory/file conflicts within the refs directory.

git-upload-pack(1) and git-receive-pack(1) rewrite the names of refs as specified by GIT_NAMESPACE. git-upload-pack and git-receive-pack will ignore all references outside the specified namespace.

The smart HTTP server, git-http-backend(1), will pass GIT_NAMESPACE through to the backend programs; see git-http-backend(1) for sample configuration to expose repository namespaces as repositories.

For a simple local test, you can use git-remote-ext(1):

git clone ext::git –namespace=foo %s /tmp/prefixed.git

SECURITY

The fetch and push protocols are not designed to prevent one side from stealing data from the other repository that was not intended to be shared. If you have private data that you need to protect from a malicious peer, your best option is to store it in another repository. This applies to both clients and servers. In particular, namespaces on a server are not effective for read access control; you should only grant read access to a namespace to clients that you would trust with read access to the entire repository.

The known attack vectors are as follows:

1.

The victim sends “have” lines advertising the IDs of objects it has that are not explicitly intended to be shared but can be used to optimize the transfer if the peer also has them. The attacker chooses an object ID X to steal and sends a ref to X, but isn’t required to send the content of X because the victim already has it. Now the victim believes that the attacker has X, and it sends the content of X back to the attacker later. (This attack is most straightforward for a client to perform on a server, by creating a ref to X in the namespace the client has access to and then fetching it. The most likely way for a server to perform it on a client is to “merge” X into a public branch and hope that the user does additional work on this branch and pushes it back to the server without noticing the merge.)

2.

As in #1, the attacker chooses an object ID X to steal. The victim sends an object Y that the attacker already has, and the attacker falsely claims to have X and not Y, so the victim sends Y as a delta against X. The delta reveals regions of X that are similar to Y to the attacker.

GIT

Part of the git(1) suite

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

52 - Linux cli command EVP_KEYEXCH-X25519ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KEYEXCH-X25519ssl and provides detailed information about the command EVP_KEYEXCH-X25519ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KEYEXCH-X25519ssl.

NAME 🖥️ EVP_KEYEXCH-X25519ssl 🖥️

X25519, EVP_KEYEXCH-X448 - X25519 and X448 Key Exchange algorithm support

DESCRIPTION

Key exchange support for the X25519 and X448 key types.

Key exchange parameters

“pad” (OSSL_EXCHANGE_PARAM_PAD) <unsigned integer>
See “Common Key Exchange parameters” in provider-keyexch (7).

EXAMPLES

Keys for the host and peer can be generated as shown in “Examples” in EVP_PKEY-X25519 (7).

The code to generate a shared secret is identical to “Examples” in EVP_KEYEXCH-DH (7).

SEE ALSO

EVP_PKEY-FFC (7), EVP_PKEY-DH (7) EVP_PKEY (3), provider-keyexch (7), provider-keymgmt (7), OSSL_PROVIDER-default (7), OSSL_PROVIDER-FIPS (7),

COPYRIGHT

Copyright 2020 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

53 - Linux cli command EVP_SIGNATURE-ECDSAssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_SIGNATURE-ECDSAssl and provides detailed information about the command EVP_SIGNATURE-ECDSAssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_SIGNATURE-ECDSAssl.

NAME 🖥️ EVP_SIGNATURE-ECDSAssl 🖥️

ECDSA - The EVP_PKEY ECDSA signature implementation.

DESCRIPTION

Support for computing ECDSA signatures. See EVP_PKEY-EC (7) for information related to EC keys.

ECDSA Signature Parameters

The following signature parameters can be set using EVP_PKEY_CTX_set_params(). This may be called after EVP_PKEY_sign_init() or EVP_PKEY_verify_init(), and before calling EVP_PKEY_sign() or EVP_PKEY_verify().

“digest” (OSSL_SIGNATURE_PARAM_DIGEST) <UTF8 string>

“properties” (OSSL_SIGNATURE_PARAM_PROPERTIES) <UTF8 string>

“nonce-type” (OSSL_SIGNATURE_PARAM_NONCE_TYPE) <unsigned integer>

These parameters are described in provider-signature (7).

The following signature parameters can be retrieved using EVP_PKEY_CTX_get_params().

“algorithm-id” (OSSL_SIGNATURE_PARAM_ALGORITHM_ID) <octet string>

“digest” (OSSL_SIGNATURE_PARAM_DIGEST) <UTF8 string>

“nonce-type” (OSSL_SIGNATURE_PARAM_NONCE_TYPE) <unsigned integer>

The parameters are described in provider-signature (7).

SEE ALSO

EVP_PKEY_CTX_set_params (3), EVP_PKEY_sign (3), EVP_PKEY_verify (3), provider-signature (7),

COPYRIGHT

Copyright 2020-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

54 - Linux cli command CREATE_FUNCTION

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_FUNCTION and provides detailed information about the command CREATE_FUNCTION, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_FUNCTION.

NAME 🖥️ CREATE_FUNCTION 🖥️

define a new function

SYNOPSIS

CREATE [ OR REPLACE ] FUNCTION
    name ( [ [ argmode ] [ argname ] argtype [ { DEFAULT | = } default_expr ] [, ...] ] )
    [ RETURNS rettype
      | RETURNS TABLE ( column_name column_type [, ...] ) ]
  { LANGUAGE lang_name
    | TRANSFORM { FOR TYPE type_name } [, ... ]
    | WINDOW
    | { IMMUTABLE | STABLE | VOLATILE }
    | [ NOT ] LEAKPROOF
    | { CALLED ON NULL INPUT | RETURNS NULL ON NULL INPUT | STRICT }
    | { [ EXTERNAL ] SECURITY INVOKER | [ EXTERNAL ] SECURITY DEFINER }
    | PARALLEL { UNSAFE | RESTRICTED | SAFE }
    | COST execution_cost
    | ROWS result_rows
    | SUPPORT support_function
    | SET configuration_parameter { TO value | = value | FROM CURRENT }
    | AS definition
    | AS obj_file, link_symbol
    | sql_body
  } ...

DESCRIPTION

CREATE FUNCTION defines a new function. CREATE OR REPLACE FUNCTION will either create a new function, or replace an existing definition. To be able to define a function, the user must have the USAGE privilege on the language.

If a schema name is included, then the function is created in the specified schema. Otherwise it is created in the current schema. The name of the new function must not match any existing function or procedure with the same input argument types in the same schema. However, functions and procedures of different argument types can share a name (this is called overloading).

To replace the current definition of an existing function, use CREATE OR REPLACE FUNCTION. It is not possible to change the name or argument types of a function this way (if you tried, you would actually be creating a new, distinct function). Also, CREATE OR REPLACE FUNCTION will not let you change the return type of an existing function. To do that, you must drop and recreate the function. (When using OUT parameters, that means you cannot change the types of any OUT parameters except by dropping the function.)

When CREATE OR REPLACE FUNCTION is used to replace an existing function, the ownership and permissions of the function do not change. All other function properties are assigned the values specified or implied in the command. You must own the function to replace it (this includes being a member of the owning role).

If you drop and then recreate a function, the new function is not the same entity as the old; you will have to drop existing rules, views, triggers, etc. that refer to the old function. Use CREATE OR REPLACE FUNCTION to change a function definition without breaking objects that refer to the function. Also, ALTER FUNCTION can be used to change most of the auxiliary properties of an existing function.

The user that creates the function becomes the owner of the function.

To be able to create a function, you must have USAGE privilege on the argument types and the return type.

Refer to Section 38.3 for further information on writing functions.

PARAMETERS

name

The name (optionally schema-qualified) of the function to create.

argmode

The mode of an argument: IN, OUT, INOUT, or VARIADIC. If omitted, the default is IN. Only OUT arguments can follow a VARIADIC one. Also, OUT and INOUT arguments cannot be used together with the RETURNS TABLE notation.

argname

The name of an argument. Some languages (including SQL and PL/pgSQL) let you use the name in the function body. For other languages the name of an input argument is just extra documentation, so far as the function itself is concerned; but you can use input argument names when calling a function to improve readability (see Section 4.3). In any case, the name of an output argument is significant, because it defines the column name in the result row type. (If you omit the name for an output argument, the system will choose a default column name.)

argtype

The data type(s) of the functions arguments (optionally schema-qualified), if any. The argument types can be base, composite, or domain types, or can reference the type of a table column.

Depending on the implementation language it might also be allowed to specify “pseudo-types” such as cstring. Pseudo-types indicate that the actual argument type is either incompletely specified, or outside the set of ordinary SQL data types.

The type of a column is referenced by writing table_name.column_name%TYPE. Using this feature can sometimes help make a function independent of changes to the definition of a table.

default_expr

An expression to be used as default value if the parameter is not specified. The expression has to be coercible to the argument type of the parameter. Only input (including INOUT) parameters can have a default value. All input parameters following a parameter with a default value must have default values as well.

rettype

The return data type (optionally schema-qualified). The return type can be a base, composite, or domain type, or can reference the type of a table column. Depending on the implementation language it might also be allowed to specify “pseudo-types” such as cstring. If the function is not supposed to return a value, specify void as the return type.

When there are OUT or INOUT parameters, the RETURNS clause can be omitted. If present, it must agree with the result type implied by the output parameters: RECORD if there are multiple output parameters, or the same type as the single output parameter.

The SETOF modifier indicates that the function will return a set of items, rather than a single item.

The type of a column is referenced by writing table_name.column_name%TYPE.

column_name

The name of an output column in the RETURNS TABLE syntax. This is effectively another way of declaring a named OUT parameter, except that RETURNS TABLE also implies RETURNS SETOF.

column_type

The data type of an output column in the RETURNS TABLE syntax.

lang_name

The name of the language that the function is implemented in. It can be sql, c, internal, or the name of a user-defined procedural language, e.g., plpgsql. The default is sql if sql_body is specified. Enclosing the name in single quotes is deprecated and requires matching case.

TRANSFORM { FOR TYPE type_name } [, … ] }

Lists which transforms a call to the function should apply. Transforms convert between SQL types and language-specific data types; see CREATE TRANSFORM (CREATE_TRANSFORM(7)). Procedural language implementations usually have hardcoded knowledge of the built-in types, so those dont need to be listed here. If a procedural language implementation does not know how to handle a type and no transform is supplied, it will fall back to a default behavior for converting data types, but this depends on the implementation.

WINDOW

WINDOW indicates that the function is a window function rather than a plain function. This is currently only useful for functions written in C. The WINDOW attribute cannot be changed when replacing an existing function definition.

IMMUTABLE
STABLE
VOLATILE

These attributes inform the query optimizer about the behavior of the function. At most one choice can be specified. If none of these appear, VOLATILE is the default assumption.

IMMUTABLE indicates that the function cannot modify the database and always returns the same result when given the same argument values; that is, it does not do database lookups or otherwise use information not directly present in its argument list. If this option is given, any call of the function with all-constant arguments can be immediately replaced with the function value.

STABLE indicates that the function cannot modify the database, and that within a single table scan it will consistently return the same result for the same argument values, but that its result could change across SQL statements. This is the appropriate selection for functions whose results depend on database lookups, parameter variables (such as the current time zone), etc. (It is inappropriate for AFTER triggers that wish to query rows modified by the current command.) Also note that the current_timestamp family of functions qualify as stable, since their values do not change within a transaction.

VOLATILE indicates that the function value can change even within a single table scan, so no optimizations can be made. Relatively few database functions are volatile in this sense; some examples are random(), currval(), timeofday(). But note that any function that has side-effects must be classified volatile, even if its result is quite predictable, to prevent calls from being optimized away; an example is setval().

For additional details see Section 38.7.

LEAKPROOF

LEAKPROOF indicates that the function has no side effects. It reveals no information about its arguments other than by its return value. For example, a function which throws an error message for some argument values but not others, or which includes the argument values in any error message, is not leakproof. This affects how the system executes queries against views created with the security_barrier option or tables with row level security enabled. The system will enforce conditions from security policies and security barrier views before any user-supplied conditions from the query itself that contain non-leakproof functions, in order to prevent the inadvertent exposure of data. Functions and operators marked as leakproof are assumed to be trustworthy, and may be executed before conditions from security policies and security barrier views. In addition, functions which do not take arguments or which are not passed any arguments from the security barrier view or table do not have to be marked as leakproof to be executed before security conditions. See CREATE VIEW (CREATE_VIEW(7)) and Section 41.5. This option can only be set by the superuser.

CALLED ON NULL INPUT
RETURNS NULL ON NULL INPUT
STRICT

CALLED ON NULL INPUT (the default) indicates that the function will be called normally when some of its arguments are null. It is then the function authors responsibility to check for null values if necessary and respond appropriately.

RETURNS NULL ON NULL INPUT or STRICT indicates that the function always returns null whenever any of its arguments are null. If this parameter is specified, the function is not executed when there are null arguments; instead a null result is assumed automatically.

[EXTERNAL] SECURITY INVOKER
[EXTERNAL] SECURITY DEFINER

SECURITY INVOKER indicates that the function is to be executed with the privileges of the user that calls it. That is the default. SECURITY DEFINER specifies that the function is to be executed with the privileges of the user that owns it. For information on how to write SECURITY DEFINER functions safely, see below.

The key word EXTERNAL is allowed for SQL conformance, but it is optional since, unlike in SQL, this feature applies to all functions not only external ones.

PARALLEL

PARALLEL UNSAFE indicates that the function cant be executed in parallel mode and the presence of such a function in an SQL statement forces a serial execution plan. This is the default. PARALLEL RESTRICTED indicates that the function can be executed in parallel mode, but the execution is restricted to parallel group leader. PARALLEL SAFE indicates that the function is safe to run in parallel mode without restriction.

Functions should be labeled parallel unsafe if they modify any database state, or if they make changes to the transaction such as using sub-transactions, or if they access sequences or attempt to make persistent changes to settings (e.g., setval). They should be labeled as parallel restricted if they access temporary tables, client connection state, cursors, prepared statements, or miscellaneous backend-local state which the system cannot synchronize in parallel mode (e.g., setseed cannot be executed other than by the group leader because a change made by another process would not be reflected in the leader). In general, if a function is labeled as being safe when it is restricted or unsafe, or if it is labeled as being restricted when it is in fact unsafe, it may throw errors or produce wrong answers when used in a parallel query. C-language functions could in theory exhibit totally undefined behavior if mislabeled, since there is no way for the system to protect itself against arbitrary C code, but in most likely cases the result will be no worse than for any other function. If in doubt, functions should be labeled as UNSAFE, which is the default.

COST execution_cost

A positive number giving the estimated execution cost for the function, in units of cpu_operator_cost. If the function returns a set, this is the cost per returned row. If the cost is not specified, 1 unit is assumed for C-language and internal functions, and 100 units for functions in all other languages. Larger values cause the planner to try to avoid evaluating the function more often than necessary.

ROWS result_rows

A positive number giving the estimated number of rows that the planner should expect the function to return. This is only allowed when the function is declared to return a set. The default assumption is 1000 rows.

SUPPORT support_function

The name (optionally schema-qualified) of a planner support function to use for this function. See Section 38.11 for details. You must be superuser to use this option.

configuration_parameter
value

The SET clause causes the specified configuration parameter to be set to the specified value when the function is entered, and then restored to its prior value when the function exits. SET FROM CURRENT saves the value of the parameter that is current when CREATE FUNCTION is executed as the value to be applied when the function is entered.

If a SET clause is attached to a function, then the effects of a SET LOCAL command executed inside the function for the same variable are restricted to the function: the configuration parameters prior value is still restored at function exit. However, an ordinary SET command (without LOCAL) overrides the SET clause, much as it would do for a previous SET LOCAL command: the effects of such a command will persist after function exit, unless the current transaction is rolled back.

See SET(7) and Chapter 20 for more information about allowed parameter names and values.

definition

A string constant defining the function; the meaning depends on the language. It can be an internal function name, the path to an object file, an SQL command, or text in a procedural language.

It is often helpful to use dollar quoting (see Section 4.1.2.4) to write the function definition string, rather than the normal single quote syntax. Without dollar quoting, any single quotes or backslashes in the function definition must be escaped by doubling them.

obj_file, link_symbol

This form of the AS clause is used for dynamically loadable C language functions when the function name in the C language source code is not the same as the name of the SQL function. The string obj_file is the name of the shared library file containing the compiled C function, and is interpreted as for the LOAD command. The string link_symbol is the functions link symbol, that is, the name of the function in the C language source code. If the link symbol is omitted, it is assumed to be the same as the name of the SQL function being defined. The C names of all functions must be different, so you must give overloaded C functions different C names (for example, use the argument types as part of the C names).

When repeated CREATE FUNCTION calls refer to the same object file, the file is only loaded once per session. To unload and reload the file (perhaps during development), start a new session.

sql_body

The body of a LANGUAGE SQL function. This can either be a single statement

RETURN expression

or a block

BEGIN ATOMIC statement; statement; … statement; END

This is similar to writing the text of the function body as a string constant (see definition above), but there are some differences: This form only works for LANGUAGE SQL, the string constant form works for all languages. This form is parsed at function definition time, the string constant form is parsed at execution time; therefore this form cannot support polymorphic argument types and other constructs that are not resolvable at function definition time. This form tracks dependencies between the function and objects used in the function body, so DROP … CASCADE will work correctly, whereas the form using string literals may leave dangling functions. Finally, this form is more compatible with the SQL standard and other SQL implementations.

OVERLOADING

PostgreSQL allows function overloading; that is, the same name can be used for several different functions so long as they have distinct input argument types. Whether or not you use it, this capability entails security precautions when calling functions in databases where some users mistrust other users; see Section 10.3.

Two functions are considered the same if they have the same names and input argument types, ignoring any OUT parameters. Thus for example these declarations conflict:

CREATE FUNCTION foo(int) … CREATE FUNCTION foo(int, out text) …

Functions that have different argument type lists will not be considered to conflict at creation time, but if defaults are provided they might conflict in use. For example, consider

CREATE FUNCTION foo(int) … CREATE FUNCTION foo(int, int default 42) …

A call foo(10) will fail due to the ambiguity about which function should be called.

NOTES

The full SQL type syntax is allowed for declaring a functions arguments and return value. However, parenthesized type modifiers (e.g., the precision field for type numeric) are discarded by CREATE FUNCTION. Thus for example CREATE FUNCTION foo (varchar(10)) … is exactly the same as CREATE FUNCTION foo (varchar) ….

When replacing an existing function with CREATE OR REPLACE FUNCTION, there are restrictions on changing parameter names. You cannot change the name already assigned to any input parameter (although you can add names to parameters that had none before). If there is more than one output parameter, you cannot change the names of the output parameters, because that would change the column names of the anonymous composite type that describes the functions result. These restrictions are made to ensure that existing calls of the function do not stop working when it is replaced.

If a function is declared STRICT with a VARIADIC argument, the strictness check tests that the variadic array as a whole is non-null. The function will still be called if the array has null elements.

EXAMPLES

Add two integers using an SQL function:

CREATE FUNCTION add(integer, integer) RETURNS integer AS select $1 + $2; LANGUAGE SQL IMMUTABLE RETURNS NULL ON NULL INPUT;

The same function written in a more SQL-conforming style, using argument names and an unquoted body:

CREATE FUNCTION add(a integer, b integer) RETURNS integer LANGUAGE SQL IMMUTABLE RETURNS NULL ON NULL INPUT RETURN a + b;

Increment an integer, making use of an argument name, in PL/pgSQL:

CREATE OR REPLACE FUNCTION increment(i integer) RETURNS integer AS $$ BEGIN RETURN i + 1; END; $$ LANGUAGE plpgsql;

Return a record containing multiple output parameters:

CREATE FUNCTION dup(in int, out f1 int, out f2 text) AS $$ SELECT $1, CAST($1 AS text) || is text $$ LANGUAGE SQL;

SELECT * FROM dup(42);

You can do the same thing more verbosely with an explicitly named composite type:

CREATE TYPE dup_result AS (f1 int, f2 text);

CREATE FUNCTION dup(int) RETURNS dup_result
    AS $$ SELECT $1, CAST($1 AS text) ||  is text $$
    LANGUAGE SQL;

SELECT * FROM dup(42);

Another way to return multiple columns is to use a TABLE function:

CREATE FUNCTION dup(int) RETURNS TABLE(f1 int, f2 text) AS $$ SELECT $1, CAST($1 AS text) || is text $$ LANGUAGE SQL;

SELECT * FROM dup(42);

However, a TABLE function is different from the preceding examples, because it actually returns a set of records, not just one record.

WRITING SECURITY DEFINER FUNCTIONS SAFELY

Because a SECURITY DEFINER function is executed with the privileges of the user that owns it, care is needed to ensure that the function cannot be misused. For security, search_path should be set to exclude any schemas writable by untrusted users. This prevents malicious users from creating objects (e.g., tables, functions, and operators) that mask objects intended to be used by the function. Particularly important in this regard is the temporary-table schema, which is searched first by default, and is normally writable by anyone. A secure arrangement can be obtained by forcing the temporary schema to be searched last. To do this, write pg_temp as the last entry in search_path. This function illustrates safe usage:

CREATE FUNCTION check_password(uname TEXT, pass TEXT) RETURNS BOOLEAN AS $$ DECLARE passed BOOLEAN; BEGIN SELECT (pwd = $2) INTO passed FROM pwds WHERE username = $1;

        RETURN passed;
END;
$$  LANGUAGE plpgsql
    SECURITY DEFINER
    -- Set a secure search_path: trusted schema(s), then pg_temp.
    SET search_path = admin, pg_temp;

This functions intention is to access a table admin.pwds. But without the SET clause, or with a SET clause mentioning only admin, the function could be subverted by creating a temporary table named pwds.

If the security definer function intends to create roles, and if it is running as a non-superuser, createrole_self_grant should also be set to a known value using the SET clause.

Another point to keep in mind is that by default, execute privilege is granted to PUBLIC for newly created functions (see Section 5.7 for more information). Frequently you will wish to restrict use of a security definer function to only some users. To do that, you must revoke the default PUBLIC privileges and then grant execute privilege selectively. To avoid having a window where the new function is accessible to all, create it and set the privileges within a single transaction. For example:

BEGIN; CREATE FUNCTION check_password(uname TEXT, pass TEXT) … SECURITY DEFINER; REVOKE ALL ON FUNCTION check_password(uname TEXT, pass TEXT) FROM PUBLIC; GRANT EXECUTE ON FUNCTION check_password(uname TEXT, pass TEXT) TO admins; COMMIT;

COMPATIBILITY

A CREATE FUNCTION command is defined in the SQL standard. The PostgreSQL implementation can be used in a compatible way but has many extensions. Conversely, the SQL standard specifies a number of optional features that are not implemented in PostgreSQL.

The following are important compatibility issues:

·

OR REPLACE is a PostgreSQL extension.

·

For compatibility with some other database systems, argmode can be written either before or after argname. But only the first way is standard-compliant.

·

For parameter defaults, the SQL standard specifies only the syntax with the DEFAULT key word. The syntax with = is used in T-SQL and Firebird.

·

The SETOF modifier is a PostgreSQL extension.

·

Only SQL is standardized as a language.

·

All other attributes except CALLED ON NULL INPUT and RETURNS NULL ON NULL INPUT are not standardized.

·

For the body of LANGUAGE SQL functions, the SQL standard only specifies the sql_body form.

Simple LANGUAGE SQL functions can be written in a way that is both standard-conforming and portable to other implementations. More complex functions using advanced features, optimization attributes, or other languages will necessarily be specific to PostgreSQL in a significant way.

SEE ALSO

ALTER FUNCTION (ALTER_FUNCTION(7)), DROP FUNCTION (DROP_FUNCTION(7)), GRANT(7), LOAD(7), REVOKE(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

55 - Linux cli command iso_8859-15

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso_8859-15 and provides detailed information about the command iso_8859-15, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso_8859-15.

NAME 🖥️ iso_8859-15 🖥️

15 - ISO/IEC 8859-15 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-15 encodes the characters used in many West European languages and adds the Euro sign.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-15 characters

The following table displays the characters in ISO/IEC 8859-15 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-15 is also known as Latin-9 (or sometimes as Latin-0).

SEE ALSO

ascii(7), charsets(7), cp1252(7), iso_8859-1(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

56 - Linux cli command life_cycle-macssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command life_cycle-macssl and provides detailed information about the command life_cycle-macssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the life_cycle-macssl.

NAME 🖥️ life_cycle-macssl 🖥️

mac - The MAC algorithm life-cycle

DESCRIPTION

All message authentication codes (MACs) go through a number of stages in their life-cycle:

start
This state represents the MAC before it has been allocated. It is the starting state for any life-cycle transitions.

newed
This state represents the MAC after it has been allocated.

initialised
This state represents the MAC when it is set up and capable of processing input.

updated
This state represents the MAC when it is set up and capable of processing additional input or generating output.

finaled
This state represents the MAC when it has generated output.

freed
This state is entered when the MAC is freed. It is the terminal state for all life-cycle transitions.

State Transition Diagram

The usual life-cycle of a MAC is illustrated: +——————-+ | start | +——————-+ | | EVP_MAC_CTX_new v +——————-+ | newed | +——————-+ | | EVP_MAC_init v +——————-+ +> | initialised | <+ | +——————-+ | | | | | | EVP_MAC_update | EVP_MAC_init | v | EVP_MAC_init | +——————-+ | | | updated | -+ | +——————-+ | | | | | EVP_MAC_final | EVP_MAC_finalXOF | v v | +——————-+ +- | finaled | +——————-+ | | EVP_MAC_CTX_free v +——————-+ | freed | +——————-+

Formal State Transitions

This section defines all of the legal state transitions. This is the canonical list. Function Call ——————— Current State ———————- start newed initialised updated finaled freed EVP_MAC_CTX_new newed EVP_MAC_init initialised initialised initialised initialised EVP_MAC_update updated updated EVP_MAC_final finaled EVP_MAC_finalXOF finaled EVP_MAC_CTX_free freed freed freed freed freed EVP_MAC_CTX_get_params newed initialised updated EVP_MAC_CTX_set_params newed initialised updated EVP_MAC_CTX_gettable_params newed initialised updated EVP_MAC_CTX_settable_params newed initialised updated

NOTES

At some point the EVP layer will begin enforcing the transitions described herein.

SEE ALSO

provider-mac (7), EVP_MAC (3).

HISTORY

The provider MAC interface was introduced in OpenSSL 3.0.

COPYRIGHT

Copyright 2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

57 - Linux cli command EVP_MD-MD2ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_MD-MD2ssl and provides detailed information about the command EVP_MD-MD2ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_MD-MD2ssl.

NAME 🖥️ EVP_MD-MD2ssl 🖥️

MD2 - The MD2 EVP_MD implementation

DESCRIPTION

Support for computing MD2 digests through the EVP_MD API.

Identity

This implementation is only available with the legacy provider, and is identified with the name “MD2”.

Gettable Parameters

This implementation supports the common gettable parameters described in EVP_MD-common (7).

SEE ALSO

provider-digest (7), OSSL_PROVIDER-default (7)

COPYRIGHT

Copyright 2020 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

58 - Linux cli command DROP_TEXT_SEARCH_DICTIONARY

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_TEXT_SEARCH_DICTIONARY and provides detailed information about the command DROP_TEXT_SEARCH_DICTIONARY, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_TEXT_SEARCH_DICTIONARY.

NAME 🖥️ DROP_TEXT_SEARCH_DICTIONARY 🖥️

remove a text search dictionary

SYNOPSIS

DROP TEXT SEARCH DICTIONARY [ IF EXISTS ] name [ CASCADE | RESTRICT ]

DESCRIPTION

DROP TEXT SEARCH DICTIONARY drops an existing text search dictionary. To execute this command you must be the owner of the dictionary.

PARAMETERS

IF EXISTS

Do not throw an error if the text search dictionary does not exist. A notice is issued in this case.

name

The name (optionally schema-qualified) of an existing text search dictionary.

CASCADE

Automatically drop objects that depend on the text search dictionary, and in turn all objects that depend on those objects (see Section 5.14).

RESTRICT

Refuse to drop the text search dictionary if any objects depend on it. This is the default.

EXAMPLES

Remove the text search dictionary english:

DROP TEXT SEARCH DICTIONARY english;

This command will not succeed if there are any existing text search configurations that use the dictionary. Add CASCADE to drop such configurations along with the dictionary.

COMPATIBILITY

There is no DROP TEXT SEARCH DICTIONARY statement in the SQL standard.

SEE ALSO

ALTER TEXT SEARCH DICTIONARY (ALTER_TEXT_SEARCH_DICTIONARY(7)), CREATE TEXT SEARCH DICTIONARY (CREATE_TEXT_SEARCH_DICTIONARY(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

59 - Linux cli command hashid

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command hashid and provides detailed information about the command hashid, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the hashid.

NAME 🖥️ hashid 🖥️

Identify the different types of hashes used to encrypt data

SYNOPSIS

hashid [-h] [-e] [-m] [-j] [-o FILE] [–version] INPUT

DESCRIPTION

hashID is a tool written in Python 3.x which supports the identification of over 210 unique hash types using regular expressions.

It is able to identify a single hash, parse a file or read files in a directory and identify the hashes within them. hashID is also capable of including the corresponding hashcat mode and/or JohnTheRipper format in its output. Although hashID is written in Python 3.x it should also work with Python 2.7.

OPTIONS

-e, –extended
list all possible hash algorithms including salted passwords

-m, –mode
include corresponding hashcat mode in output

-j, –john
include corresponding JohnTheRipper format in output

-o FILE, –outfile FILE
write output to file (default: STDOUT)

-h, –help
show help message and exit

–version
show program’s version number and exit

BUGS

If you find a bug, please report it at https://github.com/psypanda/hashID/issues

AUTHOR

c0re ([email protected])

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

60 - Linux cli command DROP_TEXT_SEARCH_PARSER

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_TEXT_SEARCH_PARSER and provides detailed information about the command DROP_TEXT_SEARCH_PARSER, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_TEXT_SEARCH_PARSER.

NAME 🖥️ DROP_TEXT_SEARCH_PARSER 🖥️

remove a text search parser

SYNOPSIS

DROP TEXT SEARCH PARSER [ IF EXISTS ] name [ CASCADE | RESTRICT ]

DESCRIPTION

DROP TEXT SEARCH PARSER drops an existing text search parser. You must be a superuser to use this command.

PARAMETERS

IF EXISTS

Do not throw an error if the text search parser does not exist. A notice is issued in this case.

name

The name (optionally schema-qualified) of an existing text search parser.

CASCADE

Automatically drop objects that depend on the text search parser, and in turn all objects that depend on those objects (see Section 5.14).

RESTRICT

Refuse to drop the text search parser if any objects depend on it. This is the default.

EXAMPLES

Remove the text search parser my_parser:

DROP TEXT SEARCH PARSER my_parser;

This command will not succeed if there are any existing text search configurations that use the parser. Add CASCADE to drop such configurations along with the parser.

COMPATIBILITY

There is no DROP TEXT SEARCH PARSER statement in the SQL standard.

SEE ALSO

ALTER TEXT SEARCH PARSER (ALTER_TEXT_SEARCH_PARSER(7)), CREATE TEXT SEARCH PARSER (CREATE_TEXT_SEARCH_PARSER(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

61 - Linux cli command pthreads

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command pthreads and provides detailed information about the command pthreads, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the pthreads.

NAME 🖥️ pthreads 🖥️

POSIX threads

DESCRIPTION

POSIX.1 specifies a set of interfaces (functions, header files) for threaded programming commonly known as POSIX threads, or Pthreads. A single process can contain multiple threads, all of which are executing the same program. These threads share the same global memory (data and heap segments), but each thread has its own stack (automatic variables).

POSIX.1 also requires that threads share a range of other attributes (i.e., these attributes are process-wide rather than per-thread):

  • process ID

  • parent process ID

  • process group ID and session ID

  • controlling terminal

  • user and group IDs

  • open file descriptors

  • record locks (see fcntl(2))

  • signal dispositions

  • file mode creation mask (umask(2))

  • current directory (chdir(2)) and root directory (chroot(2))

  • interval timers (setitimer(2)) and POSIX timers (timer_create(2))

  • nice value (setpriority(2))

  • resource limits (setrlimit(2))

  • measurements of the consumption of CPU time (times(2)) and resources (getrusage(2))

As well as the stack, POSIX.1 specifies that various other attributes are distinct for each thread, including:

  • thread ID (the pthread_t data type)

  • signal mask (pthread_sigmask(3))

  • the errno variable

  • alternate signal stack (sigaltstack(2))

  • real-time scheduling policy and priority (sched(7))

The following Linux-specific features are also per-thread:

  • capabilities (see capabilities(7))

  • CPU affinity (sched_setaffinity(2))

Pthreads function return values

Most pthreads functions return 0 on success, and an error number on failure. The error numbers that can be returned have the same meaning as the error numbers returned in errno by conventional system calls and C library functions. Note that the pthreads functions do not set errno. For each of the pthreads functions that can return an error, POSIX.1-2001 specifies that the function can never fail with the error EINTR.

Thread IDs

Each of the threads in a process has a unique thread identifier (stored in the type pthread_t). This identifier is returned to the caller of pthread_create(3), and a thread can obtain its own thread identifier using pthread_self(3).

Thread IDs are guaranteed to be unique only within a process. (In all pthreads functions that accept a thread ID as an argument, that ID by definition refers to a thread in the same process as the caller.)

The system may reuse a thread ID after a terminated thread has been joined, or a detached thread has terminated. POSIX says: “If an application attempts to use a thread ID whose lifetime has ended, the behavior is undefined.”

Thread-safe functions

A thread-safe function is one that can be safely (i.e., it will deliver the same results regardless of whether it is) called from multiple threads at the same time.

POSIX.1-2001 and POSIX.1-2008 require that all functions specified in the standard shall be thread-safe, except for the following functions:

asctime()
basename()
catgets()
crypt()
ctermid() if passed a non-NULL argument
ctime()
dbm_clearerr()
dbm_close()
dbm_delete()
dbm_error()
dbm_fetch()
dbm_firstkey()
dbm_nextkey()
dbm_open()
dbm_store()
dirname()
dlerror()
drand48()
ecvt() [POSIX.1-2001 only (function removed in POSIX.1-2008)]
encrypt()
endgrent()
endpwent()
endutxent()
fcvt() [POSIX.1-2001 only (function removed in POSIX.1-2008)]
ftw()
gcvt() [POSIX.1-2001 only (function removed in POSIX.1-2008)]
getc_unlocked()
getchar_unlocked()
getdate()
getenv()
getgrent()
getgrgid()
getgrnam()
gethostbyaddr() [POSIX.1-2001 only (function removed in
                 POSIX.1-2008)]
gethostbyname() [POSIX.1-2001 only (function removed in
                 POSIX.1-2008)]
gethostent()
getlogin()
getnetbyaddr()
getnetbyname()
getnetent()
getopt()
getprotobyname()
getprotobynumber()
getprotoent()
getpwent()
getpwnam()
getpwuid()
getservbyname()
getservbyport()
getservent()
getutxent()
getutxid()
getutxline()
gmtime()
hcreate()
hdestroy()
hsearch()
inet_ntoa()
l64a()
lgamma()
lgammaf()
lgammal()
localeconv()
localtime()
lrand48()
mrand48()
nftw()
nl_langinfo()
ptsname()
putc_unlocked()
putchar_unlocked()
putenv()
pututxline()
rand()
readdir()
setenv()
setgrent()
setkey()
setpwent()
setutxent()
strerror()
strsignal() [Added in POSIX.1-2008]
strtok()
system() [Added in POSIX.1-2008]
tmpnam() if passed a non-NULL argument
ttyname()
unsetenv()
wcrtomb() if its final argument is NULL
wcsrtombs() if its final argument is NULL
wcstombs()
wctomb()

Async-cancel-safe functions

An async-cancel-safe function is one that can be safely called in an application where asynchronous cancelability is enabled (see pthread_setcancelstate(3)).

Only the following functions are required to be async-cancel-safe by POSIX.1-2001 and POSIX.1-2008:

pthread_cancel()
pthread_setcancelstate()
pthread_setcanceltype()

Cancelation points

POSIX.1 specifies that certain functions must, and certain other functions may, be cancelation points. If a thread is cancelable, its cancelability type is deferred, and a cancelation request is pending for the thread, then the thread is canceled when it calls a function that is a cancelation point.

The following functions are required to be cancelation points by POSIX.1-2001 and/or POSIX.1-2008:

accept()
aio_suspend()
clock_nanosleep()
close()
connect()
creat()
fcntl() F_SETLKW
fdatasync()
fsync()
getmsg()
getpmsg()
lockf() F_LOCK
mq_receive()
mq_send()
mq_timedreceive()
mq_timedsend()
msgrcv()
msgsnd()
msync()
nanosleep()
open()
openat() [Added in POSIX.1-2008]
pause()
poll()
pread()
pselect()
pthread_cond_timedwait()
pthread_cond_wait()
pthread_join()
pthread_testcancel()
putmsg()
putpmsg()
pwrite()
read()
readv()
recv()
recvfrom()
recvmsg()
select()
sem_timedwait()
sem_wait()
send()
sendmsg()
sendto()
sigpause() [POSIX.1-2001 only (moves to "may" list in POSIX.1-2008)]
sigsuspend()
sigtimedwait()
sigwait()
sigwaitinfo()
sleep()
system()
tcdrain()
usleep() [POSIX.1-2001 only (function removed in POSIX.1-2008)]
wait()
waitid()
waitpid()
write()
writev()

The following functions may be cancelation points according to POSIX.1-2001 and/or POSIX.1-2008:

access()
asctime()
asctime_r()
catclose()
catgets()
catopen()
chmod() [Added in POSIX.1-2008]
chown() [Added in POSIX.1-2008]
closedir()
closelog()
ctermid()
ctime()
ctime_r()
dbm_close()
dbm_delete()
dbm_fetch()
dbm_nextkey()
dbm_open()
dbm_store()
dlclose()
dlopen()
dprintf() [Added in POSIX.1-2008]
endgrent()
endhostent()
endnetent()
endprotoent()
endpwent()
endservent()
endutxent()
faccessat() [Added in POSIX.1-2008]
fchmod() [Added in POSIX.1-2008]
fchmodat() [Added in POSIX.1-2008]
fchown() [Added in POSIX.1-2008]
fchownat() [Added in POSIX.1-2008]
fclose()
fcntl() (for any value of cmd argument)
fflush()
fgetc()
fgetpos()
fgets()
fgetwc()
fgetws()
fmtmsg()
fopen()
fpathconf()
fprintf()
fputc()
fputs()
fputwc()
fputws()
fread()
freopen()
fscanf()
fseek()
fseeko()
fsetpos()
fstat()
fstatat() [Added in POSIX.1-2008]
ftell()
ftello()
ftw()
futimens() [Added in POSIX.1-2008]
fwprintf()
fwrite()
fwscanf()
getaddrinfo()
getc()
getc_unlocked()
getchar()
getchar_unlocked()
getcwd()
getdate()
getdelim() [Added in POSIX.1-2008]
getgrent()
getgrgid()
getgrgid_r()
getgrnam()
getgrnam_r()
gethostbyaddr() [POSIX.1-2001 only (function removed in
                 POSIX.1-2008)]
gethostbyname() [POSIX.1-2001 only (function removed in
                 POSIX.1-2008)]
gethostent()
gethostid()
gethostname()
getline() [Added in POSIX.1-2008]
getlogin()
getlogin_r()
getnameinfo()
getnetbyaddr()
getnetbyname()
getnetent()
getopt() (if opterr is nonzero)
getprotobyname()
getprotobynumber()
getprotoent()
getpwent()
getpwnam()
getpwnam_r()
getpwuid()
getpwuid_r()
gets()
getservbyname()
getservbyport()
getservent()
getutxent()
getutxid()
getutxline()
getwc()
getwchar()
getwd() [POSIX.1-2001 only (function removed in POSIX.1-2008)]
glob()
iconv_close()
iconv_open()
ioctl()
link()
linkat() [Added in POSIX.1-2008]
lio_listio() [Added in POSIX.1-2008]
localtime()
localtime_r()
lockf() [Added in POSIX.1-2008]
lseek()
lstat()
mkdir() [Added in POSIX.1-2008]
mkdirat() [Added in POSIX.1-2008]
mkdtemp() [Added in POSIX.1-2008]
mkfifo() [Added in POSIX.1-2008]
mkfifoat() [Added in POSIX.1-2008]
mknod() [Added in POSIX.1-2008]
mknodat() [Added in POSIX.1-2008]
mkstemp()
mktime()
nftw()
opendir()
openlog()
pathconf()
pclose()
perror()
popen()
posix_fadvise()
posix_fallocate()
posix_madvise()
posix_openpt()
posix_spawn()
posix_spawnp()
posix_trace_clear()
posix_trace_close()
posix_trace_create()
posix_trace_create_withlog()
posix_trace_eventtypelist_getnext_id()
posix_trace_eventtypelist_rewind()
posix_trace_flush()
posix_trace_get_attr()
posix_trace_get_filter()
posix_trace_get_status()
posix_trace_getnext_event()
posix_trace_open()
posix_trace_rewind()
posix_trace_set_filter()
posix_trace_shutdown()
posix_trace_timedgetnext_event()
posix_typed_mem_open()
printf()
psiginfo() [Added in POSIX.1-2008]
psignal() [Added in POSIX.1-2008]
pthread_rwlock_rdlock()
pthread_rwlock_timedrdlock()
pthread_rwlock_timedwrlock()
pthread_rwlock_wrlock()
putc()
putc_unlocked()
putchar()
putchar_unlocked()
puts()
pututxline()
putwc()
putwchar()
readdir()
readdir_r()
readlink() [Added in POSIX.1-2008]
readlinkat() [Added in POSIX.1-2008]
remove()
rename()
renameat() [Added in POSIX.1-2008]
rewind()
rewinddir()
scandir() [Added in POSIX.1-2008]
scanf()
seekdir()
semop()
setgrent()
sethostent()
setnetent()
setprotoent()
setpwent()
setservent()
setutxent()
sigpause() [Added in POSIX.1-2008]
stat()
strerror()
strerror_r()
strftime()
symlink()
symlinkat() [Added in POSIX.1-2008]
sync()
syslog()
tmpfile()
tmpnam()
ttyname()
ttyname_r()
tzset()
ungetc()
ungetwc()
unlink()
unlinkat() [Added in POSIX.1-2008]
utime() [Added in POSIX.1-2008]
utimensat() [Added in POSIX.1-2008]
utimes() [Added in POSIX.1-2008]
vdprintf() [Added in POSIX.1-2008]
vfprintf()
vfwprintf()
vprintf()
vwprintf()
wcsftime()
wordexp()
wprintf()
wscanf()

An implementation may also mark other functions not specified in the standard as cancelation points. In particular, an implementation is likely to mark any nonstandard function that may block as a cancelation point. (This includes most functions that can touch files.)

It should be noted that even if an application is not using asynchronous cancelation, that calling a function from the above list from an asynchronous signal handler may cause the equivalent of asynchronous cancelation. The underlying user code may not expect asynchronous cancelation and the state of the user data may become inconsistent. Therefore signals should be used with caution when entering a region of deferred cancelation.

Compiling on Linux

On Linux, programs that use the Pthreads API should be compiled using cc -pthread.

Linux implementations of POSIX threads

Over time, two threading implementations have been provided by the GNU C library on Linux:

LinuxThreads
This is the original Pthreads implementation. Since glibc 2.4, this implementation is no longer supported.

NPTL (Native POSIX Threads Library)
This is the modern Pthreads implementation. By comparison with LinuxThreads, NPTL provides closer conformance to the requirements of the POSIX.1 specification and better performance when creating large numbers of threads. NPTL is available since glibc 2.3.2, and requires features that are present in the Linux 2.6 kernel.

Both of these are so-called 1:1 implementations, meaning that each thread maps to a kernel scheduling entity. Both threading implementations employ the Linux clone(2) system call. In NPTL, thread synchronization primitives (mutexes, thread joining, and so on) are implemented using the Linux futex(2) system call.

LinuxThreads

The notable features of this implementation are the following:

  • In addition to the main (initial) thread, and the threads that the program creates using pthread_create(3), the implementation creates a “manager” thread. This thread handles thread creation and termination. (Problems can result if this thread is inadvertently killed.)

  • Signals are used internally by the implementation. On Linux 2.2 and later, the first three real-time signals are used (see also signal(7)). On older Linux kernels, SIGUSR1 and SIGUSR2 are used. Applications must avoid the use of whichever set of signals is employed by the implementation.

  • Threads do not share process IDs. (In effect, LinuxThreads threads are implemented as processes which share more information than usual, but which do not share a common process ID.) LinuxThreads threads (including the manager thread) are visible as separate processes using ps(1).

The LinuxThreads implementation deviates from the POSIX.1 specification in a number of ways, including the following:

  • Calls to getpid(2) return a different value in each thread.

  • Calls to getppid(2) in threads other than the main thread return the process ID of the manager thread; instead getppid(2) in these threads should return the same value as getppid(2) in the main thread.

  • When one thread creates a new child process using fork(2), any thread should be able to wait(2) on the child. However, the implementation allows only the thread that created the child to wait(2) on it.

  • When a thread calls execve(2), all other threads are terminated (as required by POSIX.1). However, the resulting process has the same PID as the thread that called execve(2): it should have the same PID as the main thread.

  • Threads do not share user and group IDs. This can cause complications with set-user-ID programs and can cause failures in Pthreads functions if an application changes its credentials using seteuid(2) or similar.

  • Threads do not share a common session ID and process group ID.

  • Threads do not share record locks created using fcntl(2).

  • The information returned by times(2) and getrusage(2) is per-thread rather than process-wide.

  • Threads do not share semaphore undo values (see semop(2)).

  • Threads do not share interval timers.

  • Threads do not share a common nice value.

  • POSIX.1 distinguishes the notions of signals that are directed to the process as a whole and signals that are directed to individual threads. According to POSIX.1, a process-directed signal (sent using kill(2), for example) should be handled by a single, arbitrarily selected thread within the process. LinuxThreads does not support the notion of process-directed signals: signals may be sent only to specific threads.

  • Threads have distinct alternate signal stack settings. However, a new thread’s alternate signal stack settings are copied from the thread that created it, so that the threads initially share an alternate signal stack. (A new thread should start with no alternate signal stack defined. If two threads handle signals on their shared alternate signal stack at the same time, unpredictable program failures are likely to occur.)

NPTL

With NPTL, all of the threads in a process are placed in the same thread group; all members of a thread group share the same PID. NPTL does not employ a manager thread.

NPTL makes internal use of the first two real-time signals; these signals cannot be used in applications. See nptl(7) for further details.

NPTL still has at least one nonconformance with POSIX.1:

  • Threads do not share a common nice value.

Some NPTL nonconformances occur only with older kernels:

  • The information returned by times(2) and getrusage(2) is per-thread rather than process-wide (fixed in Linux 2.6.9).

  • Threads do not share resource limits (fixed in Linux 2.6.10).

  • Threads do not share interval timers (fixed in Linux 2.6.12).

  • Only the main thread is permitted to start a new session using setsid(2) (fixed in Linux 2.6.16).

  • Only the main thread is permitted to make the process into a process group leader using setpgid(2) (fixed in Linux 2.6.16).

  • Threads have distinct alternate signal stack settings. However, a new thread’s alternate signal stack settings are copied from the thread that created it, so that the threads initially share an alternate signal stack (fixed in Linux 2.6.16).

Note the following further points about the NPTL implementation:

  • If the stack size soft resource limit (see the description of RLIMIT_STACK in setrlimit(2)) is set to a value other than unlimited, then this value defines the default stack size for new threads. To be effective, this limit must be set before the program is executed, perhaps using the ulimit -s shell built-in command (limit stacksize in the C shell).

Determining the threading implementation

Since glibc 2.3.2, the getconf(1) command can be used to determine the system’s threading implementation, for example:

bash$ getconf GNU_LIBPTHREAD_VERSION
NPTL 2.3.4

With older glibc versions, a command such as the following should be sufficient to determine the default threading implementation:

bash$ $( ldd /bin/ls | grep libc.so | awk '{print $3}' ) | \
                egrep -i 'threads|nptl'
        Native POSIX Threads Library by Ulrich Drepper et al

Selecting the threading implementation: LD_ASSUME_KERNEL

On systems with a glibc that supports both LinuxThreads and NPTL (i.e., glibc 2.3.x), the LD_ASSUME_KERNEL environment variable can be used to override the dynamic linker’s default choice of threading implementation. This variable tells the dynamic linker to assume that it is running on top of a particular kernel version. By specifying a kernel version that does not provide the support required by NPTL, we can force the use of LinuxThreads. (The most likely reason for doing this is to run a (broken) application that depends on some nonconformant behavior in LinuxThreads.) For example:

bash$ $( LD_ASSUME_KERNEL=2.2.5 ldd /bin/ls | grep libc.so | \
                awk '{print $3}' ) | egrep -i 'threads|nptl'
        linuxthreads-0.10 by Xavier Leroy

SEE ALSO

clone(2), fork(2), futex(2), gettid(2), proc(5), attributes(7), futex(7), nptl(7), sigevent(3type), signal(7)

Various Pthreads manual pages, for example: pthread_atfork(3), pthread_attr_init(3), pthread_cancel(3), pthread_cleanup_push(3), pthread_cond_signal(3), pthread_cond_wait(3), pthread_create(3), pthread_detach(3), pthread_equal(3), pthread_exit(3), pthread_key_create(3), pthread_kill(3), pthread_mutex_lock(3), pthread_mutex_unlock(3), pthread_mutexattr_destroy(3), pthread_mutexattr_init(3), pthread_once(3), pthread_spin_init(3), pthread_spin_lock(3), pthread_rwlockattr_setkind_np(3), pthread_setcancelstate(3), pthread_setcanceltype(3), pthread_setspecific(3), pthread_sigmask(3), pthread_sigqueue(3), and pthread_testcancel(3)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

62 - Linux cli command systemd.net-naming-scheme

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command systemd.net-naming-scheme and provides detailed information about the command systemd.net-naming-scheme, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the systemd.net-naming-scheme.

NAME 🖥️ systemd.net-naming-scheme 🖥️

naming-scheme - Network device naming schemes

DESCRIPTION

Network interfaces names and MAC addresses may be generated based on certain stable interface attributes. This is possible when there is enough information about the device to generate those attributes and the use of this information is configured. This page describes interface naming, i.e. what possible names may be generated. Those names are generated by the systemd-udevd.service(8) builtin net_id and exported as udev properties (ID_NET_NAME_ONBOARD=, ID_NET_LABEL_ONBOARD=, ID_NET_NAME_PATH=, ID_NET_NAME_SLOT=).

Names and MAC addresses are derived from various stable device metadata attributes. Newer versions of udev take more of these attributes into account, improving (and thus possibly changing) the names and addresses used for the same devices. Different versions of those generation rules are called “naming schemes”. The default naming scheme is chosen at compilation time. Usually this will be the latest implemented version, but it is also possible to set one of the older versions to preserve compatibility. This may be useful for example for distributions, which may introduce new versions of systemd in stable releases without changing the naming scheme. The naming scheme may also be overridden using the net.naming_scheme= kernel command line switch, see systemd-udevd.service(8). Available naming schemes are described below.

After the udev properties have been generated, appropriate udev rules may be used to actually rename devices based on those properties. See the description of NamePolicy= and MACAddressPolicy= in systemd.link(5).

Note that while the concept of network interface naming schemes is primarily relevant in the context of systemd-udevd.service, the systemd-nspawn(1) container manager also takes it into account when naming network interfaces, see below.

POLICIES

All names start with a two-character prefix that signifies the interface type.

Table 1. Two character prefixes based on the type of interface

PrefixDescription
enEthernet
ibInfiniBand
slSerial line IP (slip)
wlWireless local area network (WLAN)
wwWireless wide area network (WWAN)

The udev net_id builtin exports the following udev device properties:

ID_NET_NAME_ONBOARD=prefixonumber, ID_NET_NAME_ONBOARD=prefixdnumber

This name is set based on the numeric ordering information given by the firmware for on-board devices. Different schemes are used depending on the firmware type, as described in the table below.

Table 2. On-board naming schemes

FormatDescription
prefixonumberPCI on-board index
prefixdnumberDevicetree alias index

Added in version 243.

ID_NET_LABEL_ONBOARD=prefix label

This property is set based on textual label given by the firmware for on-board devices. The name consists of the prefix concatenated with the label. This is only available for PCI devices.

Added in version 243.

ID_NET_NAME_MAC=prefixxAABBCCDDEEFF

This name consists of the prefix, letter x, and 12 hexadecimal digits of the MAC address. It is available if the device has a fixed MAC address. Because this name is based on an attribute of the card itself, it remains “stable” when the device is moved (even between machines), but will change when the hardware is replaced.

Added in version 243.

ID_NET_NAME_SLOT=prefix[Pdomain]sslot[ffunction][nport_name|ddev_port], ID_NET_NAME_SLOT=prefixvslot, ID_NET_NAME_SLOT=prefixxslot, ID_NET_NAME_SLOT=prefix[Pdomain]sslot[ffunction][nport_name|ddev_port]bnumber, ID_NET_NAME_SLOT=prefix[Pdomain]sslot[ffunction][nport_name|ddev_port]uport…[cconfig][iinterface], ID_NET_NAME_SLOT=prefix[Pdomain]sslot[ffunction][nport_name|ddev_port]vslot, ID_NET_NAME_SLOT=prefix[Pdomain]sslot[ffunction][nport_name|ddev_port]rslot

This property describes the slot position. Different schemes are used depending on the bus type, as described in the table below. In case of USB, BCMA, and SR-VIO devices, the full name consists of the prefix, PCI slot identifier, and USB or BCMA or SR-VIO slot identifier. The first two parts are denoted as “…” in the table below.

Table 3. Slot naming schemes

FormatDescription
prefix [Pdomain] sslot [ffunction] [nport_name | ddev_port]PCI slot number
prefix vslotVIO slot number (IBM PowerVM)
prefix XnumberVIF interface number (Xen)
... bnumberBroadcom bus (BCMA) core number
... uport... [cconfig] [iinterface]USB port number chain
... vslotSR-VIO slot number
... rslotSR-IOV slot number

The PCI domain is only prepended when it is not 0. All multi-function PCI devices will carry the ffunction number in the device name, including the function 0 device. For non-multi-function devices, the number is suppressed if 0. The port name port_name is used, or the port number ddev_port if the name is not known.

For BCMA devices, the core number is suppressed when 0.

For USB devices the full chain of port numbers of hubs is composed. If the name gets longer than the maximum number of 15 characters, the name is not exported. The usual USB configuration number 1 and interface number 0 values are suppressed.

SR-IOV virtual devices are named based on the name of the parent interface, with a suffix of v and the virtual device number, with any leading zeros removed. The bus number is ignored.

SR-IOV virtual device representors are named based on the name of the physical device interface, with a suffix of r and the number of the virtual device that is linked to the particular representor, with any leading zeros removed. The physical port name and the bus number are ignored.

In some configurations a parent PCI bridge of a given network controller may be associated with a slot. In such case we dont generate this device property to avoid possible naming conflicts.

Added in version 243.

ID_NET_NAME_PATH=prefixcbus_id, ID_NET_NAME_PATH=prefixavendormodeliinstance, ID_NET_NAME_PATH=prefixiaddressnport_name, ID_NET_NAME_PATH=prefixuport…, ID_NET_NAME_PATH=prefix[Pdomain]pbussslot[ffunction][nphys_port_name|ddev_port], ID_NET_NAME_PATH=prefix[Pdomain]pbussslot[ffunction][nphys_port_name|ddev_port]bnumber, ID_NET_NAME_PATH=prefix[Pdomain]pbussslot[ffunction][nphys_port_name|ddev_port]uport…[cconfig][iinterface]

This property describes the device installation location. Different schemes are used depending on the bus type, as described in the table below. For BCMA and USB devices, PCI path information must known, and the full name consists of the prefix, PCI slot identifier, and USB or BCMA location. The first two parts are denoted as “…” in the table below.

Table 4. Path naming schemes

FormatDescription
prefix cbus_idCCW or grouped CCW device identifier
prefix avendor model iinstanceACPI path names for ARM64 platform devices
prefix iaddress nport_nameNetdevsim (simulated networking device) device number and port name
prefix [Pdomain] pbus sslot [ffunction] [nphys_port_name | ddev_port]PCI geographical location
... bnumberBroadcom bus (BCMA) core number
... uport... [cconfig] [iinterface]USB port number chain

CCW and grouped CCW devices are found in IBM System Z mainframes. Any leading zeros and dots are suppressed.

For PCI, BCMA, and USB devices, the same rules as described above for slot naming are used.

Added in version 243.

HISTORY

The following “naming schemes” have been defined (which may be chosen at system boot-up time via the net.naming_scheme= kernel command line switch, see above):

v238

This is the naming scheme that was implemented in systemd 238.

Added in version 243.

v239

Naming was changed for virtual network interfaces created with SR-IOV and NPAR and for devices where the PCI network controller device does not have a slot number associated.

SR-IOV virtual devices are named based on the name of the parent interface, with a suffix of “vport”, where port is the virtual device number. Previously those virtual devices were named as if completely independent.

The ninth and later NPAR virtual devices are named following the scheme used for the first eight NPAR partitions. Previously those devices were not renamed and the kernel default (“ethN”) was used.

Names are also generated for PCI devices where the PCI network controller device does not have an associated slot number itself, but one of its parents does. Previously those devices were not renamed and the kernel default was used.

Added in version 243.

v240

The “ib” prefix and stable names for infiniband devices are introduced. Previously those devices were not renamed.

The ACPI index field (used in ID_NET_NAME_ONBOARD=) is now also used when 0.

A new naming policy NamePolicy=keep was introduced. With this policy, if the network device name was already set by userspace, the device will not be renamed again. Previously, this naming policy applied implicitly, and now it must be explicitly requested. Effectively, this means that network devices will be renamed according to the configuration, even if they have been renamed already, if keep is not specified as the naming policy in the .link file. See systemd.link(5) for a description of NamePolicy=.

Added in version 243.

v241

MACAddressPolicy=persistent was extended to set MAC addresses based on the device name. Previously addresses were only based on the ID_NET_NAME_* attributes, which meant that interface names would never be generated for virtual devices. Now a persistent address will be generated for most devices, including in particular bridges.

Note: when userspace does not set a MAC address for a bridge device, the kernel will initially assign a random address, and then change it when the first device is enslaved to the bridge. With this naming policy change, bridges get a persistent MAC address based on the bridge name instead of the first enslaved device.

Added in version 243.

v243

Support for renaming netdevsim (simulated networking) devices was added. Previously those devices were not renamed.

Previously two-letter interface type prefix was prepended to ID_NET_LABEL_ONBOARD=. This is not done anymore.

Added in version 243.

v245

When systemd-nspawn(1) derives the name for the host side of the network interface created with –network-veth from the container name it previously simply truncated the result at 15 characters if longer (since thats the maximum length for network interface names). From now on, for any interface name that would be longer than 15 characters the last 4 characters are set to a 24bit hash value of the full interface name. This way network interface name collisions between multiple similarly named containers (who only differ in container name suffix) should be less likely (but still possible, since the 24bit hash value is very small).

Added in version 245.

v247

When a PCI slot is associated with a PCI bridge that has multiple child network controllers, the same value of the ID_NET_NAME_SLOT property might be derived for those controllers. This would cause a naming conflict if the property is selected as the device name. Now, we detect this situation and dont produce the ID_NET_NAME_SLOT property.

Added in version 247.

v249

PCI hotplug slot names for the s390 PCI driver are a hexadecimal representation of the function_id device attribute. This attribute is now used to build the ID_NET_NAME_SLOT. Before that, all slot names were parsed as decimal numbers, which could either result in an incorrect value of the ID_NET_NAME_SLOT property or none at all.

Some firmware and hypervisor implementations report unreasonably high numbers for the on-board index. To prevent the generation of bogus on-board interface names, index numbers greater than 16381 (2¹⁴-1) were ignored. For s390 PCI devices index values up to 65535 (2¹⁶-1) are valid. To account for that, the limit was increased to 65535.

The udev rule NAME= replaces “:”, “/”, and “%” with an underscore ("_"), and refuses strings which contain only numerics.

Added in version 249.

v250

Added naming scheme for Xen netfront “vif” interfaces based on the guest side VIF number set from the Xen config (or the interface index in AWS EC2).

Added in version 250.

v251

Since version v247 we no longer set ID_NET_NAME_SLOT if we detect that a PCI device associated with a slot is a PCI bridge as that would create naming conflict when there are more child devices on that bridge. Now, this is relaxed and we will use slot information to generate the name based on it but only if the PCI device has multiple functions. This is safe because distinct function number is a part of the device name for multifunction devices.

Added in version 251.

v252

Added naming scheme for platform devices with devicetree aliases.

Added in version 252.

v253

Set ID_NET_NAME_PATH for usb devices not connected via a PCI bus.

Added in version 253.

v254

Naming was changed for SR-IOV virtual device representors, optionally settable at compilation time. The “rslot” suffix was added to differentiate SR-IOV virtual device representors attached to a single physical device interface. Because of a mistake, this scheme was not the default scheme for systemd version 254.

Added in version 255.

v255

Naming was changed for SR-IOV virtual device representors to enable the change introduced in v254 by default.

Added in version 255.

Note that latest may be used to denote the latest scheme known (to this particular version of systemd).

LIMITING THE USE OF SPECIFIC SYSFS ATTRIBUTES

When creating names for network cards, some naming schemes use data from sysfs populated by the kernel. This means that although a specific naming scheme in udev is picked, the network cards name can still change when a new kernel version adds a new sysfs attribute. For example if kernel starts setting the phys_port_name, udev will append the “nphys_port_name” suffix to the device name.

ID_NET_NAME_ALLOW=BOOL

This udev property sets a fallback policy for reading a sysfs attribute. If set to 0 udev will not read any sysfs attribute by default, unless it is explicitly allowlisted, see below. If set to 1 udev can use any sysfs attribute unless it is explicitly forbidden. The default value is 1.

Added in version 256.

ID_NET_NAME_ALLOW_sysfsattr=BOOL

This udev property explicitly states if udev shall use the specified sysfsattr, when composing the device name.

Added in version 256.

With these options, users can set an allowlist or denylist for sysfs attributes. To create an allowlist, the user needs to set ID_NET_NAME_ALLOW=0 for the device and then list the allowed attributes with the ID_NET_NAME_ALLOW_sysfsattr=1 options. In case of a denylist, the user needs to provide the list of denied attributes with the ID_NET_NAME_ALLOW_sysfsattr=0 options.

EXAMPLES

Example 1. Using udevadm test-builtin to display device properties

$ udevadm test-builtin net_id /sys/class/net/enp0s31f6 … Using default interface naming scheme v243. ID_NET_NAMING_SCHEME=v243 ID_NET_NAME_MAC=enx54ee75cb1dc0 ID_OUI_FROM_DATABASE=Wistron InfoComm(Kunshan)Co.,Ltd. ID_NET_NAME_PATH=enp0s31f6 …

Example 2. PCI Ethernet card with firmware index “1”

ID_NET_NAME_ONBOARD=eno1 ID_NET_NAME_ONBOARD_LABEL=Ethernet Port 1

Example 3. PCI Ethernet card in hotplug slot with firmware index number

/sys/devices/pci0000:00/0000:00:1c.3/0000:05:00.0/net/ens1

ID_NET_NAME_MAC=enx000000000466
ID_NET_NAME_PATH=enp5s0
ID_NET_NAME_SLOT=ens1

Example 4. PCI Ethernet multi-function card with 2 ports

/sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/net/enp2s0f0

ID_NET_NAME_MAC=enx78e7d1ea46da
ID_NET_NAME_PATH=enp2s0f0

# /sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.1/net/enp2s0f1
ID_NET_NAME_MAC=enx78e7d1ea46dc
ID_NET_NAME_PATH=enp2s0f1

Example 5. PCI WLAN card

/sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/net/wlp3s0

ID_NET_NAME_MAC=wlx0024d7e31130
ID_NET_NAME_PATH=wlp3s0

Example 6. PCI IB host adapter with 2 ports

/sys/devices/pci0000:00/0000:00:03.0/0000:15:00.0/net/ibp21s0f0

ID_NET_NAME_PATH=ibp21s0f0

# /sys/devices/pci0000:00/0000:00:03.0/0000:15:00.1/net/ibp21s0f1
ID_NET_NAME_PATH=ibp21s0f1

Example 7. USB built-in 3G modem

/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4:1.6/net/wwp0s29u1u4i6

ID_NET_NAME_MAC=wwx028037ec0200
ID_NET_NAME_PATH=wwp0s29u1u4i6

Example 8. USB Android phone

/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/net/enp0s29u1u2

ID_NET_NAME_MAC=enxd626b3450fb5
ID_NET_NAME_PATH=enp0s29u1u2

Example 9. s390 grouped CCW interface

/sys/devices/css0/0.0.0007/0.0.f5f0/group_device/net/encf5f0

ID_NET_NAME_MAC=enx026d3c00000a
ID_NET_NAME_PATH=encf5f0

Example 10. Set an allowlist for reading sysfs attributes for network card naming

/etc/udev/hwdb.d/50-net-naming-allowlist.hwdb net:naming:drvirtio_net:* ID_NET_NAME_ALLOW=0 ID_NET_NAME_ALLOW_ACPI_INDEX=1 ID_NET_NAME_ALLOW_ADDR_ASSIGN_TYPE=1 ID_NET_NAME_ALLOW_ADDRESS=1 ID_NET_NAME_ALLOW_ARI_ENABLED=1 ID_NET_NAME_ALLOW_DEV_PORT=1 ID_NET_NAME_ALLOW_FUNCTION_ID=1 ID_NET_NAME_ALLOW_IFLINK=1 ID_NET_NAME_ALLOW_INDEX=1 ID_NET_NAME_ALLOW_LABEL=1 ID_NET_NAME_ALLOW_PHYS_PORT_NAME=1 ID_NET_NAME_ALLOW_TYPE=1

Example 11. Set a denylist so that specified sysfs attribute are ignored

/etc/udev/hwdb.d/50-net-naming-denylist.hwdb net:naming:drvirtio_net:* ID_NET_NAME_ALLOW=1 ID_NET_NAME_ALLOW_DEV_PORT=0 ID_NET_NAME_ALLOW_PHYS_PORT_NAME=0

SEE ALSO

udev(7), udevadm(8), Predictable Network Interface Names[1], systemd-nspawn(1)

NOTES

Predictable Network Interface Names

https://systemd.io/PREDICTABLE_INTERFACE_NAMES

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

63 - Linux cli command systemd.special

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command systemd.special and provides detailed information about the command systemd.special, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the systemd.special.

NAME 🖥️ systemd.special 🖥️

Special systemd units

SYNOPSIS

basic.target, bluetooth.target, cryptsetup-pre.target, cryptsetup.target, veritysetup-pre.target, veritysetup.target, ctrl-alt-del.target, [email protected], boot-complete.target, default.target, emergency.target, exit.target, factory-reset.target, final.target, first-boot-complete.target, getty.target, getty-pre.target, graphical.target, halt.target, hibernate.target, hybrid-sleep.target, suspend-then-hibernate.target, initrd.target, initrd-fs.target, initrd-root-device.target, initrd-root-fs.target, initrd-usr-fs.target, integritysetup-pre.target, integritysetup.target, kbrequest.target, kexec.target, local-fs-pre.target, local-fs.target, machines.target multi-user.target, network-online.target, network-pre.target, network.target, nss-lookup.target, nss-user-lookup.target, paths.target, poweroff.target, printer.target, reboot.target, remote-cryptsetup.target, remote-veritysetup.target, remote-fs-pre.target, remote-fs.target, rescue.target, rpcbind.target, runlevel2.target, runlevel3.target, runlevel4.target, runlevel5.target, shutdown.target, sigpwr.target, sleep.target, slices.target, smartcard.target, sockets.target, soft-reboot.target, sound.target, ssh-access.target, storage-target-mode.target, suspend.target, swap.target, sysinit.target, system-update.target, system-update-pre.target, time-set.target, time-sync.target, timers.target, tpm2.target, umount.target, usb-gadget.target, -.slice, capsule.slice, machine.slice, system.slice, user.slice, -.mount, dbus.service, dbus.socket, display-manager.service, init.scope, syslog.socket, system-update-cleanup.service

DESCRIPTION

A few units are treated specially by systemd. Many of them have special internal semantics and cannot be renamed, while others simply have a standard meaning and should be present on all systems.

UNITS MANAGED BY THE SYSTEM SERVICE MANAGER

Special System Units

-.mount

The root mount point, i.e. the mount unit for the / path. This unit is unconditionally active, during the entire time the system is up, as this mount point is where the basic userspace is running from.

Added in version 235.

basic.target

A special target unit covering basic boot-up.

systemd automatically adds dependency of the type After= for this target unit to all services (except for those with DefaultDependencies=no).

Usually, this should pull-in all local mount points plus /var/, /tmp/ and /var/tmp/, swap devices, sockets, timers, path units and other basic initialization necessary for general purpose daemons. The mentioned mount points are special cased to allow them to be remote.

This target usually does not pull in any non-target units directly, but rather does so indirectly via other early boot targets. It is instead meant as a synchronization point for late boot services. Refer to bootup(7) for details on the targets involved.

boot-complete.target

This target is intended as generic synchronization point for services that shall determine or act on whether the boot process completed successfully. Order units that are required to succeed for a boot process to be considered successful before this unit, and add a Requires= dependency from the target unit to them. Order units that shall only run when the boot process is considered successful after the target unit and pull in the target from it, also with Requires=. Note that by default this target unit is not part of the initial boot transaction, but is supposed to be pulled in only if required by units that want to run only on successful boots.

See systemd-boot-check-no-failures.service(8) for a service that implements a generic system health check and orders itself before boot-complete.target.

See systemd-bless-boot.service(8) for a service that propagates boot success information to the boot loader, and orders itself after boot-complete.target.

Added in version 240.

ctrl-alt-del.target

systemd starts this target whenever Control+Alt+Del is pressed on the console. Usually, this should be aliased (symlinked) to reboot.target.

cryptsetup.target

A target that pulls in setup services for all encrypted block devices.

veritysetup.target

A target that pulls in setup services for all verity integrity protected block devices.

Added in version 248.

dbus.service

A special unit for the D-Bus bus daemon. As soon as this service is fully started up systemd will connect to it and register its service.

dbus.socket

A special unit for the D-Bus system bus socket. All units with Type=dbus automatically gain a dependency on this unit.

default.target

The default unit systemd starts at bootup. Usually, this should be aliased (symlinked) to multi-user.target or graphical.target. See bootup(7) for more discussion.

The default unit systemd starts at bootup can be overridden with the systemd.unit= kernel command line option, or more conveniently, with the short names like single, rescue, 1, 3, 5, …; see systemd(1).

display-manager.service

The display manager service. Usually, this should be aliased (symlinked) to gdm.service or a similar display manager service.

emergency.target

A special target unit that starts an emergency shell on the main console. This target does not pull in other services or mounts. It is the most minimal version of starting the system in order to acquire an interactive shell; the only processes running are usually just the system manager (PID 1) and the shell process. This unit may be used by specifying emergency on the kernel command line; it is also used when a file system check on a required file system fails and boot-up cannot continue. Compare with rescue.target, which serves a similar purpose, but also starts the most basic services and mounts all file systems.

In many ways booting into emergency.target is similar to the effect of booting with “init=/bin/sh” on the kernel command line, except that emergency mode provides you with the full system and service manager, and allows starting individual units in order to continue the boot process in steps.

Note that depending on how emergency.target is reached, the root file system might be mounted read-only or read-write (no remounting is done specially for this target). For example, the system may boot with root mounted read-only when ro is used on the kernel command line and remain this way for emergency.target, or the system may transition to emergency.target after the system has been partially booted and disks have already been remounted read-write.

exit.target

A special service unit for shutting down the system or user service manager. It is equivalent to poweroff.target on non-container systems, and also works in containers.

systemd will start this unit when it receives the SIGTERM or SIGINT signal when running as user service daemon.

Normally, this (indirectly) pulls in shutdown.target, which in turn should be conflicted by all units that want to be scheduled for shutdown when the service manager starts to exit.

Added in version 186.

factory-reset.target

A special target to trigger a factory reset.

Added in version 250.

final.target

A special target unit that is used during the shutdown logic and may be used to pull in late services after all normal services are already terminated and all mounts unmounted.

getty.target

A special target unit that pulls in statically configured local TTY getty instances.

graphical.target

A special target unit for setting up a graphical login screen. This pulls in multi-user.target.

Units that are needed for graphical logins shall add Wants= dependencies for their unit to this unit (or multi-user.target) during installation. This is best configured via WantedBy=graphical.target in the units [Install] section.

hibernate.target

A special target unit for hibernating the system. This pulls in sleep.target.

hybrid-sleep.target

A special target unit for hibernating and suspending the system at the same time. This pulls in sleep.target.

Added in version 196.

suspend-then-hibernate.target

A special target unit for suspending the system for a period of time, waking it and putting it into hibernate. This pulls in sleep.target.

Added in version 239.

halt.target

A special target unit for shutting down and halting the system. Note that this target is distinct from poweroff.target in that it generally really just halts the system rather than powering it down.

Applications wanting to halt the system should not start this unit directly, but should instead execute systemctl halt (possibly with the –no-block option) or call systemd(1)s org.freedesktop.systemd1.Manager.Halt D-Bus method directly.

init.scope

This scope unit is where the system and service manager (PID 1) itself resides. It is active as long as the system is running.

Added in version 235.

initrd.target

This is the default target in the initrd, similar to default.target in the main system. It is used to mount the real root and transition to it. See bootup(7) for more discussion.

Added in version 245.

initrd-fs.target

systemd-fstab-generator(3) automatically adds dependencies of type Before= to sysroot-usr.mount and all mount points found in /etc/fstab that have the x-initrd.mount mount option set and do not have the noauto mount option set. It is also indirectly ordered after sysroot.mount. Thus, once this target is reached the /sysroot/ hierarchy is fully set up, in preparation for the transition to the host OS.

Added in version 199.

initrd-root-device.target

A special initrd target unit that is reached when the root filesystem device is available, but before it has been mounted. systemd-fstab-generator(3) and systemd-gpt-auto-generator(3) automatically setup the appropriate dependencies to make this happen.

Added in version 230.

initrd-root-fs.target

systemd-fstab-generator(3) automatically adds dependencies of type Before= to the sysroot.mount unit, which is generated from the kernel command lines root= setting (or equivalent).

Added in version 199.

initrd-usr-fs.target

systemd-fstab-generator(3) automatically adds dependencies of type Before= to the sysusr-usr.mount unit, which is generated from the kernel command lines usr= switch. Services may order themselves after this target unit in order to run once the /sysusr/ hierarchy becomes available, on systems that come up initially without a root file system, but with an initialized /usr/ and need to access that before setting up the root file system to ultimately switch to. On systems where usr= is not used this target is ordered after sysroot.mount and thus mostly equivalent to initrd-root-fs.target. In effect on any system once this target is reached the file system backing /usr/ is mounted, though possibly at two different locations, either below the /sysusr/ or the /sysroot/ hierarchies.

Added in version 249.

kbrequest.target

systemd starts this target whenever Alt+ArrowUp is pressed on the console. Note that any user with physical access to the machine will be able to do this, without authentication, so this should be used carefully.

kexec.target

A special target unit for shutting down and rebooting the system via kexec.

Applications wanting to reboot the system should not start this unit directly, but should instead execute systemctl kexec (possibly with the –no-block option) or call systemd-logind(8)s org.freedesktop.login1.Manager.RebootWithFlags() D-Bus method directly.

See systemd-kexec.service(8) for further details of the operation this target pulls in.

local-fs.target

systemd-fstab-generator(3) automatically adds dependencies of type Before= to all mount units that refer to local mount points for this target unit. In addition, it adds dependencies of type Wants= to this target unit for those mounts listed in /etc/fstab that have the auto mount option set.

machines.target

A standard target unit for starting all the containers and other virtual machines. See [email protected] for an example.

Added in version 233.

multi-user.target

A special target unit for setting up a multi-user system (non-graphical). This is pulled in by graphical.target.

Units that are needed for a multi-user system shall add Wants= dependencies for their unit to this unit during installation. This is best configured via WantedBy=multi-user.target in the units [Install] section.

network-online.target

Units that strictly require a configured network connection should pull in network-online.target (via a Wants= type dependency) and order themselves after it. This target unit is intended to pull in a service that delays further execution until the network is sufficiently set up. What precisely this requires is left to the implementation of the network managing service.

Note the distinction between this unit and network.target. This unit is an active unit (i.e. pulled in by the consumer rather than the provider of this functionality) and pulls in a service which possibly adds substantial delays to further execution. In contrast, network.target is a passive unit (i.e. pulled in by the provider of the functionality, rather than the consumer) that usually does not delay execution much. Usually, network.target is part of the boot of most systems, while network-online.target is not, except when at least one unit requires it. Also see Running Services After the Network Is Up[1] for more information.

All mount units for remote network file systems automatically pull in this unit, and order themselves after it. Note that networking daemons that simply provide functionality to other hosts (as opposed to consume functionality of other hosts) generally do not need to pull this in.

systemd automatically adds dependencies of type Wants= and After= for this target unit to all SysV init script service units with an LSB header referring to the “$network” facility.

Note that this unit is only useful during the original system start-up logic. After the system has completed booting up, it will not track the online state of the system anymore. Due to this it cannot be used as a network connection monitor concept, it is purely a one-time system start-up concept.

Added in version 200.

paths.target

A special target unit that sets up all path units (see systemd.path(5) for details) that shall be active after boot.

It is recommended that path units installed by applications get pulled in via Wants= dependencies from this unit. This is best configured via a WantedBy=paths.target in the path units [Install] section.

Added in version 199.

poweroff.target

A special target unit for shutting down and powering off the system.

Applications wanting to power off the system should not start this unit directly, but should instead execute systemctl poweroff (possibly with the –no-block option) or call systemd-logind(8)s org.freedesktop.login1.Manager.PowerOff D-Bus method directly.

runlevel0.target is an alias for this target unit, for compatibility with SysV.

reboot.target

A special target unit for shutting down and rebooting the system.

Applications wanting to reboot the system should not start this unit directly, but should instead execute systemctl reboot (possibly with the –no-block option) or call systemd-logind(8)s org.freedesktop.login1.Manager.Reboot() D-Bus method directly.

See systemd-reboot.service(8) for further details of the operation this target pulls in.

runlevel6.target is an alias for this target unit, for compatibility with SysV.

remote-cryptsetup.target

Similar to cryptsetup.target, but for encrypted devices which are accessed over the network. It is used for crypttab(8) entries marked with _netdev.

Added in version 235.

remote-veritysetup.target

Similar to veritysetup.target, but for verity integrity protected devices which are accessed over the network. It is used for veritytab(8) entries marked with _netdev.

Added in version 248.

remote-fs.target

Similar to local-fs.target, but for remote mount points.

systemd automatically adds dependencies of type After= for this target unit to all SysV init script service units with an LSB header referring to the “$remote_fs” facility.

rescue.target

A special target unit that pulls in the base system (including system mounts) and spawns a rescue shell. Isolate to this target in order to administer the system in single-user mode with all file systems mounted but with no services running, except for the most basic. Compare with emergency.target, which is much more reduced and does not provide the file systems or most basic services. Compare with multi-user.target, this target could be seen as single-user.target.

runlevel1.target is an alias for this target unit, for compatibility with SysV.

Use the “systemd.unit=rescue.target” kernel command line option to boot into this mode. A short alias for this kernel command line option is “1”, for compatibility with SysV.

runlevel2.target, runlevel3.target, runlevel4.target, runlevel5.target

These are targets that are called whenever the SysV compatibility code asks for runlevel 2, 3, 4, 5, respectively. It is a good idea to make this an alias for (i.e. symlink to) graphical.target (for runlevel 5) or multi-user.target (the others).

shutdown.target

A special target unit that terminates the services on system shutdown.

Services that shall be terminated on system shutdown shall add Conflicts= and Before= dependencies to this unit for their service unit, which is implicitly done when DefaultDependencies=yes is set (the default).

sigpwr.target

A special target that is started when systemd receives the SIGPWR process signal, which is normally sent by the kernel or UPS daemons when power fails.

sleep.target

A special target unit that is pulled in by suspend.target, hibernate.target and hybrid-sleep.target and may be used to hook units into the sleep state logic.

slices.target

A special target unit that sets up all slice units (see systemd.slice(5) for details) that shall always be active after boot. By default the generic system.slice slice unit as well as the root slice unit -.slice are pulled in and ordered before this unit (see below).

Adding slice units to slices.target is generally not necessary. Instead, when some unit that uses Slice= is started, the specified slice will be started automatically. Adding WantedBy=slices.target lines to the [Install] section should only be done for units that need to be always active. In that case care needs to be taken to avoid creating a loop through the automatic dependencies on “parent” slices.

Added in version 229.

sockets.target

A special target unit that sets up all socket units (see systemd.socket(5) for details) that shall be active after boot.

Services that can be socket-activated shall add Wants= dependencies to this unit for their socket unit during installation. This is best configured via a WantedBy=sockets.target in the socket units [Install] section.

soft-reboot.target

A special target unit for shutting down and rebooting the userspace of the system (leaving the kernel running).

Applications wanting to reboot the system should not start this unit directly, but should instead execute systemctl soft-reboot (possibly with the –no-block option) or call systemd-logind(8)s org.freedesktop.login1.Manager.RebootWithFlags() D-Bus method directly.

See systemd-soft-reboot.service(8) for further details of the operation this target pulls in.

Added in version 254.

storage-target-mode.target

A special target unit that can be booted into that selects the “Storage Target Mode” for the OS. In this mode all local storage disks are exposed to external systems as block devices. This invokes systemd-storagetm.service(8) which exposes all local disks as NVMe-TCP devices for access over the network. It might as well invoke other services too that make local disks available via other mechanisms.

Added in version 255.

suspend.target

A special target unit for suspending the system. This pulls in sleep.target.

swap.target

Similar to local-fs.target, but for swap partitions and swap files.

sysinit.target

systemd automatically adds dependencies of the types Requires= and After= for this target unit to all services (except for those with DefaultDependencies=no).

This target pulls in the services required for system initialization. System services pulled in by this target should declare DefaultDependencies=no and specify all their dependencies manually, including access to anything more than a read only root filesystem. For details on the dependencies of this target, refer to bootup(7).

syslog.socket

The socket unit syslog implementations should listen on. All userspace log messages will be made available on this socket. For more information about syslog integration, please consult the Syslog Interface[2] document.

system-update.target, system-update-pre.target, system-update-cleanup.service

A special target unit that is used for offline system updates. systemd-system-update-generator(8) will redirect the boot process to this target if /system-update or /etc/system-update exists. For more information see systemd.offline-updates(7).

Updates should happen before the system-update.target is reached, and the services which implement them should cause the machine to reboot. The main units executing the update should order themselves after system-update-pre.target but not pull it in. Services which want to run during system updates only, but before the actual system update is executed should order themselves before this unit and pull it in. As a safety measure, if this does not happen, and /system-update or /etc/system-update still exists after system-update.target is reached, system-update-cleanup.service will remove the symlinks and reboot the machine.

Added in version 186.

timers.target

A special target unit that sets up all timer units (see systemd.timer(5) for details) that shall be active after boot.

It is recommended that timer units installed by applications get pulled in via Wants= dependencies from this unit. This is best configured via WantedBy=timers.target in the timer units [Install] section.

Added in version 199.

umount.target

A special target unit that unmounts all mount and automount points on system shutdown.

Mounts that shall be unmounted on system shutdown shall add Conflicts dependencies to this unit for their mount unit, which is implicitly done when DefaultDependencies=yes is set (the default).

Special System Units for Devices

Some target units are automatically pulled in as devices of certain kinds show up in the system. These may be used to automatically activate various services based on the specific type of the available hardware.

bluetooth.target

This target is started automatically as soon as a Bluetooth controller is plugged in or becomes available at boot.

This may be used to pull in Bluetooth management daemons dynamically when Bluetooth hardware is found.

printer.target

This target is started automatically as soon as a printer is plugged in or becomes available at boot.

This may be used to pull in printer management daemons dynamically when printer hardware is found.

smartcard.target

This target is started automatically as soon as a smartcard controller is plugged in or becomes available at boot.

This may be used to pull in smartcard management daemons dynamically when smartcard hardware is found.

sound.target

This target is started automatically as soon as a sound card is plugged in or becomes available at boot.

This may be used to pull in audio management daemons dynamically when audio hardware is found.

usb-gadget.target

This target is started automatically as soon as a USB Device Controller becomes available at boot.

This may be used to pull in usb gadget dynamically when UDC hardware is found.

Added in version 242.

tpm2.target

This target is started automatically if a TPM2 device is discovered, either by the OS or by the firmware. It acts as synchronization point for services that require TPM2 device access. The target unit is enqueued by systemd-tpm2-generator(8) if it detects that the firmware has discovered a TPM2 device but the OS kernel has not activated a driver for it yet. It is also pulled in whenever systemd-udevd.service(8) discovers a TPM2 device. The target unit is ordered after the /dev/tpmrm0 device node, so that it only becomes active once the TPM2 device is actually accessible. Early boot programs that intend to access the TPM2 device should hence order themselves after this target unit, but not pull it in.

Added in version 256.

Special Passive System Units

A number of special system targets are defined that can be used to properly order boot-up of optional services. These targets are generally not part of the initial boot transaction, unless they are explicitly pulled in by one of the implementing services. Note specifically that these passive target units are generally not pulled in by the consumer of a service, but by the provider of the service. This means: a consuming service should order itself after these targets (as appropriate), but not pull it in. A providing service should order itself before these targets (as appropriate) and pull it in (via a Wants= type dependency).

Note that these passive units cannot be started manually, i.e. “systemctl start time-sync.target” will fail with an error. They can only be pulled in by dependency. This is enforced since they exist for ordering purposes only and thus are not useful as only unit within a transaction.

[email protected]

This template unit is used to order mount units and other consumers of block devices after services that synthesize these block devices. In particular, this is intended to be used with storage services (such as [email protected](5)/ [email protected](5)) that allocate and manage a virtual block device. Storage services are ordered before an instance of [email protected], and the consumer units after it. The ordering is particularly relevant during shutdown, as it ensures that the mount is deactivated first and the service backing the mount later. The [email protected] instance should be pulled in via a Wants= dependency of the storage daemon and thus generally not be part of any transaction unless a storage daemon is used. The instance name for instances of this template unit must be a properly escaped block device node path, e.g. [email protected] for the storage device /dev/mapper/foobar.

Added in version 245.

cryptsetup-pre.target

This passive target unit may be pulled in by services that want to run before any encrypted block device is set up. All encrypted block devices are set up after this target has been reached. Since the shutdown order is implicitly the reverse start-up order between units, this target is particularly useful to ensure that a service is shut down only after all encrypted block devices are fully stopped.

Added in version 215.

veritysetup-pre.target

This passive target unit may be pulled in by services that want to run before any verity integrity protected block device is set up. All verity integrity protected block devices are set up after this target has been reached. Since the shutdown order is implicitly the reverse start-up order between units, this target is particularly useful to ensure that a service is shut down only after all verity integrity protected block devices are fully stopped.

Added in version 248.

first-boot-complete.target

This passive target is intended as a synchronization point for units that need to run once during the first boot. Only after all units ordered before this target have finished, will the machine-id(5) be committed to disk, marking the first boot as completed. If the boot is aborted at any time before that, the next boot will re-run any units with ConditionFirstBoot=yes.

Added in version 247.

getty-pre.target

A special passive target unit. Users of this target are expected to pull it in the boot transaction via a dependency (e.g. Wants=). Order your unit before this unit if you want to make use of the console just before getty is started.

Added in version 235.

local-fs-pre.target

This target unit is automatically ordered before all local mount points marked with auto (see above). It can be used to execute certain units before all local mounts.

network.target

This unit is supposed to indicate when network functionality is available, but it is only very weakly defined what that is supposed to mean. However, the following should apply at minimum:

·

At start-up, any configured synthetic network devices (i.e. not physical ones that require hardware to show up and be probed, but virtual ones like bridge devices and similar which are created programmatically) that do not depend on any underlying hardware should be allocated by the time this target is reached. It is not necessary for these interfaces to also have completed IP level configuration by the time network.target is reached.

·

At shutdown, a unit that is ordered after network.target will be stopped before the network — to whatever level it might be set up by then — is shut down. It is hence useful when writing service files that require network access on shutdown, which should order themselves after this target, but not pull it in. Also see Running Services After the Network Is Up[1] for more information.

It must emphasized that at start-up theres no guarantee that hardware-based devices have shown up by the time this target is reached, or even acquired complete IP configuration. For that purpose use network-online.target as described above.

network-pre.target

This passive target unit may be pulled in by services that want to run before any network is set up, for example for the purpose of setting up a firewall. All network management software orders itself after this target, but does not pull it in. Also see Running Services After the Network Is Up[1] for more information.

Added in version 214.

nss-lookup.target

A target that should be used as synchronization point for all host/network name service lookups. Note that this is independent of UNIX user/group name lookups for which nss-user-lookup.target should be used. All services for which the availability of full host/network name resolution is essential should be ordered after this target, but not pull it in. systemd automatically adds dependencies of type After= for this target unit to all SysV init script service units with an LSB header referring to the “$named” facility.

nss-user-lookup.target

A target that should be used as synchronization point for all regular UNIX user/group name service lookups. Note that this is independent of host/network name lookups for which nss-lookup.target should be used. All services for which the availability of the full user/group database is essential should be ordered after this target, but not pull it in. All services which provide parts of the user/group database should be ordered before this target, and pull it in. Note that this unit is only relevant for regular users and groups — system users and groups are required to be resolvable during earliest boot already, and hence do not need any special ordering against this target.

remote-fs-pre.target

This target unit is automatically ordered before all mount point units (see above) and cryptsetup/veritysetup devices marked with the _netdev. It can be used to run certain units before remote encrypted devices and mounts are established. Note that this unit is generally not part of the initial transaction, unless the unit that wants to be ordered before all remote mounts pulls it in via a Wants= type dependency. If the unit wants to be pulled in by the first remote mount showing up, it should use network-online.target (see above).

rpcbind.target

The portmapper/rpcbind pulls in this target and orders itself before it, to indicate its availability. systemd automatically adds dependencies of type After= for this target unit to all SysV init script service units with an LSB header referring to the “$portmap” facility.

ssh-access.target

Service and socket units that provide remote SSH secure shell access to the local system should pull in this unit and order themselves before this unit. Its supposed to act as a milestone indicating if and when SSH access into the system is available. It should only become active when an SSH port is bound for remote clients (i.e. if SSH is used as a local privilege escalation mechanism, it should not involve this target unit), regardless of the protocol choices, i.e. regardless if IPv4, IPv6 or AF_VSOCK is used.

Added in version 256.

time-set.target

Services responsible for setting the system clock (CLOCK_REALTIME) from a local source (such as a maintained timestamp file or imprecise real-time clock) should pull in this target and order themselves before it. Services where approximate, roughly monotonic time is desired should be ordered after this unit, but not pull it in.

This target does not provide the accuracy guarantees of time-sync.target (see below), however does not depend on remote clock sources to be reachable, i.e. the target is typically not delayed by network problems and similar. Use of this target is recommended for services where approximate clock accuracy and rough monotonicity is desired but activation shall not be delayed for possibly unreliable network communication.

The service manager automatically adds dependencies of type After= for this target unit to all timer units with at least one OnCalendar= directive.

The systemd-timesyncd.service(8) service is a simple daemon that pulls in this target and orders itself before it. Besides implementing the SNTP network protocol it maintains a timestamp file on disk whose modification time is regularly updated. At service start-up the local system clock is set from that modification time, ensuring it increases roughly monotonically.

Note that ordering a unit after time-set.target only has effect if theres actually a service ordered before it that delays it until the clock is adjusted for rough monotonicity. Otherwise, this target might get reached before the clock is adjusted to be roughly monotonic. Enable systemd-timesyncd.service(8), or an alternative NTP implementation to delay the target.

Added in version 242.

time-sync.target

Services indicating completed synchronization of the system clock (CLOCK_REALTIME) to a remote source should pull in this target and order themselves before it. Services where accurate time is essential should be ordered after this unit, but not pull it in.

The service manager automatically adds dependencies of type After= for this target unit to all SysV init script service units with an LSB header referring to the “$time” facility, as well to all timer units with at least one OnCalendar= directive.

This target provides stricter clock accuracy guarantees than time-set.target (see above), but likely requires network communication and thus introduces unpredictable delays. Services that require clock accuracy and where network communication delays are acceptable should use this target. Services that require a less accurate clock, and only approximate and roughly monotonic clock behaviour should use time-set.target instead.

Note that ordering a unit after time-sync.target only has effect if theres actually a service ordered before it that delays it until clock synchronization is reached. Otherwise, this target might get reached before the clock is synchronized to any remote accurate reference clock. When using systemd-timesyncd.service(8), enable systemd-time-wait-sync.service(8) to delay the target; or use an equivalent service for other NTP implementations.

Table 1. Comparison

time-set.targettime-sync.target
"quick" to reach"slow" to reach
typically uses local clock sources, boot process not affected by availability of external resourcestypically uses remote clock sources, inserts dependencies on remote resources into boot process
reliable, because localunreliable, because typically network involved
typically guarantees an approximate and roughly monotonic clock onlytypically guarantees an accurate clock
implemented by systemd-timesyncd.serviceimplemented by systemd-time-wait-sync.service

Special Slice Units

There are four “.slice” units which form the basis of the hierarchy for assignment of resources for services, users, and virtual machines or containers. See systemd.slice(7) for details about slice units.

-.slice

The root slice is the root of the slice hierarchy. It usually does not contain units directly, but may be used to set defaults for the whole tree.

Added in version 206.

machine.slice

By default, all virtual machines and containers registered with systemd-machined are found in this slice. This is pulled in by systemd-machined.service.

Added in version 206.

capsule.slice

By default, all capsules encapsulated in [email protected] are found in this slice.

Added in version 255.

system.slice

By default, all system services started by systemd are found in this slice.

Added in version 206.

user.slice

By default, all user processes and services started on behalf of the user, including the per-user systemd instance are found in this slice. This is pulled in by systemd-logind.service.

Added in version 206.

UNITS MANAGED BY THE USER SERVICE MANAGER

Special User Units

When systemd runs as a user instance, the following special units are available:

default.target

This is the main target of the user service manager, started by default when the service manager is invoked. Various services that compose the normal user session should be pulled into this target. In this regard, default.target is similar to multi-user.target in the system instance, but it is a real unit, not an alias.

Added in version 242.

[email protected]

This is the main target of capsule service managers, started by default, instantiated with the capsule name. This may be used to define different sets of units that are started for different capsules via generic unit definitions. For details about capsules see [email protected](5).

Added in version 255.

In addition, the following units are available which have definitions similar to their system counterparts: exit.target, shutdown.target, sockets.target, timers.target, paths.target, bluetooth.target, printer.target, smartcard.target, sound.target.

Special Passive User Units

graphical-session.target

This target is active whenever any graphical session is running. It is used to stop user services which only apply to a graphical (X, Wayland, etc.) session when the session is terminated. Such services should have “PartOf=graphical-session.target” in their [Unit] section. A target for a particular session (e. g. gnome-session.target) starts and stops “graphical-session.target” with “BindsTo=graphical-session.target”.

Which services are started by a session target is determined by the “Wants=” and “Requires=” dependencies. For services that can be enabled independently, symlinks in “.wants/” and “.requires/” should be used, see systemd.unit(5). Those symlinks should either be shipped in packages, or should be added dynamically after installation, for example using “systemctl add-wants”, see systemctl(1).

Example 1. Nautilus as part of a GNOME session “gnome-session.target” pulls in Nautilus as top-level service:

[Unit] Description=User systemd services for GNOME graphical session Wants=nautilus.service BindsTo=graphical-session.target

“nautilus.service” gets stopped when the session stops:

[Unit] Description=Render the desktop icons with Nautilus PartOf=graphical-session.target

[Service]
...

Added in version 234.

graphical-session-pre.target

This target contains services which set up the environment or global configuration of a graphical session, such as SSH/GPG agents (which need to export an environment variable into all desktop processes) or migration of obsolete d-conf keys after an OS upgrade (which needs to happen before starting any process that might use them). This target must be started before starting a graphical session like gnome-session.target.

Added in version 234.

xdg-desktop-autostart.target

The XDG specification defines a way to autostart applications using XDG desktop files. systemd ships systemd-xdg-autostart-generator(8) for the XDG desktop files in autostart directories. Desktop Environments can opt-in to use this service by adding a Wants= dependency on xdg-desktop-autostart.target.

Added in version 246.

Special User Slice Units

There are four “.slice” units which form the basis of the user hierarchy for assignment of resources for user applications and services. See systemd.slice(7) for details about slice units and the documentation about Desktop Environments[3] for further information.

-.slice

The root slice is the root of the users slice hierarchy. It usually does not contain units directly, but may be used to set defaults for the whole tree.

Added in version 247.

app.slice

By default, all user services and applications managed by systemd are found in this slice. All interactively launched applications like web browsers and text editors as well as non-critical services should be placed into this slice.

Added in version 247.

session.slice

All essential services and applications required for the session should use this slice. These are services that either cannot be restarted easily or where latency issues may affect the interactivity of the system and applications. This includes the display server, screen readers and other services such as DBus or XDG portals. Such services should be configured to be part of this slice by adding Slice=session.slice to their unit files.

Added in version 247.

background.slice

All services running low-priority background tasks should use this slice. This permits resources to be preferentially assigned to the other slices. Examples include non-interactive tasks like file indexing or backup operations where latency is not important.

Added in version 247.

SEE ALSO

systemd(1), systemd.unit(5), systemd.service(5), systemd.socket(5), systemd.target(5), systemd.slice(5), bootup(7), systemd-fstab-generator(8), [email protected](5)

NOTES

Running Services After the Network Is Up

https://systemd.io/NETWORK_ONLINE

Syslog Interface

https://systemd.io/SYSLOG

Desktop Environments

https://systemd.io/DESKTOP_ENVIRONMENTS

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

64 - Linux cli command SET_SESSION_AUTHORIZATION

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command SET_SESSION_AUTHORIZATION and provides detailed information about the command SET_SESSION_AUTHORIZATION, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the SET_SESSION_AUTHORIZATION.

NAME 🖥️ SET_SESSION_AUTHORIZATION 🖥️

set the session user identifier and the current user identifier of the current session

SYNOPSIS

SET [ SESSION | LOCAL ] SESSION AUTHORIZATION user_name
SET [ SESSION | LOCAL ] SESSION AUTHORIZATION DEFAULT
RESET SESSION AUTHORIZATION

DESCRIPTION

This command sets the session user identifier and the current user identifier of the current SQL session to be user_name. The user name can be written as either an identifier or a string literal. Using this command, it is possible, for example, to temporarily become an unprivileged user and later switch back to being a superuser.

The session user identifier is initially set to be the (possibly authenticated) user name provided by the client. The current user identifier is normally equal to the session user identifier, but might change temporarily in the context of SECURITY DEFINER functions and similar mechanisms; it can also be changed by SET ROLE. The current user identifier is relevant for permission checking.

The session user identifier can be changed only if the initial session user (the authenticated user) had the superuser privilege. Otherwise, the command is accepted only if it specifies the authenticated user name.

The SESSION and LOCAL modifiers act the same as for the regular SET command.

The DEFAULT and RESET forms reset the session and current user identifiers to be the originally authenticated user name. These forms can be executed by any user.

NOTES

SET SESSION AUTHORIZATION cannot be used within a SECURITY DEFINER function.

EXAMPLES

SELECT SESSION_USER, CURRENT_USER;

 session_user | current_user
--------------+--------------
 peter        | peter

SET SESSION AUTHORIZATION paul;

SELECT SESSION_USER, CURRENT_USER;

 session_user | current_user
--------------+--------------
 paul         | paul

COMPATIBILITY

The SQL standard allows some other expressions to appear in place of the literal user_name, but these options are not important in practice. PostgreSQL allows identifier syntax ("username"), which SQL does not. SQL does not allow this command during a transaction; PostgreSQL does not make this restriction because there is no reason to. The SESSION and LOCAL modifiers are a PostgreSQL extension, as is the RESET syntax.

The privileges necessary to execute this command are left implementation-defined by the standard.

SEE ALSO

SET ROLE (SET_ROLE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

65 - Linux cli command libc

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command libc and provides detailed information about the command libc, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the libc.

NAME 🖥️ libc 🖥️

overview of standard C libraries on Linux

DESCRIPTION

The term “libc” is commonly used as a shorthand for the “standard C library” a library of standard functions that can be used by all C programs (and sometimes by programs in other languages). Because of some history (see below), use of the term “libc” to refer to the standard C library is somewhat ambiguous on Linux.

glibc

By far the most widely used C library on Linux is the GNU C Library, often referred to as glibc. This is the C library that is nowadays used in all major Linux distributions. It is also the C library whose details are documented in the relevant pages of the man-pages project (primarily in Section 3 of the manual). Documentation of glibc is also available in the glibc manual, available via the command info libc. Release 1.0 of glibc was made in September 1992. (There were earlier 0.x releases.) The next major release of glibc was 2.0, at the beginning of 1997.

The pathname /lib/libc.so.6 (or something similar) is normally a symbolic link that points to the location of the glibc library, and executing this pathname will cause glibc to display various information about the version installed on your system.

Linux libc

In the early to mid 1990s, there was for a while Linux libc, a fork of glibc 1.x created by Linux developers who felt that glibc development at the time was not sufficing for the needs of Linux. Often, this library was referred to (ambiguously) as just “libc”. Linux libc released major versions 2, 3, 4, and 5, as well as many minor versions of those releases. Linux libc4 was the last version to use the a.out binary format, and the first version to provide (primitive) shared library support. Linux libc 5 was the first version to support the ELF binary format; this version used the shared library soname libc.so.5. For a while, Linux libc was the standard C library in many Linux distributions.

However, notwithstanding the original motivations of the Linux libc effort, by the time glibc 2.0 was released (in 1997), it was clearly superior to Linux libc, and all major Linux distributions that had been using Linux libc soon switched back to glibc. To avoid any confusion with Linux libc versions, glibc 2.0 and later used the shared library soname libc.so.6.

Since the switch from Linux libc to glibc 2.0 occurred long ago, man-pages no longer takes care to document Linux libc details. Nevertheless, the history is visible in vestiges of information about Linux libc that remain in a few manual pages, in particular, references to libc4 and libc5.

Other C libraries

There are various other less widely used C libraries for Linux. These libraries are generally smaller than glibc, both in terms of features and memory footprint, and often intended for building small binaries, perhaps targeted at development for embedded Linux systems. Among such libraries are

uClibc

dietlibc

and

musl libc

Details of these libraries are covered by the man-pages project, where they are known.

SEE ALSO

syscalls(2), getauxval(3), proc(5), feature_test_macros(7), man-pages(7), standards(7), vdso(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

66 - Linux cli command DROP_TYPE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_TYPE and provides detailed information about the command DROP_TYPE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_TYPE.

NAME 🖥️ DROP_TYPE 🖥️

remove a data type

SYNOPSIS

DROP TYPE [ IF EXISTS ] name [, ...] [ CASCADE | RESTRICT ]

DESCRIPTION

DROP TYPE removes a user-defined data type. Only the owner of a type can remove it.

PARAMETERS

IF EXISTS

Do not throw an error if the type does not exist. A notice is issued in this case.

name

The name (optionally schema-qualified) of the data type to remove.

CASCADE

Automatically drop objects that depend on the type (such as table columns, functions, and operators), and in turn all objects that depend on those objects (see Section 5.14).

RESTRICT

Refuse to drop the type if any objects depend on it. This is the default.

EXAMPLES

To remove the data type box:

DROP TYPE box;

COMPATIBILITY

This command is similar to the corresponding command in the SQL standard, apart from the IF EXISTS option, which is a PostgreSQL extension. But note that much of the CREATE TYPE command and the data type extension mechanisms in PostgreSQL differ from the SQL standard.

SEE ALSO

ALTER TYPE (ALTER_TYPE(7)), CREATE TYPE (CREATE_TYPE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

67 - Linux cli command iso_8859-2

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso_8859-2 and provides detailed information about the command iso_8859-2, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso_8859-2.

NAME 🖥️ iso_8859-2 🖥️

2 - ISO/IEC 8859-2 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-2 encodes the Latin characters used in many Central and East European languages.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-2 characters

The following table displays the characters in ISO/IEC 8859-2 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-2 is also known as Latin-2.

SEE ALSO

ascii(7), charsets(7), iso_8859-1(7), iso_8859-16(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

68 - Linux cli command EVP_KEYEXCH-ECDHssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KEYEXCH-ECDHssl and provides detailed information about the command EVP_KEYEXCH-ECDHssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KEYEXCH-ECDHssl.

NAME 🖥️ EVP_KEYEXCH-ECDHssl 🖥️

ECDH - ECDH Key Exchange algorithm support

DESCRIPTION

Key exchange support for the ECDH key type.

ECDH Key Exchange parameters

“ecdh-cofactor-mode” (OSSL_EXCHANGE_PARAM_EC_ECDH_COFACTOR_MODE) <integer>
Sets or gets the ECDH mode of operation for the associated key exchange ctx. In the context of an Elliptic Curve Diffie-Hellman key exchange, this parameter can be used to select between the plain Diffie-Hellman (DH) or Cofactor Diffie-Hellman (CDH) variants of the key exchange algorithm. When setting, the value should be 1, 0 or -1, respectively forcing cofactor mode on, off, or resetting it to the default for the private key associated with the given key exchange ctx. When getting, the value should be either 1 or 0, respectively signaling if the cofactor mode is on or off. See also provider-keymgmt (7) for the related OSSL_PKEY_PARAM_USE_COFACTOR_ECDH parameter that can be set on a per-key basis.

“kdf-type” (OSSL_EXCHANGE_PARAM_KDF_TYPE) <UTF8 string>
See “Common Key Exchange parameters” in provider-keyexch (7).

“kdf-digest” (OSSL_EXCHANGE_PARAM_KDF_DIGEST) <UTF8 string>
See “Common Key Exchange parameters” in provider-keyexch (7).

“kdf-digest-props” (OSSL_EXCHANGE_PARAM_KDF_DIGEST_PROPS) <UTF8 string>
See “Common Key Exchange parameters” in provider-keyexch (7).

“kdf-outlen” (OSSL_EXCHANGE_PARAM_KDF_OUTLEN) <unsigned integer>
See “Common Key Exchange parameters” in provider-keyexch (7).

“kdf-ukm” (OSSL_EXCHANGE_PARAM_KDF_UKM) <octet string>
See “Common Key Exchange parameters” in provider-keyexch (7).

EXAMPLES

Keys for the host and peer must be generated as shown in “Examples” in EVP_PKEY-EC (7) using the same curve name.

The code to generate a shared secret for the normal case is identical to “Examples” in EVP_KEYEXCH-DH (7).

To derive a shared secret on the host using the host’s key and the peer’s public key but also using X963KDF with a user key material:

/* It is assumed that the host_key, peer_pub_key and ukm are set up */ void derive_secret(EVP_PKEY *host_key, EVP_PKEY *peer_key, unsigned char *ukm, size_t ukm_len) { unsigned char secret[64]; size_t out_len = sizeof(secret); size_t secret_len = out_len; unsigned int pad = 1; OSSL_PARAM params[6]; EVP_PKEY_CTX *dctx = EVP_PKEY_CTX_new_from_pkey(NULL, host_key, NULL); EVP_PKEY_derive_init(dctx); params[0] = OSSL_PARAM_construct_uint(OSSL_EXCHANGE_PARAM_PAD, &pad); params[1] = OSSL_PARAM_construct_utf8_string(OSSL_EXCHANGE_PARAM_KDF_TYPE, “X963KDF”, 0); params[2] = OSSL_PARAM_construct_utf8_string(OSSL_EXCHANGE_PARAM_KDF_DIGEST, “SHA1”, 0); params[3] = OSSL_PARAM_construct_size_t(OSSL_EXCHANGE_PARAM_KDF_OUTLEN, &out_len); params[4] = OSSL_PARAM_construct_octet_string(OSSL_EXCHANGE_PARAM_KDF_UKM, ukm, ukm_len); params[5] = OSSL_PARAM_construct_end(); EVP_PKEY_CTX_set_params(dctx, params); EVP_PKEY_derive_set_peer(dctx, peer_pub_key); EVP_PKEY_derive(dctx, secret, &secret_len); … OPENSSL_clear_free(secret, secret_len); EVP_PKEY_CTX_free(dctx); }

SEE ALSO

EVP_PKEY-EC (7) EVP_PKEY (3), provider-keyexch (7), provider-keymgmt (7), OSSL_PROVIDER-default (7), OSSL_PROVIDER-FIPS (7),

COPYRIGHT

Copyright 2020-2022 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

69 - Linux cli command rtnetlink

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command rtnetlink and provides detailed information about the command rtnetlink, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the rtnetlink.

NAME 🖥️ rtnetlink 🖥️

Linux routing socket

SYNOPSIS

#include <asm/types.h>
#include <linux/if_link.h>
#include <linux/netlink.h>
#include <linux/rtnetlink.h>
#include <sys/socket.h>
rtnetlink_socket = socket(AF_NETLINK, int socket_type, NETLINK_ROUTE);

DESCRIPTION

Rtnetlink allows the kernel’s routing tables to be read and altered. It is used within the kernel to communicate between various subsystems, though this usage is not documented here, and for communication with user-space programs. Network routes, IP addresses, link parameters, neighbor setups, queueing disciplines, traffic classes and packet classifiers may all be controlled through NETLINK_ROUTE sockets. It is based on netlink messages; see netlink(7) for more information.

Routing attributes

Some rtnetlink messages have optional attributes after the initial header:

struct rtattr {
    unsigned short rta_len;    /* Length of option */
    unsigned short rta_type;   /* Type of option */
    /* Data follows */
};

These attributes should be manipulated using only the RTA_* macros or libnetlink, see rtnetlink(3).

Messages

Rtnetlink consists of these message types (in addition to standard netlink messages):

RTM_NEWLINK
RTM_DELLINK
RTM_GETLINK
Create, remove, or get information about a specific network interface. These messages contain an ifinfomsg structure followed by a series of rtattr structures.

struct ifinfomsg {
    unsigned char  ifi_family; /* AF_UNSPEC */
    unsigned short ifi_type;   /* Device type */
    int            ifi_index;  /* Interface index */
    unsigned int   ifi_flags;  /* Device flags  */
    unsigned int   ifi_change; /* change mask */
};

ifi_flags contains the device flags, see netdevice(7); ifi_index is the unique interface index (since Linux 3.7, it is possible to feed a nonzero value with the RTM_NEWLINK message, thus creating a link with the given ifindex); ifi_change is reserved for future use and should be always set to 0xFFFFFFFF.

TABLE

The value type for IFLA_STATS is struct rtnl_link_stats (struct net_device_stats in Linux 2.4 and earlier).

RTM_NEWADDR
RTM_DELADDR
RTM_GETADDR
Add, remove, or receive information about an IP address associated with an interface. In Linux 2.2, an interface can carry multiple IP addresses, this replaces the alias device concept in Linux 2.0. In Linux 2.2, these messages support IPv4 and IPv6 addresses. They contain an ifaddrmsg structure, optionally followed by rtattr routing attributes.

struct ifaddrmsg {
    unsigned char ifa_family;    /* Address type */
    unsigned char ifa_prefixlen; /* Prefixlength of address */
    unsigned char ifa_flags;     /* Address flags */
    unsigned char ifa_scope;     /* Address scope */
    unsigned int  ifa_index;     /* Interface index */
};

ifa_family is the address family type (currently AF_INET or AF_INET6), ifa_prefixlen is the length of the address mask of the address if defined for the family (like for IPv4), ifa_scope is the address scope, ifa_index is the interface index of the interface the address is associated with. ifa_flags is a flag word of IFA_F_SECONDARY for secondary address (old alias interface), IFA_F_PERMANENT for a permanent address set by the user and other undocumented flags.

TABLE

RTM_NEWROUTE
RTM_DELROUTE
RTM_GETROUTE
Create, remove, or receive information about a network route. These messages contain an rtmsg structure with an optional sequence of rtattr structures following. For RTM_GETROUTE, setting rtm_dst_len and rtm_src_len to 0 means you get all entries for the specified routing table. For the other fields, except rtm_table and rtm_protocol, 0 is the wildcard.

struct rtmsg {
    unsigned char rtm_family;   /* Address family of route */
    unsigned char rtm_dst_len;  /* Length of destination */
    unsigned char rtm_src_len;  /* Length of source */
    unsigned char rtm_tos;      /* TOS filter */
    unsigned char rtm_table;    /* Routing table ID;
                                   see RTA_TABLE below */
    unsigned char rtm_protocol; /* Routing protocol; see below */
    unsigned char rtm_scope;    /* See below */
    unsigned char rtm_type;     /* See below */
    unsigned int  rtm_flags;
};
rtm_typeRoute type
RTN_UNSPECunknown route
RTN_UNICASTa gateway or direct route
RTN_LOCALa local interface route
RTN_BROADCASTa local broadcast route (sent as a broadcast)
RTN_ANYCASTa local broadcast route (sent as a unicast)
RTN_MULTICASTa multicast route
RTN_BLACKHOLEa packet dropping route
RTN_UNREACHABLEan unreachable destination
RTN_PROHIBITa packet rejection route
RTN_THROWcontinue routing lookup in another table
RTN_NATa network address translation rule
RTN_XRESOLVErefer to an external resolver (not implemented)
rtm_protocolRoute origin
RTPROT_UNSPECunknown
RTPROT_REDIRECTby an ICMP redirect (currently unused)
RTPROT_KERNELby the kernel
RTPROT_BOOTduring boot
RTPROT_STATICby the administrator

Values larger than RTPROT_STATIC are not interpreted by the kernel, they are just for user information. They may be used to tag the source of a routing information or to distinguish between multiple routing daemons. See <linux/rtnetlink.h> for the routing daemon identifiers which are already assigned.

rtm_scope is the distance to the destination:

RT_SCOPE_UNIVERSEglobal route
RT_SCOPE_SITEinterior route in the local autonomous system
RT_SCOPE_LINKroute on this link
RT_SCOPE_HOSTroute on the local host
RT_SCOPE_NOWHEREdestination doesn't exist

The values between RT_SCOPE_UNIVERSE and RT_SCOPE_SITE are available to the user.

The rtm_flags have the following meanings:

RTM_F_NOTIFYif the route changes, notify the user via rtnetlink
RTM_F_CLONEDroute is cloned from another route
RTM_F_EQUALIZEa multipath equalizer (not yet implemented)

rtm_table specifies the routing table

RT_TABLE_UNSPECan unspecified routing table
RT_TABLE_DEFAULTthe default table
RT_TABLE_MAINthe main table
RT_TABLE_LOCALthe local table

The user may assign arbitrary values between RT_TABLE_UNSPEC and RT_TABLE_DEFAULT.

TABLE

RTA_MULTIPATH contains several packed instances of struct rtnexthop together with nested RTAs (RTA_GATEWAY):

struct rtnexthop {
    unsigned short rtnh_len;     /* Length of struct + length
                                    of RTAs */
    unsigned char  rtnh_flags;   /* Flags (see
                                    linux/rtnetlink.h) */
    unsigned char  rtnh_hops;    /* Nexthop priority */
    int            rtnh_ifindex; /* Interface index for this
                                    nexthop */
}

There exist a bunch of RTNH_* macros similar to RTA_* and NLHDR_* macros useful to handle these structures.

struct rtvia {
    unsigned short rtvia_family;
    unsigned char  rtvia_addr[0];
};

rtvia_addr is the address, rtvia_family is its family type.

RTA_PREF may contain values ICMPV6_ROUTER_PREF_LOW, ICMPV6_ROUTER_PREF_MEDIUM, and ICMPV6_ROUTER_PREF_HIGH defined incw <linux/icmpv6.h>.

RTA_ENCAP_TYPE may contain values LWTUNNEL_ENCAP_MPLS, LWTUNNEL_ENCAP_IP, LWTUNNEL_ENCAP_ILA, or LWTUNNEL_ENCAP_IP6 defined in <linux/lwtunnel.h>.

Fill these values in!

RTM_NEWNEIGH
RTM_DELNEIGH
RTM_GETNEIGH
Add, remove, or receive information about a neighbor table entry (e.g., an ARP entry). The message contains an ndmsg structure.

struct ndmsg {
    unsigned char ndm_family;
    int           ndm_ifindex;  /* Interface index */
    __u16         ndm_state;    /* State */
    __u8          ndm_flags;    /* Flags */
    __u8          ndm_type;
};
struct nda_cacheinfo {
    __u32         ndm_confirmed;
    __u32         ndm_used;
    __u32         ndm_updated;
    __u32         ndm_refcnt;
};

ndm_state is a bit mask of the following states:

NUD_INCOMPLETEa currently resolving cache entry
NUD_REACHABLEa confirmed working cache entry
NUD_STALEan expired cache entry
NUD_DELAYan entry waiting for a timer
NUD_PROBEa cache entry that is currently reprobed
NUD_FAILEDan invalid cache entry
NUD_NOARPa device with no destination cache
NUD_PERMANENTa static entry

Valid ndm_flags are:

NTF_PROXYa proxy arp entry
NTF_ROUTERan IPv6 router

The rtattr struct has the following meanings for the rta_type field:

NDA_UNSPECunknown type
NDA_DSTa neighbor cache n/w layer destination address
NDA_LLADDRa neighbor cache link layer address
NDA_CACHEINFOcache statistics

If the rta_type field is NDA_CACHEINFO, then a struct nda_cacheinfo header follows.

RTM_NEWRULE
RTM_DELRULE
RTM_GETRULE
Add, delete, or retrieve a routing rule. Carries a struct rtmsg

RTM_NEWQDISC
RTM_DELQDISC
RTM_GETQDISC
Add, remove, or get a queueing discipline. The message contains a struct tcmsg and may be followed by a series of attributes.

struct tcmsg {
    unsigned char    tcm_family;
    int              tcm_ifindex;   /* interface index */
    __u32            tcm_handle;    /* Qdisc handle */
    __u32            tcm_parent;    /* Parent qdisc */
    __u32            tcm_info;
};

TABLE

In addition, various other qdisc-module-specific attributes are allowed. For more information see the appropriate include files.

RTM_NEWTCLASS
RTM_DELTCLASS
RTM_GETTCLASS
Add, remove, or get a traffic class. These messages contain a struct tcmsg as described above.

RTM_NEWTFILTER
RTM_DELTFILTER
RTM_GETTFILTER
Add, remove, or receive information about a traffic filter. These messages contain a struct tcmsg as described above.

VERSIONS

rtnetlink is a new feature of Linux 2.2.

BUGS

This manual page is incomplete.

SEE ALSO

cmsg(3), rtnetlink(3), ip(7), netlink(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

70 - Linux cli command EVP_KEYMGMT-DHssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KEYMGMT-DHssl and provides detailed information about the command EVP_KEYMGMT-DHssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KEYMGMT-DHssl.

NAME 🖥️ EVP_KEYMGMT-DHssl 🖥️

DH, EVP_PKEY-DHX, EVP_KEYMGMT-DH, EVP_KEYMGMT-DHX - EVP_PKEY DH and DHX keytype and algorithm support

DESCRIPTION

For DH FFC key agreement, two classes of domain parameters can be used: “safe” domain parameters that are associated with approved named safe-prime groups, and a class of “FIPS186-type” domain parameters. FIPS186-type domain parameters should only be used for backward compatibility with existing applications that cannot be upgraded to use the approved safe-prime groups.

See EVP_PKEY-FFC (7) for more information about FFC keys.

The DH key type uses PKCS#3 format which saves p and g, but not the q value. The DHX key type uses X9.42 format which saves the value of q and this must be used for FIPS186-4. If key validation is required, users should be aware of the nuances associated with FIPS186-4 style parameters as discussed in “DH key validation”.

DH and DHX domain parameters

In addition to the common FCC parameters that all FFC keytypes should support (see “FFC parameters” in EVP_PKEY-FFC (7)) the DHX and DH keytype implementations support the following:

“group” (OSSL_PKEY_PARAM_GROUP_NAME) <UTF8 string>
Sets or gets a string that associates a DH or DHX named safe prime group with known values for p, q and g. The following values can be used by the OpenSSL’s default and FIPS providers: “ffdhe2048”, “ffdhe3072”, “ffdhe4096”, “ffdhe6144”, “ffdhe8192”, “modp_2048”, “modp_3072”, “modp_4096”, “modp_6144”, “modp_8192”. The following additional values can also be used by OpenSSL’s default provider: “modp_1536”, “dh_1024_160”, “dh_2048_224”, “dh_2048_256”. DH/DHX named groups can be easily validated since the parameters are well known. For protocols that only transfer p and g the value of q can also be retrieved.

DH and DHX additional parameters

“encoded-pub-key” (OSSL_PKEY_PARAM_ENCODED_PUBLIC_KEY) <octet string>
Used for getting and setting the encoding of the DH public key used in a key exchange message for the TLS protocol. See EVP_PKEY_set1_encoded_public_key() and EVP_PKEY_get1_encoded_public_key().

DH additional domain parameters

“safeprime-generator” (OSSL_PKEY_PARAM_DH_GENERATOR) <integer>
Used for DH generation of safe primes using the old safe prime generator code. The default value is 2. It is recommended to use a named safe prime group instead, if domain parameter validation is required. Randomly generated safe primes are not allowed by FIPS, so setting this value for the OpenSSL FIPS provider will instead choose a named safe prime group based on the size of p.

DH and DHX domain parameter / key generation parameters

In addition to the common FFC key generation parameters that all FFC key types should support (see “FFC key generation parameters” in EVP_PKEY-FFC (7)) the DH and DHX keytype implementation supports the following:

“type” (OSSL_PKEY_PARAM_FFC_TYPE) <UTF8 string>
Sets the type of parameter generation. For DH valid values are:

“fips186_4”

“default”

“fips186_2”

These are described in “FFC key generation parameters” in EVP_PKEY-FFC (7)

“group”
This specifies that a named safe prime name will be chosen using the “pbits” type.

“generator”
A safe prime generator. See the “safeprime-generator” type above. This is only valid for DH keys.

“pbits” (OSSL_PKEY_PARAM_FFC_PBITS) <unsigned integer>
Sets the size (in bits) of the prime ‘p’. For “fips186_4” this must be 2048. For “fips186_2” this must be 1024. For “group” this can be any one of 2048, 3072, 4096, 6144 or 8192.

“priv_len” (OSSL_PKEY_PARAM_DH_PRIV_LEN) <integer>
An optional value to set the maximum length of the generated private key. The default value used if this is not set is the maximum value of BN_num_bits(q)). The minimum value that this can be set to is 2 * s. Where s is the security strength of the key which has values of 112, 128, 152, 176 and 200 for key sizes of 2048, 3072, 4096, 6144 and 8192.

DH key validation

For DHX that is not a named group the FIPS186-4 standard specifies that the values used for FFC parameter generation are also required for parameter validation. This means that optional FFC domain parameter values for seed, pcounter and gindex or hindex may need to be stored for validation purposes. For DHX the seed and pcounter can be stored in ASN1 data (but the gindex or hindex cannot be stored). It is recommended to use a named safe prime group instead.

For DH keys, EVP_PKEY_param_check (3) behaves in the following way: The OpenSSL FIPS provider tests if the parameters are either an approved safe prime group OR that the FFC parameters conform to FIPS186-4 as defined in SP800-56Ar3 Assurances of Domain-Parameter Validity. The OpenSSL default provider uses simpler checks that allows there to be no q value for backwards compatibility.

For DH keys, EVP_PKEY_param_check_quick (3) is equivalent to EVP_PKEY_param_check (3).

For DH keys, EVP_PKEY_public_check (3) conforms to SP800-56Ar3 FFC Full Public-Key Validation.

For DH keys, EVP_PKEY_public_check_quick (3) conforms to SP800-56Ar3 FFC Partial Public-Key Validation when the DH key is an approved named safe prime group, otherwise it is the same as EVP_PKEY_public_check (3).

For DH Keys, EVP_PKEY_private_check (3) tests that the private key is in the correct range according to SP800-56Ar3. The OpenSSL FIPS provider requires the value of q to be set (note that this is set for named safe prime groups). For backwards compatibility the OpenSSL default provider only requires p to be set.

For DH keys, EVP_PKEY_pairwise_check (3) conforms to SP800-56Ar3 Owner Assurance of Pair-wise Consistency.

EXAMPLES

An EVP_PKEY context can be obtained by calling:

EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “DH”, NULL);

A DH key can be generated with a named safe prime group by calling:

int priv_len = 2 * 112; OSSL_PARAM params[3]; EVP_PKEY *pkey = NULL; EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “DH”, NULL); params[0] = OSSL_PARAM_construct_utf8_string(“group”, “ffdhe2048”, 0); /* “priv_len” is optional */ params[1] = OSSL_PARAM_construct_int(“priv_len”, &priv_len); params[2] = OSSL_PARAM_construct_end(); EVP_PKEY_keygen_init(pctx); EVP_PKEY_CTX_set_params(pctx, params); EVP_PKEY_generate(pctx, &pkey); … EVP_PKEY_free(pkey); EVP_PKEY_CTX_free(pctx);

DHX domain parameters can be generated according to FIPS186-4 by calling:

int gindex = 2; unsigned int pbits = 2048; unsigned int qbits = 256; OSSL_PARAM params[6]; EVP_PKEY *param_key = NULL; EVP_PKEY_CTX *pctx = NULL; pctx = EVP_PKEY_CTX_new_from_name(NULL, “DHX”, NULL); EVP_PKEY_paramgen_init(pctx); params[0] = OSSL_PARAM_construct_uint(“pbits”, &pbits); params[1] = OSSL_PARAM_construct_uint(“qbits”, &qbits); params[2] = OSSL_PARAM_construct_int(“gindex”, &gindex); params[3] = OSSL_PARAM_construct_utf8_string(“type”, “fips186_4”, 0); params[4] = OSSL_PARAM_construct_utf8_string(“digest”, “SHA256”, 0); params[5] = OSSL_PARAM_construct_end(); EVP_PKEY_CTX_set_params(pctx, params); EVP_PKEY_generate(pctx, &param_key); EVP_PKEY_print_params(bio_out, param_key, 0, NULL); … EVP_PKEY_free(param_key); EVP_PKEY_CTX_free(pctx);

A DH key can be generated using domain parameters by calling:

EVP_PKEY *key = NULL; EVP_PKEY_CTX *gctx = EVP_PKEY_CTX_new_from_pkey(NULL, param_key, NULL); EVP_PKEY_keygen_init(gctx); EVP_PKEY_generate(gctx, &key); EVP_PKEY_print_private(bio_out, key, 0, NULL); … EVP_PKEY_free(key); EVP_PKEY_CTX_free(gctx);

To validate FIPS186-4 DHX domain parameters decoded from PEM or DER data, additional values used during generation may be required to be set into the key.

EVP_PKEY_todata(), OSSL_PARAM_merge(), and EVP_PKEY_fromdata() are useful to add these parameters to the original key or domain parameters before the actual validation. In production code the return values should be checked.

EVP_PKEY *received_domp = …; /* parameters received and decoded */ unsigned char *seed = …; /* and additional parameters received */ size_t seedlen = …; /* by other means, required */ int gindex = …; /* for the validation */ int pcounter = …; int hindex = …; OSSL_PARAM extra_params[4]; OSSL_PARAM *domain_params = NULL; OSSL_PARAM *merged_params = NULL; EVP_PKEY_CTX *ctx = NULL, *validate_ctx = NULL; EVP_PKEY *complete_domp = NULL; EVP_PKEY_todata(received_domp, OSSL_KEYMGMT_SELECT_DOMAIN_PARAMETERS, &domain_params); extra_params[0] = OSSL_PARAM_construct_octet_string(“seed”, seed, seedlen); /* * NOTE: For unverifiable g use “hindex” instead of “gindex” * extra_params[1] = OSSL_PARAM_construct_int(“hindex”, &hindex); */ extra_params[1] = OSSL_PARAM_construct_int(“gindex”, &gindex); extra_params[2] = OSSL_PARAM_construct_int(“pcounter”, &pcounter); extra_params[3] = OSSL_PARAM_construct_end(); merged_params = OSSL_PARAM_merge(domain_params, extra_params); ctx = EVP_PKEY_CTX_new_from_name(NULL, “DHX”, NULL); EVP_PKEY_fromdata_init(ctx); EVP_PKEY_fromdata(ctx, &complete_domp, OSSL_KEYMGMT_SELECT_ALL, merged_params); validate_ctx = EVP_PKEY_CTX_new_from_pkey(NULL, complete_domp, NULL); if (EVP_PKEY_param_check(validate_ctx) > 0) /* validation_passed(); */ else /* validation_failed(); */ OSSL_PARAM_free(domain_params); OSSL_PARAM_free(merged_params); EVP_PKEY_CTX_free(ctx); EVP_PKEY_CTX_free(validate_ctx); EVP_PKEY_free(complete_domp);

CONFORMING TO

RFC 7919 (TLS ffdhe named safe prime groups)

RFC 3526 (IKE modp named safe prime groups)

RFC 5114 (Additional DH named groups for dh_1024_160", “dh_2048_224” and “dh_2048_256”).

The following sections of SP800-56Ar3:

Appendix D: FFC Safe-prime Groups

The following sections of FIPS186-4:

SEE ALSO

EVP_PKEY-FFC (7), EVP_KEYEXCH-DH (7) EVP_PKEY (3), provider-keymgmt (7), EVP_KEYMGMT (3), OSSL_PROVIDER-default (7), OSSL_PROVIDER-FIPS (7)

COPYRIGHT

Copyright 2020-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

71 - Linux cli command iso_8859_2

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso_8859_2 and provides detailed information about the command iso_8859_2, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso_8859_2.

NAME 🖥️ iso_8859_2 🖥️

2 - ISO/IEC 8859-2 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-2 encodes the Latin characters used in many Central and East European languages.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-2 characters

The following table displays the characters in ISO/IEC 8859-2 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-2 is also known as Latin-2.

SEE ALSO

ascii(7), charsets(7), iso_8859-1(7), iso_8859-16(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

72 - Linux cli command CLOSE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CLOSE and provides detailed information about the command CLOSE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CLOSE.

NAME 🖥️ CLOSE 🖥️

close a cursor

SYNOPSIS

CLOSE { name | ALL }

DESCRIPTION

CLOSE frees the resources associated with an open cursor. After the cursor is closed, no subsequent operations are allowed on it. A cursor should be closed when it is no longer needed.

Every non-holdable open cursor is implicitly closed when a transaction is terminated by COMMIT or ROLLBACK. A holdable cursor is implicitly closed if the transaction that created it aborts via ROLLBACK. If the creating transaction successfully commits, the holdable cursor remains open until an explicit CLOSE is executed, or the client disconnects.

PARAMETERS

name

The name of an open cursor to close.

ALL

Close all open cursors.

NOTES

PostgreSQL does not have an explicit OPEN cursor statement; a cursor is considered open when it is declared. Use the DECLARE statement to declare a cursor.

You can see all available cursors by querying the pg_cursors system view.

If a cursor is closed after a savepoint which is later rolled back, the CLOSE is not rolled back; that is, the cursor remains closed.

EXAMPLES

Close the cursor liahona:

CLOSE liahona;

COMPATIBILITY

CLOSE is fully conforming with the SQL standard. CLOSE ALL is a PostgreSQL extension.

SEE ALSO

DECLARE(7), FETCH(7), MOVE(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

73 - Linux cli command MOVE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command MOVE and provides detailed information about the command MOVE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the MOVE.

NAME 🖥️ MOVE 🖥️

position a cursor

SYNOPSIS

MOVE [ direction ] [ FROM | IN ] cursor_name

where direction can be one of:

    NEXT
    PRIOR
    FIRST
    LAST
    ABSOLUTE count
    RELATIVE count
    count
    ALL
    FORWARD
    FORWARD count
    FORWARD ALL
    BACKWARD
    BACKWARD count
    BACKWARD ALL

DESCRIPTION

MOVE repositions a cursor without retrieving any data. MOVE works exactly like the FETCH command, except it only positions the cursor and does not return rows.

The parameters for the MOVE command are identical to those of the FETCH command; refer to FETCH(7) for details on syntax and usage.

OUTPUTS

On successful completion, a MOVE command returns a command tag of the form

MOVE count

The count is the number of rows that a FETCH command with the same parameters would have returned (possibly zero).

EXAMPLES

BEGIN WORK; DECLARE liahona CURSOR FOR SELECT * FROM films;

-- Skip the first 5 rows:
MOVE FORWARD 5 IN liahona;
MOVE 5

-- Fetch the 6th row from the cursor liahona:
FETCH 1 FROM liahona;
 code  | title: | did | date_prod  |  kind  |  len
-------+--------+-----+------------+--------+-------
 P_303 | 48 Hrs | 103 | 1982-10-22 | Action | 01:37
(1 row)

-- Close the cursor liahona and end the transaction:
CLOSE liahona;
COMMIT WORK;

COMPATIBILITY

There is no MOVE statement in the SQL standard.

SEE ALSO

CLOSE(7), DECLARE(7), FETCH(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

74 - Linux cli command go-path

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command go-path and provides detailed information about the command go-path, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the go-path.

NAME 🖥️ go-path 🖥️

tool for managing Go source code

DESCRIPTION

The Go path is used to resolve import statements. It is implemented by and documented in the go/build package.

The GOPATH environment variable lists places to look for Go code. On Unix, the value is a colon-separated string. On Windows, the value is a semicolon-separated string. On Plan 9, the value is a list.

If the environment variable is unset, GOPATH defaults to a subdirectory named “go” in the user’s home directory ($HOME/go on Unix, %USERPROFILE% on Windows), unless that directory holds a Go distribution. Run “go env GOPATH” to see the current GOPATH.

See https://golang.org/wiki/SettingGOPATH to set a custom GOPATH.

Each directory listed in GOPATH must have a prescribed structure:

The src directory holds source code. The path below src determines the import path or executable name.

The pkg directory holds installed package objects. As in the Go tree, each target operating system and architecture pair has its own subdirectory of pkg (pkg/GOOS_GOARCH).

If DIR is a directory listed in the GOPATH, a package with source in DIR/src/foo/bar can be imported as “foo/bar” and has its compiled form installed to “DIR/pkg/GOOS_GOARCH/foo/bar.a”.

The bin directory holds compiled commands. Each command is named for its source directory, but only the final element, not the entire path. That is, the command with source in DIR/src/foo/quux is installed into DIR/bin/quux, not DIR/bin/foo/quux. The “foo/” prefix is stripped so that you can add DIR/bin to your PATH to get at the installed commands. If the GOBIN environment variable is set, commands are installed to the directory it names instead of DIR/bin. GOBIN must be an absolute path.

Here’s an example directory layout:

GOPATH=/home/user/gocode /home/user/gocode/ src/ foo/ bar/ (go code in package bar) x.go quux/ (go code in package main) y.go bin/ quux (installed command) pkg/ linux_amd64/ foo/ bar.a (installed package object)

Go searches each directory listed in GOPATH to find source code, but new packages are always downloaded into the first directory in the list.

See https://golang.org/doc/code.html for an example.

GOPATH and Modules

When using modules, GOPATH is no longer used for resolving imports. However, it is still used to store downloaded source code (in GOPATH/pkg/mod) and compiled commands (in GOPATH/bin).

Internal Directories

Code in or below a directory named “internal” is importable only by code in the directory tree rooted at the parent of “internal”. Here’s an extended version of the directory layout above:

/home/user/go/ src/ crash/ bang/ (go code in package bang) b.go foo/ (go code in package foo) f.go bar/ (go code in package bar) x.go internal/ baz/ (go code in package baz) z.go quux/ (go code in package main) y.go

The code in z.go is imported as “foo/internal/baz”, but that import statement can only appear in source files in the subtree rooted at foo. The source files foo/f.go, foo/bar/x.go, and foo/quux/y.go can all import “foo/internal/baz”, but the source file crash/bang/b.go cannot.

See https://golang.org/s/go14internal for details.

Vendor Directories

Go 1.6 includes support for using local copies of external dependencies to satisfy imports of those dependencies, often referred to as vendoring.

Code below a directory named “vendor” is importable only by code in the directory tree rooted at the parent of “vendor”, and only using an import path that omits the prefix up to and including the vendor element.

Here’s the example from the previous section, but with the “internal” directory renamed to “vendor” and a new foo/vendor/crash/bang directory added:

/home/user/go/ src/ crash/ bang/ (go code in package bang) b.go foo/ (go code in package foo) f.go bar/ (go code in package bar) x.go vendor/ crash/ bang/ (go code in package bang) b.go baz/ (go code in package baz) z.go quux/ (go code in package main) y.go

The same visibility rules apply as for internal, but the code in z.go is imported as “baz”, not as “foo/vendor/baz”.

Code in vendor directories deeper in the source tree shadows code in higher directories. Within the subtree rooted at foo, an import of “crash/bang” resolves to “foo/vendor/crash/bang”, not the top-level “crash/bang”.

Code in vendor directories is not subject to import path checking (see ‘go help importpath’).

When ‘go get’ checks out or updates a git repository, it now also updates submodules.

Vendor directories do not affect the placement of new repositories being checked out for the first time by ‘go get’: those are always placed in the main GOPATH, never in a vendor subtree.

See https://golang.org/s/go15vendor for details.

AUTHOR

This manual page was written by Michael Stapelberg <[email protected]> and is maintained by the Debian Go Compiler Team <[email protected]> based on the output of ‘go help gopath’ for the Debian project (and may be used by others).

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

75 - Linux cli command groff_trace

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command groff_trace and provides detailed information about the command groff_trace, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the groff_trace.

Name

groff_trace - macros for debugging GNU roff documents

Synopsis

groff -m trace [*option *. . .] [*file *. . .]

Description

trace is a macro package for the

document formatting system, designed as an aid for debugging documents written in its language. It issues a message to the standard error stream upon entry to and exit from each macro call. This can ease the process of isolating errors in macro definitions.

Activate the package by specifying the command-line option “-m trace” to the formatter program (often

You can achieve finer control by including the macro file within the document; invoke the mso request, as in “.mso trace.tmac”. Only macros that are defined after this invocation are traced. If the trace-full register is set to a true value, as with the command-line option “-r trace-full=1”, register and string assignments, along with some other requests, are traced also. If another macro package should be traced as well, specify it after “-m trace” on the command line.

The macro file trace.tmac is unusual because it does not contain any macros to be called by a user. Instead, groff’s macro definition and alteration facilities are wrapped such that they display diagnostic messages.

Limitations

Because trace.tmac wraps the de request (and its cousins), macro arguments are expanded one level more. This causes problems if an argument uses four or more backslashes to delay interpretation of an escape sequence. For example, the macro call

.foo \n[bar]

normally passes “\n[bar]” to macro “foo”, but with de redefined, it passes “ [bar]” instead.

The solution to this problem is to use groff’s  escape sequence, an escape character that is not interpreted in copy mode.

.foo n[bar]

Examples

We will illustrate trace.tmac using the shell’s “here document” feature to supply groff with a document on the standard input stream. Since we are interested only in diagnostic messages appearing on the standard error stream, we discard the formatted output by redirecting the standard output stream to /dev/null.

Observing nested macro calls

Macro calls can be nested, even with themselves. Tracing recurses along with them; this feature can help to detangle complex call stacks.

$ “cat«EOF|groff-mtrace>/dev/null .de countdown . nop $1 . nr count ($1 - 1) . if \n[count] .countdown \n[count] .. .countdown 3 blastoff EOF  *** .de countdown  *** de trace enter: .countdown “3”   *** de trace enter: .countdown “2”    *** de trace enter: .countdown “1”    *** trace exit: .countdown “1”   *** trace exit: .countdown “2”  *** trace exit: .countdown “3”

Tracing with the mso request

Now let us activate tracing within the document, not with a command-line option. We might do this when using a macro package like ms or mom, where we may not want to be distracted by traces of macros we didn’t write.

$ cat «EOF | groff -ms > /dev/null .LP This is my introductory paragraph. .mso trace.tmac .de Mymac .. .Mymac .PP Let us review the existing literature. EOF  *** .de Mymac  *** de trace enter: .Mymac  *** trace exit: .Mymac

As tracing was not yet active when the macros “LP” and “PP” were defined (by s.tmac), their calls were not traced; contrast with the macro “Mymac”.

Files

/usr/share/groff/1.23.0/tmac/trace.tmac
implements the package.

Authors

trace.tmac was written by James Clark. This document was written by Bernd Warken and G. Branden Robinson.

See also

Groff: The GNU Implementation of troff, by Trent A. Fisher and Werner Lemberg, is the primary groff manual. You can browse it interactively with “info groff”.

gives an overview of the groff document formatting system.

supplies details of the -m command-line option.

offers a survey of groff macro packages.

is a reference manual for the groff language.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

76 - Linux cli command hier

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command hier and provides detailed information about the command hier, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the hier.

NAME 🖥️ hier 🖥️

description of the filesystem hierarchy

DESCRIPTION

A typical Linux system has, among others, the following directories:

/
This is the root directory. This is where the whole tree starts.

/bin
This directory contains executable programs which are needed in single user mode and to bring the system up or repair it.

/boot
Contains static files for the boot loader. This directory holds only the files which are needed during the boot process. The map installer and configuration files should go to /sbin and /etc. The operating system kernel (initrd for example) must be located in either / or /boot.

/dev
Special or device files, which refer to physical devices. See mknod(1).

/etc
Contains configuration files which are local to the machine. Some larger software packages, like X11, can have their own subdirectories below /etc. Site-wide configuration files may be placed here or in /usr/etc. Nevertheless, programs should always look for these files in /etc and you may have links for these files to /usr/etc.

/etc/opt
Host-specific configuration files for add-on applications installed in /opt.

/etc/sgml
This directory contains the configuration files for SGML (optional).

/etc/skel
When a new user account is created, files from this directory are usually copied into the user’s home directory.

/etc/X11
Configuration files for the X11 window system (optional).

/etc/xml
This directory contains the configuration files for XML (optional).

/home
On machines with home directories for users, these are usually beneath this directory, directly or not. The structure of this directory depends on local administration decisions (optional).

/lib
This directory should hold those shared libraries that are necessary to boot the system and to run the commands in the root filesystem.

/lib<qual>
These directories are variants of /lib on system which support more than one binary format requiring separate libraries (optional).

/lib/modules
Loadable kernel modules (optional).

/lost+found
This directory contains items lost in the filesystem. These items are usually chunks of files mangled as a consequence of a faulty disk or a system crash.

/media
This directory contains mount points for removable media such as CD and DVD disks or USB sticks. On systems where more than one device exists for mounting a certain type of media, mount directories can be created by appending a digit to the name of those available above starting with ‘0’, but the unqualified name must also exist.

/media/floppy[1-9]
Floppy drive (optional).

/media/cdrom[1-9]
CD-ROM drive (optional).

/media/cdrecorder[1-9]
CD writer (optional).

/media/zip[1-9]
Zip drive (optional).

/media/usb[1-9]
USB drive (optional).

/mnt
This directory is a mount point for a temporarily mounted filesystem. In some distributions, /mnt contains subdirectories intended to be used as mount points for several temporary filesystems.

/opt
This directory should contain add-on packages that contain static files.

/proc
This is a mount point for the proc filesystem, which provides information about running processes and the kernel. This pseudo-filesystem is described in more detail in proc(5).

/root
This directory is usually the home directory for the root user (optional).

/run
This directory contains information which describes the system since it was booted. Once this purpose was served by /var/run and programs may continue to use it.

/sbin
Like /bin, this directory holds commands needed to boot the system, but which are usually not executed by normal users.

/srv
This directory contains site-specific data that is served by this system.

/sys
This is a mount point for the sysfs filesystem, which provides information about the kernel like /proc, but better structured, following the formalism of kobject infrastructure.

/tmp
This directory contains temporary files which may be deleted with no notice, such as by a regular job or at system boot up.

/usr
This directory is usually mounted from a separate partition. It should hold only shareable, read-only data, so that it can be mounted by various machines running Linux.

/usr/X11R6
The X-Window system, version 11 release 6 (present in FHS 2.3, removed in FHS 3.0).

/usr/X11R6/bin
Binaries which belong to the X-Window system; often, there is a symbolic link from the more traditional /usr/bin/X11 to here.

/usr/X11R6/lib
Data files associated with the X-Window system.

/usr/X11R6/lib/X11
These contain miscellaneous files needed to run X; Often, there is a symbolic link from /usr/lib/X11 to this directory.

/usr/X11R6/include/X11
Contains include files needed for compiling programs using the X11 window system. Often, there is a symbolic link from /usr/include/X11 to this directory.

/usr/bin
This is the primary directory for executable programs. Most programs executed by normal users which are not needed for booting or for repairing the system and which are not installed locally should be placed in this directory.

/usr/bin/mh
Commands for the MH mail handling system (optional).

/usr/bin/X11
This is the traditional place to look for X11 executables; on Linux, it usually is a symbolic link to /usr/X11R6/bin.

/usr/dict
Replaced by /usr/share/dict.

/usr/doc
Replaced by /usr/share/doc.

/usr/etc
Site-wide configuration files to be shared between several machines may be stored in this directory. However, commands should always reference those files using the /etc directory. Links from files in /etc should point to the appropriate files in /usr/etc.

/usr/games
Binaries for games and educational programs (optional).

/usr/include
Include files for the C compiler.

/usr/include/bsd
BSD compatibility include files (optional).

/usr/include/X11
Include files for the C compiler and the X-Window system. This is usually a symbolic link to /usr/X11R6/include/X11.

/usr/include/asm
Include files which declare some assembler functions. This used to be a symbolic link to /usr/src/linux/include/asm.

/usr/include/linux
This contains information which may change from system release to system release and used to be a symbolic link to /usr/src/linux/include/linux to get at operating-system-specific information.

(Note that one should have include files there that work correctly with the current libc and in user space. However, Linux kernel source is not designed to be used with user programs and does not know anything about the libc you are using. It is very likely that things will break if you let /usr/include/asm and /usr/include/linux point at a random kernel tree. Debian systems don’t do this and use headers from a known good kernel version, provided in the libc*-dev package.)

/usr/include/g++
Include files to use with the GNU C++ compiler.

/usr/lib
Object libraries, including dynamic libraries, plus some executables which usually are not invoked directly. More complicated programs may have whole subdirectories there.

/usr/libexec
Directory contains binaries for internal use only and they are not meant to be executed directly by users shell or scripts.

/usr/lib<qual>
These directories are variants of /usr/lib on system which support more than one binary format requiring separate libraries, except that the symbolic link /usr/libqual*/X11* is not required (optional).

/usr/lib/X11
The usual place for data files associated with X programs, and configuration files for the X system itself. On Linux, it usually is a symbolic link to /usr/X11R6/lib/X11.

/usr/lib/gcc-lib
contains executables and include files for the GNU C compiler, gcc(1).

/usr/lib/groff
Files for the GNU groff document formatting system.

/usr/lib/uucp
Files for uucp(1).

/usr/local
This is where programs which are local to the site typically go.

/usr/local/bin
Binaries for programs local to the site.

/usr/local/doc
Local documentation.

/usr/local/etc
Configuration files associated with locally installed programs.

/usr/local/games
Binaries for locally installed games.

/usr/local/lib
Files associated with locally installed programs.

/usr/local/lib<qual>
These directories are variants of /usr/local/lib on system which support more than one binary format requiring separate libraries (optional).

/usr/local/include
Header files for the local C compiler.

/usr/local/info
Info pages associated with locally installed programs.

/usr/local/man
Man pages associated with locally installed programs.

/usr/local/sbin
Locally installed programs for system administration.

/usr/local/share
Local application data that can be shared among different architectures of the same OS.

/usr/local/src
Source code for locally installed software.

/usr/man
Replaced by /usr/share/man.

/usr/sbin
This directory contains program binaries for system administration which are not essential for the boot process, for mounting /usr, or for system repair.

/usr/share
This directory contains subdirectories with specific application data, that can be shared among different architectures of the same OS. Often one finds stuff here that used to live in /usr/doc or /usr/lib or /usr/man.

/usr/share/color
Contains color management information, like International Color Consortium (ICC) Color profiles (optional).

/usr/share/dict
Contains the word lists used by spell checkers (optional).

/usr/share/dict/words
List of English words (optional).

/usr/share/doc
Documentation about installed programs (optional).

/usr/share/games
Static data files for games in /usr/games (optional).

/usr/share/info
Info pages go here (optional).

/usr/share/locale
Locale information goes here (optional).

/usr/share/man
Manual pages go here in subdirectories according to the man page sections.

/usr/share/man/locale/man[1-9]
These directories contain manual pages for the specific locale in source code form. Systems which use a unique language and code set for all manual pages may omit the <locale> substring.

/usr/share/misc
Miscellaneous data that can be shared among different architectures of the same OS.

/usr/share/nls
The message catalogs for native language support go here (optional).

/usr/share/ppd
Postscript Printer Definition (PPD) files (optional).

/usr/share/sgml
Files for SGML (optional).

/usr/share/sgml/docbook
DocBook DTD (optional).

/usr/share/sgml/tei
TEI DTD (optional).

/usr/share/sgml/html
HTML DTD (optional).

/usr/share/sgml/mathml
MathML DTD (optional).

/usr/share/terminfo
The database for terminfo (optional).

/usr/share/tmac
Troff macros that are not distributed with groff (optional).

/usr/share/xml
Files for XML (optional).

/usr/share/xml/docbook
DocBook DTD (optional).

/usr/share/xml/xhtml
XHTML DTD (optional).

/usr/share/xml/mathml
MathML DTD (optional).

/usr/share/zoneinfo
Files for timezone information (optional).

/usr/src
Source files for different parts of the system, included with some packages for reference purposes. Don’t work here with your own projects, as files below /usr should be read-only except when installing software (optional).

/usr/src/linux
This was the traditional place for the kernel source. Some distributions put here the source for the default kernel they ship. You should probably use another directory when building your own kernel.

/usr/tmp
Obsolete. This should be a link to /var/tmp. This link is present only for compatibility reasons and shouldn’t be used.

/var
This directory contains files which may change in size, such as spool and log files.

/var/account
Process accounting logs (optional).

/var/adm
This directory is superseded by /var/log and should be a symbolic link to /var/log.

/var/backups
Reserved for historical reasons.

/var/cache
Data cached for programs.

/var/cache/fonts
Locally generated fonts (optional).

/var/cache/man
Locally formatted man pages (optional).

/var/cache/www
WWW proxy or cache data (optional).

/var/cache/<package>
Package specific cache data (optional).

/var/catman/cat[1-9] or /var/cache/man/cat[1-9]
These directories contain preformatted manual pages according to their man page section. (The use of preformatted manual pages is deprecated.)

/var/crash
System crash dumps (optional).

/var/cron
Reserved for historical reasons.

/var/games
Variable game data (optional).

/var/lib
Variable state information for programs.

/var/lib/color
Variable files containing color management information (optional).

/var/lib/hwclock
State directory for hwclock (optional).

/var/lib/misc
Miscellaneous state data.

/var/lib/xdm
X display manager variable data (optional).

/var/lib/<editor>
Editor backup files and state (optional).

/var/lib/<name>
These directories must be used for all distribution packaging support.

/var/lib/<package>
State data for packages and subsystems (optional).

/var/lib/<pkgtool>
Packaging support files (optional).

/var/local
Variable data for /usr/local.

/var/lock
Lock files are placed in this directory. The naming convention for device lock files is LCK..<device> where <device> is the device’s name in the filesystem. The format used is that of HDU UUCP lock files, that is, lock files contain a PID as a 10-byte ASCII decimal number, followed by a newline character.

/var/log
Miscellaneous log files.

/var/opt
Variable data for /opt.

/var/mail
Users’ mailboxes. Replaces /var/spool/mail.

/var/msgs
Reserved for historical reasons.

/var/preserve
Reserved for historical reasons.

/var/run
Run-time variable files, like files holding process identifiers (PIDs) and logged user information (utmp). Files in this directory are usually cleared when the system boots.

/var/spool
Spooled (or queued) files for various programs.

/var/spool/at
Spooled jobs for at(1).

/var/spool/cron
Spooled jobs for cron(8).

/var/spool/lpd
Spooled files for printing (optional).

/var/spool/lpd/printer
Spools for a specific printer (optional).

/var/spool/mail
Replaced by /var/mail.

/var/spool/mqueue
Queued outgoing mail (optional).

/var/spool/news
Spool directory for news (optional).

/var/spool/rwho
Spooled files for rwhod(8) (optional).

/var/spool/smail
Spooled files for the smail(1) mail delivery program.

/var/spool/uucp
Spooled files for uucp(1) (optional).

/var/tmp
Like /tmp, this directory holds temporary files stored for an unspecified duration.

/var/yp
Database files for NIS, formerly known as the Sun Yellow Pages (YP).

STANDARDS

The Filesystem Hierarchy Standard (FHS), Version 3.0, published March 19, 2015

BUGS

This list is not exhaustive; different distributions and systems may be configured differently.

SEE ALSO

find(1), ln(1), proc(5), file-hierarchy(7), mount(8)

The Filesystem Hierarchy Standard

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

77 - Linux cli command iso_8859-4

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso_8859-4 and provides detailed information about the command iso_8859-4, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso_8859-4.

NAME 🖥️ iso_8859-4 🖥️

4 - ISO/IEC 8859-4 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-4 encodes the characters used in Scandinavian and Baltic languages.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-4 characters

The following table displays the characters in ISO/IEC 8859-4 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-4 is also known as Latin-4.

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

78 - Linux cli command ossl-guide-quic-introductionssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ossl-guide-quic-introductionssl and provides detailed information about the command ossl-guide-quic-introductionssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ossl-guide-quic-introductionssl.

NAME 🖥️ ossl-guide-quic-introductionssl 🖥️

guide-quic-introduction - OpenSSL Guide: An introduction to QUIC in OpenSSL

INTRODUCTION

This page will provide an introduction to some basic QUIC concepts and background and how it is used within OpenSSL. It assumes that you have a basic understanding of UDP/IP and sockets. It also assumes that you are familiar with some OpenSSL and TLS fundamentals (see ossl-guide-libraries-introduction (7) and ossl-guide-tls-introduction (7)).

WHAT IS QUIC?

QUIC is a general purpose protocol for enabling applications to securely communicate over a network. It is defined in RFC9000 (see <https://datatracker.ietf.org/doc/rfc9000/>). QUIC integrates parts of the TLS protocol for connection establishment but independently protects packets. It provides similar security guarantees to TLS such as confidentiality, integrity and authentication (see ossl-guide-tls-introduction (7)).

QUIC delivers a number of advantages:

Multiple streams
It supports multiple streams of communication (see “QUIC STREAMS” below), allowing application protocols built on QUIC to create arbitrarily many bytestreams for communication between a client and server. This allows an application protocol to avoid problems where one packet of data is held up waiting on another packet being delivered (commonly referred to as “head-of-line blocking”). It also enables an application to open additional logical streams without requiring a round-trip exchange of packets between the client and server as is required when opening an additional TLS/TCP connection.

HTTP/3
Since QUIC is the basis of HTTP/3, support for QUIC also enables applications to use HTTP/3 using a suitable third-party library.

Fast connection initiation
Future versions of OpenSSL will offer support for 0-RTT connection initiation, allowing a connection to be initiated to a server and application data to be transmitted without any waiting time. This is similar to TLS 1.3’s 0-RTT functionality but also avoids the round trip needed to open a TCP socket; thus, it is similar to a combination of TLS 1.3 0-RTT and TCP Fast Open.

Connection migration
Future versions of OpenSSL will offer support for connection migration, allowing connections to seamlessly survive IP address changes.

Datagram based use cases
Future versions of OpenSSL will offer support for the QUIC datagram extension, allowing support for both TLS and DTLS-style use cases on a single connection.

Implemented as application library
Because most QUIC implementations, including OpenSSL’s implementation, are implemented as an application library rather than by an operating system, an application can gain the benefit of QUIC without needing to wait for an OS update to be deployed. Future evolutions and enhancements to the QUIC protocol can be delivered as quickly as an application can be updated without dependency on an OS update cadence.

Multiplexing over a single UDP socket
Because QUIC is UDP-based, it is possible to multiplex a QUIC connection on the same UDP socket as some other UDP-based protocols, such as RTP.

QUIC TIME BASED EVENTS

A key difference between the TLS implementation and the QUIC implementation in OpenSSL is how time is handled. The QUIC protocol requires various actions to be performed on a regular basis regardless of whether application data is being transmitted or received.

OpenSSL introduces a new function SSL_handle_events (3) that will automatically process any outstanding time based events that must be handled. Alternatively calling any I/O function such as SSL_read_ex (3) or SSL_write_ex (3) will also process these events. There is also SSL_get_event_timeout (3) which tells an application the amount of time that remains until SSL_handle_events (3) (or any I/O function) must be called.

Fortunately a blocking application that does not leave the QUIC connection idle, and is regularly calling I/O functions does not typically need to worry about this. However if you are developing a nonblocking application or one that may leave the QUIC connection idle for a period of time then you will need to arrange to call these functions.

OpenSSL provides an optional “thread assisted mode” that will automatically create a background thread and will regularly call SSL_handle_events (3) in a thread safe manner. This provides a simple way for an application to satisfy the QUIC requirements for time based events without having to implement special logic to accomplish it.

QUIC AND TLS

QUIC reuses parts of the TLS protocol in its implementation. Specifically the TLS handshake also exists in QUIC. The TLS handshake messages are wrapped up in QUIC protocol messages in order to send them to the peer. Once the TLS handshake is complete all application data is sent entirely using QUIC protocol messages without using TLS - although some TLS handshake messages may still be sent in some circumstances.

This relationship between QUIC and TLS means that many of the API functions in OpenSSL that apply to TLS connections also apply to QUIC connections and applications can use them in exactly the same way. Some functions do not apply to QUIC at all, and others have altered semantics. You should refer to the documentation pages for each function for information on how it applies to QUIC. Typically if QUIC is not mentioned in the manual pages then the functions apply to both TLS and QUIC.

QUIC STREAMS

QUIC introduces the concept of “streams”. A stream provides a reliable mechanism for sending and receiving application data between the endpoints. The bytes transmitted are guaranteed to be received in the same order they were sent without any loss of data or reordering of the bytes. A TLS application effectively has one bi-directional stream available to it per TLS connection. A QUIC application can have multiple uni-directional or bi-directional streams available to it for each connection.

In OpenSSL an SSL object is used to represent both connections and streams. A QUIC application creates an initial SSL object to represent the connection (known as the connection SSL object). Once the connection is complete additional SSL objects can be created to represent streams (known as stream SSL objects). Unless configured otherwise, a “default” stream is also associated with the connection SSL object so you can still write data and read data to/from it. Some OpenSSL API functions can only be used with connection SSL objects, and some can only be used with stream SSL objects. Check the documentation for each function to confirm what type of SSL object can be used in any particular context. A connection SSL object that has a default stream attached to it can be used in contexts that require a connection SSL object or in contexts that require a stream SSL object.

SOCKETS AND BLOCKING

TLS assumes “stream” type semantics for its underlying transport layer protocol (usually achieved by using TCP). However QUIC assumes “datagram” type semantics by using UDP. An OpenSSL application using QUIC is responsible for creating a BIO to represent the underlying transport layer. This BIO must support datagrams and is typically BIO_s_datagram (3), but other BIO choices are available. See bio (7) for an introduction to OpenSSL’s BIO concept.

A significant difference between OpenSSL TLS applications and OpenSSL QUIC applications is the way that blocking is implemented. In TLS if your application expects blocking behaviour then you configure the underlying socket for blocking. Conversely if your application wants nonblocking behaviour then the underlying socket is configured to be nonblocking.

With an OpenSSL QUIC application the underlying socket must always be configured to be nonblocking. Howevever the SSL object will, by default, still operate in blocking mode. So, from an application’s perspective, calls to functions such as SSL_read_ex (3), SSL_write_ex (3) and other I/O functions will still block. OpenSSL itself provides that blocking capability for QUIC instead of the socket. If nonblocking behaviour is desired then the application must call SSL_set_blocking_mode (3).

FURTHER READING

See ossl-guide-quic-client-block (7) to see an example of applying these concepts in order to write a simple blocking QUIC client.

SEE ALSO

ossl-guide-introduction (7), ossl-guide-libraries-introduction (7), ossl-guide-libssl-introduction (7), ossl-guide-tls-introduction (7), ossl-guide-tls-client-block (7), ossl-guide-quic-client-block (7), bio (7)

COPYRIGHT

Copyright 2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

79 - Linux cli command tcp

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command tcp and provides detailed information about the command tcp, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the tcp.

NAME 🖥️ tcp 🖥️

TCP protocol

SYNOPSIS

#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/tcp.h>
tcp_socket = socket(AF_INET, SOCK_STREAM, 0);

DESCRIPTION

This is an implementation of the TCP protocol defined in RFC 793, RFC 1122 and RFC 2001 with the NewReno and SACK extensions. It provides a reliable, stream-oriented, full-duplex connection between two sockets on top of ip(7), for both v4 and v6 versions. TCP guarantees that the data arrives in order and retransmits lost packets. It generates and checks a per-packet checksum to catch transmission errors. TCP does not preserve record boundaries.

A newly created TCP socket has no remote or local address and is not fully specified. To create an outgoing TCP connection use connect(2) to establish a connection to another TCP socket. To receive new incoming connections, first bind(2) the socket to a local address and port and then call listen(2) to put the socket into the listening state. After that a new socket for each incoming connection can be accepted using accept(2). A socket which has had accept(2) or connect(2) successfully called on it is fully specified and may transmit data. Data cannot be transmitted on listening or not yet connected sockets.

Linux supports RFC 1323 TCP high performance extensions. These include Protection Against Wrapped Sequence Numbers (PAWS), Window Scaling and Timestamps. Window scaling allows the use of large (> 64 kB) TCP windows in order to support links with high latency or bandwidth. To make use of them, the send and receive buffer sizes must be increased. They can be set globally with the /proc/sys/net/ipv4/tcp_wmem and /proc/sys/net/ipv4/tcp_rmem files, or on individual sockets by using the SO_SNDBUF and SO_RCVBUF socket options with the setsockopt(2) call.

The maximum sizes for socket buffers declared via the SO_SNDBUF and SO_RCVBUF mechanisms are limited by the values in the /proc/sys/net/core/rmem_max and /proc/sys/net/core/wmem_max files. Note that TCP actually allocates twice the size of the buffer requested in the setsockopt(2) call, and so a succeeding getsockopt(2) call will not return the same size of buffer as requested in the setsockopt(2) call. TCP uses the extra space for administrative purposes and internal kernel structures, and the /proc file values reflect the larger sizes compared to the actual TCP windows. On individual connections, the socket buffer size must be set prior to the listen(2) or connect(2) calls in order to have it take effect. See socket(7) for more information.

TCP supports urgent data. Urgent data is used to signal the receiver that some important message is part of the data stream and that it should be processed as soon as possible. To send urgent data specify the MSG_OOB option to send(2). When urgent data is received, the kernel sends a SIGURG signal to the process or process group that has been set as the socket “owner” using the SIOCSPGRP or FIOSETOWN ioctls (or the POSIX.1-specified fcntl(2) F_SETOWN operation). When the SO_OOBINLINE socket option is enabled, urgent data is put into the normal data stream (a program can test for its location using the SIOCATMARK ioctl described below), otherwise it can be received only when the MSG_OOB flag is set for recv(2) or recvmsg(2).

When out-of-band data is present, select(2) indicates the file descriptor as having an exceptional condition and poll (2) indicates a POLLPRI event.

Linux 2.4 introduced a number of changes for improved throughput and scaling, as well as enhanced functionality. Some of these features include support for zero-copy sendfile(2), Explicit Congestion Notification, new management of TIME_WAIT sockets, keep-alive socket options and support for Duplicate SACK extensions.

Address formats

TCP is built on top of IP (see ip(7)). The address formats defined by ip(7) apply to TCP. TCP supports point-to-point communication only; broadcasting and multicasting are not supported.

/proc interfaces

System-wide TCP parameter settings can be accessed by files in the directory /proc/sys/net/ipv4/. In addition, most IP /proc interfaces also apply to TCP; see ip(7). Variables described as Boolean take an integer value, with a nonzero value (“true”) meaning that the corresponding option is enabled, and a zero value (“false”) meaning that the option is disabled.

tcp_abc (Integer; default: 0; Linux 2.6.15 to Linux 3.8)
Control the Appropriate Byte Count (ABC), defined in RFC 3465. ABC is a way of increasing the congestion window (cwnd) more slowly in response to partial acknowledgements. Possible values are:

0
increase cwnd once per acknowledgement (no ABC)

1
increase cwnd once per acknowledgement of full sized segment

2
allow increase cwnd by two if acknowledgement is of two segments to compensate for delayed acknowledgements.

tcp_abort_on_overflow (Boolean; default: disabled; since Linux 2.4)
Enable resetting connections if the listening service is too slow and unable to keep up and accept them. It means that if overflow occurred due to a burst, the connection will recover. Enable this option only if you are really sure that the listening daemon cannot be tuned to accept connections faster. Enabling this option can harm the clients of your server.

tcp_adv_win_scale (integer; default: 2; since Linux 2.4)
Count buffering overhead as bytes/2^tcp_adv_win_scale, if tcp_adv_win_scale is greater than 0; or bytes-bytes/2^(-tcp_adv_win_scale), if tcp_adv_win_scale is less than or equal to zero.

The socket receive buffer space is shared between the application and kernel. TCP maintains part of the buffer as the TCP window, this is the size of the receive window advertised to the other end. The rest of the space is used as the “application” buffer, used to isolate the network from scheduling and application latencies. The tcp_adv_win_scale default value of 2 implies that the space used for the application buffer is one fourth that of the total.

tcp_allowed_congestion_control (String; default: see text; since Linux 2.4.20)
Show/set the congestion control algorithm choices available to unprivileged processes (see the description of the TCP_CONGESTION socket option). The items in the list are separated by white space and terminated by a newline character. The list is a subset of those listed in tcp_available_congestion_control. The default value for this list is “reno” plus the default setting of tcp_congestion_control.

tcp_autocorking (Boolean; default: enabled; since Linux 3.14)
If this option is enabled, the kernel tries to coalesce small writes (from consecutive write(2) and sendmsg(2) calls) as much as possible, in order to decrease the total number of sent packets. Coalescing is done if at least one prior packet for the flow is waiting in Qdisc queues or device transmit queue. Applications can still use the TCP_CORK socket option to obtain optimal behavior when they know how/when to uncork their sockets.

tcp_available_congestion_control (String; read-only; since Linux 2.4.20)
Show a list of the congestion-control algorithms that are registered. The items in the list are separated by white space and terminated by a newline character. This list is a limiting set for the list in tcp_allowed_congestion_control. More congestion-control algorithms may be available as modules, but not loaded.

tcp_app_win (integer; default: 31; since Linux 2.4)
This variable defines how many bytes of the TCP window are reserved for buffering overhead.

A maximum of (window/2^tcp_app_win, mss) bytes in the window are reserved for the application buffer. A value of 0 implies that no amount is reserved.

tcp_base_mss (Integer; default: 512; since Linux 2.6.17)
The initial value of search_low to be used by the packetization layer Path MTU discovery (MTU probing). If MTU probing is enabled, this is the initial MSS used by the connection.

tcp_bic (Boolean; default: disabled; Linux 2.4.27/2.6.6 to Linux 2.6.13)
Enable BIC TCP congestion control algorithm. BIC-TCP is a sender-side-only change that ensures a linear RTT fairness under large windows while offering both scalability and bounded TCP-friendliness. The protocol combines two schemes called additive increase and binary search increase. When the congestion window is large, additive increase with a large increment ensures linear RTT fairness as well as good scalability. Under small congestion windows, binary search increase provides TCP friendliness.

tcp_bic_low_window (integer; default: 14; Linux 2.4.27/2.6.6 to Linux 2.6.13)
Set the threshold window (in packets) where BIC TCP starts to adjust the congestion window. Below this threshold BIC TCP behaves the same as the default TCP Reno.

tcp_bic_fast_convergence (Boolean; default: enabled; Linux 2.4.27/2.6.6 to Linux 2.6.13)
Force BIC TCP to more quickly respond to changes in congestion window. Allows two flows sharing the same connection to converge more rapidly.

tcp_congestion_control (String; default: see text; since Linux 2.4.13)
Set the default congestion-control algorithm to be used for new connections. The algorithm “reno” is always available, but additional choices may be available depending on kernel configuration. The default value for this file is set as part of kernel configuration.

tcp_dma_copybreak (integer; default: 4096; since Linux 2.6.24)
Lower limit, in bytes, of the size of socket reads that will be offloaded to a DMA copy engine, if one is present in the system and the kernel was configured with the CONFIG_NET_DMA option.

tcp_dsack (Boolean; default: enabled; since Linux 2.4)
Enable RFC 2883 TCP Duplicate SACK support.

tcp_fastopen (Bitmask; default: 0x1; since Linux 3.7)
Enables RFC 7413 Fast Open support. The flag is used as a bitmap with the following values:

0x1
Enables client side Fast Open support

0x2
Enables server side Fast Open support

0x4
Allows client side to transmit data in SYN without Fast Open option

0x200
Allows server side to accept SYN data without Fast Open option

0x400
Enables Fast Open on all listeners without TCP_FASTOPEN socket option

tcp_fastopen_key (since Linux 3.7)
Set server side RFC 7413 Fast Open key to generate Fast Open cookie when server side Fast Open support is enabled.

tcp_ecn (Integer; default: see below; since Linux 2.4)
Enable RFC 3168 Explicit Congestion Notification.

This file can have one of the following values:

0
Disable ECN. Neither initiate nor accept ECN. This was the default up to and including Linux 2.6.30.

1
Enable ECN when requested by incoming connections and also request ECN on outgoing connection attempts.

2
Enable ECN when requested by incoming connections, but do not request ECN on outgoing connections. This value is supported, and is the default, since Linux 2.6.31.

When enabled, connectivity to some destinations could be affected due to older, misbehaving middle boxes along the path, causing connections to be dropped. However, to facilitate and encourage deployment with option 1, and to work around such buggy equipment, the tcp_ecn_fallback option has been introduced.

tcp_ecn_fallback (Boolean; default: enabled; since Linux 4.1)
Enable RFC 3168, Section 6.1.1.1. fallback. When enabled, outgoing ECN-setup SYNs that time out within the normal SYN retransmission timeout will be resent with CWR and ECE cleared.

tcp_fack (Boolean; default: enabled; since Linux 2.2)
Enable TCP Forward Acknowledgement support.

tcp_fin_timeout (integer; default: 60; since Linux 2.2)
This specifies how many seconds to wait for a final FIN packet before the socket is forcibly closed. This is strictly a violation of the TCP specification, but required to prevent denial-of-service attacks. In Linux 2.2, the default value was 180.

tcp_frto (integer; default: see below; since Linux 2.4.21/2.6)
Enable F-RTO, an enhanced recovery algorithm for TCP retransmission timeouts (RTOs). It is particularly beneficial in wireless environments where packet loss is typically due to random radio interference rather than intermediate router congestion. See RFC 4138 for more details.

This file can have one of the following values:

0
Disabled. This was the default up to and including Linux 2.6.23.

1
The basic version F-RTO algorithm is enabled.

2
Enable SACK-enhanced F-RTO if flow uses SACK. The basic version can be used also when SACK is in use though in that case scenario(s) exists where F-RTO interacts badly with the packet counting of the SACK-enabled TCP flow. This value is the default since Linux 2.6.24.

Before Linux 2.6.22, this parameter was a Boolean value, supporting just values 0 and 1 above.

tcp_frto_response (integer; default: 0; since Linux 2.6.22)
When F-RTO has detected that a TCP retransmission timeout was spurious (i.e., the timeout would have been avoided had TCP set a longer retransmission timeout), TCP has several options concerning what to do next. Possible values are:

0
Rate halving based; a smooth and conservative response, results in halved congestion window (cwnd) and slow-start threshold (ssthresh) after one RTT.

1
Very conservative response; not recommended because even though being valid, it interacts poorly with the rest of Linux TCP; halves cwnd and ssthresh immediately.

2
Aggressive response; undoes congestion-control measures that are now known to be unnecessary (ignoring the possibility of a lost retransmission that would require TCP to be more cautious); cwnd and ssthresh are restored to the values prior to timeout.

tcp_keepalive_intvl (integer; default: 75; since Linux 2.4)
The number of seconds between TCP keep-alive probes.

tcp_keepalive_probes (integer; default: 9; since Linux 2.2)
The maximum number of TCP keep-alive probes to send before giving up and killing the connection if no response is obtained from the other end.

tcp_keepalive_time (integer; default: 7200; since Linux 2.2)
The number of seconds a connection needs to be idle before TCP begins sending out keep-alive probes. Keep-alives are sent only when the SO_KEEPALIVE socket option is enabled. The default value is 7200 seconds (2 hours). An idle connection is terminated after approximately an additional 11 minutes (9 probes an interval of 75 seconds apart) when keep-alive is enabled.

Note that underlying connection tracking mechanisms and application timeouts may be much shorter.

tcp_low_latency (Boolean; default: disabled; since Linux 2.4.21/2.6; obsolete since Linux 4.14)
If enabled, the TCP stack makes decisions that prefer lower latency as opposed to higher throughput. It this option is disabled, then higher throughput is preferred. An example of an application where this default should be changed would be a Beowulf compute cluster. Since Linux 4.14, this file still exists, but its value is ignored.

tcp_max_orphans (integer; default: see below; since Linux 2.4)
The maximum number of orphaned (not attached to any user file handle) TCP sockets allowed in the system. When this number is exceeded, the orphaned connection is reset and a warning is printed. This limit exists only to prevent simple denial-of-service attacks. Lowering this limit is not recommended. Network conditions might require you to increase the number of orphans allowed, but note that each orphan can eat up to ~64 kB of unswappable memory. The default initial value is set equal to the kernel parameter NR_FILE. This initial default is adjusted depending on the memory in the system.

tcp_max_syn_backlog (integer; default: see below; since Linux 2.2)
The maximum number of queued connection requests which have still not received an acknowledgement from the connecting client. If this number is exceeded, the kernel will begin dropping requests. The default value of 256 is increased to 1024 when the memory present in the system is adequate or greater (>= 128 MB), and reduced to 128 for those systems with very low memory (<= 32 MB).

Before Linux 2.6.20, it was recommended that if this needed to be increased above 1024, the size of the SYNACK hash table (TCP_SYNQ_HSIZE) in include/net/tcp.h should be modified to keep

TCP_SYNQ_HSIZE * 16 <= tcp_max_syn_backlog

and the kernel should be recompiled. In Linux 2.6.20, the fixed sized TCP_SYNQ_HSIZE was removed in favor of dynamic sizing.

tcp_max_tw_buckets (integer; default: see below; since Linux 2.4)
The maximum number of sockets in TIME_WAIT state allowed in the system. This limit exists only to prevent simple denial-of-service attacks. The default value of NR_FILE*2 is adjusted depending on the memory in the system. If this number is exceeded, the socket is closed and a warning is printed.

tcp_moderate_rcvbuf (Boolean; default: enabled; since Linux 2.4.17/2.6.7)
If enabled, TCP performs receive buffer auto-tuning, attempting to automatically size the buffer (no greater than tcp_rmem[2]) to match the size required by the path for full throughput.

tcp_mem (since Linux 2.4)
This is a vector of 3 integers: [low, pressure, high]. These bounds, measured in units of the system page size, are used by TCP to track its memory usage. The defaults are calculated at boot time from the amount of available memory. (TCP can only use low memory for this, which is limited to around 900 megabytes on 32-bit systems. 64-bit systems do not suffer this limitation.)

low
TCP doesn’t regulate its memory allocation when the number of pages it has allocated globally is below this number.

pressure
When the amount of memory allocated by TCP exceeds this number of pages, TCP moderates its memory consumption. This memory pressure state is exited once the number of pages allocated falls below the low mark.

high
The maximum number of pages, globally, that TCP will allocate. This value overrides any other limits imposed by the kernel.

tcp_mtu_probing (integer; default: 0; since Linux 2.6.17)
This parameter controls TCP Packetization-Layer Path MTU Discovery. The following values may be assigned to the file:

0
Disabled

1
Disabled by default, enabled when an ICMP black hole detected

2
Always enabled, use initial MSS of tcp_base_mss.

tcp_no_metrics_save (Boolean; default: disabled; since Linux 2.6.6)
By default, TCP saves various connection metrics in the route cache when the connection closes, so that connections established in the near future can use these to set initial conditions. Usually, this increases overall performance, but it may sometimes cause performance degradation. If tcp_no_metrics_save is enabled, TCP will not cache metrics on closing connections.

tcp_orphan_retries (integer; default: 8; since Linux 2.4)
The maximum number of attempts made to probe the other end of a connection which has been closed by our end.

tcp_reordering (integer; default: 3; since Linux 2.4)
The maximum a packet can be reordered in a TCP packet stream without TCP assuming packet loss and going into slow start. It is not advisable to change this number. This is a packet reordering detection metric designed to minimize unnecessary back off and retransmits provoked by reordering of packets on a connection.

tcp_retrans_collapse (Boolean; default: enabled; since Linux 2.2)
Try to send full-sized packets during retransmit.

tcp_retries1 (integer; default: 3; since Linux 2.2)
The number of times TCP will attempt to retransmit a packet on an established connection normally, without the extra effort of getting the network layers involved. Once we exceed this number of retransmits, we first have the network layer update the route if possible before each new retransmit. The default is the RFC specified minimum of 3.

tcp_retries2 (integer; default: 15; since Linux 2.2)
The maximum number of times a TCP packet is retransmitted in established state before giving up. The default value is 15, which corresponds to a duration of approximately between 13 to 30 minutes, depending on the retransmission timeout. The RFC 1122 specified minimum limit of 100 seconds is typically deemed too short.

tcp_rfc1337 (Boolean; default: disabled; since Linux 2.2)
Enable TCP behavior conformant with RFC 1337. When disabled, if a RST is received in TIME_WAIT state, we close the socket immediately without waiting for the end of the TIME_WAIT period.

tcp_rmem (since Linux 2.4)
This is a vector of 3 integers: [min, default, max]. These parameters are used by TCP to regulate receive buffer sizes. TCP dynamically adjusts the size of the receive buffer from the defaults listed below, in the range of these values, depending on memory available in the system.

min
minimum size of the receive buffer used by each TCP socket. The default value is the system page size. (On Linux 2.4, the default value is 4 kB, lowered to PAGE_SIZE bytes in low-memory systems.) This value is used to ensure that in memory pressure mode, allocations below this size will still succeed. This is not used to bound the size of the receive buffer declared using SO_RCVBUF on a socket.

default
the default size of the receive buffer for a TCP socket. This value overwrites the initial default buffer size from the generic global net.core.rmem_default defined for all protocols. The default value is 87380 bytes. (On Linux 2.4, this will be lowered to 43689 in low-memory systems.) If larger receive buffer sizes are desired, this value should be increased (to affect all sockets). To employ large TCP windows, the net.ipv4.tcp_window_scaling must be enabled (default).

max
the maximum size of the receive buffer used by each TCP socket. This value does not override the global net.core.rmem_max. This is not used to limit the size of the receive buffer declared using SO_RCVBUF on a socket. The default value is calculated using the formula

max(87380, min(4 MB, tcp_mem[1]*PAGE_SIZE/128))

(On Linux 2.4, the default is 87380*2 bytes, lowered to 87380 in low-memory systems).

tcp_sack (Boolean; default: enabled; since Linux 2.2)
Enable RFC 2018 TCP Selective Acknowledgements.

tcp_slow_start_after_idle (Boolean; default: enabled; since Linux 2.6.18)
If enabled, provide RFC 2861 behavior and time out the congestion window after an idle period. An idle period is defined as the current RTO (retransmission timeout). If disabled, the congestion window will not be timed out after an idle period.

tcp_stdurg (Boolean; default: disabled; since Linux 2.2)
If this option is enabled, then use the RFC 1122 interpretation of the TCP urgent-pointer field. According to this interpretation, the urgent pointer points to the last byte of urgent data. If this option is disabled, then use the BSD-compatible interpretation of the urgent pointer: the urgent pointer points to the first byte after the urgent data. Enabling this option may lead to interoperability problems.

tcp_syn_retries (integer; default: 6; since Linux 2.2)
The maximum number of times initial SYNs for an active TCP connection attempt will be retransmitted. This value should not be higher than 255. The default value is 6, which corresponds to retrying for up to approximately 127 seconds. Before Linux 3.7, the default value was 5, which (in conjunction with calculation based on other kernel parameters) corresponded to approximately 180 seconds.

tcp_synack_retries (integer; default: 5; since Linux 2.2)
The maximum number of times a SYN/ACK segment for a passive TCP connection will be retransmitted. This number should not be higher than 255.

tcp_syncookies (integer; default: 1; since Linux 2.2)
Enable TCP syncookies. The kernel must be compiled with CONFIG_SYN_COOKIES. The syncookies feature attempts to protect a socket from a SYN flood attack. This should be used as a last resort, if at all. This is a violation of the TCP protocol, and conflicts with other areas of TCP such as TCP extensions. It can cause problems for clients and relays. It is not recommended as a tuning mechanism for heavily loaded servers to help with overloaded or misconfigured conditions. For recommended alternatives see tcp_max_syn_backlog, tcp_synack_retries, and tcp_abort_on_overflow. Set to one of the following values:

0
Disable TCP syncookies.

1
Send out syncookies when the syn backlog queue of a socket overflows.

2
(since Linux 3.12) Send out syncookies unconditionally. This can be useful for network testing.

tcp_timestamps (integer; default: 1; since Linux 2.2)
Set to one of the following values to enable or disable RFC 1323 TCP timestamps:

0
Disable timestamps.

1
Enable timestamps as defined in RFC1323 and use random offset for each connection rather than only using the current time.

2
As for the value 1, but without random offsets. Setting tcp_timestamps to this value is meaningful since Linux 4.10.

tcp_tso_win_divisor (integer; default: 3; since Linux 2.6.9)
This parameter controls what percentage of the congestion window can be consumed by a single TCP Segmentation Offload (TSO) frame. The setting of this parameter is a tradeoff between burstiness and building larger TSO frames.

tcp_tw_recycle (Boolean; default: disabled; Linux 2.4 to Linux 4.11)
Enable fast recycling of TIME_WAIT sockets. Enabling this option is not recommended as the remote IP may not use monotonically increasing timestamps (devices behind NAT, devices with per-connection timestamp offsets). See RFC 1323 (PAWS) and RFC 6191.

tcp_tw_reuse (Boolean; default: disabled; since Linux 2.4.19/2.6)
Allow to reuse TIME_WAIT sockets for new connections when it is safe from protocol viewpoint. It should not be changed without advice/request of technical experts.

tcp_vegas_cong_avoid (Boolean; default: disabled; Linux 2.2 to Linux 2.6.13)
Enable TCP Vegas congestion avoidance algorithm. TCP Vegas is a sender-side-only change to TCP that anticipates the onset of congestion by estimating the bandwidth. TCP Vegas adjusts the sending rate by modifying the congestion window. TCP Vegas should provide less packet loss, but it is not as aggressive as TCP Reno.

tcp_westwood (Boolean; default: disabled; Linux 2.4.26/2.6.3 to Linux 2.6.13)
Enable TCP Westwood+ congestion control algorithm. TCP Westwood+ is a sender-side-only modification of the TCP Reno protocol stack that optimizes the performance of TCP congestion control. It is based on end-to-end bandwidth estimation to set congestion window and slow start threshold after a congestion episode. Using this estimation, TCP Westwood+ adaptively sets a slow start threshold and a congestion window which takes into account the bandwidth used at the time congestion is experienced. TCP Westwood+ significantly increases fairness with respect to TCP Reno in wired networks and throughput over wireless links.

tcp_window_scaling (Boolean; default: enabled; since Linux 2.2)
Enable RFC 1323 TCP window scaling. This feature allows the use of a large window (> 64 kB) on a TCP connection, should the other end support it. Normally, the 16 bit window length field in the TCP header limits the window size to less than 64 kB. If larger windows are desired, applications can increase the size of their socket buffers and the window scaling option will be employed. If tcp_window_scaling is disabled, TCP will not negotiate the use of window scaling with the other end during connection setup.

tcp_wmem (since Linux 2.4)
This is a vector of 3 integers: [min, default, max]. These parameters are used by TCP to regulate send buffer sizes. TCP dynamically adjusts the size of the send buffer from the default values listed below, in the range of these values, depending on memory available.

min
Minimum size of the send buffer used by each TCP socket. The default value is the system page size. (On Linux 2.4, the default value is 4 kB.) This value is used to ensure that in memory pressure mode, allocations below this size will still succeed. This is not used to bound the size of the send buffer declared using SO_SNDBUF on a socket.

default
The default size of the send buffer for a TCP socket. This value overwrites the initial default buffer size from the generic global /proc/sys/net/core/wmem_default defined for all protocols. The default value is 16 kB. If larger send buffer sizes are desired, this value should be increased (to affect all sockets). To employ large TCP windows, the /proc/sys/net/ipv4/tcp_window_scaling must be set to a nonzero value (default).

max
The maximum size of the send buffer used by each TCP socket. This value does not override the value in /proc/sys/net/core/wmem_max. This is not used to limit the size of the send buffer declared using SO_SNDBUF on a socket. The default value is calculated using the formula

max(65536, min(4 MB, tcp_mem[1]*PAGE_SIZE/128))

(On Linux 2.4, the default value is 128 kB, lowered 64 kB depending on low-memory systems.)

tcp_workaround_signed_windows (Boolean; default: disabled; since Linux 2.6.26)
If enabled, assume that no receipt of a window-scaling option means that the remote TCP is broken and treats the window as a signed quantity. If disabled, assume that the remote TCP is not broken even if we do not receive a window scaling option from it.

Socket options

To set or get a TCP socket option, call getsockopt(2) to read or setsockopt(2) to write the option with the option level argument set to IPPROTO_TCP. Unless otherwise noted, optval is a pointer to an int. In addition, most IPPROTO_IP socket options are valid on TCP sockets. For more information see ip(7).

Following is a list of TCP-specific socket options. For details of some other socket options that are also applicable for TCP sockets, see socket(7).

TCP_CONGESTION (since Linux 2.6.13)
The argument for this option is a string. This option allows the caller to set the TCP congestion control algorithm to be used, on a per-socket basis. Unprivileged processes are restricted to choosing one of the algorithms in tcp_allowed_congestion_control (described above). Privileged processes (CAP_NET_ADMIN) can choose from any of the available congestion-control algorithms (see the description of tcp_available_congestion_control above).

TCP_CORK (since Linux 2.2)
If set, don’t send out partial frames. All queued partial frames are sent when the option is cleared again. This is useful for prepending headers before calling sendfile(2), or for throughput optimization. As currently implemented, there is a 200 millisecond ceiling on the time for which output is corked by TCP_CORK. If this ceiling is reached, then queued data is automatically transmitted. This option can be combined with TCP_NODELAY only since Linux 2.5.71. This option should not be used in code intended to be portable.

TCP_DEFER_ACCEPT (since Linux 2.4)
Allow a listener to be awakened only when data arrives on the socket. Takes an integer value (seconds), this can bound the maximum number of attempts TCP will make to complete the connection. This option should not be used in code intended to be portable.

TCP_INFO (since Linux 2.4)
Used to collect information about this socket. The kernel returns a struct tcp_info as defined in the file /usr/include/linux/tcp.h. This option should not be used in code intended to be portable.

TCP_KEEPCNT (since Linux 2.4)
The maximum number of keepalive probes TCP should send before dropping the connection. This option should not be used in code intended to be portable.

TCP_KEEPIDLE (since Linux 2.4)
The time (in seconds) the connection needs to remain idle before TCP starts sending keepalive probes, if the socket option SO_KEEPALIVE has been set on this socket. This option should not be used in code intended to be portable.

TCP_KEEPINTVL (since Linux 2.4)
The time (in seconds) between individual keepalive probes. This option should not be used in code intended to be portable.

TCP_LINGER2 (since Linux 2.4)
The lifetime of orphaned FIN_WAIT2 state sockets. This option can be used to override the system-wide setting in the file /proc/sys/net/ipv4/tcp_fin_timeout for this socket. This is not to be confused with the socket(7) level option SO_LINGER. This option should not be used in code intended to be portable.

TCP_MAXSEG
The maximum segment size for outgoing TCP packets. In Linux 2.2 and earlier, and in Linux 2.6.28 and later, if this option is set before connection establishment, it also changes the MSS value announced to the other end in the initial packet. Values greater than the (eventual) interface MTU have no effect. TCP will also impose its minimum and maximum bounds over the value provided.

TCP_NODELAY
If set, disable the Nagle algorithm. This means that segments are always sent as soon as possible, even if there is only a small amount of data. When not set, data is buffered until there is a sufficient amount to send out, thereby avoiding the frequent sending of small packets, which results in poor utilization of the network. This option is overridden by TCP_CORK; however, setting this option forces an explicit flush of pending output, even if TCP_CORK is currently set.

TCP_QUICKACK (since Linux 2.4.4)
Enable quickack mode if set or disable quickack mode if cleared. In quickack mode, acks are sent immediately, rather than delayed if needed in accordance to normal TCP operation. This flag is not permanent, it only enables a switch to or from quickack mode. Subsequent operation of the TCP protocol will once again enter/leave quickack mode depending on internal protocol processing and factors such as delayed ack timeouts occurring and data transfer. This option should not be used in code intended to be portable.

TCP_SYNCNT (since Linux 2.4)
Set the number of SYN retransmits that TCP should send before aborting the attempt to connect. It cannot exceed 255. This option should not be used in code intended to be portable.

TCP_USER_TIMEOUT (since Linux 2.6.37)
This option takes an unsigned int as an argument. When the value is greater than 0, it specifies the maximum amount of time in milliseconds that transmitted data may remain unacknowledged, or buffered data may remain untransmitted (due to zero window size) before TCP will forcibly close the corresponding connection and return ETIMEDOUT to the application. If the option value is specified as 0, TCP will use the system default.

Increasing user timeouts allows a TCP connection to survive extended periods without end-to-end connectivity. Decreasing user timeouts allows applications to “fail fast”, if so desired. Otherwise, failure may take up to 20 minutes with the current system defaults in a normal WAN environment.

This option can be set during any state of a TCP connection, but is effective only during the synchronized states of a connection (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, and LAST-ACK). Moreover, when used with the TCP keepalive (SO_KEEPALIVE) option, TCP_USER_TIMEOUT will override keepalive to determine when to close a connection due to keepalive failure.

The option has no effect on when TCP retransmits a packet, nor when a keepalive probe is sent.

This option, like many others, will be inherited by the socket returned by accept(2), if it was set on the listening socket.

Further details on the user timeout feature can be found in RFC 793 and RFC 5482 (“TCP User Timeout Option”).

TCP_WINDOW_CLAMP (since Linux 2.4)
Bound the size of the advertised window to this value. The kernel imposes a minimum size of SOCK_MIN_RCVBUF/2. This option should not be used in code intended to be portable.

TCP_FASTOPEN (since Linux 3.6)
This option enables Fast Open (RFC 7413) on the listener socket. The value specifies the maximum length of pending SYNs (similar to the backlog argument in listen(2)). Once enabled, the listener socket grants the TCP Fast Open cookie on incoming SYN with TCP Fast Open option.

More importantly it accepts the data in SYN with a valid Fast Open cookie and responds SYN-ACK acknowledging both the data and the SYN sequence. accept(2) returns a socket that is available for read and write when the handshake has not completed yet. Thus the data exchange can commence before the handshake completes. This option requires enabling the server-side support on sysctl net.ipv4.tcp_fastopen (see above). For TCP Fast Open client-side support, see send(2) MSG_FASTOPEN or TCP_FASTOPEN_CONNECT below.

TCP_FASTOPEN_CONNECT (since Linux 4.11)
This option enables an alternative way to perform Fast Open on the active side (client). When this option is enabled, connect(2) would behave differently depending on if a Fast Open cookie is available for the destination.

If a cookie is not available (i.e. first contact to the destination), connect(2) behaves as usual by sending a SYN immediately, except the SYN would include an empty Fast Open cookie option to solicit a cookie.

If a cookie is available, connect(2) would return 0 immediately but the SYN transmission is deferred. A subsequent write(2) or sendmsg(2) would trigger a SYN with data plus cookie in the Fast Open option. In other words, the actual connect operation is deferred until data is supplied.

Note: While this option is designed for convenience, enabling it does change the behaviors and certain system calls might set different errno values. With cookie present, write(2) or sendmsg(2) must be called right after connect(2) in order to send out SYN+data to complete 3WHS and establish connection. Calling read(2) right after connect(2) without write(2) will cause the blocking socket to be blocked forever.

The application should either set TCP_FASTOPEN_CONNECT socket option before write(2) or sendmsg(2), or call write(2) or sendmsg(2) with MSG_FASTOPEN flag directly, instead of both on the same connection.

Here is the typical call flow with this new option:

s = socket();
setsockopt(s, IPPROTO_TCP, TCP_FASTOPEN_CONNECT, 1, ...);
connect(s);
write(s); /* write() should always follow connect()
           * in order to trigger SYN to go out. */
read(s)/write(s);
/* ... */
close(s);

Sockets API

TCP provides limited support for out-of-band data, in the form of (a single byte of) urgent data. In Linux this means if the other end sends newer out-of-band data the older urgent data is inserted as normal data into the stream (even when SO_OOBINLINE is not set). This differs from BSD-based stacks.

Linux uses the BSD compatible interpretation of the urgent pointer field by default. This violates RFC 1122, but is required for interoperability with other stacks. It can be changed via /proc/sys/net/ipv4/tcp_stdurg.

It is possible to peek at out-of-band data using the recv(2) MSG_PEEK flag.

Since Linux 2.4, Linux supports the use of MSG_TRUNC in the flags argument of recv(2) (and recvmsg(2)). This flag causes the received bytes of data to be discarded, rather than passed back in a caller-supplied buffer. Since Linux 2.4.4, MSG_TRUNC also has this effect when used in conjunction with MSG_OOB to receive out-of-band data.

Ioctls

The following ioctl(2) calls return information in value. The correct syntax is:

int value; error = ioctl(tcp_socket, ioctl_type, &value);

ioctl_type is one of the following:

SIOCINQ
Returns the amount of queued unread data in the receive buffer. The socket must not be in LISTEN state, otherwise an error (EINVAL) is returned. SIOCINQ is defined in <linux/sockios.h>. Alternatively, you can use the synonymous FIONREAD, defined in <sys/ioctl.h>.

SIOCATMARK
Returns true (i.e., value is nonzero) if the inbound data stream is at the urgent mark.

If the SO_OOBINLINE socket option is set, and SIOCATMARK returns true, then the next read from the socket will return the urgent data. If the SO_OOBINLINE socket option is not set, and SIOCATMARK returns true, then the next read from the socket will return the bytes following the urgent data (to actually read the urgent data requires the recv(MSG_OOB) flag).

Note that a read never reads across the urgent mark. If an application is informed of the presence of urgent data via select(2) (using the exceptfds argument) or through delivery of a SIGURG signal, then it can advance up to the mark using a loop which repeatedly tests SIOCATMARK and performs a read (requesting any number of bytes) as long as SIOCATMARK returns false.

SIOCOUTQ
Returns the amount of unsent data in the socket send queue. The socket must not be in LISTEN state, otherwise an error (EINVAL) is returned. SIOCOUTQ is defined in <linux/sockios.h>. Alternatively, you can use the synonymous TIOCOUTQ, defined in <sys/ioctl.h>.

Error handling

When a network error occurs, TCP tries to resend the packet. If it doesn’t succeed after some time, either ETIMEDOUT or the last received error on this connection is reported.

Some applications require a quicker error notification. This can be enabled with the IPPROTO_IP level IP_RECVERR socket option. When this option is enabled, all incoming errors are immediately passed to the user program. Use this option with care — it makes TCP less tolerant to routing changes and other normal network conditions.

ERRORS

EAFNOTSUPPORT
Passed socket address type in sin_family was not AF_INET.

EPIPE
The other end closed the socket unexpectedly or a read is executed on a shut down socket.

ETIMEDOUT
The other end didn’t acknowledge retransmitted data after some time.

Any errors defined for ip(7) or the generic socket layer may also be returned for TCP.

VERSIONS

Support for Explicit Congestion Notification, zero-copy sendfile(2), reordering support and some SACK extensions (DSACK) were introduced in Linux 2.4. Support for forward acknowledgement (FACK), TIME_WAIT recycling, and per-connection keepalive socket options were introduced in Linux 2.3.

BUGS

Not all errors are documented.

IPv6 is not described.

SEE ALSO

accept(2), bind(2), connect(2), getsockopt(2), listen(2), recvmsg(2), sendfile(2), sendmsg(2), socket(2), ip(7), socket(7)

The kernel source file Documentation/networking/ip-sysctl.txt.

RFC 793 for the TCP specification.
RFC 1122 for the TCP requirements and a description of the Nagle algorithm.
RFC 1323 for TCP timestamp and window scaling options.
RFC 1337 for a description of TIME_WAIT assassination hazards.
RFC 3168 for a description of Explicit Congestion Notification.
RFC 2581 for TCP congestion control algorithms.
RFC 2018 and RFC 2883 for SACK and extensions to SACK.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

80 - Linux cli command EVP_SIGNATURE-DSAssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_SIGNATURE-DSAssl and provides detailed information about the command EVP_SIGNATURE-DSAssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_SIGNATURE-DSAssl.

NAME 🖥️ EVP_SIGNATURE-DSAssl 🖥️

DSA - The EVP_PKEY DSA signature implementation

DESCRIPTION

Support for computing DSA signatures. See EVP_PKEY-DSA (7) for information related to DSA keys.

Signature Parameters

The following signature parameters can be set using EVP_PKEY_CTX_set_params(). This may be called after EVP_PKEY_sign_init() or EVP_PKEY_verify_init(), and before calling EVP_PKEY_sign() or EVP_PKEY_verify().

“digest” (OSSL_SIGNATURE_PARAM_DIGEST) <UTF8 string>

“properties” (OSSL_SIGNATURE_PARAM_PROPERTIES) <UTF8 string>

“nonce-type” (OSSL_SIGNATURE_PARAM_NONCE_TYPE) <unsigned integer>

The settable parameters are described in provider-signature (7).

The following signature parameters can be retrieved using EVP_PKEY_CTX_get_params().

“algorithm-id” (OSSL_SIGNATURE_PARAM_ALGORITHM_ID) <octet string>

“digest” (OSSL_SIGNATURE_PARAM_DIGEST) <UTF8 string>

“nonce-type” (OSSL_SIGNATURE_PARAM_NONCE_TYPE) <unsigned integer>

The gettable parameters are described in provider-signature (7).

SEE ALSO

EVP_PKEY_CTX_set_params (3), EVP_PKEY_sign (3), EVP_PKEY_verify (3), provider-signature (7),

COPYRIGHT

Copyright 2020-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

81 - Linux cli command bpf-helpers

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command bpf-helpers and provides detailed information about the command bpf-helpers, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the bpf-helpers.

NAME 🖥️ bpf-helpers 🖥️

HELPERS - list of eBPF helper functions

DESCRIPTION

The extended Berkeley Packet Filter (eBPF) subsystem consists in programs written in a pseudo-assembly language, then attached to one of the several kernel hooks and run in reaction of specific events. This framework differs from the older, “classic” BPF (or “cBPF”) in several aspects, one of them being the ability to call special functions (or “helpers”) from within a program. These functions are restricted to a white-list of helpers defined in the kernel.

These helpers are used by eBPF programs to interact with the system, or with the context in which they work. For instance, they can be used to print debugging messages, to get the time since the system was booted, to interact with eBPF maps, or to manipulate network packets. Since there are several eBPF program types, and that they do not run in the same context, each program type can only call a subset of those helpers.

Due to eBPF conventions, a helper can not have more than five arguments.

Internally, eBPF programs call directly into the compiled helper functions without requiring any foreign-function interface. As a result, calling helpers introduces no overhead, thus offering excellent performance.

This document is an attempt to list and document the helpers available to eBPF developers. They are sorted by chronological order (the oldest helpers in the kernel at the top).

HELPERS

void *bpf_map_lookup_elem(struct bpf_map *map,** const void *key**)****

Description
Perform a lookup in map for an entry associated to key.

Return
Map value associated to key, or NULL if no entry was found.

long bpf_map_update_elem(struct bpf_map *map,** const void *key**,** const void *value**,** u64 flags**)****

Description
Add or update the value of the entry associated to key in map with value. flags is one of:

BPF_NOEXIST
The entry for key must not exist in the map.

BPF_EXIST
The entry for key must already exist in the map.

BPF_ANY
No condition on the existence of the entry for key.

Flag value BPF_NOEXIST cannot be used for maps of types BPF_MAP_TYPE_ARRAY or BPF_MAP_TYPE_PERCPU_ARRAY (all elements always exist), the helper would return an error.

Return
0 on success, or a negative error in case of failure.

long bpf_map_delete_elem(struct bpf_map *map,** const void *key**)****

Description
Delete entry with key from map.

Return
0 on success, or a negative error in case of failure.

long bpf_probe_read(void *dst,** u32 size**,** const void *unsafe_ptr**)****

Description
For tracing programs, safely attempt to read size bytes from kernel space address unsafe_ptr and store the data in dst.

Generally, use bpf_probe_read_user() or bpf_probe_read_kernel() instead.

Return
0 on success, or a negative error in case of failure.

u64 bpf_ktime_get_ns(void)

Description
Return the time elapsed since system boot, in nanoseconds. Does not include time the system was suspended. See: clock_gettime(CLOCK_MONOTONIC)

Return
Current ktime.

long bpf_trace_printk(const char *fmt,** u32 fmt_size**,** …)**

Description
This helper is a “printk()-like” facility for debugging. It prints a message defined by format fmt (of size fmt_size) to file /sys/kernel/tracing/trace from TraceFS, if available. It can take up to three additional u64 arguments (as an eBPF helpers, the total number of arguments is limited to five).

Each time the helper is called, it appends a line to the trace. Lines are discarded while /sys/kernel/tracing/trace is open, use /sys/kernel/tracing/trace_pipe to avoid this. The format of the trace is customizable, and the exact output one will get depends on the options set in /sys/kernel/tracing/trace_options (see also the README file under the same directory). However, it usually defaults to something like:

telnet-470 [001] .N.. 419421.045894: 0x00000001:

In the above:

  • telnet is the name of the current task.

  • 470 is the PID of the current task.

  • 001 is the CPU number on which the task is running.

  • In .N.., each character refers to a set of options (whether irqs are enabled, scheduling options, whether hard/softirqs are running, level of preempt_disabled respectively). N means that TIF_NEED_RESCHED and PREEMPT_NEED_RESCHED are set.

  • 419421.045894 is a timestamp.

  • 0x00000001 is a fake value used by BPF for the instruction pointer register.

  • <formatted msg> is the message formatted with fmt.

The conversion specifiers supported by fmt are similar, but more limited than for printk(). They are %d, %i, %u, %x, %ld, %li, %lu, %lx, %lld, %lli, %llu, %llx, %p, %s. No modifier (size of field, padding with zeroes, etc.) is available, and the helper will return -EINVAL (but print nothing) if it encounters an unknown specifier.

Also, note that bpf_trace_printk() is slow, and should only be used for debugging purposes. For this reason, a notice block (spanning several lines) is printed to kernel logs and states that the helper should not be used “for production use” the first time this helper is used (or more precisely, when trace_printk() buffers are allocated). For passing values to user space, perf events should be preferred.

Return
The number of bytes written to the buffer, or a negative error in case of failure.

u32 bpf_get_prandom_u32(void)

Description
Get a pseudo-random number.

From a security point of view, this helper uses its own pseudo-random internal state, and cannot be used to infer the seed of other random functions in the kernel. However, it is essential to note that the generator used by the helper is not cryptographically secure.

Return
A random 32-bit unsigned value.

u32 bpf_get_smp_processor_id(void)

Description
Get the SMP (symmetric multiprocessing) processor id. Note that all programs run with migration disabled, which means that the SMP processor id is stable during all the execution of the program.

Return
The SMP id of the processor running the program.

long bpf_skb_store_bytes(struct sk_buff *skb,** u32 offset**,** const void *from**,** u32 len**,** u64 flags**)****

Description
Store len bytes from address from into the packet associated to skb, at offset. flags are a combination of BPF_F_RECOMPUTE_CSUM (automatically recompute the checksum for the packet after storing the bytes) and BPF_F_INVALIDATE_HASH (set skb**->hash**, skb**->swhash** and skb**->l4hash** to 0).

A call to this helper is susceptible to change the underlying packet buffer. Therefore, at load time, all checks on pointers previously done by the verifier are invalidated and must be performed again, if the helper is used in combination with direct packet access.

Return
0 on success, or a negative error in case of failure.

long bpf_l3_csum_replace(struct sk_buff *skb,** u32 offset**,** u64 from**,** u64 to**,** u64 size**)****

Description
Recompute the layer 3 (e.g. IP) checksum for the packet associated to skb. Computation is incremental, so the helper must know the former value of the header field that was modified (from), the new value of this field (to), and the number of bytes (2 or 4) for this field, stored in size. Alternatively, it is possible to store the difference between the previous and the new values of the header field in to, by setting from and size to 0. For both methods, offset indicates the location of the IP checksum within the packet.

This helper works in combination with bpf_csum_diff(), which does not update the checksum in-place, but offers more flexibility and can handle sizes larger than 2 or 4 for the checksum to update.

A call to this helper is susceptible to change the underlying packet buffer. Therefore, at load time, all checks on pointers previously done by the verifier are invalidated and must be performed again, if the helper is used in combination with direct packet access.

Return
0 on success, or a negative error in case of failure.

long bpf_l4_csum_replace(struct sk_buff *skb,** u32 offset**,** u64 from**,** u64 to**,** u64 flags**)****

Description
Recompute the layer 4 (e.g. TCP, UDP or ICMP) checksum for the packet associated to skb. Computation is incremental, so the helper must know the former value of the header field that was modified (from), the new value of this field (to), and the number of bytes (2 or 4) for this field, stored on the lowest four bits of flags. Alternatively, it is possible to store the difference between the previous and the new values of the header field in to, by setting from and the four lowest bits of flags to 0. For both methods, offset indicates the location of the IP checksum within the packet. In addition to the size of the field, flags can be added (bitwise OR) actual flags. With BPF_F_MARK_MANGLED_0, a null checksum is left untouched (unless BPF_F_MARK_ENFORCE is added as well), and for updates resulting in a null checksum the value is set to CSUM_MANGLED_0 instead. Flag BPF_F_PSEUDO_HDR indicates the checksum is to be computed against a pseudo-header.

This helper works in combination with bpf_csum_diff(), which does not update the checksum in-place, but offers more flexibility and can handle sizes larger than 2 or 4 for the checksum to update.

A call to this helper is susceptible to change the underlying packet buffer. Therefore, at load time, all checks on pointers previously done by the verifier are invalidated and must be performed again, if the helper is used in combination with direct packet access.

Return
0 on success, or a negative error in case of failure.

long bpf_tail_call(void *ctx,** struct bpf_map *prog_array_map**,** u32 index**)****

Description
This special helper is used to trigger a “tail call”, or in other words, to jump into another eBPF program. The same stack frame is used (but values on stack and in registers for the caller are not accessible to the callee). This mechanism allows for program chaining, either for raising the maximum number of available eBPF instructions, or to execute given programs in conditional blocks. For security reasons, there is an upper limit to the number of successive tail calls that can be performed.

Upon call of this helper, the program attempts to jump into a program referenced at index index in prog_array_map, a special map of type BPF_MAP_TYPE_PROG_ARRAY, and passes ctx, a pointer to the context.

If the call succeeds, the kernel immediately runs the first instruction of the new program. This is not a function call, and it never returns to the previous program. If the call fails, then the helper has no effect, and the caller continues to run its subsequent instructions. A call can fail if the destination program for the jump does not exist (i.e. index is superior to the number of entries in prog_array_map), or if the maximum number of tail calls has been reached for this chain of programs. This limit is defined in the kernel by the macro MAX_TAIL_CALL_CNT (not accessible to user space), which is currently set to 33.

Return
0 on success, or a negative error in case of failure.

long bpf_clone_redirect(struct sk_buff *skb,** u32 ifindex**,** u64 flags**)****

Description
Clone and redirect the packet associated to skb to another net device of index ifindex. Both ingress and egress interfaces can be used for redirection. The BPF_F_INGRESS value in flags is used to make the distinction (ingress path is selected if the flag is present, egress path otherwise). This is the only flag supported for now.

In comparison with bpf_redirect() helper, bpf_clone_redirect() has the associated cost of duplicating the packet buffer, but this can be executed out of the eBPF program. Conversely, bpf_redirect() is more efficient, but it is handled through an action code where the redirection happens only after the eBPF program has returned.

A call to this helper is susceptible to change the underlying packet buffer. Therefore, at load time, all checks on pointers previously done by the verifier are invalidated and must be performed again, if the helper is used in combination with direct packet access.

Return
0 on success, or a negative error in case of failure. Positive error indicates a potential drop or congestion in the target device. The particular positive error codes are not defined.

u64 bpf_get_current_pid_tgid(void)

Description
Get the current pid and tgid.

Return
A 64-bit integer containing the current tgid and pid, and created as such: current_task**->tgid << 32 |** current_task**->pid**.

u64 bpf_get_current_uid_gid(void)

Description
Get the current uid and gid.

Return
A 64-bit integer containing the current GID and UID, and created as such: current_gid << 32 | current_uid.

long bpf_get_current_comm(void *buf,** u32 size_of_buf**)****

Description
Copy the comm attribute of the current task into buf of size_of_buf. The comm attribute contains the name of the executable (excluding the path) for the current task. The size_of_buf must be strictly positive. On success, the helper makes sure that the buf is NUL-terminated. On failure, it is filled with zeroes.

Return
0 on success, or a negative error in case of failure.

u32 bpf_get_cgroup_classid(struct sk_buff *skb)****

Description
Retrieve the classid for the current task, i.e. for the net_cls cgroup to which skb belongs.

This helper can be used on TC egress path, but not on ingress.

The net_cls cgroup provides an interface to tag network packets based on a user-provided identifier for all traffic coming from the tasks belonging to the related cgroup. See also the related kernel documentation, available from the Linux sources in file Documentation/admin-guide/cgroup-v1/net_cls.rst.

The Linux kernel has two versions for cgroups: there are cgroups v1 and cgroups v2. Both are available to users, who can use a mixture of them, but note that the net_cls cgroup is for cgroup v1 only. This makes it incompatible with BPF programs run on cgroups, which is a cgroup-v2-only feature (a socket can only hold data for one version of cgroups at a time).

This helper is only available is the kernel was compiled with the CONFIG_CGROUP_NET_CLASSID configuration option set to “y” or to “m”.

Return
The classid, or 0 for the default unconfigured classid.

long bpf_skb_vlan_push(struct sk_buff *skb,** __be16 vlan_proto**,** u16 vlan_tci**)****

Description
Push a vlan_tci (VLAN tag control information) of protocol vlan_proto to the packet associated to skb, then update the checksum. Note that if vlan_proto is different from ETH_P_8021Q and ETH_P_8021AD, it is considered to be ETH_P_8021Q.

A call to this helper is susceptible to change the underlying packet buffer. Therefore, at load time, all checks on pointers previously done by the verifier are invalidated and must be performed again, if the helper is used in combination with direct packet access.

Return
0 on success, or a negative error in case of failure.

long bpf_skb_vlan_pop(struct sk_buff *skb)****

Description
Pop a VLAN header from the packet associated to skb.

A call to this helper is susceptible to change the underlying packet buffer. Therefore, at load time, all checks on pointers previously done by the verifier are invalidated and must be performed again, if the helper is used in combination with direct packet access.

Return
0 on success, or a negative error in case of failure.

long bpf_skb_get_tunnel_key(struct sk_buff *skb,** struct bpf_tunnel_key *key**,** u32 size**,** u64 flags**)****

Description
Get tunnel metadata. This helper takes a pointer key to an empty struct bpf_tunnel_key of size, that will be filled with tunnel metadata for the packet associated to skb. The flags can be set to BPF_F_TUNINFO_IPV6, which indicates that the tunnel is based on IPv6 protocol instead of IPv4.

The struct bpf_tunnel_key is an object that generalizes the principal parameters used by various tunneling protocols into a single struct. This way, it can be used to easily make a decision based on the contents of the encapsulation header, “summarized” in this struct. In particular, it holds the IP address of the remote end (IPv4 or IPv6, depending on the case) in key**->remote_ipv4** or key**->remote_ipv6**. Also, this struct exposes the key**->tunnel_id**, which is generally mapped to a VNI (Virtual Network Identifier), making it programmable together with the bpf_skb_set_tunnel_key() helper.

Let’s imagine that the following code is part of a program attached to the TC ingress interface, on one end of a GRE tunnel, and is supposed to filter out all messages coming from remote ends with IPv4 address other than 10.0.0.1:

int ret; struct bpf_tunnel_key key = {};

ret = bpf_skb_get_tunnel_key(skb, &key, sizeof(key), 0);
if (ret < 0)
        return TC_ACT_SHOT;     // drop packet

if (key.remote_ipv4 != 0x0a000001)
        return TC_ACT_SHOT;     // drop packet

return TC_ACT_OK;               // accept packet

This interface can also be used with all encapsulation devices that can operate in “collect metadata” mode: instead of having one network device per specific configuration, the “collect metadata” mode only requires a single device where the configuration can be extracted from this helper.

This can be used together with various tunnels such as VXLan, Geneve, GRE or IP in IP (IPIP).

Return
0 on success, or a negative error in case of failure.

long bpf_skb_set_tunnel_key(struct sk_buff *skb,** struct bpf_tunnel_key *key**,** u32 size**,** u64 flags**)****

Description
Populate tunnel metadata for packet associated to skb. The tunnel metadata is set to the contents of key, of size. The flags can be set to a combination of the following values:

BPF_F_TUNINFO_IPV6
Indicate that the tunnel is based on IPv6 protocol instead of IPv4.

BPF_F_ZERO_CSUM_TX
For IPv4 packets, add a flag to tunnel metadata indicating that checksum computation should be skipped and checksum set to zeroes.

BPF_F_DONT_FRAGMENT
Add a flag to tunnel metadata indicating that the packet should not be fragmented.

BPF_F_SEQ_NUMBER
Add a flag to tunnel metadata indicating that a sequence number should be added to tunnel header before sending the packet. This flag was added for GRE encapsulation, but might be used with other protocols as well in the future.

BPF_F_NO_TUNNEL_KEY
Add a flag to tunnel metadata indicating that no tunnel key should be set in the resulting tunnel header.

Here is a typical usage on the transmit path:

struct bpf_tunnel_key key; populate key … bpf_skb_set_tunnel_key(skb, &key, sizeof(key), 0); bpf_clone_redirect(skb, vxlan_dev_ifindex, 0);

See also the description of the bpf_skb_get_tunnel_key() helper for additional information.

Return
0 on success, or a negative error in case of failure.

u64 bpf_perf_event_read(struct bpf_map *map,** u64 flags**)****

Description
Read the value of a perf event counter. This helper relies on a map of type BPF_MAP_TYPE_PERF_EVENT_ARRAY. The nature of the perf event counter is selected when map is updated with perf event file descriptors. The map is an array whose size is the number of available CPUs, and each cell contains a value relative to one CPU. The value to retrieve is indicated by flags, that contains the index of the CPU to look up, masked with BPF_F_INDEX_MASK. Alternatively, flags can be set to BPF_F_CURRENT_CPU to indicate that the value for the current CPU should be retrieved.

Note that before Linux 4.13, only hardware perf event can be retrieved.

Also, be aware that the newer helper bpf_perf_event_read_value() is recommended over bpf_perf_event_read() in general. The latter has some ABI quirks where error and counter value are used as a return code (which is wrong to do since ranges may overlap). This issue is fixed with bpf_perf_event_read_value(), which at the same time provides more features over the bpf_perf_event_read() interface. Please refer to the description of bpf_perf_event_read_value() for details.

Return
The value of the perf event counter read from the map, or a negative error code in case of failure.

long bpf_redirect(u32 ifindex,** u64 flags**)****

Description
Redirect the packet to another net device of index ifindex. This helper is somewhat similar to bpf_clone_redirect(), except that the packet is not cloned, which provides increased performance.

Except for XDP, both ingress and egress interfaces can be used for redirection. The BPF_F_INGRESS value in flags is used to make the distinction (ingress path is selected if the flag is present, egress path otherwise). Currently, XDP only supports redirection to the egress interface, and accepts no flag at all.

The same effect can also be attained with the more generic bpf_redirect_map(), which uses a BPF map to store the redirect target instead of providing it directly to the helper.

Return
For XDP, the helper returns XDP_REDIRECT on success or XDP_ABORTED on error. For other program types, the values are TC_ACT_REDIRECT on success or TC_ACT_SHOT on error.

u32 bpf_get_route_realm(struct sk_buff *skb)****

Description
Retrieve the realm or the route, that is to say the tclassid field of the destination for the skb. The identifier retrieved is a user-provided tag, similar to the one used with the net_cls cgroup (see description for bpf_get_cgroup_classid() helper), but here this tag is held by a route (a destination entry), not by a task.

Retrieving this identifier works with the clsact TC egress hook (see also tc-bpf(8)), or alternatively on conventional classful egress qdiscs, but not on TC ingress path. In case of clsact TC egress hook, this has the advantage that, internally, the destination entry has not been dropped yet in the transmit path. Therefore, the destination entry does not need to be artificially held via netif_keep_dst() for a classful qdisc until the skb is freed.

This helper is available only if the kernel was compiled with CONFIG_IP_ROUTE_CLASSID configuration option.

Return
The realm of the route for the packet associated to skb, or 0 if none was found.

long bpf_perf_event_output(void *ctx,** struct bpf_map *map**,** u64 flags**,** void *data**,** u64 size**)****

Description
Write raw data blob into a special BPF perf event held by map of type BPF_MAP_TYPE_PERF_EVENT_ARRAY. This perf event must have the following attributes: PERF_SAMPLE_RAW as sample_type, PERF_TYPE_SOFTWARE as type, and PERF_COUNT_SW_BPF_OUTPUT as config.

The flags are used to indicate the index in map for which the value must be put, masked with BPF_F_INDEX_MASK. Alternatively, flags can be set to BPF_F_CURRENT_CPU to indicate that the index of the current CPU core should be used.

The value to write, of size, is passed through eBPF stack and pointed by data.

The context of the program ctx needs also be passed to the helper.

On user space, a program willing to read the values needs to call perf_event_open() on the perf event (either for one or for all CPUs) and to store the file descriptor into the map. This must be done before the eBPF program can send data into it. An example is available in file samples/bpf/trace_output_user.c in the Linux kernel source tree (the eBPF program counterpart is in samples/bpf/trace_output_kern.c).

bpf_perf_event_output() achieves better performance than bpf_trace_printk() for sharing data with user space, and is much better suitable for streaming data from eBPF programs.

Note that this helper is not restricted to tracing use cases and can be used with programs attached to TC or XDP as well, where it allows for passing data to user space listeners. Data can be:

  • Only custom structs,

  • Only the packet payload, or

  • A combination of both.

Return
0 on success, or a negative error in case of failure.

long bpf_skb_load_bytes(const void *skb,** u32 offset**,** void *to**,** u32 len**)****

Description
This helper was provided as an easy way to load data from a packet. It can be used to load len bytes from offset from the packet associated to skb, into the buffer pointed by to.

Since Linux 4.7, usage of this helper has mostly been replaced by “direct packet access”, enabling packet data to be manipulated with skb**->data** and skb**->data_end** pointing respectively to the first byte of packet data and to the byte after the last byte of packet data. However, it remains useful if one wishes to read large quantities of data at once from a packet into the eBPF stack.

Return
0 on success, or a negative error in case of failure.

long bpf_get_stackid(void *ctx,** struct bpf_map *map**,** u64 flags**)****

Description
Walk a user or a kernel stack and return its id. To achieve this, the helper needs ctx, which is a pointer to the context on which the tracing program is executed, and a pointer to a map of type BPF_MAP_TYPE_STACK_TRACE.

The last argument, flags, holds the number of stack frames to skip (from 0 to 255), masked with BPF_F_SKIP_FIELD_MASK. The next bits can be used to set a combination of the following flags:

BPF_F_USER_STACK
Collect a user space stack instead of a kernel stack.

BPF_F_FAST_STACK_CMP
Compare stacks by hash only.

BPF_F_REUSE_STACKID
If two different stacks hash into the same stackid, discard the old one.

The stack id retrieved is a 32 bit long integer handle which can be further combined with other data (including other stack ids) and used as a key into maps. This can be useful for generating a variety of graphs (such as flame graphs or off-cpu graphs).

For walking a stack, this helper is an improvement over bpf_probe_read(), which can be used with unrolled loops but is not efficient and consumes a lot of eBPF instructions. Instead, bpf_get_stackid() can collect up to PERF_MAX_STACK_DEPTH both kernel and user frames. Note that this limit can be controlled with the sysctl program, and that it should be manually increased in order to profile long user stacks (such as stacks for Java programs). To do so, use:

sysctl kernel.perf_event_max_stack=

Return
The positive or null stack id on success, or a negative error in case of failure.

s64 bpf_csum_diff(__be32 *from,** u32 from_size**,** __be32 *to**,** u32 to_size**,** __wsum seed**)****

Description
Compute a checksum difference, from the raw buffer pointed by from, of length from_size (that must be a multiple of 4), towards the raw buffer pointed by to, of size to_size (same remark). An optional seed can be added to the value (this can be cascaded, the seed may come from a previous call to the helper).

This is flexible enough to be used in several ways:

  • With from_size == 0, to_size > 0 and seed set to checksum, it can be used when pushing new data.

  • With from_size > 0, to_size == 0 and seed set to checksum, it can be used when removing data from a packet.

  • With from_size > 0, to_size > 0 and seed set to 0, it can be used to compute a diff. Note that from_size and to_size do not need to be equal.

This helper can be used in combination with bpf_l3_csum_replace() and bpf_l4_csum_replace(), to which one can feed in the difference computed with bpf_csum_diff().

Return
The checksum result, or a negative error code in case of failure.

long bpf_skb_get_tunnel_opt(struct sk_buff *skb,** void *opt**,** u32 size**)****

Description
Retrieve tunnel options metadata for the packet associated to skb, and store the raw tunnel option data to the buffer opt of size.

This helper can be used with encapsulation devices that can operate in “collect metadata” mode (please refer to the related note in the description of bpf_skb_get_tunnel_key() for more details). A particular example where this can be used is in combination with the Geneve encapsulation protocol, where it allows for pushing (with bpf_skb_get_tunnel_opt() helper) and retrieving arbitrary TLVs (Type-Length-Value headers) from the eBPF program. This allows for full customization of these headers.

Return
The size of the option data retrieved.

long bpf_skb_set_tunnel_opt(struct sk_buff *skb,** void *opt**,** u32 size**)****

Description
Set tunnel options metadata for the packet associated to skb to the option data contained in the raw buffer opt of size.

See also the description of the bpf_skb_get_tunnel_opt() helper for additional information.

Return
0 on success, or a negative error in case of failure.

long bpf_skb_change_proto(struct sk_buff *skb,** __be16 proto**,** u64 flags**)****

Description
Change the protocol of the skb to proto. Currently supported are transition from IPv4 to IPv6, and from IPv6 to IPv4. The helper takes care of the groundwork for the transition, including resizing the socket buffer. The eBPF program is expected to fill the new headers, if any, via skb_store_bytes() and to recompute the checksums with bpf_l3_csum_replace() and bpf_l4_csum_replace(). The main case for this helper is to perform NAT64 operations out of an eBPF program.

Internally, the GSO type is marked as dodgy so that headers are checked and segments are recalculated by the GSO/GRO engine. The size for GSO target is adapted as well.

All values for flags are reserved for future usage, and must be left at zero.

A call to this helper is susceptible to change the underlying packet buffer. Therefore, at load time, all checks on pointers previously done by the verifier are invalidated and must be performed again, if the helper is used in combination with direct packet access.

Return
0 on success, or a negative error in case of failure.

long bpf_skb_change_type(struct sk_buff *skb,** u32 type**)****

Description
Change the packet type for the packet associated to skb. This comes down to setting skb**->pkt_type** to type, except the eBPF program does not have a write access to skb**->pkt_type** beside this helper. Using a helper here allows for graceful handling of errors.

The major use case is to change incoming skb*s to **PACKET_HOST* in a programmatic way instead of having to recirculate via redirect(…, BPF_F_INGRESS), for example.

Note that type only allows certain values. At this time, they are:

PACKET_HOST
Packet is for us.

PACKET_BROADCAST
Send packet to all.

PACKET_MULTICAST
Send packet to group.

PACKET_OTHERHOST
Send packet to someone else.

Return
0 on success, or a negative error in case of failure.

long bpf_skb_under_cgroup(struct sk_buff *skb,** struct bpf_map *map**,** u32 index**)****

Description
Check whether skb is a descendant of the cgroup2 held by map of type BPF_MAP_TYPE_CGROUP_ARRAY, at index.

Return
The return value depends on the result of the test, and can be:

  • 0, if the skb failed the cgroup2 descendant test.

  • 1, if the skb succeeded the cgroup2 descendant test.

  • A negative error code, if an error occurred.

u32 bpf_get_hash_recalc(struct sk_buff *skb)****

Description
Retrieve the hash of the packet, skb**->hash**. If it is not set, in particular if the hash was cleared due to mangling, recompute this hash. Later accesses to the hash can be done directly with skb**->hash**.

Calling bpf_set_hash_invalid(), changing a packet prototype with bpf_skb_change_proto(), or calling bpf_skb_store_bytes() with the BPF_F_INVALIDATE_HASH are actions susceptible to clear the hash and to trigger a new computation for the next call to bpf_get_hash_recalc().

Return
The 32-bit hash.

u64 bpf_get_current_task(void)

Description
Get the current task.

Return
A pointer to the current task struct.

long bpf_probe_write_user(void *dst,** const void *src**,** u32 len**)****

Description
Attempt in a safe way to write len bytes from the buffer src to dst in memory. It only works for threads that are in user context, and dst must be a valid user space address.

This helper should not be used to implement any kind of security mechanism because of TOC-TOU attacks, but rather to debug, divert, and manipulate execution of semi-cooperative processes.

Keep in mind that this feature is meant for experiments, and it has a risk of crashing the system and running programs. Therefore, when an eBPF program using this helper is attached, a warning including PID and process name is printed to kernel logs.

Return
0 on success, or a negative error in case of failure.

long bpf_current_task_under_cgroup(struct bpf_map *map,** u32 index**)****

Description
Check whether the probe is being run is the context of a given subset of the cgroup2 hierarchy. The cgroup2 to test is held by map of type BPF_MAP_TYPE_CGROUP_ARRAY, at index.

Return
The return value depends on the result of the test, and can be:

  • 1, if current task belongs to the cgroup2.

  • 0, if current task does not belong to the cgroup2.

  • A negative error code, if an error occurred.

long bpf_skb_change_tail(struct sk_buff *skb,** u32 len**,** u64 flags**)****

Description
Resize (trim or grow) the packet associated to skb to the new len. The flags are reserved for future usage, and must be left at zero.

The basic idea is that the helper performs the needed work to change the size of the packet, then the eBPF program rewrites the rest via helpers like bpf_skb_store_bytes(), bpf_l3_csum_replace(), bpf_l3_csum_replace() and others. This helper is a slow path utility intended for replies with control messages. And because it is targeted for slow path, the helper itself can afford to be slow: it implicitly linearizes, unclones and drops offloads from the skb.

A call to this helper is susceptible to change the underlying packet buffer. Therefore, at load time, all checks on pointers previously done by the verifier are invalidated and must be performed again, if the helper is used in combination with direct packet access.

Return
0 on success, or a negative error in case of failure.

long bpf_skb_pull_data(struct sk_buff *skb,** u32 len**)****

Description
Pull in non-linear data in case the skb is non-linear and not all of len are part of the linear section. Make len bytes from skb readable and writable. If a zero value is passed for len, then all bytes in the linear part of skb will be made readable and writable.

This helper is only needed for reading and writing with direct packet access.

For direct packet access, testing that offsets to access are within packet boundaries (test on skb**->data_end**) is susceptible to fail if offsets are invalid, or if the requested data is in non-linear parts of the skb. On failure the program can just bail out, or in the case of a non-linear buffer, use a helper to make the data available. The bpf_skb_load_bytes() helper is a first solution to access the data. Another one consists in using bpf_skb_pull_data to pull in once the non-linear parts, then retesting and eventually access the data.

At the same time, this also makes sure the skb is uncloned, which is a necessary condition for direct write. As this needs to be an invariant for the write part only, the verifier detects writes and adds a prologue that is calling bpf_skb_pull_data() to effectively unclone the skb from the very beginning in case it is indeed cloned.

A call to this helper is susceptible to change the underlying packet buffer. Therefore, at load time, all checks on pointers previously done by the verifier are invalidated and must be performed again, if the helper is used in combination with direct packet access.

Return
0 on success, or a negative error in case of failure.

s64 bpf_csum_update(struct sk_buff *skb,** __wsum csum**)****

Description
Add the checksum csum into skb**->csum** in case the driver has supplied a checksum for the entire packet into that field. Return an error otherwise. This helper is intended to be used in combination with bpf_csum_diff(), in particular when the checksum needs to be updated after data has been written into the packet through direct packet access.

Return
The checksum on success, or a negative error code in case of failure.

void bpf_set_hash_invalid(struct sk_buff *skb)****

Description
Invalidate the current skb**->hash**. It can be used after mangling on headers through direct packet access, in order to indicate that the hash is outdated and to trigger a recalculation the next time the kernel tries to access this hash or when the bpf_get_hash_recalc() helper is called.

Return
void.

long bpf_get_numa_node_id(void)

Description
Return the id of the current NUMA node. The primary use case for this helper is the selection of sockets for the local NUMA node, when the program is attached to sockets using the SO_ATTACH_REUSEPORT_EBPF option (see also socket(7)), but the helper is also available to other eBPF program types, similarly to bpf_get_smp_processor_id().

Return
The id of current NUMA node.

long bpf_skb_change_head(struct sk_buff *skb,** u32 len**,** u64 flags**)****

Description
Grows headroom of packet associated to skb and adjusts the offset of the MAC header accordingly, adding len bytes of space. It automatically extends and reallocates memory as required.

This helper can be used on a layer 3 skb to push a MAC header for redirection into a layer 2 device.

All values for flags are reserved for future usage, and must be left at zero.

A call to this helper is susceptible to change the underlying packet buffer. Therefore, at load time, all checks on pointers previously done by the verifier are invalidated and must be performed again, if the helper is used in combination with direct packet access.

Return
0 on success, or a negative error in case of failure.

long bpf_xdp_adjust_head(struct xdp_buff *xdp_md,** int delta**)****

Description
Adjust (move) xdp_md**->data** by delta bytes. Note that it is possible to use a negative value for delta. This helper can be used to prepare the packet for pushing or popping headers.

A call to this helper is susceptible to change the underlying packet buffer. Therefore, at load time, all checks on pointers previously done by the verifier are invalidated and must be performed again, if the helper is used in combination with direct packet access.

Return
0 on success, or a negative error in case of failure.

long bpf_probe_read_str(void *dst,** u32 size**,** const void *unsafe_ptr**)****

Description
Copy a NUL terminated string from an unsafe kernel address unsafe_ptr to dst. See bpf_probe_read_kernel_str() for more details.

Generally, use bpf_probe_read_user_str() or bpf_probe_read_kernel_str() instead.

Return
On success, the strictly positive length of the string, including the trailing NUL character. On error, a negative value.

u64 bpf_get_socket_cookie(struct sk_buff *skb)****

Description
If the struct sk_buff pointed by skb has a known socket, retrieve the cookie (generated by the kernel) of this socket. If no cookie has been set yet, generate a new cookie. Once generated, the socket cookie remains stable for the life of the socket. This helper can be useful for monitoring per socket networking traffic statistics as it provides a global socket identifier that can be assumed unique.

Return
A 8-byte long unique number on success, or 0 if the socket field is missing inside skb.

u64 bpf_get_socket_cookie(struct bpf_sock_addr *ctx)****

Description
Equivalent to bpf_get_socket_cookie() helper that accepts skb, but gets socket from struct bpf_sock_addr context.

Return
A 8-byte long unique number.

u64 bpf_get_socket_cookie(struct bpf_sock_ops *ctx)****

Description
Equivalent to bpf_get_socket_cookie() helper that accepts skb, but gets socket from struct bpf_sock_ops context.

Return
A 8-byte long unique number.

u64 bpf_get_socket_cookie(struct sock *sk)****

Description
Equivalent to bpf_get_socket_cookie() helper that accepts sk, but gets socket from a BTF struct sock. This helper also works for sleepable programs.

Return
A 8-byte long unique number or 0 if sk is NULL.

u32 bpf_get_socket_uid(struct sk_buff *skb)****

Description
Get the owner UID of the socked associated to skb.

Return
The owner UID of the socket associated to skb. If the socket is NULL, or if it is not a full socket (i.e. if it is a time-wait or a request socket instead), overflowuid value is returned (note that overflowuid might also be the actual UID value for the socket).

long bpf_set_hash(struct sk_buff *skb,** u32 hash**)****

Description
Set the full hash for skb (set the field skb**->hash**) to value hash.

Return
0

long bpf_setsockopt(void *bpf_socket,** int level**,** int optname**,** void *optval**,** int optlen**)****

Description
Emulate a call to setsockopt() on the socket associated to bpf_socket, which must be a full socket. The level at which the option resides and the name optname of the option must be specified, see setsockopt(2) for more information. The option value of length optlen is pointed by optval.

bpf_socket should be one of the following:

  • struct bpf_sock_ops for BPF_PROG_TYPE_SOCK_OPS.

  • struct bpf_sock_addr for BPF_CGROUP_INET4_CONNECT, BPF_CGROUP_INET6_CONNECT and BPF_CGROUP_UNIX_CONNECT.

This helper actually implements a subset of setsockopt(). It supports the following levels:

  • SOL_SOCKET, which supports the following optnames: SO_RCVBUF, SO_SNDBUF, SO_MAX_PACING_RATE, SO_PRIORITY, SO_RCVLOWAT, SO_MARK, SO_BINDTODEVICE, SO_KEEPALIVE, SO_REUSEADDR, SO_REUSEPORT, SO_BINDTOIFINDEX, SO_TXREHASH.

  • IPPROTO_TCP, which supports the following optnames: TCP_CONGESTION, TCP_BPF_IW, TCP_BPF_SNDCWND_CLAMP, TCP_SAVE_SYN, TCP_KEEPIDLE, TCP_KEEPINTVL, TCP_KEEPCNT, TCP_SYNCNT, TCP_USER_TIMEOUT, TCP_NOTSENT_LOWAT, TCP_NODELAY, TCP_MAXSEG, TCP_WINDOW_CLAMP, TCP_THIN_LINEAR_TIMEOUTS, TCP_BPF_DELACK_MAX, TCP_BPF_RTO_MIN.

  • IPPROTO_IP, which supports optname IP_TOS.

  • IPPROTO_IPV6, which supports the following optnames: IPV6_TCLASS, IPV6_AUTOFLOWLABEL.

Return
0 on success, or a negative error in case of failure.

long bpf_skb_adjust_room(struct sk_buff *skb,** s32 len_diff**,** u32 mode**,** u64 flags**)****

Description
Grow or shrink the room for data in the packet associated to skb by len_diff, and according to the selected mode.

By default, the helper will reset any offloaded checksum indicator of the skb to CHECKSUM_NONE. This can be avoided by the following flag:

  • BPF_F_ADJ_ROOM_NO_CSUM_RESET: Do not reset offloaded checksum data of the skb to CHECKSUM_NONE.

There are two supported modes at this time:

  • BPF_ADJ_ROOM_MAC: Adjust room at the mac layer (room space is added or removed between the layer 2 and layer 3 headers).

  • BPF_ADJ_ROOM_NET: Adjust room at the network layer (room space is added or removed between the layer 3 and layer 4 headers).

The following flags are supported at this time:

  • BPF_F_ADJ_ROOM_FIXED_GSO: Do not adjust gso_size. Adjusting mss in this way is not allowed for datagrams.

  • BPF_F_ADJ_ROOM_ENCAP_L3_IPV4, BPF_F_ADJ_ROOM_ENCAP_L3_IPV6: Any new space is reserved to hold a tunnel header. Configure skb offsets and other fields accordingly.

  • BPF_F_ADJ_ROOM_ENCAP_L4_GRE, BPF_F_ADJ_ROOM_ENCAP_L4_UDP: Use with ENCAP_L3 flags to further specify the tunnel type.

  • BPF_F_ADJ_ROOM_ENCAP_L2(len): Use with ENCAP_L3/L4 flags to further specify the tunnel type; len is the length of the inner MAC header.

  • BPF_F_ADJ_ROOM_ENCAP_L2_ETH: Use with BPF_F_ADJ_ROOM_ENCAP_L2 flag to further specify the L2 type as Ethernet.

  • BPF_F_ADJ_ROOM_DECAP_L3_IPV4, BPF_F_ADJ_ROOM_DECAP_L3_IPV6: Indicate the new IP header version after decapsulating the outer IP header. Used when the inner and outer IP versions are different.

A call to this helper is susceptible to change the underlying packet buffer. Therefore, at load time, all checks on pointers previously done by the verifier are invalidated and must be performed again, if the helper is used in combination with direct packet access.

Return
0 on success, or a negative error in case of failure.

long bpf_redirect_map(struct bpf_map *map,** u64 key**,** u64 flags**)****

Description
Redirect the packet to the endpoint referenced by map at index key. Depending on its type, this map can contain references to net devices (for forwarding packets through other ports), or to CPUs (for redirecting XDP frames to another CPU; but this is only implemented for native XDP (with driver support) as of this writing).

The lower two bits of flags are used as the return code if the map lookup fails. This is so that the return value can be one of the XDP program return codes up to XDP_TX, as chosen by the caller. The higher bits of flags can be set to BPF_F_BROADCAST or BPF_F_EXCLUDE_INGRESS as defined below.

With BPF_F_BROADCAST the packet will be broadcasted to all the interfaces in the map, with BPF_F_EXCLUDE_INGRESS the ingress interface will be excluded when do broadcasting.

See also bpf_redirect(), which only supports redirecting to an ifindex, but doesn’t require a map to do so.

Return
XDP_REDIRECT on success, or the value of the two lower bits of the flags argument on error.

long bpf_sk_redirect_map(struct sk_buff *skb,** struct bpf_map *map**,** u32 key**,** u64 flags**)****

Description
Redirect the packet to the socket referenced by map (of type BPF_MAP_TYPE_SOCKMAP) at index key. Both ingress and egress interfaces can be used for redirection. The BPF_F_INGRESS value in flags is used to make the distinction (ingress path is selected if the flag is present, egress path otherwise). This is the only flag supported for now.

Return
SK_PASS on success, or SK_DROP on error.

long bpf_sock_map_update(struct bpf_sock_ops *skops,** struct bpf_map *map**,** void *key**,** u64 flags**)****

Description
Add an entry to, or update a map referencing sockets. The skops is used as a new value for the entry associated to key. flags is one of:

BPF_NOEXIST
The entry for key must not exist in the map.

BPF_EXIST
The entry for key must already exist in the map.

BPF_ANY
No condition on the existence of the entry for key.

If the map has eBPF programs (parser and verdict), those will be inherited by the socket being added. If the socket is already attached to eBPF programs, this results in an error.

Return
0 on success, or a negative error in case of failure.

long bpf_xdp_adjust_meta(struct xdp_buff *xdp_md,** int delta**)****

Description
Adjust the address pointed by xdp_md**->data_meta** by delta (which can be positive or negative). Note that this operation modifies the address stored in xdp_md**->data**, so the latter must be loaded only after the helper has been called.

The use of xdp_md**->data_meta** is optional and programs are not required to use it. The rationale is that when the packet is processed with XDP (e.g. as DoS filter), it is possible to push further meta data along with it before passing to the stack, and to give the guarantee that an ingress eBPF program attached as a TC classifier on the same device can pick this up for further post-processing. Since TC works with socket buffers, it remains possible to set from XDP the mark or priority pointers, or other pointers for the socket buffer. Having this scratch space generic and programmable allows for more flexibility as the user is free to store whatever meta data they need.

A call to this helper is susceptible to change the underlying packet buffer. Therefore, at load time, all checks on pointers previously done by the verifier are invalidated and must be performed again, if the helper is used in combination with direct packet access.

Return
0 on success, or a negative error in case of failure.

long bpf_perf_event_read_value(struct bpf_map *map,** u64 flags**,** struct bpf_perf_event_value *buf**,** u32 buf_size**)****

Description
Read the value of a perf event counter, and store it into buf of size buf_size. This helper relies on a map of type BPF_MAP_TYPE_PERF_EVENT_ARRAY. The nature of the perf event counter is selected when map is updated with perf event file descriptors. The map is an array whose size is the number of available CPUs, and each cell contains a value relative to one CPU. The value to retrieve is indicated by flags, that contains the index of the CPU to look up, masked with BPF_F_INDEX_MASK. Alternatively, flags can be set to BPF_F_CURRENT_CPU to indicate that the value for the current CPU should be retrieved.

This helper behaves in a way close to bpf_perf_event_read() helper, save that instead of just returning the value observed, it fills the buf structure. This allows for additional data to be retrieved: in particular, the enabled and running times (in buf**->enabled** and buf**->running**, respectively) are copied. In general, bpf_perf_event_read_value() is recommended over bpf_perf_event_read(), which has some ABI issues and provides fewer functionalities.

These values are interesting, because hardware PMU (Performance Monitoring Unit) counters are limited resources. When there are more PMU based perf events opened than available counters, kernel will multiplex these events so each event gets certain percentage (but not all) of the PMU time. In case that multiplexing happens, the number of samples or counter value will not reflect the case compared to when no multiplexing occurs. This makes comparison between different runs difficult. Typically, the counter value should be normalized before comparing to other experiments. The usual normalization is done as follows.

normalized_counter = counter * t_enabled / t_running

Where t_enabled is the time enabled for event and t_running is the time running for event since last normalization. The enabled and running times are accumulated since the perf event open. To achieve scaling factor between two invocations of an eBPF program, users can use CPU id as the key (which is typical for perf array usage model) to remember the previous value and do the calculation inside the eBPF program.

Return
0 on success, or a negative error in case of failure.

long bpf_perf_prog_read_value(struct bpf_perf_event_data *ctx,** struct bpf_perf_event_value *buf**,** u32 buf_size**)****

Description
For an eBPF program attached to a perf event, retrieve the value of the event counter associated to ctx and store it in the structure pointed by buf and of size buf_size. Enabled and running times are also stored in the structure (see description of helper bpf_perf_event_read_value() for more details).

Return
0 on success, or a negative error in case of failure.

long bpf_getsockopt(void *bpf_socket,** int level**,** int optname**,** void *optval**,** int optlen**)****

Description
Emulate a call to getsockopt() on the socket associated to bpf_socket, which must be a full socket. The level at which the option resides and the name optname of the option must be specified, see getsockopt(2) for more information. The retrieved value is stored in the structure pointed by opval and of length optlen.

bpf_socket should be one of the following:

  • struct bpf_sock_ops for BPF_PROG_TYPE_SOCK_OPS.

  • struct bpf_sock_addr for BPF_CGROUP_INET4_CONNECT, BPF_CGROUP_INET6_CONNECT and BPF_CGROUP_UNIX_CONNECT.

This helper actually implements a subset of getsockopt(). It supports the same set of optnames that is supported by the bpf_setsockopt() helper. The exceptions are TCP_BPF_* is bpf_setsockopt() only and TCP_SAVED_SYN is bpf_getsockopt() only.

Return
0 on success, or a negative error in case of failure.

long bpf_override_return(struct pt_regs *regs,** u64 rc**)****

Description
Used for error injection, this helper uses kprobes to override the return value of the probed function, and to set it to rc. The first argument is the context regs on which the kprobe works.

This helper works by setting the PC (program counter) to an override function which is run in place of the original probed function. This means the probed function is not run at all. The replacement function just returns with the required value.

This helper has security implications, and thus is subject to restrictions. It is only available if the kernel was compiled with the CONFIG_BPF_KPROBE_OVERRIDE configuration option, and in this case it only works on functions tagged with ALLOW_ERROR_INJECTION in the kernel code.

Also, the helper is only available for the architectures having the CONFIG_FUNCTION_ERROR_INJECTION option. As of this writing, x86 architecture is the only one to support this feature.

Return
0

long bpf_sock_ops_cb_flags_set(struct bpf_sock_ops *bpf_sock,** int argval**)****

Description
Attempt to set the value of the bpf_sock_ops_cb_flags field for the full TCP socket associated to bpf_sock_ops to argval.

The primary use of this field is to determine if there should be calls to eBPF programs of type BPF_PROG_TYPE_SOCK_OPS at various points in the TCP code. A program of the same type can change its value, per connection and as necessary, when the connection is established. This field is directly accessible for reading, but this helper must be used for updates in order to return an error if an eBPF program tries to set a callback that is not supported in the current kernel.

argval is a flag array which can combine these flags:

  • BPF_SOCK_OPS_RTO_CB_FLAG (retransmission time out)

  • BPF_SOCK_OPS_RETRANS_CB_FLAG (retransmission)

  • BPF_SOCK_OPS_STATE_CB_FLAG (TCP state change)

  • BPF_SOCK_OPS_RTT_CB_FLAG (every RTT)

Therefore, this function can be used to clear a callback flag by setting the appropriate bit to zero. e.g. to disable the RTO callback:

bpf_sock_ops_cb_flags_set(bpf_sock,
bpf_sock->bpf_sock_ops_cb_flags & ~BPF_SOCK_OPS_RTO_CB_FLAG)

Here are some examples of where one could call such eBPF program:

  • When RTO fires.

  • When a packet is retransmitted.

  • When the connection terminates.

  • When a packet is sent.

  • When a packet is received.

Return
Code -EINVAL if the socket is not a full TCP socket; otherwise, a positive number containing the bits that could not be set is returned (which comes down to 0 if all bits were set as required).

long bpf_msg_redirect_map(struct sk_msg_buff *msg,** struct bpf_map *map**,** u32 key**,** u64 flags**)****

Description
This helper is used in programs implementing policies at the socket level. If the message msg is allowed to pass (i.e. if the verdict eBPF program returns SK_PASS), redirect it to the socket referenced by map (of type BPF_MAP_TYPE_SOCKMAP) at index key. Both ingress and egress interfaces can be used for redirection. The BPF_F_INGRESS value in flags is used to make the distinction (ingress path is selected if the flag is present, egress path otherwise). This is the only flag supported for now.

Return
SK_PASS on success, or SK_DROP on error.

long bpf_msg_apply_bytes(struct sk_msg_buff *msg,** u32 bytes**)****

Description
For socket policies, apply the verdict of the eBPF program to the next bytes (number of bytes) of message msg.

For example, this helper can be used in the following cases:

  • A single sendmsg() or sendfile() system call contains multiple logical messages that the eBPF program is supposed to read and for which it should apply a verdict.

  • An eBPF program only cares to read the first bytes of a msg. If the message has a large payload, then setting up and calling the eBPF program repeatedly for all bytes, even though the verdict is already known, would create unnecessary overhead.

When called from within an eBPF program, the helper sets a counter internal to the BPF infrastructure, that is used to apply the last verdict to the next bytes. If bytes is smaller than the current data being processed from a sendmsg() or sendfile() system call, the first bytes will be sent and the eBPF program will be re-run with the pointer for start of data pointing to byte number bytes + 1. If bytes is larger than the current data being processed, then the eBPF verdict will be applied to multiple sendmsg() or sendfile() calls until bytes are consumed.

Note that if a socket closes with the internal counter holding a non-zero value, this is not a problem because data is not being buffered for bytes and is sent as it is received.

Return
0

long bpf_msg_cork_bytes(struct sk_msg_buff *msg,** u32 bytes**)****

Description
For socket policies, prevent the execution of the verdict eBPF program for message msg until bytes (byte number) have been accumulated.

This can be used when one needs a specific number of bytes before a verdict can be assigned, even if the data spans multiple sendmsg() or sendfile() calls. The extreme case would be a user calling sendmsg() repeatedly with 1-byte long message segments. Obviously, this is bad for performance, but it is still valid. If the eBPF program needs bytes bytes to validate a header, this helper can be used to prevent the eBPF program to be called again until bytes have been accumulated.

Return
0

long bpf_msg_pull_data(struct sk_msg_buff *msg,** u32 start**,** u32 end**,** u64 flags**)****

Description
For socket policies, pull in non-linear data from user space for msg and set pointers msg**->data** and msg**->data_end** to start and end bytes offsets into msg, respectively.

If a program of type BPF_PROG_TYPE_SK_MSG is run on a msg it can only parse data that the (data, data_end) pointers have already consumed. For sendmsg() hooks this is likely the first scatterlist element. But for calls relying on the sendpage handler (e.g. sendfile()) this will be the range (0, 0) because the data is shared with user space and by default the objective is to avoid allowing user space to modify data while (or after) eBPF verdict is being decided. This helper can be used to pull in data and to set the start and end pointer to given values. Data will be copied if necessary (i.e. if data was not linear and if start and end pointers do not point to the same chunk).

A call to this helper is susceptible to change the underlying packet buffer. Therefore, at load time, all checks on pointers previously done by the verifier are invalidated and must be performed again, if the helper is used in combination with direct packet access.

All values for flags are reserved for future usage, and must be left at zero.

Return
0 on success, or a negative error in case of failure.

long bpf_bind(struct bpf_sock_addr *ctx,** struct sockaddr *addr**,** int addr_len**)****

Description
Bind the socket associated to ctx to the address pointed by addr, of length addr_len. This allows for making outgoing connection from the desired IP address, which can be useful for example when all processes inside a cgroup should use one single IP address on a host that has multiple IP configured.

This helper works for IPv4 and IPv6, TCP and UDP sockets. The domain (addr**->sa_family**) must be AF_INET (or AF_INET6). It’s advised to pass zero port (sin_port or sin6_port) which triggers IP_BIND_ADDRESS_NO_PORT-like behavior and lets the kernel efficiently pick up an unused port as long as 4-tuple is unique. Passing non-zero port might lead to degraded performance.

Return
0 on success, or a negative error in case of failure.

long bpf_xdp_adjust_tail(struct xdp_buff *xdp_md,** int delta**)****

Description
Adjust (move) xdp_md**->data_end** by delta bytes. It is possible to both shrink and grow the packet tail. Shrink done via delta being a negative integer.

A call to this helper is susceptible to change the underlying packet buffer. Therefore, at load time, all checks on pointers previously done by the verifier are invalidated and must be performed again, if the helper is used in combination with direct packet access.

Return
0 on success, or a negative error in case of failure.

long bpf_skb_get_xfrm_state(struct sk_buff *skb,** u32 index**,** struct bpf_xfrm_state *xfrm_state**,** u32 size**,** u64 flags**)****

Description
Retrieve the XFRM state (IP transform framework, see also ip-xfrm(8)) at index in XFRM “security path” for skb.

The retrieved value is stored in the struct bpf_xfrm_state pointed by xfrm_state and of length size.

All values for flags are reserved for future usage, and must be left at zero.

This helper is available only if the kernel was compiled with CONFIG_XFRM configuration option.

Return
0 on success, or a negative error in case of failure.

long bpf_get_stack(void *ctx,** void *buf**,** u32 size**,** u64 flags**)****

Description
Return a user or a kernel stack in bpf program provided buffer. To achieve this, the helper needs ctx, which is a pointer to the context on which the tracing program is executed. To store the stacktrace, the bpf program provides buf with a nonnegative size.

The last argument, flags, holds the number of stack frames to skip (from 0 to 255), masked with BPF_F_SKIP_FIELD_MASK. The next bits can be used to set the following flags:

BPF_F_USER_STACK
Collect a user space stack instead of a kernel stack.

BPF_F_USER_BUILD_ID
Collect (build_id, file_offset) instead of ips for user stack, only valid if BPF_F_USER_STACK is also specified.

file_offset is an offset relative to the beginning of the executable or shared object file backing the vma which the ip falls in. It is not an offset relative to that object’s base address. Accordingly, it must be adjusted by adding (sh_addr - sh_offset), where sh_{addr,offset} correspond to the executable section containing file_offset in the object, for comparisons to symbols’ st_value to be valid.

bpf_get_stack() can collect up to PERF_MAX_STACK_DEPTH both kernel and user frames, subject to sufficient large buffer size. Note that this limit can be controlled with the sysctl program, and that it should be manually increased in order to profile long user stacks (such as stacks for Java programs). To do so, use:

sysctl kernel.perf_event_max_stack=

Return
The non-negative copied buf length equal to or less than size on success, or a negative error in case of failure.

long bpf_skb_load_bytes_relative(const void *skb,** u32 offset**,** void *to**,** u32 len**,** u32 start_header**)****

Description
This helper is similar to bpf_skb_load_bytes() in that it provides an easy way to load len bytes from offset from the packet associated to skb, into the buffer pointed by to. The difference to bpf_skb_load_bytes() is that a fifth argument start_header exists in order to select a base offset to start from. start_header can be one of:

BPF_HDR_START_MAC
Base offset to load data from is skb’s mac header.

BPF_HDR_START_NET
Base offset to load data from is skb’s network header.

In general, “direct packet access” is the preferred method to access packet data, however, this helper is in particular useful in socket filters where skb**->data** does not always point to the start of the mac header and where “direct packet access” is not available.

Return
0 on success, or a negative error in case of failure.

long bpf_fib_lookup(void *ctx,** struct bpf_fib_lookup *params**,** int plen**,** u32 flags**)****

Description
Do FIB lookup in kernel tables using parameters in params. If lookup is successful and result shows packet is to be forwarded, the neighbor tables are searched for the nexthop. If successful (ie., FIB lookup shows forwarding and nexthop is resolved), the nexthop address is returned in ipv4_dst or ipv6_dst based on family, smac is set to mac address of egress device, dmac is set to nexthop mac address, rt_metric is set to metric from route (IPv4/IPv6 only), and ifindex is set to the device index of the nexthop from the FIB lookup.

plen argument is the size of the passed in struct. flags argument can be a combination of one or more of the following values:

BPF_FIB_LOOKUP_DIRECT
Do a direct table lookup vs full lookup using FIB rules.

BPF_FIB_LOOKUP_TBID
Used with BPF_FIB_LOOKUP_DIRECT. Use the routing table ID present in params->tbid for the fib lookup.

BPF_FIB_LOOKUP_OUTPUT
Perform lookup from an egress perspective (default is ingress).

BPF_FIB_LOOKUP_SKIP_NEIGH
Skip the neighbour table lookup. params->dmac and params->smac will not be set as output. A common use case is to call bpf_redirect_neigh() after doing bpf_fib_lookup().

BPF_FIB_LOOKUP_SRC
Derive and set source IP addr in params->ipv{4,6}_src for the nexthop. If the src addr cannot be derived, BPF_FIB_LKUP_RET_NO_SRC_ADDR is returned. In this case, params->dmac and params->smac are not set either.

ctx is either struct xdp_md for XDP programs or struct sk_buff tc cls_act programs.

Return

  • < 0 if any input argument is invalid

  • 0 on success (packet is forwarded, nexthop neighbor exists)

  • > 0 one of BPF_FIB_LKUP_RET_ codes explaining why the packet is not forwarded or needs assist from full stack

If lookup fails with BPF_FIB_LKUP_RET_FRAG_NEEDED, then the MTU was exceeded and output params->mtu_result contains the MTU.

long bpf_sock_hash_update(struct bpf_sock_ops *skops,** struct bpf_map *map**,** void *key**,** u64 flags**)****

Description
Add an entry to, or update a sockhash map referencing sockets. The skops is used as a new value for the entry associated to key. flags is one of:

BPF_NOEXIST
The entry for key must not exist in the map.

BPF_EXIST
The entry for key must already exist in the map.

BPF_ANY
No condition on the existence of the entry for key.

If the map has eBPF programs (parser and verdict), those will be inherited by the socket being added. If the socket is already attached to eBPF programs, this results in an error.

Return
0 on success, or a negative error in case of failure.

long bpf_msg_redirect_hash(struct sk_msg_buff *msg,** struct bpf_map *map**,** void *key**,** u64 flags**)****

Description
This helper is used in programs implementing policies at the socket level. If the message msg is allowed to pass (i.e. if the verdict eBPF program returns SK_PASS), redirect it to the socket referenced by map (of type BPF_MAP_TYPE_SOCKHASH) using hash key. Both ingress and egress interfaces can be used for redirection. The BPF_F_INGRESS value in flags is used to make the distinction (ingress path is selected if the flag is present, egress path otherwise). This is the only flag supported for now.

Return
SK_PASS on success, or SK_DROP on error.

long bpf_sk_redirect_hash(struct sk_buff *skb,** struct bpf_map *map**,** void *key**,** u64 flags**)****

Description
This helper is used in programs implementing policies at the skb socket level. If the sk_buff skb is allowed to pass (i.e. if the verdict eBPF program returns SK_PASS), redirect it to the socket referenced by map (of type BPF_MAP_TYPE_SOCKHASH) using hash key. Both ingress and egress interfaces can be used for redirection. The BPF_F_INGRESS value in flags is used to make the distinction (ingress path is selected if the flag is present, egress otherwise). This is the only flag supported for now.

Return
SK_PASS on success, or SK_DROP on error.

long bpf_lwt_push_encap(struct sk_buff *skb,** u32 type**,** void *hdr**,** u32 len**)****

Description
Encapsulate the packet associated to skb within a Layer 3 protocol header. This header is provided in the buffer at address hdr, with len its size in bytes. type indicates the protocol of the header and can be one of:

BPF_LWT_ENCAP_SEG6
IPv6 encapsulation with Segment Routing Header (struct ipv6_sr_hdr). hdr only contains the SRH, the IPv6 header is computed by the kernel.

BPF_LWT_ENCAP_SEG6_INLINE
Only works if skb contains an IPv6 packet. Insert a Segment Routing Header (struct ipv6_sr_hdr) inside the IPv6 header.

BPF_LWT_ENCAP_IP
IP encapsulation (GRE/GUE/IPIP/etc). The outer header must be IPv4 or IPv6, followed by zero or more additional headers, up to LWT_BPF_MAX_HEADROOM total bytes in all prepended headers. Please note that if skb_is_gso(skb) is true, no more than two headers can be prepended, and the inner header, if present, should be either GRE or UDP/GUE.

BPF_LWT_ENCAP_SEG6* types can be called by BPF programs of type BPF_PROG_TYPE_LWT_IN; BPF_LWT_ENCAP_IP type can be called by bpf programs of types BPF_PROG_TYPE_LWT_IN and BPF_PROG_TYPE_LWT_XMIT.

A call to this helper is susceptible to change the underlying packet buffer. Therefore, at load time, all checks on pointers previously done by the verifier are invalidated and must be performed again, if the helper is used in combination with direct packet access.

Return
0 on success, or a negative error in case of failure.

long bpf_lwt_seg6_store_bytes(struct sk_buff *skb,** u32 offset**,** const void *from**,** u32 len**)****

Description
Store len bytes from address from into the packet associated to skb, at offset. Only the flags, tag and TLVs inside the outermost IPv6 Segment Routing Header can be modified through this helper.

A call to this helper is susceptible to change the underlying packet buffer. Therefore, at load time, all checks on pointers previously done by the verifier are invalidated and must be performed again, if the helper is used in combination with direct packet access.

Return
0 on success, or a negative error in case of failure.

long bpf_lwt_seg6_adjust_srh(struct sk_buff *skb,** u32 offset**,** s32 delta**)****

Description
Adjust the size allocated to TLVs in the outermost IPv6 Segment Routing Header contained in the packet associated to skb, at position offset by delta bytes. Only offsets after the segments are accepted. delta can be as well positive (growing) as negative (shrinking).

A call to this helper is susceptible to change the underlying packet buffer. Therefore, at load time, all checks on pointers previously done by the verifier are invalidated and must be performed again, if the helper is used in combination with direct packet access.

Return
0 on success, or a negative error in case of failure.

long bpf_lwt_seg6_action(struct sk_buff *skb,** u32 action**,** void *param**,** u32 param_len**)****

Description
Apply an IPv6 Segment Routing action of type action to the packet associated to skb. Each action takes a parameter contained at address param, and of length param_len bytes. action can be one of:

SEG6_LOCAL_ACTION_END_X
End.X action: Endpoint with Layer-3 cross-connect. Type of param: struct in6_addr.

SEG6_LOCAL_ACTION_END_T
End.T action: Endpoint with specific IPv6 table lookup. Type of param: int.

SEG6_LOCAL_ACTION_END_B6
End.B6 action: Endpoint bound to an SRv6 policy. Type of param: struct ipv6_sr_hdr.

SEG6_LOCAL_ACTION_END_B6_ENCAP
End.B6.Encap action: Endpoint bound to an SRv6 encapsulation policy. Type of param: struct ipv6_sr_hdr.

A call to this helper is susceptible to change the underlying packet buffer. Therefore, at load time, all checks on pointers previously done by the verifier are invalidated and must be performed again, if the helper is used in combination with direct packet access.

Return
0 on success, or a negative error in case of failure.

long bpf_rc_repeat(void *ctx)****

Description
This helper is used in programs implementing IR decoding, to report a successfully decoded repeat key message. This delays the generation of a key up event for previously generated key down event.

Some IR protocols like NEC have a special IR message for repeating last button, for when a button is held down.

The ctx should point to the lirc sample as passed into the program.

This helper is only available is the kernel was compiled with the CONFIG_BPF_LIRC_MODE2 configuration option set to “y”.

Return
0

long bpf_rc_keydown(void *ctx,** u32 protocol**,** u64 scancode**,** u32 toggle**)****

Description
This helper is used in programs implementing IR decoding, to report a successfully decoded key press with scancode, toggle value in the given protocol. The scancode will be translated to a keycode using the rc keymap, and reported as an input key down event. After a period a key up event is generated. This period can be extended by calling either bpf_rc_keydown() again with the same values, or calling bpf_rc_repeat().

Some protocols include a toggle bit, in case the button was released and pressed again between consecutive scancodes.

The ctx should point to the lirc sample as passed into the program.

The protocol is the decoded protocol number (see enum rc_proto for some predefined values).

This helper is only available is the kernel was compiled with the CONFIG_BPF_LIRC_MODE2 configuration option set to “y”.

Return
0

u64 bpf_skb_cgroup_id(struct sk_buff *skb)****

Description
Return the cgroup v2 id of the socket associated with the skb. This is roughly similar to the bpf_get_cgroup_classid() helper for cgroup v1 by providing a tag resp. identifier that can be matched on or used for map lookups e.g. to implement policy. The cgroup v2 id of a given path in the hierarchy is exposed in user space through the f_handle API in order to get to the same 64-bit id.

This helper can be used on TC egress path, but not on ingress, and is available only if the kernel was compiled with the CONFIG_SOCK_CGROUP_DATA configuration option.

Return
The id is returned or 0 in case the id could not be retrieved.

u64 bpf_get_current_cgroup_id(void)

Description
Get the current cgroup id based on the cgroup within which the current task is running.

Return
A 64-bit integer containing the current cgroup id based on the cgroup within which the current task is running.

void *bpf_get_local_storage(void *map,** u64 flags**)****

Description
Get the pointer to the local storage area. The type and the size of the local storage is defined by the map argument. The flags meaning is specific for each map type, and has to be 0 for cgroup local storage.

Depending on the BPF program type, a local storage area can be shared between multiple instances of the BPF program, running simultaneously.

A user should care about the synchronization by himself. For example, by using the BPF_ATOMIC instructions to alter the shared data.

Return
A pointer to the local storage area.

long bpf_sk_select_reuseport(struct sk_reuseport_md *reuse,** struct bpf_map *map**,** void *key**,** u64 flags**)****

Description
Select a SO_REUSEPORT socket from a BPF_MAP_TYPE_REUSEPORT_SOCKARRAY map. It checks the selected socket is matching the incoming request in the socket buffer.

Return
0 on success, or a negative error in case of failure.

u64 bpf_skb_ancestor_cgroup_id(struct sk_buff *skb,** int ancestor_level**)****

Description
Return id of cgroup v2 that is ancestor of cgroup associated with the skb at the ancestor_level. The root cgroup is at ancestor_level zero and each step down the hierarchy increments the level. If ancestor_level == level of cgroup associated with skb, then return value will be same as that of bpf_skb_cgroup_id().

The helper is useful to implement policies based on cgroups that are upper in hierarchy than immediate cgroup associated with skb.

The format of returned id and helper limitations are same as in bpf_skb_cgroup_id().

Return
The id is returned or 0 in case the id could not be retrieved.

struct bpf_sock *bpf_sk_lookup_tcp(void *ctx,** struct bpf_sock_tuple *tuple**,** u32 tuple_size**,** u64 netns**,** u64 flags**)****

Description
Look for TCP socket matching tuple, optionally in a child network namespace netns. The return value must be checked, and if non-NULL, released via bpf_sk_release().

The ctx should point to the context of the program, such as the skb or socket (depending on the hook in use). This is used to determine the base network namespace for the lookup.

tuple_size must be one of:

sizeof(tuple->ipv4**)**
Look for an IPv4 socket.

sizeof(tuple->ipv6**)**
Look for an IPv6 socket.

If the netns is a negative signed 32-bit integer, then the socket lookup table in the netns associated with the ctx will be used. For the TC hooks, this is the netns of the device in the skb. For socket hooks, this is the netns of the socket. If netns is any other signed 32-bit value greater than or equal to zero then it specifies the ID of the netns relative to the netns associated with the ctx. netns values beyond the range of 32-bit integers are reserved for future use.

All values for flags are reserved for future usage, and must be left at zero.

This helper is available only if the kernel was compiled with CONFIG_NET configuration option.

Return
Pointer to struct bpf_sock, or NULL in case of failure. For sockets with reuseport option, the struct bpf_sock result is from reuse**->socks**[] using the hash of the tuple.

struct bpf_sock *bpf_sk_lookup_udp(void *ctx,** struct bpf_sock_tuple *tuple**,** u32 tuple_size**,** u64 netns**,** u64 flags**)****

Description
Look for UDP socket matching tuple, optionally in a child network namespace netns. The return value must be checked, and if non-NULL, released via bpf_sk_release().

The ctx should point to the context of the program, such as the skb or socket (depending on the hook in use). This is used to determine the base network namespace for the lookup.

tuple_size must be one of:

sizeof(tuple->ipv4**)**
Look for an IPv4 socket.

sizeof(tuple->ipv6**)**
Look for an IPv6 socket.

If the netns is a negative signed 32-bit integer, then the socket lookup table in the netns associated with the ctx will be used. For the TC hooks, this is the netns of the device in the skb. For socket hooks, this is the netns of the socket. If netns is any other signed 32-bit value greater than or equal to zero then it specifies the ID of the netns relative to the netns associated with the ctx. netns values beyond the range of 32-bit integers are reserved for future use.

All values for flags are reserved for future usage, and must be left at zero.

This helper is available only if the kernel was compiled with CONFIG_NET configuration option.

Return
Pointer to struct bpf_sock, or NULL in case of failure. For sockets with reuseport option, the struct bpf_sock result is from reuse**->socks**[] using the hash of the tuple.

long bpf_sk_release(void *sock)****

Description
Release the reference held by sock. sock must be a non-NULL pointer that was returned from bpf_sk_lookup_xxx().

Return
0 on success, or a negative error in case of failure.

long bpf_map_push_elem(struct bpf_map *map,** const void *value**,** u64 flags**)****

Description
Push an element value in map. flags is one of:

BPF_EXIST
If the queue/stack is full, the oldest element is removed to make room for this.

Return
0 on success, or a negative error in case of failure.

long bpf_map_pop_elem(struct bpf_map *map,** void *value**)****

Description
Pop an element from map.

Return
0 on success, or a negative error in case of failure.

long bpf_map_peek_elem(struct bpf_map *map,** void *value**)****

Description
Get an element from map without removing it.

Return
0 on success, or a negative error in case of failure.

long bpf_msg_push_data(struct sk_msg_buff *msg,** u32 start**,** u32 len**,** u64 flags**)****

Description
For socket policies, insert len bytes into msg at offset start.

If a program of type BPF_PROG_TYPE_SK_MSG is run on a msg it may want to insert metadata or options into the msg. This can later be read and used by any of the lower layer BPF hooks.

This helper may fail if under memory pressure (a malloc fails) in these cases BPF programs will get an appropriate error and BPF programs will need to handle them.

Return
0 on success, or a negative error in case of failure.

long bpf_msg_pop_data(struct sk_msg_buff *msg,** u32 start**,** u32 len**,** u64 flags**)****

Description
Will remove len bytes from a msg starting at byte start. This may result in ENOMEM errors under certain situations if an allocation and copy are required due to a full ring buffer. However, the helper will try to avoid doing the allocation if possible. Other errors can occur if input parameters are invalid either due to start byte not being valid part of msg payload and/or pop value being to large.

Return
0 on success, or a negative error in case of failure.

long bpf_rc_pointer_rel(void *ctx,** s32 rel_x**,** s32 rel_y**)****

Description
This helper is used in programs implementing IR decoding, to report a successfully decoded pointer movement.

The ctx should point to the lirc sample as passed into the program.

This helper is only available is the kernel was compiled with the CONFIG_BPF_LIRC_MODE2 configuration option set to “y”.

Return
0

long bpf_spin_lock(struct bpf_spin_lock *lock)****

Description
Acquire a spinlock represented by the pointer lock, which is stored as part of a value of a map. Taking the lock allows to safely update the rest of the fields in that value. The spinlock can (and must) later be released with a call to bpf_spin_unlock(lock).

Spinlocks in BPF programs come with a number of restrictions and constraints:

  • bpf_spin_lock objects are only allowed inside maps of types BPF_MAP_TYPE_HASH and BPF_MAP_TYPE_ARRAY (this list could be extended in the future).

  • BTF description of the map is mandatory.

  • The BPF program can take ONE lock at a time, since taking two or more could cause dead locks.

  • Only one struct bpf_spin_lock is allowed per map element.

  • When the lock is taken, calls (either BPF to BPF or helpers) are not allowed.

  • The BPF_LD_ABS and BPF_LD_IND instructions are not allowed inside a spinlock-ed region.

  • The BPF program MUST call bpf_spin_unlock() to release the lock, on all execution paths, before it returns.

  • The BPF program can access struct bpf_spin_lock only via the bpf_spin_lock() and bpf_spin_unlock() helpers. Loading or storing data into the struct bpf_spin_lock lock**;** field of a map is not allowed.

  • To use the bpf_spin_lock() helper, the BTF description of the map value must be a struct and have struct bpf_spin_lock anyname**;** field at the top level. Nested lock inside another struct is not allowed.

  • The struct bpf_spin_lock lock field in a map value must be aligned on a multiple of 4 bytes in that value.

  • Syscall with command BPF_MAP_LOOKUP_ELEM does not copy the bpf_spin_lock field to user space.

  • Syscall with command BPF_MAP_UPDATE_ELEM, or update from a BPF program, do not update the bpf_spin_lock field.

  • bpf_spin_lock cannot be on the stack or inside a networking packet (it can only be inside of a map values).

  • bpf_spin_lock is available to root only.

  • Tracing programs and socket filter programs cannot use bpf_spin_lock() due to insufficient preemption checks (but this may change in the future).

  • bpf_spin_lock is not allowed in inner maps of map-in-map.

Return
0

long bpf_spin_unlock(struct bpf_spin_lock *lock)****

Description
Release the lock previously locked by a call to bpf_spin_lock(lock).

Return
0

struct bpf_sock *bpf_sk_fullsock(struct bpf_sock *sk)****

Description
This helper gets a struct bpf_sock pointer such that all the fields in this bpf_sock can be accessed.

Return
A struct bpf_sock pointer on success, or NULL in case of failure.

struct bpf_tcp_sock *bpf_tcp_sock(struct bpf_sock *sk)****

Description
This helper gets a struct bpf_tcp_sock pointer from a struct bpf_sock pointer.

Return
A struct bpf_tcp_sock pointer on success, or NULL in case of failure.

long bpf_skb_ecn_set_ce(struct sk_buff *skb)****

Description
Set ECN (Explicit Congestion Notification) field of IP header to CE (Congestion Encountered) if current value is ECT (ECN Capable Transport). Otherwise, do nothing. Works with IPv6 and IPv4.

Return
1 if the CE flag is set (either by the current helper call or because it was already present), 0 if it is not set.

struct bpf_sock *bpf_get_listener_sock(struct bpf_sock *sk)****

Description
Return a struct bpf_sock pointer in TCP_LISTEN state. bpf_sk_release() is unnecessary and not allowed.

Return
A struct bpf_sock pointer on success, or NULL in case of failure.

struct bpf_sock *bpf_skc_lookup_tcp(void *ctx,** struct bpf_sock_tuple *tuple**,** u32 tuple_size**,** u64 netns**,** u64 flags**)****

Description
Look for TCP socket matching tuple, optionally in a child network namespace netns. The return value must be checked, and if non-NULL, released via bpf_sk_release().

This function is identical to bpf_sk_lookup_tcp(), except that it also returns timewait or request sockets. Use bpf_sk_fullsock() or bpf_tcp_sock() to access the full structure.

This helper is available only if the kernel was compiled with CONFIG_NET configuration option.

Return
Pointer to struct bpf_sock, or NULL in case of failure. For sockets with reuseport option, the struct bpf_sock result is from reuse**->socks**[] using the hash of the tuple.

long bpf_tcp_check_syncookie(void *sk,** void *iph**,** u32 iph_len**,** struct tcphdr *th**,** u32 th_len**)****

Description
Check whether iph and th contain a valid SYN cookie ACK for the listening socket in sk.

iph points to the start of the IPv4 or IPv6 header, while iph_len contains sizeof(struct iphdr) or sizeof(struct ipv6hdr).

th points to the start of the TCP header, while th_len contains the length of the TCP header (at least sizeof(struct tcphdr)).

Return
0 if iph and th are a valid SYN cookie ACK, or a negative error otherwise.

long bpf_sysctl_get_name(struct bpf_sysctl *ctx,** char *buf**,** size_t buf_len**,** u64 flags**)****

Description
Get name of sysctl in /proc/sys/ and copy it into provided by program buffer buf of size buf_len.

The buffer is always NUL terminated, unless it’s zero-sized.

If flags is zero, full name (e.g. “net/ipv4/tcp_mem”) is copied. Use BPF_F_SYSCTL_BASE_NAME flag to copy base name only (e.g. “tcp_mem”).

Return
Number of character copied (not including the trailing NUL).

-E2BIG if the buffer wasn’t big enough (buf will contain truncated name in this case).

long bpf_sysctl_get_current_value(struct bpf_sysctl *ctx,** char *buf**,** size_t buf_len**)****

Description
Get current value of sysctl as it is presented in /proc/sys (incl. newline, etc), and copy it as a string into provided by program buffer buf of size buf_len.

The whole value is copied, no matter what file position user space issued e.g. sys_read at.

The buffer is always NUL terminated, unless it’s zero-sized.

Return
Number of character copied (not including the trailing NUL).

-E2BIG if the buffer wasn’t big enough (buf will contain truncated name in this case).

-EINVAL if current value was unavailable, e.g. because sysctl is uninitialized and read returns -EIO for it.

long bpf_sysctl_get_new_value(struct bpf_sysctl *ctx,** char *buf**,** size_t buf_len**)****

Description
Get new value being written by user space to sysctl (before the actual write happens) and copy it as a string into provided by program buffer buf of size buf_len.

User space may write new value at file position > 0.

The buffer is always NUL terminated, unless it’s zero-sized.

Return
Number of character copied (not including the trailing NUL).

-E2BIG if the buffer wasn’t big enough (buf will contain truncated name in this case).

-EINVAL if sysctl is being read.

long bpf_sysctl_set_new_value(struct bpf_sysctl *ctx,** const char *buf**,** size_t buf_len**)****

Description
Override new value being written by user space to sysctl with value provided by program in buffer buf of size buf_len.

buf should contain a string in same form as provided by user space on sysctl write.

User space may write new value at file position > 0. To override the whole sysctl value file position should be set to zero.

Return
0 on success.

-E2BIG if the buf_len is too big.

-EINVAL if sysctl is being read.

long bpf_strtol(const char *buf,** size_t buf_len**,** u64 flags**,** long *res**)****

Description
Convert the initial part of the string from buffer buf of size buf_len to a long integer according to the given base and save the result in res.

The string may begin with an arbitrary amount of white space (as determined by isspace(3)) followed by a single optional ‘-’ sign.

Five least significant bits of flags encode base, other bits are currently unused.

Base must be either 8, 10, 16 or 0 to detect it automatically similar to user space strtol(3).

Return
Number of characters consumed on success. Must be positive but no more than buf_len.

-EINVAL if no valid digits were found or unsupported base was provided.

-ERANGE if resulting value was out of range.

long bpf_strtoul(const char *buf,** size_t buf_len**,** u64 flags**,** unsigned long *res**)****

Description
Convert the initial part of the string from buffer buf of size buf_len to an unsigned long integer according to the given base and save the result in res.

The string may begin with an arbitrary amount of white space (as determined by isspace(3)).

Five least significant bits of flags encode base, other bits are currently unused.

Base must be either 8, 10, 16 or 0 to detect it automatically similar to user space strtoul(3).

Return
Number of characters consumed on success. Must be positive but no more than buf_len.

-EINVAL if no valid digits were found or unsupported base was provided.

-ERANGE if resulting value was out of range.

void *bpf_sk_storage_get(struct bpf_map *map,** void *sk**,** void *value**,** u64 flags**)****

Description
Get a bpf-local-storage from a sk.

Logically, it could be thought of getting the value from a map with sk as the key. From this perspective, the usage is not much different from bpf_map_lookup_elem(map, **&**sk) except this helper enforces the key must be a full socket and the map must be a BPF_MAP_TYPE_SK_STORAGE also.

Underneath, the value is stored locally at sk instead of the map. The map is used as the bpf-local-storage “type”. The bpf-local-storage “type” (i.e. the map) is searched against all bpf-local-storages residing at sk.

sk is a kernel struct sock pointer for LSM program. sk is a struct bpf_sock pointer for other program types.

An optional flags (BPF_SK_STORAGE_GET_F_CREATE) can be used such that a new bpf-local-storage will be created if one does not exist. value can be used together with BPF_SK_STORAGE_GET_F_CREATE to specify the initial value of a bpf-local-storage. If value is NULL, the new bpf-local-storage will be zero initialized.

Return
A bpf-local-storage pointer is returned on success.

NULL if not found or there was an error in adding a new bpf-local-storage.

long bpf_sk_storage_delete(struct bpf_map *map,** void *sk**)****

Description
Delete a bpf-local-storage from a sk.

Return
0 on success.

-ENOENT if the bpf-local-storage cannot be found. -EINVAL if sk is not a fullsock (e.g. a request_sock).

long bpf_send_signal(u32 sig)****

Description
Send signal sig to the process of the current task. The signal may be delivered to any of this process’s threads.

Return
0 on success or successfully queued.

-EBUSY if work queue under nmi is full.

-EINVAL if sig is invalid.

-EPERM if no permission to send the sig.

-EAGAIN if bpf program can try again.

s64 bpf_tcp_gen_syncookie(void *sk,** void *iph**,** u32 iph_len**,** struct tcphdr *th**,** u32 th_len**)****

Description
Try to issue a SYN cookie for the packet with corresponding IP/TCP headers, iph and th, on the listening socket in sk.

iph points to the start of the IPv4 or IPv6 header, while iph_len contains sizeof(struct iphdr) or sizeof(struct ipv6hdr).

th points to the start of the TCP header, while th_len contains the length of the TCP header with options (at least sizeof(struct tcphdr)).

Return
On success, lower 32 bits hold the generated SYN cookie in followed by 16 bits which hold the MSS value for that cookie, and the top 16 bits are unused.

On failure, the returned value is one of the following:

-EINVAL SYN cookie cannot be issued due to error

-ENOENT SYN cookie should not be issued (no SYN flood)

-EOPNOTSUPP kernel configuration does not enable SYN cookies

-EPROTONOSUPPORT IP packet version is not 4 or 6

long bpf_skb_output(void *ctx,** struct bpf_map *map**,** u64 flags**,** void *data**,** u64 size**)****

Description
Write raw data blob into a special BPF perf event held by map of type BPF_MAP_TYPE_PERF_EVENT_ARRAY. This perf event must have the following attributes: PERF_SAMPLE_RAW as sample_type, PERF_TYPE_SOFTWARE as type, and PERF_COUNT_SW_BPF_OUTPUT as config.

The flags are used to indicate the index in map for which the value must be put, masked with BPF_F_INDEX_MASK. Alternatively, flags can be set to BPF_F_CURRENT_CPU to indicate that the index of the current CPU core should be used.

The value to write, of size, is passed through eBPF stack and pointed by data.

ctx is a pointer to in-kernel struct sk_buff.

This helper is similar to bpf_perf_event_output() but restricted to raw_tracepoint bpf programs.

Return
0 on success, or a negative error in case of failure.

long bpf_probe_read_user(void *dst,** u32 size**,** const void *unsafe_ptr**)****

Description
Safely attempt to read size bytes from user space address unsafe_ptr and store the data in dst.

Return
0 on success, or a negative error in case of failure.

long bpf_probe_read_kernel(void *dst,** u32 size**,** const void *unsafe_ptr**)****

Description
Safely attempt to read size bytes from kernel space address unsafe_ptr and store the data in dst.

Return
0 on success, or a negative error in case of failure.

long bpf_probe_read_user_str(void *dst,** u32 size**,** const void *unsafe_ptr**)****

Description
Copy a NUL terminated string from an unsafe user address unsafe_ptr to dst. The size should include the terminating NUL byte. In case the string length is smaller than size, the target is not padded with further NUL bytes. If the string length is larger than size, just size-1 bytes are copied and the last byte is set to NUL.

On success, returns the number of bytes that were written, including the terminal NUL. This makes this helper useful in tracing programs for reading strings, and more importantly to get its length at runtime. See the following snippet:

SEC(“kprobe/sys_open”) void bpf_sys_open(struct pt_regs *ctx) { char buf[PATHLEN]; // PATHLEN is defined to 256 int res = bpf_probe_read_user_str(buf, sizeof(buf), ctx->di);

        // Consume buf, for example push it to
        // userspace via bpf_perf_event_output(); we
        // can use res (the string length) as event
        // size, after checking its boundaries.
}

In comparison, using bpf_probe_read_user() helper here instead to read the string would require to estimate the length at compile time, and would often result in copying more memory than necessary.

Another useful use case is when parsing individual process arguments or individual environment variables navigating current**->mm->arg_start** and current**->mm->env_start**: using this helper and the return value, one can quickly iterate at the right offset of the memory area.

Return
On success, the strictly positive length of the output string, including the trailing NUL character. On error, a negative value.

long bpf_probe_read_kernel_str(void *dst,** u32 size**,** const void *unsafe_ptr**)****

Description
Copy a NUL terminated string from an unsafe kernel address unsafe_ptr to dst. Same semantics as with bpf_probe_read_user_str() apply.

Return
On success, the strictly positive length of the string, including the trailing NUL character. On error, a negative value.

long bpf_tcp_send_ack(void *tp,** u32 rcv_nxt**)****

Description
Send out a tcp-ack. tp is the in-kernel struct tcp_sock. rcv_nxt is the ack_seq to be sent out.

Return
0 on success, or a negative error in case of failure.

long bpf_send_signal_thread(u32 sig)****

Description
Send signal sig to the thread corresponding to the current task.

Return
0 on success or successfully queued.

-EBUSY if work queue under nmi is full.

-EINVAL if sig is invalid.

-EPERM if no permission to send the sig.

-EAGAIN if bpf program can try again.

u64 bpf_jiffies64(void)

Description
Obtain the 64bit jiffies

Return
The 64 bit jiffies

long bpf_read_branch_records(struct bpf_perf_event_data *ctx,** void *buf**,** u32 size**,** u64 flags**)****

Description
For an eBPF program attached to a perf event, retrieve the branch records (struct perf_branch_entry) associated to ctx and store it in the buffer pointed by buf up to size size bytes.

Return
On success, number of bytes written to buf. On error, a negative value.

The flags can be set to BPF_F_GET_BRANCH_RECORDS_SIZE to instead return the number of bytes required to store all the branch entries. If this flag is set, buf may be NULL.

-EINVAL if arguments invalid or size not a multiple of sizeof(struct perf_branch_entry).

-ENOENT if architecture does not support branch records.

long bpf_get_ns_current_pid_tgid(u64 dev,** u64 ino**,** struct bpf_pidns_info *nsdata**,** u32 size**)****

Description
Returns 0 on success, values for pid and tgid as seen from the current namespace will be returned in nsdata.

Return
0 on success, or one of the following in case of failure:

-EINVAL if dev and inum supplied don’t match dev_t and inode number with nsfs of current task, or if dev conversion to dev_t lost high bits.

-ENOENT if pidns does not exists for the current task.

long bpf_xdp_output(void *ctx,** struct bpf_map *map**,** u64 flags**,** void *data**,** u64 size**)****

Description
Write raw data blob into a special BPF perf event held by map of type BPF_MAP_TYPE_PERF_EVENT_ARRAY. This perf event must have the following attributes: PERF_SAMPLE_RAW as sample_type, PERF_TYPE_SOFTWARE as type, and PERF_COUNT_SW_BPF_OUTPUT as config.

The flags are used to indicate the index in map for which the value must be put, masked with BPF_F_INDEX_MASK. Alternatively, flags can be set to BPF_F_CURRENT_CPU to indicate that the index of the current CPU core should be used.

The value to write, of size, is passed through eBPF stack and pointed by data.

ctx is a pointer to in-kernel struct xdp_buff.

This helper is similar to bpf_perf_eventoutput() but restricted to raw_tracepoint bpf programs.

Return
0 on success, or a negative error in case of failure.

u64 bpf_get_netns_cookie(void *ctx)****

Description
Retrieve the cookie (generated by the kernel) of the network namespace the input ctx is associated with. The network namespace cookie remains stable for its lifetime and provides a global identifier that can be assumed unique. If ctx is NULL, then the helper returns the cookie for the initial network namespace. The cookie itself is very similar to that of bpf_get_socket_cookie() helper, but for network namespaces instead of sockets.

Return
A 8-byte long opaque number.

u64 bpf_get_current_ancestor_cgroup_id(int ancestor_level)****

Description
Return id of cgroup v2 that is ancestor of the cgroup associated with the current task at the ancestor_level. The root cgroup is at ancestor_level zero and each step down the hierarchy increments the level. If ancestor_level == level of cgroup associated with the current task, then return value will be the same as that of bpf_get_current_cgroup_id().

The helper is useful to implement policies based on cgroups that are upper in hierarchy than immediate cgroup associated with the current task.

The format of returned id and helper limitations are same as in bpf_get_current_cgroup_id().

Return
The id is returned or 0 in case the id could not be retrieved.

long bpf_sk_assign(struct sk_buff *skb,** void *sk**,** u64 flags**)****

Description
Helper is overloaded depending on BPF program type. This description applies to BPF_PROG_TYPE_SCHED_CLS and BPF_PROG_TYPE_SCHED_ACT programs.

Assign the sk to the skb. When combined with appropriate routing configuration to receive the packet towards the socket, will cause skb to be delivered to the specified socket. Subsequent redirection of skb via bpf_redirect(), bpf_clone_redirect() or other methods outside of BPF may interfere with successful delivery to the socket.

This operation is only valid from TC ingress path.

The flags argument must be zero.

Return
0 on success, or a negative error in case of failure:

-EINVAL if specified flags are not supported.

-ENOENT if the socket is unavailable for assignment.

-ENETUNREACH if the socket is unreachable (wrong netns).

-EOPNOTSUPP if the operation is not supported, for example a call from outside of TC ingress.

long bpf_sk_assign(struct bpf_sk_lookup *ctx,** struct bpf_sock *sk**,** u64 flags**)****

Description
Helper is overloaded depending on BPF program type. This description applies to BPF_PROG_TYPE_SK_LOOKUP programs.

Select the sk as a result of a socket lookup.

For the operation to succeed passed socket must be compatible with the packet description provided by the ctx object.

L4 protocol (IPPROTO_TCP or IPPROTO_UDP) must be an exact match. While IP family (AF_INET or AF_INET6) must be compatible, that is IPv6 sockets that are not v6-only can be selected for IPv4 packets.

Only TCP listeners and UDP unconnected sockets can be selected. sk can also be NULL to reset any previous selection.

flags argument can combination of following values:

  • BPF_SK_LOOKUP_F_REPLACE to override the previous socket selection, potentially done by a BPF program that ran before us.

  • BPF_SK_LOOKUP_F_NO_REUSEPORT to skip load-balancing within reuseport group for the socket being selected.

On success ctx->sk will point to the selected socket.

Return
0 on success, or a negative errno in case of failure.

  • -EAFNOSUPPORT if socket family (sk->family) is not compatible with packet family (ctx->family).

  • -EEXIST if socket has been already selected, potentially by another program, and BPF_SK_LOOKUP_F_REPLACE flag was not specified.

  • -EINVAL if unsupported flags were specified.

  • -EPROTOTYPE if socket L4 protocol (sk->protocol) doesn’t match packet protocol (ctx->protocol).

  • -ESOCKTNOSUPPORT if socket is not in allowed state (TCP listening or UDP unconnected).

u64 bpf_ktime_get_boot_ns(void)

Description
Return the time elapsed since system boot, in nanoseconds. Does include the time the system was suspended. See: clock_gettime(CLOCK_BOOTTIME)

Return
Current ktime.

long bpf_seq_printf(struct seq_file *m,** const char *fmt**,** u32 fmt_size**,** const void *data**,** u32 data_len**)****

Description
bpf_seq_printf() uses seq_file seq_printf() to print out the format string. The m represents the seq_file. The fmt and fmt_size are for the format string itself. The data and data_len are format string arguments. The data are a u64 array and corresponding format string values are stored in the array. For strings and pointers where pointees are accessed, only the pointer values are stored in the data array. The data_len is the size of data in bytes - must be a multiple of 8.

Formats %s, %p{i,I}{4,6} requires to read kernel memory. Reading kernel memory may fail due to either invalid address or valid address but requiring a major memory fault. If reading kernel memory fails, the string for %s will be an empty string, and the ip address for %p{i,I}{4,6} will be 0. Not returning error to bpf program is consistent with what bpf_trace_printk() does for now.

Return
0 on success, or a negative error in case of failure:

-EBUSY if per-CPU memory copy buffer is busy, can try again by returning 1 from bpf program.

-EINVAL if arguments are invalid, or if fmt is invalid/unsupported.

-E2BIG if fmt contains too many format specifiers.

-EOVERFLOW if an overflow happened: The same object will be tried again.

long bpf_seq_write(struct seq_file *m,** const void *data**,** u32 len**)****

Description
bpf_seq_write() uses seq_file seq_write() to write the data. The m represents the seq_file. The data and len represent the data to write in bytes.

Return
0 on success, or a negative error in case of failure:

-EOVERFLOW if an overflow happened: The same object will be tried again.

u64 bpf_sk_cgroup_id(void *sk)****

Description
Return the cgroup v2 id of the socket sk.

sk must be a non-NULL pointer to a socket, e.g. one returned from bpf_sk_lookup_xxx(), bpf_sk_fullsock(), etc. The format of returned id is same as in bpf_skb_cgroup_id().

This helper is available only if the kernel was compiled with the CONFIG_SOCK_CGROUP_DATA configuration option.

Return
The id is returned or 0 in case the id could not be retrieved.

u64 bpf_sk_ancestor_cgroup_id(void *sk,** int ancestor_level**)****

Description
Return id of cgroup v2 that is ancestor of cgroup associated with the sk at the ancestor_level. The root cgroup is at ancestor_level zero and each step down the hierarchy increments the level. If ancestor_level == level of cgroup associated with sk, then return value will be same as that of bpf_sk_cgroup_id().

The helper is useful to implement policies based on cgroups that are upper in hierarchy than immediate cgroup associated with sk.

The format of returned id and helper limitations are same as in bpf_sk_cgroup_id().

Return
The id is returned or 0 in case the id could not be retrieved.

long bpf_ringbuf_output(void *ringbuf,** void *data**,** u64 size**,** u64 flags**)****

Description
Copy size bytes from data into a ring buffer ringbuf. If BPF_RB_NO_WAKEUP is specified in flags, no notification of new data availability is sent. If BPF_RB_FORCE_WAKEUP is specified in flags, notification of new data availability is sent unconditionally. If 0 is specified in flags, an adaptive notification of new data availability is sent.

An adaptive notification is a notification sent whenever the user-space process has caught up and consumed all available payloads. In case the user-space process is still processing a previous payload, then no notification is needed as it will process the newly added payload automatically.

Return
0 on success, or a negative error in case of failure.

void *bpf_ringbuf_reserve(void *ringbuf,** u64 size**,** u64 flags**)****

Description
Reserve size bytes of payload in a ring buffer ringbuf. flags must be 0.

Return
Valid pointer with size bytes of memory available; NULL, otherwise.

void bpf_ringbuf_submit(void *data,** u64 flags**)****

Description
Submit reserved ring buffer sample, pointed to by data. If BPF_RB_NO_WAKEUP is specified in flags, no notification of new data availability is sent. If BPF_RB_FORCE_WAKEUP is specified in flags, notification of new data availability is sent unconditionally. If 0 is specified in flags, an adaptive notification of new data availability is sent.

See ‘bpf_ringbuf_output()’ for the definition of adaptive notification.

Return
Nothing. Always succeeds.

void bpf_ringbuf_discard(void *data,** u64 flags**)****

Description
Discard reserved ring buffer sample, pointed to by data. If BPF_RB_NO_WAKEUP is specified in flags, no notification of new data availability is sent. If BPF_RB_FORCE_WAKEUP is specified in flags, notification of new data availability is sent unconditionally. If 0 is specified in flags, an adaptive notification of new data availability is sent.

See ‘bpf_ringbuf_output()’ for the definition of adaptive notification.

Return
Nothing. Always succeeds.

u64 bpf_ringbuf_query(void *ringbuf,** u64 flags**)****

Description
Query various characteristics of provided ring buffer. What exactly is queries is determined by flags:

  • BPF_RB_AVAIL_DATA: Amount of data not yet consumed.

  • BPF_RB_RING_SIZE: The size of ring buffer.

  • BPF_RB_CONS_POS: Consumer position (can wrap around).

  • BPF_RB_PROD_POS: Producer(s) position (can wrap around).

Data returned is just a momentary snapshot of actual values and could be inaccurate, so this facility should be used to power heuristics and for reporting, not to make 100% correct calculation.

Return
Requested value, or 0, if flags are not recognized.

long bpf_csum_level(struct sk_buff *skb,** u64 level**)****

Description
Change the skbs checksum level by one layer up or down, or reset it entirely to none in order to have the stack perform checksum validation. The level is applicable to the following protocols: TCP, UDP, GRE, SCTP, FCOE. For example, a decap of | ETH | IP | UDP | GUE | IP | TCP | into | ETH | IP | TCP | through bpf_skb_adjust_room() helper with passing in BPF_F_ADJ_ROOM_NO_CSUM_RESET flag would require one call to bpf_csum_level() with BPF_CSUM_LEVEL_DEC since the UDP header is removed. Similarly, an encap of the latter into the former could be accompanied by a helper call to bpf_csum_level() with BPF_CSUM_LEVEL_INC if the skb is still intended to be processed in higher layers of the stack instead of just egressing at tc.

There are three supported level settings at this time:

  • BPF_CSUM_LEVEL_INC: Increases skb->csum_level for skbs with CHECKSUM_UNNECESSARY.

  • BPF_CSUM_LEVEL_DEC: Decreases skb->csum_level for skbs with CHECKSUM_UNNECESSARY.

  • BPF_CSUM_LEVEL_RESET: Resets skb->csum_level to 0 and sets CHECKSUM_NONE to force checksum validation by the stack.

  • BPF_CSUM_LEVEL_QUERY: No-op, returns the current skb->csum_level.

Return
0 on success, or a negative error in case of failure. In the case of BPF_CSUM_LEVEL_QUERY, the current skb->csum_level is returned or the error code -EACCES in case the skb is not subject to CHECKSUM_UNNECESSARY.

struct tcp6_sock *bpf_skc_to_tcp6_sock(void *sk)****

Description
Dynamically cast a sk pointer to a tcp6_sock pointer.

Return
sk if casting is valid, or NULL otherwise.

struct tcp_sock *bpf_skc_to_tcp_sock(void *sk)****

Description
Dynamically cast a sk pointer to a tcp_sock pointer.

Return
sk if casting is valid, or NULL otherwise.

struct tcp_timewait_sock *bpf_skc_to_tcp_timewait_sock(void *sk)****

Description
Dynamically cast a sk pointer to a tcp_timewait_sock pointer.

Return
sk if casting is valid, or NULL otherwise.

struct tcp_request_sock *bpf_skc_to_tcp_request_sock(void *sk)****

Description
Dynamically cast a sk pointer to a tcp_request_sock pointer.

Return
sk if casting is valid, or NULL otherwise.

struct udp6_sock *bpf_skc_to_udp6_sock(void *sk)****

Description
Dynamically cast a sk pointer to a udp6_sock pointer.

Return
sk if casting is valid, or NULL otherwise.

long bpf_get_task_stack(struct task_struct *task,** void *buf**,** u32 size**,** u64 flags**)****

Description
Return a user or a kernel stack in bpf program provided buffer. Note: the user stack will only be populated if the task is the current task; all other tasks will return -EOPNOTSUPP. To achieve this, the helper needs task, which is a valid pointer to struct task_struct. To store the stacktrace, the bpf program provides buf with a nonnegative size.

The last argument, flags, holds the number of stack frames to skip (from 0 to 255), masked with BPF_F_SKIP_FIELD_MASK. The next bits can be used to set the following flags:

BPF_F_USER_STACK
Collect a user space stack instead of a kernel stack. The task must be the current task.

BPF_F_USER_BUILD_ID
Collect buildid+offset instead of ips for user stack, only valid if BPF_F_USER_STACK is also specified.

bpf_get_task_stack() can collect up to PERF_MAX_STACK_DEPTH both kernel and user frames, subject to sufficient large buffer size. Note that this limit can be controlled with the sysctl program, and that it should be manually increased in order to profile long user stacks (such as stacks for Java programs). To do so, use:

sysctl kernel.perf_event_max_stack=

Return
The non-negative copied buf length equal to or less than size on success, or a negative error in case of failure.

long bpf_load_hdr_opt(struct bpf_sock_ops *skops,** void *searchby_res**,** u32 len**,** u64 flags**)****

Description
Load header option. Support reading a particular TCP header option for bpf program (BPF_PROG_TYPE_SOCK_OPS).

If flags is 0, it will search the option from the skops**->skb_data**. The comment in struct bpf_sock_ops has details on what skb_data contains under different skops**->op**.

The first byte of the searchby_res specifies the kind that it wants to search.

If the searching kind is an experimental kind (i.e. 253 or 254 according to RFC6994). It also needs to specify the “magic” which is either 2 bytes or 4 bytes. It then also needs to specify the size of the magic by using the 2nd byte which is “kind-length” of a TCP header option and the “kind-length” also includes the first 2 bytes “kind” and “kind-length” itself as a normal TCP header option also does.

For example, to search experimental kind 254 with 2 byte magic 0xeB9F, the searchby_res should be [ 254, 4, 0xeB, 0x9F, 0, 0, …. 0 ].

To search for the standard window scale option (3), the searchby_res should be [ 3, 0, 0, …. 0 ]. Note, kind-length must be 0 for regular option.

Searching for No-Op (0) and End-of-Option-List (1) are not supported.

len must be at least 2 bytes which is the minimal size of a header option.

Supported flags:

  • BPF_LOAD_HDR_OPT_TCP_SYN to search from the saved_syn packet or the just-received syn packet.

Return
> 0 when found, the header option is copied to searchby_res. The return value is the total length copied. On failure, a negative error code is returned:

-EINVAL if a parameter is invalid.

-ENOMSG if the option is not found.

-ENOENT if no syn packet is available when BPF_LOAD_HDR_OPT_TCP_SYN is used.

-ENOSPC if there is not enough space. Only len number of bytes are copied.

-EFAULT on failure to parse the header options in the packet.

-EPERM if the helper cannot be used under the current skops**->op**.

long bpf_store_hdr_opt(struct bpf_sock_ops *skops,** const void *from**,** u32 len**,** u64 flags**)****

Description
Store header option. The data will be copied from buffer from with length len to the TCP header.

The buffer from should have the whole option that includes the kind, kind-length, and the actual option data. The len must be at least kind-length long. The kind-length does not have to be 4 byte aligned. The kernel will take care of the padding and setting the 4 bytes aligned value to th->doff.

This helper will check for duplicated option by searching the same option in the outgoing skb.

This helper can only be called during BPF_SOCK_OPS_WRITE_HDR_OPT_CB.

Return
0 on success, or negative error in case of failure:

-EINVAL If param is invalid.

-ENOSPC if there is not enough space in the header. Nothing has been written

-EEXIST if the option already exists.

-EFAULT on failure to parse the existing header options.

-EPERM if the helper cannot be used under the current skops**->op**.

long bpf_reserve_hdr_opt(struct bpf_sock_ops *skops,** u32 len**,** u64 flags**)****

Description
Reserve len bytes for the bpf header option. The space will be used by bpf_store_hdr_opt() later in BPF_SOCK_OPS_WRITE_HDR_OPT_CB.

If bpf_reserve_hdr_opt() is called multiple times, the total number of bytes will be reserved.

This helper can only be called during BPF_SOCK_OPS_HDR_OPT_LEN_CB.

Return
0 on success, or negative error in case of failure:

-EINVAL if a parameter is invalid.

-ENOSPC if there is not enough space in the header.

-EPERM if the helper cannot be used under the current skops**->op**.

void *bpf_inode_storage_get(struct bpf_map *map,** void *inode**,** void *value**,** u64 flags**)****

Description
Get a bpf_local_storage from an inode.

Logically, it could be thought of as getting the value from a map with inode as the key. From this perspective, the usage is not much different from bpf_map_lookup_elem(map, **&**inode) except this helper enforces the key must be an inode and the map must also be a BPF_MAP_TYPE_INODE_STORAGE.

Underneath, the value is stored locally at inode instead of the map. The map is used as the bpf-local-storage “type”. The bpf-local-storage “type” (i.e. the map) is searched against all bpf_local_storage residing at inode.

An optional flags (BPF_LOCAL_STORAGE_GET_F_CREATE) can be used such that a new bpf_local_storage will be created if one does not exist. value can be used together with BPF_LOCAL_STORAGE_GET_F_CREATE to specify the initial value of a bpf_local_storage. If value is NULL, the new bpf_local_storage will be zero initialized.

Return
A bpf_local_storage pointer is returned on success.

NULL if not found or there was an error in adding a new bpf_local_storage.

int bpf_inode_storage_delete(struct bpf_map *map,** void *inode**)****

Description
Delete a bpf_local_storage from an inode.

Return
0 on success.

-ENOENT if the bpf_local_storage cannot be found.

long bpf_d_path(struct path *path,** char *buf**,** u32 sz**)****

Description
Return full path for given struct path object, which needs to be the kernel BTF path object. The path is returned in the provided buffer buf of size sz and is zero terminated.

Return
On success, the strictly positive length of the string, including the trailing NUL character. On error, a negative value.

long bpf_copy_from_user(void *dst,** u32 size**,** const void *user_ptr**)****

Description
Read size bytes from user space address user_ptr and store the data in dst. This is a wrapper of copy_from_user().

Return
0 on success, or a negative error in case of failure.

long bpf_snprintf_btf(char *str,** u32 str_size**,** struct btf_ptr *ptr**,** u32 btf_ptr_size**,** u64 flags**)****

Description
Use BTF to store a string representation of ptr->ptr in str, using ptr->type_id. This value should specify the type that ptr->ptr points to. LLVM __builtin_btf_type_id(type, 1) can be used to look up vmlinux BTF type ids. Traversing the data structure using BTF, the type information and values are stored in the first str_size - 1 bytes of str. Safe copy of the pointer data is carried out to avoid kernel crashes during operation. Smaller types can use string space on the stack; larger programs can use map data to store the string representation.

The string can be subsequently shared with userspace via bpf_perf_event_output() or ring buffer interfaces. bpf_trace_printk() is to be avoided as it places too small a limit on string size to be useful.

flags is a combination of

BTF_F_COMPACT
no formatting around type information

BTF_F_NONAME
no struct/union member names/types

BTF_F_PTR_RAW
show raw (unobfuscated) pointer values; equivalent to printk specifier %px.

BTF_F_ZERO
show zero-valued struct/union members; they are not displayed by default

Return
The number of bytes that were written (or would have been written if output had to be truncated due to string size), or a negative error in cases of failure.

long bpf_seq_printf_btf(struct seq_file *m,** struct btf_ptr *ptr**,** u32 ptr_size**,** u64 flags**)****

Description
Use BTF to write to seq_write a string representation of ptr->ptr, using ptr->type_id as per bpf_snprintf_btf(). flags are identical to those used for bpf_snprintf_btf.

Return
0 on success or a negative error in case of failure.

u64 bpf_skb_cgroup_classid(struct sk_buff *skb)****

Description
See bpf_get_cgroup_classid() for the main description. This helper differs from bpf_get_cgroup_classid() in that the cgroup v1 net_cls class is retrieved only from the skb’s associated socket instead of the current process.

Return
The id is returned or 0 in case the id could not be retrieved.

long bpf_redirect_neigh(u32 ifindex,** struct bpf_redir_neigh *params**,** int plen**,** u64 flags**)****

Description
Redirect the packet to another net device of index ifindex and fill in L2 addresses from neighboring subsystem. This helper is somewhat similar to bpf_redirect(), except that it populates L2 addresses as well, meaning, internally, the helper relies on the neighbor lookup for the L2 address of the nexthop.

The helper will perform a FIB lookup based on the skb’s networking header to get the address of the next hop, unless this is supplied by the caller in the params argument. The plen argument indicates the len of params and should be set to 0 if params is NULL.

The flags argument is reserved and must be 0. The helper is currently only supported for tc BPF program types, and enabled for IPv4 and IPv6 protocols.

Return
The helper returns TC_ACT_REDIRECT on success or TC_ACT_SHOT on error.

void *bpf_per_cpu_ptr(const void *percpu_ptr,** u32 cpu**)****

Description
Take a pointer to a percpu ksym, percpu_ptr, and return a pointer to the percpu kernel variable on cpu. A ksym is an extern variable decorated with ‘__ksym’. For ksym, there is a global var (either static or global) defined of the same name in the kernel. The ksym is percpu if the global var is percpu. The returned pointer points to the global percpu var on cpu.

bpf_per_cpu_ptr() has the same semantic as per_cpu_ptr() in the kernel, except that bpf_per_cpu_ptr() may return NULL. This happens if cpu is larger than nr_cpu_ids. The caller of bpf_per_cpu_ptr() must check the returned value.

Return
A pointer pointing to the kernel percpu variable on cpu, or NULL, if cpu is invalid.

void *bpf_this_cpu_ptr(const void *percpu_ptr)****

Description
Take a pointer to a percpu ksym, percpu_ptr, and return a pointer to the percpu kernel variable on this cpu. See the description of ‘ksym’ in bpf_per_cpu_ptr().

bpf_this_cpu_ptr() has the same semantic as this_cpu_ptr() in the kernel. Different from bpf_per_cpu_ptr(), it would never return NULL.

Return
A pointer pointing to the kernel percpu variable on this cpu.

long bpf_redirect_peer(u32 ifindex,** u64 flags**)****

Description
Redirect the packet to another net device of index ifindex. This helper is somewhat similar to bpf_redirect(), except that the redirection happens to the ifindex’ peer device and the netns switch takes place from ingress to ingress without going through the CPU’s backlog queue.

The flags argument is reserved and must be 0. The helper is currently only supported for tc BPF program types at the ingress hook and for veth device types. The peer device must reside in a different network namespace.

Return
The helper returns TC_ACT_REDIRECT on success or TC_ACT_SHOT on error.

void *bpf_task_storage_get(struct bpf_map *map,** struct task_struct *task**,** void *value**,** u64 flags**)****

Description
Get a bpf_local_storage from the task.

Logically, it could be thought of as getting the value from a map with task as the key. From this perspective, the usage is not much different from bpf_map_lookup_elem(map, **&**task) except this helper enforces the key must be a task_struct and the map must also be a BPF_MAP_TYPE_TASK_STORAGE.

Underneath, the value is stored locally at task instead of the map. The map is used as the bpf-local-storage “type”. The bpf-local-storage “type” (i.e. the map) is searched against all bpf_local_storage residing at task.

An optional flags (BPF_LOCAL_STORAGE_GET_F_CREATE) can be used such that a new bpf_local_storage will be created if one does not exist. value can be used together with BPF_LOCAL_STORAGE_GET_F_CREATE to specify the initial value of a bpf_local_storage. If value is NULL, the new bpf_local_storage will be zero initialized.

Return
A bpf_local_storage pointer is returned on success.

NULL if not found or there was an error in adding a new bpf_local_storage.

long bpf_task_storage_delete(struct bpf_map *map,** struct task_struct *task**)****

Description
Delete a bpf_local_storage from a task.

Return
0 on success.

-ENOENT if the bpf_local_storage cannot be found.

struct task_struct *bpf_get_current_task_btf(void)

Description
Return a BTF pointer to the “current” task. This pointer can also be used in helpers that accept an ARG_PTR_TO_BTF_ID of type task_struct.

Return
Pointer to the current task.

long bpf_bprm_opts_set(struct linux_binprm *bprm,** u64 flags**)****

Description
Set or clear certain options on bprm:

BPF_F_BPRM_SECUREEXEC Set the secureexec bit which sets the AT_SECURE auxv for glibc. The bit is cleared if the flag is not specified.

Return
-EINVAL if invalid flags are passed, zero otherwise.

u64 bpf_ktime_get_coarse_ns(void)

Description
Return a coarse-grained version of the time elapsed since system boot, in nanoseconds. Does not include time the system was suspended.

See: clock_gettime(CLOCK_MONOTONIC_COARSE)

Return
Current ktime.

long bpf_ima_inode_hash(struct inode *inode,** void *dst**,** u32 size**)****

Description
Returns the stored IMA hash of the inode (if it’s available). If the hash is larger than size, then only size bytes will be copied to dst

Return
The hash_algo is returned on success, -EOPNOTSUP if IMA is disabled or -EINVAL if invalid arguments are passed.

struct socket *bpf_sock_from_file(struct file *file)****

Description
If the given file represents a socket, returns the associated socket.

Return
A pointer to a struct socket on success or NULL if the file is not a socket.

long bpf_check_mtu(void *ctx,** u32 ifindex**,** u32 *mtu_len**,** s32 len_diff**,** u64 flags**)****

Description
Check packet size against exceeding MTU of net device (based on ifindex). This helper will likely be used in combination with helpers that adjust/change the packet size.

The argument len_diff can be used for querying with a planned size change. This allows to check MTU prior to changing packet ctx. Providing a len_diff adjustment that is larger than the actual packet size (resulting in negative packet size) will in principle not exceed the MTU, which is why it is not considered a failure. Other BPF helpers are needed for performing the planned size change; therefore the responsibility for catching a negative packet size belongs in those helpers.

Specifying ifindex zero means the MTU check is performed against the current net device. This is practical if this isn’t used prior to redirect.

On input mtu_len must be a valid pointer, else verifier will reject BPF program. If the value mtu_len is initialized to zero then the ctx packet size is use. When value mtu_len is provided as input this specify the L3 length that the MTU check is done against. Remember XDP and TC length operate at L2, but this value is L3 as this correlate to MTU and IP-header tot_len values which are L3 (similar behavior as bpf_fib_lookup).

The Linux kernel route table can configure MTUs on a more specific per route level, which is not provided by this helper. For route level MTU checks use the bpf_fib_lookup() helper.

ctx is either struct xdp_md for XDP programs or struct sk_buff for tc cls_act programs.

The flags argument can be a combination of one or more of the following values:

BPF_MTU_CHK_SEGS
This flag will only works for ctx struct sk_buff. If packet context contains extra packet segment buffers (often knows as GSO skb), then MTU check is harder to check at this point, because in transmit path it is possible for the skb packet to get re-segmented (depending on net device features). This could still be a MTU violation, so this flag enables performing MTU check against segments, with a different violation return code to tell it apart. Check cannot use len_diff.

On return mtu_len pointer contains the MTU value of the net device. Remember the net device configured MTU is the L3 size, which is returned here and XDP and TC length operate at L2. Helper take this into account for you, but remember when using MTU value in your BPF-code.

Return

  • 0 on success, and populate MTU value in mtu_len pointer.

  • < 0 if any input argument is invalid (mtu_len not updated)

MTU violations return positive values, but also populate MTU value in mtu_len pointer, as this can be needed for implementing PMTU handing:

  • BPF_MTU_CHK_RET_FRAG_NEEDED

  • BPF_MTU_CHK_RET_SEGS_TOOBIG

long bpf_for_each_map_elem(struct bpf_map *map,** void *callback_fn**,** void *callback_ctx**,** u64 flags**)****

Description
For each element in map, call callback_fn function with map, callback_ctx and other map-specific parameters. The callback_fn should be a static function and the callback_ctx should be a pointer to the stack. The flags is used to control certain aspects of the helper. Currently, the flags must be 0.

The following are a list of supported map types and their respective expected callback signatures:

BPF_MAP_TYPE_HASH, BPF_MAP_TYPE_PERCPU_HASH, BPF_MAP_TYPE_LRU_HASH, BPF_MAP_TYPE_LRU_PERCPU_HASH, BPF_MAP_TYPE_ARRAY, BPF_MAP_TYPE_PERCPU_ARRAY

long (*callback_fn)(struct bpf_map *map, const void *key, void *value, void *ctx);

For per_cpu maps, the map_value is the value on the cpu where the bpf_prog is running.

If callback_fn return 0, the helper will continue to the next element. If return value is 1, the helper will skip the rest of elements and return. Other return values are not used now.

Return
The number of traversed map elements for success, -EINVAL for invalid flags.

long bpf_snprintf(char *str,** u32 str_size**,** const char *fmt**,** u64 *data**,** u32 data_len**)****

Description
Outputs a string into the str buffer of size str_size based on a format string stored in a read-only map pointed by fmt.

Each format specifier in fmt corresponds to one u64 element in the data array. For strings and pointers where pointees are accessed, only the pointer values are stored in the data array. The data_len is the size of data in bytes - must be a multiple of 8.

Formats %s and %p{i,I}{4,6} require to read kernel memory. Reading kernel memory may fail due to either invalid address or valid address but requiring a major memory fault. If reading kernel memory fails, the string for %s will be an empty string, and the ip address for %p{i,I}{4,6} will be 0. Not returning error to bpf program is consistent with what bpf_trace_printk() does for now.

Return
The strictly positive length of the formatted string, including the trailing zero character. If the return value is greater than str_size, str contains a truncated string, guaranteed to be zero-terminated except when str_size is 0.

Or -EBUSY if the per-CPU memory copy buffer is busy.

long bpf_sys_bpf(u32 cmd,** void *attr**,** u32 attr_size**)****

Description
Execute bpf syscall with given arguments.

Return
A syscall result.

long bpf_btf_find_by_name_kind(char *name,** int name_sz**,** u32 kind**,** int flags**)****

Description
Find BTF type with given name and kind in vmlinux BTF or in module’s BTFs.

Return
Returns btf_id and btf_obj_fd in lower and upper 32 bits.

long bpf_sys_close(u32 fd)****

Description
Execute close syscall for given FD.

Return
A syscall result.

long bpf_timer_init(struct bpf_timer *timer,** struct bpf_map *map**,** u64 flags**)****

Description
Initialize the timer. First 4 bits of flags specify clockid. Only CLOCK_MONOTONIC, CLOCK_REALTIME, CLOCK_BOOTTIME are allowed. All other bits of flags are reserved. The verifier will reject the program if timer is not from the same map.

Return
0 on success. -EBUSY if timer is already initialized. -EINVAL if invalid flags are passed. -EPERM if timer is in a map that doesn’t have any user references. The user space should either hold a file descriptor to a map with timers or pin such map in bpffs. When map is unpinned or file descriptor is closed all timers in the map will be cancelled and freed.

long bpf_timer_set_callback(struct bpf_timer *timer,** void *callback_fn**)****

Description
Configure the timer to call callback_fn static function.

Return
0 on success. -EINVAL if timer was not initialized with bpf_timer_init() earlier. -EPERM if timer is in a map that doesn’t have any user references. The user space should either hold a file descriptor to a map with timers or pin such map in bpffs. When map is unpinned or file descriptor is closed all timers in the map will be cancelled and freed.

long bpf_timer_start(struct bpf_timer *timer,** u64 nsecs**,** u64 flags**)****

Description
Set timer expiration N nanoseconds from the current time. The configured callback will be invoked in soft irq context on some cpu and will not repeat unless another bpf_timer_start() is made. In such case the next invocation can migrate to a different cpu. Since struct bpf_timer is a field inside map element the map owns the timer. The bpf_timer_set_callback() will increment refcnt of BPF program to make sure that callback_fn code stays valid. When user space reference to a map reaches zero all timers in a map are cancelled and corresponding program’s refcnts are decremented. This is done to make sure that Ctrl-C of a user process doesn’t leave any timers running. If map is pinned in bpffs the callback_fn can re-arm itself indefinitely. bpf_map_update/delete_elem() helpers and user space sys_bpf commands cancel and free the timer in the given map element. The map can contain timers that invoke callback_fn-s from different programs. The same callback_fn can serve different timers from different maps if key/value layout matches across maps. Every bpf_timer_set_callback() can have different callback_fn.

flags can be one of:

BPF_F_TIMER_ABS
Start the timer in absolute expire value instead of the default relative one.

BPF_F_TIMER_CPU_PIN
Timer will be pinned to the CPU of the caller.

Return
0 on success. -EINVAL if timer was not initialized with bpf_timer_init() earlier or invalid flags are passed.

long bpf_timer_cancel(struct bpf_timer *timer)****

Description
Cancel the timer and wait for callback_fn to finish if it was running.

Return
0 if the timer was not active. 1 if the timer was active. -EINVAL if timer was not initialized with bpf_timer_init() earlier. -EDEADLK if callback_fn tried to call bpf_timer_cancel() on its own timer which would have led to a deadlock otherwise.

u64 bpf_get_func_ip(void *ctx)****

Description
Get address of the traced function (for tracing and kprobe programs).

When called for kprobe program attached as uprobe it returns probe address for both entry and return uprobe.

Return
Address of the traced function for kprobe. 0 for kprobes placed within the function (not at the entry). Address of the probe for uprobe and return uprobe.

u64 bpf_get_attach_cookie(void *ctx)****

Description
Get bpf_cookie value provided (optionally) during the program attachment. It might be different for each individual attachment, even if BPF program itself is the same. Expects BPF program context ctx as a first argument.

Supported for the following program types:

  • kprobe/uprobe;

  • tracepoint;

  • perf_event.

Return
Value specified by user at BPF link creation/attachment time or 0, if it was not specified.

long bpf_task_pt_regs(struct task_struct *task)****

Description
Get the struct pt_regs associated with task.

Return
A pointer to struct pt_regs.

long bpf_get_branch_snapshot(void *entries,** u32 size**,** u64 flags**)****

Description
Get branch trace from hardware engines like Intel LBR. The hardware engine is stopped shortly after the helper is called. Therefore, the user need to filter branch entries based on the actual use case. To capture branch trace before the trigger point of the BPF program, the helper should be called at the beginning of the BPF program.

The data is stored as struct perf_branch_entry into output buffer entries. size is the size of entries in bytes. flags is reserved for now and must be zero.

Return
On success, number of bytes written to buf. On error, a negative value.

-EINVAL if flags is not zero.

-ENOENT if architecture does not support branch records.

long bpf_trace_vprintk(const char *fmt,** u32 fmt_size**,** const void *data**,** u32 data_len**)****

Description
Behaves like bpf_trace_printk() helper, but takes an array of u64 to format and can handle more format args as a result.

Arguments are to be used as in bpf_seq_printf() helper.

Return
The number of bytes written to the buffer, or a negative error in case of failure.

struct unix_sock *bpf_skc_to_unix_sock(void *sk)****

Description
Dynamically cast a sk pointer to a unix_sock pointer.

Return
sk if casting is valid, or NULL otherwise.

long bpf_kallsyms_lookup_name(const char *name,** int name_sz**,** int flags**,** u64 *res**)****

Description
Get the address of a kernel symbol, returned in res. res is set to 0 if the symbol is not found.

Return
On success, zero. On error, a negative value.

-EINVAL if flags is not zero.

-EINVAL if string name is not the same size as name_sz.

-ENOENT if symbol is not found.

-EPERM if caller does not have permission to obtain kernel address.

long bpf_find_vma(struct task_struct *task,** u64 addr**,** void *callback_fn**,** void *callback_ctx**,** u64 flags**)****

Description
Find vma of task that contains addr, call callback_fn function with task, vma, and callback_ctx. The callback_fn should be a static function and the callback_ctx should be a pointer to the stack. The flags is used to control certain aspects of the helper. Currently, the flags must be 0.

The expected callback signature is

long (*callback_fn)(struct task_struct *task, struct vm_area_struct *vma, void *callback_ctx);

Return
0 on success. -ENOENT if task->mm is NULL, or no vma contains addr. -EBUSY if failed to try lock mmap_lock. -EINVAL for invalid flags.

long bpf_loop(u32 nr_loops,** void *callback_fn**,** void *callback_ctx**,** u64 flags**)****

Description
For nr_loops, call callback_fn function with callback_ctx as the context parameter. The callback_fn should be a static function and the callback_ctx should be a pointer to the stack. The flags is used to control certain aspects of the helper. Currently, the flags must be 0. Currently, nr_loops is limited to 1 << 23 (~8 million) loops.

long (*callback_fn)(u32 index, void *ctx);

where index is the current index in the loop. The index is zero-indexed.

If callback_fn returns 0, the helper will continue to the next loop. If return value is 1, the helper will skip the rest of the loops and return. Other return values are not used now, and will be rejected by the verifier.

Return
The number of loops performed, -EINVAL for invalid flags, -E2BIG if nr_loops exceeds the maximum number of loops.

long bpf_strncmp(const char *s1,** u32 s1_sz**,** const char *s2**)****

Description
Do strncmp() between s1 and s2. s1 doesn’t need to be null-terminated and s1_sz is the maximum storage size of s1. s2 must be a read-only string.

Return
An integer less than, equal to, or greater than zero if the first s1_sz bytes of s1 is found to be less than, to match, or be greater than s2.

long bpf_get_func_arg(void *ctx,** u32 n**,** u64 *value**)****

Description
Get n-th argument register (zero based) of the traced function (for tracing programs) returned in value.

Return
0 on success. -EINVAL if n >= argument register count of traced function.

long bpf_get_func_ret(void *ctx,** u64 *value**)****

Description
Get return value of the traced function (for tracing programs) in value.

Return
0 on success. -EOPNOTSUPP for tracing programs other than BPF_TRACE_FEXIT or BPF_MODIFY_RETURN.

long bpf_get_func_arg_cnt(void *ctx)****

Description
Get number of registers of the traced function (for tracing programs) where function arguments are stored in these registers.

Return
The number of argument registers of the traced function.

int bpf_get_retval(void)

Description
Get the BPF program’s return value that will be returned to the upper layers.

This helper is currently supported by cgroup programs and only by the hooks where BPF program’s return value is returned to the userspace via errno.

Return
The BPF program’s return value.

int bpf_set_retval(int retval)****

Description
Set the BPF program’s return value that will be returned to the upper layers.

This helper is currently supported by cgroup programs and only by the hooks where BPF program’s return value is returned to the userspace via errno.

Note that there is the following corner case where the program exports an error via bpf_set_retval but signals success via ‘return 1’:

bpf_set_retval(-EPERM); return 1;

In this case, the BPF program’s return value will use helper’s -EPERM. This still holds true for cgroup/bind{4,6} which supports extra ‘return 3’ success case.

Return
0 on success, or a negative error in case of failure.

u64 bpf_xdp_get_buff_len(struct xdp_buff *xdp_md)****

Description
Get the total size of a given xdp buff (linear and paged area)

Return
The total size of a given xdp buffer.

long bpf_xdp_load_bytes(struct xdp_buff *xdp_md,** u32 offset**,** void *buf**,** u32 len**)****

Description
This helper is provided as an easy way to load data from a xdp buffer. It can be used to load len bytes from offset from the frame associated to xdp_md, into the buffer pointed by buf.

Return
0 on success, or a negative error in case of failure.

long bpf_xdp_store_bytes(struct xdp_buff *xdp_md,** u32 offset**,** void *buf**,** u32 len**)****

Description
Store len bytes from buffer buf into the frame associated to xdp_md, at offset.

Return
0 on success, or a negative error in case of failure.

long bpf_copy_from_user_task(void *dst,** u32 size**,** const void *user_ptr**,** struct task_struct *tsk**,** u64 flags**)****

Description
Read size bytes from user space address user_ptr in tsk’s address space, and stores the data in dst. flags is not used yet and is provided for future extensibility. This helper can only be used by sleepable programs.

Return
0 on success, or a negative error in case of failure. On error dst buffer is zeroed out.

long bpf_skb_set_tstamp(struct sk_buff *skb,** u64 tstamp**,** u32 tstamp_type**)****

Description
Change the __sk_buff->tstamp_type to tstamp_type and set tstamp to the __sk_buff->tstamp together.

If there is no need to change the __sk_buff->tstamp_type, the tstamp value can be directly written to __sk_buff->tstamp instead.

BPF_SKB_TSTAMP_DELIVERY_MONO is the only tstamp that will be kept during bpf_redirect_*(). A non zero tstamp must be used with the BPF_SKB_TSTAMP_DELIVERY_MONO tstamp_type.

A BPF_SKB_TSTAMP_UNSPEC tstamp_type can only be used with a zero tstamp.

Only IPv4 and IPv6 skb->protocol are supported.

This function is most useful when it needs to set a mono delivery time to __sk_buff->tstamp and then bpf_redirect_*() to the egress of an iface. For example, changing the (rcv) timestamp in __sk_buff->tstamp at ingress to a mono delivery time and then bpf_redirect_*() to sch_fq@phy-dev.

Return
0 on success. -EINVAL for invalid input -EOPNOTSUPP for unsupported protocol

long bpf_ima_file_hash(struct file *file,** void *dst**,** u32 size**)****

Description
Returns a calculated IMA hash of the file. If the hash is larger than size, then only size bytes will be copied to dst

Return
The hash_algo is returned on success, -EOPNOTSUP if the hash calculation failed or -EINVAL if invalid arguments are passed.

void *bpf_kptr_xchg(void *map_value,** void *ptr**)****

Description
Exchange kptr at pointer map_value with ptr, and return the old value. ptr can be NULL, otherwise it must be a referenced pointer which will be released when this helper is called.

Return
The old value of kptr (which can be NULL). The returned pointer if not NULL, is a reference which must be released using its corresponding release function, or moved into a BPF map before program exit.

void *bpf_map_lookup_percpu_elem(struct bpf_map *map,** const void *key**,** u32 cpu**)****

Description
Perform a lookup in percpu map for an entry associated to key on cpu.

Return
Map value associated to key on cpu, or NULL if no entry was found or cpu is invalid.

struct mptcp_sock *bpf_skc_to_mptcp_sock(void *sk)****

Description
Dynamically cast a sk pointer to a mptcp_sock pointer.

Return
sk if casting is valid, or NULL otherwise.

long bpf_dynptr_from_mem(void *data,** u32 size**,** u64 flags**,** struct bpf_dynptr *ptr**)****

Description
Get a dynptr to local memory data.

data must be a ptr to a map value. The maximum size supported is DYNPTR_MAX_SIZE. flags is currently unused.

Return
0 on success, -E2BIG if the size exceeds DYNPTR_MAX_SIZE, -EINVAL if flags is not 0.

long bpf_ringbuf_reserve_dynptr(void *ringbuf,** u32 size**,** u64 flags**,** struct bpf_dynptr *ptr**)****

Description
Reserve size bytes of payload in a ring buffer ringbuf through the dynptr interface. flags must be 0.

Please note that a corresponding bpf_ringbuf_submit_dynptr or bpf_ringbuf_discard_dynptr must be called on ptr, even if the reservation fails. This is enforced by the verifier.

Return
0 on success, or a negative error in case of failure.

void bpf_ringbuf_submit_dynptr(struct bpf_dynptr *ptr,** u64 flags**)****

Description
Submit reserved ring buffer sample, pointed to by data, through the dynptr interface. This is a no-op if the dynptr is invalid/null.

For more information on flags, please see ‘bpf_ringbuf_submit’.

Return
Nothing. Always succeeds.

void bpf_ringbuf_discard_dynptr(struct bpf_dynptr *ptr,** u64 flags**)****

Description
Discard reserved ring buffer sample through the dynptr interface. This is a no-op if the dynptr is invalid/null.

For more information on flags, please see ‘bpf_ringbuf_discard’.

Return
Nothing. Always succeeds.

long bpf_dynptr_read(void *dst,** u32 len**,** const struct bpf_dynptr *src**,** u32 offset**,** u64 flags**)****

Description
Read len bytes from src into dst, starting from offset into src. flags is currently unused.

Return
0 on success, -E2BIG if offset + len exceeds the length of src’s data, -EINVAL if src is an invalid dynptr or if flags is not 0.

long bpf_dynptr_write(const struct bpf_dynptr *dst,** u32 offset**,** void *src**,** u32 len**,** u64 flags**)****

Description
Write len bytes from src into dst, starting from offset into dst.

flags must be 0 except for skb-type dynptrs.

For skb-type dynptrs:

  • All data slices of the dynptr are automatically invalidated after bpf_dynptr_write(). This is because writing may pull the skb and change the underlying packet buffer.

  • For flags, please see the flags accepted by bpf_skb_store_bytes().

Return
0 on success, -E2BIG if offset + len exceeds the length of dst’s data, -EINVAL if dst is an invalid dynptr or if dst is a read-only dynptr or if flags is not correct. For skb-type dynptrs, other errors correspond to errors returned by bpf_skb_store_bytes().

void *bpf_dynptr_data(const struct bpf_dynptr *ptr,** u32 offset**,** u32 len**)****

Description
Get a pointer to the underlying dynptr data.

len must be a statically known value. The returned data slice is invalidated whenever the dynptr is invalidated.

skb and xdp type dynptrs may not use bpf_dynptr_data. They should instead use bpf_dynptr_slice and bpf_dynptr_slice_rdwr.

Return
Pointer to the underlying dynptr data, NULL if the dynptr is read-only, if the dynptr is invalid, or if the offset and length is out of bounds.

s64 bpf_tcp_raw_gen_syncookie_ipv4(struct iphdr *iph,** struct tcphdr *th**,** u32 th_len**)****

Description
Try to issue a SYN cookie for the packet with corresponding IPv4/TCP headers, iph and th, without depending on a listening socket.

iph points to the IPv4 header.

th points to the start of the TCP header, while th_len contains the length of the TCP header (at least sizeof(struct tcphdr)).

Return
On success, lower 32 bits hold the generated SYN cookie in followed by 16 bits which hold the MSS value for that cookie, and the top 16 bits are unused.

On failure, the returned value is one of the following:

-EINVAL if th_len is invalid.

s64 bpf_tcp_raw_gen_syncookie_ipv6(struct ipv6hdr *iph,** struct tcphdr *th**,** u32 th_len**)****

Description
Try to issue a SYN cookie for the packet with corresponding IPv6/TCP headers, iph and th, without depending on a listening socket.

iph points to the IPv6 header.

th points to the start of the TCP header, while th_len contains the length of the TCP header (at least sizeof(struct tcphdr)).

Return
On success, lower 32 bits hold the generated SYN cookie in followed by 16 bits which hold the MSS value for that cookie, and the top 16 bits are unused.

On failure, the returned value is one of the following:

-EINVAL if th_len is invalid.

-EPROTONOSUPPORT if CONFIG_IPV6 is not builtin.

long bpf_tcp_raw_check_syncookie_ipv4(struct iphdr *iph,** struct tcphdr *th**)****

Description
Check whether iph and th contain a valid SYN cookie ACK without depending on a listening socket.

iph points to the IPv4 header.

th points to the TCP header.

Return
0 if iph and th are a valid SYN cookie ACK.

On failure, the returned value is one of the following:

-EACCES if the SYN cookie is not valid.

long bpf_tcp_raw_check_syncookie_ipv6(struct ipv6hdr *iph,** struct tcphdr *th**)****

Description
Check whether iph and th contain a valid SYN cookie ACK without depending on a listening socket.

iph points to the IPv6 header.

th points to the TCP header.

Return
0 if iph and th are a valid SYN cookie ACK.

On failure, the returned value is one of the following:

-EACCES if the SYN cookie is not valid.

-EPROTONOSUPPORT if CONFIG_IPV6 is not builtin.

u64 bpf_ktime_get_tai_ns(void)

Description
A nonsettable system-wide clock derived from wall-clock time but ignoring leap seconds. This clock does not experience discontinuities and backwards jumps caused by NTP inserting leap seconds as CLOCK_REALTIME does.

See: clock_gettime(CLOCK_TAI)

Return
Current ktime.

long bpf_user_ringbuf_drain(struct bpf_map *map,** void *callback_fn**,** void *ctx**,** u64 flags**)****

Description
Drain samples from the specified user ring buffer, and invoke the provided callback for each such sample:

long (*callback_fn)(const struct bpf_dynptr *dynptr, void *ctx);

If callback_fn returns 0, the helper will continue to try and drain the next sample, up to a maximum of BPF_MAX_USER_RINGBUF_SAMPLES samples. If the return value is 1, the helper will skip the rest of the samples and return. Other return values are not used now, and will be rejected by the verifier.

Return
The number of drained samples if no error was encountered while draining samples, or 0 if no samples were present in the ring buffer. If a user-space producer was epoll-waiting on this map, and at least one sample was drained, they will receive an event notification notifying them of available space in the ring buffer. If the BPF_RB_NO_WAKEUP flag is passed to this function, no wakeup notification will be sent. If the BPF_RB_FORCE_WAKEUP flag is passed, a wakeup notification will be sent even if no sample was drained.

On failure, the returned value is one of the following:

-EBUSY if the ring buffer is contended, and another calling context was concurrently draining the ring buffer.

-EINVAL if user-space is not properly tracking the ring buffer due to the producer position not being aligned to 8 bytes, a sample not being aligned to 8 bytes, or the producer position not matching the advertised length of a sample.

-E2BIG if user-space has tried to publish a sample which is larger than the size of the ring buffer, or which cannot fit within a struct bpf_dynptr.

void *bpf_cgrp_storage_get(struct bpf_map *map,** struct cgroup *cgroup**,** void *value**,** u64 flags**)****

Description
Get a bpf_local_storage from the cgroup.

Logically, it could be thought of as getting the value from a map with cgroup as the key. From this perspective, the usage is not much different from bpf_map_lookup_elem(map, **&**cgroup) except this helper enforces the key must be a cgroup struct and the map must also be a BPF_MAP_TYPE_CGRP_STORAGE.

In reality, the local-storage value is embedded directly inside of the cgroup object itself, rather than being located in the BPF_MAP_TYPE_CGRP_STORAGE map. When the local-storage value is queried for some map on a cgroup object, the kernel will perform an O(n) iteration over all of the live local-storage values for that cgroup object until the local-storage value for the map is found.

An optional flags (BPF_LOCAL_STORAGE_GET_F_CREATE) can be used such that a new bpf_local_storage will be created if one does not exist. value can be used together with BPF_LOCAL_STORAGE_GET_F_CREATE to specify the initial value of a bpf_local_storage. If value is NULL, the new bpf_local_storage will be zero initialized.

Return
A bpf_local_storage pointer is returned on success.

NULL if not found or there was an error in adding a new bpf_local_storage.

long bpf_cgrp_storage_delete(struct bpf_map *map,** struct cgroup *cgroup**)****

Description
Delete a bpf_local_storage from a cgroup.

Return
0 on success.

-ENOENT if the bpf_local_storage cannot be found.

EXAMPLES

Example usage for most of the eBPF helpers listed in this manual page are available within the Linux kernel sources, at the following locations:

  • samples/bpf/

  • tools/testing/selftests/bpf/

LICENSE

eBPF programs can have an associated license, passed along with the bytecode instructions to the kernel when the programs are loaded. The format for that string is identical to the one in use for kernel modules (Dual licenses, such as “Dual BSD/GPL”, may be used). Some helper functions are only accessible to programs that are compatible with the GNU General Public License (GNU GPL).

In order to use such helpers, the eBPF program must be loaded with the correct license string passed (via attr) to the bpf() system call, and this generally translates into the C source code of the program containing a line similar to the following:

char ____license[] attribute((section(“license”), used)) = “GPL”;

IMPLEMENTATION

This manual page is an effort to document the existing eBPF helper functions. But as of this writing, the BPF sub-system is under heavy development. New eBPF program or map types are added, along with new helper functions. Some helpers are occasionally made available for additional program types. So in spite of the efforts of the community, this page might not be up-to-date. If you want to check by yourself what helper functions exist in your kernel, or what types of programs they can support, here are some files among the kernel tree that you may be interested in:

  • include/uapi/linux/bpf.h is the main BPF header. It contains the full list of all helper functions, as well as many other BPF definitions including most of the flags, structs or constants used by the helpers.

  • net/core/filter.c contains the definition of most network-related helper functions, and the list of program types from which they can be used.

  • kernel/trace/bpf_trace.c is the equivalent for most tracing program-related helpers.

  • kernel/bpf/verifier.c contains the functions used to check that valid types of eBPF maps are used with a given helper function.

  • kernel/bpf/ directory contains other files in which additional helpers are defined (for cgroups, sockmaps, etc.).

  • The bpftool utility can be used to probe the availability of helper functions on the system (as well as supported program and map types, and a number of other parameters). To do so, run bpftool feature probe (see bpftool-feature(8) for details). Add the unprivileged keyword to list features available to unprivileged users.

Compatibility between helper functions and program types can generally be found in the files where helper functions are defined. Look for the struct bpf_func_proto objects and for functions returning them: these functions contain a list of helpers that a given program type can call. Note that the default: label of the switch … case used to filter helpers can call other functions, themselves allowing access to additional helpers. The requirement for GPL license is also in those struct bpf_func_proto.

Compatibility between helper functions and map types can be found in the check_map_func_compatibility() function in file kernel/bpf/verifier.c.

Helper functions that invalidate the checks on data and data_end pointers for network processing are listed in function bpf_helper_changes_pkt_data() in file net/core/filter.c.

SEE ALSO

bpf(2), bpftool(8), cgroups(7), ip(8), perf_event_open(2), sendmsg(2), socket(7), tc-bpf(8)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

82 - Linux cli command latin3

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command latin3 and provides detailed information about the command latin3, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the latin3.

NAME 🖥️ latin3 🖥️

3 - ISO/IEC 8859-3 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-3 encodes the characters used in certain Southeast European languages.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-3 characters

The following table displays the characters in ISO/IEC 8859-3 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-3 is also known as Latin-3.

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

83 - Linux cli command wlog

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command wlog and provides detailed information about the command wlog, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the wlog.

NAME 🖥️ wlog 🖥️

WinPR logging facility

DESCRIPTION

wLog is a configurable and flexible logging system used throughout WinPR and FreeRDP.

The primary concept is to have a hierarchy of loggers that can be be configured independently.

Appenders

WLog uses different appenders that define where the log output should be written to. If the application doesn’t explicitly configure the appenders the below described variable WLOG_APPENDER can be used to choose one appender.

The following kind of appenders are available:

Binary
Write the log data into a binary format file.

Console
The console appender writes to the console. Depending of the operating system the application runs on, the output might be handled differently. For example on android log print would be used.

File
The file appender writes the textual output to a file.

Udp
This appender sends the logging messages to a pre-defined remote host via UDP.

If no target is set the default one 127.0.0.1:20000 is used. To receive the log messages one can use netcat. To receive the default target the following command can be used: nc -u 127.0.0.1 -p 20000 -l

Syslog
Use syslog for outputting the debug messages.

Journald
This appender outputs messages to journald.

Levels

The WLog are complementary, the higher level always includes the lower ones. The level list below is top down. Top the highest level.

TRACE
print everything including packets dumps

DEBUG
debug messages

INFO
general information

WARN
warnings

ERROR
errors

FATAL
fatal problems

OFF
completely disable the wlog output

Formats

The format a logger prints has the following possible options:

  1. log level

mn
module name

fl
file name

fn
function

ln
line number

pid
process id

tid
thread id

yr
year

mo
month

dw
day of week

hr
hour

  1. minute

se
second

  1. millisecond

A maximum of 16 options can be used per format string.

An example that generally sets the WLOG_PREFIX for xfreerdp would look like: WLOG_PREFIX=“pid=%pid:tid=%tid:fn=%fn -” xfreerdp /v:xxx

ENVIRONMENT

WLOG_APPENDER
The kind of appender, the accepted values are: CONSOLE, FILE, BINARY, SYSLOG, JOURNALD or UDP

WLOG_PREFIX
configure the prefix used for outputting the message (see Format for more details and examples)

WLOG_LEVEL
the level to output messages for

WLOG_FILTER
sets a filter for WLog messages. Only the filtered messages are printed. The format of the filter is a series of <logger name>:<level> separated by comas

example: WLOG_FILTER=core.channel:DEBUG,dummy:TRACE will display debug messages for the core.channel logger and trace level for the dummy logger

WLOG_FILEAPPENDER_OUTPUT_FILE_PATH
When using the file appender it may contains the output log file’s path

WLOG_FILEAPPENDER_OUTPUT_FILE_NAME
When using the file appender it may contains the output log file’s name

WLOG_JOURNALD_ID
When using the systemd journal appender, this variable contains the id used with the journal (by default the executable’s name)

WLOG_UDP_TARGET
target to use for the UDP appender in the format host:port

BUGS

Please report any bugs using the bug reporting form on the FreeRDP web site

SEE ALSO

Additional information and the latest version is available at the web site: http://www.freerdp.com

AUTHOR

David Fort <[email protected]> wrote this manpage from materials written by Bernhard Miklautz <[email protected]>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

84 - Linux cli command life_cycle-randssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command life_cycle-randssl and provides detailed information about the command life_cycle-randssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the life_cycle-randssl.

NAME 🖥️ life_cycle-randssl 🖥️

rand - The RAND algorithm life-cycle

DESCRIPTION

All random number generator (RANDs) go through a number of stages in their life-cycle:

start
This state represents the RAND before it has been allocated. It is the starting state for any life-cycle transitions.

newed
This state represents the RAND after it has been allocated but unable to generate any output.

instantiated
This state represents the RAND when it is set up and capable of generating output.

uninstantiated
This state represents the RAND when it has been shutdown and it is no longer capable of generating output.

freed
This state is entered when the RAND is freed. It is the terminal state for all life-cycle transitions.

State Transition Diagram

The usual life-cycle of a RAND is illustrated: +————————-+ | start | +————————-+ | | EVP_RAND_CTX_new v +————————-+ | newed | +————————-+ | | EVP_RAND_instantiate v EVP_RAND_generate +————————-+ +——————– | | | | instantiated | +——————-> | | <+ +————————-+ ’ | ’ | EVP_RAND_uninstantiate ’ EVP_RAND_instantiate v ’ +————————-+ ’ | uninstantiated | -+ +————————-+ | | EVP_RAND_CTX_free v +————————-+ | freed | +————————-+

Formal State Transitions

This section defines all of the legal state transitions. This is the canonical list. Function Call —————— Current State —————— start newed instantiated uninstantiated freed EVP_RAND_CTX_new newed EVP_RAND_instantiate instantiated EVP_RAND_generate instantiated EVP_RAND_uninstantiate uninstantiated EVP_RAND_CTX_free freed freed freed freed EVP_RAND_CTX_get_params newed instantiated uninstantiated freed EVP_RAND_CTX_set_params newed instantiated uninstantiated freed EVP_RAND_CTX_gettable_params newed instantiated uninstantiated freed EVP_RAND_CTX_settable_params newed instantiated uninstantiated freed

NOTES

At some point the EVP layer will begin enforcing the transitions described herein.

SEE ALSO

provider-rand (7), EVP_RAND (3).

HISTORY

The provider RAND interface was introduced in OpenSSL 3.0.

COPYRIGHT

Copyright 2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

85 - Linux cli command ALTER_DEFAULT_PRIVILEGES

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_DEFAULT_PRIVILEGES and provides detailed information about the command ALTER_DEFAULT_PRIVILEGES, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_DEFAULT_PRIVILEGES.

NAME 🖥️ ALTER_DEFAULT_PRIVILEGES 🖥️

define default access privileges

SYNOPSIS

ALTER DEFAULT PRIVILEGES
    [ FOR { ROLE | USER } target_role [, ...] ]
    [ IN SCHEMA schema_name [, ...] ]
    abbreviated_grant_or_revoke

where abbreviated_grant_or_revoke is one of:

GRANT { { SELECT | INSERT | UPDATE | DELETE | TRUNCATE | REFERENCES | TRIGGER }
    [, ...] | ALL [ PRIVILEGES ] }
    ON TABLES
    TO { [ GROUP ] role_name | PUBLIC } [, ...] [ WITH GRANT OPTION ]

GRANT { { USAGE | SELECT | UPDATE }
    [, ...] | ALL [ PRIVILEGES ] }
    ON SEQUENCES
    TO { [ GROUP ] role_name | PUBLIC } [, ...] [ WITH GRANT OPTION ]

GRANT { EXECUTE | ALL [ PRIVILEGES ] }
    ON { FUNCTIONS | ROUTINES }
    TO { [ GROUP ] role_name | PUBLIC } [, ...] [ WITH GRANT OPTION ]

GRANT { USAGE | ALL [ PRIVILEGES ] }
    ON TYPES
    TO { [ GROUP ] role_name | PUBLIC } [, ...] [ WITH GRANT OPTION ]

GRANT { { USAGE | CREATE }
    [, ...] | ALL [ PRIVILEGES ] }
    ON SCHEMAS
    TO { [ GROUP ] role_name | PUBLIC } [, ...] [ WITH GRANT OPTION ]

REVOKE [ GRANT OPTION FOR ]
    { { SELECT | INSERT | UPDATE | DELETE | TRUNCATE | REFERENCES | TRIGGER }
    [, ...] | ALL [ PRIVILEGES ] }
    ON TABLES
    FROM { [ GROUP ] role_name | PUBLIC } [, ...]
    [ CASCADE | RESTRICT ]

REVOKE [ GRANT OPTION FOR ]
    { { USAGE | SELECT | UPDATE }
    [, ...] | ALL [ PRIVILEGES ] }
    ON SEQUENCES
    FROM { [ GROUP ] role_name | PUBLIC } [, ...]
    [ CASCADE | RESTRICT ]

REVOKE [ GRANT OPTION FOR ]
    { EXECUTE | ALL [ PRIVILEGES ] }
    ON { FUNCTIONS | ROUTINES }
    FROM { [ GROUP ] role_name | PUBLIC } [, ...]
    [ CASCADE | RESTRICT ]

REVOKE [ GRANT OPTION FOR ]
    { USAGE | ALL [ PRIVILEGES ] }
    ON TYPES
    FROM { [ GROUP ] role_name | PUBLIC } [, ...]
    [ CASCADE | RESTRICT ]

REVOKE [ GRANT OPTION FOR ]
    { { USAGE | CREATE }
    [, ...] | ALL [ PRIVILEGES ] }
    ON SCHEMAS
    FROM { [ GROUP ] role_name | PUBLIC } [, ...]
    [ CASCADE | RESTRICT ]

DESCRIPTION

ALTER DEFAULT PRIVILEGES allows you to set the privileges that will be applied to objects created in the future. (It does not affect privileges assigned to already-existing objects.) Privileges can be set globally (i.e., for all objects created in the current database), or just for objects created in specified schemas.

While you can change your own default privileges and the defaults of roles that you are a member of, at object creation time, new object permissions are only affected by the default privileges of the current role, and are not inherited from any roles in which the current role is a member.

As explained in Section 5.7, the default privileges for any object type normally grant all grantable permissions to the object owner, and may grant some privileges to PUBLIC as well. However, this behavior can be changed by altering the global default privileges with ALTER DEFAULT PRIVILEGES.

Currently, only the privileges for schemas, tables (including views and foreign tables), sequences, functions, and types (including domains) can be altered. For this command, functions include aggregates and procedures. The words FUNCTIONS and ROUTINES are equivalent in this command. (ROUTINES is preferred going forward as the standard term for functions and procedures taken together. In earlier PostgreSQL releases, only the word FUNCTIONS was allowed. It is not possible to set default privileges for functions and procedures separately.)

Default privileges that are specified per-schema are added to whatever the global default privileges are for the particular object type. This means you cannot revoke privileges per-schema if they are granted globally (either by default, or according to a previous ALTER DEFAULT PRIVILEGES command that did not specify a schema). Per-schema REVOKE is only useful to reverse the effects of a previous per-schema GRANT.

Parameters

target_role

Change default privileges for objects created by the target_role, or the current role if unspecified.

schema_name

The name of an existing schema. If specified, the default privileges are altered for objects later created in that schema. If IN SCHEMA is omitted, the global default privileges are altered. IN SCHEMA is not allowed when setting privileges for schemas, since schemas cant be nested.

role_name

The name of an existing role to grant or revoke privileges for. This parameter, and all the other parameters in abbreviated_grant_or_revoke, act as described under GRANT(7) or REVOKE(7), except that one is setting permissions for a whole class of objects rather than specific named objects.

NOTES

Use psql(1)s \ddp command to obtain information about existing assignments of default privileges. The meaning of the privilege display is the same as explained for \dp in Section 5.7.

If you wish to drop a role for which the default privileges have been altered, it is necessary to reverse the changes in its default privileges or use DROP OWNED BY to get rid of the default privileges entry for the role.

EXAMPLES

Grant SELECT privilege to everyone for all tables (and views) you subsequently create in schema myschema, and allow role webuser to INSERT into them too:

ALTER DEFAULT PRIVILEGES IN SCHEMA myschema GRANT SELECT ON TABLES TO PUBLIC; ALTER DEFAULT PRIVILEGES IN SCHEMA myschema GRANT INSERT ON TABLES TO webuser;

Undo the above, so that subsequently-created tables wont have any more permissions than normal:

ALTER DEFAULT PRIVILEGES IN SCHEMA myschema REVOKE SELECT ON TABLES FROM PUBLIC; ALTER DEFAULT PRIVILEGES IN SCHEMA myschema REVOKE INSERT ON TABLES FROM webuser;

Remove the public EXECUTE permission that is normally granted on functions, for all functions subsequently created by role admin:

ALTER DEFAULT PRIVILEGES FOR ROLE admin REVOKE EXECUTE ON FUNCTIONS FROM PUBLIC;

Note however that you cannot accomplish that effect with a command limited to a single schema. This command has no effect, unless it is undoing a matching GRANT:

ALTER DEFAULT PRIVILEGES IN SCHEMA public REVOKE EXECUTE ON FUNCTIONS FROM PUBLIC;

Thats because per-schema default privileges can only add privileges to the global setting, not remove privileges granted by it.

COMPATIBILITY

There is no ALTER DEFAULT PRIVILEGES statement in the SQL standard.

SEE ALSO

GRANT(7), REVOKE(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

86 - Linux cli command EVP_MAC-KMAC256ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_MAC-KMAC256ssl and provides detailed information about the command EVP_MAC-KMAC256ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_MAC-KMAC256ssl.

NAME 🖥️ EVP_MAC-KMAC256ssl 🖥️

KMAC, EVP_MAC-KMAC128, EVP_MAC-KMAC256 - The KMAC EVP_MAC implementations

DESCRIPTION

Support for computing KMAC MACs through the EVP_MAC API.

Identity

These implementations are identified with one of these names and properties, to be used with EVP_MAC_fetch():

“KMAC-128”, “provider=default” or “provider=fips”

“KMAC-256”, “provider=default” or “provider=fips”

Supported parameters

The general description of these parameters can be found in “PARAMETERS” in EVP_MAC (3).

All these parameters (except for “block-size”) can be set with EVP_MAC_CTX_set_params(). Furthermore, the “size” parameter can be retrieved with EVP_MAC_CTX_get_params(), or with EVP_MAC_CTX_get_mac_size(). The length of the “size” parameter should not exceed that of a size_t. Likewise, the “block-size” parameter can be retrieved with EVP_MAC_CTX_get_params(), or with EVP_MAC_CTX_get_block_size().

“key” (OSSL_MAC_PARAM_KEY) <octet string>
Sets the MAC key. Setting this parameter is identical to passing a key to EVP_MAC_init (3). The length of the key (in bytes) must be in the range 4…512.

“custom” (OSSL_MAC_PARAM_CUSTOM) <octet string>
Sets the customization string. It is an optional value with a length of at most 512 bytes, and is empty by default.

“size” (OSSL_MAC_PARAM_SIZE) <unsigned integer>
Sets the MAC size. By default, it is 32 for KMAC-128 and 64 for KMAC-256.

“block-size” (OSSL_MAC_PARAM_BLOCK_SIZE) <unsigned integer>
Gets the MAC block size. It is 168 for KMAC-128 and 136 for KMAC-256.

“xof” (OSSL_MAC_PARAM_XOF) <integer>
The “xof” parameter value is expected to be 1 or 0. Use 1 to enable XOF mode. The default value is 0.

The “custom” parameter must be set as part of or before the EVP_MAC_init() call. The “xof” and “size” parameters can be set at any time before EVP_MAC_final(). The “key” parameter is set as part of the EVP_MAC_init() call, but can be set before it instead.

EXAMPLES

#include <openssl/evp.h> #include <openssl/params.h> static int do_kmac(const unsigned char *in, size_t in_len, const unsigned char *key, size_t key_len, const unsigned char *custom, size_t custom_len, int xof_enabled, unsigned char *out, int out_len) { EVP_MAC_CTX *ctx = NULL; EVP_MAC *mac = NULL; OSSL_PARAM params[4], *p; int ret = 0; size_t l = 0; mac = EVP_MAC_fetch(NULL, “KMAC-128”, NULL); if (mac == NULL) goto err; ctx = EVP_MAC_CTX_new(mac); /* The mac can be freed after it is used by EVP_MAC_CTX_new */ EVP_MAC_free(mac); if (ctx == NULL) goto err; /* * Setup parameters required before calling EVP_MAC_init() * The parameters OSSL_MAC_PARAM_XOF and OSSL_MAC_PARAM_SIZE may also be * used at this point. */ p = params; *p++ = OSSL_PARAM_construct_octet_string(OSSL_MAC_PARAM_KEY, (void *)key, key_len); if (custom != NULL && custom_len != 0) *p++ = OSSL_PARAM_construct_octet_string(OSSL_MAC_PARAM_CUSTOM, (void *)custom, custom_len); *p = OSSL_PARAM_construct_end(); if (!EVP_MAC_CTX_set_params(ctx, params)) goto err; if (!EVP_MAC_init(ctx)) goto err; /* * Note: the following optional parameters can be set any time * before EVP_MAC_final(). */ p = params; *p++ = OSSL_PARAM_construct_int(OSSL_MAC_PARAM_XOF, &xof_enabled); *p++ = OSSL_PARAM_construct_int(OSSL_MAC_PARAM_SIZE, &out_len); *p = OSSL_PARAM_construct_end(); if (!EVP_MAC_CTX_set_params(ctx, params)) goto err; /* The update may be called multiple times here for streamed input */ if (!EVP_MAC_update(ctx, in, in_len)) goto err; if (!EVP_MAC_final(ctx, out, &l, out_len)) goto err; ret = 1; err: EVP_MAC_CTX_free(ctx); return ret; }

SEE ALSO

EVP_MAC_CTX_get_params (3), EVP_MAC_CTX_set_params (3), “PARAMETERS” in EVP_MAC (3), OSSL_PARAM (3)

COPYRIGHT

Copyright 2018-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

87 - Linux cli command sock_diag

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command sock_diag and provides detailed information about the command sock_diag, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the sock_diag.

NAME 🖥️ sock_diag 🖥️

obtaining information about sockets

SYNOPSIS

#include <sys/socket.h>
#include <linux/sock_diag.h>
#include <linux/unix_diag.h> /* for UNIX domain sockets */
#include <linux/inet_diag.h> /* for IPv4 and IPv6 sockets */
diag_socket = socket(AF_NETLINK, socket_type, NETLINK_SOCK_DIAG);

DESCRIPTION

The sock_diag netlink subsystem provides a mechanism for obtaining information about sockets of various address families from the kernel. This subsystem can be used to obtain information about individual sockets or request a list of sockets.

In the request, the caller can specify additional information it would like to obtain about the socket, for example, memory information or information specific to the address family.

When requesting a list of sockets, the caller can specify filters that would be applied by the kernel to select a subset of sockets to report. For now, there is only the ability to filter sockets by state (connected, listening, and so on.)

Note that sock_diag reports only those sockets that have a name; that is, either sockets bound explicitly with bind(2) or sockets that were automatically bound to an address (e.g., by connect(2)). This is the same set of sockets that is available via /proc/net/unix, /proc/net/tcp, /proc/net/udp, and so on.

Request

The request starts with a struct nlmsghdr header described in netlink(7) with nlmsg_type field set to SOCK_DIAG_BY_FAMILY. It is followed by a header specific to the address family that starts with a common part shared by all address families:

struct sock_diag_req {
    __u8 sdiag_family;
    __u8 sdiag_protocol;
};

The fields of this structure are as follows:

sdiag_family
An address family. It should be set to the appropriate AF_* constant.

sdiag_protocol
Depends on sdiag_family. It should be set to the appropriate IPPROTO_* constant for AF_INET and AF_INET6, and to 0 otherwise.

If the nlmsg_flags field of the struct nlmsghdr header has the NLM_F_DUMP flag set, it means that a list of sockets is being requested; otherwise it is a query about an individual socket.

Response

The response starts with a struct nlmsghdr header and is followed by an array of objects specific to the address family. The array is to be accessed with the standard NLMSG_* macros from the netlink(3) API.

Each object is the NLA (netlink attributes) list that is to be accessed with the RTA_* macros from rtnetlink(3) API.

UNIX domain sockets

For UNIX domain sockets the request is represented in the following structure:

struct unix_diag_req {
    __u8    sdiag_family;
    __u8    sdiag_protocol;
    __u16   pad;
    __u32   udiag_states;
    __u32   udiag_ino;
    __u32   udiag_show;
    __u32   udiag_cookie[2];
};

The fields of this structure are as follows:

sdiag_family
The address family; it should be set to AF_UNIX.

sdiag_protocol

pad These fields should be set to 0.

udiag_states
This is a bit mask that defines a filter of sockets states. Only those sockets whose states are in this mask will be reported. Ignored when querying for an individual socket. Supported values are:

1 << TCP_ESTABLISHED

1 << TCP_LISTEN

udiag_ino
This is an inode number when querying for an individual socket. Ignored when querying for a list of sockets.

udiag_show
This is a set of flags defining what kind of information to report. Each requested kind of information is reported back as a netlink attribute as described below:

UDIAG_SHOW_NAME
The attribute reported in answer to this request is UNIX_DIAG_NAME. The payload associated with this attribute is the pathname to which the socket was bound (a sequence of bytes up to UNIX_PATH_MAX length).

UDIAG_SHOW_VFS
The attribute reported in answer to this request is UNIX_DIAG_VFS. The payload associated with this attribute is represented in the following structure:

struct unix_diag_vfs {
    __u32 udiag_vfs_dev;
    __u32 udiag_vfs_ino;
};

The fields of this structure are as follows:

udiag_vfs_dev
The device number of the corresponding on-disk socket inode.

udiag_vfs_ino
The inode number of the corresponding on-disk socket inode.

UDIAG_SHOW_PEER
The attribute reported in answer to this request is UNIX_DIAG_PEER. The payload associated with this attribute is a __u32 value which is the peer’s inode number. This attribute is reported for connected sockets only.

UDIAG_SHOW_ICONS
The attribute reported in answer to this request is UNIX_DIAG_ICONS. The payload associated with this attribute is an array of __u32 values which are inode numbers of sockets that has passed the connect(2) call, but hasn’t been processed with accept(2) yet. This attribute is reported for listening sockets only.

UDIAG_SHOW_RQLEN
The attribute reported in answer to this request is UNIX_DIAG_RQLEN. The payload associated with this attribute is represented in the following structure:

struct unix_diag_rqlen {
    __u32 udiag_rqueue;
    __u32 udiag_wqueue;
};

The fields of this structure are as follows:

udiag_rqueue
For listening sockets: the number of pending connections. The length of the array associated with the UNIX_DIAG_ICONS response attribute is equal to this value.

For established sockets: the amount of data in incoming queue.

udiag_wqueue
For listening sockets: the backlog length which equals to the value passed as the second argument to listen(2).

For established sockets: the amount of memory available for sending.

UDIAG_SHOW_MEMINFO
The attribute reported in answer to this request is UNIX_DIAG_MEMINFO. The payload associated with this attribute is an array of __u32 values described below in the subsection “Socket memory information”.

The following attributes are reported back without any specific request:

UNIX_DIAG_SHUTDOWN
The payload associated with this attribute is __u8 value which represents bits of shutdown(2) state.

udiag_cookie
This is an array of opaque identifiers that could be used along with udiag_ino to specify an individual socket. It is ignored when querying for a list of sockets, as well as when all its elements are set to -1.

The response to a query for UNIX domain sockets is represented as an array of

struct unix_diag_msg {
    __u8    udiag_family;
    __u8    udiag_type;
    __u8    udiag_state;
    __u8    pad;
    __u32   udiag_ino;
    __u32   udiag_cookie[2];
};

followed by netlink attributes.

The fields of this structure are as follows:

udiag_family
This field has the same meaning as in struct unix_diag_req.

udiag_type
This is set to one of SOCK_PACKET, SOCK_STREAM, or SOCK_SEQPACKET.

udiag_state
This is set to one of TCP_LISTEN or TCP_ESTABLISHED.

pad
This field is set to 0.

udiag_ino
This is the socket inode number.

udiag_cookie
This is an array of opaque identifiers that could be used in subsequent queries.

IPv4 and IPv6 sockets

For IPv4 and IPv6 sockets, the request is represented in the following structure:

struct inet_diag_req_v2 {
    __u8    sdiag_family;
    __u8    sdiag_protocol;
    __u8    idiag_ext;
    __u8    pad;
    __u32   idiag_states;
    struct inet_diag_sockid id;
};

where struct inet_diag_sockid is defined as follows:

struct inet_diag_sockid {
    __be16  idiag_sport;
    __be16  idiag_dport;
    __be32  idiag_src[4];
    __be32  idiag_dst[4];
    __u32   idiag_if;
    __u32   idiag_cookie[2];
};

The fields of struct inet_diag_req_v2 are as follows:

sdiag_family
This should be set to either AF_INET or AF_INET6 for IPv4 or IPv6 sockets respectively.

sdiag_protocol
This should be set to one of IPPROTO_TCP, IPPROTO_UDP, or IPPROTO_UDPLITE.

idiag_ext
This is a set of flags defining what kind of extended information to report. Each requested kind of information is reported back as a netlink attribute as described below:

INET_DIAG_TOS
The payload associated with this attribute is a __u8 value which is the TOS of the socket.

INET_DIAG_TCLASS
The payload associated with this attribute is a __u8 value which is the TClass of the socket. IPv6 sockets only. For LISTEN and CLOSE sockets, this is followed by INET_DIAG_SKV6ONLY attribute with associated __u8 payload value meaning whether the socket is IPv6-only or not.

INET_DIAG_MEMINFO
The payload associated with this attribute is represented in the following structure:

struct inet_diag_meminfo {
    __u32 idiag_rmem;
    __u32 idiag_wmem;
    __u32 idiag_fmem;
    __u32 idiag_tmem;
};

The fields of this structure are as follows:

idiag_rmem
The amount of data in the receive queue.

idiag_wmem
The amount of data that is queued by TCP but not yet sent.

idiag_fmem
The amount of memory scheduled for future use (TCP only).

idiag_tmem
The amount of data in send queue.

INET_DIAG_SKMEMINFO
The payload associated with this attribute is an array of __u32 values described below in the subsection “Socket memory information”.

INET_DIAG_INFO
The payload associated with this attribute is specific to the address family. For TCP sockets, it is an object of type struct tcp_info.

INET_DIAG_CONG
The payload associated with this attribute is a string that describes the congestion control algorithm used. For TCP sockets only.

pad
This should be set to 0.

idiag_states
This is a bit mask that defines a filter of socket states. Only those sockets whose states are in this mask will be reported. Ignored when querying for an individual socket.

id
This is a socket ID object that is used in dump requests, in queries about individual sockets, and is reported back in each response. Unlike UNIX domain sockets, IPv4 and IPv6 sockets are identified using addresses and ports. All values are in network byte order.

The fields of struct inet_diag_sockid are as follows:

idiag_sport
The source port.

idiag_dport
The destination port.

idiag_src
The source address.

idiag_dst
The destination address.

idiag_if
The interface number the socket is bound to.

idiag_cookie
This is an array of opaque identifiers that could be used along with other fields of this structure to specify an individual socket. It is ignored when querying for a list of sockets, as well as when all its elements are set to -1.

The response to a query for IPv4 or IPv6 sockets is represented as an array of

struct inet_diag_msg {
    __u8    idiag_family;
    __u8    idiag_state;
    __u8    idiag_timer;
    __u8    idiag_retrans;
    struct inet_diag_sockid id;
    __u32   idiag_expires;
    __u32   idiag_rqueue;
    __u32   idiag_wqueue;
    __u32   idiag_uid;
    __u32   idiag_inode;
};

followed by netlink attributes.

The fields of this structure are as follows:

idiag_family
This is the same field as in struct inet_diag_req_v2.

idiag_state
This denotes socket state as in struct inet_diag_req_v2.

idiag_timer
For TCP sockets, this field describes the type of timer that is currently active for the socket. It is set to one of the following constants:

0
no timer is active

1
a retransmit timer

2
a keep-alive timer

3
a TIME_WAIT timer

4
a zero window probe timer

For non-TCP sockets, this field is set to 0.

idiag_retrans
For idiag_timer values 1, 2, and 4, this field contains the number of retransmits. For other idiag_timer values, this field is set to 0.

idiag_expires
For TCP sockets that have an active timer, this field describes its expiration time in milliseconds. For other sockets, this field is set to 0.

idiag_rqueue
For listening sockets: the number of pending connections.

For other sockets: the amount of data in the incoming queue.

idiag_wqueue
For listening sockets: the backlog length.

For other sockets: the amount of memory available for sending.

idiag_uid
This is the socket owner UID.

idiag_inode
This is the socket inode number.

Socket memory information

The payload associated with UNIX_DIAG_MEMINFO and INET_DIAG_SKMEMINFO netlink attributes is an array of the following __u32 values:

SK_MEMINFO_RMEM_ALLOC
The amount of data in receive queue.

SK_MEMINFO_RCVBUF
The receive socket buffer as set by SO_RCVBUF.

SK_MEMINFO_WMEM_ALLOC
The amount of data in send queue.

SK_MEMINFO_SNDBUF
The send socket buffer as set by SO_SNDBUF.

SK_MEMINFO_FWD_ALLOC
The amount of memory scheduled for future use (TCP only).

SK_MEMINFO_WMEM_QUEUED
The amount of data queued by TCP, but not yet sent.

SK_MEMINFO_OPTMEM
The amount of memory allocated for the socket’s service needs (e.g., socket filter).

SK_MEMINFO_BACKLOG
The amount of packets in the backlog (not yet processed).

VERSIONS

NETLINK_INET_DIAG was introduced in Linux 2.6.14 and supported AF_INET and AF_INET6 sockets only. In Linux 3.3, it was renamed to NETLINK_SOCK_DIAG and extended to support AF_UNIX sockets.

UNIX_DIAG_MEMINFO and INET_DIAG_SKMEMINFO were introduced in Linux 3.6.

STANDARDS

Linux.

EXAMPLES

The following example program prints inode number, peer’s inode number, and name of all UNIX domain sockets in the current namespace.

#include <errno.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <sys/socket.h>
#include <sys/un.h>
#include <linux/netlink.h>
#include <linux/rtnetlink.h>
#include <linux/sock_diag.h>
#include <linux/unix_diag.h>
static int
send_query(int fd)
{
    struct sockaddr_nl nladdr = {
        .nl_family = AF_NETLINK
    };
    struct
    {
        struct nlmsghdr nlh;
        struct unix_diag_req udr;
    } req = {
        .nlh = {
            .nlmsg_len = sizeof(req),
            .nlmsg_type = SOCK_DIAG_BY_FAMILY,
            .nlmsg_flags = NLM_F_REQUEST | NLM_F_DUMP
        },
        .udr = {
            .sdiag_family = AF_UNIX,
            .udiag_states = -1,
            .udiag_show = UDIAG_SHOW_NAME | UDIAG_SHOW_PEER
        }
    };
    struct iovec iov = {
        .iov_base = &req,
        .iov_len = sizeof(req)
    };
    struct msghdr msg = {
        .msg_name = &nladdr,
        .msg_namelen = sizeof(nladdr),
        .msg_iov = &iov,
        .msg_iovlen = 1
    };
    for (;;) {
        if (sendmsg(fd, &msg, 0) < 0) {
            if (errno == EINTR)
                continue;
            perror("sendmsg");
            return -1;
        }
        return 0;
    }
}
static int
print_diag(const struct unix_diag_msg *diag, unsigned int len)
{
    if (len < NLMSG_LENGTH(sizeof(*diag))) {
        fputs("short response

“, stderr); return -1; } if (diag->udiag_family != AF_UNIX) { fprintf(stderr, “unexpected family %u “, diag->udiag_family); return -1; } unsigned int rta_len = len - NLMSG_LENGTH(sizeof(*diag)); unsigned int peer = 0; size_t path_len = 0; char path[sizeof(((struct sockaddr_un *) 0)->sun_path) + 1]; for (struct rtattr *attr = (struct rtattr *) (diag + 1); RTA_OK(attr, rta_len); attr = RTA_NEXT(attr, rta_len)) { switch (attr->rta_type) { case UNIX_DIAG_NAME: if (!path_len) { path_len = RTA_PAYLOAD(attr); if (path_len > sizeof(path) - 1) path_len = sizeof(path) - 1; memcpy(path, RTA_DATA(attr), path_len); path[path_len] = ‘�’; } break; case UNIX_DIAG_PEER: if (RTA_PAYLOAD(attr) >= sizeof(peer)) peer = *(unsigned int *) RTA_DATA(attr); break; } } printf(“inode=%u”, diag->udiag_ino); if (peer) printf(”, peer=%u”, peer); if (path_len) printf(”, name=%s%s", *path ? "" : “@”, *path ? path : path + 1); putchar(’ ‘); return 0; } static int receive_responses(int fd) { long buf[8192 / sizeof(long)]; struct sockaddr_nl nladdr; struct iovec iov = { .iov_base = buf, .iov_len = sizeof(buf) }; int flags = 0; for (;;) { struct msghdr msg = { .msg_name = &nladdr, .msg_namelen = sizeof(nladdr), .msg_iov = &iov, .msg_iovlen = 1 }; ssize_t ret = recvmsg(fd, &msg, flags); if (ret < 0) { if (errno == EINTR) continue; perror(“recvmsg”); return -1; } if (ret == 0) return 0; if (nladdr.nl_family != AF_NETLINK) { fputs("!AF_NETLINK “, stderr); return -1; } const struct nlmsghdr *h = (struct nlmsghdr *) buf; if (!NLMSG_OK(h, ret)) { fputs("!NLMSG_OK “, stderr); return -1; } for (; NLMSG_OK(h, ret); h = NLMSG_NEXT(h, ret)) { if (h->nlmsg_type == NLMSG_DONE) return 0; if (h->nlmsg_type == NLMSG_ERROR) { const struct nlmsgerr *err = NLMSG_DATA(h); if (h->nlmsg_len < NLMSG_LENGTH(sizeof(*err))) { fputs(“NLMSG_ERROR “, stderr); } else { errno = -err->error; perror(“NLMSG_ERROR”); } return -1; } if (h->nlmsg_type != SOCK_DIAG_BY_FAMILY) { fprintf(stderr, “unexpected nlmsg_type %u “, (unsigned) h->nlmsg_type); return -1; } if (print_diag(NLMSG_DATA(h), h->nlmsg_len)) return -1; } } } int main(void) { int fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_SOCK_DIAG); if (fd < 0) { perror(“socket”); return 1; } int ret = send_query(fd) || receive_responses(fd); close(fd); return ret; }

SEE ALSO

netlink(3), rtnetlink(3), netlink(7), tcp(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

88 - Linux cli command man-pages

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command man-pages and provides detailed information about the command man-pages, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the man-pages.

NAME 🖥️ man-pages 🖥️

pages - conventions for writing Linux man pages

SYNOPSIS

man [section] title

DESCRIPTION

This page describes the conventions that should be employed when writing man pages for the Linux man-pages project, which documents the user-space API provided by the Linux kernel and the GNU C library. The project thus provides most of the pages in Section 2, many of the pages that appear in Sections 3, 4, and 7, and a few of the pages that appear in Sections 1, 5, and 8 of the man pages on a Linux system. The conventions described on this page may also be useful for authors writing man pages for other projects.

Sections of the manual pages

The manual Sections are traditionally defined as follows:

1 User commands (Programs)
Commands that can be executed by the user from within a shell.

2 System calls
Functions which wrap operations performed by the kernel.

3 Library calls
All library functions excluding the system call wrappers (Most of the libc functions).

4 Special files (devices)
Files found in /dev which allow to access to devices through the kernel.

5 File formats and configuration files
Describes various human-readable file formats and configuration files.

6 Games
Games and funny little programs available on the system.

7 Overview, conventions, and miscellaneous
Overviews or descriptions of various topics, conventions, and protocols, character set standards, the standard filesystem layout, and miscellaneous other things.

8 System management commands
Commands like mount(8), many of which only root can execute.

Macro package

New manual pages should be marked up using the groff an.tmac package described in man(7). This choice is mainly for consistency: the vast majority of existing Linux manual pages are marked up using these macros.

Conventions for source file layout

Please limit source code line length to no more than about 75 characters wherever possible. This helps avoid line-wrapping in some mail clients when patches are submitted inline.

Title line

The first command in a man page should be a TH command:

.TH title section date source manual-section

The arguments of the command are as follows:

title
The title of the man page, written in all caps (e.g., MAN-PAGES).

section
The section number in which the man page should be placed (e.g., 7).

date
The date of the last nontrivial change that was made to the man page. (Within the man-pages project, the necessary updates to these timestamps are handled automatically by scripts, so there is no need to manually update them as part of a patch.) Dates should be written in the form YYYY-MM-DD.

source
The name and version of the project that provides the manual page (not necessarily the package that provides the functionality).

manual-section
Normally, this should be empty, since the default value will be good.

Sections within a manual page

The list below shows conventional or suggested sections. Most manual pages should include at least the highlighted sections. Arrange a new manual page so that sections are placed in the order shown in the list.

NAME
LIBRARY[Normally only in Sections 2, 3]
SYNOPSIS
CONFIGURATION[Normally only in Section 4]
DESCRIPTION
OPTIONS[Normally only in Sections 1, 8]
EXIT STATUS[Normally only in Sections 1, 8]
RETURN VALUE[Normally only in Sections 2, 3]
ERRORS[Typically only in Sections 2, 3]
ENVIRONMENT
FILES
ATTRIBUTES[Normally only in Sections 2, 3]
VERSIONS[Normally only in Sections 2, 3]
STANDARDS
HISTORY
NOTES
CAVEATS
BUGS
EXAMPLES
AUTHORS[Discouraged]
REPORTING BUGS[Not used in man-pages]
COPYRIGHT[Not used in man-pages]
SEE ALSO

Where a traditional heading would apply, please use it; this kind of consistency can make the information easier to understand. If you must, you can create your own headings if they make things easier to understand (this can be especially useful for pages in Sections 4 and 5). However, before doing this, consider whether you could use the traditional headings, with some subsections (.SS) within those sections.

The following list elaborates on the contents of each of the above sections.

NAME
The name of this manual page.

See man(7) for important details of the line(s) that should follow the .SH NAME command. All words in this line (including the word immediately following the “") should be in lowercase, except where English or technical terminological convention dictates otherwise.

LIBRARY
The library providing a symbol.

It shows the common name of the library, and in parentheses, the name of the library file and, if needed, the linker flag needed to link a program against it: (libfoo[, -lfoo]).

SYNOPSIS
A brief summary of the command or function’s interface.

For commands, this shows the syntax of the command and its arguments (including options); boldface is used for as-is text and italics are used to indicate replaceable arguments. Brackets ([]) surround optional arguments, vertical bars (|) separate choices, and ellipses (…) can be repeated. For functions, it shows any required data declarations or #include directives, followed by the function declaration.

Where a feature test macro must be defined in order to obtain the declaration of a function (or a variable) from a header file, then the SYNOPSIS should indicate this, as described in feature_test_macros(7).

CONFIGURATION
Configuration details for a device.

This section normally appears only in Section 4 pages.

DESCRIPTION
An explanation of what the program, function, or format does.

Discuss how it interacts with files and standard input, and what it produces on standard output or standard error. Omit internals and implementation details unless they’re critical for understanding the interface. Describe the usual case; for information on command-line options of a program use the OPTIONS section.

When describing new behavior or new flags for a system call or library function, be careful to note the kernel or C library version that introduced the change. The preferred method of noting this information for flags is as part of a .TP list, in the following form (here, for a new system call flag):

XYZ_FLAG (since Linux 3.7)
Description of flag…

Including version information is especially useful to users who are constrained to using older kernel or C library versions (which is typical in embedded systems, for example).

OPTIONS
A description of the command-line options accepted by a program and how they change its behavior.

This section should appear only for Section 1 and 8 manual pages.

EXIT STATUS
A list of the possible exit status values of a program and the conditions that cause these values to be returned.

This section should appear only for Section 1 and 8 manual pages.

RETURN VALUE
For Section 2 and 3 pages, this section gives a list of the values the library routine will return to the caller and the conditions that cause these values to be returned.

ERRORS
For Section 2 and 3 manual pages, this is a list of the values that may be placed in errno in the event of an error, along with information about the cause of the errors.

Where several different conditions produce the same error, the preferred approach is to create separate list entries (with duplicate error names) for each of the conditions. This makes the separate conditions clear, may make the list easier to read, and allows metainformation (e.g., kernel version number where the condition first became applicable) to be more easily marked for each condition.

The error list should be in alphabetical order.

ENVIRONMENT
A list of all environment variables that affect the program or function and how they affect it.

FILES
A list of the files the program or function uses, such as configuration files, startup files, and files the program directly operates on.

Give the full pathname of these files, and use the installation process to modify the directory part to match user preferences. For many programs, the default installation location is in /usr/local, so your base manual page should use /usr/local as the base.

ATTRIBUTES
A summary of various attributes of the function(s) documented on this page. See attributes(7) for further details.

VERSIONS
A summary of systems where the API performs differently, or where there’s a similar API.

STANDARDS
A description of any standards or conventions that relate to the function or command described by the manual page.

The preferred terms to use for the various standards are listed as headings in standards(7).

This section should note the current standards to which the API conforms to.

If the API is not governed by any standards but commonly exists on other systems, note them. If the call is Linux-specific or GNU-specific, note this. If it’s available in the BSDs, note that.

If this section consists of just a list of standards (which it commonly does), terminate the list with a period (’.’).

HISTORY
A brief summary of the Linux kernel or glibc versions where a system call or library function appeared, or changed significantly in its operation.

As a general rule, every new interface should include a HISTORY section in its manual page. Unfortunately, many existing manual pages don’t include this information (since there was no policy to do so when they were written). Patches to remedy this are welcome, but, from the perspective of programmers writing new code, this information probably matters only in the case of kernel interfaces that have been added in Linux 2.4 or later (i.e., changes since Linux 2.2), and library functions that have been added to glibc since glibc 2.1 (i.e., changes since glibc 2.0).

The syscalls(2) manual page also provides information about kernel versions in which various system calls first appeared.

Old versions of standards should be mentioned here, rather than in STANDARDS, for example, SUS, SUSv2, and XPG, or the SVr4 and 4.xBSD implementation standards.

NOTES
Miscellaneous notes.

For Section 2 and 3 man pages you may find it useful to include subsections (SS) named Linux Notes and glibc Notes.

In Section 2, use the heading C library/kernel differences to mark off notes that describe the differences (if any) between the C library wrapper function for a system call and the raw system call interface provided by the kernel.

CAVEATS
Warnings about typical user misuse of an API, that don’t constitute an API bug or design defect.

BUGS
A list of limitations, known defects or inconveniences, and other questionable activities.

EXAMPLES
One or more examples demonstrating how this function, file, or command is used.

For details on writing example programs, see Example programs below.

AUTHORS
A list of authors of the documentation or program.

Use of an AUTHORS section is strongly discouraged. Generally, it is better not to clutter every page with a list of (over time potentially numerous) authors; if you write or significantly amend a page, add a copyright notice as a comment in the source file. If you are the author of a device driver and want to include an address for reporting bugs, place this under the BUGS section.

REPORTING BUGS
The man-pages project doesn’t use a REPORTING BUGS section in manual pages. Information on reporting bugs is instead supplied in the script-generated COLOPHON section. However, various projects do use a REPORTING BUGS section. It is recommended to place it near the foot of the page.

COPYRIGHT
The man-pages project doesn’t use a COPYRIGHT section in manual pages. Copyright information is instead maintained in the page source. In pages where this section is present, it is recommended to place it near the foot of the page, just above SEE ALSO.

SEE ALSO
A comma-separated list of related man pages, possibly followed by other related pages or documents.

The list should be ordered by section number and then alphabetically by name. Do not terminate this list with a period.

Where the SEE ALSO list contains many long manual page names, to improve the visual result of the output, it may be useful to employ the .ad l (don’t right justify) and .nh (don’t hyphenate) directives. Hyphenation of individual page names can be prevented by preceding words with the string “".

Given the distributed, autonomous nature of FOSS projects and their documentation, it is sometimes necessary—and in many cases desirable—that the SEE ALSO section includes references to manual pages provided by other projects.

FORMATTING AND WORDING CONVENTIONS

The following subsections note some details for preferred formatting and wording conventions in various sections of the pages in the man-pages project.

SYNOPSIS

Wrap the function prototype(s) in a .nf/.fi pair to prevent filling.

In general, where more than one function prototype is shown in the SYNOPSIS, the prototypes should not be separated by blank lines. However, blank lines (achieved using .P) may be added in the following cases:

  • to separate long lists of function prototypes into related groups (see for example list(3));

  • in other cases that may improve readability.

In the SYNOPSIS, a long function prototype may need to be continued over to the next line. The continuation line is indented according to the following rules:

  1. If there is a single such prototype that needs to be continued, then align the continuation line so that when the page is rendered on a fixed-width font device (e.g., on an xterm) the continuation line starts just below the start of the argument list in the line above. (Exception: the indentation may be adjusted if necessary to prevent a very long continuation line or a further continuation line where the function prototype is very long.) As an example:

    int tcsetattr(int fd, int optional_actions,
 const struct termios *termios_p);

  2. But, where multiple functions in the SYNOPSIS require continuation lines, and the function names have different lengths, then align all continuation lines to start in the same column. This provides a nicer rendering in PDF output (because the SYNOPSIS uses a variable width font where spaces render narrower than most characters). As an example:

    int getopt(int argc, char * const argv[],
 const char *optstring);
int getopt_long(int argc, char * const argv[],
 const char *optstring,
 const struct option *longopts, int *longindex);

RETURN VALUE

The preferred wording to describe how errno is set is “errno is set to indicate the error” or similar. This wording is consistent with the wording used in both POSIX.1 and FreeBSD.

ATTRIBUTES

Note the following:

  • Wrap the table in this section in a .ad l/.ad pair to disable text filling and a .nh/.hy pair to disable hyphenation.

  • Ensure that the table occupies the full page width through the use of an lbx description for one of the columns (usually the first column, though in some cases the last column if it contains a lot of text).

  • Make free use of T{/T} macro pairs to allow table cells to be broken over multiple lines (also bearing in mind that pages may sometimes be rendered to a width of less than 80 columns).

For examples of all of the above, see the source code of various pages.

STYLE GUIDE

The following subsections describe the preferred style for the man-pages project. For details not covered below, the Chicago Manual of Style is usually a good source; try also grepping for preexisting usage in the project source tree.

Use of gender-neutral language

As far as possible, use gender-neutral language in the text of man pages. Use of “they” (“them”, “themself”, “their”) as a gender-neutral singular pronoun is acceptable.

Formatting conventions for manual pages describing commands

For manual pages that describe a command (typically in Sections 1 and 8), the arguments are always specified using italics, even in the SYNOPSIS section.

The name of the command, and its options, should always be formatted in bold.

Formatting conventions for manual pages describing functions

For manual pages that describe functions (typically in Sections 2 and 3), the arguments are always specified using italics, even in the SYNOPSIS section, where the rest of the function is specified in bold:

** int myfunction(int argc, char **argv);**

Variable names should, like argument names, be specified in italics.

Any reference to the subject of the current manual page should be written with the name in bold followed by a pair of parentheses in Roman (normal) font. For example, in the fcntl(2) man page, references to the subject of the page would be written as: fcntl(). The preferred way to write this in the source file is:

    .BR fcntl ()

(Using this format, rather than the use of " B… P()” makes it easier to write tools that parse man page source files.)

Use semantic newlines

In the source of a manual page, new sentences should be started on new lines, long sentences should be split into lines at clause breaks (commas, semicolons, colons, and so on), and long clauses should be split at phrase boundaries. This convention, sometimes known as “semantic newlines”, makes it easier to see the effect of patches, which often operate at the level of individual sentences, clauses, or phrases.

Lists

There are different kinds of lists:

Tagged paragraphs
These are used for a list of tags and their descriptions. When the tags are constants (either macros or numbers) they are in bold. Use the .TP macro.

An example is this “Tagged paragraphs” subsection is itself.

Ordered lists
Elements are preceded by a number in parentheses (1), (2). These represent a set of steps that have an order.

When there are substeps, they will be numbered like (4.2).

Positional lists
Elements are preceded by a number (index) in square brackets [4], [5]. These represent fields in a set. The first index will be:

0
When it represents fields of a C data structure, to be consistent with arrays.

1
When it represents fields of a file, to be consistent with tools like cut(1).

Alternatives list
Elements are preceded by a letter in parentheses (a), (b). These represent a set of (normally) exclusive alternatives.

Bullet lists
Elements are preceded by bullet symbols (\bu]). Anything that doesn’t fit elsewhere is usually covered by this type of list.

Numbered notes
Not really a list, but the syntax is identical to “positional lists”.

There should always be exactly 2 spaces between the list symbol and the elements. This doesn’t apply to “tagged paragraphs”, which use the default indentation rules.

Formatting conventions (general)

Paragraphs should be separated by suitable markers (usually either .P or .IP). Do not separate paragraphs using blank lines, as this results in poor rendering in some output formats (such as PostScript and PDF).

Filenames (whether pathnames, or references to header files) are always in italics (e.g., <stdio.h>), except in the SYNOPSIS section, where included files are in bold (e.g., #include <stdio.h>). When referring to a standard header file include, specify the header file surrounded by angle brackets, in the usual C way (e.g., <stdio.h>).

Special macros, which are usually in uppercase, are in bold (e.g., MAXINT). Exception: don’t boldface NULL.

When enumerating a list of error codes, the codes are in bold (this list usually uses the .TP macro).

Complete commands should, if long, be written as an indented line on their own, with a blank line before and after the command, for example

man 7 man-pages

If the command is short, then it can be included inline in the text, in italic format, for example, man 7 man-pages. In this case, it may be worth using nonbreaking spaces (\ti]) at suitable places in the command. Command options should be written in italics (e.g., -l).

Expressions, if not written on a separate indented line, should be specified in italics. Again, the use of nonbreaking spaces may be appropriate if the expression is inlined with normal text.

When showing example shell sessions, user input should be formatted in bold, for example

$ date
Thu Jul  7 13:01:27 CEST 2016

Any reference to another man page should be written with the name in bold, always followed by the section number, formatted in Roman (normal) font, without any separating spaces (e.g., intro(2)). The preferred way to write this in the source file is:

    .BR intro (2)

(Including the section number in cross references lets tools like man2html(1) create properly hyperlinked pages.)

Control characters should be written in bold face, with no quotes; for example, ^X.

Spelling

Starting with release 2.59, man-pages follows American spelling conventions (previously, there was a random mix of British and American spellings); please write all new pages and patches according to these conventions.

Aside from the well-known spelling differences, there are a few other subtleties to watch for:

  • American English tends to use the forms “backward”, “upward”, “toward”, and so on rather than the British forms “backwards”, “upwards”, “towards”, and so on.

  • Opinions are divided on “acknowledgement” vs “acknowledgment”. The latter is predominant, but not universal usage in American English. POSIX and the BSD license use the former spelling. In the Linux man-pages project, we use “acknowledgement”.

BSD version numbers

The classical scheme for writing BSD version numbers is x.yBSD, where x.y is the version number (e.g., 4.2BSD). Avoid forms such as BSD 4.3.

Capitalization

In subsection (“SS”) headings, capitalize the first word in the heading, but otherwise use lowercase, except where English usage (e.g., proper nouns) or programming language requirements (e.g., identifier names) dictate otherwise. For example:

.SS Unicode under Linux

Indentation of structure definitions, shell session logs, and so on

When structure definitions, shell session logs, and so on are included in running text, indent them by 4 spaces (i.e., a block enclosed by .in +4n and .in), format them using the .EX and .EE macros, and surround them with suitable paragraph markers (either .P or .IP). For example:

.P
.in +4n
.EX
int
main(int argc, char *argv[])
{
    return 0;
}
.EE
.in
.P

Preferred terms

The following table lists some preferred terms to use in man pages, mainly to ensure consistency across pages.

TermAvoid usingNotes
bit maskbitmask
built-inbuiltin
EpochepochFor the UNIX Epoch (00:00:00, 1 Jan 1970 UTC)
filenamefile name
filesystemfile system
hostnamehost name
inodei-node
lowercaselower case, lower-case
nonzeronon-zero
pathnamepath name
pseudoterminalpseudo-terminal
privileged portreserved port, system port
real-timerealtime, real time
run timeruntime
saved set-group-IDsaved group ID, saved set-GID
saved set-user-IDsaved user ID, saved set-UID
set-group-IDset-GID, setgid
set-user-IDset-UID, setuid
superusersuper user, super-user
superblocksuper block, super-block
symbolic linksymlink
timestamptime stamp
timezonetime zone
uppercaseupper case, upper-case
usableuseable
user spaceuserspace
usernameuser name
x86-64x86_64Except if referring to result of "uname -m" or similar
zeroszeroes

See also the discussion Hyphenation of attributive compounds below.

Terms to avoid

The following table lists some terms to avoid using in man pages, along with some suggested alternatives, mainly to ensure consistency across pages.

AvoidUse insteadNotes
32bit32-bitsame for 8-bit, 16-bit, etc.
current processcalling processA common mistake made by kernel programmers when writing man pages
manpageman page, manual page
minus infinitynegative infinity
non-rootunprivileged user
non-superuserunprivileged user
nonprivilegedunprivileged
OSoperating system
plus infinitypositive infinity
ptypseudoterminal
ttyterminal
UnicesUNIX systems
UnixesUNIX systems

Trademarks

Use the correct spelling and case for trademarks. The following is a list of the correct spellings of various relevant trademarks that are sometimes misspelled:

DG/UX
HP-UX
UNIX
UnixWare

NULL, NUL, null pointer, and null byte

A null pointer is a pointer that points to nothing, and is normally indicated by the constant NULL. On the other hand, NUL is the null byte, a byte with the value 0, represented in C via the character constant ‘�’.

The preferred term for the pointer is “null pointer” or simply “NULL”; avoid writing “NULL pointer”.

The preferred term for the byte is “null byte”. Avoid writing “NUL”, since it is too easily confused with “NULL”. Avoid also the terms “zero byte” and “null character”. The byte that terminates a C string should be described as “the terminating null byte”; strings may be described as “null-terminated”, but avoid the use of “NUL-terminated”.

For hyperlinks, use the .UR/.UE macro pair (see groff_man(7)). This produces proper hyperlinks that can be used in a web browser, when rendering a page with, say:

BROWSER=firefox man -H pagename

Use of e.g., i.e., etc., a.k.a., and similar

In general, the use of abbreviations such as “e.g.”, “i.e.”, “etc.”, “cf.”, and “a.k.a.” should be avoided, in favor of suitable full wordings (“for example”, “that is”, “and so on”, “compare to”, “also known as”).

The only place where such abbreviations may be acceptable is in short parenthetical asides (e.g., like this one).

Always include periods in such abbreviations, as shown here. In addition, “e.g.” and “i.e.” should always be followed by a comma.

Em-dashes

The way to write an em-dash—the glyph that appears at either end of this subphrase—in *roff is with the macro “\em]”. (On an ASCII terminal, an em-dash typically renders as two hyphens, but in other typographical contexts it renders as a long dash.) Em-dashes should be written without surrounding spaces.

Hyphenation of attributive compounds

Compound terms should be hyphenated when used attributively (i.e., to qualify a following noun). Some examples:

32-bit value
command-line argument
floating-point number
run-time check
user-space function
wide-character string

Hyphenation with multi, non, pre, re, sub, and so on

The general tendency in modern English is not to hyphenate after prefixes such as “multi”, “non”, “pre”, “re”, “sub”, and so on. Manual pages should generally follow this rule when these prefixes are used in natural English constructions with simple suffixes. The following list gives some examples of the preferred forms:

interprocess
multithreaded
multiprocess
nonblocking
nondefault
nonempty
noninteractive
nonnegative
nonportable
nonzero
preallocated
precreate
prerecorded
reestablished
reinitialize
rearm
reread
subcomponent
subdirectory
subsystem

Hyphens should be retained when the prefixes are used in nonstandard English words, with trademarks, proper nouns, acronyms, or compound terms. Some examples:

non-ASCII
non-English
non-NULL
non-real-time

Finally, note that “re-create” and “recreate” are two different verbs, and the former is probably what you want.

Generating optimal glyphs

Where a real minus character is required (e.g., for numbers such as -1, for man page cross references such as utf-8(7), or when writing options that have a leading dash, such as in ls -l), use the following form in the man page source:

\-

This guideline applies also to code examples.

The use of real minus signs serves the following purposes:

  • To provide better renderings on various targets other than ASCII terminals, notably in PDF and on Unicode/UTF-8-capable terminals.

  • To generate glyphs that when copied from rendered pages will produce real minus signs when pasted into a terminal.

To produce unslanted single quotes that render well in ASCII, UTF-8, and PDF, use “\aq]” (“apostrophe quote”); for example

\[aq]C\[aq]

where C is the quoted character. This guideline applies also to character constants used in code examples.

Where a proper caret (^) that renders well in both a terminal and PDF is required, use “\ha]”. This is especially necessary in code samples, to get a nicely rendered caret when rendering to PDF.

Using a naked “~” character results in a poor rendering in PDF. Instead use “\ti]”. This is especially necessary in code samples, to get a nicely rendered tilde when rendering to PDF.

Example programs and shell sessions

Manual pages may include example programs demonstrating how to use a system call or library function. However, note the following:

  • Example programs should be written in C.

  • An example program is necessary and useful only if it demonstrates something beyond what can easily be provided in a textual description of the interface. An example program that does nothing other than call an interface usually serves little purpose.

  • Example programs should ideally be short (e.g., a good example can often be provided in less than 100 lines of code), though in some cases longer programs may be necessary to properly illustrate the use of an API.

  • Expressive code is appreciated.

  • Comments should included where helpful. Complete sentences in free-standing comments should be terminated by a period. Periods should generally be omitted in “tag” comments (i.e., comments that are placed on the same line of code); such comments are in any case typically brief phrases rather than complete sentences.

  • Example programs should do error checking after system calls and library function calls.

  • Example programs should be complete, and compile without warnings when compiled with cc -Wall.

  • Where possible and appropriate, example programs should allow experimentation, by varying their behavior based on inputs (ideally from command-line arguments, or alternatively, via input read by the program).

  • Example programs should be laid out according to Kernighan and Ritchie style, with 4-space indents. (Avoid the use of TAB characters in source code!) The following command can be used to format your source code to something close to the preferred style:

    indent -npro -kr -i4 -ts4 -sob -l72 -ss -nut -psl prog.c

  • For consistency, all example programs should terminate using either of:

    exit(EXIT_SUCCESS);
exit(EXIT_FAILURE);

    Avoid using the following forms to terminate a program:

    exit(0);
exit(1);
return n;

  • If there is extensive explanatory text before the program source code, mark off the source code with a subsection heading Program source, as in:

    .SS Program source

    Always do this if the explanatory text includes a shell session log.

If you include a shell session log demonstrating the use of a program or other system feature:

  • Place the session log above the source code listing.

  • Indent the session log by four spaces.

  • Boldface the user input text, to distinguish it from output produced by the system.

For some examples of what example programs should look like, see wait(2) and pipe(2).

EXAMPLES

For canonical examples of how man pages in the man-pages package should look, see pipe(2) and fcntl(2).

SEE ALSO

man(1), man2html(1), attributes(7), groff(7), groff_man(7), man(7), mdoc(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

89 - Linux cli command glibc

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command glibc and provides detailed information about the command glibc, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the glibc.

NAME 🖥️ glibc 🖥️

overview of standard C libraries on Linux

DESCRIPTION

The term “libc” is commonly used as a shorthand for the “standard C library” a library of standard functions that can be used by all C programs (and sometimes by programs in other languages). Because of some history (see below), use of the term “libc” to refer to the standard C library is somewhat ambiguous on Linux.

glibc

By far the most widely used C library on Linux is the GNU C Library, often referred to as glibc. This is the C library that is nowadays used in all major Linux distributions. It is also the C library whose details are documented in the relevant pages of the man-pages project (primarily in Section 3 of the manual). Documentation of glibc is also available in the glibc manual, available via the command info libc. Release 1.0 of glibc was made in September 1992. (There were earlier 0.x releases.) The next major release of glibc was 2.0, at the beginning of 1997.

The pathname /lib/libc.so.6 (or something similar) is normally a symbolic link that points to the location of the glibc library, and executing this pathname will cause glibc to display various information about the version installed on your system.

Linux libc

In the early to mid 1990s, there was for a while Linux libc, a fork of glibc 1.x created by Linux developers who felt that glibc development at the time was not sufficing for the needs of Linux. Often, this library was referred to (ambiguously) as just “libc”. Linux libc released major versions 2, 3, 4, and 5, as well as many minor versions of those releases. Linux libc4 was the last version to use the a.out binary format, and the first version to provide (primitive) shared library support. Linux libc 5 was the first version to support the ELF binary format; this version used the shared library soname libc.so.5. For a while, Linux libc was the standard C library in many Linux distributions.

However, notwithstanding the original motivations of the Linux libc effort, by the time glibc 2.0 was released (in 1997), it was clearly superior to Linux libc, and all major Linux distributions that had been using Linux libc soon switched back to glibc. To avoid any confusion with Linux libc versions, glibc 2.0 and later used the shared library soname libc.so.6.

Since the switch from Linux libc to glibc 2.0 occurred long ago, man-pages no longer takes care to document Linux libc details. Nevertheless, the history is visible in vestiges of information about Linux libc that remain in a few manual pages, in particular, references to libc4 and libc5.

Other C libraries

There are various other less widely used C libraries for Linux. These libraries are generally smaller than glibc, both in terms of features and memory footprint, and often intended for building small binaries, perhaps targeted at development for embedded Linux systems. Among such libraries are

uClibc

dietlibc

and

musl libc

Details of these libraries are covered by the man-pages project, where they are known.

SEE ALSO

syscalls(2), getauxval(3), proc(5), feature_test_macros(7), man-pages(7), standards(7), vdso(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

90 - Linux cli command utf-8

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command utf-8 and provides detailed information about the command utf-8, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the utf-8.

NAME 🖥️ utf-8 🖥️

8 - an ASCII compatible multibyte Unicode encoding

DESCRIPTION

The Unicode 3.0 character set occupies a 16-bit code space. The most obvious Unicode encoding (known as UCS-2) consists of a sequence of 16-bit words. Such strings can contain—as part of many 16-bit characters—bytes such as ‘�’ or ‘/’, which have a special meaning in filenames and other C library function arguments. In addition, the majority of UNIX tools expect ASCII files and can’t read 16-bit words as characters without major modifications. For these reasons, UCS-2 is not a suitable external encoding of Unicode in filenames, text files, environment variables, and so on. The ISO/IEC 10646 Universal Character Set (UCS), a superset of Unicode, occupies an even larger code space—31 bits—and the obvious UCS-4 encoding for it (a sequence of 32-bit words) has the same problems.

The UTF-8 encoding of Unicode and UCS does not have these problems and is the common way in which Unicode is used on UNIX-style operating systems.

Properties

The UTF-8 encoding has the following nice properties:

  • UCS characters 0x00000000 to 0x0000007f (the classic US-ASCII characters) are encoded simply as bytes 0x00 to 0x7f (ASCII compatibility). This means that files and strings which contain only 7-bit ASCII characters have the same encoding under both ASCII and UTF-8.

  • All UCS characters greater than 0x7f are encoded as a multibyte sequence consisting only of bytes in the range 0x80 to 0xfd, so no ASCII byte can appear as part of another character and there are no problems with, for example, ‘�’ or ‘/’.

  • The lexicographic sorting order of UCS-4 strings is preserved.

  • All possible 2^31 UCS codes can be encoded using UTF-8.

  • The bytes 0xc0, 0xc1, 0xfe, and 0xff are never used in the UTF-8 encoding.

  • The first byte of a multibyte sequence which represents a single non-ASCII UCS character is always in the range 0xc2 to 0xfd and indicates how long this multibyte sequence is. All further bytes in a multibyte sequence are in the range 0x80 to 0xbf. This allows easy resynchronization and makes the encoding stateless and robust against missing bytes.

  • UTF-8 encoded UCS characters may be up to six bytes long, however the Unicode standard specifies no characters above 0x10ffff, so Unicode characters can be only up to four bytes long in UTF-8.

Encoding

The following byte sequences are used to represent a character. The sequence to be used depends on the UCS code number of the character:

0x00000000 - 0x0000007F:
0xxxxxxx

0x00000080 - 0x000007FF:
110xxxxx 10xxxxxx

0x00000800 - 0x0000FFFF:
1110xxxx 10xxxxxx 10xxxxxx

0x00010000 - 0x001FFFFF:
11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

0x00200000 - 0x03FFFFFF:
111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

0x04000000 - 0x7FFFFFFF:
1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

The xxx bit positions are filled with the bits of the character code number in binary representation, most significant bit first (big-endian). Only the shortest possible multibyte sequence which can represent the code number of the character can be used.

The UCS code values 0xd800–0xdfff (UTF-16 surrogates) as well as 0xfffe and 0xffff (UCS noncharacters) should not appear in conforming UTF-8 streams. According to RFC 3629 no point above U+10FFFF should be used, which limits characters to four bytes.

Example

The Unicode character 0xa9 = 1010 1001 (the copyright sign) is encoded in UTF-8 as

11000010 10101001 = 0xc2 0xa9

and character 0x2260 = 0010 0010 0110 0000 (the “not equal” symbol) is encoded as:

11100010 10001001 10100000 = 0xe2 0x89 0xa0

Application notes

Users have to select a UTF-8 locale, for example with

export LANG=en_GB.UTF-8

in order to activate the UTF-8 support in applications.

Application software that has to be aware of the used character encoding should always set the locale with for example

setlocale(LC_CTYPE, “”)

and programmers can then test the expression

strcmp(nl_langinfo(CODESET), “UTF-8”) == 0

to determine whether a UTF-8 locale has been selected and whether therefore all plaintext standard input and output, terminal communication, plaintext file content, filenames, and environment variables are encoded in UTF-8.

Programmers accustomed to single-byte encodings such as US-ASCII or ISO/IEC 8859 have to be aware that two assumptions made so far are no longer valid in UTF-8 locales. Firstly, a single byte does not necessarily correspond any more to a single character. Secondly, since modern terminal emulators in UTF-8 mode also support Chinese, Japanese, and Korean double-width characters as well as nonspacing combining characters, outputting a single character does not necessarily advance the cursor by one position as it did in ASCII. Library functions such as mbsrtowcs(3) and wcswidth(3) should be used today to count characters and cursor positions.

The official ESC sequence to switch from an ISO/IEC 2022 encoding scheme (as used for instance by VT100 terminals) to UTF-8 is ESC % G (“%G”). The corresponding return sequence from UTF-8 to ISO/IEC 2022 is ESC % @ (“%@”). Other ISO/IEC 2022 sequences (such as for switching the G0 and G1 sets) are not applicable in UTF-8 mode.

Security

The Unicode and UCS standards require that producers of UTF-8 shall use the shortest form possible, for example, producing a two-byte sequence with first byte 0xc0 is nonconforming. Unicode 3.1 has added the requirement that conforming programs must not accept non-shortest forms in their input. This is for security reasons: if user input is checked for possible security violations, a program might check only for the ASCII version of “/../” or “;” or NUL and overlook that there are many non-ASCII ways to represent these things in a non-shortest UTF-8 encoding.

Standards

ISO/IEC 10646-1:2000, Unicode 3.1, RFC 3629, Plan 9.

SEE ALSO

locale(1), nl_langinfo(3), setlocale(3), charsets(7), unicode(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

91 - Linux cli command FETCH

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command FETCH and provides detailed information about the command FETCH, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the FETCH.

NAME 🖥️ FETCH 🖥️

retrieve rows from a query using a cursor

SYNOPSIS

FETCH [ direction ] [ FROM | IN ] cursor_name

where direction can be one of:

    NEXT
    PRIOR
    FIRST
    LAST
    ABSOLUTE count
    RELATIVE count
    count
    ALL
    FORWARD
    FORWARD count
    FORWARD ALL
    BACKWARD
    BACKWARD count
    BACKWARD ALL

DESCRIPTION

FETCH retrieves rows using a previously-created cursor.

A cursor has an associated position, which is used by FETCH. The cursor position can be before the first row of the query result, on any particular row of the result, or after the last row of the result. When created, a cursor is positioned before the first row. After fetching some rows, the cursor is positioned on the row most recently retrieved. If FETCH runs off the end of the available rows then the cursor is left positioned after the last row, or before the first row if fetching backward. FETCH ALL or FETCH BACKWARD ALL will always leave the cursor positioned after the last row or before the first row.

The forms NEXT, PRIOR, FIRST, LAST, ABSOLUTE, RELATIVE fetch a single row after moving the cursor appropriately. If there is no such row, an empty result is returned, and the cursor is left positioned before the first row or after the last row as appropriate.

The forms using FORWARD and BACKWARD retrieve the indicated number of rows moving in the forward or backward direction, leaving the cursor positioned on the last-returned row (or after/before all rows, if the count exceeds the number of rows available).

RELATIVE 0, FORWARD 0, and BACKWARD 0 all request fetching the current row without moving the cursor, that is, re-fetching the most recently fetched row. This will succeed unless the cursor is positioned before the first row or after the last row; in which case, no row is returned.

Note

This page describes usage of cursors at the SQL command level. If you are trying to use cursors inside a PL/pgSQL function, the rules are different — see Section 43.7.3.

PARAMETERS

direction

direction defines the fetch direction and number of rows to fetch. It can be one of the following:

NEXT

Fetch the next row. This is the default if direction is omitted.

PRIOR

Fetch the prior row.

FIRST

Fetch the first row of the query (same as ABSOLUTE 1).

LAST

Fetch the last row of the query (same as ABSOLUTE -1).

ABSOLUTE count

Fetch the countth row of the query, or the abs(count)th row from the end if count is negative. Position before first row or after last row if count is out of range; in particular, ABSOLUTE 0 positions before the first row.

RELATIVE count

Fetch the countth succeeding row, or the abs(count)th prior row if count is negative. RELATIVE 0 re-fetches the current row, if any.

count

Fetch the next count rows (same as FORWARD count).

ALL

Fetch all remaining rows (same as FORWARD ALL).

FORWARD

Fetch the next row (same as NEXT).

FORWARD count

Fetch the next count rows. FORWARD 0 re-fetches the current row.

FORWARD ALL

Fetch all remaining rows.

BACKWARD

Fetch the prior row (same as PRIOR).

BACKWARD count

Fetch the prior count rows (scanning backwards). BACKWARD 0 re-fetches the current row.

BACKWARD ALL

Fetch all prior rows (scanning backwards).

count

count is a possibly-signed integer constant, determining the location or number of rows to fetch. For FORWARD and BACKWARD cases, specifying a negative count is equivalent to changing the sense of FORWARD and BACKWARD.

cursor_name

An open cursors name.

OUTPUTS

On successful completion, a FETCH command returns a command tag of the form

FETCH count

The count is the number of rows fetched (possibly zero). Note that in psql, the command tag will not actually be displayed, since psql displays the fetched rows instead.

NOTES

The cursor should be declared with the SCROLL option if one intends to use any variants of FETCH other than FETCH NEXT or FETCH FORWARD with a positive count. For simple queries PostgreSQL will allow backwards fetch from cursors not declared with SCROLL, but this behavior is best not relied on. If the cursor is declared with NO SCROLL, no backward fetches are allowed.

ABSOLUTE fetches are not any faster than navigating to the desired row with a relative move: the underlying implementation must traverse all the intermediate rows anyway. Negative absolute fetches are even worse: the query must be read to the end to find the last row, and then traversed backward from there. However, rewinding to the start of the query (as with FETCH ABSOLUTE 0) is fast.

DECLARE is used to define a cursor. Use MOVE to change cursor position without retrieving data.

EXAMPLES

The following example traverses a table using a cursor:

BEGIN WORK;

-- Set up a cursor:
DECLARE liahona SCROLL CURSOR FOR SELECT * FROM films;

-- Fetch the first 5 rows in the cursor liahona:
FETCH FORWARD 5 FROM liahona;

 code  |          title:        | did | date_prod  |   kind   |  len
-------+-------------------------+-----+------------+----------+-------
 BL101 | The Third Man           | 101 | 1949-12-23 | Drama    | 01:44
 BL102 | The African Queen       | 101 | 1951-08-11 | Romantic | 01:43
 JL201 | Une Femme est une Femme | 102 | 1961-03-12 | Romantic | 01:25
 P_301 | Vertigo                 | 103 | 1958-11-14 | Action   | 02:08
 P_302 | Becket                  | 103 | 1964-02-03 | Drama    | 02:28

-- Fetch the previous row:
FETCH PRIOR FROM liahona;

 code  |  title: | did | date_prod  |  kind  |  len
-------+---------+-----+------------+--------+-------
 P_301 | Vertigo | 103 | 1958-11-14 | Action | 02:08

-- Close the cursor and end the transaction:
CLOSE liahona;
COMMIT WORK;

COMPATIBILITY

The SQL standard defines FETCH for use in embedded SQL only. The variant of FETCH described here returns the data as if it were a SELECT result rather than placing it in host variables. Other than this point, FETCH is fully upward-compatible with the SQL standard.

The FETCH forms involving FORWARD and BACKWARD, as well as the forms FETCH count and FETCH ALL, in which FORWARD is implicit, are PostgreSQL extensions.

The SQL standard allows only FROM preceding the cursor name; the option to use IN, or to leave them out altogether, is an extension.

SEE ALSO

CLOSE(7), DECLARE(7), MOVE(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

92 - Linux cli command ALTER_ROLE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_ROLE and provides detailed information about the command ALTER_ROLE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_ROLE.

NAME 🖥️ ALTER_ROLE 🖥️

change a database role

SYNOPSIS

ALTER ROLE role_specification [ WITH ] option [ ... ]

where option can be:

      SUPERUSER | NOSUPERUSER
    | CREATEDB | NOCREATEDB
    | CREATEROLE | NOCREATEROLE
    | INHERIT | NOINHERIT
    | LOGIN | NOLOGIN
    | REPLICATION | NOREPLICATION
    | BYPASSRLS | NOBYPASSRLS
    | CONNECTION LIMIT connlimit
    | [ ENCRYPTED ] PASSWORD password | PASSWORD NULL
    | VALID UNTIL timestamp

ALTER ROLE name RENAME TO new_name

ALTER ROLE { role_specification | ALL } [ IN DATABASE database_name ] SET configuration_parameter { TO | = } { value | DEFAULT }
ALTER ROLE { role_specification | ALL } [ IN DATABASE database_name ] SET configuration_parameter FROM CURRENT
ALTER ROLE { role_specification | ALL } [ IN DATABASE database_name ] RESET configuration_parameter
ALTER ROLE { role_specification | ALL } [ IN DATABASE database_name ] RESET ALL

where role_specification can be:

    role_name
  | CURRENT_ROLE
  | CURRENT_USER
  | SESSION_USER

DESCRIPTION

ALTER ROLE changes the attributes of a PostgreSQL role.

The first variant of this command listed in the synopsis can change many of the role attributes that can be specified in CREATE ROLE. (All the possible attributes are covered, except that there are no options for adding or removing memberships; use GRANT and REVOKE for that.) Attributes not mentioned in the command retain their previous settings. Database superusers can change any of these settings for any role. Non-superuser roles having CREATEROLE privilege can change most of these properties, but only for non-superuser and non-replication roles for which they have been granted ADMIN OPTION. Non-superusers cannot change the SUPERUSER property and can change the CREATEDB, REPLICATION, and BYPASSRLS properties only if they possess the corresponding property themselves. Ordinary roles can only change their own password.

The second variant changes the name of the role. Database superusers can rename any role. Roles having CREATEROLE privilege can rename non-superuser roles for which they have been granted ADMIN OPTION. The current session user cannot be renamed. (Connect as a different user if you need to do that.) Because MD5-encrypted passwords use the role name as cryptographic salt, renaming a role clears its password if the password is MD5-encrypted.

The remaining variants change a roles session default for a configuration variable, either for all databases or, when the IN DATABASE clause is specified, only for sessions in the named database. If ALL is specified instead of a role name, this changes the setting for all roles. Using ALL with IN DATABASE is effectively the same as using the command ALTER DATABASE … SET ….

Whenever the role subsequently starts a new session, the specified value becomes the session default, overriding whatever setting is present in postgresql.conf or has been received from the postgres command line. This only happens at login time; executing SET ROLE or SET SESSION AUTHORIZATION does not cause new configuration values to be set. Settings set for all databases are overridden by database-specific settings attached to a role. Settings for specific databases or specific roles override settings for all roles.

Superusers can change anyones session defaults. Roles having CREATEROLE privilege can change defaults for non-superuser roles for which they have been granted ADMIN OPTION. Ordinary roles can only set defaults for themselves. Certain configuration variables cannot be set this way, or can only be set if a superuser issues the command. Only superusers can change a setting for all roles in all databases.

PARAMETERS

name

The name of the role whose attributes are to be altered.

CURRENT_ROLE
CURRENT_USER

Alter the current user instead of an explicitly identified role.

SESSION_USER

Alter the current session user instead of an explicitly identified role.

SUPERUSER
NOSUPERUSER
CREATEDB
NOCREATEDB
CREATEROLE
NOCREATEROLE
INHERIT
NOINHERIT
LOGIN
NOLOGIN
REPLICATION
NOREPLICATION
BYPASSRLS
NOBYPASSRLS
CONNECTION LIMIT connlimit
[ ENCRYPTED ] PASSWORD password
PASSWORD NULL
VALID UNTIL timestamp

These clauses alter attributes originally set by CREATE ROLE. For more information, see the CREATE ROLE reference page.

new_name

The new name of the role.

database_name

The name of the database the configuration variable should be set in.

configuration_parameter
value

Set this roles session default for the specified configuration parameter to the given value. If value is DEFAULT or, equivalently, RESET is used, the role-specific variable setting is removed, so the role will inherit the system-wide default setting in new sessions. Use RESET ALL to clear all role-specific settings. SET FROM CURRENT saves the sessions current value of the parameter as the role-specific value. If IN DATABASE is specified, the configuration parameter is set or removed for the given role and database only.

Role-specific variable settings take effect only at login; SET ROLE and SET SESSION AUTHORIZATION do not process role-specific variable settings.

See SET(7) and Chapter 20 for more information about allowed parameter names and values.

NOTES

Use CREATE ROLE to add new roles, and DROP ROLE to remove a role.

ALTER ROLE cannot change a roles memberships. Use GRANT and REVOKE to do that.

Caution must be exercised when specifying an unencrypted password with this command. The password will be transmitted to the server in cleartext, and it might also be logged in the clients command history or the server log. psql(1) contains a command \password that can be used to change a roles password without exposing the cleartext password.

It is also possible to tie a session default to a specific database rather than to a role; see ALTER DATABASE (ALTER_DATABASE(7)). If there is a conflict, database-role-specific settings override role-specific ones, which in turn override database-specific ones.

EXAMPLES

Change a roles password:

ALTER ROLE davide WITH PASSWORD hu8jmn3;

Remove a roles password:

ALTER ROLE davide WITH PASSWORD NULL;

Change a password expiration date, specifying that the password should expire at midday on 4th May 2015 using the time zone which is one hour ahead of UTC:

ALTER ROLE chris VALID UNTIL May 4 12:00:00 2015 +1;

Make a password valid forever:

ALTER ROLE fred VALID UNTIL infinity;

Give a role the ability to manage other roles and create new databases:

ALTER ROLE miriam CREATEROLE CREATEDB;

Give a role a non-default setting of the maintenance_work_mem parameter:

ALTER ROLE worker_bee SET maintenance_work_mem = 100000;

Give a role a non-default, database-specific setting of the client_min_messages parameter:

ALTER ROLE fred IN DATABASE devel SET client_min_messages = DEBUG;

COMPATIBILITY

The ALTER ROLE statement is a PostgreSQL extension.

SEE ALSO

CREATE ROLE (CREATE_ROLE(7)), DROP ROLE (DROP_ROLE(7)), ALTER DATABASE (ALTER_DATABASE(7)), SET(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

93 - Linux cli command life_cycle-pkeyssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command life_cycle-pkeyssl and provides detailed information about the command life_cycle-pkeyssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the life_cycle-pkeyssl.

NAME 🖥️ life_cycle-pkeyssl 🖥️

pkey - The PKEY algorithm life-cycle

DESCRIPTION

All public keys (PKEYs) go through a number of stages in their life-cycle:

start
This state represents the PKEY before it has been allocated. It is the starting state for any life-cycle transitions.

newed
This state represents the PKEY after it has been allocated.

decapsulate
This state represents the PKEY when it is ready to perform a private key decapsulation operation.

decrypt
This state represents the PKEY when it is ready to decrypt some ciphertext.

derive
This state represents the PKEY when it is ready to derive a shared secret.

digest sign
This state represents the PKEY when it is ready to perform a private key signature operation.

encapsulate
This state represents the PKEY when it is ready to perform a public key encapsulation operation.

encrypt
This state represents the PKEY when it is ready to encrypt some plaintext.

key generation
This state represents the PKEY when it is ready to generate a new public/private key.

parameter generation
This state represents the PKEY when it is ready to generate key parameters.

verify
This state represents the PKEY when it is ready to verify a public key signature.

verify recover
This state represents the PKEY when it is ready to recover a public key signature data.

freed
This state is entered when the PKEY is freed. It is the terminal state for all life-cycle transitions.

State Transition Diagram

The usual life-cycle of a PKEY object is illustrated: +————-+ | | | start | | | EVP_PKEY_derive +————-+ +————-+ EVP_PKEY_derive_set_peer | +————-+ | |—————————-+ | +—————————-| | | derive | | | | EVP_PKEY_verify | verify | | |<—————————+ | +—————————>| | +————-+ | +————-+ ^ | ^ | EVP_PKEY_derive_init | EVP_PKEY_verify_init | +—————————————+ | +—————————————+ | | | +————-+ | | | +————-+ | |—————————-+ | | | +—————————-| | | digest sign | EVP_PKEY_sign | | | | | EVP_PKEY_verify_recover | verify | | |<—————————+ | | | +—————————>| recover | +————-+ | | | +————-+ ^ | | | ^ | EVP_PKEY_sign_init | | | EVP_PKEY_verify_recover_init | +———————————+ | | | +———————————+ | | | | | +————-+ | | | | | +————-+ | |—————————-+ | | | | | +—————————-| | | decapsulate | EVP_PKEY_decapsulate | | | | | | | EVP_PKEY_decrypt | decrypt | | |<—————————+ | | v | | +—————————>| | +————-+ | +————-+ | +————-+ ^ +—| |—+ ^ | EVP_PKEY_decapsulate_init | | EVP_PKEY_decrypt_init | +————————————-| newed |————————————-+ | | +—| |—+ +————-+ | +————-+ | +————-+ | |—————————-+ | | | | +—————————-| | | encapsulate | EVP_PKEY_encapsulate | | | | | | EVP_PKEY_encrypt | encrypt | | |<—————————+ | | | | +—————————>| | +————-+ | | | | +————-+ ^ | | | | ^ | EVP_PKEY_encapsulate_init | | | | EVP_PKEY_encrypt_init | +———————————+ | | +———————————+ | | +—————————————+ +—————————————+ | EVP_PKEY_paramgen_init EVP_PKEY_keygen_init | v v +————-+ +————-+ | |—————————-+ +—————————-| | | parameter | | | | key | | generation |<—————————+ +—————————>| generation | +————-+ EVP_PKEY_paramgen EVP_PKEY_keygen +————-+ EVP_PKEY_gen EVP_PKEY_gen

+ - - - - - + +———–+ ’ ’ EVP_PKEY_CTX_free | | ’ any state ‘——————->| freed | ’ ’ | | + - - - - - + +———–+

Formal State Transitions

This section defines all of the legal state transitions. This is the canonical list. Function Call ———————————————————————- Current State ———————————————————————- start newed digest verify verify encrypt decrypt derive encapsulate decapsulate parameter key freed sign recover generation generation EVP_PKEY_CTX_new newed EVP_PKEY_CTX_new_id newed EVP_PKEY_CTX_new_from_name newed EVP_PKEY_CTX_new_from_pkey newed EVP_PKEY_sign_init digest digest digest digest digest digest digest digest digest digest digest sign sign sign sign sign sign sign sign sign sign sign EVP_PKEY_sign digest sign EVP_PKEY_verify_init verify verify verify verify verify verify verify verify verify verify verify EVP_PKEY_verify verify EVP_PKEY_verify_recover_init verify verify verify verify verify verify verify verify verify verify verify recover recover recover recover recover recover recover recover recover recover recover EVP_PKEY_verify_recover verify recover EVP_PKEY_encrypt_init encrypt encrypt encrypt encrypt encrypt encrypt encrypt encrypt encrypt encrypt encrypt EVP_PKEY_encrypt encrypt EVP_PKEY_decrypt_init decrypt decrypt decrypt decrypt decrypt decrypt decrypt decrypt decrypt decrypt decrypt EVP_PKEY_decrypt decrypt EVP_PKEY_derive_init derive derive derive derive derive derive derive derive derive derive derive EVP_PKEY_derive_set_peer derive EVP_PKEY_derive derive EVP_PKEY_encapsulate_init encapsulate encapsulate encapsulate encapsulate encapsulate encapsulate encapsulate encapsulate encapsulate encapsulate encapsulate EVP_PKEY_encapsulate encapsulate EVP_PKEY_decapsulate_init decapsulate decapsulate decapsulate decapsulate decapsulate decapsulate decapsulate decapsulate decapsulate decapsulate decapsulate EVP_PKEY_decapsulate decapsulate EVP_PKEY_paramgen_init parameter parameter parameter parameter parameter parameter parameter parameter parameter parameter parameter generation generation generation generation generation generation generation generation generation generation generation EVP_PKEY_paramgen parameter generation EVP_PKEY_keygen_init key key key key key key key key key key key generation generation generation generation generation generation generation generation generation generation generation EVP_PKEY_keygen key generation EVP_PKEY_gen parameter key generation generation EVP_PKEY_CTX_get_params newed digest verify verify encrypt decrypt derive encapsulate decapsulate parameter key sign recover generation generation EVP_PKEY_CTX_set_params newed digest verify verify encrypt decrypt derive encapsulate decapsulate parameter key sign recover generation generation EVP_PKEY_CTX_gettable_params newed digest verify verify encrypt decrypt derive encapsulate decapsulate parameter key sign recover generation generation EVP_PKEY_CTX_settable_params newed digest verify verify encrypt decrypt derive encapsulate decapsulate parameter key sign recover generation generation EVP_PKEY_CTX_free freed freed freed freed freed freed freed freed freed freed freed freed

NOTES

At some point the EVP layer will begin enforcing the transitions described herein.

SEE ALSO

EVP_PKEY_new (3), EVP_PKEY_decapsulate (3), EVP_PKEY_decrypt (3), EVP_PKEY_encapsulate (3), EVP_PKEY_encrypt (3), EVP_PKEY_derive (3), EVP_PKEY_keygen (3), EVP_PKEY_sign (3), EVP_PKEY_verify (3), EVP_PKEY_verify_recover (3)

HISTORY

The provider PKEY interface was introduced in OpenSSL 3.0.

COPYRIGHT

Copyright 2021-2022 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

94 - Linux cli command pty

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command pty and provides detailed information about the command pty, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the pty.

NAME 🖥️ pty 🖥️

pseudoterminal interfaces

DESCRIPTION

A pseudoterminal (sometimes abbreviated “pty”) is a pair of virtual character devices that provide a bidirectional communication channel. One end of the channel is called the master; the other end is called the slave.

The slave end of the pseudoterminal provides an interface that behaves exactly like a classical terminal. A process that expects to be connected to a terminal, can open the slave end of a pseudoterminal and then be driven by a program that has opened the master end. Anything that is written on the master end is provided to the process on the slave end as though it was input typed on a terminal. For example, writing the interrupt character (usually control-C) to the master device would cause an interrupt signal (SIGINT) to be generated for the foreground process group that is connected to the slave. Conversely, anything that is written to the slave end of the pseudoterminal can be read by the process that is connected to the master end.

Data flow between master and slave is handled asynchronously, much like data flow with a physical terminal. Data written to the slave will be available at the master promptly, but may not be available immediately. Similarly, there may be a small processing delay between a write to the master, and the effect being visible at the slave.

Historically, two pseudoterminal APIs have evolved: BSD and System V. SUSv1 standardized a pseudoterminal API based on the System V API, and this API should be employed in all new programs that use pseudoterminals.

Linux provides both BSD-style and (standardized) System V-style pseudoterminals. System V-style terminals are commonly called UNIX 98 pseudoterminals on Linux systems.

Since Linux 2.6.4, BSD-style pseudoterminals are considered deprecated: support can be disabled when building the kernel by disabling the CONFIG_LEGACY_PTYS option. (Starting with Linux 2.6.30, that option is disabled by default in the mainline kernel.) UNIX 98 pseudoterminals should be used in new applications.

UNIX 98 pseudoterminals

An unused UNIX 98 pseudoterminal master is opened by calling posix_openpt(3). (This function opens the master clone device, /dev/ptmx; see pts(4).) After performing any program-specific initializations, changing the ownership and permissions of the slave device using grantpt(3), and unlocking the slave using unlockpt(3)), the corresponding slave device can be opened by passing the name returned by ptsname(3) in a call to open(2).

The Linux kernel imposes a limit on the number of available UNIX 98 pseudoterminals. Up to and including Linux 2.6.3, this limit is configured at kernel compilation time (CONFIG_UNIX98_PTYS), and the permitted number of pseudoterminals can be up to 2048, with a default setting of 256. Since Linux 2.6.4, the limit is dynamically adjustable via /proc/sys/kernel/pty/max, and a corresponding file, /proc/sys/kernel/pty/nr, indicates how many pseudoterminals are currently in use. For further details on these two files, see proc(5).

BSD pseudoterminals

BSD-style pseudoterminals are provided as precreated pairs, with names of the form /dev/ptyXY (master) and /dev/ttyXY (slave), where X is a letter from the 16-character set [p-za-e], and Y is a letter from the 16-character set [0-9a-f]. (The precise range of letters in these two sets varies across UNIX implementations.) For example, /dev/ptyp1 and /dev/ttyp1 constitute a BSD pseudoterminal pair. A process finds an unused pseudoterminal pair by trying to open(2) each pseudoterminal master until an open succeeds. The corresponding pseudoterminal slave (substitute “tty” for “pty” in the name of the master) can then be opened.

FILES

/dev/ptmx
UNIX 98 master clone device

/dev/pts/*
UNIX 98 slave devices

/dev/pty[p-za-e][0-9a-f]
BSD master devices

/dev/tty[p-za-e][0-9a-f]
BSD slave devices

NOTES

Pseudoterminals are used by applications such as network login services ( ssh(1), rlogin(1), telnet(1)), terminal emulators such as xterm(1), script(1), screen(1), tmux(1), unbuffer(1), and expect(1).

A description of the TIOCPKT ioctl(2), which controls packet mode operation, can be found in ioctl_tty(2).

The BSD ioctl(2) operations TIOCSTOP, TIOCSTART, TIOCUCNTL, and TIOCREMOTE have not been implemented under Linux.

SEE ALSO

ioctl_tty(2), select(2), setsid(2), forkpty(3), openpty(3), termios(3), pts(4), tty(4)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

95 - Linux cli command udev

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command udev and provides detailed information about the command udev, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the udev.

NAME 🖥️ udev 🖥️

Dynamic device management

DESCRIPTION

udev supplies the system software with device events, manages permissions of device nodes and may create additional symlinks in the /dev/ directory, or renames network interfaces. The kernel usually just assigns unpredictable device names based on the order of discovery. Meaningful symlinks or network device names provide a way to reliably identify devices based on their properties or current configuration.

The udev daemon, systemd-udevd.service(8), receives device uevents directly from the kernel whenever a device is added or removed from the system, or it changes its state. When udev receives a device event, it matches its configured set of rules against various device attributes to identify the device. Rules that match may provide additional device information to be stored in the udev database or to be used to create meaningful symlink names.

All device information udev processes is stored in the udev database and sent out to possible event subscribers. Access to all stored data and the event sources is provided by the library libudev.

RULES FILES

The udev rules are read from the files located in the system rules directories /usr/lib/udev/rules.d and /usr/local/lib/udev/rules.d, the volatile runtime directory /run/udev/rules.d and the local administration directory /etc/udev/rules.d. All rules files are collectively sorted and processed in lexical order, regardless of the directories in which they live. However, files with identical filenames replace each other. Files in /etc/ have the highest priority, files in /run/ take precedence over files with the same name under /usr/. This can be used to override a system-supplied rules file with a local file if needed; a symlink in /etc/ with the same name as a rules file in /usr/lib/, pointing to /dev/null, disables the rules file entirely. Rule files must have the extension .rules; other extensions are ignored.

Every line in the rules file contains at least one key-value pair. Except for empty lines or lines beginning with “#”, which are ignored. There are two kinds of keys: match and assignment. If all match keys match against their values, the rule gets applied and the assignment keys get the specified values assigned.

A matching rule may rename a network interface, add symlinks pointing to the device node, or run a specified program as part of the event handling.

A rule consists of a comma-separated list of one or more key-operator-value expressions. Each expression has a distinct effect, depending on the key and operator used.

Operators

“==”

Compare for equality. (The specified key has the specified value.)

“!=”

Compare for inequality. (The specified key doesnt have the specified value, or the specified key is not present at all.)

“=”

Assign a value to a key. Keys that represent a list are reset and only this single value is assigned.

“+=”

Add the value to a key that holds a list of entries.

“-=”

Remove the value from a key that holds a list of entries.

Added in version 217.

“:=”

Assign a value to a key finally; disallow any later changes.

Added in version 247.

Values

Values are written as double quoted strings, such as (“string”). To include a quotation mark (") in the value, precede it by a backslash (). Any other occurrences of a backslash followed by a character are not unescaped. That is, " " is treated as four characters: backslash, lowercase t, backslash, lowercase n.

The string can be prefixed with a lowercase e (e"string “) to mark the string as C-style escaped, see Escape sequences in C[1]. For example, e"string " is parsed as 7 characters: 6 lowercase letters and a newline. This can be useful for writing special characters when a kernel driver requires them.

Please note that NUL is not allowed in either string variant.

Keys

The following key names can be used to match against device properties. Some of the keys also match against properties of the parent devices in sysfs, not only the device that has generated the event. If multiple keys that match a parent device are specified in a single rule, all these keys must match at one and the same parent device.

ACTION

Match the name of the event action.

DEVPATH

Match the devpath of the event device.

KERNEL

Match the name of the event device.

KERNELS

Search the devpath upwards for a matching device name.

NAME

Match the name of a network interface. It can be used once the NAME key has been set in one of the preceding rules.

SYMLINK

Match the name of a symlink targeting the node. It can be used once a SYMLINK key has been set in one of the preceding rules. There may be multiple symlinks; only one needs to match. If the operator is “!=”, the token returns true only if there is no symlink matched.

SUBSYSTEM

Match the subsystem of the event device.

SUBSYSTEMS

Search the devpath upwards for a matching device subsystem name.

DRIVER

Match the driver name of the event device. Only set this key for devices which are bound to a driver at the time the event is generated.

DRIVERS

Search the devpath upwards for a matching device driver name.

ATTR{filename}

Match sysfs attribute value of the event device.

Trailing whitespace in the attribute values is ignored unless the specified match value itself contains trailing whitespace.

ATTRS{filename}

Search the devpath upwards for a device with matching sysfs attribute values. If multiple ATTRS matches are specified, all of them must match on the same device.

Trailing whitespace in the attribute values is ignored unless the specified match value itself contains trailing whitespace.

SYSCTL{kernel parameter}

Match a kernel parameter value.

Added in version 240.

ENV{key}

Match against a device property value.

CONST{key}

Match against a system-wide constant. Supported keys are:

“arch”

Systems architecture. See ConditionArchitecture= in systemd.unit(5) for possible values.

Added in version 244.

“virt”

Systems virtualization environment. See systemd-detect-virt(1) for possible values.

Added in version 244.

“cvm”

Systems confidential virtualization technology. See systemd-detect-virt(1) for possible values.

Added in version 254.

Unknown keys will never match.

Added in version 244.

TAG

Match against one of device tags. It can be used once a TAG key has been set in one of the preceding rules. There may be multiple tags; only one needs to match. If the operator is “!=”, the token returns true only if there is no tag matched.

TAGS

Search the devpath upwards for a device with matching tag. If the operator is “!=”, the token returns true only if there is no tag matched.

TEST{octal mode mask}

Test the existence of a file. An octal mode mask can be specified if needed.

PROGRAM

Execute a program to determine whether there is a match; the key is true if the program returns successfully. The device properties are made available to the executed program in the environment. The programs standard output is available in the RESULT key.

This can only be used for very short-running foreground tasks. For details, see RUN.

Note that multiple PROGRAM keys may be specified in one rule, and “=”, “:=”, and “+=” have the same effect as “==”.

RESULT

Match the returned string of the last PROGRAM call. This key can be used in the same or in any later rule after a PROGRAM call.

Most of the fields support shell glob pattern matching and alternate patterns. The following special characters are supported:

“*”

Matches zero or more characters.

“?”

Matches any single character.

“[]”

Matches any single character specified within the brackets. For example, the pattern string “tty[SR]” would match either “ttyS” or “ttyR”. Ranges are also supported via the “-” character. For example, to match on the range of all digits, the pattern “[0-9]” could be used. If the first character following the “[” is a “!”, any characters not enclosed are matched.

“|”

Separates alternative patterns. For example, the pattern string “abc|x*” would match either “abc” or “x*”.

Added in version 217.

The following keys can get values assigned:

NAME

The name to use for a network interface. See systemd.link(5) for a higher-level mechanism for setting the interface name. The name of a device node cannot be changed by udev, only additional symlinks can be created.

SYMLINK

The name of a symlink targeting the node. Every matching rule adds this value to the list of symlinks to be created.

The set of characters to name a symlink is limited. Allowed characters are “0-9A-Za-z#+-.:=@_/”, valid UTF-8 character sequences, and “�” hex encoding. All other characters are replaced by a “_” character.

Multiple symlinks may be specified by separating the names by the space character. In case multiple devices claim the same name, the link always points to the device with the highest link_priority. If the current device goes away, the links are re-evaluated and the device with the next highest link_priority becomes the owner of the link. If no link_priority is specified, the order of the devices (and which one of them owns the link) is undefined.

Symlink names must never conflict with the kernels default device node names, as that would result in unpredictable behavior.

OWNER, GROUP, MODE

The permissions for the device node. Every specified value overrides the compiled-in default value.

SECLABEL{module}

Applies the specified Linux Security Module label to the device node.

Added in version 209.

ATTR{key}

The value that should be written to a sysfs attribute of the event device.

SYSCTL{kernel parameter}

The value that should be written to kernel parameter.

Added in version 220.

ENV{key}

Set a device property value. Property names with a leading “.” are neither stored in the database nor exported to events or external tools (run by, for example, the PROGRAM match key).

TAG

Attach a tag to a device. This is used to filter events for users of libudevs monitor functionality, or to enumerate a group of tagged devices. The implementation can only work efficiently if only a few tags are attached to a device. It is only meant to be used in contexts with specific device filter requirements, and not as a general-purpose flag. Excessive use might result in inefficient event handling.

RUN{type}

Specify a program to be executed after processing of all the rules for the event. With “+=”, this invocation is added to the list, and with “=” or “:=”, it replaces any previous contents of the list. Please note that both “program” and “builtin” types described below share a common list, so clearing the list with “:=” and “=” affects both types.

type may be:

“program”

Execute an external program specified as the assigned value. If no absolute path is given, the program is expected to live in /usr/lib/udev; otherwise, the absolute path must be specified.

This is the default if no type is specified.

“builtin”

As program, but use one of the built-in programs rather than an external one.

Added in version 199.

The program name and following arguments are separated by spaces. Single quotes can be used to specify arguments with spaces.

This can only be used for very short-running foreground tasks. Running an event process for a long period of time may block all further events for this or a dependent device.

Note that running programs that access the network or mount/unmount filesystems is not allowed inside of udev rules, due to the default sandbox that is enforced on systemd-udevd.service.

Starting daemons or other long-running processes is not allowed; the forked processes, detached or not, will be unconditionally killed after the event handling has finished. In order to activate long-running processes from udev rules, provide a service unit and pull it in from a udev device using the SYSTEMD_WANTS device property. See systemd.device(5) for details.

LABEL

A named label to which a GOTO may jump.

GOTO

Jumps to the next LABEL with a matching name.

IMPORT{type}

Import a set of variables as device properties, depending on type:

“program”

Execute an external program specified as the assigned value and, if it returns successfully, import its output, which must be in environment key format. Path specification, command/argument separation, and quoting work like in RUN.

Added in version 199.

“builtin”

Similar to “program”, but use one of the built-in programs rather than an external one.

Added in version 199.

“file”

Import a text file specified as the assigned value, the content of which must be in environment key format.

“db”

Import a single property specified as the assigned value from the current device database. This works only if the database is already populated by an earlier event.

“cmdline”

Import a single property from the kernel command line. For simple flags the value of the property is set to “1”.

“parent”

Import the stored keys from the parent device by reading the database entry of the parent device. The value assigned to IMPORT{parent} is used as a filter of key names to import (with the same shell glob pattern matching used for comparisons).

This can only be used for very short-running foreground tasks. For details see RUN.

Note that multiple IMPORT{} keys may be specified in one rule, and “=”, “:=”, and “+=” have the same effect as “==”. The key is true if the import is successful, unless “!=” is used as the operator which causes the key to be true if the import failed.

OPTIONS

Rule and device options:

**link_priority=**value

Specify the priority of the created symlinks. Devices with higher priorities overwrite existing symlinks of other devices. The default is 0.

**string_escape=**none|replace

When “replace”, possibly unsafe characters in strings assigned to NAME, SYMLINK, and ENV{key} are replaced. When “none”, no replacement is performed. When unset, the replacement is performed for NAME, SYMLINK, but not for ENV{key}. Defaults to unset.

static_node=

Apply the permissions specified in this rule to the static device node with the specified name. Also, for every tag specified in this rule, create a symlink in the directory /run/udev/static_node-tags/tag pointing at the static device node with the specified name. Static device node creation is performed by systemd-tmpfiles before systemd-udevd is started. The static nodes might not have a corresponding kernel device; they are used to trigger automatic kernel module loading when they are accessed.

watch

Watch the device node with inotify; when the node is closed after being opened for writing, a change uevent is synthesized.

nowatch

Disable the watching of a device node with inotify.

db_persist

Set the flag (sticky bit) on the udev database entry of the event device. Device properties are then kept in the database even when udevadm info –cleanup-db is called. This option can be useful in certain cases (e.g. Device Mapper devices) for persisting device state on the transition from initrd.

Added in version 241.

**log_level=**level

Takes a log level name like “debug” or “info”, or a special value “reset”. When a log level name is specified, the maximum log level is changed to that level. When “reset” is set, then the previously specified log level is revoked. Defaults to the log level of the main process of systemd-udevd.

This may be useful when debugging events for certain devices. Note that the log level is applied when the line including this rule is processed. So, for debugging, it is recommended that this is specified at earlier place, e.g., the first line of 00-debug.rules.

Example for debugging uevent processing for network interfaces:

/etc/udev/rules.d/00-debug-net.rules

SUBSYSTEM=="net", OPTIONS="log_level=debug"

Added in version 248.

The ENV, GROUP, MODE, NAME, OWNER, PROGRAM, RUN, SECLABEL, and SYMLINK fields support simple string substitutions. The RUN substitutions are performed after all rules have been processed, right before the program is executed, allowing for the use of device properties set by earlier matching rules. For all other fields, substitutions are performed while the individual rule is being processed. The available substitutions are:

$kernel, %k

The kernel name for this device.

$number, %n

The kernel number for this device. For example, “sda3” has kernel number 3.

$devpath, %p

The devpath of the device.

$id, %b

The name of the device matched while searching the devpath upwards for SUBSYSTEMS, KERNELS, DRIVERS, and ATTRS.

$driver

The driver name of the device matched while searching the devpath upwards for SUBSYSTEMS, KERNELS, DRIVERS, and ATTRS.

$attr{file}, %s{file}

The value of a sysfs attribute found at the device where all keys of the rule have matched. If the matching device does not have such an attribute, and a previous KERNELS, SUBSYSTEMS, DRIVERS, or ATTRS test selected a parent device, then the attribute from that parent device is used.

If the attribute is a symlink, the last element of the symlink target is returned as the value.

$env{key}, %E{key}

A device property value.

$major, %M

The kernel major number for the device.

$minor, %m

The kernel minor number for the device.

$result, %c

The string returned by the external program requested with PROGRAM. A single part of the string, separated by a space character, may be selected by specifying the part number as an attribute: “%c{N}”. If the number is followed by the “+” character, this part plus all remaining parts of the result string are substituted: “%c{N+}”.

$parent, %P

The node name of the parent device.

$name

The current name of the device. If not changed by a rule, it is the name of the kernel device.

$links

A space-separated list of the current symlinks. The value is only set during a remove event or if an earlier rule assigned a value.

$root, %r

The udev_root value.

$sys, %S

The sysfs mount point.

$devnode, %N

The name of the device node.

%%

The “%” character itself.

$$

The “$” character itself.

SEE ALSO

systemd-udevd.service(8), udevadm(8), systemd.link(5)

NOTES

Escape sequences in C

https://en.wikipedia.org/wiki/Escape_sequences_in_C#Table_of_escape_sequences

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

96 - Linux cli command address_families

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command address_families and provides detailed information about the command address_families, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the address_families.

NAME 🖥️ address_families 🖥️

socket address families (domains)

SYNOPSIS

#include <sys/types.h> /* See NOTES */
#include <sys/socket.h>
int socket(int domain, int type, int protocol);

DESCRIPTION

The domain argument of the socket(2) specifies a communication domain; this selects the protocol family which will be used for communication. These families are defined in <sys/socket.h>. The formats currently understood by the Linux kernel include:

AF_UNIX
AF_LOCAL
Local communication. For further information, see unix(7).

AF_INET
IPv4 Internet protocols. For further information, see ip(7).

AF_AX25
Amateur radio AX.25 protocol. For further information, see ax25(4).

AF_IPX
IPX - Novell protocols.

AF_APPLETALK
AppleTalk For further information, see ddp(7).

AF_NETROM
AX.25 packet layer protocol. For further information, see netrom(4),

The Packet Radio Protocols and Linux

and the AX.25, NET/ROM, and ROSE network programming chapters of the

Linux Amateur Radio AX.25 HOWTO

AF_BRIDGE
Can’t be used for creating sockets; mostly used for bridge links in rtnetlink(7) protocol commands.

AF_ATMPVC
Access to raw ATM Permanent Virtual Circuits (PVCs). For further information, see the

ATM on Linux HOWTO

AF_X25
ITU-T X.25 / ISO/IEC 8208 protocol. For further information, see x25(7).

AF_INET6
IPv6 Internet protocols. For further information, see ipv6(7).

AF_ROSE
RATS (Radio Amateur Telecommunications Society). Open Systems environment (ROSE) AX.25 packet layer protocol. For further information, see the resources listed for AF_NETROM.

AF_DECnet
DECet protocol sockets. See Documentation/networking/decnet.txt in the Linux kernel source tree for details.

AF_NETBEUI
Reserved for “802.2LLC project”; never used.

AF_SECURITY
This was a short-lived (between Linux 2.1.30 and 2.1.99pre2) protocol family for firewall upcalls.

AF_KEY
Key management protocol, originally developed for usage with IPsec (since Linux 2.1.38). This has no relation to keyctl(2) and the in-kernel key storage facility. See

RFC 2367 PF_KEY Key Management API, Version 2

for details.

AF_NETLINK
Kernel user interface device. For further information, see netlink(7).

AF_PACKET
Low-level packet interface. For further information, see packet(7).

AF_ECONET
Acorn Econet protocol (removed in Linux 3.5). See the Econet documentation for details.

AF_ATMSVC
Access to ATM Switched Virtual Circuits (SVCs) See the

ATM on Linux HOWTO

for details.

AF_RDS
Reliable Datagram Sockets (RDS) protocol (since Linux 2.6.30). RDS over RDMA has no relation to AF_SMC or AF_XDP. For further information, see rds(7), rds-rdma(7), and Documentation/networking/rds.txt in the Linux kernel source tree.

AF_IRDA
Socket interface over IrDA (moved to staging in Linux 4.14, removed in Linux 4.17). For further information, see irda(7).

AF_PPPOX
Generic PPP transport layer, for setting up L2 tunnels (L2TP and PPPoE). See Documentation/networking/l2tp.txt in the Linux kernel source tree for details.

AF_WANPIPE
Legacy protocol for wide area network (WAN) connectivity that was used by Sangoma WAN cards (called “WANPIPE”); removed in Linux 2.6.21.

AF_LLC
Logical link control (IEEE 802.2 LLC) protocol, upper part of data link layer of ISO/OSI networking protocol stack (since Linux 2.4); has no relation to AF_PACKET. See chapter 13.5.3. Logical Link Control in Understanding Linux Kernel Internals (O’Reilly Media, 2006) and IEEE Standards for Local Area Networks: Logical Link Control (The Institute of Electronics and Electronics Engineers, Inc., New York, New York, 1985) for details. See also some historical notes regarding its development.

AF_IB
InfiniBand native addressing (since Linux 3.11).

AF_MPLS
Multiprotocol Label Switching (since Linux 4.1); mostly used for configuring MPLS routing via netlink(7), as it doesn’t expose ability to create sockets to user space.

AF_CAN
Controller Area Network automotive bus protocol (since Linux 2.6.25). See Documentation/networking/can.rst in the Linux kernel source tree for details.

AF_TIPC
TIPC, “cluster domain sockets” protocol (since Linux 2.6.16). See

TIPC Programmer’s Guide

and the protocol description for details.

AF_BLUETOOTH
Bluetooth low-level socket protocol (since Linux 3.11). See

Bluetooth Management API overview

and

An Introduction to Bluetooth Programming by Albert Huang

for details.

AF_IUCV
IUCV (inter-user communication vehicle) z/VM protocol for hypervisor-guest interaction (since Linux 2.6.21); has no relation to AF_VSOCK and/or AF_SMC See

IUCV protocol overview

for details.

AF_RXRPC
Rx, Andrew File System remote procedure call protocol (since Linux 2.6.22). See Documentation/networking/rxrpc.txt in the Linux kernel source tree for details.

AF_ISDN
New “modular ISDN” driver interface protocol (since Linux 2.6.27). See the mISDN wiki for details.

AF_PHONET
Nokia cellular modem IPC/RPC interface (since Linux 2.6.31). See Documentation/networking/phonet.txt in the Linux kernel source tree for details.

AF_IEEE802154
IEEE 802.15.4 WPAN (wireless personal area network) raw packet protocol (since Linux 2.6.31). See Documentation/networking/ieee802154.txt in the Linux kernel source tree for details.

AF_CAIF
Ericsson’s Communication CPU to Application CPU interface (CAIF) protocol (since Linux 2.6.36). See Documentation/networking/caif/Linux-CAIF.txt in the Linux kernel source tree for details.

AF_ALG
Interface to kernel crypto API (since Linux 2.6.38). See Documentation/crypto/userspace-if.rst in the Linux kernel source tree for details.

AF_VSOCK
VMWare VSockets protocol for hypervisor-guest interaction (since Linux 3.9); has no relation to AF_IUCV and AF_SMC. For further information, see vsock(7).

AF_KCM
KCM (kernel connection multiplexer) interface (since Linux 4.6). See Documentation/networking/kcm.txt in the Linux kernel source tree for details.

AF_QIPCRTR
Qualcomm IPC router interface protocol (since Linux 4.7).

AF_SMC
SMC-R (shared memory communications over RDMA) protocol (since Linux 4.11), and SMC-D (shared memory communications, direct memory access) protocol for intra-node z/VM quest interaction (since Linux 4.19); has no relation to AF_RDS, AF_IUCV or AF_VSOCK. See

RFC 7609 IBM’s Shared Memory Communications over RDMA (SMC-R) Protocol

for details regarding SMC-R. See

SMC-D Reference Information

for details regarding SMC-D.

AF_XDP
XDP (express data path) interface (since Linux 4.18). See Documentation/networking/af_xdp.rst in the Linux kernel source tree for details.

SEE ALSO

socket(2), socket(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

97 - Linux cli command ALTER_RULE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_RULE and provides detailed information about the command ALTER_RULE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_RULE.

NAME 🖥️ ALTER_RULE 🖥️

change the definition of a rule

SYNOPSIS

ALTER RULE name ON table_name RENAME TO new_name

DESCRIPTION

ALTER RULE changes properties of an existing rule. Currently, the only available action is to change the rules name.

To use ALTER RULE, you must own the table or view that the rule applies to.

PARAMETERS

name

The name of an existing rule to alter.

table_name

The name (optionally schema-qualified) of the table or view that the rule applies to.

new_name

The new name for the rule.

EXAMPLES

To rename an existing rule:

ALTER RULE notify_all ON emp RENAME TO notify_me;

COMPATIBILITY

ALTER RULE is a PostgreSQL language extension, as is the entire query rewrite system.

SEE ALSO

CREATE RULE (CREATE_RULE(7)), DROP RULE (DROP_RULE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

98 - Linux cli command COMMENT

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command COMMENT and provides detailed information about the command COMMENT, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the COMMENT.

NAME 🖥️ COMMENT 🖥️

define or change the comment of an object

SYNOPSIS

COMMENT ON
{
  ACCESS METHOD object_name |
  AGGREGATE aggregate_name ( aggregate_signature ) |
  CAST (source_type AS target_type) |
  COLLATION object_name |
  COLUMN relation_name.column_name |
  CONSTRAINT constraint_name ON table_name |
  CONSTRAINT constraint_name ON DOMAIN domain_name |
  CONVERSION object_name |
  DATABASE object_name |
  DOMAIN object_name |
  EXTENSION object_name |
  EVENT TRIGGER object_name |
  FOREIGN DATA WRAPPER object_name |
  FOREIGN TABLE object_name |
  FUNCTION function_name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ] |
  INDEX object_name |
  LARGE OBJECT large_object_oid |
  MATERIALIZED VIEW object_name |
  OPERATOR operator_name (left_type, right_type) |
  OPERATOR CLASS object_name USING index_method |
  OPERATOR FAMILY object_name USING index_method |
  POLICY policy_name ON table_name |
  [ PROCEDURAL ] LANGUAGE object_name |
  PROCEDURE procedure_name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ] |
  PUBLICATION object_name |
  ROLE object_name |
  ROUTINE routine_name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ] |
  RULE rule_name ON table_name |
  SCHEMA object_name |
  SEQUENCE object_name |
  SERVER object_name |
  STATISTICS object_name |
  SUBSCRIPTION object_name |
  TABLE object_name |
  TABLESPACE object_name |
  TEXT SEARCH CONFIGURATION object_name |
  TEXT SEARCH DICTIONARY object_name |
  TEXT SEARCH PARSER object_name |
  TEXT SEARCH TEMPLATE object_name |
  TRANSFORM FOR type_name LANGUAGE lang_name |
  TRIGGER trigger_name ON table_name |
  TYPE object_name |
  VIEW object_name
} IS { string_literal | NULL }

where aggregate_signature is:

* |
[ argmode ] [ argname ] argtype [ , ... ] |
[ [ argmode ] [ argname ] argtype [ , ... ] ] ORDER BY [ argmode ] [ argname ] argtype [ , ... ]

DESCRIPTION

COMMENT stores a comment about a database object.

Only one comment string is stored for each object, so to modify a comment, issue a new COMMENT command for the same object. To remove a comment, write NULL in place of the text string. Comments are automatically dropped when their object is dropped.

A SHARE UPDATE EXCLUSIVE lock is acquired on the object to be commented.

For most kinds of object, only the objects owner can set the comment. Roles dont have owners, so the rule for COMMENT ON ROLE is that you must be superuser to comment on a superuser role, or have the CREATEROLE privilege and have been granted ADMIN OPTION on the target role. Likewise, access methods dont have owners either; you must be superuser to comment on an access method. Of course, a superuser can comment on anything.

Comments can be viewed using psqls \d family of commands. Other user interfaces to retrieve comments can be built atop the same built-in functions that psql uses, namely obj_description, col_description, and shobj_description (see Table 9.78).

PARAMETERS

object_name
relation_name.column_name
aggregate_name
constraint_name
function_name
operator_name
policy_name
procedure_name
routine_name
rule_name
trigger_name

The name of the object to be commented. Names of objects that reside in schemas (tables, functions, etc.) can be schema-qualified. When commenting on a column, relation_name must refer to a table, view, composite type, or foreign table.

table_name
domain_name

When creating a comment on a constraint, a trigger, a rule or a policy these parameters specify the name of the table or domain on which that object is defined.

source_type

The name of the source data type of the cast.

target_type

The name of the target data type of the cast.

argmode

The mode of a function, procedure, or aggregate argument: IN, OUT, INOUT, or VARIADIC. If omitted, the default is IN. Note that COMMENT does not actually pay any attention to OUT arguments, since only the input arguments are needed to determine the functions identity. So it is sufficient to list the IN, INOUT, and VARIADIC arguments.

argname

The name of a function, procedure, or aggregate argument. Note that COMMENT does not actually pay any attention to argument names, since only the argument data types are needed to determine the functions identity.

argtype

The data type of a function, procedure, or aggregate argument.

large_object_oid

The OID of the large object.

left_type
right_type

The data type(s) of the operators arguments (optionally schema-qualified). Write NONE for the missing argument of a prefix operator.

PROCEDURAL

This is a noise word.

type_name

The name of the data type of the transform.

lang_name

The name of the language of the transform.

string_literal

The new comment contents, written as a string literal.

NULL

Write NULL to drop the comment.

NOTES

There is presently no security mechanism for viewing comments: any user connected to a database can see all the comments for objects in that database. For shared objects such as databases, roles, and tablespaces, comments are stored globally so any user connected to any database in the cluster can see all the comments for shared objects. Therefore, dont put security-critical information in comments.

EXAMPLES

Attach a comment to the table mytable:

COMMENT ON TABLE mytable IS This is my table.;

Remove it again:

COMMENT ON TABLE mytable IS NULL;

Some more examples:

COMMENT ON ACCESS METHOD gin IS GIN index access method; COMMENT ON AGGREGATE my_aggregate (double precision) IS Computes sample variance; COMMENT ON CAST (text AS int4) IS Allow casts from text to int4; COMMENT ON COLLATION “fr_CA” IS Canadian French; COMMENT ON COLUMN my_table.my_column IS Employee ID number; COMMENT ON CONVERSION my_conv IS Conversion to UTF8; COMMENT ON CONSTRAINT bar_col_cons ON bar IS Constrains column col; COMMENT ON CONSTRAINT dom_col_constr ON DOMAIN dom IS Constrains col of domain; COMMENT ON DATABASE my_database IS Development Database; COMMENT ON DOMAIN my_domain IS Email Address Domain; COMMENT ON EVENT TRIGGER abort_ddl IS Aborts all DDL commands; COMMENT ON EXTENSION hstore IS implements the hstore data type; COMMENT ON FOREIGN DATA WRAPPER mywrapper IS my foreign data wrapper; COMMENT ON FOREIGN TABLE my_foreign_table IS Employee Information in other database; COMMENT ON FUNCTION my_function (timestamp) IS Returns Roman Numeral; COMMENT ON INDEX my_index IS Enforces uniqueness on employee ID; COMMENT ON LANGUAGE plpython IS Python support for stored procedures; COMMENT ON LARGE OBJECT 346344 IS Planning document; COMMENT ON MATERIALIZED VIEW my_matview IS Summary of order history; COMMENT ON OPERATOR ^ (text, text) IS Performs intersection of two texts; COMMENT ON OPERATOR - (NONE, integer) IS Unary minus; COMMENT ON OPERATOR CLASS int4ops USING btree IS 4 byte integer operators for btrees; COMMENT ON OPERATOR FAMILY integer_ops USING btree IS all integer operators for btrees; COMMENT ON POLICY my_policy ON mytable IS Filter rows by users; COMMENT ON PROCEDURE my_proc (integer, integer) IS Runs a report; COMMENT ON PUBLICATION alltables IS Publishes all operations on all tables; COMMENT ON ROLE my_role IS Administration group for finance tables; COMMENT ON ROUTINE my_routine (integer, integer) IS Runs a routine (which is a function or procedure); COMMENT ON RULE my_rule ON my_table IS Logs updates of employee records; COMMENT ON SCHEMA my_schema IS Departmental data; COMMENT ON SEQUENCE my_sequence IS Used to generate primary keys; COMMENT ON SERVER myserver IS my foreign server; COMMENT ON STATISTICS my_statistics IS Improves planner row estimations; COMMENT ON SUBSCRIPTION alltables IS Subscription for all operations on all tables; COMMENT ON TABLE my_schema.my_table IS Employee Information; COMMENT ON TABLESPACE my_tablespace IS Tablespace for indexes; COMMENT ON TEXT SEARCH CONFIGURATION my_config IS Special word filtering; COMMENT ON TEXT SEARCH DICTIONARY swedish IS Snowball stemmer for Swedish language; COMMENT ON TEXT SEARCH PARSER my_parser IS Splits text into words; COMMENT ON TEXT SEARCH TEMPLATE snowball IS Snowball stemmer; COMMENT ON TRANSFORM FOR hstore LANGUAGE plpython3u IS Transform between hstore and Python dict; COMMENT ON TRIGGER my_trigger ON my_table IS Used for RI; COMMENT ON TYPE complex IS Complex number data type; COMMENT ON VIEW my_view IS View of departmental costs;

COMPATIBILITY

There is no COMMENT command in the SQL standard.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

99 - Linux cli command evpssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command evpssl and provides detailed information about the command evpssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the evpssl.

NAME 🖥️ evpssl 🖥️

high-level cryptographic functions

SYNOPSIS

#include <openssl/evp.h>

DESCRIPTION

The EVP library provides a high-level interface to cryptographic functions.

The EVP_SealXXX and EVP_OpenXXX functions provide public key encryption and decryption to implement digital “envelopes”.

The EVP_DigestSignXXX and EVP_DigestVerifyXXX functions implement digital signatures and Message Authentication Codes (MACs). Also see the older EVP_SignXXX and EVP_VerifyXXX functions.

Symmetric encryption is available with the EVP_EncryptXXX functions. The EVP_DigestXXX functions provide message digests.

The EVP_PKEYXXX functions provide a high-level interface to asymmetric algorithms. To create a new EVP_PKEY see EVP_PKEY_new (3). EVP_PKEYs can be associated with a private key of a particular algorithm by using the functions described on the EVP_PKEY_fromdata (3) page, or new keys can be generated using EVP_PKEY_keygen (3). EVP_PKEYs can be compared using EVP_PKEY_eq (3), or printed using EVP_PKEY_print_private (3). EVP_PKEY_todata (3) can be used to convert a key back into an OSSL_PARAM (3) array.

The EVP_PKEY functions support the full range of asymmetric algorithm operations:

For key agreement see EVP_PKEY_derive (3)

For signing and verifying see EVP_PKEY_sign (3), EVP_PKEY_verify (3) and EVP_PKEY_verify_recover (3). However, note that these functions do not perform a digest of the data to be signed. Therefore, normally you would use the EVP_DigestSignInit (3) functions for this purpose.

For encryption and decryption see EVP_PKEY_encrypt (3) and EVP_PKEY_decrypt (3) respectively. However, note that these functions perform encryption and decryption only. As public key encryption is an expensive operation, normally you would wrap an encrypted message in a “digital envelope” using the EVP_SealInit (3) and EVP_OpenInit (3) functions.

The EVP_BytesToKey (3) function provides some limited support for password based encryption. Careful selection of the parameters will provide a PKCS#5 PBKDF1 compatible implementation. However, new applications should not typically use this (preferring, for example, PBKDF2 from PCKS#5).

The EVP_EncodeXXX and EVP_DecodeXXX functions implement base 64 encoding and decoding.

All the symmetric algorithms (ciphers), digests and asymmetric algorithms (public key algorithms) can be replaced by ENGINE modules providing alternative implementations. If ENGINE implementations of ciphers or digests are registered as defaults, then the various EVP functions will automatically use those implementations automatically in preference to built in software implementations. For more information, consult the engine (3) man page.

Although low-level algorithm specific functions exist for many algorithms their use is discouraged. They cannot be used with an ENGINE and ENGINE versions of new algorithms cannot be accessed using the low-level functions. Also makes code harder to adapt to new algorithms and some options are not cleanly supported at the low-level and some operations are more efficient using the high-level interface.

SEE ALSO

EVP_DigestInit (3), EVP_EncryptInit (3), EVP_OpenInit (3), EVP_SealInit (3), EVP_DigestSignInit (3), EVP_SignInit (3), EVP_VerifyInit (3), EVP_EncodeInit (3), EVP_PKEY_new (3), EVP_PKEY_fromdata (3), EVP_PKEY_todata (3), EVP_PKEY_keygen (3), EVP_PKEY_print_private (3), EVP_PKEY_decrypt (3), EVP_PKEY_encrypt (3), EVP_PKEY_sign (3), EVP_PKEY_verify (3), EVP_PKEY_verify_recover (3), EVP_PKEY_derive (3), EVP_BytesToKey (3), ENGINE_by_id (3)

COPYRIGHT

Copyright 2000-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

100 - Linux cli command koi8-r

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command koi8-r and provides detailed information about the command koi8-r, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the koi8-r.

NAME 🖥️ koi8-r 🖥️

r - Russian character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

RFC 1489 defines an 8-bit character set, KOI8-R. KOI8-R encodes the characters used in Russian.

KOI8-R characters

The following table displays the characters in KOI8-R that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

The differences with KOI8-U are in the hex positions A4, A6, A7, AD, B4, B6, B7, and BD.

SEE ALSO

ascii(7), charsets(7), cp1251(7), iso_8859-5(7), koi8-u(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

101 - Linux cli command PREPARE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command PREPARE and provides detailed information about the command PREPARE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the PREPARE.

NAME 🖥️ PREPARE 🖥️

prepare a statement for execution

SYNOPSIS

PREPARE name [ ( data_type [, ...] ) ] AS statement

DESCRIPTION

PREPARE creates a prepared statement. A prepared statement is a server-side object that can be used to optimize performance. When the PREPARE statement is executed, the specified statement is parsed, analyzed, and rewritten. When an EXECUTE command is subsequently issued, the prepared statement is planned and executed. This division of labor avoids repetitive parse analysis work, while allowing the execution plan to depend on the specific parameter values supplied.

Prepared statements can take parameters: values that are substituted into the statement when it is executed. When creating the prepared statement, refer to parameters by position, using $1, $2, etc. A corresponding list of parameter data types can optionally be specified. When a parameters data type is not specified or is declared as unknown, the type is inferred from the context in which the parameter is first referenced (if possible). When executing the statement, specify the actual values for these parameters in the EXECUTE statement. Refer to EXECUTE(7) for more information about that.

Prepared statements only last for the duration of the current database session. When the session ends, the prepared statement is forgotten, so it must be recreated before being used again. This also means that a single prepared statement cannot be used by multiple simultaneous database clients; however, each client can create their own prepared statement to use. Prepared statements can be manually cleaned up using the DEALLOCATE command.

Prepared statements potentially have the largest performance advantage when a single session is being used to execute a large number of similar statements. The performance difference will be particularly significant if the statements are complex to plan or rewrite, e.g., if the query involves a join of many tables or requires the application of several rules. If the statement is relatively simple to plan and rewrite but relatively expensive to execute, the performance advantage of prepared statements will be less noticeable.

PARAMETERS

name

An arbitrary name given to this particular prepared statement. It must be unique within a single session and is subsequently used to execute or deallocate a previously prepared statement.

data_type

The data type of a parameter to the prepared statement. If the data type of a particular parameter is unspecified or is specified as unknown, it will be inferred from the context in which the parameter is first referenced. To refer to the parameters in the prepared statement itself, use $1, $2, etc.

statement

Any SELECT, INSERT, UPDATE, DELETE, MERGE, or VALUES statement.

NOTES

A prepared statement can be executed with either a generic plan or a custom plan. A generic plan is the same across all executions, while a custom plan is generated for a specific execution using the parameter values given in that call. Use of a generic plan avoids planning overhead, but in some situations a custom plan will be much more efficient to execute because the planner can make use of knowledge of the parameter values. (Of course, if the prepared statement has no parameters, then this is moot and a generic plan is always used.)

By default (that is, when plan_cache_mode is set to auto), the server will automatically choose whether to use a generic or custom plan for a prepared statement that has parameters. The current rule for this is that the first five executions are done with custom plans and the average estimated cost of those plans is calculated. Then a generic plan is created and its estimated cost is compared to the average custom-plan cost. Subsequent executions use the generic plan if its cost is not so much higher than the average custom-plan cost as to make repeated replanning seem preferable.

This heuristic can be overridden, forcing the server to use either generic or custom plans, by setting plan_cache_mode to force_generic_plan or force_custom_plan respectively. This setting is primarily useful if the generic plans cost estimate is badly off for some reason, allowing it to be chosen even though its actual cost is much more than that of a custom plan.

To examine the query plan PostgreSQL is using for a prepared statement, use EXPLAIN, for example

EXPLAIN EXECUTE name(parameter_values);

If a generic plan is in use, it will contain parameter symbols $n, while a custom plan will have the supplied parameter values substituted into it.

For more information on query planning and the statistics collected by PostgreSQL for that purpose, see the ANALYZE(7) documentation.

Although the main point of a prepared statement is to avoid repeated parse analysis and planning of the statement, PostgreSQL will force re-analysis and re-planning of the statement before using it whenever database objects used in the statement have undergone definitional (DDL) changes or their planner statistics have been updated since the previous use of the prepared statement. Also, if the value of search_path changes from one use to the next, the statement will be re-parsed using the new search_path. (This latter behavior is new as of PostgreSQL 9.3.) These rules make use of a prepared statement semantically almost equivalent to re-submitting the same query text over and over, but with a performance benefit if no object definitions are changed, especially if the best plan remains the same across uses. An example of a case where the semantic equivalence is not perfect is that if the statement refers to a table by an unqualified name, and then a new table of the same name is created in a schema appearing earlier in the search_path, no automatic re-parse will occur since no object used in the statement changed. However, if some other change forces a re-parse, the new table will be referenced in subsequent uses.

You can see all prepared statements available in the session by querying the pg_prepared_statements system view.

EXAMPLES

Create a prepared statement for an INSERT statement, and then execute it:

PREPARE fooplan (int, text, bool, numeric) AS INSERT INTO foo VALUES($1, $2, $3, $4); EXECUTE fooplan(1, Hunter Valley, t, 200.00);

Create a prepared statement for a SELECT statement, and then execute it:

PREPARE usrrptplan (int) AS SELECT * FROM users u, logs l WHERE u.usrid=$1 AND u.usrid=l.usrid AND l.date = $2; EXECUTE usrrptplan(1, current_date);

In this example, the data type of the second parameter is not specified, so it is inferred from the context in which $2 is used.

COMPATIBILITY

The SQL standard includes a PREPARE statement, but it is only for use in embedded SQL. This version of the PREPARE statement also uses a somewhat different syntax.

SEE ALSO

DEALLOCATE(7), EXECUTE(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

102 - Linux cli command iso_8859-8

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso_8859-8 and provides detailed information about the command iso_8859-8, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso_8859-8.

NAME 🖥️ iso_8859-8 🖥️

8 - ISO/IEC 8859-8 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-8 encodes the characters used in Modern Hebrew.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-8 characters

The following table displays the characters in ISO/IEC 8859-8 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-8 was also known as ISO-IR-138. ISO/IEC 8859-8 includes neither short vowels nor diacritical marks, and Yiddish is not provided for.

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

103 - Linux cli command EVP_CIPHER-DESssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_CIPHER-DESssl and provides detailed information about the command EVP_CIPHER-DESssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_CIPHER-DESssl.

NAME 🖥️ EVP_CIPHER-DESssl 🖥️

DES - The DES EVP_CIPHER implementations

DESCRIPTION

Support for DES symmetric encryption using the EVP_CIPHER API.

Algorithm Names

The following algorithms are available in the FIPS provider as well as the default provider:

“DES-EDE3-ECB” or “DES-EDE3”

“DES-EDE3-CBC” or “DES3”

The following algorithms are available in the default provider, but not the FIPS provider:

“DES-EDE3-CFB8” and “DES-EDE3-CFB1”

“DES-EDE-ECB” or “DES-EDE”

“DES-EDE-CBC”

“DES-EDE-OFB”

“DES-EDE-CFB”

“DES3-WRAP”

The following algorithms are available in the legacy provider:

“DES-ECB”

“DES-CBC”

“DES-OFB”

“DES-CFB”, “DES-CFB1” and “DES-CFB8”

“DESX-CBC”

Parameters

This implementation supports the parameters described in “PARAMETERS” in EVP_EncryptInit (3).

SEE ALSO

provider-cipher (7), OSSL_PROVIDER-FIPS (7), OSSL_PROVIDER-default (7), OSSL_PROVIDER-legacy (7),

COPYRIGHT

Copyright 2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

104 - Linux cli command EVP_KDF-X963ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KDF-X963ssl and provides detailed information about the command EVP_KDF-X963ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KDF-X963ssl.

NAME 🖥️ EVP_KDF-X963ssl 🖥️

X963 - The X9.63-2001 EVP_KDF implementation

DESCRIPTION

The EVP_KDF-X963 algorithm implements the key derivation function (X963KDF). X963KDF is used by Cryptographic Message Syntax (CMS) for EC KeyAgreement, to derive a key using input such as a shared secret key and shared info.

Identity

“X963KDF” is the name for this implementation; it can be used with the EVP_KDF_fetch() function.

Supported parameters

The supported parameters are:

“properties” (OSSL_KDF_PARAM_PROPERTIES) <UTF8 string>

“digest” (OSSL_KDF_PARAM_DIGEST) <UTF8 string>

These parameters work as described in “PARAMETERS” in EVP_KDF (3).

“key” (OSSL_KDF_PARAM_KEY) <octet string>
The shared secret used for key derivation. This parameter sets the secret.

“info” (OSSL_KDF_PARAM_INFO) <octet string>
This parameter specifies an optional value for shared info.

NOTES

X963KDF is very similar to the SSKDF that uses a digest as the auxiliary function, X963KDF appends the counter to the secret, whereas SSKDF prepends the counter.

A context for X963KDF can be obtained by calling:

EVP_KDF *kdf = EVP_KDF_fetch(NULL, “X963KDF”, NULL); EVP_KDF_CTX *kctx = EVP_KDF_CTX_new(kdf);

The output length of an X963KDF is specified via the keylen parameter to the EVP_KDF_derive (3) function.

EXAMPLES

This example derives 10 bytes, with the secret key “secret” and sharedinfo value “label”:

EVP_KDF *kdf; EVP_KDF_CTX *kctx; unsigned char out[10]; OSSL_PARAM params[4], *p = params; kdf = EVP_KDF_fetch(NULL, “X963KDF”, NULL); kctx = EVP_KDF_CTX_new(kdf); EVP_KDF_free(kdf); *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_DIGEST, SN_sha256, strlen(SN_sha256)); *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_SECRET, “secret”, (size_t)6); *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_INFO, “label”, (size_t)5); *p = OSSL_PARAM_construct_end(); if (EVP_KDF_derive(kctx, out, sizeof(out), params) <= 0) { error(“EVP_KDF_derive”); } EVP_KDF_CTX_free(kctx);

CONFORMING TO

“SEC 1: Elliptic Curve Cryptography”

SEE ALSO

EVP_KDF (3), EVP_KDF_CTX_new (3), EVP_KDF_CTX_free (3), EVP_KDF_CTX_set_params (3), EVP_KDF_CTX_get_kdf_size (3), EVP_KDF_derive (3), “PARAMETERS” in EVP_KDF (3)

HISTORY

This functionality was added in OpenSSL 3.0.

COPYRIGHT

Copyright 2019-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

105 - Linux cli command REVOKE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command REVOKE and provides detailed information about the command REVOKE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the REVOKE.

NAME 🖥️ REVOKE 🖥️

remove access privileges

SYNOPSIS

REVOKE [ GRANT OPTION FOR ]
    { { SELECT | INSERT | UPDATE | DELETE | TRUNCATE | REFERENCES | TRIGGER }
    [, ...] | ALL [ PRIVILEGES ] }
    ON { [ TABLE ] table_name [, ...]
         | ALL TABLES IN SCHEMA schema_name [, ...] }
    FROM role_specification [, ...]
    [ GRANTED BY role_specification ]
    [ CASCADE | RESTRICT ]

REVOKE [ GRANT OPTION FOR ]
    { { SELECT | INSERT | UPDATE | REFERENCES } ( column_name [, ...] )
    [, ...] | ALL [ PRIVILEGES ] ( column_name [, ...] ) }
    ON [ TABLE ] table_name [, ...]
    FROM role_specification [, ...]
    [ GRANTED BY role_specification ]
    [ CASCADE | RESTRICT ]

REVOKE [ GRANT OPTION FOR ]
    { { USAGE | SELECT | UPDATE }
    [, ...] | ALL [ PRIVILEGES ] }
    ON { SEQUENCE sequence_name [, ...]
         | ALL SEQUENCES IN SCHEMA schema_name [, ...] }
    FROM role_specification [, ...]
    [ GRANTED BY role_specification ]
    [ CASCADE | RESTRICT ]

REVOKE [ GRANT OPTION FOR ]
    { { CREATE | CONNECT | TEMPORARY | TEMP } [, ...] | ALL [ PRIVILEGES ] }
    ON DATABASE database_name [, ...]
    FROM role_specification [, ...]
    [ GRANTED BY role_specification ]
    [ CASCADE | RESTRICT ]

REVOKE [ GRANT OPTION FOR ]
    { USAGE | ALL [ PRIVILEGES ] }
    ON DOMAIN domain_name [, ...]
    FROM role_specification [, ...]
    [ GRANTED BY role_specification ]
    [ CASCADE | RESTRICT ]

REVOKE [ GRANT OPTION FOR ]
    { USAGE | ALL [ PRIVILEGES ] }
    ON FOREIGN DATA WRAPPER fdw_name [, ...]
    FROM role_specification [, ...]
    [ GRANTED BY role_specification ]
    [ CASCADE | RESTRICT ]

REVOKE [ GRANT OPTION FOR ]
    { USAGE | ALL [ PRIVILEGES ] }
    ON FOREIGN SERVER server_name [, ...]
    FROM role_specification [, ...]
    [ GRANTED BY role_specification ]
    [ CASCADE | RESTRICT ]

REVOKE [ GRANT OPTION FOR ]
    { EXECUTE | ALL [ PRIVILEGES ] }
    ON { { FUNCTION | PROCEDURE | ROUTINE } function_name [ ( [ [ argmode ] [ arg_name ] arg_type [, ...] ] ) ] [, ...]
         | ALL { FUNCTIONS | PROCEDURES | ROUTINES } IN SCHEMA schema_name [, ...] }
    FROM role_specification [, ...]
    [ GRANTED BY role_specification ]
    [ CASCADE | RESTRICT ]

REVOKE [ GRANT OPTION FOR ]
    { USAGE | ALL [ PRIVILEGES ] }
    ON LANGUAGE lang_name [, ...]
    FROM role_specification [, ...]
    [ GRANTED BY role_specification ]
    [ CASCADE | RESTRICT ]

REVOKE [ GRANT OPTION FOR ]
    { { SELECT | UPDATE } [, ...] | ALL [ PRIVILEGES ] }
    ON LARGE OBJECT loid [, ...]
    FROM role_specification [, ...]
    [ GRANTED BY role_specification ]
    [ CASCADE | RESTRICT ]

REVOKE [ GRANT OPTION FOR ]
    { { SET | ALTER SYSTEM } [, ...] | ALL [ PRIVILEGES ] }
    ON PARAMETER configuration_parameter [, ...]
    FROM role_specification [, ...]
    [ GRANTED BY role_specification ]
    [ CASCADE | RESTRICT ]

REVOKE [ GRANT OPTION FOR ]
    { { CREATE | USAGE } [, ...] | ALL [ PRIVILEGES ] }
    ON SCHEMA schema_name [, ...]
    FROM role_specification [, ...]
    [ GRANTED BY role_specification ]
    [ CASCADE | RESTRICT ]

REVOKE [ GRANT OPTION FOR ]
    { CREATE | ALL [ PRIVILEGES ] }
    ON TABLESPACE tablespace_name [, ...]
    FROM role_specification [, ...]
    [ GRANTED BY role_specification ]
    [ CASCADE | RESTRICT ]

REVOKE [ GRANT OPTION FOR ]
    { USAGE | ALL [ PRIVILEGES ] }
    ON TYPE type_name [, ...]
    FROM role_specification [, ...]
    [ GRANTED BY role_specification ]
    [ CASCADE | RESTRICT ]

REVOKE [ { ADMIN | INHERIT | SET } OPTION FOR ]
    role_name [, ...] FROM role_specification [, ...]
    [ GRANTED BY role_specification ]
    [ CASCADE | RESTRICT ]

where role_specification can be:

    [ GROUP ] role_name
  | PUBLIC
  | CURRENT_ROLE
  | CURRENT_USER
  | SESSION_USER

DESCRIPTION

The REVOKE command revokes previously granted privileges from one or more roles. The key word PUBLIC refers to the implicitly defined group of all roles.

See the description of the GRANT command for the meaning of the privilege types.

Note that any particular role will have the sum of privileges granted directly to it, privileges granted to any role it is presently a member of, and privileges granted to PUBLIC. Thus, for example, revoking SELECT privilege from PUBLIC does not necessarily mean that all roles have lost SELECT privilege on the object: those who have it granted directly or via another role will still have it. Similarly, revoking SELECT from a user might not prevent that user from using SELECT if PUBLIC or another membership role still has SELECT rights.

If GRANT OPTION FOR is specified, only the grant option for the privilege is revoked, not the privilege itself. Otherwise, both the privilege and the grant option are revoked.

If a user holds a privilege with grant option and has granted it to other users then the privileges held by those other users are called dependent privileges. If the privilege or the grant option held by the first user is being revoked and dependent privileges exist, those dependent privileges are also revoked if CASCADE is specified; if it is not, the revoke action will fail. This recursive revocation only affects privileges that were granted through a chain of users that is traceable to the user that is the subject of this REVOKE command. Thus, the affected users might effectively keep the privilege if it was also granted through other users.

When revoking privileges on a table, the corresponding column privileges (if any) are automatically revoked on each column of the table, as well. On the other hand, if a role has been granted privileges on a table, then revoking the same privileges from individual columns will have no effect.

When revoking membership in a role, GRANT OPTION is instead called ADMIN OPTION, but the behavior is similar. Note that, in releases prior to PostgreSQL 16, dependent privileges were not tracked for grants of role membership, and thus CASCADE had no effect for role membership. This is no longer the case. Note also that this form of the command does not allow the noise word GROUP in role_specification.

Just as ADMIN OPTION can be removed from an existing role grant, it is also possible to revoke INHERIT OPTION or SET OPTION. This is equivalent to setting the value of the corresponding option to FALSE.

NOTES

A user can only revoke privileges that were granted directly by that user. If, for example, user A has granted a privilege with grant option to user B, and user B has in turn granted it to user C, then user A cannot revoke the privilege directly from C. Instead, user A could revoke the grant option from user B and use the CASCADE option so that the privilege is in turn revoked from user C. For another example, if both A and B have granted the same privilege to C, A can revoke their own grant but not Bs grant, so C will still effectively have the privilege.

When a non-owner of an object attempts to REVOKE privileges on the object, the command will fail outright if the user has no privileges whatsoever on the object. As long as some privilege is available, the command will proceed, but it will revoke only those privileges for which the user has grant options. The REVOKE ALL PRIVILEGES forms will issue a warning message if no grant options are held, while the other forms will issue a warning if grant options for any of the privileges specifically named in the command are not held. (In principle these statements apply to the object owner as well, but since the owner is always treated as holding all grant options, the cases can never occur.)

If a superuser chooses to issue a GRANT or REVOKE command, the command is performed as though it were issued by the owner of the affected object. (Since roles do not have owners, in the case of a GRANT of role membership, the command is performed as though it were issued by the bootstrap superuser.) Since all privileges ultimately come from the object owner (possibly indirectly via chains of grant options), it is possible for a superuser to revoke all privileges, but this might require use of CASCADE as stated above.

REVOKE can also be done by a role that is not the owner of the affected object, but is a member of the role that owns the object, or is a member of a role that holds privileges WITH GRANT OPTION on the object. In this case the command is performed as though it were issued by the containing role that actually owns the object or holds the privileges WITH GRANT OPTION. For example, if table t1 is owned by role g1, of which role u1 is a member, then u1 can revoke privileges on t1 that are recorded as being granted by g1. This would include grants made by u1 as well as by other members of role g1.

If the role executing REVOKE holds privileges indirectly via more than one role membership path, it is unspecified which containing role will be used to perform the command. In such cases it is best practice to use SET ROLE to become the specific role you want to do the REVOKE as. Failure to do so might lead to revoking privileges other than the ones you intended, or not revoking anything at all.

See Section 5.7 for more information about specific privilege types, as well as how to inspect objects privileges.

EXAMPLES

Revoke insert privilege for the public on table films:

REVOKE INSERT ON films FROM PUBLIC;

Revoke all privileges from user manuel on view kinds:

REVOKE ALL PRIVILEGES ON kinds FROM manuel;

Note that this actually means “revoke all privileges that I granted”.

Revoke membership in role admins from user joe:

REVOKE admins FROM joe;

COMPATIBILITY

The compatibility notes of the GRANT command apply analogously to REVOKE. The keyword RESTRICT or CASCADE is required according to the standard, but PostgreSQL assumes RESTRICT by default.

SEE ALSO

GRANT(7), ALTER DEFAULT PRIVILEGES (ALTER_DEFAULT_PRIVILEGES(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

106 - Linux cli command BEGIN

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command BEGIN and provides detailed information about the command BEGIN, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the BEGIN.

NAME 🖥️ BEGIN 🖥️

start a transaction block

SYNOPSIS

BEGIN [ WORK | TRANSACTION ] [ transaction_mode [, ...] ]

where transaction_mode is one of:

    ISOLATION LEVEL { SERIALIZABLE | REPEATABLE READ | READ COMMITTED | READ UNCOMMITTED }
    READ WRITE | READ ONLY
    [ NOT ] DEFERRABLE

DESCRIPTION

BEGIN initiates a transaction block, that is, all statements after a BEGIN command will be executed in a single transaction until an explicit COMMIT or ROLLBACK is given. By default (without BEGIN), PostgreSQL executes transactions in “autocommit” mode, that is, each statement is executed in its own transaction and a commit is implicitly performed at the end of the statement (if execution was successful, otherwise a rollback is done).

Statements are executed more quickly in a transaction block, because transaction start/commit requires significant CPU and disk activity. Execution of multiple statements inside a transaction is also useful to ensure consistency when making several related changes: other sessions will be unable to see the intermediate states wherein not all the related updates have been done.

If the isolation level, read/write mode, or deferrable mode is specified, the new transaction has those characteristics, as if SET TRANSACTION was executed.

PARAMETERS

WORK
TRANSACTION

Optional key words. They have no effect.

Refer to SET TRANSACTION (SET_TRANSACTION(7)) for information on the meaning of the other parameters to this statement.

NOTES

START TRANSACTION has the same functionality as BEGIN.

Use COMMIT or ROLLBACK to terminate a transaction block.

Issuing BEGIN when already inside a transaction block will provoke a warning message. The state of the transaction is not affected. To nest transactions within a transaction block, use savepoints (see SAVEPOINT(7)).

For reasons of backwards compatibility, the commas between successive transaction_modes can be omitted.

EXAMPLES

To begin a transaction block:

BEGIN;

COMPATIBILITY

BEGIN is a PostgreSQL language extension. It is equivalent to the SQL-standard command START TRANSACTION, whose reference page contains additional compatibility information.

The DEFERRABLE transaction_mode is a PostgreSQL language extension.

Incidentally, the BEGIN key word is used for a different purpose in embedded SQL. You are advised to be careful about the transaction semantics when porting database applications.

SEE ALSO

COMMIT(7), ROLLBACK(7), START TRANSACTION (START_TRANSACTION(7)), SAVEPOINT(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

107 - Linux cli command latin1

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command latin1 and provides detailed information about the command latin1, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the latin1.

NAME 🖥️ latin1 🖥️

1 - ISO/IEC 8859-1 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-1 encodes the characters used in many West European languages.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-1 characters

The following table displays the characters in ISO/IEC 8859-1 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-1 is also known as Latin-1.

SEE ALSO

ascii(7), charsets(7), cp1252(7), iso_8859-15(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

108 - Linux cli command CREATE_EVENT_TRIGGER

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_EVENT_TRIGGER and provides detailed information about the command CREATE_EVENT_TRIGGER, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_EVENT_TRIGGER.

NAME 🖥️ CREATE_EVENT_TRIGGER 🖥️

define a new event trigger

SYNOPSIS

CREATE EVENT TRIGGER name
    ON event
    [ WHEN filter_variable IN (filter_value [, ... ]) [ AND ... ] ]
    EXECUTE { FUNCTION | PROCEDURE } function_name()

DESCRIPTION

CREATE EVENT TRIGGER creates a new event trigger. Whenever the designated event occurs and the WHEN condition associated with the trigger, if any, is satisfied, the trigger function will be executed. For a general introduction to event triggers, see Chapter 40. The user who creates an event trigger becomes its owner.

PARAMETERS

name

The name to give the new trigger. This name must be unique within the database.

event

The name of the event that triggers a call to the given function. See Section 40.1 for more information on event names.

filter_variable

The name of a variable used to filter events. This makes it possible to restrict the firing of the trigger to a subset of the cases in which it is supported. Currently the only supported filter_variable is TAG.

filter_value

A list of values for the associated filter_variable for which the trigger should fire. For TAG, this means a list of command tags (e.g., DROP FUNCTION).

function_name

A user-supplied function that is declared as taking no argument and returning type event_trigger.

In the syntax of CREATE EVENT TRIGGER, the keywords FUNCTION and PROCEDURE are equivalent, but the referenced function must in any case be a function, not a procedure. The use of the keyword PROCEDURE here is historical and deprecated.

NOTES

Only superusers can create event triggers.

Event triggers are disabled in single-user mode (see postgres(1)). If an erroneous event trigger disables the database so much that you cant even drop the trigger, restart in single-user mode and youll be able to do that.

EXAMPLES

Forbid the execution of any DDL command:

CREATE OR REPLACE FUNCTION abort_any_command() RETURNS event_trigger LANGUAGE plpgsql AS $$ BEGIN RAISE EXCEPTION command % is disabled, tg_tag; END; $$;

CREATE EVENT TRIGGER abort_ddl ON ddl_command_start
   EXECUTE FUNCTION abort_any_command();

COMPATIBILITY

There is no CREATE EVENT TRIGGER statement in the SQL standard.

SEE ALSO

ALTER EVENT TRIGGER (ALTER_EVENT_TRIGGER(7)), DROP EVENT TRIGGER (DROP_EVENT_TRIGGER(7)), CREATE FUNCTION (CREATE_FUNCTION(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

109 - Linux cli command openssl-core.hssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command openssl-core.hssl and provides detailed information about the command openssl-core.hssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the openssl-core.hssl.

NAME 🖥️ openssl-core.hssl 🖥️

OpenSSL Core types

SYNOPSIS

#include <openssl/core.h>

DESCRIPTION

The <openssl/core.h> header defines a number of public types that are used to communicate between the OpenSSL libraries and implementation providers. These types are designed to minimise the need for intimate knowledge of internal structures between the OpenSSL libraries and the providers.

The types are:

OSSL_DISPATCH (3)

OSSL_ITEM (3)

OSSL_ALGORITHM (3)

OSSL_PARAM (3)

OSSL_CALLBACK (3)

OSSL_PASSPHRASE_CALLBACK (3)

SEE ALSO

openssl-core_dispatch.h (7)

HISTORY

The types described here were added in OpenSSL 3.0.

COPYRIGHT

Copyright 2019-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

110 - Linux cli command UPower

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command UPower and provides detailed information about the command UPower, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the UPower.

NAME 🖥️ UPower 🖥️

System-wide Power Management

DESCRIPTION

UPower provides an interface to enumerate power sources on the system and control system-wide power management. Any application can access the org.freedesktop.UPower service on the system message bus.

AUTHOR

Written by David Zeuthen <[email protected]>, Richard Hughes <[email protected]> and with a lot of help from many others.

BUGS

Please send bug reports to either the distribution or the DeviceKit mailing list, see http://lists.freedesktop.org/mailman/listinfo/devkit-devel on how to subscribe.

SEE ALSO

PolicyKit(8), upowerd(8), upower(1)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

111 - Linux cli command gitcore-tutorial

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command gitcore-tutorial and provides detailed information about the command gitcore-tutorial, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the gitcore-tutorial.

NAME 🖥️ gitcore-tutorial 🖥️

tutorial - A Git core tutorial for developers

SYNOPSIS

git *

DESCRIPTION

This tutorial explains how to use the “core” Git commands to set up and work with a Git repository.

If you just need to use Git as a revision control system you may prefer to start with “A Tutorial Introduction to Git” (gittutorial(7)) or the Git User Manual[1].

However, an understanding of these low-level tools can be helpful if you want to understand Git’s internals.

The core Git is often called “plumbing”, with the prettier user interfaces on top of it called “porcelain”. You may not want to use the plumbing directly very often, but it can be good to know what the plumbing does when the porcelain isn’t flushing.

Back when this document was originally written, many porcelain commands were shell scripts. For simplicity, it still uses them as examples to illustrate how plumbing is fit together to form the porcelain commands. The source tree includes some of these scripts in contrib/examples/ for reference. Although these are not implemented as shell scripts anymore, the description of what the plumbing layer commands do is still valid.

Note

Deeper technical details are often marked as Notes, which you can skip on your first reading.

CREATING A GIT REPOSITORY

Creating a new Git repository couldn’t be easier: all Git repositories start out empty, and the only thing you need to do is find yourself a subdirectory that you want to use as a working tree - either an empty one for a totally new project, or an existing working tree that you want to import into Git.

For our first example, we’re going to start a totally new repository from scratch, with no pre-existing files, and we’ll call it git-tutorial. To start up, create a subdirectory for it, change into that subdirectory, and initialize the Git infrastructure with git init:

$ mkdir git-tutorial $ cd git-tutorial $ git init

to which Git will reply

Initialized empty Git repository in .git/

which is just Git’s way of saying that you haven’t been doing anything strange, and that it will have created a local .git directory setup for your new project. You will now have a .git directory, and you can inspect that with ls. For your new empty project, it should show you three entries, among other things:

·

a file called HEAD, that has ref: refs/heads/master in it. This is similar to a symbolic link and points at refs/heads/master relative to the HEAD file.

Don’t worry about the fact that the file that the HEAD link points to doesn’t even exist yet — you haven’t created the commit that will start your HEAD development branch yet.

·

a subdirectory called objects, which will contain all the objects of your project. You should never have any real reason to look at the objects directly, but you might want to know that these objects are what contains all the real data in your repository.

·

a subdirectory called refs, which contains references to objects.

In particular, the refs subdirectory will contain two other subdirectories, named heads and tags respectively. They do exactly what their names imply: they contain references to any number of different heads of development (aka branches), and to any tags that you have created to name specific versions in your repository.

One note: the special master head is the default branch, which is why the .git/HEAD file was created points to it even if it doesn’t yet exist. Basically, the HEAD link is supposed to always point to the branch you are working on right now, and you always start out expecting to work on the master branch.

However, this is only a convention, and you can name your branches anything you want, and don’t have to ever even have a master branch. A number of the Git tools will assume that .git/HEAD is valid, though.

Note

An object is identified by its 160-bit SHA-1 hash, aka object name, and a reference to an object is always the 40-byte hex representation of that SHA-1 name. The files in the refs subdirectory are expected to contain these hex references (usually with a final ** ** at the end), and you should thus expect to see a number of 41-byte files containing these references in these refs subdirectories when you actually start populating your tree.

Note

An advanced user may want to take a look at gitrepository-layout(5) after finishing this tutorial.

You have now created your first Git repository. Of course, since it’s empty, that’s not very useful, so let’s start populating it with data.

POPULATING A GIT REPOSITORY

We’ll keep this simple and stupid, so we’ll start off with populating a few trivial files just to get a feel for it.

Start off with just creating any random files that you want to maintain in your Git repository. We’ll start off with a few bad examples, just to get a feel for how this works:

$ echo “Hello World” >hello $ echo “Silly example” >example

you have now created two files in your working tree (aka working directory), but to actually check in your hard work, you will have to go through two steps:

·

fill in the index file (aka cache) with the information about your working tree state.

·

commit that index file as an object.

The first step is trivial: when you want to tell Git about any changes to your working tree, you use the git update-index program. That program normally just takes a list of filenames you want to update, but to avoid trivial mistakes, it refuses to add new entries to the index (or remove existing ones) unless you explicitly tell it that you’re adding a new entry with the –add flag (or removing an entry with the –remove) flag.

So to populate the index with the two files you just created, you can do

$ git update-index –add hello example

and you have now told Git to track those two files.

In fact, as you did that, if you now look into your object directory, you’ll notice that Git will have added two new objects to the object database. If you did exactly the steps above, you should now be able to do

$ ls .git/objects/??/*

and see two files:

.git/objects/55/7db03de997c86a4a028e1ebd3a1ceb225be238 .git/objects/f2/4c74a2e500f5ee1332c86b94199f52b1d1d962

which correspond with the objects with names of 557db… and f24c7… respectively.

If you want to, you can use git cat-file to look at those objects, but you’ll have to use the object name, not the filename of the object:

$ git cat-file -t 557db03de997c86a4a028e1ebd3a1ceb225be238

where the -t tells git cat-file to tell you what the “type” of the object is. Git will tell you that you have a “blob” object (i.e., just a regular file), and you can see the contents with

$ git cat-file blob 557db03

which will print out “Hello World”. The object 557db03 is nothing more than the contents of your file hello.

Note

Don’t confuse that object with the file hello itself. The object is literally just those specific contents of the file, and however much you later change the contents in file hello, the object we just looked at will never change. Objects are immutable.

Note

The second example demonstrates that you can abbreviate the object name to only the first several hexadecimal digits in most places.

Anyway, as we mentioned previously, you normally never actually take a look at the objects themselves, and typing long 40-character hex names is not something you’d normally want to do. The above digression was just to show that git update-index did something magical, and actually saved away the contents of your files into the Git object database.

Updating the index did something else too: it created a .git/index file. This is the index that describes your current working tree, and something you should be very aware of. Again, you normally never worry about the index file itself, but you should be aware of the fact that you have not actually really “checked in” your files into Git so far, you’ve only told Git about them.

However, since Git knows about them, you can now start using some of the most basic Git commands to manipulate the files or look at their status.

In particular, let’s not even check in the two files into Git yet, we’ll start off by adding another line to hello first:

$ echo “Its a new day for git” »hello

and you can now, since you told Git about the previous state of hello, ask Git what has changed in the tree compared to your old index, using the git diff-files command:

$ git diff-files

Oops. That wasn’t very readable. It just spit out its own internal version of a diff, but that internal version really just tells you that it has noticed that “hello” has been modified, and that the old object contents it had have been replaced with something else.

To make it readable, we can tell git diff-files to output the differences as a patch, using the -p flag:

$ git diff-files -p diff –git a/hello b/hello index 557db03..263414f 100644 — a/hello +++ b/hello @@ -1 +1,2 @@ Hello World +Its a new day for git

i.e. the diff of the change we caused by adding another line to hello.

In other words, git diff-files always shows us the difference between what is recorded in the index, and what is currently in the working tree. That’s very useful.

A common shorthand for git diff-files -p is to just write git diff, which will do the same thing.

$ git diff diff –git a/hello b/hello index 557db03..263414f 100644 — a/hello +++ b/hello @@ -1 +1,2 @@ Hello World +Its a new day for git

COMMITTING GIT STATE

Now, we want to go to the next stage in Git, which is to take the files that Git knows about in the index, and commit them as a real tree. We do that in two phases: creating a tree object, and committing that tree object as a commit object together with an explanation of what the tree was all about, along with information of how we came to that state.

Creating a tree object is trivial, and is done with git write-tree. There are no options or other input: git write-tree will take the current index state, and write an object that describes that whole index. In other words, we’re now tying together all the different filenames with their contents (and their permissions), and we’re creating the equivalent of a Git “directory” object:

$ git write-tree

and this will just output the name of the resulting tree, in this case (if you have done exactly as I’ve described) it should be

8988da15d077d4829fc51d8544c097def6644dbb

which is another incomprehensible object name. Again, if you want to, you can use git cat-file -t 8988d… to see that this time the object is not a “blob” object, but a “tree” object (you can also use git cat-file to actually output the raw object contents, but you’ll see mainly a binary mess, so that’s less interesting).

However — normally you’d never use git write-tree on its own, because normally you always commit a tree into a commit object using the git commit-tree command. In fact, it’s easier to not actually use git write-tree on its own at all, but to just pass its result in as an argument to git commit-tree.

git commit-tree normally takes several arguments — it wants to know what the parent of a commit was, but since this is the first commit ever in this new repository, and it has no parents, we only need to pass in the object name of the tree. However, git commit-tree also wants to get a commit message on its standard input, and it will write out the resulting object name for the commit to its standard output.

And this is where we create the .git/refs/heads/master file which is pointed at by HEAD. This file is supposed to contain the reference to the top-of-tree of the master branch, and since that’s exactly what git commit-tree spits out, we can do this all with a sequence of simple shell commands:

$ tree=$(git write-tree) $ commit=$(echo Initial commit | git commit-tree $tree) $ git update-ref HEAD $commit

In this case this creates a totally new commit that is not related to anything else. Normally you do this only once for a project ever, and all later commits will be parented on top of an earlier commit.

Again, normally you’d never actually do this by hand. There is a helpful script called git commit that will do all of this for you. So you could have just written git commit instead, and it would have done the above magic scripting for you.

MAKING A CHANGE

Remember how we did the git update-index on file hello and then we changed hello afterward, and could compare the new state of hello with the state we saved in the index file?

Further, remember how I said that git write-tree writes the contents of the index file to the tree, and thus what we just committed was in fact the original contents of the file hello, not the new ones. We did that on purpose, to show the difference between the index state, and the state in the working tree, and how they don’t have to match, even when we commit things.

As before, if we do git diff-files -p in our git-tutorial project, we’ll still see the same difference we saw last time: the index file hasn’t changed by the act of committing anything. However, now that we have committed something, we can also learn to use a new command: git diff-index.

Unlike git diff-files, which showed the difference between the index file and the working tree, git diff-index shows the differences between a committed tree and either the index file or the working tree. In other words, git diff-index wants a tree to be diffed against, and before we did the commit, we couldn’t do that, because we didn’t have anything to diff against.

But now we can do

$ git diff-index -p HEAD

(where -p has the same meaning as it did in git diff-files), and it will show us the same difference, but for a totally different reason. Now we’re comparing the working tree not against the index file, but against the tree we just wrote. It just so happens that those two are obviously the same, so we get the same result.

Again, because this is a common operation, you can also just shorthand it with

$ git diff HEAD

which ends up doing the above for you.

In other words, git diff-index normally compares a tree against the working tree, but when given the –cached flag, it is told to instead compare against just the index cache contents, and ignore the current working tree state entirely. Since we just wrote the index file to HEAD, doing git diff-index –cached -p HEAD should thus return an empty set of differences, and that’s exactly what it does.

Note

git diff-index really always uses the index for its comparisons, and saying that it compares a tree against the working tree is thus not strictly accurate. In particular, the list of files to compare (the “meta-data”) always comes from the index file, regardless of whether the –cached flag is used or not. The –cached flag really only determines whether the file contents to be compared come from the working tree or not.

This is not hard to understand, as soon as you realize that Git simply never knows (or cares) about files that it is not told about explicitly. Git will never go looking for files to compare, it expects you to tell it what the files are, and that’s what the index is there for.

However, our next step is to commit the change we did, and again, to understand what’s going on, keep in mind the difference between “working tree contents”, “index file” and “committed tree”. We have changes in the working tree that we want to commit, and we always have to work through the index file, so the first thing we need to do is to update the index cache:

$ git update-index hello

(note how we didn’t need the –add flag this time, since Git knew about the file already).

Note what happens to the different git diff-* versions here. After we’ve updated hello in the index, git diff-files -p now shows no differences, but git diff-index -p HEAD still does show that the current state is different from the state we committed. In fact, now git diff-index shows the same difference whether we use the –cached flag or not, since now the index is coherent with the working tree.

Now, since we’ve updated hello in the index, we can commit the new version. We could do it by writing the tree by hand again, and committing the tree (this time we’d have to use the -p HEAD flag to tell commit that the HEAD was the parent of the new commit, and that this wasn’t an initial commit any more), but you’ve done that once already, so let’s just use the helpful script this time:

$ git commit

which starts an editor for you to write the commit message and tells you a bit about what you have done.

Write whatever message you want, and all the lines that start with # will be pruned out, and the rest will be used as the commit message for the change. If you decide you don’t want to commit anything after all at this point (you can continue to edit things and update the index), you can just leave an empty message. Otherwise git commit will commit the change for you.

You’ve now made your first real Git commit. And if you’re interested in looking at what git commit really does, feel free to investigate: it’s a few very simple shell scripts to generate the helpful (?) commit message headers, and a few one-liners that actually do the commit itself (git commit).

INSPECTING CHANGES

While creating changes is useful, it’s even more useful if you can tell later what changed. The most useful command for this is another of the diff family, namely git diff-tree.

git diff-tree can be given two arbitrary trees, and it will tell you the differences between them. Perhaps even more commonly, though, you can give it just a single commit object, and it will figure out the parent of that commit itself, and show the difference directly. Thus, to get the same diff that we’ve already seen several times, we can now do

$ git diff-tree -p HEAD

(again, -p means to show the difference as a human-readable patch), and it will show what the last commit (in HEAD) actually changed.

Note

Here is an ASCII art by Jon Loeliger that illustrates how various diff-* commands compare things.

        diff-tree
             +----+
             |    |
             |    |
             V    V
          +-----------+
          | Object DB |
          |  Backing  |
          |   Store   |
          +-----------+
            ^    ^
            |    |
            |    |  diff-index --cached
            |    |
diff-index  |    V
            |  +-----------+
            |  |   Index   |
            |  |  "cache"  |
            |  +-----------+
            |    ^
            |    |
            |    |  diff-files
            |    |
            V    V
          +-----------+
          |  Working  |
          | Directory |
          +-----------+

More interestingly, you can also give git diff-tree the –pretty flag, which tells it to also show the commit message and author and date of the commit, and you can tell it to show a whole series of diffs. Alternatively, you can tell it to be “silent”, and not show the diffs at all, but just show the actual commit message.

In fact, together with the git rev-list program (which generates a list of revisions), git diff-tree ends up being a veritable fount of changes. You can emulate git log, git log -p, etc. with a trivial script that pipes the output of git rev-list to git diff-tree –stdin, which was exactly how early versions of git log were implemented.

TAGGING A VERSION

In Git, there are two kinds of tags, a “light” one, and an “annotated tag”.

A “light” tag is technically nothing more than a branch, except we put it in the .git/refs/tags/ subdirectory instead of calling it a head. So the simplest form of tag involves nothing more than

$ git tag my-first-tag

which just writes the current HEAD into the .git/refs/tags/my-first-tag file, after which point you can then use this symbolic name for that particular state. You can, for example, do

$ git diff my-first-tag

to diff your current state against that tag which at this point will obviously be an empty diff, but if you continue to develop and commit stuff, you can use your tag as an “anchor-point” to see what has changed since you tagged it.

An “annotated tag” is actually a real Git object, and contains not only a pointer to the state you want to tag, but also a small tag name and message, along with optionally a PGP signature that says that yes, you really did that tag. You create these annotated tags with either the -a or -s flag to git tag:

$ git tag -s

which will sign the current HEAD (but you can also give it another argument that specifies the thing to tag, e.g., you could have tagged the current mybranch point by using git tag <tagname> mybranch).

You normally only do signed tags for major releases or things like that, while the light-weight tags are useful for any marking you want to do — any time you decide that you want to remember a certain point, just create a private tag for it, and you have a nice symbolic name for the state at that point.

COPYING REPOSITORIES

Git repositories are normally totally self-sufficient and relocatable. Unlike CVS, for example, there is no separate notion of “repository” and “working tree”. A Git repository normally is the working tree, with the local Git information hidden in the .git subdirectory. There is nothing else. What you see is what you got.

Note

You can tell Git to split the Git internal information from the directory that it tracks, but we’ll ignore that for now: it’s not how normal projects work, and it’s really only meant for special uses. So the mental model of “the Git information is always tied directly to the working tree that it describes” may not be technically 100% accurate, but it’s a good model for all normal use.

This has two implications:

·

if you grow bored with the tutorial repository you created (or you’ve made a mistake and want to start all over), you can just do simple

$ rm -rf git-tutorial

and it will be gone. There’s no external repository, and there’s no history outside the project you created.

·

if you want to move or duplicate a Git repository, you can do so. There is git clone command, but if all you want to do is just to create a copy of your repository (with all the full history that went along with it), you can do so with a regular cp -a git-tutorial new-git-tutorial.

Note that when you’ve moved or copied a Git repository, your Git index file (which caches various information, notably some of the “stat” information for the files involved) will likely need to be refreshed. So after you do a cp -a to create a new copy, you’ll want to do

$ git update-index –refresh

in the new repository to make sure that the index file is up to date.

Note that the second point is true even across machines. You can duplicate a remote Git repository with any regular copy mechanism, be it scp, rsync or wget.

When copying a remote repository, you’ll want to at a minimum update the index cache when you do this, and especially with other peoples repositories you often want to make sure that the index cache is in some known state (you don’t know what they’ve done and not yet checked in), so usually you’ll precede the git update-index with a

$ git read-tree –reset HEAD $ git update-index –refresh

which will force a total index re-build from the tree pointed to by HEAD. It resets the index contents to HEAD, and then the git update-index makes sure to match up all index entries with the checked-out files. If the original repository had uncommitted changes in its working tree, git update-index –refresh notices them and tells you they need to be updated.

The above can also be written as simply

$ git reset

and in fact a lot of the common Git command combinations can be scripted with the git xyz interfaces. You can learn things by just looking at what the various git scripts do. For example, git reset used to be the above two lines implemented in git reset, but some things like git status and git commit are slightly more complex scripts around the basic Git commands.

Many (most?) public remote repositories will not contain any of the checked out files or even an index file, and will only contain the actual core Git files. Such a repository usually doesn’t even have the .git subdirectory, but has all the Git files directly in the repository.

To create your own local live copy of such a “raw” Git repository, you’d first create your own subdirectory for the project, and then copy the raw repository contents into the .git directory. For example, to create your own copy of the Git repository, you’d do the following

$ mkdir my-git $ cd my-git $ rsync -rL rsync://rsync.kernel.org/pub/scm/git/git.git/ .git

followed by

$ git read-tree HEAD

to populate the index. However, now you have populated the index, and you have all the Git internal files, but you will notice that you don’t actually have any of the working tree files to work on. To get those, you’d check them out with

$ git checkout-index -u -a

where the -u flag means that you want the checkout to keep the index up to date (so that you don’t have to refresh it afterward), and the -a flag means “check out all files” (if you have a stale copy or an older version of a checked out tree you may also need to add the -f flag first, to tell git checkout-index to force overwriting of any old files).

Again, this can all be simplified with

$ git clone git://git.kernel.org/pub/scm/git/git.git/ my-git $ cd my-git $ git checkout

which will end up doing all of the above for you.

You have now successfully copied somebody else’s (mine) remote repository, and checked it out.

CREATING A NEW BRANCH

Branches in Git are really nothing more than pointers into the Git object database from within the .git/refs/ subdirectory, and as we already discussed, the HEAD branch is nothing but a symlink to one of these object pointers.

You can at any time create a new branch by just picking an arbitrary point in the project history, and just writing the SHA-1 name of that object into a file under .git/refs/heads/. You can use any filename you want (and indeed, subdirectories), but the convention is that the “normal” branch is called master. That’s just a convention, though, and nothing enforces it.

To show that as an example, let’s go back to the git-tutorial repository we used earlier, and create a branch in it. You do that by simply just saying that you want to check out a new branch:

$ git switch -c mybranch

will create a new branch based at the current HEAD position, and switch to it.

Note

If you make the decision to start your new branch at some other point in the history than the current HEAD, you can do so by just telling git switch what the base of the checkout would be. In other words, if you have an earlier tag or branch, you’d just do

$ git switch -c mybranch earlier-commit

and it would create the new branch mybranch at the earlier commit, and check out the state at that time.

You can always just jump back to your original master branch by doing

$ git switch master

(or any other branch-name, for that matter) and if you forget which branch you happen to be on, a simple

$ cat .git/HEAD

will tell you where it’s pointing. To get the list of branches you have, you can say

$ git branch

which used to be nothing more than a simple script around ls .git/refs/heads. There will be an asterisk in front of the branch you are currently on.

Sometimes you may wish to create a new branch without actually checking it out and switching to it. If so, just use the command

$ git branch [startingpoint]

which will simply create the branch, but will not do anything further. You can then later — once you decide that you want to actually develop on that branch — switch to that branch with a regular git switch with the branchname as the argument.

MERGING TWO BRANCHES

One of the ideas of having a branch is that you do some (possibly experimental) work in it, and eventually merge it back to the main branch. So assuming you created the above mybranch that started out being the same as the original master branch, let’s make sure we’re in that branch, and do some work there.

$ git switch mybranch $ echo “Work, work, work” »hello $ git commit -m “Some work.” -i hello

Here, we just added another line to hello, and we used a shorthand for doing both git update-index hello and git commit by just giving the filename directly to git commit, with an -i flag (it tells Git to include that file in addition to what you have done to the index file so far when making the commit). The -m flag is to give the commit log message from the command line.

Now, to make it a bit more interesting, let’s assume that somebody else does some work in the original branch, and simulate that by going back to the master branch, and editing the same file differently there:

$ git switch master

Here, take a moment to look at the contents of hello, and notice how they don’t contain the work we just did in mybranch — because that work hasn’t happened in the master branch at all. Then do

$ echo “Play, play, play” »hello $ echo “Lots of fun” »example $ git commit -m “Some fun.” -i hello example

since the master branch is obviously in a much better mood.

Now, you’ve got two branches, and you decide that you want to merge the work done. Before we do that, let’s introduce a cool graphical tool that helps you view what’s going on:

$ gitk –all

will show you graphically both of your branches (that’s what the –all means: normally it will just show you your current HEAD) and their histories. You can also see exactly how they came to be from a common source.

Anyway, let’s exit gitk (^Q or the File menu), and decide that we want to merge the work we did on the mybranch branch into the master branch (which is currently our HEAD too). To do that, there’s a nice script called git merge, which wants to know which branches you want to resolve and what the merge is all about:

$ git merge -m “Merge work in mybranch” mybranch

where the first argument is going to be used as the commit message if the merge can be resolved automatically.

Now, in this case we’ve intentionally created a situation where the merge will need to be fixed up by hand, though, so Git will do as much of it as it can automatically (which in this case is just merge the example file, which had no differences in the mybranch branch), and say:

    Auto-merging hello
        CONFLICT (content): Merge conflict in hello
        Automatic merge failed; fix conflicts and then commit the result.

It tells you that it did an “Automatic merge”, which failed due to conflicts in hello.

Not to worry. It left the (trivial) conflict in hello in the same form you should already be well used to if you’ve ever used CVS, so let’s just open hello in our editor (whatever that may be), and fix it up somehow. I’d suggest just making it so that hello contains all four lines:

Hello World Its a new day for git Play, play, play Work, work, work

and once you’re happy with your manual merge, just do a

$ git commit -i hello

which will very loudly warn you that you’re now committing a merge (which is correct, so never mind), and you can write a small merge message about your adventures in git merge-land.

After you’re done, start up gitk –all to see graphically what the history looks like. Notice that mybranch still exists, and you can switch to it, and continue to work with it if you want to. The mybranch branch will not contain the merge, but next time you merge it from the master branch, Git will know how you merged it, so you’ll not have to do that merge again.

Another useful tool, especially if you do not always work in X-Window environment, is git show-branch.

$ git show-branch –topo-order –more=1 master mybranch * [master] Merge work in mybranch ! [mybranch] Some work. – - [master] Merge work in mybranch *+ [mybranch] Some work. * [master^] Some fun.

The first two lines indicate that it is showing the two branches with the titles of their top-of-the-tree commits, you are currently on master branch (notice the asterisk * character), and the first column for the later output lines is used to show commits contained in the master branch, and the second column for the mybranch branch. Three commits are shown along with their titles. All of them have non blank characters in the first column (* shows an ordinary commit on the current branch, - is a merge commit), which means they are now part of the master branch. Only the “Some work” commit has the plus + character in the second column, because mybranch has not been merged to incorporate these commits from the master branch. The string inside brackets before the commit log message is a short name you can use to name the commit. In the above example, master and mybranch are branch heads. master^ is the first parent of master branch head. Please see gitrevisions(7) if you want to see more complex cases.

Note

Without the –more=1 option, git show-branch would not output the [master^] commit, as [mybranch] commit is a common ancestor of both master and mybranch tips. Please see git-show-branch(1) for details.

Note

If there were more commits on the master branch after the merge, the merge commit itself would not be shown by git show-branch by default. You would need to provide –sparse option to make the merge commit visible in this case.

Now, let’s pretend you are the one who did all the work in mybranch, and the fruit of your hard work has finally been merged to the master branch. Let’s go back to mybranch, and run git merge to get the “upstream changes” back to your branch.

$ git switch mybranch $ git merge -m “Merge upstream changes.” master

This outputs something like this (the actual commit object names would be different)

Updating from ae3a2da… to a80b4aa…. Fast-forward (no commit created; -m option ignored) example | 1 + hello | 1 + 2 files changed, 2 insertions(+)

Because your branch did not contain anything more than what had already been merged into the master branch, the merge operation did not actually do a merge. Instead, it just updated the top of the tree of your branch to that of the master branch. This is often called fast-forward merge.

You can run gitk –all again to see how the commit ancestry looks like, or run show-branch, which tells you this.

$ git show-branch master mybranch ! [master] Merge work in mybranch * [mybranch] Merge work in mybranch – – [master] Merge work in mybranch

MERGING EXTERNAL WORK

It’s usually much more common that you merge with somebody else than merging with your own branches, so it’s worth pointing out that Git makes that very easy too, and in fact, it’s not that different from doing a git merge. In fact, a remote merge ends up being nothing more than “fetch the work from a remote repository into a temporary tag” followed by a git merge.

Fetching from a remote repository is done by, unsurprisingly, git fetch:

$ git fetch

One of the following transports can be used to name the repository to download from:

SSH

remote.machine:/path/to/repo.git/ or

ssh://remote.machine/path/to/repo.git/

This transport can be used for both uploading and downloading, and requires you to have a log-in privilege over ssh to the remote machine. It finds out the set of objects the other side lacks by exchanging the head commits both ends have and transfers (close to) minimum set of objects. It is by far the most efficient way to exchange Git objects between repositories.

Local directory

/path/to/repo.git/

This transport is the same as SSH transport but uses sh to run both ends on the local machine instead of running other end on the remote machine via ssh.

Git Native

git://remote.machine/path/to/repo.git/

This transport was designed for anonymous downloading. Like SSH transport, it finds out the set of objects the downstream side lacks and transfers (close to) minimum set of objects.

HTTP(S)

http://remote.machine/path/to/repo.git/

Downloader from http and https URL first obtains the topmost commit object name from the remote site by looking at the specified refname under repo.git/refs/ directory, and then tries to obtain the commit object by downloading from repo.git/objects/xx/xxx… using the object name of that commit object. Then it reads the commit object to find out its parent commits and the associate tree object; it repeats this process until it gets all the necessary objects. Because of this behavior, they are sometimes also called commit walkers.

The commit walkers are sometimes also called dumb transports, because they do not require any Git aware smart server like Git Native transport does. Any stock HTTP server that does not even support directory index would suffice. But you must prepare your repository with git update-server-info to help dumb transport downloaders.

Once you fetch from the remote repository, you merge that with your current branch.

However — it’s such a common thing to fetch and then immediately merge, that it’s called git pull, and you can simply do

$ git pull

and optionally give a branch-name for the remote end as a second argument.

Note

You could do without using any branches at all, by keeping as many local repositories as you would like to have branches, and merging between them with git pull, just like you merge between branches. The advantage of this approach is that it lets you keep a set of files for each branch checked out and you may find it easier to switch back and forth if you juggle multiple lines of development simultaneously. Of course, you will pay the price of more disk usage to hold multiple working trees, but disk space is cheap these days.

It is likely that you will be pulling from the same remote repository from time to time. As a short hand, you can store the remote repository URL in the local repository’s config file like this:

$ git config remote.linus.url http://www.kernel.org/pub/scm/git/git.git/

and use the “linus” keyword with git pull instead of the full URL.

Examples.

1.

git pull linus

2.

git pull linus tag v0.99.1

the above are equivalent to:

1.

git pull http://www.kernel.org/pub/scm/git/git.git/ HEAD

2.

git pull http://www.kernel.org/pub/scm/git/git.git/ tag v0.99.1

HOW DOES THE MERGE WORK?

We said this tutorial shows what plumbing does to help you cope with the porcelain that isn’t flushing, but we so far did not talk about how the merge really works. If you are following this tutorial the first time, I’d suggest to skip to “Publishing your work” section and come back here later.

OK, still with me? To give us an example to look at, let’s go back to the earlier repository with “hello” and “example” file, and bring ourselves back to the pre-merge state:

$ git show-branch –more=2 master mybranch ! [master] Merge work in mybranch * [mybranch] Merge work in mybranch – – [master] Merge work in mybranch +* [master^2] Some work. +* [master^] Some fun.

Remember, before running git merge, our master head was at “Some fun.” commit, while our mybranch head was at “Some work.” commit.

$ git switch -C mybranch master^2 $ git switch master $ git reset –hard master^

After rewinding, the commit structure should look like this:

$ git show-branch * [master] Some fun. ! [mybranch] Some work. – * [master] Some fun. + [mybranch] Some work. *+ [master^] Initial commit

Now we are ready to experiment with the merge by hand.

git merge command, when merging two branches, uses 3-way merge algorithm. First, it finds the common ancestor between them. The command it uses is git merge-base:

$ mb=$(git merge-base HEAD mybranch)

The command writes the commit object name of the common ancestor to the standard output, so we captured its output to a variable, because we will be using it in the next step. By the way, the common ancestor commit is the “Initial commit” commit in this case. You can tell it by:

$ git name-rev –name-only –tags $mb my-first-tag

After finding out a common ancestor commit, the second step is this:

$ git read-tree -m -u $mb HEAD mybranch

This is the same git read-tree command we have already seen, but it takes three trees, unlike previous examples. This reads the contents of each tree into different stage in the index file (the first tree goes to stage 1, the second to stage 2, etc.). After reading three trees into three stages, the paths that are the same in all three stages are collapsed into stage 0. Also paths that are the same in two of three stages are collapsed into stage 0, taking the SHA-1 from either stage 2 or stage 3, whichever is different from stage 1 (i.e. only one side changed from the common ancestor).

After collapsing operation, paths that are different in three trees are left in non-zero stages. At this point, you can inspect the index file with this command:

$ git ls-files –stage 100644 7f8b141b65fdcee47321e399a2598a235a032422 0 example 100644 557db03de997c86a4a028e1ebd3a1ceb225be238 1 hello 100644 ba42a2a96e3027f3333e13ede4ccf4498c3ae942 2 hello 100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello

In our example of only two files, we did not have unchanged files so only example resulted in collapsing. But in real-life large projects, when only a small number of files change in one commit, this collapsing tends to trivially merge most of the paths fairly quickly, leaving only a handful of real changes in non-zero stages.

To look at only non-zero stages, use –unmerged flag:

$ git ls-files –unmerged 100644 557db03de997c86a4a028e1ebd3a1ceb225be238 1 hello 100644 ba42a2a96e3027f3333e13ede4ccf4498c3ae942 2 hello 100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello

The next step of merging is to merge these three versions of the file, using 3-way merge. This is done by giving git merge-one-file command as one of the arguments to git merge-index command:

$ git merge-index git-merge-one-file hello Auto-merging hello ERROR: Merge conflict in hello fatal: merge program failed

git merge-one-file script is called with parameters to describe those three versions, and is responsible to leave the merge results in the working tree. It is a fairly straightforward shell script, and eventually calls merge program from RCS suite to perform a file-level 3-way merge. In this case, merge detects conflicts, and the merge result with conflict marks is left in the working tree.. This can be seen if you run ls-files –stage again at this point:

$ git ls-files –stage 100644 7f8b141b65fdcee47321e399a2598a235a032422 0 example 100644 557db03de997c86a4a028e1ebd3a1ceb225be238 1 hello 100644 ba42a2a96e3027f3333e13ede4ccf4498c3ae942 2 hello 100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello

This is the state of the index file and the working file after git merge returns control back to you, leaving the conflicting merge for you to resolve. Notice that the path hello is still unmerged, and what you see with git diff at this point is differences since stage 2 (i.e. your version).

PUBLISHING YOUR WORK

So, we can use somebody else’s work from a remote repository, but how can you prepare a repository to let other people pull from it?

You do your real work in your working tree that has your primary repository hanging under it as its .git subdirectory. You could make that repository accessible remotely and ask people to pull from it, but in practice that is not the way things are usually done. A recommended way is to have a public repository, make it reachable by other people, and when the changes you made in your primary working tree are in good shape, update the public repository from it. This is often called pushing.

Note

This public repository could further be mirrored, and that is how Git repositories at kernel.org are managed.

Publishing the changes from your local (private) repository to your remote (public) repository requires a write privilege on the remote machine. You need to have an SSH account there to run a single command, git-receive-pack.

First, you need to create an empty repository on the remote machine that will house your public repository. This empty repository will be populated and be kept up to date by pushing into it later. Obviously, this repository creation needs to be done only once.

Note

git push uses a pair of commands, git send-pack on your local machine, and git-receive-pack on the remote machine. The communication between the two over the network internally uses an SSH connection.

Your private repository’s Git directory is usually .git, but your public repository is often named after the project name, i.e. <project>.git. Let’s create such a public repository for project my-git. After logging into the remote machine, create an empty directory:

$ mkdir my-git.git

Then, make that directory into a Git repository by running git init, but this time, since its name is not the usual .git, we do things slightly differently:

$ GIT_DIR=my-git.git git init

Make sure this directory is available for others you want your changes to be pulled via the transport of your choice. Also you need to make sure that you have the git-receive-pack program on the $PATH.

Note

Many installations of sshd do not invoke your shell as the login shell when you directly run programs; what this means is that if your login shell is bash, only .bashrc is read and not .bash_profile. As a workaround, make sure .bashrc sets up $PATH so that you can run git-receive-pack program.

Note

If you plan to publish this repository to be accessed over http, you should do mv my-git.git/hooks/post-update.sample my-git.git/hooks/post-update at this point. This makes sure that every time you push into this repository, git update-server-info is run.

Your “public repository” is now ready to accept your changes. Come back to the machine you have your private repository. From there, run this command:

$ git push :/path/to/my-git.git master

This synchronizes your public repository to match the named branch head (i.e. master in this case) and objects reachable from them in your current repository.

As a real example, this is how I update my public Git repository. Kernel.org mirror network takes care of the propagation to other publicly visible machines:

$ git push master.kernel.org:/pub/scm/git/git.git/

PACKING YOUR REPOSITORY

Earlier, we saw that one file under .git/objects/??/ directory is stored for each Git object you create. This representation is efficient to create atomically and safely, but not so convenient to transport over the network. Since Git objects are immutable once they are created, there is a way to optimize the storage by “packing them together”. The command

$ git repack

will do it for you. If you followed the tutorial examples, you would have accumulated about 17 objects in .git/objects/??/ directories by now. git repack tells you how many objects it packed, and stores the packed file in the .git/objects/pack directory.

Note

You will see two files, pack-*.pack and pack-*.idx, in .git/objects/pack directory. They are closely related to each other, and if you ever copy them by hand to a different repository for whatever reason, you should make sure you copy them together. The former holds all the data from the objects in the pack, and the latter holds the index for random access.

If you are paranoid, running git verify-pack command would detect if you have a corrupt pack, but do not worry too much. Our programs are always perfect ;-).

Once you have packed objects, you do not need to leave the unpacked objects that are contained in the pack file anymore.

$ git prune-packed

would remove them for you.

You can try running find .git/objects -type f before and after you run git prune-packed if you are curious. Also git count-objects would tell you how many unpacked objects are in your repository and how much space they are consuming.

Note

git pull is slightly cumbersome for HTTP transport, as a packed repository may contain relatively few objects in a relatively large pack. If you expect many HTTP pulls from your public repository you might want to repack & prune often, or never.

If you run git repack again at this point, it will say “Nothing new to pack.”. Once you continue your development and accumulate the changes, running git repack again will create a new pack, that contains objects created since you packed your repository the last time. We recommend that you pack your project soon after the initial import (unless you are starting your project from scratch), and then run git repack every once in a while, depending on how active your project is.

When a repository is synchronized via git push and git pull objects packed in the source repository are usually stored unpacked in the destination. While this allows you to use different packing strategies on both ends, it also means you may need to repack both repositories every once in a while.

WORKING WITH OTHERS

Although Git is a truly distributed system, it is often convenient to organize your project with an informal hierarchy of developers. Linux kernel development is run this way. There is a nice illustration (page 17, “Merges to Mainline”) in Randy Dunlap’s presentation[2].

It should be stressed that this hierarchy is purely informal. There is nothing fundamental in Git that enforces the “chain of patch flow” this hierarchy implies. You do not have to pull from only one remote repository.

A recommended workflow for a “project lead” goes like this:

1.

Prepare your primary repository on your local machine. Your work is done there.

2.

Prepare a public repository accessible to others.

If other people are pulling from your repository over dumb transport protocols (HTTP), you need to keep this repository dumb transport friendly. After git init, $GIT_DIR/hooks/post-update.sample copied from the standard templates would contain a call to git update-server-info but you need to manually enable the hook with mv post-update.sample post-update. This makes sure git update-server-info keeps the necessary files up to date.

3.

Push into the public repository from your primary repository.

4.

git repack the public repository. This establishes a big pack that contains the initial set of objects as the baseline, and possibly git prune if the transport used for pulling from your repository supports packed repositories.

5.

Keep working in your primary repository. Your changes include modifications of your own, patches you receive via e-mails, and merges resulting from pulling the “public” repositories of your “subsystem maintainers”.

You can repack this private repository whenever you feel like.

6.

Push your changes to the public repository, and announce it to the public.

7.

Every once in a while, git repack the public repository. Go back to step 5. and continue working.

A recommended work cycle for a “subsystem maintainer” who works on that project and has an own “public repository” goes like this:

1.

Prepare your work repository, by running git clone on the public repository of the “project lead”. The URL used for the initial cloning is stored in the remote.origin.url configuration variable.

2.

Prepare a public repository accessible to others, just like the “project lead” person does.

3.

Copy over the packed files from “project lead” public repository to your public repository, unless the “project lead” repository lives on the same machine as yours. In the latter case, you can use objects/info/alternates file to point at the repository you are borrowing from.

4.

Push into the public repository from your primary repository. Run git repack, and possibly git prune if the transport used for pulling from your repository supports packed repositories.

5.

Keep working in your primary repository. Your changes include modifications of your own, patches you receive via e-mails, and merges resulting from pulling the “public” repositories of your “project lead” and possibly your “sub-subsystem maintainers”.

You can repack this private repository whenever you feel like.

6.

Push your changes to your public repository, and ask your “project lead” and possibly your “sub-subsystem maintainers” to pull from it.

7.

Every once in a while, git repack the public repository. Go back to step 5. and continue working.

A recommended work cycle for an “individual developer” who does not have a “public” repository is somewhat different. It goes like this:

1.

Prepare your work repository, by git clone the public repository of the “project lead” (or a “subsystem maintainer”, if you work on a subsystem). The URL used for the initial cloning is stored in the remote.origin.url configuration variable.

2.

Do your work in your repository on master branch.

3.

Run git fetch origin from the public repository of your upstream every once in a while. This does only the first half of git pull but does not merge. The head of the public repository is stored in .git/refs/remotes/origin/master.

4.

Use git cherry origin to see which ones of your patches were accepted, and/or use git rebase origin to port your unmerged changes forward to the updated upstream.

5.

Use git format-patch origin to prepare patches for e-mail submission to your upstream and send it out. Go back to step 2. and continue.

WORKING WITH OTHERS, SHARED REPOSITORY STYLE

If you are coming from a CVS background, the style of cooperation suggested in the previous section may be new to you. You do not have to worry. Git supports the “shared public repository” style of cooperation you are probably more familiar with as well.

See gitcvs-migration(7) for the details.

BUNDLING YOUR WORK TOGETHER

It is likely that you will be working on more than one thing at a time. It is easy to manage those more-or-less independent tasks using branches with Git.

We have already seen how branches work previously, with “fun and work” example using two branches. The idea is the same if there are more than two branches. Let’s say you started out from “master” head, and have some new code in the “master” branch, and two independent fixes in the “commit-fix” and “diff-fix” branches:

$ git show-branch ! [commit-fix] Fix commit message normalization. ! [diff-fix] Fix rename detection. * [master] Release candidate #1 — + [diff-fix] Fix rename detection. + [diff-fix1] Better common substring algorithm. + [commit-fix] Fix commit message normalization. * [master] Release candidate #1 ++* [diff-fix2] Pretty-print messages.

Both fixes are tested well, and at this point, you want to merge in both of them. You could merge in diff-fix first and then commit-fix next, like this:

$ git merge -m “Merge fix in diff-fix” diff-fix $ git merge -m “Merge fix in commit-fix” commit-fix

Which would result in:

$ git show-branch ! [commit-fix] Fix commit message normalization. ! [diff-fix] Fix rename detection. * [master] Merge fix in commit-fix — - [master] Merge fix in commit-fix + * [commit-fix] Fix commit message normalization. - [master1] Merge fix in diff-fix +* [diff-fix] Fix rename detection. +* [diff-fix1] Better common substring algorithm. * [master2] Release candidate #1 ++* [master3] Pretty-print messages.

However, there is no particular reason to merge in one branch first and the other next, when what you have are a set of truly independent changes (if the order mattered, then they are not independent by definition). You could instead merge those two branches into the current branch at once. First let’s undo what we just did and start over. We would want to get the master branch before these two merges by resetting it to master~2:

$ git reset –hard master~2

You can make sure git show-branch matches the state before those two git merge you just did. Then, instead of running two git merge commands in a row, you would merge these two branch heads (this is known as making an Octopus):

$ git merge commit-fix diff-fix $ git show-branch ! [commit-fix] Fix commit message normalization. ! [diff-fix] Fix rename detection. * [master] Octopus merge of branches diff-fix and commit-fix — - [master] Octopus merge of branches diff-fix and commit-fix + * [commit-fix] Fix commit message normalization. +* [diff-fix] Fix rename detection. +* [diff-fix1] Better common substring algorithm. * [master1] Release candidate #1 ++* [master~2] Pretty-print messages.

Note that you should not do Octopus just because you can. An octopus is a valid thing to do and often makes it easier to view the commit history if you are merging more than two independent changes at the same time. However, if you have merge conflicts with any of the branches you are merging in and need to hand resolve, that is an indication that the development happened in those branches were not independent after all, and you should merge two at a time, documenting how you resolved the conflicts, and the reason why you preferred changes made in one side over the other. Otherwise it would make the project history harder to follow, not easier.

SEE ALSO

gittutorial(7), gittutorial-2(7), gitcvs-migration(7), git-help(1), giteveryday(7), The Git User’s Manual[1]

GIT

Part of the git(1) suite

NOTES

the Git User Manual

file:///usr/share/doc/git/html/user-manual.html

Randy Dunlap’s presentation

https://web.archive.org/web/20120915203609/http://www.xenotime.net/linux/mentor/linux-mentoring-2006.pdf

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

112 - Linux cli command xattr

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command xattr and provides detailed information about the command xattr, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the xattr.

NAME 🖥️ xattr 🖥️

Extended attributes

DESCRIPTION

Extended attributes are name:value pairs associated permanently with files and directories, similar to the environment strings associated with a process. An attribute may be defined or undefined. If it is defined, its value may be empty or non-empty.

Extended attributes are extensions to the normal attributes which are associated with all inodes in the system (i.e., the stat(2) data). They are often used to provide additional functionality to a filesystem—for example, additional security features such as Access Control Lists (ACLs) may be implemented using extended attributes.

Users with search access to a file or directory may use listxattr(2) to retrieve a list of attribute names defined for that file or directory.

Extended attributes are accessed as atomic objects. Reading (getxattr(2)) retrieves the whole value of an attribute and stores it in a buffer. Writing (setxattr(2)) replaces any previous value with the new value.

Space consumed for extended attributes may be counted towards the disk quotas of the file owner and file group.

Extended attribute namespaces

Attribute names are null-terminated strings. The attribute name is always specified in the fully qualified namespace.attribute form, for example, user.mime_type, trusted.md5sum, system.posix_acl_access, or security.selinux.

The namespace mechanism is used to define different classes of extended attributes. These different classes exist for several reasons; for example, the permissions and capabilities required for manipulating extended attributes of one namespace may differ to another.

Currently, the security, system, trusted, and user extended attribute classes are defined as described below. Additional classes may be added in the future.

Extended security attributes

The security attribute namespace is used by kernel security modules, such as Security Enhanced Linux, and also to implement file capabilities (see capabilities(7)). Read and write access permissions to security attributes depend on the policy implemented for each security attribute by the security module. When no security module is loaded, all processes have read access to extended security attributes, and write access is limited to processes that have the CAP_SYS_ADMIN capability.

System extended attributes

System extended attributes are used by the kernel to store system objects such as Access Control Lists. Read and write access permissions to system attributes depend on the policy implemented for each system attribute implemented by filesystems in the kernel.

Trusted extended attributes

Trusted extended attributes are visible and accessible only to processes that have the CAP_SYS_ADMIN capability. Attributes in this class are used to implement mechanisms in user space (i.e., outside the kernel) which keep information in extended attributes to which ordinary processes should not have access.

User extended attributes

User extended attributes may be assigned to files and directories for storing arbitrary additional information such as the mime type, character set or encoding of a file. The access permissions for user attributes are defined by the file permission bits: read permission is required to retrieve the attribute value, and writer permission is required to change it.

The file permission bits of regular files and directories are interpreted differently from the file permission bits of special files and symbolic links. For regular files and directories the file permission bits define access to the file’s contents, while for device special files they define access to the device described by the special file. The file permissions of symbolic links are not used in access checks. These differences would allow users to consume filesystem resources in a way not controllable by disk quotas for group or world writable special files and directories.

For this reason, user extended attributes are allowed only for regular files and directories, and access to user extended attributes is restricted to the owner and to users with appropriate capabilities for directories with the sticky bit set (see the chmod(1) manual page for an explanation of the sticky bit).

Filesystem differences

The kernel and the filesystem may place limits on the maximum number and size of extended attributes that can be associated with a file. The VFS-imposed limits on attribute names and values are 255 bytes and 64 kB, respectively. The list of attribute names that can be returned is also limited to 64 kB (see BUGS in listxattr(2)).

Some filesystems, such as Reiserfs (and, historically, ext2 and ext3), require the filesystem to be mounted with the user_xattr mount option in order for user extended attributes to be used.

In the current ext2, ext3, and ext4 filesystem implementations, the total bytes used by the names and values of all of a file’s extended attributes must fit in a single filesystem block (1024, 2048 or 4096 bytes, depending on the block size specified when the filesystem was created).

In the Btrfs, XFS, and Reiserfs filesystem implementations, there is no practical limit on the number of extended attributes associated with a file, and the algorithms used to store extended attribute information on disk are scalable.

In the JFS, XFS, and Reiserfs filesystem implementations, the limit on bytes used in an EA value is the ceiling imposed by the VFS.

In the Btrfs filesystem implementation, the total bytes used for the name, value, and implementation overhead bytes is limited to the filesystem nodesize value (16 kB by default).

STANDARDS

Extended attributes are not specified in POSIX.1, but some other systems (e.g., the BSDs and Solaris) provide a similar feature.

NOTES

Since the filesystems on which extended attributes are stored might also be used on architectures with a different byte order and machine word size, care should be taken to store attribute values in an architecture-independent format.

This page was formerly named attr(5).

SEE ALSO

attr(1), getfattr(1), setfattr(1), getxattr(2), ioctl_iflags(2), listxattr(2), removexattr(2), setxattr(2), acl(5), capabilities(7), selinux(8)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

113 - Linux cli command CREATE_OPERATOR_CLASS

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_OPERATOR_CLASS and provides detailed information about the command CREATE_OPERATOR_CLASS, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_OPERATOR_CLASS.

NAME 🖥️ CREATE_OPERATOR_CLASS 🖥️

define a new operator class

SYNOPSIS

CREATE OPERATOR CLASS name [ DEFAULT ] FOR TYPE data_type
  USING index_method [ FAMILY family_name ] AS
  {  OPERATOR strategy_number operator_name [ ( op_type, op_type ) ] [ FOR SEARCH | FOR ORDER BY sort_family_name ]
   | FUNCTION support_number [ ( op_type [ , op_type ] ) ] function_name ( argument_type [, ...] )
   | STORAGE storage_type
  } [, ... ]

DESCRIPTION

CREATE OPERATOR CLASS creates a new operator class. An operator class defines how a particular data type can be used with an index. The operator class specifies that certain operators will fill particular roles or “strategies” for this data type and this index method. The operator class also specifies the support functions to be used by the index method when the operator class is selected for an index column. All the operators and functions used by an operator class must be defined before the operator class can be created.

If a schema name is given then the operator class is created in the specified schema. Otherwise it is created in the current schema. Two operator classes in the same schema can have the same name only if they are for different index methods.

The user who defines an operator class becomes its owner. Presently, the creating user must be a superuser. (This restriction is made because an erroneous operator class definition could confuse or even crash the server.)

CREATE OPERATOR CLASS does not presently check whether the operator class definition includes all the operators and functions required by the index method, nor whether the operators and functions form a self-consistent set. It is the users responsibility to define a valid operator class.

Related operator classes can be grouped into operator families. To add a new operator class to an existing family, specify the FAMILY option in CREATE OPERATOR CLASS. Without this option, the new class is placed into a family named the same as the new class (creating that family if it doesnt already exist).

Refer to Section 38.16 for further information.

PARAMETERS

name

The name of the operator class to be created. The name can be schema-qualified.

DEFAULT

If present, the operator class will become the default operator class for its data type. At most one operator class can be the default for a specific data type and index method.

data_type

The column data type that this operator class is for.

index_method

The name of the index method this operator class is for.

family_name

The name of the existing operator family to add this operator class to. If not specified, a family named the same as the operator class is used (creating it, if it doesnt already exist).

strategy_number

The index methods strategy number for an operator associated with the operator class.

operator_name

The name (optionally schema-qualified) of an operator associated with the operator class.

op_type

In an OPERATOR clause, the operand data type(s) of the operator, or NONE to signify a prefix operator. The operand data types can be omitted in the normal case where they are the same as the operator classs data type.

In a FUNCTION clause, the operand data type(s) the function is intended to support, if different from the input data type(s) of the function (for B-tree comparison functions and hash functions) or the classs data type (for B-tree sort support functions, B-tree equal image functions, and all functions in GiST, SP-GiST, GIN and BRIN operator classes). These defaults are correct, and so op_type need not be specified in FUNCTION clauses, except for the case of a B-tree sort support function that is meant to support cross-data-type comparisons.

sort_family_name

The name (optionally schema-qualified) of an existing btree operator family that describes the sort ordering associated with an ordering operator.

If neither FOR SEARCH nor FOR ORDER BY is specified, FOR SEARCH is the default.

support_number

The index methods support function number for a function associated with the operator class.

function_name

The name (optionally schema-qualified) of a function that is an index method support function for the operator class.

argument_type

The parameter data type(s) of the function.

storage_type

The data type actually stored in the index. Normally this is the same as the column data type, but some index methods (currently GiST, GIN, SP-GiST and BRIN) allow it to be different. The STORAGE clause must be omitted unless the index method allows a different type to be used. If the column data_type is specified as anyarray, the storage_type can be declared as anyelement to indicate that the index entries are members of the element type belonging to the actual array type that each particular index is created for.

The OPERATOR, FUNCTION, and STORAGE clauses can appear in any order.

NOTES

Because the index machinery does not check access permissions on functions before using them, including a function or operator in an operator class is tantamount to granting public execute permission on it. This is usually not an issue for the sorts of functions that are useful in an operator class.

The operators should not be defined by SQL functions. An SQL function is likely to be inlined into the calling query, which will prevent the optimizer from recognizing that the query matches an index.

Before PostgreSQL 8.4, the OPERATOR clause could include a RECHECK option. This is no longer supported because whether an index operator is “lossy” is now determined on-the-fly at run time. This allows efficient handling of cases where an operator might or might not be lossy.

EXAMPLES

The following example command defines a GiST index operator class for the data type _int4 (array of int4). See the intarray module for the complete example.

CREATE OPERATOR CLASS gist__int_ops DEFAULT FOR TYPE _int4 USING gist AS OPERATOR 3 &&, OPERATOR 6 = (anyarray, anyarray), OPERATOR 7 @>, OPERATOR 8 <@, OPERATOR 20 @@ (_int4, query_int), FUNCTION 1 g_int_consistent (internal, _int4, smallint, oid, internal), FUNCTION 2 g_int_union (internal, internal), FUNCTION 3 g_int_compress (internal), FUNCTION 4 g_int_decompress (internal), FUNCTION 5 g_int_penalty (internal, internal, internal), FUNCTION 6 g_int_picksplit (internal, internal), FUNCTION 7 g_int_same (_int4, _int4, internal);

COMPATIBILITY

CREATE OPERATOR CLASS is a PostgreSQL extension. There is no CREATE OPERATOR CLASS statement in the SQL standard.

SEE ALSO

ALTER OPERATOR CLASS (ALTER_OPERATOR_CLASS(7)), DROP OPERATOR CLASS (DROP_OPERATOR_CLASS(7)), CREATE OPERATOR FAMILY (CREATE_OPERATOR_FAMILY(7)), ALTER OPERATOR FAMILY (ALTER_OPERATOR_FAMILY(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

114 - Linux cli command ALTER_SEQUENCE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_SEQUENCE and provides detailed information about the command ALTER_SEQUENCE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_SEQUENCE.

NAME 🖥️ ALTER_SEQUENCE 🖥️

change the definition of a sequence generator

SYNOPSIS

ALTER SEQUENCE [ IF EXISTS ] name
    [ AS data_type ]
    [ INCREMENT [ BY ] increment ]
    [ MINVALUE minvalue | NO MINVALUE ] [ MAXVALUE maxvalue | NO MAXVALUE ]
    [ START [ WITH ] start ]
    [ RESTART [ [ WITH ] restart ] ]
    [ CACHE cache ] [ [ NO ] CYCLE ]
    [ OWNED BY { table_name.column_name | NONE } ]
ALTER SEQUENCE [ IF EXISTS ] name SET { LOGGED | UNLOGGED }
ALTER SEQUENCE [ IF EXISTS ] name OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }
ALTER SEQUENCE [ IF EXISTS ] name RENAME TO new_name
ALTER SEQUENCE [ IF EXISTS ] name SET SCHEMA new_schema

DESCRIPTION

ALTER SEQUENCE changes the parameters of an existing sequence generator. Any parameters not specifically set in the ALTER SEQUENCE command retain their prior settings.

You must own the sequence to use ALTER SEQUENCE. To change a sequences schema, you must also have CREATE privilege on the new schema. To alter the owner, you must be able to SET ROLE to the new owning role, and that role must have CREATE privilege on the sequences schema. (These restrictions enforce that altering the owner doesnt do anything you couldnt do by dropping and recreating the sequence. However, a superuser can alter ownership of any sequence anyway.)

PARAMETERS

name

The name (optionally schema-qualified) of a sequence to be altered.

IF EXISTS

Do not throw an error if the sequence does not exist. A notice is issued in this case.

data_type

The optional clause AS data_type changes the data type of the sequence. Valid types are smallint, integer, and bigint.

Changing the data type automatically changes the minimum and maximum values of the sequence if and only if the previous minimum and maximum values were the minimum or maximum value of the old data type (in other words, if the sequence had been created using NO MINVALUE or NO MAXVALUE, implicitly or explicitly). Otherwise, the minimum and maximum values are preserved, unless new values are given as part of the same command. If the minimum and maximum values do not fit into the new data type, an error will be generated.

increment

The clause INCREMENT BY increment is optional. A positive value will make an ascending sequence, a negative one a descending sequence. If unspecified, the old increment value will be maintained.

minvalue
NO MINVALUE

The optional clause MINVALUE minvalue determines the minimum value a sequence can generate. If NO MINVALUE is specified, the defaults of 1 and the minimum value of the data type for ascending and descending sequences, respectively, will be used. If neither option is specified, the current minimum value will be maintained.

maxvalue
NO MAXVALUE

The optional clause MAXVALUE maxvalue determines the maximum value for the sequence. If NO MAXVALUE is specified, the defaults of the maximum value of the data type and -1 for ascending and descending sequences, respectively, will be used. If neither option is specified, the current maximum value will be maintained.

start

The optional clause START WITH start changes the recorded start value of the sequence. This has no effect on the current sequence value; it simply sets the value that future ALTER SEQUENCE RESTART commands will use.

restart

The optional clause RESTART [ WITH restart ] changes the current value of the sequence. This is similar to calling the setval function with is_called = false: the specified value will be returned by the next call of nextval. Writing RESTART with no restart value is equivalent to supplying the start value that was recorded by CREATE SEQUENCE or last set by ALTER SEQUENCE START WITH.

In contrast to a setval call, a RESTART operation on a sequence is transactional and blocks concurrent transactions from obtaining numbers from the same sequence. If thats not the desired mode of operation, setval should be used.

cache

The clause CACHE cache enables sequence numbers to be preallocated and stored in memory for faster access. The minimum value is 1 (only one value can be generated at a time, i.e., no cache). If unspecified, the old cache value will be maintained.

CYCLE

The optional CYCLE key word can be used to enable the sequence to wrap around when the maxvalue or minvalue has been reached by an ascending or descending sequence respectively. If the limit is reached, the next number generated will be the minvalue or maxvalue, respectively.

NO CYCLE

If the optional NO CYCLE key word is specified, any calls to nextval after the sequence has reached its maximum value will return an error. If neither CYCLE or NO CYCLE are specified, the old cycle behavior will be maintained.

SET { LOGGED | UNLOGGED }

This form changes the sequence from unlogged to logged or vice-versa (see CREATE SEQUENCE (CREATE_SEQUENCE(7))). It cannot be applied to a temporary sequence.

OWNED BY table_name.column_name
OWNED BY NONE

The OWNED BY option causes the sequence to be associated with a specific table column, such that if that column (or its whole table) is dropped, the sequence will be automatically dropped as well. If specified, this association replaces any previously specified association for the sequence. The specified table must have the same owner and be in the same schema as the sequence. Specifying OWNED BY NONE removes any existing association, making the sequence “free-standing”.

new_owner

The user name of the new owner of the sequence.

new_name

The new name for the sequence.

new_schema

The new schema for the sequence.

NOTES

ALTER SEQUENCE will not immediately affect nextval results in backends, other than the current one, that have preallocated (cached) sequence values. They will use up all cached values prior to noticing the changed sequence generation parameters. The current backend will be affected immediately.

ALTER SEQUENCE does not affect the currval status for the sequence. (Before PostgreSQL 8.3, it sometimes did.)

ALTER SEQUENCE blocks concurrent nextval, currval, lastval, and setval calls.

For historical reasons, ALTER TABLE can be used with sequences too; but the only variants of ALTER TABLE that are allowed with sequences are equivalent to the forms shown above.

EXAMPLES

Restart a sequence called serial, at 105:

ALTER SEQUENCE serial RESTART WITH 105;

COMPATIBILITY

ALTER SEQUENCE conforms to the SQL standard, except for the AS, START WITH, OWNED BY, OWNER TO, RENAME TO, and SET SCHEMA clauses, which are PostgreSQL extensions.

SEE ALSO

CREATE SEQUENCE (CREATE_SEQUENCE(7)), DROP SEQUENCE (DROP_SEQUENCE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

115 - Linux cli command EVP_MD-SHAKEssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_MD-SHAKEssl and provides detailed information about the command EVP_MD-SHAKEssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_MD-SHAKEssl.

NAME 🖥️ EVP_MD-SHAKEssl 🖥️

SHAKE, EVP_MD-KECCAK-KMAC - The SHAKE / KECCAK family EVP_MD implementations

DESCRIPTION

Support for computing SHAKE or KECCAK-KMAC digests through the EVP_MD API.

KECCAK-KMAC is an Extendable Output Function (XOF), with a definition similar to SHAKE, used by the KMAC EVP_MAC implementation (see EVP_MAC-KMAC (7)).

Identities

This implementation is available in the FIPS provider as well as the default provider, and includes the following varieties:

KECCAK-KMAC-128
Known names are “KECCAK-KMAC-128” and “KECCAK-KMAC128”. This is used by EVP_MAC-KMAC128 (7). Using the notation from NIST FIPS 202 (Section 6.2), we have KECCAK-KMAC-128(M, d) = KECCAK[256](M || 00, d) (see the description of KMAC128 in Appendix A of NIST SP 800-185).

KECCAK-KMAC-256
Known names are “KECCAK-KMAC-256” and “KECCAK-KMAC256”. This is used by EVP_MAC-KMAC256 (7). Using the notation from NIST FIPS 202 (Section 6.2), we have KECCAK-KMAC-256(M, d) = KECCAK[512](M || 00, d) (see the description of KMAC256 in Appendix A of NIST SP 800-185).

SHAKE-128
Known names are “SHAKE-128” and “SHAKE128”.

SHAKE-256
Known names are “SHAKE-256” and “SHAKE256”.

Gettable Parameters

This implementation supports the common gettable parameters described in EVP_MD-common (7).

Settable Context Parameters

These implementations support the following OSSL_PARAM (3) entries, settable for an EVP_MD_CTX with EVP_MD_CTX_set_params (3):

“xoflen” (OSSL_DIGEST_PARAM_XOFLEN) <unsigned integer>
Sets the digest length for extendable output functions. The length of the “xoflen” parameter should not exceed that of a size_t. For backwards compatibility reasons the default xoflen length for SHAKE-128 is 16 (bytes) which results in a security strength of only 64 bits. To ensure the maximum security strength of 128 bits, the xoflen should be set to at least 32. For backwards compatibility reasons the default xoflen length for SHAKE-256 is 32 (bytes) which results in a security strength of only 128 bits. To ensure the maximum security strength of 256 bits, the xoflen should be set to at least 64.

SEE ALSO

EVP_MD_CTX_set_params (3), provider-digest (7), OSSL_PROVIDER-default (7)

COPYRIGHT

Copyright 2020-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

116 - Linux cli command iso_8859-10

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso_8859-10 and provides detailed information about the command iso_8859-10, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso_8859-10.

NAME 🖥️ iso_8859-10 🖥️

10 - ISO/IEC 8859-10 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-10 encodes the characters used in Nordic languages.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-10 characters

The following table displays the characters in ISO/IEC 8859-10 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-10 is also known as Latin-6.

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

117 - Linux cli command udp

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command udp and provides detailed information about the command udp, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the udp.

NAME 🖥️ udp 🖥️

User Datagram Protocol for IPv4

SYNOPSIS

#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/udp.h>
udp_socket = socket(AF_INET, SOCK_DGRAM, 0);

DESCRIPTION

This is an implementation of the User Datagram Protocol described in RFC 768. It implements a connectionless, unreliable datagram packet service. Packets may be reordered or duplicated before they arrive. UDP generates and checks checksums to catch transmission errors.

When a UDP socket is created, its local and remote addresses are unspecified. Datagrams can be sent immediately using sendto(2) or sendmsg(2) with a valid destination address as an argument. When connect(2) is called on the socket, the default destination address is set and datagrams can now be sent using send(2) or write(2) without specifying a destination address. It is still possible to send to other destinations by passing an address to sendto(2) or sendmsg(2). In order to receive packets, the socket can be bound to a local address first by using bind(2). Otherwise, the socket layer will automatically assign a free local port out of the range defined by /proc/sys/net/ipv4/ip_local_port_range and bind the socket to INADDR_ANY.

All receive operations return only one packet. When the packet is smaller than the passed buffer, only that much data is returned; when it is bigger, the packet is truncated and the MSG_TRUNC flag is set. MSG_WAITALL is not supported.

IP options may be sent or received using the socket options described in ip(7). They are processed by the kernel only when the appropriate /proc parameter is enabled (but still passed to the user even when it is turned off). See ip(7).

When the MSG_DONTROUTE flag is set on sending, the destination address must refer to a local interface address and the packet is sent only to that interface.

By default, Linux UDP does path MTU (Maximum Transmission Unit) discovery. This means the kernel will keep track of the MTU to a specific target IP address and return EMSGSIZE when a UDP packet write exceeds it. When this happens, the application should decrease the packet size. Path MTU discovery can be also turned off using the IP_MTU_DISCOVER socket option or the /proc/sys/net/ipv4/ip_no_pmtu_disc file; see ip(7) for details. When turned off, UDP will fragment outgoing UDP packets that exceed the interface MTU. However, disabling it is not recommended for performance and reliability reasons.

Address format

UDP uses the IPv4 sockaddr_in address format described in ip(7).

Error handling

All fatal errors will be passed to the user as an error return even when the socket is not connected. This includes asynchronous errors received from the network. You may get an error for an earlier packet that was sent on the same socket. This behavior differs from many other BSD socket implementations which don’t pass any errors unless the socket is connected. Linux’s behavior is mandated by RFC 1122.

For compatibility with legacy code, in Linux 2.0 and 2.2 it was possible to set the SO_BSDCOMPAT SOL_SOCKET option to receive remote errors only when the socket has been connected (except for EPROTO and EMSGSIZE). Locally generated errors are always passed. Support for this socket option was removed in later kernels; see socket(7) for further information.

When the IP_RECVERR option is enabled, all errors are stored in the socket error queue, and can be received by recvmsg(2) with the MSG_ERRQUEUE flag set.

/proc interfaces

System-wide UDP parameter settings can be accessed by files in the directory /proc/sys/net/ipv4/.

udp_mem (since Linux 2.6.25)
This is a vector of three integers governing the number of pages allowed for queueing by all UDP sockets.

min
Below this number of pages, UDP is not bothered about its memory appetite. When the amount of memory allocated by UDP exceeds this number, UDP starts to moderate memory usage.

pressure
This value was introduced to follow the format of tcp_mem (see tcp(7)).

max
Number of pages allowed for queueing by all UDP sockets.

Defaults values for these three items are calculated at boot time from the amount of available memory.

udp_rmem_min (integer; default value: PAGE_SIZE; since Linux 2.6.25)
Minimal size, in bytes, of receive buffers used by UDP sockets in moderation. Each UDP socket is able to use the size for receiving data, even if total pages of UDP sockets exceed udp_mem pressure.

udp_wmem_min (integer; default value: PAGE_SIZE; since Linux 2.6.25)
Minimal size, in bytes, of send buffer used by UDP sockets in moderation. Each UDP socket is able to use the size for sending data, even if total pages of UDP sockets exceed udp_mem pressure.

Socket options

To set or get a UDP socket option, call getsockopt(2) to read or setsockopt(2) to write the option with the option level argument set to IPPROTO_UDP. Unless otherwise noted, optval is a pointer to an int.

Following is a list of UDP-specific socket options. For details of some other socket options that are also applicable for UDP sockets, see socket(7).

UDP_CORK (since Linux 2.5.44)
If this option is enabled, then all data output on this socket is accumulated into a single datagram that is transmitted when the option is disabled. This option should not be used in code intended to be portable.

UDP_SEGMENT (since Linux 4.18)
Enables UDP segmentation offload. Segmentation offload reduces send(2) cost by transferring multiple datagrams worth of data as a single large packet through the kernel transmit path, even when that exceeds MTU. As late as possible, the large packet is split by segment size into a series of datagrams. This segmentation offload step is deferred to hardware if supported, else performed in software. This option takes a value in the range [0, USHRT_MAX] that sets the segment size: the size of datagram payload, excluding the UDP header. The segment size must be chosen such that at most 64 datagrams are sent in a single call and that the datagrams after segmentation meet the same MTU rules that apply to datagrams sent without this option. Segmentation offload depends on checksum offload, as datagram checksums are computed after segmentation. The option may also be set for individual sendmsg(2) calls by passing it as a cmsg(3). A value of zero disables the feature. This option should not be used in code intended to be portable.

UDP_GRO (since Linux 5.0)
Enables UDP receive offload. If enabled, the socket may receive multiple datagrams worth of data as a single large buffer, together with a cmsg(3) that holds the segment size. This option is the inverse of segmentation offload. It reduces receive cost by handling multiple datagrams worth of data as a single large packet in the kernel receive path, even when that exceeds MTU. This option should not be used in code intended to be portable.

Ioctls

These ioctls can be accessed using ioctl(2). The correct syntax is:

int value; error = ioctl(udp_socket, ioctl_type, &value);

FIONREAD (SIOCINQ)
Gets a pointer to an integer as argument. Returns the size of the next pending datagram in the integer in bytes, or 0 when no datagram is pending. Warning: Using FIONREAD, it is impossible to distinguish the case where no datagram is pending from the case where the next pending datagram contains zero bytes of data. It is safer to use select(2), poll(2), or epoll(7) to distinguish these cases.

TIOCOUTQ (SIOCOUTQ)
Returns the number of data bytes in the local send queue. Supported only with Linux 2.4 and above.

In addition, all ioctls documented in ip(7) and socket(7) are supported.

ERRORS

All errors documented for socket(7) or ip(7) may be returned by a send or receive on a UDP socket.

ECONNREFUSED
No receiver was associated with the destination address. This might be caused by a previous packet sent over the socket.

VERSIONS

IP_RECVERR is a new feature in Linux 2.2.

SEE ALSO

ip(7), raw(7), socket(7), udplite(7)

The kernel source file Documentation/networking/ip-sysctl.txt.

RFC 768 for the User Datagram Protocol.
RFC 1122 for the host requirements.
RFC 1191 for a description of path MTU discovery.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

118 - Linux cli command DROP_TEXT_SEARCH_TEMPLATE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_TEXT_SEARCH_TEMPLATE and provides detailed information about the command DROP_TEXT_SEARCH_TEMPLATE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_TEXT_SEARCH_TEMPLATE.

NAME 🖥️ DROP_TEXT_SEARCH_TEMPLATE 🖥️

remove a text search template

SYNOPSIS

DROP TEXT SEARCH TEMPLATE [ IF EXISTS ] name [ CASCADE | RESTRICT ]

DESCRIPTION

DROP TEXT SEARCH TEMPLATE drops an existing text search template. You must be a superuser to use this command.

PARAMETERS

IF EXISTS

Do not throw an error if the text search template does not exist. A notice is issued in this case.

name

The name (optionally schema-qualified) of an existing text search template.

CASCADE

Automatically drop objects that depend on the text search template, and in turn all objects that depend on those objects (see Section 5.14).

RESTRICT

Refuse to drop the text search template if any objects depend on it. This is the default.

EXAMPLES

Remove the text search template thesaurus:

DROP TEXT SEARCH TEMPLATE thesaurus;

This command will not succeed if there are any existing text search dictionaries that use the template. Add CASCADE to drop such dictionaries along with the template.

COMPATIBILITY

There is no DROP TEXT SEARCH TEMPLATE statement in the SQL standard.

SEE ALSO

ALTER TEXT SEARCH TEMPLATE (ALTER_TEXT_SEARCH_TEMPLATE(7)), CREATE TEXT SEARCH TEMPLATE (CREATE_TEXT_SEARCH_TEMPLATE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

119 - Linux cli command EVP_KDF-PBKDF1ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KDF-PBKDF1ssl and provides detailed information about the command EVP_KDF-PBKDF1ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KDF-PBKDF1ssl.

NAME 🖥️ EVP_KDF-PBKDF1ssl 🖥️

PBKDF1 - The PBKDF1 EVP_KDF implementation

DESCRIPTION

Support for computing the PBKDF1 password-based KDF through the EVP_KDF API.

The EVP_KDF-PBKDF1 algorithm implements the PBKDF1 password-based key derivation function, as described in RFC 8018; it derives a key from a password using a salt and iteration count.

Identity

“PBKDF1” is the name for this implementation; it can be used with the EVP_KDF_fetch() function.

Supported parameters

The supported parameters are:

“pass” (OSSL_KDF_PARAM_PASSWORD) <octet string>

“salt” (OSSL_KDF_PARAM_SALT) <octet string>

“iter” (OSSL_KDF_PARAM_ITER) <unsigned integer>

This parameter has a default value of 0 and should be set.

“properties” (OSSL_KDF_PARAM_PROPERTIES) <UTF8 string>

“digest” (OSSL_KDF_PARAM_DIGEST) <UTF8 string>

These parameters work as described in “PARAMETERS” in EVP_KDF (3).

NOTES

A typical application of this algorithm is to derive keying material for an encryption algorithm from a password in the “pass”, a salt in “salt”, and an iteration count.

Increasing the “iter” parameter slows down the algorithm which makes it harder for an attacker to perform a brute force attack using a large number of candidate passwords.

No assumption is made regarding the given password; it is simply treated as a byte sequence.

The legacy provider needs to be available in order to access this algorithm.

CONFORMING TO

RFC 8018

SEE ALSO

EVP_KDF (3), EVP_KDF_CTX_new (3), EVP_KDF_CTX_free (3), EVP_KDF_CTX_set_params (3), EVP_KDF_derive (3), “PARAMETERS” in EVP_KDF (3), OSSL_PROVIDER-legacy (7)

HISTORY

This functionality was added in OpenSSL 3.0.

COPYRIGHT

Copyright 2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

120 - Linux cli command numa

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command numa and provides detailed information about the command numa, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the numa.

NAME 🖥️ numa 🖥️

overview of Non-Uniform Memory Architecture

DESCRIPTION

Non-Uniform Memory Access (NUMA) refers to multiprocessor systems whose memory is divided into multiple memory nodes. The access time of a memory node depends on the relative locations of the accessing CPU and the accessed node. (This contrasts with a symmetric multiprocessor system, where the access time for all of the memory is the same for all CPUs.) Normally, each CPU on a NUMA system has a local memory node whose contents can be accessed faster than the memory in the node local to another CPU or the memory on a bus shared by all CPUs.

NUMA system calls

The Linux kernel implements the following NUMA-related system calls: get_mempolicy(2), mbind(2), migrate_pages(2), move_pages(2), and set_mempolicy(2). However, applications should normally use the interface provided by libnuma; see “Library Support” below.

/proc/pid/numa_maps (since Linux 2.6.14)

This file displays information about a process’s NUMA memory policy and allocation.

Each line contains information about a memory range used by the process, displaying—among other information—the effective memory policy for that memory range and on which nodes the pages have been allocated.

numa_maps is a read-only file. When /proc/pid/numa_maps is read, the kernel will scan the virtual address space of the process and report how memory is used. One line is displayed for each unique memory range of the process.

The first field of each line shows the starting address of the memory range. This field allows a correlation with the contents of the /proc/pid/maps file, which contains the end address of the range and other information, such as the access permissions and sharing.

The second field shows the memory policy currently in effect for the memory range. Note that the effective policy is not necessarily the policy installed by the process for that memory range. Specifically, if the process installed a “default” policy for that range, the effective policy for that range will be the process policy, which may or may not be “default”.

The rest of the line contains information about the pages allocated in the memory range, as follows:

N<node>=<nr_pages>
The number of pages allocated on <node>. <nr_pages> includes only pages currently mapped by the process. Page migration and memory reclaim may have temporarily unmapped pages associated with this memory range. These pages may show up again only after the process has attempted to reference them. If the memory range represents a shared memory area or file mapping, other processes may currently have additional pages mapped in a corresponding memory range.

file=<filename>
The file backing the memory range. If the file is mapped as private, write accesses may have generated COW (Copy-On-Write) pages in this memory range. These pages are displayed as anonymous pages.

heap
Memory range is used for the heap.

stack
Memory range is used for the stack.

huge
Huge memory range. The page counts shown are huge pages and not regular sized pages.

anon=<pages>
The number of anonymous page in the range.

dirty=<pages>
Number of dirty pages.

mapped=<pages>
Total number of mapped pages, if different from dirty and anon pages.

mapmax=<count>
Maximum mapcount (number of processes mapping a single page) encountered during the scan. This may be used as an indicator of the degree of sharing occurring in a given memory range.

swapcache=<count>
Number of pages that have an associated entry on a swap device.

active=<pages>
The number of pages on the active list. This field is shown only if different from the number of pages in this range. This means that some inactive pages exist in the memory range that may be removed from memory by the swapper soon.

writeback=<pages>
Number of pages that are currently being written out to disk.

STANDARDS

None.

NOTES

The Linux NUMA system calls and /proc interface are available only if the kernel was configured and built with the CONFIG_NUMA option.

Library support

Link with -lnuma to get the system call definitions. libnuma and the required <numaif.h> header are available in the numactl package.

However, applications should not use these system calls directly. Instead, the higher level interface provided by the numa(3) functions in the numactl package is recommended. The numactl package is available at . The package is also included in some Linux distributions. Some distributions include the development library and header in the separate numactl-devel package.

SEE ALSO

get_mempolicy(2), mbind(2), move_pages(2), set_mempolicy(2), numa(3), cpuset(7), numactl(8)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

121 - Linux cli command SET_ROLE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command SET_ROLE and provides detailed information about the command SET_ROLE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the SET_ROLE.

NAME 🖥️ SET_ROLE 🖥️

set the current user identifier of the current session

SYNOPSIS

SET [ SESSION | LOCAL ] ROLE role_name
SET [ SESSION | LOCAL ] ROLE NONE
RESET ROLE

DESCRIPTION

This command sets the current user identifier of the current SQL session to be role_name. The role name can be written as either an identifier or a string literal. After SET ROLE, permissions checking for SQL commands is carried out as though the named role were the one that had logged in originally.

The current session user must have the SET option for the specified role_name, either directly or indirectly via a chain of memberships with the SET option. (If the session user is a superuser, any role can be selected.)

The SESSION and LOCAL modifiers act the same as for the regular SET command.

SET ROLE NONE sets the current user identifier to the current session user identifier, as returned by session_user. RESET ROLE sets the current user identifier to the connection-time setting specified by the command-line options, ALTER ROLE, or ALTER DATABASE, if any such settings exist. Otherwise, RESET ROLE sets the current user identifier to the current session user identifier. These forms can be executed by any user.

NOTES

Using this command, it is possible to either add privileges or restrict ones privileges. If the session user role has been granted memberships WITH INHERIT TRUE, it automatically has all the privileges of every such role. In this case, SET ROLE effectively drops all the privileges except for those which the target role directly possesses or inherits. On the other hand, if the session user role has been granted memberships WITH INHERIT FALSE, the privileges of the granted roles cant be accessed by default. However, if the role was granted WITH SET TRUE, the session user can use SET ROLE to drop the privileges assigned directly to the session user and instead acquire the privileges available to the named role. If the role was granted WITH INHERIT FALSE, SET FALSE then the privileges of that role cannot be exercised either with or without SET ROLE.

Note that when a superuser chooses to SET ROLE to a non-superuser role, they lose their superuser privileges.

SET ROLE has effects comparable to SET SESSION AUTHORIZATION, but the privilege checks involved are quite different. Also, SET SESSION AUTHORIZATION determines which roles are allowable for later SET ROLE commands, whereas changing roles with SET ROLE does not change the set of roles allowed to a later SET ROLE.

SET ROLE does not process session variables as specified by the roles ALTER ROLE settings; this only happens during login.

SET ROLE cannot be used within a SECURITY DEFINER function.

EXAMPLES

SELECT SESSION_USER, CURRENT_USER;

 session_user | current_user
--------------+--------------
 peter        | peter

SET ROLE paul;

SELECT SESSION_USER, CURRENT_USER;

 session_user | current_user
--------------+--------------
 peter        | paul

COMPATIBILITY

PostgreSQL allows identifier syntax ("rolename"), while the SQL standard requires the role name to be written as a string literal. SQL does not allow this command during a transaction; PostgreSQL does not make this restriction because there is no reason to. The SESSION and LOCAL modifiers are a PostgreSQL extension, as is the RESET syntax.

SEE ALSO

SET SESSION AUTHORIZATION (SET_SESSION_AUTHORIZATION(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

122 - Linux cli command EVP_MAC-HMACssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_MAC-HMACssl and provides detailed information about the command EVP_MAC-HMACssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_MAC-HMACssl.

NAME 🖥️ EVP_MAC-HMACssl 🖥️

HMAC - The HMAC EVP_MAC implementation

DESCRIPTION

Support for computing HMAC MACs through the EVP_MAC API.

This implementation uses EVP_MD functions to get access to the underlying digest.

Identity

This implementation is identified with this name and properties, to be used with EVP_MAC_fetch():

“HMAC”, “provider=default” or “provider=fips”

Supported parameters

The general description of these parameters can be found in “PARAMETERS” in EVP_MAC (3).

The following parameter can be set with EVP_MAC_CTX_set_params():

“key” (OSSL_MAC_PARAM_KEY) <octet string>
Sets the MAC key. Setting this parameter is identical to passing a key to EVP_MAC_init (3).

“digest” (OSSL_MAC_PARAM_DIGEST) <UTF8 string>
Sets the name of the underlying digest to be used.

“properties” (OSSL_MAC_PARAM_PROPERTIES) <UTF8 string>
Sets the properties to be queried when trying to fetch the underlying digest. This must be given together with the digest naming parameter (“digest”, or OSSL_MAC_PARAM_DIGEST) to be considered valid.

“digest-noinit” (OSSL_MAC_PARAM_DIGEST_NOINIT) <integer>
A flag to set the MAC digest to not initialise the implementation specific data. The value 0 or 1 is expected.

“digest-oneshot” (OSSL_MAC_PARAM_DIGEST_ONESHOT) <integer>
A flag to set the MAC digest to be a one-shot operation. The value 0 or 1 is expected.

“tls-data-size” (OSSL_MAC_PARAM_TLS_DATA_SIZE) <unsigned integer>

The following parameter can be retrieved with EVP_MAC_CTX_get_params():

“size” (OSSL_MAC_PARAM_SIZE) <unsigned integer>
The “size” parameter can also be retrieved with EVP_MAC_CTX_get_mac_size(). The length of the “size” parameter is equal to that of an unsigned int.

“block-size” (OSSL_MAC_PARAM_BLOCK_SIZE) <unsigned integer>
Gets the MAC block size. The “block-size” parameter can also be retrieved with EVP_MAC_CTX_get_block_size().

SEE ALSO

EVP_MAC_CTX_get_params (3), EVP_MAC_CTX_set_params (3), “PARAMETERS” in EVP_MAC (3), OSSL_PARAM (3), HMAC (3)

COPYRIGHT

Copyright 2018-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

123 - Linux cli command DROP_ROUTINE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_ROUTINE and provides detailed information about the command DROP_ROUTINE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_ROUTINE.

NAME 🖥️ DROP_ROUTINE 🖥️

remove a routine

SYNOPSIS

DROP ROUTINE [ IF EXISTS ] name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ] [, ...]
    [ CASCADE | RESTRICT ]

DESCRIPTION

DROP ROUTINE removes the definition of one or more existing routines. The term “routine” includes aggregate functions, normal functions, and procedures. See under DROP AGGREGATE (DROP_AGGREGATE(7)), DROP FUNCTION (DROP_FUNCTION(7)), and DROP PROCEDURE (DROP_PROCEDURE(7)) for the description of the parameters, more examples, and further details.

NOTES

The lookup rules used by DROP ROUTINE are fundamentally the same as for DROP PROCEDURE; in particular, DROP ROUTINE shares that commands behavior of considering an argument list that has no argmode markers to be possibly using the SQL standards definition that OUT arguments are included in the list. (DROP AGGREGATE and DROP FUNCTION do not do that.)

In some cases where the same name is shared by routines of different kinds, it is possible for DROP ROUTINE to fail with an ambiguity error when a more specific command (DROP FUNCTION, etc.) would work. Specifying the argument type list more carefully will also resolve such problems.

These lookup rules are also used by other commands that act on existing routines, such as ALTER ROUTINE and COMMENT ON ROUTINE.

EXAMPLES

To drop the routine foo for type integer:

DROP ROUTINE foo(integer);

This command will work independent of whether foo is an aggregate, function, or procedure.

COMPATIBILITY

This command conforms to the SQL standard, with these PostgreSQL extensions:

·

The standard only allows one routine to be dropped per command.

·

The IF EXISTS option is an extension.

·

The ability to specify argument modes and names is an extension, and the lookup rules differ when modes are given.

·

User-definable aggregate functions are an extension.

SEE ALSO

DROP AGGREGATE (DROP_AGGREGATE(7)), DROP FUNCTION (DROP_FUNCTION(7)), DROP PROCEDURE (DROP_PROCEDURE(7)), ALTER ROUTINE (ALTER_ROUTINE(7))

Note that there is no CREATE ROUTINE command.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

124 - Linux cli command EVP_KEYMGMT-DHXssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KEYMGMT-DHXssl and provides detailed information about the command EVP_KEYMGMT-DHXssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KEYMGMT-DHXssl.

NAME 🖥️ EVP_KEYMGMT-DHXssl 🖥️

DH, EVP_PKEY-DHX, EVP_KEYMGMT-DH, EVP_KEYMGMT-DHX - EVP_PKEY DH and DHX keytype and algorithm support

DESCRIPTION

For DH FFC key agreement, two classes of domain parameters can be used: “safe” domain parameters that are associated with approved named safe-prime groups, and a class of “FIPS186-type” domain parameters. FIPS186-type domain parameters should only be used for backward compatibility with existing applications that cannot be upgraded to use the approved safe-prime groups.

See EVP_PKEY-FFC (7) for more information about FFC keys.

The DH key type uses PKCS#3 format which saves p and g, but not the q value. The DHX key type uses X9.42 format which saves the value of q and this must be used for FIPS186-4. If key validation is required, users should be aware of the nuances associated with FIPS186-4 style parameters as discussed in “DH key validation”.

DH and DHX domain parameters

In addition to the common FCC parameters that all FFC keytypes should support (see “FFC parameters” in EVP_PKEY-FFC (7)) the DHX and DH keytype implementations support the following:

“group” (OSSL_PKEY_PARAM_GROUP_NAME) <UTF8 string>
Sets or gets a string that associates a DH or DHX named safe prime group with known values for p, q and g. The following values can be used by the OpenSSL’s default and FIPS providers: “ffdhe2048”, “ffdhe3072”, “ffdhe4096”, “ffdhe6144”, “ffdhe8192”, “modp_2048”, “modp_3072”, “modp_4096”, “modp_6144”, “modp_8192”. The following additional values can also be used by OpenSSL’s default provider: “modp_1536”, “dh_1024_160”, “dh_2048_224”, “dh_2048_256”. DH/DHX named groups can be easily validated since the parameters are well known. For protocols that only transfer p and g the value of q can also be retrieved.

DH and DHX additional parameters

“encoded-pub-key” (OSSL_PKEY_PARAM_ENCODED_PUBLIC_KEY) <octet string>
Used for getting and setting the encoding of the DH public key used in a key exchange message for the TLS protocol. See EVP_PKEY_set1_encoded_public_key() and EVP_PKEY_get1_encoded_public_key().

DH additional domain parameters

“safeprime-generator” (OSSL_PKEY_PARAM_DH_GENERATOR) <integer>
Used for DH generation of safe primes using the old safe prime generator code. The default value is 2. It is recommended to use a named safe prime group instead, if domain parameter validation is required. Randomly generated safe primes are not allowed by FIPS, so setting this value for the OpenSSL FIPS provider will instead choose a named safe prime group based on the size of p.

DH and DHX domain parameter / key generation parameters

In addition to the common FFC key generation parameters that all FFC key types should support (see “FFC key generation parameters” in EVP_PKEY-FFC (7)) the DH and DHX keytype implementation supports the following:

“type” (OSSL_PKEY_PARAM_FFC_TYPE) <UTF8 string>
Sets the type of parameter generation. For DH valid values are:

“fips186_4”

“default”

“fips186_2”

These are described in “FFC key generation parameters” in EVP_PKEY-FFC (7)

“group”
This specifies that a named safe prime name will be chosen using the “pbits” type.

“generator”
A safe prime generator. See the “safeprime-generator” type above. This is only valid for DH keys.

“pbits” (OSSL_PKEY_PARAM_FFC_PBITS) <unsigned integer>
Sets the size (in bits) of the prime ‘p’. For “fips186_4” this must be 2048. For “fips186_2” this must be 1024. For “group” this can be any one of 2048, 3072, 4096, 6144 or 8192.

“priv_len” (OSSL_PKEY_PARAM_DH_PRIV_LEN) <integer>
An optional value to set the maximum length of the generated private key. The default value used if this is not set is the maximum value of BN_num_bits(q)). The minimum value that this can be set to is 2 * s. Where s is the security strength of the key which has values of 112, 128, 152, 176 and 200 for key sizes of 2048, 3072, 4096, 6144 and 8192.

DH key validation

For DHX that is not a named group the FIPS186-4 standard specifies that the values used for FFC parameter generation are also required for parameter validation. This means that optional FFC domain parameter values for seed, pcounter and gindex or hindex may need to be stored for validation purposes. For DHX the seed and pcounter can be stored in ASN1 data (but the gindex or hindex cannot be stored). It is recommended to use a named safe prime group instead.

For DH keys, EVP_PKEY_param_check (3) behaves in the following way: The OpenSSL FIPS provider tests if the parameters are either an approved safe prime group OR that the FFC parameters conform to FIPS186-4 as defined in SP800-56Ar3 Assurances of Domain-Parameter Validity. The OpenSSL default provider uses simpler checks that allows there to be no q value for backwards compatibility.

For DH keys, EVP_PKEY_param_check_quick (3) is equivalent to EVP_PKEY_param_check (3).

For DH keys, EVP_PKEY_public_check (3) conforms to SP800-56Ar3 FFC Full Public-Key Validation.

For DH keys, EVP_PKEY_public_check_quick (3) conforms to SP800-56Ar3 FFC Partial Public-Key Validation when the DH key is an approved named safe prime group, otherwise it is the same as EVP_PKEY_public_check (3).

For DH Keys, EVP_PKEY_private_check (3) tests that the private key is in the correct range according to SP800-56Ar3. The OpenSSL FIPS provider requires the value of q to be set (note that this is set for named safe prime groups). For backwards compatibility the OpenSSL default provider only requires p to be set.

For DH keys, EVP_PKEY_pairwise_check (3) conforms to SP800-56Ar3 Owner Assurance of Pair-wise Consistency.

EXAMPLES

An EVP_PKEY context can be obtained by calling:

EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “DH”, NULL);

A DH key can be generated with a named safe prime group by calling:

int priv_len = 2 * 112; OSSL_PARAM params[3]; EVP_PKEY *pkey = NULL; EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “DH”, NULL); params[0] = OSSL_PARAM_construct_utf8_string(“group”, “ffdhe2048”, 0); /* “priv_len” is optional */ params[1] = OSSL_PARAM_construct_int(“priv_len”, &priv_len); params[2] = OSSL_PARAM_construct_end(); EVP_PKEY_keygen_init(pctx); EVP_PKEY_CTX_set_params(pctx, params); EVP_PKEY_generate(pctx, &pkey); … EVP_PKEY_free(pkey); EVP_PKEY_CTX_free(pctx);

DHX domain parameters can be generated according to FIPS186-4 by calling:

int gindex = 2; unsigned int pbits = 2048; unsigned int qbits = 256; OSSL_PARAM params[6]; EVP_PKEY *param_key = NULL; EVP_PKEY_CTX *pctx = NULL; pctx = EVP_PKEY_CTX_new_from_name(NULL, “DHX”, NULL); EVP_PKEY_paramgen_init(pctx); params[0] = OSSL_PARAM_construct_uint(“pbits”, &pbits); params[1] = OSSL_PARAM_construct_uint(“qbits”, &qbits); params[2] = OSSL_PARAM_construct_int(“gindex”, &gindex); params[3] = OSSL_PARAM_construct_utf8_string(“type”, “fips186_4”, 0); params[4] = OSSL_PARAM_construct_utf8_string(“digest”, “SHA256”, 0); params[5] = OSSL_PARAM_construct_end(); EVP_PKEY_CTX_set_params(pctx, params); EVP_PKEY_generate(pctx, &param_key); EVP_PKEY_print_params(bio_out, param_key, 0, NULL); … EVP_PKEY_free(param_key); EVP_PKEY_CTX_free(pctx);

A DH key can be generated using domain parameters by calling:

EVP_PKEY *key = NULL; EVP_PKEY_CTX *gctx = EVP_PKEY_CTX_new_from_pkey(NULL, param_key, NULL); EVP_PKEY_keygen_init(gctx); EVP_PKEY_generate(gctx, &key); EVP_PKEY_print_private(bio_out, key, 0, NULL); … EVP_PKEY_free(key); EVP_PKEY_CTX_free(gctx);

To validate FIPS186-4 DHX domain parameters decoded from PEM or DER data, additional values used during generation may be required to be set into the key.

EVP_PKEY_todata(), OSSL_PARAM_merge(), and EVP_PKEY_fromdata() are useful to add these parameters to the original key or domain parameters before the actual validation. In production code the return values should be checked.

EVP_PKEY *received_domp = …; /* parameters received and decoded */ unsigned char *seed = …; /* and additional parameters received */ size_t seedlen = …; /* by other means, required */ int gindex = …; /* for the validation */ int pcounter = …; int hindex = …; OSSL_PARAM extra_params[4]; OSSL_PARAM *domain_params = NULL; OSSL_PARAM *merged_params = NULL; EVP_PKEY_CTX *ctx = NULL, *validate_ctx = NULL; EVP_PKEY *complete_domp = NULL; EVP_PKEY_todata(received_domp, OSSL_KEYMGMT_SELECT_DOMAIN_PARAMETERS, &domain_params); extra_params[0] = OSSL_PARAM_construct_octet_string(“seed”, seed, seedlen); /* * NOTE: For unverifiable g use “hindex” instead of “gindex” * extra_params[1] = OSSL_PARAM_construct_int(“hindex”, &hindex); */ extra_params[1] = OSSL_PARAM_construct_int(“gindex”, &gindex); extra_params[2] = OSSL_PARAM_construct_int(“pcounter”, &pcounter); extra_params[3] = OSSL_PARAM_construct_end(); merged_params = OSSL_PARAM_merge(domain_params, extra_params); ctx = EVP_PKEY_CTX_new_from_name(NULL, “DHX”, NULL); EVP_PKEY_fromdata_init(ctx); EVP_PKEY_fromdata(ctx, &complete_domp, OSSL_KEYMGMT_SELECT_ALL, merged_params); validate_ctx = EVP_PKEY_CTX_new_from_pkey(NULL, complete_domp, NULL); if (EVP_PKEY_param_check(validate_ctx) > 0) /* validation_passed(); */ else /* validation_failed(); */ OSSL_PARAM_free(domain_params); OSSL_PARAM_free(merged_params); EVP_PKEY_CTX_free(ctx); EVP_PKEY_CTX_free(validate_ctx); EVP_PKEY_free(complete_domp);

CONFORMING TO

RFC 7919 (TLS ffdhe named safe prime groups)

RFC 3526 (IKE modp named safe prime groups)

RFC 5114 (Additional DH named groups for dh_1024_160", “dh_2048_224” and “dh_2048_256”).

The following sections of SP800-56Ar3:

Appendix D: FFC Safe-prime Groups

The following sections of FIPS186-4:

SEE ALSO

EVP_PKEY-FFC (7), EVP_KEYEXCH-DH (7) EVP_PKEY (3), provider-keymgmt (7), EVP_KEYMGMT (3), OSSL_PROVIDER-default (7), OSSL_PROVIDER-FIPS (7)

COPYRIGHT

Copyright 2020-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

125 - Linux cli command ALTER_EVENT_TRIGGER

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_EVENT_TRIGGER and provides detailed information about the command ALTER_EVENT_TRIGGER, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_EVENT_TRIGGER.

NAME 🖥️ ALTER_EVENT_TRIGGER 🖥️

change the definition of an event trigger

SYNOPSIS

ALTER EVENT TRIGGER name DISABLE
ALTER EVENT TRIGGER name ENABLE [ REPLICA | ALWAYS ]
ALTER EVENT TRIGGER name OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }
ALTER EVENT TRIGGER name RENAME TO new_name

DESCRIPTION

ALTER EVENT TRIGGER changes properties of an existing event trigger.

You must be superuser to alter an event trigger.

PARAMETERS

name

The name of an existing trigger to alter.

new_owner

The user name of the new owner of the event trigger.

new_name

The new name of the event trigger.

DISABLE/ENABLE [ REPLICA | ALWAYS ]

These forms configure the firing of event triggers. A disabled trigger is still known to the system, but is not executed when its triggering event occurs. See also session_replication_role.

COMPATIBILITY

There is no ALTER EVENT TRIGGER statement in the SQL standard.

SEE ALSO

CREATE EVENT TRIGGER (CREATE_EVENT_TRIGGER(7)), DROP EVENT TRIGGER (DROP_EVENT_TRIGGER(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

126 - Linux cli command iso-8859-2

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso-8859-2 and provides detailed information about the command iso-8859-2, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso-8859-2.

NAME 🖥️ iso-8859-2 🖥️

2 - ISO/IEC 8859-2 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-2 encodes the Latin characters used in many Central and East European languages.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-2 characters

The following table displays the characters in ISO/IEC 8859-2 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-2 is also known as Latin-2.

SEE ALSO

ascii(7), charsets(7), iso_8859-1(7), iso_8859-16(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

127 - Linux cli command EVP_KDF-ARGON2ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KDF-ARGON2ssl and provides detailed information about the command EVP_KDF-ARGON2ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KDF-ARGON2ssl.

NAME 🖥️ EVP_KDF-ARGON2ssl 🖥️

ARGON2 - The Argon2 EVP KDF implementation

DESCRIPTION

Support for computing the argon2 password-based KDF through the EVP_KDF API.

The EVP_KDF-ARGON2 algorithm implements the Argon2 password-based key derivation function, as described in IETF RFC 9106. It is memory-hard in the sense that it deliberately requires a significant amount of RAM for efficient computation. The intention of this is to render brute forcing of passwords on systems that lack large amounts of main memory (such as GPUs or ASICs) computationally infeasible.

Argon2d (Argon2i) uses data-dependent (data-independent) memory access and primary seek to address trade-off (side-channel) attacks.

Argon2id is a hybrid construction which, in the first two slices of the first pass, generates reference addresses data-independently as in Argon2i, whereas in later slices and next passes it generates them data-dependently as in Argon2d.

Sbox-hardened version Argon2ds is not supported.

For more information, please refer to RFC 9106.

Supported parameters

The supported parameters are:

“pass” (OSSL_KDF_PARAM_PASSWORD) <octet string>

“salt” (OSSL_KDF_PARAM_SALT) <octet string>

“secret” (OSSL_KDF_PARAM_SECRET) <octet string>

“iter” (OSSL_KDF_PARAM_ITER) <unsigned integer>

“size” (OSSL_KDF_PARAM_SIZE) <unsigned integer>

These parameters work as described in “PARAMETERS” in EVP_KDF (3). Note that RFC 9106 recommends 128 bits salt for most applications, or 64 bits salt in the case of space constraints. At least 128 bits output length is recommended. Note that secret (or pepper) is an optional secret data used along the password.

“threads” (OSSL_KDF_PARAM_THREADS) <unsigned integer>
The number of threads, bounded above by the number of lanes. This can only be used with built-in thread support. Threading must be explicitly enabled. See EXAMPLES section for more information.

“ad” (OSSL_KDF_PARAM_ARGON2_AD) <octet string>
Optional associated data, may be used to “tag” a group of keys, or tie them to a particular public key, without having to modify salt.

“lanes” (OSSL_KDF_PARAM_ARGON2_LANES) <unsigned integer>
Argon2 splits the requested memory size into lanes, each of which is designed to be processed in parallel. For example, on a system with p cores, it’s recommended to use p lanes. The number of lanes is used to derive the key. It is possible to specify more lanes than the number of available computational threads. This is especially encouraged if multi-threading is disabled.

“memcost” (OSSL_KDF_PARAM_ARGON2_MEMCOST) <unsigned integer>
Memory cost parameter (the number of 1k memory blocks used).

“version” (OSSL_KDF_PARAM_ARGON2_VERSION) <unsigned integer>
Argon2 version. Supported values: 0x10, 0x13 (default).

“early_clean” (OSSL_KDF_PARAM_EARLY_CLEAN) <unsigned integer>
If set (nonzero), password and secret stored in Argon2 context are zeroed early during initial hash computation, as soon as they are not needed. Otherwise, they are zeroed along the rest of Argon2 context data on clear, free, reset. This can be useful if, for example, multiple keys with different ad value are to be generated from a single password and secret.

EXAMPLES

This example uses Argon2d with password “1234567890”, salt “saltsalt”, using 2 lanes, 2 threads, and memory cost of 65536:

#include <string.h> /* strlen */ #include <openssl/core_names.h> /* OSSL_KDF_* */ #include <openssl/params.h> /* OSSL_PARAM_* */ #include <openssl/thread.h> /* OSSL_set_max_threads */ #include <openssl/kdf.h> /* EVP_KDF_* */ int main(void) { int retval = 1; EVP_KDF *kdf = NULL; EVP_KDF_CTX *kctx = NULL; OSSL_PARAM params[6], *p = params; /* argon2 params, please refer to RFC9106 for recommended defaults */ uint32_t lanes = 2, threads = 2, memcost = 65536; char pwd[] = “1234567890”, salt[] = “saltsalt”; /* derive result */ size_t outlen = 128; unsigned char result[outlen]; /* required if threads > 1 */ if (OSSL_set_max_threads(NULL, threads) != 1) goto fail; p = params; *p++ = OSSL_PARAM_construct_uint32(OSSL_KDF_PARAM_THREADS, &threads); *p++ = OSSL_PARAM_construct_uint32(OSSL_KDF_PARAM_ARGON2_LANES, &lanes); *p++ = OSSL_PARAM_construct_uint32(OSSL_KDF_PARAM_ARGON2_MEMCOST, &memcost); *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_SALT, salt, strlen((const char *)salt)); *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_PASSWORD, pwd, strlen((const char *)pwd)); *p++ = OSSL_PARAM_construct_end(); if ((kdf = EVP_KDF_fetch(NULL, “ARGON2D”, NULL)) == NULL) goto fail; if ((kctx = EVP_KDF_CTX_new(kdf)) == NULL) goto fail; if (EVP_KDF_derive(kctx, &result[0], outlen, params) != 1) goto fail; printf(“Output = %s “, OPENSSL_buf2hexstr(result, outlen)); retval = 0; fail: EVP_KDF_free(kdf); EVP_KDF_CTX_free(kctx); OSSL_set_max_threads(NULL, 0); return retval; }

NOTES

“ARGON2I”, “ARGON2D”, and “ARGON2ID” are the names for this implementation; it can be used with the EVP_KDF_fetch() function.

CONFORMING TO

RFC 9106 Argon2, see <https://www.rfc-editor.org/rfc/rfc9106.txt>.

SEE ALSO

EVP_KDF (3), EVP_KDF_CTX_new (3), EVP_KDF_CTX_free (3), EVP_KDF_CTX_set_params (3), EVP_KDF_derive (3), “PARAMETERS” in EVP_KDF (3)

HISTORY

This functionality was added to OpenSSL 3.2.

COPYRIGHT

Copyright 2022-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

128 - Linux cli command precedence

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command precedence and provides detailed information about the command precedence, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the precedence.

NAME 🖥️ precedence 🖥️

C operator precedence and order of evaluation

DESCRIPTION

This manual page lists C operators and their precedence in evaluation.

OperatorAssociativityNotes
[] () . -> ++ --left to right[1]
++ -- & * + - ~ ! sizeofright to left[2]
(type)right to left
* / %left to right
+ -left to right
<< >>left to right
< > <= >=left to right
== !=left to right
&left to right
^left to right
|left to right
&&left to right
||left to right
?:right to left
= *= /= %= += -= <<= >>= &= ^= |=right to left
,left to right

The following notes provide further information to the above table:

[1]
The ++ and – operators at this precedence level are the postfix flavors of the operators.

[2]
The ++ and – operators at this precedence level are the prefix flavors of the operators.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

129 - Linux cli command sslssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command sslssl and provides detailed information about the command sslssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the sslssl.

NAME 🖥️ sslssl 🖥️

guide-libssl-introduction, ssl - OpenSSL Guide: An introduction to libssl

INTRODUCTION

The OpenSSL libssl library provides implementations of several secure network communications protocols. Specifically it provides SSL/TLS (SSLv3, TLSv1, TLSv1.1, TLSv1.2 and TLSv1.3), DTLS (DTLSv1 and DTLSv1.2) and QUIC (client side only). The library depends on libcrypto for its underlying cryptographic operations (see ossl-guide-libcrypto-introduction (7)).

The set of APIs supplied by libssl is common across all of these different network protocols, so a developer familiar with writing applications using one of these protocols should be able to transition to using another with relative ease.

An application written to use libssl will include the <openssl/ssl.h> header file and will typically use two main data structures, i.e. SSL and SSL_CTX.

An SSL object is used to represent a connection to a remote peer. Once a connection with a remote peer has been established data can be exchanged with that peer.

When using DTLS any data that is exchanged uses “datagram” semantics, i.e. the packets of data can be delivered in any order, and they are not guaranteed to arrive at all. In this case the SSL object used for the connection is also used for exchanging data with the peer.

Both TLS and QUIC support the concept of a “stream” of data. Data sent via a stream is guaranteed to be delivered in order without any data loss. A stream can be uni- or bi-directional.

SSL/TLS only supports one stream of data per connection and it is always bi-directional. In this case the SSL object used for the connection also represents that stream. See ossl-guide-tls-introduction (7) for more information.

The QUIC protocol can support multiple streams per connection and they can be uni- or bi-directional. In this case an SSL object can represent the underlying connection, or a stream, or both. Where multiple streams are in use a separate SSL object is used for each one. See ossl-guide-quic-introduction (7) for more information.

An SSL_CTX object is used to create the SSL object for the underlying connection. A single SSL_CTX object can be used to create many connections (each represented by a separate SSL object). Many API functions in libssl exist in two forms: one that takes an SSL_CTX and one that takes an SSL. Typically settings that you apply to the SSL_CTX will then be inherited by any SSL object that you create from it. Alternatively you can apply settings directly to the SSL object without affecting other SSL objects. Note that you should not normally make changes to an SSL_CTX after the first SSL object has been created from it.

DATA STRUCTURES

As well as SSL_CTX and SSL there are a number of other data structures that an application may need to use. They are summarised below.

SSL_METHOD (SSL Method)
This structure is used to indicate the kind of connection you want to make, e.g. whether it is to represent the client or the server, and whether it is to use SSL/TLS, DTLS or QUIC (client only). It is passed as a parameter when creating the SSL_CTX.

SSL_SESSION (SSL Session)
After establishing a connection with a peer the agreed cryptographic material can be reused to create future connections with the same peer more rapidly. The set of data used for such a future connection establishment attempt is collected together into an SSL_SESSION object. A single successful connection with a peer may generate zero or more such SSL_SESSION objects for use in future connection attempts.

SSL_CIPHER (SSL Cipher)
During connection establishment the client and server agree upon cryptographic algorithms they are going to use for encryption and other uses. A single set of cryptographic algorithms that are to be used together is known as a ciphersuite. Such a set is represented by an SSL_CIPHER object. The set of available ciphersuites that can be used are configured in the SSL_CTX or SSL.

FURTHER READING

See ossl-guide-tls-introduction (7) for an introduction to the SSL/TLS protocol and ossl-guide-quic-introduction (7) for an introduction to QUIC.

See ossl-guide-libcrypto-introduction (7) for an introduction to libcrypto.

SEE ALSO

ossl-guide-libcrypto-introduction (7), ossl-guide-tls-introduction (7), ossl-guide-quic-introduction (7)

COPYRIGHT

Copyright 2000-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

130 - Linux cli command latin4

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command latin4 and provides detailed information about the command latin4, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the latin4.

NAME 🖥️ latin4 🖥️

4 - ISO/IEC 8859-4 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-4 encodes the characters used in Scandinavian and Baltic languages.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-4 characters

The following table displays the characters in ISO/IEC 8859-4 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-4 is also known as Latin-4.

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

131 - Linux cli command ANALYZE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ANALYZE and provides detailed information about the command ANALYZE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ANALYZE.

NAME 🖥️ ANALYZE 🖥️

collect statistics about a database

SYNOPSIS

ANALYZE [ ( option [, ...] ) ] [ table_and_columns [, ...] ]
ANALYZE [ VERBOSE ] [ table_and_columns [, ...] ]

where option can be one of:

    VERBOSE [ boolean ]
    SKIP_LOCKED [ boolean ]
    BUFFER_USAGE_LIMIT size

and table_and_columns is:

    table_name [ ( column_name [, ...] ) ]

DESCRIPTION

ANALYZE collects statistics about the contents of tables in the database, and stores the results in the pg_statistic system catalog. Subsequently, the query planner uses these statistics to help determine the most efficient execution plans for queries.

Without a table_and_columns list, ANALYZE processes every table and materialized view in the current database that the current user has permission to analyze. With a list, ANALYZE processes only those table(s). It is further possible to give a list of column names for a table, in which case only the statistics for those columns are collected.

When the option list is surrounded by parentheses, the options can be written in any order. The parenthesized syntax was added in PostgreSQL 11; the unparenthesized syntax is deprecated.

PARAMETERS

VERBOSE

Enables display of progress messages.

SKIP_LOCKED

Specifies that ANALYZE should not wait for any conflicting locks to be released when beginning work on a relation: if a relation cannot be locked immediately without waiting, the relation is skipped. Note that even with this option, ANALYZE may still block when opening the relations indexes or when acquiring sample rows from partitions, table inheritance children, and some types of foreign tables. Also, while ANALYZE ordinarily processes all partitions of specified partitioned tables, this option will cause ANALYZE to skip all partitions if there is a conflicting lock on the partitioned table.

BUFFER_USAGE_LIMIT

Specifies the Buffer Access Strategy ring buffer size for ANALYZE. This size is used to calculate the number of shared buffers which will be reused as part of this strategy. 0 disables use of a Buffer Access Strategy. When this option is not specified, ANALYZE uses the value from vacuum_buffer_usage_limit. Higher settings can allow ANALYZE to run more quickly, but having too large a setting may cause too many other useful pages to be evicted from shared buffers. The minimum value is 128 kB and the maximum value is 16 GB.

boolean

Specifies whether the selected option should be turned on or off. You can write TRUE, ON, or 1 to enable the option, and FALSE, OFF, or 0 to disable it. The boolean value can also be omitted, in which case TRUE is assumed.

size

Specifies an amount of memory in kilobytes. Sizes may also be specified as a string containing the numerical size followed by any one of the following memory units: B (bytes), kB (kilobytes), MB (megabytes), GB (gigabytes), or TB (terabytes).

table_name

The name (possibly schema-qualified) of a specific table to analyze. If omitted, all regular tables, partitioned tables, and materialized views in the current database are analyzed (but not foreign tables). If the specified table is a partitioned table, both the inheritance statistics of the partitioned table as a whole and statistics of the individual partitions are updated.

column_name

The name of a specific column to analyze. Defaults to all columns.

OUTPUTS

When VERBOSE is specified, ANALYZE emits progress messages to indicate which table is currently being processed. Various statistics about the tables are printed as well.

NOTES

To analyze a table, one must ordinarily be the tables owner or a superuser. However, database owners are allowed to analyze all tables in their databases, except shared catalogs. (The restriction for shared catalogs means that a true database-wide ANALYZE can only be performed by a superuser.) ANALYZE will skip over any tables that the calling user does not have permission to analyze.

Foreign tables are analyzed only when explicitly selected. Not all foreign data wrappers support ANALYZE. If the tables wrapper does not support ANALYZE, the command prints a warning and does nothing.

In the default PostgreSQL configuration, the autovacuum daemon (see Section 25.1.6) takes care of automatic analyzing of tables when they are first loaded with data, and as they change throughout regular operation. When autovacuum is disabled, it is a good idea to run ANALYZE periodically, or just after making major changes in the contents of a table. Accurate statistics will help the planner to choose the most appropriate query plan, and thereby improve the speed of query processing. A common strategy for read-mostly databases is to run VACUUM and ANALYZE once a day during a low-usage time of day. (This will not be sufficient if there is heavy update activity.)

ANALYZE requires only a read lock on the target table, so it can run in parallel with other activity on the table.

The statistics collected by ANALYZE usually include a list of some of the most common values in each column and a histogram showing the approximate data distribution in each column. One or both of these can be omitted if ANALYZE deems them uninteresting (for example, in a unique-key column, there are no common values) or if the column data type does not support the appropriate operators. There is more information about the statistics in Chapter 25.

For large tables, ANALYZE takes a random sample of the table contents, rather than examining every row. This allows even very large tables to be analyzed in a small amount of time. Note, however, that the statistics are only approximate, and will change slightly each time ANALYZE is run, even if the actual table contents did not change. This might result in small changes in the planners estimated costs shown by EXPLAIN. In rare situations, this non-determinism will cause the planners choices of query plans to change after ANALYZE is run. To avoid this, raise the amount of statistics collected by ANALYZE, as described below.

The extent of analysis can be controlled by adjusting the default_statistics_target configuration variable, or on a column-by-column basis by setting the per-column statistics target with ALTER TABLE … ALTER COLUMN … SET STATISTICS. The target value sets the maximum number of entries in the most-common-value list and the maximum number of bins in the histogram. The default target value is 100, but this can be adjusted up or down to trade off accuracy of planner estimates against the time taken for ANALYZE and the amount of space occupied in pg_statistic. In particular, setting the statistics target to zero disables collection of statistics for that column. It might be useful to do that for columns that are never used as part of the WHERE, GROUP BY, or ORDER BY clauses of queries, since the planner will have no use for statistics on such columns.

The largest statistics target among the columns being analyzed determines the number of table rows sampled to prepare the statistics. Increasing the target causes a proportional increase in the time and space needed to do ANALYZE.

One of the values estimated by ANALYZE is the number of distinct values that appear in each column. Because only a subset of the rows are examined, this estimate can sometimes be quite inaccurate, even with the largest possible statistics target. If this inaccuracy leads to bad query plans, a more accurate value can be determined manually and then installed with ALTER TABLE … ALTER COLUMN … SET (n_distinct = …).

If the table being analyzed has inheritance children, ANALYZE gathers two sets of statistics: one on the rows of the parent table only, and a second including rows of both the parent table and all of its children. This second set of statistics is needed when planning queries that process the inheritance tree as a whole. The child tables themselves are not individually analyzed in this case. The autovacuum daemon, however, will only consider inserts or updates on the parent table itself when deciding whether to trigger an automatic analyze for that table. If that table is rarely inserted into or updated, the inheritance statistics will not be up to date unless you run ANALYZE manually.

For partitioned tables, ANALYZE gathers statistics by sampling rows from all partitions; in addition, it will recurse into each partition and update its statistics. Each leaf partition is analyzed only once, even with multi-level partitioning. No statistics are collected for only the parent table (without data from its partitions), because with partitioning its guaranteed to be empty.

The autovacuum daemon does not process partitioned tables, nor does it process inheritance parents if only the children are ever modified. It is usually necessary to periodically run a manual ANALYZE to keep the statistics of the table hierarchy up to date.

If any child tables or partitions are foreign tables whose foreign data wrappers do not support ANALYZE, those tables are ignored while gathering inheritance statistics.

If the table being analyzed is completely empty, ANALYZE will not record new statistics for that table. Any existing statistics will be retained.

Each backend running ANALYZE will report its progress in the pg_stat_progress_analyze view. See Section 28.4.1 for details.

COMPATIBILITY

There is no ANALYZE statement in the SQL standard.

SEE ALSO

VACUUM(7), vacuumdb(1), Section 20.4.4, Section 25.1.6, Section 28.4.1

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

132 - Linux cli command graphviz

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command graphviz and provides detailed information about the command graphviz, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the graphviz.

NAME 🖥️ graphviz 🖥️

rich set of graph drawing tools

SYNOPSIS

This manpage has been written to fulfil the need of a centralized documentation presenting all available tools in the graphviz package.

AVAILABLE TOOLS

Graph layout programs

dot
filter for hierarchical layouts of graphs

neato
filter for symmetric layouts of graphs

twopi
filter for radial layouts of graphs

circo
filter for circular layout of graphs

fdp
filter for symmetric layouts of graphs

All of the filters work with either directed or undirected graphs, though dot is typically used for directed graphs and neato for undirected graphs. Note also that neato -n[2] can be used to render layouts produced by the other filters.

Graph drawing programs

lefty
A Programmable Graphics Editor

lneato
lefty + neato

dotty
lefty + dot

Graph layout enhancement

gvcolor
flow colors through a ranked digraph

unflatten
adjust directed graphs to improve layout aspect ratio

gvpack
merge and pack disjoint graphs

Graph information and transformation

gc
count graph components

acyclic
make directed graph acyclic

nop
pretty-print graph file

ccomps
connected components filter for graphs

sccmap
extract strongly connected components of directed graphs

tred
transitive reduction filter for directed graphs

dijkstra
single-source distance filter

bcomps
biconnected components filter for graphs

gvpr
graph pattern scanning and processing language

prune
prune directed graphs

Other

gxl2dot, dot2gxl
GXL-DOT converters

AUTHOR

This manual page was written by Cyril Brulebois <[email protected]> in november 2006, based on an initial documentation effort by Joachim Berdal Haga <[email protected]>. It can be distributed under the same terms as the graphviz package.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

133 - Linux cli command mawk-arrays

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command mawk-arrays and provides detailed information about the command mawk-arrays, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the mawk-arrays.

NAME 🖥️ mawk-arrays 🖥️

arrays - design notes for mawk’s array implementation

SYNOPSIS

This is the documentation for the mawk implementation of awk arrays. Arrays in awk are associations of strings to awk scalar values. The mawk implementation stores the associations in hash tables. The hash table scheme was influenced by and is similar to the design presented in Griswold and Townsend, The Design and Implementation of Dynamic Hashing Sets and Tables in Icon, Software Practice and Experience, 23, 351-367, 1993.

DATA STRUCTURES

Array Structure

The type ARRAY is a pointer to a struct array. The size field is the number of elements in the table. The meaning of the other fields depends on the type field.

There are three types of arrays and these are distinguished by the type field in the structure. The types are:

AY_NULL
The array is empty and the size field is always zero. The other fields have no meaning.

AY_SPLIT
The array was created by the AWK built-in split. The return value from split is stored in the size field. The ptr field points at a vector of CELLs. The number of CELLs is the limit field. It is always true that size ≤ limit. The address of A[i] is (CELL*)A->ptr+i-1 for 1≤ i ≤ size. The hmask field has no meaning.

Hash Table
The array is a hash table. If the AY_STR bit in the type field is set, then the table is keyed on strings. If the AY_INT bit in the type field is set, then the table is keyed on integers. Both bits can be set, and then the two keys are consistent, i.e., look up of A[-14] and A["-14"] will return identical CELL pointers although the look up methods will be different. In this case, the size field is the number of hash nodes in the table. When insertion of a new element would cause size to exceed limit, the table grows by doubling the number of hash chains. The invariant, (hmask+1)max_ave_list_length=limit is always true. Max_ave_list_length is a tunable constant.

Hash Tables

The hash tables are linked lists of nodes, called ANODEs. The number of lists is hmask+1 which is always a power of two. The ptr field points at a vector of list heads. Since there are potentially two types of lists, integer lists and strings lists, each list head is a structure, DUAL_LINK.

The string lists are chains connected by slinks and the integer lists are chains connected by ilinks. We sometimes refer to these lists as slists and ilists, respectively. The elements on the lists are ANODEs. The fields of an ANODE are:

slink The link field for slists. ilink The link field for ilists. sval If non-null, then sval is a pointer to a string key. For a given table, if the AY_STR bit is set then every ANODE has a non-null sval field and conversely, if AY_STR is not set, then every sval field is null.

hval The hash value of sval. This field has no meaning if sval is null.

ival The integer key. The field has no meaning if set to the constant, NOT_AN_IVALUE. If the AY_STR bit is off, then every ANODE will have a valid ival field. If the AY_STR bit is on, then the ival field may or may not be valid.

cell The data field in the hash table. dhitems

So the value of A[expr is stored in the cell field, and if expr is an integer, then expr is stored in ival, else it is stored in sval.

ARRAY OPERATIONS

The functions that operate on arrays are,

CELL* array_find(ARRAY A, CELL *cp, int create_flag)
returns a pointer to A[expr] where cp is a pointer to the CELL holding expr. If the create_flag is on and expr is not an element of A, then the element is created with value null.

void array_delete(ARRAY A, CELL *cp)
removes an element A[expr from the array A. cp points at the CELL holding expr.

void array_load(ARRAY A, size_t cnt)
builds a split array. The values A[1..cnt] are moved into A from an anonymous buffer with transfer_to_array() which is declared in split.h.

void array_clear(ARRAY A) removes all elements of A.
The type of A is then AY_NULL.

STRING** array_loop_vector(ARRAY A, size_t *sizep)
returns a pointer to a linear vector that holds all the strings that are indices of A. The size of the the vector is returned indirectly in *sizep. If A->size≡0, a null pointer is returned.

CELL* array_cat(CELL *sp, int cnt)
concatenates the elements of sp[1-cnt..0], with each element separated by SUBSEP, to compute an array index. For example, on a reference to A[i,j], array_cat computes i ○ SUBSEP ○ j where ○ denotes concatenation.

Array Find

Any reference to A[expr] creates a call to array_find(A,cp,CREATE) where cp points at the cell holding expr. The test, expr in A, creates a call to array_find(A,cp,NO_CREATE).

Array_find is a hash-table lookup function that handles two cases:

1.
If *cp is numeric and integer valued, then lookup by integer value using find_by_ival. If *cp is numeric, but not integer valued, then convert to string with sprintf(CONVFMT,…) and go to case~2.

2.
If *cp is string valued, then lookup by string value using find_by_sval. dlist

To test whether cp->dval is integer, we convert to the nearest integer by rounding towards zero (done by do_to_I) and then cast back to double. If we get the same number we started with, then cp->dval is integer valued.

When we get to the function find_by_ival, the search has been reduced to lookup in a hash table by integer value.

When a search by integer value fails, we have to check by string value to correctly handle the case insertion by A[“123”] and later search as A[123]. This string search is necessary if and only if the AY_STR bit is set. An important point is that all ANODEs get created with a valid sval if AY_STR is set, because then creation of new nodes always occurs in a call to find_by_sval.

Searching by string value is easier because AWK arrays are really string associations. If the array does not have the AY_STR bit set, then we have to convert the array to a dual hash table with strings which is done by the function add_string_associations.

One Int value is reserved to show that the ival field is invalid. This works because d_to_I returns a value in [-Max_Int, Max_Int].

On entry to add_string_associations, we know that the AY_STR bit is not set. We convert to a dual hash table, then walk all the integer lists and put each ANODE on a string list.

Array Delete

The execution of the statement, delete A[expr], creates a call to array_delete(ARRAY A, CELL *cp). Depending on the type of *cp, the call is routed to find_by_sval or find_by_ival. Each of these functions leaves its return value on the front of an slist or ilist, respectively, and then it is deleted from the front of the list. The case where A[expr is on two lists, e.g., A[12] and A[“12”] is checked by examining the sval and ival fields of the returned ANODE*.

Even though we found a node by searching an ilist it might also be on an slist and vice-versa.

When the size of a hash table drops below a certain value, it might be profitable to shrink the hash table. Currently we don’t do this, because our guess is that it would be a waste of time for most AWK applications. However, we do convert an array to AY_NULL when the size goes to zero which would resize a large hash table that had been completely cleared by successive deletions.

Building an Array with Split

A simple operation is to create an array with the AWK primitive split. The code that performs split puts the pieces in an anonymous buffer. array_load(A, cnt) moves the cnt elements from the anonymous buffer into A. This is the only way an array of type AY_SPLIT is created.

If the array A is a split array and big enough then we reuse it, otherwise we need to allocate a new split array. When we allocate a block of CELLs for a split array, we round up to a multiple of 4.

Array Clear

The function array_clear(ARRAY A) converts A to type AY_NULL and frees all storage used by A except for the struct array itself. This function gets called in three contexts:

(1)
when an array local to a user function goes out of scope,

(2)
execution of the AWK statement, delete A and

(3)
when an existing changes type or size from split().

Constructor and Conversions

Arrays are always created as empty arrays of type AY_NULL*.* Global arrays are never destroyed although they can go empty or have their type change by conversion. The only constructor function is a macro.

Hash tables only get constructed by conversion. This happens in two ways. The function make_empty_table converts an empty array of type AY_NULL to an empty hash table. The number of lists in the table is a power of 2 determined by the constant STARTING_HMASK. The limit size of the table is determined by the constant MAX_AVE_LIST_LENGTH which is the largest average size of the hash lists that we are willing to tolerate before enlarging the table. When A->size exceeds A->limit, the hash table grows in size by doubling the number of lists. A->limit is then reset to MAX_AVE_LIST_LENGTH times A->hmask+1.

The other way a hash table gets constructed is when a split array is converted to a hash table of type AY_INT*.*

To determine the size of the table, we set the initial size to STARTING_HMASK+1 and then double the size until A->size ≤ A->limit.

Doubling the Size of a Hash Table

The whole point of making the table size a power of two is to facilitate resizing the table. If the table size is 2**(n) and h is the hash key, then h mod 2**(n) is the hash chain index which can be calculated with bit-wise and, h & (2**(n-1)). When the table size doubles, the new bit-mask has one more bit turned on. Elements of an old hash chain whose hash value have this bit turned on get moved to a new chain. Elements with this bit turned off stay on the same chain. On average only half the old chain moves to the new chain. If the old chain is at table[i], 0 ≤ i < 2**(n), then the elements that move, all move to the new chain at table[i + 2**(n)].

As we walk an old string list with pointer p, the expression p->hval & new_hmask takes one of two values. If it is equal to p->hval & old_hmask (which equals i), then the node stays otherwise it gets moved to a new string list at j. The new string list preserves order so that the positions of the move-to-the-front heuristic are preserved. Nodes moving to the new list are appended at pointer tail. The ANODEs, dummy0~and dummy1, are sentinels that remove special handling of boundary conditions.

The doubling of the integer lists is exactly the same except that slink is replaced by ilink and hval is replaced by ival.

Array Loops

Our mechanism for dealing with execution of the statement,

for (i in A) { statements }

is simple. We allocate a vector of STRING* of size, A->size. Each element of the vector is a string key for~A. Note that if the AY_STR bit of A is not set, then A has to be converted to a string hash table, because the index i walks string indices.

To execute the loop, the only state that needs to be saved is the address of i and an index into the vector of string keys. Since nothing about A is saved as state, the user program can do anything to A inside the body of the loop, even delete A, and the loop still works. Essentially, we have traded data space (the string vector) in exchange for implementation simplicity. On a 32-bit system, each ANODE is 36 bytes, so the extra memory needed for the array loop is 11 more than the memory consumed by the ANODEs of the array. Note that the large size of the ANODEs is indicative of our whole design which pays data space for integer lookup speed and algorithm simplicity.

The only aspect of array loops that occurs in array.c is construction of the string vector. The rest of the implementation is in the file execute.c.

As we walk over the hash table ANODEs, putting each sval in ret, we need to increment each reference count. The user of the return value is responsible for these new reference counts.

Concatenating Array Indices

In AWK, an array expression A[i,j] is equivalent to the expression A[i SUBSEP j], i.e., the index is the concatenation of the three elements i, SUBSEP and j. This is performed by the function array_cat. On entry, sp points at the top of a stack of CELLs. Cnt cells are popped off the stack and concatenated together separated by SUBSEP and the result is pushed back on the stack. On entry, the first multi-index is in sp[1-cnt] and the last is in sp[0]. The return value is the new stack top. (The stack is the run-time evaluation stack. This operation really has nothing to do with array structure, so logically this code belongs in execute.c, but remains here for historical reasons.)

We make a copy of SUBSEP which we can cast to string in the unlikely event the user has assigned a number to SUBSEP.

Set sp and top so the cells to concatenate are inclusively between sp and top.

The total_len is the sum of the lengths of the cnt strings and the cnt-1 copies of subsep.

The return value is sp and it is already set correctly. We just need to free the strings and set the contents of sp.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

134 - Linux cli command DROP_DATABASE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_DATABASE and provides detailed information about the command DROP_DATABASE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_DATABASE.

NAME 🖥️ DROP_DATABASE 🖥️

remove a database

SYNOPSIS

DROP DATABASE [ IF EXISTS ] name [ [ WITH ] ( option [, ...] ) ]

where option can be:

    FORCE

DESCRIPTION

DROP DATABASE drops a database. It removes the catalog entries for the database and deletes the directory containing the data. It can only be executed by the database owner. It cannot be executed while you are connected to the target database. (Connect to postgres or any other database to issue this command.) Also, if anyone else is connected to the target database, this command will fail unless you use the FORCE option described below.

DROP DATABASE cannot be undone. Use it with care!

PARAMETERS

IF EXISTS

Do not throw an error if the database does not exist. A notice is issued in this case.

name

The name of the database to remove.

FORCE

Attempt to terminate all existing connections to the target database. It doesnt terminate if prepared transactions, active logical replication slots or subscriptions are present in the target database.

This terminates background worker connections and connections that the current user has permission to terminate with pg_terminate_backend, described in Section 9.27.2. If connections would remain, this command will fail.

NOTES

DROP DATABASE cannot be executed inside a transaction block.

This command cannot be executed while connected to the target database. Thus, it might be more convenient to use the program dropdb(1) instead, which is a wrapper around this command.

COMPATIBILITY

There is no DROP DATABASE statement in the SQL standard.

SEE ALSO

CREATE DATABASE (CREATE_DATABASE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

135 - Linux cli command DROP_SUBSCRIPTION

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_SUBSCRIPTION and provides detailed information about the command DROP_SUBSCRIPTION, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_SUBSCRIPTION.

NAME 🖥️ DROP_SUBSCRIPTION 🖥️

remove a subscription

SYNOPSIS

DROP SUBSCRIPTION [ IF EXISTS ] name [ CASCADE | RESTRICT ]

DESCRIPTION

DROP SUBSCRIPTION removes a subscription from the database cluster.

To execute this command the user must be the owner of the subscription.

DROP SUBSCRIPTION cannot be executed inside a transaction block if the subscription is associated with a replication slot. (You can use ALTER SUBSCRIPTION to unset the slot.)

PARAMETERS

name

The name of a subscription to be dropped.

CASCADE
RESTRICT

These key words do not have any effect, since there are no dependencies on subscriptions.

NOTES

When dropping a subscription that is associated with a replication slot on the remote host (the normal state), DROP SUBSCRIPTION will connect to the remote host and try to drop the replication slot (and any remaining table synchronization slots) as part of its operation. This is necessary so that the resources allocated for the subscription on the remote host are released. If this fails, either because the remote host is not reachable or because the remote replication slot cannot be dropped or does not exist or never existed, the DROP SUBSCRIPTION command will fail. To proceed in this situation, first disable the subscription by executing ALTER SUBSCRIPTION … DISABLE, and then disassociate it from the replication slot by executing ALTER SUBSCRIPTION … SET (slot_name = NONE). After that, DROP SUBSCRIPTION will no longer attempt any actions on a remote host. Note that if the remote replication slot still exists, it (and any related table synchronization slots) should then be dropped manually; otherwise it/they will continue to reserve WAL and might eventually cause the disk to fill up. See also Section 31.2.1.

If a subscription is associated with a replication slot, then DROP SUBSCRIPTION cannot be executed inside a transaction block.

EXAMPLES

Drop a subscription:

DROP SUBSCRIPTION mysub;

COMPATIBILITY

DROP SUBSCRIPTION is a PostgreSQL extension.

SEE ALSO

CREATE SUBSCRIPTION (CREATE_SUBSCRIPTION(7)), ALTER SUBSCRIPTION (ALTER_SUBSCRIPTION(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

136 - Linux cli command DROP_SEQUENCE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_SEQUENCE and provides detailed information about the command DROP_SEQUENCE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_SEQUENCE.

NAME 🖥️ DROP_SEQUENCE 🖥️

remove a sequence

SYNOPSIS

DROP SEQUENCE [ IF EXISTS ] name [, ...] [ CASCADE | RESTRICT ]

DESCRIPTION

DROP SEQUENCE removes sequence number generators. A sequence can only be dropped by its owner or a superuser.

PARAMETERS

IF EXISTS

Do not throw an error if the sequence does not exist. A notice is issued in this case.

name

The name (optionally schema-qualified) of a sequence.

CASCADE

Automatically drop objects that depend on the sequence, and in turn all objects that depend on those objects (see Section 5.14).

RESTRICT

Refuse to drop the sequence if any objects depend on it. This is the default.

EXAMPLES

To remove the sequence serial:

DROP SEQUENCE serial;

COMPATIBILITY

DROP SEQUENCE conforms to the SQL standard, except that the standard only allows one sequence to be dropped per command, and apart from the IF EXISTS option, which is a PostgreSQL extension.

SEE ALSO

CREATE SEQUENCE (CREATE_SEQUENCE(7)), ALTER SEQUENCE (ALTER_SEQUENCE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

137 - Linux cli command keyrings

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command keyrings and provides detailed information about the command keyrings, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the keyrings.

NAME 🖥️ keyrings 🖥️

in-kernel key management and retention facility

DESCRIPTION

The Linux key-management facility is primarily a way for various kernel components to retain or cache security data, authentication keys, encryption keys, and other data in the kernel.

System call interfaces are provided so that user-space programs can manage those objects and also use the facility for their own purposes; see add_key(2), request_key(2), and keyctl(2).

A library and some user-space utilities are provided to allow access to the facility. See keyctl(1), keyctl(3), and keyutils(7) for more information.

Keys

A key has the following attributes:

Serial number (ID)
This is a unique integer handle by which a key is referred to in system calls. The serial number is sometimes synonymously referred as the key ID. Programmatically, key serial numbers are represented using the type key_serial_t.

Type
A key’s type defines what sort of data can be held in the key, how the proposed content of the key will be parsed, and how the payload will be used.

There are a number of general-purpose types available, plus some specialist types defined by specific kernel components.

Description (name)
The key description is a printable string that is used as the search term for the key (in conjunction with the key type) as well as a display name. During searches, the description may be partially matched or exactly matched.

Payload (data)
The payload is the actual content of a key. This is usually set when a key is created, but it is possible for the kernel to upcall to user space to finish the instantiation of a key if that key wasn’t already known to the kernel when it was requested. For further details, see request_key(2).

A key’s payload can be read and updated if the key type supports it and if suitable permission is granted to the caller.

Access rights
Much as files do, each key has an owning user ID, an owning group ID, and a security label. Each key also has a set of permissions, though there are more than for a normal UNIX file, and there is an additional category—possessor—beyond the usual user, group, and other (see Possession, below).

Note that keys are quota controlled, since they require unswappable kernel memory. The owning user ID specifies whose quota is to be debited.

Expiration time
Each key can have an expiration time set. When that time is reached, the key is marked as being expired and accesses to it fail with the error EKEYEXPIRED. If not deleted, updated, or replaced, then, after a set amount of time, an expired key is automatically removed (garbage collected) along with all links to it, and attempts to access the key fail with the error ENOKEY.

Reference count
Each key has a reference count. Keys are referenced by keyrings, by currently active users, and by a process’s credentials. When the reference count reaches zero, the key is scheduled for garbage collection.

Key types

The kernel provides several basic types of key:

“keyring”
Keyrings are special keys which store a set of links to other keys (including other keyrings), analogous to a directory holding links to files. The main purpose of a keyring is to prevent other keys from being garbage collected because nothing refers to them.

Keyrings with descriptions (names) that begin with a period (’.’) are reserved to the implementation.

“user”
This is a general-purpose key type. The key is kept entirely within kernel memory. The payload may be read and updated by user-space applications.

The payload for keys of this type is a blob of arbitrary data of up to 32,767 bytes.

The description may be any valid string, though it is preferred that it start with a colon-delimited prefix representing the service to which the key is of interest (for instance “afs:mykey”).

“logon” (since Linux 3.3)
This key type is essentially the same as “user”, but it does not provide reading (i.e., the keyctl(2) KEYCTL_READ operation), meaning that the key payload is never visible from user space. This is suitable for storing username-password pairs that should not be readable from user space.

The description of a “logon” key must start with a non-empty colon-delimited prefix whose purpose is to identify the service to which the key belongs. (Note that this differs from keys of the “user” type, where the inclusion of a prefix is recommended but is not enforced.)

“big_key” (since Linux 3.13)
This key type is similar to the “user” key type, but it may hold a payload of up to 1 MiB in size. This key type is useful for purposes such as holding Kerberos ticket caches.

The payload data may be stored in a tmpfs filesystem, rather than in kernel memory, if the data size exceeds the overhead of storing the data in the filesystem. (Storing the data in a filesystem requires filesystem structures to be allocated in the kernel. The size of these structures determines the size threshold above which the tmpfs storage method is used.) Since Linux 4.8, the payload data is encrypted when stored in tmpfs, thereby preventing it from being written unencrypted into swap space.

There are more specialized key types available also, but they aren’t discussed here because they aren’t intended for normal user-space use.

Key type names that begin with a period (’.’) are reserved to the implementation.

Keyrings

As previously mentioned, keyrings are a special type of key that contain links to other keys (which may include other keyrings). Keys may be linked to by multiple keyrings. Keyrings may be considered as analogous to UNIX directories where each directory contains a set of hard links to files.

Various operations (system calls) may be applied only to keyrings:

Adding
A key may be added to a keyring by system calls that create keys. This prevents the new key from being immediately deleted when the system call releases its last reference to the key.

Linking
A link may be added to a keyring pointing to a key that is already known, provided this does not create a self-referential cycle.

Unlinking
A link may be removed from a keyring. When the last link to a key is removed, that key will be scheduled for deletion by the garbage collector.

Clearing
All the links may be removed from a keyring.

Searching
A keyring may be considered the root of a tree or subtree in which keyrings form the branches and non-keyrings the leaves. This tree may be searched for a key matching a particular type and description.

See keyctl_clear(3), keyctl_link(3), keyctl_search(3), and keyctl_unlink(3) for more information.

Anchoring keys

To prevent a key from being garbage collected, it must be anchored to keep its reference count elevated when it is not in active use by the kernel.

Keyrings are used to anchor other keys: each link is a reference on a key. Note that keyrings themselves are just keys and are also subject to the same anchoring requirement to prevent them being garbage collected.

The kernel makes available a number of anchor keyrings. Note that some of these keyrings will be created only when first accessed.

Process keyrings
Process credentials themselves reference keyrings with specific semantics. These keyrings are pinned as long as the set of credentials exists, which is usually as long as the process exists.

There are three keyrings with different inheritance/sharing rules: the session-keyring(7) (inherited and shared by all child processes), the process-keyring(7) (shared by all threads in a process) and the thread-keyring(7) (specific to a particular thread).

As an alternative to using the actual keyring IDs, in calls to add_key(2), keyctl(2), and request_key(2), the special keyring values KEY_SPEC_SESSION_KEYRING, KEY_SPEC_PROCESS_KEYRING, and KEY_SPEC_THREAD_KEYRING can be used to refer to the caller’s own instances of these keyrings.

User keyrings
Each UID known to the kernel has a record that contains two keyrings: the user-keyring(7) and the user-session-keyring(7). These exist for as long as the UID record in the kernel exists.

As an alternative to using the actual keyring IDs, in calls to add_key(2), keyctl(2), and request_key(2), the special keyring values KEY_SPEC_USER_KEYRING and KEY_SPEC_USER_SESSION_KEYRING can be used to refer to the caller’s own instances of these keyrings.

A link to the user keyring is placed in a new session keyring by pam_keyinit(8) when a new login session is initiated.

Persistent keyrings
There is a persistent-keyring(7) available to each UID known to the system. It may persist beyond the life of the UID record previously mentioned, but has an expiration time set such that it is automatically cleaned up after a set time. The persistent keyring permits, for example, cron(8) scripts to use credentials that are left in the persistent keyring after the user logs out.

Note that the expiration time of the persistent keyring is reset every time the persistent key is requested.

Special keyrings
There are special keyrings owned by the kernel that can anchor keys for special purposes. An example of this is the system keyring used for holding encryption keys for module signature verification.

These special keyrings are usually closed to direct alteration by user space.

An originally planned “group keyring”, for storing keys associated with each GID known to the kernel, is not so far implemented, is unlikely to be implemented. Nevertheless, the constant KEY_SPEC_GROUP_KEYRING has been defined for this keyring.

Possession

The concept of possession is important to understanding the keyrings security model. Whether a thread possesses a key is determined by the following rules:

  1. Any key or keyring that does not grant search permission to the caller is ignored in all the following rules.

  2. A thread possesses its session-keyring(7), process-keyring(7), and thread-keyring(7) directly because those keyrings are referred to by its credentials.

  3. If a keyring is possessed, then any key it links to is also possessed.

  4. If any key a keyring links to is itself a keyring, then rule (3) applies recursively.

  5. If a process is upcalled from the kernel to instantiate a key (see request_key(2)), then it also possesses the requester’s keyrings as in rule (1) as if it were the requester.

Note that possession is not a fundamental property of a key, but must rather be calculated each time the key is needed.

Possession is designed to allow set-user-ID programs run from, say a user’s shell to access the user’s keys. Granting permissions to the key possessor while denying them to the key owner and group allows the prevention of access to keys on the basis of UID and GID matches.

When it creates the session keyring, pam_keyinit(8) adds a link to the user-keyring(7), thus making the user keyring and anything it contains possessed by default.

Access rights

Each key has the following security-related attributes:

  • The owning user ID

  • The ID of a group that is permitted to access the key

  • A security label

  • A permissions mask

The permissions mask contains four sets of rights. The first three sets are mutually exclusive. One and only one will be in force for a particular access check. In order of descending priority, these three sets are:

user
The set specifies the rights granted if the key’s user ID matches the caller’s filesystem user ID.

group
The set specifies the rights granted if the user ID didn’t match and the key’s group ID matches the caller’s filesystem GID or one of the caller’s supplementary group IDs.

other
The set specifies the rights granted if neither the key’s user ID nor group ID matched.

The fourth set of rights is:

possessor
The set specifies the rights granted if a key is determined to be possessed by the caller.

The complete set of rights for a key is the union of whichever of the first three sets is applicable plus the fourth set if the key is possessed.

The set of rights that may be granted in each of the four masks is as follows:

view
The attributes of the key may be read. This includes the type, description, and access rights (excluding the security label).

read
For a key: the payload of the key may be read. For a keyring: the list of serial numbers (keys) to which the keyring has links may be read.

write
The payload of the key may be updated and the key may be revoked. For a keyring, links may be added to or removed from the keyring, and the keyring may be cleared completely (all links are removed),

search
For a key (or a keyring): the key may be found by a search. For a keyring: keys and keyrings that are linked to by the keyring may be searched.

link
Links may be created from keyrings to the key. The initial link to a key that is established when the key is created doesn’t require this permission.

setattr
The ownership details and security label of the key may be changed, the key’s expiration time may be set, and the key may be revoked.

In addition to access rights, any active Linux Security Module (LSM) may prevent access to a key if its policy so dictates. A key may be given a security label or other attribute by the LSM; this label is retrievable via keyctl_get_security(3).

See keyctl_chown(3), keyctl_describe(3), keyctl_get_security(3), keyctl_setperm(3), and selinux(8) for more information.

Searching for keys

One of the key features of the Linux key-management facility is the ability to find a key that a process is retaining. The request_key(2) system call is the primary point of access for user-space applications to find a key. (Internally, the kernel has something similar available for use by internal components that make use of keys.)

The search algorithm works as follows:

  1. The process keyrings are searched in the following order: the thread-keyring(7) if it exists, the process-keyring(7) if it exists, and then either the session-keyring(7) if it exists or the user-session-keyring(7) if that exists.

  2. If the caller was a process that was invoked by the request_key(2) upcall mechanism, then the keyrings of the original caller of request_key(2) will be searched as well.

  3. The search of a keyring tree is in breadth-first order: each keyring is searched first for a match, then the keyrings referred to by that keyring are searched.

  4. If a matching key is found that is valid, then the search terminates and that key is returned.

  5. If a matching key is found that has an error state attached, that error state is noted and the search continues.

  6. If no valid matching key is found, then the first noted error state is returned; otherwise, an ENOKEY error is returned.

It is also possible to search a specific keyring, in which case only steps (3) to (6) apply.

See request_key(2) and keyctl_search(3) for more information.

On-demand key creation

If a key cannot be found, request_key(2) will, if given a callout_info argument, create a new key and then upcall to user space to instantiate the key. This allows keys to be created on an as-needed basis.

Typically, this will involve the kernel creating a new process that executes the request-key(8) program, which will then execute the appropriate handler based on its configuration.

The handler is passed a special authorization key that allows it and only it to instantiate the new key. This is also used to permit searches performed by the handler program to also search the requester’s keyrings.

See request_key(2), keyctl_assume_authority(3), keyctl_instantiate(3), keyctl_negate(3), keyctl_reject(3), request-key(8), and request-key.conf(5) for more information.

/proc files

The kernel provides various /proc files that expose information about keys or define limits on key usage.

/proc/keys (since Linux 2.6.10)
This file exposes a list of the keys for which the reading thread has view permission, providing various information about each key. The thread need not possess the key for it to be visible in this file.

The only keys included in the list are those that grant view permission to the reading process (regardless of whether or not it possesses them). LSM security checks are still performed, and may filter out further keys that the process is not authorized to view.

An example of the data that one might see in this file (with the columns numbered for easy reference below) is the following:

  (1)     (2)     (3)(4)    (5)     (6)   (7)   (8)        (9)
009a2028 I--Q---   1 perm 3f010000  1000  1000 user     krb_ccache:primary: 12
1806c4ba I--Q---   1 perm 3f010000  1000  1000 keyring  _pid: 2
25d3a08f I--Q---   1 perm 1f3f0000  1000 65534 keyring  _uid_ses.1000: 1
28576bd8 I--Q---   3 perm 3f010000  1000  1000 keyring  _krb: 1
2c546d21 I--Q--- 190 perm 3f030000  1000  1000 keyring  _ses: 2
30a4e0be I------   4   2d 1f030000  1000 65534 keyring  _persistent.1000: 1
32100fab I--Q---   4 perm 1f3f0000  1000 65534 keyring  _uid.1000: 2
32a387ea I--Q---   1 perm 3f010000  1000  1000 keyring  _pid: 2
3ce56aea I--Q---   5 perm 3f030000  1000  1000 keyring  _ses: 1

The fields shown in each line of this file are as follows:

ID (1)
The ID (serial number) of the key, expressed in hexadecimal.

Flags (2)
A set of flags describing the state of the key:

I
The key has been instantiated.

R
The key has been revoked.

D
The key is dead (i.e., the key type has been unregistered). (A key may be briefly in this state during garbage collection.)

Q
The key contributes to the user’s quota.

U
The key is under construction via a callback to user space; see request-key(2).

N
The key is negatively instantiated.

i
The key has been invalidated.

Usage (3)
This is a count of the number of kernel credential structures that are pinning the key (approximately: the number of threads and open file references that refer to this key).

Timeout (4)
The amount of time until the key will expire, expressed in human-readable form (weeks, days, hours, minutes, and seconds). The string perm here means that the key is permanent (no timeout). The string expd means that the key has already expired, but has not yet been garbage collected.

Permissions (5)
The key permissions, expressed as four hexadecimal bytes containing, from left to right, the possessor, user, group, and other permissions. Within each byte, the permission bits are as follows:

0x01
view

0x02
read

0x04
write

0x08
search

0x10
link

0x20
setattr

UID (6)
The user ID of the key owner.

GID (7)
The group ID of the key. The value -1 here means that the key has no group ID; this can occur in certain circumstances for keys created by the kernel.

Type (8)
The key type (user, keyring, etc.)

Description (9)
The key description (name). This field contains descriptive information about the key. For most key types, it has the form

name[: extra-info]

The name subfield is the key’s description (name). The optional extra-info field provides some further information about the key. The information that appears here depends on the key type, as follows:

“user” and “logon”
The size in bytes of the key payload (expressed in decimal).

“keyring”
The number of keys linked to the keyring, or the string empty if there are no keys linked to the keyring.

“big_key”
The payload size in bytes, followed either by the string [file], if the key payload exceeds the threshold that means that the payload is stored in a (swappable) tmpfs(5) filesystem, or otherwise the string [buff], indicating that the key is small enough to reside in kernel memory.

For the ".request_key_auth" key type (authorization key; see request_key(2)), the description field has the form shown in the following example:

key:c9a9b19 pid:28880 ci:10

The three subfields are as follows:

key
The hexadecimal ID of the key being instantiated in the requesting program.

pid
The PID of the requesting program.

ci
The length of the callout data with which the requested key should be instantiated (i.e., the length of the payload associated with the authorization key).

/proc/key-users (since Linux 2.6.10)
This file lists various information for each user ID that has at least one key on the system. An example of the data that one might see in this file is the following:

   0:    10 9/9 2/1000000 22/25000000
  42:     9 9/9 8/200 106/20000
1000:    11 11/11 10/200 271/20000

The fields shown in each line are as follows:

uid
The user ID.

usage
This is a kernel-internal usage count for the kernel structure used to record key users.

nkeys/nikeys
The total number of keys owned by the user, and the number of those keys that have been instantiated.

qnkeys/maxkeys
The number of keys owned by the user, and the maximum number of keys that the user may own.

qnbytes/maxbytes
The number of bytes consumed in payloads of the keys owned by this user, and the upper limit on the number of bytes in key payloads for that user.

/proc/sys/kernel/keys/gc_delay (since Linux 2.6.32)
The value in this file specifies the interval, in seconds, after which revoked and expired keys will be garbage collected. The purpose of having such an interval is so that there is a window of time where user space can see an error (respectively EKEYREVOKED and EKEYEXPIRED) that indicates what happened to the key.

The default value in this file is 300 (i.e., 5 minutes).

/proc/sys/kernel/keys/persistent_keyring_expiry (since Linux 3.13)
This file defines an interval, in seconds, to which the persistent keyring’s expiration timer is reset each time the keyring is accessed (via keyctl_get_persistent(3) or the keyctl(2) KEYCTL_GET_PERSISTENT operation.)

The default value in this file is 259200 (i.e., 3 days).

The following files (which are writable by privileged processes) are used to enforce quotas on the number of keys and number of bytes of data that can be stored in key payloads:

/proc/sys/kernel/keys/maxbytes (since Linux 2.6.26)
This is the maximum number of bytes of data that a nonroot user can hold in the payloads of the keys owned by the user.

The default value in this file is 20,000.

/proc/sys/kernel/keys/maxkeys (since Linux 2.6.26)
This is the maximum number of keys that a nonroot user may own.

The default value in this file is 200.

/proc/sys/kernel/keys/root_maxbytes (since Linux 2.6.26)
This is the maximum number of bytes of data that the root user (UID 0 in the root user namespace) can hold in the payloads of the keys owned by root.

The default value in this file is 25,000,000 (20,000 before Linux 3.17).

/proc/sys/kernel/keys/root_maxkeys (since Linux 2.6.26)
This is the maximum number of keys that the root user (UID 0 in the root user namespace) may own.

The default value in this file is 1,000,000 (200 before Linux 3.17).

With respect to keyrings, note that each link in a keyring consumes 4 bytes of the keyring payload.

Users

The Linux key-management facility has a number of users and usages, but is not limited to those that already exist.

In-kernel users of this facility include:

Network filesystems - DNS
The kernel uses the upcall mechanism provided by the keys to upcall to user space to do DNS lookups and then to cache the results.

AF_RXRPC and kAFS - Authentication
The AF_RXRPC network protocol and the in-kernel AFS filesystem use keys to store the ticket needed to do secured or encrypted traffic. These are then looked up by network operations on AF_RXRPC and filesystem operations on kAFS.

NFS - User ID mapping
The NFS filesystem uses keys to store mappings of foreign user IDs to local user IDs.

CIFS - Password
The CIFS filesystem uses keys to store passwords for accessing remote shares.

Module verification
The kernel build process can be made to cryptographically sign modules. That signature is then checked when a module is loaded.

User-space users of this facility include:

Kerberos key storage
The MIT Kerberos 5 facility (libkrb5) can use keys to store authentication tokens which can be made to be automatically cleaned up a set time after the user last uses them, but until then permits them to hang around after the user has logged out so that cron(8) scripts can use them.

SEE ALSO

keyctl(1), add_key(2), keyctl(2), request_key(2), keyctl(3), keyutils(7), persistent-keyring(7), process-keyring(7), session-keyring(7), thread-keyring(7), user-keyring(7), user-session-keyring(7), pam_keyinit(8), request-key(8)

The kernel source files Documentation/crypto/asymmetric-keys.txt and under Documentation/security/keys (or, before Linux 4.13, in the file Documentation/security/keys.txt).

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

138 - Linux cli command X25519ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command X25519ssl and provides detailed information about the command X25519ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the X25519ssl.

NAME 🖥️ X25519ssl 🖥️

EVP_PKEY X25519 and X448 support

DESCRIPTION

The X25519 and X448 EVP_PKEY implementation supports key generation and key derivation using X25519 and X448. It has associated private and public key formats compatible with RFC 8410.

No additional parameters can be set during key generation.

The peer public key must be set using EVP_PKEY_derive_set_peer() when performing key derivation.

NOTES

A context for the X25519 algorithm can be obtained by calling:

EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_id(EVP_PKEY_X25519, NULL);

For the X448 algorithm a context can be obtained by calling:

EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_id(EVP_PKEY_X448, NULL);

X25519 or X448 private keys can be set directly using EVP_PKEY_new_raw_private_key (3) or loaded from a PKCS#8 private key file using PEM_read_bio_PrivateKey (3) (or similar function). Completely new keys can also be generated (see the example below). Setting a private key also sets the associated public key.

X25519 or X448 public keys can be set directly using EVP_PKEY_new_raw_public_key (3) or loaded from a SubjectPublicKeyInfo structure in a PEM file using PEM_read_bio_PUBKEY (3) (or similar function).

EXAMPLES

This example generates an X25519 private key and writes it to standard output in PEM format:

#include <openssl/evp.h> #include <openssl/pem.h> … EVP_PKEY *pkey = NULL; EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_id(EVP_PKEY_X25519, NULL); EVP_PKEY_keygen_init(pctx); EVP_PKEY_keygen(pctx, &pkey); EVP_PKEY_CTX_free(pctx); PEM_write_PrivateKey(stdout, pkey, NULL, NULL, 0, NULL, NULL);

The key derivation example in EVP_PKEY_derive (3) can be used with X25519 and X448.

SEE ALSO

EVP_PKEY_CTX_new (3), EVP_PKEY_keygen (3), EVP_PKEY_derive (3), EVP_PKEY_derive_set_peer (3)

COPYRIGHT

Copyright 2017-2020 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

139 - Linux cli command netlink

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command netlink and provides detailed information about the command netlink, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the netlink.

NAME 🖥️ netlink 🖥️

communication between kernel and user space (AF_NETLINK)

SYNOPSIS

#include <asm/types.h>
#include <sys/socket.h>
#include <linux/netlink.h>
netlink_socket = socket(AF_NETLINK, socket_type, netlink_family);

DESCRIPTION

Netlink is used to transfer information between the kernel and user-space processes. It consists of a standard sockets-based interface for user space processes and an internal kernel API for kernel modules. The internal kernel interface is not documented in this manual page. There is also an obsolete netlink interface via netlink character devices; this interface is not documented here and is provided only for backward compatibility.

Netlink is a datagram-oriented service. Both SOCK_RAW and SOCK_DGRAM are valid values for socket_type. However, the netlink protocol does not distinguish between datagram and raw sockets.

netlink_family selects the kernel module or netlink group to communicate with. The currently assigned netlink families are:

NETLINK_ROUTE
Receives routing and link updates and may be used to modify the routing tables (both IPv4 and IPv6), IP addresses, link parameters, neighbor setups, queueing disciplines, traffic classes, and packet classifiers (see rtnetlink(7)).

NETLINK_W1 (Linux 2.6.13 to Linux 2.16.17)
Messages from 1-wire subsystem.

NETLINK_USERSOCK
Reserved for user-mode socket protocols.

NETLINK_FIREWALL (up to and including Linux 3.4)
Transport IPv4 packets from netfilter to user space. Used by ip_queue kernel module. After a long period of being declared obsolete (in favor of the more advanced nfnetlink_queue feature), NETLINK_FIREWALL was removed in Linux 3.5.

NETLINK_SOCK_DIAG (since Linux 3.3)
Query information about sockets of various protocol families from the kernel (see sock_diag(7)).

NETLINK_INET_DIAG (since Linux 2.6.14)
An obsolete synonym for NETLINK_SOCK_DIAG.

NETLINK_NFLOG (up to and including Linux 3.16)
Netfilter/iptables ULOG.

NETLINK_XFRM
IPsec.

NETLINK_SELINUX (since Linux 2.6.4)
SELinux event notifications.

NETLINK_ISCSI (since Linux 2.6.15)
Open-iSCSI.

NETLINK_AUDIT (since Linux 2.6.6)
Auditing.

NETLINK_FIB_LOOKUP (since Linux 2.6.13)
Access to FIB lookup from user space.

NETLINK_CONNECTOR (since Linux 2.6.14)
Kernel connector. See Documentation/driver-api/connector.rst (or /Documentation/connector/connector.* in Linux 5.2 and earlier) in the Linux kernel source tree for further information.

NETLINK_NETFILTER (since Linux 2.6.14)
Netfilter subsystem.

NETLINK_SCSITRANSPORT (since Linux 2.6.19)
SCSI Transports.

NETLINK_RDMA (since Linux 3.0)
Infiniband RDMA.

NETLINK_IP6_FW (up to and including Linux 3.4)
Transport IPv6 packets from netfilter to user space. Used by ip6_queue kernel module.

NETLINK_DNRTMSG
DECnet routing messages.

NETLINK_KOBJECT_UEVENT (since Linux 2.6.10)
Kernel messages to user space.

NETLINK_GENERIC (since Linux 2.6.15)
Generic netlink family for simplified netlink usage.

NETLINK_CRYPTO (since Linux 3.2)
Netlink interface to request information about ciphers registered with the kernel crypto API as well as allow configuration of the kernel crypto API.

Netlink messages consist of a byte stream with one or multiple nlmsghdr headers and associated payload. The byte stream should be accessed only with the standard NLMSG_* macros. See netlink(3) for further information.

In multipart messages (multiple nlmsghdr headers with associated payload in one byte stream) the first and all following headers have the NLM_F_MULTI flag set, except for the last header which has the type NLMSG_DONE.

After each nlmsghdr the payload follows.

struct nlmsghdr {
    __u32 nlmsg_len;    /* Length of message including header */
    __u16 nlmsg_type;   /* Type of message content */
    __u16 nlmsg_flags;  /* Additional flags */
    __u32 nlmsg_seq;    /* Sequence number */
    __u32 nlmsg_pid;    /* Sender port ID */
};

nlmsg_type can be one of the standard message types: NLMSG_NOOP message is to be ignored, NLMSG_ERROR message signals an error and the payload contains an nlmsgerr structure, NLMSG_DONE message terminates a multipart message. Error messages get the original request appended, unless the user requests to cap the error message, and get extra error data if requested.

struct nlmsgerr {
    int error;        /* Negative errno or 0 for acknowledgements */
    struct nlmsghdr msg;  /* Message header that caused the error */
    /*
     * followed by the message contents
     * unless NETLINK_CAP_ACK was set
     * or the ACK indicates success (error == 0).
     * For example Generic Netlink message with attributes.
     * message length is aligned with NLMSG_ALIGN()
     */
    /*
     * followed by TLVs defined in enum nlmsgerr_attrs
     * if NETLINK_EXT_ACK was set
     */
};

A netlink family usually specifies more message types, see the appropriate manual pages for that, for example, rtnetlink(7) for NETLINK_ROUTE.

TABLE

TABLE

Note that NLM_F_ATOMIC requires the CAP_NET_ADMIN capability or an effective UID of 0.

TABLE

nlmsg_seq and nlmsg_pid are used to track messages. nlmsg_pid shows the origin of the message. Note that there isn’t a 1:1 relationship between nlmsg_pid and the PID of the process if the message originated from a netlink socket. See the ADDRESS FORMATS section for further information.

Both nlmsg_seq and nlmsg_pid are opaque to netlink core.

Netlink is not a reliable protocol. It tries its best to deliver a message to its destination(s), but may drop messages when an out-of-memory condition or other error occurs. For reliable transfer the sender can request an acknowledgement from the receiver by setting the NLM_F_ACK flag. An acknowledgement is an NLMSG_ERROR packet with the error field set to 0. The application must generate acknowledgements for received messages itself. The kernel tries to send an NLMSG_ERROR message for every failed packet. A user process should follow this convention too.

However, reliable transmissions from kernel to user are impossible in any case. The kernel can’t send a netlink message if the socket buffer is full: the message will be dropped and the kernel and the user-space process will no longer have the same view of kernel state. It is up to the application to detect when this happens (via the ENOBUFS error returned by recvmsg(2)) and resynchronize.

Address formats

The sockaddr_nl structure describes a netlink client in user space or in the kernel. A sockaddr_nl can be either unicast (only sent to one peer) or sent to netlink multicast groups (nl_groups not equal 0).

struct sockaddr_nl {
    sa_family_t     nl_family;  /* AF_NETLINK */
    unsigned short  nl_pad;     /* Zero */
    pid_t           nl_pid;     /* Port ID */
    __u32           nl_groups;  /* Multicast groups mask */
};

nl_pid is the unicast address of netlink socket. It’s always 0 if the destination is in the kernel. For a user-space process, nl_pid is usually the PID of the process owning the destination socket. However, nl_pid identifies a netlink socket, not a process. If a process owns several netlink sockets, then nl_pid can be equal to the process ID only for at most one socket. There are two ways to assign nl_pid to a netlink socket. If the application sets nl_pid before calling bind(2), then it is up to the application to make sure that nl_pid is unique. If the application sets it to 0, the kernel takes care of assigning it. The kernel assigns the process ID to the first netlink socket the process opens and assigns a unique nl_pid to every netlink socket that the process subsequently creates.

nl_groups is a bit mask with every bit representing a netlink group number. Each netlink family has a set of 32 multicast groups. When bind(2) is called on the socket, the nl_groups field in the sockaddr_nl should be set to a bit mask of the groups which it wishes to listen to. The default value for this field is zero which means that no multicasts will be received. A socket may multicast messages to any of the multicast groups by setting nl_groups to a bit mask of the groups it wishes to send to when it calls sendmsg(2) or does a connect(2). Only processes with an effective UID of 0 or the CAP_NET_ADMIN capability may send or listen to a netlink multicast group. Since Linux 2.6.13, messages can’t be broadcast to multiple groups. Any replies to a message received for a multicast group should be sent back to the sending PID and the multicast group. Some Linux kernel subsystems may additionally allow other users to send and/or receive messages. As at Linux 3.0, the NETLINK_KOBJECT_UEVENT, NETLINK_GENERIC, NETLINK_ROUTE, and NETLINK_SELINUX groups allow other users to receive messages. No groups allow other users to send messages.

Socket options

To set or get a netlink socket option, call getsockopt(2) to read or setsockopt(2) to write the option with the option level argument set to SOL_NETLINK. Unless otherwise noted, optval is a pointer to an int.

NETLINK_PKTINFO (since Linux 2.6.14)
Enable nl_pktinfo control messages for received packets to get the extended destination group number.

NETLINK_ADD_MEMBERSHIP
NETLINK_DROP_MEMBERSHIP (since Linux 2.6.14)
Join/leave a group specified by optval.

NETLINK_LIST_MEMBERSHIPS (since Linux 4.2)
Retrieve all groups a socket is a member of. optval is a pointer to __u32 and optlen is the size of the array. The array is filled with the full membership set of the socket, and the required array size is returned in optlen.

NETLINK_BROADCAST_ERROR (since Linux 2.6.30)
When not set, netlink_broadcast() only reports ESRCH errors and silently ignore ENOBUFS errors.

NETLINK_NO_ENOBUFS (since Linux 2.6.30)
This flag can be used by unicast and broadcast listeners to avoid receiving ENOBUFS errors.

NETLINK_LISTEN_ALL_NSID (since Linux 4.2)
When set, this socket will receive netlink notifications from all network namespaces that have an nsid assigned into the network namespace where the socket has been opened. The nsid is sent to user space via an ancillary data.

NETLINK_CAP_ACK (since Linux 4.3)
The kernel may fail to allocate the necessary room for the acknowledgement message back to user space. This option trims off the payload of the original netlink message. The netlink message header is still included, so the user can guess from the sequence number which message triggered the acknowledgement.

VERSIONS

The socket interface to netlink first appeared Linux 2.2.

Linux 2.0 supported a more primitive device-based netlink interface (which is still available as a compatibility option). This obsolete interface is not described here.

NOTES

It is often better to use netlink via libnetlink or libnl than via the low-level kernel interface.

BUGS

This manual page is not complete.

EXAMPLES

The following example creates a NETLINK_ROUTE netlink socket which will listen to the RTMGRP_LINK (network interface create/delete/up/down events) and RTMGRP_IPV4_IFADDR (IPv4 addresses add/delete events) multicast groups.

struct sockaddr_nl sa;
memset(&sa, 0, sizeof(sa));
sa.nl_family = AF_NETLINK;
sa.nl_groups = RTMGRP_LINK | RTMGRP_IPV4_IFADDR;
fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE);
bind(fd, (struct sockaddr *) &sa, sizeof(sa));

The next example demonstrates how to send a netlink message to the kernel (pid 0). Note that the application must take care of message sequence numbers in order to reliably track acknowledgements.

struct nlmsghdr *nh;    /* The nlmsghdr with payload to send */
struct sockaddr_nl sa;
struct iovec iov = { nh, nh->nlmsg_len };
struct msghdr msg;
msg = { &sa, sizeof(sa), &iov, 1, NULL, 0, 0 };
memset(&sa, 0, sizeof(sa));
sa.nl_family = AF_NETLINK;
nh->nlmsg_pid = 0;
nh->nlmsg_seq = ++sequence_number;
/* Request an ack from kernel by setting NLM_F_ACK */
nh->nlmsg_flags |= NLM_F_ACK;
sendmsg(fd, &msg, 0);

And the last example is about reading netlink message.

int len;
/* 8192 to avoid message truncation on platforms with
   page size > 4096 */
struct nlmsghdr buf[8192/sizeof(struct nlmsghdr)];
struct iovec iov = { buf, sizeof(buf) };
struct sockaddr_nl sa;
struct msghdr msg;
struct nlmsghdr *nh;
msg = { &sa, sizeof(sa), &iov, 1, NULL, 0, 0 };
len = recvmsg(fd, &msg, 0);
for (nh = (struct nlmsghdr *) buf; NLMSG_OK (nh, len);
     nh = NLMSG_NEXT (nh, len)) {
    /* The end of multipart message */
    if (nh->nlmsg_type == NLMSG_DONE)
        return;
    if (nh->nlmsg_type == NLMSG_ERROR)
        /* Do some error handling */
    ...
    /* Continue with parsing payload */
    ...
}

SEE ALSO

cmsg(3), netlink(3), capabilities(7), rtnetlink(7), sock_diag(7)

information about libnetlink

information about libnl

RFC 3549 “Linux Netlink as an IP Services Protocol”

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

140 - Linux cli command random

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command random and provides detailed information about the command random, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the random.

NAME 🖥️ random 🖥️

overview of interfaces for obtaining randomness

DESCRIPTION

The kernel random-number generator relies on entropy gathered from device drivers and other sources of environmental noise to seed a cryptographically secure pseudorandom number generator (CSPRNG). It is designed for security, rather than speed.

The following interfaces provide access to output from the kernel CSPRNG:

  • The /dev/urandom and /dev/random devices, both described in random(4). These devices have been present on Linux since early times, and are also available on many other systems.

  • The Linux-specific getrandom(2) system call, available since Linux 3.17. This system call provides access either to the same source as /dev/urandom (called the urandom source in this page) or to the same source as /dev/random (called the random source in this page). The default is the urandom source; the random source is selected by specifying the GRND_RANDOM flag to the system call. (The getentropy(3) function provides a slightly more portable interface on top of getrandom(2).)

Initialization of the entropy pool

The kernel collects bits of entropy from the environment. When a sufficient number of random bits has been collected, the entropy pool is considered to be initialized.

Choice of random source

Unless you are doing long-term key generation (and most likely not even then), you probably shouldn’t be reading from the /dev/random device or employing getrandom(2) with the GRND_RANDOM flag. Instead, either read from the /dev/urandom device or employ getrandom(2) without the GRND_RANDOM flag. The cryptographic algorithms used for the urandom source are quite conservative, and so should be sufficient for all purposes.

The disadvantage of GRND_RANDOM and reads from /dev/random is that the operation can block for an indefinite period of time. Furthermore, dealing with the partially fulfilled requests that can occur when using GRND_RANDOM or when reading from /dev/random increases code complexity.

Monte Carlo and other probabilistic sampling applications

Using these interfaces to provide large quantities of data for Monte Carlo simulations or other programs/algorithms which are doing probabilistic sampling will be slow. Furthermore, it is unnecessary, because such applications do not need cryptographically secure random numbers. Instead, use the interfaces described in this page to obtain a small amount of data to seed a user-space pseudorandom number generator for use by such applications.

Comparison between getrandom, /dev/urandom, and /dev/random

The following table summarizes the behavior of the various interfaces that can be used to obtain randomness. GRND_NONBLOCK is a flag that can be used to control the blocking behavior of getrandom(2). The final column of the table considers the case that can occur in early boot time when the entropy pool is not yet initialized.

InterfacePoolBlocking behaviorBehavior when pool is not yet ready
/dev/randomBlocking poolIf entropy too low, blocks until there is enough entropy againBlocks until enough entropy gathered
/dev/urandomCSPRNG outputNever blocksReturns output from uninitialized CSPRNG (may be low entropy and unsuitable for cryptography)
getrandom()Same as /dev/urandomDoes not block once is pool readyBlocks until pool ready
getrandom() GRND_RANDOMSame as /dev/randomIf entropy too low, blocks until there is enough entropy againBlocks until pool ready
getrandom() GRND_NONBLOCKSame as /dev/urandomDoes not block once is pool readyEAGAIN
getrandom() GRND_RANDOM + GRND_NONBLOCKSame as /dev/randomEAGAIN if not enough entropy availableEAGAIN

Generating cryptographic keys

The amount of seed material required to generate a cryptographic key equals the effective key size of the key. For example, a 3072-bit RSA or Diffie-Hellman private key has an effective key size of 128 bits (it requires about 2^128 operations to break) so a key generator needs only 128 bits (16 bytes) of seed material from /dev/random.

While some safety margin above that minimum is reasonable, as a guard against flaws in the CSPRNG algorithm, no cryptographic primitive available today can hope to promise more than 256 bits of security, so if any program reads more than 256 bits (32 bytes) from the kernel random pool per invocation, or per reasonable reseed interval (not less than one minute), that should be taken as a sign that its cryptography is not skillfully implemented.

SEE ALSO

getrandom(2), getauxval(3), getentropy(3), random(4), urandom(4), signal(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

141 - Linux cli command ossl-guide-libcrypto-introductionssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ossl-guide-libcrypto-introductionssl and provides detailed information about the command ossl-guide-libcrypto-introductionssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ossl-guide-libcrypto-introductionssl.

NAME 🖥️ ossl-guide-libcrypto-introductionssl 🖥️

guide-libcrypto-introduction, crypto - OpenSSL Guide: An introduction to libcrypto

INTRODUCTION

The OpenSSL cryptography library (libcrypto) enables access to a wide range of cryptographic algorithms used in various Internet standards. The services provided by this library are used by the OpenSSL implementations of TLS and CMS, and they have also been used to implement many other third party products and protocols.

The functionality includes symmetric encryption, public key cryptography, key agreement, certificate handling, cryptographic hash functions, cryptographic pseudo-random number generators, message authentication codes (MACs), key derivation functions (KDFs), and various utilities.

Algorithms

Cryptographic primitives such as the SHA256 digest, or AES encryption are referred to in OpenSSL as “algorithms”. Each algorithm may have multiple implementations available for use. For example the RSA algorithm is available as a “default” implementation suitable for general use, and a “fips” implementation which has been validated to FIPS 140 standards for situations where that is important. It is also possible that a third party could add additional implementations such as in a hardware security module (HSM).

Algorithms are implemented in providers. See ossl-guide-libraries-introduction (7) for information about providers.

Operations

Different algorithms can be grouped together by their purpose. For example there are algorithms for encryption, and different algorithms for digesting data. These different groups are known as “operations” in OpenSSL. Each operation has a different set of functions associated with it. For example to perform an encryption operation using AES (or any other encryption algorithm) you would use the encryption functions detailed on the EVP_EncryptInit (3) page. Or to perform a digest operation using SHA256 then you would use the digesting functions on the EVP_DigestInit (3) page.

ALGORITHM FETCHING

In order to use an algorithm an implementation for it must first be “fetched”. Fetching is the process of looking through the available implementations, applying selection criteria (via a property query string), and finally choosing the implementation that will be used.

Two types of fetching are supported by OpenSSL - “Explicit fetching” and “Implicit fetching”.

Explicit fetching

Explicit fetching involves directly calling a specific API to fetch an algorithm implementation from a provider. This fetched object can then be passed to other APIs. These explicit fetching functions usually have the name APINAME_fetch, where APINAME is the name of the operation. For example EVP_MD_fetch (3) can be used to explicitly fetch a digest algorithm implementation. The user is responsible for freeing the object returned from the APINAME_fetch function using APINAME_free when it is no longer needed.

These fetching functions follow a fairly common pattern, where three arguments are passed:

The library context
See OSSL_LIB_CTX (3) for a more detailed description. This may be NULL to signify the default (global) library context, or a context created by the user. Only providers loaded in this library context (see OSSL_PROVIDER_load (3)) will be considered by the fetching function. In case no provider has been loaded in this library context then the default provider will be loaded as a fallback (see OSSL_PROVIDER-default (7)).

An identifier
For all currently implemented fetching functions this is the algorithm name. Each provider supports a list of algorithm implementations. See the provider specific documentation for information on the algorithm implementations available in each provider: “OPERATIONS AND ALGORITHMS” in OSSL_PROVIDER-default (7), “OPERATIONS AND ALGORITHMS” in OSSL_PROVIDER-FIPS (7), “OPERATIONS AND ALGORITHMS” in OSSL_PROVIDER-legacy (7) and “OPERATIONS AND ALGORITHMS” in OSSL_PROVIDER-base (7). Note, while providers may register algorithms against a list of names using a string with a colon separated list of names, fetching algorithms using that format is currently unsupported.

A property query string
The property query string used to guide selection of the algorithm implementation. See “PROPERTY QUERY STRINGS” in ossl-guide-libraries-introduction (7).

The algorithm implementation that is fetched can then be used with other diverse functions that use them. For example the EVP_DigestInit_ex (3) function takes as a parameter an EVP_MD object which may have been returned from an earlier call to EVP_MD_fetch (3).

Implicit fetching

OpenSSL has a number of functions that return an algorithm object with no associated implementation, such as EVP_sha256 (3), EVP_aes_128_cbc (3), EVP_get_cipherbyname (3) or EVP_get_digestbyname (3). These are present for compatibility with OpenSSL before version 3.0 where explicit fetching was not available.

When they are used with functions like EVP_DigestInit_ex (3) or EVP_CipherInit_ex (3), the actual implementation to be used is fetched implicitly using default search criteria (which uses NULL for the library context and property query string).

In some cases implicit fetching can also occur when a NULL algorithm parameter is supplied. In this case an algorithm implementation is implicitly fetched using default search criteria and an algorithm name that is consistent with the context in which it is being used.

Functions that use an EVP_PKEY_CTX or an EVP_PKEY (3), such as EVP_DigestSignInit (3), all fetch the implementations implicitly. Usually the algorithm to fetch is determined based on the type of key that is being used and the function that has been called.

Performance

If you perform the same operation many times with the same algorithm then it is recommended to use a single explicit fetch of the algorithm and then reuse the explicitly fetched algorithm each subsequent time. This will typically be faster than implicitly fetching the algorithm every time you use it. See an example of Explicit fetching in “USING ALGORITHMS IN APPLICATIONS”.

Prior to OpenSSL 3.0, functions such as EVP_sha256() which return a “const” object were used directly to indicate the algorithm to use in various function calls. If you pass the return value of one of these convenience functions to an operation then you are using implicit fetching. If you are converting an application that worked with an OpenSSL version prior to OpenSSL 3.0 then consider changing instances of implicit fetching to explicit fetching instead.

If an explicitly fetched object is not passed to an operation, then any implicit fetch will use an internally cached prefetched object, but it will still be slower than passing the explicitly fetched object directly.

The following functions can be used for explicit fetching:

EVP_MD_fetch (3)
Fetch a message digest/hashing algorithm implementation.

EVP_CIPHER_fetch (3)
Fetch a symmetric cipher algorithm implementation.

EVP_KDF_fetch (3)
Fetch a Key Derivation Function (KDF) algorithm implementation.

EVP_MAC_fetch (3)
Fetch a Message Authentication Code (MAC) algorithm implementation.

EVP_KEM_fetch (3)
Fetch a Key Encapsulation Mechanism (KEM) algorithm implementation

OSSL_ENCODER_fetch (3)
Fetch an encoder algorithm implementation (e.g. to encode keys to a specified format).

OSSL_DECODER_fetch (3)
Fetch a decoder algorithm implementation (e.g. to decode keys from a specified format).

EVP_RAND_fetch (3)
Fetch a Pseudo Random Number Generator (PRNG) algorithm implementation.

See “OPERATIONS AND ALGORITHMS” in OSSL_PROVIDER-default (7), “OPERATIONS AND ALGORITHMS” in OSSL_PROVIDER-FIPS (7), “OPERATIONS AND ALGORITHMS” in OSSL_PROVIDER-legacy (7) and “OPERATIONS AND ALGORITHMS” in OSSL_PROVIDER-base (7) for a list of algorithm names that can be fetched.

FETCHING EXAMPLES

The following section provides a series of examples of fetching algorithm implementations.

Fetch any available implementation of SHA2-256 in the default context. Note that some algorithms have aliases. So “SHA256” and “SHA2-256” are synonymous:

EVP_MD *md = EVP_MD_fetch(NULL, “SHA2-256”, NULL); … EVP_MD_free(md);

Fetch any available implementation of AES-128-CBC in the default context:

EVP_CIPHER *cipher = EVP_CIPHER_fetch(NULL, “AES-128-CBC”, NULL); … EVP_CIPHER_free(cipher);

Fetch an implementation of SHA2-256 from the default provider in the default context:

EVP_MD *md = EVP_MD_fetch(NULL, “SHA2-256”, “provider=default”); … EVP_MD_free(md);

Fetch an implementation of SHA2-256 that is not from the default provider in the default context:

EVP_MD *md = EVP_MD_fetch(NULL, “SHA2-256”, “provider!=default”); … EVP_MD_free(md);

Fetch an implementation of SHA2-256 that is preferably from the FIPS provider in the default context:

EVP_MD *md = EVP_MD_fetch(NULL, “SHA2-256”, “provider=?fips”); … EVP_MD_free(md);

Fetch an implementation of SHA2-256 from the default provider in the specified library context:

EVP_MD *md = EVP_MD_fetch(libctx, “SHA2-256”, “provider=default”); … EVP_MD_free(md);

Load the legacy provider into the default context and then fetch an implementation of WHIRLPOOL from it:

/* This only needs to be done once - usually at application start up */ OSSL_PROVIDER *legacy = OSSL_PROVIDER_load(NULL, “legacy”); EVP_MD *md = EVP_MD_fetch(NULL, “WHIRLPOOL”, “provider=legacy”); … EVP_MD_free(md);

Note that in the above example the property string “provider=legacy” is optional since, assuming no other providers have been loaded, the only implementation of the “whirlpool” algorithm is in the “legacy” provider. Also note that the default provider should be explicitly loaded if it is required in addition to other providers:

/* This only needs to be done once - usually at application start up */ OSSL_PROVIDER *legacy = OSSL_PROVIDER_load(NULL, “legacy”); OSSL_PROVIDER *default = OSSL_PROVIDER_load(NULL, “default”); EVP_MD *md_whirlpool = EVP_MD_fetch(NULL, “whirlpool”, NULL); EVP_MD *md_sha256 = EVP_MD_fetch(NULL, “SHA2-256”, NULL); … EVP_MD_free(md_whirlpool); EVP_MD_free(md_sha256);

USING ALGORITHMS IN APPLICATIONS

Cryptographic algorithms are made available to applications through use of the “EVP” APIs. Each of the various operations such as encryption, digesting, message authentication codes, etc., have a set of EVP function calls that can be invoked to use them. See the evp (7) page for further details.

Most of these follow a common pattern. A “context” object is first created. For example for a digest operation you would use an EVP_MD_CTX, and for an encryption/decryption operation you would use an EVP_CIPHER_CTX. The operation is then initialised ready for use via an “init” function - optionally passing in a set of parameters (using the OSSL_PARAM (3) type) to configure how the operation should behave. Next data is fed into the operation in a series of “update” calls. The operation is finalised using a “final” call which will typically provide some kind of output. Finally the context is cleaned up and freed.

The following shows a complete example for doing this process for digesting data using SHA256. The process is similar for other operations such as encryption/decryption, signatures, message authentication codes, etc. Additional examples can be found in the OpenSSL demos (see “DEMO APPLICATIONS” in ossl-guide-libraries-introduction (7)).

#include <stdio.h> #include <openssl/evp.h> #include <openssl/bio.h> #include <openssl/err.h> int main(void) { EVP_MD_CTX *ctx = NULL; EVP_MD *sha256 = NULL; const unsigned char msg[] = { 0x00, 0x01, 0x02, 0x03 }; unsigned int len = 0; unsigned char *outdigest = NULL; int ret = 1; /* Create a context for the digest operation */ ctx = EVP_MD_CTX_new(); if (ctx == NULL) goto err; /* * Fetch the SHA256 algorithm implementation for doing the digest. Were * using the “default” library context here (first NULL parameter), and * were not supplying any particular search criteria for our SHA256 * implementation (second NULL parameter). Any SHA256 implementation will * do. * In a larger application this fetch would just be done once, and could * be used for multiple calls to other operations such as EVP_DigestInit_ex(). */ sha256 = EVP_MD_fetch(NULL, “SHA256”, NULL); if (sha256 == NULL) goto err; /* Initialise the digest operation */ if (!EVP_DigestInit_ex(ctx, sha256, NULL)) goto err; /* * Pass the message to be digested. This can be passed in over multiple * EVP_DigestUpdate calls if necessary */ if (!EVP_DigestUpdate(ctx, msg, sizeof(msg))) goto err; /* Allocate the output buffer */ outdigest = OPENSSL_malloc(EVP_MD_get_size(sha256)); if (outdigest == NULL) goto err; /* Now calculate the digest itself */ if (!EVP_DigestFinal_ex(ctx, outdigest, &len)) goto err; /* Print out the digest result */ BIO_dump_fp(stdout, outdigest, len); ret = 0; err: /* Clean up all the resources we allocated */ OPENSSL_free(outdigest); EVP_MD_free(sha256); EVP_MD_CTX_free(ctx); if (ret != 0) ERR_print_errors_fp(stderr); return ret; }

ENCODING AND DECODING KEYS

Many algorithms require the use of a key. Keys can be generated dynamically using the EVP APIs (for example see EVP_PKEY_Q_keygen (3)). However it is often necessary to save or load keys (or their associated parameters) to or from some external format such as PEM or DER (see openssl-glossary (7)). OpenSSL uses encoders and decoders to perform this task.

Encoders and decoders are just algorithm implementations in the same way as any other algorithm implementation in OpenSSL. They are implemented by providers. The OpenSSL encoders and decoders are available in the default provider. They are also duplicated in the base provider.

For information about encoders see OSSL_ENCODER_CTX_new_for_pkey (3). For information about decoders see OSSL_DECODER_CTX_new_for_pkey (3).

As well as using encoders/decoders directly there are also some helper functions that can be used for certain well known and commonly used formats. For example see PEM_read_PrivateKey (3) and PEM_write_PrivateKey (3) for information about reading and writing key data from PEM encoded files.

FURTHER READING

See ossl-guide-libssl-introduction (7) for an introduction to using libssl.

SEE ALSO

openssl (1), ssl (7), evp (7), OSSL_LIB_CTX (3), openssl-threads (7), property (7), OSSL_PROVIDER-default (7), OSSL_PROVIDER-base (7), OSSL_PROVIDER-FIPS (7), OSSL_PROVIDER-legacy (7), OSSL_PROVIDER-null (7), openssl-glossary (7), provider (7)

COPYRIGHT

Copyright 2000-2024 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

142 - Linux cli command EVP_KDF-KBssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KDF-KBssl and provides detailed information about the command EVP_KDF-KBssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KDF-KBssl.

NAME 🖥️ EVP_KDF-KBssl 🖥️

KB - The Key-Based EVP_KDF implementation

DESCRIPTION

The EVP_KDF-KB algorithm implements the Key-Based key derivation function (KBKDF). KBKDF derives a key from repeated application of a keyed MAC to an input secret (and other optional values).

Identity

“KBKDF” is the name for this implementation; it can be used with the EVP_KDF_fetch() function.

Supported parameters

The supported parameters are:

“mode” (OSSL_KDF_PARAM_MODE) <UTF8 string>
The mode parameter determines which flavor of KBKDF to use - currently the choices are “counter” and “feedback”. “counter” is the default, and will be used if unspecified.

“mac” (OSSL_KDF_PARAM_MAC) <UTF8 string>
The value is either CMAC, HMAC, KMAC128 or KMAC256.

“digest” (OSSL_KDF_PARAM_DIGEST) <UTF8 string>

“cipher” (OSSL_KDF_PARAM_CIPHER) <UTF8 string>

“properties” (OSSL_KDF_PARAM_PROPERTIES) <UTF8 string>

“key” (OSSL_KDF_PARAM_KEY) <octet string>

“salt” (OSSL_KDF_PARAM_SALT) <octet string>

“info (OSSL_KDF_PARAM_INFO) <octet string>

“seed” (OSSL_KDF_PARAM_SEED) <octet string>

The seed parameter is unused in counter mode.

“use-l” (OSSL_KDF_PARAM_KBKDF_USE_L) <integer>
Set to 0 to disable use of the optional Fixed Input data ‘L’ (see SP800-108). The default value of 1 will be used if unspecified.

“use-separator” (OSSL_KDF_PARAM_KBKDF_USE_SEPARATOR) <integer>
Set to 0 to disable use of the optional Fixed Input data ‘zero separator’ (see SP800-108) that is placed between the Label and Context. The default value of 1 will be used if unspecified.

“r” (OSSL_KDF_PARAM_KBKDF_R) <integer>
Set the fixed value ‘r’, indicating the length of the counter in bits. Supported values are 8, 16, 24, and 32. The default value of 32 will be used if unspecified.

Depending on whether mac is CMAC or HMAC, either digest or cipher is required (respectively) and the other is unused. They are unused for KMAC128 and KMAC256.

The parameters key, salt, info, and seed correspond to KI, Label, Context, and IV (respectively) in SP800-108. As in that document, salt, info, and seed are optional and may be omitted.

“mac”, “digest”, cipher” and “properties” are described in “PARAMETERS” in EVP_KDF (3).

NOTES

A context for KBKDF can be obtained by calling:

EVP_KDF *kdf = EVP_KDF_fetch(NULL, “KBKDF”, NULL); EVP_KDF_CTX *kctx = EVP_KDF_CTX_new(kdf);

The output length of an KBKDF is specified via the keylen parameter to the EVP_KDF_derive (3) function.

Note that currently OpenSSL only implements counter and feedback modes. Other variants may be supported in the future.

EXAMPLES

This example derives 10 bytes using COUNTER-HMAC-SHA256, with KI “secret”, Label “label”, and Context “context”.

EVP_KDF *kdf; EVP_KDF_CTX *kctx; unsigned char out[10]; OSSL_PARAM params[6], *p = params; kdf = EVP_KDF_fetch(NULL, “KBKDF”, NULL); kctx = EVP_KDF_CTX_new(kdf); EVP_KDF_free(kdf); *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_DIGEST, “SHA2-256”, 0); *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_MAC, “HMAC”, 0); *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_KEY, “secret”, strlen(“secret”)); *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_SALT, “label”, strlen(“label”)); *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_INFO, “context”, strlen(“context”)); *p = OSSL_PARAM_construct_end(); if (EVP_KDF_derive(kctx, out, sizeof(out), params) <= 0) error(“EVP_KDF_derive”); EVP_KDF_CTX_free(kctx);

This example derives 10 bytes using FEEDBACK-CMAC-AES256, with KI “secret”, Label “label”, and IV “sixteen bytes iv”.

EVP_KDF *kdf; EVP_KDF_CTX *kctx; unsigned char out[10]; OSSL_PARAM params[8], *p = params; unsigned char *iv = “sixteen bytes iv”; kdf = EVP_KDF_fetch(NULL, “KBKDF”, NULL); kctx = EVP_KDF_CTX_new(kdf); EVP_KDF_free(kdf); *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_CIPHER, “AES256”, 0); *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_MAC, “CMAC”, 0); *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_MODE, “FEEDBACK”, 0); *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_KEY, “secret”, strlen(“secret”)); *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_SALT, “label”, strlen(“label”)); *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_INFO, “context”, strlen(“context”)); *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_SEED, iv, strlen(iv)); *p = OSSL_PARAM_construct_end(); if (EVP_KDF_derive(kctx, out, sizeof(out), params) <= 0) error(“EVP_KDF_derive”); EVP_KDF_CTX_free(kctx);

CONFORMING TO

NIST SP800-108, IETF RFC 6803, IETF RFC 8009.

SEE ALSO

EVP_KDF (3), EVP_KDF_CTX_free (3), EVP_KDF_CTX_get_kdf_size (3), EVP_KDF_derive (3), “PARAMETERS” in EVP_KDF (3)

HISTORY

This functionality was added in OpenSSL 3.0.

Support for KMAC was added in OpenSSL 3.1.

COPYRIGHT

Copyright 2019-2022 The OpenSSL Project Authors. All Rights Reserved. Copyright 2019 Red Hat, Inc.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

143 - Linux cli command libOpenCL

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command libOpenCL and provides detailed information about the command libOpenCL, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the libOpenCL.

NAME 🖥️ libOpenCL 🖥️

OCL-ICD implementation of OpenCL ICD loader

DESCRIPTION

libOpenCL.so is the library linked by OpenCL programs. It does not contains any OpenCL implementation itself, but merely act as a dispatcher to real OpenCL implementations provided as OpenCL Installable Client Driver (ICD). An ICD loader should be able to load ICDs provided by any vendors.

According to OpenCL specifications from Khronos (see [Khronos]), the ICD Loader looks for files into /etc/OpenCL/vendors directory and, for each file whose name ends with .icd, the ICD Loader loads with dlopen(3) the shared library whose name is on the first line of the .icd file.

Each shared library name in “.icd” files can have its path, or it can be a plain filename. In the latter case, the ICD shared library will be looked for into the standard dynamic library loader paths.

ENVIRONMENT

Some environment variables can be used modify the default behavior of libOpenCL.

OPENCL_VENDOR_PATH

This variable allows one to modify the default /etc/OpenCL/vendors path. It is compatible with some other ICD loaders (but not all of them, as the variable is not part of the standard). Note that $OCL_ICD_VENDORS (see below) is used in priority if defined and not empty.

OCL_ICD_VENDORS

This variable allows one to change the way ICD are searched on the system. Several cases are considered:

1.

if $OCL_ICD_VENDORS is a directory path, then this path replaces the “/etc/OpenCL/vendors” path in the standard behavior: the loader will use the .icd files in this directory;

2.

else, if $OCL_ICD_VENDORS ends with .icd, libOpenCL.so will only load the ICD whose shared library name is wrote into the specified “.icd” file;

If there is no slashes into $OCL_ICD_VENDORS, libOpenCL.so will first try to use /etc/OpenCL/vendors/$OCL_ICD_VENDORS (or $OPENCL_VENDOR_PATH*/*$OCL_ICD_VENDORS if OPENCL_VENDOR_PATH is defined). If this fail or if there are shashes, it uses $OCL_ICD_VENDORS (as a relative or absolute file name path).

3.

else libOpenCL.so will try to load $OCL_ICD_VENDORS as the ICD shared library itself (i.e. to load it directly with dlopen(3)).

OPENCL_LAYERS

This variable allows one to specify a colon separated list of layers to load, specifying their path.

OPENCL_LAYER_PATH

This variable allows one to override the default system layer search path (/etc/OpenCL/layers).

OCL_ICD_ASSUME_ICD_EXTENSION

If set to an non-empty value, contrary the Khronos specification, the loader will not check that the loaded ICDs declare the cl_khr_icd extension. It will also use the clGetPlatformInfo from the dispatch table if no such function is globally available. You may need to define this environment variable if you are using not (fully) compliant ICD, or if you are using the Intel ICD together with optirun(1). In the latter case, a bug into the Intel ICD will make the application crash.

If set to the debug value, some additional messages will be printed in debug mode (see OCL_ICD_DEBUG below).

OCL_ICD_PLATFORM_SORT

Allows one to choose the way platforms are sorted when presented to programs through clGetPlatformIDs(3). Current provided algorithms are:

·

devices: first, list platforms that support most GPU, then most CPU then most accelerators. If OCL_ICD_PLATFORM_SORT is not set or set to an unknown value, this algorithm is used.

·

none: no sort is done and the order can change at each run.

OCL_ICD_DEFAULT_PLATFORM

Number of the platform to choose as default platform. Note that using this environment variable without ensuring the use of a sort algorithm for platforms is not really useful.

OCL_ICD_DEBUG

If ocl-icd has been compiled with debug support, you can set this environment variable to a value where each bit display some kind of informations. Defined values are:

·

1: warnings (enabled by default if debug support is present and OCL_ICD_DEBUG is not set)

·

2: informative messages

·

4: entering/exiting for some OpenCL functions

·

8: dump of the internal structure of loaded ICDs

OCL_ICD_DEBUG is mainly useful for ocl-icd development itself and/or for ICD development.

SEE ALSO

Khronos OpenCL registry website

AUTHOR

Vincent Danjean <[email protected]>

Author.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

144 - Linux cli command fanotify

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command fanotify and provides detailed information about the command fanotify, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the fanotify.

NAME 🖥️ fanotify 🖥️

monitoring filesystem events

DESCRIPTION

The fanotify API provides notification and interception of filesystem events. Use cases include virus scanning and hierarchical storage management. In the original fanotify API, only a limited set of events was supported. In particular, there was no support for create, delete, and move events. The support for those events was added in Linux 5.1. (See inotify(7) for details of an API that did notify those events pre Linux 5.1.)

Additional capabilities compared to the inotify(7) API include the ability to monitor all of the objects in a mounted filesystem, the ability to make access permission decisions, and the possibility to read or modify files before access by other applications.

The following system calls are used with this API: fanotify_init(2), fanotify_mark(2), read(2), write(2), and close(2).

fanotify_init(), fanotify_mark(), and notification groups

The fanotify_init(2) system call creates and initializes an fanotify notification group and returns a file descriptor referring to it.

An fanotify notification group is a kernel-internal object that holds a list of files, directories, filesystems, and mounts for which events shall be created.

For each entry in an fanotify notification group, two bit masks exist: the mark mask and the ignore mask. The mark mask defines file activities for which an event shall be created. The ignore mask defines activities for which no event shall be generated. Having these two types of masks permits a filesystem, mount, or directory to be marked for receiving events, while at the same time ignoring events for specific objects under a mount or directory.

The fanotify_mark(2) system call adds a file, directory, filesystem, or mount to a notification group and specifies which events shall be reported (or ignored), or removes or modifies such an entry.

A possible usage of the ignore mask is for a file cache. Events of interest for a file cache are modification of a file and closing of the same. Hence, the cached directory or mount is to be marked to receive these events. After receiving the first event informing that a file has been modified, the corresponding cache entry will be invalidated. No further modification events for this file are of interest until the file is closed. Hence, the modify event can be added to the ignore mask. Upon receiving the close event, the modify event can be removed from the ignore mask and the file cache entry can be updated.

The entries in the fanotify notification groups refer to files and directories via their inode number and to mounts via their mount ID. If files or directories are renamed or moved within the same mount, the respective entries survive. If files or directories are deleted or moved to another mount or if filesystems or mounts are unmounted, the corresponding entries are deleted.

The event queue

As events occur on the filesystem objects monitored by a notification group, the fanotify system generates events that are collected in a queue. These events can then be read (using read(2) or similar) from the fanotify file descriptor returned by fanotify_init(2).

Two types of events are generated: notification events and permission events. Notification events are merely informative and require no action to be taken by the receiving application with one exception: if a valid file descriptor is provided within a generic event, the file descriptor must be closed. Permission events are requests to the receiving application to decide whether permission for a file access shall be granted. For these events, the recipient must write a response which decides whether access is granted or not.

An event is removed from the event queue of the fanotify group when it has been read. Permission events that have been read are kept in an internal list of the fanotify group until either a permission decision has been taken by writing to the fanotify file descriptor or the fanotify file descriptor is closed.

Reading fanotify events

Calling read(2) for the file descriptor returned by fanotify_init(2) blocks (if the flag FAN_NONBLOCK is not specified in the call to fanotify_init(2)) until either a file event occurs or the call is interrupted by a signal (see signal(7)).

After a successful read(2), the read buffer contains one or more of the following structures:

struct fanotify_event_metadata {
    __u32 event_len;
    __u8 vers;
    __u8 reserved;
    __u16 metadata_len;
    __aligned_u64 mask;
    __s32 fd;
    __s32 pid;
};

Information records are supplemental pieces of information that may be provided alongside the generic fanotify_event_metadata structure. The flags passed to fanotify_init(2) have influence over the type of information records that may be returned for an event. For example, if a notification group is initialized with FAN_REPORT_FID or FAN_REPORT_DIR_FID, then event listeners should also expect to receive a fanotify_event_info_fid structure alongside the fanotify_event_metadata structure, whereby file handles are used to identify filesystem objects rather than file descriptors. Information records may also be stacked, meaning that using the various FAN_REPORT_* flags in conjunction with one another is supported. In such cases, multiple information records can be returned for an event alongside the generic fanotify_event_metadata structure. For example, if a notification group is initialized with FAN_REPORT_TARGET_FID and FAN_REPORT_PIDFD, then an event listener should expect to receive up to two fanotify_event_info_fid information records and one fanotify_event_info_pidfd information record alongside the generic fanotify_event_metadata structure. Importantly, fanotify provides no guarantee around the ordering of information records when a notification group is initialized with a stacked based configuration. Each information record has a nested structure of type fanotify_event_info_header. It is imperative for event listeners to inspect the info_type field of this structure in order to determine the type of information record that had been received for a given event.

In cases where an fanotify group identifies filesystem objects by file handles, event listeners should also expect to receive one or more of the below information record objects alongside the generic fanotify_event_metadata structure within the read buffer:

struct fanotify_event_info_fid {
    struct fanotify_event_info_header hdr;
    __kernel_fsid_t fsid;
    unsigned char handle[];
};

In cases where an fanotify group is initialized with FAN_REPORT_PIDFD, event listeners should expect to receive the below information record object alongside the generic fanotify_event_metadata structure within the read buffer:

struct fanotify_event_info_pidfd {
        struct fanotify_event_info_header hdr;
        __s32 pidfd;
};

In case of a FAN_FS_ERROR event, an additional information record describing the error that occurred is returned alongside the generic fanotify_event_metadata structure within the read buffer. This structure is defined as follows:

struct fanotify_event_info_error {
    struct fanotify_event_info_header hdr;
    __s32 error;
    __u32 error_count;
};

All information records contain a nested structure of type fanotify_event_info_header. This structure holds meta-information about the information record that may have been returned alongside the generic fanotify_event_metadata structure. This structure is defined as follows:

struct fanotify_event_info_header {
	__u8 info_type;
	__u8 pad;
	__u16 len;
};

For performance reasons, it is recommended to use a large buffer size (for example, 4096 bytes), so that multiple events can be retrieved by a single read(2).

The return value of read(2) is the number of bytes placed in the buffer, or -1 in case of an error (but see BUGS).

The fields of the fanotify_event_metadata structure are as follows:

event_len
This is the length of the data for the current event and the offset to the next event in the buffer. Unless the group identifies filesystem objects by file handles, the value of event_len is always FAN_EVENT_METADATA_LEN. For a group that identifies filesystem objects by file handles, event_len also includes the variable length file identifier records.

vers
This field holds a version number for the structure. It must be compared to FANOTIFY_METADATA_VERSION to verify that the structures returned at run time match the structures defined at compile time. In case of a mismatch, the application should abandon trying to use the fanotify file descriptor.

reserved
This field is not used.

metadata_len
This is the length of the structure. The field was introduced to facilitate the implementation of optional headers per event type. No such optional headers exist in the current implementation.

mask
This is a bit mask describing the event (see below).

fd
This is an open file descriptor for the object being accessed, or FAN_NOFD if a queue overflow occurred. With an fanotify group that identifies filesystem objects by file handles, applications should expect this value to be set to FAN_NOFD for each event that is received. The file descriptor can be used to access the contents of the monitored file or directory. The reading application is responsible for closing this file descriptor.

When calling fanotify_init(2), the caller may specify (via the event_f_flags argument) various file status flags that are to be set on the open file description that corresponds to this file descriptor. In addition, the (kernel-internal) FMODE_NONOTIFY file status flag is set on the open file description. This flag suppresses fanotify event generation. Hence, when the receiver of the fanotify event accesses the notified file or directory using this file descriptor, no additional events will be created.

pid
If flag FAN_REPORT_TID was set in fanotify_init(2), this is the TID of the thread that caused the event. Otherwise, this the PID of the process that caused the event.

A program listening to fanotify events can compare this PID to the PID returned by getpid(2), to determine whether the event is caused by the listener itself, or is due to a file access by another process.

The bit mask in mask indicates which events have occurred for a single filesystem object. Multiple bits may be set in this mask, if more than one event occurred for the monitored filesystem object. In particular, consecutive events for the same filesystem object and originating from the same process may be merged into a single event, with the exception that two permission events are never merged into one queue entry.

The bits that may appear in mask are as follows:

FAN_ACCESS
A file or a directory (but see BUGS) was accessed (read).

FAN_OPEN
A file or a directory was opened.

FAN_OPEN_EXEC
A file was opened with the intent to be executed. See NOTES in fanotify_mark(2) for additional details.

FAN_ATTRIB
A file or directory metadata was changed.

FAN_CREATE
A child file or directory was created in a watched parent.

FAN_DELETE
A child file or directory was deleted in a watched parent.

FAN_DELETE_SELF
A watched file or directory was deleted.

FAN_FS_ERROR
A filesystem error was detected.

FAN_RENAME
A file or directory has been moved to or from a watched parent directory.

FAN_MOVED_FROM
A file or directory has been moved from a watched parent directory.

FAN_MOVED_TO
A file or directory has been moved to a watched parent directory.

FAN_MOVE_SELF
A watched file or directory was moved.

FAN_MODIFY
A file was modified.

FAN_CLOSE_WRITE
A file that was opened for writing (O_WRONLY or O_RDWR) was closed.

FAN_CLOSE_NOWRITE
A file or directory that was opened read-only (O_RDONLY) was closed.

FAN_Q_OVERFLOW
The event queue exceeded the limit on number of events. This limit can be overridden by specifying the FAN_UNLIMITED_QUEUE flag when calling fanotify_init(2).

FAN_ACCESS_PERM
An application wants to read a file or directory, for example using read(2) or readdir(2). The reader must write a response (as described below) that determines whether the permission to access the filesystem object shall be granted.

FAN_OPEN_PERM
An application wants to open a file or directory. The reader must write a response that determines whether the permission to open the filesystem object shall be granted.

FAN_OPEN_EXEC_PERM
An application wants to open a file for execution. The reader must write a response that determines whether the permission to open the filesystem object for execution shall be granted. See NOTES in fanotify_mark(2) for additional details.

To check for any close event, the following bit mask may be used:

FAN_CLOSE
A file was closed. This is a synonym for:

FAN_CLOSE_WRITE | FAN_CLOSE_NOWRITE

To check for any move event, the following bit mask may be used:

FAN_MOVE
A file or directory was moved. This is a synonym for:

FAN_MOVED_FROM | FAN_MOVED_TO

The following bits may appear in mask only in conjunction with other event type bits:

FAN_ONDIR
The events described in the mask have occurred on a directory object. Reporting events on directories requires setting this flag in the mark mask. See fanotify_mark(2) for additional details. The FAN_ONDIR flag is reported in an event mask only if the fanotify group identifies filesystem objects by file handles.

Information records that are supplied alongside the generic fanotify_event_metadata structure will always contain a nested structure of type fanotify_event_info_header. The fields of the fanotify_event_info_header are as follows:

info_type
A unique integer value representing the type of information record object received for an event. The value of this field can be set to one of the following: FAN_EVENT_INFO_TYPE_FID, FAN_EVENT_INFO_TYPE_DFID, FAN_EVENT_INFO_TYPE_DFID_NAME, or FAN_EVENT_INFO_TYPE_PIDFD. The value set for this field is dependent on the flags that have been supplied to fanotify_init(2). Refer to the field details of each information record object type below to understand the different cases in which the info_type values can be set.

pad
This field is currently not used by any information record object type and therefore is set to zero.

len
The value of len is set to the size of the information record object, including the fanotify_event_info_header. The total size of all additional information records is not expected to be larger than (event_len - metadata_len).

The fields of the fanotify_event_info_fid structure are as follows:

hdr
This is a structure of type fanotify_event_info_header. For example, when an fanotify file descriptor is created using FAN_REPORT_FID, a single information record is expected to be attached to the event with info_type field value of FAN_EVENT_INFO_TYPE_FID. When an fanotify file descriptor is created using the combination of FAN_REPORT_FID and FAN_REPORT_DIR_FID, there may be two information records attached to the event: one with info_type field value of FAN_EVENT_INFO_TYPE_DFID, identifying a parent directory object, and one with info_type field value of FAN_EVENT_INFO_TYPE_FID, identifying a child object. Note that for the directory entry modification events FAN_CREATE, FAN_DELETE, FAN_MOVE, and FAN_RENAME, an information record identifying the created/deleted/moved child object is reported only if an fanotify group was initialized with the flag FAN_REPORT_TARGET_FID.

fsid
This is a unique identifier of the filesystem containing the object associated with the event. It is a structure of type __kernel_fsid_t and contains the same value as f_fsid when calling statfs(2).

handle
This field contains a variable-length structure of type struct file_handle. It is an opaque handle that corresponds to a specified object on a filesystem as returned by name_to_handle_at(2). It can be used to uniquely identify a file on a filesystem and can be passed as an argument to open_by_handle_at(2). If the value of info_type field is FAN_EVENT_INFO_TYPE_DFID_NAME, the file handle is followed by a null terminated string that identifies the created/deleted/moved directory entry name. For other events such as FAN_OPEN, FAN_ATTRIB, FAN_DELETE_SELF, and FAN_MOVE_SELF, if the value of info_type field is FAN_EVENT_INFO_TYPE_FID, the handle identifies the object correlated to the event. If the value of info_type field is FAN_EVENT_INFO_TYPE_DFID, the handle identifies the directory object correlated to the event or the parent directory of a non-directory object correlated to the event. If the value of info_type field is FAN_EVENT_INFO_TYPE_DFID_NAME, the handle identifies the same directory object that would be reported with FAN_EVENT_INFO_TYPE_DFID and the file handle is followed by a null terminated string that identifies the name of a directory entry in that directory, or ‘.’ to identify the directory object itself.

The fields of the fanotify_event_info_pidfd structure are as follows:

hdr
This is a structure of type fanotify_event_info_header. When an fanotify group is initialized using FAN_REPORT_PIDFD, the info_type field value of the fanotify_event_info_header is set to FAN_EVENT_INFO_TYPE_PIDFD.

pidfd
This is a process file descriptor that refers to the process responsible for generating the event. The returned process file descriptor is no different from one which could be obtained manually if pidfd_open(2) were to be called on fanotify_event_metadata.pid. In the instance that an error is encountered during pidfd creation, one of two possible error types represented by a negative integer value may be returned in this pidfd field. In cases where the process responsible for generating the event has terminated prior to the event listener being able to read events from the notification queue, FAN_NOPIDFD is returned. The pidfd creation for an event is only performed at the time the events are read from the notification queue. All other possible pidfd creation failures are represented by FAN_EPIDFD. Once the event listener has dealt with an event and the pidfd is no longer required, the pidfd should be closed via close(2).

The fields of the fanotify_event_info_error structure are as follows:

hdr
This is a structure of type fanotify_event_info_header. The info_type field is set to FAN_EVENT_INFO_TYPE_ERROR.

error
Identifies the type of error that occurred.

error_count
This is a counter of the number of errors suppressed since the last error was read.

The following macros are provided to iterate over a buffer containing fanotify event metadata returned by a read(2) from an fanotify file descriptor:

FAN_EVENT_OK(meta, len)
This macro checks the remaining length len of the buffer meta against the length of the metadata structure and the event_len field of the first metadata structure in the buffer.

FAN_EVENT_NEXT(meta, len)
This macro uses the length indicated in the event_len field of the metadata structure pointed to by meta to calculate the address of the next metadata structure that follows meta. len is the number of bytes of metadata that currently remain in the buffer. The macro returns a pointer to the next metadata structure that follows meta, and reduces len by the number of bytes in the metadata structure that has been skipped over (i.e., it subtracts meta->event_len from len).

In addition, there is:

FAN_EVENT_METADATA_LEN
This macro returns the size (in bytes) of the structure fanotify_event_metadata. This is the minimum size (and currently the only size) of any event metadata.

Monitoring an fanotify file descriptor for events

When an fanotify event occurs, the fanotify file descriptor indicates as readable when passed to epoll(7), poll(2), or select(2).

Dealing with permission events

For permission events, the application must write(2) a structure of the following form to the fanotify file descriptor:

struct fanotify_response {
    __s32 fd;
    __u32 response;
};

The fields of this structure are as follows:

fd
This is the file descriptor from the structure fanotify_event_metadata.

response
This field indicates whether or not the permission is to be granted. Its value must be either FAN_ALLOW to allow the file operation or FAN_DENY to deny the file operation.

If access is denied, the requesting application call will receive an EPERM error. Additionally, if the notification group has been created with the FAN_ENABLE_AUDIT flag, then the FAN_AUDIT flag can be set in the response field. In that case, the audit subsystem will log information about the access decision to the audit logs.

Monitoring filesystems for errors

A single FAN_FS_ERROR event is stored per filesystem at once. Extra error messages are suppressed and accounted for in the error_count field of the existing FAN_FS_ERROR event record, but details about the errors are lost.

Errors reported by FAN_FS_ERROR are generic errno values, but not all kinds of error types are reported by all filesystems.

Errors not directly related to a file (i.e. super block corruption) are reported with an invalid handle. For these errors, the handle will have the field handle_type set to FILEID_INVALID, and the handle buffer size set to 0.

Closing the fanotify file descriptor

When all file descriptors referring to the fanotify notification group are closed, the fanotify group is released and its resources are freed for reuse by the kernel. Upon close(2), outstanding permission events will be set to allowed.

/proc interfaces

The file */proc/pid/fdinfo/*fd contains information about fanotify marks for file descriptor fd of process pid. See proc(5) for details.

Since Linux 5.13, the following interfaces can be used to control the amount of kernel resources consumed by fanotify:

/proc/sys/fs/fanotify/max_queued_events
The value in this file is used when an application calls fanotify_init(2) to set an upper limit on the number of events that can be queued to the corresponding fanotify group. Events in excess of this limit are dropped, but an FAN_Q_OVERFLOW event is always generated. Prior to Linux kernel 5.13, the hardcoded limit was 16384 events.

/proc/sys/fs/fanotify/max_user_group
This specifies an upper limit on the number of fanotify groups that can be created per real user ID. Prior to Linux kernel 5.13, the hardcoded limit was 128 groups per user.

/proc/sys/fs/fanotify/max_user_marks
This specifies an upper limit on the number of fanotify marks that can be created per real user ID. Prior to Linux kernel 5.13, the hardcoded limit was 8192 marks per group (not per user).

ERRORS

In addition to the usual errors for read(2), the following errors can occur when reading from the fanotify file descriptor:

EINVAL
The buffer is too small to hold the event.

EMFILE
The per-process limit on the number of open files has been reached. See the description of RLIMIT_NOFILE in getrlimit(2).

ENFILE
The system-wide limit on the total number of open files has been reached. See /proc/sys/fs/file-max in proc(5).

ETXTBSY
This error is returned by read(2) if O_RDWR or O_WRONLY was specified in the event_f_flags argument when calling fanotify_init(2) and an event occurred for a monitored file that is currently being executed.

In addition to the usual errors for write(2), the following errors can occur when writing to the fanotify file descriptor:

EINVAL
Fanotify access permissions are not enabled in the kernel configuration or the value of response in the response structure is not valid.

ENOENT
The file descriptor fd in the response structure is not valid. This may occur when a response for the permission event has already been written.

STANDARDS

Linux.

HISTORY

The fanotify API was introduced in Linux 2.6.36 and enabled in Linux 2.6.37. fdinfo support was added in Linux 3.8.

NOTES

The fanotify API is available only if the kernel was built with the CONFIG_FANOTIFY configuration option enabled. In addition, fanotify permission handling is available only if the CONFIG_FANOTIFY_ACCESS_PERMISSIONS configuration option is enabled.

Limitations and caveats

Fanotify reports only events that a user-space program triggers through the filesystem API. As a result, it does not catch remote events that occur on network filesystems.

The fanotify API does not report file accesses and modifications that may occur because of mmap(2), msync(2), and munmap(2).

Events for directories are created only if the directory itself is opened, read, and closed. Adding, removing, or changing children of a marked directory does not create events for the monitored directory itself.

Fanotify monitoring of directories is not recursive: to monitor subdirectories under a directory, additional marks must be created. The FAN_CREATE event can be used for detecting when a subdirectory has been created under a marked directory. An additional mark must then be set on the newly created subdirectory. This approach is racy, because it can lose events that occurred inside the newly created subdirectory, before a mark is added on that subdirectory. Monitoring mounts offers the capability to monitor a whole directory tree in a race-free manner. Monitoring filesystems offers the capability to monitor changes made from any mount of a filesystem instance in a race-free manner.

The event queue can overflow. In this case, events are lost.

BUGS

Before Linux 3.19, fallocate(2) did not generate fanotify events. Since Linux 3.19, calls to fallocate(2) generate FAN_MODIFY events.

As of Linux 3.17, the following bugs exist:

  • On Linux, a filesystem object may be accessible through multiple paths, for example, a part of a filesystem may be remounted using the –bind option of mount(8). A listener that marked a mount will be notified only of events that were triggered for a filesystem object using the same mount. Any other event will pass unnoticed.

  • When an event is generated, no check is made to see whether the user ID of the receiving process has authorization to read or write the file before passing a file descriptor for that file. This poses a security risk, when the CAP_SYS_ADMIN capability is set for programs executed by unprivileged users.

  • If a call to read(2) processes multiple events from the fanotify queue and an error occurs, the return value will be the total length of the events successfully copied to the user-space buffer before the error occurred. The return value will not be -1, and errno will not be set. Thus, the reading application has no way to detect the error.

EXAMPLES

The two example programs below demonstrate the usage of the fanotify API.

Example program: fanotify_example.c

The first program is an example of fanotify being used with its event object information passed in the form of a file descriptor. The program marks the mount passed as a command-line argument and waits for events of type FAN_OPEN_PERM and FAN_CLOSE_WRITE. When a permission event occurs, a FAN_ALLOW response is given.

The following shell session shows an example of running this program. This session involved editing the file /home/user/temp/notes. Before the file was opened, a FAN_OPEN_PERM event occurred. After the file was closed, a FAN_CLOSE_WRITE event occurred. Execution of the program ends when the user presses the ENTER key.

# ./fanotify_example /home
Press enter key to terminate.
Listening for events.
FAN_OPEN_PERM: File /home/user/temp/notes
FAN_CLOSE_WRITE: File /home/user/temp/notes
Listening for events stopped.

Program source: fanotify_example.c

#define _GNU_SOURCE     /* Needed to get O_LARGEFILE definition */
#include <errno.h>
#include <fcntl.h>
#include <limits.h>
#include <poll.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/fanotify.h>
#include <unistd.h>
/* Read all available fanotify events from the file descriptor 'fd'. */
static void
handle_events(int fd)
{
    const struct fanotify_event_metadata *metadata;
    struct fanotify_event_metadata buf[200];
    ssize_t len;
    char path[PATH_MAX];
    ssize_t path_len;
    char procfd_path[PATH_MAX];
    struct fanotify_response response;
    /* Loop while events can be read from fanotify file descriptor. */
    for (;;) {
        /* Read some events. */
        len = read(fd, buf, sizeof(buf));
        if (len == -1 && errno != EAGAIN) {
            perror("read");
            exit(EXIT_FAILURE);
        }
        /* Check if end of available data reached. */
        if (len <= 0)
            break;
        /* Point to the first event in the buffer. */
        metadata = buf;
        /* Loop over all events in the buffer. */
        while (FAN_EVENT_OK(metadata, len)) {
            /* Check that run-time and compile-time structures match. */
            if (metadata->vers != FANOTIFY_METADATA_VERSION) {
                fprintf(stderr,
                        "Mismatch of fanotify metadata version.

“); exit(EXIT_FAILURE); } /* metadata->fd contains either FAN_NOFD, indicating a queue overflow, or a file descriptor (a nonnegative integer). Here, we simply ignore queue overflow. / if (metadata->fd >= 0) { / Handle open permission event. / if (metadata->mask & FAN_OPEN_PERM) { printf(“FAN_OPEN_PERM: “); / Allow file to be opened. / response.fd = metadata->fd; response.response = FAN_ALLOW; write(fd, &response, sizeof(response)); } / Handle closing of writable file event. / if (metadata->mask & FAN_CLOSE_WRITE) printf(“FAN_CLOSE_WRITE: “); / Retrieve and print pathname of the accessed file. / snprintf(procfd_path, sizeof(procfd_path), “/proc/self/fd/%d”, metadata->fd); path_len = readlink(procfd_path, path, sizeof(path) - 1); if (path_len == -1) { perror(“readlink”); exit(EXIT_FAILURE); } path[path_len] = ‘�’; printf(“File %s “, path); / Close the file descriptor of the event. / close(metadata->fd); } / Advance to next event. */ metadata = FAN_EVENT_NEXT(metadata, len); } } } int main(int argc, char argv[]) { char buf; int fd, poll_num; nfds_t nfds; struct pollfd fds[2]; / Check mount point is supplied. / if (argc != 2) { fprintf(stderr, “Usage: %s MOUNT “, argv[0]); exit(EXIT_FAILURE); } printf(“Press enter key to terminate. “); / Create the file descriptor for accessing the fanotify API. / fd = fanotify_init(FAN_CLOEXEC | FAN_CLASS_CONTENT | FAN_NONBLOCK, O_RDONLY | O_LARGEFILE); if (fd == -1) { perror(“fanotify_init”); exit(EXIT_FAILURE); } / Mark the mount for: - permission events before opening files - notification events after closing a write-enabled file descriptor. / if (fanotify_mark(fd, FAN_MARK_ADD | FAN_MARK_MOUNT, FAN_OPEN_PERM | FAN_CLOSE_WRITE, AT_FDCWD, argv[1]) == -1) { perror(“fanotify_mark”); exit(EXIT_FAILURE); } / Prepare for polling. / nfds = 2; fds[0].fd = STDIN_FILENO; / Console input / fds[0].events = POLLIN; fds[1].fd = fd; / Fanotify input / fds[1].events = POLLIN; / This is the loop to wait for incoming events. / printf(“Listening for events. “); while (1) { poll_num = poll(fds, nfds, -1); if (poll_num == -1) { if (errno == EINTR) / Interrupted by a signal / continue; / Restart poll() / perror(“poll”); / Unexpected error / exit(EXIT_FAILURE); } if (poll_num > 0) { if (fds[0].revents & POLLIN) { / Console input is available: empty stdin and quit. / while (read(STDIN_FILENO, &buf, 1) > 0 && buf != ' ‘) continue; break; } if (fds[1].revents & POLLIN) { / Fanotify events are available. */ handle_events(fd); } } } printf(“Listening for events stopped. “); exit(EXIT_SUCCESS); }

Example program: fanotify_fid.c

The second program is an example of fanotify being used with a group that identifies objects by file handles. The program marks the filesystem object that is passed as a command-line argument and waits until an event of type FAN_CREATE has occurred. The event mask indicates which type of filesystem object—either a file or a directory—was created. Once all events have been read from the buffer and processed accordingly, the program simply terminates.

The following shell sessions show two different invocations of this program, with different actions performed on a watched object.

The first session shows a mark being placed on /home/user. This is followed by the creation of a regular file, /home/user/testfile.txt. This results in a FAN_CREATE event being generated and reported against the file’s parent watched directory object and with the created file name. Program execution ends once all events captured within the buffer have been processed.

# ./fanotify_fid /home/user
Listening for events.
FAN_CREATE (file created):
        Directory /home/user has been modified.
        Entry 'testfile.txt' is not a subdirectory.
All events processed successfully. Program exiting.
$ touch /home/user/testfile.txt              # In another terminal

The second session shows a mark being placed on /home/user. This is followed by the creation of a directory, /home/user/testdir. This specific action results in a FAN_CREATE event being generated and is reported with the FAN_ONDIR flag set and with the created directory name.

# ./fanotify_fid /home/user
Listening for events.
FAN_CREATE | FAN_ONDIR (subdirectory created):
        Directory /home/user has been modified.
        Entry 'testdir' is a subdirectory.
All events processed successfully. Program exiting.
$ mkdir -p /home/user/testdir          # In another terminal

Program source: fanotify_fid.c

#define _GNU_SOURCE
#include <errno.h>
#include <fcntl.h>
#include <limits.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/fanotify.h>
#include <unistd.h>
#define BUF_SIZE 256
int
main(int argc, char *argv[])
{
    int fd, ret, event_fd, mount_fd;
    ssize_t len, path_len;
    char path[PATH_MAX];
    char procfd_path[PATH_MAX];
    char events_buf[BUF_SIZE];
    struct file_handle *file_handle;
    struct fanotify_event_metadata *metadata;
    struct fanotify_event_info_fid *fid;
    const char *file_name;
    struct stat sb;
    if (argc != 2) {
        fprintf(stderr, "Invalid number of command line arguments.

“); exit(EXIT_FAILURE); } mount_fd = open(argv[1], O_DIRECTORY | O_RDONLY); if (mount_fd == -1) { perror(argv[1]); exit(EXIT_FAILURE); } /* Create an fanotify file descriptor with FAN_REPORT_DFID_NAME as a flag so that program can receive fid events with directory entry name. / fd = fanotify_init(FAN_CLASS_NOTIF | FAN_REPORT_DFID_NAME, 0); if (fd == -1) { perror(“fanotify_init”); exit(EXIT_FAILURE); } / Place a mark on the filesystem object supplied in argv[1]. / ret = fanotify_mark(fd, FAN_MARK_ADD | FAN_MARK_ONLYDIR, FAN_CREATE | FAN_ONDIR, AT_FDCWD, argv[1]); if (ret == -1) { perror(“fanotify_mark”); exit(EXIT_FAILURE); } printf(“Listening for events. “); / Read events from the event queue into a buffer. / len = read(fd, events_buf, sizeof(events_buf)); if (len == -1 && errno != EAGAIN) { perror(“read”); exit(EXIT_FAILURE); } / Process all events within the buffer. */ for (metadata = (struct fanotify_event_metadata *) events_buf; FAN_EVENT_OK(metadata, len); metadata = FAN_EVENT_NEXT(metadata, len)) { fid = (struct fanotify_event_info_fid *) (metadata + 1); file_handle = (struct file_handle ) fid->handle; / Ensure that the event info is of the correct type. / if (fid->hdr.info_type == FAN_EVENT_INFO_TYPE_FID || fid->hdr.info_type == FAN_EVENT_INFO_TYPE_DFID) { file_name = NULL; } else if (fid->hdr.info_type == FAN_EVENT_INFO_TYPE_DFID_NAME) { file_name = file_handle->f_handle + file_handle->handle_bytes; } else { fprintf(stderr, “Received unexpected event info type. “); exit(EXIT_FAILURE); } if (metadata->mask == FAN_CREATE) printf(“FAN_CREATE (file created): “); if (metadata->mask == (FAN_CREATE | FAN_ONDIR)) printf(“FAN_CREATE | FAN_ONDIR (subdirectory created): “); / metadata->fd is set to FAN_NOFD when the group identifies objects by file handles. To obtain a file descriptor for the file object corresponding to an event you can use the struct file_handle that’s provided within the fanotify_event_info_fid in conjunction with the open_by_handle_at(2) system call. A check for ESTALE is done to accommodate for the situation where the file handle for the object was deleted prior to this system call. / event_fd = open_by_handle_at(mount_fd, file_handle, O_RDONLY); if (event_fd == -1) { if (errno == ESTALE) { printf(“File handle is no longer valid. " “File has been deleted “); continue; } else { perror(“open_by_handle_at”); exit(EXIT_FAILURE); } } snprintf(procfd_path, sizeof(procfd_path), “/proc/self/fd/%d”, event_fd); / Retrieve and print the path of the modified dentry. / path_len = readlink(procfd_path, path, sizeof(path) - 1); if (path_len == -1) { perror(“readlink”); exit(EXIT_FAILURE); } path[path_len] = ‘�’; printf(” Directory ‘%s’ has been modified. “, path); if (file_name) { ret = fstatat(event_fd, file_name, &sb, 0); if (ret == -1) { if (errno != ENOENT) { perror(“fstatat”); exit(EXIT_FAILURE); } printf(” Entry ‘%s’ does not exist. “, file_name); } else if ((sb.st_mode & S_IFMT) == S_IFDIR) { printf(” Entry ‘%s’ is a subdirectory. “, file_name); } else { printf(” Entry ‘%s’ is not a subdirectory. “, file_name); } } / Close associated file descriptor for this event. */ close(event_fd); } printf(“All events processed successfully. Program exiting. “); exit(EXIT_SUCCESS); }

SEE ALSO

fanotify_init(2), fanotify_mark(2), inotify(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

145 - Linux cli command CREATE_OPERATOR

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_OPERATOR and provides detailed information about the command CREATE_OPERATOR, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_OPERATOR.

NAME 🖥️ CREATE_OPERATOR 🖥️

define a new operator

SYNOPSIS

CREATE OPERATOR name (
    {FUNCTION|PROCEDURE} = function_name
    [, LEFTARG = left_type ] [, RIGHTARG = right_type ]
    [, COMMUTATOR = com_op ] [, NEGATOR = neg_op ]
    [, RESTRICT = res_proc ] [, JOIN = join_proc ]
    [, HASHES ] [, MERGES ]
)

DESCRIPTION

CREATE OPERATOR defines a new operator, name. The user who defines an operator becomes its owner. If a schema name is given then the operator is created in the specified schema. Otherwise it is created in the current schema.

The operator name is a sequence of up to NAMEDATALEN-1 (63 by default) characters from the following list:

      • / < > = ~ ! @ # % ^ & | ` ?

There are a few restrictions on your choice of name:

·

– and /* cannot appear anywhere in an operator name, since they will be taken as the start of a comment.

·

A multicharacter operator name cannot end in + or -, unless the name also contains at least one of these characters:

~ ! @ # % ^ & | ` ?

For example, @- is an allowed operator name, but *- is not. This restriction allows PostgreSQL to parse SQL-compliant commands without requiring spaces between tokens.

·

The symbol => is reserved by the SQL grammar, so it cannot be used as an operator name.

The operator != is mapped to <> on input, so these two names are always equivalent.

For binary operators, both LEFTARG and RIGHTARG must be defined. For prefix operators only RIGHTARG should be defined. The function_name function must have been previously defined using CREATE FUNCTION and must be defined to accept the correct number of arguments (either one or two) of the indicated types.

In the syntax of CREATE OPERATOR, the keywords FUNCTION and PROCEDURE are equivalent, but the referenced function must in any case be a function, not a procedure. The use of the keyword PROCEDURE here is historical and deprecated.

The other clauses specify optional operator optimization clauses. Their meaning is detailed in Section 38.15.

To be able to create an operator, you must have USAGE privilege on the argument types and the return type, as well as EXECUTE privilege on the underlying function. If a commutator or negator operator is specified, you must own these operators.

PARAMETERS

name

The name of the operator to be defined. See above for allowable characters. The name can be schema-qualified, for example CREATE OPERATOR myschema.+ (…). If not, then the operator is created in the current schema. Two operators in the same schema can have the same name if they operate on different data types. This is called overloading.

function_name

The function used to implement this operator.

left_type

The data type of the operators left operand, if any. This option would be omitted for a prefix operator.

right_type

The data type of the operators right operand.

com_op

The commutator of this operator.

neg_op

The negator of this operator.

res_proc

The restriction selectivity estimator function for this operator.

join_proc

The join selectivity estimator function for this operator.

HASHES

Indicates this operator can support a hash join.

MERGES

Indicates this operator can support a merge join.

To give a schema-qualified operator name in com_op or the other optional arguments, use the OPERATOR() syntax, for example:

COMMUTATOR = OPERATOR(myschema.===) ,

NOTES

Refer to Section 38.14 for further information.

It is not possible to specify an operators lexical precedence in CREATE OPERATOR, because the parsers precedence behavior is hard-wired. See Section 4.1.6 for precedence details.

The obsolete options SORT1, SORT2, LTCMP, and GTCMP were formerly used to specify the names of sort operators associated with a merge-joinable operator. This is no longer necessary, since information about associated operators is found by looking at B-tree operator families instead. If one of these options is given, it is ignored except for implicitly setting MERGES true.

Use DROP OPERATOR to delete user-defined operators from a database. Use ALTER OPERATOR to modify operators in a database.

EXAMPLES

The following command defines a new operator, area-equality, for the data type box:

CREATE OPERATOR === ( LEFTARG = box, RIGHTARG = box, FUNCTION = area_equal_function, COMMUTATOR = ===, NEGATOR = !==, RESTRICT = area_restriction_function, JOIN = area_join_function, HASHES, MERGES );

COMPATIBILITY

CREATE OPERATOR is a PostgreSQL extension. There are no provisions for user-defined operators in the SQL standard.

SEE ALSO

ALTER OPERATOR (ALTER_OPERATOR(7)), CREATE OPERATOR CLASS (CREATE_OPERATOR_CLASS(7)), DROP OPERATOR (DROP_OPERATOR(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

146 - Linux cli command EVP_MD-SM3ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_MD-SM3ssl and provides detailed information about the command EVP_MD-SM3ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_MD-SM3ssl.

NAME 🖥️ EVP_MD-SM3ssl 🖥️

SM3 - The SM3 EVP_MD implementations

DESCRIPTION

Support for computing SM3 digests through the EVP_MD API.

Identity

This implementation is only available with the default provider, and is identified with the name “SM3”.

Gettable Parameters

This implementation supports the common gettable parameters described in EVP_MD-common (7).

SEE ALSO

provider-digest (7), OSSL_PROVIDER-default (7)

COPYRIGHT

Copyright 2020 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

147 - Linux cli command EVP_CIPHER-ARIAssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_CIPHER-ARIAssl and provides detailed information about the command EVP_CIPHER-ARIAssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_CIPHER-ARIAssl.

NAME 🖥️ EVP_CIPHER-ARIAssl 🖥️

ARIA - The ARIA EVP_CIPHER implementations

DESCRIPTION

Support for ARIA symmetric encryption using the EVP_CIPHER API.

Algorithm Names

The following algorithms are available in the default provider:

“ARIA-128-CBC”, “ARIA-192-CBC” and “ARIA-256-CBC”

“ARIA-128-CFB”, “ARIA-192-CFB”, “ARIA-256-CFB”, “ARIA-128-CFB1”, “ARIA-192-CFB1”, “ARIA-256-CFB1”, “ARIA-128-CFB8”, “ARIA-192-CFB8” and “ARIA-256-CFB8”

“ARIA-128-CTR”, “ARIA-192-CTR” and “ARIA-256-CTR”

“ARIA-128-ECB”, “ARIA-192-ECB” and “ARIA-256-ECB”

“AES-192-OCB”, “AES-128-OCB” and “AES-256-OCB”

“ARIA-128-OFB”, “ARIA-192-OFB” and “ARIA-256-OFB”

“ARIA-128-CCM”, “ARIA-192-CCM” and “ARIA-256-CCM”

“ARIA-128-GCM”, “ARIA-192-GCM” and “ARIA-256-GCM”

Parameters

This implementation supports the parameters described in “PARAMETERS” in EVP_EncryptInit (3).

SEE ALSO

provider-cipher (7), OSSL_PROVIDER-default (7)

COPYRIGHT

Copyright 2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

148 - Linux cli command ip

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ip and provides detailed information about the command ip, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ip.

NAME 🖥️ ip 🖥️

Linux IPv4 protocol implementation

SYNOPSIS

#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/ip.h> /* superset of previous */
tcp_socket = socket(AF_INET, SOCK_STREAM, 0);
udp_socket = socket(AF_INET, SOCK_DGRAM, 0);
raw_socket = socket(AF_INET, SOCK_RAW, protocol);

DESCRIPTION

Linux implements the Internet Protocol, version 4, described in RFC 791 and RFC 1122. ip contains a level 2 multicasting implementation conforming to RFC 1112. It also contains an IP router including a packet filter.

The programming interface is BSD-sockets compatible. For more information on sockets, see socket(7).

An IP socket is created using socket(2):

socket(AF_INET, socket_type, protocol);

Valid socket types include SOCK_STREAM to open a stream socket, SOCK_DGRAM to open a datagram socket, and SOCK_RAW to open a raw(7) socket to access the IP protocol directly.

protocol is the IP protocol in the IP header to be received or sent. Valid values for protocol include:

  • 0 and IPPROTO_TCP for tcp(7) stream sockets;

  • 0 and IPPROTO_UDP for udp(7) datagram sockets;

  • IPPROTO_SCTP for sctp(7) stream sockets; and

  • IPPROTO_UDPLITE for udplite(7) datagram sockets.

For SOCK_RAW you may specify a valid IANA IP protocol defined in RFC 1700 assigned numbers.

When a process wants to receive new incoming packets or connections, it should bind a socket to a local interface address using bind(2). In this case, only one IP socket may be bound to any given local (address, port) pair. When INADDR_ANY is specified in the bind call, the socket will be bound to all local interfaces. When listen(2) is called on an unbound socket, the socket is automatically bound to a random free port with the local address set to INADDR_ANY. When connect(2) is called on an unbound socket, the socket is automatically bound to a random free port or to a usable shared port with the local address set to INADDR_ANY.

A TCP local socket address that has been bound is unavailable for some time after closing, unless the SO_REUSEADDR flag has been set. Care should be taken when using this flag as it makes TCP less reliable.

Address format

An IP socket address is defined as a combination of an IP interface address and a 16-bit port number. The basic IP protocol does not supply port numbers, they are implemented by higher level protocols like udp(7) and tcp(7). On raw sockets sin_port is set to the IP protocol.

struct sockaddr_in {
    sa_family_t    sin_family; /* address family: AF_INET */
    in_port_t      sin_port;   /* port in network byte order */
    struct in_addr sin_addr;   /* internet address */
};
/* Internet address */
struct in_addr {
    uint32_t       s_addr;     /* address in network byte order */
};

sin_family is always set to AF_INET. This is required; in Linux 2.2 most networking functions return EINVAL when this setting is missing. sin_port contains the port in network byte order. The port numbers below 1024 are called privileged ports (or sometimes: reserved ports). Only a privileged process (on Linux: a process that has the CAP_NET_BIND_SERVICE capability in the user namespace governing its network namespace) may bind(2) to these sockets. Note that the raw IPv4 protocol as such has no concept of a port, they are implemented only by higher protocols like tcp(7) and udp(7).

sin_addr is the IP host address. The s_addr member of struct in_addr contains the host interface address in network byte order. in_addr should be assigned one of the INADDR_* values (e.g., INADDR_LOOPBACK) using htonl(3) or set using the inet_aton(3), inet_addr(3), inet_makeaddr(3) library functions or directly with the name resolver (see gethostbyname(3)).

IPv4 addresses are divided into unicast, broadcast, and multicast addresses. Unicast addresses specify a single interface of a host, broadcast addresses specify all hosts on a network, and multicast addresses address all hosts in a multicast group. Datagrams to broadcast addresses can be sent or received only when the SO_BROADCAST socket flag is set. In the current implementation, connection-oriented sockets are allowed to use only unicast addresses.

Note that the address and the port are always stored in network byte order. In particular, this means that you need to call htons(3) on the number that is assigned to a port. All address/port manipulation functions in the standard library work in network byte order.

Special and reserved addresses

There are several special addresses:

INADDR_LOOPBACK (127.0.0.1)
always refers to the local host via the loopback device;

INADDR_ANY (0.0.0.0)
means any address for socket binding;

INADDR_BROADCAST (255.255.255.255)
has the same effect on bind(2) as INADDR_ANY for historical reasons. A packet addressed to INADDR_BROADCAST through a socket which has SO_BROADCAST set will be broadcast to all hosts on the local network segment, as long as the link is broadcast-capable.

Highest-numbered address
Lowest-numbered address
On any locally-attached non-point-to-point IP subnet with a link type that supports broadcasts, the highest-numbered address (e.g., the .255 address on a subnet with netmask 255.255.255.0) is designated as a broadcast address. It cannot usefully be assigned to an individual interface, and can only be addressed with a socket on which the SO_BROADCAST option has been set. Internet standards have historically also reserved the lowest-numbered address (e.g., the .0 address on a subnet with netmask 255.255.255.0) for broadcast, though they call it “obsolete” for this purpose. (Some sources also refer to this as the “network address.”) Since Linux 5.14, it is treated as an ordinary unicast address and can be assigned to an interface.

Internet standards have traditionally also reserved various addresses for particular uses, though Linux no longer treats some of these specially.

[0.0.0.1, 0.255.255.255]
[240.0.0.0, 255.255.255.254]
Addresses in these ranges (0/8 and 240/4) are reserved globally. Since Linux 5.3 and Linux 2.6.25, respectively, the 0/8 and 240/4 addresses, other than INADDR_ANY and INADDR_BROADCAST, are treated as ordinary unicast addresses. Systems that follow the traditional behaviors may not interoperate with these historically reserved addresses.

[127.0.0.1, 127.255.255.254]
Addresses in this range (127/8) are treated as loopback addresses akin to the standardized local loopback address INADDR_LOOPBACK (127.0.0.1);

[224.0.0.0, 239.255.255.255]
Addresses in this range (224/4) are dedicated to multicast use.

Socket options

IP supports some protocol-specific socket options that can be set with setsockopt(2) and read with getsockopt(2). The socket option level for IP is IPPROTO_IP. A boolean integer flag is zero when it is false, otherwise true.

When an invalid socket option is specified, getsockopt(2) and setsockopt(2) fail with the error ENOPROTOOPT.

IP_ADD_MEMBERSHIP (since Linux 1.2)
Join a multicast group. Argument is an ip_mreqn structure.

struct ip_mreqn {
    struct in_addr imr_multiaddr; /* IP multicast group
                                     address */
    struct in_addr imr_address;   /* IP address of local
                                     interface */
    int            imr_ifindex;   /* interface index */
};

imr_multiaddr contains the address of the multicast group the application wants to join or leave. It must be a valid multicast address (or setsockopt(2) fails with the error EINVAL). imr_address is the address of the local interface with which the system should join the multicast group; if it is equal to INADDR_ANY, an appropriate interface is chosen by the system. imr_ifindex is the interface index of the interface that should join/leave the imr_multiaddr group, or 0 to indicate any interface.

The ip_mreqn structure is available only since Linux 2.2. For compatibility, the old ip_mreq structure (present since Linux 1.2) is still supported; it differs from ip_mreqn only by not including the imr_ifindex field. (The kernel determines which structure is being passed based on the size passed in optlen.)

IP_ADD_MEMBERSHIP is valid only for setsockopt(2).

IP_ADD_SOURCE_MEMBERSHIP (since Linux 2.4.22 / Linux 2.5.68)
Join a multicast group and allow receiving data only from a specified source. Argument is an ip_mreq_source structure.

struct ip_mreq_source {
    struct in_addr imr_multiaddr;  /* IP multicast group
                                      address */
    struct in_addr imr_interface;  /* IP address of local
                                      interface */
    struct in_addr imr_sourceaddr; /* IP address of
                                      multicast source */
};

The ip_mreq_source structure is similar to ip_mreqn described under IP_ADD_MEMBERSHIP. The imr_multiaddr field contains the address of the multicast group the application wants to join or leave. The imr_interface field is the address of the local interface with which the system should join the multicast group. Finally, the imr_sourceaddr field contains the address of the source the application wants to receive data from.

This option can be used multiple times to allow receiving data from more than one source.

IP_BIND_ADDRESS_NO_PORT (since Linux 4.2)
Inform the kernel to not reserve an ephemeral port when using bind(2) with a port number of 0. The port will later be automatically chosen at connect(2) time, in a way that allows sharing a source port as long as the 4-tuple is unique.

IP_BLOCK_SOURCE (since Linux 2.4.22 / 2.5.68)
Stop receiving multicast data from a specific source in a given group. This is valid only after the application has subscribed to the multicast group using either IP_ADD_MEMBERSHIP or IP_ADD_SOURCE_MEMBERSHIP.

Argument is an ip_mreq_source structure as described under IP_ADD_SOURCE_MEMBERSHIP.

IP_DROP_MEMBERSHIP (since Linux 1.2)
Leave a multicast group. Argument is an ip_mreqn or ip_mreq structure similar to IP_ADD_MEMBERSHIP.

IP_DROP_SOURCE_MEMBERSHIP (since Linux 2.4.22 / 2.5.68)
Leave a source-specific group—that is, stop receiving data from a given multicast group that come from a given source. If the application has subscribed to multiple sources within the same group, data from the remaining sources will still be delivered. To stop receiving data from all sources at once, use IP_DROP_MEMBERSHIP.

Argument is an ip_mreq_source structure as described under IP_ADD_SOURCE_MEMBERSHIP.

IP_FREEBIND (since Linux 2.4)
If enabled, this boolean option allows binding to an IP address that is nonlocal or does not (yet) exist. This permits listening on a socket, without requiring the underlying network interface or the specified dynamic IP address to be up at the time that the application is trying to bind to it. This option is the per-socket equivalent of the ip_nonlocal_bind /proc interface described below.

IP_HDRINCL (since Linux 2.0)
If enabled, the user supplies an IP header in front of the user data. Valid only for SOCK_RAW sockets; see raw(7) for more information. When this flag is enabled, the values set by IP_OPTIONS, IP_TTL, and IP_TOS are ignored.

IP_LOCAL_PORT_RANGE (since Linux 6.3)
Set or get the per-socket default local port range. This option can be used to clamp down the global local port range, defined by the ip_local_port_range /proc interface described below, for a given socket.

The option takes an uint32_t value with the high 16 bits set to the upper range bound, and the low 16 bits set to the lower range bound. Range bounds are inclusive. The 16-bit values should be in host byte order.

The lower bound has to be less than the upper bound when both bounds are not zero. Otherwise, setting the option fails with EINVAL.

If either bound is outside of the global local port range, or is zero, then that bound has no effect.

To reset the setting, pass zero as both the upper and the lower bound.

IP_MSFILTER (since Linux 2.4.22 / 2.5.68)
This option provides access to the advanced full-state filtering API. Argument is an ip_msfilter structure.

struct ip_msfilter {
    struct in_addr imsf_multiaddr; /* IP multicast group
                                      address */
    struct in_addr imsf_interface; /* IP address of local
                                      interface */
    uint32_t       imsf_fmode;     /* Filter-mode */
    uint32_t       imsf_numsrc;    /* Number of sources in
                                      the following array */
    struct in_addr imsf_slist[1];  /* Array of source
                                      addresses */
};

There are two macros, MCAST_INCLUDE and MCAST_EXCLUDE, which can be used to specify the filtering mode. Additionally, the IP_MSFILTER_SIZE(n) macro exists to determine how much memory is needed to store ip_msfilter structure with n sources in the source list.

For the full description of multicast source filtering refer to RFC 3376.

IP_MTU (since Linux 2.2)
Retrieve the current known path MTU of the current socket. Returns an integer.

IP_MTU is valid only for getsockopt(2) and can be employed only when the socket has been connected.

IP_MTU_DISCOVER (since Linux 2.2)
Set or receive the Path MTU Discovery setting for a socket. When enabled, Linux will perform Path MTU Discovery as defined in RFC 1191 on SOCK_STREAM sockets. For non-SOCK_STREAM sockets, IP_PMTUDISC_DO forces the don’t-fragment flag to be set on all outgoing packets. It is the user’s responsibility to packetize the data in MTU-sized chunks and to do the retransmits if necessary. The kernel will reject (with EMSGSIZE) datagrams that are bigger than the known path MTU. IP_PMTUDISC_WANT will fragment a datagram if needed according to the path MTU, or will set the don’t-fragment flag otherwise.

The system-wide default can be toggled between IP_PMTUDISC_WANT and IP_PMTUDISC_DONT by writing (respectively, zero and nonzero values) to the /proc/sys/net/ipv4/ip_no_pmtu_disc file.

Path MTU discovery valueMeaning
IP_PMTUDISC_WANTUse per-route settings.
IP_PMTUDISC_DONTNever do Path MTU Discovery.
IP_PMTUDISC_DOAlways do Path MTU Discovery.
IP_PMTUDISC_PROBESet DF but ignore Path MTU.

When PMTU discovery is enabled, the kernel automatically keeps track of the path MTU per destination host. When it is connected to a specific peer with connect(2), the currently known path MTU can be retrieved conveniently using the IP_MTU socket option (e.g., after an EMSGSIZE error occurred). The path MTU may change over time. For connectionless sockets with many destinations, the new MTU for a given destination can also be accessed using the error queue (see IP_RECVERR). A new error will be queued for every incoming MTU update.

While MTU discovery is in progress, initial packets from datagram sockets may be dropped. Applications using UDP should be aware of this and not take it into account for their packet retransmit strategy.

To bootstrap the path MTU discovery process on unconnected sockets, it is possible to start with a big datagram size (headers up to 64 kilobytes long) and let it shrink by updates of the path MTU.

To get an initial estimate of the path MTU, connect a datagram socket to the destination address using connect(2) and retrieve the MTU by calling getsockopt(2) with the IP_MTU option.

It is possible to implement RFC 4821 MTU probing with SOCK_DGRAM or SOCK_RAW sockets by setting a value of IP_PMTUDISC_PROBE (available since Linux 2.6.22). This is also particularly useful for diagnostic tools such as tracepath(8) that wish to deliberately send probe packets larger than the observed Path MTU.

IP_MULTICAST_ALL (since Linux 2.6.31)
This option can be used to modify the delivery policy of multicast messages. The argument is a boolean integer (defaults to 1). If set to 1, the socket will receive messages from all the groups that have been joined globally on the whole system. Otherwise, it will deliver messages only from the groups that have been explicitly joined (for example via the IP_ADD_MEMBERSHIP option) on this particular socket.

IP_MULTICAST_IF (since Linux 1.2)
Set the local device for a multicast socket. The argument for setsockopt(2) is an ip_mreqn or (since Linux 3.5) ip_mreq structure similar to IP_ADD_MEMBERSHIP, or an in_addr structure. (The kernel determines which structure is being passed based on the size passed in optlen.) For getsockopt(2), the argument is an in_addr structure.

IP_MULTICAST_LOOP (since Linux 1.2)
Set or read a boolean integer argument that determines whether sent multicast packets should be looped back to the local sockets.

IP_MULTICAST_TTL (since Linux 1.2)
Set or read the time-to-live value of outgoing multicast packets for this socket. It is very important for multicast packets to set the smallest TTL possible. The default is 1 which means that multicast packets don’t leave the local network unless the user program explicitly requests it. Argument is an integer.

IP_NODEFRAG (since Linux 2.6.36)
If enabled (argument is nonzero), the reassembly of outgoing packets is disabled in the netfilter layer. The argument is an integer.

This option is valid only for SOCK_RAW sockets.

IP_OPTIONS (since Linux 2.0)
Set or get the IP options to be sent with every packet from this socket. The arguments are a pointer to a memory buffer containing the options and the option length. The setsockopt(2) call sets the IP options associated with a socket. The maximum option size for IPv4 is 40 bytes. See RFC 791 for the allowed options. When the initial connection request packet for a SOCK_STREAM socket contains IP options, the IP options will be set automatically to the options from the initial packet with routing headers reversed. Incoming packets are not allowed to change options after the connection is established. The processing of all incoming source routing options is disabled by default and can be enabled by using the accept_source_route /proc interface. Other options like timestamps are still handled. For datagram sockets, IP options can be set only by the local user. Calling getsockopt(2) with IP_OPTIONS puts the current IP options used for sending into the supplied buffer.

IP_PASSSEC (since Linux 2.6.17)
If labeled IPSEC or NetLabel is configured on the sending and receiving hosts, this option enables receiving of the security context of the peer socket in an ancillary message of type SCM_SECURITY retrieved using recvmsg(2). This option is supported only for UDP sockets; for TCP or SCTP sockets, see the description of the SO_PEERSEC option below.

The value given as an argument to setsockopt(2) and returned as the result of getsockopt(2) is an integer boolean flag.

The security context returned in the SCM_SECURITY ancillary message is of the same format as the one described under the SO_PEERSEC option below.

Note: the reuse of the SCM_SECURITY message type for the IP_PASSSEC socket option was likely a mistake, since other IP control messages use their own numbering scheme in the IP namespace and often use the socket option value as the message type. There is no conflict currently since the IP option with the same value as SCM_SECURITY is IP_HDRINCL and this is never used for a control message type.

IP_PKTINFO (since Linux 2.2)
Pass an IP_PKTINFO ancillary message that contains a pktinfo structure that supplies some information about the incoming packet. This works only for datagram oriented sockets. The argument is a flag that tells the socket whether the IP_PKTINFO message should be passed or not. The message itself can be sent/retrieved only as a control message with a packet using recvmsg(2) or sendmsg(2).

struct in_pktinfo {
    unsigned int   ipi_ifindex;  /* Interface index */
    struct in_addr ipi_spec_dst; /* Local address */
    struct in_addr ipi_addr;     /* Header Destination
                                    address */
};

ipi_ifindex is the unique index of the interface the packet was received on. ipi_spec_dst is the local address of the packet and ipi_addr is the destination address in the packet header. If IP_PKTINFO is passed to sendmsg(2) and ipi_spec_dst is not zero, then it is used as the local source address for the routing table lookup and for setting up IP source route options. When ipi_ifindex is not zero, the primary local address of the interface specified by the index overwrites ipi_spec_dst for the routing table lookup.

Not supported for SOCK_STREAM sockets.

IP_RECVERR (since Linux 2.2)
Enable extended reliable error message passing. When enabled on a datagram socket, all generated errors will be queued in a per-socket error queue. When the user receives an error from a socket operation, the errors can be received by calling recvmsg(2) with the MSG_ERRQUEUE flag set. The sock_extended_err structure describing the error will be passed in an ancillary message with the type IP_RECVERR and the level IPPROTO_IP. This is useful for reliable error handling on unconnected sockets. The received data portion of the error queue contains the error packet.

The IP_RECVERR control message contains a sock_extended_err structure:

#define SO_EE_ORIGIN_NONE    0
#define SO_EE_ORIGIN_LOCAL   1
#define SO_EE_ORIGIN_ICMP    2
#define SO_EE_ORIGIN_ICMP6   3
struct sock_extended_err {
    uint32_t ee_errno;   /* error number */
    uint8_t  ee_origin;  /* where the error originated */
    uint8_t  ee_type;    /* type */
    uint8_t  ee_code;    /* code */
    uint8_t  ee_pad;
    uint32_t ee_info;    /* additional information */
    uint32_t ee_data;    /* other data */
    /* More data may follow */
};
struct sockaddr *SO_EE_OFFENDER(struct sock_extended_err *);

ee_errno contains the errno number of the queued error. ee_origin is the origin code of where the error originated. The other fields are protocol-specific. The macro SO_EE_OFFENDER returns a pointer to the address of the network object where the error originated from given a pointer to the ancillary message. If this address is not known, the sa_family member of the sockaddr contains AF_UNSPEC and the other fields of the sockaddr are undefined.

IP uses the sock_extended_err structure as follows: ee_origin is set to SO_EE_ORIGIN_ICMP for errors received as an ICMP packet, or SO_EE_ORIGIN_LOCAL for locally generated errors. Unknown values should be ignored. ee_type and ee_code are set from the type and code fields of the ICMP header. ee_info contains the discovered MTU for EMSGSIZE errors. The message also contains the sockaddr_in of the node caused the error, which can be accessed with the SO_EE_OFFENDER macro. The sin_family field of the SO_EE_OFFENDER address is AF_UNSPEC when the source was unknown. When the error originated from the network, all IP options (IP_OPTIONS, IP_TTL, etc.) enabled on the socket and contained in the error packet are passed as control messages. The payload of the packet causing the error is returned as normal payload. Note that TCP has no error queue; MSG_ERRQUEUE is not permitted on SOCK_STREAM sockets. IP_RECVERR is valid for TCP, but all errors are returned by socket function return or SO_ERROR only.

For raw sockets, IP_RECVERR enables passing of all received ICMP errors to the application, otherwise errors are reported only on connected sockets

It sets or retrieves an integer boolean flag. IP_RECVERR defaults to off.

IP_RECVOPTS (since Linux 2.2)
Pass all incoming IP options to the user in a IP_OPTIONS control message. The routing header and other options are already filled in for the local host. Not supported for SOCK_STREAM sockets.

IP_RECVORIGDSTADDR (since Linux 2.6.29)
This boolean option enables the IP_ORIGDSTADDR ancillary message in recvmsg(2), in which the kernel returns the original destination address of the datagram being received. The ancillary message contains a struct sockaddr_in. Not supported for SOCK_STREAM sockets.

IP_RECVTOS (since Linux 2.2)
If enabled, the IP_TOS ancillary message is passed with incoming packets. It contains a byte which specifies the Type of Service/Precedence field of the packet header. Expects a boolean integer flag. Not supported for SOCK_STREAM sockets.

IP_RECVTTL (since Linux 2.2)
When this flag is set, pass a IP_TTL control message with the time-to-live field of the received packet as a 32 bit integer. Not supported for SOCK_STREAM sockets.

IP_RETOPTS (since Linux 2.2)
Identical to IP_RECVOPTS, but returns raw unprocessed options with timestamp and route record options not filled in for this hop. Not supported for SOCK_STREAM sockets.

IP_ROUTER_ALERT (since Linux 2.2)
Pass all to-be forwarded packets with the IP Router Alert option set to this socket. Valid only for raw sockets. This is useful, for instance, for user-space RSVP daemons. The tapped packets are not forwarded by the kernel; it is the user’s responsibility to send them out again. Socket binding is ignored, such packets are filtered only by protocol. Expects an integer flag.

IP_TOS (since Linux 1.0)
Set or receive the Type-Of-Service (TOS) field that is sent with every IP packet originating from this socket. It is used to prioritize packets on the network. TOS is a byte. There are some standard TOS flags defined: IPTOS_LOWDELAY to minimize delays for interactive traffic, IPTOS_THROUGHPUT to optimize throughput, IPTOS_RELIABILITY to optimize for reliability, IPTOS_MINCOST should be used for “filler data” where slow transmission doesn’t matter. At most one of these TOS values can be specified. Other bits are invalid and shall be cleared. Linux sends IPTOS_LOWDELAY datagrams first by default, but the exact behavior depends on the configured queueing discipline. Some high-priority levels may require superuser privileges (the CAP_NET_ADMIN capability).

IP_TRANSPARENT (since Linux 2.6.24)
Setting this boolean option enables transparent proxying on this socket. This socket option allows the calling application to bind to a nonlocal IP address and operate both as a client and a server with the foreign address as the local endpoint. NOTE: this requires that routing be set up in a way that packets going to the foreign address are routed through the TProxy box (i.e., the system hosting the application that employs the IP_TRANSPARENT socket option). Enabling this socket option requires superuser privileges (the CAP_NET_ADMIN capability).

TProxy redirection with the iptables TPROXY target also requires that this option be set on the redirected socket.

IP_TTL (since Linux 1.0)
Set or retrieve the current time-to-live field that is used in every packet sent from this socket.

IP_UNBLOCK_SOURCE (since Linux 2.4.22 / 2.5.68)
Unblock previously blocked multicast source. Returns EADDRNOTAVAIL when given source is not being blocked.

Argument is an ip_mreq_source structure as described under IP_ADD_SOURCE_MEMBERSHIP.

SO_PEERSEC (since Linux 2.6.17)
If labeled IPSEC or NetLabel is configured on both the sending and receiving hosts, this read-only socket option returns the security context of the peer socket connected to this socket. By default, this will be the same as the security context of the process that created the peer socket unless overridden by the policy or by a process with the required permissions.

The argument to getsockopt(2) is a pointer to a buffer of the specified length in bytes into which the security context string will be copied. If the buffer length is less than the length of the security context string, then getsockopt(2) returns -1, sets errno to ERANGE, and returns the required length via optlen. The caller should allocate at least NAME_MAX bytes for the buffer initially, although this is not guaranteed to be sufficient. Resizing the buffer to the returned length and retrying may be necessary.

The security context string may include a terminating null character in the returned length, but is not guaranteed to do so: a security context “foo” might be represented as either {‘f’,‘o’,‘o’} of length 3 or {‘f’,‘o’,‘o’,‘�’} of length 4, which are considered to be interchangeable. The string is printable, does not contain non-terminating null characters, and is in an unspecified encoding (in particular, it is not guaranteed to be ASCII or UTF-8).

The use of this option for sockets in the AF_INET address family is supported since Linux 2.6.17 for TCP sockets, and since Linux 4.17 for SCTP sockets.

For SELinux, NetLabel conveys only the MLS portion of the security context of the peer across the wire, defaulting the rest of the security context to the values defined in the policy for the netmsg initial security identifier (SID). However, NetLabel can be configured to pass full security contexts over loopback. Labeled IPSEC always passes full security contexts as part of establishing the security association (SA) and looks them up based on the association for each packet.

/proc interfaces

The IP protocol supports a set of /proc interfaces to configure some global parameters. The parameters can be accessed by reading or writing files in the directory /proc/sys/net/ipv4/. Interfaces described as Boolean take an integer value, with a nonzero value (“true”) meaning that the corresponding option is enabled, and a zero value (“false”) meaning that the option is disabled.

ip_always_defrag (Boolean; since Linux 2.2.13)
[New with Linux 2.2.13; in earlier kernel versions this feature was controlled at compile time by the CONFIG_IP_ALWAYS_DEFRAG option; this option is not present in Linux 2.4.x and later]

When this boolean flag is enabled (not equal 0), incoming fragments (parts of IP packets that arose when some host between origin and destination decided that the packets were too large and cut them into pieces) will be reassembled (defragmented) before being processed, even if they are about to be forwarded.

Enable only if running either a firewall that is the sole link to your network or a transparent proxy; never ever use it for a normal router or host. Otherwise, fragmented communication can be disturbed if the fragments travel over different links. Defragmentation also has a large memory and CPU time cost.

This is automagically turned on when masquerading or transparent proxying are configured.

ip_autoconfig (since Linux 2.2 to Linux 2.6.17)
Not documented.

ip_default_ttl (integer; default: 64; since Linux 2.2)
Set the default time-to-live value of outgoing packets. This can be changed per socket with the IP_TTL option.

ip_dynaddr (Boolean; default: disabled; since Linux 2.0.31)
Enable dynamic socket address and masquerading entry rewriting on interface address change. This is useful for dialup interface with changing IP addresses. 0 means no rewriting, 1 turns it on and 2 enables verbose mode.

ip_forward (Boolean; default: disabled; since Linux 1.2)
Enable IP forwarding with a boolean flag. IP forwarding can be also set on a per-interface basis.

ip_local_port_range (since Linux 2.2)
This file contains two integers that define the default local port range allocated to sockets that are not explicitly bound to a port number—that is, the range used for ephemeral ports. An ephemeral port is allocated to a socket in the following circumstances:

  • the port number in a socket address is specified as 0 when calling bind(2);

  • listen(2) is called on a stream socket that was not previously bound;

  • connect(2) was called on a socket that was not previously bound;

  • sendto(2) is called on a datagram socket that was not previously bound.

Allocation of ephemeral ports starts with the first number in ip_local_port_range and ends with the second number. If the range of ephemeral ports is exhausted, then the relevant system call returns an error (but see BUGS).

Note that the port range in ip_local_port_range should not conflict with the ports used by masquerading (although the case is handled). Also, arbitrary choices may cause problems with some firewall packet filters that make assumptions about the local ports in use. The first number should be at least greater than 1024, or better, greater than 4096, to avoid clashes with well known ports and to minimize firewall problems.

ip_no_pmtu_disc (Boolean; default: disabled; since Linux 2.2)
If enabled, don’t do Path MTU Discovery for TCP sockets by default. Path MTU discovery may fail if misconfigured firewalls (that drop all ICMP packets) or misconfigured interfaces (e.g., a point-to-point link where the both ends don’t agree on the MTU) are on the path. It is better to fix the broken routers on the path than to turn off Path MTU Discovery globally, because not doing it incurs a high cost to the network.

ip_nonlocal_bind (Boolean; default: disabled; since Linux 2.4)
If set, allows processes to bind(2) to nonlocal IP addresses, which can be quite useful, but may break some applications.

ip6frag_time (integer; default: 30)
Time in seconds to keep an IPv6 fragment in memory.

ip6frag_secret_interval (integer; default: 600)
Regeneration interval (in seconds) of the hash secret (or lifetime for the hash secret) for IPv6 fragments.

ipfrag_high_thresh (integer)
ipfrag_low_thresh (integer)
If the amount of queued IP fragments reaches ipfrag_high_thresh, the queue is pruned down to ipfrag_low_thresh. Contains an integer with the number of bytes.

neigh/*
See arp(7).

Ioctls

All ioctls described in socket(7) apply to ip.

Ioctls to configure generic device parameters are described in netdevice(7).

ERRORS

EACCES
The user tried to execute an operation without the necessary permissions. These include: sending a packet to a broadcast address without having the SO_BROADCAST flag set; sending a packet via a prohibit route; modifying firewall settings without superuser privileges (the CAP_NET_ADMIN capability); binding to a privileged port without superuser privileges (the CAP_NET_BIND_SERVICE capability).

EADDRINUSE
Tried to bind to an address already in use.

EADDRNOTAVAIL
A nonexistent interface was requested or the requested source address was not local.

EAGAIN
Operation on a nonblocking socket would block.

EALREADY
A connection operation on a nonblocking socket is already in progress.

ECONNABORTED
A connection was closed during an accept(2).

EHOSTUNREACH
No valid routing table entry matches the destination address. This error can be caused by an ICMP message from a remote router or for the local routing table.

EINVAL
Invalid argument passed. For send operations this can be caused by sending to a blackhole route.

EISCONN
connect(2) was called on an already connected socket.

EMSGSIZE
Datagram is bigger than an MTU on the path and it cannot be fragmented.

ENOBUFS
ENOMEM
Not enough free memory. This often means that the memory allocation is limited by the socket buffer limits, not by the system memory, but this is not 100% consistent.

ENOENT
SIOCGSTAMP was called on a socket where no packet arrived.

ENOPKG
A kernel subsystem was not configured.

ENOPROTOOPT and EOPNOTSUPP
Invalid socket option passed.

ENOTCONN
The operation is defined only on a connected socket, but the socket wasn’t connected.

EPERM
User doesn’t have permission to set high priority, change configuration, or send signals to the requested process or group.

EPIPE
The connection was unexpectedly closed or shut down by the other end.

ESOCKTNOSUPPORT
The socket is not configured or an unknown socket type was requested.

Other errors may be generated by the overlaying protocols; see tcp(7), raw(7), udp(7), and socket(7).

NOTES

IP_FREEBIND, IP_MSFILTER, IP_MTU, IP_MTU_DISCOVER, IP_RECVORIGDSTADDR, IP_PASSSEC, IP_PKTINFO, IP_RECVERR, IP_ROUTER_ALERT, and IP_TRANSPARENT are Linux-specific.

Be very careful with the SO_BROADCAST option - it is not privileged in Linux. It is easy to overload the network with careless broadcasts. For new application protocols it is better to use a multicast group instead of broadcasting. Broadcasting is discouraged. See RFC 6762 for an example of a protocol (mDNS) using the more modern multicast approach to communicating with an open-ended group of hosts on the local network.

Some other BSD sockets implementations provide IP_RCVDSTADDR and IP_RECVIF socket options to get the destination address and the interface of received datagrams. Linux has the more general IP_PKTINFO for the same task.

Some BSD sockets implementations also provide an IP_RECVTTL option, but an ancillary message with type IP_RECVTTL is passed with the incoming packet. This is different from the IP_TTL option used in Linux.

Using the SOL_IP socket options level isn’t portable; BSD-based stacks use the IPPROTO_IP level.

INADDR_ANY (0.0.0.0) and INADDR_BROADCAST (255.255.255.255) are byte-order-neutral. This means htonl(3) has no effect on them.

Compatibility

For compatibility with Linux 2.0, the obsolete socket(AF_INET, SOCK_PACKET, protocol) syntax is still supported to open a packet(7) socket. This is deprecated and should be replaced by socket(AF_PACKET, SOCK_RAW, protocol) instead. The main difference is the new sockaddr_ll address structure for generic link layer information instead of the old sockaddr_pkt.

BUGS

There are too many inconsistent error values.

The error used to diagnose exhaustion of the ephemeral port range differs across the various system calls (connect(2), bind(2), listen(2), sendto(2)) that can assign ephemeral ports.

The ioctls to configure IP-specific interface options and ARP tables are not described.

Receiving the original destination address with MSG_ERRQUEUE in msg_name by recvmsg(2) does not work in some Linux 2.2 kernels.

SEE ALSO

recvmsg(2), sendmsg(2), byteorder(3), capabilities(7), icmp(7), ipv6(7), netdevice(7), netlink(7), raw(7), socket(7), tcp(7), udp(7), ip(8)

The kernel source file Documentation/networking/ip-sysctl.txt.

RFC 791 for the original IP specification. RFC 1122 for the IPv4 host requirements. RFC 1812 for the IPv4 router requirements.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

149 - Linux cli command CREATE_TRIGGER

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_TRIGGER and provides detailed information about the command CREATE_TRIGGER, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_TRIGGER.

NAME 🖥️ CREATE_TRIGGER 🖥️

define a new trigger

SYNOPSIS

CREATE [ OR REPLACE ] [ CONSTRAINT ] TRIGGER name { BEFORE | AFTER | INSTEAD OF } { event [ OR ... ] }
    ON table_name
    [ FROM referenced_table_name ]
    [ NOT DEFERRABLE | [ DEFERRABLE ] [ INITIALLY IMMEDIATE | INITIALLY DEFERRED ] ]
    [ REFERENCING { { OLD | NEW } TABLE [ AS ] transition_relation_name } [ ... ] ]
    [ FOR [ EACH ] { ROW | STATEMENT } ]
    [ WHEN ( condition ) ]
    EXECUTE { FUNCTION | PROCEDURE } function_name ( arguments )

where event can be one of:

    INSERT
    UPDATE [ OF column_name [, ... ] ]
    DELETE
    TRUNCATE

DESCRIPTION

CREATE TRIGGER creates a new trigger. CREATE OR REPLACE TRIGGER will either create a new trigger, or replace an existing trigger. The trigger will be associated with the specified table, view, or foreign table and will execute the specified function function_name when certain operations are performed on that table.

To replace the current definition of an existing trigger, use CREATE OR REPLACE TRIGGER, specifying the existing triggers name and parent table. All other properties are replaced.

The trigger can be specified to fire before the operation is attempted on a row (before constraints are checked and the INSERT, UPDATE, or DELETE is attempted); or after the operation has completed (after constraints are checked and the INSERT, UPDATE, or DELETE has completed); or instead of the operation (in the case of inserts, updates or deletes on a view). If the trigger fires before or instead of the event, the trigger can skip the operation for the current row, or change the row being inserted (for INSERT and UPDATE operations only). If the trigger fires after the event, all changes, including the effects of other triggers, are “visible” to the trigger.

A trigger that is marked FOR EACH ROW is called once for every row that the operation modifies. For example, a DELETE that affects 10 rows will cause any ON DELETE triggers on the target relation to be called 10 separate times, once for each deleted row. In contrast, a trigger that is marked FOR EACH STATEMENT only executes once for any given operation, regardless of how many rows it modifies (in particular, an operation that modifies zero rows will still result in the execution of any applicable FOR EACH STATEMENT triggers).

Triggers that are specified to fire INSTEAD OF the trigger event must be marked FOR EACH ROW, and can only be defined on views. BEFORE and AFTER triggers on a view must be marked as FOR EACH STATEMENT.

In addition, triggers may be defined to fire for TRUNCATE, though only FOR EACH STATEMENT.

The following table summarizes which types of triggers may be used on tables, views, and foreign tables:

WhenEventRow-levelStatement-level
BEFOREINSERT/UPDATE/DELETETables and foreign tablesTables, views, and foreign tables
TRUNCATE—Tables and foreign tables
AFTERINSERT/UPDATE/DELETETables and foreign tablesTables, views, and foreign tables
TRUNCATE—Tables and foreign tables
INSTEAD OFINSERT/UPDATE/DELETEViews—
TRUNCATE——

Also, a trigger definition can specify a Boolean WHEN condition, which will be tested to see whether the trigger should be fired. In row-level triggers the WHEN condition can examine the old and/or new values of columns of the row. Statement-level triggers can also have WHEN conditions, although the feature is not so useful for them since the condition cannot refer to any values in the table.

If multiple triggers of the same kind are defined for the same event, they will be fired in alphabetical order by name.

When the CONSTRAINT option is specified, this command creates a constraint trigger. This is the same as a regular trigger except that the timing of the trigger firing can be adjusted using SET CONSTRAINTS. Constraint triggers must be AFTER ROW triggers on plain tables (not foreign tables). They can be fired either at the end of the statement causing the triggering event, or at the end of the containing transaction; in the latter case they are said to be deferred. A pending deferred-trigger firing can also be forced to happen immediately by using SET CONSTRAINTS. Constraint triggers are expected to raise an exception when the constraints they implement are violated.

The REFERENCING option enables collection of transition relations, which are row sets that include all of the rows inserted, deleted, or modified by the current SQL statement. This feature lets the trigger see a global view of what the statement did, not just one row at a time. This option is only allowed for an AFTER trigger that is not a constraint trigger; also, if the trigger is an UPDATE trigger, it must not specify a column_name list. OLD TABLE may only be specified once, and only for a trigger that can fire on UPDATE or DELETE; it creates a transition relation containing the before-images of all rows updated or deleted by the statement. Similarly, NEW TABLE may only be specified once, and only for a trigger that can fire on UPDATE or INSERT; it creates a transition relation containing the after-images of all rows updated or inserted by the statement.

SELECT does not modify any rows so you cannot create SELECT triggers. Rules and views may provide workable solutions to problems that seem to need SELECT triggers.

Refer to Chapter 39 for more information about triggers.

PARAMETERS

name

The name to give the new trigger. This must be distinct from the name of any other trigger for the same table. The name cannot be schema-qualified — the trigger inherits the schema of its table. For a constraint trigger, this is also the name to use when modifying the triggers behavior using SET CONSTRAINTS.

BEFORE
AFTER
INSTEAD OF

Determines whether the function is called before, after, or instead of the event. A constraint trigger can only be specified as AFTER.

event

One of INSERT, UPDATE, DELETE, or TRUNCATE; this specifies the event that will fire the trigger. Multiple events can be specified using OR, except when transition relations are requested.

For UPDATE events, it is possible to specify a list of columns using this syntax:

UPDATE OF column_name1 [, column_name2 … ]

The trigger will only fire if at least one of the listed columns is mentioned as a target of the UPDATE command or if one of the listed columns is a generated column that depends on a column that is the target of the UPDATE.

INSTEAD OF UPDATE events do not allow a list of columns. A column list cannot be specified when requesting transition relations, either.

table_name

The name (optionally schema-qualified) of the table, view, or foreign table the trigger is for.

referenced_table_name

The (possibly schema-qualified) name of another table referenced by the constraint. This option is used for foreign-key constraints and is not recommended for general use. This can only be specified for constraint triggers.

DEFERRABLE
NOT DEFERRABLE
INITIALLY IMMEDIATE
INITIALLY DEFERRED

The default timing of the trigger. See the CREATE TABLE (CREATE_TABLE(7)) documentation for details of these constraint options. This can only be specified for constraint triggers.

REFERENCING

This keyword immediately precedes the declaration of one or two relation names that provide access to the transition relations of the triggering statement.

OLD TABLE
NEW TABLE

This clause indicates whether the following relation name is for the before-image transition relation or the after-image transition relation.

transition_relation_name

The (unqualified) name to be used within the trigger for this transition relation.

FOR EACH ROW
FOR EACH STATEMENT

This specifies whether the trigger function should be fired once for every row affected by the trigger event, or just once per SQL statement. If neither is specified, FOR EACH STATEMENT is the default. Constraint triggers can only be specified FOR EACH ROW.

condition

A Boolean expression that determines whether the trigger function will actually be executed. If WHEN is specified, the function will only be called if the condition returns true. In FOR EACH ROW triggers, the WHEN condition can refer to columns of the old and/or new row values by writing OLD.column_name or NEW.column_name respectively. Of course, INSERT triggers cannot refer to OLD and DELETE triggers cannot refer to NEW.

INSTEAD OF triggers do not support WHEN conditions.

Currently, WHEN expressions cannot contain subqueries.

Note that for constraint triggers, evaluation of the WHEN condition is not deferred, but occurs immediately after the row update operation is performed. If the condition does not evaluate to true then the trigger is not queued for deferred execution.

function_name

A user-supplied function that is declared as taking no arguments and returning type trigger, which is executed when the trigger fires.

In the syntax of CREATE TRIGGER, the keywords FUNCTION and PROCEDURE are equivalent, but the referenced function must in any case be a function, not a procedure. The use of the keyword PROCEDURE here is historical and deprecated.

arguments

An optional comma-separated list of arguments to be provided to the function when the trigger is executed. The arguments are literal string constants. Simple names and numeric constants can be written here, too, but they will all be converted to strings. Please check the description of the implementation language of the trigger function to find out how these arguments can be accessed within the function; it might be different from normal function arguments.

NOTES

To create or replace a trigger on a table, the user must have the TRIGGER privilege on the table. The user must also have EXECUTE privilege on the trigger function.

Use DROP TRIGGER to remove a trigger.

Creating a row-level trigger on a partitioned table will cause an identical “clone” trigger to be created on each of its existing partitions; and any partitions created or attached later will have an identical trigger, too. If there is a conflictingly-named trigger on a child partition already, an error occurs unless CREATE OR REPLACE TRIGGER is used, in which case that trigger is replaced with a clone trigger. When a partition is detached from its parent, its clone triggers are removed.

A column-specific trigger (one defined using the UPDATE OF column_name syntax) will fire when any of its columns are listed as targets in the UPDATE commands SET list. It is possible for a columns value to change even when the trigger is not fired, because changes made to the rows contents by BEFORE UPDATE triggers are not considered. Conversely, a command such as UPDATE … SET x = x … will fire a trigger on column x, even though the columns value did not change.

In a BEFORE trigger, the WHEN condition is evaluated just before the function is or would be executed, so using WHEN is not materially different from testing the same condition at the beginning of the trigger function. Note in particular that the NEW row seen by the condition is the current value, as possibly modified by earlier triggers. Also, a BEFORE triggers WHEN condition is not allowed to examine the system columns of the NEW row (such as ctid), because those wont have been set yet.

In an AFTER trigger, the WHEN condition is evaluated just after the row update occurs, and it determines whether an event is queued to fire the trigger at the end of statement. So when an AFTER triggers WHEN condition does not return true, it is not necessary to queue an event nor to re-fetch the row at end of statement. This can result in significant speedups in statements that modify many rows, if the trigger only needs to be fired for a few of the rows.

In some cases it is possible for a single SQL command to fire more than one kind of trigger. For instance an INSERT with an ON CONFLICT DO UPDATE clause may cause both insert and update operations, so it will fire both kinds of triggers as needed. The transition relations supplied to triggers are specific to their event type; thus an INSERT trigger will see only the inserted rows, while an UPDATE trigger will see only the updated rows.

Row updates or deletions caused by foreign-key enforcement actions, such as ON UPDATE CASCADE or ON DELETE SET NULL, are treated as part of the SQL command that caused them (note that such actions are never deferred). Relevant triggers on the affected table will be fired, so that this provides another way in which an SQL command might fire triggers not directly matching its type. In simple cases, triggers that request transition relations will see all changes caused in their table by a single original SQL command as a single transition relation. However, there are cases in which the presence of an AFTER ROW trigger that requests transition relations will cause the foreign-key enforcement actions triggered by a single SQL command to be split into multiple steps, each with its own transition relation(s). In such cases, any statement-level triggers that are present will be fired once per creation of a transition relation set, ensuring that the triggers see each affected row in a transition relation once and only once.

Statement-level triggers on a view are fired only if the action on the view is handled by a row-level INSTEAD OF trigger. If the action is handled by an INSTEAD rule, then whatever statements are emitted by the rule are executed in place of the original statement naming the view, so that the triggers that will be fired are those on tables named in the replacement statements. Similarly, if the view is automatically updatable, then the action is handled by automatically rewriting the statement into an action on the views base table, so that the base tables statement-level triggers are the ones that are fired.

Modifying a partitioned table or a table with inheritance children fires statement-level triggers attached to the explicitly named table, but not statement-level triggers for its partitions or child tables. In contrast, row-level triggers are fired on the rows in affected partitions or child tables, even if they are not explicitly named in the query. If a statement-level trigger has been defined with transition relations named by a REFERENCING clause, then before and after images of rows are visible from all affected partitions or child tables. In the case of inheritance children, the row images include only columns that are present in the table that the trigger is attached to.

Currently, row-level triggers with transition relations cannot be defined on partitions or inheritance child tables. Also, triggers on partitioned tables may not be INSTEAD OF.

Currently, the OR REPLACE option is not supported for constraint triggers.

Replacing an existing trigger within a transaction that has already performed updating actions on the triggers table is not recommended. Trigger firing decisions, or portions of firing decisions, that have already been made will not be reconsidered, so the effects could be surprising.

There are a few built-in trigger functions that can be used to solve common problems without having to write your own trigger code; see Section 9.28.

EXAMPLES

Execute the function check_account_update whenever a row of the table accounts is about to be updated:

CREATE TRIGGER check_update BEFORE UPDATE ON accounts FOR EACH ROW EXECUTE FUNCTION check_account_update();

Modify that trigger definition to only execute the function if column balance is specified as a target in the UPDATE command:

CREATE OR REPLACE TRIGGER check_update BEFORE UPDATE OF balance ON accounts FOR EACH ROW EXECUTE FUNCTION check_account_update();

This form only executes the function if column balance has in fact changed value:

CREATE TRIGGER check_update BEFORE UPDATE ON accounts FOR EACH ROW WHEN (OLD.balance IS DISTINCT FROM NEW.balance) EXECUTE FUNCTION check_account_update();

Call a function to log updates of accounts, but only if something changed:

CREATE TRIGGER log_update AFTER UPDATE ON accounts FOR EACH ROW WHEN (OLD.* IS DISTINCT FROM NEW.*) EXECUTE FUNCTION log_account_update();

Execute the function view_insert_row for each row to insert rows into the tables underlying a view:

CREATE TRIGGER view_insert INSTEAD OF INSERT ON my_view FOR EACH ROW EXECUTE FUNCTION view_insert_row();

Execute the function check_transfer_balances_to_zero for each statement to confirm that the transfer rows offset to a net of zero:

CREATE TRIGGER transfer_insert AFTER INSERT ON transfer REFERENCING NEW TABLE AS inserted FOR EACH STATEMENT EXECUTE FUNCTION check_transfer_balances_to_zero();

Execute the function check_matching_pairs for each row to confirm that changes are made to matching pairs at the same time (by the same statement):

CREATE TRIGGER paired_items_update AFTER UPDATE ON paired_items REFERENCING NEW TABLE AS newtab OLD TABLE AS oldtab FOR EACH ROW EXECUTE FUNCTION check_matching_pairs();

Section 39.4 contains a complete example of a trigger function written in C.

COMPATIBILITY

The CREATE TRIGGER statement in PostgreSQL implements a subset of the SQL standard. The following functionalities are currently missing:

·

While transition table names for AFTER triggers are specified using the REFERENCING clause in the standard way, the row variables used in FOR EACH ROW triggers may not be specified in a REFERENCING clause. They are available in a manner that is dependent on the language in which the trigger function is written, but is fixed for any one language. Some languages effectively behave as though there is a REFERENCING clause containing OLD ROW AS OLD NEW ROW AS NEW.

·

The standard allows transition tables to be used with column-specific UPDATE triggers, but then the set of rows that should be visible in the transition tables depends on the triggers column list. This is not currently implemented by PostgreSQL.

·

PostgreSQL only allows the execution of a user-defined function for the triggered action. The standard allows the execution of a number of other SQL commands, such as CREATE TABLE, as the triggered action. This limitation is not hard to work around by creating a user-defined function that executes the desired commands.

SQL specifies that multiple triggers should be fired in time-of-creation order. PostgreSQL uses name order, which was judged to be more convenient.

SQL specifies that BEFORE DELETE triggers on cascaded deletes fire after the cascaded DELETE completes. The PostgreSQL behavior is for BEFORE DELETE to always fire before the delete action, even a cascading one. This is considered more consistent. There is also nonstandard behavior if BEFORE triggers modify rows or prevent updates during an update that is caused by a referential action. This can lead to constraint violations or stored data that does not honor the referential constraint.

The ability to specify multiple actions for a single trigger using OR is a PostgreSQL extension of the SQL standard.

The ability to fire triggers for TRUNCATE is a PostgreSQL extension of the SQL standard, as is the ability to define statement-level triggers on views.

CREATE CONSTRAINT TRIGGER is a PostgreSQL extension of the SQL standard. So is the OR REPLACE option.

SEE ALSO

ALTER TRIGGER (ALTER_TRIGGER(7)), DROP TRIGGER (DROP_TRIGGER(7)), CREATE FUNCTION (CREATE_FUNCTION(7)), SET CONSTRAINTS (SET_CONSTRAINTS(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

150 - Linux cli command iso_8859_6

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso_8859_6 and provides detailed information about the command iso_8859_6, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso_8859_6.

NAME 🖥️ iso_8859_6 🖥️

6 - ISO/IEC 8859-6 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-6 encodes the characters used in the Arabic language.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-6 characters

The following table displays the characters in ISO/IEC 8859-6 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-6 lacks the glyphs required for many related languages, such as Urdu and Persian (Farsi).

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

151 - Linux cli command openssl_user_macrosssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command openssl_user_macrosssl and provides detailed information about the command openssl_user_macrosssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the openssl_user_macrosssl.

NAME 🖥️ openssl_user_macrosssl 🖥️

User defined macros

DESCRIPTION

User defined macros allow the programmer to control certain aspects of what is exposed by the OpenSSL headers.

NOTE: to be effective, a user defined macro must be defined before including any header file that depends on it, either in the compilation command (cc -DMACRO=value) or by defining the macro in source before including any headers.

Other manual pages may refer to this page when declarations depend on user defined macros.

The macros

OPENSSL_API_COMPAT
The value is a version number, given in one of the following two forms:

“0xMNNFF000L”
This is the form supported for all versions up to 1.1.x, where M represents the major number, NN represents the minor number, and FF represents the fix number, as a hexadecimal number. For version 1.1.0, that’s 0x10100000L. Any version number may be given, but these numbers are the current known major deprecation points, making them the most meaningful:

“0x00908000L” (version 0.9.8)

“0x10000000L” (version 1.0.0)

“0x10100000L” (version 1.1.0)

For convenience, higher numbers are accepted as well, as long as feasible. For example, 0x60000000L will work as expected. However, it is recommended to start using the second form instead:

“mmnnpp”
This form is a simple decimal number calculated with this formula: major * 10000 + minor * 100 + patch where major, minor and patch are the desired major, minor and patch components of the version number. For example:

30000 corresponds to version 3.0.0

10002 corresponds to version 1.0.2

420101 corresponds to version 42.1.1

If OPENSSL_API_COMPAT is undefined, this default value is used in its place: 30200

OPENSSL_NO_DEPRECATED
If this macro is defined, all deprecated public symbols in all OpenSSL versions up to and including the version given by OPENSSL_API_COMPAT (or the default value given above, when OPENSSL_API_COMPAT isn’t defined) will be hidden.

COPYRIGHT

Copyright 2018-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

152 - Linux cli command sysvipc

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command sysvipc and provides detailed information about the command sysvipc, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the sysvipc.

NAME 🖥️ sysvipc 🖥️

System V interprocess communication mechanisms

DESCRIPTION

System V IPC is the name given to three interprocess communication mechanisms that are widely available on UNIX systems: message queues, semaphore, and shared memory.

Message queues

System V message queues allow data to be exchanged in units called messages. Each message can have an associated priority. POSIX message queues provide an alternative API for achieving the same result; see mq_overview(7).

The System V message queue API consists of the following system calls:

msgget(2)
Create a new message queue or obtain the ID of an existing message queue. This call returns an identifier that is used in the remaining APIs.

msgsnd(2)
Add a message to a queue.

msgrcv(2)
Remove a message from a queue.

msgctl(2)
Perform various control operations on a queue, including deletion.

Semaphore sets

System V semaphores allow processes to synchronize their actions. System V semaphores are allocated in groups called sets; each semaphore in a set is a counting semaphore. POSIX semaphores provide an alternative API for achieving the same result; see sem_overview(7).

The System V semaphore API consists of the following system calls:

semget(2)
Create a new set or obtain the ID of an existing set. This call returns an identifier that is used in the remaining APIs.

semop(2)
Perform operations on the semaphores in a set.

semctl(2)
Perform various control operations on a set, including deletion.

Shared memory segments

System V shared memory allows processes to share a region a memory (a “segment”). POSIX shared memory is an alternative API for achieving the same result; see shm_overview(7).

The System V shared memory API consists of the following system calls:

shmget(2)
Create a new segment or obtain the ID of an existing segment. This call returns an identifier that is used in the remaining APIs.

shmat(2)
Attach an existing shared memory object into the calling process’s address space.

shmdt(2)
Detach a segment from the calling process’s address space.

shmctl(2)
Perform various control operations on a segment, including deletion.

IPC namespaces

For a discussion of the interaction of System V IPC objects and IPC namespaces, see ipc_namespaces(7).

SEE ALSO

ipcmk(1), ipcrm(1), ipcs(1), lsipc(1), ipc(2), msgctl(2), msgget(2), msgrcv(2), msgsnd(2), semctl(2), semget(2), semop(2), shmat(2), shmctl(2), shmdt(2), shmget(2), ftok(3), ipc_namespaces(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

153 - Linux cli command SHOW

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command SHOW and provides detailed information about the command SHOW, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the SHOW.

NAME 🖥️ SHOW 🖥️

show the value of a run-time parameter

SYNOPSIS

SHOW name
SHOW ALL

DESCRIPTION

SHOW will display the current setting of run-time parameters. These variables can be set using the SET statement, by editing the postgresql.conf configuration file, through the PGOPTIONS environmental variable (when using libpq or a libpq-based application), or through command-line flags when starting the postgres server. See Chapter 20 for details.

PARAMETERS

name

The name of a run-time parameter. Available parameters are documented in Chapter 20 and on the SET(7) reference page. In addition, there are a few parameters that can be shown but not set:

SERVER_VERSION

Shows the servers version number.

SERVER_ENCODING

Shows the server-side character set encoding. At present, this parameter can be shown but not set, because the encoding is determined at database creation time.

LC_COLLATE

Shows the databases locale setting for collation (text ordering). At present, this parameter can be shown but not set, because the setting is determined at database creation time.

LC_CTYPE

Shows the databases locale setting for character classification. At present, this parameter can be shown but not set, because the setting is determined at database creation time.

IS_SUPERUSER

True if the current role has superuser privileges.

ALL

Show the values of all configuration parameters, with descriptions.

NOTES

The function current_setting produces equivalent output; see Section 9.27.1. Also, the pg_settings system view produces the same information.

EXAMPLES

Show the current setting of the parameter DateStyle:

SHOW DateStyle; DateStyle ———– ISO, MDY (1 row)

Show the current setting of the parameter geqo:

SHOW geqo; geqo —— on (1 row)

Show all settings:

SHOW ALL; name | setting | description ————————-+———+————————————————- allow_system_table_mods | off | Allows modifications of the structure of … . . . xmloption | content | Sets whether XML data in implicit parsing … zero_damaged_pages | off | Continues processing past damaged page headers. (196 rows)

COMPATIBILITY

The SHOW command is a PostgreSQL extension.

SEE ALSO

SET(7), RESET(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

154 - Linux cli command provider-macssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command provider-macssl and provides detailed information about the command provider-macssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the provider-macssl.

NAME 🖥️ provider-macssl 🖥️

mac - The mac library <-> provider functions

SYNOPSIS

#include <openssl/core_dispatch.h> #include <openssl/core_names.h> /* * None of these are actual functions, but are displayed like this for * the function signatures for functions that are offered as function * pointers in OSSL_DISPATCH arrays. */ /* Context management */ void *OSSL_FUNC_mac_newctx(void *provctx); void OSSL_FUNC_mac_freectx(void *mctx); void *OSSL_FUNC_mac_dupctx(void *src); /* Encryption/decryption */ int OSSL_FUNC_mac_init(void *mctx, unsigned char *key, size_t keylen, const OSSL_PARAM params[]); int OSSL_FUNC_mac_update(void *mctx, const unsigned char *in, size_t inl); int OSSL_FUNC_mac_final(void *mctx, unsigned char *out, size_t *outl, size_t outsize); /* MAC parameter descriptors */ const OSSL_PARAM *OSSL_FUNC_mac_gettable_params(void *provctx); const OSSL_PARAM *OSSL_FUNC_mac_gettable_ctx_params(void *mctx, void *provctx); const OSSL_PARAM *OSSL_FUNC_mac_settable_ctx_params(void *mctx, void *provctx); /* MAC parameters */ int OSSL_FUNC_mac_get_params(OSSL_PARAM params[]); int OSSL_FUNC_mac_get_ctx_params(void *mctx, OSSL_PARAM params[]); int OSSL_FUNC_mac_set_ctx_params(void *mctx, const OSSL_PARAM params[]);

DESCRIPTION

This documentation is primarily aimed at provider authors. See provider (7) for further information.

The MAC operation enables providers to implement mac algorithms and make them available to applications via the API functions EVP_MAC_init (3), EVP_MAC_update (3) and EVP_MAC_final (3).

All “functions” mentioned here are passed as function pointers between libcrypto and the provider in OSSL_DISPATCH (3) arrays via OSSL_ALGORITHM (3) arrays that are returned by the provider’s provider_query_operation() function (see “Provider Functions” in provider-base (7)).

All these “functions” have a corresponding function type definition named OSSL_FUNC_{name}_fn, and a helper function to retrieve the function pointer from an OSSL_DISPATCH (3) element named OSSL_FUNC_{name}. For example, the “function” OSSL_FUNC_mac_newctx() has these:

typedef void *(OSSL_FUNC_mac_newctx_fn)(void *provctx); static ossl_inline OSSL_FUNC_mac_newctx_fn OSSL_FUNC_mac_newctx(const OSSL_DISPATCH *opf);

OSSL_DISPATCH (3) arrays are indexed by numbers that are provided as macros in openssl-core_dispatch.h (7), as follows:

OSSL_FUNC_mac_newctx OSSL_FUNC_MAC_NEWCTX OSSL_FUNC_mac_freectx OSSL_FUNC_MAC_FREECTX OSSL_FUNC_mac_dupctx OSSL_FUNC_MAC_DUPCTX OSSL_FUNC_mac_init OSSL_FUNC_MAC_INIT OSSL_FUNC_mac_update OSSL_FUNC_MAC_UPDATE OSSL_FUNC_mac_final OSSL_FUNC_MAC_FINAL OSSL_FUNC_mac_get_params OSSL_FUNC_MAC_GET_PARAMS OSSL_FUNC_mac_get_ctx_params OSSL_FUNC_MAC_GET_CTX_PARAMS OSSL_FUNC_mac_set_ctx_params OSSL_FUNC_MAC_SET_CTX_PARAMS OSSL_FUNC_mac_gettable_params OSSL_FUNC_MAC_GETTABLE_PARAMS OSSL_FUNC_mac_gettable_ctx_params OSSL_FUNC_MAC_GETTABLE_CTX_PARAMS OSSL_FUNC_mac_settable_ctx_params OSSL_FUNC_MAC_SETTABLE_CTX_PARAMS

A mac algorithm implementation may not implement all of these functions. In order to be a consistent set of functions, at least the following functions must be implemented: OSSL_FUNC_mac_newctx(), OSSL_FUNC_mac_freectx(), OSSL_FUNC_mac_init(), OSSL_FUNC_mac_update(), OSSL_FUNC_mac_final(). All other functions are optional.

Context Management Functions

OSSL_FUNC_mac_newctx() should create and return a pointer to a provider side structure for holding context information during a mac operation. A pointer to this context will be passed back in a number of the other mac operation function calls. The parameter provctx is the provider context generated during provider initialisation (see provider (7)).

OSSL_FUNC_mac_freectx() is passed a pointer to the provider side mac context in the mctx parameter. If it receives NULL as mctx value, it should not do anything other than return. This function should free any resources associated with that context.

OSSL_FUNC_mac_dupctx() should duplicate the provider side mac context in the mctx parameter and return the duplicate copy.

Encryption/Decryption Functions

OSSL_FUNC_mac_init() initialises a mac operation given a newly created provider side mac context in the mctx parameter. The params are set before setting the MAC key of keylen bytes.

OSSL_FUNC_mac_update() is called to supply data for MAC computation of a previously initialised mac operation. The mctx parameter contains a pointer to a previously initialised provider side context. OSSL_FUNC_mac_update() may be called multiple times for a single mac operation.

OSSL_FUNC_mac_final() completes the MAC computation started through previous OSSL_FUNC_mac_init() and OSSL_FUNC_mac_update() calls. The mctx parameter contains a pointer to the provider side context. The resulting MAC should be written to out and the amount of data written to *outl, which should not exceed outsize bytes. The same expectations apply to outsize as documented for EVP_MAC_final (3).

Mac Parameters

See OSSL_PARAM (3) for further details on the parameters structure used by these functions.

OSSL_FUNC_mac_get_params() gets details of parameter values associated with the provider algorithm and stores them in params.

OSSL_FUNC_mac_set_ctx_params() sets mac parameters associated with the given provider side mac context mctx to params. Any parameter settings are additional to any that were previously set. Passing NULL for params should return true.

OSSL_FUNC_mac_get_ctx_params() gets details of currently set parameter values associated with the given provider side mac context mctx and stores them in params. Passing NULL for params should return true.

OSSL_FUNC_mac_gettable_params(), OSSL_FUNC_mac_gettable_ctx_params(), and OSSL_FUNC_mac_settable_ctx_params() all return constant OSSL_PARAM (3) arrays as descriptors of the parameters that OSSL_FUNC_mac_get_params(), OSSL_FUNC_mac_get_ctx_params(), and OSSL_FUNC_mac_set_ctx_params() can handle, respectively. OSSL_FUNC_mac_gettable_ctx_params() and OSSL_FUNC_mac_settable_ctx_params() will return the parameters associated with the provider side context mctx in its current state if it is not NULL. Otherwise, they return the parameters associated with the provider side algorithm provctx.

All MAC implementations are expected to handle the following parameters:

with OSSL_FUNC_set_ctx_params():

“key” (OSSL_MAC_PARAM_KEY) <octet string>

Sets the key in the associated MAC ctx. This is identical to passing a key argument to the OSSL_FUNC_mac_init() function.

with OSSL_FUNC_get_params():

“size” (OSSL_MAC_PARAM_SIZE) <integer>

Can be used to get the default MAC size (which might be the only allowable MAC size for the implementation). Note that some implementations allow setting the size that the resulting MAC should have as well, see the documentation of the implementation.

“size” (OSSL_MAC_PARAM_BLOCK_SIZE) <integer>
Can be used to get the MAC block size (if supported by the algorithm).

NOTES

The MAC life-cycle is described in life_cycle-rand (7). Providers should ensure that the various transitions listed there are supported. At some point the EVP layer will begin enforcing the listed transitions.

RETURN VALUES

OSSL_FUNC_mac_newctx() and OSSL_FUNC_mac_dupctx() should return the newly created provider side mac context, or NULL on failure.

OSSL_FUNC_mac_init(), OSSL_FUNC_mac_update(), OSSL_FUNC_mac_final(), OSSL_FUNC_mac_get_params(), OSSL_FUNC_mac_get_ctx_params() and OSSL_FUNC_mac_set_ctx_params() should return 1 for success or 0 on error.

OSSL_FUNC_mac_gettable_params(), OSSL_FUNC_mac_gettable_ctx_params() and OSSL_FUNC_mac_settable_ctx_params() should return a constant OSSL_PARAM (3) array, or NULL if none is offered.

SEE ALSO

provider (7), EVP_MAC-BLAKE2 (7), EVP_MAC-CMAC (7), EVP_MAC-GMAC (7), EVP_MAC-HMAC (7), EVP_MAC-KMAC (7), EVP_MAC-Poly1305 (7), EVP_MAC-Siphash (7), life_cycle-mac (7), EVP_MAC (3)

HISTORY

The provider MAC interface was introduced in OpenSSL 3.0.

COPYRIGHT

Copyright 2019-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

155 - Linux cli command ROLLBACK_PREPARED

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ROLLBACK_PREPARED and provides detailed information about the command ROLLBACK_PREPARED, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ROLLBACK_PREPARED.

NAME 🖥️ ROLLBACK_PREPARED 🖥️

cancel a transaction that was earlier prepared for two-phase commit

SYNOPSIS

ROLLBACK PREPARED transaction_id

DESCRIPTION

ROLLBACK PREPARED rolls back a transaction that is in prepared state.

PARAMETERS

transaction_id

The transaction identifier of the transaction that is to be rolled back.

NOTES

To roll back a prepared transaction, you must be either the same user that executed the transaction originally, or a superuser. But you do not have to be in the same session that executed the transaction.

This command cannot be executed inside a transaction block. The prepared transaction is rolled back immediately.

All currently available prepared transactions are listed in the pg_prepared_xacts system view.

EXAMPLES

Roll back the transaction identified by the transaction identifier foobar:

ROLLBACK PREPARED foobar;

COMPATIBILITY

ROLLBACK PREPARED is a PostgreSQL extension. It is intended for use by external transaction management systems, some of which are covered by standards (such as X/Open XA), but the SQL side of those systems is not standardized.

SEE ALSO

PREPARE TRANSACTION (PREPARE_TRANSACTION(7)), COMMIT PREPARED (COMMIT_PREPARED(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

156 - Linux cli command groff_rfc1345

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command groff_rfc1345 and provides detailed information about the command groff_rfc1345, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the groff_rfc1345.

Name

groff_rfc1345 - special character names from RFC 1345 and Vim digraphs

Description

The file rfc1345.tmac defines special character escape sequences for

based on the glyph mnemonics specified in RFC 1345 and the digraph table of the text editor Vim. Each escape sequence translates to a Unicode code point, and will render correctly if the underlying font is a Unicode font that covers the code point.

For example, “\Rx]” is the “recipe” or “prescription take” symbol, and maps to the code point U+211E. groff lets you write it as “\u211E]”, but “\Rx]” is more mnemonic.

For a list of the glyph names provided, please see the file rfc1345.tmac, which contains definitions of the form

.char [Rx] [u211E] " PRESCRIPTION TAKE

where .char’s first argument defines a groff special character escape sequence with a mnemonic glyph name, its second argument is a special character escape sequence based on the code point, and the comment describes the glyph defined.

The RFC 1345 glyph names cover a wide range of Unicode code points, including supplemental Latin, Greek, Cyrillic, Hebrew, Arabic, Hiragana, Katakana, and Bopomofo letters, punctuation, math notation, currency symbols, industrial and entertainment icons, and box-drawing symbols.

The Vim digraph table is practically a subset of RFC 1345 (being limited to two-character mnemonics), but, as a newer implementation, adds four mnemonics not specified in the RFC (the horizontal ellipsis, the Euro sign, and two mappings for the rouble sign). These have also been added to rfc1345.tmac.

rfc1345.tmac contains a total of 1,696 glyph names. It is not an error to load rfc1345.tmac if your font does not have all the glyphs, as long as it contains the glyphs that you actually use in your document.

The RFC 1345 mnemonics are not identical in every case to the mappings for special character glyph names that are built in to groff; for example, “&lt;<]” means the “much less than” sign (U+226A) when rfc1345.tmac is not loaded and this special character is not otherwise defined by a document or macro package. rfc1345.tmac redefines “&lt;<]” to the “left-pointing double angle quotation mark” (U+00AB). See

for the full list of predefined special character escape sequences.

Usage

Load the rfc1345.tmac file. This can be done by either adding “.mso rfc1345.tmac” to your document before the first use of any of the glyph names the macro file defines, or by using the

option “-m rfc1345” from the shell.

Bugs

As the groff Texinfo manual notes, “[o]nly the current font is checked for ligatures and kerns; neither special fonts nor entities defined with the char request (and its siblings) are taken into account.” Many of the characters defined in rfc1345.tmac are accented Latin letters, and will be affected by this deficiency, producing subpar typography.

Files

/usr/share/groff/1.23.0/tmac/rfc1345.tmac
implements the character mappings.

Authors

rfc1345.tmac was contributed by Dorai Sitaram.

See also

RFC 1345, by Keld Simonsen, June 1992.

The Vim digraph table can be listed using the

command “:help digraph-table”.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

157 - Linux cli command asymmetric-key

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command asymmetric-key and provides detailed information about the command asymmetric-key, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the asymmetric-key.

NAME 🖥️ asymmetric-key 🖥️

Kernel key type for holding asymmetric keys

OVERVIEW

A kernel key of asymmetric type acts as a handle to an asymmetric key as used for public-key cryptography. The key material itself may be held inside the kernel or it may be held in hardware with operations being offloaded. This prevents direct user access to the cryptographic material.

Keys may be any asymmetric type (RSA, ECDSA, …) and may have both private and public components present or just the public component.

Asymmetric keys can be made use of by both the kernel and userspace. The kernel can make use of them for module signature verification and kexec image verification for example. Userspace is provided with a set of keyctl(KEYCTL_PKEY_*) calls for querying and using the key. These are wrapped by libkeyutils as functions named keyctl_pkey_*().

An asymmetric-type key can be loaded by the keyctl utility using a command line like:

openssl x509 -in key.x509 -outform DER |
keyctl padd asymmetric foo @s

DESCRIPTION

The asymmetric-type key can be viewed as a container that comprises of a number of components:

Parsers
The asymmetric key parsers attempt to identify the content of the payload blob and extract useful data from it with which to instantiate the key. The parser is only used when adding, instantiating or updating a key and isn’t thereafter associated with the key.

Available parsers include ones that can deal with DER-encoded X.509, DER-encoded PKCS#8 and DER-encoded TPM-wrapped blobs.

Public and private keys
These are the cryptographic components of the key pair. The public half should always be available, but the private half might not be. What operations are available can be queried, as can the size of the key. The key material may or may not actually reside in the kernel.

Identifiers
In addition to the normal key description (which can be generated by the parser), a number of supplementary identifiers may be available that can be searched for. These may be obtained, for example, by hashing the public key material or from the subjectKeyIdentifier in an X.509 certificate.

Identifier-based searches are selected by passing as the description to keyctl_search() a string constructed of hex characters prefixed with either “id:” or “ex:”. The “id:” prefix indicates that a partial tail match is permissible whereas “ex:” requires an exact match on the full string. The hex characters indicate the data to match.

Subtype
This is the driver inside the kernel that accesses the key material and performs operations on it. It might be entirely software-based or it may offload the operations to a hardware key store, such as a TPM.

Note that expiry times from the payload are ignored as these patches may be used during boot before the system clock is set.

PARSERS

The asymmetric key parsers can handle keys in a number of forms:

X.509
DER-encoded X.509 certificates can be accepted. Two identifiers are constructed: one from from the certificate issuer and serial number and the other from the subjectKeyIdentifier, if present. If left blank, the key description will be filled in from the subject field plus either the subjectKeyIdentifier or the serialNumber. Only the public key is filled in and only the encrypt and verify operations are supported.

The signature on the X.509 certificate may be checked by the keyring it is being added to and it may also be rejected if the key is blacklisted.

PKCS#8
Unencrypted DER-encoded PKCS#8 key data containers can be accepted. Currently no identifiers are constructed. The private key and the public key are loaded from the PKCS#8 blobs. Encrypted PKCS#8 is not currently supported.

TPM-Wrapped keys
DER-encoded TPM-wrapped TSS key blobs can be accepted. Currently no identifiers are constructed. The public key is extracted from the blob but the private key is expected to be resident in the TPM. Encryption and signature verification is done in software, but decryption and signing are offloaded to the TPM so as not to expose the private key.

This parser only supports TPM-1.2 wrappings and enc=pkcs1 encoding type. It also uses a hard-coded null SRK password; password-protected SRKs are not yet supported.

USERSPACE API

In addition to the standard keyutils library functions, such as keyctl_update(), there are five calls specific to the asymmetric key type (though they are open to being used by other key types also):

keyctl_pkey_query()
keyctl_pkey_encrypt()
keyctl_pkey_decrypt()
keyctl_pkey_sign()
keyctl_pkey_verify()

The query function can be used to retrieve information about an asymmetric key, such as the key size, the amount of space required by buffers for the other operations and which operations are actually supported.

The other operations form two pairs: encrypt/decrypt and create/verify signature. Not all of these operations will necessarily be available; typically, encrypt and verify only require the public key to be available whereas decrypt and sign require the private key as well.

All of these operations take an information string parameter that supplies additional information such as encoding type/form and the password(s) needed to unlock/unwrap the key. This takes the form of a comma-separated list of “key[=value]” pairs, the exact set of which depends on the subtype driver used by a particular key.

Available parameters include:

enc=<type>
The encoding type for use in an encrypted blob or a signature. An example might be “enc=pkcs1”.

hash=<name>
The name of the hash algorithm that was used to digest the data to be signed. Note that this is only used to construct any encoding that is used in a signature. The data to be signed or verified must have been parsed by the caller and the hash passed to keyctl_pkey_sign() or keyctl_pkey_verify() beforehand. An example might be “hash=sha256”.

Note that not all parameters are used by all subtypes.

RESTRICTED KEYRINGS

An additional keyutils function, keyctl_restrict_keyring(), can be used to gate a keyring so that a new key can only be added to the affected keyring if (a) it’s an asymmetric key, (b) it’s validly signed by a key in some appropriate keyring and (c) it’s not blacklisted.

 keyctl_restrict_keyring(keyring, "asymmetric",
                         "key_or_keyring:<signing-key>[:chain]");

Where <signing-key> is the ID of a key or a ring of keys that act as the authority to permit a new key to be added to the keyring. The chain flag indicates that keys that have been added to the keyring may also be used to verify new keys. Authorising keys must themselves be asymmetric-type keys that can be used to do a signature verification on the key being added.

Note that there are various system keyrings visible to the root user that may permit additional keys to be added. These are typically gated by keys that already exist, preventing unauthorised keys from being used for such things as module verification.

BLACKLISTING

When the attempt is made to add a key to the kernel, a hash of the public key is checked against the blacklist. This is a system keyring named .blacklist and contains keys of type blacklist. If the blacklist contains a key whose description matches the hash of the new key, that new key will be rejected with error EKEYREJECTED.

The blacklist keyring may be loaded from multiple sources, including a list compiled into the kernel and the UEFI dbx variable. Further hashes may also be blacklisted by the administrator. Note that blacklisting is not retroactive, so an asymmetric key that is already on the system cannot be blacklisted by adding a matching blacklist entry later.

VERSIONS

The asymmetric key type first appeared in v3.7 of the Linux kernel, the restriction function in v4.11 and the public key operations in v4.20.

SEE ALSO

keyctl(1), add_key(2), keyctl(3), keyctl_pkey_encrypt(3), keyctl_pkey_query(3), keyctl_pkey_sign(3), keyrings(7), keyutils(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

158 - Linux cli command iso_8859_13

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso_8859_13 and provides detailed information about the command iso_8859_13, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso_8859_13.

NAME 🖥️ iso_8859_13 🖥️

13 - ISO/IEC 8859-13 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-13 encodes the characters used in Baltic Rim languages.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-13 characters

The following table displays the characters in ISO/IEC 8859-13 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-13 is also known as Latin-7.

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

159 - Linux cli command INSERT

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command INSERT and provides detailed information about the command INSERT, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the INSERT.

NAME 🖥️ INSERT 🖥️

create new rows in a table

SYNOPSIS

[ WITH [ RECURSIVE ] with_query [, ...] ]
INSERT INTO table_name [ AS alias ] [ ( column_name [, ...] ) ]
    [ OVERRIDING { SYSTEM | USER } VALUE ]
    { DEFAULT VALUES | VALUES ( { expression | DEFAULT } [, ...] ) [, ...] | query }
    [ ON CONFLICT [ conflict_target ] conflict_action ]
    [ RETURNING { * | output_expression [ [ AS ] output_name ] } [, ...] ]

where conflict_target can be one of:

    ( { index_column_name | ( index_expression ) } [ COLLATE collation ] [ opclass ] [, ...] ) [ WHERE index_predicate ]
    ON CONSTRAINT constraint_name

and conflict_action is one of:

    DO NOTHING
    DO UPDATE SET { column_name = { expression | DEFAULT } |
                    ( column_name [, ...] ) = [ ROW ] ( { expression | DEFAULT } [, ...] ) |
                    ( column_name [, ...] ) = ( sub-SELECT )
                  } [, ...]
              [ WHERE condition ]

DESCRIPTION

INSERT inserts new rows into a table. One can insert one or more rows specified by value expressions, or zero or more rows resulting from a query.

The target column names can be listed in any order. If no list of column names is given at all, the default is all the columns of the table in their declared order; or the first N column names, if there are only N columns supplied by the VALUES clause or query. The values supplied by the VALUES clause or query are associated with the explicit or implicit column list left-to-right.

Each column not present in the explicit or implicit column list will be filled with a default value, either its declared default value or null if there is none.

If the expression for any column is not of the correct data type, automatic type conversion will be attempted.

INSERT into tables that lack unique indexes will not be blocked by concurrent activity. Tables with unique indexes might block if concurrent sessions perform actions that lock or modify rows matching the unique index values being inserted; the details are covered in Section 64.5. ON CONFLICT can be used to specify an alternative action to raising a unique constraint or exclusion constraint violation error. (See ON CONFLICT Clause below.)

The optional RETURNING clause causes INSERT to compute and return value(s) based on each row actually inserted (or updated, if an ON CONFLICT DO UPDATE clause was used). This is primarily useful for obtaining values that were supplied by defaults, such as a serial sequence number. However, any expression using the tables columns is allowed. The syntax of the RETURNING list is identical to that of the output list of SELECT. Only rows that were successfully inserted or updated will be returned. For example, if a row was locked but not updated because an ON CONFLICT DO UPDATE … WHERE clause condition was not satisfied, the row will not be returned.

You must have INSERT privilege on a table in order to insert into it. If ON CONFLICT DO UPDATE is present, UPDATE privilege on the table is also required.

If a column list is specified, you only need INSERT privilege on the listed columns. Similarly, when ON CONFLICT DO UPDATE is specified, you only need UPDATE privilege on the column(s) that are listed to be updated. However, ON CONFLICT DO UPDATE also requires SELECT privilege on any column whose values are read in the ON CONFLICT DO UPDATE expressions or condition.

Use of the RETURNING clause requires SELECT privilege on all columns mentioned in RETURNING. If you use the query clause to insert rows from a query, you of course need to have SELECT privilege on any table or column used in the query.

PARAMETERS

Inserting

This section covers parameters that may be used when only inserting new rows. Parameters exclusively used with the ON CONFLICT clause are described separately.

with_query

The WITH clause allows you to specify one or more subqueries that can be referenced by name in the INSERT query. See Section 7.8 and SELECT(7) for details.

It is possible for the query (SELECT statement) to also contain a WITH clause. In such a case both sets of with_query can be referenced within the query, but the second one takes precedence since it is more closely nested.

table_name

The name (optionally schema-qualified) of an existing table.

alias

A substitute name for table_name. When an alias is provided, it completely hides the actual name of the table. This is particularly useful when ON CONFLICT DO UPDATE targets a table named excluded, since that will otherwise be taken as the name of the special table representing the row proposed for insertion.

column_name

The name of a column in the table named by table_name. The column name can be qualified with a subfield name or array subscript, if needed. (Inserting into only some fields of a composite column leaves the other fields null.) When referencing a column with ON CONFLICT DO UPDATE, do not include the tables name in the specification of a target column. For example, INSERT INTO table_name … ON CONFLICT DO UPDATE SET table_name.col = 1 is invalid (this follows the general behavior for UPDATE).

OVERRIDING SYSTEM VALUE

If this clause is specified, then any values supplied for identity columns will override the default sequence-generated values.

For an identity column defined as GENERATED ALWAYS, it is an error to insert an explicit value (other than DEFAULT) without specifying either OVERRIDING SYSTEM VALUE or OVERRIDING USER VALUE. (For an identity column defined as GENERATED BY DEFAULT, OVERRIDING SYSTEM VALUE is the normal behavior and specifying it does nothing, but PostgreSQL allows it as an extension.)

OVERRIDING USER VALUE

If this clause is specified, then any values supplied for identity columns are ignored and the default sequence-generated values are applied.

This clause is useful for example when copying values between tables. Writing INSERT INTO tbl2 OVERRIDING USER VALUE SELECT * FROM tbl1 will copy from tbl1 all columns that are not identity columns in tbl2 while values for the identity columns in tbl2 will be generated by the sequences associated with tbl2.

DEFAULT VALUES

All columns will be filled with their default values, as if DEFAULT were explicitly specified for each column. (An OVERRIDING clause is not permitted in this form.)

expression

An expression or value to assign to the corresponding column.

DEFAULT

The corresponding column will be filled with its default value. An identity column will be filled with a new value generated by the associated sequence. For a generated column, specifying this is permitted but merely specifies the normal behavior of computing the column from its generation expression.

query

A query (SELECT statement) that supplies the rows to be inserted. Refer to the SELECT(7) statement for a description of the syntax.

output_expression

An expression to be computed and returned by the INSERT command after each row is inserted or updated. The expression can use any column names of the table named by table_name. Write * to return all columns of the inserted or updated row(s).

output_name

A name to use for a returned column.

ON CONFLICT Clause

The optional ON CONFLICT clause specifies an alternative action to raising a unique violation or exclusion constraint violation error. For each individual row proposed for insertion, either the insertion proceeds, or, if an arbiter constraint or index specified by conflict_target is violated, the alternative conflict_action is taken. ON CONFLICT DO NOTHING simply avoids inserting a row as its alternative action. ON CONFLICT DO UPDATE updates the existing row that conflicts with the row proposed for insertion as its alternative action.

conflict_target can perform unique index inference. When performing inference, it consists of one or more index_column_name columns and/or index_expression expressions, and an optional index_predicate. All table_name unique indexes that, without regard to order, contain exactly the conflict_target-specified columns/expressions are inferred (chosen) as arbiter indexes. If an index_predicate is specified, it must, as a further requirement for inference, satisfy arbiter indexes. Note that this means a non-partial unique index (a unique index without a predicate) will be inferred (and thus used by ON CONFLICT) if such an index satisfying every other criteria is available. If an attempt at inference is unsuccessful, an error is raised.

ON CONFLICT DO UPDATE guarantees an atomic INSERT or UPDATE outcome; provided there is no independent error, one of those two outcomes is guaranteed, even under high concurrency. This is also known as UPSERT — “UPDATE or INSERT”.

conflict_target

Specifies which conflicts ON CONFLICT takes the alternative action on by choosing arbiter indexes. Either performs unique index inference, or names a constraint explicitly. For ON CONFLICT DO NOTHING, it is optional to specify a conflict_target; when omitted, conflicts with all usable constraints (and unique indexes) are handled. For ON CONFLICT DO UPDATE, a conflict_target must be provided.

conflict_action

conflict_action specifies an alternative ON CONFLICT action. It can be either DO NOTHING, or a DO UPDATE clause specifying the exact details of the UPDATE action to be performed in case of a conflict. The SET and WHERE clauses in ON CONFLICT DO UPDATE have access to the existing row using the tables name (or an alias), and to the row proposed for insertion using the special excluded table. SELECT privilege is required on any column in the target table where corresponding excluded columns are read.

Note that the effects of all per-row BEFORE INSERT triggers are reflected in excluded values, since those effects may have contributed to the row being excluded from insertion.

index_column_name

The name of a table_name column. Used to infer arbiter indexes. Follows CREATE INDEX format. SELECT privilege on index_column_name is required.

index_expression

Similar to index_column_name, but used to infer expressions on table_name columns appearing within index definitions (not simple columns). Follows CREATE INDEX format. SELECT privilege on any column appearing within index_expression is required.

collation

When specified, mandates that corresponding index_column_name or index_expression use a particular collation in order to be matched during inference. Typically this is omitted, as collations usually do not affect whether or not a constraint violation occurs. Follows CREATE INDEX format.

opclass

When specified, mandates that corresponding index_column_name or index_expression use particular operator class in order to be matched during inference. Typically this is omitted, as the equality semantics are often equivalent across a types operator classes anyway, or because its sufficient to trust that the defined unique indexes have the pertinent definition of equality. Follows CREATE INDEX format.

index_predicate

Used to allow inference of partial unique indexes. Any indexes that satisfy the predicate (which need not actually be partial indexes) can be inferred. Follows CREATE INDEX format. SELECT privilege on any column appearing within index_predicate is required.

constraint_name

Explicitly specifies an arbiter constraint by name, rather than inferring a constraint or index.

condition

An expression that returns a value of type boolean. Only rows for which this expression returns true will be updated, although all rows will be locked when the ON CONFLICT DO UPDATE action is taken. Note that condition is evaluated last, after a conflict has been identified as a candidate to update.

Note that exclusion constraints are not supported as arbiters with ON CONFLICT DO UPDATE. In all cases, only NOT DEFERRABLE constraints and unique indexes are supported as arbiters.

INSERT with an ON CONFLICT DO UPDATE clause is a “deterministic” statement. This means that the command will not be allowed to affect any single existing row more than once; a cardinality violation error will be raised when this situation arises. Rows proposed for insertion should not duplicate each other in terms of attributes constrained by an arbiter index or constraint.

Note that it is currently not supported for the ON CONFLICT DO UPDATE clause of an INSERT applied to a partitioned table to update the partition key of a conflicting row such that it requires the row be moved to a new partition.

Tip

It is often preferable to use unique index inference rather than naming a constraint directly using ON CONFLICT ON CONSTRAINT constraint_name. Inference will continue to work correctly when the underlying index is replaced by another more or less equivalent index in an overlapping way, for example when using CREATE UNIQUE INDEX … CONCURRENTLY before dropping the index being replaced.

OUTPUTS

On successful completion, an INSERT command returns a command tag of the form

INSERT oid count

The count is the number of rows inserted or updated. oid is always 0 (it used to be the OID assigned to the inserted row if count was exactly one and the target table was declared WITH OIDS and 0 otherwise, but creating a table WITH OIDS is not supported anymore).

If the INSERT command contains a RETURNING clause, the result will be similar to that of a SELECT statement containing the columns and values defined in the RETURNING list, computed over the row(s) inserted or updated by the command.

NOTES

If the specified table is a partitioned table, each row is routed to the appropriate partition and inserted into it. If the specified table is a partition, an error will occur if one of the input rows violates the partition constraint.

You may also wish to consider using MERGE, since that allows mixing INSERT, UPDATE, and DELETE within a single statement. See MERGE(7).

EXAMPLES

Insert a single row into table films:

INSERT INTO films VALUES (UA502, Bananas, 105, 1971-07-13, Comedy, 82 minutes);

In this example, the len column is omitted and therefore it will have the default value:

INSERT INTO films (code, title, did, date_prod, kind) VALUES (T_601, Yojimbo, 106, 1961-06-16, Drama);

This example uses the DEFAULT clause for the date columns rather than specifying a value:

INSERT INTO films VALUES (UA502, Bananas, 105, DEFAULT, Comedy, 82 minutes); INSERT INTO films (code, title, did, date_prod, kind) VALUES (T_601, Yojimbo, 106, DEFAULT, Drama);

To insert a row consisting entirely of default values:

INSERT INTO films DEFAULT VALUES;

To insert multiple rows using the multirow VALUES syntax:

INSERT INTO films (code, title, did, date_prod, kind) VALUES (B6717, Tampopo, 110, 1985-02-10, Comedy), (HG120, The Dinner Game, 140, DEFAULT, Comedy);

This example inserts some rows into table films from a table tmp_films with the same column layout as films:

INSERT INTO films SELECT * FROM tmp_films WHERE date_prod < 2004-05-07;

This example inserts into array columns:

– Create an empty 3x3 gameboard for noughts-and-crosses INSERT INTO tictactoe (game, board[1:3][1:3]) VALUES (1, {{" “,” “,” “},{” “,” “,” “},{” “,” “,” “}}); – The subscripts in the above example arent really needed INSERT INTO tictactoe (game, board) VALUES (2, {{X,” “,” “},{” “,O,” “},{” “,X,” “}});

Insert a single row into table distributors, returning the sequence number generated by the DEFAULT clause:

INSERT INTO distributors (did, dname) VALUES (DEFAULT, XYZ Widgets) RETURNING did;

Increment the sales count of the salesperson who manages the account for Acme Corporation, and record the whole updated row along with current time in a log table:

WITH upd AS ( UPDATE employees SET sales_count = sales_count + 1 WHERE id = (SELECT sales_person FROM accounts WHERE name = Acme Corporation) RETURNING * ) INSERT INTO employees_log SELECT *, current_timestamp FROM upd;

Insert or update new distributors as appropriate. Assumes a unique index has been defined that constrains values appearing in the did column. Note that the special excluded table is used to reference values originally proposed for insertion:

INSERT INTO distributors (did, dname) VALUES (5, Gizmo Transglobal), (6, Associated Computing, Inc) ON CONFLICT (did) DO UPDATE SET dname = EXCLUDED.dname;

Insert a distributor, or do nothing for rows proposed for insertion when an existing, excluded row (a row with a matching constrained column or columns after before row insert triggers fire) exists. Example assumes a unique index has been defined that constrains values appearing in the did column:

INSERT INTO distributors (did, dname) VALUES (7, Redline GmbH) ON CONFLICT (did) DO NOTHING;

Insert or update new distributors as appropriate. Example assumes a unique index has been defined that constrains values appearing in the did column. WHERE clause is used to limit the rows actually updated (any existing row not updated will still be locked, though):

– Dont update existing distributors based in a certain ZIP code INSERT INTO distributors AS d (did, dname) VALUES (8, Anvil Distribution) ON CONFLICT (did) DO UPDATE SET dname = EXCLUDED.dname || (formerly || d.dname || ) WHERE d.zipcode <> 21201;

-- Name a constraint directly in the statement (uses associated
-- index to arbitrate taking the DO NOTHING action)
INSERT INTO distributors (did, dname) VALUES (9, Antwerp Design)
    ON CONFLICT ON CONSTRAINT distributors_pkey DO NOTHING;

Insert new distributor if possible; otherwise DO NOTHING. Example assumes a unique index has been defined that constrains values appearing in the did column on a subset of rows where the is_active Boolean column evaluates to true:

– This statement could infer a partial unique index on “did” – with a predicate of “WHERE is_active”, but it could also – just use a regular unique constraint on “did” INSERT INTO distributors (did, dname) VALUES (10, Conrad International) ON CONFLICT (did) WHERE is_active DO NOTHING;

COMPATIBILITY

INSERT conforms to the SQL standard, except that the RETURNING clause is a PostgreSQL extension, as is the ability to use WITH with INSERT, and the ability to specify an alternative action with ON CONFLICT. Also, the case in which a column name list is omitted, but not all the columns are filled from the VALUES clause or query, is disallowed by the standard. If you prefer a more SQL standard conforming statement than ON CONFLICT, see MERGE(7).

The SQL standard specifies that OVERRIDING SYSTEM VALUE can only be specified if an identity column that is generated always exists. PostgreSQL allows the clause in any case and ignores it if it is not applicable.

Possible limitations of the query clause are documented under SELECT(7).

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

160 - Linux cli command latin8

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command latin8 and provides detailed information about the command latin8, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the latin8.

NAME 🖥️ latin8 🖥️

14 - ISO/IEC 8859-14 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-14 encodes the characters used in Celtic languages.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-14 characters

The following table displays the characters in ISO/IEC 8859-14 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-14 is also known as Latin-8.

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

161 - Linux cli command EVP_KDF-TLS1_PRFssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KDF-TLS1_PRFssl and provides detailed information about the command EVP_KDF-TLS1_PRFssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KDF-TLS1_PRFssl.

NAME 🖥️ EVP_KDF-TLS1_PRFssl 🖥️

TLS1_PRF - The TLS1 PRF EVP_KDF implementation

DESCRIPTION

Support for computing the TLS1 PRF through the EVP_KDF API.

The EVP_KDF-TLS1_PRF algorithm implements the PRF used by TLS versions up to and including TLS 1.2.

Identity

“TLS1-PRF” is the name for this implementation; it can be used with the EVP_KDF_fetch() function.

Supported parameters

The supported parameters are:

“properties” (OSSL_KDF_PARAM_PROPERTIES) <UTF8 string>

“digest” (OSSL_KDF_PARAM_DIGEST) <UTF8 string>

These parameters work as described in “PARAMETERS” in EVP_KDF (3). The OSSL_KDF_PARAM_DIGEST parameter is used to set the message digest associated with the TLS PRF. EVP_md5_sha1() is treated as a special case which uses the PRF algorithm using both MD5 and SHA1 as used in TLS 1.0 and 1.1.

“secret” (OSSL_KDF_PARAM_SECRET) <octet string>
This parameter sets the secret value of the TLS PRF. Any existing secret value is replaced.

“seed” (OSSL_KDF_PARAM_SEED) <octet string>
This parameter sets the context seed. The length of the context seed cannot exceed 1024 bytes; this should be more than enough for any normal use of the TLS PRF.

NOTES

A context for the TLS PRF can be obtained by calling:

EVP_KDF *kdf = EVP_KDF_fetch(NULL, “TLS1-PRF”, NULL); EVP_KDF_CTX *kctx = EVP_KDF_CTX_new(kdf);

The digest, secret value and seed must be set before a key is derived otherwise an error will occur.

The output length of the PRF is specified by the keylen parameter to the EVP_KDF_derive() function.

EXAMPLES

This example derives 10 bytes using SHA-256 with the secret key “secret” and seed value “seed”:

EVP_KDF *kdf; EVP_KDF_CTX *kctx; unsigned char out[10]; OSSL_PARAM params[4], *p = params; kdf = EVP_KDF_fetch(NULL, “TLS1-PRF”, NULL); kctx = EVP_KDF_CTX_new(kdf); EVP_KDF_free(kdf); *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_DIGEST, SN_sha256, strlen(SN_sha256)); *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_SECRET, “secret”, (size_t)6); *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_SEED, “seed”, (size_t)4); *p = OSSL_PARAM_construct_end(); if (EVP_KDF_derive(kctx, out, sizeof(out), params) <= 0) { error(“EVP_KDF_derive”); } EVP_KDF_CTX_free(kctx);

CONFORMING TO

RFC 2246, RFC 5246 and NIST SP 800-135 r1

SEE ALSO

EVP_KDF (3), EVP_KDF_CTX_new (3), EVP_KDF_CTX_free (3), EVP_KDF_CTX_set_params (3), EVP_KDF_derive (3), “PARAMETERS” in EVP_KDF (3)

HISTORY

This functionality was added in OpenSSL 3.0.

COPYRIGHT

Copyright 2018-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

162 - Linux cli command DROP_SCHEMA

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_SCHEMA and provides detailed information about the command DROP_SCHEMA, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_SCHEMA.

NAME 🖥️ DROP_SCHEMA 🖥️

remove a schema

SYNOPSIS

DROP SCHEMA [ IF EXISTS ] name [, ...] [ CASCADE | RESTRICT ]

DESCRIPTION

DROP SCHEMA removes schemas from the database.

A schema can only be dropped by its owner or a superuser. Note that the owner can drop the schema (and thereby all contained objects) even if they do not own some of the objects within the schema.

PARAMETERS

IF EXISTS

Do not throw an error if the schema does not exist. A notice is issued in this case.

name

The name of a schema.

CASCADE

Automatically drop objects (tables, functions, etc.) that are contained in the schema, and in turn all objects that depend on those objects (see Section 5.14).

RESTRICT

Refuse to drop the schema if it contains any objects. This is the default.

NOTES

Using the CASCADE option might make the command remove objects in other schemas besides the one(s) named.

EXAMPLES

To remove schema mystuff from the database, along with everything it contains:

DROP SCHEMA mystuff CASCADE;

COMPATIBILITY

DROP SCHEMA is fully conforming with the SQL standard, except that the standard only allows one schema to be dropped per command, and apart from the IF EXISTS option, which is a PostgreSQL extension.

SEE ALSO

ALTER SCHEMA (ALTER_SCHEMA(7)), CREATE SCHEMA (CREATE_SCHEMA(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

163 - Linux cli command EVP_PKEY-DSAssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_PKEY-DSAssl and provides detailed information about the command EVP_PKEY-DSAssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_PKEY-DSAssl.

NAME 🖥️ EVP_PKEY-DSAssl 🖥️

DSA, EVP_KEYMGMT-DSA - EVP_PKEY DSA keytype and algorithm support

DESCRIPTION

For DSA the FIPS186-4 standard specifies that the values used for FFC parameter generation are also required for parameter validation. This means that optional FFC domain parameter values for seed, pcounter and gindex may need to be stored for validation purposes. For DSA these fields are not stored in the ASN1 data so they need to be stored externally if validation is required.

DSA parameters

The DSA key type supports the FFC parameters (see “FFC parameters” in EVP_PKEY-FFC (7)).

DSA key generation parameters

The DSA key type supports the FFC key generation parameters (see “FFC key generation parameters” in EVP_PKEY-FFC (7)

The following restrictions apply to the “pbits” field:

For “fips186_4” this must be either 2048 or 3072. For “fips186_2” this must be 1024. For “group” this can be any one of 2048, 3072, 4096, 6144 or 8192.

DSA key validation

For DSA keys, EVP_PKEY_param_check (3) behaves in the following way: The OpenSSL FIPS provider conforms to the rules within the FIPS186-4 standard for FFC parameter validation. For backwards compatibility the OpenSSL default provider uses a much simpler check (see below) for parameter validation, unless the seed parameter is set.

For DSA keys, EVP_PKEY_param_check_quick (3) behaves in the following way: A simple check of L and N and partial g is performed. The default provider also supports validation of legacy “fips186_2” keys.

For DSA keys, EVP_PKEY_public_check (3), EVP_PKEY_private_check (3) and EVP_PKEY_pairwise_check (3) the OpenSSL default and FIPS providers conform to the rules within SP800-56Ar3 for public, private and pairwise tests respectively.

EXAMPLES

An EVP_PKEY context can be obtained by calling:

EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “DSA”, NULL);

The DSA domain parameters can be generated by calling:

unsigned int pbits = 2048; unsigned int qbits = 256; int gindex = 1; OSSL_PARAM params[5]; EVP_PKEY *param_key = NULL; EVP_PKEY_CTX *pctx = NULL; pctx = EVP_PKEY_CTX_new_from_name(NULL, “DSA”, NULL); EVP_PKEY_paramgen_init(pctx); params[0] = OSSL_PARAM_construct_uint(“pbits”, &pbits); params[1] = OSSL_PARAM_construct_uint(“qbits”, &qbits); params[2] = OSSL_PARAM_construct_int(“gindex”, &gindex); params[3] = OSSL_PARAM_construct_utf8_string(“digest”, “SHA384”, 0); params[4] = OSSL_PARAM_construct_end(); EVP_PKEY_CTX_set_params(pctx, params); EVP_PKEY_generate(pctx, &param_key); EVP_PKEY_CTX_free(pctx); EVP_PKEY_print_params(bio_out, param_key, 0, NULL);

A DSA key can be generated using domain parameters by calling:

EVP_PKEY *key = NULL; EVP_PKEY_CTX *gctx = NULL; gctx = EVP_PKEY_CTX_new_from_pkey(NULL, param_key, NULL); EVP_PKEY_keygen_init(gctx); EVP_PKEY_generate(gctx, &key); EVP_PKEY_CTX_free(gctx); EVP_PKEY_print_private(bio_out, key, 0, NULL);

CONFORMING TO

The following sections of FIPS186-4:

SEE ALSO

EVP_PKEY-FFC (7), EVP_SIGNATURE-DSA (7) EVP_PKEY (3), provider-keymgmt (7), EVP_KEYMGMT (3), OSSL_PROVIDER-default (7), OSSL_PROVIDER-FIPS (7)

COPYRIGHT

Copyright 2020-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

164 - Linux cli command iso-8859-16

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso-8859-16 and provides detailed information about the command iso-8859-16, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso-8859-16.

NAME 🖥️ iso-8859-16 🖥️

16 - ISO/IEC 8859-16 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-16 encodes the Latin characters used in Southeast European languages.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-16 characters

The following table displays the characters in ISO/IEC 8859-16 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-16 is also known as Latin-10.

SEE ALSO

ascii(7), charsets(7), iso_8859-3(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

165 - Linux cli command EVP_SIGNATURE-HMACssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_SIGNATURE-HMACssl and provides detailed information about the command EVP_SIGNATURE-HMACssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_SIGNATURE-HMACssl.

NAME 🖥️ EVP_SIGNATURE-HMACssl 🖥️

HMAC, EVP_SIGNATURE-Siphash, EVP_SIGNATURE-Poly1305, EVP_SIGNATURE-CMAC - The legacy EVP_PKEY MAC signature implementations

DESCRIPTION

The algorithms described here have legacy support for creating MACs using EVP_DigestSignInit (3) and related functions. This is not the preferred way of creating MACs. Instead you should use the newer EVP_MAC_init (3) functions. This mechanism is provided for backwards compatibility with older versions of OpenSSL.

The same signature parameters can be set using EVP_PKEY_CTX_set_params() as can be set via EVP_MAC_CTX_set_params() for the underlying EVP_MAC. See EVP_MAC-HMAC (7), EVP_MAC-Siphash (7), EVP_MAC-Poly1305 (7) and EVP_MAC-CMAC (7) for details.

See L<EVP_PKEY-HMAC(7)>, L<EVP_PKEY-Siphash(7)>, L<EVP_PKEY-Poly1305(7)> or L<EVP_PKEY-CMAC(7)> for details about parameters that are supported during the creation of an EVP_PKEY.

SEE ALSO

EVP_MAC_init (3), EVP_DigestSignInit (3), EVP_PKEY-HMAC (7), EVP_PKEY-Siphash (7), EVP_PKEY-Poly1305 (7), EVP_PKEY-CMAC (7), EVP_MAC-HMAC (7), EVP_MAC-Siphash (7), EVP_MAC-Poly1305 (7), EVP_MAC-CMAC (7), provider-signature (7),

COPYRIGHT

Copyright 2020 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

166 - Linux cli command iso_8859-1

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso_8859-1 and provides detailed information about the command iso_8859-1, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso_8859-1.

NAME 🖥️ iso_8859-1 🖥️

1 - ISO/IEC 8859-1 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-1 encodes the characters used in many West European languages.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-1 characters

The following table displays the characters in ISO/IEC 8859-1 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-1 is also known as Latin-1.

SEE ALSO

ascii(7), charsets(7), cp1252(7), iso_8859-15(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

167 - Linux cli command ALTER_STATISTICS

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_STATISTICS and provides detailed information about the command ALTER_STATISTICS, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_STATISTICS.

NAME 🖥️ ALTER_STATISTICS 🖥️

change the definition of an extended statistics object

SYNOPSIS

ALTER STATISTICS name OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }
ALTER STATISTICS name RENAME TO new_name
ALTER STATISTICS name SET SCHEMA new_schema
ALTER STATISTICS name SET STATISTICS new_target

DESCRIPTION

ALTER STATISTICS changes the parameters of an existing extended statistics object. Any parameters not specifically set in the ALTER STATISTICS command retain their prior settings.

You must own the statistics object to use ALTER STATISTICS. To change a statistics objects schema, you must also have CREATE privilege on the new schema. To alter the owner, you must be able to SET ROLE to the new owning role, and that role must have CREATE privilege on the statistics objects schema. (These restrictions enforce that altering the owner doesnt do anything you couldnt do by dropping and recreating the statistics object. However, a superuser can alter ownership of any statistics object anyway.)

PARAMETERS

name

The name (optionally schema-qualified) of the statistics object to be altered.

new_owner

The user name of the new owner of the statistics object.

new_name

The new name for the statistics object.

new_schema

The new schema for the statistics object.

new_target

The statistic-gathering target for this statistics object for subsequent ANALYZE operations. The target can be set in the range 0 to 10000; alternatively, set it to -1 to revert to using the maximum of the statistics target of the referenced columns, if set, or the system default statistics target (default_statistics_target). For more information on the use of statistics by the PostgreSQL query planner, refer to Section 14.2.

COMPATIBILITY

There is no ALTER STATISTICS command in the SQL standard.

SEE ALSO

CREATE STATISTICS (CREATE_STATISTICS(7)), DROP STATISTICS (DROP_STATISTICS(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

168 - Linux cli command VACUUM

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command VACUUM and provides detailed information about the command VACUUM, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the VACUUM.

NAME 🖥️ VACUUM 🖥️

garbage-collect and optionally analyze a database

SYNOPSIS

VACUUM [ ( option [, ...] ) ] [ table_and_columns [, ...] ]
VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] [ ANALYZE ] [ table_and_columns [, ...] ]

where option can be one of:

    FULL [ boolean ]
    FREEZE [ boolean ]
    VERBOSE [ boolean ]
    ANALYZE [ boolean ]
    DISABLE_PAGE_SKIPPING [ boolean ]
    SKIP_LOCKED [ boolean ]
    INDEX_CLEANUP { AUTO | ON | OFF }
    PROCESS_MAIN [ boolean ]
    PROCESS_TOAST [ boolean ]
    TRUNCATE [ boolean ]
    PARALLEL integer
    SKIP_DATABASE_STATS [ boolean ]
    ONLY_DATABASE_STATS [ boolean ]
    BUFFER_USAGE_LIMIT size

and table_and_columns is:

    table_name [ ( column_name [, ...] ) ]

DESCRIPTION

VACUUM reclaims storage occupied by dead tuples. In normal PostgreSQL operation, tuples that are deleted or obsoleted by an update are not physically removed from their table; they remain present until a VACUUM is done. Therefore its necessary to do VACUUM periodically, especially on frequently-updated tables.

Without a table_and_columns list, VACUUM processes every table and materialized view in the current database that the current user has permission to vacuum. With a list, VACUUM processes only those table(s).

VACUUM ANALYZE performs a VACUUM and then an ANALYZE for each selected table. This is a handy combination form for routine maintenance scripts. See ANALYZE(7) for more details about its processing.

Plain VACUUM (without FULL) simply reclaims space and makes it available for re-use. This form of the command can operate in parallel with normal reading and writing of the table, as an exclusive lock is not obtained. However, extra space is not returned to the operating system (in most cases); its just kept available for re-use within the same table. It also allows us to leverage multiple CPUs in order to process indexes. This feature is known as parallel vacuum. To disable this feature, one can use PARALLEL option and specify parallel workers as zero. VACUUM FULL rewrites the entire contents of the table into a new disk file with no extra space, allowing unused space to be returned to the operating system. This form is much slower and requires an ACCESS EXCLUSIVE lock on each table while it is being processed.

When the option list is surrounded by parentheses, the options can be written in any order. Without parentheses, options must be specified in exactly the order shown above. The parenthesized syntax was added in PostgreSQL 9.0; the unparenthesized syntax is deprecated.

PARAMETERS

FULL

Selects “full” vacuum, which can reclaim more space, but takes much longer and exclusively locks the table. This method also requires extra disk space, since it writes a new copy of the table and doesnt release the old copy until the operation is complete. Usually this should only be used when a significant amount of space needs to be reclaimed from within the table.

FREEZE

Selects aggressive “freezing” of tuples. Specifying FREEZE is equivalent to performing VACUUM with the vacuum_freeze_min_age and vacuum_freeze_table_age parameters set to zero. Aggressive freezing is always performed when the table is rewritten, so this option is redundant when FULL is specified.

VERBOSE

Prints a detailed vacuum activity report for each table.

ANALYZE

Updates statistics used by the planner to determine the most efficient way to execute a query.

DISABLE_PAGE_SKIPPING

Normally, VACUUM will skip pages based on the visibility map. Pages where all tuples are known to be frozen can always be skipped, and those where all tuples are known to be visible to all transactions may be skipped except when performing an aggressive vacuum. Furthermore, except when performing an aggressive vacuum, some pages may be skipped in order to avoid waiting for other sessions to finish using them. This option disables all page-skipping behavior, and is intended to be used only when the contents of the visibility map are suspect, which should happen only if there is a hardware or software issue causing database corruption.

SKIP_LOCKED

Specifies that VACUUM should not wait for any conflicting locks to be released when beginning work on a relation: if a relation cannot be locked immediately without waiting, the relation is skipped. Note that even with this option, VACUUM may still block when opening the relations indexes. Additionally, VACUUM ANALYZE may still block when acquiring sample rows from partitions, table inheritance children, and some types of foreign tables. Also, while VACUUM ordinarily processes all partitions of specified partitioned tables, this option will cause VACUUM to skip all partitions if there is a conflicting lock on the partitioned table.

INDEX_CLEANUP

Normally, VACUUM will skip index vacuuming when there are very few dead tuples in the table. The cost of processing all of the tables indexes is expected to greatly exceed the benefit of removing dead index tuples when this happens. This option can be used to force VACUUM to process indexes when there are more than zero dead tuples. The default is AUTO, which allows VACUUM to skip index vacuuming when appropriate. If INDEX_CLEANUP is set to ON, VACUUM will conservatively remove all dead tuples from indexes. This may be useful for backwards compatibility with earlier releases of PostgreSQL where this was the standard behavior.

INDEX_CLEANUP can also be set to OFF to force VACUUM to always skip index vacuuming, even when there are many dead tuples in the table. This may be useful when it is necessary to make VACUUM run as quickly as possible to avoid imminent transaction ID wraparound (see Section 25.1.5). However, the wraparound failsafe mechanism controlled by vacuum_failsafe_age will generally trigger automatically to avoid transaction ID wraparound failure, and should be preferred. If index cleanup is not performed regularly, performance may suffer, because as the table is modified indexes will accumulate dead tuples and the table itself will accumulate dead line pointers that cannot be removed until index cleanup is completed.

This option has no effect for tables that have no index and is ignored if the FULL option is used. It also has no effect on the transaction ID wraparound failsafe mechanism. When triggered it will skip index vacuuming, even when INDEX_CLEANUP is set to ON.

PROCESS_MAIN

Specifies that VACUUM should attempt to process the main relation. This is usually the desired behavior and is the default. Setting this option to false may be useful when it is only necessary to vacuum a relations corresponding TOAST table.

PROCESS_TOAST

Specifies that VACUUM should attempt to process the corresponding TOAST table for each relation, if one exists. This is usually the desired behavior and is the default. Setting this option to false may be useful when it is only necessary to vacuum the main relation. This option is required when the FULL option is used.

TRUNCATE

Specifies that VACUUM should attempt to truncate off any empty pages at the end of the table and allow the disk space for the truncated pages to be returned to the operating system. This is normally the desired behavior and is the default unless the vacuum_truncate option has been set to false for the table to be vacuumed. Setting this option to false may be useful to avoid ACCESS EXCLUSIVE lock on the table that the truncation requires. This option is ignored if the FULL option is used.

PARALLEL

Perform index vacuum and index cleanup phases of VACUUM in parallel using integer background workers (for the details of each vacuum phase, please refer to Table 28.45). The number of workers used to perform the operation is equal to the number of indexes on the relation that support parallel vacuum which is limited by the number of workers specified with PARALLEL option if any which is further limited by max_parallel_maintenance_workers. An index can participate in parallel vacuum if and only if the size of the index is more than min_parallel_index_scan_size. Please note that it is not guaranteed that the number of parallel workers specified in integer will be used during execution. It is possible for a vacuum to run with fewer workers than specified, or even with no workers at all. Only one worker can be used per index. So parallel workers are launched only when there are at least 2 indexes in the table. Workers for vacuum are launched before the start of each phase and exit at the end of the phase. These behaviors might change in a future release. This option cant be used with the FULL option.

SKIP_DATABASE_STATS

Specifies that VACUUM should skip updating the database-wide statistics about oldest unfrozen XIDs. Normally VACUUM will update these statistics once at the end of the command. However, this can take awhile in a database with a very large number of tables, and it will accomplish nothing unless the table that had contained the oldest unfrozen XID was among those vacuumed. Moreover, if multiple VACUUM commands are issued in parallel, only one of them can update the database-wide statistics at a time. Therefore, if an application intends to issue a series of many VACUUM commands, it can be helpful to set this option in all but the last such command; or set it in all the commands and separately issue VACUUM (ONLY_DATABASE_STATS) afterwards.

ONLY_DATABASE_STATS

Specifies that VACUUM should do nothing except update the database-wide statistics about oldest unfrozen XIDs. When this option is specified, the table_and_columns list must be empty, and no other option may be enabled except VERBOSE.

BUFFER_USAGE_LIMIT

Specifies the Buffer Access Strategy ring buffer size for VACUUM. This size is used to calculate the number of shared buffers which will be reused as part of this strategy. 0 disables use of a Buffer Access Strategy. If ANALYZE is also specified, the BUFFER_USAGE_LIMIT value is used for both the vacuum and analyze stages. This option cant be used with the FULL option except if ANALYZE is also specified. When this option is not specified, VACUUM uses the value from vacuum_buffer_usage_limit. Higher settings can allow VACUUM to run more quickly, but having too large a setting may cause too many other useful pages to be evicted from shared buffers. The minimum value is 128 kB and the maximum value is 16 GB.

boolean

Specifies whether the selected option should be turned on or off. You can write TRUE, ON, or 1 to enable the option, and FALSE, OFF, or 0 to disable it. The boolean value can also be omitted, in which case TRUE is assumed.

integer

Specifies a non-negative integer value passed to the selected option.

size

Specifies an amount of memory in kilobytes. Sizes may also be specified as a string containing the numerical size followed by any one of the following memory units: B (bytes), kB (kilobytes), MB (megabytes), GB (gigabytes), or TB (terabytes).

table_name

The name (optionally schema-qualified) of a specific table or materialized view to vacuum. If the specified table is a partitioned table, all of its leaf partitions are vacuumed.

column_name

The name of a specific column to analyze. Defaults to all columns. If a column list is specified, ANALYZE must also be specified.

OUTPUTS

When VERBOSE is specified, VACUUM emits progress messages to indicate which table is currently being processed. Various statistics about the tables are printed as well.

NOTES

To vacuum a table, one must ordinarily be the tables owner or a superuser. However, database owners are allowed to vacuum all tables in their databases, except shared catalogs. (The restriction for shared catalogs means that a true database-wide VACUUM can only be performed by a superuser.) VACUUM will skip over any tables that the calling user does not have permission to vacuum.

VACUUM cannot be executed inside a transaction block.

For tables with GIN indexes, VACUUM (in any form) also completes any pending index insertions, by moving pending index entries to the appropriate places in the main GIN index structure. See Section 70.4.1 for details.

We recommend that all databases be vacuumed regularly in order to remove dead rows. PostgreSQL includes an “autovacuum” facility which can automate routine vacuum maintenance. For more information about automatic and manual vacuuming, see Section 25.1.

The FULL option is not recommended for routine use, but might be useful in special cases. An example is when you have deleted or updated most of the rows in a table and would like the table to physically shrink to occupy less disk space and allow faster table scans. VACUUM FULL will usually shrink the table more than a plain VACUUM would.

The PARALLEL option is used only for vacuum purposes. If this option is specified with the ANALYZE option, it does not affect ANALYZE.

VACUUM causes a substantial increase in I/O traffic, which might cause poor performance for other active sessions. Therefore, it is sometimes advisable to use the cost-based vacuum delay feature. For parallel vacuum, each worker sleeps in proportion to the work done by that worker. See Section 20.4.4 for details.

Each backend running VACUUM without the FULL option will report its progress in the pg_stat_progress_vacuum view. Backends running VACUUM FULL will instead report their progress in the pg_stat_progress_cluster view. See Section 28.4.5 and Section 28.4.2 for details.

EXAMPLES

To clean a single table onek, analyze it for the optimizer and print a detailed vacuum activity report:

VACUUM (VERBOSE, ANALYZE) onek;

COMPATIBILITY

There is no VACUUM statement in the SQL standard.

SEE ALSO

vacuumdb(1), Section 20.4.4, Section 25.1.6, Section 28.4.5, Section 28.4.2

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

169 - Linux cli command DROP_FOREIGN_TABLE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_FOREIGN_TABLE and provides detailed information about the command DROP_FOREIGN_TABLE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_FOREIGN_TABLE.

NAME 🖥️ DROP_FOREIGN_TABLE 🖥️

remove a foreign table

SYNOPSIS

DROP FOREIGN TABLE [ IF EXISTS ] name [, ...] [ CASCADE | RESTRICT ]

DESCRIPTION

DROP FOREIGN TABLE removes a foreign table. Only the owner of a foreign table can remove it.

PARAMETERS

IF EXISTS

Do not throw an error if the foreign table does not exist. A notice is issued in this case.

name

The name (optionally schema-qualified) of the foreign table to drop.

CASCADE

Automatically drop objects that depend on the foreign table (such as views), and in turn all objects that depend on those objects (see Section 5.14).

RESTRICT

Refuse to drop the foreign table if any objects depend on it. This is the default.

EXAMPLES

To destroy two foreign tables, films and distributors:

DROP FOREIGN TABLE films, distributors;

COMPATIBILITY

This command conforms to ISO/IEC 9075-9 (SQL/MED), except that the standard only allows one foreign table to be dropped per command, and apart from the IF EXISTS option, which is a PostgreSQL extension.

SEE ALSO

ALTER FOREIGN TABLE (ALTER_FOREIGN_TABLE(7)), CREATE FOREIGN TABLE (CREATE_FOREIGN_TABLE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

170 - Linux cli command time_namespaces

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command time_namespaces and provides detailed information about the command time_namespaces, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the time_namespaces.

NAME 🖥️ time_namespaces 🖥️

overview of Linux time namespaces

DESCRIPTION

Time namespaces virtualize the values of two system clocks:

  • CLOCK_MONOTONIC (and likewise CLOCK_MONOTONIC_COARSE and CLOCK_MONOTONIC_RAW), a nonsettable clock that represents monotonic time since—as described by POSIX—“some unspecified point in the past”.

  • CLOCK_BOOTTIME (and likewise CLOCK_BOOTTIME_ALARM), a nonsettable clock that is identical to CLOCK_MONOTONIC, except that it also includes any time that the system is suspended.

Thus, the processes in a time namespace share per-namespace values for these clocks. This affects various APIs that measure against these clocks, including: clock_gettime(2), clock_nanosleep(2), nanosleep(2), timer_settime(2), timerfd_settime(2), and /proc/uptime.

Currently, the only way to create a time namespace is by calling unshare(2) with the CLONE_NEWTIME flag. This call creates a new time namespace but does not place the calling process in the new namespace. Instead, the calling process’s subsequently created children are placed in the new namespace. This allows clock offsets (see below) for the new namespace to be set before the first process is placed in the namespace. The /proc/pid/ns/time_for_children symbolic link shows the time namespace in which the children of a process will be created. (A process can use a file descriptor opened on this symbolic link in a call to setns(2) in order to move into the namespace.)

/proc/pid/timens_offsets

Associated with each time namespace are offsets, expressed with respect to the initial time namespace, that define the values of the monotonic and boot-time clocks in that namespace. These offsets are exposed via the file /proc/pid/timens_offsets. Within this file, the offsets are expressed as lines consisting of three space-delimited fields:

<clock-id> <offset-secs> <offset-nanosecs>

The clock-id is a string that identifies the clock whose offsets are being shown. This field is either monotonic, for CLOCK_MONOTONIC, or boottime, for CLOCK_BOOTTIME. The remaining fields express the offset (seconds plus nanoseconds) for the clock in this time namespace. These offsets are expressed relative to the clock values in the initial time namespace. The offset-secs value can be negative, subject to restrictions noted below; offset-nanosecs is an unsigned value.

In the initial time namespace, the contents of the timens_offsets file are as follows:

$ cat /proc/self/timens_offsets
monotonic           0         0
boottime            0         0

In a new time namespace that has had no member processes, the clock offsets can be modified by writing newline-terminated records of the same form to the timens_offsets file. The file can be written to multiple times, but after the first process has been created in or has entered the namespace, write(2)s on this file fail with the error EACCES. In order to write to the timens_offsets file, a process must have the CAP_SYS_TIME capability in the user namespace that owns the time namespace.

Writes to the timens_offsets file can fail with the following errors:

EINVAL
An offset-nanosecs value is greater than 999,999,999.

EINVAL
A clock-id value is not valid.

EPERM
The caller does not have the CAP_SYS_TIME capability.

ERANGE
An offset-secs value is out of range. In particular;

  • offset-secs can’t be set to a value which would make the current time on the corresponding clock inside the namespace a negative value; and

  • offset-secs can’t be set to a value such that the time on the corresponding clock inside the namespace would exceed half of the value of the kernel constant KTIME_SEC_MAX (this limits the clock value to a maximum of approximately 146 years).

In a new time namespace created by unshare(2), the contents of the timens_offsets file are inherited from the time namespace of the creating process.

NOTES

Use of time namespaces requires a kernel that is configured with the CONFIG_TIME_NS option.

Note that time namespaces do not virtualize the CLOCK_REALTIME clock. Virtualization of this clock was avoided for reasons of complexity and overhead within the kernel.

For compatibility with the initial implementation, when writing a clock-id to the /proc/pid/timens_offsets file, the numerical values of the IDs can be written instead of the symbolic names show above; i.e., 1 instead of monotonic, and 7 instead of boottime. For readability, the use of the symbolic names over the numbers is preferred.

The motivation for adding time namespaces was to allow the monotonic and boot-time clocks to maintain consistent values during container migration and checkpoint/restore.

EXAMPLES

The following shell session demonstrates the operation of time namespaces. We begin by displaying the inode number of the time namespace of a shell in the initial time namespace:

$ readlink /proc/$$/ns/time
time:[4026531834]

Continuing in the initial time namespace, we display the system uptime using uptime(1) and use the clock_times example program shown in clock_getres(2) to display the values of various clocks:

$ uptime --pretty
up 21 hours, 17 minutes
$ ./clock_times
CLOCK_REALTIME : 1585989401.971 (18356 days +  8h 36m 41s)
CLOCK_TAI      : 1585989438.972 (18356 days +  8h 37m 18s)
CLOCK_MONOTONIC:      56338.247 (15h 38m 58s)
CLOCK_BOOTTIME :      76633.544 (21h 17m 13s)

We then use unshare(1) to create a time namespace and execute a bash(1) shell. From the new shell, we use the built-in echo command to write records to the timens_offsets file adjusting the offset for the CLOCK_MONOTONIC clock forward 2 days and the offset for the CLOCK_BOOTTIME clock forward 7 days:

$ PS1="ns2# " sudo unshare -T -- bash --norc
ns2# echo "monotonic $((2*24*60*60)) 0" > /proc/$$/timens_offsets
ns2# echo "boottime  $((7*24*60*60)) 0" > /proc/$$/timens_offsets

Above, we started the bash(1) shell with the –norc option so that no start-up scripts were executed. This ensures that no child processes are created from the shell before we have a chance to update the timens_offsets file.

We then use cat(1) to display the contents of the timens_offsets file. The execution of cat(1) creates the first process in the new time namespace, after which further attempts to update the timens_offsets file produce an error.

ns2# cat /proc/$$/timens_offsets
monotonic      172800         0
boottime       604800         0
ns2# echo "boottime $((9*24*60*60)) 0" > /proc/$$/timens_offsets
bash: echo: write error: Permission denied

Continuing in the new namespace, we execute uptime(1) and the clock_times example program:

ns2# uptime --pretty
up 1 week, 21 hours, 18 minutes
ns2# ./clock_times
CLOCK_REALTIME : 1585989457.056 (18356 days +  8h 37m 37s)
CLOCK_TAI      : 1585989494.057 (18356 days +  8h 38m 14s)
CLOCK_MONOTONIC:     229193.332 (2 days + 15h 39m 53s)
CLOCK_BOOTTIME :     681488.629 (7 days + 21h 18m  8s)

From the above output, we can see that the monotonic and boot-time clocks have different values in the new time namespace.

Examining the /proc/pid/ns/time and /proc/pid/ns/time_for_children symbolic links, we see that the shell is a member of the initial time namespace, but its children are created in the new namespace.

ns2# readlink /proc/$$/ns/time
time:[4026531834]
ns2# readlink /proc/$$/ns/time_for_children
time:[4026532900]
ns2# readlink /proc/self/ns/time   # Creates a child process
time:[4026532900]

Returning to the shell in the initial time namespace, we see that the monotonic and boot-time clocks are unaffected by the timens_offsets changes that were made in the other time namespace:

$ uptime --pretty
up 21 hours, 19 minutes
$ ./clock_times
CLOCK_REALTIME : 1585989401.971 (18356 days +  8h 38m 51s)
CLOCK_TAI      : 1585989438.972 (18356 days +  8h 39m 28s)
CLOCK_MONOTONIC:      56338.247 (15h 41m  8s)
CLOCK_BOOTTIME :      76633.544 (21h 19m 23s)

SEE ALSO

nsenter(1), unshare(1), clock_settime(2), setns(2), unshare(2), namespaces(7), time(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

171 - Linux cli command latin10

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command latin10 and provides detailed information about the command latin10, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the latin10.

NAME 🖥️ latin10 🖥️

16 - ISO/IEC 8859-16 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-16 encodes the Latin characters used in Southeast European languages.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-16 characters

The following table displays the characters in ISO/IEC 8859-16 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-16 is also known as Latin-10.

SEE ALSO

ascii(7), charsets(7), iso_8859-3(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

172 - Linux cli command EVP_KDF-X942-ASN1ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KDF-X942-ASN1ssl and provides detailed information about the command EVP_KDF-X942-ASN1ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KDF-X942-ASN1ssl.

NAME 🖥️ EVP_KDF-X942-ASN1ssl 🖥️

X942-ASN1 - The X9.42-2003 asn1 EVP_KDF implementation

DESCRIPTION

The EVP_KDF-X942-ASN1 algorithm implements the key derivation function X942KDF-ASN1. It is used by DH KeyAgreement, to derive a key using input such as a shared secret key and other info. The other info is DER encoded data that contains a 32 bit counter as well as optional fields for “partyu-info”, “partyv-info”, “supp-pubinfo” and “supp-privinfo”. This kdf is used by Cryptographic Message Syntax (CMS).

Identity

“X942KDF-ASN1” or “X942KDF” is the name for this implementation; it can be used with the EVP_KDF_fetch() function.

Supported parameters

The supported parameters are:

“properties” (OSSL_KDF_PARAM_PROPERTIES) <UTF8 string>

“digest” (OSSL_KDF_PARAM_DIGEST) <UTF8 string>

These parameters work as described in “PARAMETERS” in EVP_KDF (3).

“secret” (OSSL_KDF_PARAM_SECRET) <octet string>
The shared secret used for key derivation. This parameter sets the secret.

“acvp-info” (OSSL_KDF_PARAM_X942_ACVPINFO) <octet string>
This value should not be used in production and should only be used for ACVP testing. It is an optional octet string containing a combined DER encoded blob of any of the optional fields related to “partyu-info”, “partyv-info”, “supp-pubinfo” and “supp-privinfo”. If it is specified then none of these other fields should be used.

“partyu-info” (OSSL_KDF_PARAM_X942_PARTYUINFO) <octet string>
An optional octet string containing public info contributed by the initiator.

“ukm” (OSSL_KDF_PARAM_UKM) <octet string>
An alias for “partyu-info”. In CMS this is the user keying material.

“partyv-info” (OSSL_KDF_PARAM_X942_PARTYVINFO) <octet string>
An optional octet string containing public info contributed by the responder.

“supp-pubinfo” (OSSL_KDF_PARAM_X942_SUPP_PUBINFO) <octet string>
An optional octet string containing some additional, mutually-known public information. Setting this value also sets “use-keybits” to 0.

“use-keybits” (OSSL_KDF_PARAM_X942_USE_KEYBITS) <integer>
The default value of 1 will use the KEK key length (in bits) as the “supp-pubinfo”. A value of 0 disables setting the “supp-pubinfo”.

“supp-privinfo” (OSSL_KDF_PARAM_X942_SUPP_PRIVINFO) <octet string>
An optional octet string containing some additional, mutually-known private information.

“cekalg” (OSSL_KDF_PARAM_CEK_ALG) <UTF8 string>
This parameter sets the CEK wrapping algorithm name. Valid values are “AES-128-WRAP”, “AES-192-WRAP”, “AES-256-WRAP” and “DES3-WRAP”.

NOTES

A context for X942KDF can be obtained by calling:

EVP_KDF *kdf = EVP_KDF_fetch(NULL, “X942KDF”, NULL); EVP_KDF_CTX *kctx = EVP_KDF_CTX_new(kdf);

The output length of an X942KDF is specified via the keylen parameter to the EVP_KDF_derive (3) function.

EXAMPLES

This example derives 24 bytes, with the secret key “secret” and random user keying material:

EVP_KDF_CTX *kctx; EVP_KDF_CTX *kctx; unsigned char out[192/8]; unsignred char ukm[64]; OSSL_PARAM params[5], *p = params; if (RAND_bytes(ukm, sizeof(ukm)) <= 0) error(“RAND_bytes”); kdf = EVP_KDF_fetch(NULL, “X942KDF”, NULL); if (kctx == NULL) error(“EVP_KDF_fetch”); kctx = EVP_KDF_CTX_new(kdf); EVP_KDF_free(kdf); if (kctx == NULL) error(“EVP_KDF_CTX_new”); *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_DIGEST, “SHA256”, 0); *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_SECRET, “secret”, (size_t)6); *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_UKM, ukm, sizeof(ukm)); *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_CEK_ALG, “AES-256-WRAP, 0); *p = OSSL_PARAM_construct_end(); if (EVP_KDF_derive(kctx, out, sizeof(out), params) <= 0) error(“EVP_KDF_derive”); EVP_KDF_CTX_free(kctx);

CONFORMING TO

ANS1 X9.42-2003 RFC 2631

SEE ALSO

EVP_KDF (3), EVP_KDF_CTX_new (3), EVP_KDF_CTX_free (3), EVP_KDF_CTX_set_params (3), EVP_KDF_CTX_get_kdf_size (3), EVP_KDF_derive (3), “PARAMETERS” in EVP_KDF (3)

HISTORY

This functionality was added in OpenSSL 3.0.

COPYRIGHT

Copyright 2019-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

173 - Linux cli command EVP_KEM-X448ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KEM-X448ssl and provides detailed information about the command EVP_KEM-X448ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KEM-X448ssl.

NAME 🖥️ EVP_KEM-X448ssl 🖥️

X25519, EVP_KEM-X448 - EVP_KEM X25519 and EVP_KEM X448 keytype and algorithm support

DESCRIPTION

The X25519 and <X448> keytype and its parameters are described in EVP_PKEY-X25519 (7). See EVP_PKEY_encapsulate (3) and EVP_PKEY_decapsulate (3) for more info.

X25519 and X448 KEM parameters

“operation” (OSSL_KEM_PARAM_OPERATION)<UTF8 string>
The OpenSSL X25519 and X448 Key Encapsulation Mechanisms only support the following operation:

“DHKEM” (OSSL_KEM_PARAM_OPERATION_DHKEM)
The encapsulate function generates an ephemeral keypair. It produces keymaterial by doing an X25519 or X448 key exchange using the ephemeral private key and a supplied recipient public key. A HKDF operation using the keymaterial and a kem context then produces a shared secret. The shared secret and the ephemeral public key are returned. The decapsulate function uses the recipient private key and the ephemeral public key to produce the same keymaterial, which can then be used to produce the same shared secret. See <https://www.rfc-editor.org/rfc/rfc9180.html#name-dh-based-kem-dhkem>

This can be set using either EVP_PKEY_CTX_set_kem_op() or EVP_PKEY_CTX_set_params().

“ikme” (OSSL_KEM_PARAM_IKME) <octet string>
Used to specify the key material used for generation of the ephemeral key. This value should not be reused for other purposes. It should have a length of at least 32 for X25519, and 56 for X448. If this value is not set, then a random ikm is used.

CONFORMING TO

RFC9180

SEE ALSO

EVP_PKEY_CTX_set_kem_op (3), EVP_PKEY_encapsulate (3), EVP_PKEY_decapsulate (3) EVP_KEYMGMT (3), EVP_PKEY (3), provider-keymgmt (7)

HISTORY

This functionality was added in OpenSSL 3.2.

COPYRIGHT

Copyright 2022 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

174 - Linux cli command iso_8859-14

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso_8859-14 and provides detailed information about the command iso_8859-14, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso_8859-14.

NAME 🖥️ iso_8859-14 🖥️

14 - ISO/IEC 8859-14 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-14 encodes the characters used in Celtic languages.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-14 characters

The following table displays the characters in ISO/IEC 8859-14 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-14 is also known as Latin-8.

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

175 - Linux cli command EVP_MD-SHA3ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_MD-SHA3ssl and provides detailed information about the command EVP_MD-SHA3ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_MD-SHA3ssl.

NAME 🖥️ EVP_MD-SHA3ssl 🖥️

SHA3 - The SHA3 EVP_MD implementations

DESCRIPTION

Support for computing SHA3 digests through the EVP_MD API.

Identities

This implementation is available with the FIPS provider as well as the default provider, and includes the following varieties:

“SHA3-224”

“SHA3-256”

“SHA3-384”

“SHA3-512”

Gettable Parameters

This implementation supports the common gettable parameters described in EVP_MD-common (7).

SEE ALSO

provider-digest (7), OSSL_PROVIDER-FIPS (7), OSSL_PROVIDER-default (7)

COPYRIGHT

Copyright 2020 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

176 - Linux cli command DROP_EXTENSION

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_EXTENSION and provides detailed information about the command DROP_EXTENSION, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_EXTENSION.

NAME 🖥️ DROP_EXTENSION 🖥️

remove an extension

SYNOPSIS

DROP EXTENSION [ IF EXISTS ] name [, ...] [ CASCADE | RESTRICT ]

DESCRIPTION

DROP EXTENSION removes extensions from the database. Dropping an extension causes its member objects, and other explicitly dependent routines (see ALTER ROUTINE (ALTER_ROUTINE(7)), the DEPENDS ON EXTENSION extension_name action), to be dropped as well.

You must own the extension to use DROP EXTENSION.

PARAMETERS

IF EXISTS

Do not throw an error if the extension does not exist. A notice is issued in this case.

name

The name of an installed extension.

CASCADE

Automatically drop objects that depend on the extension, and in turn all objects that depend on those objects (see Section 5.14).

RESTRICT

This option prevents the specified extensions from being dropped if other objects, besides these extensions, their members, and their explicitly dependent routines, depend on them. This is the default.

EXAMPLES

To remove the extension hstore from the current database:

DROP EXTENSION hstore;

This command will fail if any of hstores objects are in use in the database, for example if any tables have columns of the hstore type. Add the CASCADE option to forcibly remove those dependent objects as well.

COMPATIBILITY

DROP EXTENSION is a PostgreSQL extension.

SEE ALSO

CREATE EXTENSION (CREATE_EXTENSION(7)), ALTER EXTENSION (ALTER_EXTENSION(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

177 - Linux cli command gitfaq

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command gitfaq and provides detailed information about the command gitfaq, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the gitfaq.

NAME 🖥️ gitfaq 🖥️

Frequently asked questions about using Git

SYNOPSIS

gitfaq

DESCRIPTION

The examples in this FAQ assume a standard POSIX shell, like bash or dash, and a user, A U Thor, who has the account author on the hosting provider git.example.org.

CONFIGURATION

What should I put in user.name?

You should put your personal name, generally a form using a given name and family name. For example, the current maintainer of Git uses “Junio C Hamano”. This will be the name portion that is stored in every commit you make.

This configuration doesn’t have any effect on authenticating to remote services; for that, see credential.username in git-config(1).

What does http.postBuffer really do?

This option changes the size of the buffer that Git uses when pushing data to a remote over HTTP or HTTPS. If the data is larger than this size, libcurl, which handles the HTTP support for Git, will use chunked transfer encoding since it isn’t known ahead of time what the size of the pushed data will be.

Leaving this value at the default size is fine unless you know that either the remote server or a proxy in the middle doesn’t support HTTP/1.1 (which introduced the chunked transfer encoding) or is known to be broken with chunked data. This is often (erroneously) suggested as a solution for generic push problems, but since almost every server and proxy supports at least HTTP/1.1, raising this value usually doesn’t solve most push problems. A server or proxy that didn’t correctly support HTTP/1.1 and chunked transfer encoding wouldn’t be that useful on the Internet today, since it would break lots of traffic.

Note that increasing this value will increase the memory used on every relevant push that Git does over HTTP or HTTPS, since the entire buffer is allocated regardless of whether or not it is all used. Thus, it’s best to leave it at the default unless you are sure you need a different value.

How do I configure a different editor?

If you haven’t specified an editor specifically for Git, it will by default use the editor you’ve configured using the VISUAL or EDITOR environment variables, or if neither is specified, the system default (which is usually vi). Since some people find vi difficult to use or prefer a different editor, it may be desirable to change the editor used.

If you want to configure a general editor for most programs which need one, you can edit your shell configuration (e.g., ~/.bashrc or ~/.zshenv) to contain a line setting the EDITOR or VISUAL environment variable to an appropriate value. For example, if you prefer the editor nano, then you could write the following:

export VISUAL=nano

If you want to configure an editor specifically for Git, you can either set the core.editor configuration value or the GIT_EDITOR environment variable. You can see git-var(1) for details on the order in which these options are consulted.

Note that in all cases, the editor value will be passed to the shell, so any arguments containing spaces should be appropriately quoted. Additionally, if your editor normally detaches from the terminal when invoked, you should specify it with an argument that makes it not do that, or else Git will not see any changes. An example of a configuration addressing both of these issues on Windows would be the configuration “C:\Program Files\Vim\gvim.exe” –nofork, which quotes the filename with spaces and specifies the –nofork option to avoid backgrounding the process.

CREDENTIALS

How do I specify my credentials when pushing over HTTP?

The easiest way to do this is to use a credential helper via the credential.helper configuration. Most systems provide a standard choice to integrate with the system credential manager. For example, Git for Windows provides the wincred credential manager, macOS has the osxkeychain credential manager, and Unix systems with a standard desktop environment can use the libsecret credential manager. All of these store credentials in an encrypted store to keep your passwords or tokens secure.

In addition, you can use the store credential manager which stores in a file in your home directory, or the cache credential manager, which does not permanently store your credentials, but does prevent you from being prompted for them for a certain period of time.

You can also just enter your password when prompted. While it is possible to place the password (which must be percent-encoded) in the URL, this is not particularly secure and can lead to accidental exposure of credentials, so it is not recommended.

How do I read a password or token from an environment variable?

The credential.helper configuration option can also take an arbitrary shell command that produces the credential protocol on standard output. This is useful when passing credentials into a container, for example.

Such a shell command can be specified by starting the option value with an exclamation point. If your password or token were stored in the GIT_TOKEN, you could run the following command to set your credential helper:

$ git config credential.helper
!f() { echo username=author; echo “password=$GIT_TOKEN”; };f

How do I change the password or token I’ve saved in my credential manager?

Usually, if the password or token is invalid, Git will erase it and prompt for a new one. However, there are times when this doesn’t always happen. To change the password or token, you can erase the existing credentials and then Git will prompt for new ones. To erase credentials, use a syntax like the following (substituting your username and the hostname):

$ echo url=https://[email protected] | git credential reject

How do I use multiple accounts with the same hosting provider using HTTP?

Usually the easiest way to distinguish between these accounts is to use the username in the URL. For example, if you have the accounts author and committer on git.example.org, you can use the URLs https://[email protected]/org1/project1.git and https://[email protected]/org2/project2.git. This way, when you use a credential helper, it will automatically try to look up the correct credentials for your account. If you already have a remote set up, you can change the URL with something like git remote set-url origin https://[email protected]/org1/project1.git (see git-remote(1) for details).

How do I use multiple accounts with the same hosting provider using SSH?

With most hosting providers that support SSH, a single key pair uniquely identifies a user. Therefore, to use multiple accounts, it’s necessary to create a key pair for each account. If you’re using a reasonably modern OpenSSH version, you can create a new key pair with something like ssh-keygen -t ed25519 -f ~/.ssh/id_committer. You can then register the public key (in this case, ~/.ssh/id_committer.pub; note the .pub) with the hosting provider.

Most hosting providers use a single SSH account for pushing; that is, all users push to the git account (e.g., [email protected]). If that’s the case for your provider, you can set up multiple aliases in SSH to make it clear which key pair to use. For example, you could write something like the following in ~/.ssh/config, substituting the proper private key file:

This is the account for author on git.example.org.

Host example_author
        HostName git.example.org
        User git
        # This is the key pair registered for author with git.example.org.
        IdentityFile ~/.ssh/id_author
        IdentitiesOnly yes
# This is the account for committer on git.example.org.
Host example_committer
        HostName git.example.org
        User git
        # This is the key pair registered for committer with git.example.org.
        IdentityFile ~/.ssh/id_committer
        IdentitiesOnly yes

Then, you can adjust your push URL to use git@example_author or git@example_committer instead of [email protected] (e.g., git remote set-url git@example_author:org1/project1.git).

COMMON ISSUES

I’ve made a mistake in the last commit. How do I change it?

You can make the appropriate change to your working tree, run git add <file> or git rm <file>, as appropriate, to stage it, and then git commit –amend. Your change will be included in the commit, and you’ll be prompted to edit the commit message again; if you wish to use the original message verbatim, you can use the –no-edit option to git commit in addition, or just save and quit when your editor opens.

I’ve made a change with a bug and it’s been included in the main branch. How should I undo it?

The usual way to deal with this is to use git revert. This preserves the history that the original change was made and was a valuable contribution, but also introduces a new commit that undoes those changes because the original had a problem. The commit message of the revert indicates the commit which was reverted and is usually edited to include an explanation as to why the revert was made.

How do I ignore changes to a tracked file?

Git doesn’t provide a way to do this. The reason is that if Git needs to overwrite this file, such as during a checkout, it doesn’t know whether the changes to the file are precious and should be kept, or whether they are irrelevant and can safely be destroyed. Therefore, it has to take the safe route and always preserve them.

It’s tempting to try to use certain features of git update-index, namely the assume-unchanged and skip-worktree bits, but these don’t work properly for this purpose and shouldn’t be used this way.

If your goal is to modify a configuration file, it can often be helpful to have a file checked into the repository which is a template or set of defaults which can then be copied alongside and modified as appropriate. This second, modified file is usually ignored to prevent accidentally committing it.

I asked Git to ignore various files, yet they are still tracked

A gitignore file ensures that certain file(s) which are not tracked by Git remain untracked. However, sometimes particular file(s) may have been tracked before adding them into the .gitignore, hence they still remain tracked. To untrack and ignore files/patterns, use git rm –cached <file/pattern> and add a pattern to .gitignore that matches the <file>. See gitignore(5) for details.

How do I know if I want to do a fetch or a pull?

A fetch stores a copy of the latest changes from the remote repository, without modifying the working tree or current branch. You can then at your leisure inspect, merge, rebase on top of, or ignore the upstream changes. A pull consists of a fetch followed immediately by either a merge or rebase. See git-pull(1).

MERGING AND REBASING

What kinds of problems can occur when merging long-lived branches with squash merges?

In general, there are a variety of problems that can occur when using squash merges to merge two branches multiple times. These can include seeing extra commits in git log output, with a GUI, or when using the … notation to express a range, as well as the possibility of needing to re-resolve conflicts again and again.

When Git does a normal merge between two branches, it considers exactly three points: the two branches and a third commit, called the merge base, which is usually the common ancestor of the commits. The result of the merge is the sum of the changes between the merge base and each head. When you merge two branches with a regular merge commit, this results in a new commit which will end up as a merge base when they’re merged again, because there is now a new common ancestor. Git doesn’t have to consider changes that occurred before the merge base, so you don’t have to re-resolve any conflicts you resolved before.

When you perform a squash merge, a merge commit isn’t created; instead, the changes from one side are applied as a regular commit to the other side. This means that the merge base for these branches won’t have changed, and so when Git goes to perform its next merge, it considers all of the changes that it considered the last time plus the new changes. That means any conflicts may need to be re-resolved. Similarly, anything using the … notation in git diff, git log, or a GUI will result in showing all of the changes since the original merge base.

As a consequence, if you want to merge two long-lived branches repeatedly, it’s best to always use a regular merge commit.

If I make a change on two branches but revert it on one, why does the merge of those branches include the change?

By default, when Git does a merge, it uses a strategy called the ort strategy, which does a fancy three-way merge. In such a case, when Git performs the merge, it considers exactly three points: the two heads and a third point, called the merge base, which is usually the common ancestor of those commits. Git does not consider the history or the individual commits that have happened on those branches at all.

As a result, if both sides have a change and one side has reverted that change, the result is to include the change. This is because the code has changed on one side and there is no net change on the other, and in this scenario, Git adopts the change.

If this is a problem for you, you can do a rebase instead, rebasing the branch with the revert onto the other branch. A rebase in this scenario will revert the change, because a rebase applies each individual commit, including the revert. Note that rebases rewrite history, so you should avoid rebasing published branches unless you’re sure you’re comfortable with that. See the NOTES section in git-rebase(1) for more details.

HOOKS

How do I use hooks to prevent users from making certain changes?

The only safe place to make these changes is on the remote repository (i.e., the Git server), usually in the pre-receive hook or in a continuous integration (CI) system. These are the locations in which policy can be enforced effectively.

It’s common to try to use pre-commit hooks (or, for commit messages, commit-msg hooks) to check these things, which is great if you’re working as a solo developer and want the tooling to help you. However, using hooks on a developer machine is not effective as a policy control because a user can bypass these hooks with –no-verify without being noticed (among various other ways). Git assumes that the user is in control of their local repositories and doesn’t try to prevent this or tattle on the user.

In addition, some advanced users find pre-commit hooks to be an impediment to workflows that use temporary commits to stage work in progress or that create fixup commits, so it’s better to push these kinds of checks to the server anyway.

CROSS-PLATFORM ISSUES

I’m on Windows and my text files are detected as binary.

Git works best when you store text files as UTF-8. Many programs on Windows support UTF-8, but some do not and only use the little-endian UTF-16 format, which Git detects as binary. If you can’t use UTF-8 with your programs, you can specify a working tree encoding that indicates which encoding your files should be checked out with, while still storing these files as UTF-8 in the repository. This allows tools like git-diff(1) to work as expected, while still allowing your tools to work.

To do so, you can specify a gitattributes(5) pattern with the working-tree-encoding attribute. For example, the following pattern sets all C files to use UTF-16LE-BOM, which is a common encoding on Windows:

*.c working-tree-encoding=UTF-16LE-BOM

You will need to run git add –renormalize to have this take effect. Note that if you are making these changes on a project that is used across platforms, you’ll probably want to make it in a per-user configuration file or in the one in $GIT_DIR/info/attributes, since making it in a .gitattributes file in the repository will apply to all users of the repository.

See the following entry for information about normalizing line endings as well, and see gitattributes(5) for more information about attribute files.

I’m on Windows and git diff shows my files as having a ^M at the end.

By default, Git expects files to be stored with Unix line endings. As such, the carriage return (^M) that is part of a Windows line ending is shown because it is considered to be trailing whitespace. Git defaults to showing trailing whitespace only on new lines, not existing ones.

You can store the files in the repository with Unix line endings and convert them automatically to your platform’s line endings. To do that, set the configuration option core.eol to native and see the following entry for information about how to configure files as text or binary.

You can also control this behavior with the core.whitespace setting if you don’t wish to remove the carriage returns from your line endings.

Why do I have a file that’s always modified?

Internally, Git always stores file names as sequences of bytes and doesn’t perform any encoding or case folding. However, Windows and macOS by default both perform case folding on file names. As a result, it’s possible to end up with multiple files or directories whose names differ only in case. Git can handle this just fine, but the file system can store only one of these files, so when Git reads the other file to see its contents, it looks modified.

It’s best to remove one of the files such that you only have one file. You can do this with commands like the following (assuming two files AFile.txt and afile.txt) on an otherwise clean working tree:

$ git rm –cached AFile.txt $ git commit -m Remove files conflicting in case $ git checkout .

This avoids touching the disk, but removes the additional file. Your project may prefer to adopt a naming convention, such as all-lowercase names, to avoid this problem from occurring again; such a convention can be checked using a pre-receive hook or as part of a continuous integration (CI) system.

It is also possible for perpetually modified files to occur on any platform if a smudge or clean filter is in use on your system but a file was previously committed without running the smudge or clean filter. To fix this, run the following on an otherwise clean working tree:

$ git add –renormalize .

What’s the recommended way to store files in Git?

While Git can store and handle any file of any type, there are some settings that work better than others. In general, we recommend that text files be stored in UTF-8 without a byte-order mark (BOM) with LF (Unix-style) endings. We also recommend the use of UTF-8 (again, without BOM) in commit messages. These are the settings that work best across platforms and with tools such as git diff and git merge.

Additionally, if you have a choice between storage formats that are text based or non-text based, we recommend storing files in the text format and, if necessary, transforming them into the other format. For example, a text-based SQL dump with one record per line will work much better for diffing and merging than an actual database file. Similarly, text-based formats such as Markdown and AsciiDoc will work better than binary formats such as Microsoft Word and PDF.

Similarly, storing binary dependencies (e.g., shared libraries or JAR files) or build products in the repository is generally not recommended. Dependencies and build products are best stored on an artifact or package server with only references, URLs, and hashes stored in the repository.

We also recommend setting a gitattributes(5) file to explicitly mark which files are text and which are binary. If you want Git to guess, you can set the attribute text=auto. For example, the following might be appropriate in some projects:

By default, guess.

*       text=auto
# Mark all C files as text.
*.c     text
# Mark all JPEG files as binary.
*.jpg   binary

These settings help tools pick the right format for output such as patches and result in files being checked out in the appropriate line ending for the platform.

GIT

Part of the git(1) suite

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

178 - Linux cli command EVP_MD-MDC2ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_MD-MDC2ssl and provides detailed information about the command EVP_MD-MDC2ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_MD-MDC2ssl.

NAME 🖥️ EVP_MD-MDC2ssl 🖥️

MDC2 - The MDC2 EVP_MD implementation

DESCRIPTION

Support for computing MDC2 digests through the EVP_MD API.

Identity

This implementation is only available with the legacy provider, and is identified with the name “MDC2”.

Gettable Parameters

This implementation supports the common gettable parameters described in EVP_MD-common (7).

Settable Context Parameters

This implementation supports the following OSSL_PARAM (3) entries, settable for an EVP_MD_CTX with EVP_MD_CTX_set_params (3):

“pad-type” (OSSL_DIGEST_PARAM_PAD_TYPE) <unsigned integer>
Sets the padding type to be used. Normally the final MDC2 block is padded with zeros. If the pad type is set to 2 then the final block is padded with 0x80 followed by zeros.

SEE ALSO

EVP_MD_CTX_set_params (3), provider-digest (7), OSSL_PROVIDER-legacy (7)

COPYRIGHT

Copyright 2020-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

179 - Linux cli command provider-signaturessl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command provider-signaturessl and provides detailed information about the command provider-signaturessl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the provider-signaturessl.

NAME 🖥️ provider-signaturessl 🖥️

signature - The signature library <-> provider functions

SYNOPSIS

#include <openssl/core_dispatch.h> #include <openssl/core_names.h> /* * None of these are actual functions, but are displayed like this for * the function signatures for functions that are offered as function * pointers in OSSL_DISPATCH arrays. */ /* Context management */ void *OSSL_FUNC_signature_newctx(void *provctx, const char *propq); void OSSL_FUNC_signature_freectx(void *ctx); void *OSSL_FUNC_signature_dupctx(void *ctx); /* Signing */ int OSSL_FUNC_signature_sign_init(void *ctx, void *provkey, const OSSL_PARAM params[]); int OSSL_FUNC_signature_sign(void *ctx, unsigned char *sig, size_t *siglen, size_t sigsize, const unsigned char *tbs, size_t tbslen); /* Verifying */ int OSSL_FUNC_signature_verify_init(void *ctx, void *provkey, const OSSL_PARAM params[]); int OSSL_FUNC_signature_verify(void *ctx, const unsigned char *sig, size_t siglen, const unsigned char *tbs, size_t tbslen); /* Verify Recover */ int OSSL_FUNC_signature_verify_recover_init(void *ctx, void *provkey, const OSSL_PARAM params[]); int OSSL_FUNC_signature_verify_recover(void *ctx, unsigned char *rout, size_t *routlen, size_t routsize, const unsigned char *sig, size_t siglen); /* Digest Sign */ int OSSL_FUNC_signature_digest_sign_init(void *ctx, const char *mdname, void *provkey, const OSSL_PARAM params[]); int OSSL_FUNC_signature_digest_sign_update(void *ctx, const unsigned char *data, size_t datalen); int OSSL_FUNC_signature_digest_sign_final(void *ctx, unsigned char *sig, size_t *siglen, size_t sigsize); int OSSL_FUNC_signature_digest_sign(void *ctx, unsigned char *sig, size_t *siglen, size_t sigsize, const unsigned char *tbs, size_t tbslen); /* Digest Verify */ int OSSL_FUNC_signature_digest_verify_init(void *ctx, const char *mdname, void *provkey, const OSSL_PARAM params[]); int OSSL_FUNC_signature_digest_verify_update(void *ctx, const unsigned char *data, size_t datalen); int OSSL_FUNC_signature_digest_verify_final(void *ctx, const unsigned char *sig, size_t siglen); int OSSL_FUNC_signature_digest_verify(void *ctx, const unsigned char *sig, size_t siglen, const unsigned char *tbs, size_t tbslen); /* Signature parameters */ int OSSL_FUNC_signature_get_ctx_params(void *ctx, OSSL_PARAM params[]); const OSSL_PARAM *OSSL_FUNC_signature_gettable_ctx_params(void *ctx, void *provctx); int OSSL_FUNC_signature_set_ctx_params(void *ctx, const OSSL_PARAM params[]); const OSSL_PARAM *OSSL_FUNC_signature_settable_ctx_params(void *ctx, void *provctx); /* MD parameters */ int OSSL_FUNC_signature_get_ctx_md_params(void *ctx, OSSL_PARAM params[]); const OSSL_PARAM * OSSL_FUNC_signature_gettable_ctx_md_params(void *ctx); int OSSL_FUNC_signature_set_ctx_md_params(void *ctx, const OSSL_PARAM params[]); const OSSL_PARAM * OSSL_FUNC_signature_settable_ctx_md_params(void *ctx);

DESCRIPTION

This documentation is primarily aimed at provider authors. See provider (7) for further information.

The signature (OSSL_OP_SIGNATURE) operation enables providers to implement signature algorithms and make them available to applications via the API functions EVP_PKEY_sign (3), EVP_PKEY_verify (3), and EVP_PKEY_verify_recover (3) (as well as other related functions).

All “functions” mentioned here are passed as function pointers between libcrypto and the provider in OSSL_DISPATCH (3) arrays via OSSL_ALGORITHM (3) arrays that are returned by the provider’s provider_query_operation() function (see “Provider Functions” in provider-base (7)).

All these “functions” have a corresponding function type definition named OSSL_FUNC_{name}_fn, and a helper function to retrieve the function pointer from an OSSL_DISPATCH (3) element named OSSL_FUNC_{name}. For example, the “function” OSSL_FUNC_signature_newctx() has these:

typedef void *(OSSL_FUNC_signature_newctx_fn)(void *provctx, const char *propq); static ossl_inline OSSL_FUNC_signature_newctx_fn OSSL_FUNC_signature_newctx(const OSSL_DISPATCH *opf);

OSSL_DISPATCH (3) arrays are indexed by numbers that are provided as macros in openssl-core_dispatch.h (7), as follows:

OSSL_FUNC_signature_newctx OSSL_FUNC_SIGNATURE_NEWCTX OSSL_FUNC_signature_freectx OSSL_FUNC_SIGNATURE_FREECTX OSSL_FUNC_signature_dupctx OSSL_FUNC_SIGNATURE_DUPCTX OSSL_FUNC_signature_sign_init OSSL_FUNC_SIGNATURE_SIGN_INIT OSSL_FUNC_signature_sign OSSL_FUNC_SIGNATURE_SIGN OSSL_FUNC_signature_verify_init OSSL_FUNC_SIGNATURE_VERIFY_INIT OSSL_FUNC_signature_verify OSSL_FUNC_SIGNATURE_VERIFY OSSL_FUNC_signature_verify_recover_init OSSL_FUNC_SIGNATURE_VERIFY_RECOVER_INIT OSSL_FUNC_signature_verify_recover OSSL_FUNC_SIGNATURE_VERIFY_RECOVER OSSL_FUNC_signature_digest_sign_init OSSL_FUNC_SIGNATURE_DIGEST_SIGN_INIT OSSL_FUNC_signature_digest_sign_update OSSL_FUNC_SIGNATURE_DIGEST_SIGN_UPDATE OSSL_FUNC_signature_digest_sign_final OSSL_FUNC_SIGNATURE_DIGEST_SIGN_FINAL OSSL_FUNC_signature_digest_sign OSSL_FUNC_SIGNATURE_DIGEST_SIGN OSSL_FUNC_signature_digest_verify_init OSSL_FUNC_SIGNATURE_DIGEST_VERIFY_INIT OSSL_FUNC_signature_digest_verify_update OSSL_FUNC_SIGNATURE_DIGEST_VERIFY_UPDATE OSSL_FUNC_signature_digest_verify_final OSSL_FUNC_SIGNATURE_DIGEST_VERIFY_FINAL OSSL_FUNC_signature_digest_verify OSSL_FUNC_SIGNATURE_DIGEST_VERIFY OSSL_FUNC_signature_get_ctx_params OSSL_FUNC_SIGNATURE_GET_CTX_PARAMS OSSL_FUNC_signature_gettable_ctx_params OSSL_FUNC_SIGNATURE_GETTABLE_CTX_PARAMS OSSL_FUNC_signature_set_ctx_params OSSL_FUNC_SIGNATURE_SET_CTX_PARAMS OSSL_FUNC_signature_settable_ctx_params OSSL_FUNC_SIGNATURE_SETTABLE_CTX_PARAMS OSSL_FUNC_signature_get_ctx_md_params OSSL_FUNC_SIGNATURE_GET_CTX_MD_PARAMS OSSL_FUNC_signature_gettable_ctx_md_params OSSL_FUNC_SIGNATURE_GETTABLE_CTX_MD_PARAMS OSSL_FUNC_signature_set_ctx_md_params OSSL_FUNC_SIGNATURE_SET_CTX_MD_PARAMS OSSL_FUNC_signature_settable_ctx_md_params OSSL_FUNC_SIGNATURE_SETTABLE_CTX_MD_PARAMS

A signature algorithm implementation may not implement all of these functions. In order to be a consistent set of functions we must have at least a set of context functions (OSSL_FUNC_signature_newctx and OSSL_FUNC_signature_freectx) as well as a set of “signature” functions, i.e. at least one of:

OSSL_FUNC_signature_sign_init and OSSL_FUNC_signature_sign

OSSL_FUNC_signature_verify_init and OSSL_FUNC_signature_verify

OSSL_FUNC_signature_verify_recover_init and OSSL_FUNC_signature_verify_recover

OSSL_FUNC_signature_digest_sign_init, OSSL_FUNC_signature_digest_sign_update and OSSL_FUNC_signature_digest_sign_final

OSSL_FUNC_signature_digest_verify_init, OSSL_FUNC_signature_digest_verify_update and OSSL_FUNC_signature_digest_verify_final

OSSL_FUNC_signature_digest_sign_init and OSSL_FUNC_signature_digest_sign

OSSL_FUNC_signature_digest_verify_init and OSSL_FUNC_signature_digest_verify

OSSL_FUNC_signature_set_ctx_params and OSSL_FUNC_signature_settable_ctx_params are optional, but if one of them is present then the other one must also be present. The same applies to OSSL_FUNC_signature_get_ctx_params and OSSL_FUNC_signature_gettable_ctx_params, as well as the “md_params” functions. The OSSL_FUNC_signature_dupctx function is optional.

A signature algorithm must also implement some mechanism for generating, loading or importing keys via the key management (OSSL_OP_KEYMGMT) operation. See provider-keymgmt (7) for further details.

Context Management Functions

OSSL_FUNC_signature_newctx() should create and return a pointer to a provider side structure for holding context information during a signature operation. A pointer to this context will be passed back in a number of the other signature operation function calls. The parameter provctx is the provider context generated during provider initialisation (see provider (7)). The propq parameter is a property query string that may be (optionally) used by the provider during any “fetches” that it may perform (if it performs any).

OSSL_FUNC_signature_freectx() is passed a pointer to the provider side signature context in the ctx parameter. This function should free any resources associated with that context.

OSSL_FUNC_signature_dupctx() should duplicate the provider side signature context in the ctx parameter and return the duplicate copy.

Signing Functions

OSSL_FUNC_signature_sign_init() initialises a context for signing given a provider side signature context in the ctx parameter, and a pointer to a provider key object in the provkey parameter. The params, if not NULL, should be set on the context in a manner similar to using OSSL_FUNC_signature_set_ctx_params(). The key object should have been previously generated, loaded or imported into the provider using the key management (OSSL_OP_KEYMGMT) operation (see provider-keymgmt (7)>.

OSSL_FUNC_signature_sign() performs the actual signing itself. A previously initialised signature context is passed in the ctx parameter. The data to be signed is pointed to be the tbs parameter which is tbslen bytes long. Unless sig is NULL, the signature should be written to the location pointed to by the sig parameter and it should not exceed sigsize bytes in length. The length of the signature should be written to *siglen. If sig is NULL then the maximum length of the signature should be written to *siglen.

Verify Functions

OSSL_FUNC_signature_verify_init() initialises a context for verifying a signature given a provider side signature context in the ctx parameter, and a pointer to a provider key object in the provkey parameter. The params, if not NULL, should be set on the context in a manner similar to using OSSL_FUNC_signature_set_ctx_params(). The key object should have been previously generated, loaded or imported into the provider using the key management (OSSL_OP_KEYMGMT) operation (see provider-keymgmt (7)>.

OSSL_FUNC_signature_verify() performs the actual verification itself. A previously initialised signature context is passed in the ctx parameter. The data that the signature covers is pointed to be the tbs parameter which is tbslen bytes long. The signature is pointed to by the sig parameter which is siglen bytes long.

Verify Recover Functions

OSSL_FUNC_signature_verify_recover_init() initialises a context for recovering the signed data given a provider side signature context in the ctx parameter, and a pointer to a provider key object in the provkey parameter. The params, if not NULL, should be set on the context in a manner similar to using OSSL_FUNC_signature_set_ctx_params(). The key object should have been previously generated, loaded or imported into the provider using the key management (OSSL_OP_KEYMGMT) operation (see provider-keymgmt (7)>.

OSSL_FUNC_signature_verify_recover() performs the actual verify recover itself. A previously initialised signature context is passed in the ctx parameter. The signature is pointed to by the sig parameter which is siglen bytes long. Unless rout is NULL, the recovered data should be written to the location pointed to by rout which should not exceed routsize bytes in length. The length of the recovered data should be written to *routlen. If rout is NULL then the maximum size of the output buffer is written to the routlen parameter.

Digest Sign Functions

OSSL_FUNC_signature_digeset_sign_init() initialises a context for signing given a provider side signature context in the ctx parameter, and a pointer to a provider key object in the provkey parameter. The params, if not NULL, should be set on the context in a manner similar to using OSSL_FUNC_signature_set_ctx_params() and OSSL_FUNC_signature_set_ctx_md_params(). The key object should have been previously generated, loaded or imported into the provider using the key management (OSSL_OP_KEYMGMT) operation (see provider-keymgmt (7)>. The name of the digest to be used will be in the mdname parameter.

OSSL_FUNC_signature_digest_sign_update() provides data to be signed in the data parameter which should be of length datalen. A previously initialised signature context is passed in the ctx parameter. This function may be called multiple times to cumulatively add data to be signed.

OSSL_FUNC_signature_digest_sign_final() finalises a signature operation previously started through OSSL_FUNC_signature_digest_sign_init() and OSSL_FUNC_signature_digest_sign_update() calls. Once finalised no more data will be added through OSSL_FUNC_signature_digest_sign_update(). A previously initialised signature context is passed in the ctx parameter. Unless sig is NULL, the signature should be written to the location pointed to by the sig parameter and it should not exceed sigsize bytes in length. The length of the signature should be written to *siglen. If sig is NULL then the maximum length of the signature should be written to *siglen.

OSSL_FUNC_signature_digest_sign() implements a “one shot” digest sign operation previously started through OSSL_FUNC_signature_digeset_sign_init(). A previously initialised signature context is passed in the ctx parameter. The data to be signed is in tbs which should be tbslen bytes long. Unless sig is NULL, the signature should be written to the location pointed to by the sig parameter and it should not exceed sigsize bytes in length. The length of the signature should be written to *siglen. If sig is NULL then the maximum length of the signature should be written to *siglen.

Digest Verify Functions

OSSL_FUNC_signature_digeset_verify_init() initialises a context for verifying given a provider side verification context in the ctx parameter, and a pointer to a provider key object in the provkey parameter. The params, if not NULL, should be set on the context in a manner similar to OSSL_FUNC_signature_set_ctx_params() and OSSL_FUNC_signature_set_ctx_md_params(). The key object should have been previously generated, loaded or imported into the provider using the key management (OSSL_OP_KEYMGMT) operation (see provider-keymgmt (7)>. The name of the digest to be used will be in the mdname parameter.

OSSL_FUNC_signature_digest_verify_update() provides data to be verified in the data parameter which should be of length datalen. A previously initialised verification context is passed in the ctx parameter. This function may be called multiple times to cumulatively add data to be verified.

OSSL_FUNC_signature_digest_verify_final() finalises a verification operation previously started through OSSL_FUNC_signature_digest_verify_init() and OSSL_FUNC_signature_digest_verify_update() calls. Once finalised no more data will be added through OSSL_FUNC_signature_digest_verify_update(). A previously initialised verification context is passed in the ctx parameter. The signature to be verified is in sig which is siglen bytes long.

OSSL_FUNC_signature_digest_verify() implements a “one shot” digest verify operation previously started through OSSL_FUNC_signature_digeset_verify_init(). A previously initialised verification context is passed in the ctx parameter. The data to be verified is in tbs which should be tbslen bytes long. The signature to be verified is in sig which is siglen bytes long.

Signature parameters

See OSSL_PARAM (3) for further details on the parameters structure used by the OSSL_FUNC_signature_get_ctx_params() and OSSL_FUNC_signature_set_ctx_params() functions.

OSSL_FUNC_signature_get_ctx_params() gets signature parameters associated with the given provider side signature context ctx and stored them in params. Passing NULL for params should return true.

OSSL_FUNC_signature_set_ctx_params() sets the signature parameters associated with the given provider side signature context ctx to params. Any parameter settings are additional to any that were previously set. Passing NULL for params should return true.

Common parameters currently recognised by built-in signature algorithms are as follows.

“digest” (OSSL_SIGNATURE_PARAM_DIGEST) <UTF8 string>
Get or sets the name of the digest algorithm used for the input to the signature functions. It is required in order to calculate the “algorithm-id”.

“properties” (OSSL_SIGNATURE_PARAM_PROPERTIES) <UTF8 string>
Sets the name of the property query associated with the “digest” algorithm. NULL is used if this optional value is not set.

“digest-size” (OSSL_SIGNATURE_PARAM_DIGEST_SIZE) <unsigned integer>
Gets or sets the output size of the digest algorithm used for the input to the signature functions. The length of the “digest-size” parameter should not exceed that of a size_t.

“algorithm-id” (OSSL_SIGNATURE_PARAM_ALGORITHM_ID) <octet string>
Gets the DER encoded AlgorithmIdentifier that corresponds to the combination of signature algorithm and digest algorithm for the signature operation.

“nonce-type” (OSSL_SIGNATURE_PARAM_NONCE_TYPE) <unsigned integer>
Set this to 1 to use deterministic digital signature generation with ECDSA or DSA, as defined in RFC 6979 (see Section 3.2 “Generation of k”). In this case, the “digest” parameter must be explicitly set (otherwise, deterministic nonce generation will fail). Before using deterministic digital signature generation, please read RFC 6979 Section 4 “Security Considerations”. The default value for “nonce-type” is 0 and results in a random value being used for the nonce k as defined in FIPS 186-4 Section 6.3 “Secret Number Generation”.

“kat” (OSSL_SIGNATURE_PARAM_KAT) <unsigned integer>
Sets a flag to modify the sign operation to return an error if the initial calculated signature is invalid. In the normal mode of operation - new random values are chosen until the signature operation succeeds. By default it retries until a signature is calculated. Setting the value to 0 causes the sign operation to retry, otherwise the sign operation is only tried once and returns whether or not it was successful. Known answer tests can be performed if the random generator is overridden to supply known values that either pass or fail.

OSSL_FUNC_signature_gettable_ctx_params() and OSSL_FUNC_signature_settable_ctx_params() get a constant OSSL_PARAM (3) array that describes the gettable and settable parameters, i.e. parameters that can be used with OSSL_FUNC_signature_get_ctx_params() and OSSL_FUNC_signature_set_ctx_params() respectively.

MD parameters

See OSSL_PARAM (3) for further details on the parameters structure used by the OSSL_FUNC_signature_get_md_ctx_params() and OSSL_FUNC_signature_set_md_ctx_params() functions.

OSSL_FUNC_signature_get_md_ctx_params() gets digest parameters associated with the given provider side digest signature context ctx and stores them in params. Passing NULL for params should return true.

OSSL_FUNC_signature_set_ms_ctx_params() sets the digest parameters associated with the given provider side digest signature context ctx to params. Any parameter settings are additional to any that were previously set. Passing NULL for params should return true.

Parameters currently recognised by built-in signature algorithms are the same as those for built-in digest algorithms. See “Digest Parameters” in provider-digest (7) for further information.

OSSL_FUNC_signature_gettable_md_ctx_params() and OSSL_FUNC_signature_settable_md_ctx_params() get a constant OSSL_PARAM (3) array that describes the gettable and settable digest parameters, i.e. parameters that can be used with OSSL_FUNC_signature_get_md_ctx_params() and OSSL_FUNC_signature_set_md_ctx_params() respectively.

RETURN VALUES

OSSL_FUNC_signature_newctx() and OSSL_FUNC_signature_dupctx() should return the newly created provider side signature context, or NULL on failure.

OSSL_FUNC_signature_gettable_ctx_params(), OSSL_FUNC_signature_settable_ctx_params(), OSSL_FUNC_signature_gettable_md_ctx_params() and OSSL_FUNC_signature_settable_md_ctx_params(), return the gettable or settable parameters in a constant OSSL_PARAM (3) array.

All other functions should return 1 for success or 0 on error.

SEE ALSO

provider (7)

HISTORY

The provider SIGNATURE interface was introduced in OpenSSL 3.0.

COPYRIGHT

Copyright 2019-2024 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

180 - Linux cli command EVP_RANDssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_RANDssl and provides detailed information about the command EVP_RANDssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_RANDssl.

NAME 🖥️ EVP_RANDssl 🖥️

the random bit generator

SYNOPSIS

#include <openssl/evp.h> #include <rand.h>

DESCRIPTION

The default OpenSSL RAND method is based on the EVP_RAND classes to provide non-deterministic inputs to other cryptographic algorithms.

While the RAND API is the ‘frontend’ which is intended to be used by application developers for obtaining random bytes, the EVP_RAND API serves as the ‘backend’, connecting the former with the operating systems’s entropy sources and providing access to deterministic random bit generators (DRBG) and their configuration parameters. A DRBG is a certain type of cryptographically-secure pseudo-random number generator (CSPRNG), which is described in [NIST SP 800-90A Rev. 1].

Disclaimer

Unless you have very specific requirements for your random generator, it is in general not necessary to utilize the EVP_RAND API directly. The usual way to obtain random bytes is to use RAND_bytes (3) or RAND_priv_bytes (3), see also RAND (7).

Typical Use Cases

Typical examples for such special use cases are the following:

  • You want to use your own private DRBG instances. Multiple DRBG instances which are accessed only by a single thread provide additional security (because their internal states are independent) and better scalability in multithreaded applications (because they don’t need to be locked).

  • You need to integrate a previously unsupported entropy source. Refer to provider-rand (7) for the implementation details to support adding randomness sources to EVP_RAND.

  • You need to change the default settings of the standard OpenSSL RAND implementation to meet specific requirements.

EVP_RAND CHAINING

An EVP_RAND instance can be used as the entropy source of another EVP_RAND instance, provided it has itself access to a valid entropy source. The EVP_RAND instance which acts as entropy source is called the parent, the other instance the child. Typically, the child will be a DRBG because it does not make sense for the child to be an entropy source.

This is called chaining. A chained EVP_RAND instance is created by passing a pointer to the parent EVP_RAND_CTX as argument to the EVP_RAND_CTX_new() call. It is possible to create chains of more than two DRBG in a row. It is also possible to use any EVP_RAND_CTX class as the parent, however, only a live entropy source may ignore and not use its parent.

THE THREE SHARED DRBG INSTANCES

Currently, there are three shared DRBG instances, the <primary>, <public>, and <private> DRBG. While the <primary> DRBG is a single global instance, the <public> and <private> DRBG are created per thread and accessed through thread-local storage.

By default, the functions RAND_bytes (3) and RAND_priv_bytes (3) use the thread-local <public> and <private> DRBG instance, respectively.

The <primary> DRBG instance

The <primary> DRBG is not used directly by the application, only for reseeding the two other two DRBG instances. It reseeds itself by obtaining randomness either from os entropy sources or by consuming randomness which was added previously by RAND_add (3).

The <public> DRBG instance

This instance is used per default by RAND_bytes (3).

The <private> DRBG instance

This instance is used per default by RAND_priv_bytes (3)

LOCKING

The <primary> DRBG is intended to be accessed concurrently for reseeding by its child DRBG instances. The necessary locking is done internally. It is not thread-safe to access the <primary> DRBG directly via the EVP_RAND interface. The <public> and <private> DRBG are thread-local, i.e. there is an instance of each per thread. So they can safely be accessed without locking via the EVP_RAND interface.

Pointers to these DRBG instances can be obtained using RAND_get0_primary(), RAND_get0_public() and RAND_get0_private(), respectively. Note that it is not allowed to store a pointer to one of the thread-local DRBG instances in a variable or other memory location where it will be accessed and used by multiple threads.

All other DRBG instances created by an application don’t support locking, because they are intended to be used by a single thread. Instead of accessing a single DRBG instance concurrently from different threads, it is recommended to instantiate a separate DRBG instance per thread. Using the <primary> DRBG as entropy source for multiple DRBG instances on different threads is thread-safe, because the DRBG instance will lock the <primary> DRBG automatically for obtaining random input.

THE OVERALL PICTURE

The following picture gives an overview over how the DRBG instances work together and are being used.

+——————–+ | os entropy sources | +——————–+ | v +—————————–+ RAND_add() ==> <primary> <-| shared DRBG (with locking) | / \ +—————————–+ / \ +—————————+ <public> <private> <- | per-thread DRBG instances | | | +—————————+ v v RAND_bytes() RAND_priv_bytes() | ^ | | +——————+ +————————————+ | general purpose | | used for secrets like session keys | | random generator | | and private keys for certificates | +——————+ +————————————+

The usual way to obtain random bytes is to call RAND_bytes(…) or RAND_priv_bytes(…). These calls are roughly equivalent to calling EVP_RAND_generate(<public>, …) and EVP_RAND_generate(<private>, …), respectively.

RESEEDING

A DRBG instance seeds itself automatically, pulling random input from its entropy source. The entropy source can be either a trusted operating system entropy source, or another DRBG with access to such a source.

Automatic reseeding occurs after a predefined number of generate requests. The selection of the trusted entropy sources is configured at build time using the –with-rand-seed option. The following sections explain the reseeding process in more detail.

Automatic Reseeding

Before satisfying a generate request (EVP_RAND_generate (3)), the DRBG reseeds itself automatically, if one of the following conditions holds:

- the DRBG was not instantiated (=seeded) yet or has been uninstantiated.

- the number of generate requests since the last reseeding exceeds a certain threshold, the so called reseed_interval. This behaviour can be disabled by setting the reseed_interval to 0.

- the time elapsed since the last reseeding exceeds a certain time interval, the so called reseed_time_interval. This can be disabled by setting the reseed_time_interval to 0.

- the DRBG is in an error state.

Note: An error state is entered if the entropy source fails while the DRBG is seeding or reseeding. The last case ensures that the DRBG automatically recovers from the error as soon as the entropy source is available again.

Manual Reseeding

In addition to automatic reseeding, the caller can request an immediate reseeding of the DRBG with fresh entropy by setting the prediction resistance parameter to 1 when calling EVP_RAND_generate (3).

The document [NIST SP 800-90C] describes prediction resistance requests in detail and imposes strict conditions on the entropy sources that are approved for providing prediction resistance. A request for prediction resistance can only be satisfied by pulling fresh entropy from a live entropy source (section 5.5.2 of [NIST SP 800-90C]). It is up to the user to ensure that a live entropy source is configured and is being used.

For the three shared DRBGs (and only for these) there is another way to reseed them manually: If RAND_add (3) is called with a positive randomness argument (or RAND_seed (3)), then this will immediately reseed the <primary> DRBG. The <public> and <private> DRBG will detect this on their next generate call and reseed, pulling randomness from <primary>.

The last feature has been added to support the common practice used with previous OpenSSL versions to call RAND_add() before calling RAND_bytes().

Entropy Input and Additional Data

The DRBG distinguishes two different types of random input: entropy, which comes from a trusted source, and additional input’, which can optionally be added by the user and is considered untrusted. It is possible to add additional input not only during reseeding, but also for every generate request.

Configuring the Random Seed Source

In most cases OpenSSL will automatically choose a suitable seed source for automatically seeding and reseeding its <primary> DRBG. In some cases however, it will be necessary to explicitly specify a seed source during configuration, using the –with-rand-seed option. For more information, see the INSTALL instructions. There are also operating systems where no seed source is available and automatic reseeding is disabled by default.

The following two sections describe the reseeding process of the primary DRBG, depending on whether automatic reseeding is available or not.

Reseeding the primary DRBG with automatic seeding enabled

Calling RAND_poll() or RAND_add() is not necessary, because the DRBG pulls the necessary entropy from its source automatically. However, both calls are permitted, and do reseed the RNG.

RAND_add() can be used to add both kinds of random input, depending on the value of the randomness argument:

randomness == 0:
The random bytes are mixed as additional input into the current state of the DRBG. Mixing in additional input is not considered a full reseeding, hence the reseed counter is not reset.

randomness > 0:
The random bytes are used as entropy input for a full reseeding (resp. reinstantiation) if the DRBG is instantiated (resp. uninstantiated or in an error state). The number of random bits required for reseeding is determined by the security strength of the DRBG. Currently it defaults to 256 bits (32 bytes). It is possible to provide less randomness than required. In this case the missing randomness will be obtained by pulling random input from the trusted entropy sources.

NOTE: Manual reseeding is *not allowed* in FIPS mode, because [NIST SP-800-90Ar1] mandates that entropy *shall not* be provided by the consuming application for instantiation (Section 9.1) or reseeding (Section 9.2). For that reason, the randomness argument is ignored and the random bytes provided by the RAND_add (3) and RAND_seed (3) calls are treated as additional data.

Reseeding the primary DRBG with automatic seeding disabled

Calling RAND_poll() will always fail.

RAND_add() needs to be called for initial seeding and periodic reseeding. At least 48 bytes (384 bits) of randomness have to be provided, otherwise the (re-)seeding of the DRBG will fail. This corresponds to one and a half times the security strength of the DRBG. The extra half is used for the nonce during instantiation.

More precisely, the number of bytes needed for seeding depend on the security strength of the DRBG, which is set to 256 by default.

SEE ALSO

RAND (7), EVP_RAND (3)

HISTORY

This functionality was added in OpenSSL 3.0.

COPYRIGHT

Copyright 2017-2020 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

181 - Linux cli command SET

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command SET and provides detailed information about the command SET, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the SET.

NAME 🖥️ SET 🖥️

change a run-time parameter

SYNOPSIS

SET [ SESSION | LOCAL ] configuration_parameter { TO | = } { value | value | DEFAULT }
SET [ SESSION | LOCAL ] TIME ZONE { value | value | LOCAL | DEFAULT }

DESCRIPTION

The SET command changes run-time configuration parameters. Many of the run-time parameters listed in Chapter 20 can be changed on-the-fly with SET. (Some parameters can only be changed by superusers and users who have been granted SET privilege on that parameter. There are also parameters that cannot be changed after server or session start.) SET only affects the value used by the current session.

If SET (or equivalently SET SESSION) is issued within a transaction that is later aborted, the effects of the SET command disappear when the transaction is rolled back. Once the surrounding transaction is committed, the effects will persist until the end of the session, unless overridden by another SET.

The effects of SET LOCAL last only till the end of the current transaction, whether committed or not. A special case is SET followed by SET LOCAL within a single transaction: the SET LOCAL value will be seen until the end of the transaction, but afterwards (if the transaction is committed) the SET value will take effect.

The effects of SET or SET LOCAL are also canceled by rolling back to a savepoint that is earlier than the command.

If SET LOCAL is used within a function that has a SET option for the same variable (see CREATE FUNCTION (CREATE_FUNCTION(7))), the effects of the SET LOCAL command disappear at function exit; that is, the value in effect when the function was called is restored anyway. This allows SET LOCAL to be used for dynamic or repeated changes of a parameter within a function, while still having the convenience of using the SET option to save and restore the callers value. However, a regular SET command overrides any surrounding functions SET option; its effects will persist unless rolled back.

Note

In PostgreSQL versions 8.0 through 8.2, the effects of a SET LOCAL would be canceled by releasing an earlier savepoint, or by successful exit from a PL/pgSQL exception block. This behavior has been changed because it was deemed unintuitive.

PARAMETERS

SESSION

Specifies that the command takes effect for the current session. (This is the default if neither SESSION nor LOCAL appears.)

LOCAL

Specifies that the command takes effect for only the current transaction. After COMMIT or ROLLBACK, the session-level setting takes effect again. Issuing this outside of a transaction block emits a warning and otherwise has no effect.

configuration_parameter

Name of a settable run-time parameter. Available parameters are documented in Chapter 20 and below.

value

New value of parameter. Values can be specified as string constants, identifiers, numbers, or comma-separated lists of these, as appropriate for the particular parameter. DEFAULT can be written to specify resetting the parameter to its default value (that is, whatever value it would have had if no SET had been executed in the current session).

Besides the configuration parameters documented in Chapter 20, there are a few that can only be adjusted using the SET command or that have a special syntax:

SCHEMA

SET SCHEMA value is an alias for SET search_path TO value. Only one schema can be specified using this syntax.

NAMES

SET NAMES value is an alias for SET client_encoding TO value.

SEED

Sets the internal seed for the random number generator (the function random). Allowed values are floating-point numbers between -1 and 1 inclusive.

The seed can also be set by invoking the function setseed:

SELECT setseed(value);

TIME ZONE

SET TIME ZONE value is an alias for SET timezone TO value. The syntax SET TIME ZONE allows special syntax for the time zone specification. Here are examples of valid values:

PST8PDT

The time zone for Berkeley, California.

Europe/Rome

The time zone for Italy.

-7

The time zone 7 hours west from UTC (equivalent to PDT). Positive values are east from UTC.

INTERVAL -08:00 HOUR TO MINUTE

The time zone 8 hours west from UTC (equivalent to PST).

LOCAL
DEFAULT

Set the time zone to your local time zone (that is, the servers default value of timezone).

Timezone settings given as numbers or intervals are internally translated to POSIX timezone syntax. For example, after SET TIME ZONE -7, SHOW TIME ZONE would report <-07>+07.

Time zone abbreviations are not supported by SET; see Section 8.5.3 for more information about time zones.

NOTES

The function set_config provides equivalent functionality; see Section 9.27.1. Also, it is possible to UPDATE the pg_settings system view to perform the equivalent of SET.

EXAMPLES

Set the schema search path:

SET search_path TO my_schema, public;

Set the style of date to traditional POSTGRES with “day before month” input convention:

SET datestyle TO postgres, dmy;

Set the time zone for Berkeley, California:

SET TIME ZONE PST8PDT;

Set the time zone for Italy:

SET TIME ZONE Europe/Rome;

COMPATIBILITY

SET TIME ZONE extends syntax defined in the SQL standard. The standard allows only numeric time zone offsets while PostgreSQL allows more flexible time-zone specifications. All other SET features are PostgreSQL extensions.

SEE ALSO

RESET(7), SHOW(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

182 - Linux cli command EXPLAIN

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EXPLAIN and provides detailed information about the command EXPLAIN, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EXPLAIN.

NAME 🖥️ EXPLAIN 🖥️

show the execution plan of a statement

SYNOPSIS

EXPLAIN [ ( option [, ...] ) ] statement
EXPLAIN [ ANALYZE ] [ VERBOSE ] statement

where option can be one of:

    ANALYZE [ boolean ]
    VERBOSE [ boolean ]
    COSTS [ boolean ]
    SETTINGS [ boolean ]
    GENERIC_PLAN [ boolean ]
    BUFFERS [ boolean ]
    WAL [ boolean ]
    TIMING [ boolean ]
    SUMMARY [ boolean ]
    FORMAT { TEXT | XML | JSON | YAML }

DESCRIPTION

This command displays the execution plan that the PostgreSQL planner generates for the supplied statement. The execution plan shows how the table(s) referenced by the statement will be scanned — by plain sequential scan, index scan, etc. — and if multiple tables are referenced, what join algorithms will be used to bring together the required rows from each input table.

The most critical part of the display is the estimated statement execution cost, which is the planners guess at how long it will take to run the statement (measured in cost units that are arbitrary, but conventionally mean disk page fetches). Actually two numbers are shown: the start-up cost before the first row can be returned, and the total cost to return all the rows. For most queries the total cost is what matters, but in contexts such as a subquery in EXISTS, the planner will choose the smallest start-up cost instead of the smallest total cost (since the executor will stop after getting one row, anyway). Also, if you limit the number of rows to return with a LIMIT clause, the planner makes an appropriate interpolation between the endpoint costs to estimate which plan is really the cheapest.

The ANALYZE option causes the statement to be actually executed, not only planned. Then actual run time statistics are added to the display, including the total elapsed time expended within each plan node (in milliseconds) and the total number of rows it actually returned. This is useful for seeing whether the planners estimates are close to reality.

Important

Keep in mind that the statement is actually executed when the ANALYZE option is used. Although EXPLAIN will discard any output that a SELECT would return, other side effects of the statement will happen as usual. If you wish to use EXPLAIN ANALYZE on an INSERT, UPDATE, DELETE, MERGE, CREATE TABLE AS, or EXECUTE statement without letting the command affect your data, use this approach:

BEGIN; EXPLAIN ANALYZE …; ROLLBACK;

Only the ANALYZE and VERBOSE options can be specified, and only in that order, without surrounding the option list in parentheses. Prior to PostgreSQL 9.0, the unparenthesized syntax was the only one supported. It is expected that all new options will be supported only in the parenthesized syntax.

PARAMETERS

ANALYZE

Carry out the command and show actual run times and other statistics. This parameter defaults to FALSE.

VERBOSE

Display additional information regarding the plan. Specifically, include the output column list for each node in the plan tree, schema-qualify table and function names, always label variables in expressions with their range table alias, and always print the name of each trigger for which statistics are displayed. The query identifier will also be displayed if one has been computed, see compute_query_id for more details. This parameter defaults to FALSE.

COSTS

Include information on the estimated startup and total cost of each plan node, as well as the estimated number of rows and the estimated width of each row. This parameter defaults to TRUE.

SETTINGS

Include information on configuration parameters. Specifically, include options affecting query planning with value different from the built-in default value. This parameter defaults to FALSE.

GENERIC_PLAN

Allow the statement to contain parameter placeholders like $1, and generate a generic plan that does not depend on the values of those parameters. See PREPARE for details about generic plans and the types of statement that support parameters. This parameter cannot be used together with ANALYZE. It defaults to FALSE.

BUFFERS

Include information on buffer usage. Specifically, include the number of shared blocks hit, read, dirtied, and written, the number of local blocks hit, read, dirtied, and written, the number of temp blocks read and written, and the time spent reading and writing data file blocks and temporary file blocks (in milliseconds) if track_io_timing is enabled. A hit means that a read was avoided because the block was found already in cache when needed. Shared blocks contain data from regular tables and indexes; local blocks contain data from temporary tables and indexes; while temporary blocks contain short-term working data used in sorts, hashes, Materialize plan nodes, and similar cases. The number of blocks dirtied indicates the number of previously unmodified blocks that were changed by this query; while the number of blocks written indicates the number of previously-dirtied blocks evicted from cache by this backend during query processing. The number of blocks shown for an upper-level node includes those used by all its child nodes. In text format, only non-zero values are printed. This parameter defaults to FALSE.

WAL

Include information on WAL record generation. Specifically, include the number of records, number of full page images (fpi) and the amount of WAL generated in bytes. In text format, only non-zero values are printed. This parameter may only be used when ANALYZE is also enabled. It defaults to FALSE.

TIMING

Include actual startup time and time spent in each node in the output. The overhead of repeatedly reading the system clock can slow down the query significantly on some systems, so it may be useful to set this parameter to FALSE when only actual row counts, and not exact times, are needed. Run time of the entire statement is always measured, even when node-level timing is turned off with this option. This parameter may only be used when ANALYZE is also enabled. It defaults to TRUE.

SUMMARY

Include summary information (e.g., totaled timing information) after the query plan. Summary information is included by default when ANALYZE is used but otherwise is not included by default, but can be enabled using this option. Planning time in EXPLAIN EXECUTE includes the time required to fetch the plan from the cache and the time required for re-planning, if necessary.

FORMAT

Specify the output format, which can be TEXT, XML, JSON, or YAML. Non-text output contains the same information as the text output format, but is easier for programs to parse. This parameter defaults to TEXT.

boolean

Specifies whether the selected option should be turned on or off. You can write TRUE, ON, or 1 to enable the option, and FALSE, OFF, or 0 to disable it. The boolean value can also be omitted, in which case TRUE is assumed.

statement

Any SELECT, INSERT, UPDATE, DELETE, MERGE, VALUES, EXECUTE, DECLARE, CREATE TABLE AS, or CREATE MATERIALIZED VIEW AS statement, whose execution plan you wish to see.

OUTPUTS

The commands result is a textual description of the plan selected for the statement, optionally annotated with execution statistics. Section 14.1 describes the information provided.

NOTES

In order to allow the PostgreSQL query planner to make reasonably informed decisions when optimizing queries, the pg_statistic data should be up-to-date for all tables used in the query. Normally the autovacuum daemon will take care of that automatically. But if a table has recently had substantial changes in its contents, you might need to do a manual ANALYZE rather than wait for autovacuum to catch up with the changes.

In order to measure the run-time cost of each node in the execution plan, the current implementation of EXPLAIN ANALYZE adds profiling overhead to query execution. As a result, running EXPLAIN ANALYZE on a query can sometimes take significantly longer than executing the query normally. The amount of overhead depends on the nature of the query, as well as the platform being used. The worst case occurs for plan nodes that in themselves require very little time per execution, and on machines that have relatively slow operating system calls for obtaining the time of day.

EXAMPLES

To show the plan for a simple query on a table with a single integer column and 10000 rows:

EXPLAIN SELECT * FROM foo;

                       QUERY PLAN
---------------------------------------------------------
 Seq Scan on foo  (cost=0.00..155.00 rows=10000 width=4)
(1 row)

Here is the same query, with JSON output formatting:

EXPLAIN (FORMAT JSON) SELECT * FROM foo; QUERY PLAN ——————————– [ + { + “Plan”: { + “Node Type”: “Seq Scan”,+ “Relation Name”: “foo”, + “Alias”: “foo”, + “Startup Cost”: 0.00, + “Total Cost”: 155.00, + “Plan Rows”: 10000, + “Plan Width”: 4 + } + } + ] (1 row)

If there is an index and we use a query with an indexable WHERE condition, EXPLAIN might show a different plan:

EXPLAIN SELECT * FROM foo WHERE i = 4;

                         QUERY PLAN
--------------------------------------------------------------
 Index Scan using fi on foo  (cost=0.00..5.98 rows=1 width=4)
   Index Cond: (i = 4)
(2 rows)

Here is the same query, but in YAML format:

EXPLAIN (FORMAT YAML) SELECT * FROM foo WHERE i=4; QUERY PLAN ——————————- - Plan: + Node Type: “Index Scan” + Scan Direction: “Forward”+ Index Name: “fi” + Relation Name: “foo” + Alias: “foo” + Startup Cost: 0.00 + Total Cost: 5.98 + Plan Rows: 1 + Plan Width: 4 + Index Cond: “(i = 4)” (1 row)

XML format is left as an exercise for the reader.

Here is the same plan with cost estimates suppressed:

EXPLAIN (COSTS FALSE) SELECT * FROM foo WHERE i = 4;

        QUERY PLAN
----------------------------
 Index Scan using fi on foo
   Index Cond: (i = 4)
(2 rows)

Here is an example of a query plan for a query using an aggregate function:

EXPLAIN SELECT sum(i) FROM foo WHERE i < 10;

                             QUERY PLAN
---------------------------------------------------------------------
 Aggregate  (cost=23.93..23.93 rows=1 width=4)
   ->  Index Scan using fi on foo  (cost=0.00..23.92 rows=6 width=4)
         Index Cond: (i < 10)
(3 rows)

Here is an example of using EXPLAIN EXECUTE to display the execution plan for a prepared query:

PREPARE query(int, int) AS SELECT sum(bar) FROM test WHERE id > $1 AND id < $2 GROUP BY foo;

EXPLAIN ANALYZE EXECUTE query(100, 200);

                                                       QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------
 HashAggregate  (cost=10.77..10.87 rows=10 width=12) (actual time=0.043..0.044 rows=10 loops=1)
   Group Key: foo
   Batches: 1  Memory Usage: 24kB
   ->  Index Scan using test_pkey on test  (cost=0.29..10.27 rows=99 width=8) (actual time=0.009..0.025 rows=99 loops=1)
         Index Cond: ((id > 100) AND (id < 200))
 Planning Time: 0.244 ms
 Execution Time: 0.073 ms
(7 rows)

Of course, the specific numbers shown here depend on the actual contents of the tables involved. Also note that the numbers, and even the selected query strategy, might vary between PostgreSQL releases due to planner improvements. In addition, the ANALYZE command uses random sampling to estimate data statistics; therefore, it is possible for cost estimates to change after a fresh run of ANALYZE, even if the actual distribution of data in the table has not changed.

Notice that the previous example showed a “custom” plan for the specific parameter values given in EXECUTE. We might also wish to see the generic plan for a parameterized query, which can be done with GENERIC_PLAN:

EXPLAIN (GENERIC_PLAN) SELECT sum(bar) FROM test WHERE id > $1 AND id < $2 GROUP BY foo;

                                  QUERY PLAN
-------------------------------------------------------------------------------
 HashAggregate  (cost=26.79..26.89 rows=10 width=12)
   Group Key: foo
   ->  Index Scan using test_pkey on test  (cost=0.29..24.29 rows=500 width=8)
         Index Cond: ((id > $1) AND (id < $2))
(4 rows)

In this case the parser correctly inferred that $1 and $2 should have the same data type as id, so the lack of parameter type information from PREPARE was not a problem. In other cases it might be necessary to explicitly specify types for the parameter symbols, which can be done by casting them, for example:

EXPLAIN (GENERIC_PLAN) SELECT sum(bar) FROM test WHERE id > $1::integer AND id < $2::integer GROUP BY foo;

COMPATIBILITY

There is no EXPLAIN statement defined in the SQL standard.

SEE ALSO

ANALYZE(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

183 - Linux cli command CREATE_PUBLICATION

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_PUBLICATION and provides detailed information about the command CREATE_PUBLICATION, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_PUBLICATION.

NAME 🖥️ CREATE_PUBLICATION 🖥️

define a new publication

SYNOPSIS

CREATE PUBLICATION name
    [ FOR ALL TABLES
      | FOR publication_object [, ... ] ]
    [ WITH ( publication_parameter [= value] [, ... ] ) ]

where publication_object is one of:

    TABLE [ ONLY ] table_name [ * ] [ ( column_name [, ... ] ) ] [ WHERE ( expression ) ] [, ... ]
    TABLES IN SCHEMA { schema_name | CURRENT_SCHEMA } [, ... ]

DESCRIPTION

CREATE PUBLICATION adds a new publication into the current database. The publication name must be distinct from the name of any existing publication in the current database.

A publication is essentially a group of tables whose data changes are intended to be replicated through logical replication. See Section 31.1 for details about how publications fit into the logical replication setup.

PARAMETERS

name

The name of the new publication.

FOR TABLE

Specifies a list of tables to add to the publication. If ONLY is specified before the table name, only that table is added to the publication. If ONLY is not specified, the table and all its descendant tables (if any) are added. Optionally, * can be specified after the table name to explicitly indicate that descendant tables are included. This does not apply to a partitioned table, however. The partitions of a partitioned table are always implicitly considered part of the publication, so they are never explicitly added to the publication.

If the optional WHERE clause is specified, it defines a row filter expression. Rows for which the expression evaluates to false or null will not be published. Note that parentheses are required around the expression. It has no effect on TRUNCATE commands.

When a column list is specified, only the named columns are replicated. If no column list is specified, all columns of the table are replicated through this publication, including any columns added later. It has no effect on TRUNCATE commands. See Section 31.4 for details about column lists.

Only persistent base tables and partitioned tables can be part of a publication. Temporary tables, unlogged tables, foreign tables, materialized views, and regular views cannot be part of a publication.

Specifying a column list when the publication also publishes FOR TABLES IN SCHEMA is not supported.

When a partitioned table is added to a publication, all of its existing and future partitions are implicitly considered to be part of the publication. So, even operations that are performed directly on a partition are also published via publications that its ancestors are part of.

FOR ALL TABLES

Marks the publication as one that replicates changes for all tables in the database, including tables created in the future.

FOR TABLES IN SCHEMA

Marks the publication as one that replicates changes for all tables in the specified list of schemas, including tables created in the future.

Specifying a schema when the publication also publishes a table with a column list is not supported.

Only persistent base tables and partitioned tables present in the schema will be included as part of the publication. Temporary tables, unlogged tables, foreign tables, materialized views, and regular views from the schema will not be part of the publication.

When a partitioned table is published via schema level publication, all of its existing and future partitions are implicitly considered to be part of the publication, regardless of whether they are from the publication schema or not. So, even operations that are performed directly on a partition are also published via publications that its ancestors are part of.

WITH ( publication_parameter [= value] [, … ] )

This clause specifies optional parameters for a publication. The following parameters are supported:

publish (string)

This parameter determines which DML operations will be published by the new publication to the subscribers. The value is comma-separated list of operations. The allowed operations are insert, update, delete, and truncate. The default is to publish all actions, and so the default value for this option is insert, update, delete, truncate.

This parameter only affects DML operations. In particular, the initial data synchronization (see Section 31.7.1) for logical replication does not take this parameter into account when copying existing table data.

publish_via_partition_root (boolean)

This parameter determines whether changes in a partitioned table (or on its partitions) contained in the publication will be published using the identity and schema of the partitioned table rather than that of the individual partitions that are actually changed; the latter is the default. Enabling this allows the changes to be replicated into a non-partitioned table or a partitioned table consisting of a different set of partitions.

There can be a case where a subscription combines multiple publications. If a partitioned table is published by any subscribed publications which set publish_via_partition_root = true, changes on this partitioned table (or on its partitions) will be published using the identity and schema of this partitioned table rather than that of the individual partitions.

This parameter also affects how row filters and column lists are chosen for partitions; see below for details.

If this is enabled, TRUNCATE operations performed directly on partitions are not replicated.

When specifying a parameter of type boolean, the = value part can be omitted, which is equivalent to specifying TRUE.

NOTES

If FOR TABLE, FOR ALL TABLES or FOR TABLES IN SCHEMA are not specified, then the publication starts out with an empty set of tables. That is useful if tables or schemas are to be added later.

The creation of a publication does not start replication. It only defines a grouping and filtering logic for future subscribers.

To create a publication, the invoking user must have the CREATE privilege for the current database. (Of course, superusers bypass this check.)

To add a table to a publication, the invoking user must have ownership rights on the table. The FOR ALL TABLES and FOR TABLES IN SCHEMA clauses require the invoking user to be a superuser.

The tables added to a publication that publishes UPDATE and/or DELETE operations must have REPLICA IDENTITY defined. Otherwise those operations will be disallowed on those tables.

Any column list must include the REPLICA IDENTITY columns in order for UPDATE or DELETE operations to be published. There are no column list restrictions if the publication publishes only INSERT operations.

A row filter expression (i.e., the WHERE clause) must contain only columns that are covered by the REPLICA IDENTITY, in order for UPDATE and DELETE operations to be published. For publication of INSERT operations, any column may be used in the WHERE expression. The row filter allows simple expressions that dont have user-defined functions, user-defined operators, user-defined types, user-defined collations, non-immutable built-in functions, or references to system columns.

The row filter on a table becomes redundant if FOR TABLES IN SCHEMA is specified and the table belongs to the referred schema.

For published partitioned tables, the row filter for each partition is taken from the published partitioned table if the publication parameter publish_via_partition_root is true, or from the partition itself if it is false (the default). See Section 31.3 for details about row filters. Similarly, for published partitioned tables, the column list for each partition is taken from the published partitioned table if the publication parameter publish_via_partition_root is true, or from the partition itself if it is false.

For an INSERT … ON CONFLICT command, the publication will publish the operation that results from the command. Depending on the outcome, it may be published as either INSERT or UPDATE, or it may not be published at all.

For a MERGE command, the publication will publish an INSERT, UPDATE, or DELETE for each row inserted, updated, or deleted.

ATTACHing a table into a partition tree whose root is published using a publication with publish_via_partition_root set to true does not result in the tables existing contents being replicated.

COPY … FROM commands are published as INSERT operations.

DDL operations are not published.

The WHERE clause expression is executed with the role used for the replication connection.

EXAMPLES

Create a publication that publishes all changes in two tables:

CREATE PUBLICATION mypublication FOR TABLE users, departments;

Create a publication that publishes all changes from active departments:

CREATE PUBLICATION active_departments FOR TABLE departments WHERE (active IS TRUE);

Create a publication that publishes all changes in all tables:

CREATE PUBLICATION alltables FOR ALL TABLES;

Create a publication that only publishes INSERT operations in one table:

CREATE PUBLICATION insert_only FOR TABLE mydata WITH (publish = insert);

Create a publication that publishes all changes for tables users, departments and all changes for all the tables present in the schema production:

CREATE PUBLICATION production_publication FOR TABLE users, departments, TABLES IN SCHEMA production;

Create a publication that publishes all changes for all the tables present in the schemas marketing and sales:

CREATE PUBLICATION sales_publication FOR TABLES IN SCHEMA marketing, sales;

Create a publication that publishes all changes for table users, but replicates only columns user_id and firstname:

CREATE PUBLICATION users_filtered FOR TABLE users (user_id, firstname);

COMPATIBILITY

CREATE PUBLICATION is a PostgreSQL extension.

SEE ALSO

ALTER PUBLICATION (ALTER_PUBLICATION(7)), DROP PUBLICATION (DROP_PUBLICATION(7)), CREATE SUBSCRIPTION (CREATE_SUBSCRIPTION(7)), ALTER SUBSCRIPTION (ALTER_SUBSCRIPTION(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

184 - Linux cli command unix

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command unix and provides detailed information about the command unix, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the unix.

NAME 🖥️ unix 🖥️

sockets for local interprocess communication

SYNOPSIS

#include <sys/socket.h>
#include <sys/un.h>
unix_socket = socket(AF_UNIX, type, 0);
error = socketpair(AF_UNIX, type, 0, int *sv);

DESCRIPTION

The AF_UNIX (also known as AF_LOCAL) socket family is used to communicate between processes on the same machine efficiently. Traditionally, UNIX domain sockets can be either unnamed, or bound to a filesystem pathname (marked as being of type socket). Linux also supports an abstract namespace which is independent of the filesystem.

Valid socket types in the UNIX domain are: SOCK_STREAM, for a stream-oriented socket; SOCK_DGRAM, for a datagram-oriented socket that preserves message boundaries (as on most UNIX implementations, UNIX domain datagram sockets are always reliable and don’t reorder datagrams); and (since Linux 2.6.4) SOCK_SEQPACKET, for a sequenced-packet socket that is connection-oriented, preserves message boundaries, and delivers messages in the order that they were sent.

UNIX domain sockets support passing file descriptors or process credentials to other processes using ancillary data.

Address format

A UNIX domain socket address is represented in the following structure:

struct sockaddr_un {
    sa_family_t sun_family;               /* AF_UNIX */
    char        sun_path[108];            /* Pathname */
};

The sun_family field always contains AF_UNIX. On Linux, sun_path is 108 bytes in size; see also BUGS, below.

Various system calls (for example, bind(2), connect(2), and sendto(2)) take a sockaddr_un argument as input. Some other system calls (for example, getsockname(2), getpeername(2), recvfrom(2), and accept(2)) return an argument of this type.

Three types of address are distinguished in the sockaddr_un structure:

pathname
a UNIX domain socket can be bound to a null-terminated filesystem pathname using bind(2). When the address of a pathname socket is returned (by one of the system calls noted above), its length is

offsetof(struct sockaddr_un, sun_path) + strlen(sun_path) + 1

and sun_path contains the null-terminated pathname. (On Linux, the above offsetof() expression equates to the same value as sizeof(sa_family_t), but some other implementations include other fields before sun_path, so the offsetof() expression more portably describes the size of the address structure.)

For further details of pathname sockets, see below.

unnamed
A stream socket that has not been bound to a pathname using bind(2) has no name. Likewise, the two sockets created by socketpair(2) are unnamed. When the address of an unnamed socket is returned, its length is sizeof(sa_family_t), and sun_path should not be inspected.

abstract
an abstract socket address is distinguished (from a pathname socket) by the fact that sun_path[0] is a null byte (‘�’). The socket’s address in this namespace is given by the additional bytes in sun_path that are covered by the specified length of the address structure. (Null bytes in the name have no special significance.) The name has no connection with filesystem pathnames. When the address of an abstract socket is returned, the returned addrlen is greater than sizeof(sa_family_t) (i.e., greater than 2), and the name of the socket is contained in the first (addrlen - sizeof(sa_family_t)) bytes of sun_path.

Pathname sockets

When binding a socket to a pathname, a few rules should be observed for maximum portability and ease of coding:

  • The pathname in sun_path should be null-terminated.

  • The length of the pathname, including the terminating null byte, should not exceed the size of sun_path.

  • The addrlen argument that describes the enclosing sockaddr_un structure should have a value of at least:

    offsetof(struct sockaddr_un, sun_path)+strlen(addr.sun_path)+1

    or, more simply, addrlen can be specified as sizeof(struct sockaddr_un).

There is some variation in how implementations handle UNIX domain socket addresses that do not follow the above rules. For example, some (but not all) implementations append a null terminator if none is present in the supplied sun_path.

When coding portable applications, keep in mind that some implementations have sun_path as short as 92 bytes.

Various system calls (accept(2), recvfrom(2), getsockname(2), getpeername(2)) return socket address structures. When applied to UNIX domain sockets, the value-result addrlen argument supplied to the call should be initialized as above. Upon return, the argument is set to indicate the actual size of the address structure. The caller should check the value returned in this argument: if the output value exceeds the input value, then there is no guarantee that a null terminator is present in sun_path. (See BUGS.)

Pathname socket ownership and permissions

In the Linux implementation, pathname sockets honor the permissions of the directory they are in. Creation of a new socket fails if the process does not have write and search (execute) permission on the directory in which the socket is created.

On Linux, connecting to a stream socket object requires write permission on that socket; sending a datagram to a datagram socket likewise requires write permission on that socket. POSIX does not make any statement about the effect of the permissions on a socket file, and on some systems (e.g., older BSDs), the socket permissions are ignored. Portable programs should not rely on this feature for security.

When creating a new socket, the owner and group of the socket file are set according to the usual rules. The socket file has all permissions enabled, other than those that are turned off by the process umask(2).

The owner, group, and permissions of a pathname socket can be changed (using chown(2) and chmod(2)).

Abstract sockets

Socket permissions have no meaning for abstract sockets: the process umask(2) has no effect when binding an abstract socket, and changing the ownership and permissions of the object (via fchown(2) and fchmod(2)) has no effect on the accessibility of the socket.

Abstract sockets automatically disappear when all open references to the socket are closed.

The abstract socket namespace is a nonportable Linux extension.

Socket options

For historical reasons, these socket options are specified with a SOL_SOCKET type even though they are AF_UNIX specific. They can be set with setsockopt(2) and read with getsockopt(2) by specifying SOL_SOCKET as the socket family.

SO_PASSCRED
Enabling this socket option causes receipt of the credentials of the sending process in an SCM_CREDENTIALS ancillary message in each subsequently received message. The returned credentials are those specified by the sender using SCM_CREDENTIALS, or a default that includes the sender’s PID, real user ID, and real group ID, if the sender did not specify SCM_CREDENTIALS ancillary data.

When this option is set and the socket is not yet connected, a unique name in the abstract namespace will be generated automatically.

The value given as an argument to setsockopt(2) and returned as the result of getsockopt(2) is an integer boolean flag.

SO_PASSSEC
Enables receiving of the SELinux security label of the peer socket in an ancillary message of type SCM_SECURITY (see below).

The value given as an argument to setsockopt(2) and returned as the result of getsockopt(2) is an integer boolean flag.

The SO_PASSSEC option is supported for UNIX domain datagram sockets since Linux 2.6.18; support for UNIX domain stream sockets was added in Linux 4.2.

SO_PEEK_OFF
See socket(7).

SO_PEERCRED
This read-only socket option returns the credentials of the peer process connected to this socket. The returned credentials are those that were in effect at the time of the call to connect(2), listen(2), or socketpair(2).

The argument to getsockopt(2) is a pointer to a ucred structure; define the _GNU_SOURCE feature test macro to obtain the definition of that structure from <sys/socket.h>.

The use of this option is possible only for connected AF_UNIX stream sockets and for AF_UNIX stream and datagram socket pairs created using socketpair(2).

SO_PEERSEC
This read-only socket option returns the security context of the peer socket connected to this socket. By default, this will be the same as the security context of the process that created the peer socket unless overridden by the policy or by a process with the required permissions.

The argument to getsockopt(2) is a pointer to a buffer of the specified length in bytes into which the security context string will be copied. If the buffer length is less than the length of the security context string, then getsockopt(2) returns -1, sets errno to ERANGE, and returns the required length via optlen. The caller should allocate at least NAME_MAX bytes for the buffer initially, although this is not guaranteed to be sufficient. Resizing the buffer to the returned length and retrying may be necessary.

The security context string may include a terminating null character in the returned length, but is not guaranteed to do so: a security context “foo” might be represented as either {‘f’,‘o’,‘o’} of length 3 or {‘f’,‘o’,‘o’,‘�’} of length 4, which are considered to be interchangeable. The string is printable, does not contain non-terminating null characters, and is in an unspecified encoding (in particular, it is not guaranteed to be ASCII or UTF-8).

The use of this option for sockets in the AF_UNIX address family is supported since Linux 2.6.2 for connected stream sockets, and since Linux 4.18 also for stream and datagram socket pairs created using socketpair(2).

Autobind feature

If a bind(2) call specifies addrlen as sizeof(sa_family_t), or the SO_PASSCRED socket option was specified for a socket that was not explicitly bound to an address, then the socket is autobound to an abstract address. The address consists of a null byte followed by 5 bytes in the character set [0-9a-f]. Thus, there is a limit of 2^20 autobind addresses. (From Linux 2.1.15, when the autobind feature was added, 8 bytes were used, and the limit was thus 2^32 autobind addresses. The change to 5 bytes came in Linux 2.3.15.)

Sockets API

The following paragraphs describe domain-specific details and unsupported features of the sockets API for UNIX domain sockets on Linux.

UNIX domain sockets do not support the transmission of out-of-band data (the MSG_OOB flag for send(2) and recv(2)).

The send(2) MSG_MORE flag is not supported by UNIX domain sockets.

Before Linux 3.4, the use of MSG_TRUNC in the flags argument of recv(2) was not supported by UNIX domain sockets.

The SO_SNDBUF socket option does have an effect for UNIX domain sockets, but the SO_RCVBUF option does not. For datagram sockets, the SO_SNDBUF value imposes an upper limit on the size of outgoing datagrams. This limit is calculated as the doubled (see socket(7)) option value less 32 bytes used for overhead.

Ancillary messages

Ancillary data is sent and received using sendmsg(2) and recvmsg(2). For historical reasons, the ancillary message types listed below are specified with a SOL_SOCKET type even though they are AF_UNIX specific. To send them, set the cmsg_level field of the struct cmsghdr to SOL_SOCKET and the cmsg_type field to the type. For more information, see cmsg(3).

SCM_RIGHTS
Send or receive a set of open file descriptors from another process. The data portion contains an integer array of the file descriptors.

Commonly, this operation is referred to as “passing a file descriptor” to another process. However, more accurately, what is being passed is a reference to an open file description (see open(2)), and in the receiving process it is likely that a different file descriptor number will be used. Semantically, this operation is equivalent to duplicating (dup(2)) a file descriptor into the file descriptor table of another process.

If the buffer used to receive the ancillary data containing file descriptors is too small (or is absent), then the ancillary data is truncated (or discarded) and the excess file descriptors are automatically closed in the receiving process.

If the number of file descriptors received in the ancillary data would cause the process to exceed its RLIMIT_NOFILE resource limit (see getrlimit(2)), the excess file descriptors are automatically closed in the receiving process.

The kernel constant SCM_MAX_FD defines a limit on the number of file descriptors in the array. Attempting to send an array larger than this limit causes sendmsg(2) to fail with the error EINVAL. SCM_MAX_FD has the value 253 (or 255 before Linux 2.6.38).

SCM_CREDENTIALS
Send or receive UNIX credentials. This can be used for authentication. The credentials are passed as a struct ucred ancillary message. This structure is defined in <sys/socket.h> as follows:

struct ucred {
    pid_t pid;    /* Process ID of the sending process */
    uid_t uid;    /* User ID of the sending process */
    gid_t gid;    /* Group ID of the sending process */
};

Since glibc 2.8, the _GNU_SOURCE feature test macro must be defined (before including any header files) in order to obtain the definition of this structure.

The credentials which the sender specifies are checked by the kernel. A privileged process is allowed to specify values that do not match its own. The sender must specify its own process ID (unless it has the capability CAP_SYS_ADMIN, in which case the PID of any existing process may be specified), its real user ID, effective user ID, or saved set-user-ID (unless it has CAP_SETUID), and its real group ID, effective group ID, or saved set-group-ID (unless it has CAP_SETGID).

To receive a struct ucred message, the SO_PASSCRED option must be enabled on the socket.

SCM_SECURITY
Receive the SELinux security context (the security label) of the peer socket. The received ancillary data is a null-terminated string containing the security context. The receiver should allocate at least NAME_MAX bytes in the data portion of the ancillary message for this data.

To receive the security context, the SO_PASSSEC option must be enabled on the socket (see above).

When sending ancillary data with sendmsg(2), only one item of each of the above types may be included in the sent message.

At least one byte of real data should be sent when sending ancillary data. On Linux, this is required to successfully send ancillary data over a UNIX domain stream socket. When sending ancillary data over a UNIX domain datagram socket, it is not necessary on Linux to send any accompanying real data. However, portable applications should also include at least one byte of real data when sending ancillary data over a datagram socket.

When receiving from a stream socket, ancillary data forms a kind of barrier for the received data. For example, suppose that the sender transmits as follows:

  1. sendmsg(2) of four bytes, with no ancillary data.

  2. sendmsg(2) of one byte, with ancillary data.

  3. sendmsg(2) of four bytes, with no ancillary data.

Suppose that the receiver now performs recvmsg(2) calls each with a buffer size of 20 bytes. The first call will receive five bytes of data, along with the ancillary data sent by the second sendmsg(2) call. The next call will receive the remaining four bytes of data.

If the space allocated for receiving incoming ancillary data is too small then the ancillary data is truncated to the number of headers that will fit in the supplied buffer (or, in the case of an SCM_RIGHTS file descriptor list, the list of file descriptors may be truncated). If no buffer is provided for incoming ancillary data (i.e., the msg_control field of the msghdr structure supplied to recvmsg(2) is NULL), then the incoming ancillary data is discarded. In both of these cases, the MSG_CTRUNC flag will be set in the msg.msg_flags value returned by recvmsg(2).

Ioctls

The following ioctl(2) calls return information in value. The correct syntax is:

int value; error = ioctl(unix_socket, ioctl_type, &value);

ioctl_type can be:

SIOCINQ
For SOCK_STREAM sockets, this call returns the number of unread bytes in the receive buffer. The socket must not be in LISTEN state, otherwise an error (EINVAL) is returned. SIOCINQ is defined in <linux/sockios.h>. Alternatively, you can use the synonymous FIONREAD, defined in <sys/ioctl.h>. For SOCK_DGRAM sockets, the returned value is the same as for Internet domain datagram sockets; see udp(7).

ERRORS

EADDRINUSE
The specified local address is already in use or the filesystem socket object already exists.

EBADF
This error can occur for sendmsg(2) when sending a file descriptor as ancillary data over a UNIX domain socket (see the description of SCM_RIGHTS, above), and indicates that the file descriptor number that is being sent is not valid (e.g., it is not an open file descriptor).

ECONNREFUSED
The remote address specified by connect(2) was not a listening socket. This error can also occur if the target pathname is not a socket.

ECONNRESET
Remote socket was unexpectedly closed.

EFAULT
User memory address was not valid.

EINVAL
Invalid argument passed. A common cause is that the value AF_UNIX was not specified in the sun_type field of passed addresses, or the socket was in an invalid state for the applied operation.

EISCONN
connect(2) called on an already connected socket or a target address was specified on a connected socket.

ENFILE
The system-wide limit on the total number of open files has been reached.

ENOENT
The pathname in the remote address specified to connect(2) did not exist.

ENOMEM
Out of memory.

ENOTCONN
Socket operation needs a target address, but the socket is not connected.

EOPNOTSUPP
Stream operation called on non-stream oriented socket or tried to use the out-of-band data option.

EPERM
The sender passed invalid credentials in the struct ucred.

EPIPE
Remote socket was closed on a stream socket. If enabled, a SIGPIPE is sent as well. This can be avoided by passing the MSG_NOSIGNAL flag to send(2) or sendmsg(2).

EPROTONOSUPPORT
Passed protocol is not AF_UNIX.

EPROTOTYPE
Remote socket does not match the local socket type (SOCK_DGRAM versus SOCK_STREAM).

ESOCKTNOSUPPORT
Unknown socket type.

ESRCH
While sending an ancillary message containing credentials (SCM_CREDENTIALS), the caller specified a PID that does not match any existing process.

ETOOMANYREFS
This error can occur for sendmsg(2) when sending a file descriptor as ancillary data over a UNIX domain socket (see the description of SCM_RIGHTS, above). It occurs if the number of “in-flight” file descriptors exceeds the RLIMIT_NOFILE resource limit and the caller does not have the CAP_SYS_RESOURCE capability. An in-flight file descriptor is one that has been sent using sendmsg(2) but has not yet been accepted in the recipient process using recvmsg(2).

This error is diagnosed since mainline Linux 4.5 (and in some earlier kernel versions where the fix has been backported). In earlier kernel versions, it was possible to place an unlimited number of file descriptors in flight, by sending each file descriptor with sendmsg(2) and then closing the file descriptor so that it was not accounted against the RLIMIT_NOFILE resource limit.

Other errors can be generated by the generic socket layer or by the filesystem while generating a filesystem socket object. See the appropriate manual pages for more information.

VERSIONS

SCM_CREDENTIALS and the abstract namespace were introduced with Linux 2.2 and should not be used in portable programs. (Some BSD-derived systems also support credential passing, but the implementation details differ.)

NOTES

Binding to a socket with a filename creates a socket in the filesystem that must be deleted by the caller when it is no longer needed (using unlink(2)). The usual UNIX close-behind semantics apply; the socket can be unlinked at any time and will be finally removed from the filesystem when the last reference to it is closed.

To pass file descriptors or credentials over a SOCK_STREAM socket, you must send or receive at least one byte of nonancillary data in the same sendmsg(2) or recvmsg(2) call.

UNIX domain stream sockets do not support the notion of out-of-band data.

BUGS

When binding a socket to an address, Linux is one of the implementations that append a null terminator if none is supplied in sun_path. In most cases this is unproblematic: when the socket address is retrieved, it will be one byte longer than that supplied when the socket was bound. However, there is one case where confusing behavior can result: if 108 non-null bytes are supplied when a socket is bound, then the addition of the null terminator takes the length of the pathname beyond sizeof(sun_path). Consequently, when retrieving the socket address (for example, via accept(2)), if the input addrlen argument for the retrieving call is specified as sizeof(struct sockaddr_un), then the returned address structure won’t have a null terminator in sun_path.

In addition, some implementations don’t require a null terminator when binding a socket (the addrlen argument is used to determine the length of sun_path) and when the socket address is retrieved on these implementations, there is no null terminator in sun_path.

Applications that retrieve socket addresses can (portably) code to handle the possibility that there is no null terminator in sun_path by respecting the fact that the number of valid bytes in the pathname is:

strnlen(addr.sun_path, addrlen - offsetof(sockaddr_un, sun_path))

Alternatively, an application can retrieve the socket address by allocating a buffer of size sizeof(struct sockaddr_un)+1 that is zeroed out before the retrieval. The retrieving call can specify addrlen as sizeof(struct sockaddr_un), and the extra zero byte ensures that there will be a null terminator for the string returned in sun_path:

void *addrp;
addrlen = sizeof(struct sockaddr_un);
addrp = malloc(addrlen + 1);
if (addrp == NULL)
    /* Handle error */ ;
memset(addrp, 0, addrlen + 1);
if (getsockname(sfd, (struct sockaddr *) addrp, &addrlen)) == -1)
    /* handle error */ ;
printf("sun_path = %s

“, ((struct sockaddr_un *) addrp)->sun_path);

This sort of messiness can be avoided if it is guaranteed that the applications that create pathname sockets follow the rules outlined above under Pathname sockets.

EXAMPLES

The following code demonstrates the use of sequenced-packet sockets for local interprocess communication. It consists of two programs. The server program waits for a connection from the client program. The client sends each of its command-line arguments in separate messages. The server treats the incoming messages as integers and adds them up. The client sends the command string “END”. The server sends back a message containing the sum of the client’s integers. The client prints the sum and exits. The server waits for the next client to connect. To stop the server, the client is called with the command-line argument “DOWN”.

The following output was recorded while running the server in the background and repeatedly executing the client. Execution of the server program ends when it receives the “DOWN” command.

Example output

$ ./server &
[1] 25887
$ ./client 3 4
Result = 7
$ ./client 11 -5
Result = 6
$ ./client DOWN
Result = 0
[1]+  Done                    ./server
$

Program source

/*
 * File connection.h
 */
#ifndef CONNECTION_H
#define CONNECTION_H
#define SOCKET_NAME "/tmp/9Lq7BNBnBycd6nxy.socket"
#define BUFFER_SIZE 12
#endif  // include guard

/*
 * File server.c
 */
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <sys/un.h>
#include <unistd.h>
#include "connection.h"
int
main(void)
{
    int                 down_flag = 0;
    int                 ret;
    int                 connection_socket;
    int                 data_socket;
    int                 result;
    ssize_t             r, w;
    struct sockaddr_un  name;
    char                buffer[BUFFER_SIZE];
    /* Create local socket. */
    connection_socket = socket(AF_UNIX, SOCK_SEQPACKET, 0);
    if (connection_socket == -1) {
        perror("socket");
        exit(EXIT_FAILURE);
    }
    /*
     * For portability clear the whole structure, since some
     * implementations have additional (nonstandard) fields in
     * the structure.
     */
    memset(&name, 0, sizeof(name));
    /* Bind socket to socket name. */
    name.sun_family = AF_UNIX;
    strncpy(name.sun_path, SOCKET_NAME, sizeof(name.sun_path) - 1);
    ret = bind(connection_socket, (const struct sockaddr *) &name,
               sizeof(name));
    if (ret == -1) {
        perror("bind");
        exit(EXIT_FAILURE);
    }
    /*
     * Prepare for accepting connections. The backlog size is set
     * to 20. So while one request is being processed other requests
     * can be waiting.
     */
    ret = listen(connection_socket, 20);
    if (ret == -1) {
        perror("listen");
        exit(EXIT_FAILURE);
    }
    /* This is the main loop for handling connections. */
    for (;;) {
        /* Wait for incoming connection. */
        data_socket = accept(connection_socket, NULL, NULL);
        if (data_socket == -1) {
            perror("accept");
            exit(EXIT_FAILURE);
        }
        result = 0;
        for (;;) {
            /* Wait for next data packet. */
            r = read(data_socket, buffer, sizeof(buffer));
            if (r == -1) {
                perror("read");
                exit(EXIT_FAILURE);
            }
            /* Ensure buffer is 0-terminated. */
            buffer[sizeof(buffer) - 1] = 0;
            /* Handle commands. */
            if (!strncmp(buffer, "DOWN", sizeof(buffer))) {
                down_flag = 1;
                continue;
            }
            if (!strncmp(buffer, "END", sizeof(buffer))) {
                break;
            }
            if (down_flag) {
                continue;
            }
            /* Add received summand. */
            result += atoi(buffer);
        }
        /* Send result. */
        sprintf(buffer, "%d", result);
        w = write(data_socket, buffer, sizeof(buffer));
        if (w == -1) {
            perror("write");
            exit(EXIT_FAILURE);
        }
        /* Close socket. */
        close(data_socket);
        /* Quit on DOWN command. */
        if (down_flag) {
            break;
        }
    }
    close(connection_socket);
    /* Unlink the socket. */
    unlink(SOCKET_NAME);
    exit(EXIT_SUCCESS);
}

/*
 * File client.c
 */
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <sys/un.h>
#include <unistd.h>
#include "connection.h"
int
main(int argc, char *argv[])
{
    int                 ret;
    int                 data_socket;
    ssize_t             r, w;
    struct sockaddr_un  addr;
    char                buffer[BUFFER_SIZE];
    /* Create local socket. */
    data_socket = socket(AF_UNIX, SOCK_SEQPACKET, 0);
    if (data_socket == -1) {
        perror("socket");
        exit(EXIT_FAILURE);
    }
    /*
     * For portability clear the whole structure, since some
     * implementations have additional (nonstandard) fields in
     * the structure.
     */
    memset(&addr, 0, sizeof(addr));
    /* Connect socket to socket address. */
    addr.sun_family = AF_UNIX;
    strncpy(addr.sun_path, SOCKET_NAME, sizeof(addr.sun_path) - 1);
    ret = connect(data_socket, (const struct sockaddr *) &addr,
                   sizeof(addr));
    if (ret == -1) {
        fprintf(stderr, "The server is down.

“); exit(EXIT_FAILURE); } /* Send arguments. / for (int i = 1; i < argc; ++i) { w = write(data_socket, argv[i], strlen(argv[i]) + 1); if (w == -1) { perror(“write”); break; } } / Request result. / strcpy(buffer, “END”); w = write(data_socket, buffer, strlen(buffer) + 1); if (w == -1) { perror(“write”); exit(EXIT_FAILURE); } / Receive result. / r = read(data_socket, buffer, sizeof(buffer)); if (r == -1) { perror(“read”); exit(EXIT_FAILURE); } / Ensure buffer is 0-terminated. / buffer[sizeof(buffer) - 1] = 0; printf(“Result = %s “, buffer); / Close socket. */ close(data_socket); exit(EXIT_SUCCESS); }

For examples of the use of SCM_RIGHTS, see cmsg(3) and seccomp_unotify(2).

SEE ALSO

recvmsg(2), sendmsg(2), socket(2), socketpair(2), cmsg(3), capabilities(7), credentials(7), socket(7), udp(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

185 - Linux cli command namespaces

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command namespaces and provides detailed information about the command namespaces, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the namespaces.

NAME 🖥️ namespaces 🖥️

overview of Linux namespaces

DESCRIPTION

A namespace wraps a global system resource in an abstraction that makes it appear to the processes within the namespace that they have their own isolated instance of the global resource. Changes to the global resource are visible to other processes that are members of the namespace, but are invisible to other processes. One use of namespaces is to implement containers.

This page provides pointers to information on the various namespace types, describes the associated /proc files, and summarizes the APIs for working with namespaces.

Namespace types

The following table shows the namespace types available on Linux. The second column of the table shows the flag value that is used to specify the namespace type in various APIs. The third column identifies the manual page that provides details on the namespace type. The last column is a summary of the resources that are isolated by the namespace type.

NamespaceFlagPageIsolates
CgroupCLONE_NEWCGROUPcgroup_namespaces(7)Cgroup root directory
IPCCLONE_NEWIPCipc_namespaces(7)System V IPC, POSIX message queues
NetworkCLONE_NEWNETnetwork_namespaces(7)Network devices, stacks, ports, etc.
MountCLONE_NEWNSmount_namespaces(7)Mount points
PIDCLONE_NEWPIDpid_namespaces(7)Process IDs
TimeCLONE_NEWTIMEtime_namespaces(7)Boot and monotonic clocks
UserCLONE_NEWUSERuser_namespaces(7)User and group IDs
UTSCLONE_NEWUTSuts_namespaces(7)Hostname and NIS domain name

The namespaces API

As well as various /proc files described below, the namespaces API includes the following system calls:

clone(2)
The clone(2) system call creates a new process. If the flags argument of the call specifies one or more of the CLONE_NEW* flags listed above, then new namespaces are created for each flag, and the child process is made a member of those namespaces. (This system call also implements a number of features unrelated to namespaces.)

setns(2)
The setns(2) system call allows the calling process to join an existing namespace. The namespace to join is specified via a file descriptor that refers to one of the /proc/pid/ns files described below.

unshare(2)
The unshare(2) system call moves the calling process to a new namespace. If the flags argument of the call specifies one or more of the CLONE_NEW* flags listed above, then new namespaces are created for each flag, and the calling process is made a member of those namespaces. (This system call also implements a number of features unrelated to namespaces.)

ioctl(2)
Various ioctl(2) operations can be used to discover information about namespaces. These operations are described in ioctl_ns(2).

Creation of new namespaces using clone(2) and unshare(2) in most cases requires the CAP_SYS_ADMIN capability, since, in the new namespace, the creator will have the power to change global resources that are visible to other processes that are subsequently created in, or join the namespace. User namespaces are the exception: since Linux 3.8, no privilege is required to create a user namespace.

The /proc/pid/ns/ directory

Each process has a /proc/pid/ns/ subdirectory containing one entry for each namespace that supports being manipulated by setns(2):

$ ls -l /proc/$$/ns | awk '{print $1, $9, $10, $11}'
total 0
lrwxrwxrwx. cgroup -> cgroup:[4026531835]
lrwxrwxrwx. ipc -> ipc:[4026531839]
lrwxrwxrwx. mnt -> mnt:[4026531840]
lrwxrwxrwx. net -> net:[4026531969]
lrwxrwxrwx. pid -> pid:[4026531836]
lrwxrwxrwx. pid_for_children -> pid:[4026531834]
lrwxrwxrwx. time -> time:[4026531834]
lrwxrwxrwx. time_for_children -> time:[4026531834]
lrwxrwxrwx. user -> user:[4026531837]
lrwxrwxrwx. uts -> uts:[4026531838]

Bind mounting (see mount(2)) one of the files in this directory to somewhere else in the filesystem keeps the corresponding namespace of the process specified by pid alive even if all processes currently in the namespace terminate.

Opening one of the files in this directory (or a file that is bind mounted to one of these files) returns a file handle for the corresponding namespace of the process specified by pid. As long as this file descriptor remains open, the namespace will remain alive, even if all processes in the namespace terminate. The file descriptor can be passed to setns(2).

In Linux 3.7 and earlier, these files were visible as hard links. Since Linux 3.8, they appear as symbolic links. If two processes are in the same namespace, then the device IDs and inode numbers of their */proc/pid/ns/*xxx symbolic links will be the same; an application can check this using the stat.st_dev and stat.st_ino fields returned by stat(2). The content of this symbolic link is a string containing the namespace type and inode number as in the following example:

$ readlink /proc/$$/ns/uts
uts:[4026531838]

The symbolic links in this subdirectory are as follows:

/proc/pid/ns/cgroup (since Linux 4.6)
This file is a handle for the cgroup namespace of the process.

/proc/pid/ns/ipc (since Linux 3.0)
This file is a handle for the IPC namespace of the process.

/proc/pid/ns/mnt (since Linux 3.8)
This file is a handle for the mount namespace of the process.

/proc/pid/ns/net (since Linux 3.0)
This file is a handle for the network namespace of the process.

/proc/pid/ns/pid (since Linux 3.8)
This file is a handle for the PID namespace of the process. This handle is permanent for the lifetime of the process (i.e., a process’s PID namespace membership never changes).

/proc/pid/ns/pid_for_children (since Linux 4.12)
This file is a handle for the PID namespace of child processes created by this process. This can change as a consequence of calls to unshare(2) and setns(2) (see pid_namespaces(7)), so the file may differ from /proc/pid/ns/pid. The symbolic link gains a value only after the first child process is created in the namespace. (Beforehand, readlink(2) of the symbolic link will return an empty buffer.)

/proc/pid/ns/time (since Linux 5.6)
This file is a handle for the time namespace of the process.

/proc/pid/ns/time_for_children (since Linux 5.6)
This file is a handle for the time namespace of child processes created by this process. This can change as a consequence of calls to unshare(2) and setns(2) (see time_namespaces(7)), so the file may differ from /proc/pid/ns/time.

/proc/pid/ns/user (since Linux 3.8)
This file is a handle for the user namespace of the process.

/proc/pid/ns/uts (since Linux 3.0)
This file is a handle for the UTS namespace of the process.

Permission to dereference or read (readlink(2)) these symbolic links is governed by a ptrace access mode PTRACE_MODE_READ_FSCREDS check; see ptrace(2).

The /proc/sys/user directory

The files in the /proc/sys/user directory (which is present since Linux 4.9) expose limits on the number of namespaces of various types that can be created. The files are as follows:

max_cgroup_namespaces
The value in this file defines a per-user limit on the number of cgroup namespaces that may be created in the user namespace.

max_ipc_namespaces
The value in this file defines a per-user limit on the number of ipc namespaces that may be created in the user namespace.

max_mnt_namespaces
The value in this file defines a per-user limit on the number of mount namespaces that may be created in the user namespace.

max_net_namespaces
The value in this file defines a per-user limit on the number of network namespaces that may be created in the user namespace.

max_pid_namespaces
The value in this file defines a per-user limit on the number of PID namespaces that may be created in the user namespace.

max_time_namespaces (since Linux 5.7)
The value in this file defines a per-user limit on the number of time namespaces that may be created in the user namespace.

max_user_namespaces
The value in this file defines a per-user limit on the number of user namespaces that may be created in the user namespace.

max_uts_namespaces
The value in this file defines a per-user limit on the number of uts namespaces that may be created in the user namespace.

Note the following details about these files:

  • The values in these files are modifiable by privileged processes.

  • The values exposed by these files are the limits for the user namespace in which the opening process resides.

  • The limits are per-user. Each user in the same user namespace can create namespaces up to the defined limit.

  • The limits apply to all users, including UID 0.

  • These limits apply in addition to any other per-namespace limits (such as those for PID and user namespaces) that may be enforced.

  • Upon encountering these limits, clone(2) and unshare(2) fail with the error ENOSPC.

  • For the initial user namespace, the default value in each of these files is half the limit on the number of threads that may be created (/proc/sys/kernel/threads-max). In all descendant user namespaces, the default value in each file is MAXINT.

  • When a namespace is created, the object is also accounted against ancestor namespaces. More precisely:

    • Each user namespace has a creator UID.

    • When a namespace is created, it is accounted against the creator UIDs in each of the ancestor user namespaces, and the kernel ensures that the corresponding namespace limit for the creator UID in the ancestor namespace is not exceeded.

    • The aforementioned point ensures that creating a new user namespace cannot be used as a means to escape the limits in force in the current user namespace.

Namespace lifetime

Absent any other factors, a namespace is automatically torn down when the last process in the namespace terminates or leaves the namespace. However, there are a number of other factors that may pin a namespace into existence even though it has no member processes. These factors include the following:

  • An open file descriptor or a bind mount exists for the corresponding /proc/pid/ns/* file.

  • The namespace is hierarchical (i.e., a PID or user namespace), and has a child namespace.

  • It is a user namespace that owns one or more nonuser namespaces.

  • It is a PID namespace, and there is a process that refers to the namespace via a /proc/pid/ns/pid_for_children symbolic link.

  • It is a time namespace, and there is a process that refers to the namespace via a /proc/pid/ns/time_for_children symbolic link.

  • It is an IPC namespace, and a corresponding mount of an mqueue filesystem (see mq_overview(7)) refers to this namespace.

  • It is a PID namespace, and a corresponding mount of a proc(5) filesystem refers to this namespace.

EXAMPLES

See clone(2) and user_namespaces(7).

SEE ALSO

nsenter(1), readlink(1), unshare(1), clone(2), ioctl_ns(2), setns(2), unshare(2), proc(5), capabilities(7), cgroup_namespaces(7), cgroups(7), credentials(7), ipc_namespaces(7), network_namespaces(7), pid_namespaces(7), user_namespaces(7), uts_namespaces(7), lsns(8), switch_root(8)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

186 - Linux cli command EVP_KEYMGMT-X25519ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KEYMGMT-X25519ssl and provides detailed information about the command EVP_KEYMGMT-X25519ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KEYMGMT-X25519ssl.

NAME 🖥️ EVP_KEYMGMT-X25519ssl 🖥️

X25519, EVP_PKEY-X448, EVP_PKEY-ED25519, EVP_PKEY-ED448, EVP_KEYMGMT-X25519, EVP_KEYMGMT-X448, EVP_KEYMGMT-ED25519, EVP_KEYMGMT-ED448 - EVP_PKEY X25519, X448, ED25519 and ED448 keytype and algorithm support

DESCRIPTION

The X25519, X448, ED25519 and ED448 keytypes are implemented in OpenSSL’s default and FIPS providers. These implementations support the associated key, containing the public key pub and the private key priv.

Keygen Parameters

“dhkem-ikm” (OSSL_PKEY_PARAM_DHKEM_IKM) <octet string>
DHKEM requires the generation of a keypair using an input key material (seed). Use this to specify the key material used for generation of the private key. This value should not be reused for other purposes. It should have a length of at least 32 for X25519, and 56 for X448. This is only supported by X25519 and X448.

Use EVP_PKEY_CTX_set_params() after calling EVP_PKEY_keygen_init().

Common X25519, X448, ED25519 and ED448 parameters

In addition to the common parameters that all keytypes should support (see “Common parameters” in provider-keymgmt (7)), the implementation of these keytypes support the following.

“group” (OSSL_PKEY_PARAM_GROUP_NAME) <UTF8 string>
This is only supported by X25519 and X448. The group name must be “x25519” or “x448” respectively for those algorithms. This is only present for consistency with other key exchange algorithms and is typically not needed.

“pub” (OSSL_PKEY_PARAM_PUB_KEY) <octet string>
The public key value.

“priv” (OSSL_PKEY_PARAM_PRIV_KEY) <octet string>
The private key value.

“encoded-pub-key” (OSSL_PKEY_PARAM_ENCODED_PUBLIC_KEY) <octet string>
Used for getting and setting the encoding of a public key for the X25519 and X448 key types. Public keys are expected be encoded in a format as defined by RFC7748.

ED25519 and ED448 parameters

“mandatory-digest” (OSSL_PKEY_PARAM_MANDATORY_DIGEST) <UTF8 string>
The empty string, signifying that no digest may be specified.

CONFORMING TO

RFC 8032

RFC 8410

EXAMPLES

An EVP_PKEY context can be obtained by calling:

EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “X25519”, NULL); EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “X448”, NULL); EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “ED25519”, NULL); EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “ED448”, NULL);

An X25519 key can be generated like this:

pkey = EVP_PKEY_Q_keygen(NULL, NULL, “X25519”);

An X448, ED25519, or ED448 key can be generated likewise.

SEE ALSO

EVP_KEYMGMT (3), EVP_PKEY (3), provider-keymgmt (7), EVP_KEYEXCH-X25519 (7), EVP_KEYEXCH-X448 (7), EVP_SIGNATURE-ED25519 (7), EVP_SIGNATURE-ED448 (7)

COPYRIGHT

Copyright 2020-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

187 - Linux cli command systemd.time

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command systemd.time and provides detailed information about the command systemd.time, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the systemd.time.

NAME 🖥️ systemd.time 🖥️

Time and date specifications

DESCRIPTION

In systemd, timestamps, time spans, and calendar events are displayed and may be specified in closely related syntaxes.

DISPLAYING TIME SPANS

Time spans refer to time durations. On display, systemd will present time spans as a space-separated series of time values each suffixed by a time unit. Example:

2h 30min

All specified time values are meant to be added up. The above hence refers to 150 minutes. Display is locale-independent, only English names for the time units are used.

PARSING TIME SPANS

When parsing, systemd will accept the same time span syntax. Separating spaces may be omitted. The following time units are understood:

·

usec, us, μs

·

msec, ms

·

seconds, second, sec, s

·

minutes, minute, min, m

·

hours, hour, hr, h

·

days, day, d

·

weeks, week, w

·

months, month, M (defined as 30.44 days)

·

years, year, y (defined as 365.25 days)

If no time unit is specified, generally seconds are assumed, but some exceptions exist and are marked as such. In a few cases “ns”, “nsec” is accepted too, where the granularity of the time span permits this. Parsing is generally locale-independent, non-English names for the time units are not accepted.

Examples for valid time span specifications:

2 h 2hours 48hr 1y 12month 55s500ms 300ms20s 5day

One can use the timespan command of systemd-analyze(1) to normalise a textual time span for testing and validation purposes.

Internally, systemd generally operates with microsecond time granularity, while the default time unit in user-configurable time spans is usually seconds (see above). This disparity becomes visible when comparing the same settings in the (high-level) unit file syntax with the matching (more low-level) D-Bus properties (which are what systemctl(1)s show command displays). The former typically are suffixed with “…Sec” to indicate the default unit of seconds, the latter are typically suffixed with “…USec” to indicate the underlying low-level time unit, even if they both encapsulate the very same settings.

DISPLAYING TIMESTAMPS

Timestamps refer to specific, unique points in time. On display, systemd will format these in the local timezone as follows:

Fri 2012-11-23 23:02:15 CET

The weekday is printed in the abbreviated English language form. The formatting is locale-independent.

In some cases timestamps are shown in the UTC timezone instead of the local timezone, which is indicated via the “UTC” timezone specifier in the output.

In some cases timestamps are shown with microsecond granularity. In this case the sub-second remainder is separated by a full stop from the seconds component.

PARSING TIMESTAMPS

When parsing, systemd will accept a similar syntax, but some fields can be omitted, and the space between the date and time can be replaced with a “T” (à la the RFC 3339[1] profile of ISO 8601); thus, in CET, the following are all identical: “Fri 2012-11-23 23:02:15 CET”, “Fri 2012-11-23T23:02:15”, “2012-11-23T23:02:15 CET”, “2012-11-23 23:02:15”.

The timezone defaults to the current timezone if not specified explicitly. It may be given after a space, like above, in which case it can be: “UTC”, an entry in the installed IANA timezone database (“CET”, “Asia/Tokyo”, &c.; complete list obtainable with “timedatectl list-timezones” (see timedatectl(1))), or “±05”, “±0530”, “±05:30”, “Z”.

It may also be affixed directly to the timestamp, in which case it must correspond to one of the formats defined in the RFC 3339[1] profile of ISO 8601: “±05:30” or “Z”. Thus, the following are also identical to the above: “2012-11-23T23:02:15+01:00”, “2012-11-23 22:02:15Z”.

A timestamp can start with a field containing a weekday, which can be in an abbreviated (“Wed”) or non-abbreviated (“Wednesday”) English language form (case does not matter), regardless of the locale. However, if a weekday is specified and doesnt match the date, the timestamp is rejected.

If the date is omitted, it defaults to today. If the time is omitted, it defaults to 00:00:00. Fractional seconds can be specified down to 1µs precision. The seconds field can also be omitted, defaulting to 0.

There are special tokens that can be used in place of timestamps: “now” may be used to refer to the current time (or of the invocation of the command that is currently executed). “today”, “yesterday”, and “tomorrow” refer to 00:00:00 of the current day, the day before, or the next day, respectively.

Relative times are also accepted: a time span (see above) prefixed with “+” is evaluated to the current time plus the specified time span. Correspondingly, a time span that is prefixed with “-” is evaluated to the current time minus the specified time span. Instead of prefixing the time span with “+” or “-”, it may also be suffixed with a space and the word “left” or “ago”.

Finally, an integer prefixed with “@” is evaluated relative to the UNIX epoch – 1970-01-01 00:00:00 UTC.

Examples for valid timestamps and their normalized form (assuming the current time was 2012-11-23 18:15:22 and the timezone was UTC+8, for example “TZ=:Asia/Shanghai”):

Fri 2012-11-23 11:12:13 → Fri 2012-11-23 11:12:13 2012-11-23 11:12:13 → Fri 2012-11-23 11:12:13 2012-11-23 11:12:13 UTC → Fri 2012-11-23 19:12:13 2012-11-23T11:12:13Z → Fri 2012-11-23 19:12:13 2012-11-23T11:12+02:00 → Fri 2012-11-23 17:12:00 2012-11-23 → Fri 2012-11-23 00:00:00 12-11-23 → Fri 2012-11-23 00:00:00 11:12:13 → Fri 2012-11-23 11:12:13 11:12 → Fri 2012-11-23 11:12:00 now → Fri 2012-11-23 18:15:22 today → Fri 2012-11-23 00:00:00 today UTC → Fri 2012-11-23 16:00:00 yesterday → Fri 2012-11-22 00:00:00 tomorrow → Fri 2012-11-24 00:00:00 tomorrow Pacific/Auckland → Thu 2012-11-23 19:00:00 +3h30min → Fri 2012-11-23 21:45:22 -5s → Fri 2012-11-23 18:15:17 11min ago → Fri 2012-11-23 18:04:22 @1395716396 → Tue 2014-03-25 03:59:56

Note that timestamps displayed by remote systems with a non-matching timezone are usually not parsable locally, as the timezone component is not understood (unless it happens to be “UTC”).

Timestamps may also be specified with microsecond granularity. The sub-second remainder is expected separated by a full stop from the seconds component. Example:

2014-03-25 03:59:56.654563

In some cases, systemd will display a relative timestamp (relative to the current time, or the time of invocation of the command) instead of or in addition to an absolute timestamp as described above. A relative timestamp is formatted as follows:

2 months 5 days ago

Note that a relative timestamp is also accepted where a timestamp is expected (see above).

Use the timestamp command of systemd-analyze(1) to validate and normalize timestamps for testing purposes.

CALENDAR EVENTS

Calendar events may be used to refer to one or more points in time in a single expression. They form a superset of the absolute timestamps explained above:

Thu,Fri 2012-*-1,5 11:12:13

The above refers to 11:12:13 of the first or fifth day of any month of the year 2012, but only if that day is a Thursday or Friday.

The weekday specification is optional. If specified, it should consist of one or more English language weekday names, either in the abbreviated (Wed) or non-abbreviated (Wednesday) form (case does not matter), separated by commas. Specifying two weekdays separated by “..” refers to a range of continuous weekdays. “,” and “..” may be combined freely.

In the date and time specifications, any component may be specified as “*” in which case any value will match. Alternatively, each component can be specified as a list of values separated by commas. Values may be suffixed with “/” and a repetition value, which indicates that the value itself and the value plus all multiples of the repetition value are matched. Two values separated by “..” may be used to indicate a range of values; ranges may also be followed with “/” and a repetition value, in which case the expression matches all times starting with the start value, and continuing with all multiples of the repetition value relative to the start value, ending at the end value the latest.

A date specification may use “” to indicate the last day in a month. For example, “*-0203” means “the third last day in February,” and “Mon *-05~07/1” means “the last Monday in May.”

The seconds component may contain decimal fractions both in the value and the repetition. All fractions are rounded to 6 decimal places.

Either time or date specification may be omitted, in which case *-*-* and 00:00:00 is implied, respectively. If the seconds component is not specified, “:00” is assumed.

Timezone can be specified as the literal string “UTC”, or the local timezone, similar to the supported syntax of timestamps (see above), or the timezone in the IANA timezone database format (also see above).

The following special expressions may be used as shorthands for longer normalized forms:

minutely → *-*-* *:*:00
      hourly → *-*-* *:00:00
       daily → *-*-* 00:00:00
     monthly → *-*-01 00:00:00
      weekly → Mon *-*-* 00:00:00
      yearly → *-01-01 00:00:00
   quarterly → *-01,04,07,10-01 00:00:00
semiannually → *-01,07-01 00:00:00

Examples for valid timestamps and their normalized form:

Sat,Thu,Mon..Wed,Sat..Sun → Mon..Thu,Sat,Sun --* 00:00:00 Mon,Sun 12-- 2,1:23 → Mon,Sun 2012-- 01,02:23:00 Wed *-1 → Wed --01 00:00:00 Wed..Wed,Wed -1 → Wed --01 00:00:00 Wed, 17:48 → Wed -- 17:48:00 Wed..Sat,Tue 12-10-15 1:2:3 → Tue..Sat 2012-10-15 01:02:03 --7 0:0:0 → --07 00:00:00 10-15 → -10-15 00:00:00 monday -12- 17:00 → Mon -12- 17:00:00 Mon,Fri --3,1,2 :30:45 → Mon,Fri --01,02,03 :30:45 12,14,13,12:20,10,30 → -- 12,13,14:10,20,30:00 12..14:10,20,30 → -- 12..14:10,20,30:00 mon,fri -1/2-1,3 :30:45 → Mon,Fri -01/2-01,03 :30:45 03-05 08:05:40 → -03-05 08:05:40 08:05:40 → -- 08:05:40 05:40 → -- 05:40:00 Sat,Sun 12-05 08:05:40 → Sat,Sun -12-05 08:05:40 Sat,Sun 08:05:40 → Sat,Sun -- 08:05:40 2003-03-05 05:40 → 2003-03-05 05:40:00 05:40:23.4200004/3.1700005 → -- 05:40:23.420000/3.170001 2003-02..04-05 → 2003-02..04-05 00:00:00 2003-03-05 05:40 UTC → 2003-03-05 05:40:00 UTC 2003-03-05 → 2003-03-05 00:00:00 03-05 → -03-05 00:00:00 hourly → -- :00:00 daily → -- 00:00:00 daily UTC → -- 00:00:00 UTC monthly → --01 00:00:00 weekly → Mon -- 00:00:00 weekly Pacific/Auckland → Mon -- 00:00:00 Pacific/Auckland yearly → *-01-01 00:00:00 annually → *-01-01 00:00:00 :2/3 → -- *:02/3:00

Calendar events are used by timer units, see systemd.timer(5) for details.

Use the calendar command of systemd-analyze(1) to validate and normalize calendar time specifications for testing purposes. The tool also calculates when a specified calendar event would occur next.

SEE ALSO

systemd(1), journalctl(1), systemd.timer(5), systemd.unit(5), systemd.directives(7), systemd-analyze(1)

NOTES

RFC 3339

https://tools.ietf.org/html/rfc3339

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

188 - Linux cli command hwloc

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command hwloc and provides detailed information about the command hwloc, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the hwloc.

NAME 🖥️ hwloc 🖥️

General information about hwloc (“hardware locality”).

DESCRIPTION

hwloc provides command line tools and a C API to obtain the hierarchical map of key computing elements, such as: NUMA memory nodes, shared caches, processor packages, processor cores, and processor “threads”. hwloc also gathers various attributes such as cache and memory information, and is portable across a variety of different operating systems and platforms.

Definitions

hwloc has some specific definitions for terms that are used in this man page and other hwloc documentation.

hwloc CPU set:
A set of processors included in an hwloc object, expressed as a bitmask indexed by the physical numbers of the CPUs (as announced by the OS). The hwloc definition of “CPU set” does not carry any of the same connotations as Linux’s “CPU set” (e.g., process affinity, cgroup, etc.).

hwloc node set:
A set of NUMA memory nodes near an hwloc object, expressed as a bitmask indexed by the physical numbers of the NUMA nodes (as announced by the OS).

Linux CPU set:
See http://www.mjmwired.net/kernel/Documentation/cpusets.txt for a discussion of Linux CPU sets. A super-short-ignoring-many-details description (taken from that page) is:

“Cpusets provide a mechanism for assigning a set of CPUs and Memory Nodes to a set of tasks.”

Linux Cgroup:
See http://www.mjmwired.net/kernel/Documentation/cgroups.txt for a discussion of Linux control groups. A super-short-ignoring-many-details description (taken from that page) is:

“Control Groups provide a mechanism for aggregating/partitioning sets of tasks, and all their future children, into hierarchical groups with specialized behaviour.”

To be clear, hwloc supports all of the above concepts. It is simply worth noting that they are different things.

Location Specification

Locations refer to specific regions within a topology. Before reading the rest of this man page, it may be useful to read lstopo(1) and/or run lstopo on your machine to see the reported topology tree. Seeing and understanding a topology tree will definitely help in understanding the concepts that are discussed below.

Locations can be specified in multiple ways:

Tuples:
Tuples of hwloc “objects” and associated indexes can be specified in the form object:index. hwloc objects represent types of mapped items (e.g., packages, cores, etc.) in a topology tree; indexes are non-negative integers that specify a unique physical object in a topology tree. Both concepts are described in detail, below.

Some filters may be added after the type to further specify which objects are wanted. <type>[subtype=<subtype>] selects objects matching the given type and also its subtype string attribute. For instance NUMA[HBM] selects NUMA nodes of subtype “HBM”. The prefix subtype= may be avoided if there is no ambiguity. NUMA[tier=X] selects NUMA nodes of tier <X> (“MemoryTier” info attribute).

Indexes may also be specified as ranges. x-y enumerates from index x to y. x:y enumerates y objects starting from index x (wrapping around the end of the index range if needed). x- enumerates all objects starting from index x. all, odd, and even are also supported for listing all objects, or only those with odd or even indexes.

Chaining multiple tuples together in the more general form object1:index[.object2:index2[…]] is permissable. While the first tuple’s object may appear anywhere in the topology, the Nth tuple’s object must have a shallower topology depth than the (N+1)th tuple’s object. Put simply: as you move right in a tuple chain, objects must go deeper in the topology tree. When using logical indexes (which is the default), indexes specified in chained tuples are relative to the scope of the parent object. For example, “package:0.core:1” refers to the second core in the first package.

When using OS/physical indexes, the first object matching the given index is used.

PCI and OS devices may also be designed using their identifier. For example, “pci=02:03.1” is the PCI device with bus ID “02:03.1”. “os=eth0” is the network interface whose software name is “eth0”. PCI devices may also be filtered based on their vendor and/or device IDs, for instance “pci[15b3:]:2” for the third Mellanox PCI device (vendor ID 0x15b3). OS devices may also be filtered based on their subtype, for instance “os[gpu]:all” for all GPU OS devices.

Hex:
For tools that manipulate object as sets (e.g. hwloc-calc and hwloc-bind), locations can also be specified as hexidecimal bitmasks prefixed with “0x”. Commas must be used to separate the hex digits into blocks of 8, such as “0xffc0140,0x00020110”. Leading zeros in each block do not need to be specified. For example, “0xffc0140,0x20110” is equivalent to the prior example, and “0x0000000f” is exactly equivalent to “0xf”. Intermediate blocks of 8 digits that are all zeoro can be left empty; “0xff0,,0x13” is equivalent to “0xff0,0x00000000,0x13”. If the location is prefixed with the special string “0xf…f”, then all unspecified bits are set (as if the set were infinite). For example, “0xf…f,0x1” sets both the first bit and all bits starting with the 33rd. The string “0xf…f” – with no other specified values – sets all bits.

“all” and “root” are special locations consisting in the root object in tree. It contains the entire current topology.

Some tools directly operate on these objects (e.g. hwloc-info and hwloc-annotate). They do not support hexadecimal locations because each location may correspond to multiple objects. For instance, there can be exactly one L3 cache per package and NUMA node, which means it’s the same location. If multiple locations are given on the command-line, these tools will operation on each location individually and consecutively.

Some other tools internally manipulate objects as sets (e.g. hwloc-calc and hwloc-bind). They translate each input location into a hexidecimal location. When I/O or Misc objects are used, they are translated into the set of processors (or NUMA nodes) that are close to the given object (because I/O or Misc objects do not contain processors or NUMA nodes).

If multiple locations are specified on the command-line (delimited by whitespace), they are combined (the overall location is wider). If prefixed with “~”, the given location will be cleared instead of added to the current list of locations. If prefixed with “x”, the given location will be and’ed instead of added to the current list. If prefixed with “^”, the given location will be xor’ed.

More complex operations may be performed by using hwloc-calc to compute intermediate values.

hwloc Objects

Objects in tuples can be any of the following strings (listed from “biggest” to “smallest”):

machine
A set of processors and memory.

numanode
A NUMA node; a set of processors around memory which the processors can directly access. If numa[hbm] is used instead of numanode in locations, command-line tools only consider NUMA nodes marked as high-bandwidth memory (subtype “HBM”).

package
Typically a physical package or chip, that goes into a package, it is a grouping of one or more processors.

l1cache … l5cache
A data (or unified) cache.

l1icache … l3icache
An instruction cache.

core
A single, physical processing unit which may still contain multiple logical processors, such as hardware threads.

pu
Short for processor unit (not process!). The smallest physical execution unit that hwloc recognizes. For example, there may be multiple PUs on a core (e.g., hardware threads).

osdev, pcidev, bridge, and misc may also be used to specify special devices although some of them have dedicated identification ways as explained in Location Specification.

Finally, note that an object can be denoted by its numeric “depth” in the topology graph.

hwloc Indexes

Indexes are integer values that uniquely specify a given object of a specific type. Indexes can be expressed either as logical values or physical values. Most hwloc utilities accept logical indexes by default. Passing –physical switches to physical/OS indexes. Both logical and physical indexes are described on this man page.

Logical indexes are relative to the object order in the output from the lstopo command. They always start with 0 and increment by 1 for each successive object.

Physical indexes are how the operating system refers to objects. Note that while physical indexes are non-negative integer values, the hardware and/or operating system may choose arbitrary values – they may not start with 0, and successive objects may not have consecutive values.

For example, if the first few lines of lstopo -p output are the following:

Machine (47GB) NUMANode P#0 (24GB) + Package P#0 + L3 (12MB) L2 (256KB) + L1 (32KB) + Core P#0 + PU P#0 L2 (256KB) + L1 (32KB) + Core P#1 + PU P#0 L2 (256KB) + L1 (32KB) + Core P#2 + PU P#0 L2 (256KB) + L1 (32KB) + Core P#8 + PU P#0 L2 (256KB) + L1 (32KB) + Core P#9 + PU P#0 L2 (256KB) + L1 (32KB) + Core P#10 + PU P#0 NUMANode P#1 (24GB) + Package P#1 + L3 (12MB) L2 (256KB) + L1 (32KB) + Core P#0 + PU P#0 L2 (256KB) + L1 (32KB) + Core P#1 + PU P#0 L2 (256KB) + L1 (32KB) + Core P#2 + PU P#0 L2 (256KB) + L1 (32KB) + Core P#8 + PU P#0 L2 (256KB) + L1 (32KB) + Core P#9 + PU P#0 L2 (256KB) + L1 (32KB) + Core P#10 + PU P#0

In this example, the first core on the second package is logically number 6 (i.e., logically the 7th core, starting from 0). Its physical index is 0, but note that another core also has a physical index of 0. Hence, physical indexes may only be relevant within the scope of their parent (or set of ancestors). In this example, to uniquely identify logical core 6 with physical indexes, you must specify (at a minimum) both a package and a core: package 1, core 0.

Index values, regardless of whether they are logical or physical, can be expressed in several different forms (where X, Y, and N are positive integers):

X
The object with index value X.

X-Y
All the objects with index values >= X and <= Y.

X-
All the objects with index values >= X.

X:N
N objects starting with index X, possibly wrapping around the end of the level.

all
A special index value indicating all valid index values.

odd
A special index value indicating all valid odd index values.

even
A special index value indicating all valid even index values.

REMEMBER: hwloc’s command line tools accept logical indexes for location values by default. Use –physical and –logical to switch from one mode to another.

SEE ALSO

hwloc’s command line tool documentation: lstopo(1), hwloc-bind(1), hwloc-calc(1), hwloc-distrib(1), hwloc-ps(1).

hwloc has many C API functions, each of which have their own man page. Some top-level man pages are also provided, grouping similar functions together. A few good places to start might include: hwlocality_objects(3), hwlocality_types(3), hwlocality_creation(3), hwlocality_cpuset(3), hwlocality_information(3), and hwlocality_binding(3).

For a listing of all available hwloc man pages, look at all “hwloc*” files in the man1 and man3 directories.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

189 - Linux cli command EVP_KDF-SSssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KDF-SSssl and provides detailed information about the command EVP_KDF-SSssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KDF-SSssl.

NAME 🖥️ EVP_KDF-SSssl 🖥️

SS - The Single Step / One Step EVP_KDF implementation

DESCRIPTION

The EVP_KDF-SS algorithm implements the Single Step key derivation function (SSKDF). SSKDF derives a key using input such as a shared secret key (that was generated during the execution of a key establishment scheme) and fixedinfo. SSKDF is also informally referred to as ‘Concat KDF’.

Auxiliary function

The implementation uses a selectable auxiliary function H, which can be one of:

H(x) = hash(x, digest=md)

H(x) = HMAC_hash(x, key=salt, digest=md)

H(x) = KMACxxx(x, key=salt, custom=“KDF”, outlen=mac_size)

Both the HMAC and KMAC implementations set the key using the ‘salt’ value. The hash and HMAC also require the digest to be set.

Identity

“SSKDF” is the name for this implementation; it can be used with the EVP_KDF_fetch() function.

Supported parameters

The supported parameters are:

“properties” (OSSL_KDF_PARAM_PROPERTIES) <UTF8 string>

“digest” (OSSL_KDF_PARAM_DIGEST) <UTF8 string>

This parameter is ignored for KMAC.

“mac” (OSSL_KDF_PARAM_MAC) <UTF8 string>

“maclen” (OSSL_KDF_PARAM_MAC_SIZE) <unsigned integer>

“salt” (OSSL_KDF_PARAM_SALT) <octet string>

These parameters work as described in “PARAMETERS” in EVP_KDF (3).

“key” (OSSL_KDF_PARAM_SECRET) <octet string>
This parameter set the shared secret that is used for key derivation.

“info” (OSSL_KDF_PARAM_INFO) <octet string>
This parameter sets an optional value for fixedinfo, also known as otherinfo.

NOTES

A context for SSKDF can be obtained by calling:

EVP_KDF *kdf = EVP_KDF_fetch(NULL, “SSKDF”, NULL); EVP_KDF_CTX *kctx = EVP_KDF_CTX_new(kdf);

The output length of an SSKDF is specified via the keylen parameter to the EVP_KDF_derive (3) function.

EXAMPLES

This example derives 10 bytes using H(x) = SHA-256, with the secret key “secret” and fixedinfo value “label”:

EVP_KDF *kdf; EVP_KDF_CTX *kctx; unsigned char out[10]; OSSL_PARAM params[4], *p = params; kdf = EVP_KDF_fetch(NULL, “SSKDF”, NULL); kctx = EVP_KDF_CTX_new(kdf); EVP_KDF_free(kdf); *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_DIGEST, SN_sha256, strlen(SN_sha256)); *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_KEY, “secret”, (size_t)6); *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_INFO, “label”, (size_t)5); *p = OSSL_PARAM_construct_end(); if (EVP_KDF_derive(kctx, out, sizeof(out), params) <= 0) { error(“EVP_KDF_derive”); } EVP_KDF_CTX_free(kctx);

This example derives 10 bytes using H(x) = HMAC(SHA-256), with the secret key “secret”, fixedinfo value “label” and salt “salt”:

EVP_KDF *kdf; EVP_KDF_CTX *kctx; unsigned char out[10]; OSSL_PARAM params[6], *p = params; kdf = EVP_KDF_fetch(NULL, “SSKDF”, NULL); kctx = EVP_KDF_CTX_new(kdf); EVP_KDF_free(kdf); *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_MAC, SN_hmac, strlen(SN_hmac)); *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_DIGEST, SN_sha256, strlen(SN_sha256)); *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_SECRET, “secret”, (size_t)6); *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_INFO, “label”, (size_t)5); *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_SALT, “salt”, (size_t)4); *p = OSSL_PARAM_construct_end(); if (EVP_KDF_derive(kctx, out, sizeof(out), params) <= 0) { error(“EVP_KDF_derive”); } EVP_KDF_CTX_free(kctx);

This example derives 10 bytes using H(x) = KMAC128(x,salt,outlen), with the secret key “secret” fixedinfo value “label”, salt of “salt” and KMAC outlen of 20:

EVP_KDF *kdf; EVP_KDF_CTX *kctx; unsigned char out[10]; OSSL_PARAM params[6], *p = params; kdf = EVP_KDF_fetch(NULL, “SSKDF”, NULL); kctx = EVP_KDF_CTX_new(kdf); EVP_KDF_free(kdf); *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_MAC, SN_kmac128, strlen(SN_kmac128)); *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_SECRET, “secret”, (size_t)6); *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_INFO, “label”, (size_t)5); *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_SALT, “salt”, (size_t)4); *p++ = OSSL_PARAM_construct_size_t(OSSL_KDF_PARAM_MAC_SIZE, (size_t)20); *p = OSSL_PARAM_construct_end(); if (EVP_KDF_derive(kctx, out, sizeof(out), params) <= 0) { error(“EVP_KDF_derive”); } EVP_KDF_CTX_free(kctx);

CONFORMING TO

NIST SP800-56Cr1.

SEE ALSO

EVP_KDF (3), EVP_KDF_CTX_new (3), EVP_KDF_CTX_free (3), EVP_KDF_CTX_set_params (3), EVP_KDF_CTX_get_kdf_size (3), EVP_KDF_derive (3), “PARAMETERS” in EVP_KDF (3)

HISTORY

This functionality was added in OpenSSL 3.0.

COPYRIGHT

Copyright 2019-2023 The OpenSSL Project Authors. All Rights Reserved. Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

190 - Linux cli command EVP_MD-MD5-SHA1ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_MD-MD5-SHA1ssl and provides detailed information about the command EVP_MD-MD5-SHA1ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_MD-MD5-SHA1ssl.

NAME 🖥️ EVP_MD-MD5-SHA1ssl 🖥️

MD5-SHA1 - The MD5-SHA1 EVP_MD implementation

DESCRIPTION

Support for computing MD5-SHA1 digests through the EVP_MD API.

MD5-SHA1 is a rather special digest that’s used with SSLv3.

Identity

This implementation is only available with the default provider, and is identified with the name “MD5-SHA1”.

Gettable Parameters

This implementation supports the common gettable parameters described in EVP_MD-common (7).

Settable Context Parameters

This implementation supports the following OSSL_PARAM (3) entries, settable for an EVP_MD_CTX with EVP_MD_CTX_set_params (3):

“ssl3-ms” (OSSL_DIGEST_PARAM_SSL3_MS) <octet string>
This parameter is set by libssl in order to calculate a signature hash for an SSLv3 CertificateVerify message as per RFC6101. It is only set after all handshake messages have already been digested via OP_digest_update() calls. The parameter provides the master secret value to be added to the digest. The digest implementation should calculate the complete digest as per RFC6101 section 5.6.8. The next call after setting this parameter should be OP_digest_final().

SEE ALSO

EVP_MD_CTX_set_params (3), provider-digest (7), OSSL_PROVIDER-default (7)

COPYRIGHT

Copyright 2020 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

191 - Linux cli command WITH

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command WITH and provides detailed information about the command WITH, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the WITH.
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

192 - Linux cli command OSSL_PROVIDER-nullssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command OSSL_PROVIDER-nullssl and provides detailed information about the command OSSL_PROVIDER-nullssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the OSSL_PROVIDER-nullssl.

NAME 🖥️ OSSL_PROVIDER-nullssl 🖥️

null - OpenSSL null provider

DESCRIPTION

The OpenSSL null provider supplies no algorithms.

It can used to guarantee that the default library context and a fallback provider will not be accidentally accessed.

Properties

The null provider defines no properties.

OPERATIONS AND ALGORITHMS

The OpenSSL null provider supports no operations and algorithms.

SEE ALSO

provider (7)

HISTORY

This functionality was added in OpenSSL 3.0.

COPYRIGHT

Copyright 2020 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

193 - Linux cli command cpuset

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command cpuset and provides detailed information about the command cpuset, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the cpuset.

NAME 🖥️ cpuset 🖥️

confine processes to processor and memory node subsets

DESCRIPTION

The cpuset filesystem is a pseudo-filesystem interface to the kernel cpuset mechanism, which is used to control the processor placement and memory placement of processes. It is commonly mounted at /dev/cpuset.

On systems with kernels compiled with built in support for cpusets, all processes are attached to a cpuset, and cpusets are always present. If a system supports cpusets, then it will have the entry nodev cpuset in the file /proc/filesystems. By mounting the cpuset filesystem (see the EXAMPLES section below), the administrator can configure the cpusets on a system to control the processor and memory placement of processes on that system. By default, if the cpuset configuration on a system is not modified or if the cpuset filesystem is not even mounted, then the cpuset mechanism, though present, has no effect on the system’s behavior.

A cpuset defines a list of CPUs and memory nodes.

The CPUs of a system include all the logical processing units on which a process can execute, including, if present, multiple processor cores within a package and Hyper-Threads within a processor core. Memory nodes include all distinct banks of main memory; small and SMP systems typically have just one memory node that contains all the system’s main memory, while NUMA (non-uniform memory access) systems have multiple memory nodes.

Cpusets are represented as directories in a hierarchical pseudo-filesystem, where the top directory in the hierarchy (/dev/cpuset) represents the entire system (all online CPUs and memory nodes) and any cpuset that is the child (descendant) of another parent cpuset contains a subset of that parent’s CPUs and memory nodes. The directories and files representing cpusets have normal filesystem permissions.

Every process in the system belongs to exactly one cpuset. A process is confined to run only on the CPUs in the cpuset it belongs to, and to allocate memory only on the memory nodes in that cpuset. When a process fork(2)s, the child process is placed in the same cpuset as its parent. With sufficient privilege, a process may be moved from one cpuset to another and the allowed CPUs and memory nodes of an existing cpuset may be changed.

When the system begins booting, a single cpuset is defined that includes all CPUs and memory nodes on the system, and all processes are in that cpuset. During the boot process, or later during normal system operation, other cpusets may be created, as subdirectories of this top cpuset, under the control of the system administrator, and processes may be placed in these other cpusets.

Cpusets are integrated with the sched_setaffinity(2) scheduling affinity mechanism and the mbind(2) and set_mempolicy(2) memory-placement mechanisms in the kernel. Neither of these mechanisms let a process make use of a CPU or memory node that is not allowed by that process’s cpuset. If changes to a process’s cpuset placement conflict with these other mechanisms, then cpuset placement is enforced even if it means overriding these other mechanisms. The kernel accomplishes this overriding by silently restricting the CPUs and memory nodes requested by these other mechanisms to those allowed by the invoking process’s cpuset. This can result in these other calls returning an error, if for example, such a call ends up requesting an empty set of CPUs or memory nodes, after that request is restricted to the invoking process’s cpuset.

Typically, a cpuset is used to manage the CPU and memory-node confinement for a set of cooperating processes such as a batch scheduler job, and these other mechanisms are used to manage the placement of individual processes or memory regions within that set or job.

FILES

Each directory below /dev/cpuset represents a cpuset and contains a fixed set of pseudo-files describing the state of that cpuset.

New cpusets are created using the mkdir(2) system call or the mkdir(1) command. The properties of a cpuset, such as its flags, allowed CPUs and memory nodes, and attached processes, are queried and modified by reading or writing to the appropriate file in that cpuset’s directory, as listed below.

The pseudo-files in each cpuset directory are automatically created when the cpuset is created, as a result of the mkdir(2) invocation. It is not possible to directly add or remove these pseudo-files.

A cpuset directory that contains no child cpuset directories, and has no attached processes, can be removed using rmdir(2) or rmdir(1). It is not necessary, or possible, to remove the pseudo-files inside the directory before removing it.

The pseudo-files in each cpuset directory are small text files that may be read and written using traditional shell utilities such as cat(1), and echo(1), or from a program by using file I/O library functions or system calls, such as open(2), read(2), write(2), and close(2).

The pseudo-files in a cpuset directory represent internal kernel state and do not have any persistent image on disk. Each of these per-cpuset files is listed and described below.

tasks
List of the process IDs (PIDs) of the processes in that cpuset. The list is formatted as a series of ASCII decimal numbers, each followed by a newline. A process may be added to a cpuset (automatically removing it from the cpuset that previously contained it) by writing its PID to that cpuset’s tasks file (with or without a trailing newline).

Warning: only one PID may be written to the tasks file at a time. If a string is written that contains more than one PID, only the first one will be used.

notify_on_release
Flag (0 or 1). If set (1), that cpuset will receive special handling after it is released, that is, after all processes cease using it (i.e., terminate or are moved to a different cpuset) and all child cpuset directories have been removed. See the Notify On Release section, below.

cpuset.cpus
List of the physical numbers of the CPUs on which processes in that cpuset are allowed to execute. See List Format below for a description of the format of cpus.

The CPUs allowed to a cpuset may be changed by writing a new list to its cpus file.

cpuset.cpu_exclusive
Flag (0 or 1). If set (1), the cpuset has exclusive use of its CPUs (no sibling or cousin cpuset may overlap CPUs). By default, this is off (0). Newly created cpusets also initially default this to off (0).

Two cpusets are sibling cpusets if they share the same parent cpuset in the /dev/cpuset hierarchy. Two cpusets are cousin cpusets if neither is the ancestor of the other. Regardless of the cpu_exclusive setting, if one cpuset is the ancestor of another, and if both of these cpusets have nonempty cpus, then their cpus must overlap, because the cpus of any cpuset are always a subset of the cpus of its parent cpuset.

cpuset.mems
List of memory nodes on which processes in this cpuset are allowed to allocate memory. See List Format below for a description of the format of mems.

cpuset.mem_exclusive
Flag (0 or 1). If set (1), the cpuset has exclusive use of its memory nodes (no sibling or cousin may overlap). Also if set (1), the cpuset is a Hardwall cpuset (see below). By default, this is off (0). Newly created cpusets also initially default this to off (0).

Regardless of the mem_exclusive setting, if one cpuset is the ancestor of another, then their memory nodes must overlap, because the memory nodes of any cpuset are always a subset of the memory nodes of that cpuset’s parent cpuset.

cpuset.mem_hardwall (since Linux 2.6.26)
Flag (0 or 1). If set (1), the cpuset is a Hardwall cpuset (see below). Unlike mem_exclusive, there is no constraint on whether cpusets marked mem_hardwall may have overlapping memory nodes with sibling or cousin cpusets. By default, this is off (0). Newly created cpusets also initially default this to off (0).

cpuset.memory_migrate (since Linux 2.6.16)
Flag (0 or 1). If set (1), then memory migration is enabled. By default, this is off (0). See the Memory Migration section, below.

cpuset.memory_pressure (since Linux 2.6.16)
A measure of how much memory pressure the processes in this cpuset are causing. See the Memory Pressure section, below. Unless memory_pressure_enabled is enabled, always has value zero (0). This file is read-only. See the WARNINGS section, below.

cpuset.memory_pressure_enabled (since Linux 2.6.16)
Flag (0 or 1). This file is present only in the root cpuset, normally /dev/cpuset. If set (1), the memory_pressure calculations are enabled for all cpusets in the system. By default, this is off (0). See the Memory Pressure section, below.

cpuset.memory_spread_page (since Linux 2.6.17)
Flag (0 or 1). If set (1), pages in the kernel page cache (filesystem buffers) are uniformly spread across the cpuset. By default, this is off (0) in the top cpuset, and inherited from the parent cpuset in newly created cpusets. See the Memory Spread section, below.

cpuset.memory_spread_slab (since Linux 2.6.17)
Flag (0 or 1). If set (1), the kernel slab caches for file I/O (directory and inode structures) are uniformly spread across the cpuset. By default, is off (0) in the top cpuset, and inherited from the parent cpuset in newly created cpusets. See the Memory Spread section, below.

cpuset.sched_load_balance (since Linux 2.6.24)
Flag (0 or 1). If set (1, the default) the kernel will automatically load balance processes in that cpuset over the allowed CPUs in that cpuset. If cleared (0) the kernel will avoid load balancing processes in this cpuset, unless some other cpuset with overlapping CPUs has its sched_load_balance flag set. See Scheduler Load Balancing, below, for further details.

cpuset.sched_relax_domain_level (since Linux 2.6.26)
Integer, between -1 and a small positive value. The sched_relax_domain_level controls the width of the range of CPUs over which the kernel scheduler performs immediate rebalancing of runnable tasks across CPUs. If sched_load_balance is disabled, then the setting of sched_relax_domain_level does not matter, as no such load balancing is done. If sched_load_balance is enabled, then the higher the value of the sched_relax_domain_level, the wider the range of CPUs over which immediate load balancing is attempted. See Scheduler Relax Domain Level, below, for further details.

In addition to the above pseudo-files in each directory below /dev/cpuset, each process has a pseudo-file, /proc/pid/cpuset, that displays the path of the process’s cpuset directory relative to the root of the cpuset filesystem.

Also the /proc/pid/status file for each process has four added lines, displaying the process’s Cpus_allowed (on which CPUs it may be scheduled) and Mems_allowed (on which memory nodes it may obtain memory), in the two formats Mask Format and List Format (see below) as shown in the following example:

Cpus_allowed:   ffffffff,ffffffff,ffffffff,ffffffff
Cpus_allowed_list:     0-127
Mems_allowed:   ffffffff,ffffffff
Mems_allowed_list:     0-63

The “allowed” fields were added in Linux 2.6.24; the “allowed_list” fields were added in Linux 2.6.26.

EXTENDED CAPABILITIES

In addition to controlling which cpus and mems a process is allowed to use, cpusets provide the following extended capabilities.

Exclusive cpusets

If a cpuset is marked cpu_exclusive or mem_exclusive, no other cpuset, other than a direct ancestor or descendant, may share any of the same CPUs or memory nodes.

A cpuset that is mem_exclusive restricts kernel allocations for buffer cache pages and other internal kernel data pages commonly shared by the kernel across multiple users. All cpusets, whether mem_exclusive or not, restrict allocations of memory for user space. This enables configuring a system so that several independent jobs can share common kernel data, while isolating each job’s user allocation in its own cpuset. To do this, construct a large mem_exclusive cpuset to hold all the jobs, and construct child, non-mem_exclusive cpusets for each individual job. Only a small amount of kernel memory, such as requests from interrupt handlers, is allowed to be placed on memory nodes outside even a mem_exclusive cpuset.

Hardwall

A cpuset that has mem_exclusive or mem_hardwall set is a hardwall cpuset. A hardwall cpuset restricts kernel allocations for page, buffer, and other data commonly shared by the kernel across multiple users. All cpusets, whether hardwall or not, restrict allocations of memory for user space.

This enables configuring a system so that several independent jobs can share common kernel data, such as filesystem pages, while isolating each job’s user allocation in its own cpuset. To do this, construct a large hardwall cpuset to hold all the jobs, and construct child cpusets for each individual job which are not hardwall cpusets.

Only a small amount of kernel memory, such as requests from interrupt handlers, is allowed to be taken outside even a hardwall cpuset.

Notify on release

If the notify_on_release flag is enabled (1) in a cpuset, then whenever the last process in the cpuset leaves (exits or attaches to some other cpuset) and the last child cpuset of that cpuset is removed, the kernel will run the command /sbin/cpuset_release_agent, supplying the pathname (relative to the mount point of the cpuset filesystem) of the abandoned cpuset. This enables automatic removal of abandoned cpusets.

The default value of notify_on_release in the root cpuset at system boot is disabled (0). The default value of other cpusets at creation is the current value of their parent’s notify_on_release setting.

The command /sbin/cpuset_release_agent is invoked, with the name (/dev/cpuset relative path) of the to-be-released cpuset in argv[1].

The usual contents of the command /sbin/cpuset_release_agent is simply the shell script:

#!/bin/sh
rmdir /dev/cpuset/$1

As with other flag values below, this flag can be changed by writing an ASCII number 0 or 1 (with optional trailing newline) into the file, to clear or set the flag, respectively.

Memory pressure

The memory_pressure of a cpuset provides a simple per-cpuset running average of the rate that the processes in a cpuset are attempting to free up in-use memory on the nodes of the cpuset to satisfy additional memory requests.

This enables batch managers that are monitoring jobs running in dedicated cpusets to efficiently detect what level of memory pressure that job is causing.

This is useful both on tightly managed systems running a wide mix of submitted jobs, which may choose to terminate or reprioritize jobs that are trying to use more memory than allowed on the nodes assigned them, and with tightly coupled, long-running, massively parallel scientific computing jobs that will dramatically fail to meet required performance goals if they start to use more memory than allowed to them.

This mechanism provides a very economical way for the batch manager to monitor a cpuset for signs of memory pressure. It’s up to the batch manager or other user code to decide what action to take if it detects signs of memory pressure.

Unless memory pressure calculation is enabled by setting the pseudo-file /dev/cpuset/cpuset.memory_pressure_enabled, it is not computed for any cpuset, and reads from any memory_pressure always return zero, as represented by the ASCII string “0 “. See the WARNINGS section, below.

A per-cpuset, running average is employed for the following reasons:

  • Because this meter is per-cpuset rather than per-process or per virtual memory region, the system load imposed by a batch scheduler monitoring this metric is sharply reduced on large systems, because a scan of the tasklist can be avoided on each set of queries.

  • Because this meter is a running average rather than an accumulating counter, a batch scheduler can detect memory pressure with a single read, instead of having to read and accumulate results for a period of time.

  • Because this meter is per-cpuset rather than per-process, the batch scheduler can obtain the key information—memory pressure in a cpuset—with a single read, rather than having to query and accumulate results over all the (dynamically changing) set of processes in the cpuset.

The memory_pressure of a cpuset is calculated using a per-cpuset simple digital filter that is kept within the kernel. For each cpuset, this filter tracks the recent rate at which processes attached to that cpuset enter the kernel direct reclaim code.

The kernel direct reclaim code is entered whenever a process has to satisfy a memory page request by first finding some other page to repurpose, due to lack of any readily available already free pages. Dirty filesystem pages are repurposed by first writing them to disk. Unmodified filesystem buffer pages are repurposed by simply dropping them, though if that page is needed again, it will have to be reread from disk.

The cpuset.memory_pressure file provides an integer number representing the recent (half-life of 10 seconds) rate of entries to the direct reclaim code caused by any process in the cpuset, in units of reclaims attempted per second, times 1000.

Memory spread

There are two Boolean flag files per cpuset that control where the kernel allocates pages for the filesystem buffers and related in-kernel data structures. They are called cpuset.memory_spread_page and cpuset.memory_spread_slab.

If the per-cpuset Boolean flag file cpuset.memory_spread_page is set, then the kernel will spread the filesystem buffers (page cache) evenly over all the nodes that the faulting process is allowed to use, instead of preferring to put those pages on the node where the process is running.

If the per-cpuset Boolean flag file cpuset.memory_spread_slab is set, then the kernel will spread some filesystem-related slab caches, such as those for inodes and directory entries, evenly over all the nodes that the faulting process is allowed to use, instead of preferring to put those pages on the node where the process is running.

The setting of these flags does not affect the data segment (see brk(2)) or stack segment pages of a process.

By default, both kinds of memory spreading are off and the kernel prefers to allocate memory pages on the node local to where the requesting process is running. If that node is not allowed by the process’s NUMA memory policy or cpuset configuration or if there are insufficient free memory pages on that node, then the kernel looks for the nearest node that is allowed and has sufficient free memory.

When new cpusets are created, they inherit the memory spread settings of their parent.

Setting memory spreading causes allocations for the affected page or slab caches to ignore the process’s NUMA memory policy and be spread instead. However, the effect of these changes in memory placement caused by cpuset-specified memory spreading is hidden from the mbind(2) or set_mempolicy(2) calls. These two NUMA memory policy calls always appear to behave as if no cpuset-specified memory spreading is in effect, even if it is. If cpuset memory spreading is subsequently turned off, the NUMA memory policy most recently specified by these calls is automatically reapplied.

Both cpuset.memory_spread_page and cpuset.memory_spread_slab are Boolean flag files. By default, they contain “0”, meaning that the feature is off for that cpuset. If a “1” is written to that file, that turns the named feature on.

Cpuset-specified memory spreading behaves similarly to what is known (in other contexts) as round-robin or interleave memory placement.

Cpuset-specified memory spreading can provide substantial performance improvements for jobs that:

  • need to place thread-local data on memory nodes close to the CPUs which are running the threads that most frequently access that data; but also

  • need to access large filesystem data sets that must to be spread across the several nodes in the job’s cpuset in order to fit.

Without this policy, the memory allocation across the nodes in the job’s cpuset can become very uneven, especially for jobs that might have just a single thread initializing or reading in the data set.

Memory migration

Normally, under the default setting (disabled) of cpuset.memory_migrate, once a page is allocated (given a physical page of main memory), then that page stays on whatever node it was allocated, so long as it remains allocated, even if the cpuset’s memory-placement policy mems subsequently changes.

When memory migration is enabled in a cpuset, if the mems setting of the cpuset is changed, then any memory page in use by any process in the cpuset that is on a memory node that is no longer allowed will be migrated to a memory node that is allowed.

Furthermore, if a process is moved into a cpuset with memory_migrate enabled, any memory pages it uses that were on memory nodes allowed in its previous cpuset, but which are not allowed in its new cpuset, will be migrated to a memory node allowed in the new cpuset.

The relative placement of a migrated page within the cpuset is preserved during these migration operations if possible. For example, if the page was on the second valid node of the prior cpuset, then the page will be placed on the second valid node of the new cpuset, if possible.

Scheduler load balancing

The kernel scheduler automatically load balances processes. If one CPU is underutilized, the kernel will look for processes on other more overloaded CPUs and move those processes to the underutilized CPU, within the constraints of such placement mechanisms as cpusets and sched_setaffinity(2).

The algorithmic cost of load balancing and its impact on key shared kernel data structures such as the process list increases more than linearly with the number of CPUs being balanced. For example, it costs more to load balance across one large set of CPUs than it does to balance across two smaller sets of CPUs, each of half the size of the larger set. (The precise relationship between the number of CPUs being balanced and the cost of load balancing depends on implementation details of the kernel process scheduler, which is subject to change over time, as improved kernel scheduler algorithms are implemented.)

The per-cpuset flag sched_load_balance provides a mechanism to suppress this automatic scheduler load balancing in cases where it is not needed and suppressing it would have worthwhile performance benefits.

By default, load balancing is done across all CPUs, except those marked isolated using the kernel boot time “isolcpus=” argument. (See Scheduler Relax Domain Level, below, to change this default.)

This default load balancing across all CPUs is not well suited to the following two situations:

  • On large systems, load balancing across many CPUs is expensive. If the system is managed using cpusets to place independent jobs on separate sets of CPUs, full load balancing is unnecessary.

  • Systems supporting real-time on some CPUs need to minimize system overhead on those CPUs, including avoiding process load balancing if that is not needed.

When the per-cpuset flag sched_load_balance is enabled (the default setting), it requests load balancing across all the CPUs in that cpuset’s allowed CPUs, ensuring that load balancing can move a process (not otherwise pinned, as by sched_setaffinity(2)) from any CPU in that cpuset to any other.

When the per-cpuset flag sched_load_balance is disabled, then the scheduler will avoid load balancing across the CPUs in that cpuset, except in so far as is necessary because some overlapping cpuset has sched_load_balance enabled.

So, for example, if the top cpuset has the flag sched_load_balance enabled, then the scheduler will load balance across all CPUs, and the setting of the sched_load_balance flag in other cpusets has no effect, as we’re already fully load balancing.

Therefore in the above two situations, the flag sched_load_balance should be disabled in the top cpuset, and only some of the smaller, child cpusets would have this flag enabled.

When doing this, you don’t usually want to leave any unpinned processes in the top cpuset that might use nontrivial amounts of CPU, as such processes may be artificially constrained to some subset of CPUs, depending on the particulars of this flag setting in descendant cpusets. Even if such a process could use spare CPU cycles in some other CPUs, the kernel scheduler might not consider the possibility of load balancing that process to the underused CPU.

Of course, processes pinned to a particular CPU can be left in a cpuset that disables sched_load_balance as those processes aren’t going anywhere else anyway.

Scheduler relax domain level

The kernel scheduler performs immediate load balancing whenever a CPU becomes free or another task becomes runnable. This load balancing works to ensure that as many CPUs as possible are usefully employed running tasks. The kernel also performs periodic load balancing off the software clock described in time(7). The setting of sched_relax_domain_level applies only to immediate load balancing. Regardless of the sched_relax_domain_level setting, periodic load balancing is attempted over all CPUs (unless disabled by turning off sched_load_balance.) In any case, of course, tasks will be scheduled to run only on CPUs allowed by their cpuset, as modified by sched_setaffinity(2) system calls.

On small systems, such as those with just a few CPUs, immediate load balancing is useful to improve system interactivity and to minimize wasteful idle CPU cycles. But on large systems, attempting immediate load balancing across a large number of CPUs can be more costly than it is worth, depending on the particular performance characteristics of the job mix and the hardware.

The exact meaning of the small integer values of sched_relax_domain_level will depend on internal implementation details of the kernel scheduler code and on the non-uniform architecture of the hardware. Both of these will evolve over time and vary by system architecture and kernel version.

As of this writing, when this capability was introduced in Linux 2.6.26, on certain popular architectures, the positive values of sched_relax_domain_level have the following meanings.

1
Perform immediate load balancing across Hyper-Thread siblings on the same core.

2
Perform immediate load balancing across other cores in the same package.

3
Perform immediate load balancing across other CPUs on the same node or blade.

4
Perform immediate load balancing across over several (implementation detail) nodes [On NUMA systems].

5
Perform immediate load balancing across over all CPUs in system [On NUMA systems].

The sched_relax_domain_level value of zero (0) always means don’t perform immediate load balancing, hence that load balancing is done only periodically, not immediately when a CPU becomes available or another task becomes runnable.

The sched_relax_domain_level value of minus one (-1) always means use the system default value. The system default value can vary by architecture and kernel version. This system default value can be changed by kernel boot-time “relax_domain_level=” argument.

In the case of multiple overlapping cpusets which have conflicting sched_relax_domain_level values, then the highest such value applies to all CPUs in any of the overlapping cpusets. In such cases, -1 is the lowest value, overridden by any other value, and 0 is the next lowest value.

FORMATS

The following formats are used to represent sets of CPUs and memory nodes.

Mask format

The Mask Format is used to represent CPU and memory-node bit masks in the /proc/pid/status file.

This format displays each 32-bit word in hexadecimal (using ASCII characters “0” - “9” and “a” - “f”); words are filled with leading zeros, if required. For masks longer than one word, a comma separator is used between words. Words are displayed in big-endian order, which has the most significant bit first. The hex digits within a word are also in big-endian order.

The number of 32-bit words displayed is the minimum number needed to display all bits of the bit mask, based on the size of the bit mask.

Examples of the Mask Format:

00000001                        # just bit 0 set
40000000,00000000,00000000      # just bit 94 set
00000001,00000000,00000000      # just bit 64 set
000000ff,00000000               # bits 32-39 set
00000000,000e3862               # 1,5,6,11-13,17-19 set

A mask with bits 0, 1, 2, 4, 8, 16, 32, and 64 set displays as:

00000001,00000001,00010117

The first “1” is for bit 64, the second for bit 32, the third for bit 16, the fourth for bit 8, the fifth for bit 4, and the “7” is for bits 2, 1, and 0.

List format

The List Format for cpus and mems is a comma-separated list of CPU or memory-node numbers and ranges of numbers, in ASCII decimal.

Examples of the List Format:

0-4,9           # bits 0, 1, 2, 3, 4, and 9 set
0-2,7,12-14     # bits 0, 1, 2, 7, 12, 13, and 14 set

RULES

The following rules apply to each cpuset:

  • Its CPUs and memory nodes must be a (possibly equal) subset of its parent’s.

  • It can be marked cpu_exclusive only if its parent is.

  • It can be marked mem_exclusive only if its parent is.

  • If it is cpu_exclusive, its CPUs may not overlap any sibling.

  • If it is mem_exclusive, its memory nodes may not overlap any sibling.

PERMISSIONS

The permissions of a cpuset are determined by the permissions of the directories and pseudo-files in the cpuset filesystem, normally mounted at /dev/cpuset.

For instance, a process can put itself in some other cpuset (than its current one) if it can write the tasks file for that cpuset. This requires execute permission on the encompassing directories and write permission on the tasks file.

An additional constraint is applied to requests to place some other process in a cpuset. One process may not attach another to a cpuset unless it would have permission to send that process a signal (see kill(2)).

A process may create a child cpuset if it can access and write the parent cpuset directory. It can modify the CPUs or memory nodes in a cpuset if it can access that cpuset’s directory (execute permissions on the each of the parent directories) and write the corresponding cpus or mems file.

There is one minor difference between the manner in which these permissions are evaluated and the manner in which normal filesystem operation permissions are evaluated. The kernel interprets relative pathnames starting at a process’s current working directory. Even if one is operating on a cpuset file, relative pathnames are interpreted relative to the process’s current working directory, not relative to the process’s current cpuset. The only ways that cpuset paths relative to a process’s current cpuset can be used are if either the process’s current working directory is its cpuset (it first did a cd or chdir(2) to its cpuset directory beneath /dev/cpuset, which is a bit unusual) or if some user code converts the relative cpuset path to a full filesystem path.

In theory, this means that user code should specify cpusets using absolute pathnames, which requires knowing the mount point of the cpuset filesystem (usually, but not necessarily, /dev/cpuset). In practice, all user level code that this author is aware of simply assumes that if the cpuset filesystem is mounted, then it is mounted at /dev/cpuset. Furthermore, it is common practice for carefully written user code to verify the presence of the pseudo-file /dev/cpuset/tasks in order to verify that the cpuset pseudo-filesystem is currently mounted.

WARNINGS

Enabling memory_pressure

By default, the per-cpuset file cpuset.memory_pressure always contains zero (0). Unless this feature is enabled by writing “1” to the pseudo-file /dev/cpuset/cpuset.memory_pressure_enabled, the kernel does not compute per-cpuset memory_pressure.

Using the echo command

When using the echo command at the shell prompt to change the values of cpuset files, beware that the built-in echo command in some shells does not display an error message if the write(2) system call fails. For example, if the command:

echo 19 > cpuset.mems

failed because memory node 19 was not allowed (perhaps the current system does not have a memory node 19), then the echo command might not display any error. It is better to use the /bin/echo external command to change cpuset file settings, as this command will display write(2) errors, as in the example:

/bin/echo 19 > cpuset.mems
/bin/echo: write error: Invalid argument

EXCEPTIONS

Memory placement

Not all allocations of system memory are constrained by cpusets, for the following reasons.

If hot-plug functionality is used to remove all the CPUs that are currently assigned to a cpuset, then the kernel will automatically update the cpus_allowed of all processes attached to CPUs in that cpuset to allow all CPUs. When memory hot-plug functionality for removing memory nodes is available, a similar exception is expected to apply there as well. In general, the kernel prefers to violate cpuset placement, rather than starving a process that has had all its allowed CPUs or memory nodes taken offline. User code should reconfigure cpusets to refer only to online CPUs and memory nodes when using hot-plug to add or remove such resources.

A few kernel-critical, internal memory-allocation requests, marked GFP_ATOMIC, must be satisfied immediately. The kernel may drop some request or malfunction if one of these allocations fail. If such a request cannot be satisfied within the current process’s cpuset, then we relax the cpuset, and look for memory anywhere we can find it. It’s better to violate the cpuset than stress the kernel.

Allocations of memory requested by kernel drivers while processing an interrupt lack any relevant process context, and are not confined by cpusets.

Renaming cpusets

You can use the rename(2) system call to rename cpusets. Only simple renaming is supported; that is, changing the name of a cpuset directory is permitted, but moving a directory into a different directory is not permitted.

ERRORS

The Linux kernel implementation of cpusets sets errno to specify the reason for a failed system call affecting cpusets.

The possible errno settings and their meaning when set on a failed cpuset call are as listed below.

E2BIG
Attempted a write(2) on a special cpuset file with a length larger than some kernel-determined upper limit on the length of such writes.

EACCES
Attempted to write(2) the process ID (PID) of a process to a cpuset tasks file when one lacks permission to move that process.

EACCES
Attempted to add, using write(2), a CPU or memory node to a cpuset, when that CPU or memory node was not already in its parent.

EACCES
Attempted to set, using write(2), cpuset.cpu_exclusive or cpuset.mem_exclusive on a cpuset whose parent lacks the same setting.

EACCES
Attempted to write(2) a cpuset.memory_pressure file.

EACCES
Attempted to create a file in a cpuset directory.

EBUSY
Attempted to remove, using rmdir(2), a cpuset with attached processes.

EBUSY
Attempted to remove, using rmdir(2), a cpuset with child cpusets.

EBUSY
Attempted to remove a CPU or memory node from a cpuset that is also in a child of that cpuset.

EEXIST
Attempted to create, using mkdir(2), a cpuset that already exists.

EEXIST
Attempted to rename(2) a cpuset to a name that already exists.

EFAULT
Attempted to read(2) or write(2) a cpuset file using a buffer that is outside the writing processes accessible address space.

EINVAL
Attempted to change a cpuset, using write(2), in a way that would violate a cpu_exclusive or mem_exclusive attribute of that cpuset or any of its siblings.

EINVAL
Attempted to write(2) an empty cpuset.cpus or cpuset.mems list to a cpuset which has attached processes or child cpusets.

EINVAL
Attempted to write(2) a cpuset.cpus or cpuset.mems list which included a range with the second number smaller than the first number.

EINVAL
Attempted to write(2) a cpuset.cpus or cpuset.mems list which included an invalid character in the string.

EINVAL
Attempted to write(2) a list to a cpuset.cpus file that did not include any online CPUs.

EINVAL
Attempted to write(2) a list to a cpuset.mems file that did not include any online memory nodes.

EINVAL
Attempted to write(2) a list to a cpuset.mems file that included a node that held no memory.

EIO
Attempted to write(2) a string to a cpuset tasks file that does not begin with an ASCII decimal integer.

EIO
Attempted to rename(2) a cpuset into a different directory.

ENAMETOOLONG
Attempted to read(2) a /proc/pid/cpuset file for a cpuset path that is longer than the kernel page size.

ENAMETOOLONG
Attempted to create, using mkdir(2), a cpuset whose base directory name is longer than 255 characters.

ENAMETOOLONG
Attempted to create, using mkdir(2), a cpuset whose full pathname, including the mount point (typically “/dev/cpuset/”) prefix, is longer than 4095 characters.

ENODEV
The cpuset was removed by another process at the same time as a write(2) was attempted on one of the pseudo-files in the cpuset directory.

ENOENT
Attempted to create, using mkdir(2), a cpuset in a parent cpuset that doesn’t exist.

ENOENT
Attempted to access(2) or open(2) a nonexistent file in a cpuset directory.

ENOMEM
Insufficient memory is available within the kernel; can occur on a variety of system calls affecting cpusets, but only if the system is extremely short of memory.

ENOSPC
Attempted to write(2) the process ID (PID) of a process to a cpuset tasks file when the cpuset had an empty cpuset.cpus or empty cpuset.mems setting.

ENOSPC
Attempted to write(2) an empty cpuset.cpus or cpuset.mems setting to a cpuset that has tasks attached.

ENOTDIR
Attempted to rename(2) a nonexistent cpuset.

EPERM
Attempted to remove a file from a cpuset directory.

ERANGE
Specified a cpuset.cpus or cpuset.mems list to the kernel which included a number too large for the kernel to set in its bit masks.

ESRCH
Attempted to write(2) the process ID (PID) of a nonexistent process to a cpuset tasks file.

VERSIONS

Cpusets appeared in Linux 2.6.12.

NOTES

Despite its name, the pid parameter is actually a thread ID, and each thread in a threaded group can be attached to a different cpuset. The value returned from a call to gettid(2) can be passed in the argument pid.

BUGS

cpuset.memory_pressure cpuset files can be opened for writing, creation, or truncation, but then the write(2) fails with errno set to EACCES, and the creation and truncation options on open(2) have no effect.

EXAMPLES

The following examples demonstrate querying and setting cpuset options using shell commands.

Creating and attaching to a cpuset.

To create a new cpuset and attach the current command shell to it, the steps are:

  1. mkdir /dev/cpuset (if not already done)

  2. mount -t cpuset none /dev/cpuset (if not already done)

  3. Create the new cpuset using mkdir(1).

  4. Assign CPUs and memory nodes to the new cpuset.

  5. Attach the shell to the new cpuset.

For example, the following sequence of commands will set up a cpuset named “Charlie”, containing just CPUs 2 and 3, and memory node 1, and then attach the current shell to that cpuset.

$ mkdir /dev/cpuset
$ mount -t cpuset cpuset /dev/cpuset
$ cd /dev/cpuset
$ mkdir Charlie
$ cd Charlie
$ /bin/echo 2-3 > cpuset.cpus
$ /bin/echo 1 > cpuset.mems
$ /bin/echo $$ > tasks
# The current shell is now running in cpuset Charlie
# The next line should display '/Charlie'
$ cat /proc/self/cpuset

Migrating a job to different memory nodes.

To migrate a job (the set of processes attached to a cpuset) to different CPUs and memory nodes in the system, including moving the memory pages currently allocated to that job, perform the following steps.

  1. Let’s say we want to move the job in cpuset alpha (CPUs 4–7 and memory nodes 2–3) to a new cpuset beta (CPUs 16–19 and memory nodes 8–9).

  2. First create the new cpuset beta.

  3. Then allow CPUs 16–19 and memory nodes 8–9 in beta.

  4. Then enable memory_migration in beta.

  5. Then move each process from alpha to beta.

The following sequence of commands accomplishes this.

$ cd /dev/cpuset
$ mkdir beta
$ cd beta
$ /bin/echo 16-19 > cpuset.cpus
$ /bin/echo 8-9 > cpuset.mems
$ /bin/echo 1 > cpuset.memory_migrate
$ while read i; do /bin/echo $i; done < ../alpha/tasks > tasks

The above should move any processes in alpha to beta, and any memory held by these processes on memory nodes 2–3 to memory nodes 8–9, respectively.

Notice that the last step of the above sequence did not do:

$ cp ../alpha/tasks tasks

The while loop, rather than the seemingly easier use of the cp(1) command, was necessary because only one process PID at a time may be written to the tasks file.

The same effect (writing one PID at a time) as the while loop can be accomplished more efficiently, in fewer keystrokes and in syntax that works on any shell, but alas more obscurely, by using the -u (unbuffered) option of sed(1):

$ sed -un p < ../alpha/tasks > tasks

SEE ALSO

taskset(1), get_mempolicy(2), getcpu(2), mbind(2), sched_getaffinity(2), sched_setaffinity(2), sched_setscheduler(2), set_mempolicy(2), CPU_SET(3), proc(5), cgroups(7), numa(7), sched(7), migratepages(8), numactl(8)

Documentation/admin-guide/cgroup-v1/cpusets.rst in the Linux kernel source tree (or Documentation/cgroup-v1/cpusets.txt before Linux 4.18, and Documentation/cpusets.txt before Linux 2.6.29)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

194 - Linux cli command RANDssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command RANDssl and provides detailed information about the command RANDssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the RANDssl.

NAME 🖥️ RANDssl 🖥️

the OpenSSL random generator

DESCRIPTION

Random numbers are a vital part of cryptography, they are needed to provide unpredictability for tasks like key generation, creating salts, and many more. Software-based generators must be seeded with external randomness before they can be used as a cryptographically-secure pseudo-random number generator (CSPRNG). The availability of common hardware with special instructions and modern operating systems, which may use items such as interrupt jitter and network packet timings, can be reasonable sources of seeding material.

OpenSSL comes with a default implementation of the RAND API which is based on the deterministic random bit generator (DRBG) model as described in [NIST SP 800-90A Rev. 1]. The default random generator will initialize automatically on first use and will be fully functional without having to be initialized (‘seeded’) explicitly. It seeds and reseeds itself automatically using trusted random sources provided by the operating system.

As a normal application developer, you do not have to worry about any details, just use RAND_bytes (3) to obtain random data. Having said that, there is one important rule to obey: Always check the error return value of RAND_bytes (3) and do not take randomness for granted. Although (re-)seeding is automatic, it can fail because no trusted random source is available or the trusted source(s) temporarily fail to provide sufficient random seed material. In this case the CSPRNG enters an error state and ceases to provide output, until it is able to recover from the error by reseeding itself. For more details on reseeding and error recovery, see EVP_RAND (7).

For values that should remain secret, you can use RAND_priv_bytes (3) instead. This method does not provide ‘better’ randomness, it uses the same type of CSPRNG. The intention behind using a dedicated CSPRNG exclusively for private values is that none of its output should be visible to an attacker (e.g., used as salt value), in order to reveal as little information as possible about its internal state, and that a compromise of the “public” CSPRNG instance will not affect the secrecy of these private values.

In the rare case where the default implementation does not satisfy your special requirements, the default RAND internals can be replaced by your own EVP_RAND (3) objects.

Changing the default random generator should be necessary only in exceptional cases and is not recommended, unless you have a profound knowledge of cryptographic principles and understand the implications of your changes.

DEFAULT SETUP

The default OpenSSL RAND method is based on the EVP_RAND deterministic random bit generator (DRBG) classes. A DRBG is a certain type of cryptographically-secure pseudo-random number generator (CSPRNG), which is described in [NIST SP 800-90A Rev. 1].

SEE ALSO

RAND_bytes (3), RAND_priv_bytes (3), EVP_RAND (3), RAND_get0_primary (3), EVP_RAND (7)

COPYRIGHT

Copyright 2018-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

195 - Linux cli command iso_8859-16

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso_8859-16 and provides detailed information about the command iso_8859-16, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso_8859-16.

NAME 🖥️ iso_8859-16 🖥️

16 - ISO/IEC 8859-16 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-16 encodes the Latin characters used in Southeast European languages.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-16 characters

The following table displays the characters in ISO/IEC 8859-16 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-16 is also known as Latin-10.

SEE ALSO

ascii(7), charsets(7), iso_8859-3(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

196 - Linux cli command RSA-PSSssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command RSA-PSSssl and provides detailed information about the command RSA-PSSssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the RSA-PSSssl.

NAME 🖥️ RSA-PSSssl 🖥️

PSS - EVP_PKEY RSA-PSS algorithm support

DESCRIPTION

The RSA-PSS EVP_PKEY implementation is a restricted version of the RSA algorithm which only supports signing, verification and key generation using PSS padding modes with optional parameter restrictions.

It has associated private key and public key formats.

This algorithm shares several control operations with the RSA algorithm but with some restrictions described below.

Signing and Verification

Signing and verification is similar to the RSA algorithm except the padding mode is always PSS. If the key in use has parameter restrictions then the corresponding signature parameters are set to the restrictions: for example, if the key can only be used with digest SHA256, MGF1 SHA256 and minimum salt length 32 then the digest, MGF1 digest and salt length will be set to SHA256, SHA256 and 32 respectively.

Key Generation

By default no parameter restrictions are placed on the generated key.

NOTES

The public key format is documented in RFC4055.

The PKCS#8 private key format used for RSA-PSS keys is similar to the RSA format except it uses the id-RSASSA-PSS OID and the parameters field, if present, restricts the key parameters in the same way as the public key.

CONFORMING TO

RFC 4055

SEE ALSO

EVP_PKEY_CTX_set_rsa_pss_keygen_md (3), EVP_PKEY_CTX_set_rsa_pss_keygen_mgf1_md (3), EVP_PKEY_CTX_set_rsa_pss_keygen_saltlen (3), EVP_PKEY_CTX_new (3), EVP_PKEY_CTX_ctrl_str (3), EVP_PKEY_derive (3)

COPYRIGHT

Copyright 2017-2018 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

197 - Linux cli command ALTER_TABLESPACE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_TABLESPACE and provides detailed information about the command ALTER_TABLESPACE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_TABLESPACE.

NAME 🖥️ ALTER_TABLESPACE 🖥️

change the definition of a tablespace

SYNOPSIS

ALTER TABLESPACE name RENAME TO new_name
ALTER TABLESPACE name OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }
ALTER TABLESPACE name SET ( tablespace_option = value [, ... ] )
ALTER TABLESPACE name RESET ( tablespace_option [, ... ] )

DESCRIPTION

ALTER TABLESPACE can be used to change the definition of a tablespace.

You must own the tablespace to change the definition of a tablespace. To alter the owner, you must also be able to SET ROLE to the new owning role. (Note that superusers have these privileges automatically.)

PARAMETERS

name

The name of an existing tablespace.

new_name

The new name of the tablespace. The new name cannot begin with pg_, as such names are reserved for system tablespaces.

new_owner

The new owner of the tablespace.

tablespace_option

A tablespace parameter to be set or reset. Currently, the only available parameters are seq_page_cost, random_page_cost, effective_io_concurrency and maintenance_io_concurrency. Setting these values for a particular tablespace will override the planners usual estimate of the cost of reading pages from tables in that tablespace, and the executors prefetching behavior, as established by the configuration parameters of the same name (see seq_page_cost, random_page_cost, effective_io_concurrency, maintenance_io_concurrency). This may be useful if one tablespace is located on a disk which is faster or slower than the remainder of the I/O subsystem.

EXAMPLES

Rename tablespace index_space to fast_raid:

ALTER TABLESPACE index_space RENAME TO fast_raid;

Change the owner of tablespace index_space:

ALTER TABLESPACE index_space OWNER TO mary;

COMPATIBILITY

There is no ALTER TABLESPACE statement in the SQL standard.

SEE ALSO

CREATE TABLESPACE (CREATE_TABLESPACE(7)), DROP TABLESPACE (DROP_TABLESPACE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

198 - Linux cli command provider-cipherssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command provider-cipherssl and provides detailed information about the command provider-cipherssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the provider-cipherssl.

NAME 🖥️ provider-cipherssl 🖥️

cipher - The cipher library <-> provider functions

SYNOPSIS

#include <openssl/core_dispatch.h> #include <openssl/core_names.h> /* * None of these are actual functions, but are displayed like this for * the function signatures for functions that are offered as function * pointers in OSSL_DISPATCH arrays. */ /* Context management */ void *OSSL_FUNC_cipher_newctx(void *provctx); void OSSL_FUNC_cipher_freectx(void *cctx); void *OSSL_FUNC_cipher_dupctx(void *cctx); /* Encryption/decryption */ int OSSL_FUNC_cipher_encrypt_init(void *cctx, const unsigned char *key, size_t keylen, const unsigned char *iv, size_t ivlen, const OSSL_PARAM params[]); int OSSL_FUNC_cipher_decrypt_init(void *cctx, const unsigned char *key, size_t keylen, const unsigned char *iv, size_t ivlen, const OSSL_PARAM params[]); int OSSL_FUNC_cipher_update(void *cctx, unsigned char *out, size_t *outl, size_t outsize, const unsigned char *in, size_t inl); int OSSL_FUNC_cipher_final(void *cctx, unsigned char *out, size_t *outl, size_t outsize); int OSSL_FUNC_cipher_cipher(void *cctx, unsigned char *out, size_t *outl, size_t outsize, const unsigned char *in, size_t inl); /* Cipher parameter descriptors */ const OSSL_PARAM *OSSL_FUNC_cipher_gettable_params(void *provctx); /* Cipher operation parameter descriptors */ const OSSL_PARAM *OSSL_FUNC_cipher_gettable_ctx_params(void *cctx, void *provctx); const OSSL_PARAM *OSSL_FUNC_cipher_settable_ctx_params(void *cctx, void *provctx); /* Cipher parameters */ int OSSL_FUNC_cipher_get_params(OSSL_PARAM params[]); /* Cipher operation parameters */ int OSSL_FUNC_cipher_get_ctx_params(void *cctx, OSSL_PARAM params[]); int OSSL_FUNC_cipher_set_ctx_params(void *cctx, const OSSL_PARAM params[]);

DESCRIPTION

This documentation is primarily aimed at provider authors. See provider (7) for further information.

The CIPHER operation enables providers to implement cipher algorithms and make them available to applications via the API functions EVP_EncryptInit_ex (3), EVP_EncryptUpdate (3) and EVP_EncryptFinal (3) (as well as the decrypt equivalents and other related functions).

All “functions” mentioned here are passed as function pointers between libcrypto and the provider in OSSL_DISPATCH (3) arrays via OSSL_ALGORITHM (3) arrays that are returned by the provider’s provider_query_operation() function (see “Provider Functions” in provider-base (7)).

All these “functions” have a corresponding function type definition named OSSL_FUNC_{name}_fn, and a helper function to retrieve the function pointer from an OSSL_DISPATCH (3) element named OSSL_FUNC_{name}. For example, the “function” OSSL_FUNC_cipher_newctx() has these:

typedef void *(OSSL_FUNC_cipher_newctx_fn)(void *provctx); static ossl_inline OSSL_FUNC_cipher_newctx_fn OSSL_FUNC_cipher_newctx(const OSSL_DISPATCH *opf);

OSSL_DISPATCH (3) arrays are indexed by numbers that are provided as macros in openssl-core_dispatch.h (7), as follows:

OSSL_FUNC_cipher_newctx OSSL_FUNC_CIPHER_NEWCTX OSSL_FUNC_cipher_freectx OSSL_FUNC_CIPHER_FREECTX OSSL_FUNC_cipher_dupctx OSSL_FUNC_CIPHER_DUPCTX OSSL_FUNC_cipher_encrypt_init OSSL_FUNC_CIPHER_ENCRYPT_INIT OSSL_FUNC_cipher_decrypt_init OSSL_FUNC_CIPHER_DECRYPT_INIT OSSL_FUNC_cipher_update OSSL_FUNC_CIPHER_UPDATE OSSL_FUNC_cipher_final OSSL_FUNC_CIPHER_FINAL OSSL_FUNC_cipher_cipher OSSL_FUNC_CIPHER_CIPHER OSSL_FUNC_cipher_get_params OSSL_FUNC_CIPHER_GET_PARAMS OSSL_FUNC_cipher_get_ctx_params OSSL_FUNC_CIPHER_GET_CTX_PARAMS OSSL_FUNC_cipher_set_ctx_params OSSL_FUNC_CIPHER_SET_CTX_PARAMS OSSL_FUNC_cipher_gettable_params OSSL_FUNC_CIPHER_GETTABLE_PARAMS OSSL_FUNC_cipher_gettable_ctx_params OSSL_FUNC_CIPHER_GETTABLE_CTX_PARAMS OSSL_FUNC_cipher_settable_ctx_params OSSL_FUNC_CIPHER_SETTABLE_CTX_PARAMS

A cipher algorithm implementation may not implement all of these functions. In order to be a consistent set of functions there must at least be a complete set of “encrypt” functions, or a complete set of “decrypt” functions, or a single “cipher” function. In all cases both the OSSL_FUNC_cipher_newctx and OSSL_FUNC_cipher_freectx functions must be present. All other functions are optional.

Context Management Functions

OSSL_FUNC_cipher_newctx() should create and return a pointer to a provider side structure for holding context information during a cipher operation. A pointer to this context will be passed back in a number of the other cipher operation function calls. The parameter provctx is the provider context generated during provider initialisation (see provider (7)).

OSSL_FUNC_cipher_freectx() is passed a pointer to the provider side cipher context in the cctx parameter. This function should free any resources associated with that context.

OSSL_FUNC_cipher_dupctx() should duplicate the provider side cipher context in the cctx parameter and return the duplicate copy.

Encryption/Decryption Functions

OSSL_FUNC_cipher_encrypt_init() initialises a cipher operation for encryption given a newly created provider side cipher context in the cctx parameter. The key to be used is given in key which is keylen bytes long. The IV to be used is given in iv which is ivlen bytes long. The params, if not NULL, should be set on the context in a manner similar to using OSSL_FUNC_cipher_set_ctx_params().

OSSL_FUNC_cipher_decrypt_init() is the same as OSSL_FUNC_cipher_encrypt_init() except that it initialises the context for a decryption operation.

OSSL_FUNC_cipher_update() is called to supply data to be encrypted/decrypted as part of a previously initialised cipher operation. The cctx parameter contains a pointer to a previously initialised provider side context. OSSL_FUNC_cipher_update() should encrypt/decrypt inl bytes of data at the location pointed to by in. The encrypted data should be stored in out and the amount of data written to *outl which should not exceed outsize bytes. OSSL_FUNC_cipher_update() may be called multiple times for a single cipher operation. It is the responsibility of the cipher implementation to handle input lengths that are not multiples of the block length. In such cases a cipher implementation will typically cache partial blocks of input data until a complete block is obtained. The pointers out and in may point to the same location, in which case the encryption must be done in-place. If out and in point to different locations, the requirements of EVP_EncryptUpdate (3) and EVP_DecryptUpdate (3) guarantee that the two buffers are disjoint. Similarly, the requirements of EVP_EncryptUpdate (3) and EVP_DecryptUpdate (3) ensure that the buffer pointed to by out contains sufficient room for the operation being performed.

OSSL_FUNC_cipher_final() completes an encryption or decryption started through previous OSSL_FUNC_cipher_encrypt_init() or OSSL_FUNC_cipher_decrypt_init(), and OSSL_FUNC_cipher_update() calls. The cctx parameter contains a pointer to the provider side context. Any final encryption/decryption output should be written to out and the amount of data written to *outl which should not exceed outsize bytes. The same expectations apply to outsize as documented for EVP_EncryptFinal (3) and EVP_DecryptFinal (3).

OSSL_FUNC_cipher_cipher() performs encryption/decryption using the provider side cipher context in the cctx parameter that should have been previously initialised via a call to OSSL_FUNC_cipher_encrypt_init() or OSSL_FUNC_cipher_decrypt_init(). This should call the raw underlying cipher function without any padding. This will be invoked in the provider as a result of the application calling EVP_Cipher (3). The application is responsible for ensuring that the input is a multiple of the block length. The data to be encrypted/decrypted will be in in, and it will be inl bytes in length. The output from the encryption/decryption should be stored in out and the amount of data stored should be put in *outl which should be no more than outsize bytes.

Cipher Parameters

See OSSL_PARAM (3) for further details on the parameters structure used by these functions.

OSSL_FUNC_cipher_get_params() gets details of the algorithm implementation and stores them in params.

OSSL_FUNC_cipher_set_ctx_params() sets cipher operation parameters for the provider side cipher context cctx to params. Any parameter settings are additional to any that were previously set. Passing NULL for params should return true.

OSSL_FUNC_cipher_get_ctx_params() gets cipher operation details details from the given provider side cipher context cctx and stores them in params. Passing NULL for params should return true.

OSSL_FUNC_cipher_gettable_params(), OSSL_FUNC_cipher_gettable_ctx_params(), and OSSL_FUNC_cipher_settable_ctx_params() all return constant OSSL_PARAM (3) arrays as descriptors of the parameters that OSSL_FUNC_cipher_get_params(), OSSL_FUNC_cipher_get_ctx_params(), and OSSL_FUNC_cipher_set_ctx_params() can handle, respectively. OSSL_FUNC_cipher_gettable_ctx_params() and OSSL_FUNC_cipher_settable_ctx_params() will return the parameters associated with the provider side context cctx in its current state if it is not NULL. Otherwise, they return the parameters associated with the provider side algorithm provctx.

Parameters currently recognised by built-in ciphers are listed in “PARAMETERS” in EVP_EncryptInit (3). Not all parameters are relevant to, or are understood by all ciphers.

RETURN VALUES

OSSL_FUNC_cipher_newctx() and OSSL_FUNC_cipher_dupctx() should return the newly created provider side cipher context, or NULL on failure.

OSSL_FUNC_cipher_encrypt_init(), OSSL_FUNC_cipher_decrypt_init(), OSSL_FUNC_cipher_update(), OSSL_FUNC_cipher_final(), OSSL_FUNC_cipher_cipher(), OSSL_FUNC_cipher_get_params(), OSSL_FUNC_cipher_get_ctx_params() and OSSL_FUNC_cipher_set_ctx_params() should return 1 for success or 0 on error.

OSSL_FUNC_cipher_gettable_params(), OSSL_FUNC_cipher_gettable_ctx_params() and OSSL_FUNC_cipher_settable_ctx_params() should return a constant OSSL_PARAM (3) array, or NULL if none is offered.

SEE ALSO

provider (7), OSSL_PROVIDER-FIPS (7), OSSL_PROVIDER-default (7), OSSL_PROVIDER-legacy (7), EVP_CIPHER-AES (7), EVP_CIPHER-ARIA (7), EVP_CIPHER-BLOWFISH (7), EVP_CIPHER-CAMELLIA (7), EVP_CIPHER-CAST (7), EVP_CIPHER-CHACHA (7), EVP_CIPHER-DES (7), EVP_CIPHER-IDEA (7), EVP_CIPHER-RC2 (7), EVP_CIPHER-RC4 (7), EVP_CIPHER-RC5 (7), EVP_CIPHER-SEED (7), EVP_CIPHER-SM4 (7), EVP_CIPHER-NULL (7), life_cycle-cipher (7), EVP_EncryptInit (3)

HISTORY

The provider CIPHER interface was introduced in OpenSSL 3.0.

COPYRIGHT

Copyright 2019-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

199 - Linux cli command EVP_KEYMGMT-ECssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KEYMGMT-ECssl and provides detailed information about the command EVP_KEYMGMT-ECssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KEYMGMT-ECssl.

NAME 🖥️ EVP_KEYMGMT-ECssl 🖥️

EC, EVP_KEYMGMT-EC - EVP_PKEY EC keytype and algorithm support

DESCRIPTION

The EC keytype is implemented in OpenSSL’s default provider.

Common EC parameters

The normal way of specifying domain parameters for an EC curve is via the curve name “group”. For curves with no curve name, explicit parameters can be used that specify “field-type”, “p”, “a”, “b”, “generator” and “order”. Explicit parameters are supported for backwards compatibility reasons, but they are not compliant with multiple standards (including RFC5915) which only allow named curves.

The following KeyGen/Gettable/Import/Export types are available for the built-in EC algorithm:

“group” (OSSL_PKEY_PARAM_GROUP_NAME) <UTF8 string>
The curve name.

“field-type” (OSSL_PKEY_PARAM_EC_FIELD_TYPE) <UTF8 string>
The value should be either “prime-field” or “characteristic-two-field”, which correspond to prime field Fp and binary field F2^m.

“p” (OSSL_PKEY_PARAM_EC_P) <unsigned integer>
For a curve over Fp p is the prime for the field. For a curve over F2^m p represents the irreducible polynomial - each bit represents a term in the polynomial. Therefore, there will either be three or five bits set dependent on whether the polynomial is a trinomial or a pentanomial.

“a” (OSSL_PKEY_PARAM_EC_A) <unsigned integer>

“b” (OSSL_PKEY_PARAM_EC_B) <unsigned integer>

“seed” (OSSL_PKEY_PARAM_EC_SEED) <octet string>

a and b represents the coefficients of the curve For Fp: y^2 mod p = x^3 +ax + b mod p OR For F2^m: y^2 + xy = x^3 + ax^2 + b seed is an optional value that is for information purposes only. It represents the random number seed used to generate the coefficient b from a random number.

“generator” (OSSL_PKEY_PARAM_EC_GENERATOR) <octet string>

“order” (OSSL_PKEY_PARAM_EC_ORDER) <unsigned integer>

“cofactor” (OSSL_PKEY_PARAM_EC_COFACTOR) <unsigned integer>

The generator is a well defined point on the curve chosen for cryptographic operations. The encoding conforms with Sec. 2.3.3 of the SECG SEC 1 (“Elliptic Curve Cryptography”) standard. See EC_POINT_oct2point(). Integers used for point multiplications will be between 0 and order - 1. cofactor is an optional value. order multiplied by the cofactor gives the number of points on the curve.

“decoded-from-explicit” (OSSL_PKEY_PARAM_EC_DECODED_FROM_EXPLICIT_PARAMS) <integer>
Gets a flag indicating whether the key or parameters were decoded from explicit curve parameters. Set to 1 if so or 0 if a named curve was used.

“use-cofactor-flag” (OSSL_PKEY_PARAM_USE_COFACTOR_ECDH) <integer>
Enable Cofactor DH (ECC CDH) if this value is 1, otherwise it uses normal EC DH if the value is zero. The cofactor variant multiplies the shared secret by the EC curve’s cofactor (note for some curves the cofactor is 1). See also EVP_KEYEXCH-ECDH (7) for the related OSSL_EXCHANGE_PARAM_EC_ECDH_COFACTOR_MODE parameter that can be set on a per-operation basis.

“encoding” (OSSL_PKEY_PARAM_EC_ENCODING) <UTF8 string>
Set the format used for serializing the EC group parameters. Valid values are “explicit” or “named_curve”. The default value is “named_curve”.

“point-format” (OSSL_PKEY_PARAM_EC_POINT_CONVERSION_FORMAT) <UTF8 string>
Sets or gets the point_conversion_form for the key. For a description of point_conversion_forms please see EC_POINT_new (3). Valid values are “uncompressed” or “compressed”. The default value is “uncompressed”.

“group-check” (OSSL_PKEY_PARAM_EC_GROUP_CHECK_TYPE) <UTF8 string>
Sets or Gets the type of group check done when EVP_PKEY_param_check() is called. Valid values are “default”, “named” and “named-nist”. The “named” type checks that the domain parameters match the inbuilt curve parameters, “named-nist” is similar but also checks that the named curve is a nist curve. The “default” type does domain parameter validation for the OpenSSL default provider, but is equivalent to “named-nist” for the OpenSSL FIPS provider.

“include-public” (OSSL_PKEY_PARAM_EC_INCLUDE_PUBLIC) <integer>
Setting this value to 0 indicates that the public key should not be included when encoding the private key. The default value of 1 will include the public key.

“pub” (OSSL_PKEY_PARAM_PUB_KEY) <octet string>
The public key value in encoded EC point format conforming to Sec. 2.3.3 and 2.3.4 of the SECG SEC 1 (“Elliptic Curve Cryptography”) standard. This parameter is used when importing or exporting the public key value with the EVP_PKEY_fromdata() and EVP_PKEY_todata() functions. Note, in particular, that the choice of point compression format used for encoding the exported value via EVP_PKEY_todata() depends on the underlying provider implementation. Before OpenSSL 3.0.8, the implementation of providers included with OpenSSL always opted for an encoding in compressed format, unconditionally. Since OpenSSL 3.0.8, the implementation has been changed to honor the OSSL_PKEY_PARAM_EC_POINT_CONVERSION_FORMAT parameter, if set, or to default to uncompressed format.

“priv” (OSSL_PKEY_PARAM_PRIV_KEY) <unsigned integer>
The private key value.

“encoded-pub-key” (OSSL_PKEY_PARAM_ENCODED_PUBLIC_KEY) <octet string>
Used for getting and setting the encoding of an EC public key. The public key is expected to be a point conforming to Sec. 2.3.4 of the SECG SEC 1 (“Elliptic Curve Cryptography”) standard.

“qx” (OSSL_PKEY_PARAM_EC_PUB_X) <unsigned integer>
Used for getting the EC public key X component.

“qy” (OSSL_PKEY_PARAM_EC_PUB_Y) <unsigned integer>
Used for getting the EC public key Y component.

“default-digest” (OSSL_PKEY_PARAM_DEFAULT_DIGEST) <UTF8 string>
Getter that returns the default digest name. (Currently returns “SHA256” as of OpenSSL 3.0).

“dhkem-ikm” (OSSL_PKEY_PARAM_DHKEM_IKM) <octet string>
DHKEM requires the generation of a keypair using an input key material (seed). Use this to specify the key material used for generation of the private key. This value should not be reused for other purposes. It can only be used for the curves “P-256”, “P-384” and “P-521” and should have a length of at least the size of the encoded private key (i.e. 32, 48 and 66 for the listed curves).

The following Gettable types are also available for the built-in EC algorithm:

“basis-type” (OSSL_PKEY_PARAM_EC_CHAR2_TYPE) <UTF8 string>
Supports the values “tpBasis” for a trinomial or “ppBasis” for a pentanomial. This field is only used for a binary field F2^m.

“m” (OSSL_PKEY_PARAM_EC_CHAR2_M) <integer>

“tp” (OSSL_PKEY_PARAM_EC_CHAR2_TP_BASIS) <integer>

“k1” (OSSL_PKEY_PARAM_EC_CHAR2_PP_K1) <integer>

“k2” (OSSL_PKEY_PARAM_EC_CHAR2_PP_K2) <integer>

“k3” (OSSL_PKEY_PARAM_EC_CHAR2_PP_K3) <integer>

These fields are only used for a binary field F2^m. m is the degree of the binary field. tp is the middle bit of a trinomial so its value must be in the range m > tp > 0. k1, k2 and k3 are used to get the middle bits of a pentanomial such that m > k3 > k2 > k1 > 0

EC key validation

For EC keys, EVP_PKEY_param_check (3) behaves in the following way: For the OpenSSL default provider it uses either EC_GROUP_check (3) or EC_GROUP_check_named_curve (3) depending on the flag EC_FLAG_CHECK_NAMED_GROUP. The OpenSSL FIPS provider uses EC_GROUP_check_named_curve (3) in order to conform to SP800-56Ar3 Assurances of Domain-Parameter Validity.

For EC keys, EVP_PKEY_param_check_quick (3) is equivalent to EVP_PKEY_param_check (3).

For EC keys, EVP_PKEY_public_check (3) and EVP_PKEY_public_check_quick (3) conform to SP800-56Ar3 ECC Full Public-Key Validation and ECC Partial Public-Key Validation respectively.

For EC Keys, EVP_PKEY_private_check (3) and EVP_PKEY_pairwise_check (3) conform to SP800-56Ar3 Private key validity and Owner Assurance of Pair-wise Consistency respectively.

EXAMPLES

An EVP_PKEY context can be obtained by calling:

EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “EC”, NULL);

An EVP_PKEY ECDSA or ECDH key can be generated with a “P-256” named group by calling:

pkey = EVP_EC_gen(“P-256”);

or like this:

EVP_PKEY *key = NULL; OSSL_PARAM params[2]; EVP_PKEY_CTX *gctx = EVP_PKEY_CTX_new_from_name(NULL, “EC”, NULL); EVP_PKEY_keygen_init(gctx); params[0] = OSSL_PARAM_construct_utf8_string(OSSL_PKEY_PARAM_GROUP_NAME, “P-256”, 0); params[1] = OSSL_PARAM_construct_end(); EVP_PKEY_CTX_set_params(gctx, params); EVP_PKEY_generate(gctx, &key); EVP_PKEY_print_private(bio_out, key, 0, NULL); … EVP_PKEY_free(key); EVP_PKEY_CTX_free(gctx);

An EVP_PKEY EC CDH (Cofactor Diffie-Hellman) key can be generated with a “K-571” named group by calling:

int use_cdh = 1; EVP_PKEY *key = NULL; OSSL_PARAM params[3]; EVP_PKEY_CTX *gctx = EVP_PKEY_CTX_new_from_name(NULL, “EC”, NULL); EVP_PKEY_keygen_init(gctx); params[0] = OSSL_PARAM_construct_utf8_string(OSSL_PKEY_PARAM_GROUP_NAME, “K-571”, 0); /* * This curve has a cofactor that is not 1 - so setting CDH mode changes * the behaviour. For many curves the cofactor is 1 - so setting this has * no effect. */ params[1] = OSSL_PARAM_construct_int(OSSL_PKEY_PARAM_USE_COFACTOR_ECDH, &use_cdh); params[2] = OSSL_PARAM_construct_end(); EVP_PKEY_CTX_set_params(gctx, params); EVP_PKEY_generate(gctx, &key); EVP_PKEY_print_private(bio_out, key, 0, NULL); … EVP_PKEY_free(key); EVP_PKEY_CTX_free(gctx);

SEE ALSO

EVP_EC_gen (3), EVP_KEYMGMT (3), EVP_PKEY (3), provider-keymgmt (7), EVP_SIGNATURE-ECDSA (7), EVP_KEYEXCH-ECDH (7)

COPYRIGHT

Copyright 2020-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

200 - Linux cli command netdevice

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command netdevice and provides detailed information about the command netdevice, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the netdevice.

NAME 🖥️ netdevice 🖥️

low-level access to Linux network devices

SYNOPSIS

#include <sys/ioctl.h>
#include <net/if.h>

DESCRIPTION

This man page describes the sockets interface which is used to configure network devices.

Linux supports some standard ioctls to configure network devices. They can be used on any socket’s file descriptor regardless of the family or type. Most of them pass an ifreq structure:

struct ifreq {
    char ifr_name[IFNAMSIZ]; /* Interface name */
    union {
        struct sockaddr ifr_addr;
        struct sockaddr ifr_dstaddr;
        struct sockaddr ifr_broadaddr;
        struct sockaddr ifr_netmask;
        struct sockaddr ifr_hwaddr;
        short           ifr_flags;
        int             ifr_ifindex;
        int             ifr_metric;
        int             ifr_mtu;
        struct ifmap    ifr_map;
        char            ifr_slave[IFNAMSIZ];
        char            ifr_newname[IFNAMSIZ];
        char           *ifr_data;
    };
};

AF_INET6 is an exception. It passes an in6_ifreq structure:

struct in6_ifreq {
    struct in6_addr     ifr6_addr;
    u32                 ifr6_prefixlen;
    int                 ifr6_ifindex; /* Interface index */
};

Normally, the user specifies which device to affect by setting ifr_name to the name of the interface or ifr6_ifindex to the index of the interface. All other members of the structure may share memory.

Ioctls

If an ioctl is marked as privileged, then using it requires an effective user ID of 0 or the CAP_NET_ADMIN capability. If this is not the case, EPERM will be returned.

SIOCGIFNAME
Given the ifr_ifindex, return the name of the interface in ifr_name. This is the only ioctl which returns its result in ifr_name.

SIOCGIFINDEX
Retrieve the interface index of the interface into ifr_ifindex.

SIOCGIFFLAGS
SIOCSIFFLAGS
Get or set the active flag word of the device. ifr_flags contains a bit mask of the following values:

TABLE

Setting the active flag word is a privileged operation, but any process may read it.

SIOCGIFPFLAGS
SIOCSIFPFLAGS
Get or set extended (private) flags for the device. ifr_flags contains a bit mask of the following values:

TABLE

Setting the extended (private) interface flags is a privileged operation.

SIOCGIFADDR
SIOCSIFADDR
SIOCDIFADDR
Get, set, or delete the address of the device using ifr_addr, or ifr6_addr with ifr6_prefixlen. Setting or deleting the interface address is a privileged operation. For compatibility, SIOCGIFADDR returns only AF_INET addresses, SIOCSIFADDR accepts AF_INET and AF_INET6 addresses, and SIOCDIFADDR deletes only AF_INET6 addresses. A AF_INET address can be deleted by setting it to zero via SIOCSIFADDR.

SIOCGIFDSTADDR
SIOCSIFDSTADDR
Get or set the destination address of a point-to-point device using ifr_dstaddr. For compatibility, only AF_INET addresses are accepted or returned. Setting the destination address is a privileged operation.

SIOCGIFBRDADDR
SIOCSIFBRDADDR
Get or set the broadcast address for a device using ifr_brdaddr. For compatibility, only AF_INET addresses are accepted or returned. Setting the broadcast address is a privileged operation.

SIOCGIFNETMASK
SIOCSIFNETMASK
Get or set the network mask for a device using ifr_netmask. For compatibility, only AF_INET addresses are accepted or returned. Setting the network mask is a privileged operation.

SIOCGIFMETRIC
SIOCSIFMETRIC
Get or set the metric of the device using ifr_metric. This is currently not implemented; it sets ifr_metric to 0 if you attempt to read it and returns EOPNOTSUPP if you attempt to set it.

SIOCGIFMTU
SIOCSIFMTU
Get or set the MTU (Maximum Transfer Unit) of a device using ifr_mtu. Setting the MTU is a privileged operation. Setting the MTU to too small values may cause kernel crashes.

SIOCGIFHWADDR
SIOCSIFHWADDR
Get or set the hardware address of a device using ifr_hwaddr. The hardware address is specified in a struct sockaddr. sa_family contains the ARPHRD_* device type, sa_data the L2 hardware address starting from byte 0. Setting the hardware address is a privileged operation.

SIOCSIFHWBROADCAST
Set the hardware broadcast address of a device from ifr_hwaddr. This is a privileged operation.

SIOCGIFMAP
SIOCSIFMAP
Get or set the interface’s hardware parameters using ifr_map. Setting the parameters is a privileged operation.

struct ifmap {
    unsigned long   mem_start;
    unsigned long   mem_end;
    unsigned short  base_addr;
    unsigned char   irq;
    unsigned char   dma;
    unsigned char   port;
};

The interpretation of the ifmap structure depends on the device driver and the architecture.

SIOCADDMULTI
SIOCDELMULTI
Add an address to or delete an address from the device’s link layer multicast filters using ifr_hwaddr. These are privileged operations. See also packet(7) for an alternative.

SIOCGIFTXQLEN
SIOCSIFTXQLEN
Get or set the transmit queue length of a device using ifr_qlen. Setting the transmit queue length is a privileged operation.

SIOCSIFNAME
Changes the name of the interface specified in ifr_name to ifr_newname. This is a privileged operation. It is allowed only when the interface is not up.

SIOCGIFCONF
Return a list of interface (network layer) addresses. This currently means only addresses of the AF_INET (IPv4) family for compatibility. Unlike the others, this ioctl passes an ifconf structure:

struct ifconf {
    int               ifc_len; /* size of buffer */
    union {
        char         *ifc_buf; /* buffer address */
        struct ifreq *ifc_req; /* array of structures */
    };
};

If ifc_req is NULL, SIOCGIFCONF returns the necessary buffer size in bytes for receiving all available addresses in ifc_len. Otherwise, ifc_req contains a pointer to an array of ifreq structures to be filled with all currently active L3 interface addresses. ifc_len contains the size of the array in bytes. Within each ifreq structure, ifr_name will receive the interface name, and ifr_addr the address. The actual number of bytes transferred is returned in ifc_len.

If the size specified by ifc_len is insufficient to store all the addresses, the kernel will skip the exceeding ones and return success. There is no reliable way of detecting this condition once it has occurred. It is therefore recommended to either determine the necessary buffer size beforehand by calling SIOCGIFCONF with ifc_req set to NULL, or to retry the call with a bigger buffer whenever ifc_len upon return differs by less than sizeof(struct ifreq) from its original value.

If an error occurs accessing the ifconf or ifreq structures, EFAULT will be returned.

Most protocols support their own ioctls to configure protocol-specific interface options. See the protocol man pages for a description. For configuring IP addresses, see ip(7).

In addition, some devices support private ioctls. These are not described here.

NOTES

SIOCGIFCONF and the other ioctls that accept or return only AF_INET socket addresses are IP-specific and perhaps should rather be documented in ip(7).

The names of interfaces with no addresses or that don’t have the IFF_RUNNING flag set can be found via /proc/net/dev.

AF_INET6 IPv6 addresses can be read from /proc/net/if_inet6 or via rtnetlink(7). Adding a new IPv6 address and deleting an existing IPv6 address can be done via SIOCSIFADDR and SIOCDIFADDR or via rtnetlink(7). Retrieving or changing destination IPv6 addresses of a point-to-point interface is possible only via rtnetlink(7).

BUGS

glibc 2.1 is missing the ifr_newname macro in <net/if.h>. Add the following to your program as a workaround:

#ifndef ifr_newname
#define ifr_newname     ifr_ifru.ifru_slave
#endif

SEE ALSO

proc(5), capabilities(7), ip(7), rtnetlink(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

201 - Linux cli command systemd.generator

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command systemd.generator and provides detailed information about the command systemd.generator, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the systemd.generator.

NAME 🖥️ systemd.generator 🖥️

systemd unit generators

SYNOPSIS

/path/to/generator normal-dir [early-dir] [late-dir]

/run/systemd/system-generators/*

/etc/systemd/system-generators/*

/usr/local/lib/systemd/system-generators/*

/usr/lib/systemd/system-generators/*

/run/systemd/user-generators/*

/etc/systemd/user-generators/*

/usr/local/lib/systemd/user-generators/*

/usr/lib/systemd/user-generators/*

DESCRIPTION

Generators are small executables placed in /usr/lib/systemd/system-generators/ and other directories listed above. systemd(1) will execute these binaries very early at bootup and at configuration reload time — before unit files are loaded. Their main purpose is to convert configuration and execution context parameters that are not native to the service manager into dynamically generated unit files, symlinks or unit file drop-ins, so that they can extend the unit file hierarchy the service manager subsequently loads and operates on.

systemd will call each generator with three directory paths that are to be used for generator output. In these three directories, generators may dynamically generate unit files (regular ones, instances, as well as templates), unit file .d/ drop-ins, and create symbolic links to unit files to add additional dependencies, create aliases, or instantiate existing templates. Those directories are included in the unit load path, allowing generated configuration to extend or override existing definitions. For tests, generators may be called with just one argument; the generator should assume that all three paths are the same in that case.

Directory paths for generator output differ by priority: …/generator.early has priority higher than the admin configuration in /etc/, while …/generator has lower priority than /etc/ but higher than vendor configuration in /usr/, and …/generator.late has priority lower than all other configuration. See the next section and the discussion of unit load paths and unit overriding in systemd.unit(5).

Generators are loaded from a set of paths determined during compilation, as listed above. System and user generators are loaded from directories with names ending in system-generators/ and user-generators/, respectively. Generators found in directories listed earlier override the ones with the same name in directories lower in the list [1]. A symlink to /dev/null or an empty file can be used to mask a generator, thereby preventing it from running. Please note that the order of the two directories with the highest priority is reversed with respect to the unit load path, and generators in /run/ overwrite those in /etc/.

After installing new generators or updating the configuration, systemctl daemon-reload may be executed. This will delete the previous configuration created by generators, re-run all generators, and cause systemd to reload units from disk. See systemctl(1) for more information.

OUTPUT DIRECTORIES

Generators are invoked with three arguments: paths to directories where generators can place their generated unit files or symlinks. By default those paths are runtime directories that are included in the search path of systemd, but a generator may be called with different paths for debugging purposes. If only one argument is provided, the generator should use the same directory as the three output paths.

1.

normal-dir

In normal use this is /run/systemd/generator in case of the system generators and $XDG_RUNTIME_DIR/systemd/generator in case of the user generators. Unit files placed in this directory take precedence over vendor unit configuration but not over native user/administrator unit configuration.

2.

early-dir

In normal use this is /run/systemd/generator.early in case of the system generators and $XDG_RUNTIME_DIR/systemd/generator.early in case of the user generators. Unit files placed in this directory override unit files in /usr/, /run/ and /etc/. This means that unit files placed in this directory take precedence over all normal configuration, both vendor and user/administrator.

3.

late-dir

In normal use this is /run/systemd/generator.late in case of the system generators and $XDG_RUNTIME_DIR/systemd/generator.late in case of the user generators. This directory may be used to extend the unit file tree without overriding any other unit files. Any native configuration files supplied by the vendor or user/administrator take precedence.

Note: generators must not write to other locations or otherwise make changes to system state. Generator output is supposed to last only until the next daemon-reload or daemon-reexec; if the generator is replaced or masked, its effects should vanish.

ENVIRONMENT

The service manager sets a number of environment variables when invoking generator executables. They carry information about the execution context of the generator, in order to simplify conditionalizing generators to specific environments. The following environment variables are set:

$SYSTEMD_SCOPE

If the generator is invoked from the system service manager this variable is set to “system”; if invoked from the per-user service manager it is set to “user”.

Added in version 251.

$SYSTEMD_IN_INITRD

If the generator is run as part of an initrd this is set to “1”. If it is run from the regular host (i.e. after the transition from initrd to host) it is set to “0”. This environment variable is only set for system generators.

Added in version 251.

$SYSTEMD_FIRST_BOOT

If this boot-up cycle is considered a “first boot”, this is set to “1”; if it is a subsequent, regular boot it is set to “0”. For details see the documentation of ConditionFirstBoot= in systemd.unit(5). This environment variable is only set for system generators.

Added in version 251.

$SYSTEMD_VIRTUALIZATION

If the service manager is run in a virtualized environment, $SYSTEMD_VIRTUALIZATION is set to a pair of strings, separated by a colon. The first string is either “vm” or “container”, categorizing the type of virtualization. The second string identifies the implementation of the virtualization technology. If no virtualization is detected this variable will not be set. This data is identical to what systemd-detect-virt(1) detects and reports, and uses the same vocabulary of virtualization implementation identifiers.

Added in version 251.

$SYSTEMD_ARCHITECTURE

This variable is set to a short identifier of the reported architecture of the system. For details about defined values, see documentation of ConditionArchitecture= in systemd.unit(5).

Added in version 251.

$CREDENTIALS_DIRECTORY, $ENCRYPTED_CREDENTIALS_DIRECTORY

If set, refers to the directory system credentials have been placed in. Credentials passed into the system in plaintext form will be placed in $CREDENTIALS_DIRECTORY, and those passed in in encrypted form will be placed in $ENCRYPTED_CREDENTIALS_DIRECTORY. Use the systemd-creds(1) command to automatically decrypt/authenticate credentials passed in, if needed. Specifically, use the systemd-creds –system cat command.

Added in version 254.

$SYSTEMD_CONFIDENTIAL_VIRTUALIZATION

If the service manager is run in a confidential virtualized environment, $SYSTEMD_CONFIDENTIAL_VIRTUALIZATION is set to a string that identifies the confidential virtualization hardware technology. If no confidential virtualization is detected this variable will not be set. This data is identical to what systemd-detect-virt(1) detects and reports, and uses the same vocabulary of confidential virtualization technology identifiers.

Added in version 254.

NOTES ABOUT WRITING GENERATORS

·

All generators are executed in parallel. That means all executables are started at the very same time and need to be able to cope with this parallelism.

·

Generators are run very early at boot and cannot rely on any external services. They may not talk to any other process. That includes simple things such as logging to syslog(3), or systemd itself (this means: no systemctl(1))! Non-essential file systems like /var/ and /home/ are mounted after generators have run. Generators can however rely on the most basic kernel functionality to be available, as well as mounted /sys/, /proc/, /dev/, /usr/ and /run/ file systems.

·

Units written by generators are removed when the configuration is reloaded. That means the lifetime of the generated units is closely bound to the reload cycles of systemd itself.

·

Generators should only be used to generate unit files, .d/*.conf drop-ins for them and symlinks to them, not any other kind of non-unit related configuration. Due to the lifecycle logic mentioned above, generators are not a good fit to generate dynamic configuration for other services. If you need to generate dynamic configuration for other services, do so in normal services you order before the service in question.

Note that using the StandardInputData=/StandardInputText= settings of service unit files (see systemd.exec(5)), it is possible to make arbitrary input data (including daemon-specific configuration) part of the unit definitions, which often might be sufficient to embed data or configuration for other programs into unit files in a native fashion.

·

Since syslog(3) is not available (see above), log messages have to be written to /dev/kmsg instead.

·

The generator should always include its own name in a comment at the top of the generated file, so that the user can easily figure out which component created or amended a particular unit.

The SourcePath= directive should be used in generated files to specify the source configuration file they are generated from. This makes things more easily understood by the user and also has the benefit that systemd can warn the user about configuration files that changed on disk but have not been read yet by systemd. The SourcePath= value does not have to be a file in a physical filesystem. For example, in the common case of the generator looking at the kernel command line, SourcePath=/proc/cmdline should be used.

·

Generators may write out dynamic unit files or just hook unit files into other units with the usual .wants/ or .requires/ symlinks. Often, it is nicer to simply instantiate a template unit file from /usr/ with a generator instead of writing out entirely dynamic unit files. Of course, this works only if a single parameter is to be used.

·

If you are careful, you can implement generators in shell scripts. We do recommend C code however, since generators are executed synchronously and hence delay the entire boot if they are slow.

·

Regarding overriding semantics: there are two rules we try to follow when thinking about the overriding semantics:

1.

User configuration should override vendor configuration. This (mostly) means that stuff from /etc/ should override stuff from /usr/.

2.

Native configuration should override non-native configuration. This (mostly) means that stuff you generate should never override native unit files for the same purpose.

Of these two rules the first rule is probably the more important one and breaks the second one sometimes. Hence, when deciding whether to use argv[1], argv[2], or argv[3], your default choice should probably be argv[1].

·

Instead of heading off now and writing all kind of generators for legacy configuration file formats, please think twice! It is often a better idea to just deprecate old stuff instead of keeping it artificially alive.

EXAMPLES

Example 1. systemd-fstab-generator

systemd-fstab-generator(8) converts /etc/fstab into native mount units. It uses argv[1] as location to place the generated unit files in order to allow the user to override /etc/fstab with their own native unit files, but also to ensure that /etc/fstab overrides any vendor default from /usr/.

After editing /etc/fstab, the user should invoke systemctl daemon-reload. This will re-run all generators and cause systemd to reload units from disk. To actually mount new directories added to fstab, systemctl start /path/to/mountpoint or systemctl start local-fs.target may be used.

Example 2. systemd-system-update-generator

systemd-system-update-generator(8) temporarily redirects default.target to system-update.target, if a system update is scheduled. Since this needs to override the default user configuration for default.target, it uses argv[2]. For details about this logic, see systemd.offline-updates(7).

Example 3. Debugging a generator

dir=$(mktemp -d) SYSTEMD_LOG_LEVEL=debug /usr/lib/systemd/system-generators/systemd-fstab-generator
“$dir” “$dir” “$dir” find $dir

SEE ALSO

systemd(1), systemd-cryptsetup-generator(8), systemd-debug-generator(8), systemd-fstab-generator(8), fstab(5), systemd-getty-generator(8), systemd-gpt-auto-generator(8), systemd-hibernate-resume-generator(8), systemd-rc-local-generator(8), systemd-system-update-generator(8), systemd-sysv-generator(8), systemd-xdg-autostart-generator(8), systemd.unit(5), systemctl(1), systemd.environment-generator(7)

NOTES

💣💥🧨💥💥💣 Please note that those configuration files must be available at all times. If /usr/local/ is a separate partition, it may not be available during early boot, and must not be used for configuration.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

202 - Linux cli command ALTER_GROUP

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_GROUP and provides detailed information about the command ALTER_GROUP, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_GROUP.

NAME 🖥️ ALTER_GROUP 🖥️

change role name or membership

SYNOPSIS

ALTER GROUP role_specification ADD USER user_name [, ... ]
ALTER GROUP role_specification DROP USER user_name [, ... ]

where role_specification can be:

    role_name
  | CURRENT_ROLE
  | CURRENT_USER
  | SESSION_USER

ALTER GROUP group_name RENAME TO new_name

DESCRIPTION

ALTER GROUP changes the attributes of a user group. This is an obsolete command, though still accepted for backwards compatibility, because groups (and users too) have been superseded by the more general concept of roles.

The first two variants add users to a group or remove them from a group. (Any role can play the part of either a “user” or a “group” for this purpose.) These variants are effectively equivalent to granting or revoking membership in the role named as the “group”; so the preferred way to do this is to use GRANT or REVOKE. Note that GRANT and REVOKE have additional options which are not available with this command, such as the ability to grant and revoke ADMIN OPTION, and the ability to specify the grantor.

The third variant changes the name of the group. This is exactly equivalent to renaming the role with ALTER ROLE.

PARAMETERS

group_name

The name of the group (role) to modify.

user_name

Users (roles) that are to be added to or removed from the group. The users must already exist; ALTER GROUP does not create or drop users.

new_name

The new name of the group.

EXAMPLES

Add users to a group:

ALTER GROUP staff ADD USER karl, john;

Remove a user from a group:

ALTER GROUP workers DROP USER beth;

COMPATIBILITY

There is no ALTER GROUP statement in the SQL standard.

SEE ALSO

GRANT(7), REVOKE(7), ALTER ROLE (ALTER_ROLE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

203 - Linux cli command CREATE_VIEW

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_VIEW and provides detailed information about the command CREATE_VIEW, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_VIEW.

NAME 🖥️ CREATE_VIEW 🖥️

define a new view

SYNOPSIS

CREATE [ OR REPLACE ] [ TEMP | TEMPORARY ] [ RECURSIVE ] VIEW name [ ( column_name [, ...] ) ]
    [ WITH ( view_option_name [= view_option_value] [, ... ] ) ]
    AS query
    [ WITH [ CASCADED | LOCAL ] CHECK OPTION ]

DESCRIPTION

CREATE VIEW defines a view of a query. The view is not physically materialized. Instead, the query is run every time the view is referenced in a query.

CREATE OR REPLACE VIEW is similar, but if a view of the same name already exists, it is replaced. The new query must generate the same columns that were generated by the existing view query (that is, the same column names in the same order and with the same data types), but it may add additional columns to the end of the list. The calculations giving rise to the output columns may be completely different.

If a schema name is given (for example, CREATE VIEW myschema.myview …) then the view is created in the specified schema. Otherwise it is created in the current schema. Temporary views exist in a special schema, so a schema name cannot be given when creating a temporary view. The name of the view must be distinct from the name of any other relation (table, sequence, index, view, materialized view, or foreign table) in the same schema.

PARAMETERS

TEMPORARY or TEMP

If specified, the view is created as a temporary view. Temporary views are automatically dropped at the end of the current session. Existing permanent relations with the same name are not visible to the current session while the temporary view exists, unless they are referenced with schema-qualified names.

If any of the tables referenced by the view are temporary, the view is created as a temporary view (whether TEMPORARY is specified or not).

RECURSIVE

Creates a recursive view. The syntax

CREATE RECURSIVE VIEW [ schema . ] view_name (column_names) AS SELECT …;

is equivalent to

CREATE VIEW [ schema . ] view_name AS WITH RECURSIVE view_name (column_names) AS (SELECT …) SELECT column_names FROM view_name;

A view column name list must be specified for a recursive view.

name

The name (optionally schema-qualified) of a view to be created.

column_name

An optional list of names to be used for columns of the view. If not given, the column names are deduced from the query.

WITH ( view_option_name [= view_option_value] [, … ] )

This clause specifies optional parameters for a view; the following parameters are supported:

check_option (enum)

This parameter may be either local or cascaded, and is equivalent to specifying WITH [ CASCADED | LOCAL ] CHECK OPTION (see below).

security_barrier (boolean)

This should be used if the view is intended to provide row-level security. See Section 41.5 for full details.

security_invoker (boolean)

This option causes the underlying base relations to be checked against the privileges of the user of the view rather than the view owner. See the notes below for full details.

All of the above options can be changed on existing views using ALTER VIEW.

query

A SELECT or VALUES command which will provide the columns and rows of the view.

WITH [ CASCADED | LOCAL ] CHECK OPTION

This option controls the behavior of automatically updatable views. When this option is specified, INSERT and UPDATE commands on the view will be checked to ensure that new rows satisfy the view-defining condition (that is, the new rows are checked to ensure that they are visible through the view). If they are not, the update will be rejected. If the CHECK OPTION is not specified, INSERT and UPDATE commands on the view are allowed to create rows that are not visible through the view. The following check options are supported:

LOCAL

New rows are only checked against the conditions defined directly in the view itself. Any conditions defined on underlying base views are not checked (unless they also specify the CHECK OPTION).

CASCADED

New rows are checked against the conditions of the view and all underlying base views. If the CHECK OPTION is specified, and neither LOCAL nor CASCADED is specified, then CASCADED is assumed.

The CHECK OPTION may not be used with RECURSIVE views.

Note that the CHECK OPTION is only supported on views that are automatically updatable, and do not have INSTEAD OF triggers or INSTEAD rules. If an automatically updatable view is defined on top of a base view that has INSTEAD OF triggers, then the LOCAL CHECK OPTION may be used to check the conditions on the automatically updatable view, but the conditions on the base view with INSTEAD OF triggers will not be checked (a cascaded check option will not cascade down to a trigger-updatable view, and any check options defined directly on a trigger-updatable view will be ignored). If the view or any of its base relations has an INSTEAD rule that causes the INSERT or UPDATE command to be rewritten, then all check options will be ignored in the rewritten query, including any checks from automatically updatable views defined on top of the relation with the INSTEAD rule.

NOTES

Use the DROP VIEW statement to drop views.

Be careful that the names and types of the views columns will be assigned the way you want. For example:

CREATE VIEW vista AS SELECT Hello World;

is bad form because the column name defaults to ?column?; also, the column data type defaults to text, which might not be what you wanted. Better style for a string literal in a views result is something like:

CREATE VIEW vista AS SELECT text Hello World AS hello;

By default, access to the underlying base relations referenced in the view is determined by the permissions of the view owner. In some cases, this can be used to provide secure but restricted access to the underlying tables. However, not all views are secure against tampering; see Section 41.5 for details.

If the view has the security_invoker property set to true, access to the underlying base relations is determined by the permissions of the user executing the query, rather than the view owner. Thus, the user of a security invoker view must have the relevant permissions on the view and its underlying base relations.

If any of the underlying base relations is a security invoker view, it will be treated as if it had been accessed directly from the original query. Thus, a security invoker view will always check its underlying base relations using the permissions of the current user, even if it is accessed from a view without the security_invoker property.

If any of the underlying base relations has row-level security enabled, then by default, the row-level security policies of the view owner are applied, and access to any additional relations referred to by those policies is determined by the permissions of the view owner. However, if the view has security_invoker set to true, then the policies and permissions of the invoking user are used instead, as if the base relations had been referenced directly from the query using the view.

Functions called in the view are treated the same as if they had been called directly from the query using the view. Therefore, the user of a view must have permissions to call all functions used by the view. Functions in the view are executed with the privileges of the user executing the query or the function owner, depending on whether the functions are defined as SECURITY INVOKER or SECURITY DEFINER. Thus, for example, calling CURRENT_USER directly in a view will always return the invoking user, not the view owner. This is not affected by the views security_invoker setting, and so a view with security_invoker set to false is not equivalent to a SECURITY DEFINER function and those concepts should not be confused.

The user creating or replacing a view must have USAGE privileges on any schemas referred to in the view query, in order to look up the referenced objects in those schemas. Note, however, that this lookup only happens when the view is created or replaced. Therefore, the user of the view only requires the USAGE privilege on the schema containing the view, not on the schemas referred to in the view query, even for a security invoker view.

When CREATE OR REPLACE VIEW is used on an existing view, only the views defining SELECT rule, plus any WITH ( … ) parameters and its CHECK OPTION are changed. Other view properties, including ownership, permissions, and non-SELECT rules, remain unchanged. You must own the view to replace it (this includes being a member of the owning role).

Updatable Views

Simple views are automatically updatable: the system will allow INSERT, UPDATE and DELETE statements to be used on the view in the same way as on a regular table. A view is automatically updatable if it satisfies all of the following conditions:

·

The view must have exactly one entry in its FROM list, which must be a table or another updatable view.

·

The view definition must not contain WITH, DISTINCT, GROUP BY, HAVING, LIMIT, or OFFSET clauses at the top level.

·

The view definition must not contain set operations (UNION, INTERSECT or EXCEPT) at the top level.

·

The views select list must not contain any aggregates, window functions or set-returning functions.

An automatically updatable view may contain a mix of updatable and non-updatable columns. A column is updatable if it is a simple reference to an updatable column of the underlying base relation; otherwise the column is read-only, and an error will be raised if an INSERT or UPDATE statement attempts to assign a value to it.

If the view is automatically updatable the system will convert any INSERT, UPDATE or DELETE statement on the view into the corresponding statement on the underlying base relation. INSERT statements that have an ON CONFLICT UPDATE clause are fully supported.

If an automatically updatable view contains a WHERE condition, the condition restricts which rows of the base relation are available to be modified by UPDATE and DELETE statements on the view. However, an UPDATE is allowed to change a row so that it no longer satisfies the WHERE condition, and thus is no longer visible through the view. Similarly, an INSERT command can potentially insert base-relation rows that do not satisfy the WHERE condition and thus are not visible through the view (ON CONFLICT UPDATE may similarly affect an existing row not visible through the view). The CHECK OPTION may be used to prevent INSERT and UPDATE commands from creating such rows that are not visible through the view.

If an automatically updatable view is marked with the security_barrier property then all the views WHERE conditions (and any conditions using operators which are marked as LEAKPROOF) will always be evaluated before any conditions that a user of the view has added. See Section 41.5 for full details. Note that, due to this, rows which are not ultimately returned (because they do not pass the users WHERE conditions) may still end up being locked. EXPLAIN can be used to see which conditions are applied at the relation level (and therefore do not lock rows) and which are not.

A more complex view that does not satisfy all these conditions is read-only by default: the system will not allow an insert, update, or delete on the view. You can get the effect of an updatable view by creating INSTEAD OF triggers on the view, which must convert attempted inserts, etc. on the view into appropriate actions on other tables. For more information see CREATE TRIGGER (CREATE_TRIGGER(7)). Another possibility is to create rules (see CREATE RULE (CREATE_RULE(7))), but in practice triggers are easier to understand and use correctly.

Note that the user performing the insert, update or delete on the view must have the corresponding insert, update or delete privilege on the view. In addition, by default, the views owner must have the relevant privileges on the underlying base relations, whereas the user performing the update does not need any permissions on the underlying base relations (see Section 41.5). However, if the view has security_invoker set to true, the user performing the update, rather than the view owner, must have the relevant privileges on the underlying base relations.

EXAMPLES

Create a view consisting of all comedy films:

CREATE VIEW comedies AS SELECT * FROM films WHERE kind = Comedy;

This will create a view containing the columns that are in the film table at the time of view creation. Though * was used to create the view, columns added later to the table will not be part of the view.

Create a view with LOCAL CHECK OPTION:

CREATE VIEW universal_comedies AS SELECT * FROM comedies WHERE classification = U WITH LOCAL CHECK OPTION;

This will create a view based on the comedies view, showing only films with kind = Comedy and classification = U. Any attempt to INSERT or UPDATE a row in the view will be rejected if the new row doesnt have classification = U, but the film kind will not be checked.

Create a view with CASCADED CHECK OPTION:

CREATE VIEW pg_comedies AS SELECT * FROM comedies WHERE classification = PG WITH CASCADED CHECK OPTION;

This will create a view that checks both the kind and classification of new rows.

Create a view with a mix of updatable and non-updatable columns:

CREATE VIEW comedies AS SELECT f.*, country_code_to_name(f.country_code) AS country, (SELECT avg(r.rating) FROM user_ratings r WHERE r.film_id = f.id) AS avg_rating FROM films f WHERE f.kind = Comedy;

This view will support INSERT, UPDATE and DELETE. All the columns from the films table will be updatable, whereas the computed columns country and avg_rating will be read-only.

Create a recursive view consisting of the numbers from 1 to 100:

CREATE RECURSIVE VIEW public.nums_1_100 (n) AS VALUES (1) UNION ALL SELECT n+1 FROM nums_1_100 WHERE n < 100;

Notice that although the recursive views name is schema-qualified in this CREATE, its internal self-reference is not schema-qualified. This is because the implicitly-created CTEs name cannot be schema-qualified.

COMPATIBILITY

CREATE OR REPLACE VIEW is a PostgreSQL language extension. So is the concept of a temporary view. The WITH ( … ) clause is an extension as well, as are security barrier views and security invoker views.

SEE ALSO

ALTER VIEW (ALTER_VIEW(7)), DROP VIEW (DROP_VIEW(7)), CREATE MATERIALIZED VIEW (CREATE_MATERIALIZED_VIEW(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

204 - Linux cli command CREATE_SEQUENCE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_SEQUENCE and provides detailed information about the command CREATE_SEQUENCE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_SEQUENCE.

NAME 🖥️ CREATE_SEQUENCE 🖥️

define a new sequence generator

SYNOPSIS

CREATE [ { TEMPORARY | TEMP } | UNLOGGED ] SEQUENCE [ IF NOT EXISTS ] name
    [ AS data_type ]
    [ INCREMENT [ BY ] increment ]
    [ MINVALUE minvalue | NO MINVALUE ] [ MAXVALUE maxvalue | NO MAXVALUE ]
    [ START [ WITH ] start ] [ CACHE cache ] [ [ NO ] CYCLE ]
    [ OWNED BY { table_name.column_name | NONE } ]

DESCRIPTION

CREATE SEQUENCE creates a new sequence number generator. This involves creating and initializing a new special single-row table with the name name. The generator will be owned by the user issuing the command.

If a schema name is given then the sequence is created in the specified schema. Otherwise it is created in the current schema. Temporary sequences exist in a special schema, so a schema name cannot be given when creating a temporary sequence. The sequence name must be distinct from the name of any other relation (table, sequence, index, view, materialized view, or foreign table) in the same schema.

After a sequence is created, you use the functions nextval, currval, and setval to operate on the sequence. These functions are documented in Section 9.17.

Although you cannot update a sequence directly, you can use a query like:

SELECT * FROM name;

to examine the parameters and current state of a sequence. In particular, the last_value field of the sequence shows the last value allocated by any session. (Of course, this value might be obsolete by the time its printed, if other sessions are actively doing nextval calls.)

PARAMETERS

TEMPORARY or TEMP

If specified, the sequence object is created only for this session, and is automatically dropped on session exit. Existing permanent sequences with the same name are not visible (in this session) while the temporary sequence exists, unless they are referenced with schema-qualified names.

UNLOGGED

If specified, the sequence is created as an unlogged sequence. Changes to unlogged sequences are not written to the write-ahead log. They are not crash-safe: an unlogged sequence is automatically reset to its initial state after a crash or unclean shutdown. Unlogged sequences are also not replicated to standby servers.

Unlike unlogged tables, unlogged sequences do not offer a significant performance advantage. This option is mainly intended for sequences associated with unlogged tables via identity columns or serial columns. In those cases, it usually wouldnt make sense to have the sequence WAL-logged and replicated but not its associated table.

IF NOT EXISTS

Do not throw an error if a relation with the same name already exists. A notice is issued in this case. Note that there is no guarantee that the existing relation is anything like the sequence that would have been created — it might not even be a sequence.

name

The name (optionally schema-qualified) of the sequence to be created.

data_type

The optional clause AS data_type specifies the data type of the sequence. Valid types are smallint, integer, and bigint. bigint is the default. The data type determines the default minimum and maximum values of the sequence.

increment

The optional clause INCREMENT BY increment specifies which value is added to the current sequence value to create a new value. A positive value will make an ascending sequence, a negative one a descending sequence. The default value is 1.

minvalue
NO MINVALUE

The optional clause MINVALUE minvalue determines the minimum value a sequence can generate. If this clause is not supplied or NO MINVALUE is specified, then defaults will be used. The default for an ascending sequence is 1. The default for a descending sequence is the minimum value of the data type.

maxvalue
NO MAXVALUE

The optional clause MAXVALUE maxvalue determines the maximum value for the sequence. If this clause is not supplied or NO MAXVALUE is specified, then default values will be used. The default for an ascending sequence is the maximum value of the data type. The default for a descending sequence is -1.

start

The optional clause START WITH start allows the sequence to begin anywhere. The default starting value is minvalue for ascending sequences and maxvalue for descending ones.

cache

The optional clause CACHE cache specifies how many sequence numbers are to be preallocated and stored in memory for faster access. The minimum value is 1 (only one value can be generated at a time, i.e., no cache), and this is also the default.

CYCLE
NO CYCLE

The CYCLE option allows the sequence to wrap around when the maxvalue or minvalue has been reached by an ascending or descending sequence respectively. If the limit is reached, the next number generated will be the minvalue or maxvalue, respectively.

If NO CYCLE is specified, any calls to nextval after the sequence has reached its maximum value will return an error. If neither CYCLE or NO CYCLE are specified, NO CYCLE is the default.

OWNED BY table_name.column_name
OWNED BY NONE

The OWNED BY option causes the sequence to be associated with a specific table column, such that if that column (or its whole table) is dropped, the sequence will be automatically dropped as well. The specified table must have the same owner and be in the same schema as the sequence. OWNED BY NONE, the default, specifies that there is no such association.

NOTES

Use DROP SEQUENCE to remove a sequence.

Sequences are based on bigint arithmetic, so the range cannot exceed the range of an eight-byte integer (-9223372036854775808 to 9223372036854775807).

Because nextval and setval calls are never rolled back, sequence objects cannot be used if “gapless” assignment of sequence numbers is needed. It is possible to build gapless assignment by using exclusive locking of a table containing a counter; but this solution is much more expensive than sequence objects, especially if many transactions need sequence numbers concurrently.

Unexpected results might be obtained if a cache setting greater than one is used for a sequence object that will be used concurrently by multiple sessions. Each session will allocate and cache successive sequence values during one access to the sequence object and increase the sequence objects last_value accordingly. Then, the next cache-1 uses of nextval within that session simply return the preallocated values without touching the sequence object. So, any numbers allocated but not used within a session will be lost when that session ends, resulting in “holes” in the sequence.

Furthermore, although multiple sessions are guaranteed to allocate distinct sequence values, the values might be generated out of sequence when all the sessions are considered. For example, with a cache setting of 10, session A might reserve values 1..10 and return nextval=1, then session B might reserve values 11..20 and return nextval=11 before session A has generated nextval=2. Thus, with a cache setting of one it is safe to assume that nextval values are generated sequentially; with a cache setting greater than one you should only assume that the nextval values are all distinct, not that they are generated purely sequentially. Also, last_value will reflect the latest value reserved by any session, whether or not it has yet been returned by nextval.

Another consideration is that a setval executed on such a sequence will not be noticed by other sessions until they have used up any preallocated values they have cached.

EXAMPLES

Create an ascending sequence called serial, starting at 101:

CREATE SEQUENCE serial START 101;

Select the next number from this sequence:

SELECT nextval(serial);

 nextval
---------
     101

Select the next number from this sequence:

SELECT nextval(serial);

 nextval
---------
     102

Use this sequence in an INSERT command:

INSERT INTO distributors VALUES (nextval(serial), nothing);

Update the sequence value after a COPY FROM:

BEGIN; COPY distributors FROM input_file; SELECT setval(serial, max(id)) FROM distributors; END;

COMPATIBILITY

CREATE SEQUENCE conforms to the SQL standard, with the following exceptions:

·

Obtaining the next value is done using the nextval() function instead of the standards NEXT VALUE FOR expression.

·

The OWNED BY clause is a PostgreSQL extension.

SEE ALSO

ALTER SEQUENCE (ALTER_SEQUENCE(7)), DROP SEQUENCE (DROP_SEQUENCE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

205 - Linux cli command EVP_KEM-RSAssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KEM-RSAssl and provides detailed information about the command EVP_KEM-RSAssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KEM-RSAssl.

NAME 🖥️ EVP_KEM-RSAssl 🖥️

RSA - EVP_KEM RSA keytype and algorithm support

DESCRIPTION

The RSA keytype and its parameters are described in EVP_PKEY-RSA (7). See EVP_PKEY_encapsulate (3) and EVP_PKEY_decapsulate (3) for more info.

RSA KEM parameters

“operation” (OSSL_KEM_PARAM_OPERATION) <UTF8 string>
The OpenSSL RSA Key Encapsulation Mechanism only currently supports the following operation

“RSASVE”
The encapsulate function simply generates a secret using random bytes and then encrypts the secret using the RSA public key (with no padding). The decapsulate function recovers the secret using the RSA private key.

This can be set using EVP_PKEY_CTX_set_kem_op().

CONFORMING TO

SP800-56Br2
Section 7.2.1.2 RSASVE Generate Operation (RSASVE.GENERATE). Section 7.2.1.3 RSASVE Recovery Operation (RSASVE.RECOVER).

SEE ALSO

EVP_PKEY_CTX_set_kem_op (3), EVP_PKEY_encapsulate (3), EVP_PKEY_decapsulate (3) EVP_KEYMGMT (3), EVP_PKEY (3), provider-keymgmt (7)

HISTORY

This functionality was added in OpenSSL 3.0.

COPYRIGHT

Copyright 2020 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

206 - Linux cli command systemd.v

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command systemd.v and provides detailed information about the command systemd.v, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the systemd.v.

NAME 🖥️ systemd.v 🖥️

Directory with Versioned Resources

DESCRIPTION

In various places systemd components accept paths whose trailing components have the “.v/” suffix, pointing to a directory. These components will then automatically look for suitable files inside the directory, do a version comparison and open the newest file found (by version). Available since version v256. Specifically, two expressions are supported:

·

When looking for files with a suffix .SUFFIX, and a path …PATH/NAME.SUFFIX.v/ is specified, then all files …PATH/NAME.SUFFIX.v/NAME_*.SUFFIX are enumerated, filtered, sorted and the newest file used. The primary sorting key is the variable part, here indicated by the wildcard “*”.

·

When a path …PATH.v/NAME___.SUFFIX is specified (i.e. the penultimate component of the path ends in “.v” and the final component contains a triple underscore), then all files …PATH.v/NAME_*.SUFFIX are enumerated, filtered, sorted and the newest file used (again, by the variable part, here indicated by the wildcard “*”).

To illustrate this in an example, consider a directory /var/lib/machines/mymachine.raw.v/, which is populated with three files:

·

mymachine_7.5.13.raw

·

mymachine_7.5.14.raw

·

mymachine_7.6.0.raw

Invoke a tool such as systemd-nspawn(1) with a command line like the following:

systemd-nspawn –image=/var/lib/machines/mymachine.raw.v –boot

Then this would automatically be resolved to the equivalent of:

systemd-nspawn –image=/var/lib/machines/mymachine.raw.v/mymachine_7.6.0.raw –boot

Much of systemds functionality that expects a path to a disk image or OS directory hierarchy support the “.v/” versioned directory mechanism, for example systemd-nspawn(1), systemd-dissect(1) or the RootDirectory=/RootImage= settings of service files (see systemd.exec(5)).

Use the systemd-vpick(1) tool to resolve “.v/” paths from the command line, for example for usage in shell scripts.

FILTERING AND SORTING

The variable part of the filenames in the “.v/” directories are filtered and compared primarily with a version comparison, implementing Version Format Specification[1]. However, additional rules apply:

·

If the variable part is suffixed by one or two integer values (“tries left” and “tries done”) in the formats +LEFT or +LEFT-DONE, then these indicate usage attempt counters. The idea is that each time before a file is attempted to be used, its “tries left” counter is decreased, and the “tries done” counter increased (simply by renaming the file). When the file is successfully used (which for example could mean for an OS image: successfully booted) the counters are removed from the file name, indicating that the file has been validated to work correctly. This mechanism mirrors the boot assessment counters defined by Automatic Boot Assessment[2]. Any filenames with no boot counters or with a non-zero “tries left” counter are sorted before filenames with a zero “tries left” counter.

·

Preceding the use counters (if they are specified), an optional CPU architecture identifier may be specified in the filename (separated from the version with an underscore), as defined in the architecture vocabulary of the ConditionArchitecture= unit file setting, as documented in systemd.unit(5). Files whose name indicates an architecture not supported locally are filtered and not considered for the version comparison.

·

The rest of the variable part is the version string.

Or in other words, the files in the “.v/” directories should follow one of these naming structures:

·

NAME_VERSION.SUFFIX

·

NAME_VERSION_ARCHITECTURE.SUFFIX

·

NAME_VERSION+LEFT.SUFFIX

·

NAME_VERSION+LEFT-DONE.SUFFIX

·

NAME_VERSION_ARCHITECTURE+LEFT.SUFFIX

·

NAME_VERSION_ARCHITECTURE+LEFT-DONE.SUFFIX

EXAMPLE

Heres a more comprehensive example, further extending the one described above. Consider a directory /var/lib/machines/mymachine.raw.v/, which is populated with the following files:

·

mymachine_7.5.13.raw

·

mymachine_7.5.14_x86-64.raw

·

mymachine_7.6.0_arm64.raw

·

mymachine_7.7.0_x86-64+0-5.raw

Now invoke the following command on an x86-64 machine:

$ systemd-vpick –suffix=.raw /var/lib/machines/mymachine.raw.v/

This would resolve the specified path to /var/lib/machines/mymachine.raw.v/mymachine_7.5.14_x86-64.raw. Explanation: even though mymachine_7.7.0_x86-64+0-5.raw has the newest version, it is not preferred because its tries left counter is zero. And even though mymachine_7.6.0_arm64.raw has the second newest version it is also not considered, in this case because we operate on an x86_64 system and the image is intended for arm64 CPUs. Finally, the mymachine_7.5.13.raw image is not considered because it is older than mymachine_7.5.14_x86-64.raw.

SEE ALSO

systemd(1), systemd-vpick(1), systemd-nspawn(1), systemd-dissect(1), systemd.exec(5), systemd-sysupdate(1)

NOTES

Version Format Specification

https://uapi-group.org/specifications/specs/version_format_specification/

Automatic Boot Assessment

https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

207 - Linux cli command termio

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command termio and provides detailed information about the command termio, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the termio.

NAME 🖥️ termio 🖥️

System V terminal driver interface

DESCRIPTION

termio is the name of the old System V terminal driver interface. This interface defined a termio structure used to store terminal settings, and a range of ioctl(2) operations to get and set terminal attributes.

The termio interface is now obsolete: POSIX.1-1990 standardized a modified version of this interface, under the name termios. The POSIX.1 data structure differs slightly from the System V version, and POSIX.1 defined a suite of functions to replace the various ioctl(2) operations that existed in System V. (This was done because ioctl(2) was unstandardized, and its variadic third argument does not allow argument type checking.)

If you’re looking for a page called “termio”, then you can probably find most of the information that you seek in either termios(3) or ioctl_tty(2).

SEE ALSO

reset(1), setterm(1), stty(1), ioctl_tty(2), termios(3), tty(4)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

208 - Linux cli command daemon

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command daemon and provides detailed information about the command daemon, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the daemon.

NAME 🖥️ daemon 🖥️

Writing and packaging system daemons

DESCRIPTION

A daemon is a service process that runs in the background and supervises the system or provides functionality to other processes. Traditionally, daemons are implemented following a scheme originating in SysV Unix. Modern daemons should follow a simpler yet more powerful scheme (here called “new-style” daemons), as implemented by systemd(1). This manual page covers both schemes, and in particular includes recommendations for daemons that shall be included in the systemd init system.

SysV Daemons

When a traditional SysV daemon starts, it should execute the following steps as part of the initialization. Note that these steps are unnecessary for new-style daemons (see below), and should only be implemented if compatibility with SysV is essential.

1.

Close all open file descriptors except standard input, output, and error (i.e. the first three file descriptors 0, 1, 2). This ensures that no accidentally passed file descriptor stays around in the daemon process. On Linux, this is best implemented by iterating through /proc/self/fd, with a fallback of iterating from file descriptor 3 to the value returned by getrlimit() for RLIMIT_NOFILE.

2.

Reset all signal handlers to their default. This is best done by iterating through the available signals up to the limit of _NSIG and resetting them to SIG_DFL.

3.

Reset the signal mask using sigprocmask().

4.

Sanitize the environment block, removing or resetting environment variables that might negatively impact daemon runtime.

5.

Call fork(), to create a background process.

6.

In the child, call setsid() to detach from any terminal and create an independent session.

7.

In the child, call fork() again, to ensure that the daemon can never re-acquire a terminal again. (This is relevant if the program — and all its dependencies — does not carefully specify `O_NOCTTY` on each and every single `open()` call that might potentially open a TTY device node.)

8.

Call exit() in the first child, so that only the second child (the actual daemon process) stays around. This ensures that the daemon process is re-parented to init/PID 1, as all daemons should be.

9.

In the daemon process, connect /dev/null to standard input, output, and error.

10.

In the daemon process, reset the umask to 0, so that the file modes passed to open(), mkdir() and suchlike directly control the access mode of the created files and directories.

11.

In the daemon process, change the current directory to the root directory (/), in order to avoid that the daemon involuntarily blocks mount points from being unmounted.

12.

In the daemon process, write the daemon PID (as returned by getpid()) to a PID file, for example /run/foobar.pid (for a hypothetical daemon “foobar”) to ensure that the daemon cannot be started more than once. This must be implemented in race-free fashion so that the PID file is only updated when it is verified at the same time that the PID previously stored in the PID file no longer exists or belongs to a foreign process.

13.

In the daemon process, drop privileges, if possible and applicable.

14.

From the daemon process, notify the original process started that initialization is complete. This can be implemented via an unnamed pipe or similar communication channel that is created before the first fork() and hence available in both the original and the daemon process.

15.

Call exit() in the original process. The process that invoked the daemon must be able to rely on that this exit() happens after initialization is complete and all external communication channels are established and accessible.

The BSD daemon() function should not be used, as it implements only a subset of these steps.

A daemon that needs to provide compatibility with SysV systems should implement the scheme pointed out above. However, it is recommended to make this behavior optional and configurable via a command line argument to ease debugging as well as to simplify integration into systems using systemd.

New-Style Daemons

Modern services for Linux should be implemented as new-style daemons. This makes it easier to supervise and control them at runtime and simplifies their implementation.

For developing a new-style daemon, none of the initialization steps recommended for SysV daemons need to be implemented. New-style init systems such as systemd make all of them redundant. Moreover, since some of these steps interfere with process monitoring, file descriptor passing, and other functionality of the service manager, it is recommended not to execute them when run as new-style service.

Note that new-style init systems guarantee execution of daemon processes in a clean process context: it is guaranteed that the environment block is sanitized, that the signal handlers and mask is reset and that no left-over file descriptors are passed. Daemons will be executed in their own session, with standard input connected to /dev/null and standard output/error connected to the systemd-journald.service(8) logging service, unless otherwise configured. The umask is reset.

It is recommended for new-style daemons to implement the following:

1.

If applicable, the daemon should notify the service manager about startup completion or status updates via the sd_notify(3) interface, in particular READY=1 and STATUS=….

2.

If SIGTERM is received, shut down the daemon and exit cleanly. A STOPPING=1 notification should be sent via sd_notify(3).

3.

If SIGHUP is received, reload the configuration files, if this applies. This should be combined with notifications via sd_notify(3): RELOADING=1 and READY=1.

4.

Provide a correct exit code from the main daemon process, as this is used by the service manager to detect service errors and problems. It is recommended to follow the exit code scheme as defined in the LSB recommendations for SysV init scripts[1].

5.

If possible and applicable, expose the daemons control interface via the D-Bus IPC system and grab a bus name as last step of initialization.

6.

For integration in systemd, provide a .service unit file that carries information about starting, stopping and otherwise maintaining the daemon. See systemd.service(5) for details.

7.

As much as possible, rely on the service managers functionality to limit the access of the daemon to files, services, and other resources, i.e. in the case of systemd, rely on systemds resource limit control instead of implementing your own, rely on systemds privilege dropping code instead of implementing it in the daemon, and so on. See systemd.exec(5) for the available controls.

8.

If D-Bus is used, make your daemon bus-activatable by supplying a D-Bus service activation configuration file. This has multiple advantages: your daemon may be started lazily on-demand; it may be started in parallel to other daemons requiring it — which maximizes parallelization and boot-up speed; your daemon can be restarted on failure without losing any bus requests, as the bus queues requests for activatable services. See below for details.

9.

If your daemon provides services to other local processes or remote clients via a socket, it should be made socket-activatable following the scheme pointed out below. Like D-Bus activation, this enables on-demand starting of services as well as it allows improved parallelization of service start-up. Also, for state-less protocols (such as syslog, DNS), a daemon implementing socket-based activation can be restarted without losing a single request. See below for details.

10.

If the service opens sockets or other files on it own, and those file descriptors shall survive a restart, the daemon should store them in the service manager via sd_notify(3) with FDSTORE=1.

11.

Instead of using the syslog() call to log directly to the system syslog service, a new-style daemon may choose to simply log to standard error via fprintf(), which is then forwarded to syslog. If log levels are necessary, these can be encoded by prefixing individual log lines with strings like “<4>” (for log level 4 “WARNING” in the syslog priority scheme), following a similar style as the Linux kernels printk() level system. For details, see sd-daemon(3) and systemd.exec(5).

12.

As new-style daemons are invoked without a controlling TTY (but as their own session leaders) care should be taken to always specify O_NOCTTY on open(2) calls that possibly reference a TTY device node, so that no controlling TTY is accidentally acquired.

These recommendations are similar but not identical to the Apple MacOS X Daemon Requirements[2].

ACTIVATION

New-style init systems provide multiple additional mechanisms to activate services, as detailed below. It is common that services are configured to be activated via more than one mechanism at the same time. An example for systemd: bluetoothd.service might get activated either when Bluetooth hardware is plugged in, or when an application accesses its programming interfaces via D-Bus. Or, a print server daemon might get activated when traffic arrives at an IPP port, or when a printer is plugged in, or when a file is queued in the printer spool directory. Even for services that are intended to be started on system bootup unconditionally, it is a good idea to implement some of the various activation schemes outlined below, in order to maximize parallelization. If a daemon implements a D-Bus service or listening socket, implementing the full bus and socket activation scheme allows starting of the daemon with its clients in parallel (which speeds up boot-up), since all its communication channels are established already, and no request is lost because client requests will be queued by the bus system (in case of D-Bus) or the kernel (in case of sockets) until the activation is completed.

Activation on Boot

Old-style daemons are usually activated exclusively on boot (and manually by the administrator) via SysV init scripts, as detailed in the LSB Linux Standard Base Core Specification[1]. This method of activation is supported ubiquitously on Linux init systems, both old-style and new-style systems. Among other issues, SysV init scripts have the disadvantage of involving shell scripts in the boot process. New-style init systems generally use updated versions of activation, both during boot-up and during runtime and using more minimal service description files.

In systemd, if the developer or administrator wants to make sure that a service or other unit is activated automatically on boot, it is recommended to place a symlink to the unit file in the .wants/ directory of either multi-user.target or graphical.target, which are normally used as boot targets at system startup. See systemd.unit(5) for details about the .wants/ directories, and systemd.special(7) for details about the two boot targets.

Socket-Based Activation

In order to maximize the possible parallelization and robustness and simplify configuration and development, it is recommended for all new-style daemons that communicate via listening sockets to use socket-based activation. In a socket-based activation scheme, the creation and binding of the listening socket as primary communication channel of daemons to local (and sometimes remote) clients is moved out of the daemon code and into the service manager. Based on per-daemon configuration, the service manager installs the sockets and then hands them off to the spawned process as soon as the respective daemon is to be started. Optionally, activation of the service can be delayed until the first inbound traffic arrives at the socket to implement on-demand activation of daemons. However, the primary advantage of this scheme is that all providers and all consumers of the sockets can be started in parallel as soon as all sockets are established. In addition to that, daemons can be restarted with losing only a minimal number of client transactions, or even any client request at all (the latter is particularly true for state-less protocols, such as DNS or syslog), because the socket stays bound and accessible during the restart, and all requests are queued while the daemon cannot process them.

New-style daemons which support socket activation must be able to receive their sockets from the service manager instead of creating and binding them themselves. For details about the programming interfaces for this scheme provided by systemd, see sd_listen_fds(3) and sd-daemon(3). For details about porting existing daemons to socket-based activation, see below. With minimal effort, it is possible to implement socket-based activation in addition to traditional internal socket creation in the same codebase in order to support both new-style and old-style init systems from the same daemon binary.

systemd implements socket-based activation via .socket units, which are described in systemd.socket(5). When configuring socket units for socket-based activation, it is essential that all listening sockets are pulled in by the special target unit sockets.target. It is recommended to place a WantedBy=sockets.target directive in the [Install] section to automatically add such a dependency on installation of a socket unit. Unless DefaultDependencies=no is set, the necessary ordering dependencies are implicitly created for all socket units. For more information about sockets.target, see systemd.special(7). It is not necessary or recommended to place any additional dependencies on socket units (for example from multi-user.target or suchlike) when one is installed in sockets.target.

Bus-Based Activation

When the D-Bus IPC system is used for communication with clients, new-style daemons should use bus activation so that they are automatically activated when a client application accesses their IPC interfaces. This is configured in D-Bus service files (not to be confused with systemd service unit files!). To ensure that D-Bus uses systemd to start-up and maintain the daemon, use the SystemdService= directive in these service files to configure the matching systemd service for a D-Bus service. e.g.: For a D-Bus service whose D-Bus activation file is named org.freedesktop.RealtimeKit.service, make sure to set SystemdService=rtkit-daemon.service in that file to bind it to the systemd service rtkit-daemon.service. This is needed to make sure that the daemon is started in a race-free fashion when activated via multiple mechanisms simultaneously.

Device-Based Activation

Often, daemons that manage a particular type of hardware should be activated only when the hardware of the respective kind is plugged in or otherwise becomes available. In a new-style init system, it is possible to bind activation to hardware plug/unplug events. In systemd, kernel devices appearing in the sysfs/udev device tree can be exposed as units if they are tagged with the string “systemd”. Like any other kind of unit, they may then pull in other units when activated (i.e. plugged in) and thus implement device-based activation. systemd dependencies may be encoded in the udev database via the SYSTEMD_WANTS= property. See systemd.device(5) for details. Often, it is nicer to pull in services from devices only indirectly via dedicated targets. Example: Instead of pulling in bluetoothd.service from all the various bluetooth dongles and other hardware available, pull in bluetooth.target from them and bluetoothd.service from that target. This provides for nicer abstraction and gives administrators the option to enable bluetoothd.service via controlling a bluetooth.target.wants/ symlink uniformly with a command like enable of systemctl(1) instead of manipulating the udev ruleset.

Path-Based Activation

Often, runtime of daemons processing spool files or directories (such as a printing system) can be delayed until these file system objects change state, or become non-empty. New-style init systems provide a way to bind service activation to file system changes. systemd implements this scheme via path-based activation configured in .path units, as outlined in systemd.path(5).

Timer-Based Activation

Some daemons that implement clean-up jobs that are intended to be executed in regular intervals benefit from timer-based activation. In systemd, this is implemented via .timer units, as described in systemd.timer(5).

Other Forms of Activation

Other forms of activation have been suggested and implemented in some systems. However, there are often simpler or better alternatives, or they can be put together of combinations of the schemes above. Example: Sometimes, it appears useful to start daemons or .socket units when a specific IP address is configured on a network interface, because network sockets shall be bound to the address. However, an alternative to implement this is by utilizing the Linux IP_FREEBIND/IPV6_FREEBIND socket option, as accessible via FreeBind=yes in systemd socket files (see systemd.socket(5) for details). This option, when enabled, allows sockets to be bound to a non-local, not configured IP address, and hence allows bindings to a particular IP address before it actually becomes available, making such an explicit dependency to the configured address redundant. Another often suggested trigger for service activation is low system load. However, here too, a more convincing approach might be to make proper use of features of the operating system, in particular, the CPU or I/O scheduler of Linux. Instead of scheduling jobs from userspace based on monitoring the OS scheduler, it is advisable to leave the scheduling of processes to the OS scheduler itself. systemd provides fine-grained access to the CPU and I/O schedulers. If a process executed by the service manager shall not negatively impact the amount of CPU or I/O bandwidth available to other processes, it should be configured with CPUSchedulingPolicy=idle and/or IOSchedulingClass=idle. Optionally, this may be combined with timer-based activation to schedule background jobs during runtime and with minimal impact on the system, and remove it from the boot phase itself.

INTEGRATION WITH SYSTEMD

Writing systemd Unit Files

When writing systemd unit files, it is recommended to consider the following suggestions:

1.

If possible, do not use the Type=forking setting in service files. But if you do, make sure to set the PID file path using PIDFile=. See systemd.service(5) for details.

2.

If your daemon registers a D-Bus name on the bus, make sure to use Type=dbus in the service file if possible.

3.

Make sure to set a good human-readable description string with Description=.

4.

Do not disable DefaultDependencies=, unless you really know what you do and your unit is involved in early boot or late system shutdown.

5.

Normally, little if any dependencies should need to be defined explicitly. However, if you do configure explicit dependencies, only refer to unit names listed on systemd.special(7) or names introduced by your own package to keep the unit file operating system-independent.

6.

Make sure to include an [Install] section including installation information for the unit file. See systemd.unit(5) for details. To activate your service on boot, make sure to add a WantedBy=multi-user.target or WantedBy=graphical.target directive. To activate your socket on boot, make sure to add WantedBy=sockets.target. Usually, you also want to make sure that when your service is installed, your socket is installed too, hence add Also=foo.socket in your service file foo.service, for a hypothetical program foo.

Installing systemd Service Files

At the build installation time (e.g. make install during package build), packages are recommended to install their systemd unit files in the directory returned by pkg-config systemd –variable=systemdsystemunitdir (for system services) or pkg-config systemd –variable=systemduserunitdir (for user services). This will make the services available in the system on explicit request but not activate them automatically during boot. Optionally, during package installation (e.g. rpm -i by the administrator), symlinks should be created in the systemd configuration directories via the enable command of the systemctl(1) tool to activate them automatically on boot.

Packages using autoconf(1) are recommended to use a configure script excerpt like the following to determine the unit installation path during source configuration:

PKG_PROG_PKG_CONFIG() AC_ARG_WITH([systemdsystemunitdir], [AS_HELP_STRING([–with-systemdsystemunitdir=DIR], [Directory for systemd service files])],, [with_systemdsystemunitdir=auto]) AS_IF([test “x$with_systemdsystemunitdir” = “xyes” -o “x$with_systemdsystemunitdir” = “xauto”], [ def_systemdsystemunitdir=$($PKG_CONFIG –variable=systemdsystemunitdir systemd)

     AS_IF([test "x$def_systemdsystemunitdir" = "x"],
   [AS_IF([test "x$with_systemdsystemunitdir" = "xyes"],
    [AC_MSG_ERROR([systemd support requested but pkg-config unable to query systemd package])])
    with_systemdsystemunitdir=no],
   [with_systemdsystemunitdir="$def_systemdsystemunitdir"])])
AS_IF([test "x$with_systemdsystemunitdir" != "xno"],
      [AC_SUBST([systemdsystemunitdir], [$with_systemdsystemunitdir])])
AM_CONDITIONAL([HAVE_SYSTEMD], [test "x$with_systemdsystemunitdir" != "xno"])

This snippet allows automatic installation of the unit files on systemd machines, and optionally allows their installation even on machines lacking systemd. (Modification of this snippet for the user unit directory is left as an exercise for the reader.)

Additionally, to ensure that make distcheck continues to work, it is recommended to add the following to the top-level Makefile.am file in automake(1)-based projects:

AM_DISTCHECK_CONFIGURE_FLAGS =
–with-systemdsystemunitdir=$$dc_install_base/$(systemdsystemunitdir)

Finally, unit files should be installed in the system with an automake excerpt like the following:

if HAVE_SYSTEMD systemdsystemunit_DATA =
foobar.socket
foobar.service endif

In the rpm(8) .spec file, use snippets like the following to enable/disable the service during installation/deinstallation. This makes use of the RPM macros shipped along systemd. Consult the packaging guidelines of your distribution for details and the equivalent for other package managers.

At the top of the file:

BuildRequires: systemd %{?systemd_requires}

And as scriptlets, further down:

%post %systemd_post foobar.service foobar.socket

%preun
%systemd_preun foobar.service foobar.socket

%postun
%systemd_postun

If the service shall be restarted during upgrades, replace the “%postun” scriptlet above with the following:

%postun %systemd_postun_with_restart foobar.service

Note that “%systemd_post” and “%systemd_preun” expect the names of all units that are installed/removed as arguments, separated by spaces. “%systemd_postun” expects no arguments. “%systemd_postun_with_restart” expects the units to restart as arguments.

To facilitate upgrades from a package version that shipped only SysV init scripts to a package version that ships both a SysV init script and a native systemd service file, use a fragment like the following:

%triggerun – foobar < 0.47.11-1 if /sbin/chkconfig –level 5 foobar ; then /bin/systemctl –no-reload enable foobar.service foobar.socket >/dev/null 2>&1 || : fi

Where 0.47.11-1 is the first package version that includes the native unit file. This fragment will ensure that the first time the unit file is installed, it will be enabled if and only if the SysV init script is enabled, thus making sure that the enable status is not changed. Note that chkconfig is a command specific to Fedora which can be used to check whether a SysV init script is enabled. Other operating systems will have to use different commands here.

PORTING EXISTING DAEMONS

Since new-style init systems such as systemd are compatible with traditional SysV init systems, it is not strictly necessary to port existing daemons to the new style. However, doing so offers additional functionality to the daemons as well as simplifying integration into new-style init systems.

To port an existing SysV compatible daemon, the following steps are recommended:

1.

If not already implemented, add an optional command line switch to the daemon to disable daemonization. This is useful not only for using the daemon in new-style init systems, but also to ease debugging.

2.

If the daemon offers interfaces to other software running on the local system via local AF_UNIX sockets, consider implementing socket-based activation (see above). Usually, a minimal patch is sufficient to implement this: Extend the socket creation in the daemon code so that sd_listen_fds(3) is checked for already passed sockets first. If sockets are passed (i.e. when sd_listen_fds() returns a positive value), skip the socket creation step and use the passed sockets. Secondly, ensure that the file system socket nodes for local AF_UNIX sockets used in the socket-based activation are not removed when the daemon shuts down, if sockets have been passed. Third, if the daemon normally closes all remaining open file descriptors as part of its initialization, the sockets passed from the service manager must be spared. Since new-style init systems guarantee that no left-over file descriptors are passed to executed processes, it might be a good choice to simply skip the closing of all remaining open file descriptors if sockets are passed.

3.

Write and install a systemd unit file for the service (and the sockets if socket-based activation is used, as well as a path unit file, if the daemon processes a spool directory), see above for details.

4.

If the daemon exposes interfaces via D-Bus, write and install a D-Bus activation file for the service, see above for details.

PLACING DAEMON DATA

It is recommended to follow the general guidelines for placing package files, as discussed in file-hierarchy(7).

SEE ALSO

systemd(1), sd-daemon(3), sd_listen_fds(3), sd_notify(3), daemon(3), systemd.service(5), file-hierarchy(7)

NOTES

LSB recommendations for SysV init scripts

http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/iniscrptact.html

Apple MacOS X Daemon Requirements

https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

209 - Linux cli command EVP_CIPHER-RC2ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_CIPHER-RC2ssl and provides detailed information about the command EVP_CIPHER-RC2ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_CIPHER-RC2ssl.

NAME 🖥️ EVP_CIPHER-RC2ssl 🖥️

RC2 - The RC2 EVP_CIPHER implementations

DESCRIPTION

Support for RC2 symmetric encryption using the EVP_CIPHER API.

Algorithm Names

The following algorithms are available in the legacy provider:

“RC2-CBC”, “RC2” or “RC2-128”

“RC2-40-CBC” or “RC2-40”

“RC2-64-CBC” or “RC2-64”

“RC2-ECB”

“RC2-CFB”

“RC2-OFB”

Parameters

This implementation supports the parameters described in “PARAMETERS” in EVP_EncryptInit (3).

SEE ALSO

provider-cipher (7), OSSL_PROVIDER-legacy (7)

COPYRIGHT

Copyright 2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

210 - Linux cli command OSSL_PROVIDER-basessl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command OSSL_PROVIDER-basessl and provides detailed information about the command OSSL_PROVIDER-basessl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the OSSL_PROVIDER-basessl.

NAME 🖥️ OSSL_PROVIDER-basessl 🖥️

base - OpenSSL base provider

DESCRIPTION

The OpenSSL base provider supplies the encoding for OpenSSL’s asymmetric cryptography.

Properties

The implementations in this provider specifically have this property defined:

“provider=base”

It may be used in a property query string with fetching functions.

It isn’t mandatory to query for this property, except to make sure to get implementations of this provider and none other.

“type=parameters”

“type=private”

“type=public”

These may be used in a property query string with fetching functions to select which data are to be encoded. Either the private key material, the public key material or the domain parameters can be selected.

“format=der”

“format=pem”

“format=text”

These may be used in a property query string with fetching functions to select the encoding output format. Either the DER, PEM and plaintext are currently permitted.

OPERATIONS AND ALGORITHMS

The OpenSSL base provider supports these operations and algorithms:

Random Number Generation

SEED-SRC, see EVP_RAND-SEED-SRC (7)

In addition to this provider, the “SEED-SRC” algorithm is also available in the default provider.

Asymmetric Key Encoder

RSA

RSA-PSS

DH

DHX

DSA

EC

ED25519

ED448

X25519

X448

SM2

In addition to this provider, all of these encoding algorithms are also available in the default provider. Some of these algorithms may be used in combination with the FIPS provider.

Asymmetric Key Decoder

RSA

RSA-PSS

DH

DHX

DSA

EC

ED25519

ED448

X25519

X448

SM2

DER

In addition to this provider, all of these decoding algorithms are also available in the default provider. Some of these algorithms may be used in combination with the FIPS provider.

Stores

file

org.openssl.winstore, see OSSL_STORE-winstore (7)

In addition to this provider, all of these store algorithms are also available in the default provider.

SEE ALSO

OSSL_PROVIDER-default (7), openssl-core.h (7), openssl-core_dispatch.h (7), provider (7)

HISTORY

This functionality was added in OpenSSL 3.0.

COPYRIGHT

Copyright 2020-2024 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

211 - Linux cli command gtk-options

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command gtk-options and provides detailed information about the command gtk-options, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the gtk-options.

NAME 🖥️ gtk-options 🖥️

options - Standard Command Line Options for GTK Programs

SYNOPSIS

*program *[standard options] [specific options] arguments

DESCRIPTION

This manual page describes the command line options, which are common to all GTK based applications.

OPTIONS

GTK OPTIONS

–gtk-module=MODULE
Load an additional Gtk module.

–gtk-debug=FLAGS
A colon separated list of GTK debugging flags to set. Valid flags are objects, misc, signals, dnd, and plugsocket. The special value all enables all flags.

–gtk-no-debug=FLAGS
GTK debugging flags to unset. Use this options to override the GTK_DEBUG environment variable.

–g-fatal-warnings
Make all warnings fatal.

GDK OPTIONS

–display=DISPLAY
Set the X display to use. Use this option to override the DISPLAY environment variable.

–screen=SCREEN
X screen to use. Use this options to override the screen part of the DISPLAY environment variable (see the DISPLAY NAMES section of the X(7x) manual page).

–sync
Make X calls synchronous. This slows down the program considerably, but may be useful for debugging purposes.

–no-xshm
Do not use the X server’s XSHM shared memory extension. This slows down the program.

–name=NAME
Program name as used by the window manager.

–class=CLASS
Program class as used by the window manager.

–gxid_host=HOST

–gxid_port=PORT

–xim-preedit

–xim-status
Control the X input method.

–gdk-debug=FLAGS
A colon-separated list of GDK debugging flags to set. This only works if your GDK library was compile with debugging support. Valid flags are events, misc, dnd, color-context, and xim. The special value all enables all valid flags.

–gdk-no-debug=FLAGS
A colon-separated list of GDK debugging flags to unset. Use this options to override the GDK_DEBUG environment variable.

SEE ALSO

X(7x), the GTK documentation, and the GDK documentation.

For most GTK programs there will be additional command line options, which are specific to the program. These will be explained in the application’s documentation.

AUTHOR

This manual page was written by Jochen Voss <[email protected]>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

212 - Linux cli command provider-randssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command provider-randssl and provides detailed information about the command provider-randssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the provider-randssl.

NAME 🖥️ provider-randssl 🖥️

rand - The random number generation library <-> provider functions

SYNOPSIS

#include <openssl/core_dispatch.h> #include <openssl/core_names.h> /* * None of these are actual functions, but are displayed like this for * the function signatures for functions that are offered as function * pointers in OSSL_DISPATCH arrays. */ /* Context management */ void *OSSL_FUNC_rand_newctx(void *provctx, void *parent, const OSSL_DISPATCH *parent_calls); void OSSL_FUNC_rand_freectx(void *ctx); /* Random number generator functions: NIST */ int OSSL_FUNC_rand_instantiate(void *ctx, unsigned int strength, int prediction_resistance, const unsigned char *pstr, size_t pstr_len, const OSSL_PARAM params[]); int OSSL_FUNC_rand_uninstantiate(void *ctx); int OSSL_FUNC_rand_generate(void *ctx, unsigned char *out, size_t outlen, unsigned int strength, int prediction_resistance, const unsigned char *addin, size_t addin_len); int OSSL_FUNC_rand_reseed(void *ctx, int prediction_resistance, const unsigned char *ent, size_t ent_len, const unsigned char *addin, size_t addin_len); /* Random number generator functions: additional */ size_t OSSL_FUNC_rand_nonce(void *ctx, unsigned char *out, size_t outlen, int strength, size_t min_noncelen, size_t max_noncelen); size_t OSSL_FUNC_rand_get_seed(void *ctx, unsigned char **buffer, int entropy, size_t min_len, size_t max_len, int prediction_resistance, const unsigned char *adin, size_t adin_len); void OSSL_FUNC_rand_clear_seed(void *ctx, unsigned char *buffer, size_t b_len); int OSSL_FUNC_rand_verify_zeroization(void *ctx); /* Context Locking */ int OSSL_FUNC_rand_enable_locking(void *ctx); int OSSL_FUNC_rand_lock(void *ctx); void OSSL_FUNC_rand_unlock(void *ctx); /* RAND parameter descriptors */ const OSSL_PARAM *OSSL_FUNC_rand_gettable_params(void *provctx); const OSSL_PARAM *OSSL_FUNC_rand_gettable_ctx_params(void *ctx, void *provctx); const OSSL_PARAM *OSSL_FUNC_rand_settable_ctx_params(void *ctx, void *provctx); /* RAND parameters */ int OSSL_FUNC_rand_get_params(OSSL_PARAM params[]); int OSSL_FUNC_rand_get_ctx_params(void *ctx, OSSL_PARAM params[]); int OSSL_FUNC_rand_set_ctx_params(void *ctx, const OSSL_PARAM params[]);

DESCRIPTION

This documentation is primarily aimed at provider authors. See provider (7) for further information.

The RAND operation enables providers to implement random number generation algorithms and random number sources and make them available to applications via the API function EVP_RAND (3).

Context Management Functions

OSSL_FUNC_rand_newctx() should create and return a pointer to a provider side structure for holding context information during a rand operation. A pointer to this context will be passed back in a number of the other rand operation function calls. The parameter provctx is the provider context generated during provider initialisation (see provider (7)). The parameter parent specifies another rand instance to be used for seeding purposes. If NULL and the specific instance supports it, the operating system will be used for seeding. The parameter parent_calls points to the dispatch table for parent. Thus, the parent need not be from the same provider as the new instance.

OSSL_FUNC_rand_freectx() is passed a pointer to the provider side rand context in the mctx parameter. If it receives NULL as ctx value, it should not do anything other than return. This function should free any resources associated with that context.

Random Number Generator Functions: NIST

These functions correspond to those defined in NIST SP 800-90A and SP 800-90C.

OSSL_FUNC_rand_instantiate() is used to instantiate the DRBG ctx at a requested security strength. In addition, prediction_resistance can be requested. Additional input addin of length addin_len bytes can optionally be provided. The parameters specified in params configure the DRBG and these should be processed before instantiation.

OSSL_FUNC_rand_uninstantiate() is used to uninstantiate the DRBG ctx. After being uninstantiated, a DRBG is unable to produce output until it is instantiated anew.

OSSL_FUNC_rand_generate() is used to generate random bytes from the DRBG ctx. It will generate outlen bytes placing them into the buffer pointed to by out. The generated bytes will meet the specified security strength and, if prediction_resistance is true, the bytes will be produced after reseeding from a live entropy source. Additional input addin of length addin_len bytes can optionally be provided.

Random Number Generator Functions: Additional

OSSL_FUNC_rand_nonce() is used to generate a nonce of the given strength with a length from min_noncelen to max_noncelen. If the output buffer out is NULL, the length of the nonce should be returned.

OSSL_FUNC_rand_get_seed() is used by deterministic generators to obtain their seeding material from their parent. The seed bytes will meet the specified security level of entropy bits and there will be between min_len and max_len inclusive bytes in total. If prediction_resistance is true, the bytes will be produced from a live entropy source. Additional input addin of length addin_len bytes can optionally be provided. A pointer to the seed material is returned in *buffer and this must be freed by a later call to OSSL_FUNC_rand_clear_seed().

OSSL_FUNC_rand_clear_seed() frees a seed buffer of length b_len bytes which was previously allocated by OSSL_FUNC_rand_get_seed().

OSSL_FUNC_rand_verify_zeroization() is used to determine if the internal state of the DRBG is zero. This capability is mandated by NIST as part of the self tests, it is unlikely to be useful in other circumstances.

Context Locking

When DRBGs are used by multiple threads, there must be locking employed to ensure their proper operation. Because locking introduces an overhead, it is disabled by default.

OSSL_FUNC_rand_enable_locking() allows locking to be turned on for a DRBG and all of its parent DRBGs. From this call onwards, the DRBG can be used in a thread safe manner.

OSSL_FUNC_rand_lock() is used to lock a DRBG. Once locked, exclusive access is guaranteed.

OSSL_FUNC_rand_unlock() is used to unlock a DRBG.

Rand Parameters

See OSSL_PARAM (3) for further details on the parameters structure used by these functions.

OSSL_FUNC_rand_get_params() gets details of parameter values associated with the provider algorithm and stores them in params.

OSSL_FUNC_rand_set_ctx_params() sets rand parameters associated with the given provider side rand context ctx to params. Any parameter settings are additional to any that were previously set. Passing NULL for params should return true.

OSSL_FUNC_rand_get_ctx_params() gets details of currently set parameter values associated with the given provider side rand context ctx and stores them in params. Passing NULL for params should return true.

OSSL_FUNC_rand_gettable_params(), OSSL_FUNC_rand_gettable_ctx_params(), and OSSL_FUNC_rand_settable_ctx_params() all return constant OSSL_PARAM (3) arrays as descriptors of the parameters that OSSL_FUNC_rand_get_params(), OSSL_FUNC_rand_get_ctx_params(), and OSSL_FUNC_rand_set_ctx_params() can handle, respectively. OSSL_FUNC_rand_gettable_ctx_params() and OSSL_FUNC_rand_settable_ctx_params() will return the parameters associated with the provider side context ctx in its current state if it is not NULL. Otherwise, they return the parameters associated with the provider side algorithm provctx.

Parameters currently recognised by built-in rands are as follows. Not all parameters are relevant to, or are understood by all rands:

“state” (OSSL_RAND_PARAM_STATE) <integer>
Returns the state of the random number generator.

“strength” (OSSL_RAND_PARAM_STRENGTH) <unsigned integer>
Returns the bit strength of the random number generator.

For rands that are also deterministic random bit generators (DRBGs), these additional parameters are recognised. Not all parameters are relevant to, or are understood by all DRBG rands:

“reseed_requests” (OSSL_DRBG_PARAM_RESEED_REQUESTS) <unsigned integer>
Reads or set the number of generate requests before reseeding the associated RAND ctx.

“reseed_time_interval” (OSSL_DRBG_PARAM_RESEED_TIME_INTERVAL) <integer>
Reads or set the number of elapsed seconds before reseeding the associated RAND ctx.

“max_request” (OSSL_DRBG_PARAM_RESEED_REQUESTS) <unsigned integer>
Specifies the maximum number of bytes that can be generated in a single call to OSSL_FUNC_rand_generate.

“min_entropylen” (OSSL_DRBG_PARAM_MIN_ENTROPYLEN) <unsigned integer>

“max_entropylen” (OSSL_DRBG_PARAM_MAX_ENTROPYLEN) <unsigned integer>

Specify the minimum and maximum number of bytes of random material that can be used to seed the DRBG.

“min_noncelen” (OSSL_DRBG_PARAM_MIN_NONCELEN) <unsigned integer>

“max_noncelen” (OSSL_DRBG_PARAM_MAX_NONCELEN) <unsigned integer>

Specify the minimum and maximum number of bytes of nonce that can be used to instantiate the DRBG.

“max_perslen” (OSSL_DRBG_PARAM_MAX_PERSLEN) <unsigned integer>

“max_adinlen” (OSSL_DRBG_PARAM_MAX_ADINLEN) <unsigned integer>

Specify the minimum and maximum number of bytes of personalisation string that can be used with the DRBG.

“reseed_counter” (OSSL_DRBG_PARAM_RESEED_COUNTER) <unsigned integer>
Specifies the number of times the DRBG has been seeded or reseeded.

“digest” (OSSL_DRBG_PARAM_DIGEST) <UTF8 string>

“cipher” (OSSL_DRBG_PARAM_CIPHER) <UTF8 string>

“mac” (OSSL_DRBG_PARAM_MAC) <UTF8 string>

Sets the name of the underlying cipher, digest or MAC to be used. It must name a suitable algorithm for the DRBG that’s being used.

“properties” (OSSL_DRBG_PARAM_PROPERTIES) <UTF8 string>
Sets the properties to be queried when trying to fetch an underlying algorithm. This must be given together with the algorithm naming parameter to be considered valid.

RETURN VALUES

OSSL_FUNC_rand_newctx() should return the newly created provider side rand context, or NULL on failure.

OSSL_FUNC_rand_gettable_params(), OSSL_FUNC_rand_gettable_ctx_params() and OSSL_FUNC_rand_settable_ctx_params() should return a constant OSSL_PARAM (3) array, or NULL if none is offered.

OSSL_FUNC_rand_nonce() returns the size of the generated nonce, or 0 on error.

OSSL_FUNC_rand_get_seed() returns the size of the generated seed, or 0 on error.

All of the remaining functions should return 1 for success or 0 on error.

NOTES

The RAND life-cycle is described in life_cycle-rand (7). Providers should ensure that the various transitions listed there are supported. At some point the EVP layer will begin enforcing the listed transitions.

SEE ALSO

provider (7), RAND (7), EVP_RAND (7), life_cycle-rand (7), EVP_RAND (3)

HISTORY

The provider RAND interface was introduced in OpenSSL 3.0.

COPYRIGHT

Copyright 2020-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

213 - Linux cli command openssl-glossaryssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command openssl-glossaryssl and provides detailed information about the command openssl-glossaryssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the openssl-glossaryssl.

NAME 🖥️ openssl-glossaryssl 🖥️

glossary - An OpenSSL Glossary

DESCRIPTION

Algorithm
Cryptographic primitives such as the SHA256 digest, or AES encryption are referred to in OpenSSL as “algorithms”. There can be more than one implementation for any given algorithm available for use. crypto (7)

ASN.1, ASN1
ASN.1 (“Abstract Syntax Notation One”) is a notation for describing abstract types and values. It is defined in the ITU-T documents X.680 to X.683: <https://www.itu.int/rec/T-REC-X.680>, <https://www.itu.int/rec/T-REC-X.681>, <https://www.itu.int/rec/T-REC-X.682>, <https://www.itu.int/rec/T-REC-X.683>

Base Provider
An OpenSSL Provider that contains encoders and decoders for OpenSSL keys. All the algorithm implementations in the Base Provider are also available in the Default Provider. OSSL_PROVIDER-base (7)

Decoder
A decoder is a type of algorithm used for decoding keys and parameters from some external format such as PEM or DER. OSSL_DECODER_CTX_new_for_pkey (3)

Default Provider
An OpenSSL Provider that contains the most common OpenSSL algorithm implementations. It is loaded by default if no other provider is available. All the algorithm implementations in the Base Provider are also available in the Default Provider. OSSL_PROVIDER-default (7)

DER (“Distinguished Encoding Rules”)
DER is a binary encoding of data, structured according to an ASN.1 specification. This is a common encoding used for cryptographic objects such as private and public keys, certificates, CRLs, … It is defined in ITU-T document X.690: <https://www.itu.int/rec/T-REC-X.690>

Encoder
An encoder is a type of algorithm used for encoding keys and parameters to some external format such as PEM or DER. OSSL_ENCODER_CTX_new_for_pkey (3)

Explicit Fetching
Explicit Fetching is a type of Fetching (see Fetching). Explicit Fetching is where a function call is made to obtain an algorithm object representing an implementation such as EVP_MD_fetch (3) or EVP_CIPHER_fetch (3)

Fetching
Fetching is the process of looking through the available algorithm implementations, applying selection criteria (via a property query string), and finally choosing the implementation that will be used. Also see Explicit Fetching and Implicit Fetching. crypto (7)

FIPS Provider
An OpenSSL Provider that contains OpenSSL algorithm implementations that have been validated according to the FIPS 140-2 standard. OSSL_PROVIDER-FIPS (7)

Implicit Fetching
Implicit Fetching is a type of Fetching (see Fetching). Implicit Fetching is where an algorithm object with no associated implementation is used such as the return value from EVP_sha256 (3) or EVP_aes_128_cbc (3). With implicit fetching an implementation is fetched automatically using default selection criteria the first time the algorithm is used.

Legacy Provider
An OpenSSL Provider that contains algorithm implementations that are considered insecure or are no longer in common use. OSSL_PROVIDER-legacy (7)

Library Context
A Library Context in OpenSSL is represented by the type OSSL_LIB_CTX. It can be thought of as a scope within which configuration options apply. If an application does not explicitly create a library context then the “default” one is used. Many OpenSSL functions can take a library context as an argument. A NULL value can always be passed to indicate the default library context. OSSL_LIB_CTX (3)

MSBLOB
MSBLOB is a Microsoft specific binary format for RSA and DSA keys, both private and public. This form is never passphrase protected.

Null Provider
An OpenSSL Provider that contains no algorithm implementations. This can be useful to prevent the default provider from being automatically loaded in a library context. OSSL_PROVIDER-null (7)

Operation
An operation is a group of OpenSSL functions with a common purpose such as encryption, or digesting. crypto (7)

PEM (“Privacy Enhanced Message”)
PEM is a format used for encoding of binary content into a mail and ASCII friendly form. The content is a series of base64-encoded lines, surrounded by begin/end markers each on their own line. For example: —–BEGIN PRIVATE KEY—– MIICdg…. … bhTQ== —–END PRIVATE KEY—– Optional header line(s) may appear after the begin line, and their existence depends on the type of object being written or read. For all OpenSSL uses, the binary content is expected to be a DER encoded structure. This is defined in IETF RFC 1421: <https://tools.ietf.org/html/rfc1421>

PKCS#8
PKCS#8 is a specification of ASN.1 structures that OpenSSL uses for storing or transmitting any private key in a key type agnostic manner. There are two structures worth noting for OpenSSL use, one that contains the key data in unencrypted form (known as “PrivateKeyInfo”) and an encrypted wrapper structure (known as “EncryptedPrivateKeyInfo”). This is specified in RFC 5208: <https://tools.ietf.org/html/rfc5208>

Property
A property is a way of classifying and selecting algorithm implementations. A property is a key/value pair expressed as a string. For example all algorithm implementations in the default provider have the property “provider=default”. An algorithm implementation can have multiple properties defined against it. Also see Property Query String. property (7)

Property Query String
A property query string is a string containing a sequence of properties that can be used to select an algorithm implementation. For example the query string “provider=example,foo=bar” will select algorithms from the “example” provider that have a “foo” property defined for them with a value of “bar”. Property Query Strings are used during fetching. See Fetching. property (7)

Provider
A provider in OpenSSL is a component that groups together algorithm implementations. Providers can come from OpenSSL itself or from third parties. provider (7)

PVK
PVK is a Microsoft specific binary format for RSA and DSA private keys. This form may be passphrase protected.

SubjectPublicKeyInfo
SubjectPublicKeyInfo is an ASN.1 structure that OpenSSL uses for storing and transmitting any public key in a key type agnostic manner. This is specified as part of the specification for certificates, RFC 5280: <https://tools.ietf.org/html/rfc5280>

HISTORY

This glossary was added in OpenSSL 3.0.

COPYRIGHT

Copyright 2020-2022 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

214 - Linux cli command bash-builtins

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command bash-builtins and provides detailed information about the command bash-builtins, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the bash-builtins.

NAME 🖥️ bash-builtins 🖥️

builtins - bash built-in commands, see bash(1)

SYNOPSIS

bash defines the following built-in commands: :, ., [, alias, bg, bind, break, builtin, case, cd, command, compgen, complete, continue, declare, dirs, disown, echo, enable, eval, exec, exit, export, fc, fg, getopts, hash, help, history, if, jobs, kill, let, local, logout, popd, printf, pushd, pwd, read, readonly, return, set, shift, shopt, source, suspend, test, times, trap, type, typeset, ulimit, umask, unalias, unset, until, wait, while.

BASH BUILTIN COMMANDS

SEE ALSO

bash(1), sh(1)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

215 - Linux cli command provider-objectssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command provider-objectssl and provides detailed information about the command provider-objectssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the provider-objectssl.

NAME 🖥️ provider-objectssl 🖥️

object - A specification for a provider-native object abstraction

SYNOPSIS

#include <openssl/core_object.h> #include <openssl/core_names.h>

DESCRIPTION

The provider-native object abstraction is a set of OSSL_PARAM (3) keys and values that can be used to pass provider-native objects to OpenSSL library code or between different provider operation implementations with the help of OpenSSL library code.

The intention is that certain provider-native operations can pass any sort of object that belong with other operations, or with OpenSSL library code.

An object may be passed in the following manners:

  1. By value This means that the object data is passed as an octet string or an UTF8 string, which can be handled in diverse ways by other provided implementations. The encoding of the object depends on the context it’s used in; for example, OSSL_DECODER (3) allows multiple encodings, depending on existing decoders. If central OpenSSL library functionality is to handle the data directly, it must be encoded in DER for all object types except for OSSL_OBJECT_NAME (see “Parameter reference” below), where it’s assumed to a plain UTF8 string.

  2. By reference This means that the object data isn’t passed directly, an object reference is passed instead. It’s an octet string that only the correct provider understands correctly.

Objects by value can be used by anything that handles DER encoded objects.

Objects by reference need a higher level of cooperation from the implementation where the object originated (let’s call it X) and its target implementation (let’s call it Y):

  1. An object loading function in the target implementation The target implementation (Y) may have a function that can take an object reference. This can only be used if the target implementation is from the same provider as the one originating the object abstraction in question (X). The exact target implementation to use is determined from the object type and possibly the object data type. For example, when the OpenSSL library receives an object abstraction with the object type OSSL_OBJECT_PKEY, it will fetch a provider-keymgmt (7) using the object data type as its key type (the second argument in EVP_KEYMGMT_fetch (3)).

  2. An object exporter in the originating implementation The originating implementation (X) may have an exporter function. This exporter function can be used to export the object in OSSL_PARAM (3) form, that can then be imported by the target implementation’s imported function. This can be used when it’s not possible to fetch the target implementation (Y) from the same provider.

Parameter reference

A provider-native object abstraction is an OSSL_PARAM (3) with a selection of the following parameters:

“data” (OSSL_OBJECT_PARAM_DATA) <octet string> or <UTF8 string>
The object data passed by value.

“reference” (OSSL_OBJECT_PARAM_REFERENCE) <octet string>
The object data passed by reference.

“type” (OSSL_OBJECT_PARAM_TYPE) <integer>
The object type, a number that may have any of the following values (all defined in <openssl/core_object.h>):

OSSL_OBJECT_NAME
The object data may only be passed by value, and should be a UTF8 string. This is useful for provider-storemgmt (7) when a URI load results in new URIs.

OSSL_OBJECT_PKEY
The object data is suitable as provider-native EVP_PKEY key data. The object data may be passed by value or passed by reference.

OSSL_OBJECT_CERT
The object data is suitable as X509 data. The object data for this object type can only be passed by value, and should be an octet string. Since there’s no provider-native X.509 object, OpenSSL libraries that receive this object abstraction are expected to convert the data to a X509 object with d2i_X509().

OSSL_OBJECT_CRL
The object data is suitable as X509_CRL data. The object data can only be passed by value, and should be an octet string. Since there’s no provider-native X.509 CRL object, OpenSSL libraries that receive this object abstraction are expected to convert the data to a X509_CRL object with d2i_X509_CRL().

“data-type” (OSSL_OBJECT_PARAM_DATA_TYPE) <UTF8 string>
The specific type of the object content. Legitimate values depend on the object type; if it is OSSL_OBJECT_PKEY, the data type is expected to be a key type suitable for fetching a provider-keymgmt (7) that can handle the data.

“data-structure” (OSSL_OBJECT_PARAM_DATA_STRUCTURE) <UTF8 string>
The outermost structure of the object content. Legitimate values depend on the object type.

“desc” (OSSL_OBJECT_PARAM_DESC) <UTF8 string>
A human readable text that describes extra details on the object.

When a provider-native object abstraction is used, it must contain object data in at least one form (object data passed by value, i.e. the “data” item, or object data passed by reference, i.e. the “reference” item). Both may be present at once, in which case the OpenSSL library code that receives this will use the most optimal variant.

For objects with the object type OSSL_OBJECT_NAME, that object type must be given.

SEE ALSO

provider (7), OSSL_DECODER (3)

HISTORY

The concept of providers and everything surrounding them was introduced in OpenSSL 3.0.

COPYRIGHT

Copyright 2020-2022 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

216 - Linux cli command CREATE_POLICY

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_POLICY and provides detailed information about the command CREATE_POLICY, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_POLICY.

NAME 🖥️ CREATE_POLICY 🖥️

define a new row-level security policy for a table

SYNOPSIS

CREATE POLICY name ON table_name
    [ AS { PERMISSIVE | RESTRICTIVE } ]
    [ FOR { ALL | SELECT | INSERT | UPDATE | DELETE } ]
    [ TO { role_name | PUBLIC | CURRENT_ROLE | CURRENT_USER | SESSION_USER } [, ...] ]
    [ USING ( using_expression ) ]
    [ WITH CHECK ( check_expression ) ]

DESCRIPTION

The CREATE POLICY command defines a new row-level security policy for a table. Note that row-level security must be enabled on the table (using ALTER TABLE … ENABLE ROW LEVEL SECURITY) in order for created policies to be applied.

A policy grants the permission to select, insert, update, or delete rows that match the relevant policy expression. Existing table rows are checked against the expression specified in USING, while new rows that would be created via INSERT or UPDATE are checked against the expression specified in WITH CHECK. When a USING expression returns true for a given row then that row is visible to the user, while if false or null is returned then the row is not visible. When a WITH CHECK expression returns true for a row then that row is inserted or updated, while if false or null is returned then an error occurs.

For INSERT, UPDATE, and MERGE statements, WITH CHECK expressions are enforced after BEFORE triggers are fired, and before any actual data modifications are made. Thus a BEFORE ROW trigger may modify the data to be inserted, affecting the result of the security policy check. WITH CHECK expressions are enforced before any other constraints.

Policy names are per-table. Therefore, one policy name can be used for many different tables and have a definition for each table which is appropriate to that table.

Policies can be applied for specific commands or for specific roles. The default for newly created policies is that they apply for all commands and roles, unless otherwise specified. Multiple policies may apply to a single command; see below for more details. Table 292 summarizes how the different types of policy apply to specific commands.

For policies that can have both USING and WITH CHECK expressions (ALL and UPDATE), if no WITH CHECK expression is defined, then the USING expression will be used both to determine which rows are visible (normal USING case) and which new rows will be allowed to be added (WITH CHECK case).

If row-level security is enabled for a table, but no applicable policies exist, a “default deny” policy is assumed, so that no rows will be visible or updatable.

PARAMETERS

name

The name of the policy to be created. This must be distinct from the name of any other policy for the table.

table_name

The name (optionally schema-qualified) of the table the policy applies to.

PERMISSIVE

Specify that the policy is to be created as a permissive policy. All permissive policies which are applicable to a given query will be combined together using the Boolean “OR” operator. By creating permissive policies, administrators can add to the set of records which can be accessed. Policies are permissive by default.

RESTRICTIVE

Specify that the policy is to be created as a restrictive policy. All restrictive policies which are applicable to a given query will be combined together using the Boolean “AND” operator. By creating restrictive policies, administrators can reduce the set of records which can be accessed as all restrictive policies must be passed for each record.

Note that there needs to be at least one permissive policy to grant access to records before restrictive policies can be usefully used to reduce that access. If only restrictive policies exist, then no records will be accessible. When a mix of permissive and restrictive policies are present, a record is only accessible if at least one of the permissive policies passes, in addition to all the restrictive policies.

command

The command to which the policy applies. Valid options are ALL, SELECT, INSERT, UPDATE, and DELETE. ALL is the default. See below for specifics regarding how these are applied.

role_name

The role(s) to which the policy is to be applied. The default is PUBLIC, which will apply the policy to all roles.

using_expression

Any SQL conditional expression (returning boolean). The conditional expression cannot contain any aggregate or window functions. This expression will be added to queries that refer to the table if row-level security is enabled. Rows for which the expression returns true will be visible. Any rows for which the expression returns false or null will not be visible to the user (in a SELECT), and will not be available for modification (in an UPDATE or DELETE). Such rows are silently suppressed; no error is reported.

check_expression

Any SQL conditional expression (returning boolean). The conditional expression cannot contain any aggregate or window functions. This expression will be used in INSERT and UPDATE queries against the table if row-level security is enabled. Only rows for which the expression evaluates to true will be allowed. An error will be thrown if the expression evaluates to false or null for any of the records inserted or any of the records that result from the update. Note that the check_expression is evaluated against the proposed new contents of the row, not the original contents.

Per-Command Policies

ALL

Using ALL for a policy means that it will apply to all commands, regardless of the type of command. If an ALL policy exists and more specific policies exist, then both the ALL policy and the more specific policy (or policies) will be applied. Additionally, ALL policies will be applied to both the selection side of a query and the modification side, using the USING expression for both cases if only a USING expression has been defined.

As an example, if an UPDATE is issued, then the ALL policy will be applicable both to what the UPDATE will be able to select as rows to be updated (applying the USING expression), and to the resulting updated rows, to check if they are permitted to be added to the table (applying the WITH CHECK expression, if defined, and the USING expression otherwise). If an INSERT or UPDATE command attempts to add rows to the table that do not pass the ALL policys WITH CHECK expression, the entire command will be aborted.

SELECT

Using SELECT for a policy means that it will apply to SELECT queries and whenever SELECT permissions are required on the relation the policy is defined for. The result is that only those records from the relation that pass the SELECT policy will be returned during a SELECT query, and that queries that require SELECT permissions, such as UPDATE, will also only see those records that are allowed by the SELECT policy. A SELECT policy cannot have a WITH CHECK expression, as it only applies in cases where records are being retrieved from the relation.

INSERT

Using INSERT for a policy means that it will apply to INSERT commands and MERGE commands that contain INSERT actions. Rows being inserted that do not pass this policy will result in a policy violation error, and the entire INSERT command will be aborted. An INSERT policy cannot have a USING expression, as it only applies in cases where records are being added to the relation.

Note that INSERT with ON CONFLICT DO UPDATE checks INSERT policies WITH CHECK expressions only for rows appended to the relation by the INSERT path.

UPDATE

Using UPDATE for a policy means that it will apply to UPDATE, SELECT FOR UPDATE and SELECT FOR SHARE commands, as well as auxiliary ON CONFLICT DO UPDATE clauses of INSERT commands. MERGE commands containing UPDATE actions are affected as well. Since UPDATE involves pulling an existing record and replacing it with a new modified record, UPDATE policies accept both a USING expression and a WITH CHECK expression. The USING expression determines which records the UPDATE command will see to operate against, while the WITH CHECK expression defines which modified rows are allowed to be stored back into the relation.

Any rows whose updated values do not pass the WITH CHECK expression will cause an error, and the entire command will be aborted. If only a USING clause is specified, then that clause will be used for both USING and WITH CHECK cases.

Typically an UPDATE command also needs to read data from columns in the relation being updated (e.g., in a WHERE clause or a RETURNING clause, or in an expression on the right hand side of the SET clause). In this case, SELECT rights are also required on the relation being updated, and the appropriate SELECT or ALL policies will be applied in addition to the UPDATE policies. Thus the user must have access to the row(s) being updated through a SELECT or ALL policy in addition to being granted permission to update the row(s) via an UPDATE or ALL policy.

When an INSERT command has an auxiliary ON CONFLICT DO UPDATE clause, if the UPDATE path is taken, the row to be updated is first checked against the USING expressions of any UPDATE policies, and then the new updated row is checked against the WITH CHECK expressions. Note, however, that unlike a standalone UPDATE command, if the existing row does not pass the USING expressions, an error will be thrown (the UPDATE path will never be silently avoided).

DELETE

Using DELETE for a policy means that it will apply to DELETE commands. Only rows that pass this policy will be seen by a DELETE command. There can be rows that are visible through a SELECT that are not available for deletion, if they do not pass the USING expression for the DELETE policy.

In most cases a DELETE command also needs to read data from columns in the relation that it is deleting from (e.g., in a WHERE clause or a RETURNING clause). In this case, SELECT rights are also required on the relation, and the appropriate SELECT or ALL policies will be applied in addition to the DELETE policies. Thus the user must have access to the row(s) being deleted through a SELECT or ALL policy in addition to being granted permission to delete the row(s) via a DELETE or ALL policy.

A DELETE policy cannot have a WITH CHECK expression, as it only applies in cases where records are being deleted from the relation, so that there is no new row to check.

Table 292. Policies Applied by Command Type

TABLE

Application of Multiple Policies

When multiple policies of different command types apply to the same command (for example, SELECT and UPDATE policies applied to an UPDATE command), then the user must have both types of permissions (for example, permission to select rows from the relation as well as permission to update them). Thus the expressions for one type of policy are combined with the expressions for the other type of policy using the AND operator.

When multiple policies of the same command type apply to the same command, then there must be at least one PERMISSIVE policy granting access to the relation, and all of the RESTRICTIVE policies must pass. Thus all the PERMISSIVE policy expressions are combined using OR, all the RESTRICTIVE policy expressions are combined using AND, and the results are combined using AND. If there are no PERMISSIVE policies, then access is denied.

Note that, for the purposes of combining multiple policies, ALL policies are treated as having the same type as whichever other type of policy is being applied.

For example, in an UPDATE command requiring both SELECT and UPDATE permissions, if there are multiple applicable policies of each type, they will be combined as follows:

expression from RESTRICTIVE SELECT/ALL policy 1 AND expression from RESTRICTIVE SELECT/ALL policy 2 AND … AND ( expression from PERMISSIVE SELECT/ALL policy 1 OR expression from PERMISSIVE SELECT/ALL policy 2 OR … ) AND expression from RESTRICTIVE UPDATE/ALL policy 1 AND expression from RESTRICTIVE UPDATE/ALL policy 2 AND … AND ( expression from PERMISSIVE UPDATE/ALL policy 1 OR expression from PERMISSIVE UPDATE/ALL policy 2 OR … )

NOTES

You must be the owner of a table to create or change policies for it.

While policies will be applied for explicit queries against tables in the database, they are not applied when the system is performing internal referential integrity checks or validating constraints. This means there are indirect ways to determine that a given value exists. An example of this is attempting to insert a duplicate value into a column that is a primary key or has a unique constraint. If the insert fails then the user can infer that the value already exists. (This example assumes that the user is permitted by policy to insert records which they are not allowed to see.) Another example is where a user is allowed to insert into a table which references another, otherwise hidden table. Existence can be determined by the user inserting values into the referencing table, where success would indicate that the value exists in the referenced table. These issues can be addressed by carefully crafting policies to prevent users from being able to insert, delete, or update records at all which might possibly indicate a value they are not otherwise able to see, or by using generated values (e.g., surrogate keys) instead of keys with external meanings.

Generally, the system will enforce filter conditions imposed using security policies prior to qualifications that appear in user queries, in order to prevent inadvertent exposure of the protected data to user-defined functions which might not be trustworthy. However, functions and operators marked by the system (or the system administrator) as LEAKPROOF may be evaluated before policy expressions, as they are assumed to be trustworthy.

Since policy expressions are added to the users query directly, they will be run with the rights of the user running the overall query. Therefore, users who are using a given policy must be able to access any tables or functions referenced in the expression or they will simply receive a permission denied error when attempting to query the table that has row-level security enabled. This does not change how views work, however. As with normal queries and views, permission checks and policies for the tables which are referenced by a view will use the view owners rights and any policies which apply to the view owner, except if the view is defined using the security_invoker option (see CREATE VIEW).

No separate policy exists for MERGE. Instead, the policies defined for SELECT, INSERT, UPDATE, and DELETE are applied while executing MERGE, depending on the actions that are performed.

Additional discussion and practical examples can be found in Section 5.8.

COMPATIBILITY

CREATE POLICY is a PostgreSQL extension.

SEE ALSO

ALTER POLICY (ALTER_POLICY(7)), DROP POLICY (DROP_POLICY(7)), ALTER TABLE (ALTER_TABLE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

217 - Linux cli command socket

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command socket and provides detailed information about the command socket, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the socket.

NAME 🖥️ socket 🖥️

Linux socket interface

SYNOPSIS

#include <sys/socket.h>
sockfd = socket(int socket_family, int socket_type, int protocol);

DESCRIPTION

This manual page describes the Linux networking socket layer user interface. The BSD compatible sockets are the uniform interface between the user process and the network protocol stacks in the kernel. The protocol modules are grouped into protocol families such as AF_INET, AF_IPX, and AF_PACKET, and socket types such as SOCK_STREAM or SOCK_DGRAM. See socket(2) for more information on families and types.

Socket-layer functions

These functions are used by the user process to send or receive packets and to do other socket operations. For more information, see their respective manual pages.

socket(2) creates a socket, connect(2) connects a socket to a remote socket address, the bind(2) function binds a socket to a local socket address, listen(2) tells the socket that new connections shall be accepted, and accept(2) is used to get a new socket with a new incoming connection. socketpair(2) returns two connected anonymous sockets (implemented only for a few local families like AF_UNIX)

send(2), sendto(2), and sendmsg(2) send data over a socket, and recv(2), recvfrom(2), recvmsg(2) receive data from a socket. poll(2) and select(2) wait for arriving data or a readiness to send data. In addition, the standard I/O operations like write(2), writev(2), sendfile(2), read(2), and readv(2) can be used to read and write data.

getsockname(2) returns the local socket address and getpeername(2) returns the remote socket address. getsockopt(2) and setsockopt(2) are used to set or get socket layer or protocol options. ioctl(2) can be used to set or read some other options.

close(2) is used to close a socket. shutdown(2) closes parts of a full-duplex socket connection.

Seeking, or calling pread(2) or pwrite(2) with a nonzero position is not supported on sockets.

It is possible to do nonblocking I/O on sockets by setting the O_NONBLOCK flag on a socket file descriptor using fcntl(2). Then all operations that would block will (usually) return with EAGAIN (operation should be retried later); connect(2) will return EINPROGRESS error. The user can then wait for various events via poll(2) or select(2).

TABLE

An alternative to poll(2) and select(2) is to let the kernel inform the application about events via a SIGIO signal. For that the O_ASYNC flag must be set on a socket file descriptor via fcntl(2) and a valid signal handler for SIGIO must be installed via sigaction(2). See the Signals discussion below.

Socket address structures

Each socket domain has its own format for socket addresses, with a domain-specific address structure. Each of these structures begins with an integer “family” field (typed as sa_family_t) that indicates the type of the address structure. This allows the various system calls (e.g., connect(2), bind(2), accept(2), getsockname(2), getpeername(2)), which are generic to all socket domains, to determine the domain of a particular socket address.

To allow any type of socket address to be passed to interfaces in the sockets API, the type struct sockaddr is defined. The purpose of this type is purely to allow casting of domain-specific socket address types to a “generic” type, so as to avoid compiler warnings about type mismatches in calls to the sockets API.

In addition, the sockets API provides the data type struct sockaddr_storage. This type is suitable to accommodate all supported domain-specific socket address structures; it is large enough and is aligned properly. (In particular, it is large enough to hold IPv6 socket addresses.) The structure includes the following field, which can be used to identify the type of socket address actually stored in the structure:

    sa_family_t ss_family;

The sockaddr_storage structure is useful in programs that must handle socket addresses in a generic way (e.g., programs that must deal with both IPv4 and IPv6 socket addresses).

Socket options

The socket options listed below can be set by using setsockopt(2) and read with getsockopt(2) with the socket level set to SOL_SOCKET for all sockets. Unless otherwise noted, optval is a pointer to an int.

SO_ACCEPTCONN
Returns a value indicating whether or not this socket has been marked to accept connections with listen(2). The value 0 indicates that this is not a listening socket, the value 1 indicates that this is a listening socket. This socket option is read-only.

SO_ATTACH_FILTER (since Linux 2.2)
SO_ATTACH_BPF (since Linux 3.19)
Attach a classic BPF (SO_ATTACH_FILTER) or an extended BPF (SO_ATTACH_BPF) program to the socket for use as a filter of incoming packets. A packet will be dropped if the filter program returns zero. If the filter program returns a nonzero value which is less than the packet’s data length, the packet will be truncated to the length returned. If the value returned by the filter is greater than or equal to the packet’s data length, the packet is allowed to proceed unmodified.

The argument for SO_ATTACH_FILTER is a sock_fprog structure, defined in <linux/filter.h>:

struct sock_fprog {
    unsigned short      len;
    struct sock_filter *filter;
};

The argument for SO_ATTACH_BPF is a file descriptor returned by the bpf(2) system call and must refer to a program of type BPF_PROG_TYPE_SOCKET_FILTER.

These options may be set multiple times for a given socket, each time replacing the previous filter program. The classic and extended versions may be called on the same socket, but the previous filter will always be replaced such that a socket never has more than one filter defined.

Both classic and extended BPF are explained in the kernel source file Documentation/networking/filter.txt

SO_ATTACH_REUSEPORT_CBPF
SO_ATTACH_REUSEPORT_EBPF
For use with the SO_REUSEPORT option, these options allow the user to set a classic BPF (SO_ATTACH_REUSEPORT_CBPF) or an extended BPF (SO_ATTACH_REUSEPORT_EBPF) program which defines how packets are assigned to the sockets in the reuseport group (that is, all sockets which have SO_REUSEPORT set and are using the same local address to receive packets).

The BPF program must return an index between 0 and N-1 representing the socket which should receive the packet (where N is the number of sockets in the group). If the BPF program returns an invalid index, socket selection will fall back to the plain SO_REUSEPORT mechanism.

Sockets are numbered in the order in which they are added to the group (that is, the order of bind(2) calls for UDP sockets or the order of listen(2) calls for TCP sockets). New sockets added to a reuseport group will inherit the BPF program. When a socket is removed from a reuseport group (via close(2)), the last socket in the group will be moved into the closed socket’s position.

These options may be set repeatedly at any time on any socket in the group to replace the current BPF program used by all sockets in the group.

SO_ATTACH_REUSEPORT_CBPF takes the same argument type as SO_ATTACH_FILTER and SO_ATTACH_REUSEPORT_EBPF takes the same argument type as SO_ATTACH_BPF.

UDP support for this feature is available since Linux 4.5; TCP support is available since Linux 4.6.

SO_BINDTODEVICE
Bind this socket to a particular device like “eth0”, as specified in the passed interface name. If the name is an empty string or the option length is zero, the socket device binding is removed. The passed option is a variable-length null-terminated interface name string with the maximum size of IFNAMSIZ. If a socket is bound to an interface, only packets received from that particular interface are processed by the socket. Note that this works only for some socket types, particularly AF_INET sockets. It is not supported for packet sockets (use normal bind(2) there).

Before Linux 3.8, this socket option could be set, but could not retrieved with getsockopt(2). Since Linux 3.8, it is readable. The optlen argument should contain the buffer size available to receive the device name and is recommended to be IFNAMSIZ bytes. The real device name length is reported back in the optlen argument.

SO_BROADCAST
Set or get the broadcast flag. When enabled, datagram sockets are allowed to send packets to a broadcast address. This option has no effect on stream-oriented sockets.

SO_BSDCOMPAT
Enable BSD bug-to-bug compatibility. This is used by the UDP protocol module in Linux 2.0 and 2.2. If enabled, ICMP errors received for a UDP socket will not be passed to the user program. In later kernel versions, support for this option has been phased out: Linux 2.4 silently ignores it, and Linux 2.6 generates a kernel warning (printk()) if a program uses this option. Linux 2.0 also enabled BSD bug-to-bug compatibility options (random header changing, skipping of the broadcast flag) for raw sockets with this option, but that was removed in Linux 2.2.

SO_DEBUG
Enable socket debugging. Allowed only for processes with the CAP_NET_ADMIN capability or an effective user ID of 0.

SO_DETACH_FILTER (since Linux 2.2)
SO_DETACH_BPF (since Linux 3.19)
These two options, which are synonyms, may be used to remove the classic or extended BPF program attached to a socket with either SO_ATTACH_FILTER or SO_ATTACH_BPF. The option value is ignored.

SO_DOMAIN (since Linux 2.6.32)
Retrieves the socket domain as an integer, returning a value such as AF_INET6. See socket(2) for details. This socket option is read-only.

SO_ERROR
Get and clear the pending socket error. This socket option is read-only. Expects an integer.

SO_DONTROUTE
Don’t send via a gateway, send only to directly connected hosts. The same effect can be achieved by setting the MSG_DONTROUTE flag on a socket send(2) operation. Expects an integer boolean flag.

SO_INCOMING_CPU (gettable since Linux 3.19, settable since Linux 4.4)
Sets or gets the CPU affinity of a socket. Expects an integer flag.

int cpu = 1;
setsockopt(fd, SOL_SOCKET, SO_INCOMING_CPU, &cpu,
           sizeof(cpu));

Because all of the packets for a single stream (i.e., all packets for the same 4-tuple) arrive on the single RX queue that is associated with a particular CPU, the typical use case is to employ one listening process per RX queue, with the incoming flow being handled by a listener on the same CPU that is handling the RX queue. This provides optimal NUMA behavior and keeps CPU caches hot.

SO_INCOMING_NAPI_ID (gettable since Linux 4.12)
Returns a system-level unique ID called NAPI ID that is associated with a RX queue on which the last packet associated with that socket is received.

This can be used by an application to split the incoming flows among worker threads based on the RX queue on which the packets associated with the flows are received. It allows each worker thread to be associated with a NIC HW receive queue and service all the connection requests received on that RX queue. This mapping between an app thread and a HW NIC queue streamlines the flow of data from the NIC to the application.

SO_KEEPALIVE
Enable sending of keep-alive messages on connection-oriented sockets. Expects an integer boolean flag.

SO_LINGER
Sets or gets the SO_LINGER option. The argument is a linger structure.

struct linger {
    int l_onoff;    /* linger active */
    int l_linger;   /* how many seconds to linger for */
};

When enabled, a close(2) or shutdown(2) will not return until all queued messages for the socket have been successfully sent or the linger timeout has been reached. Otherwise, the call returns immediately and the closing is done in the background. When the socket is closed as part of exit(2), it always lingers in the background.

SO_LOCK_FILTER
When set, this option will prevent changing the filters associated with the socket. These filters include any set using the socket options SO_ATTACH_FILTER, SO_ATTACH_BPF, SO_ATTACH_REUSEPORT_CBPF, and SO_ATTACH_REUSEPORT_EBPF.

The typical use case is for a privileged process to set up a raw socket (an operation that requires the CAP_NET_RAW capability), apply a restrictive filter, set the SO_LOCK_FILTER option, and then either drop its privileges or pass the socket file descriptor to an unprivileged process via a UNIX domain socket.

Once the SO_LOCK_FILTER option has been enabled, attempts to change or remove the filter attached to a socket, or to disable the SO_LOCK_FILTER option will fail with the error EPERM.

SO_MARK (since Linux 2.6.25)
Set the mark for each packet sent through this socket (similar to the netfilter MARK target but socket-based). Changing the mark can be used for mark-based routing without netfilter or for packet filtering. Setting this option requires the CAP_NET_ADMIN or CAP_NET_RAW (since Linux 5.17) capability.

SO_OOBINLINE
If this option is enabled, out-of-band data is directly placed into the receive data stream. Otherwise, out-of-band data is passed only when the MSG_OOB flag is set during receiving.

SO_PASSCRED
Enable or disable the receiving of the SCM_CREDENTIALS control message. For more information, see unix(7).

SO_PASSSEC
Enable or disable the receiving of the SCM_SECURITY control message. For more information, see unix(7).

SO_PEEK_OFF (since Linux 3.4)
This option, which is currently supported only for unix(7) sockets, sets the value of the “peek offset” for the recv(2) system call when used with MSG_PEEK flag.

When this option is set to a negative value (it is set to -1 for all new sockets), traditional behavior is provided: recv(2) with the MSG_PEEK flag will peek data from the front of the queue.

When the option is set to a value greater than or equal to zero, then the next peek at data queued in the socket will occur at the byte offset specified by the option value. At the same time, the “peek offset” will be incremented by the number of bytes that were peeked from the queue, so that a subsequent peek will return the next data in the queue.

If data is removed from the front of the queue via a call to recv(2) (or similar) without the MSG_PEEK flag, the “peek offset” will be decreased by the number of bytes removed. In other words, receiving data without the MSG_PEEK flag will cause the “peek offset” to be adjusted to maintain the correct relative position in the queued data, so that a subsequent peek will retrieve the data that would have been retrieved had the data not been removed.

For datagram sockets, if the “peek offset” points to the middle of a packet, the data returned will be marked with the MSG_TRUNC flag.

The following example serves to illustrate the use of SO_PEEK_OFF. Suppose a stream socket has the following queued input data:

aabbccddeeff

The following sequence of recv(2) calls would have the effect noted in the comments:

int ov = 4;                  // Set peek offset to 4
setsockopt(fd, SOL_SOCKET, SO_PEEK_OFF, &ov, sizeof(ov));
recv(fd, buf, 2, MSG_PEEK);  // Peeks "cc"; offset set to 6
recv(fd, buf, 2, MSG_PEEK);  // Peeks "dd"; offset set to 8
recv(fd, buf, 2, 0);         // Reads "aa"; offset set to 6
recv(fd, buf, 2, MSG_PEEK);  // Peeks "ee"; offset set to 8

SO_PEERCRED
Return the credentials of the peer process connected to this socket. For further details, see unix(7).

SO_PEERSEC (since Linux 2.6.2)
Return the security context of the peer socket connected to this socket. For further details, see unix(7) and ip(7).

SO_PRIORITY
Set the protocol-defined priority for all packets to be sent on this socket. Linux uses this value to order the networking queues: packets with a higher priority may be processed first depending on the selected device queueing discipline. Setting a priority outside the range 0 to 6 requires the CAP_NET_ADMIN capability.

SO_PROTOCOL (since Linux 2.6.32)
Retrieves the socket protocol as an integer, returning a value such as IPPROTO_SCTP. See socket(2) for details. This socket option is read-only.

SO_RCVBUF
Sets or gets the maximum socket receive buffer in bytes. The kernel doubles this value (to allow space for bookkeeping overhead) when it is set using setsockopt(2), and this doubled value is returned by getsockopt(2). The default value is set by the /proc/sys/net/core/rmem_default file, and the maximum allowed value is set by the /proc/sys/net/core/rmem_max file. The minimum (doubled) value for this option is 256.

SO_RCVBUFFORCE (since Linux 2.6.14)
Using this socket option, a privileged (CAP_NET_ADMIN) process can perform the same task as SO_RCVBUF, but the rmem_max limit can be overridden.

SO_RCVLOWAT and SO_SNDLOWAT
Specify the minimum number of bytes in the buffer until the socket layer will pass the data to the protocol (SO_SNDLOWAT) or the user on receiving (SO_RCVLOWAT). These two values are initialized to 1. SO_SNDLOWAT is not changeable on Linux (setsockopt(2) fails with the error ENOPROTOOPT). SO_RCVLOWAT is changeable only since Linux 2.4.

Before Linux 2.6.28 select(2), poll(2), and epoll(7) did not respect the SO_RCVLOWAT setting on Linux, and indicated a socket as readable when even a single byte of data was available. A subsequent read from the socket would then block until SO_RCVLOWAT bytes are available. Since Linux 2.6.28, select(2), poll(2), and epoll(7) indicate a socket as readable only if at least SO_RCVLOWAT bytes are available.

SO_RCVTIMEO and SO_SNDTIMEO
Specify the receiving or sending timeouts until reporting an error. The argument is a struct timeval. If an input or output function blocks for this period of time, and data has been sent or received, the return value of that function will be the amount of data transferred; if no data has been transferred and the timeout has been reached, then -1 is returned with errno set to EAGAIN or EWOULDBLOCK, or EINPROGRESS (for connect(2)) just as if the socket was specified to be nonblocking. If the timeout is set to zero (the default), then the operation will never timeout. Timeouts only have effect for system calls that perform socket I/O (e.g., accept(2), connect(2), read(2), recvmsg(2), send(2), sendmsg(2)); timeouts have no effect for select(2), poll(2), epoll_wait(2), and so on.

SO_REUSEADDR
Indicates that the rules used in validating addresses supplied in a bind(2) call should allow reuse of local addresses. For AF_INET sockets this means that a socket may bind, except when there is an active listening socket bound to the address. When the listening socket is bound to INADDR_ANY with a specific port then it is not possible to bind to this port for any local address. Argument is an integer boolean flag.

SO_REUSEPORT (since Linux 3.9)
Permits multiple AF_INET or AF_INET6 sockets to be bound to an identical socket address. This option must be set on each socket (including the first socket) prior to calling bind(2) on the socket. To prevent port hijacking, all of the processes binding to the same address must have the same effective UID. This option can be employed with both TCP and UDP sockets.

For TCP sockets, this option allows accept(2) load distribution in a multi-threaded server to be improved by using a distinct listener socket for each thread. This provides improved load distribution as compared to traditional techniques such using a single accept(2)ing thread that distributes connections, or having multiple threads that compete to accept(2) from the same socket.

For UDP sockets, the use of this option can provide better distribution of incoming datagrams to multiple processes (or threads) as compared to the traditional technique of having multiple processes compete to receive datagrams on the same socket.

SO_RXQ_OVFL (since Linux 2.6.33)
Indicates that an unsigned 32-bit value ancillary message (cmsg) should be attached to received skbs indicating the number of packets dropped by the socket since its creation.

SO_SELECT_ERR_QUEUE (since Linux 3.10)
When this option is set on a socket, an error condition on a socket causes notification not only via the exceptfds set of select(2). Similarly, poll(2) also returns a POLLPRI whenever an POLLERR event is returned.

Background: this option was added when waking up on an error condition occurred only via the readfds and writefds sets of select(2). The option was added to allow monitoring for error conditions via the exceptfds argument without simultaneously having to receive notifications (via readfds) for regular data that can be read from the socket. After changes in Linux 4.16, the use of this flag to achieve the desired notifications is no longer necessary. This option is nevertheless retained for backwards compatibility.

SO_SNDBUF
Sets or gets the maximum socket send buffer in bytes. The kernel doubles this value (to allow space for bookkeeping overhead) when it is set using setsockopt(2), and this doubled value is returned by getsockopt(2). The default value is set by the /proc/sys/net/core/wmem_default file and the maximum allowed value is set by the /proc/sys/net/core/wmem_max file. The minimum (doubled) value for this option is 2048.

SO_SNDBUFFORCE (since Linux 2.6.14)
Using this socket option, a privileged (CAP_NET_ADMIN) process can perform the same task as SO_SNDBUF, but the wmem_max limit can be overridden.

SO_TIMESTAMP
Enable or disable the receiving of the SO_TIMESTAMP control message. The timestamp control message is sent with level SOL_SOCKET and a cmsg_type of SCM_TIMESTAMP. The cmsg_data field is a struct timeval indicating the reception time of the last packet passed to the user in this call. See cmsg(3) for details on control messages.

SO_TIMESTAMPNS (since Linux 2.6.22)
Enable or disable the receiving of the SO_TIMESTAMPNS control message. The timestamp control message is sent with level SOL_SOCKET and a cmsg_type of SCM_TIMESTAMPNS. The cmsg_data field is a struct timespec indicating the reception time of the last packet passed to the user in this call. The clock used for the timestamp is CLOCK_REALTIME. See cmsg(3) for details on control messages.

A socket cannot mix SO_TIMESTAMP and SO_TIMESTAMPNS: the two modes are mutually exclusive.

SO_TYPE
Gets the socket type as an integer (e.g., SOCK_STREAM). This socket option is read-only.

SO_BUSY_POLL (since Linux 3.11)
Sets the approximate time in microseconds to busy poll on a blocking receive when there is no data. Increasing this value requires CAP_NET_ADMIN. The default for this option is controlled by the /proc/sys/net/core/busy_read file.

The value in the /proc/sys/net/core/busy_poll file determines how long select(2) and poll(2) will busy poll when they operate on sockets with SO_BUSY_POLL set and no events to report are found.

In both cases, busy polling will only be done when the socket last received data from a network device that supports this option.

While busy polling may improve latency of some applications, care must be taken when using it since this will increase both CPU utilization and power usage.

Signals

When writing onto a connection-oriented socket that has been shut down (by the local or the remote end) SIGPIPE is sent to the writing process and EPIPE is returned. The signal is not sent when the write call specified the MSG_NOSIGNAL flag.

When requested with the FIOSETOWN fcntl(2) or SIOCSPGRP ioctl(2), SIGIO is sent when an I/O event occurs. It is possible to use poll(2) or select(2) in the signal handler to find out which socket the event occurred on. An alternative (in Linux 2.2) is to set a real-time signal using the F_SETSIG fcntl(2); the handler of the real time signal will be called with the file descriptor in the si_fd field of its siginfo_t. See fcntl(2) for more information.

Under some circumstances (e.g., multiple processes accessing a single socket), the condition that caused the SIGIO may have already disappeared when the process reacts to the signal. If this happens, the process should wait again because Linux will resend the signal later.

/proc interfaces

The core socket networking parameters can be accessed via files in the directory /proc/sys/net/core/.

rmem_default
contains the default setting in bytes of the socket receive buffer.

rmem_max
contains the maximum socket receive buffer size in bytes which a user may set by using the SO_RCVBUF socket option.

wmem_default
contains the default setting in bytes of the socket send buffer.

wmem_max
contains the maximum socket send buffer size in bytes which a user may set by using the SO_SNDBUF socket option.

message_cost and message_burst
configure the token bucket filter used to load limit warning messages caused by external network events.

netdev_max_backlog
Maximum number of packets in the global input queue.

optmem_max
Maximum length of ancillary data and user control data like the iovecs per socket.

Ioctls

These operations can be accessed using ioctl(2):

error = ioctl(ip_socket, ioctl_type, &value_result);

SIOCGSTAMP
Return a struct timeval with the receive timestamp of the last packet passed to the user. This is useful for accurate round trip time measurements. See setitimer(2) for a description of struct timeval. This ioctl should be used only if the socket options SO_TIMESTAMP and SO_TIMESTAMPNS are not set on the socket. Otherwise, it returns the timestamp of the last packet that was received while SO_TIMESTAMP and SO_TIMESTAMPNS were not set, or it fails if no such packet has been received, (i.e., ioctl(2) returns -1 with errno set to ENOENT).

SIOCSPGRP
Set the process or process group that is to receive SIGIO or SIGURG signals when I/O becomes possible or urgent data is available. The argument is a pointer to a pid_t. For further details, see the description of F_SETOWN in fcntl(2).

FIOASYNC
Change the O_ASYNC flag to enable or disable asynchronous I/O mode of the socket. Asynchronous I/O mode means that the SIGIO signal or the signal set with F_SETSIG is raised when a new I/O event occurs.

Argument is an integer boolean flag. (This operation is synonymous with the use of fcntl(2) to set the O_ASYNC flag.)

SIOCGPGRP
Get the current process or process group that receives SIGIO or SIGURG signals, or 0 when none is set.

Valid fcntl(2) operations:

FIOGETOWN
The same as the SIOCGPGRP ioctl(2).

FIOSETOWN
The same as the SIOCSPGRP ioctl(2).

VERSIONS

SO_BINDTODEVICE was introduced in Linux 2.0.30. SO_PASSCRED is new in Linux 2.2. The /proc interfaces were introduced in Linux 2.2. SO_RCVTIMEO and SO_SNDTIMEO are supported since Linux 2.3.41. Earlier, timeouts were fixed to a protocol-specific setting, and could not be read or written.

NOTES

Linux assumes that half of the send/receive buffer is used for internal kernel structures; thus the values in the corresponding /proc files are twice what can be observed on the wire.

Linux will allow port reuse only with the SO_REUSEADDR option when this option was set both in the previous program that performed a bind(2) to the port and in the program that wants to reuse the port. This differs from some implementations (e.g., FreeBSD) where only the later program needs to set the SO_REUSEADDR option. Typically this difference is invisible, since, for example, a server program is designed to always set this option.

SEE ALSO

wireshark(1), bpf(2), connect(2), getsockopt(2), setsockopt(2), socket(2), pcap(3), address_families(7), capabilities(7), ddp(7), ip(7), ipv6(7), packet(7), tcp(7), udp(7), unix(7), tcpdump(8)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

218 - Linux cli command IMPORT_FOREIGN_SCHEMA

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command IMPORT_FOREIGN_SCHEMA and provides detailed information about the command IMPORT_FOREIGN_SCHEMA, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the IMPORT_FOREIGN_SCHEMA.

NAME 🖥️ IMPORT_FOREIGN_SCHEMA 🖥️

import table definitions from a foreign server

SYNOPSIS

IMPORT FOREIGN SCHEMA remote_schema
    [ { LIMIT TO | EXCEPT } ( table_name [, ...] ) ]
    FROM SERVER server_name
    INTO local_schema
    [ OPTIONS ( option value [, ... ] ) ]

DESCRIPTION

IMPORT FOREIGN SCHEMA creates foreign tables that represent tables existing on a foreign server. The new foreign tables will be owned by the user issuing the command and are created with the correct column definitions and options to match the remote tables.

By default, all tables and views existing in a particular schema on the foreign server are imported. Optionally, the list of tables can be limited to a specified subset, or specific tables can be excluded. The new foreign tables are all created in the target schema, which must already exist.

To use IMPORT FOREIGN SCHEMA, the user must have USAGE privilege on the foreign server, as well as CREATE privilege on the target schema.

PARAMETERS

remote_schema

The remote schema to import from. The specific meaning of a remote schema depends on the foreign data wrapper in use.

LIMIT TO ( table_name [, …] )

Import only foreign tables matching one of the given table names. Other tables existing in the foreign schema will be ignored.

EXCEPT ( table_name [, …] )

Exclude specified foreign tables from the import. All tables existing in the foreign schema will be imported except the ones listed here.

server_name

The foreign server to import from.

local_schema

The schema in which the imported foreign tables will be created.

OPTIONS ( option value [, …] )

Options to be used during the import. The allowed option names and values are specific to each foreign data wrapper.

EXAMPLES

Import table definitions from a remote schema foreign_films on server film_server, creating the foreign tables in local schema films:

IMPORT FOREIGN SCHEMA foreign_films FROM SERVER film_server INTO films;

As above, but import only the two tables actors and directors (if they exist):

IMPORT FOREIGN SCHEMA foreign_films LIMIT TO (actors, directors) FROM SERVER film_server INTO films;

COMPATIBILITY

The IMPORT FOREIGN SCHEMA command conforms to the SQL standard, except that the OPTIONS clause is a PostgreSQL extension.

SEE ALSO

CREATE FOREIGN TABLE (CREATE_FOREIGN_TABLE(7)), CREATE SERVER (CREATE_SERVER(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

219 - Linux cli command iso_8859_1

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso_8859_1 and provides detailed information about the command iso_8859_1, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso_8859_1.

NAME 🖥️ iso_8859_1 🖥️

1 - ISO/IEC 8859-1 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-1 encodes the characters used in many West European languages.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-1 characters

The following table displays the characters in ISO/IEC 8859-1 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-1 is also known as Latin-1.

SEE ALSO

ascii(7), charsets(7), cp1252(7), iso_8859-15(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

220 - Linux cli command ossl-guide-quic-client-non-blockssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ossl-guide-quic-client-non-blockssl and provides detailed information about the command ossl-guide-quic-client-non-blockssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ossl-guide-quic-client-non-blockssl.

NAME 🖥️ ossl-guide-quic-client-non-blockssl 🖥️

guide-quic-client-non-block - OpenSSL Guide: Writing a simple nonblocking QUIC client

SIMPLE NONBLOCKING QUIC CLIENT EXAMPLE

This page will build on the example developed on the ossl-guide-quic-client-block (7) page which demonstrates how to write a simple blocking QUIC client. On this page we will amend that demo code so that it supports nonblocking functionality.

The complete source code for this example nonblocking QUIC client is available in the demos/guide directory of the OpenSSL source distribution in the file quic-client-non-block.c. It is also available online at <https://github.com/openssl/openssl/blob/master/demos/guide/quic-client-non-block.c>.

As we saw in the previous example an OpenSSL QUIC application always uses a nonblocking socket. However, despite this, the SSL object still has blocking behaviour. When the SSL object has blocking behaviour then this means that it waits (blocks) until data is available to read if you attempt to read from it when there is no data yet. Similarly it waits when writing if the SSL object is currently unable to write at the moment. This can simplify the development of code because you do not have to worry about what to do in these cases. The execution of the code will simply stop until it is able to continue. However in many cases you do not want this behaviour. Rather than stopping and waiting your application may need to go and do other tasks whilst the SSL object is unable to read/write, for example updating a GUI or performing operations on some other connection or stream.

We will see later in this tutorial how to change the SSL object so that it has nonblocking behaviour. With a nonblocking SSL object, functions such as SSL_read_ex (3) or SSL_write_ex (3) will return immediately with a non-fatal error if they are currently unable to read or write respectively.

Since this page is building on the example developed on the ossl-guide-quic-client-block (7) page we assume that you are familiar with it and we only explain how this example differs.

Performing work while waiting for the socket

In a nonblocking application you will need work to perform in the event that we want to read or write to the SSL object but we are currently unable to. In fact this is the whole point of using a nonblocking SSL object, i.e. to give the application the opportunity to do something else. Whatever it is that the application has to do, it must also be prepared to come back and retry the operation that it previously attempted periodically to see if it can now complete. Ideally it would only do this in the event that something has changed such that it might succeed on the retry attempt, but this does not have to be the case. It can retry at any time.

Note that it is important that you retry exactly the same operation that you tried last time. You cannot start something new. For example if you were attempting to write the text “Hello World” and the operation failed because the SSL object is currently unable to write, then you cannot then attempt to write some other text when you retry the operation.

In this demo application we will create a helper function which simulates doing other work. In fact, for the sake of simplicity, it will do nothing except wait for the state of the underlying socket to change or until a timeout expires after which the state of the SSL object might have changed. We will call our function wait_for_activity().

static void wait_for_activity(SSL *ssl) { fd_set wfds, rfds; int width, sock, isinfinite; struct timeval tv; struct timeval *tvp = NULL; /* Get hold of the underlying file descriptor for the socket */ sock = SSL_get_fd(ssl); FD_ZERO(&wfds); FD_ZERO(&rfds); /* * Find out if we would like to write to the socket, or read from it (or * both) */ if (SSL_net_write_desired(ssl)) FD_SET(sock, &wfds); if (SSL_net_read_desired(ssl)) FD_SET(sock, &rfds); width = sock + 1; /* * Find out when OpenSSL would next like to be called, regardless of * whether the state of the underlying socket has changed or not. */ if (SSL_get_event_timeout(ssl, &tv, &isinfinite) && !isinfinite) tvp = &tv; /* * Wait until the socket is writeable or readable. We use select here * for the sake of simplicity and portability, but you could equally use * poll/epoll or similar functions * * NOTE: For the purposes of this demonstration code this effectively * makes this demo block until it has something more useful to do. In a * real application you probably want to go and do other work here (e.g. * update a GUI, or service other connections). * * Lets say for example that you want to update the progress counter on * a GUI every 100ms. One way to do that would be to use the timeout in * the last parameter to “select” below. If the tvp value is greater * than 100ms then use 100ms instead. Then, when select returns, you * check if it did so because of activity on the file descriptors or * because of the timeout. If the 100ms GUI timeout has expired but the * tvp timeout has not then go and update the GUI and then restart the * “select” (with updated timeouts). */ select(width, &rfds, &wfds, NULL, tvp); }

If you are familiar with how to write nonblocking applications in OpenSSL for TLS (see ossl-guide-tls-client-non-block (7)) then you should note that there is an important difference here between the way a QUIC application and a TLS application works. With a TLS application if we try to read or write something to the SSL object and we get a “retry” response (SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE) then we can assume that is because OpenSSL attempted to read or write to the underlying socket and the socket signalled the “retry”. With QUIC that is not the case. OpenSSL may signal retry as a result of an SSL_read_ex (3) or SSL_write_ex (3) (or similar) call which indicates the state of the stream. This is entirely independent of whether the underlying socket needs to retry or not.

To determine whether OpenSSL currently wants to read or write to the underlying socket for a QUIC application we must call the SSL_net_read_desired (3) and SSL_net_write_desired (3) functions.

It is also important with QUIC that we periodically call an I/O function (or otherwise call the SSL_handle_events (3) function) to ensure that the QUIC connection remains healthy. This is particularly important with a nonblocking application because you are likely to leave the SSL object idle for a while while the application goes off to do other work. The SSL_get_event_timeout (3) function can be used to determine what the deadline is for the next time we need to call an I/O function (or call SSL_handle_events (3)).

An alternative to using SSL_get_event_timeout (3) to find the next deadline that OpenSSL must be called again by is to use “thread assisted” mode. In “thread assisted” mode OpenSSL spawns an additional thread which will periodically call SSL_handle_events (3) automatically, meaning that the application can leave the connection idle safe in the knowledge that the connection will still be maintained in a healthy state. See “Creating the SSL_CTX and SSL objects” below for further details about this.

In this example we are using the select function to check the readability/writeability of the socket because it is very simple to use and is available on most Operating Systems. However you could use any other similar function to do the same thing. select waits for the state of the underlying socket(s) to become readable/writeable or until the timeout has expired before returning.

Handling errors from OpenSSL I/O functions

A QUIC application that has been configured for nonblocking behaviour will need to be prepared to handle errors returned from OpenSSL I/O functions such as SSL_read_ex (3) or SSL_write_ex (3). Errors may be fatal for the stream (for example because the stream has been reset or because the underlying connection has failed), or non-fatal (for example because we are trying to read from the stream but no data has not yet arrived from the peer for that stream).

SSL_read_ex (3) and SSL_write_ex (3) will return 0 to indicate an error and SSL_read (3) and SSL_write (3) will return 0 or a negative value to indicate an error. SSL_shutdown (3) will return a negative value to incidate an error.

In the event of an error an application should call SSL_get_error (3) to find out what type of error has occurred. If the error is non-fatal and can be retried then SSL_get_error (3) will return SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE depending on whether OpenSSL wanted to read to or write from the stream but was unable to. Note that a call to SSL_read_ex (3) or SSL_read (3) can still generate SSL_ERROR_WANT_WRITE. Similarly calls to SSL_write_ex (3) or SSL_write (3) might generate SSL_ERROR_WANT_READ.

Another type of non-fatal error that may occur is SSL_ERROR_ZERO_RETURN. This indicates an EOF (End-Of-File) which can occur if you attempt to read data from an SSL object but the peer has indicated that it will not send any more data on the stream. In this case you may still want to write data to the stream but you will not receive any more data.

Fatal errors that may occur are SSL_ERROR_SYSCALL and SSL_ERROR_SSL. These indicate that the stream is no longer usable. For example, this could be because the stream has been reset by the peer, or because the underlying connection has failed. You can consult the OpenSSL error stack for further details (for example by calling ERR_print_errors (3) to print out details of errors that have occurred). You can also consult the return value of SSL_get_stream_read_state (3) to determine whether the error is local to the stream, or whether the underlying connection has also failed. A return value of SSL_STREAM_STATE_RESET_REMOTE tells you that the stream has been reset by the peer and SSL_STREAM_STATE_CONN_CLOSED tells you that the underlying connection has closed.

In our demo application we will write a function to handle these errors from OpenSSL I/O functions:

static int handle_io_failure(SSL *ssl, int res) { switch (SSL_get_error(ssl, res)) { case SSL_ERROR_WANT_READ: case SSL_ERROR_WANT_WRITE: /* Temporary failure. Wait until we can read/write and try again */ wait_for_activity(ssl); return 1; case SSL_ERROR_ZERO_RETURN: /* EOF */ return 0; case SSL_ERROR_SYSCALL: return -1; case SSL_ERROR_SSL: /* * Some stream fatal error occurred. This could be because of a * stream reset - or some failure occurred on the underlying * connection. */ switch (SSL_get_stream_read_state(ssl)) { case SSL_STREAM_STATE_RESET_REMOTE: printf(“Stream reset occurred “); /* * The stream has been reset but the connection is still * healthy. */ break; case SSL_STREAM_STATE_CONN_CLOSED: printf(“Connection closed “); /* Connection is already closed. */ break; default: printf(“Unknown stream failure “); break; } /* * If the failure is due to a verification error we can get more * information about it from SSL_get_verify_result(). */ if (SSL_get_verify_result(ssl) != X509_V_OK) printf(“Verify error: %s “, X509_verify_cert_error_string(SSL_get_verify_result(ssl))); return -1; default: return -1; } }

This function takes as arguments the SSL object that represents the connection, as well as the return code from the I/O function that failed. In the event of a non-fatal failure, it waits until a retry of the I/O operation might succeed (by using the wait_for_activity() function that we developed in the previous section). It returns 1 in the event of a non-fatal error (except EOF), 0 in the event of EOF, or -1 if a fatal error occurred.

Creating the SSL_CTX and SSL objects

In order to connect to a server we must create SSL_CTX and SSL objects for this. Most of the steps to do this are the same as for a blocking client and are explained on the ossl-guide-quic-client-block (7) page. We won’t repeat that information here.

One key difference is that we must put the SSL object into nonblocking mode (the default is blocking mode). To do that we use the SSL_set_blocking_mode (3) function:

/* * The underlying socket is always nonblocking with QUIC, but the default * behaviour of the SSL object is still to block. We set it for nonblocking * mode in this demo. */ if (!SSL_set_blocking_mode(ssl, 0)) { printf(“Failed to turn off blocking mode “); goto end; }

Although the demo application that we are developing here does not use it, it is possible to use “thread assisted mode” when developing QUIC applications. Normally, when writing an OpenSSL QUIC application, it is important that SSL_handle_events (3) (or alternatively any I/O function) is called on the connection SSL object periodically to maintain the connection in a healthy state. See “Performing work while waiting for the socket” for more discussion on this. This is particularly important to keep in mind when writing a nonblocking QUIC application because it is common to leave the SSL connection object idle for some time when using nonblocking mode. By using “thread assisted mode” a separate thread is created by OpenSSL to do this automatically which means that the application developer does not need to handle this aspect. To do this we must use OSSL_QUIC_client_thread_method (3) when we construct the SSL_CTX as shown below:

ctx = SSL_CTX_new(OSSL_QUIC_client_thread_method()); if (ctx == NULL) { printf(“Failed to create the SSL_CTX “); goto end; }

Performing the handshake

As in the demo for a blocking QUIC client we use the SSL_connect (3) function to perform the handshake with the server. Since we are using a nonblocking SSL object it is very likely that calls to this function will fail with a non-fatal error while we are waiting for the server to respond to our handshake messages. In such a case we must retry the same SSL_connect (3) call at a later time. In this demo we do this in a loop:

/* Do the handshake with the server */ while ((ret = SSL_connect(ssl)) != 1) { if (handle_io_failure(ssl, ret) == 1) continue; /* Retry */ printf(“Failed to connect to server “); goto end; /* Cannot retry: error */ }

We continually call SSL_connect (3) until it gives us a success response. Otherwise we use the handle_io_failure() function that we created earlier to work out what we should do next. Note that we do not expect an EOF to occur at this stage, so such a response is treated in the same way as a fatal error.

Sending and receiving data

As with the blocking QUIC client demo we use the SSL_write_ex (3) function to send data to the server. As with SSL_connect (3) above, because we are using a nonblocking SSL object, this call could fail with a non-fatal error. In that case we should retry exactly the same SSL_write_ex (3) call again. Note that the parameters must be exactly the same, i.e. the same pointer to the buffer to write with the same length. You must not attempt to send different data on a retry. An optional mode does exist (SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER) which will configure OpenSSL to allow the buffer being written to change from one retry to the next. However, in this case, you must still retry exactly the same data - even though the buffer that contains that data may change location. See SSL_CTX_set_mode (3) for further details. As in the TLS tutorials (ossl-guide-tls-client-block (7)) we write the request in three chunks.

/* Write an HTTP GET request to the peer */ while (!SSL_write_ex(ssl, request_start, strlen(request_start), &written)) { if (handle_io_failure(ssl, 0) == 1) continue; /* Retry */ printf(“Failed to write start of HTTP request “); goto end; /* Cannot retry: error */ } while (!SSL_write_ex(ssl, hostname, strlen(hostname), &written)) { if (handle_io_failure(ssl, 0) == 1) continue; /* Retry */ printf(“Failed to write hostname in HTTP request “); goto end; /* Cannot retry: error */ } while (!SSL_write_ex(ssl, request_end, strlen(request_end), &written)) { if (handle_io_failure(ssl, 0) == 1) continue; /* Retry */ printf(“Failed to write end of HTTP request “); goto end; /* Cannot retry: error */ }

On a write we do not expect to see an EOF response so we treat that case in the same way as a fatal error.

Reading a response back from the server is similar:

do { /* * Get up to sizeof(buf) bytes of the response. We keep reading until * the server closes the connection. */ while (!eof && !SSL_read_ex(ssl, buf, sizeof(buf), &readbytes)) { switch (handle_io_failure(ssl, 0)) { case 1: continue; /* Retry */ case 0: eof = 1; continue; case -1: default: printf(“Failed reading remaining data “); goto end; /* Cannot retry: error */ } } /* * OpenSSL does not guarantee that the returned data is a string or * that it is NUL terminated so we use fwrite() to write the exact * number of bytes that we read. The data could be non-printable or * have NUL characters in the middle of it. For this simple example * were going to print it to stdout anyway. */ if (!eof) fwrite(buf, 1, readbytes, stdout); } while (!eof); /* In case the response didnt finish with a newline we add one now */ printf(” “);

The main difference this time is that it is valid for us to receive an EOF response when trying to read data from the server. This will occur when the server closes down the connection after sending all the data in its response.

In this demo we just print out all the data we’ve received back in the response from the server. We continue going around the loop until we either encounter a fatal error, or we receive an EOF (indicating a graceful finish).

Shutting down the connection

As in the QUIC blocking example we must shutdown the connection when we are finished with it.

Even though we have received EOF on the stream that we were reading from above, this tell us nothing about the state of the underlying connection. Our demo application will initiate the connection shutdown process via SSL_shutdown (3).

Since our application is initiating the shutdown then we might expect to see SSL_shutdown (3) give a return value of 0, and then we should continue to call it until we receive a return value of 1 (meaning we have successfully completed the shutdown). Since we are using a nonblocking SSL object we might expect to have to retry this operation several times. If SSL_shutdown (3) returns a negative result then we must call SSL_get_error (3) to work out what to do next. We use our handle_io_failure() function that we developed earlier for this:

/* * Repeatedly call SSL_shutdown() until the connection is fully * closed. */ while ((ret = SSL_shutdown(ssl)) != 1) { if (ret < 0 && handle_io_failure(ssl, ret) == 1) continue; /* Retry */ }

Final clean up

As with the blocking QUIC client example, once our connection is finished with we must free it. The steps to do this for this example are the same as for the blocking example, so we won’t repeat it here.

FURTHER READING

See ossl-guide-quic-client-block (7) to read a tutorial on how to write a blocking QUIC client. See ossl-guide-quic-multi-stream (7) to see how to write a multi-stream QUIC client.

SEE ALSO

ossl-guide-introduction (7), ossl-guide-libraries-introduction (7), ossl-guide-libssl-introduction (7), ossl-guide-quic-introduction (7), ossl-guide-quic-client-block (7), ossl-guide-quic-multi-stream (7)

COPYRIGHT

Copyright 2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

221 - Linux cli command samba

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command samba and provides detailed information about the command samba, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the samba.

NAME 🖥️ samba 🖥️

A Windows AD and SMB/CIFS fileserver for UNIX

SYNOPSIS

samba

DESCRIPTION

The Samba software suite is a collection of programs that implements the Server Message Block (commonly abbreviated as SMB) protocol for UNIX systems and provides Active Directory services. The first version of the SMB protocol is sometimes also referred to as the Common Internet File System (CIFS). For a more thorough description, see http://www.ubiqx.org/cifs/. Samba also implements the NetBIOS protocol in nmbd.

samba(8)

The samba daemon provides the Active Directory services and file and print services to SMB clients. The configuration file for this daemon is described in smb.conf(5).

smbd(8)

The smbd daemon provides the file and print services to SMB clients. The configuration file for this daemon is described in smb.conf(5).

nmbd(8)

The nmbd daemon provides NetBIOS nameservice and browsing support. The configuration file for this daemon is described in smb.conf(5).

winbindd(8)

winbindd is a daemon that is used for integrating authentication and the user database into unix.

smbclient(1)

The smbclient program implements a simple ftp-like client. This is useful for accessing SMB shares on other compatible SMB servers, and can also be used to allow a UNIX box to print to a printer attached to any SMB server.

samba-tool(8)

The samba-tool is the main Samba Administration tool regarding Active Directory services.

testparm(1)

The testparm utility is a simple syntax checker for Sambas smb.conf(5) configuration file. In AD server mode samba-tool testparm should be used though.

smbstatus(1)

The smbstatus tool provides access to information about the current connections to smbd.

nmblookup(1)

The nmblookup tool allows NetBIOS name queries to be made.

smbpasswd(8)

The smbpasswd command is a tool for setting passwords on local Samba but also on remote SMB servers.

smbcacls(1)

The smbcacls command is a tool to set ACLs on remote SMB servers.

smbtree(1)

The smbtree command is a text-based network neighborhood tool.

smbtar(1)

The smbtar can make backups of data directly from SMB servers.

smbspool(8)

smbspool is a helper utility for printing on printers connected to SMB servers.

smbcontrol(1)

smbcontrol is a utility that can change the behaviour of running samba, smbd, nmbd and winbindd daemons.

rpcclient(1)

rpcclient is a utility that can be used to execute RPC commands on remote SMB servers.

pdbedit(8)

The pdbedit command can be used to maintain the local user database on a Samba server.

net(8)

The net command is the main administration tool for Samba member and standalone servers.

wbinfo(1)

wbinfo is a utility that retrieves and stores information related to winbind.

profiles(1)

profiles is a command-line utility that can be used to replace all occurrences of a certain SID with another SID.

log2pcap(1)

log2pcap is a utility for generating pcap trace files from Samba log files.

vfstest(1)

vfstest is a utility that can be used to test vfs modules.

ntlm_auth(1)

ntlm_auth is a helper-utility for external programs wanting to do NTLM-authentication.

smbcquotas(1)

smbcquotas is a tool to manage quotas on remote SMB servers.

COMPONENTS

The Samba suite is made up of several components. Each component is described in a separate manual page. It is strongly recommended that you read the documentation that comes with Samba and the manual pages of those components that you use. If the manual pages and documents arent clear enough then please visit https://devel.samba.org for information on how to file a bug report or submit a patch.

If you require help, visit the Samba webpage at https://www.samba.org/ and explore the many option available to you.

AVAILABILITY

The Samba software suite is licensed under the GNU Public License(GPL). A copy of that license should have come with the package in the file COPYING. You are encouraged to distribute copies of the Samba suite, but please obey the terms of this license.

The latest version of the Samba suite can be obtained from https://download.samba.org/pub/samba/.

The Samba Wiki at https://wiki.samba.org has also a lot of useful information. On the Samba mailing list at https://lists.samba.org you can find a lot of information in the archives and you can subscribe to the samba list and ask for help or discuss things.

VERSION

This man page is part of version 4.20.1-Debian of the Samba suite.

CONTRIBUTIONS

If you wish to contribute to the Samba project, then I suggest you join the Samba mailing list at https://lists.samba.org.

If you have patches to submit, visit https://devel.samba.org/ for information on how to do it properly. We prefer patches in git format-patch format.

CONTRIBUTORS

Contributors to the project are now too numerous to mention here but all deserve the thanks of all Samba users. To see a full list, look at the change-log in the source package for the pre-CVS changes and at https://git.samba.org/ for the contributors to Samba post-GIT. GIT is the Open Source source code control system used by the Samba Team to develop Samba. The project would have been unmanageable without it.

AUTHOR

The original Samba software and related utilities were created by Andrew Tridgell. Samba is now developed by the Samba Team as an Open Source project similar to the way the Linux kernel is developed.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

222 - Linux cli command CREATE_AGGREGATE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_AGGREGATE and provides detailed information about the command CREATE_AGGREGATE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_AGGREGATE.

NAME 🖥️ CREATE_AGGREGATE 🖥️

define a new aggregate function

SYNOPSIS

CREATE [ OR REPLACE ] AGGREGATE name ( [ argmode ] [ argname ] arg_data_type [ , ... ] ) (
    SFUNC = sfunc,
    STYPE = state_data_type
    [ , SSPACE = state_data_size ]
    [ , FINALFUNC = ffunc ]
    [ , FINALFUNC_EXTRA ]
    [ , FINALFUNC_MODIFY = { READ_ONLY | SHAREABLE | READ_WRITE } ]
    [ , COMBINEFUNC = combinefunc ]
    [ , SERIALFUNC = serialfunc ]
    [ , DESERIALFUNC = deserialfunc ]
    [ , INITCOND = initial_condition ]
    [ , MSFUNC = msfunc ]
    [ , MINVFUNC = minvfunc ]
    [ , MSTYPE = mstate_data_type ]
    [ , MSSPACE = mstate_data_size ]
    [ , MFINALFUNC = mffunc ]
    [ , MFINALFUNC_EXTRA ]
    [ , MFINALFUNC_MODIFY = { READ_ONLY | SHAREABLE | READ_WRITE } ]
    [ , MINITCOND = minitial_condition ]
    [ , SORTOP = sort_operator ]
    [ , PARALLEL = { SAFE | RESTRICTED | UNSAFE } ]
)

CREATE [ OR REPLACE ] AGGREGATE name ( [ [ argmode ] [ argname ] arg_data_type [ , ... ] ]
                        ORDER BY [ argmode ] [ argname ] arg_data_type [ , ... ] ) (
    SFUNC = sfunc,
    STYPE = state_data_type
    [ , SSPACE = state_data_size ]
    [ , FINALFUNC = ffunc ]
    [ , FINALFUNC_EXTRA ]
    [ , FINALFUNC_MODIFY = { READ_ONLY | SHAREABLE | READ_WRITE } ]
    [ , INITCOND = initial_condition ]
    [ , PARALLEL = { SAFE | RESTRICTED | UNSAFE } ]
    [ , HYPOTHETICAL ]
)

or the old syntax

CREATE [ OR REPLACE ] AGGREGATE name (
    BASETYPE = base_type,
    SFUNC = sfunc,
    STYPE = state_data_type
    [ , SSPACE = state_data_size ]
    [ , FINALFUNC = ffunc ]
    [ , FINALFUNC_EXTRA ]
    [ , FINALFUNC_MODIFY = { READ_ONLY | SHAREABLE | READ_WRITE } ]
    [ , COMBINEFUNC = combinefunc ]
    [ , SERIALFUNC = serialfunc ]
    [ , DESERIALFUNC = deserialfunc ]
    [ , INITCOND = initial_condition ]
    [ , MSFUNC = msfunc ]
    [ , MINVFUNC = minvfunc ]
    [ , MSTYPE = mstate_data_type ]
    [ , MSSPACE = mstate_data_size ]
    [ , MFINALFUNC = mffunc ]
    [ , MFINALFUNC_EXTRA ]
    [ , MFINALFUNC_MODIFY = { READ_ONLY | SHAREABLE | READ_WRITE } ]
    [ , MINITCOND = minitial_condition ]
    [ , SORTOP = sort_operator ]
)

DESCRIPTION

CREATE AGGREGATE defines a new aggregate function. CREATE OR REPLACE AGGREGATE will either define a new aggregate function or replace an existing definition. Some basic and commonly-used aggregate functions are included with the distribution; they are documented in Section 9.21. If one defines new types or needs an aggregate function not already provided, then CREATE AGGREGATE can be used to provide the desired features.

When replacing an existing definition, the argument types, result type, and number of direct arguments may not be changed. Also, the new definition must be of the same kind (ordinary aggregate, ordered-set aggregate, or hypothetical-set aggregate) as the old one.

If a schema name is given (for example, CREATE AGGREGATE myschema.myagg …) then the aggregate function is created in the specified schema. Otherwise it is created in the current schema.

An aggregate function is identified by its name and input data type(s). Two aggregates in the same schema can have the same name if they operate on different input types. The name and input data type(s) of an aggregate must also be distinct from the name and input data type(s) of every ordinary function in the same schema. This behavior is identical to overloading of ordinary function names (see CREATE FUNCTION (CREATE_FUNCTION(7))).

A simple aggregate function is made from one or two ordinary functions: a state transition function sfunc, and an optional final calculation function ffunc. These are used as follows:

sfunc( internal-state, next-data-values ) —> next-internal-state ffunc( internal-state ) —> aggregate-value

PostgreSQL creates a temporary variable of data type stype to hold the current internal state of the aggregate. At each input row, the aggregate argument value(s) are calculated and the state transition function is invoked with the current state value and the new argument value(s) to calculate a new internal state value. After all the rows have been processed, the final function is invoked once to calculate the aggregates return value. If there is no final function then the ending state value is returned as-is.

An aggregate function can provide an initial condition, that is, an initial value for the internal state value. This is specified and stored in the database as a value of type text, but it must be a valid external representation of a constant of the state value data type. If it is not supplied then the state value starts out null.

If the state transition function is declared “strict”, then it cannot be called with null inputs. With such a transition function, aggregate execution behaves as follows. Rows with any null input values are ignored (the function is not called and the previous state value is retained). If the initial state value is null, then at the first row with all-nonnull input values, the first argument value replaces the state value, and the transition function is invoked at each subsequent row with all-nonnull input values. This is handy for implementing aggregates like max. Note that this behavior is only available when state_data_type is the same as the first arg_data_type. When these types are different, you must supply a nonnull initial condition or use a nonstrict transition function.

If the state transition function is not strict, then it will be called unconditionally at each input row, and must deal with null inputs and null state values for itself. This allows the aggregate author to have full control over the aggregates handling of null values.

If the final function is declared “strict”, then it will not be called when the ending state value is null; instead a null result will be returned automatically. (Of course this is just the normal behavior of strict functions.) In any case the final function has the option of returning a null value. For example, the final function for avg returns null when it sees there were zero input rows.

Sometimes it is useful to declare the final function as taking not just the state value, but extra parameters corresponding to the aggregates input values. The main reason for doing this is if the final function is polymorphic and the state values data type would be inadequate to pin down the result type. These extra parameters are always passed as NULL (and so the final function must not be strict when the FINALFUNC_EXTRA option is used), but nonetheless they are valid parameters. The final function could for example make use of get_fn_expr_argtype to identify the actual argument type in the current call.

An aggregate can optionally support moving-aggregate mode, as described in Section 38.12.1. This requires specifying the MSFUNC, MINVFUNC, and MSTYPE parameters, and optionally the MSSPACE, MFINALFUNC, MFINALFUNC_EXTRA, MFINALFUNC_MODIFY, and MINITCOND parameters. Except for MINVFUNC, these parameters work like the corresponding simple-aggregate parameters without M; they define a separate implementation of the aggregate that includes an inverse transition function.

The syntax with ORDER BY in the parameter list creates a special type of aggregate called an ordered-set aggregate; or if HYPOTHETICAL is specified, then a hypothetical-set aggregate is created. These aggregates operate over groups of sorted values in order-dependent ways, so that specification of an input sort order is an essential part of a call. Also, they can have direct arguments, which are arguments that are evaluated only once per aggregation rather than once per input row. Hypothetical-set aggregates are a subclass of ordered-set aggregates in which some of the direct arguments are required to match, in number and data types, the aggregated argument columns. This allows the values of those direct arguments to be added to the collection of aggregate-input rows as an additional “hypothetical” row.

An aggregate can optionally support partial aggregation, as described in Section 38.12.4. This requires specifying the COMBINEFUNC parameter. If the state_data_type is internal, its usually also appropriate to provide the SERIALFUNC and DESERIALFUNC parameters so that parallel aggregation is possible. Note that the aggregate must also be marked PARALLEL SAFE to enable parallel aggregation.

Aggregates that behave like MIN or MAX can sometimes be optimized by looking into an index instead of scanning every input row. If this aggregate can be so optimized, indicate it by specifying a sort operator. The basic requirement is that the aggregate must yield the first element in the sort ordering induced by the operator; in other words:

SELECT agg(col) FROM tab;

must be equivalent to:

SELECT col FROM tab ORDER BY col USING sortop LIMIT 1;

Further assumptions are that the aggregate ignores null inputs, and that it delivers a null result if and only if there were no non-null inputs. Ordinarily, a data types < operator is the proper sort operator for MIN, and > is the proper sort operator for MAX. Note that the optimization will never actually take effect unless the specified operator is the “less than” or “greater than” strategy member of a B-tree index operator class.

To be able to create an aggregate function, you must have USAGE privilege on the argument types, the state type(s), and the return type, as well as EXECUTE privilege on the supporting functions.

PARAMETERS

name

The name (optionally schema-qualified) of the aggregate function to create.

argmode

The mode of an argument: IN or VARIADIC. (Aggregate functions do not support OUT arguments.) If omitted, the default is IN. Only the last argument can be marked VARIADIC.

argname

The name of an argument. This is currently only useful for documentation purposes. If omitted, the argument has no name.

arg_data_type

An input data type on which this aggregate function operates. To create a zero-argument aggregate function, write * in place of the list of argument specifications. (An example of such an aggregate is count(*).)

base_type

In the old syntax for CREATE AGGREGATE, the input data type is specified by a basetype parameter rather than being written next to the aggregate name. Note that this syntax allows only one input parameter. To define a zero-argument aggregate function with this syntax, specify the basetype as “ANY” (not *). Ordered-set aggregates cannot be defined with the old syntax.

sfunc

The name of the state transition function to be called for each input row. For a normal N-argument aggregate function, the sfunc must take N+1 arguments, the first being of type state_data_type and the rest matching the declared input data type(s) of the aggregate. The function must return a value of type state_data_type. This function takes the current state value and the current input data value(s), and returns the next state value.

For ordered-set (including hypothetical-set) aggregates, the state transition function receives only the current state value and the aggregated arguments, not the direct arguments. Otherwise it is the same.

state_data_type

The data type for the aggregates state value.

state_data_size

The approximate average size (in bytes) of the aggregates state value. If this parameter is omitted or is zero, a default estimate is used based on the state_data_type. The planner uses this value to estimate the memory required for a grouped aggregate query.

ffunc

The name of the final function called to compute the aggregates result after all input rows have been traversed. For a normal aggregate, this function must take a single argument of type state_data_type. The return data type of the aggregate is defined as the return type of this function. If ffunc is not specified, then the ending state value is used as the aggregates result, and the return type is state_data_type.

For ordered-set (including hypothetical-set) aggregates, the final function receives not only the final state value, but also the values of all the direct arguments.

If FINALFUNC_EXTRA is specified, then in addition to the final state value and any direct arguments, the final function receives extra NULL values corresponding to the aggregates regular (aggregated) arguments. This is mainly useful to allow correct resolution of the aggregate result type when a polymorphic aggregate is being defined.

FINALFUNC_MODIFY = { READ_ONLY | SHAREABLE | READ_WRITE }

This option specifies whether the final function is a pure function that does not modify its arguments. READ_ONLY indicates it does not; the other two values indicate that it may change the transition state value. See Notes below for more detail. The default is READ_ONLY, except for ordered-set aggregates, for which the default is READ_WRITE.

combinefunc

The combinefunc function may optionally be specified to allow the aggregate function to support partial aggregation. If provided, the combinefunc must combine two state_data_type values, each containing the result of aggregation over some subset of the input values, to produce a new state_data_type that represents the result of aggregating over both sets of inputs. This function can be thought of as an sfunc, where instead of acting upon an individual input row and adding it to the running aggregate state, it adds another aggregate state to the running state.

The combinefunc must be declared as taking two arguments of the state_data_type and returning a value of the state_data_type. Optionally this function may be “strict”. In this case the function will not be called when either of the input states are null; the other state will be taken as the correct result.

For aggregate functions whose state_data_type is internal, the combinefunc must not be strict. In this case the combinefunc must ensure that null states are handled correctly and that the state being returned is properly stored in the aggregate memory context.

serialfunc

An aggregate function whose state_data_type is internal can participate in parallel aggregation only if it has a serialfunc function, which must serialize the aggregate state into a bytea value for transmission to another process. This function must take a single argument of type internal and return type bytea. A corresponding deserialfunc is also required.

deserialfunc

Deserialize a previously serialized aggregate state back into state_data_type. This function must take two arguments of types bytea and internal, and produce a result of type internal. (Note: the second, internal argument is unused, but is required for type safety reasons.)

initial_condition

The initial setting for the state value. This must be a string constant in the form accepted for the data type state_data_type. If not specified, the state value starts out null.

msfunc

The name of the forward state transition function to be called for each input row in moving-aggregate mode. This is exactly like the regular transition function, except that its first argument and result are of type mstate_data_type, which might be different from state_data_type.

minvfunc

The name of the inverse state transition function to be used in moving-aggregate mode. This function has the same argument and result types as msfunc, but it is used to remove a value from the current aggregate state, rather than add a value to it. The inverse transition function must have the same strictness attribute as the forward state transition function.

mstate_data_type

The data type for the aggregates state value, when using moving-aggregate mode.

mstate_data_size

The approximate average size (in bytes) of the aggregates state value, when using moving-aggregate mode. This works the same as state_data_size.

mffunc

The name of the final function called to compute the aggregates result after all input rows have been traversed, when using moving-aggregate mode. This works the same as ffunc, except that its first arguments type is mstate_data_type and extra dummy arguments are specified by writing MFINALFUNC_EXTRA. The aggregate result type determined by mffunc or mstate_data_type must match that determined by the aggregates regular implementation.

MFINALFUNC_MODIFY = { READ_ONLY | SHAREABLE | READ_WRITE }

This option is like FINALFUNC_MODIFY, but it describes the behavior of the moving-aggregate final function.

minitial_condition

The initial setting for the state value, when using moving-aggregate mode. This works the same as initial_condition.

sort_operator

The associated sort operator for a MIN- or MAX-like aggregate. This is just an operator name (possibly schema-qualified). The operator is assumed to have the same input data types as the aggregate (which must be a single-argument normal aggregate).

PARALLEL = { SAFE | RESTRICTED | UNSAFE }

The meanings of PARALLEL SAFE, PARALLEL RESTRICTED, and PARALLEL UNSAFE are the same as in CREATE FUNCTION. An aggregate will not be considered for parallelization if it is marked PARALLEL UNSAFE (which is the default!) or PARALLEL RESTRICTED. Note that the parallel-safety markings of the aggregates support functions are not consulted by the planner, only the marking of the aggregate itself.

HYPOTHETICAL

For ordered-set aggregates only, this flag specifies that the aggregate arguments are to be processed according to the requirements for hypothetical-set aggregates: that is, the last few direct arguments must match the data types of the aggregated (WITHIN GROUP) arguments. The HYPOTHETICAL flag has no effect on run-time behavior, only on parse-time resolution of the data types and collations of the aggregates arguments.

The parameters of CREATE AGGREGATE can be written in any order, not just the order illustrated above.

NOTES

In parameters that specify support function names, you can write a schema name if needed, for example SFUNC = public.sum. Do not write argument types there, however — the argument types of the support functions are determined from other parameters.

Ordinarily, PostgreSQL functions are expected to be true functions that do not modify their input values. However, an aggregate transition function, when used in the context of an aggregate, is allowed to cheat and modify its transition-state argument in place. This can provide substantial performance benefits compared to making a fresh copy of the transition state each time.

Likewise, while an aggregate final function is normally expected not to modify its input values, sometimes it is impractical to avoid modifying the transition-state argument. Such behavior must be declared using the FINALFUNC_MODIFY parameter. The READ_WRITE value indicates that the final function modifies the transition state in unspecified ways. This value prevents use of the aggregate as a window function, and it also prevents merging of transition states for aggregate calls that share the same input values and transition functions. The SHAREABLE value indicates that the transition function cannot be applied after the final function, but multiple final-function calls can be performed on the ending transition state value. This value prevents use of the aggregate as a window function, but it allows merging of transition states. (That is, the optimization of interest here is not applying the same final function repeatedly, but applying different final functions to the same ending transition state value. This is allowed as long as none of the final functions are marked READ_WRITE.)

If an aggregate supports moving-aggregate mode, it will improve calculation efficiency when the aggregate is used as a window function for a window with moving frame start (that is, a frame start mode other than UNBOUNDED PRECEDING). Conceptually, the forward transition function adds input values to the aggregates state when they enter the window frame from the bottom, and the inverse transition function removes them again when they leave the frame at the top. So, when values are removed, they are always removed in the same order they were added. Whenever the inverse transition function is invoked, it will thus receive the earliest added but not yet removed argument value(s). The inverse transition function can assume that at least one row will remain in the current state after it removes the oldest row. (When this would not be the case, the window function mechanism simply starts a fresh aggregation, rather than using the inverse transition function.)

The forward transition function for moving-aggregate mode is not allowed to return NULL as the new state value. If the inverse transition function returns NULL, this is taken as an indication that the inverse function cannot reverse the state calculation for this particular input, and so the aggregate calculation will be redone from scratch for the current frame starting position. This convention allows moving-aggregate mode to be used in situations where there are some infrequent cases that are impractical to reverse out of the running state value.

If no moving-aggregate implementation is supplied, the aggregate can still be used with moving frames, but PostgreSQL will recompute the whole aggregation whenever the start of the frame moves. Note that whether or not the aggregate supports moving-aggregate mode, PostgreSQL can handle a moving frame end without recalculation; this is done by continuing to add new values to the aggregates state. This is why use of an aggregate as a window function requires that the final function be read-only: it must not damage the aggregates state value, so that the aggregation can be continued even after an aggregate result value has been obtained for one set of frame boundaries.

The syntax for ordered-set aggregates allows VARIADIC to be specified for both the last direct parameter and the last aggregated (WITHIN GROUP) parameter. However, the current implementation restricts use of VARIADIC in two ways. First, ordered-set aggregates can only use VARIADIC “any”, not other variadic array types. Second, if the last direct parameter is VARIADIC “any”, then there can be only one aggregated parameter and it must also be VARIADIC “any”. (In the representation used in the system catalogs, these two parameters are merged into a single VARIADIC “any” item, since pg_proc cannot represent functions with more than one VARIADIC parameter.) If the aggregate is a hypothetical-set aggregate, the direct arguments that match the VARIADIC “any” parameter are the hypothetical ones; any preceding parameters represent additional direct arguments that are not constrained to match the aggregated arguments.

Currently, ordered-set aggregates do not need to support moving-aggregate mode, since they cannot be used as window functions.

Partial (including parallel) aggregation is currently not supported for ordered-set aggregates. Also, it will never be used for aggregate calls that include DISTINCT or ORDER BY clauses, since those semantics cannot be supported during partial aggregation.

EXAMPLES

See Section 38.12.

COMPATIBILITY

CREATE AGGREGATE is a PostgreSQL language extension. The SQL standard does not provide for user-defined aggregate functions.

SEE ALSO

ALTER AGGREGATE (ALTER_AGGREGATE(7)), DROP AGGREGATE (DROP_AGGREGATE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

223 - Linux cli command EVP_SIGNATURE-Siphashssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_SIGNATURE-Siphashssl and provides detailed information about the command EVP_SIGNATURE-Siphashssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_SIGNATURE-Siphashssl.

NAME 🖥️ EVP_SIGNATURE-Siphashssl 🖥️

HMAC, EVP_SIGNATURE-Siphash, EVP_SIGNATURE-Poly1305, EVP_SIGNATURE-CMAC - The legacy EVP_PKEY MAC signature implementations

DESCRIPTION

The algorithms described here have legacy support for creating MACs using EVP_DigestSignInit (3) and related functions. This is not the preferred way of creating MACs. Instead you should use the newer EVP_MAC_init (3) functions. This mechanism is provided for backwards compatibility with older versions of OpenSSL.

The same signature parameters can be set using EVP_PKEY_CTX_set_params() as can be set via EVP_MAC_CTX_set_params() for the underlying EVP_MAC. See EVP_MAC-HMAC (7), EVP_MAC-Siphash (7), EVP_MAC-Poly1305 (7) and EVP_MAC-CMAC (7) for details.

See L<EVP_PKEY-HMAC(7)>, L<EVP_PKEY-Siphash(7)>, L<EVP_PKEY-Poly1305(7)> or L<EVP_PKEY-CMAC(7)> for details about parameters that are supported during the creation of an EVP_PKEY.

SEE ALSO

EVP_MAC_init (3), EVP_DigestSignInit (3), EVP_PKEY-HMAC (7), EVP_PKEY-Siphash (7), EVP_PKEY-Poly1305 (7), EVP_PKEY-CMAC (7), EVP_MAC-HMAC (7), EVP_MAC-Siphash (7), EVP_MAC-Poly1305 (7), EVP_MAC-CMAC (7), provider-signature (7),

COPYRIGHT

Copyright 2020 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

224 - Linux cli command shm_overview

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command shm_overview and provides detailed information about the command shm_overview, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the shm_overview.

NAME 🖥️ shm_overview 🖥️

overview of POSIX shared memory

DESCRIPTION

The POSIX shared memory API allows processes to communicate information by sharing a region of memory.

The interfaces employed in the API are:

shm_open(3)
Create and open a new object, or open an existing object. This is analogous to open(2). The call returns a file descriptor for use by the other interfaces listed below.

ftruncate(2)
Set the size of the shared memory object. (A newly created shared memory object has a length of zero.)

mmap(2)
Map the shared memory object into the virtual address space of the calling process.

munmap(2)
Unmap the shared memory object from the virtual address space of the calling process.

shm_unlink(3)
Remove a shared memory object name.

close(2)
Close the file descriptor allocated by shm_open(3) when it is no longer needed.

fstat(2)
Obtain a stat structure that describes the shared memory object. Among the information returned by this call are the object’s size (st_size), permissions (st_mode), owner (st_uid), and group (st_gid).

fchown(2)
To change the ownership of a shared memory object.

fchmod(2)
To change the permissions of a shared memory object.

Versions

POSIX shared memory is supported since Linux 2.4 and glibc 2.2.

Persistence

POSIX shared memory objects have kernel persistence: a shared memory object will exist until the system is shut down, or until all processes have unmapped the object and it has been deleted with shm_unlink(3)

Linking

Programs using the POSIX shared memory API must be compiled with cc -lrt to link against the real-time library, librt.

Accessing shared memory objects via the filesystem

On Linux, shared memory objects are created in a (tmpfs(5)) virtual filesystem, normally mounted under /dev/shm. Since Linux 2.6.19, Linux supports the use of access control lists (ACLs) to control the permissions of objects in the virtual filesystem.

NOTES

Typically, processes must synchronize their access to a shared memory object, using, for example, POSIX semaphores.

System V shared memory (shmget(2), shmop(2), etc.) is an older shared memory API. POSIX shared memory provides a simpler, and better designed interface; on the other hand POSIX shared memory is somewhat less widely available (especially on older systems) than System V shared memory.

SEE ALSO

fchmod(2), fchown(2), fstat(2), ftruncate(2), memfd_create(2), mmap(2), mprotect(2), munmap(2), shmget(2), shmop(2), shm_open(3), shm_unlink(3), sem_overview(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

225 - Linux cli command ipc_namespaces

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ipc_namespaces and provides detailed information about the command ipc_namespaces, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ipc_namespaces.

NAME 🖥️ ipc_namespaces 🖥️

overview of Linux IPC namespaces

DESCRIPTION

IPC namespaces isolate certain IPC resources, namely, System V IPC objects (see sysvipc(7)) and (since Linux 2.6.30) POSIX message queues (see mq_overview(7)). The common characteristic of these IPC mechanisms is that IPC objects are identified by mechanisms other than filesystem pathnames.

Each IPC namespace has its own set of System V IPC identifiers and its own POSIX message queue filesystem. Objects created in an IPC namespace are visible to all other processes that are members of that namespace, but are not visible to processes in other IPC namespaces.

The following /proc interfaces are distinct in each IPC namespace:

  • The POSIX message queue interfaces in /proc/sys/fs/mqueue.

  • The System V IPC interfaces in /proc/sys/kernel, namely: msgmax, msgmnb, msgmni, sem, shmall, shmmax, shmmni, and shm_rmid_forced.

  • The System V IPC interfaces in /proc/sysvipc.

When an IPC namespace is destroyed (i.e., when the last process that is a member of the namespace terminates), all IPC objects in the namespace are automatically destroyed.

Use of IPC namespaces requires a kernel that is configured with the CONFIG_IPC_NS option.

SEE ALSO

nsenter(1), unshare(1), clone(2), setns(2), unshare(2), mq_overview(7), namespaces(7), sysvipc(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

226 - Linux cli command RSAssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command RSAssl and provides detailed information about the command RSAssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the RSAssl.

NAME 🖥️ RSAssl 🖥️

RSA, EVP_KEYMGMT-RSA, RSA - EVP_PKEY RSA keytype and algorithm support

DESCRIPTION

The RSA keytype is implemented in OpenSSL’s default and FIPS providers. That implementation supports the basic RSA keys, containing the modulus n, the public exponent e, the private exponent d, and a collection of prime factors, exponents and coefficient for CRT calculations, of which the first few are known as p and q, dP and dQ, and qInv.

Common RSA parameters

In addition to the common parameters that all keytypes should support (see “Common parameters” in provider-keymgmt (7)), the RSA keytype implementation supports the following.

“n” (OSSL_PKEY_PARAM_RSA_N) <unsigned integer>
The RSA modulus “n” value.

“e” (OSSL_PKEY_PARAM_RSA_E) <unsigned integer>
The RSA public exponent “e” value. This value must always be set when creating a raw key using EVP_PKEY_fromdata (3). Note that when a decryption operation is performed, that this value is used for blinding purposes to prevent timing attacks.

“d” (OSSL_PKEY_PARAM_RSA_D) <unsigned integer>
The RSA private exponent “d” value.

“rsa-factor1” (OSSL_PKEY_PARAM_RSA_FACTOR1) <unsigned integer>

“rsa-factor2” (OSSL_PKEY_PARAM_RSA_FACTOR2) <unsigned integer>

“rsa-factor3” (OSSL_PKEY_PARAM_RSA_FACTOR3) <unsigned integer>

“rsa-factor4” (OSSL_PKEY_PARAM_RSA_FACTOR4) <unsigned integer>

“rsa-factor5” (OSSL_PKEY_PARAM_RSA_FACTOR5) <unsigned integer>

“rsa-factor6” (OSSL_PKEY_PARAM_RSA_FACTOR6) <unsigned integer>

“rsa-factor7” (OSSL_PKEY_PARAM_RSA_FACTOR7) <unsigned integer>

“rsa-factor8” (OSSL_PKEY_PARAM_RSA_FACTOR8) <unsigned integer>

“rsa-factor9” (OSSL_PKEY_PARAM_RSA_FACTOR9) <unsigned integer>

“rsa-factor10” (OSSL_PKEY_PARAM_RSA_FACTOR10) <unsigned integer>

RSA prime factors. The factors are known as “p”, “q” and “r_i” in RFC8017. Up to eight additional “r_i” prime factors are supported.

“rsa-exponent1” (OSSL_PKEY_PARAM_RSA_EXPONENT1) <unsigned integer>

“rsa-exponent2” (OSSL_PKEY_PARAM_RSA_EXPONENT2) <unsigned integer>

“rsa-exponent3” (OSSL_PKEY_PARAM_RSA_EXPONENT3) <unsigned integer>

“rsa-exponent4” (OSSL_PKEY_PARAM_RSA_EXPONENT4) <unsigned integer>

“rsa-exponent5” (OSSL_PKEY_PARAM_RSA_EXPONENT5) <unsigned integer>

“rsa-exponent6” (OSSL_PKEY_PARAM_RSA_EXPONENT6) <unsigned integer>

“rsa-exponent7” (OSSL_PKEY_PARAM_RSA_EXPONENT7) <unsigned integer>

“rsa-exponent8” (OSSL_PKEY_PARAM_RSA_EXPONENT8) <unsigned integer>

“rsa-exponent9” (OSSL_PKEY_PARAM_RSA_EXPONENT9) <unsigned integer>

“rsa-exponent10” (OSSL_PKEY_PARAM_RSA_EXPONENT10) <unsigned integer>

RSA CRT (Chinese Remainder Theorem) exponents. The exponents are known as “dP”, “dQ” and “d_i” in RFC8017. Up to eight additional “d_i” exponents are supported.

“rsa-coefficient1” (OSSL_PKEY_PARAM_RSA_COEFFICIENT1) <unsigned integer>

“rsa-coefficient2” (OSSL_PKEY_PARAM_RSA_COEFFICIENT2) <unsigned integer>

“rsa-coefficient3” (OSSL_PKEY_PARAM_RSA_COEFFICIENT3) <unsigned integer>

“rsa-coefficient4” (OSSL_PKEY_PARAM_RSA_COEFFICIENT4) <unsigned integer>

“rsa-coefficient5” (OSSL_PKEY_PARAM_RSA_COEFFICIENT5) <unsigned integer>

“rsa-coefficient6” (OSSL_PKEY_PARAM_RSA_COEFFICIENT6) <unsigned integer>

“rsa-coefficient7” (OSSL_PKEY_PARAM_RSA_COEFFICIENT7) <unsigned integer>

“rsa-coefficient8” (OSSL_PKEY_PARAM_RSA_COEFFICIENT8) <unsigned integer>

“rsa-coefficient9” (OSSL_PKEY_PARAM_RSA_COEFFICIENT9) <unsigned integer>

RSA CRT (Chinese Remainder Theorem) coefficients. The coefficients are known as “qInv” and “t_i”. Up to eight additional “t_i” exponents are supported.

RSA key generation parameters

When generating RSA keys, the following key generation parameters may be used.

“bits” (OSSL_PKEY_PARAM_RSA_BITS) <unsigned integer>
The value should be the cryptographic length for the RSA cryptosystem, in bits.

“primes” (OSSL_PKEY_PARAM_RSA_PRIMES) <unsigned integer>
The value should be the number of primes for the generated RSA key. The default is 2. It isn’t permitted to specify a larger number of primes than 10. Additionally, the number of primes is limited by the length of the key being generated so the maximum number could be less. Some providers may only support a value of 2.

“e” (OSSL_PKEY_PARAM_RSA_E) <unsigned integer>
The RSA “e” value. The value may be any odd number greater than or equal to 65537. The default value is 65537. For legacy reasons a value of 3 is currently accepted but is deprecated.

RSA key generation parameters for FIPS module testing

When generating RSA keys, the following additional key generation parameters may be used for algorithm testing purposes only. Do not use these to generate RSA keys for a production environment.

“xp” (OSSL_PKEY_PARAM_RSA_TEST_XP) <unsigned integer>

“xq” (OSSL_PKEY_PARAM_RSA_TEST_XQ) <unsigned integer>

These 2 fields are normally randomly generated and are used to generate “p” and “q”.

“xp1” (OSSL_PKEY_PARAM_RSA_TEST_XP1) <unsigned integer>

“xp2” (OSSL_PKEY_PARAM_RSA_TEST_XP2) <unsigned integer>

“xq1” (OSSL_PKEY_PARAM_RSA_TEST_XQ1) <unsigned integer>

“xq2” (OSSL_PKEY_PARAM_RSA_TEST_XQ2) <unsigned integer>

These 4 fields are normally randomly generated. The prime factors “p1”, “p2”, “q1” and “q2” are determined from these values.

RSA key parameters for FIPS module testing

The following intermediate values can be retrieved only if the values specified in “RSA key generation parameters for FIPS module testing” are set. These should not be accessed in a production environment.

“p1” (OSSL_PKEY_PARAM_RSA_TEST_P1) <unsigned integer>

“p2” (OSSL_PKEY_PARAM_RSA_TEST_P2) <unsigned integer>

“q1” (OSSL_PKEY_PARAM_RSA_TEST_Q1) <unsigned integer>

“q2” (OSSL_PKEY_PARAM_RSA_TEST_Q2) <unsigned integer>

The auxiliary probable primes.

RSA key validation

For RSA keys, EVP_PKEY_param_check (3) and EVP_PKEY_param_check_quick (3) both return 1 unconditionally.

For RSA keys, EVP_PKEY_public_check (3) conforms to the SP800-56Br1 public key check when the OpenSSL FIPS provider is used. The OpenSSL default provider performs similar tests but relaxes the keysize restrictions for backwards compatibility.

For RSA keys, EVP_PKEY_public_check_quick (3) is the same as EVP_PKEY_public_check (3).

For RSA keys, EVP_PKEY_private_check (3) conforms to the SP800-56Br1 private key test.

For RSA keys, EVP_PKEY_pairwise_check (3) conforms to the SP800-56Br1 KeyPair Validation check for the OpenSSL FIPS provider. The OpenSSL default provider allows testing of the validity of multi-primes.

CONFORMING TO

FIPS186-4
Section B.3.6 Generation of Probable Primes with Conditions Based on Auxiliary Probable Primes

RFC 8017, excluding RSA-PSS and RSA-OAEP

EXAMPLES

An EVP_PKEY context can be obtained by calling:

EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “RSA”, NULL);

An RSA key can be generated simply like this:

pkey = EVP_RSA_gen(4096);

or like this:

EVP_PKEY *pkey = NULL; EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “RSA”, NULL); EVP_PKEY_keygen_init(pctx); EVP_PKEY_generate(pctx, &pkey); EVP_PKEY_CTX_free(pctx);

An RSA key can be generated with key generation parameters:

unsigned int primes = 3; unsigned int bits = 4096; OSSL_PARAM params[3]; EVP_PKEY *pkey = NULL; EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “RSA”, NULL); EVP_PKEY_keygen_init(pctx); params[0] = OSSL_PARAM_construct_uint(“bits”, &bits); params[1] = OSSL_PARAM_construct_uint(“primes”, &primes); params[2] = OSSL_PARAM_construct_end(); EVP_PKEY_CTX_set_params(pctx, params); EVP_PKEY_generate(pctx, &pkey); EVP_PKEY_print_private(bio_out, pkey, 0, NULL); EVP_PKEY_CTX_free(pctx);

SEE ALSO

EVP_RSA_gen (3), EVP_KEYMGMT (3), EVP_PKEY (3), provider-keymgmt (7)

COPYRIGHT

Copyright 2020-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

227 - Linux cli command EVP_SIGNATURE-ED25519ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_SIGNATURE-ED25519ssl and provides detailed information about the command EVP_SIGNATURE-ED25519ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_SIGNATURE-ED25519ssl.

NAME 🖥️ EVP_SIGNATURE-ED25519ssl 🖥️

ED25519, EVP_SIGNATURE-ED448, Ed25519, Ed448 - EVP_PKEY Ed25519 and Ed448 support

DESCRIPTION

The Ed25519 and Ed448 EVP_PKEY implementation supports key generation, one-shot digest-sign and digest-verify using the EdDSA signature scheme described in RFC 8032. It has associated private and public key formats compatible with RFC 8410.

EdDSA Instances

RFC 8032 describes five EdDSA instances: Ed25519, Ed25519ctx, Ed25519ph, Ed448, Ed448ph.

The instances Ed25519, Ed25519ctx, Ed448 are referred to as PureEdDSA schemes. For these three instances, the sign and verify procedures require access to the complete message (not a digest of the message).

The instances Ed25519ph, Ed448ph are referred to as HashEdDSA schemes. For these two instances, the sign and verify procedures do not require access to the complete message; they operate on a hash of the message. For Ed25519ph, the hash function is SHA512. For Ed448ph, the hash function is SHAKE256 with an output length of 512 bits.

The instances Ed25519ctx, Ed25519ph, Ed448, Ed448ph accept an optional context-string as input to sign and verify operations (and for Ed25519ctx, the context-string must be nonempty). For the Ed25519 instance, a nonempty context-string is not permitted.

ED25519 and ED448 Signature Parameters

Two parameters can be set during signing or verification: the EdDSA instance name and the context-string value. They can be set by passing an OSSL_PARAM array to EVP_DigestSignInit_ex().

  • “instance” (OSSL_SIGNATURE_PARAM_INSTANCE) <utf8 string> One of the five strings “Ed25519”, “Ed25519ctx”, “Ed25519ph”, “Ed448”, “Ed448ph”. “Ed25519”, “Ed25519ctx”, “Ed25519ph” are valid only for an Ed25519 EVP_PKEY. “Ed448”, “Ed448ph” are valid only for an Ed448 EVP_PKEY.

  • “context-string” (OSSL_SIGNATURE_PARAM_CONTEXT_STRING) <octet string> A string of octets with length at most 255.

Both of these parameters are optional.

If the instance name is not specified, then the default “Ed25519” or “Ed448” is used.

If a context-string is not specified, then an empty context-string is used.

Note that a message digest name must NOT be specified when signing or verifying.

See EVP_PKEY-X25519 (7) for information related to X25519 and X448 keys.

The following signature parameters can be retrieved using EVP_PKEY_CTX_get_params().

  • “algorithm-id” (OSSL_SIGNATURE_PARAM_ALGORITHM_ID) <octet string>

  • “instance” (OSSL_SIGNATURE_PARAM_INSTANCE) <utf8 string>

  • “context-string” (OSSL_SIGNATURE_PARAM_CONTEXT_STRING) <octet string>

The parameters are described in provider-signature (7).

NOTES

The PureEdDSA instances do not support the streaming mechanism of other signature algorithms using, for example, EVP_DigestUpdate(). The message to sign or verify must be passed using the one-shot EVP_DigestSign() and EVP_DigestVerify() functions.

The HashEdDSA instances do not yet support the streaming mechanisms (so the one-shot functions must be used with HashEdDSA as well).

When calling EVP_DigestSignInit() or EVP_DigestVerifyInit(), the digest type parameter MUST be set to NULL.

Applications wishing to sign certificates (or other structures such as CRLs or certificate requests) using Ed25519 or Ed448 can either use X509_sign() or X509_sign_ctx() in the usual way.

Ed25519 or Ed448 private keys can be set directly using EVP_PKEY_new_raw_private_key (3) or loaded from a PKCS#8 private key file using PEM_read_bio_PrivateKey (3) (or similar function). Completely new keys can also be generated (see the example below). Setting a private key also sets the associated public key.

Ed25519 or Ed448 public keys can be set directly using EVP_PKEY_new_raw_public_key (3) or loaded from a SubjectPublicKeyInfo structure in a PEM file using PEM_read_bio_PUBKEY (3) (or similar function).

Ed25519 and Ed448 can be tested with the openssl-speed (1) application since version 1.1.1. Valid algorithm names are ed25519, ed448 and eddsa. If eddsa is specified, then both Ed25519 and Ed448 are benchmarked.

EXAMPLES

To sign a message using an ED25519 EVP_PKEY structure:

void do_sign(EVP_PKEY *ed_key, unsigned char *msg, size_t msg_len) { size_t sig_len; unsigned char *sig = NULL; EVP_MD_CTX *md_ctx = EVP_MD_CTX_new(); const OSSL_PARAM params[] = { OSSL_PARAM_utf8_string (“instance”, “Ed25519ctx”, 10), OSSL_PARAM_octet_string(“context-string”, (unsigned char *)“A protocol defined context string”, 33), OSSL_PARAM_END }; /* The input “params” is not needed if default options are acceptable. Use NULL in place of “params” in that case. */ EVP_DigestSignInit_ex(md_ctx, NULL, NULL, NULL, NULL, ed_key, params); /* Calculate the required size for the signature by passing a NULL buffer. */ EVP_DigestSign(md_ctx, NULL, &sig_len, msg, msg_len); sig = OPENSSL_zalloc(sig_len); EVP_DigestSign(md_ctx, sig, &sig_len, msg, msg_len); … OPENSSL_free(sig); EVP_MD_CTX_free(md_ctx); }

SEE ALSO

EVP_PKEY-X25519 (7) provider-signature (7), EVP_DigestSignInit (3), EVP_DigestVerifyInit (3),

COPYRIGHT

Copyright 2017-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

228 - Linux cli command iso_8859_16

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso_8859_16 and provides detailed information about the command iso_8859_16, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso_8859_16.

NAME 🖥️ iso_8859_16 🖥️

16 - ISO/IEC 8859-16 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-16 encodes the Latin characters used in Southeast European languages.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-16 characters

The following table displays the characters in ISO/IEC 8859-16 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-16 is also known as Latin-10.

SEE ALSO

ascii(7), charsets(7), iso_8859-3(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

229 - Linux cli command iso_8859_8

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso_8859_8 and provides detailed information about the command iso_8859_8, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso_8859_8.

NAME 🖥️ iso_8859_8 🖥️

8 - ISO/IEC 8859-8 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-8 encodes the characters used in Modern Hebrew.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-8 characters

The following table displays the characters in ISO/IEC 8859-8 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-8 was also known as ISO-IR-138. ISO/IEC 8859-8 includes neither short vowels nor diacritical marks, and Yiddish is not provided for.

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

230 - Linux cli command EXECUTE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EXECUTE and provides detailed information about the command EXECUTE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EXECUTE.

NAME 🖥️ EXECUTE 🖥️

execute a prepared statement

SYNOPSIS

EXECUTE name [ ( parameter [, ...] ) ]

DESCRIPTION

EXECUTE is used to execute a previously prepared statement. Since prepared statements only exist for the duration of a session, the prepared statement must have been created by a PREPARE statement executed earlier in the current session.

If the PREPARE statement that created the statement specified some parameters, a compatible set of parameters must be passed to the EXECUTE statement, or else an error is raised. Note that (unlike functions) prepared statements are not overloaded based on the type or number of their parameters; the name of a prepared statement must be unique within a database session.

For more information on the creation and usage of prepared statements, see PREPARE(7).

PARAMETERS

name

The name of the prepared statement to execute.

parameter

The actual value of a parameter to the prepared statement. This must be an expression yielding a value that is compatible with the data type of this parameter, as was determined when the prepared statement was created.

OUTPUTS

The command tag returned by EXECUTE is that of the prepared statement, and not EXECUTE.

EXAMPLES

Examples are given in Examples in the PREPARE(7) documentation.

COMPATIBILITY

The SQL standard includes an EXECUTE statement, but it is only for use in embedded SQL. This version of the EXECUTE statement also uses a somewhat different syntax.

SEE ALSO

DEALLOCATE(7), PREPARE(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

231 - Linux cli command inotify

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command inotify and provides detailed information about the command inotify, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the inotify.

NAME 🖥️ inotify 🖥️

monitoring filesystem events

DESCRIPTION

The inotify API provides a mechanism for monitoring filesystem events. Inotify can be used to monitor individual files, or to monitor directories. When a directory is monitored, inotify will return events for the directory itself, and for files inside the directory.

The following system calls are used with this API:

  • inotify_init(2) creates an inotify instance and returns a file descriptor referring to the inotify instance. The more recent inotify_init1(2) is like inotify_init(2), but has a flags argument that provides access to some extra functionality.

  • inotify_add_watch(2) manipulates the “watch list” associated with an inotify instance. Each item (“watch”) in the watch list specifies the pathname of a file or directory, along with some set of events that the kernel should monitor for the file referred to by that pathname. inotify_add_watch(2) either creates a new watch item, or modifies an existing watch. Each watch has a unique “watch descriptor”, an integer returned by inotify_add_watch(2) when the watch is created.

  • When events occur for monitored files and directories, those events are made available to the application as structured data that can be read from the inotify file descriptor using read(2) (see below).

  • inotify_rm_watch(2) removes an item from an inotify watch list.

  • When all file descriptors referring to an inotify instance have been closed (using close(2)), the underlying object and its resources are freed for reuse by the kernel; all associated watches are automatically freed.

With careful programming, an application can use inotify to efficiently monitor and cache the state of a set of filesystem objects. However, robust applications should allow for the fact that bugs in the monitoring logic or races of the kind described below may leave the cache inconsistent with the filesystem state. It is probably wise to do some consistency checking, and rebuild the cache when inconsistencies are detected.

Reading events from an inotify file descriptor

To determine what events have occurred, an application read(2)s from the inotify file descriptor. If no events have so far occurred, then, assuming a blocking file descriptor, read(2) will block until at least one event occurs (unless interrupted by a signal, in which case the call fails with the error EINTR; see signal(7)).

Each successful read(2) returns a buffer containing one or more of the following structures:

struct inotify_event {
    int      wd;       /* Watch descriptor */
    uint32_t mask;     /* Mask describing event */
    uint32_t cookie;   /* Unique cookie associating related
                          events (for rename(2)) */
    uint32_t len;      /* Size of name field */
    char     name[];   /* Optional null-terminated name */
};

wd identifies the watch for which this event occurs. It is one of the watch descriptors returned by a previous call to inotify_add_watch(2).

mask contains bits that describe the event that occurred (see below).

cookie is a unique integer that connects related events. Currently, this is used only for rename events, and allows the resulting pair of IN_MOVED_FROM and IN_MOVED_TO events to be connected by the application. For all other event types, cookie is set to 0.

The name field is present only when an event is returned for a file inside a watched directory; it identifies the filename within the watched directory. This filename is null-terminated, and may include further null bytes (‘�’) to align subsequent reads to a suitable address boundary.

The len field counts all of the bytes in name, including the null bytes; the length of each inotify_event structure is thus sizeof(struct inotify_event)+len.

The behavior when the buffer given to read(2) is too small to return information about the next event depends on the kernel version: before Linux 2.6.21, read(2) returns 0; since Linux 2.6.21, read(2) fails with the error EINVAL. Specifying a buffer of size

sizeof(struct inotify_event) + NAME_MAX + 1

will be sufficient to read at least one event.

inotify events

The inotify_add_watch(2) mask argument and the mask field of the inotify_event structure returned when read(2)ing an inotify file descriptor are both bit masks identifying inotify events. The following bits can be specified in mask when calling inotify_add_watch(2) and may be returned in the mask field returned by read(2):

IN_ACCESS (+)
File was accessed (e.g., read(2), execve(2)).

IN_ATTRIB (*)
Metadata changed—for example, permissions (e.g., chmod(2)), timestamps (e.g., utimensat(2)), extended attributes (setxattr(2)), link count (since Linux 2.6.25; e.g., for the target of link(2) and for unlink(2)), and user/group ID (e.g., chown(2)).

IN_CLOSE_WRITE (+)
File opened for writing was closed.

IN_CLOSE_NOWRITE (*)
File or directory not opened for writing was closed.

IN_CREATE (+)
File/directory created in watched directory (e.g., open(2) O_CREAT, mkdir(2), link(2), symlink(2), bind(2) on a UNIX domain socket).

IN_DELETE (+)
File/directory deleted from watched directory.

IN_DELETE_SELF
Watched file/directory was itself deleted. (This event also occurs if an object is moved to another filesystem, since mv(1) in effect copies the file to the other filesystem and then deletes it from the original filesystem.) In addition, an IN_IGNORED event will subsequently be generated for the watch descriptor.

IN_MODIFY (+)
File was modified (e.g., write(2), truncate(2)).

IN_MOVE_SELF
Watched file/directory was itself moved.

IN_MOVED_FROM (+)
Generated for the directory containing the old filename when a file is renamed.

IN_MOVED_TO (+)
Generated for the directory containing the new filename when a file is renamed.

IN_OPEN (*)
File or directory was opened.

Inotify monitoring is inode-based: when monitoring a file (but not when monitoring the directory containing a file), an event can be generated for activity on any link to the file (in the same or a different directory).

When monitoring a directory:

  • the events marked above with an asterisk (*) can occur both for the directory itself and for objects inside the directory; and

  • the events marked with a plus sign (+) occur only for objects inside the directory (not for the directory itself).

Note: when monitoring a directory, events are not generated for the files inside the directory when the events are performed via a pathname (i.e., a link) that lies outside the monitored directory.

When events are generated for objects inside a watched directory, the name field in the returned inotify_event structure identifies the name of the file within the directory.

The IN_ALL_EVENTS macro is defined as a bit mask of all of the above events. This macro can be used as the mask argument when calling inotify_add_watch(2).

Two additional convenience macros are defined:

IN_MOVE
Equates to IN_MOVED_FROM | IN_MOVED_TO.

IN_CLOSE
Equates to IN_CLOSE_WRITE | IN_CLOSE_NOWRITE.

The following further bits can be specified in mask when calling inotify_add_watch(2):

IN_DONT_FOLLOW (since Linux 2.6.15)
Don’t dereference pathname if it is a symbolic link.

IN_EXCL_UNLINK (since Linux 2.6.36)
By default, when watching events on the children of a directory, events are generated for children even after they have been unlinked from the directory. This can result in large numbers of uninteresting events for some applications (e.g., if watching /tmp, in which many applications create temporary files whose names are immediately unlinked). Specifying IN_EXCL_UNLINK changes the default behavior, so that events are not generated for children after they have been unlinked from the watched directory.

IN_MASK_ADD
If a watch instance already exists for the filesystem object corresponding to pathname, add (OR) the events in mask to the watch mask (instead of replacing the mask); the error EINVAL results if IN_MASK_CREATE is also specified.

IN_ONESHOT
Monitor the filesystem object corresponding to pathname for one event, then remove from watch list.

IN_ONLYDIR (since Linux 2.6.15)
Watch pathname only if it is a directory; the error ENOTDIR results if pathname is not a directory. Using this flag provides an application with a race-free way of ensuring that the monitored object is a directory.

IN_MASK_CREATE (since Linux 4.18)
Watch pathname only if it does not already have a watch associated with it; the error EEXIST results if pathname is already being watched.

Using this flag provides an application with a way of ensuring that new watches do not modify existing ones. This is useful because multiple paths may refer to the same inode, and multiple calls to inotify_add_watch(2) without this flag may clobber existing watch masks.

The following bits may be set in the mask field returned by read(2):

IN_IGNORED
Watch was removed explicitly (inotify_rm_watch(2)) or automatically (file was deleted, or filesystem was unmounted). See also BUGS.

IN_ISDIR
Subject of this event is a directory.

IN_Q_OVERFLOW
Event queue overflowed (wd is -1 for this event).

IN_UNMOUNT
Filesystem containing watched object was unmounted. In addition, an IN_IGNORED event will subsequently be generated for the watch descriptor.

Examples

Suppose an application is watching the directory dir and the file dir/myfile for all events. The examples below show some events that will be generated for these two objects.

fd = open(“dir/myfile”, O_RDWR);
Generates IN_OPEN events for both dir and dir/myfile.

read(fd, buf, count);
Generates IN_ACCESS events for both dir and dir/myfile.

write(fd, buf, count);
Generates IN_MODIFY events for both dir and dir/myfile.

fchmod(fd, mode);
Generates IN_ATTRIB events for both dir and dir/myfile.

close(fd);
Generates IN_CLOSE_WRITE events for both dir and dir/myfile.

Suppose an application is watching the directories dir1 and dir2, and the file dir1/myfile. The following examples show some events that may be generated.

link(“dir1/myfile”, “dir2/new”);
Generates an IN_ATTRIB event for myfile and an IN_CREATE event for dir2.

rename(“dir1/myfile”, “dir2/myfile”);
Generates an IN_MOVED_FROM event for dir1, an IN_MOVED_TO event for dir2, and an IN_MOVE_SELF event for myfile. The IN_MOVED_FROM and IN_MOVED_TO events will have the same cookie value.

Suppose that dir1/xx and dir2/yy are (the only) links to the same file, and an application is watching dir1, dir2, dir1/xx, and dir2/yy. Executing the following calls in the order given below will generate the following events:

unlink(“dir2/yy”);
Generates an IN_ATTRIB event for xx (because its link count changes) and an IN_DELETE event for dir2.

unlink(“dir1/xx”);
Generates IN_ATTRIB, IN_DELETE_SELF, and IN_IGNORED events for xx, and an IN_DELETE event for dir1.

Suppose an application is watching the directory dir and (the empty) directory dir/subdir. The following examples show some events that may be generated.

mkdir(“dir/new”, mode);
Generates an IN_CREATE | IN_ISDIR event for dir.

rmdir(“dir/subdir”);
Generates IN_DELETE_SELF and IN_IGNORED events for subdir, and an IN_DELETE | IN_ISDIR event for dir.

/proc interfaces

The following interfaces can be used to limit the amount of kernel memory consumed by inotify:

/proc/sys/fs/inotify/max_queued_events
The value in this file is used when an application calls inotify_init(2) to set an upper limit on the number of events that can be queued to the corresponding inotify instance. Events in excess of this limit are dropped, but an IN_Q_OVERFLOW event is always generated.

/proc/sys/fs/inotify/max_user_instances
This specifies an upper limit on the number of inotify instances that can be created per real user ID.

/proc/sys/fs/inotify/max_user_watches
This specifies an upper limit on the number of watches that can be created per real user ID.

STANDARDS

Linux.

HISTORY

Inotify was merged into Linux 2.6.13. The required library interfaces were added in glibc 2.4. (IN_DONT_FOLLOW, IN_MASK_ADD, and IN_ONLYDIR were added in glibc 2.5.)

NOTES

Inotify file descriptors can be monitored using select(2), poll(2), and epoll(7). When an event is available, the file descriptor indicates as readable.

Since Linux 2.6.25, signal-driven I/O notification is available for inotify file descriptors; see the discussion of F_SETFL (for setting the O_ASYNC flag), F_SETOWN, and F_SETSIG in fcntl(2). The siginfo_t structure (described in sigaction(2)) that is passed to the signal handler has the following fields set: si_fd is set to the inotify file descriptor number; si_signo is set to the signal number; si_code is set to POLL_IN; and POLLIN is set in si_band.

If successive output inotify events produced on the inotify file descriptor are identical (same wd, mask, cookie, and name), then they are coalesced into a single event if the older event has not yet been read (but see BUGS). This reduces the amount of kernel memory required for the event queue, but also means that an application can’t use inotify to reliably count file events.

The events returned by reading from an inotify file descriptor form an ordered queue. Thus, for example, it is guaranteed that when renaming from one directory to another, events will be produced in the correct order on the inotify file descriptor.

The set of watch descriptors that is being monitored via an inotify file descriptor can be viewed via the entry for the inotify file descriptor in the process’s /proc/pid/fdinfo directory. See proc(5) for further details. The FIONREAD ioctl(2) returns the number of bytes available to read from an inotify file descriptor.

Limitations and caveats

The inotify API provides no information about the user or process that triggered the inotify event. In particular, there is no easy way for a process that is monitoring events via inotify to distinguish events that it triggers itself from those that are triggered by other processes.

Inotify reports only events that a user-space program triggers through the filesystem API. As a result, it does not catch remote events that occur on network filesystems. (Applications must fall back to polling the filesystem to catch such events.) Furthermore, various pseudo-filesystems such as /proc, /sys, and /dev/pts are not monitorable with inotify.

The inotify API does not report file accesses and modifications that may occur because of mmap(2), msync(2), and munmap(2).

The inotify API identifies affected files by filename. However, by the time an application processes an inotify event, the filename may already have been deleted or renamed.

The inotify API identifies events via watch descriptors. It is the application’s responsibility to cache a mapping (if one is needed) between watch descriptors and pathnames. Be aware that directory renamings may affect multiple cached pathnames.

Inotify monitoring of directories is not recursive: to monitor subdirectories under a directory, additional watches must be created. This can take a significant amount time for large directory trees.

If monitoring an entire directory subtree, and a new subdirectory is created in that tree or an existing directory is renamed into that tree, be aware that by the time you create a watch for the new subdirectory, new files (and subdirectories) may already exist inside the subdirectory. Therefore, you may want to scan the contents of the subdirectory immediately after adding the watch (and, if desired, recursively add watches for any subdirectories that it contains).

Note that the event queue can overflow. In this case, events are lost. Robust applications should handle the possibility of lost events gracefully. For example, it may be necessary to rebuild part or all of the application cache. (One simple, but possibly expensive, approach is to close the inotify file descriptor, empty the cache, create a new inotify file descriptor, and then re-create watches and cache entries for the objects to be monitored.)

If a filesystem is mounted on top of a monitored directory, no event is generated, and no events are generated for objects immediately under the new mount point. If the filesystem is subsequently unmounted, events will subsequently be generated for the directory and the objects it contains.

Dealing with rename() events

As noted above, the IN_MOVED_FROM and IN_MOVED_TO event pair that is generated by rename(2) can be matched up via their shared cookie value. However, the task of matching has some challenges.

These two events are usually consecutive in the event stream available when reading from the inotify file descriptor. However, this is not guaranteed. If multiple processes are triggering events for monitored objects, then (on rare occasions) an arbitrary number of other events may appear between the IN_MOVED_FROM and IN_MOVED_TO events. Furthermore, it is not guaranteed that the event pair is atomically inserted into the queue: there may be a brief interval where the IN_MOVED_FROM has appeared, but the IN_MOVED_TO has not.

Matching up the IN_MOVED_FROM and IN_MOVED_TO event pair generated by rename(2) is thus inherently racy. (Don’t forget that if an object is renamed outside of a monitored directory, there may not even be an IN_MOVED_TO event.) Heuristic approaches (e.g., assume the events are always consecutive) can be used to ensure a match in most cases, but will inevitably miss some cases, causing the application to perceive the IN_MOVED_FROM and IN_MOVED_TO events as being unrelated. If watch descriptors are destroyed and re-created as a result, then those watch descriptors will be inconsistent with the watch descriptors in any pending events. (Re-creating the inotify file descriptor and rebuilding the cache may be useful to deal with this scenario.)

Applications should also allow for the possibility that the IN_MOVED_FROM event was the last event that could fit in the buffer returned by the current call to read(2), and the accompanying IN_MOVED_TO event might be fetched only on the next read(2), which should be done with a (small) timeout to allow for the fact that insertion of the IN_MOVED_FROM+IN_MOVED_TO event pair is not atomic, and also the possibility that there may not be any IN_MOVED_TO event.

BUGS

Before Linux 3.19, fallocate(2) did not create any inotify events. Since Linux 3.19, calls to fallocate(2) generate IN_MODIFY events.

Before Linux 2.6.16, the IN_ONESHOT mask flag does not work.

As originally designed and implemented, the IN_ONESHOT flag did not cause an IN_IGNORED event to be generated when the watch was dropped after one event. However, as an unintended effect of other changes, since Linux 2.6.36, an IN_IGNORED event is generated in this case.

Before Linux 2.6.25, the kernel code that was intended to coalesce successive identical events (i.e., the two most recent events could potentially be coalesced if the older had not yet been read) instead checked if the most recent event could be coalesced with the oldest unread event.

When a watch descriptor is removed by calling inotify_rm_watch(2) (or because a watch file is deleted or the filesystem that contains it is unmounted), any pending unread events for that watch descriptor remain available to read. As watch descriptors are subsequently allocated with inotify_add_watch(2), the kernel cycles through the range of possible watch descriptors (1 to INT_MAX) incrementally. When allocating a free watch descriptor, no check is made to see whether that watch descriptor number has any pending unread events in the inotify queue. Thus, it can happen that a watch descriptor is reallocated even when pending unread events exist for a previous incarnation of that watch descriptor number, with the result that the application might then read those events and interpret them as belonging to the file associated with the newly recycled watch descriptor. In practice, the likelihood of hitting this bug may be extremely low, since it requires that an application cycle through INT_MAX watch descriptors, release a watch descriptor while leaving unread events for that watch descriptor in the queue, and then recycle that watch descriptor. For this reason, and because there have been no reports of the bug occurring in real-world applications, as of Linux 3.15, no kernel changes have yet been made to eliminate this possible bug.

EXAMPLES

The following program demonstrates the usage of the inotify API. It marks the directories passed as a command-line arguments and waits for events of type IN_OPEN, IN_CLOSE_NOWRITE, and IN_CLOSE_WRITE.

The following output was recorded while editing the file /home/user/temp/foo and listing directory /tmp. Before the file and the directory were opened, IN_OPEN events occurred. After the file was closed, an IN_CLOSE_WRITE event occurred. After the directory was closed, an IN_CLOSE_NOWRITE event occurred. Execution of the program ended when the user pressed the ENTER key.

Example output

$ ./a.out /tmp /home/user/temp
Press enter key to terminate.
Listening for events.
IN_OPEN: /home/user/temp/foo [file]
IN_CLOSE_WRITE: /home/user/temp/foo [file]
IN_OPEN: /tmp/ [directory]
IN_CLOSE_NOWRITE: /tmp/ [directory]
Listening for events stopped.

Program source

#include <errno.h>
#include <poll.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/inotify.h>
#include <unistd.h>
#include <string.h>
/* Read all available inotify events from the file descriptor 'fd'.
   wd is the table of watch descriptors for the directories in argv.
   argc is the length of wd and argv.
   argv is the list of watched directories.
   Entry 0 of wd and argv is unused. */
static void
handle_events(int fd, int *wd, int argc, char* argv[])
{
    /* Some systems cannot read integer variables if they are not
       properly aligned. On other systems, incorrect alignment may
       decrease performance. Hence, the buffer used for reading from
       the inotify file descriptor should have the same alignment as
       struct inotify_event. */
    char buf[4096]
        __attribute__ ((aligned(__alignof__(struct inotify_event))));
    const struct inotify_event *event;
    ssize_t len;
    /* Loop while events can be read from inotify file descriptor. */
    for (;;) {
        /* Read some events. */
        len = read(fd, buf, sizeof(buf));
        if (len == -1 && errno != EAGAIN) {
            perror("read");
            exit(EXIT_FAILURE);
        }
        /* If the nonblocking read() found no events to read, then
           it returns -1 with errno set to EAGAIN. In that case,
           we exit the loop. */
        if (len <= 0)
            break;
        /* Loop over all events in the buffer. */
        for (char *ptr = buf; ptr < buf + len;
                ptr += sizeof(struct inotify_event) + event->len) {
            event = (const struct inotify_event *) ptr;
            /* Print event type. */
            if (event->mask & IN_OPEN)
                printf("IN_OPEN: ");
            if (event->mask & IN_CLOSE_NOWRITE)
                printf("IN_CLOSE_NOWRITE: ");
            if (event->mask & IN_CLOSE_WRITE)
                printf("IN_CLOSE_WRITE: ");
            /* Print the name of the watched directory. */
            for (size_t i = 1; i < argc; ++i) {
                if (wd[i] == event->wd) {
                    printf("%s/", argv[i]);
                    break;
                }
            }
            /* Print the name of the file. */
            if (event->len)
                printf("%s", event->name);
            /* Print type of filesystem object. */
            if (event->mask & IN_ISDIR)
                printf(" [directory]

“); else printf(” [file] “); } } } int main(int argc, char* argv[]) { char buf; int fd, i, poll_num; int wd; nfds_t nfds; struct pollfd fds[2]; if (argc < 2) { printf(“Usage: %s PATH [PATH …] “, argv[0]); exit(EXIT_FAILURE); } printf(“Press ENTER key to terminate. “); / Create the file descriptor for accessing the inotify API. / fd = inotify_init1(IN_NONBLOCK); if (fd == -1) { perror(“inotify_init1”); exit(EXIT_FAILURE); } / Allocate memory for watch descriptors. / wd = calloc(argc, sizeof(int)); if (wd == NULL) { perror(“calloc”); exit(EXIT_FAILURE); } / Mark directories for events - file was opened - file was closed / for (i = 1; i < argc; i++) { wd[i] = inotify_add_watch(fd, argv[i], IN_OPEN | IN_CLOSE); if (wd[i] == -1) { fprintf(stderr, “Cannot watch ‘%s’: %s “, argv[i], strerror(errno)); exit(EXIT_FAILURE); } } / Prepare for polling. / nfds = 2; fds[0].fd = STDIN_FILENO; / Console input / fds[0].events = POLLIN; fds[1].fd = fd; / Inotify input / fds[1].events = POLLIN; / Wait for events and/or terminal input. / printf(“Listening for events. “); while (1) { poll_num = poll(fds, nfds, -1); if (poll_num == -1) { if (errno == EINTR) continue; perror(“poll”); exit(EXIT_FAILURE); } if (poll_num > 0) { if (fds[0].revents & POLLIN) { / Console input is available. Empty stdin and quit. / while (read(STDIN_FILENO, &buf, 1) > 0 && buf != ' ‘) continue; break; } if (fds[1].revents & POLLIN) { / Inotify events are available. / handle_events(fd, wd, argc, argv); } } } printf(“Listening for events stopped. “); / Close inotify file descriptor. */ close(fd); free(wd); exit(EXIT_SUCCESS); }

SEE ALSO

inotifywait(1), inotifywatch(1), inotify_add_watch(2), inotify_init(2), inotify_init1(2), inotify_rm_watch(2), read(2), stat(2), fanotify(7)

Documentation/filesystems/inotify.txt in the Linux kernel source tree

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

232 - Linux cli command EVP_CIPHER-CASTssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_CIPHER-CASTssl and provides detailed information about the command EVP_CIPHER-CASTssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_CIPHER-CASTssl.

NAME 🖥️ EVP_CIPHER-CASTssl 🖥️

CAST - The CAST EVP_CIPHER implementations

DESCRIPTION

Support for CAST symmetric encryption using the EVP_CIPHER API.

Algorithm Names

The following algorithms are available in the legacy provider:

“CAST-128-CBC”, “CAST-192-CBC” and “CAST-256-CBC”

“CAST-128-CFB”, “CAST-192-CFB”, “CAST-256-CFB”

“CAST-128-ECB”, “CAST-192-ECB” and “CAST-256-ECB”

“CAST-192-OFB”, “CAST-128-OFB” and “CAST-256-OFB”

Parameters

This implementation supports the parameters described in “PARAMETERS” in EVP_EncryptInit (3).

SEE ALSO

provider-cipher (7), OSSL_PROVIDER-legacy (7)

COPYRIGHT

Copyright 2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

233 - Linux cli command url

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command url and provides detailed information about the command url, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the url.

NAME 🖥️ url 🖥️

uniform resource identifier (URI), including a URL or URN

SYNOPSIS

URI = [ absoluteURI | relativeURI ] [ “#”  fragment ]

absoluteURI = *scheme * “:” ( hierarchical_part | opaque_part )

relativeURI = ( net_path | absolute_path | relative_path ) [ “?”  query ]

scheme = “http” | “ftp” | “gopher” | “mailto” | “news” | “telnet” | “file” | “ftp” | “man” | “info” | “whatis” | “ldap” | “wais” | …

hierarchical_part = ( net_path | absolute_path ) [ “?”  query ]

net_path = “//”  authority [ absolute_path ]

absolute_path = “/”  path_segments

relative_path = relative_segment [ absolute_path ]

DESCRIPTION

A Uniform Resource Identifier (URI) is a short string of characters identifying an abstract or physical resource (for example, a web page). A Uniform Resource Locator (URL) is a URI that identifies a resource through its primary access mechanism (e.g., its network “location”), rather than by name or some other attribute of that resource. A Uniform Resource Name (URN) is a URI that must remain globally unique and persistent even when the resource ceases to exist or becomes unavailable.

URIs are the standard way to name hypertext link destinations for tools such as web browsers. The string “http://www.kernel.org” is a URL (and thus it is also a URI). Many people use the term URL loosely as a synonym for URI (though technically URLs are a subset of URIs).

URIs can be absolute or relative. An absolute identifier refers to a resource independent of context, while a relative identifier refers to a resource by describing the difference from the current context. Within a relative path reference, the complete path segments “.” and “..” have special meanings: “the current hierarchy level” and “the level above this hierarchy level”, respectively, just like they do in UNIX-like systems. A path segment which contains a colon character can’t be used as the first segment of a relative URI path (e.g., “this:that”), because it would be mistaken for a scheme name; precede such segments with ./ (e.g., “./this:that”). Note that descendants of MS-DOS (e.g., Microsoft Windows) replace devicename colons with the vertical bar ("|") in URIs, so “C:” becomes “C|”.

A fragment identifier, if included, refers to a particular named portion (fragment) of a resource; text after a ‘#’ identifies the fragment. A URI beginning with ‘#’ refers to that fragment in the current resource.

Usage

There are many different URI schemes, each with specific additional rules and meanings, but they are intentionally made to be as similar as possible. For example, many URL schemes permit the authority to be the following format, called here an ip_server (square brackets show what’s optional):

*ip_server = *[user [ : password ] @ ] host [ : port]

This format allows you to optionally insert a username, a user plus password, and/or a port number. The host is the name of the host computer, either its name as determined by DNS or an IP address (numbers separated by periods). Thus the URI <http://fred:[email protected]:8080/> logs into a web server on host example.com as fred (using fredpassword) using port 8080. Avoid including a password in a URI if possible because of the many security risks of having a password written down. If the URL supplies a username but no password, and the remote server requests a password, the program interpreting the URL should request one from the user.

Here are some of the most common schemes in use on UNIX-like systems that are understood by many tools. Note that many tools using URIs also have internal schemes or specialized schemes; see those tools’ documentation for information on those schemes.

http - Web (HTTP) server

http://ip_server/path
http://ip_server/path?query

This is a URL accessing a web (HTTP) server. The default port is 80. If the path refers to a directory, the web server will choose what to return; usually if there is a file named “index.html” or “index.htm” its content is returned, otherwise, a list of the files in the current directory (with appropriate links) is generated and returned. An example is <http://lwn.net>.

A query can be given in the archaic “isindex” format, consisting of a word or phrase and not including an equal sign (=). A query can also be in the longer “GET” format, which has one or more query entries of the form key=value separated by the ampersand character (&). Note that key can be repeated more than once, though it’s up to the web server and its application programs to determine if there’s any meaning to that. There is an unfortunate interaction with HTML/XML/SGML and the GET query format; when such URIs with more than one key are embedded in SGML/XML documents (including HTML), the ampersand (&) has to be rewritten as &. Note that not all queries use this format; larger forms may be too long to store as a URI, so they use a different interaction mechanism (called POST) which does not include the data in the URI. See the Common Gateway Interface specification at for more information.

ftp - File Transfer Protocol (FTP)

ftp://ip_server/path

This is a URL accessing a file through the file transfer protocol (FTP). The default port (for control) is 21. If no username is included, the username “anonymous” is supplied, and in that case many clients provide as the password the requestor’s Internet email address. An example is <ftp://ftp.is.co.za/rfc/rfc1808.txt>.

gopher - Gopher server

gopher://ip_server/gophertype selector
gopher://ip_server/gophertype selector%09search
gopher://ip_server/gophertype selector%09search%09gopher+_string

The default gopher port is 70. gophertype is a single-character field to denote the Gopher type of the resource to which the URL refers. The entire path may also be empty, in which case the delimiting “/” is also optional and the gophertype defaults to “1”.

selector is the Gopher selector string. In the Gopher protocol, Gopher selector strings are a sequence of octets which may contain any octets except 09 hexadecimal (US-ASCII HT or tab), 0A hexadecimal (US-ASCII character LF), and 0D (US-ASCII character CR).

mailto - Email address

mailto:email-address

This is an email address, usually of the form name@hostname. See mailaddr(7) for more information on the correct format of an email address. Note that any % character must be rewritten as %25. An example is <mailto:[email protected]>.

news - Newsgroup or News message

news:newsgroup-name
news:message-id

A newsgroup-name is a period-delimited hierarchical name, such as “comp.infosystems.www.misc”. If <newsgroup-name> is “*” (as in <news:*>), it is used to refer to “all available news groups”. An example is <news:comp.lang.ada>.

A message-id corresponds to the Message-ID of IETF RFC 1036, without the enclosing “<” and “>”; it takes the form unique@full_domain_name. A message identifier may be distinguished from a news group name by the presence of the “@” character.

telnet - Telnet login

telnet://ip_server/

The Telnet URL scheme is used to designate interactive text services that may be accessed by the Telnet protocol. The final “/” character may be omitted. The default port is 23. An example is <telnet://melvyl.ucop.edu/>.

file - Normal file

file://ip_server/path_segments
file:path_segments

This represents a file or directory accessible locally. As a special case, ip_server can be the string “localhost” or the empty string; this is interpreted as “the machine from which the URL is being interpreted”. If the path is to a directory, the viewer should display the directory’s contents with links to each containee; not all viewers currently do this. KDE supports generated files through the URL <file:/cgi-bin>. If the given file isn’t found, browser writers may want to try to expand the filename via filename globbing (see glob(7) and glob(3)).

The second format (e.g., <file:/etc/passwd>) is a correct format for referring to a local file. However, older standards did not permit this format, and some programs don’t recognize this as a URI. A more portable syntax is to use an empty string as the server name, for example, <file:///etc/passwd>; this form does the same thing and is easily recognized by pattern matchers and older programs as a URI. Note that if you really mean to say “start from the current location”, don’t specify the scheme at all; use a relative address like <../test.txt>, which has the side-effect of being scheme-independent. An example of this scheme is <file:///etc/passwd>.

man - Man page documentation

man:command-name
man:command-name(section)

This refers to local online manual (man) reference pages. The command name can optionally be followed by a parenthesis and section number; see man(7) for more information on the meaning of the section numbers. This URI scheme is unique to UNIX-like systems (such as Linux) and is not currently registered by the IETF. An example is <man:ls(1)>.

info - Info page documentation

info:virtual-filename
info:virtual-filename#nodename
info:(virtual-filename)
info:(virtual-filename)nodename

This scheme refers to online info reference pages (generated from texinfo files), a documentation format used by programs such as the GNU tools. This URI scheme is unique to UNIX-like systems (such as Linux) and is not currently registered by the IETF. As of this writing, GNOME and KDE differ in their URI syntax and do not accept the other’s syntax. The first two formats are the GNOME format; in nodenames all spaces are written as underscores. The second two formats are the KDE format; spaces in nodenames must be written as spaces, even though this is forbidden by the URI standards. It’s hoped that in the future most tools will understand all of these formats and will always accept underscores for spaces in nodenames. In both GNOME and KDE, if the form without the nodename is used the nodename is assumed to be “Top”. Examples of the GNOME format are <info:gcc> and <info:gcc#G++_and_GCC>. Examples of the KDE format are <info:(gcc)> and <info:(gcc)G++ and GCC>.

whatis - Documentation search

whatis:string

This scheme searches the database of short (one-line) descriptions of commands and returns a list of descriptions containing that string. Only complete word matches are returned. See whatis(1). This URI scheme is unique to UNIX-like systems (such as Linux) and is not currently registered by the IETF.

ghelp - GNOME help documentation

ghelp:name-of-application

This loads GNOME help for the given application. Note that not much documentation currently exists in this format.

ldap - Lightweight Directory Access Protocol

ldap://hostport
ldap://hostport/
ldap://hostport/dn
ldap://hostport/dn?attributes
ldap://hostport/dn?attributes?scope
ldap://hostport/dn?attributes?scope?filter
ldap://hostport/dn?attributes?scope?filter?extensions

This scheme supports queries to the Lightweight Directory Access Protocol (LDAP), a protocol for querying a set of servers for hierarchically organized information (such as people and computing resources). See RFC 2255 for more information on the LDAP URL scheme. The components of this URL are:

hostport
the LDAP server to query, written as a hostname optionally followed by a colon and the port number. The default LDAP port is TCP port 389. If empty, the client determines which the LDAP server to use.

dn
the LDAP Distinguished Name, which identifies the base object of the LDAP search (see RFC 2253 section 3).

attributes
a comma-separated list of attributes to be returned; see RFC 2251 section 4.1.5. If omitted, all attributes should be returned.

scope
specifies the scope of the search, which can be one of “base” (for a base object search), “one” (for a one-level search), or “sub” (for a subtree search). If scope is omitted, “base” is assumed.

filter
specifies the search filter (subset of entries to return). If omitted, all entries should be returned. See RFC 2254 section 4.

extensions
a comma-separated list of type=value pairs, where the =value portion may be omitted for options not requiring it. An extension prefixed with a ‘!’ is critical (must be supported to be valid), otherwise it is noncritical (optional).

LDAP queries are easiest to explain by example. Here’s a query that asks ldap.itd.umich.edu for information about the University of Michigan in the U.S.:

ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US

To just get its postal address attribute, request:

ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US?postalAddress

To ask a host.com at port 6666 for information about the person with common name (cn) “Babs Jensen” at University of Michigan, request:

ldap://host.com:6666/o=University%20of%20Michigan,c=US??sub?(cn=Babs%20Jensen)

wais - Wide Area Information Servers

wais://hostport/database
wais://hostport/database?search
wais://hostport/database/wtype/wpath

This scheme designates a WAIS database, search, or document (see IETF RFC 1625 for more information on WAIS). Hostport is the hostname, optionally followed by a colon and port number (the default port number is 210).

The first form designates a WAIS database for searching. The second form designates a particular search of the WAIS database database. The third form designates a particular document within a WAIS database to be retrieved. wtype is the WAIS designation of the type of the object and wpath is the WAIS document-id.

other schemes

There are many other URI schemes. Most tools that accept URIs support a set of internal URIs (e.g., Mozilla has the about: scheme for internal information, and the GNOME help browser has the toc: scheme for various starting locations). There are many schemes that have been defined but are not as widely used at the current time (e.g., prospero). The nntp: scheme is deprecated in favor of the news: scheme. URNs are to be supported by the urn: scheme, with a hierarchical name space (e.g., urn:ietf:… would identify IETF documents); at this time URNs are not widely implemented. Not all tools support all schemes.

Character encoding

URIs use a limited number of characters so that they can be typed in and used in a variety of situations.

The following characters are reserved, that is, they may appear in a URI but their use is limited to their reserved purpose (conflicting data must be escaped before forming the URI):

; / ? : @ & = + $ ,

Unreserved characters may be included in a URI. Unreserved characters include uppercase and lowercase Latin letters, decimal digits, and the following limited set of punctuation marks and symbols:

- _ . ! ~ * ' ( )

All other characters must be escaped. An escaped octet is encoded as a character triplet, consisting of the percent character “%” followed by the two hexadecimal digits representing the octet code (you can use uppercase or lowercase letters for the hexadecimal digits). For example, a blank space must be escaped as “%20”, a tab character as “%09”, and the “&” as “%26”. Because the percent “%” character always has the reserved purpose of being the escape indicator, it must be escaped as “%25”. It is common practice to escape space characters as the plus symbol (+) in query text; this practice isn’t uniformly defined in the relevant RFCs (which recommend %20 instead) but any tool accepting URIs with query text should be prepared for them. A URI is always shown in its “escaped” form.

Unreserved characters can be escaped without changing the semantics of the URI, but this should not be done unless the URI is being used in a context that does not allow the unescaped character to appear. For example, “%7e” is sometimes used instead of “~” in an HTTP URL path, but the two are equivalent for an HTTP URL.

For URIs which must handle characters outside the US ASCII character set, the HTML 4.01 specification (section B.2) and IETF RFC 3986 (last paragraph of section 2.5) recommend the following approach:

  1. translate the character sequences into UTF-8 (IETF RFC 3629)—see utf-8(7)—and then

  2. use the URI escaping mechanism, that is, use the %HH encoding for unsafe octets.

Writing a URI

When written, URIs should be placed inside double quotes (e.g., “http://www.kernel.org”), enclosed in angle brackets (e.g., <http://lwn.net>), or placed on a line by themselves. A warning for those who use double-quotes: never move extraneous punctuation (such as the period ending a sentence or the comma in a list) inside a URI, since this will change the value of the URI. Instead, use angle brackets instead, or switch to a quoting system that never includes extraneous characters inside quotation marks. This latter system, called the ’new’ or ’logical’ quoting system by “Hart’s Rules” and the “Oxford Dictionary for Writers and Editors”, is preferred practice in Great Britain and in various European languages. Older documents suggested inserting the prefix “URL:” just before the URI, but this form has never caught on.

The URI syntax was designed to be unambiguous. However, as URIs have become commonplace, traditional media (television, radio, newspapers, billboards, etc.) have increasingly used abbreviated URI references consisting of only the authority and path portions of the identified resource (e.g., <www.w3.org/Addressing>). Such references are primarily intended for human interpretation rather than machine, with the assumption that context-based heuristics are sufficient to complete the URI (e.g., hostnames beginning with “www” are likely to have a URI prefix of “http://” and hostnames beginning with “ftp” likely to have a prefix of “ftp://”). Many client implementations heuristically resolve these references. Such heuristics may change over time, particularly when new schemes are introduced. Since an abbreviated URI has the same syntax as a relative URL path, abbreviated URI references cannot be used where relative URIs are permitted, and can be used only when there is no defined base (such as in dialog boxes). Don’t use abbreviated URIs as hypertext links inside a document; use the standard format as described here.

STANDARDS

(IETF RFC 2396), (HTML 4.0).

NOTES

Any tool accepting URIs (e.g., a web browser) on a Linux system should be able to handle (directly or indirectly) all of the schemes described here, including the man: and info: schemes. Handling them by invoking some other program is fine and in fact encouraged.

Technically the fragment isn’t part of the URI.

For information on how to embed URIs (including URLs) in a data format, see documentation on that format. HTML uses the format <A HREF="uri"> text </A>. Texinfo files use the format @uref{uri}. Man and mdoc have the recently added UR macro, or just include the URI in the text (viewers should be able to detect :// as part of a URI).

The GNOME and KDE desktop environments currently vary in the URIs they accept, in particular in their respective help browsers. To list man pages, GNOME uses <toc:man> while KDE uses <man:(index)>, and to list info pages, GNOME uses <toc:info> while KDE uses <info:(dir)> (the author of this man page prefers the KDE approach here, though a more regular format would be even better). In general, KDE uses <file:/cgi-bin/> as a prefix to a set of generated files. KDE prefers documentation in HTML, accessed via the <file:/cgi-bin/helpindex>. GNOME prefers the ghelp scheme to store and find documentation. Neither browser handles file: references to directories at the time of this writing, making it difficult to refer to an entire directory with a browsable URI. As noted above, these environments differ in how they handle the info: scheme, probably the most important variation. It is expected that GNOME and KDE will converge to common URI formats, and a future version of this man page will describe the converged result. Efforts to aid this convergence are encouraged.

Security

A URI does not in itself pose a security threat. There is no general guarantee that a URL, which at one time located a given resource, will continue to do so. Nor is there any guarantee that a URL will not locate a different resource at some later point in time; such a guarantee can be obtained only from the person(s) controlling that namespace and the resource in question.

It is sometimes possible to construct a URL such that an attempt to perform a seemingly harmless operation, such as the retrieval of an entity associated with the resource, will in fact cause a possibly damaging remote operation to occur. The unsafe URL is typically constructed by specifying a port number other than that reserved for the network protocol in question. The client unwittingly contacts a site that is in fact running a different protocol. The content of the URL contains instructions that, when interpreted according to this other protocol, cause an unexpected operation. An example has been the use of a gopher URL to cause an unintended or impersonating message to be sent via a SMTP server.

Caution should be used when using any URL that specifies a port number other than the default for the protocol, especially when it is a number within the reserved space.

Care should be taken when a URI contains escaped delimiters for a given protocol (for example, CR and LF characters for telnet protocols) that these are not unescaped before transmission. This might violate the protocol, but avoids the potential for such characters to be used to simulate an extra operation or parameter in that protocol, which might lead to an unexpected and possibly harmful remote operation to be performed.

It is clearly unwise to use a URI that contains a password which is intended to be secret. In particular, the use of a password within the “userinfo” component of a URI is strongly recommended against except in those rare cases where the “password” parameter is intended to be public.

BUGS

Documentation may be placed in a variety of locations, so there currently isn’t a good URI scheme for general online documentation in arbitrary formats. References of the form <file:///usr/doc/ZZZ> don’t work because different distributions and local installation requirements may place the files in different directories (it may be in /usr/doc, or /usr/local/doc, or /usr/share, or somewhere else). Also, the directory ZZZ usually changes when a version changes (though filename globbing could partially overcome this). Finally, using the file: scheme doesn’t easily support people who dynamically load documentation from the Internet (instead of loading the files onto a local filesystem). A future URI scheme may be added (e.g., “userdoc:”) to permit programs to include cross-references to more detailed documentation without having to know the exact location of that documentation. Alternatively, a future version of the filesystem specification may specify file locations sufficiently so that the file: scheme will be able to locate documentation.

Many programs and file formats don’t include a way to incorporate or implement links using URIs.

Many programs can’t handle all of these different URI formats; there should be a standard mechanism to load an arbitrary URI that automatically detects the users’ environment (e.g., text or graphics, desktop environment, local user preferences, and currently executing tools) and invokes the right tool for any URI.

SEE ALSO

lynx(1), man2html(1), mailaddr(7), utf-8(7)

IETF RFC 2255

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

234 - Linux cli command smbios-type-11

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command smbios-type-11 and provides detailed information about the command smbios-type-11, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the smbios-type-11.

NAME 🖥️ smbios-type-11 🖥️

type-11 - SMBIOS Type 11 strings

SYNOPSIS

/sys/firmware/dmi/entries/11-*/raw

DESCRIPTION

Various OS components process SMBIOS Type 11 vendor strings that a virtual machine manager (VMM) may set and a virtual machine (VM) receives. SMBIOS Type 11 vendor strings may play a similar role as kernel-command-line(1) parameters but generally are under control of the VMM rather than the boot loader or UKI.

For details on SMBIOS Type 11 see the System Management BIOS[1] specifications.

STRINGS

The following strings are supported:

io.systemd.credential:CREDENTIAL=VALUE, io.systemd.credential.binary:CREDENTIAL=VALUE

This allows passing additional system credentials into the system, in textual or binary (Base64) form. See systemd.exec(5) and System and Service Credentials[2] for details.

Added in version 252.

io.systemd.stub.kernel-cmdline-extra=CMDLINE

This allows configuration of additional kernel command line options, and is read by the kernel UEFI stub. For details see systemd-stub(1).

Added in version 254.

io.systemd.boot.kernel-cmdline-extra=CMDLINE

This allows configuration of additional kernel command line options for Boot Loader Specification Type 1 entries, and is read by systemd-boot. For details see systemd-boot(1).

Added in version 256.

SEE ALSO

systemd(1), kernel-command-line(7), systemd.system-credentials(7)

NOTES

System Management BIOS

https://www.dmtf.org/standards/smbios/

System and Service Credentials

https://systemd.io/CREDENTIALS

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

235 - Linux cli command ALTER_SUBSCRIPTION

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_SUBSCRIPTION and provides detailed information about the command ALTER_SUBSCRIPTION, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_SUBSCRIPTION.

NAME 🖥️ ALTER_SUBSCRIPTION 🖥️

change the definition of a subscription

SYNOPSIS

ALTER SUBSCRIPTION name CONNECTION conninfo
ALTER SUBSCRIPTION name SET PUBLICATION publication_name [, ...] [ WITH ( publication_option [= value] [, ... ] ) ]
ALTER SUBSCRIPTION name ADD PUBLICATION publication_name [, ...] [ WITH ( publication_option [= value] [, ... ] ) ]
ALTER SUBSCRIPTION name DROP PUBLICATION publication_name [, ...] [ WITH ( publication_option [= value] [, ... ] ) ]
ALTER SUBSCRIPTION name REFRESH PUBLICATION [ WITH ( refresh_option [= value] [, ... ] ) ]
ALTER SUBSCRIPTION name ENABLE
ALTER SUBSCRIPTION name DISABLE
ALTER SUBSCRIPTION name SET ( subscription_parameter [= value] [, ... ] )
ALTER SUBSCRIPTION name SKIP ( skip_option = value )
ALTER SUBSCRIPTION name OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }
ALTER SUBSCRIPTION name RENAME TO new_name

DESCRIPTION

ALTER SUBSCRIPTION can change most of the subscription properties that can be specified in CREATE SUBSCRIPTION (CREATE_SUBSCRIPTION(7)).

You must own the subscription to use ALTER SUBSCRIPTION. To rename a subscription or alter the owner, you must have CREATE permission on the database. In addition, to alter the owner, you must be able to SET ROLE to the new owning role. If the subscription has password_required=false, only superusers can modify it.

When refreshing a publication we remove the relations that are no longer part of the publication and we also remove the table synchronization slots if there are any. It is necessary to remove these slots so that the resources allocated for the subscription on the remote host are released. If due to network breakdown or some other error, PostgreSQL is unable to remove the slots, an error will be reported. To proceed in this situation, the user either needs to retry the operation or disassociate the slot from the subscription and drop the subscription as explained in DROP SUBSCRIPTION (DROP_SUBSCRIPTION(7)).

Commands ALTER SUBSCRIPTION … REFRESH PUBLICATION and ALTER SUBSCRIPTION … {SET|ADD|DROP} PUBLICATION … with refresh option as true cannot be executed inside a transaction block. These commands also cannot be executed when the subscription has two_phase commit enabled, unless copy_data is false. See column subtwophasestate of pg_subscription to know the actual two-phase state.

PARAMETERS

name

The name of a subscription whose properties are to be altered.

CONNECTION conninfo

This clause replaces the connection string originally set by CREATE SUBSCRIPTION (CREATE_SUBSCRIPTION(7)). See there for more information.

SET PUBLICATION publication_name
ADD PUBLICATION publication_name
DROP PUBLICATION publication_name

These forms change the list of subscribed publications. SET replaces the entire list of publications with a new list, ADD adds additional publications to the list of publications, and DROP removes the publications from the list of publications. We allow non-existent publications to be specified in ADD and SET variants so that users can add those later. See CREATE SUBSCRIPTION (CREATE_SUBSCRIPTION(7)) for more information. By default, this command will also act like REFRESH PUBLICATION.

publication_option specifies additional options for this operation. The supported options are:

refresh (boolean)

When false, the command will not try to refresh table information. REFRESH PUBLICATION should then be executed separately. The default is true.

Additionally, the options described under REFRESH PUBLICATION may be specified, to control the implicit refresh operation.

REFRESH PUBLICATION

Fetch missing table information from publisher. This will start replication of tables that were added to the subscribed-to publications since CREATE SUBSCRIPTION or the last invocation of REFRESH PUBLICATION.

refresh_option specifies additional options for the refresh operation. The supported options are:

copy_data (boolean)

Specifies whether to copy pre-existing data in the publications that are being subscribed to when the replication starts. The default is true.

Previously subscribed tables are not copied, even if a tables row filter WHERE clause has since been modified.

See Notes for details of how copy_data = true can interact with the origin parameter.

See the binary parameter of CREATE SUBSCRIPTION for details about copying pre-existing data in binary format.

ENABLE

Enables a previously disabled subscription, starting the logical replication worker at the end of the transaction.

DISABLE

Disables a running subscription, stopping the logical replication worker at the end of the transaction.

SET ( subscription_parameter [= value] [, … ] )

This clause alters parameters originally set by CREATE SUBSCRIPTION (CREATE_SUBSCRIPTION(7)). See there for more information. The parameters that can be altered are slot_name, synchronous_commit, binary, streaming, disable_on_error, password_required, run_as_owner, and origin. Only a superuser can set password_required = false.

SKIP ( skip_option = value )

Skips applying all changes of the remote transaction. If incoming data violates any constraints, logical replication will stop until it is resolved. By using the ALTER SUBSCRIPTION … SKIP command, the logical replication worker skips all data modification changes within the transaction. This option has no effect on the transactions that are already prepared by enabling two_phase on the subscriber. After the logical replication worker successfully skips the transaction or finishes a transaction, the LSN (stored in pg_subscription.subskiplsn) is cleared. See Section 31.5 for the details of logical replication conflicts.

skip_option specifies options for this operation. The supported option is:

lsn (pg_lsn)

Specifies the finish LSN of the remote transaction whose changes are to be skipped by the logical replication worker. The finish LSN is the LSN at which the transaction is either committed or prepared. Skipping individual subtransactions is not supported. Setting NONE resets the LSN.

new_owner

The user name of the new owner of the subscription.

new_name

The new name for the subscription.

When specifying a parameter of type boolean, the = value part can be omitted, which is equivalent to specifying TRUE.

EXAMPLES

Change the publication subscribed by a subscription to insert_only:

ALTER SUBSCRIPTION mysub SET PUBLICATION insert_only;

Disable (stop) the subscription:

ALTER SUBSCRIPTION mysub DISABLE;

COMPATIBILITY

ALTER SUBSCRIPTION is a PostgreSQL extension.

SEE ALSO

CREATE SUBSCRIPTION (CREATE_SUBSCRIPTION(7)), DROP SUBSCRIPTION (DROP_SUBSCRIPTION(7)), CREATE PUBLICATION (CREATE_PUBLICATION(7)), ALTER PUBLICATION (ALTER_PUBLICATION(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

236 - Linux cli command EVP_SIGNATURE-CMACssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_SIGNATURE-CMACssl and provides detailed information about the command EVP_SIGNATURE-CMACssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_SIGNATURE-CMACssl.

NAME 🖥️ EVP_SIGNATURE-CMACssl 🖥️

HMAC, EVP_SIGNATURE-Siphash, EVP_SIGNATURE-Poly1305, EVP_SIGNATURE-CMAC - The legacy EVP_PKEY MAC signature implementations

DESCRIPTION

The algorithms described here have legacy support for creating MACs using EVP_DigestSignInit (3) and related functions. This is not the preferred way of creating MACs. Instead you should use the newer EVP_MAC_init (3) functions. This mechanism is provided for backwards compatibility with older versions of OpenSSL.

The same signature parameters can be set using EVP_PKEY_CTX_set_params() as can be set via EVP_MAC_CTX_set_params() for the underlying EVP_MAC. See EVP_MAC-HMAC (7), EVP_MAC-Siphash (7), EVP_MAC-Poly1305 (7) and EVP_MAC-CMAC (7) for details.

See L<EVP_PKEY-HMAC(7)>, L<EVP_PKEY-Siphash(7)>, L<EVP_PKEY-Poly1305(7)> or L<EVP_PKEY-CMAC(7)> for details about parameters that are supported during the creation of an EVP_PKEY.

SEE ALSO

EVP_MAC_init (3), EVP_DigestSignInit (3), EVP_PKEY-HMAC (7), EVP_PKEY-Siphash (7), EVP_PKEY-Poly1305 (7), EVP_PKEY-CMAC (7), EVP_MAC-HMAC (7), EVP_MAC-Siphash (7), EVP_MAC-Poly1305 (7), EVP_MAC-CMAC (7), provider-signature (7),

COPYRIGHT

Copyright 2020 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

237 - Linux cli command ALTER_USER_MAPPING

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_USER_MAPPING and provides detailed information about the command ALTER_USER_MAPPING, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_USER_MAPPING.

NAME 🖥️ ALTER_USER_MAPPING 🖥️

change the definition of a user mapping

SYNOPSIS

ALTER USER MAPPING FOR { user_name | USER | CURRENT_ROLE | CURRENT_USER | SESSION_USER | PUBLIC }
    SERVER server_name
    OPTIONS ( [ ADD | SET | DROP ] option [value] [, ... ] )

DESCRIPTION

ALTER USER MAPPING changes the definition of a user mapping.

The owner of a foreign server can alter user mappings for that server for any user. Also, a user can alter a user mapping for their own user name if USAGE privilege on the server has been granted to the user.

PARAMETERS

user_name

User name of the mapping. CURRENT_ROLE, CURRENT_USER, and USER match the name of the current user. PUBLIC is used to match all present and future user names in the system.

server_name

Server name of the user mapping.

OPTIONS ( [ ADD | SET | DROP ] option [value] [, … ] )

Change options for the user mapping. The new options override any previously specified options. ADD, SET, and DROP specify the action to be performed. ADD is assumed if no operation is explicitly specified. Option names must be unique; options are also validated by the servers foreign-data wrapper.

EXAMPLES

Change the password for user mapping bob, server foo:

ALTER USER MAPPING FOR bob SERVER foo OPTIONS (SET password public);

COMPATIBILITY

ALTER USER MAPPING conforms to ISO/IEC 9075-9 (SQL/MED). There is a subtle syntax issue: The standard omits the FOR key word. Since both CREATE USER MAPPING and DROP USER MAPPING use FOR in analogous positions, and IBM DB2 (being the other major SQL/MED implementation) also requires it for ALTER USER MAPPING, PostgreSQL diverges from the standard here in the interest of consistency and interoperability.

SEE ALSO

CREATE USER MAPPING (CREATE_USER_MAPPING(7)), DROP USER MAPPING (DROP_USER_MAPPING(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

238 - Linux cli command EVP_MAC-BLAKE2ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_MAC-BLAKE2ssl and provides detailed information about the command EVP_MAC-BLAKE2ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_MAC-BLAKE2ssl.

NAME 🖥️ EVP_MAC-BLAKE2ssl 🖥️

BLAKE2, EVP_MAC-BLAKE2BMAC, EVP_MAC-BLAKE2SMAC - The BLAKE2 EVP_MAC implementations

DESCRIPTION

Support for computing BLAKE2 MACs through the EVP_MAC API.

Identity

These implementations are identified with one of these names and properties, to be used with EVP_MAC_fetch():

“BLAKE2BMAC”, “provider=default”

“BLAKE2SMAC”, “provider=default”

Supported parameters

The general description of these parameters can be found in “PARAMETERS” in EVP_MAC (3).

All these parameters (except for “block-size”) can be set with EVP_MAC_CTX_set_params(). Furthermore, the “size” parameter can be retrieved with EVP_MAC_CTX_get_params(), or with EVP_MAC_CTX_get_mac_size(). The length of the “size” parameter should not exceed that of a size_t. Likewise, the “block-size” parameter can be retrieved with EVP_MAC_CTX_get_params(), or with EVP_MAC_CTX_get_block_size().

“key” (OSSL_MAC_PARAM_KEY) <octet string>
Sets the MAC key. It may be at most 64 bytes for BLAKE2BMAC or 32 for BLAKE2SMAC and at least 1 byte in both cases. Setting this parameter is identical to passing a key to EVP_MAC_init (3).

“custom” (OSSL_MAC_PARAM_CUSTOM) <octet string>
Sets the customization/personalization string. It is an optional value of at most 16 bytes for BLAKE2BMAC or 8 for BLAKE2SMAC, and is empty by default.

“salt” (OSSL_MAC_PARAM_SALT) <octet string>
Sets the salt. It is an optional value of at most 16 bytes for BLAKE2BMAC or 8 for BLAKE2SMAC, and is empty by default.

“size” (OSSL_MAC_PARAM_SIZE) <unsigned integer>
Sets the MAC size. It can be any number between 1 and 32 for EVP_MAC_BLAKE2S or between 1 and 64 for EVP_MAC_BLAKE2B. It is 32 and 64 respectively by default.

“block-size” (OSSL_MAC_PARAM_BLOCK_SIZE) <unsigned integer>
Gets the MAC block size. It is 64 for EVP_MAC_BLAKE2S and 128 for EVP_MAC_BLAKE2B.

SEE ALSO

EVP_MAC_CTX_get_params (3), EVP_MAC_CTX_set_params (3), “PARAMETERS” in EVP_MAC (3), OSSL_PARAM (3)

HISTORY

The macros and functions described here were added to OpenSSL 3.0.

COPYRIGHT

Copyright 2018-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

239 - Linux cli command mosquitto-tls

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command mosquitto-tls and provides detailed information about the command mosquitto-tls, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the mosquitto-tls.

NAME 🖥️ mosquitto-tls 🖥️

tls - Configure SSL/TLS support for Mosquitto

DESCRIPTION

mosquitto provides SSL support for encrypted network connections and authentication. This manual describes how to create the files needed.

Note

It is important to use different certificate subject parameters for your CA, server and clients. If the certificates appear identical, even though generated separately, the broker/client will not be able to distinguish between them and you will experience difficult to diagnose errors.

GENERATING CERTIFICATES

The sections below give the openssl commands that can be used to generate certificates, but without any context. The asciicast at https://asciinema.org/a/201826 gives a full run through of how to use those commands.

CERTIFICATE AUTHORITY

Generate a certificate authority certificate and key.

·

openssl req -new -x509 -days <duration> -extensions v3_ca -keyout ca.key -out ca.crt

SERVER

Generate a server key.

·

openssl genrsa -aes256 -out server.key 2048

Generate a server key without encryption.

·

openssl genrsa -out server.key 2048

Generate a certificate signing request to send to the CA.

·

openssl req -out server.csr -key server.key -new

Note

When prompted for the CN (Common Name), please enter either your server (or broker) hostname or domain name.

Send the CSR to the CA, or sign it with your CA key:

·

openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days <duration>

CLIENT

Generate a client key.

·

openssl genrsa -aes256 -out client.key 2048

Generate a certificate signing request to send to the CA.

·

openssl req -out client.csr -key client.key -new

Send the CSR to the CA, or sign it with your CA key:

·

openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out client.crt -days <duration>

SEE ALSO

mosquitto(8), mosquitto-conf(5)

AUTHOR

Roger Light <[email protected]>

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

240 - Linux cli command environ

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command environ and provides detailed information about the command environ, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the environ.

NAME 🖥️ environ 🖥️

user environment

SYNOPSIS

extern char **environ;

DESCRIPTION

The variable environ points to an array of pointers to strings called the “environment”. The last pointer in this array has the value NULL. This array of strings is made available to the process by the execve(2) call when a new program is started. When a child process is created via fork(2), it inherits a copy of its parent’s environment.

By convention, the strings in environ have the form “name**=value”. The name is case-sensitive and may not contain the character “=**”. The value can be anything that can be represented as a string. The name and the value may not contain an embedded null byte (‘�’), since this is assumed to terminate the string.

Environment variables may be placed in the shell’s environment by the export command in sh(1), or by the setenv command if you use csh(1).

The initial environment of the shell is populated in various ways, such as definitions from /etc/environment that are processed by pam_env(8) for all users at login time (on systems that employ pam(8)). In addition, various shell initialization scripts, such as the system-wide /etc/profile script and per-user initializations script may include commands that add variables to the shell’s environment; see the manual page of your preferred shell for details.

Bourne-style shells support the syntax

NAME=value command

to create an environment variable definition only in the scope of the process that executes command. Multiple variable definitions, separated by white space, may precede command.

Arguments may also be placed in the environment at the point of an exec(3). A C program can manipulate its environment using the functions getenv(3), putenv(3), setenv(3), and unsetenv(3).

What follows is a list of environment variables typically seen on a system. This list is incomplete and includes only common variables seen by average users in their day-to-day routine. Environment variables specific to a particular program or library function are documented in the ENVIRONMENT section of the appropriate manual page.

USER
The name of the logged-in user (used by some BSD-derived programs). Set at login time, see section NOTES below.

LOGNAME
The name of the logged-in user (used by some System-V derived programs). Set at login time, see section NOTES below.

HOME
A user’s login directory. Set at login time, see section NOTES below.

LANG
The name of a locale to use for locale categories when not overridden by LC_ALL or more specific environment variables such as LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY, LC_NUMERIC, and LC_TIME (see locale(7) for further details of the LC_* environment variables).

PATH
The sequence of directory prefixes that sh(1) and many other programs employ when searching for an executable file that is specified as a simple filename (i.a., a pathname that contains no slashes). The prefixes are separated by colons (:). The list of prefixes is searched from beginning to end, by checking the pathname formed by concatenating a prefix, a slash, and the filename, until a file with execute permission is found.

As a legacy feature, a zero-length prefix (specified as two adjacent colons, or an initial or terminating colon) is interpreted to mean the current working directory. However, use of this feature is deprecated, and POSIX notes that a conforming application shall use an explicit pathname (e.g., .) to specify the current working directory.

Analogously to PATH, one has CDPATH used by some shells to find the target of a change directory command, MANPATH used by man(1) to find manual pages, and so on.

PWD
Absolute path to the current working directory; required to be partially canonical (no . or .. components).

SHELL
The absolute pathname of the user’s login shell. Set at login time, see section NOTES below.

TERM
The terminal type for which output is to be prepared.

PAGER
The user’s preferred utility to display text files. Any string acceptable as a command-string operand to the sh -c command shall be valid. If PAGER is null or is not set, then applications that launch a pager will default to a program such as less(1) or more(1).

EDITOR/VISUAL
The user’s preferred utility to edit text files. Any string acceptable as a command_string operand to the sh -c command shall be valid.

Note that the behavior of many programs and library routines is influenced by the presence or value of certain environment variables. Examples include the following:

  • The variables LANG, LANGUAGE, NLSPATH, LOCPATH, LC_ALL, LC_MESSAGES, and so on influence locale handling; see catopen(3), gettext(3), and locale(7).

  • TMPDIR influences the path prefix of names created by tempnam(3) and other routines, and the temporary directory used by sort(1) and other programs.

  • LD_LIBRARY_PATH, LD_PRELOAD, and other LD_* variables influence the behavior of the dynamic loader/linker. See also ld.so(8).

  • POSIXLY_CORRECT makes certain programs and library routines follow the prescriptions of POSIX.

  • The behavior of malloc(3) is influenced by MALLOC_* variables.

  • The variable HOSTALIASES gives the name of a file containing aliases to be used with gethostbyname(3).

  • TZ and TZDIR give timezone information used by tzset(3) and through that by functions like ctime(3), localtime(3), mktime(3), strftime(3). See also tzselect(8).

  • TERMCAP gives information on how to address a given terminal (or gives the name of a file containing such information).

  • COLUMNS and LINES tell applications about the window size, possibly overriding the actual size.

  • PRINTER or LPDEST may specify the desired printer to use. See lpr(1).

NOTES

Historically and by standard, environ must be declared in the user program. However, as a (nonstandard) programmer convenience, environ is declared in the header file <unistd.h> if the _GNU_SOURCE feature test macro is defined (see feature_test_macros(7)).

The prctl(2) PR_SET_MM_ENV_START and PR_SET_MM_ENV_END operations can be used to control the location of the process’s environment.

The HOME, LOGNAME, SHELL, and USER variables are set when the user is changed via a session management interface, typically by a program such as login(1) from a user database (such as passwd(5)). (Switching to the root user using su(1) may result in a mixed environment where LOGNAME and USER are retained from old user; see the su(1) manual page.)

BUGS

Clearly there is a security risk here. Many a system command has been tricked into mischief by a user who specified unusual values for IFS or LD_LIBRARY_PATH.

There is also the risk of name space pollution. Programs like make and autoconf allow overriding of default utility names from the environment with similarly named variables in all caps. Thus one uses CC to select the desired C compiler (and similarly MAKE, AR, AS, FC, LD, LEX, RM, YACC, etc.). However, in some traditional uses such an environment variable gives options for the program instead of a pathname. Thus, one has MORE and LESS. Such usage is considered mistaken, and to be avoided in new programs.

SEE ALSO

bash(1), csh(1), env(1), login(1), printenv(1), sh(1), su(1), tcsh(1), execve(2), clearenv(3), exec(3), getenv(3), putenv(3), setenv(3), unsetenv(3), locale(7), ld.so(8), pam_env(8)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

241 - Linux cli command ALTER_TABLE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_TABLE and provides detailed information about the command ALTER_TABLE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_TABLE.

NAME 🖥️ ALTER_TABLE 🖥️

change the definition of a table

SYNOPSIS

ALTER TABLE [ IF EXISTS ] [ ONLY ] name [ * ]
    action [, ... ]
ALTER TABLE [ IF EXISTS ] [ ONLY ] name [ * ]
    RENAME [ COLUMN ] column_name TO new_column_name
ALTER TABLE [ IF EXISTS ] [ ONLY ] name [ * ]
    RENAME CONSTRAINT constraint_name TO new_constraint_name
ALTER TABLE [ IF EXISTS ] name
    RENAME TO new_name
ALTER TABLE [ IF EXISTS ] name
    SET SCHEMA new_schema
ALTER TABLE ALL IN TABLESPACE name [ OWNED BY role_name [, ... ] ]
    SET TABLESPACE new_tablespace [ NOWAIT ]
ALTER TABLE [ IF EXISTS ] name
    ATTACH PARTITION partition_name { FOR VALUES partition_bound_spec | DEFAULT }
ALTER TABLE [ IF EXISTS ] name
    DETACH PARTITION partition_name [ CONCURRENTLY | FINALIZE ]

where action is one of:

    ADD [ COLUMN ] [ IF NOT EXISTS ] column_name data_type [ COLLATE collation ] [ column_constraint [ ... ] ]
    DROP [ COLUMN ] [ IF EXISTS ] column_name [ RESTRICT | CASCADE ]
    ALTER [ COLUMN ] column_name [ SET DATA ] TYPE data_type [ COLLATE collation ] [ USING expression ]
    ALTER [ COLUMN ] column_name SET DEFAULT expression
    ALTER [ COLUMN ] column_name DROP DEFAULT
    ALTER [ COLUMN ] column_name { SET | DROP } NOT NULL
    ALTER [ COLUMN ] column_name DROP EXPRESSION [ IF EXISTS ]
    ALTER [ COLUMN ] column_name ADD GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY [ ( sequence_options ) ]
    ALTER [ COLUMN ] column_name { SET GENERATED { ALWAYS | BY DEFAULT } | SET sequence_option | RESTART [ [ WITH ] restart ] } [...]
    ALTER [ COLUMN ] column_name DROP IDENTITY [ IF EXISTS ]
    ALTER [ COLUMN ] column_name SET STATISTICS integer
    ALTER [ COLUMN ] column_name SET ( attribute_option = value [, ... ] )
    ALTER [ COLUMN ] column_name RESET ( attribute_option [, ... ] )
    ALTER [ COLUMN ] column_name SET STORAGE { PLAIN | EXTERNAL | EXTENDED | MAIN | DEFAULT }
    ALTER [ COLUMN ] column_name SET COMPRESSION compression_method
    ADD table_constraint [ NOT VALID ]
    ADD table_constraint_using_index
    ALTER CONSTRAINT constraint_name [ DEFERRABLE | NOT DEFERRABLE ] [ INITIALLY DEFERRED | INITIALLY IMMEDIATE ]
    VALIDATE CONSTRAINT constraint_name
    DROP CONSTRAINT [ IF EXISTS ]  constraint_name [ RESTRICT | CASCADE ]
    DISABLE TRIGGER [ trigger_name | ALL | USER ]
    ENABLE TRIGGER [ trigger_name | ALL | USER ]
    ENABLE REPLICA TRIGGER trigger_name
    ENABLE ALWAYS TRIGGER trigger_name
    DISABLE RULE rewrite_rule_name
    ENABLE RULE rewrite_rule_name
    ENABLE REPLICA RULE rewrite_rule_name
    ENABLE ALWAYS RULE rewrite_rule_name
    DISABLE ROW LEVEL SECURITY
    ENABLE ROW LEVEL SECURITY
    FORCE ROW LEVEL SECURITY
    NO FORCE ROW LEVEL SECURITY
    CLUSTER ON index_name
    SET WITHOUT CLUSTER
    SET WITHOUT OIDS
    SET ACCESS METHOD new_access_method
    SET TABLESPACE new_tablespace
    SET { LOGGED | UNLOGGED }
    SET ( storage_parameter [= value] [, ... ] )
    RESET ( storage_parameter [, ... ] )
    INHERIT parent_table
    NO INHERIT parent_table
    OF type_name
    NOT OF
    OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }
    REPLICA IDENTITY { DEFAULT | USING INDEX index_name | FULL | NOTHING }

and partition_bound_spec is:

IN ( partition_bound_expr [, ...] ) |
FROM ( { partition_bound_expr | MINVALUE | MAXVALUE } [, ...] )
  TO ( { partition_bound_expr | MINVALUE | MAXVALUE } [, ...] ) |
WITH ( MODULUS numeric_literal, REMAINDER numeric_literal )

and column_constraint is:

[ CONSTRAINT constraint_name ]
{ NOT NULL |
  NULL |
  CHECK ( expression ) [ NO INHERIT ] |
  DEFAULT default_expr |
  GENERATED ALWAYS AS ( generation_expr ) STORED |
  GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY [ ( sequence_options ) ] |
  UNIQUE [ NULLS [ NOT ] DISTINCT ] index_parameters |
  PRIMARY KEY index_parameters |
  REFERENCES reftable [ ( refcolumn ) ] [ MATCH FULL | MATCH PARTIAL | MATCH SIMPLE ]
    [ ON DELETE referential_action ] [ ON UPDATE referential_action ] }
[ DEFERRABLE | NOT DEFERRABLE ] [ INITIALLY DEFERRED | INITIALLY IMMEDIATE ]

and table_constraint is:

[ CONSTRAINT constraint_name ]
{ CHECK ( expression ) [ NO INHERIT ] |
  UNIQUE [ NULLS [ NOT ] DISTINCT ] ( column_name [, ... ] ) index_parameters |
  PRIMARY KEY ( column_name [, ... ] ) index_parameters |
  EXCLUDE [ USING index_method ] ( exclude_element WITH operator [, ... ] ) index_parameters [ WHERE ( predicate ) ] |
  FOREIGN KEY ( column_name [, ... ] ) REFERENCES reftable [ ( refcolumn [, ... ] ) ]
    [ MATCH FULL | MATCH PARTIAL | MATCH SIMPLE ] [ ON DELETE referential_action ] [ ON UPDATE referential_action ] }
[ DEFERRABLE | NOT DEFERRABLE ] [ INITIALLY DEFERRED | INITIALLY IMMEDIATE ]

and table_constraint_using_index is:

    [ CONSTRAINT constraint_name ]
    { UNIQUE | PRIMARY KEY } USING INDEX index_name
    [ DEFERRABLE | NOT DEFERRABLE ] [ INITIALLY DEFERRED | INITIALLY IMMEDIATE ]

index_parameters in UNIQUE, PRIMARY KEY, and EXCLUDE constraints are:

[ INCLUDE ( column_name [, ... ] ) ]
[ WITH ( storage_parameter [= value] [, ... ] ) ]
[ USING INDEX TABLESPACE tablespace_name ]

exclude_element in an EXCLUDE constraint is:

{ column_name | ( expression ) } [ COLLATE collation ] [ opclass [ ( opclass_parameter = value [, ... ] ) ] ] [ ASC | DESC ] [ NULLS { FIRST | LAST } ]

referential_action in a FOREIGN KEY/REFERENCES constraint is:

{ NO ACTION | RESTRICT | CASCADE | SET NULL [ ( column_name [, ... ] ) ] | SET DEFAULT [ ( column_name [, ... ] ) ] }

DESCRIPTION

ALTER TABLE changes the definition of an existing table. There are several subforms described below. Note that the lock level required may differ for each subform. An ACCESS EXCLUSIVE lock is acquired unless explicitly noted. When multiple subcommands are given, the lock acquired will be the strictest one required by any subcommand.

ADD COLUMN [ IF NOT EXISTS ]

This form adds a new column to the table, using the same syntax as CREATE TABLE. If IF NOT EXISTS is specified and a column already exists with this name, no error is thrown.

DROP COLUMN [ IF EXISTS ]

This form drops a column from a table. Indexes and table constraints involving the column will be automatically dropped as well. Multivariate statistics referencing the dropped column will also be removed if the removal of the column would cause the statistics to contain data for only a single column. You will need to say CASCADE if anything outside the table depends on the column, for example, foreign key references or views. If IF EXISTS is specified and the column does not exist, no error is thrown. In this case a notice is issued instead.

SET DATA TYPE

This form changes the type of a column of a table. Indexes and simple table constraints involving the column will be automatically converted to use the new column type by reparsing the originally supplied expression. The optional COLLATE clause specifies a collation for the new column; if omitted, the collation is the default for the new column type. The optional USING clause specifies how to compute the new column value from the old; if omitted, the default conversion is the same as an assignment cast from old data type to new. A USING clause must be provided if there is no implicit or assignment cast from old to new type.

When this form is used, the columns statistics are removed, so running ANALYZE on the table afterwards is recommended.

SET/DROP DEFAULT

These forms set or remove the default value for a column (where removal is equivalent to setting the default value to NULL). The new default value will only apply in subsequent INSERT or UPDATE commands; it does not cause rows already in the table to change.

SET/DROP NOT NULL

These forms change whether a column is marked to allow null values or to reject null values.

SET NOT NULL may only be applied to a column provided none of the records in the table contain a NULL value for the column. Ordinarily this is checked during the ALTER TABLE by scanning the entire table; however, if a valid CHECK constraint is found which proves no NULL can exist, then the table scan is skipped.

If this table is a partition, one cannot perform DROP NOT NULL on a column if it is marked NOT NULL in the parent table. To drop the NOT NULL constraint from all the partitions, perform DROP NOT NULL on the parent table. Even if there is no NOT NULL constraint on the parent, such a constraint can still be added to individual partitions, if desired; that is, the children can disallow nulls even if the parent allows them, but not the other way around.

DROP EXPRESSION [ IF EXISTS ]

This form turns a stored generated column into a normal base column. Existing data in the columns is retained, but future changes will no longer apply the generation expression.

If DROP EXPRESSION IF EXISTS is specified and the column is not a stored generated column, no error is thrown. In this case a notice is issued instead.

ADD GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY
SET GENERATED { ALWAYS | BY DEFAULT }
DROP IDENTITY [ IF EXISTS ]

These forms change whether a column is an identity column or change the generation attribute of an existing identity column. See CREATE TABLE for details. Like SET DEFAULT, these forms only affect the behavior of subsequent INSERT and UPDATE commands; they do not cause rows already in the table to change.

If DROP IDENTITY IF EXISTS is specified and the column is not an identity column, no error is thrown. In this case a notice is issued instead.

SET sequence_option
RESTART

These forms alter the sequence that underlies an existing identity column. sequence_option is an option supported by ALTER SEQUENCE such as INCREMENT BY.

SET STATISTICS

This form sets the per-column statistics-gathering target for subsequent ANALYZE operations. The target can be set in the range 0 to 10000; alternatively, set it to -1 to revert to using the system default statistics target (default_statistics_target). For more information on the use of statistics by the PostgreSQL query planner, refer to Section 14.2.

SET STATISTICS acquires a SHARE UPDATE EXCLUSIVE lock.

SET ( attribute_option = value [, … ] )
RESET ( attribute_option [, … ] )

This form sets or resets per-attribute options. Currently, the only defined per-attribute options are n_distinct and n_distinct_inherited, which override the number-of-distinct-values estimates made by subsequent ANALYZE operations. n_distinct affects the statistics for the table itself, while n_distinct_inherited affects the statistics gathered for the table plus its inheritance children. When set to a positive value, ANALYZE will assume that the column contains exactly the specified number of distinct nonnull values. When set to a negative value, which must be greater than or equal to -1, ANALYZE will assume that the number of distinct nonnull values in the column is linear in the size of the table; the exact count is to be computed by multiplying the estimated table size by the absolute value of the given number. For example, a value of -1 implies that all values in the column are distinct, while a value of -0.5 implies that each value appears twice on the average. This can be useful when the size of the table changes over time, since the multiplication by the number of rows in the table is not performed until query planning time. Specify a value of 0 to revert to estimating the number of distinct values normally. For more information on the use of statistics by the PostgreSQL query planner, refer to Section 14.2.

Changing per-attribute options acquires a SHARE UPDATE EXCLUSIVE lock.

SET STORAGE { PLAIN | EXTERNAL | EXTENDED | MAIN | DEFAULT }

This form sets the storage mode for a column. This controls whether this column is held inline or in a secondary TOAST table, and whether the data should be compressed or not. PLAIN must be used for fixed-length values such as integer and is inline, uncompressed. MAIN is for inline, compressible data. EXTERNAL is for external, uncompressed data, and EXTENDED is for external, compressed data. Writing DEFAULT sets the storage mode to the default mode for the columns data type. EXTENDED is the default for most data types that support non-PLAIN storage. Use of EXTERNAL will make substring operations on very large text and bytea values run faster, at the penalty of increased storage space. Note that ALTER TABLE … SET STORAGE doesnt itself change anything in the table; it just sets the strategy to be pursued during future table updates. See Section 73.2 for more information.

SET COMPRESSION compression_method

This form sets the compression method for a column, determining how values inserted in future will be compressed (if the storage mode permits compression at all). This does not cause the table to be rewritten, so existing data may still be compressed with other compression methods. If the table is restored with pg_restore, then all values are rewritten with the configured compression method. However, when data is inserted from another relation (for example, by INSERT … SELECT), values from the source table are not necessarily detoasted, so any previously compressed data may retain its existing compression method, rather than being recompressed with the compression method of the target column. The supported compression methods are pglz and lz4. (lz4 is available only if –with-lz4 was used when building PostgreSQL.) In addition, compression_method can be default, which selects the default behavior of consulting the default_toast_compression setting at the time of data insertion to determine the method to use.

ADD table_constraint [ NOT VALID ]

This form adds a new constraint to a table using the same constraint syntax as CREATE TABLE, plus the option NOT VALID, which is currently only allowed for foreign key and CHECK constraints.

Normally, this form will cause a scan of the table to verify that all existing rows in the table satisfy the new constraint. But if the NOT VALID option is used, this potentially-lengthy scan is skipped. The constraint will still be enforced against subsequent inserts or updates (that is, theyll fail unless there is a matching row in the referenced table, in the case of foreign keys, or theyll fail unless the new row matches the specified check condition). But the database will not assume that the constraint holds for all rows in the table, until it is validated by using the VALIDATE CONSTRAINT option. See Notes below for more information about using the NOT VALID option.

Although most forms of ADD table_constraint require an ACCESS EXCLUSIVE lock, ADD FOREIGN KEY requires only a SHARE ROW EXCLUSIVE lock. Note that ADD FOREIGN KEY also acquires a SHARE ROW EXCLUSIVE lock on the referenced table, in addition to the lock on the table on which the constraint is declared.

Additional restrictions apply when unique or primary key constraints are added to partitioned tables; see CREATE TABLE. Also, foreign key constraints on partitioned tables may not be declared NOT VALID at present.

ADD table_constraint_using_index

This form adds a new PRIMARY KEY or UNIQUE constraint to a table based on an existing unique index. All the columns of the index will be included in the constraint.

The index cannot have expression columns nor be a partial index. Also, it must be a b-tree index with default sort ordering. These restrictions ensure that the index is equivalent to one that would be built by a regular ADD PRIMARY KEY or ADD UNIQUE command.

If PRIMARY KEY is specified, and the indexs columns are not already marked NOT NULL, then this command will attempt to do ALTER COLUMN SET NOT NULL against each such column. That requires a full table scan to verify the column(s) contain no nulls. In all other cases, this is a fast operation.

If a constraint name is provided then the index will be renamed to match the constraint name. Otherwise the constraint will be named the same as the index.

After this command is executed, the index is “owned” by the constraint, in the same way as if the index had been built by a regular ADD PRIMARY KEY or ADD UNIQUE command. In particular, dropping the constraint will make the index disappear too.

This form is not currently supported on partitioned tables.

Note

Adding a constraint using an existing index can be helpful in situations where a new constraint needs to be added without blocking table updates for a long time. To do that, create the index using CREATE INDEX CONCURRENTLY, and then install it as an official constraint using this syntax. See the example below.

ALTER CONSTRAINT

This form alters the attributes of a constraint that was previously created. Currently only foreign key constraints may be altered.

VALIDATE CONSTRAINT

This form validates a foreign key or check constraint that was previously created as NOT VALID, by scanning the table to ensure there are no rows for which the constraint is not satisfied. Nothing happens if the constraint is already marked valid. (See Notes below for an explanation of the usefulness of this command.)

This command acquires a SHARE UPDATE EXCLUSIVE lock.

DROP CONSTRAINT [ IF EXISTS ]

This form drops the specified constraint on a table, along with any index underlying the constraint. If IF EXISTS is specified and the constraint does not exist, no error is thrown. In this case a notice is issued instead.

DISABLE/ENABLE [ REPLICA | ALWAYS ] TRIGGER

These forms configure the firing of trigger(s) belonging to the table. A disabled trigger is still known to the system, but is not executed when its triggering event occurs. (For a deferred trigger, the enable status is checked when the event occurs, not when the trigger function is actually executed.) One can disable or enable a single trigger specified by name, or all triggers on the table, or only user triggers (this option excludes internally generated constraint triggers, such as those that are used to implement foreign key constraints or deferrable uniqueness and exclusion constraints). Disabling or enabling internally generated constraint triggers requires superuser privileges; it should be done with caution since of course the integrity of the constraint cannot be guaranteed if the triggers are not executed.

The trigger firing mechanism is also affected by the configuration variable session_replication_role. Simply enabled triggers (the default) will fire when the replication role is “origin” (the default) or “local”. Triggers configured as ENABLE REPLICA will only fire if the session is in “replica” mode, and triggers configured as ENABLE ALWAYS will fire regardless of the current replication role.

The effect of this mechanism is that in the default configuration, triggers do not fire on replicas. This is useful because if a trigger is used on the origin to propagate data between tables, then the replication system will also replicate the propagated data; so the trigger should not fire a second time on the replica, because that would lead to duplication. However, if a trigger is used for another purpose such as creating external alerts, then it might be appropriate to set it to ENABLE ALWAYS so that it is also fired on replicas.

When this command is applied to a partitioned table, the states of corresponding clone triggers in the partitions are updated too, unless ONLY is specified.

This command acquires a SHARE ROW EXCLUSIVE lock.

DISABLE/ENABLE [ REPLICA | ALWAYS ] RULE

These forms configure the firing of rewrite rules belonging to the table. A disabled rule is still known to the system, but is not applied during query rewriting. The semantics are as for disabled/enabled triggers. This configuration is ignored for ON SELECT rules, which are always applied in order to keep views working even if the current session is in a non-default replication role.

The rule firing mechanism is also affected by the configuration variable session_replication_role, analogous to triggers as described above.

DISABLE/ENABLE ROW LEVEL SECURITY

These forms control the application of row security policies belonging to the table. If enabled and no policies exist for the table, then a default-deny policy is applied. Note that policies can exist for a table even if row-level security is disabled. In this case, the policies will not be applied and the policies will be ignored. See also CREATE POLICY.

NO FORCE/FORCE ROW LEVEL SECURITY

These forms control the application of row security policies belonging to the table when the user is the table owner. If enabled, row-level security policies will be applied when the user is the table owner. If disabled (the default) then row-level security will not be applied when the user is the table owner. See also CREATE POLICY.

CLUSTER ON

This form selects the default index for future CLUSTER operations. It does not actually re-cluster the table.

Changing cluster options acquires a SHARE UPDATE EXCLUSIVE lock.

SET WITHOUT CLUSTER

This form removes the most recently used CLUSTER index specification from the table. This affects future cluster operations that dont specify an index.

Changing cluster options acquires a SHARE UPDATE EXCLUSIVE lock.

SET WITHOUT OIDS

Backward-compatible syntax for removing the oid system column. As oid system columns cannot be added anymore, this never has an effect.

SET ACCESS METHOD

This form changes the access method of the table by rewriting it. See Chapter 63 for more information.

SET TABLESPACE

This form changes the tables tablespace to the specified tablespace and moves the data file(s) associated with the table to the new tablespace. Indexes on the table, if any, are not moved; but they can be moved separately with additional SET TABLESPACE commands. When applied to a partitioned table, nothing is moved, but any partitions created afterwards with CREATE TABLE PARTITION OF will use that tablespace, unless overridden by a TABLESPACE clause.

All tables in the current database in a tablespace can be moved by using the ALL IN TABLESPACE form, which will lock all tables to be moved first and then move each one. This form also supports OWNED BY, which will only move tables owned by the roles specified. If the NOWAIT option is specified then the command will fail if it is unable to acquire all of the locks required immediately. Note that system catalogs are not moved by this command; use ALTER DATABASE or explicit ALTER TABLE invocations instead if desired. The information_schema relations are not considered part of the system catalogs and will be moved. See also CREATE TABLESPACE.

SET { LOGGED | UNLOGGED }

This form changes the table from unlogged to logged or vice-versa (see UNLOGGED). It cannot be applied to a temporary table.

This also changes the persistence of any sequences linked to the table (for identity or serial columns). However, it is also possible to change the persistence of such sequences separately.

SET ( storage_parameter [= value] [, … ] )

This form changes one or more storage parameters for the table. See Storage Parameters in the CREATE TABLE documentation for details on the available parameters. Note that the table contents will not be modified immediately by this command; depending on the parameter you might need to rewrite the table to get the desired effects. That can be done with VACUUM FULL, CLUSTER or one of the forms of ALTER TABLE that forces a table rewrite. For planner related parameters, changes will take effect from the next time the table is locked so currently executing queries will not be affected.

SHARE UPDATE EXCLUSIVE lock will be taken for fillfactor, toast and autovacuum storage parameters, as well as the planner parameter parallel_workers.

RESET ( storage_parameter [, … ] )

This form resets one or more storage parameters to their defaults. As with SET, a table rewrite might be needed to update the table entirely.

INHERIT parent_table

This form adds the target table as a new child of the specified parent table. Subsequently, queries against the parent will include records of the target table. To be added as a child, the target table must already contain all the same columns as the parent (it could have additional columns, too). The columns must have matching data types, and if they have NOT NULL constraints in the parent then they must also have NOT NULL constraints in the child.

There must also be matching child-table constraints for all CHECK constraints of the parent, except those marked non-inheritable (that is, created with ALTER TABLE … ADD CONSTRAINT … NO INHERIT) in the parent, which are ignored; all child-table constraints matched must not be marked non-inheritable. Currently UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints are not considered, but this might change in the future.

NO INHERIT parent_table

This form removes the target table from the list of children of the specified parent table. Queries against the parent table will no longer include records drawn from the target table.

OF type_name

This form links the table to a composite type as though CREATE TABLE OF had formed it. The tables list of column names and types must precisely match that of the composite type. The table must not inherit from any other table. These restrictions ensure that CREATE TABLE OF would permit an equivalent table definition.

NOT OF

This form dissociates a typed table from its type.

OWNER TO

This form changes the owner of the table, sequence, view, materialized view, or foreign table to the specified user.

REPLICA IDENTITY

This form changes the information which is written to the write-ahead log to identify rows which are updated or deleted. In most cases, the old value of each column is only logged if it differs from the new value; however, if the old value is stored externally, it is always logged regardless of whether it changed. This option has no effect except when logical replication is in use.

DEFAULT

Records the old values of the columns of the primary key, if any. This is the default for non-system tables.

USING INDEX index_name

Records the old values of the columns covered by the named index, that must be unique, not partial, not deferrable, and include only columns marked NOT NULL. If this index is dropped, the behavior is the same as NOTHING.

FULL

Records the old values of all columns in the row.

NOTHING

Records no information about the old row. This is the default for system tables.

RENAME

The RENAME forms change the name of a table (or an index, sequence, view, materialized view, or foreign table), the name of an individual column in a table, or the name of a constraint of the table. When renaming a constraint that has an underlying index, the index is renamed as well. There is no effect on the stored data.

SET SCHEMA

This form moves the table into another schema. Associated indexes, constraints, and sequences owned by table columns are moved as well.

ATTACH PARTITION partition_name { FOR VALUES partition_bound_spec | DEFAULT }

This form attaches an existing table (which might itself be partitioned) as a partition of the target table. The table can be attached as a partition for specific values using FOR VALUES or as a default partition by using DEFAULT. For each index in the target table, a corresponding one will be created in the attached table; or, if an equivalent index already exists, it will be attached to the target tables index, as if ALTER INDEX ATTACH PARTITION had been executed. Note that if the existing table is a foreign table, it is currently not allowed to attach the table as a partition of the target table if there are UNIQUE indexes on the target table. (See also CREATE FOREIGN TABLE (CREATE_FOREIGN_TABLE(7)).) For each user-defined row-level trigger that exists in the target table, a corresponding one is created in the attached table.

A partition using FOR VALUES uses same syntax for partition_bound_spec as CREATE TABLE. The partition bound specification must correspond to the partitioning strategy and partition key of the target table. The table to be attached must have all the same columns as the target table and no more; moreover, the column types must also match. Also, it must have all the NOT NULL and CHECK constraints of the target table. Currently FOREIGN KEY constraints are not considered. UNIQUE and PRIMARY KEY constraints from the parent table will be created in the partition, if they dont already exist. If any of the CHECK constraints of the table being attached are marked NO INHERIT, the command will fail; such constraints must be recreated without the NO INHERIT clause.

If the new partition is a regular table, a full table scan is performed to check that existing rows in the table do not violate the partition constraint. It is possible to avoid this scan by adding a valid CHECK constraint to the table that allows only rows satisfying the desired partition constraint before running this command. The CHECK constraint will be used to determine that the table need not be scanned to validate the partition constraint. This does not work, however, if any of the partition keys is an expression and the partition does not accept NULL values. If attaching a list partition that will not accept NULL values, also add a NOT NULL constraint to the partition key column, unless its an expression.

If the new partition is a foreign table, nothing is done to verify that all the rows in the foreign table obey the partition constraint. (See the discussion in CREATE FOREIGN TABLE (CREATE_FOREIGN_TABLE(7)) about constraints on the foreign table.)

When a table has a default partition, defining a new partition changes the partition constraint for the default partition. The default partition cant contain any rows that would need to be moved to the new partition, and will be scanned to verify that none are present. This scan, like the scan of the new partition, can be avoided if an appropriate CHECK constraint is present. Also like the scan of the new partition, it is always skipped when the default partition is a foreign table.

Attaching a partition acquires a SHARE UPDATE EXCLUSIVE lock on the parent table, in addition to the ACCESS EXCLUSIVE locks on the table being attached and on the default partition (if any).

Further locks must also be held on all sub-partitions if the table being attached is itself a partitioned table. Likewise if the default partition is itself a partitioned table. The locking of the sub-partitions can be avoided by adding a CHECK constraint as described in Section 5.11.2.2.

DETACH PARTITION partition_name [ CONCURRENTLY | FINALIZE ]

This form detaches the specified partition of the target table. The detached partition continues to exist as a standalone table, but no longer has any ties to the table from which it was detached. Any indexes that were attached to the target tables indexes are detached. Any triggers that were created as clones of those in the target table are removed. SHARE lock is obtained on any tables that reference this partitioned table in foreign key constraints.

If CONCURRENTLY is specified, it runs using a reduced lock level to avoid blocking other sessions that might be accessing the partitioned table. In this mode, two transactions are used internally. During the first transaction, a SHARE UPDATE EXCLUSIVE lock is taken on both parent table and partition, and the partition is marked as undergoing detach; at that point, the transaction is committed and all other transactions using the partitioned table are waited for. Once all those transactions have completed, the second transaction acquires SHARE UPDATE EXCLUSIVE on the partitioned table and ACCESS EXCLUSIVE on the partition, and the detach process completes. A CHECK constraint that duplicates the partition constraint is added to the partition. CONCURRENTLY cannot be run in a transaction block and is not allowed if the partitioned table contains a default partition.

If FINALIZE is specified, a previous DETACH CONCURRENTLY invocation that was canceled or interrupted is completed. At most one partition in a partitioned table can be pending detach at a time.

All the forms of ALTER TABLE that act on a single table, except RENAME, SET SCHEMA, ATTACH PARTITION, and DETACH PARTITION can be combined into a list of multiple alterations to be applied together. For example, it is possible to add several columns and/or alter the type of several columns in a single command. This is particularly useful with large tables, since only one pass over the table need be made.

You must own the table to use ALTER TABLE. To change the schema or tablespace of a table, you must also have CREATE privilege on the new schema or tablespace. To add the table as a new child of a parent table, you must own the parent table as well. Also, to attach a table as a new partition of the table, you must own the table being attached. To alter the owner, you must be able to SET ROLE to the new owning role, and that role must have CREATE privilege on the tables schema. (These restrictions enforce that altering the owner doesnt do anything you couldnt do by dropping and recreating the table. However, a superuser can alter ownership of any table anyway.) To add a column or alter a column type or use the OF clause, you must also have USAGE privilege on the data type.

PARAMETERS

IF EXISTS

Do not throw an error if the table does not exist. A notice is issued in this case.

name

The name (optionally schema-qualified) of an existing table to alter. If ONLY is specified before the table name, only that table is altered. If ONLY is not specified, the table and all its descendant tables (if any) are altered. Optionally, * can be specified after the table name to explicitly indicate that descendant tables are included.

column_name

Name of a new or existing column.

new_column_name

New name for an existing column.

new_name

New name for the table.

data_type

Data type of the new column, or new data type for an existing column.

table_constraint

New table constraint for the table.

constraint_name

Name of a new or existing constraint.

CASCADE

Automatically drop objects that depend on the dropped column or constraint (for example, views referencing the column), and in turn all objects that depend on those objects (see Section 5.14).

RESTRICT

Refuse to drop the column or constraint if there are any dependent objects. This is the default behavior.

trigger_name

Name of a single trigger to disable or enable.

ALL

Disable or enable all triggers belonging to the table. (This requires superuser privilege if any of the triggers are internally generated constraint triggers, such as those that are used to implement foreign key constraints or deferrable uniqueness and exclusion constraints.)

USER

Disable or enable all triggers belonging to the table except for internally generated constraint triggers, such as those that are used to implement foreign key constraints or deferrable uniqueness and exclusion constraints.

index_name

The name of an existing index.

storage_parameter

The name of a table storage parameter.

value

The new value for a table storage parameter. This might be a number or a word depending on the parameter.

parent_table

A parent table to associate or de-associate with this table.

new_owner

The user name of the new owner of the table.

new_access_method

The name of the access method to which the table will be converted.

new_tablespace

The name of the tablespace to which the table will be moved.

new_schema

The name of the schema to which the table will be moved.

partition_name

The name of the table to attach as a new partition or to detach from this table.

partition_bound_spec

The partition bound specification for a new partition. Refer to CREATE TABLE (CREATE_TABLE(7)) for more details on the syntax of the same.

NOTES

The key word COLUMN is noise and can be omitted.

When a column is added with ADD COLUMN and a non-volatile DEFAULT is specified, the default is evaluated at the time of the statement and the result stored in the tables metadata. That value will be used for the column for all existing rows. If no DEFAULT is specified, NULL is used. In neither case is a rewrite of the table required.

Adding a column with a volatile DEFAULT or changing the type of an existing column will require the entire table and its indexes to be rewritten. As an exception, when changing the type of an existing column, if the USING clause does not change the column contents and the old type is either binary coercible to the new type or an unconstrained domain over the new type, a table rewrite is not needed. However, indexes must always be rebuilt unless the system can verify that the new index would be logically equivalent to the existing one. For example, if the collation for a column has been changed, an index rebuild is always required because the new sort order might be different. However, in the absence of a collation change, a column can be changed from text to varchar (or vice versa) without rebuilding the indexes because these data types sort identically. Table and/or index rebuilds may take a significant amount of time for a large table; and will temporarily require as much as double the disk space.

Adding a CHECK or NOT NULL constraint requires scanning the table to verify that existing rows meet the constraint, but does not require a table rewrite.

Similarly, when attaching a new partition it may be scanned to verify that existing rows meet the partition constraint.

The main reason for providing the option to specify multiple changes in a single ALTER TABLE is that multiple table scans or rewrites can thereby be combined into a single pass over the table.

Scanning a large table to verify a new foreign key or check constraint can take a long time, and other updates to the table are locked out until the ALTER TABLE ADD CONSTRAINT command is committed. The main purpose of the NOT VALID constraint option is to reduce the impact of adding a constraint on concurrent updates. With NOT VALID, the ADD CONSTRAINT command does not scan the table and can be committed immediately. After that, a VALIDATE CONSTRAINT command can be issued to verify that existing rows satisfy the constraint. The validation step does not need to lock out concurrent updates, since it knows that other transactions will be enforcing the constraint for rows that they insert or update; only pre-existing rows need to be checked. Hence, validation acquires only a SHARE UPDATE EXCLUSIVE lock on the table being altered. (If the constraint is a foreign key then a ROW SHARE lock is also required on the table referenced by the constraint.) In addition to improving concurrency, it can be useful to use NOT VALID and VALIDATE CONSTRAINT in cases where the table is known to contain pre-existing violations. Once the constraint is in place, no new violations can be inserted, and the existing problems can be corrected at leisure until VALIDATE CONSTRAINT finally succeeds.

The DROP COLUMN form does not physically remove the column, but simply makes it invisible to SQL operations. Subsequent insert and update operations in the table will store a null value for the column. Thus, dropping a column is quick but it will not immediately reduce the on-disk size of your table, as the space occupied by the dropped column is not reclaimed. The space will be reclaimed over time as existing rows are updated.

To force immediate reclamation of space occupied by a dropped column, you can execute one of the forms of ALTER TABLE that performs a rewrite of the whole table. This results in reconstructing each row with the dropped column replaced by a null value.

The rewriting forms of ALTER TABLE are not MVCC-safe. After a table rewrite, the table will appear empty to concurrent transactions, if they are using a snapshot taken before the rewrite occurred. See Section 13.6 for more details.

The USING option of SET DATA TYPE can actually specify any expression involving the old values of the row; that is, it can refer to other columns as well as the one being converted. This allows very general conversions to be done with the SET DATA TYPE syntax. Because of this flexibility, the USING expression is not applied to the columns default value (if any); the result might not be a constant expression as required for a default. This means that when there is no implicit or assignment cast from old to new type, SET DATA TYPE might fail to convert the default even though a USING clause is supplied. In such cases, drop the default with DROP DEFAULT, perform the ALTER TYPE, and then use SET DEFAULT to add a suitable new default. Similar considerations apply to indexes and constraints involving the column.

If a table has any descendant tables, it is not permitted to add, rename, or change the type of a column in the parent table without doing the same to the descendants. This ensures that the descendants always have columns matching the parent. Similarly, a CHECK constraint cannot be renamed in the parent without also renaming it in all descendants, so that CHECK constraints also match between the parent and its descendants. (That restriction does not apply to index-based constraints, however.) Also, because selecting from the parent also selects from its descendants, a constraint on the parent cannot be marked valid unless it is also marked valid for those descendants. In all of these cases, ALTER TABLE ONLY will be rejected.

A recursive DROP COLUMN operation will remove a descendant tables column only if the descendant does not inherit that column from any other parents and never had an independent definition of the column. A nonrecursive DROP COLUMN (i.e., ALTER TABLE ONLY … DROP COLUMN) never removes any descendant columns, but instead marks them as independently defined rather than inherited. A nonrecursive DROP COLUMN command will fail for a partitioned table, because all partitions of a table must have the same columns as the partitioning root.

The actions for identity columns (ADD GENERATED, SET etc., DROP IDENTITY), as well as the actions CLUSTER, OWNER, and TABLESPACE never recurse to descendant tables; that is, they always act as though ONLY were specified. Actions affecting trigger states recurse to partitions of partitioned tables (unless ONLY is specified), but never to traditional-inheritance descendants. Adding a constraint recurses only for CHECK constraints that are not marked NO INHERIT.

Changing any part of a system catalog table is not permitted.

Refer to CREATE TABLE (CREATE_TABLE(7)) for a further description of valid parameters. Chapter 5 has further information on inheritance.

EXAMPLES

To add a column of type varchar to a table:

ALTER TABLE distributors ADD COLUMN address varchar(30);

That will cause all existing rows in the table to be filled with null values for the new column.

To add a column with a non-null default:

ALTER TABLE measurements ADD COLUMN mtime timestamp with time zone DEFAULT now();

Existing rows will be filled with the current time as the value of the new column, and then new rows will receive the time of their insertion.

To add a column and fill it with a value different from the default to be used later:

ALTER TABLE transactions ADD COLUMN status varchar(30) DEFAULT old, ALTER COLUMN status SET default current;

Existing rows will be filled with old, but then the default for subsequent commands will be current. The effects are the same as if the two sub-commands had been issued in separate ALTER TABLE commands.

To drop a column from a table:

ALTER TABLE distributors DROP COLUMN address RESTRICT;

To change the types of two existing columns in one operation:

ALTER TABLE distributors ALTER COLUMN address TYPE varchar(80), ALTER COLUMN name TYPE varchar(100);

To change an integer column containing Unix timestamps to timestamp with time zone via a USING clause:

ALTER TABLE foo ALTER COLUMN foo_timestamp SET DATA TYPE timestamp with time zone USING timestamp with time zone epoch + foo_timestamp * interval 1 second;

The same, when the column has a default expression that wont automatically cast to the new data type:

ALTER TABLE foo ALTER COLUMN foo_timestamp DROP DEFAULT, ALTER COLUMN foo_timestamp TYPE timestamp with time zone USING timestamp with time zone epoch + foo_timestamp * interval 1 second, ALTER COLUMN foo_timestamp SET DEFAULT now();

To rename an existing column:

ALTER TABLE distributors RENAME COLUMN address TO city;

To rename an existing table:

ALTER TABLE distributors RENAME TO suppliers;

To rename an existing constraint:

ALTER TABLE distributors RENAME CONSTRAINT zipchk TO zip_check;

To add a not-null constraint to a column:

ALTER TABLE distributors ALTER COLUMN street SET NOT NULL;

To remove a not-null constraint from a column:

ALTER TABLE distributors ALTER COLUMN street DROP NOT NULL;

To add a check constraint to a table and all its children:

ALTER TABLE distributors ADD CONSTRAINT zipchk CHECK (char_length(zipcode) = 5);

To add a check constraint only to a table and not to its children:

ALTER TABLE distributors ADD CONSTRAINT zipchk CHECK (char_length(zipcode) = 5) NO INHERIT;

(The check constraint will not be inherited by future children, either.)

To remove a check constraint from a table and all its children:

ALTER TABLE distributors DROP CONSTRAINT zipchk;

To remove a check constraint from one table only:

ALTER TABLE ONLY distributors DROP CONSTRAINT zipchk;

(The check constraint remains in place for any child tables.)

To add a foreign key constraint to a table:

ALTER TABLE distributors ADD CONSTRAINT distfk FOREIGN KEY (address) REFERENCES addresses (address);

To add a foreign key constraint to a table with the least impact on other work:

ALTER TABLE distributors ADD CONSTRAINT distfk FOREIGN KEY (address) REFERENCES addresses (address) NOT VALID; ALTER TABLE distributors VALIDATE CONSTRAINT distfk;

To add a (multicolumn) unique constraint to a table:

ALTER TABLE distributors ADD CONSTRAINT dist_id_zipcode_key UNIQUE (dist_id, zipcode);

To add an automatically named primary key constraint to a table, noting that a table can only ever have one primary key:

ALTER TABLE distributors ADD PRIMARY KEY (dist_id);

To move a table to a different tablespace:

ALTER TABLE distributors SET TABLESPACE fasttablespace;

To move a table to a different schema:

ALTER TABLE myschema.distributors SET SCHEMA yourschema;

To recreate a primary key constraint, without blocking updates while the index is rebuilt:

CREATE UNIQUE INDEX CONCURRENTLY dist_id_temp_idx ON distributors (dist_id); ALTER TABLE distributors DROP CONSTRAINT distributors_pkey, ADD CONSTRAINT distributors_pkey PRIMARY KEY USING INDEX dist_id_temp_idx;

To attach a partition to a range-partitioned table:

ALTER TABLE measurement ATTACH PARTITION measurement_y2016m07 FOR VALUES FROM (2016-07-01) TO (2016-08-01);

To attach a partition to a list-partitioned table:

ALTER TABLE cities ATTACH PARTITION cities_ab FOR VALUES IN (a, b);

To attach a partition to a hash-partitioned table:

ALTER TABLE orders ATTACH PARTITION orders_p4 FOR VALUES WITH (MODULUS 4, REMAINDER 3);

To attach a default partition to a partitioned table:

ALTER TABLE cities ATTACH PARTITION cities_partdef DEFAULT;

To detach a partition from a partitioned table:

ALTER TABLE measurement DETACH PARTITION measurement_y2015m12;

COMPATIBILITY

The forms ADD (without USING INDEX), DROP [COLUMN], DROP IDENTITY, RESTART, SET DEFAULT, SET DATA TYPE (without USING), SET GENERATED, and SET sequence_option conform with the SQL standard. The other forms are PostgreSQL extensions of the SQL standard. Also, the ability to specify more than one manipulation in a single ALTER TABLE command is an extension.

ALTER TABLE DROP COLUMN can be used to drop the only column of a table, leaving a zero-column table. This is an extension of SQL, which disallows zero-column tables.

SEE ALSO

CREATE TABLE (CREATE_TABLE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

242 - Linux cli command Ed448ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command Ed448ssl and provides detailed information about the command Ed448ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the Ed448ssl.

NAME 🖥️ Ed448ssl 🖥️

ED25519, EVP_SIGNATURE-ED448, Ed25519, Ed448 - EVP_PKEY Ed25519 and Ed448 support

DESCRIPTION

The Ed25519 and Ed448 EVP_PKEY implementation supports key generation, one-shot digest-sign and digest-verify using the EdDSA signature scheme described in RFC 8032. It has associated private and public key formats compatible with RFC 8410.

EdDSA Instances

RFC 8032 describes five EdDSA instances: Ed25519, Ed25519ctx, Ed25519ph, Ed448, Ed448ph.

The instances Ed25519, Ed25519ctx, Ed448 are referred to as PureEdDSA schemes. For these three instances, the sign and verify procedures require access to the complete message (not a digest of the message).

The instances Ed25519ph, Ed448ph are referred to as HashEdDSA schemes. For these two instances, the sign and verify procedures do not require access to the complete message; they operate on a hash of the message. For Ed25519ph, the hash function is SHA512. For Ed448ph, the hash function is SHAKE256 with an output length of 512 bits.

The instances Ed25519ctx, Ed25519ph, Ed448, Ed448ph accept an optional context-string as input to sign and verify operations (and for Ed25519ctx, the context-string must be nonempty). For the Ed25519 instance, a nonempty context-string is not permitted.

ED25519 and ED448 Signature Parameters

Two parameters can be set during signing or verification: the EdDSA instance name and the context-string value. They can be set by passing an OSSL_PARAM array to EVP_DigestSignInit_ex().

  • “instance” (OSSL_SIGNATURE_PARAM_INSTANCE) <utf8 string> One of the five strings “Ed25519”, “Ed25519ctx”, “Ed25519ph”, “Ed448”, “Ed448ph”. “Ed25519”, “Ed25519ctx”, “Ed25519ph” are valid only for an Ed25519 EVP_PKEY. “Ed448”, “Ed448ph” are valid only for an Ed448 EVP_PKEY.

  • “context-string” (OSSL_SIGNATURE_PARAM_CONTEXT_STRING) <octet string> A string of octets with length at most 255.

Both of these parameters are optional.

If the instance name is not specified, then the default “Ed25519” or “Ed448” is used.

If a context-string is not specified, then an empty context-string is used.

Note that a message digest name must NOT be specified when signing or verifying.

See EVP_PKEY-X25519 (7) for information related to X25519 and X448 keys.

The following signature parameters can be retrieved using EVP_PKEY_CTX_get_params().

  • “algorithm-id” (OSSL_SIGNATURE_PARAM_ALGORITHM_ID) <octet string>

  • “instance” (OSSL_SIGNATURE_PARAM_INSTANCE) <utf8 string>

  • “context-string” (OSSL_SIGNATURE_PARAM_CONTEXT_STRING) <octet string>

The parameters are described in provider-signature (7).

NOTES

The PureEdDSA instances do not support the streaming mechanism of other signature algorithms using, for example, EVP_DigestUpdate(). The message to sign or verify must be passed using the one-shot EVP_DigestSign() and EVP_DigestVerify() functions.

The HashEdDSA instances do not yet support the streaming mechanisms (so the one-shot functions must be used with HashEdDSA as well).

When calling EVP_DigestSignInit() or EVP_DigestVerifyInit(), the digest type parameter MUST be set to NULL.

Applications wishing to sign certificates (or other structures such as CRLs or certificate requests) using Ed25519 or Ed448 can either use X509_sign() or X509_sign_ctx() in the usual way.

Ed25519 or Ed448 private keys can be set directly using EVP_PKEY_new_raw_private_key (3) or loaded from a PKCS#8 private key file using PEM_read_bio_PrivateKey (3) (or similar function). Completely new keys can also be generated (see the example below). Setting a private key also sets the associated public key.

Ed25519 or Ed448 public keys can be set directly using EVP_PKEY_new_raw_public_key (3) or loaded from a SubjectPublicKeyInfo structure in a PEM file using PEM_read_bio_PUBKEY (3) (or similar function).

Ed25519 and Ed448 can be tested with the openssl-speed (1) application since version 1.1.1. Valid algorithm names are ed25519, ed448 and eddsa. If eddsa is specified, then both Ed25519 and Ed448 are benchmarked.

EXAMPLES

To sign a message using an ED25519 EVP_PKEY structure:

void do_sign(EVP_PKEY *ed_key, unsigned char *msg, size_t msg_len) { size_t sig_len; unsigned char *sig = NULL; EVP_MD_CTX *md_ctx = EVP_MD_CTX_new(); const OSSL_PARAM params[] = { OSSL_PARAM_utf8_string (“instance”, “Ed25519ctx”, 10), OSSL_PARAM_octet_string(“context-string”, (unsigned char *)“A protocol defined context string”, 33), OSSL_PARAM_END }; /* The input “params” is not needed if default options are acceptable. Use NULL in place of “params” in that case. */ EVP_DigestSignInit_ex(md_ctx, NULL, NULL, NULL, NULL, ed_key, params); /* Calculate the required size for the signature by passing a NULL buffer. */ EVP_DigestSign(md_ctx, NULL, &sig_len, msg, msg_len); sig = OPENSSL_zalloc(sig_len); EVP_DigestSign(md_ctx, sig, &sig_len, msg, msg_len); … OPENSSL_free(sig); EVP_MD_CTX_free(md_ctx); }

SEE ALSO

EVP_PKEY-X25519 (7) provider-signature (7), EVP_DigestSignInit (3), EVP_DigestVerifyInit (3),

COPYRIGHT

Copyright 2017-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

243 - Linux cli command gitcredentials

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command gitcredentials and provides detailed information about the command gitcredentials, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the gitcredentials.

NAME 🖥️ gitcredentials 🖥️

Providing usernames and passwords to Git

SYNOPSIS

git config credential.https://example.com.username myusername
git config credential.helper "$helper $options"

DESCRIPTION

Git will sometimes need credentials from the user in order to perform operations; for example, it may need to ask for a username and password in order to access a remote repository over HTTP. Some remotes accept a personal access token or OAuth access token as a password. This manual describes the mechanisms Git uses to request these credentials, as well as some features to avoid inputting these credentials repeatedly.

REQUESTING CREDENTIALS

Without any credential helpers defined, Git will try the following strategies to ask the user for usernames and passwords:

1.

If the GIT_ASKPASS environment variable is set, the program specified by the variable is invoked. A suitable prompt is provided to the program on the command line, and the user’s input is read from its standard output.

2.

Otherwise, if the core.askPass configuration variable is set, its value is used as above.

3.

Otherwise, if the SSH_ASKPASS environment variable is set, its value is used as above.

4.

Otherwise, the user is prompted on the terminal.

AVOIDING REPETITION

It can be cumbersome to input the same credentials over and over. Git provides two methods to reduce this annoyance:

1.

Static configuration of usernames for a given authentication context.

2.

Credential helpers to cache or store passwords, or to interact with a system password wallet or keychain.

The first is simple and appropriate if you do not have secure storage available for a password. It is generally configured by adding this to your config:

[credential “https://example.com”] username = me

Credential helpers, on the other hand, are external programs from which Git can request both usernames and passwords; they typically interface with secure storage provided by the OS or other programs. Alternatively, a credential-generating helper might generate credentials for certain servers via some API.

To use a helper, you must first select one to use. Git currently includes the following helpers:

cache

Cache credentials in memory for a short period of time. See git-credential-cache(1) for details.

store

Store credentials indefinitely on disk. See git-credential-store(1) for details.

You may also have third-party helpers installed; search for credential-* in the output of git help -a, and consult the documentation of individual helpers. Once you have selected a helper, you can tell Git to use it by putting its name into the credential.helper variable.

1.

Find a helper.

$ git help -a | grep credential- credential-foo

2.

Read its description.

$ git help credential-foo

3.

Tell Git to use it.

$ git config –global credential.helper foo

Available helpers

The community maintains a comprehensive list of Git credential helpers at https://git-scm.com/doc/credential-helpers.

OAuth

An alternative to inputting passwords or personal access tokens is to use an OAuth credential helper. Initial authentication opens a browser window to the host. Subsequent authentication happens in the background. Many popular Git hosts support OAuth.

CREDENTIAL CONTEXTS

Git considers each credential to have a context defined by a URL. This context is used to look up context-specific configuration, and is passed to any helpers, which may use it as an index into secure storage.

For instance, imagine we are accessing https://example.com/foo.git. When Git looks into a config file to see if a section matches this context, it will consider the two a match if the context is a more-specific subset of the pattern in the config file. For example, if you have this in your config file:

[credential “https://example.com”] username = foo

then we will match: both protocols are the same, both hosts are the same, and the “pattern” URL does not care about the path component at all. However, this context would not match:

[credential “https://kernel.org”] username = foo

because the hostnames differ. Nor would it match foo.example.com; Git compares hostnames exactly, without considering whether two hosts are part of the same domain. Likewise, a config entry for http://example.com would not match: Git compares the protocols exactly. However, you may use wildcards in the domain name and other pattern matching techniques as with the http.<URL>.* options.

If the “pattern” URL does include a path component, then this too must match exactly: the context https://example.com/bar/baz.git will match a config entry for https://example.com/bar/baz.git (in addition to matching the config entry for https://example.com) but will not match a config entry for https://example.com/bar.

CONFIGURATION OPTIONS

Options for a credential context can be configured either in credential.* (which applies to all credentials), or credential.<URL>.*, where <URL> matches the context as described above.

The following options are available in either location:

helper

The name of an external credential helper, and any associated options. If the helper name is not an absolute path, then the string git credential- is prepended. The resulting string is executed by the shell (so, for example, setting this to foo –option=bar will execute git credential-foo –option=bar via the shell. See the manual of specific helpers for examples of their use.

If there are multiple instances of the credential.helper configuration variable, each helper will be tried in turn, and may provide a username, password, or nothing. Once Git has acquired both a username and a non-expired password, no more helpers will be tried.

If credential.helper is configured to the empty string, this resets the helper list to empty (so you may override a helper set by a lower-priority config file by configuring the empty-string helper, followed by whatever set of helpers you would like).

username

A default username, if one is not provided in the URL.

useHttpPath

By default, Git does not consider the “path” component of an http URL to be worth matching via external helpers. This means that a credential stored for https://example.com/foo.git will also be used for https://example.com/bar.git. If you do want to distinguish these cases, set this option to true.

CUSTOM HELPERS

You can write your own custom helpers to interface with any system in which you keep credentials.

Credential helpers are programs executed by Git to fetch or save credentials from and to long-term storage (where “long-term” is simply longer than a single Git process; e.g., credentials may be stored in-memory for a few minutes, or indefinitely on disk).

Each helper is specified by a single string in the configuration variable credential.helper (and others, see git-config(1)). The string is transformed by Git into a command to be executed using these rules:

1.

If the helper string begins with “!”, it is considered a shell snippet, and everything after the “!” becomes the command.

2.

Otherwise, if the helper string begins with an absolute path, the verbatim helper string becomes the command.

3.

Otherwise, the string “git credential-” is prepended to the helper string, and the result becomes the command.

The resulting command then has an “operation” argument appended to it (see below for details), and the result is executed by the shell.

Here are some example specifications:

run “git credential-foo”

[credential]
        helper = foo

# same as above, but pass an argument to the helper
[credential]
        helper = "foo --bar=baz"

# the arguments are parsed by the shell, so use shell
# quoting if necessary
[credential]
        helper = "foo --bar=whitespace arg"

# you can also use an absolute path, which will not use the git wrapper
[credential]
        helper = "/path/to/my/helper --with-arguments"

# or you can specify your own shell snippet
[credential "https://example.com"]
        username = your_user
        helper = "!f() { test \"$1\" = get && echo \"password=$(cat $HOME/.secret)\"; }; f"

Generally speaking, rule (3) above is the simplest for users to specify. Authors of credential helpers should make an effort to assist their users by naming their program “git-credential-$NAME”, and putting it in the $PATH or $GIT_EXEC_PATH during installation, which will allow a user to enable it with git config credential.helper $NAME.

When a helper is executed, it will have one “operation” argument appended to its command line, which is one of:

get

Return a matching credential, if any exists.

store

Store the credential, if applicable to the helper.

erase

Remove matching credentials, if any, from the helper’s storage.

The details of the credential will be provided on the helper’s stdin stream. The exact format is the same as the input/output format of the git credential plumbing command (see the section INPUT/OUTPUT FORMAT in git-credential(1) for a detailed specification).

For a get operation, the helper should produce a list of attributes on stdout in the same format (see git-credential(1) for common attributes). A helper is free to produce a subset, or even no values at all if it has nothing useful to provide. Any provided attributes will overwrite those already known about by Git’s credential subsystem. Unrecognised attributes are silently discarded.

While it is possible to override all attributes, well behaving helpers should refrain from doing so for any attribute other than username and password.

If a helper outputs a quit attribute with a value of true or 1, no further helpers will be consulted, nor will the user be prompted (if no credential has been provided, the operation will then fail).

Similarly, no more helpers will be consulted once both username and password had been provided.

For a store or erase operation, the helper’s output is ignored.

If a helper fails to perform the requested operation or needs to notify the user of a potential issue, it may write to stderr.

If it does not support the requested operation (e.g., a read-only store or generator), it should silently ignore the request.

If a helper receives any other operation, it should silently ignore the request. This leaves room for future operations to be added (older helpers will just ignore the new requests).

GIT

Part of the git(1) suite

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

244 - Linux cli command pkg.m4

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command pkg.m4 and provides detailed information about the command pkg.m4, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the pkg.m4.

is a collection of autoconf macros which help to configure compiler and linker flags for development libraries. This allows build systems to detect other dependencies and use them with the system toolchain.

Checks that the version of the

autoconf macros in use is at least MIN-VERSION. This can be used to ensure a particular

macro will be available.

Checks for an implementation of

which is at least MIN-VERSION or newer.

Checks whether a given module set exists, and if so, defines

and

variables prefixed by

with the output from

and

respectively.

The optional

and

arguments are shell fragments that should be executed if the module set is found or not found.

If

is not defined, the

macro will be executed to locate a

implementation.

The

macro provides the same behaviour as

with static linking enabled via the

flag.

Defines the variable $pkgconfigdir as the location where a package should install pkg-config .pc files.

By default the directory is $libdir/pkgconfig, but the default can be changed by passing the

parameter.

This value can be overridden with the

configure parameter.

Defines the variable $noarch_pkgconfigdir as the location where a package should install pkg-config .pc files.

By default the directory is $datadir/pkgconfig, but the default can be changed by passing the

parameter.

This value can be overridden with the

configure parameter.

Retrieves the value of the

variable

from

and stores it in the

variable.

Note that repeated usage of

is not recommended as the check will be skipped if the variable is already set.

Prepares a “–with-” configure option using the lowercase

name, merging the behaviour of

and

in a single macro.

Convenience macro to trigger

after a

is exported as a make variable.

Convenience macro to trigger

and

after a

is exported as a make variable.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

245 - Linux cli command gitsubmodules

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command gitsubmodules and provides detailed information about the command gitsubmodules, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the gitsubmodules.

NAME 🖥️ gitsubmodules 🖥️

Mounting one repository inside another

SYNOPSIS

.gitmodules, $GIT_DIR/config

git submodule
git <command> --recurse-submodules

DESCRIPTION

A submodule is a repository embedded inside another repository. The submodule has its own history; the repository it is embedded in is called a superproject.

On the filesystem, a submodule usually (but not always - see FORMS below) consists of (i) a Git directory located under the $GIT_DIR/modules/ directory of its superproject, (ii) a working directory inside the superproject’s working directory, and a .git file at the root of the submodule’s working directory pointing to (i).

Assuming the submodule has a Git directory at $GIT_DIR/modules/foo/ and a working directory at path/to/bar/, the superproject tracks the submodule via a gitlink entry in the tree at path/to/bar and an entry in its .gitmodules file (see gitmodules(5)) of the form submodule.foo.path = path/to/bar.

The gitlink entry contains the object name of the commit that the superproject expects the submodule’s working directory to be at.

The section submodule.foo.* in the .gitmodules file gives additional hints to Git’s porcelain layer. For example, the submodule.foo.url setting specifies where to obtain the submodule.

Submodules can be used for at least two different use cases:

1.

Using another project while maintaining independent history. Submodules allow you to contain the working tree of another project within your own working tree while keeping the history of both projects separate. Also, since submodules are fixed to an arbitrary version, the other project can be independently developed without affecting the superproject, allowing the superproject project to fix itself to new versions only when desired.

2.

Splitting a (logically single) project into multiple repositories and tying them back together. This can be used to overcome current limitations of Git’s implementation to have finer grained access:

·

Size of the Git repository: In its current form Git scales up poorly for large repositories containing content that is not compressed by delta computation between trees. For example, you can use submodules to hold large binary assets and these repositories can be shallowly cloned such that you do not have a large history locally.

·

Transfer size: In its current form Git requires the whole working tree present. It does not allow partial trees to be transferred in fetch or clone. If the project you work on consists of multiple repositories tied together as submodules in a superproject, you can avoid fetching the working trees of the repositories you are not interested in.

·

Access control: By restricting user access to submodules, this can be used to implement read/write policies for different users.

THE CONFIGURATION OF SUBMODULES

Submodule operations can be configured using the following mechanisms (from highest to lowest precedence):

·

The command line for those commands that support taking submodules as part of their pathspecs. Most commands have a boolean flag –recurse-submodules which specifies whether to recurse into submodules. Examples are grep and checkout. Some commands take enums, such as fetch and push, where you can specify how submodules are affected.

·

The configuration inside the submodule. This includes $GIT_DIR/config in the submodule, but also settings in the tree such as a .gitattributes or .gitignore files that specify behavior of commands inside the submodule.

For example an effect from the submodule’s .gitignore file would be observed when you run git status –ignore-submodules=none in the superproject. This collects information from the submodule’s working directory by running status in the submodule while paying attention to the .gitignore file of the submodule.

The submodule’s $GIT_DIR/config file would come into play when running git push –recurse-submodules=check in the superproject, as this would check if the submodule has any changes not published to any remote. The remotes are configured in the submodule as usual in the $GIT_DIR/config file.

·

The configuration file $GIT_DIR/config in the superproject. Git only recurses into active submodules (see “ACTIVE SUBMODULES” section below).

If the submodule is not yet initialized, then the configuration inside the submodule does not exist yet, so where to obtain the submodule from is configured here for example.

·

The .gitmodules file inside the superproject. A project usually uses this file to suggest defaults for the upstream collection of repositories for the mapping that is required between a submodule’s name and its path.

This file mainly serves as the mapping between the name and path of submodules in the superproject, such that the submodule’s Git directory can be located.

If the submodule has never been initialized, this is the only place where submodule configuration is found. It serves as the last fallback to specify where to obtain the submodule from.

FORMS

Submodules can take the following forms:

·

The basic form described in DESCRIPTION with a Git directory, a working directory, a gitlink, and a .gitmodules entry.

·

“Old-form” submodule: A working directory with an embedded .git directory, and the tracking gitlink and .gitmodules entry in the superproject. This is typically found in repositories generated using older versions of Git.

It is possible to construct these old form repositories manually.

When deinitialized or deleted (see below), the submodule’s Git directory is automatically moved to $GIT_DIR/modules/<name>/ of the superproject.

·

Deinitialized submodule: A gitlink, and a .gitmodules entry, but no submodule working directory. The submodule’s Git directory may be there as after deinitializing the Git directory is kept around. The directory which is supposed to be the working directory is empty instead.

A submodule can be deinitialized by running git submodule deinit. Besides emptying the working directory, this command only modifies the superproject’s $GIT_DIR/config file, so the superproject’s history is not affected. This can be undone using git submodule init.

·

Deleted submodule: A submodule can be deleted by running git rm <submodule path> && git commit. This can be undone using git revert.

The deletion removes the superproject’s tracking data, which are both the gitlink entry and the section in the .gitmodules file. The submodule’s working directory is removed from the file system, but the Git directory is kept around as it to make it possible to checkout past commits without requiring fetching from another repository.

To completely remove a submodule, manually delete $GIT_DIR/modules/<name>/.

ACTIVE SUBMODULES

A submodule is considered active,

1.

if submodule.<name>.active is set to true

or

2.

if the submodule’s path matches the pathspec in submodule.active

or

3.

if submodule.<name>.url is set.

and these are evaluated in this order.

For example:

[submodule “foo”] active = false url = https://example.org/foo [submodule “bar”] active = true url = https://example.org/bar [submodule “baz”] url = https://example.org/baz

In the above config only the submodules bar and baz are active, bar due to (1) and baz due to (3). foo is inactive because (1) takes precedence over (3)

Note that (3) is a historical artefact and will be ignored if the (1) and (2) specify that the submodule is not active. In other words, if we have a submodule.<name>.active set to false or if the submodule’s path is excluded in the pathspec in submodule.active, the url doesn’t matter whether it is present or not. This is illustrated in the example that follows.

[submodule “foo”] active = true url = https://example.org/foo [submodule “bar”] url = https://example.org/bar [submodule “baz”] url = https://example.org/baz [submodule “bob”] ignore = true [submodule] active = b* active = :(exclude) baz

In here all submodules except baz (foo, bar, bob) are active. foo due to its own active flag and all the others due to the submodule active pathspec, which specifies that any submodule starting with b except baz are also active, regardless of the presence of the .url field.

WORKFLOW FOR A THIRD PARTY LIBRARY

Add a submodule

git submodule add <URL> <path>

Occasionally update the submodule to a new version:

git -C <path> checkout <new version>
git add <path>
git commit -m "update submodule to new version"

See the list of submodules in a superproject

git submodule status

See FORMS on removing submodules

WORKFLOW FOR AN ARTIFICIALLY SPLIT REPO

Enable recursion for relevant commands, such that

# regular commands recurse into submodules by default
git config --global submodule.recurse true

Unlike most other commands below, clone still needs

# its own recurse flag:
git clone --recurse <URL> <directory>
cd <directory>

Get to know the code:

git grep foo
git ls-files --recurse-submodules

Note

git ls-files also requires its own –recurse-submodules flag.

Get new code

git fetch
git pull --rebase

Change worktree

git checkout
git reset

IMPLEMENTATION DETAILS

When cloning or pulling a repository containing submodules the submodules will not be checked out by default; you can instruct clone to recurse into submodules. The init and update subcommands of git submodule will maintain submodules checked out and at an appropriate revision in your working tree. Alternatively you can set submodule.recurse to have checkout recurse into submodules (note that submodule.recurse also affects other Git commands, see git-config(1) for a complete list).

SEE ALSO

git-submodule(1), gitmodules(5).

GIT

Part of the git(1) suite

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

246 - Linux cli command DROP_TRIGGER

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_TRIGGER and provides detailed information about the command DROP_TRIGGER, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_TRIGGER.

NAME 🖥️ DROP_TRIGGER 🖥️

remove a trigger

SYNOPSIS

DROP TRIGGER [ IF EXISTS ] name ON table_name [ CASCADE | RESTRICT ]

DESCRIPTION

DROP TRIGGER removes an existing trigger definition. To execute this command, the current user must be the owner of the table for which the trigger is defined.

PARAMETERS

IF EXISTS

Do not throw an error if the trigger does not exist. A notice is issued in this case.

name

The name of the trigger to remove.

table_name

The name (optionally schema-qualified) of the table for which the trigger is defined.

CASCADE

Automatically drop objects that depend on the trigger, and in turn all objects that depend on those objects (see Section 5.14).

RESTRICT

Refuse to drop the trigger if any objects depend on it. This is the default.

EXAMPLES

Destroy the trigger if_dist_exists on the table films:

DROP TRIGGER if_dist_exists ON films;

COMPATIBILITY

The DROP TRIGGER statement in PostgreSQL is incompatible with the SQL standard. In the SQL standard, trigger names are not local to tables, so the command is simply DROP TRIGGER name.

SEE ALSO

CREATE TRIGGER (CREATE_TRIGGER(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

247 - Linux cli command udplite

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command udplite and provides detailed information about the command udplite, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the udplite.

NAME 🖥️ udplite 🖥️

Lightweight User Datagram Protocol

SYNOPSIS

#include <sys/socket.h>
sockfd = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDPLITE);

DESCRIPTION

This is an implementation of the Lightweight User Datagram Protocol (UDP-Lite), as described in RFC 3828.

UDP-Lite is an extension of UDP (RFC 768) to support variable-length checksums. This has advantages for some types of multimedia transport that may be able to make use of slightly damaged datagrams, rather than having them discarded by lower-layer protocols.

The variable-length checksum coverage is set via a setsockopt(2) option. If this option is not set, the only difference from UDP is in using a different IP protocol identifier (IANA number 136).

The UDP-Lite implementation is a full extension of udp(7)—that is, it shares the same API and API behavior, and in addition offers two socket options to control the checksum coverage.

Address format

UDP-Litev4 uses the sockaddr_in address format described in ip(7). UDP-Litev6 uses the sockaddr_in6 address format described in ipv6(7).

Socket options

To set or get a UDP-Lite socket option, call getsockopt(2) to read or setsockopt(2) to write the option with the option level argument set to IPPROTO_UDPLITE. In addition, all IPPROTO_UDP socket options are valid on a UDP-Lite socket. See udp(7) for more information.

The following two options are specific to UDP-Lite.

UDPLITE_SEND_CSCOV
This option sets the sender checksum coverage and takes an int as argument, with a checksum coverage value in the range 0..2^16-1.

A value of 0 means that the entire datagram is always covered. Values from 1-7 are illegal (RFC 3828, 3.1) and are rounded up to the minimum coverage of 8.

With regard to IPv6 jumbograms (RFC 2675), the UDP-Litev6 checksum coverage is limited to the first 2^16-1 octets, as per RFC 3828, 3.5. Higher values are therefore silently truncated to 2^16-1. If in doubt, the current coverage value can always be queried using getsockopt(2).

UDPLITE_RECV_CSCOV
This is the receiver-side analogue and uses the same argument format and value range as UDPLITE_SEND_CSCOV. This option is not required to enable traffic with partial checksum coverage. Its function is that of a traffic filter: when enabled, it instructs the kernel to drop all packets which have a coverage less than the specified coverage value.

When the value of UDPLITE_RECV_CSCOV exceeds the actual packet coverage, incoming packets are silently dropped, but may generate a warning message in the system log.

ERRORS

All errors documented for udp(7) may be returned. UDP-Lite does not add further errors.

FILES

/proc/net/snmp
Basic UDP-Litev4 statistics counters.

/proc/net/snmp6
Basic UDP-Litev6 statistics counters.

VERSIONS

UDP-Litev4/v6 first appeared in Linux 2.6.20.

BUGS

Where glibc support is missing, the following definitions are needed:

#define IPPROTO_UDPLITE     136
#define UDPLITE_SEND_CSCOV  10
#define UDPLITE_RECV_CSCOV  11

SEE ALSO

ip(7), ipv6(7), socket(7), udp(7)

RFC 3828 for the Lightweight User Datagram Protocol (UDP-Lite).

Documentation/networking/udplite.txt in the Linux kernel source tree

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

248 - Linux cli command SECURITY_LABEL

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command SECURITY_LABEL and provides detailed information about the command SECURITY_LABEL, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the SECURITY_LABEL.

NAME 🖥️ SECURITY_LABEL 🖥️

define or change a security label applied to an object

SYNOPSIS

SECURITY LABEL [ FOR provider ] ON
{
  TABLE object_name |
  COLUMN table_name.column_name |
  AGGREGATE aggregate_name ( aggregate_signature ) |
  DATABASE object_name |
  DOMAIN object_name |
  EVENT TRIGGER object_name |
  FOREIGN TABLE object_name |
  FUNCTION function_name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ] |
  LARGE OBJECT large_object_oid |
  MATERIALIZED VIEW object_name |
  [ PROCEDURAL ] LANGUAGE object_name |
  PROCEDURE procedure_name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ] |
  PUBLICATION object_name |
  ROLE object_name |
  ROUTINE routine_name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ] |
  SCHEMA object_name |
  SEQUENCE object_name |
  SUBSCRIPTION object_name |
  TABLESPACE object_name |
  TYPE object_name |
  VIEW object_name
} IS { string_literal | NULL }

where aggregate_signature is:

* |
[ argmode ] [ argname ] argtype [ , ... ] |
[ [ argmode ] [ argname ] argtype [ , ... ] ] ORDER BY [ argmode ] [ argname ] argtype [ , ... ]

DESCRIPTION

SECURITY LABEL applies a security label to a database object. An arbitrary number of security labels, one per label provider, can be associated with a given database object. Label providers are loadable modules which register themselves by using the function register_label_provider.

Note

register_label_provider is not an SQL function; it can only be called from C code loaded into the backend.

The label provider determines whether a given label is valid and whether it is permissible to assign that label to a given object. The meaning of a given label is likewise at the discretion of the label provider. PostgreSQL places no restrictions on whether or how a label provider must interpret security labels; it merely provides a mechanism for storing them. In practice, this facility is intended to allow integration with label-based mandatory access control (MAC) systems such as SELinux. Such systems make all access control decisions based on object labels, rather than traditional discretionary access control (DAC) concepts such as users and groups.

PARAMETERS

object_name
table_name.column_name
aggregate_name
function_name
procedure_name
routine_name

The name of the object to be labeled. Names of objects that reside in schemas (tables, functions, etc.) can be schema-qualified.

provider

The name of the provider with which this label is to be associated. The named provider must be loaded and must consent to the proposed labeling operation. If exactly one provider is loaded, the provider name may be omitted for brevity.

argmode

The mode of a function, procedure, or aggregate argument: IN, OUT, INOUT, or VARIADIC. If omitted, the default is IN. Note that SECURITY LABEL does not actually pay any attention to OUT arguments, since only the input arguments are needed to determine the functions identity. So it is sufficient to list the IN, INOUT, and VARIADIC arguments.

argname

The name of a function, procedure, or aggregate argument. Note that SECURITY LABEL does not actually pay any attention to argument names, since only the argument data types are needed to determine the functions identity.

argtype

The data type of a function, procedure, or aggregate argument.

large_object_oid

The OID of the large object.

PROCEDURAL

This is a noise word.

string_literal

The new setting of the security label, written as a string literal.

NULL

Write NULL to drop the security label.

EXAMPLES

The following example shows how the security label of a table could be set or changed:

SECURITY LABEL FOR selinux ON TABLE mytable IS system_u:object_r:sepgsql_table_t:s0;

To remove the label:

SECURITY LABEL FOR selinux ON TABLE mytable IS NULL;

COMPATIBILITY

There is no SECURITY LABEL command in the SQL standard.

SEE ALSO

sepgsql, src/test/modules/dummy_seclabel

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

249 - Linux cli command EVP_KDF-PVKKDFssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KDF-PVKKDFssl and provides detailed information about the command EVP_KDF-PVKKDFssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KDF-PVKKDFssl.

NAME 🖥️ EVP_KDF-PVKKDFssl 🖥️

PVKKDF - The PVK EVP_KDF implementation

DESCRIPTION

Support for computing the PVK KDF PIN-based KDF through the EVP_KDF API.

The EVP_KDF-PVKKDF algorithm implements a PVK PIN-based key derivation function; it derives a key from a password using a salt.

Identity

“PVKKDF” is the name for this implementation; it can be used with the EVP_KDF_fetch() function.

Supported parameters

The supported parameters are:

“pass” (OSSL_KDF_PARAM_PASSWORD) <octet string>

“salt” (OSSL_KDF_PARAM_SALT) <octet string>

“properties” (OSSL_KDF_PARAM_PROPERTIES) <UTF8 string>

“digest” (OSSL_KDF_PARAM_DIGEST) <UTF8 string>

These parameters work as described in “PARAMETERS” in EVP_KDF (3).

NOTES

A typical application of this algorithm is to derive keying material for an encryption algorithm from a password in the “pass” and a salt in “salt”.

No assumption is made regarding the given password; it is simply treated as a byte sequence.

The legacy provider needs to be available in order to access this algorithm.

SEE ALSO

EVP_KDF (3), EVP_KDF_CTX_new (3), EVP_KDF_CTX_free (3), EVP_KDF_CTX_set_params (3), EVP_KDF_derive (3), “PARAMETERS” in EVP_KDF (3), OSSL_PROVIDER-legacy (7)

HISTORY

This functionality was added in OpenSSL 3.2.

COPYRIGHT

Copyright 2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

250 - Linux cli command life_cycle-digestssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command life_cycle-digestssl and provides detailed information about the command life_cycle-digestssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the life_cycle-digestssl.

NAME 🖥️ life_cycle-digestssl 🖥️

digest - The digest algorithm life-cycle

DESCRIPTION

All message digests (MDs) go through a number of stages in their life-cycle:

start
This state represents the MD before it has been allocated. It is the starting state for any life-cycle transitions.

newed
This state represents the MD after it has been allocated.

initialised
This state represents the MD when it is set up and capable of processing input.

updated
This state represents the MD when it is set up and capable of processing additional input or generating output.

finaled
This state represents the MD when it has generated output.

freed
This state is entered when the MD is freed. It is the terminal state for all life-cycle transitions.

State Transition Diagram

The usual life-cycle of a MD is illustrated: +——————-+ | start | +——————-+ | | EVP_MD_CTX_new v +——————-+ EVP_MD_CTX_reset | newed | <——————————+ +——————-+ | | | | EVP_DigestInit | v | +——————-+ | +–> | initialised | <+ EVP_DigestInit | | +——————-+ | | | | | EVP_DigestUpdate | | | EVP_DigestUpdate | +——————+ | | v | v | | | +————————————————+ | EVP_DigestInit | | updated | –+ | +————————————————+ | | | | | | | EVP_DigestFinal | EVP_DigestFinalXOF | | v v | | +————————————————+ | +— | finaled | –+ +————————————————+ | | EVP_MD_CTX_free v +——————-+ | freed | +——————-+

Formal State Transitions

This section defines all of the legal state transitions. This is the canonical list. Function Call ——————— Current State ———————- start newed initialised updated finaled freed EVP_MD_CTX_new newed EVP_DigestInit initialised initialised initialised initialised EVP_DigestUpdate updated updated EVP_DigestFinal finaled EVP_DigestFinalXOF finaled EVP_MD_CTX_free freed freed freed freed freed EVP_MD_CTX_reset newed newed newed newed EVP_MD_CTX_get_params newed initialised updated EVP_MD_CTX_set_params newed initialised updated EVP_MD_CTX_gettable_params newed initialised updated EVP_MD_CTX_settable_params newed initialised updated

NOTES

At some point the EVP layer will begin enforcing the transitions described herein.

SEE ALSO

provider-digest (7), EVP_DigestInit (3)

COPYRIGHT

Copyright 2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

251 - Linux cli command libOpenCL.so

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command libOpenCL.so and provides detailed information about the command libOpenCL.so, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the libOpenCL.so.

NAME 🖥️ libOpenCL.so 🖥️

OCL-ICD implementation of OpenCL ICD loader

DESCRIPTION

libOpenCL.so is the library linked by OpenCL programs. It does not contains any OpenCL implementation itself, but merely act as a dispatcher to real OpenCL implementations provided as OpenCL Installable Client Driver (ICD). An ICD loader should be able to load ICDs provided by any vendors.

According to OpenCL specifications from Khronos (see [Khronos]), the ICD Loader looks for files into /etc/OpenCL/vendors directory and, for each file whose name ends with .icd, the ICD Loader loads with dlopen(3) the shared library whose name is on the first line of the .icd file.

Each shared library name in “.icd” files can have its path, or it can be a plain filename. In the latter case, the ICD shared library will be looked for into the standard dynamic library loader paths.

ENVIRONMENT

Some environment variables can be used modify the default behavior of libOpenCL.

OPENCL_VENDOR_PATH

This variable allows one to modify the default /etc/OpenCL/vendors path. It is compatible with some other ICD loaders (but not all of them, as the variable is not part of the standard). Note that $OCL_ICD_VENDORS (see below) is used in priority if defined and not empty.

OCL_ICD_VENDORS

This variable allows one to change the way ICD are searched on the system. Several cases are considered:

1.

if $OCL_ICD_VENDORS is a directory path, then this path replaces the “/etc/OpenCL/vendors” path in the standard behavior: the loader will use the .icd files in this directory;

2.

else, if $OCL_ICD_VENDORS ends with .icd, libOpenCL.so will only load the ICD whose shared library name is wrote into the specified “.icd” file;

If there is no slashes into $OCL_ICD_VENDORS, libOpenCL.so will first try to use /etc/OpenCL/vendors/$OCL_ICD_VENDORS (or $OPENCL_VENDOR_PATH*/*$OCL_ICD_VENDORS if OPENCL_VENDOR_PATH is defined). If this fail or if there are shashes, it uses $OCL_ICD_VENDORS (as a relative or absolute file name path).

3.

else libOpenCL.so will try to load $OCL_ICD_VENDORS as the ICD shared library itself (i.e. to load it directly with dlopen(3)).

OPENCL_LAYERS

This variable allows one to specify a colon separated list of layers to load, specifying their path.

OPENCL_LAYER_PATH

This variable allows one to override the default system layer search path (/etc/OpenCL/layers).

OCL_ICD_ASSUME_ICD_EXTENSION

If set to an non-empty value, contrary the Khronos specification, the loader will not check that the loaded ICDs declare the cl_khr_icd extension. It will also use the clGetPlatformInfo from the dispatch table if no such function is globally available. You may need to define this environment variable if you are using not (fully) compliant ICD, or if you are using the Intel ICD together with optirun(1). In the latter case, a bug into the Intel ICD will make the application crash.

If set to the debug value, some additional messages will be printed in debug mode (see OCL_ICD_DEBUG below).

OCL_ICD_PLATFORM_SORT

Allows one to choose the way platforms are sorted when presented to programs through clGetPlatformIDs(3). Current provided algorithms are:

·

devices: first, list platforms that support most GPU, then most CPU then most accelerators. If OCL_ICD_PLATFORM_SORT is not set or set to an unknown value, this algorithm is used.

·

none: no sort is done and the order can change at each run.

OCL_ICD_DEFAULT_PLATFORM

Number of the platform to choose as default platform. Note that using this environment variable without ensuring the use of a sort algorithm for platforms is not really useful.

OCL_ICD_DEBUG

If ocl-icd has been compiled with debug support, you can set this environment variable to a value where each bit display some kind of informations. Defined values are:

·

1: warnings (enabled by default if debug support is present and OCL_ICD_DEBUG is not set)

·

2: informative messages

·

4: entering/exiting for some OpenCL functions

·

8: dump of the internal structure of loaded ICDs

OCL_ICD_DEBUG is mainly useful for ocl-icd development itself and/or for ICD development.

SEE ALSO

Khronos OpenCL registry website

AUTHOR

Vincent Danjean <[email protected]>

Author.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

252 - Linux cli command pkeys

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command pkeys and provides detailed information about the command pkeys, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the pkeys.

NAME 🖥️ pkeys 🖥️

overview of Memory Protection Keys

DESCRIPTION

Memory Protection Keys (pkeys) are an extension to existing page-based memory permissions. Normal page permissions using page tables require expensive system calls and TLB invalidations when changing permissions. Memory Protection Keys provide a mechanism for changing protections without requiring modification of the page tables on every permission change.

To use pkeys, software must first “tag” a page in the page tables with a pkey. After this tag is in place, an application only has to change the contents of a register in order to remove write access, or all access to a tagged page.

Protection keys work in conjunction with the existing PROT_READ, PROT_WRITE, and PROT_EXEC permissions passed to system calls such as mprotect(2) and mmap(2), but always act to further restrict these traditional permission mechanisms.

If a process performs an access that violates pkey restrictions, it receives a SIGSEGV signal. See sigaction(2) for details of the information available with that signal.

To use the pkeys feature, the processor must support it, and the kernel must contain support for the feature on a given processor. As of early 2016 only future Intel x86 processors are supported, and this hardware supports 16 protection keys in each process. However, pkey 0 is used as the default key, so a maximum of 15 are available for actual application use. The default key is assigned to any memory region for which a pkey has not been explicitly assigned via pkey_mprotect(2).

Protection keys have the potential to add a layer of security and reliability to applications. But they have not been primarily designed as a security feature. For instance, WRPKRU is a completely unprivileged instruction, so pkeys are useless in any case that an attacker controls the PKRU register or can execute arbitrary instructions.

Applications should be very careful to ensure that they do not “leak” protection keys. For instance, before calling pkey_free(2), the application should be sure that no memory has that pkey assigned. If the application left the freed pkey assigned, a future user of that pkey might inadvertently change the permissions of an unrelated data structure, which could impact security or stability. The kernel currently allows in-use pkeys to have pkey_free(2) called on them because it would have processor or memory performance implications to perform the additional checks needed to disallow it. Implementation of the necessary checks is left up to applications. Applications may implement these checks by searching the /proc/pid/smaps file for memory regions with the pkey assigned. Further details can be found in proc(5).

Any application wanting to use protection keys needs to be able to function without them. They might be unavailable because the hardware that the application runs on does not support them, the kernel code does not contain support, the kernel support has been disabled, or because the keys have all been allocated, perhaps by a library the application is using. It is recommended that applications wanting to use protection keys should simply call pkey_alloc(2) and test whether the call succeeds, instead of attempting to detect support for the feature in any other way.

Although unnecessary, hardware support for protection keys may be enumerated with the cpuid instruction. Details of how to do this can be found in the Intel Software Developers Manual. The kernel performs this enumeration and exposes the information in /proc/cpuinfo under the “flags” field. The string “pku” in this field indicates hardware support for protection keys and the string “ospke” indicates that the kernel contains and has enabled protection keys support.

Applications using threads and protection keys should be especially careful. Threads inherit the protection key rights of the parent at the time of the clone(2), system call. Applications should either ensure that their own permissions are appropriate for child threads at the time when clone(2) is called, or ensure that each child thread can perform its own initialization of protection key rights.

Signal Handler Behavior

Each time a signal handler is invoked (including nested signals), the thread is temporarily given a new, default set of protection key rights that override the rights from the interrupted context. This means that applications must re-establish their desired protection key rights upon entering a signal handler if the desired rights differ from the defaults. The rights of any interrupted context are restored when the signal handler returns.

This signal behavior is unusual and is due to the fact that the x86 PKRU register (which stores protection key access rights) is managed with the same hardware mechanism (XSAVE) that manages floating-point registers. The signal behavior is the same as that of floating-point registers.

Protection Keys system calls

The Linux kernel implements the following pkey-related system calls: pkey_mprotect(2), pkey_alloc(2), and pkey_free(2).

The Linux pkey system calls are available only if the kernel was configured and built with the CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS option.

EXAMPLES

The program below allocates a page of memory with read and write permissions. It then writes some data to the memory and successfully reads it back. After that, it attempts to allocate a protection key and disallows access to the page by using the WRPKRU instruction. It then tries to access the page, which we now expect to cause a fatal signal to the application.

$ ./a.out
buffer contains: 73
about to read buffer again...
Segmentation fault (core dumped)

Program source

#define _GNU_SOURCE
#include <err.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>
int
main(void)
{
    int status;
    int pkey;
    int *buffer;
    /*
     * Allocate one page of memory.
     */
    buffer = mmap(NULL, getpagesize(), PROT_READ | PROT_WRITE,
                  MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
    if (buffer == MAP_FAILED)
        err(EXIT_FAILURE, "mmap");
    /*
     * Put some random data into the page (still OK to touch).
     */
    *buffer = __LINE__;
    printf("buffer contains: %d

“, buffer); / * Allocate a protection key: / pkey = pkey_alloc(0, 0); if (pkey == -1) err(EXIT_FAILURE, “pkey_alloc”); / * Disable access to any memory with “pkey” set, * even though there is none right now. / status = pkey_set(pkey, PKEY_DISABLE_ACCESS); if (status) err(EXIT_FAILURE, “pkey_set”); / * Set the protection key on “buffer”. * Note that it is still read/write as far as mprotect() is * concerned and the previous pkey_set() overrides it. / status = pkey_mprotect(buffer, getpagesize(), PROT_READ | PROT_WRITE, pkey); if (status == -1) err(EXIT_FAILURE, “pkey_mprotect”); printf(“about to read buffer again… “); / * This will crash, because we have disallowed access. */ printf(“buffer contains: %d “, *buffer); status = pkey_free(pkey); if (status == -1) err(EXIT_FAILURE, “pkey_free”); exit(EXIT_SUCCESS); }

SEE ALSO

pkey_alloc(2), pkey_free(2), pkey_mprotect(2), sigaction(2)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

253 - Linux cli command gnupg

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command gnupg and provides detailed information about the command gnupg, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the gnupg.

NAME 🖥️ gnupg 🖥️

The GNU Privacy Guard suite of programs

DESCRIPTION

GnuPG is a set of programs for public key encryption and digital signatures. The program most users will want to use is the OpenPGP command line tool, named gpg2. gpgvis a stripped down version of gpg2 with no encryption functionality, used only to verify signatures against a trusted keyring. gpgsm is the X.509/CMS (for S/MIME) counterpart of gpg2. gpg-agent is a passphrase and private key daemon which may also emulate the ssh-agent.

SEE ALSO

gpg(1), gpg2(1), gpgv(1), gpgsm(1), gpg-agent(1), dirmngr(8), scdaemon(1)

The full documentation for this tool is maintained as a Texinfo manual. If GnuPG and the info program are properly installed at your site, the command

info gnupg

should give you access to the complete manual including a menu structure and an index.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

254 - Linux cli command gitdiffcore

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command gitdiffcore and provides detailed information about the command gitdiffcore, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the gitdiffcore.

NAME 🖥️ gitdiffcore 🖥️

Tweaking diff output

SYNOPSIS

git diff *

DESCRIPTION

The diff commands git diff-index, git diff-files, and git diff-tree can be told to manipulate differences they find in unconventional ways before showing diff output. The manipulation is collectively called “diffcore transformation”. This short note describes what they are and how to use them to produce diff output that is easier to understand than the conventional kind.

THE CHAIN OF OPERATION

The git diff-* family works by first comparing two sets of files:

·

git diff-index compares contents of a “tree” object and the working directory (when –cached flag is not used) or a “tree” object and the index file (when –cached flag is used);

·

git diff-files compares contents of the index file and the working directory;

·

git diff-tree compares contents of two “tree” objects;

In all of these cases, the commands themselves first optionally limit the two sets of files by any pathspecs given on their command-lines, and compare corresponding paths in the two resulting sets of files.

The pathspecs are used to limit the world diff operates in. They remove the filepairs outside the specified sets of pathnames. E.g. If the input set of filepairs included:

:100644 100644 bcd1234… 0123456… M junkfile

but the command invocation was git diff-files myfile, then the junkfile entry would be removed from the list because only “myfile” is under consideration.

The result of comparison is passed from these commands to what is internally called “diffcore”, in a format similar to what is output when the -p option is not used. E.g.

in-place edit :100644 100644 bcd1234… 0123456… M file0 create :000000 100644 0000000… 1234567… A file4 delete :100644 000000 1234567… 0000000… D file5 unmerged :000000 000000 0000000… 0000000… U file6

The diffcore mechanism is fed a list of such comparison results (each of which is called “filepair”, although at this point each of them talks about a single file), and transforms such a list into another list. There are currently 5 such transformations:

·

diffcore-break

·

diffcore-rename

·

diffcore-merge-broken

·

diffcore-pickaxe

·

diffcore-order

·

diffcore-rotate

These are applied in sequence. The set of filepairs git diff-* commands find are used as the input to diffcore-break, and the output from diffcore-break is used as the input to the next transformation. The final result is then passed to the output routine and generates either diff-raw format (see Output format sections of the manual for git diff-* commands) or diff-patch format.

DIFFCORE-BREAK: FOR SPLITTING UP COMPLETE REWRITES

The second transformation in the chain is diffcore-break, and is controlled by the -B option to the git diff-* commands. This is used to detect a filepair that represents “complete rewrite” and break such filepair into two filepairs that represent delete and create. E.g. If the input contained this filepair:

:100644 100644 bcd1234… 0123456… M file0

and if it detects that the file “file0” is completely rewritten, it changes it to:

:100644 000000 bcd1234… 0000000… D file0 :000000 100644 0000000… 0123456… A file0

For the purpose of breaking a filepair, diffcore-break examines the extent of changes between the contents of the files before and after modification (i.e. the contents that have “bcd1234…” and “0123456…” as their SHA-1 content ID, in the above example). The amount of deletion of original contents and insertion of new material are added together, and if it exceeds the “break score”, the filepair is broken into two. The break score defaults to 50% of the size of the smaller of the original and the result (i.e. if the edit shrinks the file, the size of the result is used; if the edit lengthens the file, the size of the original is used), and can be customized by giving a number after “-B” option (e.g. “-B75” to tell it to use 75%).

DIFFCORE-RENAME: FOR DETECTING RENAMES AND COPIES

This transformation is used to detect renames and copies, and is controlled by the -M option (to detect renames) and the -C option (to detect copies as well) to the git diff-* commands. If the input contained these filepairs:

:100644 000000 0123456… 0000000… D fileX :000000 100644 0000000… 0123456… A file0

and the contents of the deleted file fileX is similar enough to the contents of the created file file0, then rename detection merges these filepairs and creates:

:100644 100644 0123456… 0123456… R100 fileX file0

When the “-C” option is used, the original contents of modified files, and deleted files (and also unmodified files, if the “–find-copies-harder” option is used) are considered as candidates of the source files in rename/copy operation. If the input were like these filepairs, that talk about a modified file fileY and a newly created file file0:

:100644 100644 0123456… 1234567… M fileY :000000 100644 0000000… bcd3456… A file0

the original contents of fileY and the resulting contents of file0 are compared, and if they are similar enough, they are changed to:

:100644 100644 0123456… 1234567… M fileY :100644 100644 0123456… bcd3456… C100 fileY file0

In both rename and copy detection, the same “extent of changes” algorithm used in diffcore-break is used to determine if two files are “similar enough”, and can be customized to use a similarity score different from the default of 50% by giving a number after the “-M” or “-C” option (e.g. “-M8” to tell it to use 8/10 = 80%).

Note that when rename detection is on but both copy and break detection are off, rename detection adds a preliminary step that first checks if files are moved across directories while keeping their filename the same. If there is a file added to a directory whose contents are sufficiently similar to a file with the same name that got deleted from a different directory, it will mark them as renames and exclude them from the later quadratic step (the one that pairwise compares all unmatched files to find the “best” matches, determined by the highest content similarity). So, for example, if a deleted docs/ext.txt and an added docs/config/ext.txt are similar enough, they will be marked as a rename and prevent an added docs/ext.md that may be even more similar to the deleted docs/ext.txt from being considered as the rename destination in the later step. For this reason, the preliminary “match same filename” step uses a bit higher threshold to mark a file pair as a rename and stop considering other candidates for better matches. At most, one comparison is done per file in this preliminary pass; so if there are several remaining ext.txt files throughout the directory hierarchy after exact rename detection, this preliminary step may be skipped for those files.

Note. When the “-C” option is used with –find-copies-harder option, git diff-* commands feed unmodified filepairs to diffcore mechanism as well as modified ones. This lets the copy detector consider unmodified files as copy source candidates at the expense of making it slower. Without –find-copies-harder, git diff-* commands can detect copies only if the file that was copied happened to have been modified in the same changeset.

DIFFCORE-MERGE-BROKEN: FOR PUTTING COMPLETE REWRITES BACK TOGETHER

This transformation is used to merge filepairs broken by diffcore-break, and not transformed into rename/copy by diffcore-rename, back into a single modification. This always runs when diffcore-break is used.

For the purpose of merging broken filepairs back, it uses a different “extent of changes” computation from the ones used by diffcore-break and diffcore-rename. It counts only the deletion from the original, and does not count insertion. If you removed only 10 lines from a 100-line document, even if you added 910 new lines to make a new 1000-line document, you did not do a complete rewrite. diffcore-break breaks such a case in order to help diffcore-rename to consider such filepairs as a candidate of rename/copy detection, but if filepairs broken that way were not matched with other filepairs to create rename/copy, then this transformation merges them back into the original “modification”.

The “extent of changes” parameter can be tweaked from the default 80% (that is, unless more than 80% of the original material is deleted, the broken pairs are merged back into a single modification) by giving a second number to -B option, like these:

·

-B50/60 (give 50% “break score” to diffcore-break, use 60% for diffcore-merge-broken).

·

-B/60 (the same as above, since diffcore-break defaults to 50%).

Note that earlier implementation left a broken pair as separate creation and deletion patches. This was an unnecessary hack, and the latest implementation always merges all the broken pairs back into modifications, but the resulting patch output is formatted differently for easier review in case of such a complete rewrite by showing the entire contents of the old version prefixed with -, followed by the entire contents of the new version prefixed with +.

DIFFCORE-PICKAXE: FOR DETECTING ADDITION/DELETION OF SPECIFIED STRING

This transformation limits the set of filepairs to those that change specified strings between the preimage and the postimage in a certain way. -S<block of text> and -G<regular expression> options are used to specify different ways these strings are sought.

“-S<block of text>” detects filepairs whose preimage and postimage have different number of occurrences of the specified block of text. By definition, it will not detect in-file moves. Also, when a changeset moves a file wholesale without affecting the interesting string, diffcore-rename kicks in as usual, and -S omits the filepair (since the number of occurrences of that string didn’t change in that rename-detected filepair). When used with –pickaxe-regex, treat the <block of text> as an extended POSIX regular expression to match, instead of a literal string.

“-G<regular expression>” (mnemonic: grep) detects filepairs whose textual diff has an added or a deleted line that matches the given regular expression. This means that it will detect in-file (or what rename-detection considers the same file) moves, which is noise. The implementation runs diff twice and greps, and this can be quite expensive. To speed things up, binary files without textconv filters will be ignored.

When -S or -G are used without –pickaxe-all, only filepairs that match their respective criterion are kept in the output. When –pickaxe-all is used, if even one filepair matches their respective criterion in a changeset, the entire changeset is kept. This behavior is designed to make reviewing changes in the context of the whole changeset easier.

DIFFCORE-ORDER: FOR SORTING THE OUTPUT BASED ON FILENAMES

This is used to reorder the filepairs according to the user’s (or project’s) taste, and is controlled by the -O option to the git diff-* commands.

This takes a text file each of whose lines is a shell glob pattern. Filepairs that match a glob pattern on an earlier line in the file are output before ones that match a later line, and filepairs that do not match any glob pattern are output last.

As an example, a typical orderfile for the core Git probably would look like this:

README Makefile Documentation *.h *.c t

DIFFCORE-ROTATE: FOR CHANGING AT WHICH PATH OUTPUT STARTS

This transformation takes one pathname, and rotates the set of filepairs so that the filepair for the given pathname comes first, optionally discarding the paths that come before it. This is used to implement the –skip-to and the –rotate-to options. It is an error when the specified pathname is not in the set of filepairs, but it is not useful to error out when used with “git log” family of commands, because it is unreasonable to expect that a given path would be modified by each and every commit shown by the “git log” command. For this reason, when used with “git log”, the filepair that sorts the same as, or the first one that sorts after, the given pathname is where the output starts.

Use of this transformation combined with diffcore-order will produce unexpected results, as the input to this transformation is likely not sorted when diffcore-order is in effect.

SEE ALSO

git-diff(1), git-diff-files(1), git-diff-index(1), git-diff-tree(1), git-format-patch(1), git-log(1), gitglossary(7), The Git User’s Manual[1]

GIT

Part of the git(1) suite

NOTES

The Git User’s Manual

file:///usr/share/doc/git/html/user-manual.html

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

255 - Linux cli command capabilities

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command capabilities and provides detailed information about the command capabilities, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the capabilities.

NAME 🖥️ capabilities 🖥️

overview of Linux capabilities

DESCRIPTION

For the purpose of performing permission checks, traditional UNIX implementations distinguish two categories of processes: privileged processes (whose effective user ID is 0, referred to as superuser or root), and unprivileged processes (whose effective UID is nonzero). Privileged processes bypass all kernel permission checks, while unprivileged processes are subject to full permission checking based on the process’s credentials (usually: effective UID, effective GID, and supplementary group list).

Starting with Linux 2.2, Linux divides the privileges traditionally associated with superuser into distinct units, known as capabilities, which can be independently enabled and disabled. Capabilities are a per-thread attribute.

Capabilities list

The following list shows the capabilities implemented on Linux, and the operations or behaviors that each capability permits:

CAP_AUDIT_CONTROL (since Linux 2.6.11)
Enable and disable kernel auditing; change auditing filter rules; retrieve auditing status and filtering rules.

CAP_AUDIT_READ (since Linux 3.16)
Allow reading the audit log via a multicast netlink socket.

CAP_AUDIT_WRITE (since Linux 2.6.11)
Write records to kernel auditing log.

CAP_BLOCK_SUSPEND (since Linux 3.5)
Employ features that can block system suspend (epoll(7) EPOLLWAKEUP, /proc/sys/wake_lock).

CAP_BPF (since Linux 5.8)
Employ privileged BPF operations; see bpf(2) and bpf-helpers(7).

This capability was added in Linux 5.8 to separate out BPF functionality from the overloaded CAP_SYS_ADMIN capability.

CAP_CHECKPOINT_RESTORE (since Linux 5.9)

  • Update /proc/sys/kernel/ns_last_pid (see pid_namespaces(7));

  • employ the set_tid feature of clone3(2);

  • read the contents of the symbolic links in /proc/pid/map_files for other processes.

This capability was added in Linux 5.9 to separate out checkpoint/restore functionality from the overloaded CAP_SYS_ADMIN capability.

CAP_CHOWN
Make arbitrary changes to file UIDs and GIDs (see chown(2)).

CAP_DAC_OVERRIDE
Bypass file read, write, and execute permission checks. (DAC is an abbreviation of “discretionary access control”.)

CAP_DAC_READ_SEARCH

  • Bypass file read permission checks and directory read and execute permission checks;

  • invoke open_by_handle_at(2);

  • use the linkat(2) AT_EMPTY_PATH flag to create a link to a file referred to by a file descriptor.

CAP_FOWNER

  • Bypass permission checks on operations that normally require the filesystem UID of the process to match the UID of the file (e.g., chmod(2), utime(2)), excluding those operations covered by CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH;

  • set inode flags (see ioctl_iflags(2)) on arbitrary files;

  • set Access Control Lists (ACLs) on arbitrary files;

  • ignore directory sticky bit on file deletion;

  • modify user extended attributes on sticky directory owned by any user;

  • specify O_NOATIME for arbitrary files in open(2) and fcntl(2).

CAP_FSETID

  • Don’t clear set-user-ID and set-group-ID mode bits when a file is modified;

  • set the set-group-ID bit for a file whose GID does not match the filesystem or any of the supplementary GIDs of the calling process.

CAP_IPC_LOCK

  • Lock memory (mlock(2), mlockall(2), mmap(2), shmctl(2));

  • Allocate memory using huge pages (memfd_create(2), mmap(2), shmctl(2)).

CAP_IPC_OWNER
Bypass permission checks for operations on System V IPC objects.

CAP_KILL
Bypass permission checks for sending signals (see kill(2)). This includes use of the ioctl(2) KDSIGACCEPT operation.

CAP_LEASE (since Linux 2.4)
Establish leases on arbitrary files (see fcntl(2)).

CAP_LINUX_IMMUTABLE
Set the FS_APPEND_FL and FS_IMMUTABLE_FL inode flags (see ioctl_iflags(2)).

CAP_MAC_ADMIN (since Linux 2.6.25)
Allow MAC configuration or state changes. Implemented for the Smack Linux Security Module (LSM).

CAP_MAC_OVERRIDE (since Linux 2.6.25)
Override Mandatory Access Control (MAC). Implemented for the Smack LSM.

CAP_MKNOD (since Linux 2.4)
Create special files using mknod(2).

CAP_NET_ADMIN
Perform various network-related operations:

  • interface configuration;

  • administration of IP firewall, masquerading, and accounting;

  • modify routing tables;

  • bind to any address for transparent proxying;

  • set type-of-service (TOS);

  • clear driver statistics;

  • set promiscuous mode;

  • enabling multicasting;

  • use setsockopt(2) to set the following socket options: SO_DEBUG, SO_MARK, SO_PRIORITY (for a priority outside the range 0 to 6), SO_RCVBUFFORCE, and SO_SNDBUFFORCE.

CAP_NET_BIND_SERVICE
Bind a socket to Internet domain privileged ports (port numbers less than 1024).

CAP_NET_BROADCAST
(Unused) Make socket broadcasts, and listen to multicasts.

CAP_NET_RAW

  • Use RAW and PACKET sockets;

  • bind to any address for transparent proxying.

CAP_PERFMON (since Linux 5.8)
Employ various performance-monitoring mechanisms, including:

call perf_event_open(2);

  • employ various BPF operations that have performance implications.

This capability was added in Linux 5.8 to separate out performance monitoring functionality from the overloaded CAP_SYS_ADMIN capability. See also the kernel source file Documentation/admin-guide/perf-security.rst.

CAP_SETGID

  • Make arbitrary manipulations of process GIDs and supplementary GID list;

  • forge GID when passing socket credentials via UNIX domain sockets;

  • write a group ID mapping in a user namespace (see user_namespaces(7)).

CAP_SETFCAP (since Linux 2.6.24)
Set arbitrary capabilities on a file.

Since Linux 5.12, this capability is also needed to map user ID 0 in a new user namespace; see user_namespaces(7) for details.

CAP_SETPCAP
If file capabilities are supported (i.e., since Linux 2.6.24): add any capability from the calling thread’s bounding set to its inheritable set; drop capabilities from the bounding set (via prctl(2) PR_CAPBSET_DROP); make changes to the securebits flags.

If file capabilities are not supported (i.e., before Linux 2.6.24): grant or remove any capability in the caller’s permitted capability set to or from any other process. (This property of CAP_SETPCAP is not available when the kernel is configured to support file capabilities, since CAP_SETPCAP has entirely different semantics for such kernels.)

CAP_SETUID

  • Make arbitrary manipulations of process UIDs (setuid(2), setreuid(2), setresuid(2), setfsuid(2));

  • forge UID when passing socket credentials via UNIX domain sockets;

  • write a user ID mapping in a user namespace (see user_namespaces(7)).

CAP_SYS_ADMIN
Note: this capability is overloaded; see Notes to kernel developers below.

  • Perform a range of system administration operations including: quotactl(2), mount(2), umount(2), pivot_root(2), swapon(2), swapoff(2), sethostname(2), and setdomainname(2);

  • perform privileged syslog(2) operations (since Linux 2.6.37, CAP_SYSLOG should be used to permit such operations);

  • perform VM86_REQUEST_IRQ vm86(2) command;

  • access the same checkpoint/restore functionality that is governed by CAP_CHECKPOINT_RESTORE (but the latter, weaker capability is preferred for accessing that functionality).

  • perform the same BPF operations as are governed by CAP_BPF (but the latter, weaker capability is preferred for accessing that functionality).

  • employ the same performance monitoring mechanisms as are governed by CAP_PERFMON (but the latter, weaker capability is preferred for accessing that functionality).

  • perform IPC_SET and IPC_RMID operations on arbitrary System V IPC objects;

  • override RLIMIT_NPROC resource limit;

  • perform operations on trusted and security extended attributes (see xattr(7));

  • use lookup_dcookie(2);

  • use ioprio_set(2) to assign IOPRIO_CLASS_RT and (before Linux 2.6.25) IOPRIO_CLASS_IDLE I/O scheduling classes;

  • forge PID when passing socket credentials via UNIX domain sockets;

  • exceed /proc/sys/fs/file-max, the system-wide limit on the number of open files, in system calls that open files (e.g., accept(2), execve(2), open(2), pipe(2));

  • employ CLONE_* flags that create new namespaces with clone(2) and unshare(2) (but, since Linux 3.8, creating user namespaces does not require any capability);

  • access privileged perf event information;

  • call setns(2) (requires CAP_SYS_ADMIN in the target namespace);

  • call fanotify_init(2);

  • perform privileged KEYCTL_CHOWN and KEYCTL_SETPERM keyctl(2) operations;

  • perform madvise(2) MADV_HWPOISON operation;

  • employ the TIOCSTI ioctl(2) to insert characters into the input queue of a terminal other than the caller’s controlling terminal;

  • employ the obsolete nfsservctl(2) system call;

  • employ the obsolete bdflush(2) system call;

  • perform various privileged block-device ioctl(2) operations;

  • perform various privileged filesystem ioctl(2) operations;

  • perform privileged ioctl(2) operations on the /dev/random device (see random(4));

  • install a seccomp(2) filter without first having to set the no_new_privs thread attribute;

  • modify allow/deny rules for device control groups;

  • employ the ptrace(2) PTRACE_SECCOMP_GET_FILTER operation to dump tracee’s seccomp filters;

  • employ the ptrace(2) PTRACE_SETOPTIONS operation to suspend the tracee’s seccomp protections (i.e., the PTRACE_O_SUSPEND_SECCOMP flag);

  • perform administrative operations on many device drivers;

  • modify autogroup nice values by writing to /proc/pid/autogroup (see sched(7)).

CAP_SYS_BOOT
Use reboot(2) and kexec_load(2).

CAP_SYS_CHROOT

  • Use chroot(2);

  • change mount namespaces using setns(2).

CAP_SYS_MODULE

  • Load and unload kernel modules (see init_module(2) and delete_module(2));

  • before Linux 2.6.25: drop capabilities from the system-wide capability bounding set.

CAP_SYS_NICE

  • Lower the process nice value (nice(2), setpriority(2)) and change the nice value for arbitrary processes;

  • set real-time scheduling policies for calling process, and set scheduling policies and priorities for arbitrary processes (sched_setscheduler(2), sched_setparam(2), sched_setattr(2));

  • set CPU affinity for arbitrary processes (sched_setaffinity(2));

  • set I/O scheduling class and priority for arbitrary processes (ioprio_set(2));

  • apply migrate_pages(2) to arbitrary processes and allow processes to be migrated to arbitrary nodes;

  • apply move_pages(2) to arbitrary processes;

  • use the MPOL_MF_MOVE_ALL flag with mbind(2) and move_pages(2).

CAP_SYS_PACCT
Use acct(2).

CAP_SYS_PTRACE

  • Trace arbitrary processes using ptrace(2);

  • apply get_robust_list(2) to arbitrary processes;

  • transfer data to or from the memory of arbitrary processes using process_vm_readv(2) and process_vm_writev(2);

  • inspect processes using kcmp(2).

CAP_SYS_RAWIO

  • Perform I/O port operations (iopl(2) and ioperm(2));

  • access /proc/kcore;

  • employ the FIBMAP ioctl(2) operation;

  • open devices for accessing x86 model-specific registers (MSRs, see msr(4));

  • update /proc/sys/vm/mmap_min_addr;

  • create memory mappings at addresses below the value specified by /proc/sys/vm/mmap_min_addr;

  • map files in /proc/bus/pci;

  • open /dev/mem and /dev/kmem;

  • perform various SCSI device commands;

  • perform certain operations on hpsa(4) and cciss(4) devices;

  • perform a range of device-specific operations on other devices.

CAP_SYS_RESOURCE

  • Use reserved space on ext2 filesystems;

  • make ioctl(2) calls controlling ext3 journaling;

  • override disk quota limits;

  • increase resource limits (see setrlimit(2));

  • override RLIMIT_NPROC resource limit;

  • override maximum number of consoles on console allocation;

  • override maximum number of keymaps;

  • allow more than 64hz interrupts from the real-time clock;

  • raise msg_qbytes limit for a System V message queue above the limit in /proc/sys/kernel/msgmnb (see msgop(2) and msgctl(2));

  • allow the RLIMIT_NOFILE resource limit on the number of “in-flight” file descriptors to be bypassed when passing file descriptors to another process via a UNIX domain socket (see unix(7));

  • override the /proc/sys/fs/pipe-size-max limit when setting the capacity of a pipe using the F_SETPIPE_SZ fcntl(2) command;

  • use F_SETPIPE_SZ to increase the capacity of a pipe above the limit specified by /proc/sys/fs/pipe-max-size;

  • override /proc/sys/fs/mqueue/queues_max, /proc/sys/fs/mqueue/msg_max, and /proc/sys/fs/mqueue/msgsize_max limits when creating POSIX message queues (see mq_overview(7));

  • employ the prctl(2) PR_SET_MM operation;

  • set /proc/pid/oom_score_adj to a value lower than the value last set by a process with CAP_SYS_RESOURCE.

CAP_SYS_TIME
Set system clock (settimeofday(2), stime(2), adjtimex(2)); set real-time (hardware) clock.

CAP_SYS_TTY_CONFIG
Use vhangup(2); employ various privileged ioctl(2) operations on virtual terminals.

CAP_SYSLOG (since Linux 2.6.37)

  • Perform privileged syslog(2) operations. See syslog(2) for information on which operations require privilege.

  • View kernel addresses exposed via /proc and other interfaces when /proc/sys/kernel/kptr_restrict has the value 1. (See the discussion of the kptr_restrict in proc(5).)

CAP_WAKE_ALARM (since Linux 3.0)
Trigger something that will wake up the system (set CLOCK_REALTIME_ALARM and CLOCK_BOOTTIME_ALARM timers).

Past and current implementation

A full implementation of capabilities requires that:

  • For all privileged operations, the kernel must check whether the thread has the required capability in its effective set.

  • The kernel must provide system calls allowing a thread’s capability sets to be changed and retrieved.

  • The filesystem must support attaching capabilities to an executable file, so that a process gains those capabilities when the file is executed.

Before Linux 2.6.24, only the first two of these requirements are met; since Linux 2.6.24, all three requirements are met.

Notes to kernel developers

When adding a new kernel feature that should be governed by a capability, consider the following points.

  • The goal of capabilities is divide the power of superuser into pieces, such that if a program that has one or more capabilities is compromised, its power to do damage to the system would be less than the same program running with root privilege.

  • You have the choice of either creating a new capability for your new feature, or associating the feature with one of the existing capabilities. In order to keep the set of capabilities to a manageable size, the latter option is preferable, unless there are compelling reasons to take the former option. (There is also a technical limit: the size of capability sets is currently limited to 64 bits.)

  • To determine which existing capability might best be associated with your new feature, review the list of capabilities above in order to find a “silo” into which your new feature best fits. One approach to take is to determine if there are other features requiring capabilities that will always be used along with the new feature. If the new feature is useless without these other features, you should use the same capability as the other features.

  • Don’t choose CAP_SYS_ADMIN if you can possibly avoid it! A vast proportion of existing capability checks are associated with this capability (see the partial list above). It can plausibly be called “the new root”, since on the one hand, it confers a wide range of powers, and on the other hand, its broad scope means that this is the capability that is required by many privileged programs. Don’t make the problem worse. The only new features that should be associated with CAP_SYS_ADMIN are ones that closely match existing uses in that silo.

  • If you have determined that it really is necessary to create a new capability for your feature, don’t make or name it as a “single-use” capability. Thus, for example, the addition of the highly specific CAP_SYS_PACCT was probably a mistake. Instead, try to identify and name your new capability as a broader silo into which other related future use cases might fit.

Thread capability sets

Each thread has the following capability sets containing zero or more of the above capabilities:

Permitted
This is a limiting superset for the effective capabilities that the thread may assume. It is also a limiting superset for the capabilities that may be added to the inheritable set by a thread that does not have the CAP_SETPCAP capability in its effective set.

If a thread drops a capability from its permitted set, it can never reacquire that capability (unless it execve(2)s either a set-user-ID-root program, or a program whose associated file capabilities grant that capability).

Inheritable
This is a set of capabilities preserved across an execve(2). Inheritable capabilities remain inheritable when executing any program, and inheritable capabilities are added to the permitted set when executing a program that has the corresponding bits set in the file inheritable set.

Because inheritable capabilities are not generally preserved across execve(2) when running as a non-root user, applications that wish to run helper programs with elevated capabilities should consider using ambient capabilities, described below.

Effective
This is the set of capabilities used by the kernel to perform permission checks for the thread.

Bounding (per-thread since Linux 2.6.25)
The capability bounding set is a mechanism that can be used to limit the capabilities that are gained during execve(2).

Since Linux 2.6.25, this is a per-thread capability set. In older kernels, the capability bounding set was a system wide attribute shared by all threads on the system.

For more details, see Capability bounding set below.

Ambient (since Linux 4.3)
This is a set of capabilities that are preserved across an execve(2) of a program that is not privileged. The ambient capability set obeys the invariant that no capability can ever be ambient if it is not both permitted and inheritable.

The ambient capability set can be directly modified using prctl(2). Ambient capabilities are automatically lowered if either of the corresponding permitted or inheritable capabilities is lowered.

Executing a program that changes UID or GID due to the set-user-ID or set-group-ID bits or executing a program that has any file capabilities set will clear the ambient set. Ambient capabilities are added to the permitted set and assigned to the effective set when execve(2) is called. If ambient capabilities cause a process’s permitted and effective capabilities to increase during an execve(2), this does not trigger the secure-execution mode described in ld.so(8).

A child created via fork(2) inherits copies of its parent’s capability sets. For details on how execve(2) affects capabilities, see Transformation of capabilities during execve() below.

Using capset(2), a thread may manipulate its own capability sets; see Programmatically adjusting capability sets below.

Since Linux 3.2, the file /proc/sys/kernel/cap_last_cap exposes the numerical value of the highest capability supported by the running kernel; this can be used to determine the highest bit that may be set in a capability set.

File capabilities

Since Linux 2.6.24, the kernel supports associating capability sets with an executable file using setcap(8). The file capability sets are stored in an extended attribute (see setxattr(2) and xattr(7)) named security.capability. Writing to this extended attribute requires the CAP_SETFCAP capability. The file capability sets, in conjunction with the capability sets of the thread, determine the capabilities of a thread after an execve(2).

The three file capability sets are:

Permitted (formerly known as forced):
These capabilities are automatically permitted to the thread, regardless of the thread’s inheritable capabilities.

Inheritable (formerly known as allowed):
This set is ANDed with the thread’s inheritable set to determine which inheritable capabilities are enabled in the permitted set of the thread after the execve(2).

Effective:
This is not a set, but rather just a single bit. If this bit is set, then during an execve(2) all of the new permitted capabilities for the thread are also raised in the effective set. If this bit is not set, then after an execve(2), none of the new permitted capabilities is in the new effective set.

Enabling the file effective capability bit implies that any file permitted or inheritable capability that causes a thread to acquire the corresponding permitted capability during an execve(2) (see Transformation of capabilities during execve() below) will also acquire that capability in its effective set. Therefore, when assigning capabilities to a file (setcap(8), cap_set_file(3), cap_set_fd(3)), if we specify the effective flag as being enabled for any capability, then the effective flag must also be specified as enabled for all other capabilities for which the corresponding permitted or inheritable flag is enabled.

File capability extended attribute versioning

To allow extensibility, the kernel supports a scheme to encode a version number inside the security.capability extended attribute that is used to implement file capabilities. These version numbers are internal to the implementation, and not directly visible to user-space applications. To date, the following versions are supported:

VFS_CAP_REVISION_1
This was the original file capability implementation, which supported 32-bit masks for file capabilities.

VFS_CAP_REVISION_2 (since Linux 2.6.25)
This version allows for file capability masks that are 64 bits in size, and was necessary as the number of supported capabilities grew beyond 32. The kernel transparently continues to support the execution of files that have 32-bit version 1 capability masks, but when adding capabilities to files that did not previously have capabilities, or modifying the capabilities of existing files, it automatically uses the version 2 scheme (or possibly the version 3 scheme, as described below).

VFS_CAP_REVISION_3 (since Linux 4.14)
Version 3 file capabilities are provided to support namespaced file capabilities (described below).

As with version 2 file capabilities, version 3 capability masks are 64 bits in size. But in addition, the root user ID of namespace is encoded in the security.capability extended attribute. (A namespace’s root user ID is the value that user ID 0 inside that namespace maps to in the initial user namespace.)

Version 3 file capabilities are designed to coexist with version 2 capabilities; that is, on a modern Linux system, there may be some files with version 2 capabilities while others have version 3 capabilities.

Before Linux 4.14, the only kind of file capability extended attribute that could be attached to a file was a VFS_CAP_REVISION_2 attribute. Since Linux 4.14, the version of the security.capability extended attribute that is attached to a file depends on the circumstances in which the attribute was created.

Starting with Linux 4.14, a security.capability extended attribute is automatically created as (or converted to) a version 3 (VFS_CAP_REVISION_3) attribute if both of the following are true:

  • The thread writing the attribute resides in a noninitial user namespace. (More precisely: the thread resides in a user namespace other than the one from which the underlying filesystem was mounted.)

  • The thread has the CAP_SETFCAP capability over the file inode, meaning that (a) the thread has the CAP_SETFCAP capability in its own user namespace; and (b) the UID and GID of the file inode have mappings in the writer’s user namespace.

When a VFS_CAP_REVISION_3 security.capability extended attribute is created, the root user ID of the creating thread’s user namespace is saved in the extended attribute.

By contrast, creating or modifying a security.capability extended attribute from a privileged (CAP_SETFCAP) thread that resides in the namespace where the underlying filesystem was mounted (this normally means the initial user namespace) automatically results in the creation of a version 2 (VFS_CAP_REVISION_2) attribute.

Note that the creation of a version 3 security.capability extended attribute is automatic. That is to say, when a user-space application writes (setxattr(2)) a security.capability attribute in the version 2 format, the kernel will automatically create a version 3 attribute if the attribute is created in the circumstances described above. Correspondingly, when a version 3 security.capability attribute is retrieved (getxattr(2)) by a process that resides inside a user namespace that was created by the root user ID (or a descendant of that user namespace), the returned attribute is (automatically) simplified to appear as a version 2 attribute (i.e., the returned value is the size of a version 2 attribute and does not include the root user ID). These automatic translations mean that no changes are required to user-space tools (e.g., setcap(1) and getcap(1)) in order for those tools to be used to create and retrieve version 3 security.capability attributes.

Note that a file can have either a version 2 or a version 3 security.capability extended attribute associated with it, but not both: creation or modification of the security.capability extended attribute will automatically modify the version according to the circumstances in which the extended attribute is created or modified.

Transformation of capabilities during execve()

During an execve(2), the kernel calculates the new capabilities of the process using the following algorithm:

P'(ambient)     = (file is privileged) ? 0 : P(ambient)
P'(permitted)   = (P(inheritable) & F(inheritable)) |
                  (F(permitted) & P(bounding)) | P'(ambient)
P'(effective)   = F(effective) ? P'(permitted) : P'(ambient)
P'(inheritable) = P(inheritable)    [i.e., unchanged]
P'(bounding)    = P(bounding)       [i.e., unchanged]

where:

P()
denotes the value of a thread capability set before the execve(2)

P’()
denotes the value of a thread capability set after the execve(2)

F()
denotes a file capability set

Note the following details relating to the above capability transformation rules:

  • The ambient capability set is present only since Linux 4.3. When determining the transformation of the ambient set during execve(2), a privileged file is one that has capabilities or has the set-user-ID or set-group-ID bit set.

  • Prior to Linux 2.6.25, the bounding set was a system-wide attribute shared by all threads. That system-wide value was employed to calculate the new permitted set during execve(2) in the same manner as shown above for P(bounding).

Note: during the capability transitions described above, file capabilities may be ignored (treated as empty) for the same reasons that the set-user-ID and set-group-ID bits are ignored; see execve(2). File capabilities are similarly ignored if the kernel was booted with the no_file_caps option.

Note: according to the rules above, if a process with nonzero user IDs performs an execve(2) then any capabilities that are present in its permitted and effective sets will be cleared. For the treatment of capabilities when a process with a user ID of zero performs an execve(2), see Capabilities and execution of programs by root below.

Safety checking for capability-dumb binaries

A capability-dumb binary is an application that has been marked to have file capabilities, but has not been converted to use the libcap(3) API to manipulate its capabilities. (In other words, this is a traditional set-user-ID-root program that has been switched to use file capabilities, but whose code has not been modified to understand capabilities.) For such applications, the effective capability bit is set on the file, so that the file permitted capabilities are automatically enabled in the process effective set when executing the file. The kernel recognizes a file which has the effective capability bit set as capability-dumb for the purpose of the check described here.

When executing a capability-dumb binary, the kernel checks if the process obtained all permitted capabilities that were specified in the file permitted set, after the capability transformations described above have been performed. (The typical reason why this might not occur is that the capability bounding set masked out some of the capabilities in the file permitted set.) If the process did not obtain the full set of file permitted capabilities, then execve(2) fails with the error EPERM. This prevents possible security risks that could arise when a capability-dumb application is executed with less privilege than it needs. Note that, by definition, the application could not itself recognize this problem, since it does not employ the libcap(3) API.

Capabilities and execution of programs by root

In order to mirror traditional UNIX semantics, the kernel performs special treatment of file capabilities when a process with UID 0 (root) executes a program and when a set-user-ID-root program is executed.

After having performed any changes to the process effective ID that were triggered by the set-user-ID mode bit of the binary—e.g., switching the effective user ID to 0 (root) because a set-user-ID-root program was executed—the kernel calculates the file capability sets as follows:

  1. If the real or effective user ID of the process is 0 (root), then the file inheritable and permitted sets are ignored; instead they are notionally considered to be all ones (i.e., all capabilities enabled). (There is one exception to this behavior, described in Set-user-ID-root programs that have file capabilities below.)

  2. If the effective user ID of the process is 0 (root) or the file effective bit is in fact enabled, then the file effective bit is notionally defined to be one (enabled).

These notional values for the file’s capability sets are then used as described above to calculate the transformation of the process’s capabilities during execve(2).

Thus, when a process with nonzero UIDs execve(2)s a set-user-ID-root program that does not have capabilities attached, or when a process whose real and effective UIDs are zero execve(2)s a program, the calculation of the process’s new permitted capabilities simplifies to:

P'(permitted)   = P(inheritable) | P(bounding)
P'(effective)   = P'(permitted)

Consequently, the process gains all capabilities in its permitted and effective capability sets, except those masked out by the capability bounding set. (In the calculation of P’(permitted), the P’(ambient) term can be simplified away because it is by definition a proper subset of P(inheritable).)

The special treatments of user ID 0 (root) described in this subsection can be disabled using the securebits mechanism described below.

Set-user-ID-root programs that have file capabilities

There is one exception to the behavior described in Capabilities and execution of programs by root above. If (a) the binary that is being executed has capabilities attached and (b) the real user ID of the process is not 0 (root) and (c) the effective user ID of the process is 0 (root), then the file capability bits are honored (i.e., they are not notionally considered to be all ones). The usual way in which this situation can arise is when executing a set-UID-root program that also has file capabilities. When such a program is executed, the process gains just the capabilities granted by the program (i.e., not all capabilities, as would occur when executing a set-user-ID-root program that does not have any associated file capabilities).

Note that one can assign empty capability sets to a program file, and thus it is possible to create a set-user-ID-root program that changes the effective and saved set-user-ID of the process that executes the program to 0, but confers no capabilities to that process.

Capability bounding set

The capability bounding set is a security mechanism that can be used to limit the capabilities that can be gained during an execve(2). The bounding set is used in the following ways:

  • During an execve(2), the capability bounding set is ANDed with the file permitted capability set, and the result of this operation is assigned to the thread’s permitted capability set. The capability bounding set thus places a limit on the permitted capabilities that may be granted by an executable file.

  • (Since Linux 2.6.25) The capability bounding set acts as a limiting superset for the capabilities that a thread can add to its inheritable set using capset(2). This means that if a capability is not in the bounding set, then a thread can’t add this capability to its inheritable set, even if it was in its permitted capabilities, and thereby cannot have this capability preserved in its permitted set when it execve(2)s a file that has the capability in its inheritable set.

Note that the bounding set masks the file permitted capabilities, but not the inheritable capabilities. If a thread maintains a capability in its inheritable set that is not in its bounding set, then it can still gain that capability in its permitted set by executing a file that has the capability in its inheritable set.

Depending on the kernel version, the capability bounding set is either a system-wide attribute, or a per-process attribute.

Capability bounding set from Linux 2.6.25 onward

From Linux 2.6.25, the capability bounding set is a per-thread attribute. (The system-wide capability bounding set described below no longer exists.)

The bounding set is inherited at fork(2) from the thread’s parent, and is preserved across an execve(2).

A thread may remove capabilities from its capability bounding set using the prctl(2) PR_CAPBSET_DROP operation, provided it has the CAP_SETPCAP capability. Once a capability has been dropped from the bounding set, it cannot be restored to that set. A thread can determine if a capability is in its bounding set using the prctl(2) PR_CAPBSET_READ operation.

Removing capabilities from the bounding set is supported only if file capabilities are compiled into the kernel. Before Linux 2.6.33, file capabilities were an optional feature configurable via the CONFIG_SECURITY_FILE_CAPABILITIES option. Since Linux 2.6.33, the configuration option has been removed and file capabilities are always part of the kernel. When file capabilities are compiled into the kernel, the init process (the ancestor of all processes) begins with a full bounding set. If file capabilities are not compiled into the kernel, then init begins with a full bounding set minus CAP_SETPCAP, because this capability has a different meaning when there are no file capabilities.

Removing a capability from the bounding set does not remove it from the thread’s inheritable set. However it does prevent the capability from being added back into the thread’s inheritable set in the future.

Capability bounding set prior to Linux 2.6.25

Before Linux 2.6.25, the capability bounding set is a system-wide attribute that affects all threads on the system. The bounding set is accessible via the file /proc/sys/kernel/cap-bound. (Confusingly, this bit mask parameter is expressed as a signed decimal number in /proc/sys/kernel/cap-bound.)

Only the init process may set capabilities in the capability bounding set; other than that, the superuser (more precisely: a process with the CAP_SYS_MODULE capability) may only clear capabilities from this set.

On a standard system the capability bounding set always masks out the CAP_SETPCAP capability. To remove this restriction (dangerous!), modify the definition of CAP_INIT_EFF_SET in include/linux/capability.h and rebuild the kernel.

The system-wide capability bounding set feature was added to Linux 2.2.11.

Effect of user ID changes on capabilities

To preserve the traditional semantics for transitions between 0 and nonzero user IDs, the kernel makes the following changes to a thread’s capability sets on changes to the thread’s real, effective, saved set, and filesystem user IDs (using setuid(2), setresuid(2), or similar):

  • If one or more of the real, effective, or saved set user IDs was previously 0, and as a result of the UID changes all of these IDs have a nonzero value, then all capabilities are cleared from the permitted, effective, and ambient capability sets.

  • If the effective user ID is changed from 0 to nonzero, then all capabilities are cleared from the effective set.

  • If the effective user ID is changed from nonzero to 0, then the permitted set is copied to the effective set.

  • If the filesystem user ID is changed from 0 to nonzero (see setfsuid(2)), then the following capabilities are cleared from the effective set: CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH, CAP_FOWNER, CAP_FSETID, CAP_LINUX_IMMUTABLE (since Linux 2.6.30), CAP_MAC_OVERRIDE, and CAP_MKNOD (since Linux 2.6.30). If the filesystem UID is changed from nonzero to 0, then any of these capabilities that are enabled in the permitted set are enabled in the effective set.

If a thread that has a 0 value for one or more of its user IDs wants to prevent its permitted capability set being cleared when it resets all of its user IDs to nonzero values, it can do so using the SECBIT_KEEP_CAPS securebits flag described below.

Programmatically adjusting capability sets

A thread can retrieve and change its permitted, effective, and inheritable capability sets using the capget(2) and capset(2) system calls. However, the use of cap_get_proc(3) and cap_set_proc(3), both provided in the libcap package, is preferred for this purpose. The following rules govern changes to the thread capability sets:

  • If the caller does not have the CAP_SETPCAP capability, the new inheritable set must be a subset of the combination of the existing inheritable and permitted sets.

  • (Since Linux 2.6.25) The new inheritable set must be a subset of the combination of the existing inheritable set and the capability bounding set.

  • The new permitted set must be a subset of the existing permitted set (i.e., it is not possible to acquire permitted capabilities that the thread does not currently have).

  • The new effective set must be a subset of the new permitted set.

The securebits flags: establishing a capabilities-only environment

Starting with Linux 2.6.26, and with a kernel in which file capabilities are enabled, Linux implements a set of per-thread securebits flags that can be used to disable special handling of capabilities for UID 0 (root). These flags are as follows:

SECBIT_KEEP_CAPS
Setting this flag allows a thread that has one or more 0 UIDs to retain capabilities in its permitted set when it switches all of its UIDs to nonzero values. If this flag is not set, then such a UID switch causes the thread to lose all permitted capabilities. This flag is always cleared on an execve(2).

Note that even with the SECBIT_KEEP_CAPS flag set, the effective capabilities of a thread are cleared when it switches its effective UID to a nonzero value. However, if the thread has set this flag and its effective UID is already nonzero, and the thread subsequently switches all other UIDs to nonzero values, then the effective capabilities will not be cleared.

The setting of the SECBIT_KEEP_CAPS flag is ignored if the SECBIT_NO_SETUID_FIXUP flag is set. (The latter flag provides a superset of the effect of the former flag.)

This flag provides the same functionality as the older prctl(2) PR_SET_KEEPCAPS operation.

SECBIT_NO_SETUID_FIXUP
Setting this flag stops the kernel from adjusting the process’s permitted, effective, and ambient capability sets when the thread’s effective and filesystem UIDs are switched between zero and nonzero values. See Effect of user ID changes on capabilities above.

SECBIT_NOROOT
If this bit is set, then the kernel does not grant capabilities when a set-user-ID-root program is executed, or when a process with an effective or real UID of 0 calls execve(2). (See Capabilities and execution of programs by root above.)

SECBIT_NO_CAP_AMBIENT_RAISE
Setting this flag disallows raising ambient capabilities via the prctl(2) PR_CAP_AMBIENT_RAISE operation.

Each of the above “base” flags has a companion “locked” flag. Setting any of the “locked” flags is irreversible, and has the effect of preventing further changes to the corresponding “base” flag. The locked flags are: SECBIT_KEEP_CAPS_LOCKED, SECBIT_NO_SETUID_FIXUP_LOCKED, SECBIT_NOROOT_LOCKED, and SECBIT_NO_CAP_AMBIENT_RAISE_LOCKED.

The securebits flags can be modified and retrieved using the prctl(2) PR_SET_SECUREBITS and PR_GET_SECUREBITS operations. The CAP_SETPCAP capability is required to modify the flags. Note that the SECBIT_* constants are available only after including the <linux/securebits.h> header file.

The securebits flags are inherited by child processes. During an execve(2), all of the flags are preserved, except SECBIT_KEEP_CAPS which is always cleared.

An application can use the following call to lock itself, and all of its descendants, into an environment where the only way of gaining capabilities is by executing a program with associated file capabilities:

prctl(PR_SET_SECUREBITS,
        /* SECBIT_KEEP_CAPS off */
        SECBIT_KEEP_CAPS_LOCKED |
        SECBIT_NO_SETUID_FIXUP |
        SECBIT_NO_SETUID_FIXUP_LOCKED |
        SECBIT_NOROOT |
        SECBIT_NOROOT_LOCKED);
        /* Setting/locking SECBIT_NO_CAP_AMBIENT_RAISE
           is not required */

Per-user-namespace “set-user-ID-root” programs

A set-user-ID program whose UID matches the UID that created a user namespace will confer capabilities in the process’s permitted and effective sets when executed by any process inside that namespace or any descendant user namespace.

The rules about the transformation of the process’s capabilities during the execve(2) are exactly as described in Transformation of capabilities during execve() and Capabilities and execution of programs by root above, with the difference that, in the latter subsection, “root” is the UID of the creator of the user namespace.

Namespaced file capabilities

Traditional (i.e., version 2) file capabilities associate only a set of capability masks with a binary executable file. When a process executes a binary with such capabilities, it gains the associated capabilities (within its user namespace) as per the rules described in Transformation of capabilities during execve() above.

Because version 2 file capabilities confer capabilities to the executing process regardless of which user namespace it resides in, only privileged processes are permitted to associate capabilities with a file. Here, “privileged” means a process that has the CAP_SETFCAP capability in the user namespace where the filesystem was mounted (normally the initial user namespace). This limitation renders file capabilities useless for certain use cases. For example, in user-namespaced containers, it can be desirable to be able to create a binary that confers capabilities only to processes executed inside that container, but not to processes that are executed outside the container.

Linux 4.14 added so-called namespaced file capabilities to support such use cases. Namespaced file capabilities are recorded as version 3 (i.e., VFS_CAP_REVISION_3) security.capability extended attributes. Such an attribute is automatically created in the circumstances described in File capability extended attribute versioning above. When a version 3 security.capability extended attribute is created, the kernel records not just the capability masks in the extended attribute, but also the namespace root user ID.

As with a binary that has VFS_CAP_REVISION_2 file capabilities, a binary with VFS_CAP_REVISION_3 file capabilities confers capabilities to a process during execve(). However, capabilities are conferred only if the binary is executed by a process that resides in a user namespace whose UID 0 maps to the root user ID that is saved in the extended attribute, or when executed by a process that resides in a descendant of such a namespace.

Interaction with user namespaces

For further information on the interaction of capabilities and user namespaces, see user_namespaces(7).

STANDARDS

No standards govern capabilities, but the Linux capability implementation is based on the withdrawn POSIX.1e draft standard.

NOTES

When attempting to strace(1) binaries that have capabilities (or set-user-ID-root binaries), you may find the -u <username> option useful. Something like:

$ sudo strace -o trace.log -u ceci ./myprivprog

From Linux 2.5.27 to Linux 2.6.26, capabilities were an optional kernel component, and could be enabled/disabled via the CONFIG_SECURITY_CAPABILITIES kernel configuration option.

The /proc/pid/task/TID/status file can be used to view the capability sets of a thread. The /proc/pid/status file shows the capability sets of a process’s main thread. Before Linux 3.8, nonexistent capabilities were shown as being enabled (1) in these sets. Since Linux 3.8, all nonexistent capabilities (above CAP_LAST_CAP) are shown as disabled (0).

The libcap package provides a suite of routines for setting and getting capabilities that is more comfortable and less likely to change than the interface provided by capset(2) and capget(2). This package also provides the setcap(8) and getcap(8) programs. It can be found at
.

Before Linux 2.6.24, and from Linux 2.6.24 to Linux 2.6.32 if file capabilities are not enabled, a thread with the CAP_SETPCAP capability can manipulate the capabilities of threads other than itself. However, this is only theoretically possible, since no thread ever has CAP_SETPCAP in either of these cases:

  • In the pre-2.6.25 implementation the system-wide capability bounding set, /proc/sys/kernel/cap-bound, always masks out the CAP_SETPCAP capability, and this can not be changed without modifying the kernel source and rebuilding the kernel.

  • If file capabilities are disabled (i.e., the kernel CONFIG_SECURITY_FILE_CAPABILITIES option is disabled), then init starts out with the CAP_SETPCAP capability removed from its per-process bounding set, and that bounding set is inherited by all other processes created on the system.

SEE ALSO

capsh(1), setpriv(1), prctl(2), setfsuid(2), cap_clear(3), cap_copy_ext(3), cap_from_text(3), cap_get_file(3), cap_get_proc(3), cap_init(3), capgetp(3), capsetp(3), libcap(3), proc(5), credentials(7), pthreads(7), user_namespaces(7), captest(8), filecap(8), getcap(8), getpcaps(8), netcap(8), pscap(8), setcap(8)

include/linux/capability.h in the Linux kernel source tree

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

256 - Linux cli command iso-8859-6

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso-8859-6 and provides detailed information about the command iso-8859-6, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso-8859-6.

NAME 🖥️ iso-8859-6 🖥️

6 - ISO/IEC 8859-6 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-6 encodes the characters used in the Arabic language.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-6 characters

The following table displays the characters in ISO/IEC 8859-6 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-6 lacks the glyphs required for many related languages, such as Urdu and Persian (Farsi).

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

257 - Linux cli command EVP_PKEY-HMACssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_PKEY-HMACssl and provides detailed information about the command EVP_PKEY-HMACssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_PKEY-HMACssl.

NAME 🖥️ EVP_PKEY-HMACssl 🖥️

HMAC, EVP_KEYMGMT-HMAC, EVP_PKEY-Siphash, EVP_KEYMGMT-Siphash, EVP_PKEY-Poly1305, EVP_KEYMGMT-Poly1305, EVP_PKEY-CMAC, EVP_KEYMGMT-CMAC - EVP_PKEY legacy MAC keytypes and algorithm support

DESCRIPTION

The HMAC and CMAC key types are implemented in OpenSSL’s default and FIPS providers. Additionally the Siphash and Poly1305 key types are implemented in the default provider. Performing MAC operations via an EVP_PKEY is considered legacy and are only available for backwards compatibility purposes and for a restricted set of algorithms. The preferred way of performing MAC operations is via the EVP_MAC APIs. See EVP_MAC_init (3).

For further details on using EVP_PKEY based MAC keys see EVP_SIGNATURE-HMAC (7), EVP_SIGNATURE-Siphash (7), EVP_SIGNATURE-Poly1305 (7) or EVP_SIGNATURE-CMAC (7).

Common MAC parameters

All the MAC keytypes support the following parameters.

“priv” (OSSL_PKEY_PARAM_PRIV_KEY) <octet string>
The MAC key value.

“properties” (OSSL_PKEY_PARAM_PROPERTIES) <UTF8 string>
A property query string to be used when any algorithms are fetched.

CMAC parameters

As well as the parameters described above, the CMAC keytype additionally supports the following parameters.

“cipher” (OSSL_PKEY_PARAM_CIPHER) <UTF8 string>
The name of a cipher to be used when generating the MAC.

“engine” (OSSL_PKEY_PARAM_ENGINE) <UTF8 string>
The name of an engine to be used for the specified cipher (if any).

Common MAC key generation parameters

MAC key generation is unusual in that no new key is actually generated. Instead a new provider side key object is created with the supplied raw key value. This is done for backwards compatibility with previous versions of OpenSSL.

“priv” (OSSL_PKEY_PARAM_PRIV_KEY) <octet string>
The MAC key value.

CMAC key generation parameters

In addition to the common MAC key generation parameters, the CMAC key generation additionally recognises the following.

“cipher” (OSSL_PKEY_PARAM_CIPHER) <UTF8 string>
The name of a cipher to be used when generating the MAC.

SEE ALSO

EVP_KEYMGMT (3), EVP_PKEY (3), provider-keymgmt (7)

COPYRIGHT

Copyright 2020 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

258 - Linux cli command SET_CONSTRAINTS

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command SET_CONSTRAINTS and provides detailed information about the command SET_CONSTRAINTS, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the SET_CONSTRAINTS.

NAME 🖥️ SET_CONSTRAINTS 🖥️

set constraint check timing for the current transaction

SYNOPSIS

SET CONSTRAINTS { ALL | name [, ...] } { DEFERRED | IMMEDIATE }

DESCRIPTION

SET CONSTRAINTS sets the behavior of constraint checking within the current transaction. IMMEDIATE constraints are checked at the end of each statement. DEFERRED constraints are not checked until transaction commit. Each constraint has its own IMMEDIATE or DEFERRED mode.

Upon creation, a constraint is given one of three characteristics: DEFERRABLE INITIALLY DEFERRED, DEFERRABLE INITIALLY IMMEDIATE, or NOT DEFERRABLE. The third class is always IMMEDIATE and is not affected by the SET CONSTRAINTS command. The first two classes start every transaction in the indicated mode, but their behavior can be changed within a transaction by SET CONSTRAINTS.

SET CONSTRAINTS with a list of constraint names changes the mode of just those constraints (which must all be deferrable). Each constraint name can be schema-qualified. The current schema search path is used to find the first matching name if no schema name is specified. SET CONSTRAINTS ALL changes the mode of all deferrable constraints.

When SET CONSTRAINTS changes the mode of a constraint from DEFERRED to IMMEDIATE, the new mode takes effect retroactively: any outstanding data modifications that would have been checked at the end of the transaction are instead checked during the execution of the SET CONSTRAINTS command. If any such constraint is violated, the SET CONSTRAINTS fails (and does not change the constraint mode). Thus, SET CONSTRAINTS can be used to force checking of constraints to occur at a specific point in a transaction.

Currently, only UNIQUE, PRIMARY KEY, REFERENCES (foreign key), and EXCLUDE constraints are affected by this setting. NOT NULL and CHECK constraints are always checked immediately when a row is inserted or modified (not at the end of the statement). Uniqueness and exclusion constraints that have not been declared DEFERRABLE are also checked immediately.

The firing of triggers that are declared as “constraint triggers” is also controlled by this setting — they fire at the same time that the associated constraint should be checked.

NOTES

Because PostgreSQL does not require constraint names to be unique within a schema (but only per-table), it is possible that there is more than one match for a specified constraint name. In this case SET CONSTRAINTS will act on all matches. For a non-schema-qualified name, once a match or matches have been found in some schema in the search path, schemas appearing later in the path are not searched.

This command only alters the behavior of constraints within the current transaction. Issuing this outside of a transaction block emits a warning and otherwise has no effect.

COMPATIBILITY

This command complies with the behavior defined in the SQL standard, except for the limitation that, in PostgreSQL, it does not apply to NOT NULL and CHECK constraints. Also, PostgreSQL checks non-deferrable uniqueness constraints immediately, not at end of statement as the standard would suggest.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

259 - Linux cli command persistent-keyring

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command persistent-keyring and provides detailed information about the command persistent-keyring, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the persistent-keyring.

NAME 🖥️ persistent-keyring 🖥️

keyring - per-user persistent keyring

DESCRIPTION

The persistent keyring is a keyring used to anchor keys on behalf of a user. Each UID the kernel deals with has its own persistent keyring that is shared between all threads owned by that UID. The persistent keyring has a name (description) of the form _persistent.<UID> where <UID> is the user ID of the corresponding user.

The persistent keyring may not be accessed directly, even by processes with the appropriate UID. Instead, it must first be linked to one of a process’s keyrings, before that keyring can access the persistent keyring by virtue of its possessor permits. This linking is done with the keyctl_get_persistent(3) function.

If a persistent keyring does not exist when it is accessed by the keyctl_get_persistent(3) operation, it will be automatically created.

Each time the keyctl_get_persistent(3) operation is performed, the persistent keyring’s expiration timer is reset to the value in:

/proc/sys/kernel/keys/persistent_keyring_expiry

Should the timeout be reached, the persistent keyring will be removed and everything it pins can then be garbage collected. The keyring will then be re-created on a subsequent call to keyctl_get_persistent(3).

The persistent keyring is not directly searched by request_key(2); it is searched only if it is linked into one of the keyrings that is searched by request_key(2).

The persistent keyring is independent of clone(2), fork(2), vfork(2), execve(2), and _exit(2). It persists until its expiration timer triggers, at which point it is garbage collected. This allows the persistent keyring to carry keys beyond the life of the kernel’s record of the corresponding UID (the destruction of which results in the destruction of the user-keyring(7) and the user-session-keyring(7)). The persistent keyring can thus be used to hold authentication tokens for processes that run without user interaction, such as programs started by cron(8).

The persistent keyring is used to store UID-specific objects that themselves have limited lifetimes (e.g., kerberos tokens). If those tokens cease to be used (i.e., the persistent keyring is not accessed), then the timeout of the persistent keyring ensures that the corresponding objects are automatically discarded.

Special operations

The keyutils library provides the keyctl_get_persistent(3) function for manipulating persistent keyrings. (This function is an interface to the keyctl(2) KEYCTL_GET_PERSISTENT operation.) This operation allows the calling thread to get the persistent keyring corresponding to its own UID or, if the thread has the CAP_SETUID capability, the persistent keyring corresponding to some other UID in the same user namespace.

NOTES

Each user namespace owns a keyring called .persistent_register that contains links to all of the persistent keys in that namespace. (The .persistent_register keyring can be seen when reading the contents of the /proc/keys file for the UID 0 in the namespace.) The keyctl_get_persistent(3) operation looks for a key with a name of the form *_persistent.*UID in that keyring, creates the key if it does not exist, and links it into the keyring.

SEE ALSO

keyctl(1), keyctl(3), keyctl_get_persistent(3), keyrings(7), process-keyring(7), session-keyring(7), thread-keyring(7), user-keyring(7), user-session-keyring(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

260 - Linux cli command go-testflag

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command go-testflag and provides detailed information about the command go-testflag, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the go-testflag.

NAME 🖥️ go-testflag 🖥️

tool for managing Go source code

DESCRIPTION

The ‘go test’ command takes both flags that apply to ‘go test’ itself and flags that apply to the resulting test binary.

Several of the flags control profiling and write an execution profile suitable for “go tool pprof”; run “go tool pprof -h” for more information. The –alloc_space, –alloc_objects, and –show_bytes options of pprof control how the information is presented.

The following flags are recognized by the ‘go test’ command and control the execution of any test:

-bench* regexp*
Run only those benchmarks matching a regular expression. By default, no benchmarks are run. To run all benchmarks, use ‘-bench .’ or ‘-bench=.’. The regular expression is split by unbracketed slash (/) characters into a sequence of regular expressions, and each part of a benchmark’s identifier must match the corresponding element in the sequence, if any. Possible parents of matches are run with b.N=1 to identify sub-benchmarks. For example, given -bench=X/Y, top-level benchmarks matching X are run with b.N=1 to find any sub-benchmarks matching Y, which are then run in full.

-benchtime* t*
Run enough iterations of each benchmark to take t, specified as a time.Duration (for example, -benchtime 1h30s).
The default is 1 second (1s).
The special syntax Nx means to run the benchmark N times (for example, -benchtime 100x).

-count* n*
Run each test, benchmark, and fuzz seed n times (default 1).
If -cpu is set, run n times for each GOMAXPROCS value.
Examples are always run once. -count does not apply to fuzz tests matched by -fuzz.

-cover
Enable coverage analysis.
Note that because coverage works by annotating the source code before compilation, compilation and test failures with coverage enabled may report line numbers that don’t correspond to the original sources.

-covermode set,count,atomic
Set the mode for coverage analysis for the package[s] being tested. The default is “set” unless -race is enabled, in which case it is “atomic”.
The values: set: bool: does this statement run? count: int: how many times does this statement run? atomic: int: count, but correct in multithreaded tests; significantly more expensive.
Sets -cover.

**-coverpkg pattern1,pattern2,**pattern3
Apply coverage analysis in each test to packages matching the patterns. The default is for each test to analyze only the package being tested.
See ‘go help packages’ for a description of package patterns.
Sets -cover.

**-cpu 1,2,**4
Specify a list of GOMAXPROCS values for which the tests, benchmarks or fuzz tests should be executed. The default is the current value of GOMAXPROCS. -cpu does not apply to fuzz tests matched by -fuzz.

-failfast
Do not start new tests after the first test failure.

-fuzz* regexp*
Run the fuzz test matching the regular expression. When specified, the command line argument must match exactly one package within the main module, and regexp must match exactly one fuzz test within that package. Fuzzing will occur after tests, benchmarks, seed corpora of other fuzz tests, and examples have completed. See the Fuzzing section of the testing package documentation for details.

-fuzztime* t*
Run enough iterations of the fuzz target during fuzzing to take t, specified as a time.Duration (for example, -fuzztime 1h30s). The default is to run forever.
The special syntax Nx means to run the fuzz target N times (for example, -fuzztime 1000x).

-fuzzminimizetime* t*
Run enough iterations of the fuzz target during each minimization attempt to take t, as specified as a time.Duration (for example, -fuzzminimizetime 30s). The default is 60s.
The special syntax Nx means to run the fuzz target N times (for example, -fuzzminimizetime 100x).

-json
Log verbose output and test results in JSON. This presents the same information as the -v flag in a machine-readable format.

-list* regexp*
List tests, benchmarks, fuzz tests, or examples matching the regular expression. No tests, benchmarks, fuzz tests, or examples will be run. This will only list top-level tests. No subtest or subbenchmarks will be shown.

-parallel* n*
Allow parallel execution of test functions that call t.Parallel, and fuzz targets that call t.Parallel when running the seed corpus. The value of this flag is the maximum number of tests to run simultaneously.
While fuzzing, the value of this flag is the maximum number of subprocesses that may call the fuzz function simultaneously, regardless of whether T.Parallel is called.
By default, -parallel is set to the value of GOMAXPROCS. Setting -parallel to values higher than GOMAXPROCS may cause degraded performance due to CPU contention, especially when fuzzing. Note that -parallel only applies within a single test binary. The ‘go test’ command may run tests for different packages in parallel as well, according to the setting of the -p flag (see ‘go help build’).

-run* regexp*
Run only those tests, examples, and fuzz tests matching the regular expression. For tests, the regular expression is split by unbracketed slash (/) characters into a sequence of regular expressions, and each part of a test’s identifier must match the corresponding element in the sequence, if any. Note that possible parents of matches are run too, so that -run=X/Y matches and runs and reports the result of all tests matching X, even those without sub-tests matching Y, because it must run them to look for those sub-tests.

-short
Tell long-running tests to shorten their run time. It is off by default but set during all.bash so that installing the Go tree can run a sanity check but not spend time running exhaustive tests.

**-shuffle **off,on,N
Randomize the execution order of tests and benchmarks. It is off by default. If -shuffle is set to on, then it will seed the randomizer using the system clock. If -shuffle is set to an integer N, then N will be used as the seed value. In both cases, the seed will be reported for reproducibility.

-timeout* d*
If a test binary runs longer than duration d, panic.
If d is 0, the timeout is disabled.
The default is 10 minutes (10m).

-v
Verbose output: log all tests as they are run. Also print all text from Log and Logf calls even if the test succeeds.

-vet* list*
Configure the invocation of “go vet” during “go test” to use the comma-separated list of vet checks.
If list is empty, “go test” runs “go vet” with a curated list of checks believed to be always worth addressing.
If list is “off”, “go test” does not run “go vet” at all.

The following flags are also recognized by ‘go test’ and can be used to profile the tests during execution:

-benchmem
Print memory allocation statistics for benchmarks.

-blockprofile block.out
Write a goroutine blocking profile to the specified file when all tests are complete.
Writes test binary as -c would.

-blockprofilerate* n*
Control the detail provided in goroutine blocking profiles by calling runtime.SetBlockProfileRate with n.
See ‘go doc runtime.SetBlockProfileRate’.
The profiler aims to sample, on average, one blocking event every n nanoseconds the program spends blocked. By default, if -test.blockprofile is set without this flag, all blocking events are recorded, equivalent to -test.blockprofilerate=1.

-coverprofile cover.out
Write a coverage profile to the file after all tests have passed.
Sets -cover.

-cpuprofile cpu.out
Write a CPU profile to the specified file before exiting.
Writes test binary as -c would.

-memprofile mem.out
Write an allocation profile to the file after all tests have passed.
Writes test binary as -c would.

-memprofilerate* n*
Enable more precise (and expensive) memory allocation profiles by setting runtime.MemProfileRate. See ‘go doc runtime.MemProfileRate’. To profile all memory allocations, use -test.memprofilerate=1.

-mutexprofile mutex.out
Write a mutex contention profile to the specified file when all tests are complete.
Writes test binary as -c would.

-mutexprofilefraction* n*
Sample 1 in n stack traces of goroutines holding a contended mutex.

-outputdir directory
Place output files from profiling in the specified directory, by default the directory in which “go test” is running.

-trace trace.out
Write an execution trace to the specified file before exiting.

Each of these flags is also recognized with an optional ‘test.’ prefix, as in -test.v. When invoking the generated test binary (the result of ‘go test -c’) directly, however, the prefix is mandatory.

The ‘go test’ command rewrites or removes recognized flags, as appropriate, both before and after the optional package list, before invoking the test binary.

For instance, the command

go test -v -myflag testdata -cpuprofile=prof.out -x

will compile the test binary and then run it as

pkg.test -test.v -myflag testdata -test.cpuprofile=prof.out

(The -x flag is removed because it applies only to the go command’s execution, not to the test itself.)

The test flags that generate profiles (other than for coverage) also leave the test binary in pkg.test for use when analyzing the profiles.

When ‘go test’ runs a test binary, it does so from within the corresponding package’s source code directory. Depending on the test, it may be necessary to do the same when invoking a generated test binary directly. Because that directory may be located within the module cache, which may be read-only and is verified by checksums, the test must not write to it or any other directory within the module unless explicitly requested by the user (such as with the -fuzz flag, which writes failures to testdata/fuzz).

The command-line package list, if present, must appear before any flag not known to the go test command. Continuing the example above, the package list would have to appear before -myflag, but could appear on either side of -v.

When ‘go test’ runs in package list mode, ‘go test’ caches successful package test results to avoid unnecessary repeated running of tests. To disable test caching, use any test flag or argument other than the cacheable flags. The idiomatic way to disable test caching explicitly is to use -count=1.

To keep an argument for a test binary from being interpreted as a known flag or a package name, use -args (see ‘go help test’) which passes the remainder of the command line through to the test binary uninterpreted and unaltered.

For instance, the command

go test -v -args -x -v

will compile the test binary and then run it as

pkg.test -test.v -x -v

Similarly,

go test -args math

will compile the test binary and then run it as

pkg.test math

In the first example, the -x and the second -v are passed through to the test binary unchanged and with no effect on the go command itself. In the second example, the argument math is passed through to the test binary, instead of being interpreted as the package list.

AUTHOR

This manual page was written by Michael Stapelberg <[email protected]> and is maintained by the Debian Go Compiler Team <[email protected]> based on the output of ‘go help testflag’ for the Debian project (and may be used by others).

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

261 - Linux cli command Ed25519ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command Ed25519ssl and provides detailed information about the command Ed25519ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the Ed25519ssl.

NAME 🖥️ Ed25519ssl 🖥️

ED25519, EVP_SIGNATURE-ED448, Ed25519, Ed448 - EVP_PKEY Ed25519 and Ed448 support

DESCRIPTION

The Ed25519 and Ed448 EVP_PKEY implementation supports key generation, one-shot digest-sign and digest-verify using the EdDSA signature scheme described in RFC 8032. It has associated private and public key formats compatible with RFC 8410.

EdDSA Instances

RFC 8032 describes five EdDSA instances: Ed25519, Ed25519ctx, Ed25519ph, Ed448, Ed448ph.

The instances Ed25519, Ed25519ctx, Ed448 are referred to as PureEdDSA schemes. For these three instances, the sign and verify procedures require access to the complete message (not a digest of the message).

The instances Ed25519ph, Ed448ph are referred to as HashEdDSA schemes. For these two instances, the sign and verify procedures do not require access to the complete message; they operate on a hash of the message. For Ed25519ph, the hash function is SHA512. For Ed448ph, the hash function is SHAKE256 with an output length of 512 bits.

The instances Ed25519ctx, Ed25519ph, Ed448, Ed448ph accept an optional context-string as input to sign and verify operations (and for Ed25519ctx, the context-string must be nonempty). For the Ed25519 instance, a nonempty context-string is not permitted.

ED25519 and ED448 Signature Parameters

Two parameters can be set during signing or verification: the EdDSA instance name and the context-string value. They can be set by passing an OSSL_PARAM array to EVP_DigestSignInit_ex().

  • “instance” (OSSL_SIGNATURE_PARAM_INSTANCE) <utf8 string> One of the five strings “Ed25519”, “Ed25519ctx”, “Ed25519ph”, “Ed448”, “Ed448ph”. “Ed25519”, “Ed25519ctx”, “Ed25519ph” are valid only for an Ed25519 EVP_PKEY. “Ed448”, “Ed448ph” are valid only for an Ed448 EVP_PKEY.

  • “context-string” (OSSL_SIGNATURE_PARAM_CONTEXT_STRING) <octet string> A string of octets with length at most 255.

Both of these parameters are optional.

If the instance name is not specified, then the default “Ed25519” or “Ed448” is used.

If a context-string is not specified, then an empty context-string is used.

Note that a message digest name must NOT be specified when signing or verifying.

See EVP_PKEY-X25519 (7) for information related to X25519 and X448 keys.

The following signature parameters can be retrieved using EVP_PKEY_CTX_get_params().

  • “algorithm-id” (OSSL_SIGNATURE_PARAM_ALGORITHM_ID) <octet string>

  • “instance” (OSSL_SIGNATURE_PARAM_INSTANCE) <utf8 string>

  • “context-string” (OSSL_SIGNATURE_PARAM_CONTEXT_STRING) <octet string>

The parameters are described in provider-signature (7).

NOTES

The PureEdDSA instances do not support the streaming mechanism of other signature algorithms using, for example, EVP_DigestUpdate(). The message to sign or verify must be passed using the one-shot EVP_DigestSign() and EVP_DigestVerify() functions.

The HashEdDSA instances do not yet support the streaming mechanisms (so the one-shot functions must be used with HashEdDSA as well).

When calling EVP_DigestSignInit() or EVP_DigestVerifyInit(), the digest type parameter MUST be set to NULL.

Applications wishing to sign certificates (or other structures such as CRLs or certificate requests) using Ed25519 or Ed448 can either use X509_sign() or X509_sign_ctx() in the usual way.

Ed25519 or Ed448 private keys can be set directly using EVP_PKEY_new_raw_private_key (3) or loaded from a PKCS#8 private key file using PEM_read_bio_PrivateKey (3) (or similar function). Completely new keys can also be generated (see the example below). Setting a private key also sets the associated public key.

Ed25519 or Ed448 public keys can be set directly using EVP_PKEY_new_raw_public_key (3) or loaded from a SubjectPublicKeyInfo structure in a PEM file using PEM_read_bio_PUBKEY (3) (or similar function).

Ed25519 and Ed448 can be tested with the openssl-speed (1) application since version 1.1.1. Valid algorithm names are ed25519, ed448 and eddsa. If eddsa is specified, then both Ed25519 and Ed448 are benchmarked.

EXAMPLES

To sign a message using an ED25519 EVP_PKEY structure:

void do_sign(EVP_PKEY *ed_key, unsigned char *msg, size_t msg_len) { size_t sig_len; unsigned char *sig = NULL; EVP_MD_CTX *md_ctx = EVP_MD_CTX_new(); const OSSL_PARAM params[] = { OSSL_PARAM_utf8_string (“instance”, “Ed25519ctx”, 10), OSSL_PARAM_octet_string(“context-string”, (unsigned char *)“A protocol defined context string”, 33), OSSL_PARAM_END }; /* The input “params” is not needed if default options are acceptable. Use NULL in place of “params” in that case. */ EVP_DigestSignInit_ex(md_ctx, NULL, NULL, NULL, NULL, ed_key, params); /* Calculate the required size for the signature by passing a NULL buffer. */ EVP_DigestSign(md_ctx, NULL, &sig_len, msg, msg_len); sig = OPENSSL_zalloc(sig_len); EVP_DigestSign(md_ctx, sig, &sig_len, msg, msg_len); … OPENSSL_free(sig); EVP_MD_CTX_free(md_ctx); }

SEE ALSO

EVP_PKEY-X25519 (7) provider-signature (7), EVP_DigestSignInit (3), EVP_DigestVerifyInit (3),

COPYRIGHT

Copyright 2017-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

262 - Linux cli command EVP_KEM-X25519ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KEM-X25519ssl and provides detailed information about the command EVP_KEM-X25519ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KEM-X25519ssl.

NAME 🖥️ EVP_KEM-X25519ssl 🖥️

X25519, EVP_KEM-X448 - EVP_KEM X25519 and EVP_KEM X448 keytype and algorithm support

DESCRIPTION

The X25519 and <X448> keytype and its parameters are described in EVP_PKEY-X25519 (7). See EVP_PKEY_encapsulate (3) and EVP_PKEY_decapsulate (3) for more info.

X25519 and X448 KEM parameters

“operation” (OSSL_KEM_PARAM_OPERATION)<UTF8 string>
The OpenSSL X25519 and X448 Key Encapsulation Mechanisms only support the following operation:

“DHKEM” (OSSL_KEM_PARAM_OPERATION_DHKEM)
The encapsulate function generates an ephemeral keypair. It produces keymaterial by doing an X25519 or X448 key exchange using the ephemeral private key and a supplied recipient public key. A HKDF operation using the keymaterial and a kem context then produces a shared secret. The shared secret and the ephemeral public key are returned. The decapsulate function uses the recipient private key and the ephemeral public key to produce the same keymaterial, which can then be used to produce the same shared secret. See <https://www.rfc-editor.org/rfc/rfc9180.html#name-dh-based-kem-dhkem>

This can be set using either EVP_PKEY_CTX_set_kem_op() or EVP_PKEY_CTX_set_params().

“ikme” (OSSL_KEM_PARAM_IKME) <octet string>
Used to specify the key material used for generation of the ephemeral key. This value should not be reused for other purposes. It should have a length of at least 32 for X25519, and 56 for X448. If this value is not set, then a random ikm is used.

CONFORMING TO

RFC9180

SEE ALSO

EVP_PKEY_CTX_set_kem_op (3), EVP_PKEY_encapsulate (3), EVP_PKEY_decapsulate (3) EVP_KEYMGMT (3), EVP_PKEY (3), provider-keymgmt (7)

HISTORY

This functionality was added in OpenSSL 3.2.

COPYRIGHT

Copyright 2022 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

263 - Linux cli command NOTIFY

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command NOTIFY and provides detailed information about the command NOTIFY, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the NOTIFY.

NAME 🖥️ NOTIFY 🖥️

generate a notification

SYNOPSIS

NOTIFY channel [ , payload ]

DESCRIPTION

The NOTIFY command sends a notification event together with an optional “payload” string to each client application that has previously executed LISTEN channel for the specified channel name in the current database. Notifications are visible to all users.

NOTIFY provides a simple interprocess communication mechanism for a collection of processes accessing the same PostgreSQL database. A payload string can be sent along with the notification, and higher-level mechanisms for passing structured data can be built by using tables in the database to pass additional data from notifier to listener(s).

The information passed to the client for a notification event includes the notification channel name, the notifying sessions server process PID, and the payload string, which is an empty string if it has not been specified.

It is up to the database designer to define the channel names that will be used in a given database and what each one means. Commonly, the channel name is the same as the name of some table in the database, and the notify event essentially means, “I changed this table, take a look at it to see whats new”. But no such association is enforced by the NOTIFY and LISTEN commands. For example, a database designer could use several different channel names to signal different sorts of changes to a single table. Alternatively, the payload string could be used to differentiate various cases.

When NOTIFY is used to signal the occurrence of changes to a particular table, a useful programming technique is to put the NOTIFY in a statement trigger that is triggered by table updates. In this way, notification happens automatically when the table is changed, and the application programmer cannot accidentally forget to do it.

NOTIFY interacts with SQL transactions in some important ways. Firstly, if a NOTIFY is executed inside a transaction, the notify events are not delivered until and unless the transaction is committed. This is appropriate, since if the transaction is aborted, all the commands within it have had no effect, including NOTIFY. But it can be disconcerting if one is expecting the notification events to be delivered immediately. Secondly, if a listening session receives a notification signal while it is within a transaction, the notification event will not be delivered to its connected client until just after the transaction is completed (either committed or aborted). Again, the reasoning is that if a notification were delivered within a transaction that was later aborted, one would want the notification to be undone somehow — but the server cannot “take back” a notification once it has sent it to the client. So notification events are only delivered between transactions. The upshot of this is that applications using NOTIFY for real-time signaling should try to keep their transactions short.

If the same channel name is signaled multiple times with identical payload strings within the same transaction, only one instance of the notification event is delivered to listeners. On the other hand, notifications with distinct payload strings will always be delivered as distinct notifications. Similarly, notifications from different transactions will never get folded into one notification. Except for dropping later instances of duplicate notifications, NOTIFY guarantees that notifications from the same transaction get delivered in the order they were sent. It is also guaranteed that messages from different transactions are delivered in the order in which the transactions committed.

It is common for a client that executes NOTIFY to be listening on the same notification channel itself. In that case it will get back a notification event, just like all the other listening sessions. Depending on the application logic, this could result in useless work, for example, reading a database table to find the same updates that that session just wrote out. It is possible to avoid such extra work by noticing whether the notifying sessions server process PID (supplied in the notification event message) is the same as ones own sessions PID (available from libpq). When they are the same, the notification event is ones own work bouncing back, and can be ignored.

PARAMETERS

channel

Name of the notification channel to be signaled (any identifier).

payload

The “payload” string to be communicated along with the notification. This must be specified as a simple string literal. In the default configuration it must be shorter than 8000 bytes. (If binary data or large amounts of information need to be communicated, its best to put it in a database table and send the key of the record.)

NOTES

There is a queue that holds notifications that have been sent but not yet processed by all listening sessions. If this queue becomes full, transactions calling NOTIFY will fail at commit. The queue is quite large (8GB in a standard installation) and should be sufficiently sized for almost every use case. However, no cleanup can take place if a session executes LISTEN and then enters a transaction for a very long time. Once the queue is half full you will see warnings in the log file pointing you to the session that is preventing cleanup. In this case you should make sure that this session ends its current transaction so that cleanup can proceed.

The function pg_notification_queue_usage returns the fraction of the queue that is currently occupied by pending notifications. See Section 9.26 for more information.

A transaction that has executed NOTIFY cannot be prepared for two-phase commit.

pg_notify

To send a notification you can also use the function pg_notify(text, text). The function takes the channel name as the first argument and the payload as the second. The function is much easier to use than the NOTIFY command if you need to work with non-constant channel names and payloads.

EXAMPLES

Configure and execute a listen/notify sequence from psql:

LISTEN virtual; NOTIFY virtual; Asynchronous notification “virtual” received from server process with PID 8448. NOTIFY virtual, This is the payload; Asynchronous notification “virtual” with payload “This is the payload” received from server process with PID 8448.

LISTEN foo;
SELECT pg_notify(fo || o, pay || load);
Asynchronous notification "foo" with payload "payload" received from server process with PID 14728.

COMPATIBILITY

There is no NOTIFY statement in the SQL standard.

SEE ALSO

LISTEN(7), UNLISTEN(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

264 - Linux cli command UNLISTEN

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command UNLISTEN and provides detailed information about the command UNLISTEN, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the UNLISTEN.

NAME 🖥️ UNLISTEN 🖥️

stop listening for a notification

SYNOPSIS

UNLISTEN { channel | * }

DESCRIPTION

UNLISTEN is used to remove an existing registration for NOTIFY events. UNLISTEN cancels any existing registration of the current PostgreSQL session as a listener on the notification channel named channel. The special wildcard * cancels all listener registrations for the current session.

NOTIFY(7) contains a more extensive discussion of the use of LISTEN and NOTIFY.

PARAMETERS

channel

Name of a notification channel (any identifier).

*

All current listen registrations for this session are cleared.

NOTES

You can unlisten something you were not listening for; no warning or error will appear.

At the end of each session, UNLISTEN * is automatically executed.

A transaction that has executed UNLISTEN cannot be prepared for two-phase commit.

EXAMPLES

To make a registration:

LISTEN virtual; NOTIFY virtual; Asynchronous notification “virtual” received from server process with PID 8448.

Once UNLISTEN has been executed, further NOTIFY messages will be ignored:

UNLISTEN virtual; NOTIFY virtual; – no NOTIFY event is received

COMPATIBILITY

There is no UNLISTEN command in the SQL standard.

SEE ALSO

LISTEN(7), NOTIFY(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

265 - Linux cli command CREATE_TRANSFORM

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_TRANSFORM and provides detailed information about the command CREATE_TRANSFORM, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_TRANSFORM.

NAME 🖥️ CREATE_TRANSFORM 🖥️

define a new transform

SYNOPSIS

CREATE [ OR REPLACE ] TRANSFORM FOR type_name LANGUAGE lang_name (
    FROM SQL WITH FUNCTION from_sql_function_name [ (argument_type [, ...]) ],
    TO SQL WITH FUNCTION to_sql_function_name [ (argument_type [, ...]) ]
);

DESCRIPTION

CREATE TRANSFORM defines a new transform. CREATE OR REPLACE TRANSFORM will either create a new transform, or replace an existing definition.

A transform specifies how to adapt a data type to a procedural language. For example, when writing a function in PL/Python using the hstore type, PL/Python has no prior knowledge how to present hstore values in the Python environment. Language implementations usually default to using the text representation, but that is inconvenient when, for example, an associative array or a list would be more appropriate.

A transform specifies two functions:

·

A “from SQL” function that converts the type from the SQL environment to the language. This function will be invoked on the arguments of a function written in the language.

·

A “to SQL” function that converts the type from the language to the SQL environment. This function will be invoked on the return value of a function written in the language.

It is not necessary to provide both of these functions. If one is not specified, the language-specific default behavior will be used if necessary. (To prevent a transformation in a certain direction from happening at all, you could also write a transform function that always errors out.)

To be able to create a transform, you must own and have USAGE privilege on the type, have USAGE privilege on the language, and own and have EXECUTE privilege on the from-SQL and to-SQL functions, if specified.

PARAMETERS

type_name

The name of the data type of the transform.

lang_name

The name of the language of the transform.

from_sql_function_name[(argument_type [, …])]

The name of the function for converting the type from the SQL environment to the language. It must take one argument of type internal and return type internal. The actual argument will be of the type for the transform, and the function should be coded as if it were. (But it is not allowed to declare an SQL-level function returning internal without at least one argument of type internal.) The actual return value will be something specific to the language implementation. If no argument list is specified, the function name must be unique in its schema.

to_sql_function_name[(argument_type [, …])]

The name of the function for converting the type from the language to the SQL environment. It must take one argument of type internal and return the type that is the type for the transform. The actual argument value will be something specific to the language implementation. If no argument list is specified, the function name must be unique in its schema.

NOTES

Use DROP TRANSFORM to remove transforms.

EXAMPLES

To create a transform for type hstore and language plpython3u, first set up the type and the language:

CREATE TYPE hstore …;

CREATE EXTENSION plpython3u;

Then create the necessary functions:

CREATE FUNCTION hstore_to_plpython(val internal) RETURNS internal LANGUAGE C STRICT IMMUTABLE AS …;

CREATE FUNCTION plpython_to_hstore(val internal) RETURNS hstore
LANGUAGE C STRICT IMMUTABLE
AS ...;

And finally create the transform to connect them all together:

CREATE TRANSFORM FOR hstore LANGUAGE plpython3u ( FROM SQL WITH FUNCTION hstore_to_plpython(internal), TO SQL WITH FUNCTION plpython_to_hstore(internal) );

In practice, these commands would be wrapped up in an extension.

The contrib section contains a number of extensions that provide transforms, which can serve as real-world examples.

COMPATIBILITY

This form of CREATE TRANSFORM is a PostgreSQL extension. There is a CREATE TRANSFORM command in the SQL standard, but it is for adapting data types to client languages. That usage is not supported by PostgreSQL.

SEE ALSO

CREATE FUNCTION (CREATE_FUNCTION(7)), CREATE LANGUAGE (CREATE_LANGUAGE(7)), CREATE TYPE (CREATE_TYPE(7)), DROP TRANSFORM (DROP_TRANSFORM(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

266 - Linux cli command tc-hfsc

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command tc-hfsc and provides detailed information about the command tc-hfsc, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the tc-hfsc.

NAME 🖥️ tc-hfsc 🖥️

hfcs - Hierarchical Fair Service Curve

HISTORY & INTRODUCTION

HFSC (Hierarchical Fair Service Curve) is a network packet scheduling algorithm that was first presented at SIGCOMM'97. Developed as a part of ALTQ (ALTernative Queuing) on NetBSD, found its way quickly to other BSD systems, and then a few years ago became part of the linux kernel. Still, it’s not the most popular scheduling algorithm - especially if compared to HTB - and it’s not well documented for the enduser. This introduction aims to explain how HFSC works without using too much math (although some math it will be inevitable).

In short HFSC aims to:

  1. guarantee precise bandwidth and delay allocation for all leaf classes (realtime criterion)

  2. allocate excess bandwidth fairly as specified by class hierarchy (linkshare & upperlimit criterion)

  3. minimize any discrepancy between the service curve and the actual amount of service provided during linksharing

The main “selling” point of HFSC is feature (1), which is achieved by using nonlinear service curves (more about what it actually is later). This is particularly useful in VoIP or games, where not only a guarantee of consistent bandwidth is important, but also limiting the initial delay of a data stream. Note that it matters only for leaf classes (where the actual queues are) - thus class hierarchy is ignored in the realtime case.

Feature (2) is well, obvious - any algorithm featuring class hierarchy (such as HTB) strives to achieve that. HFSC does that well, although you might end with unusual situations, if you define service curves carelessly - see section CORNER CASES for examples.

Feature (3) is mentioned due to the nature of the problem. There may be situations where it’s either not possible to guarantee service of all curves at the same time, and/or it’s impossible to do so fairly. Both will be explained later. Note that this is mainly related to interior (aka aggregate) classes, as the leafs are already handled by (1). Still, it’s perfectly possible to create a leaf class without realtime service, and in such a case the caveats will naturally extend to leaf classes as well.

ABBREVIATIONS

For the remaining part of the document, we’ll use following shortcuts:

RT - realtime
LS - linkshare
UL - upperlimit
SC - service curve

BASICS OF HFSC

To understand how HFSC works, we must first introduce a service curve. Overall, it’s a nondecreasing function of some time unit, returning the amount of service (an allowed or allocated amount of bandwidth) at some specific point in time. The purpose of it should be subconsciously obvious: if a class was allowed to transfer not less than the amount specified by its service curve, then the service curve is not violated.

Still, we need more elaborate criterion than just the above (although in the most generic case it can be reduced to it). The criterion has to take two things into account:

  • idling periods

  • the ability to “look back”, so if during current active period the service curve is violated, maybe it isn’t if we count excess bandwidth received during earlier active period(s)

Let’s define the criterion as follows:

For each t1, there must exist t0 in set B, so S(t1-t0) <= w(t0,t1)

Here ‘w’ denotes the amount of service received during some time period between t0 and t1. B is a set of all times, where a session becomes active after idling period (further denoted as ‘becoming backlogged’). For a clearer picture, imagine two situations:

  1. our session was active during two periods, with a small time gap between them

  2. as in (a), but with a larger gap

Consider (a): if the service received during both periods meets (1), then all is well. But what if it doesn’t do so during the 2nd period? If the amount of service received during the 1st period is larger than the service curve, then it might compensate for smaller service during the 2nd period and the gap - if the gap is small enough.

If the gap is larger (b) - then it’s less likely to happen (unless the excess bandwidth allocated during the 1st part was really large). Still, the larger the gap - the less interesting is what happened in the past (e.g. 10 minutes ago) - what matters is the current traffic that just started.

From HFSC’s perspective, more interesting is answering the following question: when should we start transferring packets, so a service curve of a class is not violated. Or rephrasing it: How much X() amount of service should a session receive by time t, so the service curve is not violated. Function X() defined as below is the basic building block of HFSC, used in: eligible, deadline, virtual-time and fit-time curves. Of course, X() is based on equation (1) and is defined recursively:

  • At the 1st backlogged period beginning function X is initialized to generic service curve assigned to a class

  • At any subsequent backlogged period, X() is:

min(X() from previous period ; w(t0)+S(t-t0) for t>=t0),

… where t0 denotes the beginning of the current backlogged period.

HFSC uses either linear, or two-piece linear service curves. In case of linear or two-piece linear convex functions (first slope < second slope), min() in X’s definition reduces to the 2nd argument. But in case of two-piece concave functions, the 1st argument might quickly become lesser for some t>=t0. Note, that for some backlogged period, X() is defined only from that period’s beginning. We also define X^(-1)(w) as smallest t>=t0, for which X(t) = w. We have to define it this way, as X() is usually not an injection.

The above generic X() can be one of the following:

E()
In realtime criterion, selects packets eligible for sending. If none are eligible, HFSC will use linkshare criterion. Eligible time ’et’ is calculated with reference to packets’ heads ( et = E^(-1)(w) ). It’s based on RT service curve, but in case of a convex curve, uses its 2nd slope only.

D()
In realtime criterion, selects the most suitable packet from the ones chosen by E(). Deadline time ‘dt’ corresponds to packets’ tails (dt = D^(-1)(w+l), where ’l’ is packet’s length). Based on RT service curve.

V()
In linkshare criterion, arbitrates which packet to send next. Note that V() is function of a virtual time - see LINKSHARE CRITERION section for details. Virtual time ‘vt’ corresponds to packets’ heads (vt = V^(-1)(w)). Based on LS service curve.

F()
An extension to linkshare criterion, used to limit at which speed linkshare criterion is allowed to dequeue. Fit-time ‘ft’ corresponds to packets’ heads as well (ft = F^(-1)(w)). Based on UL service curve.

Be sure to make clean distinction between session’s RT, LS and UL service curves and the above “utility” functions.

REALTIME CRITERION

RT criterion ignores class hierarchy and guarantees precise bandwidth and delay allocation. We say that a packet is eligible for sending, when the current real time is later than the eligible time of the packet. From all eligible packets, the one most suited for sending is the one with the shortest deadline time. This sounds simple, but consider the following example:

Interface 10Mbit, two classes, both with two-piece linear service curves:

  • 1st class - 2Mbit for 100ms, then 7Mbit (convex - 1st slope < 2nd slope)

  • 2nd class - 7Mbit for 100ms, then 2Mbit (concave - 1st slope > 2nd slope)

Assume for a moment, that we only use D() for both finding eligible packets, and choosing the most fitting one, thus eligible time would be computed as D^(-1)(w) and deadline time would be computed as D^(-1)(w+l). If the 2nd class starts sending packets 1 second after the 1st class, it’s of course impossible to guarantee 14Mbit, as the interface capability is only 10Mbit. The only workaround in this scenario is to allow the 1st class to send the packets earlier that would normally be allowed. That’s where separate E() comes to help. Putting all the math aside (see HFSC paper for details), E() for RT concave service curve is just like D(), but for the RT convex service curve - it’s constructed using only RT service curve’s 2nd slope (in our example 7Mbit).

The effect of such E() - packets will be sent earlier, and at the same time D() will be updated - so the current deadline time calculated from it will be later. Thus, when the 2nd class starts sending packets later, both the 1st and the 2nd class will be eligible, but the 2nd session’s deadline time will be smaller and its packets will be sent first. When the 1st class becomes idle at some later point, the 2nd class will be able to “buffer” up again for later active period of the 1st class.

A short remark - in a situation, where the total amount of bandwidth available on the interface is larger than the allocated total realtime parts (imagine a 10 Mbit interface, but 1Mbit/2Mbit and 2Mbit/1Mbit classes), the sole speed of the interface could suffice to guarantee the times.

Important part of RT criterion is that apart from updating its D() and E(), also V() used by LS criterion is updated. Generally the RT criterion is secondary to LS one, and used only if there’s a risk of violating precise realtime requirements. Still, the “participation” in bandwidth distributed by LS criterion is there, so V() has to be updated along the way. LS criterion can than properly compensate for non-ideal fair sharing situation, caused by RT scheduling. If you use UL service curve its F() will be updated as well (UL service curve is an extension to LS one - see UPPERLIMIT CRITERION section).

Anyway - careless specification of LS and RT service curves can lead to potentially undesired situations (see CORNER CASES for examples). This wasn’t the case in HFSC paper where LS and RT service curves couldn’t be specified separately.

LINKSHARING CRITERION

LS criterion’s task is to distribute bandwidth according to specified class hierarchy. Contrary to RT criterion, there’re no comparisons between current real time and virtual time - the decision is based solely on direct comparison of virtual times of all active subclasses - the one with the smallest vt wins and gets scheduled. One immediate conclusion from this fact is that absolute values don’t matter - only ratios between them (so for example, two children classes with simple linear 1Mbit service curves will get the same treatment from LS criterion’s perspective, as if they were 5Mbit). The other conclusion is, that in perfectly fluid system with linear curves, all virtual times across whole class hierarchy would be equal.

Why is VC defined in term of virtual time (and what is it)?

Imagine an example: class A with two children - A1 and A2, both with let’s say 10Mbit SCs. If A2 is idle, A1 receives all the bandwidth of A (and update its V() in the process). When A2 becomes active, A1’s virtual time is already far later than A2’s one. Considering the type of decision made by LS criterion, A1 would become idle for a long time. We can workaround this situation by adjusting virtual time of the class becoming active - we do that by getting such time “up to date”. HFSC uses a mean of the smallest and the biggest virtual time of currently active children fit for sending. As it’s not real time anymore (excluding trivial case of situation where all classes become active at the same time, and never become idle), it’s called virtual time.

Such approach has its price though. The problem is analogous to what was presented in previous section and is caused by non-linearity of service curves:

  1. either it’s impossible to guarantee service curves and satisfy fairness during certain time periods:

    Recall the example from RT section, slightly modified (with 3Mbit slopes instead of 2Mbit ones):

    • 1st class - 3Mbit for 100ms, then 7Mbit (convex - 1st slope < 2nd slope)

    • 2nd class - 7Mbit for 100ms, then 3Mbit (concave - 1st slope > 2nd slope)

    They sum up nicely to 10Mbit - the interface’s capacity. But if we wanted to only use LS for guarantees and fairness - it simply won’t work. In LS context, only V() is used for making decision which class to schedule. If the 2nd class becomes active when the 1st one is in its second slope, the fairness will be preserved - ratio will be 1:1 (7Mbit:7Mbit), but LS itself is of course unable to guarantee the absolute values themselves - as it would have to go beyond of what the interface is capable of.

  1. and/or it’s impossible to guarantee service curves of all classes at the same time [fairly or not]:

    This is similar to the above case, but a bit more subtle. We will consider two subtrees, arbitrated by their common (root here) parent:

    R (root) - 10Mbit

A  - 7Mbit, then 3Mbit
A1 - 5Mbit, then 2Mbit
A2 - 2Mbit, then 1Mbit

B  - 3Mbit, then 7Mbit

    R arbitrates between left subtree (A) and right (B). Assume that A2 and B are constantly backlogged, and at some later point A1 becomes backlogged (when all other classes are in their 2nd linear part).

    What happens now? B (choice made by R) will always get 7 Mbit as R is only (obviously) concerned with the ratio between its direct children. Thus A subtree gets 3Mbit, but its children would want (at the point when A1 became backlogged) 5Mbit + 1Mbit. That’s of course impossible, as they can only get 3Mbit due to interface limitation.

    In the left subtree - we have the same situation as previously (fair split between A1 and A2, but violated guarantees), but in the whole tree - there’s no fairness (B got 7Mbit, but A1 and A2 have to fit together in 3Mbit) and there’s no guarantees for all classes (only B got what it wanted). Even if we violated fairness in the A subtree and set A2’s service curve to 0, A1 would still not get the required bandwidth.

UPPERLIMIT CRITERION

UL criterion is an extensions to LS one, that permits sending packets only if current real time is later than fit-time (‘ft’). So the modified LS criterion becomes: choose the smallest virtual time from all active children, such that fit-time < current real time also holds. Fit-time is calculated from F(), which is based on UL service curve. As you can see, its role is kinda similar to E() used in RT criterion. Also, for obvious reasons - you can’t specify UL service curve without LS one.

The main purpose of the UL service curve is to limit HFSC to bandwidth available on the upstream router (think adsl home modem/router, and linux server as NAT/firewall/etc. with 100Mbit+ connection to mentioned modem/router). Typically, it’s used to create a single class directly under root, setting a linear UL service curve to available bandwidth - and then creating your class structure from that class downwards. Of course, you’re free to add a UL service curve (linear or not) to any class with LS criterion.

An important part about the UL service curve is that whenever at some point in time a class doesn’t qualify for linksharing due to its fit-time, the next time it does qualify it will update its virtual time to the smallest virtual time of all active children fit for linksharing. This way, one of the main things the LS criterion tries to achieve - equality of all virtual times across whole hierarchy - is preserved (in perfectly fluid system with only linear curves, all virtual times would be equal).

Without that, ‘vt’ would lag behind other virtual times, and could cause problems. Consider an interface with a capacity of 10Mbit, and the following leaf classes (just in case you’re skipping this text quickly - this example shows behavior that doesn’t happen):

A - ls 5.0Mbit
B - ls 2.5Mbit
C - ls 2.5Mbit, ul 2.5Mbit

If B was idle, while A and C were constantly backlogged, A and C would normally (as far as LS criterion is concerned) divide bandwidth in 2:1 ratio. But due to UL service curve in place, C would get at most 2.5Mbit, and A would get the remaining 7.5Mbit. The longer the backlogged period, the more the virtual times of A and C would drift apart. If B became backlogged at some later point in time, its virtual time would be set to (A’s vt + C’s vt)/2, thus blocking A from sending any traffic until B’s virtual time catches up with A.

SEPARATE LS / RT SCs

Another difference from the original HFSC paper is that RT and LS SCs can be specified separately. Moreover, leaf classes are allowed to have only either RT SC or LS SC. For interior classes, only LS SCs make sense: any RT SC will be ignored.

CORNER CASES

Separate service curves for LS and RT criteria can lead to certain traps that come from “fighting” between ideal linksharing and enforced realtime guarantees. Those situations didn’t exist in original HFSC paper, where specifying separate LS / RT service curves was not discussed.

Consider an interface with a 10Mbit capacity, with the following leaf classes:

A - ls 5.0Mbit, rt 8Mbit
B - ls 2.5Mbit
C - ls 2.5Mbit

Imagine A and C are constantly backlogged. As B is idle, A and C would divide bandwidth in 2:1 ratio, considering LS service curve (so in theory - 6.66 and 3.33). Alas RT criterion takes priority, so A will get 8Mbit and LS will be able to compensate class C for only 2 Mbit - this will cause discrepancy between virtual times of A and C.

Assume this situation lasts for a long time with no idle periods, and suddenly B becomes active. B’s virtual time will be updated to (A’s vt + C’s vt)/2, effectively landing in the middle between A’s and C’s virtual time. The effect - B, having no RT guarantees, will be punished and will not be allowed to transfer until C’s virtual time catches up.

If the interface had a higher capacity, for example 100Mbit, this example would behave perfectly fine though.

Let’s look a bit closer at the above example - it “cleverly” invalidates one of the basic things LS criterion tries to achieve - equality of all virtual times across class hierarchy. Leaf classes without RT service curves are literally left to their own fate (governed by messed up virtual times).

Also, it doesn’t make much sense. Class A will always be guaranteed up to 8Mbit, and this is more than any absolute bandwidth that could happen from its LS criterion (excluding trivial case of only A being active). If the bandwidth taken by A is smaller than absolute value from LS criterion, the unused part will be automatically assigned to other active classes (as A has idling periods in such case). The only “advantage” is, that even in case of low bandwidth on average, bursts would be handled at the speed defined by RT criterion. Still, if extra speed is needed (e.g. due to latency), non linear service curves should be used in such case.

In the other words: the LS criterion is meaningless in the above example.

You can quickly “workaround” it by making sure each leaf class has RT service curve assigned (thus guaranteeing all of them will get some bandwidth), but it doesn’t make it any more valid.

Keep in mind - if you use nonlinear curves and irregularities explained above happen only in the first segment, then there’s little wrong with “overusing” RT curve a bit:

A - ls 5.0Mbit, rt 9Mbit/30ms, then 1Mbit
B - ls 2.5Mbit
C - ls 2.5Mbit

Here, the vt of A will “spike” in the initial period, but then A will never get more than 1Mbit until B & C catch up. Then everything will be back to normal.

LINUX AND TIMER RESOLUTION

In certain situations, the scheduler can throttle itself and setup so called watchdog to wakeup dequeue function at some time later. In case of HFSC it happens when for example no packet is eligible for scheduling, and UL service curve is used to limit the speed at which LS criterion is allowed to dequeue packets. It’s called throttling, and accuracy of it is dependent on how the kernel is compiled.

There’re 3 important options in modern kernels, as far as timers’ resolution goes: ’tickless system’, ‘high resolution timer support’ and ’timer frequency’.

If you have ’tickless system’ enabled, then the timer interrupt will trigger as slowly as possible, but each time a scheduler throttles itself (or any other part of the kernel needs better accuracy), the rate will be increased as needed / possible. The ceiling is either ’timer frequency’ if ‘high resolution timer support’ is not available or not compiled in, or it’s hardware dependent and can go far beyond the highest ’timer frequency’ setting available.

If ’tickless system’ is not enabled, the timer will trigger at a fixed rate specified by ’timer frequency’ - regardless if high resolution timers are or aren’t available.

This is important to keep those settings in mind, as in scenario like: no tickless, no HR timers, frequency set to 100hz - throttling accuracy would be at 10ms. It doesn’t automatically mean you would be limited to ~0.8Mbit/s (assuming packets at ~1KB) - as long as your queues are prepared to cover for timer inaccuracy. Of course, in case of e.g. locally generated UDP traffic - appropriate socket size is needed as well. Short example to make it more understandable (assume hardcore anti-schedule settings - HZ=100, no HR timers, no tickless):

tc qdisc add dev eth0 root handle 1:0 hfsc default 1
tc class add dev eth0 parent 1:0 classid 1:1 hfsc rt m2 10Mbit

Assuming packet of ~1KB size and HZ=100, that averages to ~0.8Mbit - anything beyond it (e.g. the above example with specified rate over 10x larger) will require appropriate queuing and cause bursts every ~10 ms. As you can imagine, any HFSC’s RT guarantees will be seriously invalidated by that. Aforementioned example is mainly important if you deal with old hardware - as is particularly popular for home server chores. Even then, you can easily set HZ=1000 and have very accurate scheduling for typical adsl speeds.

Anything modern (apic or even hpet msi based timers + ’tickless system’) will provide enough accuracy for superb 1Gbit scheduling. For example, on one of my cheap dual-core AMD boards I have the following settings:

tc qdisc add dev eth0 parent root handle 1:0 hfsc default 1
tc class add dev eth0 parent 1:0 classid 1:1 hfsc rt m2 300mbit

And a simple:

nc -u dst.host.com 54321 </dev/zero
nc -l -p 54321 >/dev/null

…will yield the following effects over a period of ~10 seconds (taken from /proc/interrupts):

319: 42124229   0  HPET_MSI-edge  hpet2 (before)
319: 42436214   0  HPET_MSI-edge  hpet2 (after 10s.)

That’s roughly 31000/s. Now compare it with HZ=1000 setting. The obvious drawback of it is that cpu load can be rather high with servicing that many timer interrupts. The example with 300Mbit RT service curve on 1Gbit link is particularly ugly, as it requires a lot of throttling with minuscule delays.

Also note that it’s just an example showing the capabilities of current hardware. The above example (essentially a 300Mbit TBF emulator) is pointless on an internal interface to begin with: you will pretty much always want a regular LS service curve there, and in such a scenario HFSC simply doesn’t throttle at all.

300Mbit RT service curve (selected columns from mpstat -P ALL 1):

10:56:43 PM  CPU  %sys     %irq   %soft   %idle
10:56:44 PM  all  20.10    6.53   34.67   37.19
10:56:44 PM    0  35.00    0.00   63.00    0.00
10:56:44 PM    1   4.95   12.87    6.93   73.27

So, in the rare case you need those speeds with only a RT service curve, or with a UL service curve: remember the drawbacks.

CAVEAT: RANDOM ONLINE EXAMPLES

For reasons unknown (though well guessed), many examples you can google love to overuse UL criterion and stuff it in every node possible. This makes no sense and works against what HFSC tries to do (and does pretty damn well). Use UL where it makes sense: on the uppermost node to match upstream router’s uplink capacity. Or in special cases, such as testing (limit certain subtree to some speed), or customers that must never get more than certain speed. In the last case you can usually achieve the same by just using a RT criterion without LS+UL on leaf nodes.

As for the router case - remember it’s good to differentiate between “traffic to router” (remote console, web config, etc.) and “outgoing traffic”, so for example:

tc qdisc add dev eth0 root handle 1:0 hfsc default 0x8002
tc class add dev eth0 parent 1:0 classid 1:999 hfsc rt m2 50Mbit
tc class add dev eth0 parent 1:0 classid 1:1 hfsc ls m2 2Mbit ul m2 2Mbit

… so “internet” tree under 1:1 and “router itself” as 1:999

LAYER2 ADAPTATION

Please refer to tc-stab(8)

SEE ALSO

tc(8), tc-hfsc(8), tc-stab(8)

Please direct bugreports and patches to: <[email protected]>

AUTHOR

Manpage created by Michal Soltys ([email protected])

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

267 - Linux cli command gitcvs-migration

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command gitcvs-migration and provides detailed information about the command gitcvs-migration, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the gitcvs-migration.

NAME 🖥️ gitcvs-migration 🖥️

migration - Git for CVS users

SYNOPSIS

git cvsimport *

DESCRIPTION

Git differs from CVS in that every working tree contains a repository with a full copy of the project history, and no repository is inherently more important than any other. However, you can emulate the CVS model by designating a single shared repository which people can synchronize with; this document explains how to do that.

Some basic familiarity with Git is required. Having gone through gittutorial(7) and gitglossary(7) should be sufficient.

DEVELOPING AGAINST A SHARED REPOSITORY

Suppose a shared repository is set up in /pub/repo.git on the host foo.com. Then as an individual committer you can clone the shared repository over ssh with:

$ git clone foo.com:/pub/repo.git/ my-project $ cd my-project

and hack away. The equivalent of cvs update is

$ git pull origin

which merges in any work that others might have done since the clone operation. If there are uncommitted changes in your working tree, commit them first before running git pull.

Note

The pull command knows where to get updates from because of certain configuration variables that were set by the first git clone command; see git config -l and the git-config(1) man page for details.

You can update the shared repository with your changes by first committing your changes, and then using the git push command:

$ git push origin master

to “push” those commits to the shared repository. If someone else has updated the repository more recently, git push, like cvs commit, will complain, in which case you must pull any changes before attempting the push again.

In the git push command above we specify the name of the remote branch to update (master). If we leave that out, git push tries to update any branches in the remote repository that have the same name as a branch in the local repository. So the last push can be done with either of:

$ git push origin $ git push foo.com:/pub/project.git/

as long as the shared repository does not have any branches other than master.

SETTING UP A SHARED REPOSITORY

We assume you have already created a Git repository for your project, possibly created from scratch or from a tarball (see gittutorial(7)), or imported from an already existing CVS repository (see the next section).

Assume your existing repo is at /home/alice/myproject. Create a new “bare” repository (a repository without a working tree) and fetch your project into it:

$ mkdir /pub/my-repo.git $ cd /pub/my-repo.git $ git –bare init –shared $ git –bare fetch /home/alice/myproject master:master

Next, give every team member read/write access to this repository. One easy way to do this is to give all the team members ssh access to the machine where the repository is hosted. If you don’t want to give them a full shell on the machine, there is a restricted shell which only allows users to do Git pushes and pulls; see git-shell(1).

Put all the committers in the same group, and make the repository writable by that group:

$ chgrp -R $group /pub/my-repo.git

Make sure committers have a umask of at most 027, so that the directories they create are writable and searchable by other group members.

IMPORTING A CVS ARCHIVE

Note

These instructions use the git-cvsimport script which ships with git, but other importers may provide better results. See the note in git-cvsimport(1) for other options.

First, install version 2.1 or higher of cvsps from https://github.com/andreyvit/cvsps and make sure it is in your path. Then cd to a checked out CVS working directory of the project you are interested in and run git-cvsimport(1):

$ git cvsimport -C

This puts a Git archive of the named CVS module in the directory <destination>, which will be created if necessary.

The import checks out from CVS every revision of every file. Reportedly cvsimport can average some twenty revisions per second, so for a medium-sized project this should not take more than a couple of minutes. Larger projects or remote repositories may take longer.

The main trunk is stored in the Git branch named origin, and additional CVS branches are stored in Git branches with the same names. The most recent version of the main trunk is also left checked out on the master branch, so you can start adding your own changes right away.

The import is incremental, so if you call it again next month it will fetch any CVS updates that have been made in the meantime. For this to work, you must not modify the imported branches; instead, create new branches for your own changes, and merge in the imported branches as necessary.

If you want a shared repository, you will need to make a bare clone of the imported directory, as described above. Then treat the imported directory as another development clone for purposes of merging incremental imports.

ADVANCED SHARED REPOSITORY MANAGEMENT

Git allows you to specify scripts called “hooks” to be run at certain points. You can use these, for example, to send all commits to the shared repository to a mailing list. See githooks(5).

You can enforce finer grained permissions using update hooks. See Controlling access to branches using update hooks[1].

PROVIDING CVS ACCESS TO A GIT REPOSITORY

It is also possible to provide true CVS access to a Git repository, so that developers can still use CVS; see git-cvsserver(1) for details.

ALTERNATIVE DEVELOPMENT MODELS

CVS users are accustomed to giving a group of developers commit access to a common repository. As we’ve seen, this is also possible with Git. However, the distributed nature of Git allows other development models, and you may want to first consider whether one of them might be a better fit for your project.

For example, you can choose a single person to maintain the project’s primary public repository. Other developers then clone this repository and each work in their own clone. When they have a series of changes that they’re happy with, they ask the maintainer to pull from the branch containing the changes. The maintainer reviews their changes and pulls them into the primary repository, which other developers pull from as necessary to stay coordinated. The Linux kernel and other projects use variants of this model.

With a small group, developers may just pull changes from each other’s repositories without the need for a central maintainer.

SEE ALSO

gittutorial(7), gittutorial-2(7), gitcore-tutorial(7), gitglossary(7), giteveryday(7), The Git User’s Manual[2]

GIT

Part of the git(1) suite

NOTES

Controlling access to branches using update hooks

file:///usr/share/doc/git/html/howto/update-hook-example.html

The Git User’s Manual

file:///usr/share/doc/git/html/user-manual.html

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

268 - Linux cli command CREATE_USER

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_USER and provides detailed information about the command CREATE_USER, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_USER.

NAME 🖥️ CREATE_USER 🖥️

define a new database role

SYNOPSIS

CREATE USER name [ [ WITH ] option [ ... ] ]

where option can be:

      SUPERUSER | NOSUPERUSER
    | CREATEDB | NOCREATEDB
    | CREATEROLE | NOCREATEROLE
    | INHERIT | NOINHERIT
    | LOGIN | NOLOGIN
    | REPLICATION | NOREPLICATION
    | BYPASSRLS | NOBYPASSRLS
    | CONNECTION LIMIT connlimit
    | [ ENCRYPTED ] PASSWORD password | PASSWORD NULL
    | VALID UNTIL timestamp
    | IN ROLE role_name [, ...]
    | IN GROUP role_name [, ...]
    | ROLE role_name [, ...]
    | ADMIN role_name [, ...]
    | USER role_name [, ...]
    | SYSID uid

DESCRIPTION

CREATE USER is now an alias for CREATE ROLE. The only difference is that when the command is spelled CREATE USER, LOGIN is assumed by default, whereas NOLOGIN is assumed when the command is spelled CREATE ROLE.

COMPATIBILITY

The CREATE USER statement is a PostgreSQL extension. The SQL standard leaves the definition of users to the implementation.

SEE ALSO

CREATE ROLE (CREATE_ROLE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

269 - Linux cli command EVP_PKEY-X448ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_PKEY-X448ssl and provides detailed information about the command EVP_PKEY-X448ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_PKEY-X448ssl.

NAME 🖥️ EVP_PKEY-X448ssl 🖥️

X25519, EVP_PKEY-X448, EVP_PKEY-ED25519, EVP_PKEY-ED448, EVP_KEYMGMT-X25519, EVP_KEYMGMT-X448, EVP_KEYMGMT-ED25519, EVP_KEYMGMT-ED448 - EVP_PKEY X25519, X448, ED25519 and ED448 keytype and algorithm support

DESCRIPTION

The X25519, X448, ED25519 and ED448 keytypes are implemented in OpenSSL’s default and FIPS providers. These implementations support the associated key, containing the public key pub and the private key priv.

Keygen Parameters

“dhkem-ikm” (OSSL_PKEY_PARAM_DHKEM_IKM) <octet string>
DHKEM requires the generation of a keypair using an input key material (seed). Use this to specify the key material used for generation of the private key. This value should not be reused for other purposes. It should have a length of at least 32 for X25519, and 56 for X448. This is only supported by X25519 and X448.

Use EVP_PKEY_CTX_set_params() after calling EVP_PKEY_keygen_init().

Common X25519, X448, ED25519 and ED448 parameters

In addition to the common parameters that all keytypes should support (see “Common parameters” in provider-keymgmt (7)), the implementation of these keytypes support the following.

“group” (OSSL_PKEY_PARAM_GROUP_NAME) <UTF8 string>
This is only supported by X25519 and X448. The group name must be “x25519” or “x448” respectively for those algorithms. This is only present for consistency with other key exchange algorithms and is typically not needed.

“pub” (OSSL_PKEY_PARAM_PUB_KEY) <octet string>
The public key value.

“priv” (OSSL_PKEY_PARAM_PRIV_KEY) <octet string>
The private key value.

“encoded-pub-key” (OSSL_PKEY_PARAM_ENCODED_PUBLIC_KEY) <octet string>
Used for getting and setting the encoding of a public key for the X25519 and X448 key types. Public keys are expected be encoded in a format as defined by RFC7748.

ED25519 and ED448 parameters

“mandatory-digest” (OSSL_PKEY_PARAM_MANDATORY_DIGEST) <UTF8 string>
The empty string, signifying that no digest may be specified.

CONFORMING TO

RFC 8032

RFC 8410

EXAMPLES

An EVP_PKEY context can be obtained by calling:

EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “X25519”, NULL); EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “X448”, NULL); EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “ED25519”, NULL); EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “ED448”, NULL);

An X25519 key can be generated like this:

pkey = EVP_PKEY_Q_keygen(NULL, NULL, “X25519”);

An X448, ED25519, or ED448 key can be generated likewise.

SEE ALSO

EVP_KEYMGMT (3), EVP_PKEY (3), provider-keymgmt (7), EVP_KEYEXCH-X25519 (7), EVP_KEYEXCH-X448 (7), EVP_SIGNATURE-ED25519 (7), EVP_SIGNATURE-ED448 (7)

COPYRIGHT

Copyright 2020-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

270 - Linux cli command ossl-guide-migrationssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ossl-guide-migrationssl and provides detailed information about the command ossl-guide-migrationssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ossl-guide-migrationssl.

NAME 🖥️ ossl-guide-migrationssl 🖥️

guide-migration, migration_guide - OpenSSL Guide: Migrating from older OpenSSL versions

SYNOPSIS

See the individual manual pages for details.

DESCRIPTION

This guide details the changes required to migrate to new versions of OpenSSL. Currently this covers OpenSSL 3.0 & 3.1. For earlier versions refer to <https://github.com/openssl/openssl/blob/master/CHANGES.md>. For an overview of some of the key concepts introduced in OpenSSL 3.0 see crypto (7).

OPENSSL 3.1

Main Changes from OpenSSL 3.0

The FIPS provider in OpenSSL 3.1 includes some non-FIPS validated algorithms, consequently the property query fips=yes is mandatory for applications that want to operate in a FIPS approved manner. The algorithms are:

Triple DES ECB

Triple DES CBC

EdDSA

There are no other changes requiring additional migration measures since OpenSSL 3.0.

OPENSSL 3.0

Main Changes from OpenSSL 1.1.1

Major Release

OpenSSL 3.0 is a major release and consequently any application that currently uses an older version of OpenSSL will at the very least need to be recompiled in order to work with the new version. It is the intention that the large majority of applications will work unchanged with OpenSSL 3.0 if those applications previously worked with OpenSSL 1.1.1. However this is not guaranteed and some changes may be required in some cases. Changes may also be required if applications need to take advantage of some of the new features available in OpenSSL 3.0 such as the availability of the FIPS module.

License Change

In previous versions, OpenSSL was licensed under the dual OpenSSL and SSLeay licenses <https://www.openssl.org/source/license-openssl-ssleay.txt> (both licenses apply). From OpenSSL 3.0 this is replaced by the Apache License v2 <https://www.openssl.org/source/apache-license-2.0.txt>.

Providers and FIPS support

One of the key changes from OpenSSL 1.1.1 is the introduction of the Provider concept. Providers collect together and make available algorithm implementations. With OpenSSL 3.0 it is possible to specify, either programmatically or via a config file, which providers you want to use for any given application. OpenSSL 3.0 comes with 5 different providers as standard. Over time third parties may distribute additional providers that can be plugged into OpenSSL. All algorithm implementations available via providers are accessed through the “high level” APIs (for example those functions prefixed with EVP). They cannot be accessed using the “Low Level APIs”.

One of the standard providers available is the FIPS provider. This makes available FIPS validated cryptographic algorithms. The FIPS provider is disabled by default and needs to be enabled explicitly at configuration time using the enable-fips option. If it is enabled, the FIPS provider gets built and installed in addition to the other standard providers. No separate installation procedure is necessary. There is however a dedicated install_fips make target, which serves the special purpose of installing only the FIPS provider into an existing OpenSSL installation.

Not all algorithms may be available for the application at a particular moment. If the application code uses any digest or cipher algorithm via the EVP interface, the application should verify the result of the EVP_EncryptInit (3), EVP_EncryptInit_ex (3), and EVP_DigestInit (3) functions. In case when the requested algorithm is not available, these functions will fail.

See also “Legacy Algorithms” for information on the legacy provider.

See also “Completing the installation of the FIPS Module” and “Using the FIPS Module in applications”.

Low Level APIs

OpenSSL has historically provided two sets of APIs for invoking cryptographic algorithms: the “high level” APIs (such as the EVP APIs) and the “low level” APIs. The high level APIs are typically designed to work across all algorithm types. The “low level” APIs are targeted at a specific algorithm implementation. For example, the EVP APIs provide the functions EVP_EncryptInit_ex (3), EVP_EncryptUpdate (3) and EVP_EncryptFinal (3) to perform symmetric encryption. Those functions can be used with the algorithms AES, CHACHA, 3DES etc. On the other hand, to do AES encryption using the low level APIs you would have to call AES specific functions such as AES_set_encrypt_key (3), AES_encrypt (3), and so on. The functions for 3DES are different. Use of the low level APIs has been informally discouraged by the OpenSSL development team for a long time. However in OpenSSL 3.0 this is made more formal. All such low level APIs have been deprecated. You may still use them in your applications, but you may start to see deprecation warnings during compilation (dependent on compiler support for this). Deprecated APIs may be removed from future versions of OpenSSL so you are strongly encouraged to update your code to use the high level APIs instead.

This is described in more detail in “Deprecation of Low Level Functions”

Legacy Algorithms

Some cryptographic algorithms such as MD2 and DES that were available via the EVP APIs are now considered legacy and their use is strongly discouraged. These legacy EVP algorithms are still available in OpenSSL 3.0 but not by default. If you want to use them then you must load the legacy provider. This can be as simple as a config file change, or can be done programmatically. See OSSL_PROVIDER-legacy (7) for a complete list of algorithms. Applications using the EVP APIs to access these algorithms should instead use more modern algorithms. If that is not possible then these applications should ensure that the legacy provider has been loaded. This can be achieved either programmatically or via configuration. See crypto (7) man page for more information about providers.

Engines and “METHOD” APIs

The refactoring to support Providers conflicts internally with the APIs used to support engines, including the ENGINE API and any function that creates or modifies custom “METHODS” (for example EVP_MD_meth_new (3), EVP_CIPHER_meth_new (3), EVP_PKEY_meth_new (3), RSA_meth_new (3), EC_KEY_METHOD_new (3), etc.). These functions are being deprecated in OpenSSL 3.0, and users of these APIs should know that their use can likely bypass provider selection and configuration, with unintended consequences. This is particularly relevant for applications written to use the OpenSSL 3.0 FIPS module, as detailed below. Authors and maintainers of external engines are strongly encouraged to refactor their code transforming engines into providers using the new Provider API and avoiding deprecated methods.

Support of legacy engines

If openssl is not built without engine support or deprecated API support, engines will still work. However, their applicability will be limited.

New algorithms provided via engines will still work.

Engine-backed keys can be loaded via custom OSSL_STORE implementation. In this case the EVP_PKEY objects created via ENGINE_load_private_key (3) will be considered legacy and will continue to work.

To ensure the future compatibility, the engines should be turned to providers. To prefer the provider-based hardware offload, you can specify the default properties to prefer your provider.

Setting engine-based or application-based default low-level crypto method such as RSA_METHOD or EC_KEY_METHOD is still possible and keys inside the default provider will use the engine-based implementation for the crypto operations. However EVP_PKEYs created by decoding by using OSSL_DECODER, PEM_ or d2i_ APIs will be provider-based. To create a fully legacy EVP_PKEYs EVP_PKEY_set1_RSA (3), EVP_PKEY_set1_EC_KEY (3) or similar functions must be used.

Versioning Scheme

The OpenSSL versioning scheme has changed with the OpenSSL 3.0 release. The new versioning scheme has this format:

MAJOR.MINOR.PATCH

For OpenSSL 1.1.1 and below, different patch levels were indicated by a letter at the end of the release version number. This will no longer be used and instead the patch level is indicated by the final number in the version. A change in the second (MINOR) number indicates that new features may have been added. OpenSSL versions with the same major number are API and ABI compatible. If the major number changes then API and ABI compatibility is not guaranteed.

For more information, see OpenSSL_version (3).

Other major new features

Certificate Management Protocol (CMP, RFC 4210)

This also covers CRMF (RFC 4211) and HTTP transfer (RFC 6712) See openssl-cmp (1) and OSSL_CMP_exec_certreq (3) as starting points.

HTTP(S) client

A proper HTTP(S) client that supports GET and POST, redirection, plain and ASN.1-encoded contents, proxies, and timeouts.

Key Derivation Function API (EVP_KDF)

This simplifies the process of adding new KDF and PRF implementations.

Previously KDF algorithms had been shoe-horned into using the EVP_PKEY object which was not a logical mapping. Existing applications that use KDF algorithms using EVP_PKEY (scrypt, TLS1 PRF and HKDF) may be slower as they use an EVP_KDF bridge internally. All new applications should use the new EVP_KDF (3) interface. See also “Key Derivation Function (KDF)” in OSSL_PROVIDER-default (7) and “Key Derivation Function (KDF)” in OSSL_PROVIDER-FIPS (7).

Message Authentication Code API (EVP_MAC)

This simplifies the process of adding MAC implementations.

This includes a generic EVP_PKEY to EVP_MAC bridge, to facilitate the continued use of MACs through raw private keys in functionality such as EVP_DigestSign (3) and EVP_DigestVerify (3).

All new applications should use the new EVP_MAC (3) interface. See also “Message Authentication Code (MAC)” in OSSL_PROVIDER-default (7) and “Message Authentication Code (MAC)” in OSSL_PROVIDER-FIPS (7).

Algorithm Fetching

Using calls to convenience functions such as EVP_sha256() and EVP_aes_256_gcm() may incur a performance penalty when using providers. Retrieving algorithms from providers involves searching for an algorithm by name. This is much slower than directly accessing a method table. It is recommended to prefetch algorithms if an algorithm is used many times. See “Performance” in crypto (7), “Explicit fetching” in crypto (7) and “Implicit fetching” in crypto (7).

Support for Linux Kernel TLS

In order to use KTLS, support for it must be compiled in using the enable-ktls configuration option. It must also be enabled at run time using the SSL_OP_ENABLE_KTLS option.

New Algorithms

  • KDF algorithms “SINGLE STEP” and “SSH” See EVP_KDF-SS (7) and EVP_KDF-SSHKDF (7)

  • MAC Algorithms “GMAC” and “KMAC” See EVP_MAC-GMAC (7) and EVP_MAC-KMAC (7).

  • KEM Algorithm “RSASVE” See EVP_KEM-RSA (7).

  • Cipher Algorithm “AES-SIV” See “SIV Mode” in EVP_EncryptInit (3).

  • AES Key Wrap inverse ciphers supported by EVP layer. The inverse ciphers use AES decryption for wrapping, and AES encryption for unwrapping. The algorithms are: “AES-128-WRAP-INV”, “AES-192-WRAP-INV”, “AES-256-WRAP-INV”, “AES-128-WRAP-PAD-INV”, “AES-192-WRAP-PAD-INV” and “AES-256-WRAP-PAD-INV”.

  • CTS ciphers added to EVP layer. The algorithms are “AES-128-CBC-CTS”, “AES-192-CBC-CTS”, “AES-256-CBC-CTS”, “CAMELLIA-128-CBC-CTS”, “CAMELLIA-192-CBC-CTS” and “CAMELLIA-256-CBC-CTS”. CS1, CS2 and CS3 variants are supported.

CMS and PKCS#7 updates

  • Added CAdES-BES signature verification support.

  • Added CAdES-BES signature scheme and attributes support (RFC 5126) to CMS API.

  • Added AuthEnvelopedData content type structure (RFC 5083) using AES_GCM This uses the AES-GCM parameter (RFC 5084) for the Cryptographic Message Syntax. Its purpose is to support encryption and decryption of a digital envelope that is both authenticated and encrypted using AES GCM mode.

  • PKCS7_get_octet_string (3) and PKCS7_type_is_other (3) were made public.

PKCS#12 API updates

The default algorithms for pkcs12 creation with the PKCS12_create() function were changed to more modern PBKDF2 and AES based algorithms. The default MAC iteration count was changed to PKCS12_DEFAULT_ITER to make it equal with the password-based encryption iteration count. The default digest algorithm for the MAC computation was changed to SHA-256. The pkcs12 application now supports -legacy option that restores the previous default algorithms to support interoperability with legacy systems.

Added enhanced PKCS#12 APIs which accept a library context OSSL_LIB_CTX and (where relevant) a property query. Other APIs which handle PKCS#7 and PKCS#8 objects have also been enhanced where required. This includes:

PKCS12_add_key_ex (3), PKCS12_add_safe_ex (3), PKCS12_add_safes_ex (3), PKCS12_create_ex (3), PKCS12_decrypt_skey_ex (3), PKCS12_init_ex (3), PKCS12_item_decrypt_d2i_ex (3), PKCS12_item_i2d_encrypt_ex (3), PKCS12_key_gen_asc_ex (3), PKCS12_key_gen_uni_ex (3), PKCS12_key_gen_utf8_ex (3), PKCS12_pack_p7encdata_ex (3), PKCS12_pbe_crypt_ex (3), PKCS12_PBE_keyivgen_ex (3), PKCS12_SAFEBAG_create_pkcs8_encrypt_ex (3), PKCS5_pbe2_set_iv_ex (3), PKCS5_pbe_set0_algor_ex (3), PKCS5_pbe_set_ex (3), PKCS5_pbkdf2_set_ex (3), PKCS5_v2_PBE_keyivgen_ex (3), PKCS5_v2_scrypt_keyivgen_ex (3), PKCS8_decrypt_ex (3), PKCS8_encrypt_ex (3), PKCS8_set0_pbe_ex (3).

As part of this change the EVP_PBE_xxx APIs can also accept a library context and property query and will call an extended version of the key/IV derivation function which supports these parameters. This includes EVP_PBE_CipherInit_ex (3), EVP_PBE_find_ex (3) and EVP_PBE_scrypt_ex (3).

PKCS#12 KDF versus FIPS

Unlike in 1.x.y, the PKCS12KDF algorithm used when a PKCS#12 structure is created with a MAC that does not work with the FIPS provider as the PKCS12KDF is not a FIPS approvable mechanism.

See EVP_KDF-PKCS12KDF (7), PKCS12_create (3), openssl-pkcs12 (1), OSSL_PROVIDER-FIPS (7).

Windows thread synchronization changes

Windows thread synchronization uses read/write primitives (SRWLock) when supported by the OS, otherwise CriticalSection continues to be used.

Trace API

A new generic trace API has been added which provides support for enabling instrumentation through trace output. This feature is mainly intended as an aid for developers and is disabled by default. To utilize it, OpenSSL needs to be configured with the enable-trace option.

If the tracing API is enabled, the application can activate trace output by registering BIOs as trace channels for a number of tracing and debugging categories. See OSSL_trace_enabled (3).

Key validation updates

EVP_PKEY_public_check (3) and EVP_PKEY_param_check (3) now work for more key types. This includes RSA, DSA, ED25519, X25519, ED448 and X448. Previously (in 1.1.1) they would return -2. For key types that do not have parameters then EVP_PKEY_param_check (3) will always return 1.

Other notable deprecations and changes

The function code part of an OpenSSL error code is no longer relevant

This code is now always set to zero. Related functions are deprecated.

STACK and HASH macros have been cleaned up

The type-safe wrappers are declared everywhere and implemented once. See DEFINE_STACK_OF (3) and DEFINE_LHASH_OF_EX (3).

The RAND_DRBG subsystem has been removed

The new EVP_RAND (3) is a partial replacement: the DRBG callback framework is absent. The RAND_DRBG API did not fit well into the new provider concept as implemented by EVP_RAND and EVP_RAND_CTX.

Removed FIPS_mode() and FIPS_mode_set()

These functions are legacy APIs that are not applicable to the new provider model. Applications should instead use EVP_default_properties_is_fips_enabled (3) and EVP_default_properties_enable_fips (3).

Key generation is slower

The Miller-Rabin test now uses 64 rounds, which is used for all prime generation, including RSA key generation. This affects the time for larger keys sizes.

The default key generation method for the regular 2-prime RSA keys was changed to the FIPS186-4 B.3.6 method (Generation of Probable Primes with Conditions Based on Auxiliary Probable Primes). This method is slower than the original method.

Change PBKDF2 to conform to SP800-132 instead of the older PKCS5 RFC2898

This checks that the salt length is at least 128 bits, the derived key length is at least 112 bits, and that the iteration count is at least 1000. For backwards compatibility these checks are disabled by default in the default provider, but are enabled by default in the FIPS provider.

To enable or disable the checks see OSSL_KDF_PARAM_PKCS5 in EVP_KDF-PBKDF2 (7). The parameter can be set using EVP_KDF_derive (3).

Enforce a minimum DH modulus size of 512 bits

Smaller sizes now result in an error.

SM2 key changes

EC EVP_PKEYs with the SM2 curve have been reworked to automatically become EVP_PKEY_SM2 rather than EVP_PKEY_EC.

Unlike in previous OpenSSL versions, this means that applications cannot call EVP_PKEY_set_alias_type(pkey, EVP_PKEY_SM2) to get SM2 computations.

Parameter and key generation is also reworked to make it possible to generate EVP_PKEY_SM2 parameters and keys. Applications must now generate SM2 keys directly and must not create an EVP_PKEY_EC key first. It is no longer possible to import an SM2 key with domain parameters other than the SM2 elliptic curve ones.

Validation of SM2 keys has been separated from the validation of regular EC keys, allowing to improve the SM2 validation process to reject loaded private keys that are not conforming to the SM2 ISO standard. In particular, a private scalar k outside the range 1 <= k < n-1 is now correctly rejected.

EVP_PKEY_set_alias_type() method has been removed

This function made a EVP_PKEY object mutable after it had been set up. In OpenSSL 3.0 it was decided that a provided key should not be able to change its type, so this function has been removed.

Functions that return an internal key should be treated as read only

Functions such as EVP_PKEY_get0_RSA (3) behave slightly differently in OpenSSL 3.0. Previously they returned a pointer to the low-level key used internally by libcrypto. From OpenSSL 3.0 this key may now be held in a provider. Calling these functions will only return a handle on the internal key where the EVP_PKEY was constructed using this key in the first place, for example using a function or macro such as EVP_PKEY_assign_RSA (3), EVP_PKEY_set1_RSA (3), etc. Where the EVP_PKEY holds a provider managed key, then these functions now return a cached copy of the key. Changes to the internal provider key that take place after the first time the cached key is accessed will not be reflected back in the cached copy. Similarly any changes made to the cached copy by application code will not be reflected back in the internal provider key.

For the above reasons the keys returned from these functions should typically be treated as read-only. To emphasise this the value returned from EVP_PKEY_get0_RSA (3), EVP_PKEY_get0_DSA (3), EVP_PKEY_get0_EC_KEY (3) and EVP_PKEY_get0_DH (3) have been made const. This may break some existing code. Applications broken by this change should be modified. The preferred solution is to refactor the code to avoid the use of these deprecated functions. Failing this the code should be modified to use a const pointer instead. The EVP_PKEY_get1_RSA (3), EVP_PKEY_get1_DSA (3), EVP_PKEY_get1_EC_KEY (3) and EVP_PKEY_get1_DH (3) functions continue to return a non-const pointer to enable them to be “freed”. However they should also be treated as read-only.

The public key check has moved from EVP_PKEY_derive() to EVP_PKEY_derive_set_peer()

This may mean result in an error in EVP_PKEY_derive_set_peer (3) rather than during EVP_PKEY_derive (3). To disable this check use EVP_PKEY_derive_set_peer_ex(dh, peer, 0).

The print format has cosmetic changes for some functions

The output from numerous “printing” functions such as X509_signature_print (3), X509_print_ex (3), X509_CRL_print_ex (3), and other similar functions has been amended such that there may be cosmetic differences between the output observed in 1.1.1 and 3.0. This also applies to the -text output from the openssl x509 and openssl crl applications.

Interactive mode from the openssl program has been removed

From now on, running it without arguments is equivalent to openssl help.

The error return values from some control calls (ctrl) have changed

One significant change is that controls which used to return -2 for invalid inputs, now return -1 indicating a generic error condition instead.

DH and DHX key types have different settable parameters

Previously (in 1.1.1) these conflicting parameters were allowed, but will now result in errors. See EVP_PKEY-DH (7) for further details. This affects the behaviour of openssl-genpkey (1) for DH parameter generation.

EVP_CIPHER_CTX_set_flags() ordering change

If using a cipher from a provider the EVP_CIPH_FLAG_LENGTH_BITS flag can only be set after the cipher has been assigned to the cipher context. See “FLAGS” in EVP_EncryptInit (3) for more information.

Validation of operation context parameters

Due to move of the implementation of cryptographic operations to the providers, validation of various operation parameters can be postponed until the actual operation is executed where previously it happened immediately when an operation parameter was set.

For example when setting an unsupported curve with EVP_PKEY_CTX_set_ec_paramgen_curve_nid() this function call will not fail but later keygen operations with the EVP_PKEY_CTX will fail.

Removal of function code from the error codes

The function code part of the error code is now always set to 0. For that reason the ERR_GET_FUNC() macro was removed. Applications must resolve the error codes only using the library number and the reason code.

ChaCha20-Poly1305 cipher does not allow a truncated IV length to be used

In OpenSSL 3.0 setting the IV length to any value other than 12 will result in an error. Prior to OpenSSL 3.0 the ivlen could be smaller that the required 12 byte length, using EVP_CIPHER_CTX_ctrl(ctx, EVP_CRTL_AEAD_SET_IVLEN, ivlen, NULL). This resulted in an IV that had leading zero padding.

Installation and Compilation

Please refer to the INSTALL.md file in the top of the distribution for instructions on how to build and install OpenSSL 3.0. Please also refer to the various platform specific NOTES files for your specific platform.

Upgrading from OpenSSL 1.1.1

Upgrading to OpenSSL 3.0 from OpenSSL 1.1.1 should be relatively straight forward in most cases. The most likely area where you will encounter problems is if you have used low level APIs in your code (as discussed above). In that case you are likely to start seeing deprecation warnings when compiling your application. If this happens you have 3 options:

  1. Ignore the warnings. They are just warnings. The deprecated functions are still present and you may still use them. However be aware that they may be removed from a future version of OpenSSL.

  2. Suppress the warnings. Refer to your compiler documentation on how to do this.

  3. Remove your usage of the low level APIs. In this case you will need to rewrite your code to use the high level APIs instead

Error code changes

As OpenSSL 3.0 provides a brand new Encoder/Decoder mechanism for working with widely used file formats, application code that checks for particular error reason codes on key loading failures might need an update.

Password-protected keys may deserve special attention. If only some errors are treated as an indicator that the user should be asked about the password again, it’s worth testing these scenarios and processing the newly relevant codes.

There may be more cases to treat specially, depending on the calling application code.

Upgrading from OpenSSL 1.0.2

Upgrading to OpenSSL 3.0 from OpenSSL 1.0.2 is likely to be significantly more difficult. In addition to the issues discussed above in the section about “Upgrading from OpenSSL 1.1.1”, the main things to be aware of are:

  1. The build and installation procedure has changed significantly. Check the file INSTALL.md in the top of the installation for instructions on how to build and install OpenSSL for your platform. Also read the various NOTES files in the same directory, as applicable for your platform.

  2. Many structures have been made opaque in OpenSSL 3.0. The structure definitions have been removed from the public header files and moved to internal header files. In practice this means that you can no longer stack allocate some structures. Instead they must be heap allocated through some function call (typically those function names have a _new suffix to them). Additionally you must use “setter” or “getter” functions to access the fields within those structures. For example code that previously looked like this: EVP_MD_CTX md_ctx; /* This line will now generate compiler errors */ EVP_MD_CTX_init(&md_ctx); The code needs to be amended to look like this: EVP_MD_CTX *md_ctx; md_ctx = EVP_MD_CTX_new(); … … EVP_MD_CTX_free(md_ctx);

  3. Support for TLSv1.3 has been added. This has a number of implications for SSL/TLS applications. See the TLS1.3 page <https://wiki.openssl.org/index.php/TLS1.3> for further details.

More details about the breaking changes between OpenSSL versions 1.0.2 and 1.1.0 can be found on the OpenSSL 1.1.0 Changes page <https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes>.

Upgrading from the OpenSSL 2.0 FIPS Object Module

The OpenSSL 2.0 FIPS Object Module was a separate download that had to be built separately and then integrated into your main OpenSSL 1.0.2 build. In OpenSSL 3.0 the FIPS support is fully integrated into the mainline version of OpenSSL and is no longer a separate download. For further information see “Completing the installation of the FIPS Module”.

The function calls FIPS_mode() and FIPS_mode_set() have been removed from OpenSSL 3.0. You should rewrite your application to not use them. See fips_module (7) and OSSL_PROVIDER-FIPS (7) for details.

Completing the installation of the FIPS Module

The FIPS Module will be built and installed automatically if FIPS support has been configured. The current documentation can be found in the README-FIPS <https://github.com/openssl/openssl/blob/master/README-FIPS.md> file.

Programming

Applications written to work with OpenSSL 1.1.1 will mostly just work with OpenSSL 3.0. However changes will be required if you want to take advantage of some of the new features that OpenSSL 3.0 makes available. In order to do that you need to understand some new concepts introduced in OpenSSL 3.0. Read “Library contexts” in crypto (7) for further information.

Library Context

A library context allows different components of a complex application to each use a different library context and have different providers loaded with different configuration settings. See “Library contexts” in crypto (7) for further info.

If the user creates an OSSL_LIB_CTX via OSSL_LIB_CTX_new (3) then many functions may need to be changed to pass additional parameters to handle the library context.

Using a Library Context - Old functions that should be changed

If a library context is needed then all EVP_* digest functions that return a const EVP_MD * such as EVP_sha256() should be replaced with a call to EVP_MD_fetch (3). See “ALGORITHM FETCHING” in crypto (7).

If a library context is needed then all EVP_* cipher functions that return a const EVP_CIPHER * such as EVP_aes_128_cbc() should be replaced vith a call to EVP_CIPHER_fetch (3). See “ALGORITHM FETCHING” in crypto (7).

Some functions can be passed an object that has already been set up with a library context such as d2i_X509 (3), d2i_X509_CRL (3), d2i_X509_REQ (3) and d2i_X509_PUBKEY (3). If NULL is passed instead then the created object will be set up with the default library context. Use X509_new_ex (3), X509_CRL_new_ex (3), X509_REQ_new_ex (3) and X509_PUBKEY_new_ex (3) if a library context is required.

All functions listed below with a NAME have a replacement function NAME_ex that takes OSSL_LIB_CTX as an additional argument. Functions that have other mappings are listed along with the respective name.

  • ASN1_item_new (3), ASN1_item_d2i (3), ASN1_item_d2i_fp (3), ASN1_item_d2i_bio (3), ASN1_item_sign (3) and ASN1_item_verify (3)

  • BIO_new (3)

  • b2i_RSA_PVK_bio() and i2b_PVK_bio()

  • BN_CTX_new (3) and BN_CTX_secure_new (3)

  • CMS_AuthEnvelopedData_create (3), CMS_ContentInfo_new (3), CMS_data_create (3), CMS_digest_create (3), CMS_EncryptedData_encrypt (3), CMS_encrypt (3), CMS_EnvelopedData_create (3), CMS_ReceiptRequest_create0 (3) and CMS_sign (3)

  • CONF_modules_load_file (3)

  • CTLOG_new (3), CTLOG_new_from_base64 (3) and CTLOG_STORE_new (3)

  • CT_POLICY_EVAL_CTX_new (3)

  • d2i_AutoPrivateKey (3), d2i_PrivateKey (3) and d2i_PUBKEY (3)

  • d2i_PrivateKey_bio (3) and d2i_PrivateKey_fp (3) Use d2i_PrivateKey_ex_bio (3) and d2i_PrivateKey_ex_fp (3)

  • EC_GROUP_new (3) Use EC_GROUP_new_by_curve_name_ex (3) or EC_GROUP_new_from_params (3).

  • EVP_DigestSignInit (3) and EVP_DigestVerifyInit (3)

  • EVP_PBE_CipherInit (3), EVP_PBE_find (3) and EVP_PBE_scrypt (3)

  • PKCS5_PBE_keyivgen (3)

  • EVP_PKCS82PKEY (3)

  • EVP_PKEY_CTX_new_id (3) Use EVP_PKEY_CTX_new_from_name (3)

  • EVP_PKEY_derive_set_peer (3), EVP_PKEY_new_raw_private_key (3) and EVP_PKEY_new_raw_public_key (3)

  • EVP_SignFinal (3) and EVP_VerifyFinal (3)

  • NCONF_new (3)

  • OCSP_RESPID_match (3) and OCSP_RESPID_set_by_key (3)

  • OPENSSL_thread_stop (3)

  • OSSL_STORE_open (3)

  • PEM_read_bio_Parameters (3), PEM_read_bio_PrivateKey (3), PEM_read_bio_PUBKEY (3), PEM_read_PrivateKey (3) and PEM_read_PUBKEY (3)

  • PEM_write_bio_PrivateKey (3), PEM_write_bio_PUBKEY (3), PEM_write_PrivateKey (3) and PEM_write_PUBKEY (3)

  • PEM_X509_INFO_read_bio (3) and PEM_X509_INFO_read (3)

  • PKCS12_add_key (3), PKCS12_add_safe (3), PKCS12_add_safes (3), PKCS12_create (3), PKCS12_decrypt_skey (3), PKCS12_init (3), PKCS12_item_decrypt_d2i (3), PKCS12_item_i2d_encrypt (3), PKCS12_key_gen_asc (3), PKCS12_key_gen_uni (3), PKCS12_key_gen_utf8 (3), PKCS12_pack_p7encdata (3), PKCS12_pbe_crypt (3), PKCS12_PBE_keyivgen (3), PKCS12_SAFEBAG_create_pkcs8_encrypt (3)

  • PKCS5_pbe_set0_algor (3), PKCS5_pbe_set (3), PKCS5_pbe2_set_iv (3), PKCS5_pbkdf2_set (3) and PKCS5_v2_scrypt_keyivgen (3)

  • PKCS7_encrypt (3), PKCS7_new (3) and PKCS7_sign (3)

  • PKCS8_decrypt (3), PKCS8_encrypt (3) and PKCS8_set0_pbe (3)

  • RAND_bytes (3) and RAND_priv_bytes (3)

  • SMIME_write_ASN1 (3)

  • SSL_load_client_CA_file (3)

  • SSL_CTX_new (3)

  • TS_RESP_CTX_new (3)

  • X509_CRL_new (3)

  • X509_load_cert_crl_file (3) and X509_load_cert_file (3)

  • X509_LOOKUP_by_subject (3) and X509_LOOKUP_ctrl (3)

  • X509_NAME_hash (3)

  • X509_new (3)

  • X509_REQ_new (3) and X509_REQ_verify (3)

  • X509_STORE_CTX_new (3), X509_STORE_set_default_paths (3), X509_STORE_load_file (3), X509_STORE_load_locations (3) and X509_STORE_load_store (3)

New functions that use a Library context

The following functions can be passed a library context if required. Passing NULL will use the default library context.

  • BIO_new_from_core_bio (3)

  • EVP_ASYM_CIPHER_fetch (3) and EVP_ASYM_CIPHER_do_all_provided (3)

  • EVP_CIPHER_fetch (3) and EVP_CIPHER_do_all_provided (3)

  • EVP_default_properties_enable_fips (3) and EVP_default_properties_is_fips_enabled (3)

  • EVP_KDF_fetch (3) and EVP_KDF_do_all_provided (3)

  • EVP_KEM_fetch (3) and EVP_KEM_do_all_provided (3)

  • EVP_KEYEXCH_fetch (3) and EVP_KEYEXCH_do_all_provided (3)

  • EVP_KEYMGMT_fetch (3) and EVP_KEYMGMT_do_all_provided (3)

  • EVP_MAC_fetch (3) and EVP_MAC_do_all_provided (3)

  • EVP_MD_fetch (3) and EVP_MD_do_all_provided (3)

  • EVP_PKEY_CTX_new_from_pkey (3)

  • EVP_PKEY_Q_keygen (3)

  • EVP_Q_mac (3) and EVP_Q_digest (3)

  • EVP_RAND (3) and EVP_RAND_do_all_provided (3)

  • EVP_set_default_properties (3)

  • EVP_SIGNATURE_fetch (3) and EVP_SIGNATURE_do_all_provided (3)

  • OSSL_CMP_CTX_new (3) and OSSL_CMP_SRV_CTX_new (3)

  • OSSL_CRMF_ENCRYPTEDVALUE_get1_encCert (3)

  • OSSL_CRMF_MSG_create_popo (3) and OSSL_CRMF_MSGS_verify_popo (3)

  • OSSL_CRMF_pbm_new (3) and OSSL_CRMF_pbmp_new (3)

  • OSSL_DECODER_CTX_add_extra (3) and OSSL_DECODER_CTX_new_for_pkey (3)

  • OSSL_DECODER_fetch (3) and OSSL_DECODER_do_all_provided (3)

  • OSSL_ENCODER_CTX_add_extra (3)

  • OSSL_ENCODER_fetch (3) and OSSL_ENCODER_do_all_provided (3)

  • OSSL_LIB_CTX_free (3), OSSL_LIB_CTX_load_config (3) and OSSL_LIB_CTX_set0_default (3)

  • OSSL_PROVIDER_add_builtin (3), OSSL_PROVIDER_available (3), OSSL_PROVIDER_do_all (3), OSSL_PROVIDER_load (3), OSSL_PROVIDER_set_default_search_path (3) and OSSL_PROVIDER_try_load (3)

  • OSSL_SELF_TEST_get_callback (3) and OSSL_SELF_TEST_set_callback (3)

  • OSSL_STORE_attach (3)

  • OSSL_STORE_LOADER_fetch (3) and OSSL_STORE_LOADER_do_all_provided (3)

  • RAND_get0_primary (3), RAND_get0_private (3), RAND_get0_public (3), RAND_set_DRBG_type (3) and RAND_set_seed_source_type (3)

Providers

Providers are described in detail here “Providers” in crypto (7). See also “OPENSSL PROVIDERS” in crypto (7).

Fetching algorithms and property queries

Implicit and Explicit Fetching is described in detail here “ALGORITHM FETCHING” in crypto (7).

Mapping EVP controls and flags to provider OSSL_PARAM (3) parameters

The existing functions for controls (such as EVP_CIPHER_CTX_ctrl (3)) and manipulating flags (such as EVP_MD_CTX_set_flags (3))internally use OSSL_PARAMS to pass information to/from provider objects. See OSSL_PARAM (3) for additional information related to parameters.

For ciphers see “CONTROLS” in EVP_EncryptInit (3), “FLAGS” in EVP_EncryptInit (3) and “PARAMETERS” in EVP_EncryptInit (3).

For digests see “CONTROLS” in EVP_DigestInit (3), “FLAGS” in EVP_DigestInit (3) and “PARAMETERS” in EVP_DigestInit (3).

Deprecation of Low Level Functions

A significant number of APIs have been deprecated in OpenSSL 3.0. This section describes some common categories of deprecations. See “Deprecated function mappings” for the list of deprecated functions that refer to these categories.

Providers are a replacement for engines and low-level method overrides

Any accessor that uses an ENGINE is deprecated (such as EVP_PKEY_set1_engine()). Applications using engines should instead use providers.

Before providers were added algorithms were overridden by changing the methods used by algorithms. All these methods such as RSA_new_method() and RSA_meth_new() are now deprecated and can be replaced by using providers instead.

Deprecated i2d and d2i functions for low-level key types

Any i2d and d2i functions such as d2i_DHparams() that take a low-level key type have been deprecated. Applications should instead use the OSSL_DECODER (3) and OSSL_ENCODER (3) APIs to read and write files. See “Migration” in d2i_RSAPrivateKey (3) for further details.

Deprecated low-level key object getters and setters

Applications that set or get low-level key objects (such as EVP_PKEY_set1_DH() or EVP_PKEY_get0()) should instead use the OSSL_ENCODER (See OSSL_ENCODER_to_bio (3)) or OSSL_DECODER (See OSSL_DECODER_from_bio (3)) APIs, or alternatively use EVP_PKEY_fromdata (3) or EVP_PKEY_todata (3).

Deprecated low-level key parameter getters

Functions that access low-level objects directly such as RSA_get0_n (3) are now deprecated. Applications should use one of EVP_PKEY_get_bn_param (3), EVP_PKEY_get_int_param (3), l<EVP_PKEY_get_size_t_param (3)>, EVP_PKEY_get_utf8_string_param (3), EVP_PKEY_get_octet_string_param (3) or EVP_PKEY_get_params (3) to access fields from an EVP_PKEY. Gettable parameters are listed in “Common RSA parameters” in EVP_PKEY-RSA (7), “DH parameters” in EVP_PKEY-DH (7), “DSA parameters” in EVP_PKEY-DSA (7), “FFC parameters” in EVP_PKEY-FFC (7), “Common EC parameters” in EVP_PKEY-EC (7) and “Common X25519, X448, ED25519 and ED448 parameters” in EVP_PKEY-X25519 (7). Applications may also use EVP_PKEY_todata (3) to return all fields.

Deprecated low-level key parameter setters

Functions that access low-level objects directly such as RSA_set0_crt_params (3) are now deprecated. Applications should use EVP_PKEY_fromdata (3) to create new keys from user provided key data. Keys should be immutable once they are created, so if required the user may use EVP_PKEY_todata (3), OSSL_PARAM_merge (3), and EVP_PKEY_fromdata (3) to create a modified key. See “Examples” in EVP_PKEY-DH (7) for more information. See “Deprecated low-level key generation functions” for information on generating a key using parameters.

Deprecated low-level object creation

Low-level objects were created using methods such as RSA_new (3), RSA_up_ref (3) and RSA_free (3). Applications should instead use the high-level EVP_PKEY APIs, e.g. EVP_PKEY_new (3), EVP_PKEY_up_ref (3) and EVP_PKEY_free (3). See also EVP_PKEY_CTX_new_from_name (3) and EVP_PKEY_CTX_new_from_pkey (3).

EVP_PKEYs may be created in a variety of ways: See also “Deprecated low-level key generation functions”, “Deprecated low-level key reading and writing functions” and “Deprecated low-level key parameter setters”.

Deprecated low-level encryption functions

Low-level encryption functions such as AES_encrypt (3) and AES_decrypt (3) have been informally discouraged from use for a long time. Applications should instead use the high level EVP APIs EVP_EncryptInit_ex (3), EVP_EncryptUpdate (3), and EVP_EncryptFinal_ex (3) or EVP_DecryptInit_ex (3), EVP_DecryptUpdate (3) and EVP_DecryptFinal_ex (3).

Deprecated low-level digest functions

Use of low-level digest functions such as SHA1_Init (3) have been informally discouraged from use for a long time. Applications should instead use the the high level EVP APIs EVP_DigestInit_ex (3), EVP_DigestUpdate (3) and EVP_DigestFinal_ex (3), or the quick one-shot EVP_Q_digest (3).

Note that the functions SHA1 (3), SHA224 (3), SHA256 (3), SHA384 (3) and SHA512 (3) have changed to macros that use EVP_Q_digest (3).

Deprecated low-level signing functions

Use of low-level signing functions such as DSA_sign (3) have been informally discouraged for a long time. Instead applications should use EVP_DigestSign (3) and EVP_DigestVerify (3). See also EVP_SIGNATURE-RSA (7), EVP_SIGNATURE-DSA (7), EVP_SIGNATURE-ECDSA (7) and EVP_SIGNATURE-ED25519 (7).

Deprecated low-level MAC functions

Low-level mac functions such as CMAC_Init (3) are deprecated. Applications should instead use the new EVP_MAC (3) interface, using EVP_MAC_CTX_new (3), EVP_MAC_CTX_free (3), EVP_MAC_init (3), EVP_MAC_update (3) and EVP_MAC_final (3) or the single-shot MAC function EVP_Q_mac (3). See EVP_MAC (3), EVP_MAC-HMAC (7), EVP_MAC-CMAC (7), EVP_MAC-GMAC (7), EVP_MAC-KMAC (7), EVP_MAC-BLAKE2 (7), EVP_MAC-Poly1305 (7) and EVP_MAC-Siphash (7) for additional information.

Note that the one-shot method HMAC() is still available for compatibility purposes, but this can also be replaced by using EVP_Q_MAC if a library context is required.

Deprecated low-level validation functions

Low-level validation functions such as DH_check (3) have been informally discouraged from use for a long time. Applications should instead use the high-level EVP_PKEY APIs such as EVP_PKEY_check (3), EVP_PKEY_param_check (3), EVP_PKEY_param_check_quick (3), EVP_PKEY_public_check (3), EVP_PKEY_public_check_quick (3), EVP_PKEY_private_check (3), and EVP_PKEY_pairwise_check (3).

Deprecated low-level key exchange functions

Many low-level functions have been informally discouraged from use for a long time. Applications should instead use EVP_PKEY_derive (3). See EVP_KEYEXCH-DH (7), EVP_KEYEXCH-ECDH (7) and EVP_KEYEXCH-X25519 (7).

Deprecated low-level key generation functions

Many low-level functions have been informally discouraged from use for a long time. Applications should instead use EVP_PKEY_keygen_init (3) and EVP_PKEY_generate (3) as described in EVP_PKEY-DSA (7), EVP_PKEY-DH (7), EVP_PKEY-RSA (7), EVP_PKEY-EC (7) and EVP_PKEY-X25519 (7). The ‘quick’ one-shot function EVP_PKEY_Q_keygen (3) and macros for the most common cases: <EVP_RSA_gen (3)> and EVP_EC_gen (3) may also be used.

Deprecated low-level key reading and writing functions

Use of low-level objects (such as DSA) has been informally discouraged from use for a long time. Functions to read and write these low-level objects (such as PEM_read_DSA_PUBKEY()) should be replaced. Applications should instead use OSSL_ENCODER_to_bio (3) and OSSL_DECODER_from_bio (3).

Deprecated low-level key printing functions

Use of low-level objects (such as DSA) has been informally discouraged from use for a long time. Functions to print these low-level objects such as DSA_print() should be replaced with the equivalent EVP_PKEY functions. Application should use one of EVP_PKEY_print_public (3), EVP_PKEY_print_private (3), EVP_PKEY_print_params (3), EVP_PKEY_print_public_fp (3), EVP_PKEY_print_private_fp (3) or EVP_PKEY_print_params_fp (3). Note that internally these use OSSL_ENCODER_to_bio (3) and OSSL_DECODER_from_bio (3).

Deprecated function mappings

The following functions have been deprecated in 3.0.

  • AES_bi_ige_encrypt() and AES_ige_encrypt() There is no replacement for the IGE functions. New code should not use these modes. These undocumented functions were never integrated into the EVP layer. They implemented the AES Infinite Garble Extension (IGE) mode and AES Bi-directional IGE mode. These modes were never formally standardised and usage of these functions is believed to be very small. In particular AES_bi_ige_encrypt() has a known bug. It accepts 2 AES keys, but only one is ever used. The security implications are believed to be minimal, but this issue was never fixed for backwards compatibility reasons.

  • AES_encrypt(), AES_decrypt(), AES_set_encrypt_key(), AES_set_decrypt_key(), AES_cbc_encrypt(), AES_cfb128_encrypt(), AES_cfb1_encrypt(), AES_cfb8_encrypt(), AES_ecb_encrypt(), AES_ofb128_encrypt()

  • AES_unwrap_key(), AES_wrap_key() See “Deprecated low-level encryption functions”

  • AES_options() There is no replacement. It returned a string indicating if the AES code was unrolled.

  • ASN1_digest(), ASN1_sign(), ASN1_verify() There are no replacements. These old functions are not used, and could be disabled with the macro NO_ASN1_OLD since OpenSSL 0.9.7.

  • ASN1_STRING_length_set() Use ASN1_STRING_set (3) or ASN1_STRING_set0 (3) instead. This was a potentially unsafe function that could change the bounds of a previously passed in pointer.

  • BF_encrypt(), BF_decrypt(), BF_set_key(), BF_cbc_encrypt(), BF_cfb64_encrypt(), BF_ecb_encrypt(), BF_ofb64_encrypt() See “Deprecated low-level encryption functions”. The Blowfish algorithm has been moved to the Legacy Provider.

  • BF_options() There is no replacement. This option returned a constant string.

  • BIO_get_callback(), BIO_set_callback(), BIO_debug_callback() Use the respective non-deprecated _ex() functions.

  • BN_is_prime_ex(), BN_is_prime_fasttest_ex() Use BN_check_prime (3) which avoids possible misuse and always uses at least 64 rounds of the Miller-Rabin primality test.

  • BN_pseudo_rand(), BN_pseudo_rand_range() Use BN_rand (3) and BN_rand_range (3).

  • BN_X931_derive_prime_ex(), BN_X931_generate_prime_ex(), BN_X931_generate_Xpq() There are no replacements for these low-level functions. They were used internally by RSA_X931_derive_ex() and RSA_X931_generate_key_ex() which are also deprecated. Use EVP_PKEY_keygen (3) instead.

  • Camellia_encrypt(), Camellia_decrypt(), Camellia_set_key(), Camellia_cbc_encrypt(), Camellia_cfb128_encrypt(), Camellia_cfb1_encrypt(), Camellia_cfb8_encrypt(), Camellia_ctr128_encrypt(), Camellia_ecb_encrypt(), Camellia_ofb128_encrypt() See “Deprecated low-level encryption functions”.

  • CAST_encrypt(), CAST_decrypt(), CAST_set_key(), CAST_cbc_encrypt(), CAST_cfb64_encrypt(), CAST_ecb_encrypt(), CAST_ofb64_encrypt() See “Deprecated low-level encryption functions”. The CAST algorithm has been moved to the Legacy Provider.

  • CMAC_CTX_new(), CMAC_CTX_cleanup(), CMAC_CTX_copy(), CMAC_CTX_free(), CMAC_CTX_get0_cipher_ctx() See “Deprecated low-level MAC functions”.

  • CMAC_Init(), CMAC_Update(), CMAC_Final(), CMAC_resume() See “Deprecated low-level MAC functions”.

  • CRYPTO_mem_ctrl(), CRYPTO_mem_debug_free(), CRYPTO_mem_debug_malloc(), CRYPTO_mem_debug_pop(), CRYPTO_mem_debug_push(), CRYPTO_mem_debug_realloc(), CRYPTO_mem_leaks(), CRYPTO_mem_leaks_cb(), CRYPTO_mem_leaks_fp(), CRYPTO_set_mem_debug() Memory-leak checking has been deprecated in favor of more modern development tools, such as compiler memory and leak sanitizers or Valgrind.

  • CRYPTO_cts128_encrypt_block(), CRYPTO_cts128_encrypt(), CRYPTO_cts128_decrypt_block(), CRYPTO_cts128_decrypt(), CRYPTO_nistcts128_encrypt_block(), CRYPTO_nistcts128_encrypt(), CRYPTO_nistcts128_decrypt_block(), CRYPTO_nistcts128_decrypt() Use the higher level functions EVP_CipherInit_ex2(), EVP_CipherUpdate() and EVP_CipherFinal_ex() instead. See the “cts_mode” parameter in “Gettable and Settable EVP_CIPHER_CTX parameters” in EVP_EncryptInit (3). See “EXAMPLES” in EVP_EncryptInit (3) for a AES-256-CBC-CTS example.

  • d2i_DHparams(), d2i_DHxparams(), d2i_DSAparams(), d2i_DSAPrivateKey(), d2i_DSAPrivateKey_bio(), d2i_DSAPrivateKey_fp(), d2i_DSA_PUBKEY(), d2i_DSA_PUBKEY_bio(), d2i_DSA_PUBKEY_fp(), d2i_DSAPublicKey(), d2i_ECParameters(), d2i_ECPrivateKey(), d2i_ECPrivateKey_bio(), d2i_ECPrivateKey_fp(), d2i_EC_PUBKEY(), d2i_EC_PUBKEY_bio(), d2i_EC_PUBKEY_fp(), d2i_RSAPrivateKey(), d2i_RSAPrivateKey_bio(), d2i_RSAPrivateKey_fp(), d2i_RSA_PUBKEY(), d2i_RSA_PUBKEY_bio(), d2i_RSA_PUBKEY_fp(), d2i_RSAPublicKey(), d2i_RSAPublicKey_bio(), d2i_RSAPublicKey_fp() See “Deprecated i2d and d2i functions for low-level key types”

  • o2i_ECPublicKey() Use EVP_PKEY_set1_encoded_public_key (3). See “Deprecated low-level key parameter setters”

  • DES_crypt(), DES_fcrypt(), DES_encrypt1(), DES_encrypt2(), DES_encrypt3(), DES_decrypt3(), DES_ede3_cbc_encrypt(), DES_ede3_cfb64_encrypt(), DES_ede3_cfb_encrypt(),DES_ede3_ofb64_encrypt(), DES_ecb_encrypt(), DES_ecb3_encrypt(), DES_ofb64_encrypt(), DES_ofb_encrypt(), DES_cfb64_encrypt DES_cfb_encrypt(), DES_cbc_encrypt(), DES_ncbc_encrypt(), DES_pcbc_encrypt(), DES_xcbc_encrypt(), DES_cbc_cksum(), DES_quad_cksum(), DES_check_key_parity(), DES_is_weak_key(), DES_key_sched(), DES_options(), DES_random_key(), DES_set_key(), DES_set_key_checked(), DES_set_key_unchecked(), DES_set_odd_parity(), DES_string_to_2keys(), DES_string_to_key() See “Deprecated low-level encryption functions”. Algorithms for “DESX-CBC”, “DES-ECB”, “DES-CBC”, “DES-OFB”, “DES-CFB”, “DES-CFB1” and “DES-CFB8” have been moved to the Legacy Provider.

  • DH_bits(), DH_security_bits(), DH_size() Use EVP_PKEY_get_bits (3), EVP_PKEY_get_security_bits (3) and EVP_PKEY_get_size (3).

  • DH_check(), DH_check_ex(), DH_check_params(), DH_check_params_ex(), DH_check_pub_key(), DH_check_pub_key_ex() See “Deprecated low-level validation functions”

  • DH_clear_flags(), DH_test_flags(), DH_set_flags() The DH_FLAG_CACHE_MONT_P flag has been deprecated without replacement. The DH_FLAG_TYPE_DH and DH_FLAG_TYPE_DHX have been deprecated. Use EVP_PKEY_is_a() to determine the type of a key. There is no replacement for setting these flags.

  • DH_compute_key() DH_compute_key_padded() See “Deprecated low-level key exchange functions”.

  • DH_new(), DH_new_by_nid(), DH_free(), DH_up_ref() See “Deprecated low-level object creation”

  • DH_generate_key(), DH_generate_parameters_ex() See “Deprecated low-level key generation functions”.

  • DH_get0_pqg(), DH_get0_p(), DH_get0_q(), DH_get0_g(), DH_get0_key(), DH_get0_priv_key(), DH_get0_pub_key(), DH_get_length(), DH_get_nid() See “Deprecated low-level key parameter getters”

  • DH_get_1024_160(), DH_get_2048_224(), DH_get_2048_256() Applications should instead set the OSSL_PKEY_PARAM_GROUP_NAME as specified in “DH parameters” in EVP_PKEY-DH (7)) to one of “dh_1024_160”, “dh_2048_224” or “dh_2048_256” when generating a DH key.

  • DH_KDF_X9_42() Applications should use EVP_PKEY_CTX_set_dh_kdf_type (3) instead.

  • DH_get_default_method(), DH_get0_engine(), DH_meth_*(), DH_new_method(), DH_OpenSSL(), DH_get_ex_data(), DH_set_default_method(), DH_set_method(), DH_set_ex_data() See “Providers are a replacement for engines and low-level method overrides”

  • DHparams_print(), DHparams_print_fp() See “Deprecated low-level key printing functions”

  • DH_set0_key(), DH_set0_pqg(), DH_set_length() See “Deprecated low-level key parameter setters”

  • DSA_bits(), DSA_security_bits(), DSA_size() Use EVP_PKEY_get_bits (3), EVP_PKEY_get_security_bits (3) and EVP_PKEY_get_size (3).

  • DHparams_dup(), DSA_dup_DH() There is no direct replacement. Applications may use EVP_PKEY_copy_parameters (3) and EVP_PKEY_dup (3) instead.

  • DSA_generate_key(), DSA_generate_parameters_ex() See “Deprecated low-level key generation functions”.

  • DSA_get0_engine(), DSA_get_default_method(), DSA_get_ex_data(), DSA_get_method(), DSA_meth_*(), DSA_new_method(), DSA_OpenSSL(), DSA_set_default_method(), DSA_set_ex_data(), DSA_set_method() See “Providers are a replacement for engines and low-level method overrides”.

  • DSA_get0_p(), DSA_get0_q(), DSA_get0_g(), DSA_get0_pqg(), DSA_get0_key(), DSA_get0_priv_key(), DSA_get0_pub_key() See “Deprecated low-level key parameter getters”.

  • DSA_new(), DSA_free(), DSA_up_ref() See “Deprecated low-level object creation”

  • DSAparams_dup() There is no direct replacement. Applications may use EVP_PKEY_copy_parameters (3) and EVP_PKEY_dup (3) instead.

  • DSAparams_print(), DSAparams_print_fp(), DSA_print(), DSA_print_fp() See “Deprecated low-level key printing functions”

  • DSA_set0_key(), DSA_set0_pqg() See “Deprecated low-level key parameter setters”

  • DSA_set_flags(), DSA_clear_flags(), DSA_test_flags() The DSA_FLAG_CACHE_MONT_P flag has been deprecated without replacement.

  • DSA_sign(), DSA_do_sign(), DSA_sign_setup(), DSA_verify(), DSA_do_verify() See “Deprecated low-level signing functions”.

  • ECDH_compute_key() See “Deprecated low-level key exchange functions”.

  • ECDH_KDF_X9_62() Applications may either set this using the helper function EVP_PKEY_CTX_set_ecdh_kdf_type (3) or by setting an OSSL_PARAM (3) using the “kdf-type” as shown in “EXAMPLES” in EVP_KEYEXCH-ECDH (7)

  • ECDSA_sign(), ECDSA_sign_ex(), ECDSA_sign_setup(), ECDSA_do_sign(), ECDSA_do_sign_ex(), ECDSA_verify(), ECDSA_do_verify() See “Deprecated low-level signing functions”.

  • ECDSA_size() Applications should use EVP_PKEY_get_size (3).

  • EC_GF2m_simple_method(), EC_GFp_mont_method(), EC_GFp_nist_method(), EC_GFp_nistp224_method(), EC_GFp_nistp256_method(), EC_GFp_nistp521_method(), EC_GFp_simple_method() There are no replacements for these functions. Applications should rely on the library automatically assigning a suitable method internally when an EC_GROUP is constructed.

  • EC_GROUP_clear_free() Use EC_GROUP_free (3) instead.

  • EC_GROUP_get_curve_GF2m(), EC_GROUP_get_curve_GFp(), EC_GROUP_set_curve_GF2m(), EC_GROUP_set_curve_GFp() Applications should use EC_GROUP_get_curve (3) and EC_GROUP_set_curve (3).

  • EC_GROUP_have_precompute_mult(), EC_GROUP_precompute_mult(), EC_KEY_precompute_mult() These functions are not widely used. Applications should instead switch to named curves which OpenSSL has hardcoded lookup tables for.

  • EC_GROUP_new(), EC_GROUP_method_of(), EC_POINT_method_of() EC_METHOD is now an internal-only concept and a suitable EC_METHOD is assigned internally without application intervention. Users of EC_GROUP_new() should switch to a different suitable constructor.

  • EC_KEY_can_sign() Applications should use EVP_PKEY_can_sign (3) instead.

  • EC_KEY_check_key() See “Deprecated low-level validation functions”

  • EC_KEY_set_flags(), EC_KEY_get_flags(), EC_KEY_clear_flags() See “Common EC parameters” in EVP_PKEY-EC (7) which handles flags as separate parameters for OSSL_PKEY_PARAM_EC_POINT_CONVERSION_FORMAT, OSSL_PKEY_PARAM_EC_GROUP_CHECK_TYPE, OSSL_PKEY_PARAM_EC_ENCODING, OSSL_PKEY_PARAM_USE_COFACTOR_ECDH and OSSL_PKEY_PARAM_EC_INCLUDE_PUBLIC. See also “EXAMPLES” in EVP_PKEY-EC (7)

  • EC_KEY_dup(), EC_KEY_copy() There is no direct replacement. Applications may use EVP_PKEY_copy_parameters (3) and EVP_PKEY_dup (3) instead.

  • EC_KEY_decoded_from_explicit_params() There is no replacement.

  • EC_KEY_generate_key() See “Deprecated low-level key generation functions”.

  • EC_KEY_get0_group(), EC_KEY_get0_private_key(), EC_KEY_get0_public_key(), EC_KEY_get_conv_form(), EC_KEY_get_enc_flags() See “Deprecated low-level key parameter getters”.

  • EC_KEY_get0_engine(), EC_KEY_get_default_method(), EC_KEY_get_method(), EC_KEY_new_method(), EC_KEY_get_ex_data(), EC_KEY_OpenSSL(), EC_KEY_set_ex_data(), EC_KEY_set_default_method(), EC_KEY_METHOD_*(), EC_KEY_set_method() See “Providers are a replacement for engines and low-level method overrides”

  • EC_METHOD_get_field_type() Use EC_GROUP_get_field_type (3) instead. See “Providers are a replacement for engines and low-level method overrides”

  • EC_KEY_key2buf(), EC_KEY_oct2key(), EC_KEY_oct2priv(), EC_KEY_priv2buf(), EC_KEY_priv2oct() There are no replacements for these.

  • EC_KEY_new(), EC_KEY_new_by_curve_name(), EC_KEY_free(), EC_KEY_up_ref() See “Deprecated low-level object creation”

  • EC_KEY_print(), EC_KEY_print_fp() See “Deprecated low-level key printing functions”

  • EC_KEY_set_asn1_flag(), EC_KEY_set_conv_form(), EC_KEY_set_enc_flags() See “Deprecated low-level key parameter setters”.

  • EC_KEY_set_group(), EC_KEY_set_private_key(), EC_KEY_set_public_key(), EC_KEY_set_public_key_affine_coordinates() See “Deprecated low-level key parameter setters”.

  • ECParameters_print(), ECParameters_print_fp(), ECPKParameters_print(), ECPKParameters_print_fp() See “Deprecated low-level key printing functions”

  • EC_POINT_bn2point(), EC_POINT_point2bn() These functions were not particularly useful, since EC point serialization formats are not individual big-endian integers.

  • EC_POINT_get_affine_coordinates_GF2m(), EC_POINT_get_affine_coordinates_GFp(), EC_POINT_set_affine_coordinates_GF2m(), EC_POINT_set_affine_coordinates_GFp() Applications should use EC_POINT_get_affine_coordinates (3) and EC_POINT_set_affine_coordinates (3) instead.

  • EC_POINT_get_Jprojective_coordinates_GFp(), EC_POINT_set_Jprojective_coordinates_GFp() These functions are not widely used. Applications should instead use the EC_POINT_set_affine_coordinates (3) and EC_POINT_get_affine_coordinates (3) functions.

  • EC_POINT_make_affine(), EC_POINTs_make_affine() There is no replacement. These functions were not widely used, and OpenSSL automatically performs this conversion when needed.

  • EC_POINT_set_compressed_coordinates_GF2m(), EC_POINT_set_compressed_coordinates_GFp() Applications should use EC_POINT_set_compressed_coordinates (3) instead.

  • EC_POINTs_mul() This function is not widely used. Applications should instead use the EC_POINT_mul (3) function.

  • ENGINE_*() All engine functions are deprecated. An engine should be rewritten as a provider. See “Providers are a replacement for engines and low-level method overrides”.

  • ERR_load_*(), ERR_func_error_string(), ERR_get_error_line(), ERR_get_error_line_data(), ERR_get_state() OpenSSL now loads error strings automatically so these functions are not needed.

  • ERR_peek_error_line_data(), ERR_peek_last_error_line_data() The new functions are ERR_peek_error_func (3), ERR_peek_last_error_func (3), ERR_peek_error_data (3), ERR_peek_last_error_data (3), ERR_get_error_all (3), ERR_peek_error_all (3) and ERR_peek_last_error_all (3). Applications should use ERR_get_error_all (3), or pick information with ERR_peek functions and finish off with getting the error code by using ERR_get_error (3).

  • EVP_CIPHER_CTX_iv(), EVP_CIPHER_CTX_iv_noconst(), EVP_CIPHER_CTX_original_iv() Applications should instead use EVP_CIPHER_CTX_get_updated_iv (3), EVP_CIPHER_CTX_get_updated_iv (3) and EVP_CIPHER_CTX_get_original_iv (3) respectively. See EVP_CIPHER_CTX_get_original_iv (3) for further information.

  • EVP_CIPHER_meth_*(), EVP_MD_CTX_set_update_fn(), EVP_MD_CTX_update_fn(), EVP_MD_meth_*() See “Providers are a replacement for engines and low-level method overrides”.

  • EVP_PKEY_CTRL_PKCS7_ENCRYPT(), EVP_PKEY_CTRL_PKCS7_DECRYPT(), EVP_PKEY_CTRL_PKCS7_SIGN(), EVP_PKEY_CTRL_CMS_ENCRYPT(), EVP_PKEY_CTRL_CMS_DECRYPT(), and EVP_PKEY_CTRL_CMS_SIGN() These control operations are not invoked by the OpenSSL library anymore and are replaced by direct checks of the key operation against the key type when the operation is initialized.

  • EVP_PKEY_CTX_get0_dh_kdf_ukm(), EVP_PKEY_CTX_get0_ecdh_kdf_ukm() See the “kdf-ukm” item in “DH key exchange parameters” in EVP_KEYEXCH-DH (7) and “ECDH Key Exchange parameters” in EVP_KEYEXCH-ECDH (7). These functions are obsolete and should not be required.

  • EVP_PKEY_CTX_set_rsa_keygen_pubexp() Applications should use EVP_PKEY_CTX_set1_rsa_keygen_pubexp (3) instead.

  • EVP_PKEY_cmp(), EVP_PKEY_cmp_parameters() Applications should use EVP_PKEY_eq (3) and EVP_PKEY_parameters_eq (3) instead. See EVP_PKEY_copy_parameters (3) for further details.

  • EVP_PKEY_encrypt_old(), EVP_PKEY_decrypt_old(), Applications should use EVP_PKEY_encrypt_init (3) and EVP_PKEY_encrypt (3) or EVP_PKEY_decrypt_init (3) and EVP_PKEY_decrypt (3) instead.

  • EVP_PKEY_get0() This function returns NULL if the key comes from a provider.

  • EVP_PKEY_get0_DH(), EVP_PKEY_get0_DSA(), EVP_PKEY_get0_EC_KEY(), EVP_PKEY_get0_RSA(), EVP_PKEY_get1_DH(), EVP_PKEY_get1_DSA(), EVP_PKEY_get1_EC_KEY and EVP_PKEY_get1_RSA(), EVP_PKEY_get0_hmac(), EVP_PKEY_get0_poly1305(), EVP_PKEY_get0_siphash() See “Functions that return an internal key should be treated as read only”.

  • EVP_PKEY_meth_*() See “Providers are a replacement for engines and low-level method overrides”.

  • EVP_PKEY_new_CMAC_key() See “Deprecated low-level MAC functions”.

  • EVP_PKEY_assign(), EVP_PKEY_set1_DH(), EVP_PKEY_set1_DSA(), EVP_PKEY_set1_EC_KEY(), EVP_PKEY_set1_RSA() See “Deprecated low-level key object getters and setters”

  • EVP_PKEY_set1_tls_encodedpoint() EVP_PKEY_get1_tls_encodedpoint() These functions were previously used by libssl to set or get an encoded public key into/from an EVP_PKEY object. With OpenSSL 3.0 these are replaced by the more generic functions EVP_PKEY_set1_encoded_public_key (3) and EVP_PKEY_get1_encoded_public_key (3). The old versions have been converted to deprecated macros that just call the new functions.

  • EVP_PKEY_set1_engine(), EVP_PKEY_get0_engine() See “Providers are a replacement for engines and low-level method overrides”.

  • EVP_PKEY_set_alias_type() This function has been removed. There is no replacement. See “EVP_PKEY_set_alias_type() method has been removed”

  • HMAC_Init_ex(), HMAC_Update(), HMAC_Final(), HMAC_size() See “Deprecated low-level MAC functions”.

  • HMAC_CTX_new(), HMAC_CTX_free(), HMAC_CTX_copy(), HMAC_CTX_reset(), HMAC_CTX_set_flags(), HMAC_CTX_get_md() See “Deprecated low-level MAC functions”.

  • i2d_DHparams(), i2d_DHxparams() See “Deprecated low-level key reading and writing functions” and “Migration” in d2i_RSAPrivateKey (3)

  • i2d_DSAparams(), i2d_DSAPrivateKey(), i2d_DSAPrivateKey_bio(), i2d_DSAPrivateKey_fp(), i2d_DSA_PUBKEY(), i2d_DSA_PUBKEY_bio(), i2d_DSA_PUBKEY_fp(), i2d_DSAPublicKey() See “Deprecated low-level key reading and writing functions” and “Migration” in d2i_RSAPrivateKey (3)

  • i2d_ECParameters(), i2d_ECPrivateKey(), i2d_ECPrivateKey_bio(), i2d_ECPrivateKey_fp(), i2d_EC_PUBKEY(), i2d_EC_PUBKEY_bio(), i2d_EC_PUBKEY_fp() See “Deprecated low-level key reading and writing functions” and “Migration” in d2i_RSAPrivateKey (3)

  • i2o_ECPublicKey() Use EVP_PKEY_get1_encoded_public_key (3). See “Deprecated low-level key parameter getters”

  • i2d_RSAPrivateKey(), i2d_RSAPrivateKey_bio(), i2d_RSAPrivateKey_fp(), i2d_RSA_PUBKEY(), i2d_RSA_PUBKEY_bio(), i2d_RSA_PUBKEY_fp(), i2d_RSAPublicKey(), i2d_RSAPublicKey_bio(), i2d_RSAPublicKey_fp() See “Deprecated low-level key reading and writing functions” and “Migration” in d2i_RSAPrivateKey (3)

  • IDEA_encrypt(), IDEA_set_decrypt_key(), IDEA_set_encrypt_key(), IDEA_cbc_encrypt(), IDEA_cfb64_encrypt(), IDEA_ecb_encrypt(), IDEA_ofb64_encrypt() See “Deprecated low-level encryption functions”. IDEA has been moved to the Legacy Provider.

  • IDEA_options() There is no replacement. This function returned a constant string.

  • MD2(), MD2_Init(), MD2_Update(), MD2_Final() See “Deprecated low-level encryption functions”. MD2 has been moved to the Legacy Provider.

  • MD2_options() There is no replacement. This function returned a constant string.

  • MD4(), MD4_Init(), MD4_Update(), MD4_Final(), MD4_Transform() See “Deprecated low-level encryption functions”. MD4 has been moved to the Legacy Provider.

  • MDC2(), MDC2_Init(), MDC2_Update(), MDC2_Final() See “Deprecated low-level encryption functions”. MDC2 has been moved to the Legacy Provider.

  • MD5(), MD5_Init(), MD5_Update(), MD5_Final(), MD5_Transform() See “Deprecated low-level encryption functions”.

  • NCONF_WIN32() This undocumented function has no replacement. See “HISTORY” in config (5) for more details.

  • OCSP_parse_url() Use OSSL_HTTP_parse_url (3) instead.

  • OCSP_REQ_CTX type and OCSP_REQ_CTX_*() functions These methods were used to collect all necessary data to form a HTTP request, and to perform the HTTP transfer with that request. With OpenSSL 3.0, the type is OSSL_HTTP_REQ_CTX, and the deprecated functions are replaced with OSSL_HTTP_REQ_CTX_*(). See OSSL_HTTP_REQ_CTX (3) for additional details.

  • OPENSSL_fork_child(), OPENSSL_fork_parent(), OPENSSL_fork_prepare() There is no replacement for these functions. These pthread fork support methods were unused by OpenSSL.

  • OSSL_STORE_ctrl(), OSSL_STORE_do_all_loaders(), OSSL_STORE_LOADER_get0_engine(), OSSL_STORE_LOADER_get0_scheme(), OSSL_STORE_LOADER_new(), OSSL_STORE_LOADER_set_attach(), OSSL_STORE_LOADER_set_close(), OSSL_STORE_LOADER_set_ctrl(), OSSL_STORE_LOADER_set_eof(), OSSL_STORE_LOADER_set_error(), OSSL_STORE_LOADER_set_expect(), OSSL_STORE_LOADER_set_find(), OSSL_STORE_LOADER_set_load(), OSSL_STORE_LOADER_set_open(), OSSL_STORE_LOADER_set_open_ex(), OSSL_STORE_register_loader(), OSSL_STORE_unregister_loader(), OSSL_STORE_vctrl() These functions helped applications and engines create loaders for schemes they supported. These are all deprecated and discouraged in favour of provider implementations, see provider-storemgmt (7).

  • PEM_read_DHparams(), PEM_read_bio_DHparams(), PEM_read_DSAparams(), PEM_read_bio_DSAparams(), PEM_read_DSAPrivateKey(), PEM_read_DSA_PUBKEY(), PEM_read_bio_DSAPrivateKey and PEM_read_bio_DSA_PUBKEY(), PEM_read_ECPKParameters(), PEM_read_ECPrivateKey(), PEM_read_EC_PUBKEY(), PEM_read_bio_ECPKParameters(), PEM_read_bio_ECPrivateKey(), PEM_read_bio_EC_PUBKEY(), PEM_read_RSAPrivateKey(), PEM_read_RSA_PUBKEY(), PEM_read_RSAPublicKey(), PEM_read_bio_RSAPrivateKey(), PEM_read_bio_RSA_PUBKEY(), PEM_read_bio_RSAPublicKey(), PEM_write_bio_DHparams(), PEM_write_bio_DHxparams(), PEM_write_DHparams(), PEM_write_DHxparams(), PEM_write_DSAparams(), PEM_write_DSAPrivateKey(), PEM_write_DSA_PUBKEY(), PEM_write_bio_DSAparams(), PEM_write_bio_DSAPrivateKey(), PEM_write_bio_DSA_PUBKEY(), PEM_write_ECPKParameters(), PEM_write_ECPrivateKey(), PEM_write_EC_PUBKEY(), PEM_write_bio_ECPKParameters(), PEM_write_bio_ECPrivateKey(), PEM_write_bio_EC_PUBKEY(), PEM_write_RSAPrivateKey(), PEM_write_RSA_PUBKEY(), PEM_write_RSAPublicKey(), PEM_write_bio_RSAPrivateKey(), PEM_write_bio_RSA_PUBKEY(), PEM_write_bio_RSAPublicKey(), See “Deprecated low-level key reading and writing functions”

  • PKCS1_MGF1() See “Deprecated low-level encryption functions”.

  • RAND_get_rand_method(), RAND_set_rand_method(), RAND_OpenSSL(), RAND_set_rand_engine() Applications should instead use RAND_set_DRBG_type (3), EVP_RAND (3) and EVP_RAND (7). See RAND_set_rand_method (3) for more details.

  • RC2_encrypt(), RC2_decrypt(), RC2_set_key(), RC2_cbc_encrypt(), RC2_cfb64_encrypt(), RC2_ecb_encrypt(), RC2_ofb64_encrypt(), RC4(), RC4_set_key(), RC4_options(), RC5_32_encrypt(), RC5_32_set_key(), RC5_32_decrypt(), RC5_32_cbc_encrypt(), RC5_32_cfb64_encrypt(), RC5_32_ecb_encrypt(), RC5_32_ofb64_encrypt() See “Deprecated low-level encryption functions”. The Algorithms “RC2”, “RC4” and “RC5” have been moved to the Legacy Provider.

  • RIPEMD160(), RIPEMD160_Init(), RIPEMD160_Update(), RIPEMD160_Final(), RIPEMD160_Transform() See “Deprecated low-level digest functions”. The RIPE algorithm has been moved to the Legacy Provider.

  • RSA_bits(), RSA_security_bits(), RSA_size() Use EVP_PKEY_get_bits (3), EVP_PKEY_get_security_bits (3) and EVP_PKEY_get_size (3).

  • RSA_check_key(), RSA_check_key_ex() See “Deprecated low-level validation functions”

  • RSA_clear_flags(), RSA_flags(), RSA_set_flags(), RSA_test_flags(), RSA_setup_blinding(), RSA_blinding_off(), RSA_blinding_on() All of these RSA flags have been deprecated without replacement: RSA_FLAG_BLINDING, RSA_FLAG_CACHE_PRIVATE, RSA_FLAG_CACHE_PUBLIC, RSA_FLAG_EXT_PKEY, RSA_FLAG_NO_BLINDING, RSA_FLAG_THREAD_SAFE RSA_METHOD_FLAG_NO_CHECK

  • RSA_generate_key_ex(), RSA_generate_multi_prime_key() See “Deprecated low-level key generation functions”.

  • RSA_get0_engine() See “Providers are a replacement for engines and low-level method overrides”

  • RSA_get0_crt_params(), RSA_get0_d(), RSA_get0_dmp1(), RSA_get0_dmq1(), RSA_get0_e(), RSA_get0_factors(), RSA_get0_iqmp(), RSA_get0_key(), RSA_get0_multi_prime_crt_params(), RSA_get0_multi_prime_factors(), RSA_get0_n(), RSA_get0_p(), RSA_get0_pss_params(), RSA_get0_q(), RSA_get_multi_prime_extra_count() See “Deprecated low-level key parameter getters”

  • RSA_new(), RSA_free(), RSA_up_ref() See “Deprecated low-level object creation”.

  • RSA_get_default_method(), RSA_get_ex_data and RSA_get_method() See “Providers are a replacement for engines and low-level method overrides”.

  • RSA_get_version() There is no replacement.

  • RSA_meth_*(), RSA_new_method(), RSA_null_method and RSA_PKCS1_OpenSSL() See “Providers are a replacement for engines and low-level method overrides”.

  • RSA_padding_add_*(), RSA_padding_check_*() See “Deprecated low-level signing functions” and “Deprecated low-level encryption functions”.

  • RSA_print(), RSA_print_fp() See “Deprecated low-level key printing functions”

  • RSA_public_encrypt(), RSA_private_decrypt() See “Deprecated low-level encryption functions”

  • RSA_private_encrypt(), RSA_public_decrypt() This is equivalent to doing sign and verify recover operations (with a padding mode of none). See “Deprecated low-level signing functions”.

  • RSAPrivateKey_dup(), RSAPublicKey_dup() There is no direct replacement. Applications may use EVP_PKEY_dup (3).

  • RSAPublicKey_it(), RSAPrivateKey_it() See “Deprecated low-level key reading and writing functions”

  • RSA_set0_crt_params(), RSA_set0_factors(), RSA_set0_key(), RSA_set0_multi_prime_params() See “Deprecated low-level key parameter setters”.

  • RSA_set_default_method(), RSA_set_method(), RSA_set_ex_data() See “Providers are a replacement for engines and low-level method overrides”

  • RSA_sign(), RSA_sign_ASN1_OCTET_STRING(), RSA_verify(), RSA_verify_ASN1_OCTET_STRING(), RSA_verify_PKCS1_PSS(), RSA_verify_PKCS1_PSS_mgf1() See “Deprecated low-level signing functions”.

  • RSA_X931_derive_ex(), RSA_X931_generate_key_ex(), RSA_X931_hash_id() There are no replacements for these functions. X931 padding can be set using “Signature Parameters” in EVP_SIGNATURE-RSA (7). See OSSL_SIGNATURE_PARAM_PAD_MODE.

  • SEED_encrypt(), SEED_decrypt(), SEED_set_key(), SEED_cbc_encrypt(), SEED_cfb128_encrypt(), SEED_ecb_encrypt(), SEED_ofb128_encrypt() See “Deprecated low-level encryption functions”. The SEED algorithm has been moved to the Legacy Provider.

  • SHA1_Init(), SHA1_Update(), SHA1_Final(), SHA1_Transform(), SHA224_Init(), SHA224_Update(), SHA224_Final(), SHA256_Init(), SHA256_Update(), SHA256_Final(), SHA256_Transform(), SHA384_Init(), SHA384_Update(), SHA384_Final(), SHA512_Init(), SHA512_Update(), SHA512_Final(), SHA512_Transform() See “Deprecated low-level digest functions”.

  • SRP_Calc_A(), SRP_Calc_B(), SRP_Calc_client_key(), SRP_Calc_server_key(), SRP_Calc_u(), SRP_Calc_x(), SRP_check_known_gN_param(), SRP_create_verifier(), SRP_create_verifier_BN(), SRP_get_default_gN(), SRP_user_pwd_free(), SRP_user_pwd_new(), SRP_user_pwd_set0_sv(), SRP_user_pwd_set1_ids(), SRP_user_pwd_set_gN(), SRP_VBASE_add0_user(), SRP_VBASE_free(), SRP_VBASE_get1_by_user(), SRP_VBASE_init(), SRP_VBASE_new(), SRP_Verify_A_mod_N(), SRP_Verify_B_mod_N() There are no replacements for the SRP functions.

  • SSL_CTX_set_tmp_dh_callback(), SSL_set_tmp_dh_callback(), SSL_CTX_set_tmp_dh(), SSL_set_tmp_dh() These are used to set the Diffie-Hellman (DH) parameters that are to be used by servers requiring ephemeral DH keys. Instead applications should consider using the built-in DH parameters that are available by calling SSL_CTX_set_dh_auto (3) or SSL_set_dh_auto (3). If custom parameters are necessary then applications can use the alternative functions SSL_CTX_set0_tmp_dh_pkey (3) and SSL_set0_tmp_dh_pkey (3). There is no direct replacement for the “callback” functions. The callback was originally useful in order to have different parameters for export and non-export ciphersuites. Export ciphersuites are no longer supported by OpenSSL. Use of the callback functions should be replaced by one of the other methods described above.

  • SSL_CTX_set_tlsext_ticket_key_cb() Use the new SSL_CTX_set_tlsext_ticket_key_evp_cb (3) function instead.

  • WHIRLPOOL(), WHIRLPOOL_Init(), WHIRLPOOL_Update(), WHIRLPOOL_Final(), WHIRLPOOL_BitUpdate() See “Deprecated low-level digest functions”. The Whirlpool algorithm has been moved to the Legacy Provider.

  • X509_certificate_type() This was an undocumented function. Applications can use X509_get0_pubkey (3) and X509_get0_signature (3) instead.

  • X509_http_nbio(), X509_CRL_http_nbio() Use X509_load_http (3) and X509_CRL_load_http (3) instead.

NID handling for provided keys and algorithms

The following functions for NID (numeric id) handling have changed semantics.

  • EVP_PKEY_id(), EVP_PKEY_get_id() This function was previously used to reliably return the NID of an EVP_PKEY object, e.g., to look up the name of the algorithm of such EVP_PKEY by calling OBJ_nid2sn (3). With the introduction of provider (7)s EVP_PKEY_id() or its new equivalent EVP_PKEY_get_id (3) might now also return the value -1 (EVP_PKEY_KEYMGMT) indicating the use of a provider to implement the EVP_PKEY object. Therefore, the use of EVP_PKEY_get0_type_name (3) is recommended for retrieving the name of the EVP_PKEY algorithm.

Using the FIPS Module in applications

See fips_module (7) and OSSL_PROVIDER-FIPS (7) for details.

OpenSSL command line application changes

New applications

openssl kdf uses the new EVP_KDF (3) API. openssl kdf uses the new EVP_MAC (3) API.

Added options

-provider_path and -provider are available to all apps and can be used multiple times to load any providers, such as the ’legacy’ provider or third party providers. If used then the ‘default’ provider would also need to be specified if required. The -provider_path must be specified before the -provider option.

The list app has many new options. See openssl-list (1) for more information.

-crl_lastupdate and -crl_nextupdate used by openssl ca allows explicit setting of fields in the generated CRL.

Removed options

Interactive mode is not longer available.

The -crypt option used by openssl passwd. The -c option used by openssl x509, openssl dhparam, openssl dsaparam, and openssl ecparam.

Other Changes

The output of Command line applications may have minor changes. These are primarily changes in capitalisation and white space. However, in some cases, there are additional differences. For example, the DH parameters output from openssl dhparam now lists ‘P’, ‘Q’, ‘G’ and ‘pcounter’ instead of ‘prime’, ‘generator’, ‘subgroup order’ and ‘counter’ respectively.

The openssl commands that read keys, certificates, and CRLs now automatically detect the PEM or DER format of the input files so it is not necessary to explicitly specify the input format anymore. However if the input format option is used the specified format will be required.

openssl speed no longer uses low-level API calls. This implies some of the performance numbers might not be comparable with the previous releases due to higher overhead. This applies particularly to measuring performance on smaller data chunks.

b<openssl dhparam>, openssl dsa, openssl gendsa, openssl dsaparam, openssl genrsa and openssl rsa have been modified to use PKEY APIs. openssl genrsa and openssl rsa now write PKCS #8 keys by default.

Default settings

“SHA256” is now the default digest for TS query used by openssl ts.

Deprecated apps

openssl rsautl is deprecated, use openssl pkeyutl instead. openssl dhparam, openssl dsa, openssl gendsa, openssl dsaparam, openssl genrsa, openssl rsa, openssl genrsa and openssl rsa are now in maintenance mode and no new features will be added to them.

TLS Changes

  • TLS 1.3 FFDHE key exchange support added This uses DH safe prime named groups.

  • Support for fully “pluggable” TLSv1.3 groups. This means that providers may supply their own group implementations (using either the “key exchange” or the “key encapsulation” methods) which will automatically be detected and used by libssl.

  • SSL and SSL_CTX options are now 64 bit instead of 32 bit. The signatures of the functions to get and set options on SSL and SSL_CTX objects changed from “unsigned long” to “uint64_t” type. This may require source code changes. For example it is no longer possible to use the SSL_OP_ macro values in preprocessor #if conditions. However it is still possible to test whether these macros are defined or not. See SSL_CTX_get_options (3), SSL_CTX_set_options (3), SSL_get_options (3) and SSL_set_options (3).

  • SSL_set1_host() and SSL_add1_host() Changes These functions now take IP literal addresses as well as actual hostnames.

  • Added SSL option SSL_OP_CLEANSE_PLAINTEXT If the option is set, openssl cleanses (zeroizes) plaintext bytes from internal buffers after delivering them to the application. Note, the application is still responsible for cleansing other copies (e.g.: data received by SSL_read (3)).

  • Client-initiated renegotiation is disabled by default. To allow it, use the -client_renegotiation option, the SSL_OP_ALLOW_CLIENT_RENEGOTIATION flag, or the ClientRenegotiation config parameter as appropriate.

  • Secure renegotiation is now required by default for TLS connections Support for RFC 5746 secure renegotiation is now required by default for SSL or TLS connections to succeed. Applications that require the ability to connect to legacy peers will need to explicitly set SSL_OP_LEGACY_SERVER_CONNECT. Accordingly, SSL_OP_LEGACY_SERVER_CONNECT is no longer set as part of SSL_OP_ALL.

  • Combining the Configure options no-ec and no-dh no longer disables TLSv1.3 Typically if OpenSSL has no EC or DH algorithms then it cannot support connections with TLSv1.3. However OpenSSL now supports “pluggable” groups through providers. Therefore third party providers may supply group implementations even where there are no built-in ones. Attempting to create TLS connections in such a build without also disabling TLSv1.3 at run time or using third party provider groups may result in handshake failures. TLSv1.3 can be disabled at compile time using the “no-tls1_3” Configure option.

  • SSL_CTX_set_ciphersuites() and SSL_set_ciphersuites() changes. The methods now ignore unknown ciphers.

  • Security callback change. The security callback, which can be customised by application code, supports the security operation SSL_SECOP_TMP_DH. This is defined to take an EVP_PKEY in the “other” parameter. In most places this is what is passed. All these places occur server side. However there was one client side call of this security operation and it passed a DH object instead. This is incorrect according to the definition of SSL_SECOP_TMP_DH, and is inconsistent with all of the other locations. Therefore this client side call has been changed to pass an EVP_PKEY instead.

  • New SSL option SSL_OP_IGNORE_UNEXPECTED_EOF The SSL option SSL_OP_IGNORE_UNEXPECTED_EOF is introduced. If that option is set, an unexpected EOF is ignored, it pretends a close notify was received instead and so the returned error becomes SSL_ERROR_ZERO_RETURN.

  • The security strength of SHA1 and MD5 based signatures in TLS has been reduced. This results in SSL 3, TLS 1.0, TLS 1.1 and DTLS 1.0 no longer working at the default security level of 1 and instead requires security level 0. The security level can be changed either using the cipher string with @SECLEVEL, or calling SSL_CTX_set_security_level (3). This also means that where the signature algorithms extension is missing from a ClientHello then the handshake will fail in TLS 1.2 at security level 1. This is because, although this extension is optional, failing to provide one means that OpenSSL will fallback to a default set of signature algorithms. This default set requires the availability of SHA1.

  • X509 certificates signed using SHA1 are no longer allowed at security level 1 and above. In TLS/SSL the default security level is 1. It can be set either using the cipher string with @SECLEVEL, or calling SSL_CTX_set_security_level (3). If the leaf certificate is signed with SHA-1, a call to SSL_CTX_use_certificate (3) will fail if the security level is not lowered first. Outside TLS/SSL, the default security level is -1 (effectively 0). It can be set using X509_VERIFY_PARAM_set_auth_level (3) or using the -auth_level options of the commands.

SEE ALSO

fips_module (7)

HISTORY

The migration guide was created for OpenSSL 3.0.

COPYRIGHT

Copyright 2021-2024 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

271 - Linux cli command COMMIT_PREPARED

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command COMMIT_PREPARED and provides detailed information about the command COMMIT_PREPARED, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the COMMIT_PREPARED.

NAME 🖥️ COMMIT_PREPARED 🖥️

commit a transaction that was earlier prepared for two-phase commit

SYNOPSIS

COMMIT PREPARED transaction_id

DESCRIPTION

COMMIT PREPARED commits a transaction that is in prepared state.

PARAMETERS

transaction_id

The transaction identifier of the transaction that is to be committed.

NOTES

To commit a prepared transaction, you must be either the same user that executed the transaction originally, or a superuser. But you do not have to be in the same session that executed the transaction.

This command cannot be executed inside a transaction block. The prepared transaction is committed immediately.

All currently available prepared transactions are listed in the pg_prepared_xacts system view.

EXAMPLES

Commit the transaction identified by the transaction identifier foobar:

COMMIT PREPARED foobar;

COMPATIBILITY

COMMIT PREPARED is a PostgreSQL extension. It is intended for use by external transaction management systems, some of which are covered by standards (such as X/Open XA), but the SQL side of those systems is not standardized.

SEE ALSO

PREPARE TRANSACTION (PREPARE_TRANSACTION(7)), ROLLBACK PREPARED (ROLLBACK_PREPARED(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

272 - Linux cli command OSSL_PROVIDER-defaultssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command OSSL_PROVIDER-defaultssl and provides detailed information about the command OSSL_PROVIDER-defaultssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the OSSL_PROVIDER-defaultssl.

NAME 🖥️ OSSL_PROVIDER-defaultssl 🖥️

default - OpenSSL default provider

DESCRIPTION

The OpenSSL default provider supplies the majority of OpenSSL’s diverse algorithm implementations. If an application doesn’t specify anything else explicitly (e.g. in the application or via config), then this is the provider that will be used as fallback: It is loaded automatically the first time that an algorithm is fetched from a provider or a function acting on providers is called and no other provider has been loaded yet.

If an attempt to load a provider has already been made (whether successful or not) then the default provider won’t be loaded automatically. Therefore if the default provider is to be used in conjunction with other providers then it must be loaded explicitly. Automatic loading of the default provider only occurs a maximum of once; if the default provider is explicitly unloaded then the default provider will not be automatically loaded again.

Properties

The implementations in this provider specifically have this property defined:

“provider=default”

It may be used in a property query string with fetching functions such as EVP_MD_fetch (3) or EVP_CIPHER_fetch (3), as well as with other functions that take a property query string, such as EVP_PKEY_CTX_new_from_name (3).

It isn’t mandatory to query for this property, except to make sure to get implementations of this provider and none other.

Some implementations may define additional properties. Exact information is listed below

OPERATIONS AND ALGORITHMS

The OpenSSL default provider supports these operations and algorithms:

Hashing Algorithms / Message Digests

SHA1, see EVP_MD-SHA1 (7)

SHA2, see EVP_MD-SHA2 (7)

SHA3, see EVP_MD-SHA3 (7)

KECCAK, see EVP_MD-KECCAK (7)

KECCAK-KMAC, see EVP_MD-KECCAK-KMAC (7)

SHAKE, see EVP_MD-SHAKE (7)

BLAKE2, see EVP_MD-BLAKE2 (7)

SM3, see EVP_MD-SM3 (7)

MD5, see EVP_MD-MD5 (7)

MD5-SHA1, see EVP_MD-MD5-SHA1 (7)

RIPEMD160, see EVP_MD-RIPEMD160 (7)

NULL, see EVP_MD-NULL (7)

Symmetric Ciphers

AES, see EVP_CIPHER-AES (7)

ARIA, see EVP_CIPHER-ARIA (7)

CAMELLIA, see EVP_CIPHER-CAMELLIA (7)

3DES, see EVP_CIPHER-DES (7)

SM4, see EVP_CIPHER-SM4 (7)

ChaCha20, see EVP_CIPHER-CHACHA (7)

ChaCha20-Poly1305, see EVP_CIPHER-CHACHA (7)

NULL, see EVP_CIPHER-NULL (7)

Message Authentication Code (MAC)

BLAKE2, see EVP_MAC-BLAKE2 (7)

CMAC, see EVP_MAC-CMAC (7)

GMAC, see EVP_MAC-GMAC (7)

HMAC, see EVP_MAC-HMAC (7)

KMAC, see EVP_MAC-KMAC (7)

SIPHASH, see EVP_MAC-Siphash (7)

POLY1305, see EVP_MAC-Poly1305 (7)

Key Derivation Function (KDF)

HKDF, see EVP_KDF-HKDF (7)

TLS13-KDF, see EVP_KDF-TLS13_KDF (7)

SSKDF, see EVP_KDF-SS (7)

PBKDF2, see EVP_KDF-PBKDF2 (7)

PKCS12KDF, see EVP_KDF-PKCS12KDF (7)

SSHKDF, see EVP_KDF-SSHKDF (7)

TLS1-PRF, see EVP_KDF-TLS1_PRF (7)

KBKDF, see EVP_KDF-KB (7)

X942KDF-ASN1, see EVP_KDF-X942-ASN1 (7)

X942KDF-CONCAT, see EVP_KDF-X942-CONCAT (7)

X963KDF, see EVP_KDF-X963 (7)

SCRYPT, see EVP_KDF-SCRYPT (7)

KRB5KDF, see EVP_KDF-KRB5KDF (7)

HMAC-DRBG, see EVP_KDF-HMAC-DRBG (7)

ARGON2, see EVP_KDF-ARGON2 (7)

Key Exchange

DH, see EVP_KEYEXCH-DH (7)

ECDH, see EVP_KEYEXCH-ECDH (7)

X25519, see EVP_KEYEXCH-X25519 (7)

X448, see EVP_KEYEXCH-X448 (7)

TLS1-PRF

HKDF

SCRYPT

Asymmetric Signature

DSA, see EVP_SIGNATURE-DSA (7)

RSA, see EVP_SIGNATURE-RSA (7)

ED25519, see EVP_SIGNATURE-ED25519 (7)

ED448, see EVP_SIGNATURE-ED448 (7)

ECDSA, see EVP_SIGNATURE-ECDSA (7)

SM2

HMAC, see EVP_SIGNATURE-HMAC (7)

SIPHASH, see EVP_SIGNATURE-Siphash (7)

POLY1305, see EVP_SIGNATURE-Poly1305 (7)

CMAC, see EVP_SIGNATURE-CMAC (7)

Asymmetric Cipher

RSA, see EVP_ASYM_CIPHER-RSA (7)

SM2, see EVP_ASYM_CIPHER-SM2 (7)

Asymmetric Key Encapsulation

RSA, see EVP_KEM-RSA (7)

X25519, see EVP_KEM-X25519 (7)

X448, see EVP_KEM-X448 (7)

EC, see EVP_KEM-EC (7)

Asymmetric Key Management

DH, see EVP_KEYMGMT-DH (7)

DHX, see EVP_KEYMGMT-DHX (7)

DSA, see EVP_KEYMGMT-DSA (7)

RSA, see EVP_KEYMGMT-RSA (7)

RSA-PSS

EC, see EVP_KEYMGMT-EC (7)

X25519, see EVP_KEYMGMT-X25519 (7)

X448, see EVP_KEYMGMT-X448 (7)

ED25519, see EVP_KEYMGMT-ED25519 (7)

ED448, see EVP_KEYMGMT-ED448 (7)

TLS1-PRF

HKDF

SCRYPT

HMAC, see EVP_KEYMGMT-HMAC (7)

SIPHASH, see EVP_KEYMGMT-Siphash (7)

POLY1305, see EVP_KEYMGMT-Poly1305 (7)

CMAC, see EVP_KEYMGMT-CMAC (7)

SM2, see EVP_KEYMGMT-SM2 (7)

Random Number Generation

CTR-DRBG, see EVP_RAND-CTR-DRBG (7)

HASH-DRBG, see EVP_RAND-HASH-DRBG (7)

HMAC-DRBG, see EVP_RAND-HMAC-DRBG (7)

SEED-SRC, see EVP_RAND-SEED-SRC (7)

TEST-RAND, see EVP_RAND-TEST-RAND (7)

In addition to this provider, the “SEED-SRC” algorithm is also available in the base provider.

Asymmetric Key Encoder

RSA

RSA-PSS

DH

DHX

DSA

EC

ED25519

ED448

X25519

X448

SM2

In addition to this provider, all of these encoding algorithms are also available in the base provider. Some of these algorithms may be used in combination with the FIPS provider.

Asymmetric Key Decoder

RSA

RSA-PSS

DH

DHX

DSA

EC

ED25519

ED448

X25519

X448

SM2

DER

In addition to this provider, all of these decoding algorithms are also available in the base provider. Some of these algorithms may be used in combination with the FIPS provider.

Stores

file

org.openssl.winstore, see OSSL_STORE-winstore (7)

In addition to this provider, all of these store algorithms are also available in the base provider.

SEE ALSO

openssl-core.h (7), openssl-core_dispatch.h (7), provider (7), OSSL_PROVIDER-base (7)

HISTORY

The RIPEMD160 digest was added to the default provider in OpenSSL 3.0.7.

All other functionality was added in OpenSSL 3.0.

COPYRIGHT

Copyright 2020-2024 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

273 - Linux cli command EVP_KDF-PKCS12KDFssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KDF-PKCS12KDFssl and provides detailed information about the command EVP_KDF-PKCS12KDFssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KDF-PKCS12KDFssl.

NAME 🖥️ EVP_KDF-PKCS12KDFssl 🖥️

PKCS12KDF - The PKCS#12 EVP_KDF implementation

DESCRIPTION

Support for computing the PKCS#12 password-based KDF through the EVP_KDF API.

The EVP_KDF-PKCS12KDF algorithm implements the PKCS#12 password-based key derivation function, as described in appendix B of RFC 7292 (PKCS #12: Personal Information Exchange Syntax); it derives a key from a password using a salt, iteration count and the intended usage.

Identity

“PKCS12KDF” is the name for this implementation; it can be used with the EVP_KDF_fetch() function.

Supported parameters

The supported parameters are:

“pass” (OSSL_KDF_PARAM_PASSWORD) <octet string>

“salt” (OSSL_KDF_PARAM_SALT) <octet string>

“iter” (OSSL_KDF_PARAM_ITER) <unsigned integer>

“properties” (OSSL_KDF_PARAM_PROPERTIES) <UTF8 string>

“digest” (OSSL_KDF_PARAM_DIGEST) <UTF8 string>

These parameters work as described in “PARAMETERS” in EVP_KDF (3).

“id” (OSSL_KDF_PARAM_PKCS12_ID) <integer>
This parameter is used to specify the intended usage of the output bits, as per RFC 7292 section B.3.

NOTES

This algorithm is not available in the FIPS provider as it is not FIPS approvable.

A typical application of this algorithm is to derive keying material for an encryption algorithm from a password in the “pass”, a salt in “salt”, and an iteration count.

Increasing the “iter” parameter slows down the algorithm which makes it harder for an attacker to perform a brute force attack using a large number of candidate passwords.

No assumption is made regarding the given password; it is simply treated as a byte sequence.

CONFORMING TO

RFC7292

SEE ALSO

EVP_KDF (3), EVP_KDF_CTX_new (3), EVP_KDF_CTX_free (3), EVP_KDF_CTX_set_params (3), EVP_KDF_derive (3), “PARAMETERS” in EVP_KDF (3), OSSL_PROVIDER-FIPS (7)

HISTORY

This functionality was added in OpenSSL 3.0.

COPYRIGHT

Copyright 2020-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

274 - Linux cli command ALTER_OPERATOR

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_OPERATOR and provides detailed information about the command ALTER_OPERATOR, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_OPERATOR.

NAME 🖥️ ALTER_OPERATOR 🖥️

change the definition of an operator

SYNOPSIS

ALTER OPERATOR name ( { left_type | NONE } , right_type )
    OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }

ALTER OPERATOR name ( { left_type | NONE } , right_type )
    SET SCHEMA new_schema

ALTER OPERATOR name ( { left_type | NONE } , right_type )
    SET ( {  RESTRICT = { res_proc | NONE }
           | JOIN = { join_proc | NONE }
         } [, ... ] )

DESCRIPTION

ALTER OPERATOR changes the definition of an operator.

You must own the operator to use ALTER OPERATOR. To alter the owner, you must be able to SET ROLE to the new owning role, and that role must have CREATE privilege on the operators schema. (These restrictions enforce that altering the owner doesnt do anything you couldnt do by dropping and recreating the operator. However, a superuser can alter ownership of any operator anyway.)

PARAMETERS

name

The name (optionally schema-qualified) of an existing operator.

left_type

The data type of the operators left operand; write NONE if the operator has no left operand.

right_type

The data type of the operators right operand.

new_owner

The new owner of the operator.

new_schema

The new schema for the operator.

res_proc

The restriction selectivity estimator function for this operator; write NONE to remove existing selectivity estimator.

join_proc

The join selectivity estimator function for this operator; write NONE to remove existing selectivity estimator.

EXAMPLES

Change the owner of a custom operator a @@ b for type text:

ALTER OPERATOR @@ (text, text) OWNER TO joe;

Change the restriction and join selectivity estimator functions of a custom operator a && b for type int[]:

ALTER OPERATOR && (_int4, _int4) SET (RESTRICT = _int_contsel, JOIN = _int_contjoinsel);

COMPATIBILITY

There is no ALTER OPERATOR statement in the SQL standard.

SEE ALSO

CREATE OPERATOR (CREATE_OPERATOR(7)), DROP OPERATOR (DROP_OPERATOR(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

275 - Linux cli command DROP_FOREIGN_DATA_WRAPPER

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_FOREIGN_DATA_WRAPPER and provides detailed information about the command DROP_FOREIGN_DATA_WRAPPER, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_FOREIGN_DATA_WRAPPER.

NAME 🖥️ DROP_FOREIGN_DATA_WRAPPER 🖥️

remove a foreign-data wrapper

SYNOPSIS

DROP FOREIGN DATA WRAPPER [ IF EXISTS ] name [, ...] [ CASCADE | RESTRICT ]

DESCRIPTION

DROP FOREIGN DATA WRAPPER removes an existing foreign-data wrapper. To execute this command, the current user must be the owner of the foreign-data wrapper.

PARAMETERS

IF EXISTS

Do not throw an error if the foreign-data wrapper does not exist. A notice is issued in this case.

name

The name of an existing foreign-data wrapper.

CASCADE

Automatically drop objects that depend on the foreign-data wrapper (such as foreign tables and servers), and in turn all objects that depend on those objects (see Section 5.14).

RESTRICT

Refuse to drop the foreign-data wrapper if any objects depend on it. This is the default.

EXAMPLES

Drop the foreign-data wrapper dbi:

DROP FOREIGN DATA WRAPPER dbi;

COMPATIBILITY

DROP FOREIGN DATA WRAPPER conforms to ISO/IEC 9075-9 (SQL/MED). The IF EXISTS clause is a PostgreSQL extension.

SEE ALSO

CREATE FOREIGN DATA WRAPPER (CREATE_FOREIGN_DATA_WRAPPER(7)), ALTER FOREIGN DATA WRAPPER (ALTER_FOREIGN_DATA_WRAPPER(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

276 - Linux cli command bootup

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command bootup and provides detailed information about the command bootup, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the bootup.

NAME 🖥️ bootup 🖥️

System bootup process

DESCRIPTION

A number of different components are involved in the boot of a Linux system. Immediately after power-up, the system firmware will do minimal hardware initialization, and hand control over to a boot loader (e.g. systemd-boot(7) or GRUB[1]) stored on a persistent storage device. This boot loader will then invoke an OS kernel from disk (or the network). On systems using EFI or other types of firmware, this firmware may also load the kernel directly.

The kernel (optionally) mounts an in-memory file system, which looks for the root file system. Nowadays this is implemented as an “initramfs” — a compressed CPIO archive that the kernel extracts into a tmpfs. In the past normal file systems using an in-memory block device (ramdisk) were used, and the name “initrd” is still used to describe both concepts. Its the boot loader or the firmware that loads both the kernel and initrd/initramfs images into memory, but the kernel which interprets it as a file system. systemd(1) may be used to manage services in the initrd, similarly to the real system.

After the root file system is found and mounted, the initrd hands over control to the hosts system manager (such as systemd(1)) stored in the root file system, which is then responsible for probing all remaining hardware, mounting all necessary file systems and spawning all configured services.

On shutdown, the system manager stops all services, unmounts all file systems (detaching the storage technologies backing them), and then (optionally) jumps back into the initrd code which unmounts/detaches the root file system and the storage it resides on. As a last step, the system is powered down.

Additional information about the system boot process may be found in boot(7).

SYSTEM MANAGER BOOTUP

At boot, the system manager on the OS image is responsible for initializing the required file systems, services and drivers that are necessary for operation of the system. On systemd(1) systems, this process is split up in various discrete steps which are exposed as target units. (See systemd.target(5) for detailed information about target units.) The boot-up process is highly parallelized so that the order in which specific target units are reached is not deterministic, but still adheres to a limited amount of ordering structure.

When systemd starts up the system, it will activate all units that are dependencies of default.target (as well as recursively all dependencies of these dependencies). Usually, default.target is simply an alias of graphical.target or multi-user.target, depending on whether the system is configured for a graphical UI or only for a text console. To enforce minimal ordering between the units pulled in, a number of well-known target units are available, as listed on systemd.special(7).

The following chart is a structural overview of these well-known units and their position in the boot-up logic. The arrows describe which units are pulled in and ordered before which other units. Units near the top are started before units nearer to the bottom of the chart.

                         cryptsetup-pre.target veritysetup-pre.target
                                                  |
(various low-level                                v
 API VFS mounts:             (various cryptsetup/veritysetup devices...)
 mqueue, configfs,                                |    |
 debugfs, ...)                                    v    |
 |                                  cryptsetup.target  |
 |  (various swap                                 |    |    remote-fs-pre.target
 |   devices...)                                  |    |     |        |
 |    |                                           |    |     |        v
 |    v                       local-fs-pre.target |    |     |  (network file systems)
 |  swap.target                       |           |    v     v                 |
 |    |                               v           |  remote-cryptsetup.target  |
 |    |  (various low-level  (various mounts and  |  remote-veritysetup.target |
 |    |   services: udevd,    fsck services...)   |             |              |
 |    |   tmpfiles, random            |           |             |    remote-fs.target
 |    |   seed, sysctl, ...)          v           |             |              |
 |    |      |                 local-fs.target    |             | _____________/
 |    |      |                        |           |             |/
 \____|______|_______________   ______|___________/             |
                             \ /                                |
                              v                                 |
                       sysinit.target                           |
                              |                                 |
       ______________________/|\_____________________           |
      /              |        |      |               \          |
      |              |        |      |               |          |
      v              v        |      v               |          |
 (various       (various      |  (various            |          |
  timers...)      paths...)   |   sockets...)        |          |
      |              |        |      |               |          |
      v              v        |      v               |          |
timers.target  paths.target   |  sockets.target      |          |
      |              |        |      |               v          |
      v              \_______ | _____/         rescue.service   |
                             \|/                     |          |
                              v                      v          |
                          basic.target         rescue.target    |
                              |                                 |
                      ________v____________________             |
                     /              |              \            |
                     |              |              |            |
                     v              v              v            |
                 display-    (various system   (various system  |
             manager.service     services        services)      |
                     |         required for        |            |
                     |        graphical UIs)       v            v
                     |              |            multi-user.target
emergency.service    |              |              |
        |            \_____________ | _____________/
        v                          \|/
emergency.target                    v
                              graphical.target

Target units that are commonly used as boot targets are emphasized. These units are good choices as goal targets, for example by passing them to the systemd.unit= kernel command line option (see systemd(1)) or by symlinking default.target to them.

timers.target is pulled-in by basic.target asynchronously. This allows timers units to depend on services which become only available later in boot.

USER MANAGER STARTUP

The system manager starts the user@uid.service unit for each user, which launches a separate unprivileged instance of systemd for each user — the user manager. Similarly to the system manager, the user manager starts units which are pulled in by default.target. The following chart is a structural overview of the well-known user units. For non-graphical sessions, default.target is used. Whenever the user logs into a graphical session, the login manager will start the graphical-session.target target that is used to pull in units required for the graphical session. A number of targets (shown on the right side) are started when specific hardware is available to the user.

(various (various (various timers…) paths…) sockets…) (sound devices) | | | | v v v v timers.target paths.target sockets.target sound.target | | | ______________ _|_________________/ (bluetooth devices) \ / | V v basic.target bluetooth.target | ____/ _ (smartcard devices) / \ | | | v | v smartcard.target v graphical-session-pre.target (various user services) | (printers) | v | | (services for the graphical session) v | | printer.target v v default.target graphical-session.target

BOOTUP IN THE INITRD

Systemd can be used in the initrd as well. It detects the initrd environment by checking for the /etc/initrd-release file. The default target in the initrd is initrd.target. The bootup process is identical to the system manager bootup until the target basic.target. After that, systemd executes the special target initrd.target. Before any file systems are mounted, the manager will determine whether the system shall resume from hibernation or proceed with normal boot. This is accomplished by systemd-hibernate-resume.service which must be finished before local-fs-pre.target, so no filesystems can be mounted before the check is complete. When the root device becomes available, initrd-root-device.target is reached. If the root device can be mounted at /sysroot, the sysroot.mount unit becomes active and initrd-root-fs.target is reached. The service initrd-parse-etc.service scans /sysroot/etc/fstab for a possible /usr/ mount point and additional entries marked with the x-initrd.mount option. All entries found are mounted below /sysroot, and initrd-fs.target is reached. The service initrd-cleanup.service isolates to the initrd-switch-root.target, where cleanup services can run. As the very last step, the initrd-switch-root.service is activated, which will cause the system to switch its root to /sysroot.

                           : (beginning identical to above)
                               :
                               v
                         basic.target
                               |                       emergency.service
        ______________________/|                               |
       /                       |                               v
       |            initrd-root-device.target          emergency.target
       |                       |
       |                       v
       |                  sysroot.mount
       |                       |
       |                       v
       |             initrd-root-fs.target
       |                       |
       |                       v
       v            initrd-parse-etc.service
(custom initrd                 |
 services...)                  v
       |            (sysroot-usr.mount and
       |             various mounts marked
       |               with fstab option
       |              x-initrd.mount...)
       |                       |
       |                       v
       |                initrd-fs.target
       \______________________ |
                              \|
                               v
                          initrd.target
                               |
                               v
                     initrd-cleanup.service
                          isolates to
                    initrd-switch-root.target
                               |
                               v
        ______________________/|
       /                       v
       |        initrd-udevadm-cleanup-db.service
       v                       |
(custom initrd                 |
 services...)                  |
       \______________________ |
                              \|
                               v
                   initrd-switch-root.target
                               |
                               v
                   initrd-switch-root.service
                               |
                               v
                     Transition to Host OS

SYSTEM MANAGER SHUTDOWN

System shutdown with systemd also consists of various target units with some minimal ordering structure applied:

                   (conflicts with  (conflicts with
                          all system     all file system
                           services)     mounts, swaps,
                               |           cryptsetup/
                               |           veritysetup
                               |          devices, ...)
                               |                |
                               v                v
                        shutdown.target    umount.target
                               |                |
                               \_______   ______/
                                       \ /
                                        v
                               (various low-level
                                    services)
                                        |
                                        v
                                  final.target
                                        |
            ___________________________/ \_________________________________
           /               |               |               |               \
           |               |               |               |               |
           v               |               |               |               |
systemd-reboot.service     |               |               |               |
           |               v               |               |               |
           |    systemd-poweroff.service   |               |               |
           v               |               v               |               |
     reboot.target         |      systemd-halt.service     |               |
                           v               |               v               |
                   poweroff.target         |    systemd-kexec.service      |
                                           v               |               |
                                      halt.target          |  systemd-soft-reboot.service
                                                           v               |
                                                     kexec.target          |
                                                                           v
                                                                   soft-reboot.target

Commonly used system shutdown targets are emphasized.

Note that systemd-halt.service(8), systemd-reboot.service, systemd-poweroff.service and systemd-kexec.service will transition the system and server manager (PID 1) into the second phase of system shutdown (implemented in the systemd-shutdown binary), which will unmount any remaining file systems, kill any remaining processes and release any other remaining resources, in a simple and robust fashion, without taking any service or unit concept into account anymore. At that point, regular applications and resources are generally terminated and released already, the second phase hence operates only as safety net for everything that couldnt be stopped or released for some reason during the primary, unit-based shutdown phase described above.

SEE ALSO

systemd(1), boot(7), systemd.special(7), systemd.target(5), systemd-halt.service(8), systemd-soft-reboot.service(8)

NOTES

GRUB

https://www.gnu.org/software/grub/

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

277 - Linux cli command COPY

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command COPY and provides detailed information about the command COPY, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the COPY.

NAME 🖥️ COPY 🖥️

copy data between a file and a table

SYNOPSIS

COPY table_name [ ( column_name [, ...] ) ]
    FROM { filename | PROGRAM command | STDIN }
    [ [ WITH ] ( option [, ...] ) ]
    [ WHERE condition ]

COPY { table_name [ ( column_name [, ...] ) ] | ( query ) }
    TO { filename | PROGRAM command | STDOUT }
    [ [ WITH ] ( option [, ...] ) ]

where option can be one of:

    FORMAT format_name
    FREEZE [ boolean ]
    DELIMITER delimiter_character
    NULL null_string
    DEFAULT default_string
    HEADER [ boolean | MATCH ]
    QUOTE quote_character
    ESCAPE escape_character
    FORCE_QUOTE { ( column_name [, ...] ) | * }
    FORCE_NOT_NULL ( column_name [, ...] )
    FORCE_NULL ( column_name [, ...] )
    ENCODING encoding_name

DESCRIPTION

COPY moves data between PostgreSQL tables and standard file-system files. COPY TO copies the contents of a table to a file, while COPY FROM copies data from a file to a table (appending the data to whatever is in the table already). COPY TO can also copy the results of a SELECT query.

If a column list is specified, COPY TO copies only the data in the specified columns to the file. For COPY FROM, each field in the file is inserted, in order, into the specified column. Table columns not specified in the COPY FROM column list will receive their default values.

COPY with a file name instructs the PostgreSQL server to directly read from or write to a file. The file must be accessible by the PostgreSQL user (the user ID the server runs as) and the name must be specified from the viewpoint of the server. When PROGRAM is specified, the server executes the given command and reads from the standard output of the program, or writes to the standard input of the program. The command must be specified from the viewpoint of the server, and be executable by the PostgreSQL user. When STDIN or STDOUT is specified, data is transmitted via the connection between the client and the server.

Each backend running COPY will report its progress in the pg_stat_progress_copy view. See Section 28.4.3 for details.

PARAMETERS

table_name

The name (optionally schema-qualified) of an existing table.

column_name

An optional list of columns to be copied. If no column list is specified, all columns of the table except generated columns will be copied.

query

A SELECT, VALUES, INSERT, UPDATE, or DELETE command whose results are to be copied. Note that parentheses are required around the query.

For INSERT, UPDATE and DELETE queries a RETURNING clause must be provided, and the target relation must not have a conditional rule, nor an ALSO rule, nor an INSTEAD rule that expands to multiple statements.

filename

The path name of the input or output file. An input file name can be an absolute or relative path, but an output file name must be an absolute path. Windows users might need to use an E string and double any backslashes used in the path name.

PROGRAM

A command to execute. In COPY FROM, the input is read from standard output of the command, and in COPY TO, the output is written to the standard input of the command.

Note that the command is invoked by the shell, so if you need to pass any arguments that come from an untrusted source, you must be careful to strip or escape any special characters that might have a special meaning for the shell. For security reasons, it is best to use a fixed command string, or at least avoid including any user input in it.

STDIN

Specifies that input comes from the client application.

STDOUT

Specifies that output goes to the client application.

boolean

Specifies whether the selected option should be turned on or off. You can write TRUE, ON, or 1 to enable the option, and FALSE, OFF, or 0 to disable it. The boolean value can also be omitted, in which case TRUE is assumed.

FORMAT

Selects the data format to be read or written: text, csv (Comma Separated Values), or binary. The default is text.

FREEZE

Requests copying the data with rows already frozen, just as they would be after running the VACUUM FREEZE command. This is intended as a performance option for initial data loading. Rows will be frozen only if the table being loaded has been created or truncated in the current subtransaction, there are no cursors open and there are no older snapshots held by this transaction. It is currently not possible to perform a COPY FREEZE on a partitioned table.

Note that all other sessions will immediately be able to see the data once it has been successfully loaded. This violates the normal rules of MVCC visibility and users should be aware of the potential problems this might cause.

DELIMITER

Specifies the character that separates columns within each row (line) of the file. The default is a tab character in text format, a comma in CSV format. This must be a single one-byte character. This option is not allowed when using binary format.

NULL

Specifies the string that represents a null value. The default is \N (backslash-N) in text format, and an unquoted empty string in CSV format. You might prefer an empty string even in text format for cases where you dont want to distinguish nulls from empty strings. This option is not allowed when using binary format.

Note

When using COPY FROM, any data item that matches this string will be stored as a null value, so you should make sure that you use the same string as you used with COPY TO.

DEFAULT

Specifies the string that represents a default value. Each time the string is found in the input file, the default value of the corresponding column will be used. This option is allowed only in COPY FROM, and only when not using binary format.

HEADER

Specifies that the file contains a header line with the names of each column in the file. On output, the first line contains the column names from the table. On input, the first line is discarded when this option is set to true (or equivalent Boolean value). If this option is set to MATCH, the number and names of the columns in the header line must match the actual column names of the table, in order; otherwise an error is raised. This option is not allowed when using binary format. The MATCH option is only valid for COPY FROM commands.

QUOTE

Specifies the quoting character to be used when a data value is quoted. The default is double-quote. This must be a single one-byte character. This option is allowed only when using CSV format.

ESCAPE

Specifies the character that should appear before a data character that matches the QUOTE value. The default is the same as the QUOTE value (so that the quoting character is doubled if it appears in the data). This must be a single one-byte character. This option is allowed only when using CSV format.

FORCE_QUOTE

Forces quoting to be used for all non-NULL values in each specified column. NULL output is never quoted. If * is specified, non-NULL values will be quoted in all columns. This option is allowed only in COPY TO, and only when using CSV format.

FORCE_NOT_NULL

Do not match the specified columns values against the null string. In the default case where the null string is empty, this means that empty values will be read as zero-length strings rather than nulls, even when they are not quoted. This option is allowed only in COPY FROM, and only when using CSV format.

FORCE_NULL

Match the specified columns values against the null string, even if it has been quoted, and if a match is found set the value to NULL. In the default case where the null string is empty, this converts a quoted empty string into NULL. This option is allowed only in COPY FROM, and only when using CSV format.

ENCODING

Specifies that the file is encoded in the encoding_name. If this option is omitted, the current client encoding is used. See the Notes below for more details.

WHERE

The optional WHERE clause has the general form

WHERE condition

where condition is any expression that evaluates to a result of type boolean. Any row that does not satisfy this condition will not be inserted to the table. A row satisfies the condition if it returns true when the actual row values are substituted for any variable references.

Currently, subqueries are not allowed in WHERE expressions, and the evaluation does not see any changes made by the COPY itself (this matters when the expression contains calls to VOLATILE functions).

OUTPUTS

On successful completion, a COPY command returns a command tag of the form

COPY count

The count is the number of rows copied.

Note

psql will print this command tag only if the command was not COPY … TO STDOUT, or the equivalent psql meta-command

278 - Linux cli command ossl-guide-introductionssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ossl-guide-introductionssl and provides detailed information about the command ossl-guide-introductionssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ossl-guide-introductionssl.

NAME 🖥️ ossl-guide-introductionssl 🖥️

guide-introduction - OpenSSL Guide: An introduction to OpenSSL

WHAT IS OPENSSL?

OpenSSL is a robust, commercial-grade, full-featured toolkit for general-purpose cryptography and secure communication. Its features are made available via a command line application that enables users to perform various cryptography related functions such as generating keys and certificates. Additionally it supplies two libraries that application developers can use to implement cryptography based capabilities and to securely communicate across a network. Finally, it also has a set of providers that supply implementations of a broad set of cryptographic algorithms.

OpenSSL is fully open source. Version 3.0 and above are distributed under the Apache v2 license.

GETTING AND INSTALLING OPENSSL

The OpenSSL Project develops and distributes the source code for OpenSSL. You can obtain that source code via the OpenSSL website (<https://www.openssl.org/source>).

Many Operating Systems (notably Linux distributions) supply pre-built OpenSSL binaries either pre-installed or available via the package management system in use for that OS. It is worth checking whether this applies to you before attempting to build OpenSSL from the source code.

Some third parties also supply OpenSSL binaries (e.g. for Windows and some other platforms). The OpenSSL project maintains a list of these third parties at <https://wiki.openssl.org/index.php/Binaries>.

If you build and install OpenSSL from the source code then you should download the appropriate files for the version that you want to use from the link given above. Extract the contents of the tar.gz archive file that you downloaded into an appropriate directory. Inside that archive you will find a file named INSTALL.md which will supply detailed instructions on how to build and install OpenSSL from source. Make sure you read the contents of that file carefully in order to achieve a successful build. In the directory you will also find a set of NOTES files that provide further platform specific information. Make sure you carefully read the file appropriate to your platform. As well as the platform specific NOTES files there is also a NOTES-PERL.md file that provides information about setting up Perl for use by the OpenSSL build system across multiple platforms.

Sometimes you may want to build and install OpenSSL from source on a system which already has a pre-built version of OpenSSL installed on it via the Operating System package management system (for example if you want to use a newer version of OpenSSL than the one supplied by your Operating System). In this case it is strongly recommended to install OpenSSL to a different location than where the pre-built version is installed. You should never replace the pre-built version with a different version as this may break your system.

CONTENTS OF THE OPENSSL GUIDE

The OpenSSL Guide is a series of documentation pages (starting with this one) that introduce some of the main concepts in OpenSSL. The guide can either be read end-to-end in order, or alternatively you can simply skip to the parts most applicable to your use case. Note however that later pages may depend on and assume knowledge from earlier pages.

The pages in the guide are as follows:

ossl-guide-libraries-introduction (7): An introduction to the OpenSSL libraries

ossl-guide-libcrypto-introduction (7): An introduction to libcrypto

ossl-guide-libssl-introduction (7): An introduction to libssl

ossl-guide-tls-introduction (7): An introduction to SSL/TLS in OpenSSL

ossl-guide-tls-client-block (7): Writing a simple blocking TLS client

ossl-guide-tls-client-non-block (7): Writing a simple nonblocking TLS client

ossl-guide-quic-introduction (7): An introduction to QUIC in OpenSSL

ossl-guide-quic-client-block (7): Writing a simple blocking QUIC client

ossl-guide-quic-multi-stream (7): Writing a simple multi-stream QUIC client

ossl-guide-quic-client-non-block (7): Writing a simple nonblocking QUIC client

ossl-guide-migration (7): Migrating from older OpenSSL versions

COPYRIGHT

Copyright 2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

279 - Linux cli command EVP_MD-SHA1ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_MD-SHA1ssl and provides detailed information about the command EVP_MD-SHA1ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_MD-SHA1ssl.

NAME 🖥️ EVP_MD-SHA1ssl 🖥️

SHA1 - The SHA1 EVP_MD implementation

DESCRIPTION

Support for computing SHA1 digests through the EVP_MD API.

Identities

This implementation is available with the FIPS provider as well as the default provider, and is identified with the names “SHA1” and “SHA-1”.

Gettable Parameters

This implementation supports the common gettable parameters described in EVP_MD-common (7).

Settable Context Parameters

This implementation supports the following OSSL_PARAM (3) entries, settable for an EVP_MD_CTX with EVP_MD_CTX_set_params (3):

“ssl3-ms” (OSSL_DIGEST_PARAM_SSL3_MS) <octet string>
This parameter is set by libssl in order to calculate a signature hash for an SSLv3 CertificateVerify message as per RFC6101. It is only set after all handshake messages have already been digested via OP_digest_update() calls. The parameter provides the master secret value to be added to the digest. The digest implementation should calculate the complete digest as per RFC6101 section 5.6.8. The next call after setting this parameter should be OP_digest_final().

SEE ALSO

EVP_MD_CTX_set_params (3), provider-digest (7), OSSL_PROVIDER-FIPS (7), OSSL_PROVIDER-default (7)

COPYRIGHT

Copyright 2020 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

280 - Linux cli command DISCARD

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DISCARD and provides detailed information about the command DISCARD, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DISCARD.

NAME 🖥️ DISCARD 🖥️

discard session state

SYNOPSIS

DISCARD { ALL | PLANS | SEQUENCES | TEMPORARY | TEMP }

DESCRIPTION

DISCARD releases internal resources associated with a database session. This command is useful for partially or fully resetting the sessions state. There are several subcommands to release different types of resources; the DISCARD ALL variant subsumes all the others, and also resets additional state.

PARAMETERS

PLANS

Releases all cached query plans, forcing re-planning to occur the next time the associated prepared statement is used.

SEQUENCES

Discards all cached sequence-related state, including currval()/lastval() information and any preallocated sequence values that have not yet been returned by nextval(). (See CREATE SEQUENCE (CREATE_SEQUENCE(7)) for a description of preallocated sequence values.)

TEMPORARY or TEMP

Drops all temporary tables created in the current session.

ALL

Releases all temporary resources associated with the current session and resets the session to its initial state. Currently, this has the same effect as executing the following sequence of statements:

CLOSE ALL; SET SESSION AUTHORIZATION DEFAULT; RESET ALL; DEALLOCATE ALL; UNLISTEN *; SELECT pg_advisory_unlock_all(); DISCARD PLANS; DISCARD TEMP; DISCARD SEQUENCES;

NOTES

DISCARD ALL cannot be executed inside a transaction block.

COMPATIBILITY

DISCARD is a PostgreSQL extension.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

281 - Linux cli command EVP_PKEY-DHssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_PKEY-DHssl and provides detailed information about the command EVP_PKEY-DHssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_PKEY-DHssl.

NAME 🖥️ EVP_PKEY-DHssl 🖥️

DH, EVP_PKEY-DHX, EVP_KEYMGMT-DH, EVP_KEYMGMT-DHX - EVP_PKEY DH and DHX keytype and algorithm support

DESCRIPTION

For DH FFC key agreement, two classes of domain parameters can be used: “safe” domain parameters that are associated with approved named safe-prime groups, and a class of “FIPS186-type” domain parameters. FIPS186-type domain parameters should only be used for backward compatibility with existing applications that cannot be upgraded to use the approved safe-prime groups.

See EVP_PKEY-FFC (7) for more information about FFC keys.

The DH key type uses PKCS#3 format which saves p and g, but not the q value. The DHX key type uses X9.42 format which saves the value of q and this must be used for FIPS186-4. If key validation is required, users should be aware of the nuances associated with FIPS186-4 style parameters as discussed in “DH key validation”.

DH and DHX domain parameters

In addition to the common FCC parameters that all FFC keytypes should support (see “FFC parameters” in EVP_PKEY-FFC (7)) the DHX and DH keytype implementations support the following:

“group” (OSSL_PKEY_PARAM_GROUP_NAME) <UTF8 string>
Sets or gets a string that associates a DH or DHX named safe prime group with known values for p, q and g. The following values can be used by the OpenSSL’s default and FIPS providers: “ffdhe2048”, “ffdhe3072”, “ffdhe4096”, “ffdhe6144”, “ffdhe8192”, “modp_2048”, “modp_3072”, “modp_4096”, “modp_6144”, “modp_8192”. The following additional values can also be used by OpenSSL’s default provider: “modp_1536”, “dh_1024_160”, “dh_2048_224”, “dh_2048_256”. DH/DHX named groups can be easily validated since the parameters are well known. For protocols that only transfer p and g the value of q can also be retrieved.

DH and DHX additional parameters

“encoded-pub-key” (OSSL_PKEY_PARAM_ENCODED_PUBLIC_KEY) <octet string>
Used for getting and setting the encoding of the DH public key used in a key exchange message for the TLS protocol. See EVP_PKEY_set1_encoded_public_key() and EVP_PKEY_get1_encoded_public_key().

DH additional domain parameters

“safeprime-generator” (OSSL_PKEY_PARAM_DH_GENERATOR) <integer>
Used for DH generation of safe primes using the old safe prime generator code. The default value is 2. It is recommended to use a named safe prime group instead, if domain parameter validation is required. Randomly generated safe primes are not allowed by FIPS, so setting this value for the OpenSSL FIPS provider will instead choose a named safe prime group based on the size of p.

DH and DHX domain parameter / key generation parameters

In addition to the common FFC key generation parameters that all FFC key types should support (see “FFC key generation parameters” in EVP_PKEY-FFC (7)) the DH and DHX keytype implementation supports the following:

“type” (OSSL_PKEY_PARAM_FFC_TYPE) <UTF8 string>
Sets the type of parameter generation. For DH valid values are:

“fips186_4”

“default”

“fips186_2”

These are described in “FFC key generation parameters” in EVP_PKEY-FFC (7)

“group”
This specifies that a named safe prime name will be chosen using the “pbits” type.

“generator”
A safe prime generator. See the “safeprime-generator” type above. This is only valid for DH keys.

“pbits” (OSSL_PKEY_PARAM_FFC_PBITS) <unsigned integer>
Sets the size (in bits) of the prime ‘p’. For “fips186_4” this must be 2048. For “fips186_2” this must be 1024. For “group” this can be any one of 2048, 3072, 4096, 6144 or 8192.

“priv_len” (OSSL_PKEY_PARAM_DH_PRIV_LEN) <integer>
An optional value to set the maximum length of the generated private key. The default value used if this is not set is the maximum value of BN_num_bits(q)). The minimum value that this can be set to is 2 * s. Where s is the security strength of the key which has values of 112, 128, 152, 176 and 200 for key sizes of 2048, 3072, 4096, 6144 and 8192.

DH key validation

For DHX that is not a named group the FIPS186-4 standard specifies that the values used for FFC parameter generation are also required for parameter validation. This means that optional FFC domain parameter values for seed, pcounter and gindex or hindex may need to be stored for validation purposes. For DHX the seed and pcounter can be stored in ASN1 data (but the gindex or hindex cannot be stored). It is recommended to use a named safe prime group instead.

For DH keys, EVP_PKEY_param_check (3) behaves in the following way: The OpenSSL FIPS provider tests if the parameters are either an approved safe prime group OR that the FFC parameters conform to FIPS186-4 as defined in SP800-56Ar3 Assurances of Domain-Parameter Validity. The OpenSSL default provider uses simpler checks that allows there to be no q value for backwards compatibility.

For DH keys, EVP_PKEY_param_check_quick (3) is equivalent to EVP_PKEY_param_check (3).

For DH keys, EVP_PKEY_public_check (3) conforms to SP800-56Ar3 FFC Full Public-Key Validation.

For DH keys, EVP_PKEY_public_check_quick (3) conforms to SP800-56Ar3 FFC Partial Public-Key Validation when the DH key is an approved named safe prime group, otherwise it is the same as EVP_PKEY_public_check (3).

For DH Keys, EVP_PKEY_private_check (3) tests that the private key is in the correct range according to SP800-56Ar3. The OpenSSL FIPS provider requires the value of q to be set (note that this is set for named safe prime groups). For backwards compatibility the OpenSSL default provider only requires p to be set.

For DH keys, EVP_PKEY_pairwise_check (3) conforms to SP800-56Ar3 Owner Assurance of Pair-wise Consistency.

EXAMPLES

An EVP_PKEY context can be obtained by calling:

EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “DH”, NULL);

A DH key can be generated with a named safe prime group by calling:

int priv_len = 2 * 112; OSSL_PARAM params[3]; EVP_PKEY *pkey = NULL; EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “DH”, NULL); params[0] = OSSL_PARAM_construct_utf8_string(“group”, “ffdhe2048”, 0); /* “priv_len” is optional */ params[1] = OSSL_PARAM_construct_int(“priv_len”, &priv_len); params[2] = OSSL_PARAM_construct_end(); EVP_PKEY_keygen_init(pctx); EVP_PKEY_CTX_set_params(pctx, params); EVP_PKEY_generate(pctx, &pkey); … EVP_PKEY_free(pkey); EVP_PKEY_CTX_free(pctx);

DHX domain parameters can be generated according to FIPS186-4 by calling:

int gindex = 2; unsigned int pbits = 2048; unsigned int qbits = 256; OSSL_PARAM params[6]; EVP_PKEY *param_key = NULL; EVP_PKEY_CTX *pctx = NULL; pctx = EVP_PKEY_CTX_new_from_name(NULL, “DHX”, NULL); EVP_PKEY_paramgen_init(pctx); params[0] = OSSL_PARAM_construct_uint(“pbits”, &pbits); params[1] = OSSL_PARAM_construct_uint(“qbits”, &qbits); params[2] = OSSL_PARAM_construct_int(“gindex”, &gindex); params[3] = OSSL_PARAM_construct_utf8_string(“type”, “fips186_4”, 0); params[4] = OSSL_PARAM_construct_utf8_string(“digest”, “SHA256”, 0); params[5] = OSSL_PARAM_construct_end(); EVP_PKEY_CTX_set_params(pctx, params); EVP_PKEY_generate(pctx, &param_key); EVP_PKEY_print_params(bio_out, param_key, 0, NULL); … EVP_PKEY_free(param_key); EVP_PKEY_CTX_free(pctx);

A DH key can be generated using domain parameters by calling:

EVP_PKEY *key = NULL; EVP_PKEY_CTX *gctx = EVP_PKEY_CTX_new_from_pkey(NULL, param_key, NULL); EVP_PKEY_keygen_init(gctx); EVP_PKEY_generate(gctx, &key); EVP_PKEY_print_private(bio_out, key, 0, NULL); … EVP_PKEY_free(key); EVP_PKEY_CTX_free(gctx);

To validate FIPS186-4 DHX domain parameters decoded from PEM or DER data, additional values used during generation may be required to be set into the key.

EVP_PKEY_todata(), OSSL_PARAM_merge(), and EVP_PKEY_fromdata() are useful to add these parameters to the original key or domain parameters before the actual validation. In production code the return values should be checked.

EVP_PKEY *received_domp = …; /* parameters received and decoded */ unsigned char *seed = …; /* and additional parameters received */ size_t seedlen = …; /* by other means, required */ int gindex = …; /* for the validation */ int pcounter = …; int hindex = …; OSSL_PARAM extra_params[4]; OSSL_PARAM *domain_params = NULL; OSSL_PARAM *merged_params = NULL; EVP_PKEY_CTX *ctx = NULL, *validate_ctx = NULL; EVP_PKEY *complete_domp = NULL; EVP_PKEY_todata(received_domp, OSSL_KEYMGMT_SELECT_DOMAIN_PARAMETERS, &domain_params); extra_params[0] = OSSL_PARAM_construct_octet_string(“seed”, seed, seedlen); /* * NOTE: For unverifiable g use “hindex” instead of “gindex” * extra_params[1] = OSSL_PARAM_construct_int(“hindex”, &hindex); */ extra_params[1] = OSSL_PARAM_construct_int(“gindex”, &gindex); extra_params[2] = OSSL_PARAM_construct_int(“pcounter”, &pcounter); extra_params[3] = OSSL_PARAM_construct_end(); merged_params = OSSL_PARAM_merge(domain_params, extra_params); ctx = EVP_PKEY_CTX_new_from_name(NULL, “DHX”, NULL); EVP_PKEY_fromdata_init(ctx); EVP_PKEY_fromdata(ctx, &complete_domp, OSSL_KEYMGMT_SELECT_ALL, merged_params); validate_ctx = EVP_PKEY_CTX_new_from_pkey(NULL, complete_domp, NULL); if (EVP_PKEY_param_check(validate_ctx) > 0) /* validation_passed(); */ else /* validation_failed(); */ OSSL_PARAM_free(domain_params); OSSL_PARAM_free(merged_params); EVP_PKEY_CTX_free(ctx); EVP_PKEY_CTX_free(validate_ctx); EVP_PKEY_free(complete_domp);

CONFORMING TO

RFC 7919 (TLS ffdhe named safe prime groups)

RFC 3526 (IKE modp named safe prime groups)

RFC 5114 (Additional DH named groups for dh_1024_160", “dh_2048_224” and “dh_2048_256”).

The following sections of SP800-56Ar3:

Appendix D: FFC Safe-prime Groups

The following sections of FIPS186-4:

SEE ALSO

EVP_PKEY-FFC (7), EVP_KEYEXCH-DH (7) EVP_PKEY (3), provider-keymgmt (7), EVP_KEYMGMT (3), OSSL_PROVIDER-default (7), OSSL_PROVIDER-FIPS (7)

COPYRIGHT

Copyright 2020-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

282 - Linux cli command migration_guidessl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command migration_guidessl and provides detailed information about the command migration_guidessl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the migration_guidessl.

NAME 🖥️ migration_guidessl 🖥️

guide-migration, migration_guide - OpenSSL Guide: Migrating from older OpenSSL versions

SYNOPSIS

See the individual manual pages for details.

DESCRIPTION

This guide details the changes required to migrate to new versions of OpenSSL. Currently this covers OpenSSL 3.0 & 3.1. For earlier versions refer to <https://github.com/openssl/openssl/blob/master/CHANGES.md>. For an overview of some of the key concepts introduced in OpenSSL 3.0 see crypto (7).

OPENSSL 3.1

Main Changes from OpenSSL 3.0

The FIPS provider in OpenSSL 3.1 includes some non-FIPS validated algorithms, consequently the property query fips=yes is mandatory for applications that want to operate in a FIPS approved manner. The algorithms are:

Triple DES ECB

Triple DES CBC

EdDSA

There are no other changes requiring additional migration measures since OpenSSL 3.0.

OPENSSL 3.0

Main Changes from OpenSSL 1.1.1

Major Release

OpenSSL 3.0 is a major release and consequently any application that currently uses an older version of OpenSSL will at the very least need to be recompiled in order to work with the new version. It is the intention that the large majority of applications will work unchanged with OpenSSL 3.0 if those applications previously worked with OpenSSL 1.1.1. However this is not guaranteed and some changes may be required in some cases. Changes may also be required if applications need to take advantage of some of the new features available in OpenSSL 3.0 such as the availability of the FIPS module.

License Change

In previous versions, OpenSSL was licensed under the dual OpenSSL and SSLeay licenses <https://www.openssl.org/source/license-openssl-ssleay.txt> (both licenses apply). From OpenSSL 3.0 this is replaced by the Apache License v2 <https://www.openssl.org/source/apache-license-2.0.txt>.

Providers and FIPS support

One of the key changes from OpenSSL 1.1.1 is the introduction of the Provider concept. Providers collect together and make available algorithm implementations. With OpenSSL 3.0 it is possible to specify, either programmatically or via a config file, which providers you want to use for any given application. OpenSSL 3.0 comes with 5 different providers as standard. Over time third parties may distribute additional providers that can be plugged into OpenSSL. All algorithm implementations available via providers are accessed through the “high level” APIs (for example those functions prefixed with EVP). They cannot be accessed using the “Low Level APIs”.

One of the standard providers available is the FIPS provider. This makes available FIPS validated cryptographic algorithms. The FIPS provider is disabled by default and needs to be enabled explicitly at configuration time using the enable-fips option. If it is enabled, the FIPS provider gets built and installed in addition to the other standard providers. No separate installation procedure is necessary. There is however a dedicated install_fips make target, which serves the special purpose of installing only the FIPS provider into an existing OpenSSL installation.

Not all algorithms may be available for the application at a particular moment. If the application code uses any digest or cipher algorithm via the EVP interface, the application should verify the result of the EVP_EncryptInit (3), EVP_EncryptInit_ex (3), and EVP_DigestInit (3) functions. In case when the requested algorithm is not available, these functions will fail.

See also “Legacy Algorithms” for information on the legacy provider.

See also “Completing the installation of the FIPS Module” and “Using the FIPS Module in applications”.

Low Level APIs

OpenSSL has historically provided two sets of APIs for invoking cryptographic algorithms: the “high level” APIs (such as the EVP APIs) and the “low level” APIs. The high level APIs are typically designed to work across all algorithm types. The “low level” APIs are targeted at a specific algorithm implementation. For example, the EVP APIs provide the functions EVP_EncryptInit_ex (3), EVP_EncryptUpdate (3) and EVP_EncryptFinal (3) to perform symmetric encryption. Those functions can be used with the algorithms AES, CHACHA, 3DES etc. On the other hand, to do AES encryption using the low level APIs you would have to call AES specific functions such as AES_set_encrypt_key (3), AES_encrypt (3), and so on. The functions for 3DES are different. Use of the low level APIs has been informally discouraged by the OpenSSL development team for a long time. However in OpenSSL 3.0 this is made more formal. All such low level APIs have been deprecated. You may still use them in your applications, but you may start to see deprecation warnings during compilation (dependent on compiler support for this). Deprecated APIs may be removed from future versions of OpenSSL so you are strongly encouraged to update your code to use the high level APIs instead.

This is described in more detail in “Deprecation of Low Level Functions”

Legacy Algorithms

Some cryptographic algorithms such as MD2 and DES that were available via the EVP APIs are now considered legacy and their use is strongly discouraged. These legacy EVP algorithms are still available in OpenSSL 3.0 but not by default. If you want to use them then you must load the legacy provider. This can be as simple as a config file change, or can be done programmatically. See OSSL_PROVIDER-legacy (7) for a complete list of algorithms. Applications using the EVP APIs to access these algorithms should instead use more modern algorithms. If that is not possible then these applications should ensure that the legacy provider has been loaded. This can be achieved either programmatically or via configuration. See crypto (7) man page for more information about providers.

Engines and “METHOD” APIs

The refactoring to support Providers conflicts internally with the APIs used to support engines, including the ENGINE API and any function that creates or modifies custom “METHODS” (for example EVP_MD_meth_new (3), EVP_CIPHER_meth_new (3), EVP_PKEY_meth_new (3), RSA_meth_new (3), EC_KEY_METHOD_new (3), etc.). These functions are being deprecated in OpenSSL 3.0, and users of these APIs should know that their use can likely bypass provider selection and configuration, with unintended consequences. This is particularly relevant for applications written to use the OpenSSL 3.0 FIPS module, as detailed below. Authors and maintainers of external engines are strongly encouraged to refactor their code transforming engines into providers using the new Provider API and avoiding deprecated methods.

Support of legacy engines

If openssl is not built without engine support or deprecated API support, engines will still work. However, their applicability will be limited.

New algorithms provided via engines will still work.

Engine-backed keys can be loaded via custom OSSL_STORE implementation. In this case the EVP_PKEY objects created via ENGINE_load_private_key (3) will be considered legacy and will continue to work.

To ensure the future compatibility, the engines should be turned to providers. To prefer the provider-based hardware offload, you can specify the default properties to prefer your provider.

Setting engine-based or application-based default low-level crypto method such as RSA_METHOD or EC_KEY_METHOD is still possible and keys inside the default provider will use the engine-based implementation for the crypto operations. However EVP_PKEYs created by decoding by using OSSL_DECODER, PEM_ or d2i_ APIs will be provider-based. To create a fully legacy EVP_PKEYs EVP_PKEY_set1_RSA (3), EVP_PKEY_set1_EC_KEY (3) or similar functions must be used.

Versioning Scheme

The OpenSSL versioning scheme has changed with the OpenSSL 3.0 release. The new versioning scheme has this format:

MAJOR.MINOR.PATCH

For OpenSSL 1.1.1 and below, different patch levels were indicated by a letter at the end of the release version number. This will no longer be used and instead the patch level is indicated by the final number in the version. A change in the second (MINOR) number indicates that new features may have been added. OpenSSL versions with the same major number are API and ABI compatible. If the major number changes then API and ABI compatibility is not guaranteed.

For more information, see OpenSSL_version (3).

Other major new features

Certificate Management Protocol (CMP, RFC 4210)

This also covers CRMF (RFC 4211) and HTTP transfer (RFC 6712) See openssl-cmp (1) and OSSL_CMP_exec_certreq (3) as starting points.

HTTP(S) client

A proper HTTP(S) client that supports GET and POST, redirection, plain and ASN.1-encoded contents, proxies, and timeouts.

Key Derivation Function API (EVP_KDF)

This simplifies the process of adding new KDF and PRF implementations.

Previously KDF algorithms had been shoe-horned into using the EVP_PKEY object which was not a logical mapping. Existing applications that use KDF algorithms using EVP_PKEY (scrypt, TLS1 PRF and HKDF) may be slower as they use an EVP_KDF bridge internally. All new applications should use the new EVP_KDF (3) interface. See also “Key Derivation Function (KDF)” in OSSL_PROVIDER-default (7) and “Key Derivation Function (KDF)” in OSSL_PROVIDER-FIPS (7).

Message Authentication Code API (EVP_MAC)

This simplifies the process of adding MAC implementations.

This includes a generic EVP_PKEY to EVP_MAC bridge, to facilitate the continued use of MACs through raw private keys in functionality such as EVP_DigestSign (3) and EVP_DigestVerify (3).

All new applications should use the new EVP_MAC (3) interface. See also “Message Authentication Code (MAC)” in OSSL_PROVIDER-default (7) and “Message Authentication Code (MAC)” in OSSL_PROVIDER-FIPS (7).

Algorithm Fetching

Using calls to convenience functions such as EVP_sha256() and EVP_aes_256_gcm() may incur a performance penalty when using providers. Retrieving algorithms from providers involves searching for an algorithm by name. This is much slower than directly accessing a method table. It is recommended to prefetch algorithms if an algorithm is used many times. See “Performance” in crypto (7), “Explicit fetching” in crypto (7) and “Implicit fetching” in crypto (7).

Support for Linux Kernel TLS

In order to use KTLS, support for it must be compiled in using the enable-ktls configuration option. It must also be enabled at run time using the SSL_OP_ENABLE_KTLS option.

New Algorithms

  • KDF algorithms “SINGLE STEP” and “SSH” See EVP_KDF-SS (7) and EVP_KDF-SSHKDF (7)

  • MAC Algorithms “GMAC” and “KMAC” See EVP_MAC-GMAC (7) and EVP_MAC-KMAC (7).

  • KEM Algorithm “RSASVE” See EVP_KEM-RSA (7).

  • Cipher Algorithm “AES-SIV” See “SIV Mode” in EVP_EncryptInit (3).

  • AES Key Wrap inverse ciphers supported by EVP layer. The inverse ciphers use AES decryption for wrapping, and AES encryption for unwrapping. The algorithms are: “AES-128-WRAP-INV”, “AES-192-WRAP-INV”, “AES-256-WRAP-INV”, “AES-128-WRAP-PAD-INV”, “AES-192-WRAP-PAD-INV” and “AES-256-WRAP-PAD-INV”.

  • CTS ciphers added to EVP layer. The algorithms are “AES-128-CBC-CTS”, “AES-192-CBC-CTS”, “AES-256-CBC-CTS”, “CAMELLIA-128-CBC-CTS”, “CAMELLIA-192-CBC-CTS” and “CAMELLIA-256-CBC-CTS”. CS1, CS2 and CS3 variants are supported.

CMS and PKCS#7 updates

  • Added CAdES-BES signature verification support.

  • Added CAdES-BES signature scheme and attributes support (RFC 5126) to CMS API.

  • Added AuthEnvelopedData content type structure (RFC 5083) using AES_GCM This uses the AES-GCM parameter (RFC 5084) for the Cryptographic Message Syntax. Its purpose is to support encryption and decryption of a digital envelope that is both authenticated and encrypted using AES GCM mode.

  • PKCS7_get_octet_string (3) and PKCS7_type_is_other (3) were made public.

PKCS#12 API updates

The default algorithms for pkcs12 creation with the PKCS12_create() function were changed to more modern PBKDF2 and AES based algorithms. The default MAC iteration count was changed to PKCS12_DEFAULT_ITER to make it equal with the password-based encryption iteration count. The default digest algorithm for the MAC computation was changed to SHA-256. The pkcs12 application now supports -legacy option that restores the previous default algorithms to support interoperability with legacy systems.

Added enhanced PKCS#12 APIs which accept a library context OSSL_LIB_CTX and (where relevant) a property query. Other APIs which handle PKCS#7 and PKCS#8 objects have also been enhanced where required. This includes:

PKCS12_add_key_ex (3), PKCS12_add_safe_ex (3), PKCS12_add_safes_ex (3), PKCS12_create_ex (3), PKCS12_decrypt_skey_ex (3), PKCS12_init_ex (3), PKCS12_item_decrypt_d2i_ex (3), PKCS12_item_i2d_encrypt_ex (3), PKCS12_key_gen_asc_ex (3), PKCS12_key_gen_uni_ex (3), PKCS12_key_gen_utf8_ex (3), PKCS12_pack_p7encdata_ex (3), PKCS12_pbe_crypt_ex (3), PKCS12_PBE_keyivgen_ex (3), PKCS12_SAFEBAG_create_pkcs8_encrypt_ex (3), PKCS5_pbe2_set_iv_ex (3), PKCS5_pbe_set0_algor_ex (3), PKCS5_pbe_set_ex (3), PKCS5_pbkdf2_set_ex (3), PKCS5_v2_PBE_keyivgen_ex (3), PKCS5_v2_scrypt_keyivgen_ex (3), PKCS8_decrypt_ex (3), PKCS8_encrypt_ex (3), PKCS8_set0_pbe_ex (3).

As part of this change the EVP_PBE_xxx APIs can also accept a library context and property query and will call an extended version of the key/IV derivation function which supports these parameters. This includes EVP_PBE_CipherInit_ex (3), EVP_PBE_find_ex (3) and EVP_PBE_scrypt_ex (3).

PKCS#12 KDF versus FIPS

Unlike in 1.x.y, the PKCS12KDF algorithm used when a PKCS#12 structure is created with a MAC that does not work with the FIPS provider as the PKCS12KDF is not a FIPS approvable mechanism.

See EVP_KDF-PKCS12KDF (7), PKCS12_create (3), openssl-pkcs12 (1), OSSL_PROVIDER-FIPS (7).

Windows thread synchronization changes

Windows thread synchronization uses read/write primitives (SRWLock) when supported by the OS, otherwise CriticalSection continues to be used.

Trace API

A new generic trace API has been added which provides support for enabling instrumentation through trace output. This feature is mainly intended as an aid for developers and is disabled by default. To utilize it, OpenSSL needs to be configured with the enable-trace option.

If the tracing API is enabled, the application can activate trace output by registering BIOs as trace channels for a number of tracing and debugging categories. See OSSL_trace_enabled (3).

Key validation updates

EVP_PKEY_public_check (3) and EVP_PKEY_param_check (3) now work for more key types. This includes RSA, DSA, ED25519, X25519, ED448 and X448. Previously (in 1.1.1) they would return -2. For key types that do not have parameters then EVP_PKEY_param_check (3) will always return 1.

Other notable deprecations and changes

The function code part of an OpenSSL error code is no longer relevant

This code is now always set to zero. Related functions are deprecated.

STACK and HASH macros have been cleaned up

The type-safe wrappers are declared everywhere and implemented once. See DEFINE_STACK_OF (3) and DEFINE_LHASH_OF_EX (3).

The RAND_DRBG subsystem has been removed

The new EVP_RAND (3) is a partial replacement: the DRBG callback framework is absent. The RAND_DRBG API did not fit well into the new provider concept as implemented by EVP_RAND and EVP_RAND_CTX.

Removed FIPS_mode() and FIPS_mode_set()

These functions are legacy APIs that are not applicable to the new provider model. Applications should instead use EVP_default_properties_is_fips_enabled (3) and EVP_default_properties_enable_fips (3).

Key generation is slower

The Miller-Rabin test now uses 64 rounds, which is used for all prime generation, including RSA key generation. This affects the time for larger keys sizes.

The default key generation method for the regular 2-prime RSA keys was changed to the FIPS186-4 B.3.6 method (Generation of Probable Primes with Conditions Based on Auxiliary Probable Primes). This method is slower than the original method.

Change PBKDF2 to conform to SP800-132 instead of the older PKCS5 RFC2898

This checks that the salt length is at least 128 bits, the derived key length is at least 112 bits, and that the iteration count is at least 1000. For backwards compatibility these checks are disabled by default in the default provider, but are enabled by default in the FIPS provider.

To enable or disable the checks see OSSL_KDF_PARAM_PKCS5 in EVP_KDF-PBKDF2 (7). The parameter can be set using EVP_KDF_derive (3).

Enforce a minimum DH modulus size of 512 bits

Smaller sizes now result in an error.

SM2 key changes

EC EVP_PKEYs with the SM2 curve have been reworked to automatically become EVP_PKEY_SM2 rather than EVP_PKEY_EC.

Unlike in previous OpenSSL versions, this means that applications cannot call EVP_PKEY_set_alias_type(pkey, EVP_PKEY_SM2) to get SM2 computations.

Parameter and key generation is also reworked to make it possible to generate EVP_PKEY_SM2 parameters and keys. Applications must now generate SM2 keys directly and must not create an EVP_PKEY_EC key first. It is no longer possible to import an SM2 key with domain parameters other than the SM2 elliptic curve ones.

Validation of SM2 keys has been separated from the validation of regular EC keys, allowing to improve the SM2 validation process to reject loaded private keys that are not conforming to the SM2 ISO standard. In particular, a private scalar k outside the range 1 <= k < n-1 is now correctly rejected.

EVP_PKEY_set_alias_type() method has been removed

This function made a EVP_PKEY object mutable after it had been set up. In OpenSSL 3.0 it was decided that a provided key should not be able to change its type, so this function has been removed.

Functions that return an internal key should be treated as read only

Functions such as EVP_PKEY_get0_RSA (3) behave slightly differently in OpenSSL 3.0. Previously they returned a pointer to the low-level key used internally by libcrypto. From OpenSSL 3.0 this key may now be held in a provider. Calling these functions will only return a handle on the internal key where the EVP_PKEY was constructed using this key in the first place, for example using a function or macro such as EVP_PKEY_assign_RSA (3), EVP_PKEY_set1_RSA (3), etc. Where the EVP_PKEY holds a provider managed key, then these functions now return a cached copy of the key. Changes to the internal provider key that take place after the first time the cached key is accessed will not be reflected back in the cached copy. Similarly any changes made to the cached copy by application code will not be reflected back in the internal provider key.

For the above reasons the keys returned from these functions should typically be treated as read-only. To emphasise this the value returned from EVP_PKEY_get0_RSA (3), EVP_PKEY_get0_DSA (3), EVP_PKEY_get0_EC_KEY (3) and EVP_PKEY_get0_DH (3) have been made const. This may break some existing code. Applications broken by this change should be modified. The preferred solution is to refactor the code to avoid the use of these deprecated functions. Failing this the code should be modified to use a const pointer instead. The EVP_PKEY_get1_RSA (3), EVP_PKEY_get1_DSA (3), EVP_PKEY_get1_EC_KEY (3) and EVP_PKEY_get1_DH (3) functions continue to return a non-const pointer to enable them to be “freed”. However they should also be treated as read-only.

The public key check has moved from EVP_PKEY_derive() to EVP_PKEY_derive_set_peer()

This may mean result in an error in EVP_PKEY_derive_set_peer (3) rather than during EVP_PKEY_derive (3). To disable this check use EVP_PKEY_derive_set_peer_ex(dh, peer, 0).

The print format has cosmetic changes for some functions

The output from numerous “printing” functions such as X509_signature_print (3), X509_print_ex (3), X509_CRL_print_ex (3), and other similar functions has been amended such that there may be cosmetic differences between the output observed in 1.1.1 and 3.0. This also applies to the -text output from the openssl x509 and openssl crl applications.

Interactive mode from the openssl program has been removed

From now on, running it without arguments is equivalent to openssl help.

The error return values from some control calls (ctrl) have changed

One significant change is that controls which used to return -2 for invalid inputs, now return -1 indicating a generic error condition instead.

DH and DHX key types have different settable parameters

Previously (in 1.1.1) these conflicting parameters were allowed, but will now result in errors. See EVP_PKEY-DH (7) for further details. This affects the behaviour of openssl-genpkey (1) for DH parameter generation.

EVP_CIPHER_CTX_set_flags() ordering change

If using a cipher from a provider the EVP_CIPH_FLAG_LENGTH_BITS flag can only be set after the cipher has been assigned to the cipher context. See “FLAGS” in EVP_EncryptInit (3) for more information.

Validation of operation context parameters

Due to move of the implementation of cryptographic operations to the providers, validation of various operation parameters can be postponed until the actual operation is executed where previously it happened immediately when an operation parameter was set.

For example when setting an unsupported curve with EVP_PKEY_CTX_set_ec_paramgen_curve_nid() this function call will not fail but later keygen operations with the EVP_PKEY_CTX will fail.

Removal of function code from the error codes

The function code part of the error code is now always set to 0. For that reason the ERR_GET_FUNC() macro was removed. Applications must resolve the error codes only using the library number and the reason code.

ChaCha20-Poly1305 cipher does not allow a truncated IV length to be used

In OpenSSL 3.0 setting the IV length to any value other than 12 will result in an error. Prior to OpenSSL 3.0 the ivlen could be smaller that the required 12 byte length, using EVP_CIPHER_CTX_ctrl(ctx, EVP_CRTL_AEAD_SET_IVLEN, ivlen, NULL). This resulted in an IV that had leading zero padding.

Installation and Compilation

Please refer to the INSTALL.md file in the top of the distribution for instructions on how to build and install OpenSSL 3.0. Please also refer to the various platform specific NOTES files for your specific platform.

Upgrading from OpenSSL 1.1.1

Upgrading to OpenSSL 3.0 from OpenSSL 1.1.1 should be relatively straight forward in most cases. The most likely area where you will encounter problems is if you have used low level APIs in your code (as discussed above). In that case you are likely to start seeing deprecation warnings when compiling your application. If this happens you have 3 options:

  1. Ignore the warnings. They are just warnings. The deprecated functions are still present and you may still use them. However be aware that they may be removed from a future version of OpenSSL.

  2. Suppress the warnings. Refer to your compiler documentation on how to do this.

  3. Remove your usage of the low level APIs. In this case you will need to rewrite your code to use the high level APIs instead

Error code changes

As OpenSSL 3.0 provides a brand new Encoder/Decoder mechanism for working with widely used file formats, application code that checks for particular error reason codes on key loading failures might need an update.

Password-protected keys may deserve special attention. If only some errors are treated as an indicator that the user should be asked about the password again, it’s worth testing these scenarios and processing the newly relevant codes.

There may be more cases to treat specially, depending on the calling application code.

Upgrading from OpenSSL 1.0.2

Upgrading to OpenSSL 3.0 from OpenSSL 1.0.2 is likely to be significantly more difficult. In addition to the issues discussed above in the section about “Upgrading from OpenSSL 1.1.1”, the main things to be aware of are:

  1. The build and installation procedure has changed significantly. Check the file INSTALL.md in the top of the installation for instructions on how to build and install OpenSSL for your platform. Also read the various NOTES files in the same directory, as applicable for your platform.

  2. Many structures have been made opaque in OpenSSL 3.0. The structure definitions have been removed from the public header files and moved to internal header files. In practice this means that you can no longer stack allocate some structures. Instead they must be heap allocated through some function call (typically those function names have a _new suffix to them). Additionally you must use “setter” or “getter” functions to access the fields within those structures. For example code that previously looked like this: EVP_MD_CTX md_ctx; /* This line will now generate compiler errors */ EVP_MD_CTX_init(&md_ctx); The code needs to be amended to look like this: EVP_MD_CTX *md_ctx; md_ctx = EVP_MD_CTX_new(); … … EVP_MD_CTX_free(md_ctx);

  3. Support for TLSv1.3 has been added. This has a number of implications for SSL/TLS applications. See the TLS1.3 page <https://wiki.openssl.org/index.php/TLS1.3> for further details.

More details about the breaking changes between OpenSSL versions 1.0.2 and 1.1.0 can be found on the OpenSSL 1.1.0 Changes page <https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes>.

Upgrading from the OpenSSL 2.0 FIPS Object Module

The OpenSSL 2.0 FIPS Object Module was a separate download that had to be built separately and then integrated into your main OpenSSL 1.0.2 build. In OpenSSL 3.0 the FIPS support is fully integrated into the mainline version of OpenSSL and is no longer a separate download. For further information see “Completing the installation of the FIPS Module”.

The function calls FIPS_mode() and FIPS_mode_set() have been removed from OpenSSL 3.0. You should rewrite your application to not use them. See fips_module (7) and OSSL_PROVIDER-FIPS (7) for details.

Completing the installation of the FIPS Module

The FIPS Module will be built and installed automatically if FIPS support has been configured. The current documentation can be found in the README-FIPS <https://github.com/openssl/openssl/blob/master/README-FIPS.md> file.

Programming

Applications written to work with OpenSSL 1.1.1 will mostly just work with OpenSSL 3.0. However changes will be required if you want to take advantage of some of the new features that OpenSSL 3.0 makes available. In order to do that you need to understand some new concepts introduced in OpenSSL 3.0. Read “Library contexts” in crypto (7) for further information.

Library Context

A library context allows different components of a complex application to each use a different library context and have different providers loaded with different configuration settings. See “Library contexts” in crypto (7) for further info.

If the user creates an OSSL_LIB_CTX via OSSL_LIB_CTX_new (3) then many functions may need to be changed to pass additional parameters to handle the library context.

Using a Library Context - Old functions that should be changed

If a library context is needed then all EVP_* digest functions that return a const EVP_MD * such as EVP_sha256() should be replaced with a call to EVP_MD_fetch (3). See “ALGORITHM FETCHING” in crypto (7).

If a library context is needed then all EVP_* cipher functions that return a const EVP_CIPHER * such as EVP_aes_128_cbc() should be replaced vith a call to EVP_CIPHER_fetch (3). See “ALGORITHM FETCHING” in crypto (7).

Some functions can be passed an object that has already been set up with a library context such as d2i_X509 (3), d2i_X509_CRL (3), d2i_X509_REQ (3) and d2i_X509_PUBKEY (3). If NULL is passed instead then the created object will be set up with the default library context. Use X509_new_ex (3), X509_CRL_new_ex (3), X509_REQ_new_ex (3) and X509_PUBKEY_new_ex (3) if a library context is required.

All functions listed below with a NAME have a replacement function NAME_ex that takes OSSL_LIB_CTX as an additional argument. Functions that have other mappings are listed along with the respective name.

  • ASN1_item_new (3), ASN1_item_d2i (3), ASN1_item_d2i_fp (3), ASN1_item_d2i_bio (3), ASN1_item_sign (3) and ASN1_item_verify (3)

  • BIO_new (3)

  • b2i_RSA_PVK_bio() and i2b_PVK_bio()

  • BN_CTX_new (3) and BN_CTX_secure_new (3)

  • CMS_AuthEnvelopedData_create (3), CMS_ContentInfo_new (3), CMS_data_create (3), CMS_digest_create (3), CMS_EncryptedData_encrypt (3), CMS_encrypt (3), CMS_EnvelopedData_create (3), CMS_ReceiptRequest_create0 (3) and CMS_sign (3)

  • CONF_modules_load_file (3)

  • CTLOG_new (3), CTLOG_new_from_base64 (3) and CTLOG_STORE_new (3)

  • CT_POLICY_EVAL_CTX_new (3)

  • d2i_AutoPrivateKey (3), d2i_PrivateKey (3) and d2i_PUBKEY (3)

  • d2i_PrivateKey_bio (3) and d2i_PrivateKey_fp (3) Use d2i_PrivateKey_ex_bio (3) and d2i_PrivateKey_ex_fp (3)

  • EC_GROUP_new (3) Use EC_GROUP_new_by_curve_name_ex (3) or EC_GROUP_new_from_params (3).

  • EVP_DigestSignInit (3) and EVP_DigestVerifyInit (3)

  • EVP_PBE_CipherInit (3), EVP_PBE_find (3) and EVP_PBE_scrypt (3)

  • PKCS5_PBE_keyivgen (3)

  • EVP_PKCS82PKEY (3)

  • EVP_PKEY_CTX_new_id (3) Use EVP_PKEY_CTX_new_from_name (3)

  • EVP_PKEY_derive_set_peer (3), EVP_PKEY_new_raw_private_key (3) and EVP_PKEY_new_raw_public_key (3)

  • EVP_SignFinal (3) and EVP_VerifyFinal (3)

  • NCONF_new (3)

  • OCSP_RESPID_match (3) and OCSP_RESPID_set_by_key (3)

  • OPENSSL_thread_stop (3)

  • OSSL_STORE_open (3)

  • PEM_read_bio_Parameters (3), PEM_read_bio_PrivateKey (3), PEM_read_bio_PUBKEY (3), PEM_read_PrivateKey (3) and PEM_read_PUBKEY (3)

  • PEM_write_bio_PrivateKey (3), PEM_write_bio_PUBKEY (3), PEM_write_PrivateKey (3) and PEM_write_PUBKEY (3)

  • PEM_X509_INFO_read_bio (3) and PEM_X509_INFO_read (3)

  • PKCS12_add_key (3), PKCS12_add_safe (3), PKCS12_add_safes (3), PKCS12_create (3), PKCS12_decrypt_skey (3), PKCS12_init (3), PKCS12_item_decrypt_d2i (3), PKCS12_item_i2d_encrypt (3), PKCS12_key_gen_asc (3), PKCS12_key_gen_uni (3), PKCS12_key_gen_utf8 (3), PKCS12_pack_p7encdata (3), PKCS12_pbe_crypt (3), PKCS12_PBE_keyivgen (3), PKCS12_SAFEBAG_create_pkcs8_encrypt (3)

  • PKCS5_pbe_set0_algor (3), PKCS5_pbe_set (3), PKCS5_pbe2_set_iv (3), PKCS5_pbkdf2_set (3) and PKCS5_v2_scrypt_keyivgen (3)

  • PKCS7_encrypt (3), PKCS7_new (3) and PKCS7_sign (3)

  • PKCS8_decrypt (3), PKCS8_encrypt (3) and PKCS8_set0_pbe (3)

  • RAND_bytes (3) and RAND_priv_bytes (3)

  • SMIME_write_ASN1 (3)

  • SSL_load_client_CA_file (3)

  • SSL_CTX_new (3)

  • TS_RESP_CTX_new (3)

  • X509_CRL_new (3)

  • X509_load_cert_crl_file (3) and X509_load_cert_file (3)

  • X509_LOOKUP_by_subject (3) and X509_LOOKUP_ctrl (3)

  • X509_NAME_hash (3)

  • X509_new (3)

  • X509_REQ_new (3) and X509_REQ_verify (3)

  • X509_STORE_CTX_new (3), X509_STORE_set_default_paths (3), X509_STORE_load_file (3), X509_STORE_load_locations (3) and X509_STORE_load_store (3)

New functions that use a Library context

The following functions can be passed a library context if required. Passing NULL will use the default library context.

  • BIO_new_from_core_bio (3)

  • EVP_ASYM_CIPHER_fetch (3) and EVP_ASYM_CIPHER_do_all_provided (3)

  • EVP_CIPHER_fetch (3) and EVP_CIPHER_do_all_provided (3)

  • EVP_default_properties_enable_fips (3) and EVP_default_properties_is_fips_enabled (3)

  • EVP_KDF_fetch (3) and EVP_KDF_do_all_provided (3)

  • EVP_KEM_fetch (3) and EVP_KEM_do_all_provided (3)

  • EVP_KEYEXCH_fetch (3) and EVP_KEYEXCH_do_all_provided (3)

  • EVP_KEYMGMT_fetch (3) and EVP_KEYMGMT_do_all_provided (3)

  • EVP_MAC_fetch (3) and EVP_MAC_do_all_provided (3)

  • EVP_MD_fetch (3) and EVP_MD_do_all_provided (3)

  • EVP_PKEY_CTX_new_from_pkey (3)

  • EVP_PKEY_Q_keygen (3)

  • EVP_Q_mac (3) and EVP_Q_digest (3)

  • EVP_RAND (3) and EVP_RAND_do_all_provided (3)

  • EVP_set_default_properties (3)

  • EVP_SIGNATURE_fetch (3) and EVP_SIGNATURE_do_all_provided (3)

  • OSSL_CMP_CTX_new (3) and OSSL_CMP_SRV_CTX_new (3)

  • OSSL_CRMF_ENCRYPTEDVALUE_get1_encCert (3)

  • OSSL_CRMF_MSG_create_popo (3) and OSSL_CRMF_MSGS_verify_popo (3)

  • OSSL_CRMF_pbm_new (3) and OSSL_CRMF_pbmp_new (3)

  • OSSL_DECODER_CTX_add_extra (3) and OSSL_DECODER_CTX_new_for_pkey (3)

  • OSSL_DECODER_fetch (3) and OSSL_DECODER_do_all_provided (3)

  • OSSL_ENCODER_CTX_add_extra (3)

  • OSSL_ENCODER_fetch (3) and OSSL_ENCODER_do_all_provided (3)

  • OSSL_LIB_CTX_free (3), OSSL_LIB_CTX_load_config (3) and OSSL_LIB_CTX_set0_default (3)

  • OSSL_PROVIDER_add_builtin (3), OSSL_PROVIDER_available (3), OSSL_PROVIDER_do_all (3), OSSL_PROVIDER_load (3), OSSL_PROVIDER_set_default_search_path (3) and OSSL_PROVIDER_try_load (3)

  • OSSL_SELF_TEST_get_callback (3) and OSSL_SELF_TEST_set_callback (3)

  • OSSL_STORE_attach (3)

  • OSSL_STORE_LOADER_fetch (3) and OSSL_STORE_LOADER_do_all_provided (3)

  • RAND_get0_primary (3), RAND_get0_private (3), RAND_get0_public (3), RAND_set_DRBG_type (3) and RAND_set_seed_source_type (3)

Providers

Providers are described in detail here “Providers” in crypto (7). See also “OPENSSL PROVIDERS” in crypto (7).

Fetching algorithms and property queries

Implicit and Explicit Fetching is described in detail here “ALGORITHM FETCHING” in crypto (7).

Mapping EVP controls and flags to provider OSSL_PARAM (3) parameters

The existing functions for controls (such as EVP_CIPHER_CTX_ctrl (3)) and manipulating flags (such as EVP_MD_CTX_set_flags (3))internally use OSSL_PARAMS to pass information to/from provider objects. See OSSL_PARAM (3) for additional information related to parameters.

For ciphers see “CONTROLS” in EVP_EncryptInit (3), “FLAGS” in EVP_EncryptInit (3) and “PARAMETERS” in EVP_EncryptInit (3).

For digests see “CONTROLS” in EVP_DigestInit (3), “FLAGS” in EVP_DigestInit (3) and “PARAMETERS” in EVP_DigestInit (3).

Deprecation of Low Level Functions

A significant number of APIs have been deprecated in OpenSSL 3.0. This section describes some common categories of deprecations. See “Deprecated function mappings” for the list of deprecated functions that refer to these categories.

Providers are a replacement for engines and low-level method overrides

Any accessor that uses an ENGINE is deprecated (such as EVP_PKEY_set1_engine()). Applications using engines should instead use providers.

Before providers were added algorithms were overridden by changing the methods used by algorithms. All these methods such as RSA_new_method() and RSA_meth_new() are now deprecated and can be replaced by using providers instead.

Deprecated i2d and d2i functions for low-level key types

Any i2d and d2i functions such as d2i_DHparams() that take a low-level key type have been deprecated. Applications should instead use the OSSL_DECODER (3) and OSSL_ENCODER (3) APIs to read and write files. See “Migration” in d2i_RSAPrivateKey (3) for further details.

Deprecated low-level key object getters and setters

Applications that set or get low-level key objects (such as EVP_PKEY_set1_DH() or EVP_PKEY_get0()) should instead use the OSSL_ENCODER (See OSSL_ENCODER_to_bio (3)) or OSSL_DECODER (See OSSL_DECODER_from_bio (3)) APIs, or alternatively use EVP_PKEY_fromdata (3) or EVP_PKEY_todata (3).

Deprecated low-level key parameter getters

Functions that access low-level objects directly such as RSA_get0_n (3) are now deprecated. Applications should use one of EVP_PKEY_get_bn_param (3), EVP_PKEY_get_int_param (3), l<EVP_PKEY_get_size_t_param (3)>, EVP_PKEY_get_utf8_string_param (3), EVP_PKEY_get_octet_string_param (3) or EVP_PKEY_get_params (3) to access fields from an EVP_PKEY. Gettable parameters are listed in “Common RSA parameters” in EVP_PKEY-RSA (7), “DH parameters” in EVP_PKEY-DH (7), “DSA parameters” in EVP_PKEY-DSA (7), “FFC parameters” in EVP_PKEY-FFC (7), “Common EC parameters” in EVP_PKEY-EC (7) and “Common X25519, X448, ED25519 and ED448 parameters” in EVP_PKEY-X25519 (7). Applications may also use EVP_PKEY_todata (3) to return all fields.

Deprecated low-level key parameter setters

Functions that access low-level objects directly such as RSA_set0_crt_params (3) are now deprecated. Applications should use EVP_PKEY_fromdata (3) to create new keys from user provided key data. Keys should be immutable once they are created, so if required the user may use EVP_PKEY_todata (3), OSSL_PARAM_merge (3), and EVP_PKEY_fromdata (3) to create a modified key. See “Examples” in EVP_PKEY-DH (7) for more information. See “Deprecated low-level key generation functions” for information on generating a key using parameters.

Deprecated low-level object creation

Low-level objects were created using methods such as RSA_new (3), RSA_up_ref (3) and RSA_free (3). Applications should instead use the high-level EVP_PKEY APIs, e.g. EVP_PKEY_new (3), EVP_PKEY_up_ref (3) and EVP_PKEY_free (3). See also EVP_PKEY_CTX_new_from_name (3) and EVP_PKEY_CTX_new_from_pkey (3).

EVP_PKEYs may be created in a variety of ways: See also “Deprecated low-level key generation functions”, “Deprecated low-level key reading and writing functions” and “Deprecated low-level key parameter setters”.

Deprecated low-level encryption functions

Low-level encryption functions such as AES_encrypt (3) and AES_decrypt (3) have been informally discouraged from use for a long time. Applications should instead use the high level EVP APIs EVP_EncryptInit_ex (3), EVP_EncryptUpdate (3), and EVP_EncryptFinal_ex (3) or EVP_DecryptInit_ex (3), EVP_DecryptUpdate (3) and EVP_DecryptFinal_ex (3).

Deprecated low-level digest functions

Use of low-level digest functions such as SHA1_Init (3) have been informally discouraged from use for a long time. Applications should instead use the the high level EVP APIs EVP_DigestInit_ex (3), EVP_DigestUpdate (3) and EVP_DigestFinal_ex (3), or the quick one-shot EVP_Q_digest (3).

Note that the functions SHA1 (3), SHA224 (3), SHA256 (3), SHA384 (3) and SHA512 (3) have changed to macros that use EVP_Q_digest (3).

Deprecated low-level signing functions

Use of low-level signing functions such as DSA_sign (3) have been informally discouraged for a long time. Instead applications should use EVP_DigestSign (3) and EVP_DigestVerify (3). See also EVP_SIGNATURE-RSA (7), EVP_SIGNATURE-DSA (7), EVP_SIGNATURE-ECDSA (7) and EVP_SIGNATURE-ED25519 (7).

Deprecated low-level MAC functions

Low-level mac functions such as CMAC_Init (3) are deprecated. Applications should instead use the new EVP_MAC (3) interface, using EVP_MAC_CTX_new (3), EVP_MAC_CTX_free (3), EVP_MAC_init (3), EVP_MAC_update (3) and EVP_MAC_final (3) or the single-shot MAC function EVP_Q_mac (3). See EVP_MAC (3), EVP_MAC-HMAC (7), EVP_MAC-CMAC (7), EVP_MAC-GMAC (7), EVP_MAC-KMAC (7), EVP_MAC-BLAKE2 (7), EVP_MAC-Poly1305 (7) and EVP_MAC-Siphash (7) for additional information.

Note that the one-shot method HMAC() is still available for compatibility purposes, but this can also be replaced by using EVP_Q_MAC if a library context is required.

Deprecated low-level validation functions

Low-level validation functions such as DH_check (3) have been informally discouraged from use for a long time. Applications should instead use the high-level EVP_PKEY APIs such as EVP_PKEY_check (3), EVP_PKEY_param_check (3), EVP_PKEY_param_check_quick (3), EVP_PKEY_public_check (3), EVP_PKEY_public_check_quick (3), EVP_PKEY_private_check (3), and EVP_PKEY_pairwise_check (3).

Deprecated low-level key exchange functions

Many low-level functions have been informally discouraged from use for a long time. Applications should instead use EVP_PKEY_derive (3). See EVP_KEYEXCH-DH (7), EVP_KEYEXCH-ECDH (7) and EVP_KEYEXCH-X25519 (7).

Deprecated low-level key generation functions

Many low-level functions have been informally discouraged from use for a long time. Applications should instead use EVP_PKEY_keygen_init (3) and EVP_PKEY_generate (3) as described in EVP_PKEY-DSA (7), EVP_PKEY-DH (7), EVP_PKEY-RSA (7), EVP_PKEY-EC (7) and EVP_PKEY-X25519 (7). The ‘quick’ one-shot function EVP_PKEY_Q_keygen (3) and macros for the most common cases: <EVP_RSA_gen (3)> and EVP_EC_gen (3) may also be used.

Deprecated low-level key reading and writing functions

Use of low-level objects (such as DSA) has been informally discouraged from use for a long time. Functions to read and write these low-level objects (such as PEM_read_DSA_PUBKEY()) should be replaced. Applications should instead use OSSL_ENCODER_to_bio (3) and OSSL_DECODER_from_bio (3).

Deprecated low-level key printing functions

Use of low-level objects (such as DSA) has been informally discouraged from use for a long time. Functions to print these low-level objects such as DSA_print() should be replaced with the equivalent EVP_PKEY functions. Application should use one of EVP_PKEY_print_public (3), EVP_PKEY_print_private (3), EVP_PKEY_print_params (3), EVP_PKEY_print_public_fp (3), EVP_PKEY_print_private_fp (3) or EVP_PKEY_print_params_fp (3). Note that internally these use OSSL_ENCODER_to_bio (3) and OSSL_DECODER_from_bio (3).

Deprecated function mappings

The following functions have been deprecated in 3.0.

  • AES_bi_ige_encrypt() and AES_ige_encrypt() There is no replacement for the IGE functions. New code should not use these modes. These undocumented functions were never integrated into the EVP layer. They implemented the AES Infinite Garble Extension (IGE) mode and AES Bi-directional IGE mode. These modes were never formally standardised and usage of these functions is believed to be very small. In particular AES_bi_ige_encrypt() has a known bug. It accepts 2 AES keys, but only one is ever used. The security implications are believed to be minimal, but this issue was never fixed for backwards compatibility reasons.

  • AES_encrypt(), AES_decrypt(), AES_set_encrypt_key(), AES_set_decrypt_key(), AES_cbc_encrypt(), AES_cfb128_encrypt(), AES_cfb1_encrypt(), AES_cfb8_encrypt(), AES_ecb_encrypt(), AES_ofb128_encrypt()

  • AES_unwrap_key(), AES_wrap_key() See “Deprecated low-level encryption functions”

  • AES_options() There is no replacement. It returned a string indicating if the AES code was unrolled.

  • ASN1_digest(), ASN1_sign(), ASN1_verify() There are no replacements. These old functions are not used, and could be disabled with the macro NO_ASN1_OLD since OpenSSL 0.9.7.

  • ASN1_STRING_length_set() Use ASN1_STRING_set (3) or ASN1_STRING_set0 (3) instead. This was a potentially unsafe function that could change the bounds of a previously passed in pointer.

  • BF_encrypt(), BF_decrypt(), BF_set_key(), BF_cbc_encrypt(), BF_cfb64_encrypt(), BF_ecb_encrypt(), BF_ofb64_encrypt() See “Deprecated low-level encryption functions”. The Blowfish algorithm has been moved to the Legacy Provider.

  • BF_options() There is no replacement. This option returned a constant string.

  • BIO_get_callback(), BIO_set_callback(), BIO_debug_callback() Use the respective non-deprecated _ex() functions.

  • BN_is_prime_ex(), BN_is_prime_fasttest_ex() Use BN_check_prime (3) which avoids possible misuse and always uses at least 64 rounds of the Miller-Rabin primality test.

  • BN_pseudo_rand(), BN_pseudo_rand_range() Use BN_rand (3) and BN_rand_range (3).

  • BN_X931_derive_prime_ex(), BN_X931_generate_prime_ex(), BN_X931_generate_Xpq() There are no replacements for these low-level functions. They were used internally by RSA_X931_derive_ex() and RSA_X931_generate_key_ex() which are also deprecated. Use EVP_PKEY_keygen (3) instead.

  • Camellia_encrypt(), Camellia_decrypt(), Camellia_set_key(), Camellia_cbc_encrypt(), Camellia_cfb128_encrypt(), Camellia_cfb1_encrypt(), Camellia_cfb8_encrypt(), Camellia_ctr128_encrypt(), Camellia_ecb_encrypt(), Camellia_ofb128_encrypt() See “Deprecated low-level encryption functions”.

  • CAST_encrypt(), CAST_decrypt(), CAST_set_key(), CAST_cbc_encrypt(), CAST_cfb64_encrypt(), CAST_ecb_encrypt(), CAST_ofb64_encrypt() See “Deprecated low-level encryption functions”. The CAST algorithm has been moved to the Legacy Provider.

  • CMAC_CTX_new(), CMAC_CTX_cleanup(), CMAC_CTX_copy(), CMAC_CTX_free(), CMAC_CTX_get0_cipher_ctx() See “Deprecated low-level MAC functions”.

  • CMAC_Init(), CMAC_Update(), CMAC_Final(), CMAC_resume() See “Deprecated low-level MAC functions”.

  • CRYPTO_mem_ctrl(), CRYPTO_mem_debug_free(), CRYPTO_mem_debug_malloc(), CRYPTO_mem_debug_pop(), CRYPTO_mem_debug_push(), CRYPTO_mem_debug_realloc(), CRYPTO_mem_leaks(), CRYPTO_mem_leaks_cb(), CRYPTO_mem_leaks_fp(), CRYPTO_set_mem_debug() Memory-leak checking has been deprecated in favor of more modern development tools, such as compiler memory and leak sanitizers or Valgrind.

  • CRYPTO_cts128_encrypt_block(), CRYPTO_cts128_encrypt(), CRYPTO_cts128_decrypt_block(), CRYPTO_cts128_decrypt(), CRYPTO_nistcts128_encrypt_block(), CRYPTO_nistcts128_encrypt(), CRYPTO_nistcts128_decrypt_block(), CRYPTO_nistcts128_decrypt() Use the higher level functions EVP_CipherInit_ex2(), EVP_CipherUpdate() and EVP_CipherFinal_ex() instead. See the “cts_mode” parameter in “Gettable and Settable EVP_CIPHER_CTX parameters” in EVP_EncryptInit (3). See “EXAMPLES” in EVP_EncryptInit (3) for a AES-256-CBC-CTS example.

  • d2i_DHparams(), d2i_DHxparams(), d2i_DSAparams(), d2i_DSAPrivateKey(), d2i_DSAPrivateKey_bio(), d2i_DSAPrivateKey_fp(), d2i_DSA_PUBKEY(), d2i_DSA_PUBKEY_bio(), d2i_DSA_PUBKEY_fp(), d2i_DSAPublicKey(), d2i_ECParameters(), d2i_ECPrivateKey(), d2i_ECPrivateKey_bio(), d2i_ECPrivateKey_fp(), d2i_EC_PUBKEY(), d2i_EC_PUBKEY_bio(), d2i_EC_PUBKEY_fp(), d2i_RSAPrivateKey(), d2i_RSAPrivateKey_bio(), d2i_RSAPrivateKey_fp(), d2i_RSA_PUBKEY(), d2i_RSA_PUBKEY_bio(), d2i_RSA_PUBKEY_fp(), d2i_RSAPublicKey(), d2i_RSAPublicKey_bio(), d2i_RSAPublicKey_fp() See “Deprecated i2d and d2i functions for low-level key types”

  • o2i_ECPublicKey() Use EVP_PKEY_set1_encoded_public_key (3). See “Deprecated low-level key parameter setters”

  • DES_crypt(), DES_fcrypt(), DES_encrypt1(), DES_encrypt2(), DES_encrypt3(), DES_decrypt3(), DES_ede3_cbc_encrypt(), DES_ede3_cfb64_encrypt(), DES_ede3_cfb_encrypt(),DES_ede3_ofb64_encrypt(), DES_ecb_encrypt(), DES_ecb3_encrypt(), DES_ofb64_encrypt(), DES_ofb_encrypt(), DES_cfb64_encrypt DES_cfb_encrypt(), DES_cbc_encrypt(), DES_ncbc_encrypt(), DES_pcbc_encrypt(), DES_xcbc_encrypt(), DES_cbc_cksum(), DES_quad_cksum(), DES_check_key_parity(), DES_is_weak_key(), DES_key_sched(), DES_options(), DES_random_key(), DES_set_key(), DES_set_key_checked(), DES_set_key_unchecked(), DES_set_odd_parity(), DES_string_to_2keys(), DES_string_to_key() See “Deprecated low-level encryption functions”. Algorithms for “DESX-CBC”, “DES-ECB”, “DES-CBC”, “DES-OFB”, “DES-CFB”, “DES-CFB1” and “DES-CFB8” have been moved to the Legacy Provider.

  • DH_bits(), DH_security_bits(), DH_size() Use EVP_PKEY_get_bits (3), EVP_PKEY_get_security_bits (3) and EVP_PKEY_get_size (3).

  • DH_check(), DH_check_ex(), DH_check_params(), DH_check_params_ex(), DH_check_pub_key(), DH_check_pub_key_ex() See “Deprecated low-level validation functions”

  • DH_clear_flags(), DH_test_flags(), DH_set_flags() The DH_FLAG_CACHE_MONT_P flag has been deprecated without replacement. The DH_FLAG_TYPE_DH and DH_FLAG_TYPE_DHX have been deprecated. Use EVP_PKEY_is_a() to determine the type of a key. There is no replacement for setting these flags.

  • DH_compute_key() DH_compute_key_padded() See “Deprecated low-level key exchange functions”.

  • DH_new(), DH_new_by_nid(), DH_free(), DH_up_ref() See “Deprecated low-level object creation”

  • DH_generate_key(), DH_generate_parameters_ex() See “Deprecated low-level key generation functions”.

  • DH_get0_pqg(), DH_get0_p(), DH_get0_q(), DH_get0_g(), DH_get0_key(), DH_get0_priv_key(), DH_get0_pub_key(), DH_get_length(), DH_get_nid() See “Deprecated low-level key parameter getters”

  • DH_get_1024_160(), DH_get_2048_224(), DH_get_2048_256() Applications should instead set the OSSL_PKEY_PARAM_GROUP_NAME as specified in “DH parameters” in EVP_PKEY-DH (7)) to one of “dh_1024_160”, “dh_2048_224” or “dh_2048_256” when generating a DH key.

  • DH_KDF_X9_42() Applications should use EVP_PKEY_CTX_set_dh_kdf_type (3) instead.

  • DH_get_default_method(), DH_get0_engine(), DH_meth_*(), DH_new_method(), DH_OpenSSL(), DH_get_ex_data(), DH_set_default_method(), DH_set_method(), DH_set_ex_data() See “Providers are a replacement for engines and low-level method overrides”

  • DHparams_print(), DHparams_print_fp() See “Deprecated low-level key printing functions”

  • DH_set0_key(), DH_set0_pqg(), DH_set_length() See “Deprecated low-level key parameter setters”

  • DSA_bits(), DSA_security_bits(), DSA_size() Use EVP_PKEY_get_bits (3), EVP_PKEY_get_security_bits (3) and EVP_PKEY_get_size (3).

  • DHparams_dup(), DSA_dup_DH() There is no direct replacement. Applications may use EVP_PKEY_copy_parameters (3) and EVP_PKEY_dup (3) instead.

  • DSA_generate_key(), DSA_generate_parameters_ex() See “Deprecated low-level key generation functions”.

  • DSA_get0_engine(), DSA_get_default_method(), DSA_get_ex_data(), DSA_get_method(), DSA_meth_*(), DSA_new_method(), DSA_OpenSSL(), DSA_set_default_method(), DSA_set_ex_data(), DSA_set_method() See “Providers are a replacement for engines and low-level method overrides”.

  • DSA_get0_p(), DSA_get0_q(), DSA_get0_g(), DSA_get0_pqg(), DSA_get0_key(), DSA_get0_priv_key(), DSA_get0_pub_key() See “Deprecated low-level key parameter getters”.

  • DSA_new(), DSA_free(), DSA_up_ref() See “Deprecated low-level object creation”

  • DSAparams_dup() There is no direct replacement. Applications may use EVP_PKEY_copy_parameters (3) and EVP_PKEY_dup (3) instead.

  • DSAparams_print(), DSAparams_print_fp(), DSA_print(), DSA_print_fp() See “Deprecated low-level key printing functions”

  • DSA_set0_key(), DSA_set0_pqg() See “Deprecated low-level key parameter setters”

  • DSA_set_flags(), DSA_clear_flags(), DSA_test_flags() The DSA_FLAG_CACHE_MONT_P flag has been deprecated without replacement.

  • DSA_sign(), DSA_do_sign(), DSA_sign_setup(), DSA_verify(), DSA_do_verify() See “Deprecated low-level signing functions”.

  • ECDH_compute_key() See “Deprecated low-level key exchange functions”.

  • ECDH_KDF_X9_62() Applications may either set this using the helper function EVP_PKEY_CTX_set_ecdh_kdf_type (3) or by setting an OSSL_PARAM (3) using the “kdf-type” as shown in “EXAMPLES” in EVP_KEYEXCH-ECDH (7)

  • ECDSA_sign(), ECDSA_sign_ex(), ECDSA_sign_setup(), ECDSA_do_sign(), ECDSA_do_sign_ex(), ECDSA_verify(), ECDSA_do_verify() See “Deprecated low-level signing functions”.

  • ECDSA_size() Applications should use EVP_PKEY_get_size (3).

  • EC_GF2m_simple_method(), EC_GFp_mont_method(), EC_GFp_nist_method(), EC_GFp_nistp224_method(), EC_GFp_nistp256_method(), EC_GFp_nistp521_method(), EC_GFp_simple_method() There are no replacements for these functions. Applications should rely on the library automatically assigning a suitable method internally when an EC_GROUP is constructed.

  • EC_GROUP_clear_free() Use EC_GROUP_free (3) instead.

  • EC_GROUP_get_curve_GF2m(), EC_GROUP_get_curve_GFp(), EC_GROUP_set_curve_GF2m(), EC_GROUP_set_curve_GFp() Applications should use EC_GROUP_get_curve (3) and EC_GROUP_set_curve (3).

  • EC_GROUP_have_precompute_mult(), EC_GROUP_precompute_mult(), EC_KEY_precompute_mult() These functions are not widely used. Applications should instead switch to named curves which OpenSSL has hardcoded lookup tables for.

  • EC_GROUP_new(), EC_GROUP_method_of(), EC_POINT_method_of() EC_METHOD is now an internal-only concept and a suitable EC_METHOD is assigned internally without application intervention. Users of EC_GROUP_new() should switch to a different suitable constructor.

  • EC_KEY_can_sign() Applications should use EVP_PKEY_can_sign (3) instead.

  • EC_KEY_check_key() See “Deprecated low-level validation functions”

  • EC_KEY_set_flags(), EC_KEY_get_flags(), EC_KEY_clear_flags() See “Common EC parameters” in EVP_PKEY-EC (7) which handles flags as separate parameters for OSSL_PKEY_PARAM_EC_POINT_CONVERSION_FORMAT, OSSL_PKEY_PARAM_EC_GROUP_CHECK_TYPE, OSSL_PKEY_PARAM_EC_ENCODING, OSSL_PKEY_PARAM_USE_COFACTOR_ECDH and OSSL_PKEY_PARAM_EC_INCLUDE_PUBLIC. See also “EXAMPLES” in EVP_PKEY-EC (7)

  • EC_KEY_dup(), EC_KEY_copy() There is no direct replacement. Applications may use EVP_PKEY_copy_parameters (3) and EVP_PKEY_dup (3) instead.

  • EC_KEY_decoded_from_explicit_params() There is no replacement.

  • EC_KEY_generate_key() See “Deprecated low-level key generation functions”.

  • EC_KEY_get0_group(), EC_KEY_get0_private_key(), EC_KEY_get0_public_key(), EC_KEY_get_conv_form(), EC_KEY_get_enc_flags() See “Deprecated low-level key parameter getters”.

  • EC_KEY_get0_engine(), EC_KEY_get_default_method(), EC_KEY_get_method(), EC_KEY_new_method(), EC_KEY_get_ex_data(), EC_KEY_OpenSSL(), EC_KEY_set_ex_data(), EC_KEY_set_default_method(), EC_KEY_METHOD_*(), EC_KEY_set_method() See “Providers are a replacement for engines and low-level method overrides”

  • EC_METHOD_get_field_type() Use EC_GROUP_get_field_type (3) instead. See “Providers are a replacement for engines and low-level method overrides”

  • EC_KEY_key2buf(), EC_KEY_oct2key(), EC_KEY_oct2priv(), EC_KEY_priv2buf(), EC_KEY_priv2oct() There are no replacements for these.

  • EC_KEY_new(), EC_KEY_new_by_curve_name(), EC_KEY_free(), EC_KEY_up_ref() See “Deprecated low-level object creation”

  • EC_KEY_print(), EC_KEY_print_fp() See “Deprecated low-level key printing functions”

  • EC_KEY_set_asn1_flag(), EC_KEY_set_conv_form(), EC_KEY_set_enc_flags() See “Deprecated low-level key parameter setters”.

  • EC_KEY_set_group(), EC_KEY_set_private_key(), EC_KEY_set_public_key(), EC_KEY_set_public_key_affine_coordinates() See “Deprecated low-level key parameter setters”.

  • ECParameters_print(), ECParameters_print_fp(), ECPKParameters_print(), ECPKParameters_print_fp() See “Deprecated low-level key printing functions”

  • EC_POINT_bn2point(), EC_POINT_point2bn() These functions were not particularly useful, since EC point serialization formats are not individual big-endian integers.

  • EC_POINT_get_affine_coordinates_GF2m(), EC_POINT_get_affine_coordinates_GFp(), EC_POINT_set_affine_coordinates_GF2m(), EC_POINT_set_affine_coordinates_GFp() Applications should use EC_POINT_get_affine_coordinates (3) and EC_POINT_set_affine_coordinates (3) instead.

  • EC_POINT_get_Jprojective_coordinates_GFp(), EC_POINT_set_Jprojective_coordinates_GFp() These functions are not widely used. Applications should instead use the EC_POINT_set_affine_coordinates (3) and EC_POINT_get_affine_coordinates (3) functions.

  • EC_POINT_make_affine(), EC_POINTs_make_affine() There is no replacement. These functions were not widely used, and OpenSSL automatically performs this conversion when needed.

  • EC_POINT_set_compressed_coordinates_GF2m(), EC_POINT_set_compressed_coordinates_GFp() Applications should use EC_POINT_set_compressed_coordinates (3) instead.

  • EC_POINTs_mul() This function is not widely used. Applications should instead use the EC_POINT_mul (3) function.

  • ENGINE_*() All engine functions are deprecated. An engine should be rewritten as a provider. See “Providers are a replacement for engines and low-level method overrides”.

  • ERR_load_*(), ERR_func_error_string(), ERR_get_error_line(), ERR_get_error_line_data(), ERR_get_state() OpenSSL now loads error strings automatically so these functions are not needed.

  • ERR_peek_error_line_data(), ERR_peek_last_error_line_data() The new functions are ERR_peek_error_func (3), ERR_peek_last_error_func (3), ERR_peek_error_data (3), ERR_peek_last_error_data (3), ERR_get_error_all (3), ERR_peek_error_all (3) and ERR_peek_last_error_all (3). Applications should use ERR_get_error_all (3), or pick information with ERR_peek functions and finish off with getting the error code by using ERR_get_error (3).

  • EVP_CIPHER_CTX_iv(), EVP_CIPHER_CTX_iv_noconst(), EVP_CIPHER_CTX_original_iv() Applications should instead use EVP_CIPHER_CTX_get_updated_iv (3), EVP_CIPHER_CTX_get_updated_iv (3) and EVP_CIPHER_CTX_get_original_iv (3) respectively. See EVP_CIPHER_CTX_get_original_iv (3) for further information.

  • EVP_CIPHER_meth_*(), EVP_MD_CTX_set_update_fn(), EVP_MD_CTX_update_fn(), EVP_MD_meth_*() See “Providers are a replacement for engines and low-level method overrides”.

  • EVP_PKEY_CTRL_PKCS7_ENCRYPT(), EVP_PKEY_CTRL_PKCS7_DECRYPT(), EVP_PKEY_CTRL_PKCS7_SIGN(), EVP_PKEY_CTRL_CMS_ENCRYPT(), EVP_PKEY_CTRL_CMS_DECRYPT(), and EVP_PKEY_CTRL_CMS_SIGN() These control operations are not invoked by the OpenSSL library anymore and are replaced by direct checks of the key operation against the key type when the operation is initialized.

  • EVP_PKEY_CTX_get0_dh_kdf_ukm(), EVP_PKEY_CTX_get0_ecdh_kdf_ukm() See the “kdf-ukm” item in “DH key exchange parameters” in EVP_KEYEXCH-DH (7) and “ECDH Key Exchange parameters” in EVP_KEYEXCH-ECDH (7). These functions are obsolete and should not be required.

  • EVP_PKEY_CTX_set_rsa_keygen_pubexp() Applications should use EVP_PKEY_CTX_set1_rsa_keygen_pubexp (3) instead.

  • EVP_PKEY_cmp(), EVP_PKEY_cmp_parameters() Applications should use EVP_PKEY_eq (3) and EVP_PKEY_parameters_eq (3) instead. See EVP_PKEY_copy_parameters (3) for further details.

  • EVP_PKEY_encrypt_old(), EVP_PKEY_decrypt_old(), Applications should use EVP_PKEY_encrypt_init (3) and EVP_PKEY_encrypt (3) or EVP_PKEY_decrypt_init (3) and EVP_PKEY_decrypt (3) instead.

  • EVP_PKEY_get0() This function returns NULL if the key comes from a provider.

  • EVP_PKEY_get0_DH(), EVP_PKEY_get0_DSA(), EVP_PKEY_get0_EC_KEY(), EVP_PKEY_get0_RSA(), EVP_PKEY_get1_DH(), EVP_PKEY_get1_DSA(), EVP_PKEY_get1_EC_KEY and EVP_PKEY_get1_RSA(), EVP_PKEY_get0_hmac(), EVP_PKEY_get0_poly1305(), EVP_PKEY_get0_siphash() See “Functions that return an internal key should be treated as read only”.

  • EVP_PKEY_meth_*() See “Providers are a replacement for engines and low-level method overrides”.

  • EVP_PKEY_new_CMAC_key() See “Deprecated low-level MAC functions”.

  • EVP_PKEY_assign(), EVP_PKEY_set1_DH(), EVP_PKEY_set1_DSA(), EVP_PKEY_set1_EC_KEY(), EVP_PKEY_set1_RSA() See “Deprecated low-level key object getters and setters”

  • EVP_PKEY_set1_tls_encodedpoint() EVP_PKEY_get1_tls_encodedpoint() These functions were previously used by libssl to set or get an encoded public key into/from an EVP_PKEY object. With OpenSSL 3.0 these are replaced by the more generic functions EVP_PKEY_set1_encoded_public_key (3) and EVP_PKEY_get1_encoded_public_key (3). The old versions have been converted to deprecated macros that just call the new functions.

  • EVP_PKEY_set1_engine(), EVP_PKEY_get0_engine() See “Providers are a replacement for engines and low-level method overrides”.

  • EVP_PKEY_set_alias_type() This function has been removed. There is no replacement. See “EVP_PKEY_set_alias_type() method has been removed”

  • HMAC_Init_ex(), HMAC_Update(), HMAC_Final(), HMAC_size() See “Deprecated low-level MAC functions”.

  • HMAC_CTX_new(), HMAC_CTX_free(), HMAC_CTX_copy(), HMAC_CTX_reset(), HMAC_CTX_set_flags(), HMAC_CTX_get_md() See “Deprecated low-level MAC functions”.

  • i2d_DHparams(), i2d_DHxparams() See “Deprecated low-level key reading and writing functions” and “Migration” in d2i_RSAPrivateKey (3)

  • i2d_DSAparams(), i2d_DSAPrivateKey(), i2d_DSAPrivateKey_bio(), i2d_DSAPrivateKey_fp(), i2d_DSA_PUBKEY(), i2d_DSA_PUBKEY_bio(), i2d_DSA_PUBKEY_fp(), i2d_DSAPublicKey() See “Deprecated low-level key reading and writing functions” and “Migration” in d2i_RSAPrivateKey (3)

  • i2d_ECParameters(), i2d_ECPrivateKey(), i2d_ECPrivateKey_bio(), i2d_ECPrivateKey_fp(), i2d_EC_PUBKEY(), i2d_EC_PUBKEY_bio(), i2d_EC_PUBKEY_fp() See “Deprecated low-level key reading and writing functions” and “Migration” in d2i_RSAPrivateKey (3)

  • i2o_ECPublicKey() Use EVP_PKEY_get1_encoded_public_key (3). See “Deprecated low-level key parameter getters”

  • i2d_RSAPrivateKey(), i2d_RSAPrivateKey_bio(), i2d_RSAPrivateKey_fp(), i2d_RSA_PUBKEY(), i2d_RSA_PUBKEY_bio(), i2d_RSA_PUBKEY_fp(), i2d_RSAPublicKey(), i2d_RSAPublicKey_bio(), i2d_RSAPublicKey_fp() See “Deprecated low-level key reading and writing functions” and “Migration” in d2i_RSAPrivateKey (3)

  • IDEA_encrypt(), IDEA_set_decrypt_key(), IDEA_set_encrypt_key(), IDEA_cbc_encrypt(), IDEA_cfb64_encrypt(), IDEA_ecb_encrypt(), IDEA_ofb64_encrypt() See “Deprecated low-level encryption functions”. IDEA has been moved to the Legacy Provider.

  • IDEA_options() There is no replacement. This function returned a constant string.

  • MD2(), MD2_Init(), MD2_Update(), MD2_Final() See “Deprecated low-level encryption functions”. MD2 has been moved to the Legacy Provider.

  • MD2_options() There is no replacement. This function returned a constant string.

  • MD4(), MD4_Init(), MD4_Update(), MD4_Final(), MD4_Transform() See “Deprecated low-level encryption functions”. MD4 has been moved to the Legacy Provider.

  • MDC2(), MDC2_Init(), MDC2_Update(), MDC2_Final() See “Deprecated low-level encryption functions”. MDC2 has been moved to the Legacy Provider.

  • MD5(), MD5_Init(), MD5_Update(), MD5_Final(), MD5_Transform() See “Deprecated low-level encryption functions”.

  • NCONF_WIN32() This undocumented function has no replacement. See “HISTORY” in config (5) for more details.

  • OCSP_parse_url() Use OSSL_HTTP_parse_url (3) instead.

  • OCSP_REQ_CTX type and OCSP_REQ_CTX_*() functions These methods were used to collect all necessary data to form a HTTP request, and to perform the HTTP transfer with that request. With OpenSSL 3.0, the type is OSSL_HTTP_REQ_CTX, and the deprecated functions are replaced with OSSL_HTTP_REQ_CTX_*(). See OSSL_HTTP_REQ_CTX (3) for additional details.

  • OPENSSL_fork_child(), OPENSSL_fork_parent(), OPENSSL_fork_prepare() There is no replacement for these functions. These pthread fork support methods were unused by OpenSSL.

  • OSSL_STORE_ctrl(), OSSL_STORE_do_all_loaders(), OSSL_STORE_LOADER_get0_engine(), OSSL_STORE_LOADER_get0_scheme(), OSSL_STORE_LOADER_new(), OSSL_STORE_LOADER_set_attach(), OSSL_STORE_LOADER_set_close(), OSSL_STORE_LOADER_set_ctrl(), OSSL_STORE_LOADER_set_eof(), OSSL_STORE_LOADER_set_error(), OSSL_STORE_LOADER_set_expect(), OSSL_STORE_LOADER_set_find(), OSSL_STORE_LOADER_set_load(), OSSL_STORE_LOADER_set_open(), OSSL_STORE_LOADER_set_open_ex(), OSSL_STORE_register_loader(), OSSL_STORE_unregister_loader(), OSSL_STORE_vctrl() These functions helped applications and engines create loaders for schemes they supported. These are all deprecated and discouraged in favour of provider implementations, see provider-storemgmt (7).

  • PEM_read_DHparams(), PEM_read_bio_DHparams(), PEM_read_DSAparams(), PEM_read_bio_DSAparams(), PEM_read_DSAPrivateKey(), PEM_read_DSA_PUBKEY(), PEM_read_bio_DSAPrivateKey and PEM_read_bio_DSA_PUBKEY(), PEM_read_ECPKParameters(), PEM_read_ECPrivateKey(), PEM_read_EC_PUBKEY(), PEM_read_bio_ECPKParameters(), PEM_read_bio_ECPrivateKey(), PEM_read_bio_EC_PUBKEY(), PEM_read_RSAPrivateKey(), PEM_read_RSA_PUBKEY(), PEM_read_RSAPublicKey(), PEM_read_bio_RSAPrivateKey(), PEM_read_bio_RSA_PUBKEY(), PEM_read_bio_RSAPublicKey(), PEM_write_bio_DHparams(), PEM_write_bio_DHxparams(), PEM_write_DHparams(), PEM_write_DHxparams(), PEM_write_DSAparams(), PEM_write_DSAPrivateKey(), PEM_write_DSA_PUBKEY(), PEM_write_bio_DSAparams(), PEM_write_bio_DSAPrivateKey(), PEM_write_bio_DSA_PUBKEY(), PEM_write_ECPKParameters(), PEM_write_ECPrivateKey(), PEM_write_EC_PUBKEY(), PEM_write_bio_ECPKParameters(), PEM_write_bio_ECPrivateKey(), PEM_write_bio_EC_PUBKEY(), PEM_write_RSAPrivateKey(), PEM_write_RSA_PUBKEY(), PEM_write_RSAPublicKey(), PEM_write_bio_RSAPrivateKey(), PEM_write_bio_RSA_PUBKEY(), PEM_write_bio_RSAPublicKey(), See “Deprecated low-level key reading and writing functions”

  • PKCS1_MGF1() See “Deprecated low-level encryption functions”.

  • RAND_get_rand_method(), RAND_set_rand_method(), RAND_OpenSSL(), RAND_set_rand_engine() Applications should instead use RAND_set_DRBG_type (3), EVP_RAND (3) and EVP_RAND (7). See RAND_set_rand_method (3) for more details.

  • RC2_encrypt(), RC2_decrypt(), RC2_set_key(), RC2_cbc_encrypt(), RC2_cfb64_encrypt(), RC2_ecb_encrypt(), RC2_ofb64_encrypt(), RC4(), RC4_set_key(), RC4_options(), RC5_32_encrypt(), RC5_32_set_key(), RC5_32_decrypt(), RC5_32_cbc_encrypt(), RC5_32_cfb64_encrypt(), RC5_32_ecb_encrypt(), RC5_32_ofb64_encrypt() See “Deprecated low-level encryption functions”. The Algorithms “RC2”, “RC4” and “RC5” have been moved to the Legacy Provider.

  • RIPEMD160(), RIPEMD160_Init(), RIPEMD160_Update(), RIPEMD160_Final(), RIPEMD160_Transform() See “Deprecated low-level digest functions”. The RIPE algorithm has been moved to the Legacy Provider.

  • RSA_bits(), RSA_security_bits(), RSA_size() Use EVP_PKEY_get_bits (3), EVP_PKEY_get_security_bits (3) and EVP_PKEY_get_size (3).

  • RSA_check_key(), RSA_check_key_ex() See “Deprecated low-level validation functions”

  • RSA_clear_flags(), RSA_flags(), RSA_set_flags(), RSA_test_flags(), RSA_setup_blinding(), RSA_blinding_off(), RSA_blinding_on() All of these RSA flags have been deprecated without replacement: RSA_FLAG_BLINDING, RSA_FLAG_CACHE_PRIVATE, RSA_FLAG_CACHE_PUBLIC, RSA_FLAG_EXT_PKEY, RSA_FLAG_NO_BLINDING, RSA_FLAG_THREAD_SAFE RSA_METHOD_FLAG_NO_CHECK

  • RSA_generate_key_ex(), RSA_generate_multi_prime_key() See “Deprecated low-level key generation functions”.

  • RSA_get0_engine() See “Providers are a replacement for engines and low-level method overrides”

  • RSA_get0_crt_params(), RSA_get0_d(), RSA_get0_dmp1(), RSA_get0_dmq1(), RSA_get0_e(), RSA_get0_factors(), RSA_get0_iqmp(), RSA_get0_key(), RSA_get0_multi_prime_crt_params(), RSA_get0_multi_prime_factors(), RSA_get0_n(), RSA_get0_p(), RSA_get0_pss_params(), RSA_get0_q(), RSA_get_multi_prime_extra_count() See “Deprecated low-level key parameter getters”

  • RSA_new(), RSA_free(), RSA_up_ref() See “Deprecated low-level object creation”.

  • RSA_get_default_method(), RSA_get_ex_data and RSA_get_method() See “Providers are a replacement for engines and low-level method overrides”.

  • RSA_get_version() There is no replacement.

  • RSA_meth_*(), RSA_new_method(), RSA_null_method and RSA_PKCS1_OpenSSL() See “Providers are a replacement for engines and low-level method overrides”.

  • RSA_padding_add_*(), RSA_padding_check_*() See “Deprecated low-level signing functions” and “Deprecated low-level encryption functions”.

  • RSA_print(), RSA_print_fp() See “Deprecated low-level key printing functions”

  • RSA_public_encrypt(), RSA_private_decrypt() See “Deprecated low-level encryption functions”

  • RSA_private_encrypt(), RSA_public_decrypt() This is equivalent to doing sign and verify recover operations (with a padding mode of none). See “Deprecated low-level signing functions”.

  • RSAPrivateKey_dup(), RSAPublicKey_dup() There is no direct replacement. Applications may use EVP_PKEY_dup (3).

  • RSAPublicKey_it(), RSAPrivateKey_it() See “Deprecated low-level key reading and writing functions”

  • RSA_set0_crt_params(), RSA_set0_factors(), RSA_set0_key(), RSA_set0_multi_prime_params() See “Deprecated low-level key parameter setters”.

  • RSA_set_default_method(), RSA_set_method(), RSA_set_ex_data() See “Providers are a replacement for engines and low-level method overrides”

  • RSA_sign(), RSA_sign_ASN1_OCTET_STRING(), RSA_verify(), RSA_verify_ASN1_OCTET_STRING(), RSA_verify_PKCS1_PSS(), RSA_verify_PKCS1_PSS_mgf1() See “Deprecated low-level signing functions”.

  • RSA_X931_derive_ex(), RSA_X931_generate_key_ex(), RSA_X931_hash_id() There are no replacements for these functions. X931 padding can be set using “Signature Parameters” in EVP_SIGNATURE-RSA (7). See OSSL_SIGNATURE_PARAM_PAD_MODE.

  • SEED_encrypt(), SEED_decrypt(), SEED_set_key(), SEED_cbc_encrypt(), SEED_cfb128_encrypt(), SEED_ecb_encrypt(), SEED_ofb128_encrypt() See “Deprecated low-level encryption functions”. The SEED algorithm has been moved to the Legacy Provider.

  • SHA1_Init(), SHA1_Update(), SHA1_Final(), SHA1_Transform(), SHA224_Init(), SHA224_Update(), SHA224_Final(), SHA256_Init(), SHA256_Update(), SHA256_Final(), SHA256_Transform(), SHA384_Init(), SHA384_Update(), SHA384_Final(), SHA512_Init(), SHA512_Update(), SHA512_Final(), SHA512_Transform() See “Deprecated low-level digest functions”.

  • SRP_Calc_A(), SRP_Calc_B(), SRP_Calc_client_key(), SRP_Calc_server_key(), SRP_Calc_u(), SRP_Calc_x(), SRP_check_known_gN_param(), SRP_create_verifier(), SRP_create_verifier_BN(), SRP_get_default_gN(), SRP_user_pwd_free(), SRP_user_pwd_new(), SRP_user_pwd_set0_sv(), SRP_user_pwd_set1_ids(), SRP_user_pwd_set_gN(), SRP_VBASE_add0_user(), SRP_VBASE_free(), SRP_VBASE_get1_by_user(), SRP_VBASE_init(), SRP_VBASE_new(), SRP_Verify_A_mod_N(), SRP_Verify_B_mod_N() There are no replacements for the SRP functions.

  • SSL_CTX_set_tmp_dh_callback(), SSL_set_tmp_dh_callback(), SSL_CTX_set_tmp_dh(), SSL_set_tmp_dh() These are used to set the Diffie-Hellman (DH) parameters that are to be used by servers requiring ephemeral DH keys. Instead applications should consider using the built-in DH parameters that are available by calling SSL_CTX_set_dh_auto (3) or SSL_set_dh_auto (3). If custom parameters are necessary then applications can use the alternative functions SSL_CTX_set0_tmp_dh_pkey (3) and SSL_set0_tmp_dh_pkey (3). There is no direct replacement for the “callback” functions. The callback was originally useful in order to have different parameters for export and non-export ciphersuites. Export ciphersuites are no longer supported by OpenSSL. Use of the callback functions should be replaced by one of the other methods described above.

  • SSL_CTX_set_tlsext_ticket_key_cb() Use the new SSL_CTX_set_tlsext_ticket_key_evp_cb (3) function instead.

  • WHIRLPOOL(), WHIRLPOOL_Init(), WHIRLPOOL_Update(), WHIRLPOOL_Final(), WHIRLPOOL_BitUpdate() See “Deprecated low-level digest functions”. The Whirlpool algorithm has been moved to the Legacy Provider.

  • X509_certificate_type() This was an undocumented function. Applications can use X509_get0_pubkey (3) and X509_get0_signature (3) instead.

  • X509_http_nbio(), X509_CRL_http_nbio() Use X509_load_http (3) and X509_CRL_load_http (3) instead.

NID handling for provided keys and algorithms

The following functions for NID (numeric id) handling have changed semantics.

  • EVP_PKEY_id(), EVP_PKEY_get_id() This function was previously used to reliably return the NID of an EVP_PKEY object, e.g., to look up the name of the algorithm of such EVP_PKEY by calling OBJ_nid2sn (3). With the introduction of provider (7)s EVP_PKEY_id() or its new equivalent EVP_PKEY_get_id (3) might now also return the value -1 (EVP_PKEY_KEYMGMT) indicating the use of a provider to implement the EVP_PKEY object. Therefore, the use of EVP_PKEY_get0_type_name (3) is recommended for retrieving the name of the EVP_PKEY algorithm.

Using the FIPS Module in applications

See fips_module (7) and OSSL_PROVIDER-FIPS (7) for details.

OpenSSL command line application changes

New applications

openssl kdf uses the new EVP_KDF (3) API. openssl kdf uses the new EVP_MAC (3) API.

Added options

-provider_path and -provider are available to all apps and can be used multiple times to load any providers, such as the ’legacy’ provider or third party providers. If used then the ‘default’ provider would also need to be specified if required. The -provider_path must be specified before the -provider option.

The list app has many new options. See openssl-list (1) for more information.

-crl_lastupdate and -crl_nextupdate used by openssl ca allows explicit setting of fields in the generated CRL.

Removed options

Interactive mode is not longer available.

The -crypt option used by openssl passwd. The -c option used by openssl x509, openssl dhparam, openssl dsaparam, and openssl ecparam.

Other Changes

The output of Command line applications may have minor changes. These are primarily changes in capitalisation and white space. However, in some cases, there are additional differences. For example, the DH parameters output from openssl dhparam now lists ‘P’, ‘Q’, ‘G’ and ‘pcounter’ instead of ‘prime’, ‘generator’, ‘subgroup order’ and ‘counter’ respectively.

The openssl commands that read keys, certificates, and CRLs now automatically detect the PEM or DER format of the input files so it is not necessary to explicitly specify the input format anymore. However if the input format option is used the specified format will be required.

openssl speed no longer uses low-level API calls. This implies some of the performance numbers might not be comparable with the previous releases due to higher overhead. This applies particularly to measuring performance on smaller data chunks.

b<openssl dhparam>, openssl dsa, openssl gendsa, openssl dsaparam, openssl genrsa and openssl rsa have been modified to use PKEY APIs. openssl genrsa and openssl rsa now write PKCS #8 keys by default.

Default settings

“SHA256” is now the default digest for TS query used by openssl ts.

Deprecated apps

openssl rsautl is deprecated, use openssl pkeyutl instead. openssl dhparam, openssl dsa, openssl gendsa, openssl dsaparam, openssl genrsa, openssl rsa, openssl genrsa and openssl rsa are now in maintenance mode and no new features will be added to them.

TLS Changes

  • TLS 1.3 FFDHE key exchange support added This uses DH safe prime named groups.

  • Support for fully “pluggable” TLSv1.3 groups. This means that providers may supply their own group implementations (using either the “key exchange” or the “key encapsulation” methods) which will automatically be detected and used by libssl.

  • SSL and SSL_CTX options are now 64 bit instead of 32 bit. The signatures of the functions to get and set options on SSL and SSL_CTX objects changed from “unsigned long” to “uint64_t” type. This may require source code changes. For example it is no longer possible to use the SSL_OP_ macro values in preprocessor #if conditions. However it is still possible to test whether these macros are defined or not. See SSL_CTX_get_options (3), SSL_CTX_set_options (3), SSL_get_options (3) and SSL_set_options (3).

  • SSL_set1_host() and SSL_add1_host() Changes These functions now take IP literal addresses as well as actual hostnames.

  • Added SSL option SSL_OP_CLEANSE_PLAINTEXT If the option is set, openssl cleanses (zeroizes) plaintext bytes from internal buffers after delivering them to the application. Note, the application is still responsible for cleansing other copies (e.g.: data received by SSL_read (3)).

  • Client-initiated renegotiation is disabled by default. To allow it, use the -client_renegotiation option, the SSL_OP_ALLOW_CLIENT_RENEGOTIATION flag, or the ClientRenegotiation config parameter as appropriate.

  • Secure renegotiation is now required by default for TLS connections Support for RFC 5746 secure renegotiation is now required by default for SSL or TLS connections to succeed. Applications that require the ability to connect to legacy peers will need to explicitly set SSL_OP_LEGACY_SERVER_CONNECT. Accordingly, SSL_OP_LEGACY_SERVER_CONNECT is no longer set as part of SSL_OP_ALL.

  • Combining the Configure options no-ec and no-dh no longer disables TLSv1.3 Typically if OpenSSL has no EC or DH algorithms then it cannot support connections with TLSv1.3. However OpenSSL now supports “pluggable” groups through providers. Therefore third party providers may supply group implementations even where there are no built-in ones. Attempting to create TLS connections in such a build without also disabling TLSv1.3 at run time or using third party provider groups may result in handshake failures. TLSv1.3 can be disabled at compile time using the “no-tls1_3” Configure option.

  • SSL_CTX_set_ciphersuites() and SSL_set_ciphersuites() changes. The methods now ignore unknown ciphers.

  • Security callback change. The security callback, which can be customised by application code, supports the security operation SSL_SECOP_TMP_DH. This is defined to take an EVP_PKEY in the “other” parameter. In most places this is what is passed. All these places occur server side. However there was one client side call of this security operation and it passed a DH object instead. This is incorrect according to the definition of SSL_SECOP_TMP_DH, and is inconsistent with all of the other locations. Therefore this client side call has been changed to pass an EVP_PKEY instead.

  • New SSL option SSL_OP_IGNORE_UNEXPECTED_EOF The SSL option SSL_OP_IGNORE_UNEXPECTED_EOF is introduced. If that option is set, an unexpected EOF is ignored, it pretends a close notify was received instead and so the returned error becomes SSL_ERROR_ZERO_RETURN.

  • The security strength of SHA1 and MD5 based signatures in TLS has been reduced. This results in SSL 3, TLS 1.0, TLS 1.1 and DTLS 1.0 no longer working at the default security level of 1 and instead requires security level 0. The security level can be changed either using the cipher string with @SECLEVEL, or calling SSL_CTX_set_security_level (3). This also means that where the signature algorithms extension is missing from a ClientHello then the handshake will fail in TLS 1.2 at security level 1. This is because, although this extension is optional, failing to provide one means that OpenSSL will fallback to a default set of signature algorithms. This default set requires the availability of SHA1.

  • X509 certificates signed using SHA1 are no longer allowed at security level 1 and above. In TLS/SSL the default security level is 1. It can be set either using the cipher string with @SECLEVEL, or calling SSL_CTX_set_security_level (3). If the leaf certificate is signed with SHA-1, a call to SSL_CTX_use_certificate (3) will fail if the security level is not lowered first. Outside TLS/SSL, the default security level is -1 (effectively 0). It can be set using X509_VERIFY_PARAM_set_auth_level (3) or using the -auth_level options of the commands.

SEE ALSO

fips_module (7)

HISTORY

The migration guide was created for OpenSSL 3.0.

COPYRIGHT

Copyright 2021-2024 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

283 - Linux cli command EVP_KDF-SSHKDFssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KDF-SSHKDFssl and provides detailed information about the command EVP_KDF-SSHKDFssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KDF-SSHKDFssl.

NAME 🖥️ EVP_KDF-SSHKDFssl 🖥️

SSHKDF - The SSHKDF EVP_KDF implementation

DESCRIPTION

Support for computing the SSHKDF KDF through the EVP_KDF API.

The EVP_KDF-SSHKDF algorithm implements the SSHKDF key derivation function. It is defined in RFC 4253, section 7.2 and is used by SSH to derive IVs, encryption keys and integrity keys. Five inputs are required to perform key derivation: The hashing function (for example SHA256), the Initial Key, the Exchange Hash, the Session ID, and the derivation key type.

Identity

“SSHKDF” is the name for this implementation; it can be used with the EVP_KDF_fetch() function.

Supported parameters

The supported parameters are:

“properties” (OSSL_KDF_PARAM_PROPERTIES) <UTF8 string>

“digest” (OSSL_KDF_PARAM_DIGEST) <UTF8 string>

“key” (OSSL_KDF_PARAM_KEY) <octet string>

These parameters work as described in “PARAMETERS” in EVP_KDF (3).

“xcghash” (OSSL_KDF_PARAM_SSHKDF_XCGHASH) <octet string>

“session_id” (OSSL_KDF_PARAM_SSHKDF_SESSION_ID) <octet string>

These parameters set the respective values for the KDF. If a value is already set, the contents are replaced.

“type” (OSSL_KDF_PARAM_SSHKDF_TYPE) <UTF8 string>
This parameter sets the type for the SSHKDF operation. There are six supported types:

EVP_KDF_SSHKDF_TYPE_INITIAL_IV_CLI_TO_SRV
The Initial IV from client to server. A single char of value 65 (ASCII char ‘A’).

EVP_KDF_SSHKDF_TYPE_INITIAL_IV_SRV_TO_CLI
The Initial IV from server to client A single char of value 66 (ASCII char ‘B’).

EVP_KDF_SSHKDF_TYPE_ENCRYPTION_KEY_CLI_TO_SRV
The Encryption Key from client to server A single char of value 67 (ASCII char ‘C’).

EVP_KDF_SSHKDF_TYPE_ENCRYPTION_KEY_SRV_TO_CLI
The Encryption Key from server to client A single char of value 68 (ASCII char ‘D’).

EVP_KDF_SSHKDF_TYPE_INTEGRITY_KEY_CLI_TO_SRV
The Integrity Key from client to server A single char of value 69 (ASCII char ‘E’).

EVP_KDF_SSHKDF_TYPE_INTEGRITY_KEY_SRV_TO_CLI
The Integrity Key from client to server A single char of value 70 (ASCII char ‘F’).

NOTES

A context for SSHKDF can be obtained by calling:

EVP_KDF *kdf = EVP_KDF_fetch(NULL, “SSHKDF”, NULL); EVP_KDF_CTX *kctx = EVP_KDF_CTX_new(kdf);

The output length of the SSHKDF derivation is specified via the keylen parameter to the EVP_KDF_derive (3) function. Since the SSHKDF output length is variable, calling EVP_KDF_CTX_get_kdf_size (3) to obtain the requisite length is not meaningful. The caller must allocate a buffer of the desired length, and pass that buffer to the EVP_KDF_derive (3) function along with the desired length.

EXAMPLES

This example derives an 8 byte IV using SHA-256 with a 1K “key” and appropriate “xcghash” and “session_id” values:

EVP_KDF *kdf; EVP_KDF_CTX *kctx; char type = EVP_KDF_SSHKDF_TYPE_INITIAL_IV_CLI_TO_SRV; unsigned char key[1024] = “01234…”; unsigned char xcghash[32] = “012345…”; unsigned char session_id[32] = “012345…”; unsigned char out[8]; size_t outlen = sizeof(out); OSSL_PARAM params[6], *p = params; kdf = EVP_KDF_fetch(NULL, “SSHKDF”, NULL); kctx = EVP_KDF_CTX_new(kdf); EVP_KDF_free(kdf); *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_DIGEST, SN_sha256, strlen(SN_sha256)); *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_KEY, key, (size_t)1024); *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_SSHKDF_XCGHASH, xcghash, (size_t)32); *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_SSHKDF_SESSION_ID, session_id, (size_t)32); *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_SSHKDF_TYPE, &type, sizeof(type)); *p = OSSL_PARAM_construct_end(); if (EVP_KDF_derive(kctx, out, outlen, params) <= 0) /* Error */

CONFORMING TO

RFC 4253

SEE ALSO

EVP_KDF (3), EVP_KDF_CTX_new (3), EVP_KDF_CTX_free (3), EVP_KDF_CTX_set_params (3), EVP_KDF_CTX_get_kdf_size (3), EVP_KDF_derive (3), “PARAMETERS” in EVP_KDF (3)

HISTORY

This functionality was added in OpenSSL 3.0.

COPYRIGHT

Copyright 2016-2022 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

284 - Linux cli command iso_8859_14

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso_8859_14 and provides detailed information about the command iso_8859_14, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso_8859_14.

NAME 🖥️ iso_8859_14 🖥️

14 - ISO/IEC 8859-14 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-14 encodes the characters used in Celtic languages.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-14 characters

The following table displays the characters in ISO/IEC 8859-14 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-14 is also known as Latin-8.

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

285 - Linux cli command futex

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command futex and provides detailed information about the command futex, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the futex.

NAME 🖥️ futex 🖥️

fast user-space locking

SYNOPSIS

#include <linux/futex.h>

DESCRIPTION

The Linux kernel provides futexes (“Fast user-space mutexes”) as a building block for fast user-space locking and semaphores. Futexes are very basic and lend themselves well for building higher-level locking abstractions such as mutexes, condition variables, read-write locks, barriers, and semaphores.

Most programmers will in fact not be using futexes directly but will instead rely on system libraries built on them, such as the Native POSIX Thread Library (NPTL) (see pthreads(7)).

A futex is identified by a piece of memory which can be shared between processes or threads. In these different processes, the futex need not have identical addresses. In its bare form, a futex has semaphore semantics; it is a counter that can be incremented and decremented atomically; processes can wait for the value to become positive.

Futex operation occurs entirely in user space for the noncontended case. The kernel is involved only to arbitrate the contended case. As any sane design will strive for noncontention, futexes are also optimized for this situation.

In its bare form, a futex is an aligned integer which is touched only by atomic assembler instructions. This integer is four bytes long on all platforms. Processes can share this integer using mmap(2), via shared memory segments, or because they share memory space, in which case the application is commonly called multithreaded.

Semantics

Any futex operation starts in user space, but it may be necessary to communicate with the kernel using the futex(2) system call.

To “up” a futex, execute the proper assembler instructions that will cause the host CPU to atomically increment the integer. Afterward, check if it has in fact changed from 0 to 1, in which case there were no waiters and the operation is done. This is the noncontended case which is fast and should be common.

In the contended case, the atomic increment changed the counter from -1 (or some other negative number). If this is detected, there are waiters. User space should now set the counter to 1 and instruct the kernel to wake up any waiters using the FUTEX_WAKE operation.

Waiting on a futex, to “down” it, is the reverse operation. Atomically decrement the counter and check if it changed to 0, in which case the operation is done and the futex was uncontended. In all other circumstances, the process should set the counter to -1 and request that the kernel wait for another process to up the futex. This is done using the FUTEX_WAIT operation.

The futex(2) system call can optionally be passed a timeout specifying how long the kernel should wait for the futex to be upped. In this case, semantics are more complex and the programmer is referred to futex(2) for more details. The same holds for asynchronous futex waiting.

VERSIONS

Initial futex support was merged in Linux 2.5.7 but with different semantics from those described above. Current semantics are available from Linux 2.5.40 onward.

NOTES

To reiterate, bare futexes are not intended as an easy-to-use abstraction for end users. Implementors are expected to be assembly literate and to have read the sources of the futex user-space library referenced below.

This man page illustrates the most common use of the futex(2) primitives; it is by no means the only one.

SEE ALSO

clone(2), futex(2), get_robust_list(2), set_robust_list(2), set_tid_address(2), pthreads(7)

Fuss, Futexes and Furwocks: Fast Userlevel Locking in Linux (proceedings of the Ottawa Linux Symposium 2002), futex example library, futex-*.tar.bz2 .

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

286 - Linux cli command REASSIGN_OWNED

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command REASSIGN_OWNED and provides detailed information about the command REASSIGN_OWNED, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the REASSIGN_OWNED.

NAME 🖥️ REASSIGN_OWNED 🖥️

change the ownership of database objects owned by a database role

SYNOPSIS

REASSIGN OWNED BY { old_role | CURRENT_ROLE | CURRENT_USER | SESSION_USER } [, ...]
               TO { new_role | CURRENT_ROLE | CURRENT_USER | SESSION_USER }

DESCRIPTION

REASSIGN OWNED instructs the system to change the ownership of database objects owned by any of the old_roles to new_role.

PARAMETERS

old_role

The name of a role. The ownership of all the objects within the current database, and of all shared objects (databases, tablespaces), owned by this role will be reassigned to new_role.

new_role

The name of the role that will be made the new owner of the affected objects.

NOTES

REASSIGN OWNED is often used to prepare for the removal of one or more roles. Because REASSIGN OWNED does not affect objects within other databases, it is usually necessary to execute this command in each database that contains objects owned by a role that is to be removed.

REASSIGN OWNED requires membership on both the source role(s) and the target role.

The DROP OWNED command is an alternative that simply drops all the database objects owned by one or more roles.

The REASSIGN OWNED command does not affect any privileges granted to the old_roles on objects that are not owned by them. Likewise, it does not affect default privileges created with ALTER DEFAULT PRIVILEGES. Use DROP OWNED to revoke such privileges.

See Section 22.4 for more discussion.

COMPATIBILITY

The REASSIGN OWNED command is a PostgreSQL extension.

SEE ALSO

DROP OWNED (DROP_OWNED(7)), DROP ROLE (DROP_ROLE(7)), ALTER DATABASE (ALTER_DATABASE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

287 - Linux cli command EVP_CIPHER-CHACHAssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_CIPHER-CHACHAssl and provides detailed information about the command EVP_CIPHER-CHACHAssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_CIPHER-CHACHAssl.

NAME 🖥️ EVP_CIPHER-CHACHAssl 🖥️

CHACHA - The CHACHA EVP_CIPHER implementations

DESCRIPTION

Support for CHACHA symmetric encryption using the EVP_CIPHER API.

Algorithm Names

The following algorithms are available in the default provider:

“ChaCha20”

“ChaCha20-Poly1305”

Parameters

This implementation supports the parameters described in “PARAMETERS” in EVP_EncryptInit (3).

SEE ALSO

provider-cipher (7), OSSL_PROVIDER-default (7)

COPYRIGHT

Copyright 2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

288 - Linux cli command intro

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command intro and provides detailed information about the command intro, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the intro.

NAME 🖥️ intro 🖥️

introduction to overview and miscellany section

DESCRIPTION

Section 7 of the manual provides overviews on various topics, and describes conventions and protocols, character set standards, the standard filesystem layout, and miscellaneous other things.

NOTES

Look at the header of the manual page source for the author(s) and copyright conditions. Note that these can be different from page to page!

SEE ALSO

standards(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

289 - Linux cli command provider-asym_cipherssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command provider-asym_cipherssl and provides detailed information about the command provider-asym_cipherssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the provider-asym_cipherssl.

NAME 🖥️ provider-asym_cipherssl 🖥️

asym_cipher - The asym_cipher library <-> provider functions

SYNOPSIS

#include <openssl/core_dispatch.h> #include <openssl/core_names.h> /* * None of these are actual functions, but are displayed like this for * the function signatures for functions that are offered as function * pointers in OSSL_DISPATCH arrays. */ /* Context management */ void *OSSL_FUNC_asym_cipher_newctx(void *provctx); void OSSL_FUNC_asym_cipher_freectx(void *ctx); void *OSSL_FUNC_asym_cipher_dupctx(void *ctx); /* Encryption */ int OSSL_FUNC_asym_cipher_encrypt_init(void *ctx, void *provkey, const OSSL_PARAM params[]); int OSSL_FUNC_asym_cipher_encrypt(void *ctx, unsigned char *out, size_t *outlen, size_t outsize, const unsigned char *in, size_t inlen); /* Decryption */ int OSSL_FUNC_asym_cipher_decrypt_init(void *ctx, void *provkey, const OSSL_PARAM params[]); int OSSL_FUNC_asym_cipher_decrypt(void *ctx, unsigned char *out, size_t *outlen, size_t outsize, const unsigned char *in, size_t inlen); /* Asymmetric Cipher parameters */ int OSSL_FUNC_asym_cipher_get_ctx_params(void *ctx, OSSL_PARAM params[]); const OSSL_PARAM *OSSL_FUNC_asym_cipher_gettable_ctx_params(void *provctx); int OSSL_FUNC_asym_cipher_set_ctx_params(void *ctx, const OSSL_PARAM params[]); const OSSL_PARAM *OSSL_FUNC_asym_cipher_settable_ctx_params(void *provctx);

DESCRIPTION

This documentation is primarily aimed at provider authors. See provider (7) for further information.

The asymmetric cipher (OSSL_OP_ASYM_CIPHER) operation enables providers to implement asymmetric cipher algorithms and make them available to applications via the API functions EVP_PKEY_encrypt (3), EVP_PKEY_decrypt (3) and other related functions).

All “functions” mentioned here are passed as function pointers between libcrypto and the provider in OSSL_DISPATCH (3) arrays via OSSL_ALGORITHM (3) arrays that are returned by the provider’s provider_query_operation() function (see “Provider Functions” in provider-base (7)).

All these “functions” have a corresponding function type definition named OSSL_FUNC_{name}_fn, and a helper function to retrieve the function pointer from an OSSL_DISPATCH (3) element named OSSL_FUNC_{name}. For example, the “function” OSSL_FUNC_asym_cipher_newctx() has these:

typedef void *(OSSL_FUNC_asym_cipher_newctx_fn)(void *provctx); static ossl_inline OSSL_FUNC_asym_cipher_newctx_fn OSSL_FUNC_asym_cipher_newctx(const OSSL_DISPATCH *opf);

OSSL_DISPATCH (3) arrays are indexed by numbers that are provided as macros in openssl-core_dispatch.h (7), as follows:

OSSL_FUNC_asym_cipher_newctx OSSL_FUNC_ASYM_CIPHER_NEWCTX OSSL_FUNC_asym_cipher_freectx OSSL_FUNC_ASYM_CIPHER_FREECTX OSSL_FUNC_asym_cipher_dupctx OSSL_FUNC_ASYM_CIPHER_DUPCTX OSSL_FUNC_asym_cipher_encrypt_init OSSL_FUNC_ASYM_CIPHER_ENCRYPT_INIT OSSL_FUNC_asym_cipher_encrypt OSSL_FUNC_ASYM_CIPHER_ENCRYPT OSSL_FUNC_asym_cipher_decrypt_init OSSL_FUNC_ASYM_CIPHER_DECRYPT_INIT OSSL_FUNC_asym_cipher_decrypt OSSL_FUNC_ASYM_CIPHER_DECRYPT OSSL_FUNC_asym_cipher_get_ctx_params OSSL_FUNC_ASYM_CIPHER_GET_CTX_PARAMS OSSL_FUNC_asym_cipher_gettable_ctx_params OSSL_FUNC_ASYM_CIPHER_GETTABLE_CTX_PARAMS OSSL_FUNC_asym_cipher_set_ctx_params OSSL_FUNC_ASYM_CIPHER_SET_CTX_PARAMS OSSL_FUNC_asym_cipher_settable_ctx_params OSSL_FUNC_ASYM_CIPHER_SETTABLE_CTX_PARAMS

An asymmetric cipher algorithm implementation may not implement all of these functions. In order to be a consistent set of functions a provider must implement OSSL_FUNC_asym_cipher_newctx and OSSL_FUNC_asym_cipher_freectx. It must also implement both of OSSL_FUNC_asym_cipher_encrypt_init and OSSL_FUNC_asym_cipher_encrypt, or both of OSSL_FUNC_asym_cipher_decrypt_init and OSSL_FUNC_asym_cipher_decrypt. OSSL_FUNC_asym_cipher_get_ctx_params is optional but if it is present then so must OSSL_FUNC_asym_cipher_gettable_ctx_params. Similarly, OSSL_FUNC_asym_cipher_set_ctx_params is optional but if it is present then so must OSSL_FUNC_asym_cipher_settable_ctx_params.

An asymmetric cipher algorithm must also implement some mechanism for generating, loading or importing keys via the key management (OSSL_OP_KEYMGMT) operation. See provider-keymgmt (7) for further details.

Context Management Functions

OSSL_FUNC_asym_cipher_newctx() should create and return a pointer to a provider side structure for holding context information during an asymmetric cipher operation. A pointer to this context will be passed back in a number of the other asymmetric cipher operation function calls. The parameter provctx is the provider context generated during provider initialisation (see provider (7)).

OSSL_FUNC_asym_cipher_freectx() is passed a pointer to the provider side asymmetric cipher context in the ctx parameter. This function should free any resources associated with that context.

OSSL_FUNC_asym_cipher_dupctx() should duplicate the provider side asymmetric cipher context in the ctx parameter and return the duplicate copy.

Encryption Functions

OSSL_FUNC_asym_cipher_encrypt_init() initialises a context for an asymmetric encryption given a provider side asymmetric cipher context in the ctx parameter, and a pointer to a provider key object in the provkey parameter. The params, if not NULL, should be set on the context in a manner similar to using OSSL_FUNC_asym_cipher_set_ctx_params(). The key object should have been previously generated, loaded or imported into the provider using the key management (OSSL_OP_KEYMGMT) operation (see provider-keymgmt (7)). OSSL_FUNC_asym_cipher_encrypt() performs the actual encryption itself. A previously initialised asymmetric cipher context is passed in the ctx parameter. The data to be encrypted is pointed to by the in parameter which is inlen bytes long. Unless out is NULL, the encrypted data should be written to the location pointed to by the out parameter and it should not exceed outsize bytes in length. The length of the encrypted data should be written to *outlen. If out is NULL then the maximum length of the encrypted data should be written to *outlen.

Decryption Functions

OSSL_FUNC_asym_cipher_decrypt_init() initialises a context for an asymmetric decryption given a provider side asymmetric cipher context in the ctx parameter, and a pointer to a provider key object in the provkey parameter. The params, if not NULL, should be set on the context in a manner similar to using OSSL_FUNC_asym_cipher_set_ctx_params(). The key object should have been previously generated, loaded or imported into the provider using the key management (OSSL_OP_KEYMGMT) operation (see provider-keymgmt (7)).

OSSL_FUNC_asym_cipher_decrypt() performs the actual decryption itself. A previously initialised asymmetric cipher context is passed in the ctx parameter. The data to be decrypted is pointed to by the in parameter which is inlen bytes long. Unless out is NULL, the decrypted data should be written to the location pointed to by the out parameter and it should not exceed outsize bytes in length. The length of the decrypted data should be written to *outlen. If out is NULL then the maximum length of the decrypted data should be written to *outlen.

Asymmetric Cipher Parameters

See OSSL_PARAM (3) for further details on the parameters structure used by the OSSL_FUNC_asym_cipher_get_ctx_params() and OSSL_FUNC_asym_cipher_set_ctx_params() functions.

OSSL_FUNC_asym_cipher_get_ctx_params() gets asymmetric cipher parameters associated with the given provider side asymmetric cipher context ctx and stores them in params. Passing NULL for params should return true.

OSSL_FUNC_asym_cipher_set_ctx_params() sets the asymmetric cipher parameters associated with the given provider side asymmetric cipher context ctx to params. Any parameter settings are additional to any that were previously set. Passing NULL for params should return true.

Parameters currently recognised by built-in asymmetric cipher algorithms are as follows. Not all parameters are relevant to, or are understood by all asymmetric cipher algorithms:

“pad-mode” (OSSL_ASYM_CIPHER_PARAM_PAD_MODE) <UTF8 string> OR <integer>
The type of padding to be used. The interpretation of this value will depend on the algorithm in use.

“digest” (OSSL_ASYM_CIPHER_PARAM_OAEP_DIGEST) <UTF8 string>
Gets or sets the name of the OAEP digest algorithm used when OAEP padding is in use.

“digest” (OSSL_ASYM_CIPHER_PARAM_DIGEST) <UTF8 string>
Gets or sets the name of the digest algorithm used by the algorithm (where applicable).

“digest-props” (OSSL_ASYM_CIPHER_PARAM_OAEP_DIGEST_PROPS) <UTF8 string>
Gets or sets the properties to use when fetching the OAEP digest algorithm.

“digest-props” (OSSL_ASYM_CIPHER_PARAM_DIGEST_PROPS) <UTF8 string>
Gets or sets the properties to use when fetching the cipher digest algorithm.

“mgf1-digest” (OSSL_ASYM_CIPHER_PARAM_MGF1_DIGEST) <UTF8 string>
Gets or sets the name of the MGF1 digest algorithm used when OAEP or PSS padding is in use.

“mgf1-digest-props” (OSSL_ASYM_CIPHER_PARAM_MGF1_DIGEST_PROPS) <UTF8 string>
Gets or sets the properties to use when fetching the MGF1 digest algorithm.

“oaep-label” (OSSL_ASYM_CIPHER_PARAM_OAEP_LABEL) <octet string ptr>
Gets the OAEP label used when OAEP padding is in use.

“oaep-label” (OSSL_ASYM_CIPHER_PARAM_OAEP_LABEL) <octet string>
Sets the OAEP label used when OAEP padding is in use.

“tls-client-version” (OSSL_ASYM_CIPHER_PARAM_TLS_CLIENT_VERSION) <unsigned integer>
The TLS protocol version first requested by the client.

“tls-negotiated-version” (OSSL_ASYM_CIPHER_PARAM_TLS_CLIENT_VERSION) <unsigned integer>
The negotiated TLS protocol version.

“implicit-rejection” (OSSL_PKEY_PARAM_IMPLICIT_REJECTION) <unsigned integer>
Gets of sets the use of the implicit rejection mechanism for RSA PKCS#1 v1.5 decryption. When set (non zero value), the decryption API will return a deterministically random value if the PKCS#1 v1.5 padding check fails. This makes exploitation of the Bleichenbacher significantly harder, even if the code using the RSA decryption API is not implemented in side-channel free manner. Set by default. Requires provider support.

OSSL_FUNC_asym_cipher_gettable_ctx_params() and OSSL_FUNC_asym_cipher_settable_ctx_params() get a constant OSSL_PARAM (3) array that describes the gettable and settable parameters, i.e. parameters that can be used with OSSL_FUNC_asym_cipherget_ctx_params() and OSSL_FUNC_asym_cipher_set_ctx_params() respectively.

RETURN VALUES

OSSL_FUNC_asym_cipher_newctx() and OSSL_FUNC_asym_cipher_dupctx() should return the newly created provider side asymmetric cipher context, or NULL on failure.

All other functions should return 1 for success or 0 on error.

SEE ALSO

provider (7)

HISTORY

The provider ASYM_CIPHER interface was introduced in OpenSSL 3.0.

COPYRIGHT

Copyright 2019-2024 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

290 - Linux cli command standards

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command standards and provides detailed information about the command standards, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the standards.

NAME 🖥️ standards 🖥️

C and UNIX Standards

DESCRIPTION

The STANDARDS section that appears in many manual pages identifies various standards to which the documented interface conforms. The following list briefly describes these standards.

V7
Version 7 (also known as Seventh Edition) UNIX, released by AT&T/Bell Labs in 1979. After this point, UNIX systems diverged into two main dialects: BSD and System V.

4.2BSD
This is an implementation standard defined by the 4.2 release of the Berkeley Software Distribution, released by the University of California at Berkeley. This was the first Berkeley release that contained a TCP/IP stack and the sockets API. 4.2BSD was released in 1983.

Earlier major BSD releases included 3BSD (1980), 4BSD (1980), and 4.1BSD (1981).

4.3BSD
The successor to 4.2BSD, released in 1986.

4.4BSD
The successor to 4.3BSD, released in 1993. This was the last major Berkeley release.

System V
This is an implementation standard defined by AT&T’s milestone 1983 release of its commercial System V (five) release. The previous major AT&T release was System III, released in 1981.

System V release 2 (SVr2)
This was the next System V release, made in 1985. The SVr2 was formally described in the System V Interface Definition version 1 (SVID 1) published in 1985.

System V release 3 (SVr3)
This was the successor to SVr2, released in 1986. This release was formally described in the System V Interface Definition version 2 (SVID 2).

System V release 4 (SVr4)
This was the successor to SVr3, released in 1989. This version of System V is described in the “Programmer’s Reference Manual: Operating System API (Intel processors)” (Prentice-Hall 1992, ISBN 0-13-951294-2) This release was formally described in the System V Interface Definition version 3 (SVID 3), and is considered the definitive System V release.

SVID 4
System V Interface Definition version 4, issued in 1995. Available online at .

C89
This was the first C language standard, ratified by ANSI (American National Standards Institute) in 1989 (X3.159-1989). Sometimes this is known as ANSI C, but since C99 is also an ANSI standard, this term is ambiguous. This standard was also ratified by ISO (International Standards Organization) in 1990 (ISO/IEC 9899:1990), and is thus occasionally referred to as ISO C90.

C99
This revision of the C language standard was ratified by ISO in 1999 (ISO/IEC 9899:1999). Available online at .

C11
This revision of the C language standard was ratified by ISO in 2011 (ISO/IEC 9899:2011).

LFS
The Large File Summit specification, completed in 1996. This specification defined mechanisms that allowed 32-bit systems to support the use of large files (i.e., 64-bit file offsets). See .

POSIX.1-1988
This was the first POSIX standard, ratified by IEEE as IEEE Std 1003.1-1988, and subsequently adopted (with minor revisions) as an ISO standard in 1990. The term “POSIX” was coined by Richard Stallman.

POSIX.1-1990
“Portable Operating System Interface for Computing Environments”. IEEE 1003.1-1990 part 1, ratified by ISO in 1990 (ISO/IEC 9945-1:1990).

POSIX.2
IEEE Std 1003.2-1992, describing commands and utilities, ratified by ISO in 1993 (ISO/IEC 9945-2:1993).

POSIX.1b (formerly known as POSIX.4)
IEEE Std 1003.1b-1993, describing real-time facilities for portable operating systems, ratified by ISO in 1996 (ISO/IEC 9945-1:1996).

POSIX.1c (formerly known as POSIX.4a)
IEEE Std 1003.1c-1995, which describes the POSIX threads interfaces.

POSIX.1d
IEEE Std 1003.1d-1999, which describes additional real-time extensions.

POSIX.1g
IEEE Std 1003.1g-2000, which describes networking APIs (including sockets).

POSIX.1j
IEEE Std 1003.1j-2000, which describes advanced real-time extensions.

POSIX.1-1996
A 1996 revision of POSIX.1 which incorporated POSIX.1b and POSIX.1c.

XPG3
Released in 1989, this was the first release of the X/Open Portability Guide to be based on a POSIX standard (POSIX.1-1988). This multivolume guide was developed by the X/Open Group, a multivendor consortium.

XPG4
A revision of the X/Open Portability Guide, released in 1992. This revision incorporated POSIX.2.

XPG4v2
A 1994 revision of XPG4. This is also referred to as Spec 1170, where 1170 referred to the number of interfaces defined by this standard.

SUS (SUSv1)
Single UNIX Specification. This was a repackaging of XPG4v2 and other X/Open standards (X/Open Curses Issue 4 version 2, X/Open Networking Service (XNS) Issue 4). Systems conforming to this standard can be branded UNIX 95.

SUSv2
Single UNIX Specification version 2. Sometimes also referred to (incorrectly) as XPG5. This standard appeared in 1997. Systems conforming to this standard can be branded UNIX 98. See also .)

POSIX.1-2001
SUSv3
This was a 2001 revision and consolidation of the POSIX.1, POSIX.2, and SUS standards into a single document, conducted under the auspices of the Austin Group . The standard is available online at .

The standard defines two levels of conformance: POSIX conformance, which is a baseline set of interfaces required of a conforming system; and XSI Conformance, which additionally mandates a set of interfaces (the “XSI extension”) which are only optional for POSIX conformance. XSI-conformant systems can be branded UNIX 03.

The POSIX.1-2001 document is broken into four parts:

XBD: Definitions, terms, and concepts, header file specifications.

XSH: Specifications of functions (i.e., system calls and library functions in actual implementations).

XCU: Specifications of commands and utilities (i.e., the area formerly described by POSIX.2).

XRAT: Informative text on the other parts of the standard.

POSIX.1-2001 is aligned with C99, so that all of the library functions standardized in C99 are also standardized in POSIX.1-2001.

The Single UNIX Specification version 3 (SUSv3) comprises the Base Specifications containing XBD, XSH, XCU, and XRAT as above, plus X/Open Curses Issue 4 version 2 as an extra volume that is not in POSIX.1-2001.

Two Technical Corrigenda (minor fixes and improvements) of the original 2001 standard have occurred: TC1 in 2003 and TC2 in 2004.

POSIX.1-2008
SUSv4
Work on the next revision of POSIX.1/SUS was completed and ratified in 2008. The standard is available online at .

The changes in this revision are not as large as those that occurred for POSIX.1-2001/SUSv3, but a number of new interfaces are added and various details of existing specifications are modified. Many of the interfaces that were optional in POSIX.1-2001 become mandatory in the 2008 revision of the standard. A few interfaces that are present in POSIX.1-2001 are marked as obsolete in POSIX.1-2008, or removed from the standard altogether.

The revised standard is structured in the same way as its predecessor. The Single UNIX Specification version 4 (SUSv4) comprises the Base Specifications containing XBD, XSH, XCU, and XRAT, plus X/Open Curses Issue 7 as an extra volume that is not in POSIX.1-2008.

Again there are two levels of conformance: the baseline POSIX Conformance, and XSI Conformance, which mandates an additional set of interfaces beyond those in the base specification.

In general, where the STANDARDS section of a manual page lists POSIX.1-2001, it can be assumed that the interface also conforms to POSIX.1-2008, unless otherwise noted.

Technical Corrigendum 1 (minor fixes and improvements) of this standard was released in 2013.

Technical Corrigendum 2 of this standard was released in 2016.

Further information can be found on the Austin Group web site, .

SUSv4 2016 edition
This is equivalent to POSIX.1-2008, with the addition of Technical Corrigenda 1 and 2 and the XCurses specification.

POSIX.1-2017
This revision of POSIX is technically identical to POSIX.1-2008 with Technical Corrigenda 1 and 2 applied.

SUSv4 2018 edition
This is equivalent to POSIX.1-2017, with the addition of the XCurses specification.

The interfaces documented in POSIX.1/SUS are available as manual pages under sections 0p (header files), 1p (commands), and 3p (functions); thus one can write “man 3p open”.

SEE ALSO

getconf(1), confstr(3), pathconf(3), sysconf(3), attributes(7), feature_test_macros(7), libc(7), posixoptions(7), system_data_types(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

291 - Linux cli command DROP_OPERATOR

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_OPERATOR and provides detailed information about the command DROP_OPERATOR, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_OPERATOR.

NAME 🖥️ DROP_OPERATOR 🖥️

remove an operator

SYNOPSIS

DROP OPERATOR [ IF EXISTS ] name ( { left_type | NONE } , right_type ) [, ...] [ CASCADE | RESTRICT ]

DESCRIPTION

DROP OPERATOR drops an existing operator from the database system. To execute this command you must be the owner of the operator.

PARAMETERS

IF EXISTS

Do not throw an error if the operator does not exist. A notice is issued in this case.

name

The name (optionally schema-qualified) of an existing operator.

left_type

The data type of the operators left operand; write NONE if the operator has no left operand.

right_type

The data type of the operators right operand.

CASCADE

Automatically drop objects that depend on the operator (such as views using it), and in turn all objects that depend on those objects (see Section 5.14).

RESTRICT

Refuse to drop the operator if any objects depend on it. This is the default.

EXAMPLES

Remove the power operator a^b for type integer:

DROP OPERATOR ^ (integer, integer);

Remove the bitwise-complement prefix operator ~b for type bit:

DROP OPERATOR ~ (none, bit);

Remove multiple operators in one command:

DROP OPERATOR ~ (none, bit), ^ (integer, integer);

COMPATIBILITY

There is no DROP OPERATOR statement in the SQL standard.

SEE ALSO

CREATE OPERATOR (CREATE_OPERATOR(7)), ALTER OPERATOR (ALTER_OPERATOR(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

292 - Linux cli command EVP_KEYMGMT-SM2ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KEYMGMT-SM2ssl and provides detailed information about the command EVP_KEYMGMT-SM2ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KEYMGMT-SM2ssl.

NAME 🖥️ EVP_KEYMGMT-SM2ssl 🖥️

SM2, EVP_KEYMGMT-SM2, SM2 - EVP_PKEY keytype support for the Chinese SM2 signature and encryption algorithms

DESCRIPTION

The SM2 algorithm was first defined by the Chinese national standard GM/T 0003-2012 and was later standardized by ISO as ISO/IEC 14888. SM2 is actually an elliptic curve based algorithm. The current implementation in OpenSSL supports both signature and encryption schemes via the EVP interface.

When doing the SM2 signature algorithm, it requires a distinguishing identifier to form the message prefix which is hashed before the real message is hashed.

Common SM2 parameters

SM2 uses the parameters defined in “Common EC parameters” in EVP_PKEY-EC (7). The following parameters are different:

“cofactor” (OSSL_PKEY_PARAM_EC_COFACTOR) <unsigned integer>
This parameter is ignored for SM2.

(OSSL_PKEY_PARAM_DEFAULT_DIGEST) <UTF8 string>
Getter that returns the default digest name. (Currently returns “SM3” as of OpenSSL 3.0).

NOTES

SM2 signatures can be generated by using the ‘DigestSign’ series of APIs, for instance, EVP_DigestSignInit(), EVP_DigestSignUpdate() and EVP_DigestSignFinal(). Ditto for the verification process by calling the ‘DigestVerify’ series of APIs. Note that the SM2 algorithm requires the presence of the public key for signatures, as such the OSSL_PKEY_PARAM_PUB_KEY option must be set on any key used in signature generation.

Before computing an SM2 signature, an EVP_PKEY_CTX needs to be created, and an SM2 ID must be set for it, like this:

EVP_PKEY_CTX_set1_id(pctx, id, id_len);

Before calling the EVP_DigestSignInit() or EVP_DigestVerifyInit() functions, that EVP_PKEY_CTX should be assigned to the EVP_MD_CTX, like this:

EVP_MD_CTX_set_pkey_ctx(mctx, pctx);

There is normally no need to pass a pctx parameter to EVP_DigestSignInit() or EVP_DigestVerifyInit() in such a scenario.

SM2 can be tested with the openssl-speed (1) application since version 3.0. Currently, the only valid algorithm name is sm2.

Since version 3.0, SM2 keys can be generated and loaded only when the domain parameters specify the SM2 elliptic curve.

EXAMPLES

This example demonstrates the calling sequence for using an EVP_PKEY to verify a message with the SM2 signature algorithm and the SM3 hash algorithm:

#include <openssl/evp.h> /* obtain an EVP_PKEY using whatever methods… */ mctx = EVP_MD_CTX_new(); pctx = EVP_PKEY_CTX_new(pkey, NULL); EVP_PKEY_CTX_set1_id(pctx, id, id_len); EVP_MD_CTX_set_pkey_ctx(mctx, pctx); EVP_DigestVerifyInit(mctx, NULL, EVP_sm3(), NULL, pkey); EVP_DigestVerifyUpdate(mctx, msg, msg_len); EVP_DigestVerifyFinal(mctx, sig, sig_len)

SEE ALSO

EVP_PKEY_CTX_new (3), EVP_DigestSignInit (3), EVP_DigestVerifyInit (3), EVP_PKEY_CTX_set1_id (3), EVP_MD_CTX_set_pkey_ctx (3)

COPYRIGHT

Copyright 2018-2024 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

293 - Linux cli command EVP_MAC-KMAC128ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_MAC-KMAC128ssl and provides detailed information about the command EVP_MAC-KMAC128ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_MAC-KMAC128ssl.

NAME 🖥️ EVP_MAC-KMAC128ssl 🖥️

KMAC, EVP_MAC-KMAC128, EVP_MAC-KMAC256 - The KMAC EVP_MAC implementations

DESCRIPTION

Support for computing KMAC MACs through the EVP_MAC API.

Identity

These implementations are identified with one of these names and properties, to be used with EVP_MAC_fetch():

“KMAC-128”, “provider=default” or “provider=fips”

“KMAC-256”, “provider=default” or “provider=fips”

Supported parameters

The general description of these parameters can be found in “PARAMETERS” in EVP_MAC (3).

All these parameters (except for “block-size”) can be set with EVP_MAC_CTX_set_params(). Furthermore, the “size” parameter can be retrieved with EVP_MAC_CTX_get_params(), or with EVP_MAC_CTX_get_mac_size(). The length of the “size” parameter should not exceed that of a size_t. Likewise, the “block-size” parameter can be retrieved with EVP_MAC_CTX_get_params(), or with EVP_MAC_CTX_get_block_size().

“key” (OSSL_MAC_PARAM_KEY) <octet string>
Sets the MAC key. Setting this parameter is identical to passing a key to EVP_MAC_init (3). The length of the key (in bytes) must be in the range 4…512.

“custom” (OSSL_MAC_PARAM_CUSTOM) <octet string>
Sets the customization string. It is an optional value with a length of at most 512 bytes, and is empty by default.

“size” (OSSL_MAC_PARAM_SIZE) <unsigned integer>
Sets the MAC size. By default, it is 32 for KMAC-128 and 64 for KMAC-256.

“block-size” (OSSL_MAC_PARAM_BLOCK_SIZE) <unsigned integer>
Gets the MAC block size. It is 168 for KMAC-128 and 136 for KMAC-256.

“xof” (OSSL_MAC_PARAM_XOF) <integer>
The “xof” parameter value is expected to be 1 or 0. Use 1 to enable XOF mode. The default value is 0.

The “custom” parameter must be set as part of or before the EVP_MAC_init() call. The “xof” and “size” parameters can be set at any time before EVP_MAC_final(). The “key” parameter is set as part of the EVP_MAC_init() call, but can be set before it instead.

EXAMPLES

#include <openssl/evp.h> #include <openssl/params.h> static int do_kmac(const unsigned char *in, size_t in_len, const unsigned char *key, size_t key_len, const unsigned char *custom, size_t custom_len, int xof_enabled, unsigned char *out, int out_len) { EVP_MAC_CTX *ctx = NULL; EVP_MAC *mac = NULL; OSSL_PARAM params[4], *p; int ret = 0; size_t l = 0; mac = EVP_MAC_fetch(NULL, “KMAC-128”, NULL); if (mac == NULL) goto err; ctx = EVP_MAC_CTX_new(mac); /* The mac can be freed after it is used by EVP_MAC_CTX_new */ EVP_MAC_free(mac); if (ctx == NULL) goto err; /* * Setup parameters required before calling EVP_MAC_init() * The parameters OSSL_MAC_PARAM_XOF and OSSL_MAC_PARAM_SIZE may also be * used at this point. */ p = params; *p++ = OSSL_PARAM_construct_octet_string(OSSL_MAC_PARAM_KEY, (void *)key, key_len); if (custom != NULL && custom_len != 0) *p++ = OSSL_PARAM_construct_octet_string(OSSL_MAC_PARAM_CUSTOM, (void *)custom, custom_len); *p = OSSL_PARAM_construct_end(); if (!EVP_MAC_CTX_set_params(ctx, params)) goto err; if (!EVP_MAC_init(ctx)) goto err; /* * Note: the following optional parameters can be set any time * before EVP_MAC_final(). */ p = params; *p++ = OSSL_PARAM_construct_int(OSSL_MAC_PARAM_XOF, &xof_enabled); *p++ = OSSL_PARAM_construct_int(OSSL_MAC_PARAM_SIZE, &out_len); *p = OSSL_PARAM_construct_end(); if (!EVP_MAC_CTX_set_params(ctx, params)) goto err; /* The update may be called multiple times here for streamed input */ if (!EVP_MAC_update(ctx, in, in_len)) goto err; if (!EVP_MAC_final(ctx, out, &l, out_len)) goto err; ret = 1; err: EVP_MAC_CTX_free(ctx); return ret; }

SEE ALSO

EVP_MAC_CTX_get_params (3), EVP_MAC_CTX_set_params (3), “PARAMETERS” in EVP_MAC (3), OSSL_PARAM (3)

COPYRIGHT

Copyright 2018-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

294 - Linux cli command groff_www

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command groff_www and provides detailed information about the command groff_www, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the groff_www.

Name

groff_www - GNU roff macros for authoring web pages

Synopsis

groff -m www [*option *. . .] [*file *. . .]

Description

This manual page describes the GNU www macro package, which is part of the

document formatting system. This macro file is automatically loaded by the default troffrc file when the formatter (usually

is called with either of the options -Thtml or -Txhtml. To see hyperlinks in action, format this man page using one of those options.

This document is a basic guide; the HTML output driver (grohtml) remains in an alpha state. It has been included with the distribution to encourage testing.

Here is a summary of the functions found in this macro set.

.JOBNAMEsplit output into multiple files
.HXautomatic heading level cut off
.BCLspecify colours on a web page
.BGIMGspecify background image
.URLcreate a URL using two parameters
.FTPcreate an FTP reference
.MTOcreate an HTML email address
.TAGgenerate an HTML name
.IMGinclude an image file
.PIMGinclude PNG image
.MPIMGplace PNG on the margin and wrap text around it
.HnSbegin heading
.HnEend heading
.LKemit automatically collected links.
.HRproduce a horizontal rule
.NHRsuppress automatic generation of rules.
.HTLonly generate HTML title
.HEADadd data to <head> block
.ULSunorder list begin
.ULEunorder list end
.OLSordered list begin
.OLEordered list end
.DLSdefinition list begin
.DLEdefinition list end
.LIinsert a list item
.DCgenerate a drop capital
.HTMLpass an HTML raw request to the device driver
.CDScode example begin
.CDEcode example end
.ALNplace links on left of main text.
.LNSstart a new two-column table with links in the left.
.LNEend the two-column table.
.LINKSTYLEinitialize default URL attributes.

Macros

.JOBNAME filename
Split output into multiple HTML files. A file is split whenever a .SH or .NH 1 is encountered. Its argument is the file stem name for future output files. This option is equivalent to grohtml’s -j option.

.HX n
Specify the cut off depth when generating links from section headings. For example, a parameter of 2 would cause grohtml to generate a list of links for .NH 1 and .NH 2 but not for .NH 3. Whereas

.HX 0

tells grohtml that no heading links should be created at all. Another method for turning automatic headings off is by issuing the command-line switch -P-l to groff.

**.BCL **foreground background active not-visited visited
This macro takes five parameters: foreground, background, active hypertext link, hypertext link not yet visited, and visited hypertext link colour.

.BGIMG imagefile
the only parameter to this macro is the background image file.

.URL url [description] [after]
generates a URL using either one, two, or three arguments. The first parameter is the actual URL, the second is the name of the link, and the third is optional stuff to be printed immediately afterwards. If description and after are absent then the URL becomes the anchor text. Hyphenation is disabled while printing the actual URL; explicit breakpoints should be inserted with the ** escape sequence. Here is how to encode foo:

.URL http://\foo.org/ foo :

If this is processed by a device other than -Thtml or -Txhtml it appears as:

foo ⟨http://foo.org⟩:

The URL macro can be of any type; for example, we can reference

Eric Raymond’s pic guide

by:

.URL pic.html “Eric Raymond’s pic guide”

.MTO address [description] [after]
Generate an email HTML reference. The first argument is mandatory as the email address. The optional second argument is the text you see in your browser. If an empty argument is given, address is used instead. An optional third argument is stuff printed immediately afterwards. Hyphenation is disabled while printing the actual email address. For example, Joe User can be achieved by the following macro:

.MTO [email protected] “Joe User”

All URLs currently are treated as consuming no textual space in groff. This could be considered as a bug since it causes some problems. To circumvent this, www.tmac inserts a zero-width character which expands to a harmless space (only if run with -Thtml or -Txhtml).

.FTP url [description] [after]
indicates that data can be obtained via FTP. The first argument is the URL and the second is the browser text. A third argument, similar to the macros above, is intended for stuff printed immediately afterwards. The second and the third parameter are optional. Hyphenation is disabled while printing the actual URL. As an example, here is the location of the GNU FTP server. The macro example above can be specified as:

.FTP ftp://\ftp.gnu.org/ “GNU FTP server” .

.TAG name
Generates an HTML name tag from its argument. This can then be referenced using the URL macro. As you can see, you must precede the tag name with # since it is a local reference. This link was achieved via placing a TAG in the URL description above; the source looks like this:

.TP
.B URL
generates
.TAG URL
a URL using either two or three arguments.
. . .

.IMG [-R|-L|-C] filename [width] [height]
Include a picture into the document. The first argument is the horizontal location: right, left, or center (-R, -L, or -C). Alignment is centered by default (-C). The second argument is the filename. The optional third and fourth arguments are the width and height. If the width is absent it defaults to 1 inch. If the height is absent it defaults to the width. This maps onto an HTML img tag. If you are including a PNG image then it is advisable to use the PIMG macro.

.PIMG [-R|-L|-C] filename [width [height]]
Include an image in PNG format. This macro takes exactly the same parameters as the IMG macro; it has the advantage of working with PostScript and HTML devices also since it can automatically convert the image into the EPS format, using the following programs of the netpbm package: pngtopnm, pnmcrop, and pnmtops. If the document isn’t processed with -Thtml or -Txhtml it is necessary to use the -U option of groff.

.MPIMG [-R|-L] [-G gap] filename [width [height]]
Place a PNG image on the margin and wrap text around it. The first parameters are optional. The alignment: left or right (-L or -R) specifies the margin where the picture is placed at. The default alignment is left (-L). Optionally, -G* gap* can be used to arrange a gap between the picture and the text that wraps around it. The default gap width is zero.
The first non-optional argument is the filename. The optional following arguments are the width and height. If the width is absent it defaults to 1 inch. If the height is absent it defaults to the width. Example:

.MPIMG -L -G 2c foo.png 3c 1.5c

The height and width may also be given as percentages. The PostScript device calculates the width from the .l register and the height from the .p register. For example:

.MPIMG -L -G 2c foo.png 15%

.HnS n
Begin heading. The numeric heading level n is specified by the first parameter. Use this macro if your headings contain URL, FTP or MTO macros. Example:

.HnS 1
.HR
GNU Troff
.URL https://\:www\:.gnu\:.org/\:software/\:groff/
\[em]a
.URL http://www\:.gnu\:.org/ GNU
project.
.HR
.HnE

In this case you might wish to disable automatic links to headings. This can be done via -P-l from the command line.

.HnE
End heading.

.LK
Force grohtml to place the automatically generated links at this position.

.HR
Generate a full-width horizontal rule for -Thtml and -Txhtml. No effect for all other devices.

.NHR
Suppress generation of the top and bottom rules which grohtml emits by default.

.HTL
Generate an HTML title only. This differs from the TL macro of the ms macro package which generates both an HTML title and an <H1> heading. Use it to provide an HTML title as search engine fodder but a graphic title in the document. The macro terminates when a space or break is seen (.sp, .br).

.HEAD
Add arbitrary HTML data to the <head> block. Ignored if not processed with -Thtml or -Txhtml. Example:

.HEAD "<link \
  rel=""icon"" \
  type=""image/png"" \
  href=""http://foo.org//bar.png""/>"

.HTML
All text after this macro is treated as raw HTML. If the document is processed without -Thtml or -Txhtml then the macro is ignored. Internally, this macro is used as a building block for other higher-level macros.

For example, the BGIMG macro is defined as

.de BGIMG
.   HTML <body background=\$1>
..

.DC l text [color]
Produce a drop capital. The first parameter is the letter to be dropped and enlarged, the second parameter text is the adjoining text whose height the first letter should not exceed. The optional third parameter is the color of the dropped letter. It defaults to black.

.CDS
Start displaying a code section in constant width font.

.CDE
End code display

.ALN [color] [percentage]
Place section heading links automatically to the left of the main text. The color argument is optional and if present indicates which HTML background color is to be used under the links. The optional percentage indicates the amount of width to devote to displaying the links. The default values are #eeeeee and 30 for color and percentage width, respectively. This macro should only be called once at the beginning of the document. After calling this macro each section heading emits an HTML table consisting of the links in the left and the section text on the right.

.LNS
Start a new two-column table with links in the left column. This can be called if the document has text before the first .SH and if .ALN is used. Typically this is called just before the first paragraph and after the main title as it indicates that text after this point should be positioned to the right of the left-hand navigational links.

.LNE
End a two-column table. This should be called at the end of the document if .ALN was used.

.LINKSTYLE color [ fontstyle [ openglyph closeglyph ] ]
Initialize default URL attributes to be used if this macro set is not used with the HTML device. The macro set initializes itself with the following call

.LINKSTYLE blue CR \[la] \[ra]

but these values will be superseded by a user call to LINKSTYLE.

Section heading links

By default grohtml generates links to all section headings and places these at the top of the HTML document. (See LINKS for details of how to switch this off or alter the position).

Limitations of grohtml

tables are rendered as PNG images. Paul DuBois’s approach with

part of the

troffcvt distribution

should be explored.

Files

/usr/share/groff/1.23.0/tmac/www.tmac

Authors

The www macro package was written by Gaius Mulley, with additions by Werner Lemberg and Bernd Warken.

See also

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

295 - Linux cli command boot

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command boot and provides detailed information about the command boot, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the boot.

NAME 🖥️ boot 🖥️

System bootup process based on UNIX System V Release 4

DESCRIPTION

The bootup process (or “boot sequence”) varies in details among systems, but can be roughly divided into phases controlled by the following components:

  1. hardware

  2. operating system (OS) loader

  3. kernel

  4. root user-space process (init and inittab)

  5. boot scripts

Each of these is described below in more detail.

Hardware

After power-on or hard reset, control is given to a program stored in read-only memory (normally PROM); for historical reasons involving the personal computer, this program is often called “the BIOS”.

This program normally performs a basic self-test of the machine and accesses nonvolatile memory to read further parameters. This memory in the PC is battery-backed CMOS memory, so most people refer to it as “the CMOS”; outside of the PC world, it is usually called “the NVRAM” (nonvolatile RAM).

The parameters stored in the NVRAM vary among systems, but as a minimum, they should specify which device can supply an OS loader, or at least which devices may be probed for one; such a device is known as “the boot device”. The hardware boot stage loads the OS loader from a fixed position on the boot device, and then transfers control to it.

Note:
The device from which the OS loader is read may be attached via a network, in which case the details of booting are further specified by protocols such as DHCP, TFTP, PXE, Etherboot, etc.

OS loader

The main job of the OS loader is to locate the kernel on some device, load it, and run it. Most OS loaders allow interactive use, in order to enable specification of an alternative kernel (maybe a backup in case the one last compiled isn’t functioning) and to pass optional parameters to the kernel.

In a traditional PC, the OS loader is located in the initial 512-byte block of the boot device; this block is known as “the MBR” (Master Boot Record).

In most systems, the OS loader is very limited due to various constraints. Even on non-PC systems, there are some limitations on the size and complexity of this loader, but the size limitation of the PC MBR (512 bytes, including the partition table) makes it almost impossible to squeeze much functionality into it.

Therefore, most systems split the role of loading the OS between a primary OS loader and a secondary OS loader; this secondary OS loader may be located within a larger portion of persistent storage, such as a disk partition.

In Linux, the OS loader is often grub(8) (an alternative is lilo(8)).

Kernel

When the kernel is loaded, it initializes various components of the computer and operating system; each portion of software responsible for such a task is usually consider “a driver” for the applicable component. The kernel starts the virtual memory swapper (it is a kernel process, called “kswapd” in a modern Linux kernel), and mounts some filesystem at the root path, /.

Some of the parameters that may be passed to the kernel relate to these activities (for example, the default root filesystem can be overridden); for further information on Linux kernel parameters, read bootparam(7).

Only then does the kernel create the initial userland process, which is given the number 1 as its PID (process ID). Traditionally, this process executes the program /sbin/init, to which are passed the parameters that haven’t already been handled by the kernel.

Root user-space process

Note:
The following description applies to an OS based on UNIX System V Release 4. However, a number of widely used systems have adopted a related but fundamentally different approach known as systemd(1), for which the bootup process is detailed in its associated bootup(7).

When /sbin/init starts, it reads /etc/inittab for further instructions. This file defines what should be run when the /sbin/init program is instructed to enter a particular run level, giving the administrator an easy way to establish an environment for some usage; each run level is associated with a set of services (for example, run level S is single-user mode, and run level 2 entails running most network services).

The administrator may change the current run level via init(1), and query the current run level via runlevel(8).

However, since it is not convenient to manage individual services by editing this file, /etc/inittab only bootstraps a set of scripts that actually start/stop the individual services.

Boot scripts

Note:
The following description applies to an OS based on UNIX System V Release 4. However, a number of widely used systems (Slackware Linux, FreeBSD, OpenBSD) have a somewhat different scheme for boot scripts.

For each managed service (mail, nfs server, cron, etc.), there is a single startup script located in a specific directory (/etc/init.d in most versions of Linux). Each of these scripts accepts as a single argument the word “start” (causing it to start the service) or the word “stop” (causing it to stop the service). The script may optionally accept other “convenience” parameters (e.g., “restart” to stop and then start, “status” to display the service status, etc.). Running the script without parameters displays the possible arguments.

Sequencing directories

To make specific scripts start/stop at specific run levels and in a specific order, there are sequencing directories, normally of the form /etc/rc[0-6S].d. In each of these directories, there are links (usually symbolic) to the scripts in the /etc/init.d directory.

A primary script (usually /etc/rc) is called from inittab(5); this primary script calls each service’s script via a link in the relevant sequencing directory. Each link whose name begins with ‘S’ is called with the argument “start” (thereby starting the service). Each link whose name begins with ‘K’ is called with the argument “stop” (thereby stopping the service).

To define the starting or stopping order within the same run level, the name of a link contains an order-number. Also, for clarity, the name of a link usually ends with the name of the service to which it refers. For example, the link /etc/rc2.d/S80sendmail starts the sendmail(8) service on run level 2. This happens after /etc/rc2.d/S12syslog is run but before /etc/rc2.d/S90xfs is run.

To manage these links is to manage the boot order and run levels; under many systems, there are tools to help with this task (e.g., chkconfig(8)).

Boot configuration

A program that provides a service is often called a “daemon”. Usually, a daemon may receive various command-line options and parameters. To allow a system administrator to change these inputs without editing an entire boot script, some separate configuration file is used, and is located in a specific directory where an associated boot script may find it (/etc/sysconfig on older Red Hat systems).

In older UNIX systems, such a file contained the actual command line options for a daemon, but in modern Linux systems (and also in HP-UX), it just contains shell variables. A boot script in /etc/init.d reads and includes its configuration file (that is, it “sources” its configuration file) and then uses the variable values.

FILES

/etc/init.d/, /etc/rc[S0-6].d/, /etc/sysconfig/

SEE ALSO

init(1), systemd(1), inittab(5), bootparam(7), bootup(7), runlevel(8), shutdown(8)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

296 - Linux cli command CHECKPOINT

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CHECKPOINT and provides detailed information about the command CHECKPOINT, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CHECKPOINT.

NAME 🖥️ CHECKPOINT 🖥️

force a write-ahead log checkpoint

SYNOPSIS

CHECKPOINT

DESCRIPTION

A checkpoint is a point in the write-ahead log sequence at which all data files have been updated to reflect the information in the log. All data files will be flushed to disk. Refer to Section 30.5 for more details about what happens during a checkpoint.

The CHECKPOINT command forces an immediate checkpoint when the command is issued, without waiting for a regular checkpoint scheduled by the system (controlled by the settings in Section 20.5.2). CHECKPOINT is not intended for use during normal operation.

If executed during recovery, the CHECKPOINT command will force a restartpoint (see Section 30.5) rather than writing a new checkpoint.

Only superusers or users with the privileges of the pg_checkpoint role can call CHECKPOINT.

COMPATIBILITY

The CHECKPOINT command is a PostgreSQL language extension.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

297 - Linux cli command EVP_PKEY-ECssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_PKEY-ECssl and provides detailed information about the command EVP_PKEY-ECssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_PKEY-ECssl.

NAME 🖥️ EVP_PKEY-ECssl 🖥️

EC, EVP_KEYMGMT-EC - EVP_PKEY EC keytype and algorithm support

DESCRIPTION

The EC keytype is implemented in OpenSSL’s default provider.

Common EC parameters

The normal way of specifying domain parameters for an EC curve is via the curve name “group”. For curves with no curve name, explicit parameters can be used that specify “field-type”, “p”, “a”, “b”, “generator” and “order”. Explicit parameters are supported for backwards compatibility reasons, but they are not compliant with multiple standards (including RFC5915) which only allow named curves.

The following KeyGen/Gettable/Import/Export types are available for the built-in EC algorithm:

“group” (OSSL_PKEY_PARAM_GROUP_NAME) <UTF8 string>
The curve name.

“field-type” (OSSL_PKEY_PARAM_EC_FIELD_TYPE) <UTF8 string>
The value should be either “prime-field” or “characteristic-two-field”, which correspond to prime field Fp and binary field F2^m.

“p” (OSSL_PKEY_PARAM_EC_P) <unsigned integer>
For a curve over Fp p is the prime for the field. For a curve over F2^m p represents the irreducible polynomial - each bit represents a term in the polynomial. Therefore, there will either be three or five bits set dependent on whether the polynomial is a trinomial or a pentanomial.

“a” (OSSL_PKEY_PARAM_EC_A) <unsigned integer>

“b” (OSSL_PKEY_PARAM_EC_B) <unsigned integer>

“seed” (OSSL_PKEY_PARAM_EC_SEED) <octet string>

a and b represents the coefficients of the curve For Fp: y^2 mod p = x^3 +ax + b mod p OR For F2^m: y^2 + xy = x^3 + ax^2 + b seed is an optional value that is for information purposes only. It represents the random number seed used to generate the coefficient b from a random number.

“generator” (OSSL_PKEY_PARAM_EC_GENERATOR) <octet string>

“order” (OSSL_PKEY_PARAM_EC_ORDER) <unsigned integer>

“cofactor” (OSSL_PKEY_PARAM_EC_COFACTOR) <unsigned integer>

The generator is a well defined point on the curve chosen for cryptographic operations. The encoding conforms with Sec. 2.3.3 of the SECG SEC 1 (“Elliptic Curve Cryptography”) standard. See EC_POINT_oct2point(). Integers used for point multiplications will be between 0 and order - 1. cofactor is an optional value. order multiplied by the cofactor gives the number of points on the curve.

“decoded-from-explicit” (OSSL_PKEY_PARAM_EC_DECODED_FROM_EXPLICIT_PARAMS) <integer>
Gets a flag indicating whether the key or parameters were decoded from explicit curve parameters. Set to 1 if so or 0 if a named curve was used.

“use-cofactor-flag” (OSSL_PKEY_PARAM_USE_COFACTOR_ECDH) <integer>
Enable Cofactor DH (ECC CDH) if this value is 1, otherwise it uses normal EC DH if the value is zero. The cofactor variant multiplies the shared secret by the EC curve’s cofactor (note for some curves the cofactor is 1). See also EVP_KEYEXCH-ECDH (7) for the related OSSL_EXCHANGE_PARAM_EC_ECDH_COFACTOR_MODE parameter that can be set on a per-operation basis.

“encoding” (OSSL_PKEY_PARAM_EC_ENCODING) <UTF8 string>
Set the format used for serializing the EC group parameters. Valid values are “explicit” or “named_curve”. The default value is “named_curve”.

“point-format” (OSSL_PKEY_PARAM_EC_POINT_CONVERSION_FORMAT) <UTF8 string>
Sets or gets the point_conversion_form for the key. For a description of point_conversion_forms please see EC_POINT_new (3). Valid values are “uncompressed” or “compressed”. The default value is “uncompressed”.

“group-check” (OSSL_PKEY_PARAM_EC_GROUP_CHECK_TYPE) <UTF8 string>
Sets or Gets the type of group check done when EVP_PKEY_param_check() is called. Valid values are “default”, “named” and “named-nist”. The “named” type checks that the domain parameters match the inbuilt curve parameters, “named-nist” is similar but also checks that the named curve is a nist curve. The “default” type does domain parameter validation for the OpenSSL default provider, but is equivalent to “named-nist” for the OpenSSL FIPS provider.

“include-public” (OSSL_PKEY_PARAM_EC_INCLUDE_PUBLIC) <integer>
Setting this value to 0 indicates that the public key should not be included when encoding the private key. The default value of 1 will include the public key.

“pub” (OSSL_PKEY_PARAM_PUB_KEY) <octet string>
The public key value in encoded EC point format conforming to Sec. 2.3.3 and 2.3.4 of the SECG SEC 1 (“Elliptic Curve Cryptography”) standard. This parameter is used when importing or exporting the public key value with the EVP_PKEY_fromdata() and EVP_PKEY_todata() functions. Note, in particular, that the choice of point compression format used for encoding the exported value via EVP_PKEY_todata() depends on the underlying provider implementation. Before OpenSSL 3.0.8, the implementation of providers included with OpenSSL always opted for an encoding in compressed format, unconditionally. Since OpenSSL 3.0.8, the implementation has been changed to honor the OSSL_PKEY_PARAM_EC_POINT_CONVERSION_FORMAT parameter, if set, or to default to uncompressed format.

“priv” (OSSL_PKEY_PARAM_PRIV_KEY) <unsigned integer>
The private key value.

“encoded-pub-key” (OSSL_PKEY_PARAM_ENCODED_PUBLIC_KEY) <octet string>
Used for getting and setting the encoding of an EC public key. The public key is expected to be a point conforming to Sec. 2.3.4 of the SECG SEC 1 (“Elliptic Curve Cryptography”) standard.

“qx” (OSSL_PKEY_PARAM_EC_PUB_X) <unsigned integer>
Used for getting the EC public key X component.

“qy” (OSSL_PKEY_PARAM_EC_PUB_Y) <unsigned integer>
Used for getting the EC public key Y component.

“default-digest” (OSSL_PKEY_PARAM_DEFAULT_DIGEST) <UTF8 string>
Getter that returns the default digest name. (Currently returns “SHA256” as of OpenSSL 3.0).

“dhkem-ikm” (OSSL_PKEY_PARAM_DHKEM_IKM) <octet string>
DHKEM requires the generation of a keypair using an input key material (seed). Use this to specify the key material used for generation of the private key. This value should not be reused for other purposes. It can only be used for the curves “P-256”, “P-384” and “P-521” and should have a length of at least the size of the encoded private key (i.e. 32, 48 and 66 for the listed curves).

The following Gettable types are also available for the built-in EC algorithm:

“basis-type” (OSSL_PKEY_PARAM_EC_CHAR2_TYPE) <UTF8 string>
Supports the values “tpBasis” for a trinomial or “ppBasis” for a pentanomial. This field is only used for a binary field F2^m.

“m” (OSSL_PKEY_PARAM_EC_CHAR2_M) <integer>

“tp” (OSSL_PKEY_PARAM_EC_CHAR2_TP_BASIS) <integer>

“k1” (OSSL_PKEY_PARAM_EC_CHAR2_PP_K1) <integer>

“k2” (OSSL_PKEY_PARAM_EC_CHAR2_PP_K2) <integer>

“k3” (OSSL_PKEY_PARAM_EC_CHAR2_PP_K3) <integer>

These fields are only used for a binary field F2^m. m is the degree of the binary field. tp is the middle bit of a trinomial so its value must be in the range m > tp > 0. k1, k2 and k3 are used to get the middle bits of a pentanomial such that m > k3 > k2 > k1 > 0

EC key validation

For EC keys, EVP_PKEY_param_check (3) behaves in the following way: For the OpenSSL default provider it uses either EC_GROUP_check (3) or EC_GROUP_check_named_curve (3) depending on the flag EC_FLAG_CHECK_NAMED_GROUP. The OpenSSL FIPS provider uses EC_GROUP_check_named_curve (3) in order to conform to SP800-56Ar3 Assurances of Domain-Parameter Validity.

For EC keys, EVP_PKEY_param_check_quick (3) is equivalent to EVP_PKEY_param_check (3).

For EC keys, EVP_PKEY_public_check (3) and EVP_PKEY_public_check_quick (3) conform to SP800-56Ar3 ECC Full Public-Key Validation and ECC Partial Public-Key Validation respectively.

For EC Keys, EVP_PKEY_private_check (3) and EVP_PKEY_pairwise_check (3) conform to SP800-56Ar3 Private key validity and Owner Assurance of Pair-wise Consistency respectively.

EXAMPLES

An EVP_PKEY context can be obtained by calling:

EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “EC”, NULL);

An EVP_PKEY ECDSA or ECDH key can be generated with a “P-256” named group by calling:

pkey = EVP_EC_gen(“P-256”);

or like this:

EVP_PKEY *key = NULL; OSSL_PARAM params[2]; EVP_PKEY_CTX *gctx = EVP_PKEY_CTX_new_from_name(NULL, “EC”, NULL); EVP_PKEY_keygen_init(gctx); params[0] = OSSL_PARAM_construct_utf8_string(OSSL_PKEY_PARAM_GROUP_NAME, “P-256”, 0); params[1] = OSSL_PARAM_construct_end(); EVP_PKEY_CTX_set_params(gctx, params); EVP_PKEY_generate(gctx, &key); EVP_PKEY_print_private(bio_out, key, 0, NULL); … EVP_PKEY_free(key); EVP_PKEY_CTX_free(gctx);

An EVP_PKEY EC CDH (Cofactor Diffie-Hellman) key can be generated with a “K-571” named group by calling:

int use_cdh = 1; EVP_PKEY *key = NULL; OSSL_PARAM params[3]; EVP_PKEY_CTX *gctx = EVP_PKEY_CTX_new_from_name(NULL, “EC”, NULL); EVP_PKEY_keygen_init(gctx); params[0] = OSSL_PARAM_construct_utf8_string(OSSL_PKEY_PARAM_GROUP_NAME, “K-571”, 0); /* * This curve has a cofactor that is not 1 - so setting CDH mode changes * the behaviour. For many curves the cofactor is 1 - so setting this has * no effect. */ params[1] = OSSL_PARAM_construct_int(OSSL_PKEY_PARAM_USE_COFACTOR_ECDH, &use_cdh); params[2] = OSSL_PARAM_construct_end(); EVP_PKEY_CTX_set_params(gctx, params); EVP_PKEY_generate(gctx, &key); EVP_PKEY_print_private(bio_out, key, 0, NULL); … EVP_PKEY_free(key); EVP_PKEY_CTX_free(gctx);

SEE ALSO

EVP_EC_gen (3), EVP_KEYMGMT (3), EVP_PKEY (3), provider-keymgmt (7), EVP_SIGNATURE-ECDSA (7), EVP_KEYEXCH-ECDH (7)

COPYRIGHT

Copyright 2020-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

298 - Linux cli command propertyssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command propertyssl and provides detailed information about the command propertyssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the propertyssl.

NAME 🖥️ propertyssl 🖥️

Properties, a selection mechanism for algorithm implementations

DESCRIPTION

As of OpenSSL 3.0, a new method has been introduced to decide which of multiple implementations of an algorithm will be used. The method is centered around the concept of properties. Each implementation defines a number of properties and when an algorithm is being selected, filters based on these properties can be used to choose the most appropriate implementation of the algorithm.

Properties are like variables, they are referenced by name and have a value assigned.

Property Names

Property names fall into two categories: those reserved by the OpenSSL project and user defined names. A reserved property name consists of a single C-style identifier (except for leading underscores not being permitted), which begins with a letter and can be followed by any number of letters, numbers and underscores. Property names are case-insensitive, but OpenSSL will only use lowercase letters.

A user defined property name is similar, but it must consist of two or more C-style identifiers, separated by periods. The last identifier in the name can be considered the ’true’ property name, which is prefixed by some sort of ’namespace’. Providers for example could include their name in the prefix and use property names like

<provider_name>.<property_name> <provider_name>.<algorithm_name>.<property_name>

Properties

A property is a name=value pair. A property definition is a sequence of comma separated properties. There can be any number of properties in a definition, however each name must be unique. For example: "" defines an empty property definition (i.e., no restriction); “my.foo=bar” defines a property named my.foo which has a string value bar and “iteration.count=3” defines a property named iteration.count which has a numeric value of 3. The full syntax for property definitions appears below.

Implementations

Each implementation of an algorithm can define any number of properties. For example, the default provider defines the property provider=default for all of its algorithms. Likewise, OpenSSL’s FIPS provider defines provider=fips and the legacy provider defines provider=legacy for all of their algorithms.

Queries

A property query clause is a single conditional test. For example, “fips=yes”, “provider!=default” or “?iteration.count=3”. The first two represent mandatory clauses, such clauses must match for any algorithm to even be under consideration. The third clause represents an optional clause. Matching such clauses is not a requirement, but any additional optional match counts in favor of the algorithm. More details about that in the Lookups section. A property query is a sequence of comma separated property query clauses. It is an error if a property name appears in more than one query clause. The full syntax for property queries appears below, but the available syntactic features are:

  • = is an infix operator providing an equality test.

  • != is an infix operator providing an inequality test.

  • ? is a prefix operator that means that the following clause is optional but preferred.

  • - is a prefix operator that means any global query clause involving the following property name should be ignored.

  • "…" is a quoted string. The quotes are not included in the body of the string.

  • ’…’ is a quoted string. The quotes are not included in the body of the string.

Lookups

When an algorithm is looked up, a property query is used to determine the best matching algorithm. All mandatory query clauses must be present and the implementation that additionally has the largest number of matching optional query clauses will be used. If there is more than one such optimal candidate, the result will be chosen from amongst those in an indeterminate way. Ordering of optional clauses is not significant.

Shortcut

In order to permit a more concise expression of boolean properties, there is one short cut: a property name alone (e.g. “my.property”) is exactly equivalent to “my.property=yes” in both definitions and queries.

Global and Local

Two levels of property query are supported. A context based property query that applies to all fetch operations and a local property query. Where both the context and local queries include a clause with the same name, the local clause overrides the context clause.

It is possible for a local property query to remove a clause in the context property query by preceding the property name with a ‘-’. For example, a context property query that contains “fips=yes” would normally result in implementations that have “fips=yes”.

However, if the setting of the “fips” property is irrelevant to the operations being performed, the local property query can include the clause “-fips”. Note that the local property query could not use “fips=no” because that would disallow any implementations with “fips=yes” rather than not caring about the setting.

SYNTAX

The lexical syntax in EBNF is given by:

Definition ::= PropertyName ( = Value )? ( , PropertyName ( = Value )? )* Query ::= PropertyQuery ( , PropertyQuery )* PropertyQuery ::= - PropertyName | ?? ( PropertyName (( = | != ) Value)?) Value ::= NumberLiteral | StringLiteral StringLiteral ::= QuotedString | UnquotedString QuotedString ::= " [^"]* " | "" [^]* "" UnquotedString ::= [A-Za-z] [^{space},]+ NumberLiteral ::= 0 ( [0-7]* | x [0-9A-Fa-f]+ ) | -? [1-9] [0-9]+ PropertyName ::= [A-Za-z] [A-Za-z0-9_]* ( . [A-Za-z] [A-Za-z0-9_]* )*

The flavour of EBNF being used is defined by: <https://www.w3.org/TR/2010/REC-xquery-20101214/#EBNFNotation>.

HISTORY

Properties were added in OpenSSL 3.0

COPYRIGHT

Copyright 2019-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

299 - Linux cli command DROP_GROUP

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_GROUP and provides detailed information about the command DROP_GROUP, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_GROUP.

NAME 🖥️ DROP_GROUP 🖥️

remove a database role

SYNOPSIS

DROP GROUP [ IF EXISTS ] name [, ...]

DESCRIPTION

DROP GROUP is now an alias for DROP ROLE.

COMPATIBILITY

There is no DROP GROUP statement in the SQL standard.

SEE ALSO

DROP ROLE (DROP_ROLE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

300 - Linux cli command gitglossary

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command gitglossary and provides detailed information about the command gitglossary, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the gitglossary.

NAME 🖥️ gitglossary 🖥️

A Git Glossary

SYNOPSIS

*

DESCRIPTION

alternate object database

Via the alternates mechanism, a repository can inherit part of its object database from another object database, which is called an “alternate”.

bare repository

A bare repository is normally an appropriately named directory with a .git suffix that does not have a locally checked-out copy of any of the files under revision control. That is, all of the Git administrative and control files that would normally be present in the hidden .git sub-directory are directly present in the repository.git directory instead, and no other files are present and checked out. Usually publishers of public repositories make bare repositories available.

blob object

Untyped object, e.g. the contents of a file.

branch

A “branch” is a line of development. The most recent commit on a branch is referred to as the tip of that branch. The tip of the branch is referenced by a branch head, which moves forward as additional development is done on the branch. A single Git repository can track an arbitrary number of branches, but your working tree is associated with just one of them (the “current” or “checked out” branch), and HEAD points to that branch.

cache

Obsolete for: index.

chain

A list of objects, where each object in the list contains a reference to its successor (for example, the successor of a commit could be one of its parents).

changeset

BitKeeper/cvsps speak for “commit”. Since Git does not store changes, but states, it really does not make sense to use the term “changesets” with Git.

checkout

The action of updating all or part of the working tree with a tree object or blob from the object database, and updating the index and HEAD if the whole working tree has been pointed at a new branch.

cherry-picking

In SCM jargon, “cherry pick” means to choose a subset of changes out of a series of changes (typically commits) and record them as a new series of changes on top of a different codebase. In Git, this is performed by the “git cherry-pick” command to extract the change introduced by an existing commit and to record it based on the tip of the current branch as a new commit.

clean

A working tree is clean, if it corresponds to the revision referenced by the current head. Also see “dirty”.

commit

As a noun: A single point in the Git history; the entire history of a project is represented as a set of interrelated commits. The word “commit” is often used by Git in the same places other revision control systems use the words “revision” or “version”. Also used as a short hand for commit object.

As a verb: The action of storing a new snapshot of the project’s state in the Git history, by creating a new commit representing the current state of the index and advancing HEAD to point at the new commit.

commit graph concept, representations and usage

A synonym for the DAG structure formed by the commits in the object database, referenced by branch tips, using their chain of linked commits. This structure is the definitive commit graph. The graph can be represented in other ways, e.g. the “commit-graph” file.

commit-graph file

The “commit-graph” (normally hyphenated) file is a supplemental representation of the commit graph which accelerates commit graph walks. The “commit-graph” file is stored either in the .git/objects/info directory or in the info directory of an alternate object database.

commit object

An object which contains the information about a particular revision, such as parents, committer, author, date and the tree object which corresponds to the top directory of the stored revision.

commit-ish (also committish)

A commit object or an object that can be recursively dereferenced to a commit object. The following are all commit-ishes: a commit object, a tag object that points to a commit object, a tag object that points to a tag object that points to a commit object, etc.

core Git

Fundamental data structures and utilities of Git. Exposes only limited source code management tools.

DAG

Directed acyclic graph. The commit objects form a directed acyclic graph, because they have parents (directed), and the graph of commit objects is acyclic (there is no chain which begins and ends with the same object).

dangling object

An unreachable object which is not reachable even from other unreachable objects; a dangling object has no references to it from any reference or object in the repository.

dereference

Referring to a symbolic ref: the action of accessing the reference pointed at by a symbolic ref. Recursive dereferencing involves repeating the aforementioned process on the resulting ref until a non-symbolic reference is found.

Referring to a tag object: the action of accessing the object a tag points at. Tags are recursively dereferenced by repeating the operation on the result object until the result has either a specified object type (where applicable) or any non-“tag” object type. A synonym for “recursive dereference” in the context of tags is “peel”.

Referring to a commit object: the action of accessing the commit’s tree object. Commits cannot be dereferenced recursively.

Unless otherwise specified, “dereferencing” as it used in the context of Git commands or protocols is implicitly recursive.

detached HEAD

Normally the HEAD stores the name of a branch, and commands that operate on the history HEAD represents operate on the history leading to the tip of the branch the HEAD points at. However, Git also allows you to check out an arbitrary commit that isn’t necessarily the tip of any particular branch. The HEAD in such a state is called “detached”.

Note that commands that operate on the history of the current branch (e.g. git commit to build a new history on top of it) still work while the HEAD is detached. They update the HEAD to point at the tip of the updated history without affecting any branch. Commands that update or inquire information about the current branch (e.g. git branch –set-upstream-to that sets what remote-tracking branch the current branch integrates with) obviously do not work, as there is no (real) current branch to ask about in this state.

directory

The list you get with “ls” :-)

dirty

A working tree is said to be “dirty” if it contains modifications which have not been committed to the current branch.

evil merge

An evil merge is a merge that introduces changes that do not appear in any parent.

fast-forward

A fast-forward is a special type of merge where you have a revision and you are “merging” another branchs changes that happen to be a descendant of what you have. In such a case, you do not make a new merge commit but instead just update your branch to point at the same revision as the branch you are merging. This will happen frequently on a remote-tracking branch of a remote repository.

fetch

Fetching a branch means to get the branch’s head ref from a remote repository, to find out which objects are missing from the local object database, and to get them, too. See also git-fetch(1).

file system

Linus Torvalds originally designed Git to be a user space file system, i.e. the infrastructure to hold files and directories. That ensured the efficiency and speed of Git.

Git archive

Synonym for repository (for arch people).

gitfile

A plain file .git at the root of a working tree that points at the directory that is the real repository.

grafts

Grafts enable two otherwise different lines of development to be joined together by recording fake ancestry information for commits. This way you can make Git pretend the set of parents a commit has is different from what was recorded when the commit was created. Configured via the .git/info/grafts file.

Note that the grafts mechanism is outdated and can lead to problems transferring objects between repositories; see git-replace(1) for a more flexible and robust system to do the same thing.

hash

In Git’s context, synonym for object name.

head

A named reference to the commit at the tip of a branch. Heads are stored in a file in $GIT_DIR/refs/heads/ directory, except when using packed refs. (See git-pack-refs(1).)

HEAD

The current branch. In more detail: Your working tree is normally derived from the state of the tree referred to by HEAD. HEAD is a reference to one of the heads in your repository, except when using a detached HEAD, in which case it directly references an arbitrary commit.

head ref

A synonym for head.

hook

During the normal execution of several Git commands, call-outs are made to optional scripts that allow a developer to add functionality or checking. Typically, the hooks allow for a command to be pre-verified and potentially aborted, and allow for a post-notification after the operation is done. The hook scripts are found in the $GIT_DIR/hooks/ directory, and are enabled by simply removing the .sample suffix from the filename. In earlier versions of Git you had to make them executable.

index

A collection of files with stat information, whose contents are stored as objects. The index is a stored version of your working tree. Truth be told, it can also contain a second, and even a third version of a working tree, which are used when merging.

index entry

The information regarding a particular file, stored in the index. An index entry can be unmerged, if a merge was started, but not yet finished (i.e. if the index contains multiple versions of that file).

master

The default development branch. Whenever you create a Git repository, a branch named “master” is created, and becomes the active branch. In most cases, this contains the local development, though that is purely by convention and is not required.

merge

As a verb: To bring the contents of another branch (possibly from an external repository) into the current branch. In the case where the merged-in branch is from a different repository, this is done by first fetching the remote branch and then merging the result into the current branch. This combination of fetch and merge operations is called a pull. Merging is performed by an automatic process that identifies changes made since the branches diverged, and then applies all those changes together. In cases where changes conflict, manual intervention may be required to complete the merge.

As a noun: unless it is a fast-forward, a successful merge results in the creation of a new commit representing the result of the merge, and having as parents the tips of the merged branches. This commit is referred to as a “merge commit”, or sometimes just a “merge”.

object

The unit of storage in Git. It is uniquely identified by the SHA-1 of its contents. Consequently, an object cannot be changed.

object database

Stores a set of “objects”, and an individual object is identified by its object name. The objects usually live in $GIT_DIR/objects/.

object identifier (oid)

Synonym for object name.

object name

The unique identifier of an object. The object name is usually represented by a 40 character hexadecimal string. Also colloquially called SHA-1.

object type

One of the identifiers “commit”, “tree”, “tag” or “blob” describing the type of an object.

octopus

To merge more than two branches.

origin

The default upstream repository. Most projects have at least one upstream project which they track. By default origin is used for that purpose. New upstream updates will be fetched into remote-tracking branches named origin/name-of-upstream-branch, which you can see using git branch -r.

overlay

Only update and add files to the working directory, but don’t delete them, similar to how cp -R would update the contents in the destination directory. This is the default mode in a checkout when checking out files from the index or a tree-ish. In contrast, no-overlay mode also deletes tracked files not present in the source, similar to rsync –delete.

pack

A set of objects which have been compressed into one file (to save space or to transmit them efficiently).

pack index

The list of identifiers, and other information, of the objects in a pack, to assist in efficiently accessing the contents of a pack.

pathspec

Pattern used to limit paths in Git commands.

Pathspecs are used on the command line of “git ls-files”, “git ls-tree”, “git add”, “git grep”, “git diff”, “git checkout”, and many other commands to limit the scope of operations to some subset of the tree or working tree. See the documentation of each command for whether paths are relative to the current directory or toplevel. The pathspec syntax is as follows:

·

any path matches itself

·

the pathspec up to the last slash represents a directory prefix. The scope of that pathspec is limited to that subtree.

·

the rest of the pathspec is a pattern for the remainder of the pathname. Paths relative to the directory prefix will be matched against that pattern using fnmatch(3); in particular, * and ? can match directory separators.

For example, Documentation/*.jpg will match all .jpg files in the Documentation subtree, including Documentation/chapter_1/figure_1.jpg.

A pathspec that begins with a colon : has special meaning. In the short form, the leading colon : is followed by zero or more “magic signature” letters (which optionally is terminated by another colon :), and the remainder is the pattern to match against the path. The “magic signature” consists of ASCII symbols that are neither alphanumeric, glob, regex special characters nor colon. The optional colon that terminates the “magic signature” can be omitted if the pattern begins with a character that does not belong to “magic signature” symbol set and is not a colon.

In the long form, the leading colon : is followed by an open parenthesis (, a comma-separated list of zero or more “magic words”, and a close parentheses ), and the remainder is the pattern to match against the path.

A pathspec with only a colon means “there is no pathspec”. This form should not be combined with other pathspec.

top

The magic word top (magic signature: /) makes the pattern match from the root of the working tree, even when you are running the command from inside a subdirectory.

literal

Wildcards in the pattern such as * or ? are treated as literal characters.

icase

Case insensitive match.

glob

Git treats the pattern as a shell glob suitable for consumption by fnmatch(3) with the FNM_PATHNAME flag: wildcards in the pattern will not match a / in the pathname. For example, “Documentation/*.html” matches “Documentation/git.html” but not “Documentation/ppc/ppc.html” or “tools/perf/Documentation/perf.html”.

Two consecutive asterisks ("**") in patterns matched against full pathname may have special meaning:

·

A leading “**” followed by a slash means match in all directories. For example, “**/foo” matches file or directory “foo” anywhere, the same as pattern “foo”. “**/foo/bar” matches file or directory “bar” anywhere that is directly under directory “foo”.

·

A trailing “/**” matches everything inside. For example, “abc/**” matches all files inside directory “abc”, relative to the location of the .gitignore file, with infinite depth.

·

A slash followed by two consecutive asterisks then a slash matches zero or more directories. For example, “a/**/b” matches “a/b”, “a/x/b”, “a/x/y/b” and so on.

·

Other consecutive asterisks are considered invalid.

Glob magic is incompatible with literal magic.

attr

After attr: comes a space separated list of “attribute requirements”, all of which must be met in order for the path to be considered a match; this is in addition to the usual non-magic pathspec pattern matching. See gitattributes(5).

Each of the attribute requirements for the path takes one of these forms:

·

“ATTR” requires that the attribute ATTR be set.

·

“-ATTR” requires that the attribute ATTR be unset.

·

“ATTR=VALUE” requires that the attribute ATTR be set to the string VALUE.

·

“!ATTR” requires that the attribute ATTR be unspecified.

Note that when matching against a tree object, attributes are still obtained from working tree, not from the given tree object.

exclude

After a path matches any non-exclude pathspec, it will be run through all exclude pathspecs (magic signature: ! or its synonym ^). If it matches, the path is ignored. When there is no non-exclude pathspec, the exclusion is applied to the result set as if invoked without any pathspec.

parent

A commit object contains a (possibly empty) list of the logical predecessor(s) in the line of development, i.e. its parents.

peel

The action of recursively dereferencing a tag object.

pickaxe

The term pickaxe refers to an option to the diffcore routines that help select changes that add or delete a given text string. With the –pickaxe-all option, it can be used to view the full changeset that introduced or removed, say, a particular line of text. See git-diff(1).

plumbing

Cute name for core Git.

porcelain

Cute name for programs and program suites depending on core Git, presenting a high level access to core Git. Porcelains expose more of a SCM interface than the plumbing.

per-worktree ref

Refs that are per-worktree, rather than global. This is presently only HEAD and any refs that start with refs/bisect/, but might later include other unusual refs.

pseudoref

Pseudorefs are a class of files under $GIT_DIR which behave like refs for the purposes of rev-parse, but which are treated specially by git. Pseudorefs both have names that are all-caps, and always start with a line consisting of a SHA-1 followed by whitespace. So, HEAD is not a pseudoref, because it is sometimes a symbolic ref. They might optionally contain some additional data. MERGE_HEAD and CHERRY_PICK_HEAD are examples. Unlike per-worktree refs, these files cannot be symbolic refs, and never have reflogs. They also cannot be updated through the normal ref update machinery. Instead, they are updated by directly writing to the files. However, they can be read as if they were refs, so git rev-parse MERGE_HEAD will work.

pull

Pulling a branch means to fetch it and merge it. See also git-pull(1).

push

Pushing a branch means to get the branch’s head ref from a remote repository, find out if it is an ancestor to the branch’s local head ref, and in that case, putting all objects, which are reachable from the local head ref, and which are missing from the remote repository, into the remote object database, and updating the remote head ref. If the remote head is not an ancestor to the local head, the push fails.

reachable

All of the ancestors of a given commit are said to be “reachable” from that commit. More generally, one object is reachable from another if we can reach the one from the other by a chain that follows tags to whatever they tag, commits to their parents or trees, and trees to the trees or blobs that they contain.

reachability bitmaps

Reachability bitmaps store information about the reachability of a selected set of commits in a packfile, or a multi-pack index (MIDX), to speed up object search. The bitmaps are stored in a “.bitmap” file. A repository may have at most one bitmap file in use. The bitmap file may belong to either one pack, or the repository’s multi-pack index (if it exists).

rebase

To reapply a series of changes from a branch to a different base, and reset the head of that branch to the result.

ref

A name that begins with refs/ (e.g. refs/heads/master) that points to an object name or another ref (the latter is called a symbolic ref). For convenience, a ref can sometimes be abbreviated when used as an argument to a Git command; see gitrevisions(7) for details. Refs are stored in the repository.

The ref namespace is hierarchical. Different subhierarchies are used for different purposes (e.g. the refs/heads/ hierarchy is used to represent local branches).

There are a few special-purpose refs that do not begin with refs/. The most notable example is HEAD.

reflog

A reflog shows the local “history” of a ref. In other words, it can tell you what the 3rd last revision in this repository was, and what was the current state in this repository, yesterday 9:14pm. See git-reflog(1) for details.

refspec

A “refspec” is used by fetch and push to describe the mapping between remote ref and local ref.

remote repository

A repository which is used to track the same project but resides somewhere else. To communicate with remotes, see fetch or push.

remote-tracking branch

A ref that is used to follow changes from another repository. It typically looks like refs/remotes/foo/bar (indicating that it tracks a branch named bar in a remote named foo), and matches the right-hand-side of a configured fetch refspec. A remote-tracking branch should not contain direct modifications or have local commits made to it.

repository

A collection of refs together with an object database containing all objects which are reachable from the refs, possibly accompanied by meta data from one or more porcelains. A repository can share an object database with other repositories via alternates mechanism.

resolve

The action of fixing up manually what a failed automatic merge left behind.

revision

Synonym for commit (the noun).

rewind

To throw away part of the development, i.e. to assign the head to an earlier revision.

SCM

Source code management (tool).

SHA-1

“Secure Hash Algorithm 1”; a cryptographic hash function. In the context of Git used as a synonym for object name.

shallow clone

Mostly a synonym to shallow repository but the phrase makes it more explicit that it was created by running git clone –depth=… command.

shallow repository

A shallow repository has an incomplete history some of whose commits have parents cauterized away (in other words, Git is told to pretend that these commits do not have the parents, even though they are recorded in the commit object). This is sometimes useful when you are interested only in the recent history of a project even though the real history recorded in the upstream is much larger. A shallow repository is created by giving the –depth option to git-clone(1), and its history can be later deepened with git-fetch(1).

stash entry

An object used to temporarily store the contents of a dirty working directory and the index for future reuse.

submodule

A repository that holds the history of a separate project inside another repository (the latter of which is called superproject).

superproject

A repository that references repositories of other projects in its working tree as submodules. The superproject knows about the names of (but does not hold copies of) commit objects of the contained submodules.

symref

Symbolic reference: instead of containing the SHA-1 id itself, it is of the format ref: refs/some/thing and when referenced, it recursively dereferences to this reference. HEAD is a prime example of a symref. Symbolic references are manipulated with the git-symbolic-ref(1) command.

tag

A ref under refs/tags/ namespace that points to an object of an arbitrary type (typically a tag points to either a tag or a commit object). In contrast to a head, a tag is not updated by the commit command. A Git tag has nothing to do with a Lisp tag (which would be called an object type in Git’s context). A tag is most typically used to mark a particular point in the commit ancestry chain.

tag object

An object containing a ref pointing to another object, which can contain a message just like a commit object. It can also contain a (PGP) signature, in which case it is called a “signed tag object”.

topic branch

A regular Git branch that is used by a developer to identify a conceptual line of development. Since branches are very easy and inexpensive, it is often desirable to have several small branches that each contain very well defined concepts or small incremental yet related changes.

tree

Either a working tree, or a tree object together with the dependent blob and tree objects (i.e. a stored representation of a working tree).

tree object

An object containing a list of file names and modes along with refs to the associated blob and/or tree objects. A tree is equivalent to a directory.

tree-ish (also treeish)

A tree object or an object that can be recursively dereferenced to a tree object. Dereferencing a commit object yields the tree object corresponding to the revisions top directory. The following are all tree-ishes: a commit-ish, a tree object, a tag object that points to a tree object, a tag object that points to a tag object that points to a tree object, etc.

unmerged index

An index which contains unmerged index entries.

unreachable object

An object which is not reachable from a branch, tag, or any other reference.

upstream branch

The default branch that is merged into the branch in question (or the branch in question is rebased onto). It is configured via branch.<name>.remote and branch.<name>.merge. If the upstream branch of A is origin/B sometimes we say “A is tracking origin/B”.

working tree

The tree of actual checked out files. The working tree normally contains the contents of the HEAD commit’s tree, plus any local changes that you have made but not yet committed.

worktree

A repository can have zero (i.e. bare repository) or one or more worktrees attached to it. One “worktree” consists of a “working tree” and repository metadata, most of which are shared among other worktrees of a single repository, and some of which are maintained separately per worktree (e.g. the index, HEAD and pseudorefs like MERGE_HEAD, per-worktree refs and per-worktree configuration file).

SEE ALSO

gittutorial(7), gittutorial-2(7), gitcvs-migration(7), giteveryday(7), The Git User’s Manual[1]

GIT

Part of the git(1) suite

NOTES

The Git User’s Manual

file:///usr/share/doc/git/html/user-manual.html

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

301 - Linux cli command openssl-core_names.hssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command openssl-core_names.hssl and provides detailed information about the command openssl-core_names.hssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the openssl-core_names.hssl.

NAME 🖥️ openssl-core_names.hssl 🖥️

OpenSSL provider parameter names

SYNOPSIS

#include <openssl/core_names.h>

DESCRIPTION

The <openssl/core_names.h> header defines a multitude of macros for OSSL_PARAM (3) names, algorithm names and other known names used with OpenSSL’s providers, made available for practical purposes only.

Existing names are further described in the manuals for OpenSSL’s providers (see “SEE ALSO”) and the manuals for each algorithm they provide (listed in those provider manuals).

SEE ALSO

OSSL_PROVIDER-default (7), OSSL_PROVIDER-FIPS (7), OSSL_PROVIDER-legacy (7)

HISTORY

The macros described here were added in OpenSSL 3.0.

CAVEATS

This header file does not constitute a general registry of names. Providers that implement new algorithms are to be responsible for their own parameter names.

However, authors of provider that implement their own variants of algorithms that OpenSSL providers support will want to pay attention to the names provided in this header to work in a compatible manner.

COPYRIGHT

Copyright 2020 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

302 - Linux cli command roff

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command roff and provides detailed information about the command roff, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the roff.

Name

roff - concepts and history of roff typesetting

Description

The term roff denotes a family of document formatting systems known by names like troff, nroff, and ditroff. A roff system consists of an interpreter for an extensible text formatting language and a set of programs for preparing output for various devices and file formats. Unix-like operating systems often distribute a roff system. The manual pages on Unix systems (“man pages”) and bestselling books on software engineering, including Brian Kernighan and Dennis Ritchie’s The C Programming Language and W. Richard Stevens’s Advanced Programming in the Unix Environment have been written using roff systems. GNU roff—groff—is arguably the most widespread roff implementation.

Below we present typographical concepts that form the background of all roff implementations, narrate the development history of some roff systems, detail the command pipeline managed by

survey the formatting language, suggest tips for editing roff input, and recommend further reading materials.

Concepts

roff input files contain text interspersed with instructions to control the formatter. Even in the absence of such instructions, a roff formatter still processes its input in several ways, by filling, hyphenating, breaking, and adjusting it, and supplementing it with inter-sentence space. These processes are basic to typesetting, and can be controlled at the input document’s discretion.

When a device-independent roff formatter starts up, it obtains information about the device for which it is preparing output from the latter’s description file (see

An essential property is the length of the output line, such as “6.5 inches”.

The formatter interprets plain text files employing the Unix line-ending convention. It reads input a character at a time, collecting words as it goes, and fits as many words together on an output line as it can—this is known as filling. To a roff system, a word is any sequence of one or more characters that aren’t spaces or newlines. The exceptions separate words.

A roff formatter attempts to detect boundaries between sentences, and supplies additional inter-sentence space between them. It flags certain characters (normally “!”, “?”, and “.”) as potentially ending a sentence. When the formatter encounters one of these end-of-sentence characters at the end of an input line, or one of them is followed by two (unescaped) spaces on the same input line, it appends an inter-word space followed by an inter-sentence space in the output. The dummy character escape sequence ** can be used after an end-of-sentence character to defeat end-of-sentence detection on a per-instance basis. Normally, the occurrence of a visible non-end-of-sentence character (as opposed to a space or tab) immediately after an end-of-sentence character cancels detection of the end of a sentence. However, several characters are treated transparently after the occurrence of an end-of-sentence character. That is, a roff does not cancel end-of-sentence detection when it processes them. This is because such characters are often used as footnote markers or to close quotations and parentheticals. The default set is ", ’, ), ], *, \dg], \dd], \rq], and \cq]. The last four are examples of special characters, escape sequences whose purpose is to obtain glyphs that are not easily typed at the keyboard, or which have special meaning to the formatter (like ****).

When an output line is nearly full, it is uncommon for the next word collected from the input to exactly fill it—typically, there is room left over only for part of the next word. The process of splitting a word so that it appears partially on one line (with a hyphen to indicate to the reader that the word has been broken) with its remainder on the next is hyphenation. Hyphenation points can be manually specified; groff also uses a hyphenation algorithm and language-specific pattern files to decide which words can be hyphenated and where. Hyphenation does not always occur even when the hyphenation rules for a word allow it; it can be disabled, and when not disabled there are several parameters that can prevent it in certain circumstances.

Once an output line is full, the next word (or remainder of a hyphenated one) is placed on a different output line; this is called a break. In this document and in roff discussions generally, a “break” if not further qualified always refers to the termination of an output line. When the formatter is filling text, it introduces breaks automatically to keep output lines from exceeding the configured line length. After an automatic break, a roff formatter adjusts the line if applicable (see below), and then resumes collecting and filling text on the next output line.

Sometimes, a line cannot be broken automatically. This usually does not happen with natural language text unless the output line length has been manipulated to be extremely short, but it can with specialized text like program source code. groff provides a means of telling the formatter where the line may be broken without hyphens. This is done with the non-printing break point escape sequence ****.

There are several ways to cause a break at a predictable location. A blank input line not only causes a break, but by default it also outputs a one-line vertical space (effectively a blank output line). Macro packages may discourage or disable this “blank line method” of paragraphing in favor of their own macros. A line that begins with one or more spaces causes a break. The spaces are output at the beginning of the next line without being adjusted (see below). Again, macro packages may provide other methods of producing indented paragraphs. Trailing spaces on text lines (see below) are discarded. The end of input causes a break.

After the formatter performs an automatic break, it may then adjust the line, widening inter-word spaces until the text reaches the right margin. Extra spaces between words are preserved. Leading and trailing spaces are handled as noted above. Text can be aligned to the left or right margin only, or centered, using requests.

A roff formatter translates horizontal tab characters, also called simply “tabs”, in the input into movements to the next tab stop. These tab stops are by default located every half inch measured from the current position on the input line. With them, simple tables can be made. However, this method can be deceptive, as the appearance (and width) of the text in an editor and the results from the formatter can vary greatly, particularly when proportional typefaces are used. A tab character does not cause a break and therefore does not interrupt filling. The formatter provides facilities for sophisticated table composition; there are many details to track when using the “tab” and “field” low-level features, so most users turn to the

preprocessor to lay out tables.

Requests and macros

A request is an instruction to the formatter that occurs after a control character, which is recognized at the beginning of an input line. The regular control character is a dot “.”. Its counterpart, the no-break control character, a neutral apostrophe “** ’ ”, suppresses the break implied by some requests. These characters were chosen because it is uncommon for lines of text in natural languages to begin with them. If you require a formatted period or apostrophe (closing single quotation mark) where the formatter is expecting a control character, prefix the dot or neutral apostrophe with the dummy character escape sequence, “**”.

An input line beginning with a control character is called a control line. Every line of input that is not a control line is a text line.

Requests often take arguments, words (separated from the request name and each other by spaces) that specify details of the action the formatter is expected to perform. If a request is meaningless without arguments, it is typically ignored. Of key importance are the requests that define macros. Macros are invoked like requests, enabling the request repertoire to be extended or overridden.

A macro can be thought of as an abbreviation you can define for a collection of control and text lines. When the macro is called by giving its name after a control character, it is replaced with what it stands for. The process of textual replacement is known as interpolation. Interpolations are handled as soon as they are recognized, and once performed, a roff formatter scans the replacement for further requests, macro calls, and escape sequences.

In roff systems, the “de” request defines a macro.

Page geometry

roff systems format text under certain assumptions about the size of the output medium, or page. For the formatter to correctly break a line it is filling, it must know the line length, which it derives from the page width. For it to decide whether to write an output line to the current page or wait until the next one, it must know the page length. A device’s resolution converts practical units like inches or centimeters to basic units, a convenient length measure for the output device or file format. The formatter and output driver use basic units to reckon page measurements. The device description file defines its resolution and page dimensions (see

A page is a two-dimensional structure upon which a roff system imposes a rectangular coordinate system with its upper left corner as the origin. Coordinate values are in basic units and increase down and to the right. Useful ones are therefore always positive and within numeric ranges corresponding to the page boundaries.

While the formatter (and, later, output driver) is processing a page, it keeps track of its drawing position, which is the location at which the next glyph will be written, from which the next motion will be measured, or where a geometric object will commence rendering. Notionally, glyphs are drawn from the text baseline upward and to the right. (groff does not yet support right-to-left scripts.) The text baseline is a (usually invisible) line upon which the glyphs of a typeface are aligned. A glyph therefore “starts” at its bottom-left corner. If drawn at the origin, a typical letter glyph would lie partially or wholly off the page, depending on whether, like “g”, it features a descender below the baseline.

Such a situation is nearly always undesirable. It is furthermore conventional not to write or draw at the extreme edges of the page. Therefore the initial drawing position of a roff formatter is not at the origin, but below and to the right of it. This rightward shift from the left edge is known as the page offset. (groff’s terminal output devices have page offsets of zero.) The downward shift leaves room for a text output line.

Text is arranged on a one-dimensional lattice of text baselines from the top to the bottom of the page. Vertical spacing is the distance between adjacent text baselines. Typographic tradition sets this quantity to 120% of the type size. The initial vertical drawing position is one unit of vertical spacing below the page top. Typographers term this unit a vee.

Vertical spacing has an impact on page-breaking decisions. Generally, when a break occurs, the formatter moves the drawing position to the next text baseline automatically. If the formatter were already writing to the last line that would fit on the page, advancing by one vee would place the next text baseline off the page. Rather than let that happen, roff formatters instruct the output driver to eject the page, start a new one, and again set the drawing position to one vee below the page top; this is a page break.

When the last line of input text corresponds to the last output line that fits on the page, the break caused by the end of input will also break the page, producing a useless blank one. Macro packages keep users from having to confront this difficulty by setting “traps”; moreover, all but the simplest page layouts tend to have headers and footers, or at least bear vertical margins larger than one vee.

Other language elements

Escape sequences start with the escape character, a backslash ****, and are followed by at least one additional character. They can appear anywhere in the input.

With requests, the escape and control characters can be changed; further, escape sequence recognition can be turned off and back on.

Strings store character sequences. In groff, they can be parameterized as macros can.

Registers store numerical values, including measurements. The latter are generally in basic units; scaling units can be appended to numeric expressions to clarify their meaning when stored or interpolated. Some read-only predefined registers interpolate text.

Fonts are identified either by a name or by a mounting position (a non-negative number). Four styles are available on all devices. R is “roman”: normal, upright text. B is bold, an upright typeface with a heavier weight. I is italic, a face that is oblique on typesetter output devices and usually underlined instead on terminal devices. BI is bold-italic, combining both of the foregoing style variations. Typesetting devices group these four styles into families of text fonts; they also typically offer one or more special fonts that provide unstyled glyphs; see

groff supports named colors for glyph rendering and drawing of geometric objects. Stroke and fill colors are distinct; the stroke color is used for glyphs.

Glyphs are visual representation forms of characters. In groff, the distinction between those two elements is not always obvious (and a full discussion is beyond our scope). In brief, “A” is a character when we consider it in the abstract: to make it a glyph, we must select a typeface with which to render it, and determine its type size and color. The formatting process turns input characters into output glyphs. A few characters commonly seen on keyboards are treated specially by the roff language and may not look correct in output if used unthinkingly; they are the (double) quotation mark (** " ), the neutral apostrophe ( ’ ), the minus sign (-), the backslash ( **), the caret or circumflex accent (^), the grave accent (** ` ), and the tilde (~**). All of these and more can be produced with special character escape sequences; see

groff offers streams, identifiers for writable files, but for security reasons this feature is disabled by default.

A further few language elements arise as page layouts become more sophisticated and demanding. Environments collect formatting parameters like line length and typeface. A diversion stores formatted output for later use. A trap is a condition on the input or output, tested automatically by the formatter, that is associated with a macro, calling it when that condition is fulfilled.

Footnote support often exercises all three of the foregoing features. A simple implementation might work as follows. A pair of macros is defined: one starts a footnote and the other ends it. The author calls the first macro where a footnote marker is desired. The macro establishes a diversion so that the footnote text is collected at the place in the body text where its corresponding marker appears. An environment is created for the footnote so that it is set at a smaller typeface. The footnote text is formatted in the diversion using that environment, but it does not yet appear in the output. The document author calls the footnote end macro, which returns to the previous environment and ends the diversion. Later, after much more body text in the document, a trap, set a small distance above the page bottom, is sprung. The macro called by the trap draws a line across the page and emits the stored diversion. Thus, the footnote is rendered.

History

Computer-driven document formatting dates back to the 1960s. The roff system is intimately connected with Unix, but its origins lie with the earlier operating systems CTSS, GECOS, and Multics.

The predecessor—RUNOFF

roff’s ancestor RUNOFF was written in the MAD language by Jerry Saltzer to prepare his Ph.D. thesis on the Compatible Time Sharing System (CTSS), a project of the Massachusetts Institute of Technology (MIT). This program is referred to in full capitals, both to distinguish it from its many descendants, and because bits were expensive in those days; five- and six-bit character encodings were still in widespread usage, and mixed-case alphabetics in file names seen as a luxury. RUNOFF introduced a syntax of inlining formatting directives amid document text, by beginning a line with a period (an unlikely occurrence in human-readable material) followed by a “control word”. Control words with obvious meaning like “.line length n” were supported as well as an abbreviation system; the latter came to overwhelm the former in popular usage and later derivatives of the program. A sample of control words from a

RUNOFF manual of December 1966

was documented as follows (with the parameter notation slightly altered). The abbreviations will be familiar to roff veterans.

AbbreviationControl word
.ad.adjust
.bp.begin page
.br.break
.ce.center
.in.indent n
.ll.line length n
.nf.nofill
.pl.paper length n
.sp.space [n]

In 1965, MIT’s Project MAC teamed with Bell Telephone Laboratories and General Electric (GE) to inaugurate the Multics project. After a few years, Bell Labs discontinued its participation in Multics, famously prompting the development of Unix. Meanwhile, Saltzer’s RUNOFF proved influential, seeing many ports and derivations elsewhere.

In 1969, Doug McIlroy wrote one such reimplementation, adding extensions, in the BCPL language for a GE 645 running GECOS at the Bell Labs location in Murray Hill, New Jersey. In its manual, the control commands were termed “requests”, their two-letter names were canonical, and the control character was configurable with a .cc request. Other familiar requests emerged at this time; no-adjust (.na), need (.ne), page offset (.po), tab configuration (.ta, though it worked differently), temporary indent (.ti), character translation (.tr), and automatic underlining (.ul; on RUNOFF you had to backspace and underscore in the input yourself). .fi to enable filling of output lines got the name it retains to this day. McIlroy’s program also featured a heuristic system for automatically placing hyphenation points, designed and implemented by Molly Wagner. It furthermore introduced numeric variables, termed registers. By 1971, this program had been ported to Multics and was known as roff, a name McIlroy attributes to Bob Morris, to distinguish it from CTSS RUNOFF.

Unix and roff

McIlroy’s roff was one of the first Unix programs. In Ritchie’s term, it was “transliterated” from BCPL to DEC PDP-7 assembly language for the fledgling Unix operating system. Automatic hyphenation was managed with .hc and .hy requests, line spacing control was generalized with the .ls request, and what later roffs would call diversions were available via “footnote” requests. This roff indirectly funded operating systems research at Murray Hill; AT&T prepared patent applications to the U.S. government with it. This arrangement enabled the group to acquire a PDP-11; roff promptly proved equal to the task of formatting the manual for what would become known as “First Edition Unix”, dated November 1971.

Output from all of the foregoing programs was limited to line printers and paper terminals such as the IBM 2471 (based on the Selectric line of typewriters) and the Teletype Corporation Model 37. Proportionally spaced type was unavailable.

New roff and Typesetter roff

The first years of Unix were spent in rapid evolution. The practicalities of preparing standardized documents like patent applications (and Unix manual pages), combined with McIlroy’s enthusiasm for macro languages, perhaps created an irresistible pressure to make roff extensible. Joe Ossanna’s nroff, literally a “new roff”, was the outlet for this pressure. By the time of Unix Version 3 (February 1973)—and still in PDP-11 assembly language—it sported a swath of features now considered essential to roff systems: definition of macros (.de), diversion of text thither (.di), and removal thereof (.rm); trap planting (.wh; “when”) and relocation (.ch; “change”); conditional processing (.if); and environments (.ev). Incremental improvements included assignment of the next page number (.pn); no-space mode (.ns) and restoration of vertical spacing (.rs); the saving (.sv) and output (.os) of vertical space; specification of replacement characters for tabs (.tc) and leaders (.lc); configuration of the no-break control character (.c2); shorthand to disable automatic hyphenation (.nh); a condensation of what were formerly six different requests for configuration of page “titles” (headers and footers) into one (.tl) with a length controlled separately from the line length (.lt); automatic line numbering (.nm); interactive input (.rd), which necessitated buffer-flushing (.fl), and was made convenient with early program cessation (.ex); source file inclusion in its modern form (.so; though RUNOFF had an “.append” control word for a similar purpose) and early advance to the next file argument (.nx); ignorable content (.ig); and programmable abort (.ab).

Third Edition Unix also brought the

system call, the explosive growth of a componentized system based around it, and a “filter model” that remains perceptible today. Equally importantly, the Bell Labs site in Murray Hill acquired a Graphic Systems C/A/T phototypesetter, and with it came the necessity of expanding the capabilities of a roff system to cope with a variety of proportionally spaced typefaces at multiple sizes. Ossanna wrote a parallel implementation of nroff for the C/A/T, dubbing it troff (for “typesetter roff”). Unfortunately, surviving documentation does not illustrate what requests were implemented at this time for C/A/T support; the

man page in Fourth Edition Unix (November 1973) does not feature a request list, unlike

Apart from typesetter-driven features, Unix Version 4 roffs added string definitions (.ds); made the escape character configurable (.ec); and enabled the user to write diagnostics to the standard error stream (.tm). Around 1974, empowered with multiple type sizes, italics, and a symbol font specially commissioned by Bell Labs from Graphic Systems, Kernighan and Lorinda Cherry implemented eqn for typesetting mathematics. In the same year, for Fifth Edition Unix, Ossanna combined and reimplemented the two roffs in C, using that language’s preprocessor to generate both from a single source tree.

Ossanna documented the syntax of the input language to the nroff and troff programs in the “Troff User’s Manual”, first published in 1976, with further revisions as late as 1992 by Kernighan. (The original version was entitled “Nroff/Troff User’s Manual”, which may partially explain why roff practitioners have tended to refer to it by its AT&T document identifier, “CSTR #54”.) Its final revision serves as the de facto specification of AT&T troff, and all subsequent implementors of roff systems have done so in its shadow.

A small and simple set of roff macros was first used for the manual pages of Unix Version 4 and persisted for two further releases, but the first macro package to be formally described and installed was ms by Michael Lesk in Version 6. He also wrote a manual, “Typing Documents on the Unix System”, describing ms and basic nroff/troff usage, updating it as the package accrued features. Sixth Edition additionally saw the debut of the tbl preprocessor for formatting tables, also by Lesk.

For Unix Version 7 (January 1979), McIlroy designed, implemented, and documented the man macro package, introducing most of the macros described in

today, and edited volume 1 of the Version 7 manual using it. Documents composed using ms featured in volume 2, edited by Kernighan.

Meanwhile, troff proved popular even at Unix sites that lacked a C/A/T device. Tom Ferrin of the University of California at San Francisco combined it with Allen Hershey’s popular vector fonts to produce vtroff, which translated troff’s output to the command language used by Versatec and Benson-Varian plotters.

Ossanna had passed away unexpectedly in 1977, and after the release of Version 7, with the C/A/T typesetter becoming supplanted by alternative devices such as the Mergenthaler Linotron 202, Kernighan undertook a revision and rewrite of troff to generalize its design. To implement this revised architecture, he developed the font and device description file formats and the page description language that remain in use today. He described these novelties in the article “A Typesetter-independent TROFF”, last revised in 1982, and like the troff manual itself, it is widely known by a shorthand, “CSTR #97”.

Kernighan’s innovations prepared troff well for the introduction of the Adobe PostScript language in 1982 and a vibrant market in laser printers with built-in interpreters for it. An output driver for PostScript, dpost, was swiftly developed. However, AT&T’s software licensing practices kept Ossanna’s troff, with its tight coupling to the C/A/T’s capabilities, in parallel distribution with device-independent troff throughout the 1980s. Today, however, all actively maintained troffs follow Kernighan’s device-independent design.

groff—a free roff from GNU

The most important free roff project historically has been groff, the GNU implementation of troff, developed by James Clark starting in 1989 and distributed under copyleft licenses, ensuring to all the availability of source code and the freedom to modify and redistribute it, properties unprecedented in roff systems to that point. groff rapidly attracted contributors, and has served as a replacement for almost all applications of AT&T troff (exceptions include mv, a macro package for preparation of viewgraphs and slides, and the ideal preprocessor, which produces diagrams from mathematical constraints). Beyond that, it has added numerous features; see

Since its inception and for at least the following three decades, it has been used by practically all GNU/Linux and BSD operating systems.

groff continues to be developed, is available for almost all operating systems in common use (along with several obscure ones), and is free. These factors make groff the de facto roff standard today.

Other free roffs

In 2007, Caldera/SCO and Sun Microsystems, having acquired rights to AT&T Documenter’s Workbench (DWB) troff (a descendant of the Bell Labs code), released it under a free but GPL-incompatible license. This implementation was made portable to modern POSIX systems, and adopted and enhanced first by Gunnar Ritter and then Carsten Kunze to produce

Heirloom Doctools troff

In July 2013, Ali Gholami Rudi announced

neatroff

a permissively licensed new implementation.

Another descendant of DWB troff is part of Plan 9 from User Space. Since 2021, this troff has been available under permissive terms.

Using roff

When you read a man page, often a roff is the program rendering it. Some roff implementations provide wrapper programs that make it easy to use the roff system from the shell’s command line. These can be specific to a macro package, like

or more general.

provides command-line options sparing the user from constructing the long, order-dependent pipelines familiar to AT&T troff users. Further, a heuristic program,

is available to infer from a document’s contents which groff arguments should be used to process it.

The roff pipeline

A typical roff document is prepared by running one or more processors in series, followed by a a formatter program and then an output driver (or “device postprocessor”). Commonly, these programs are structured into a pipeline; that is, each is run in sequence such that the output of one is taken as the input to the next, without passing through secondary storage. (On non-Unix systems, pipelines may have to be simulated with temporary files.)

$ preproc1  < input-file | preproc2 |  . . . | troff  [option]  . . . 
| output-driver

Once all preprocessors have run, they deliver pure roff language input to the formatter, which in turn generates a document in a page description language that is then interpreted by a postprocessor for viewing, printing, or further processing.

Each program interprets input in a language that is independent of the others; some are purely descriptive, as with

and roff output, and some permit the definition of macros, as with

and roff input. Most roff input files employ the macros of a document formatting package, intermixed with instructions for one or more preprocessors, and seasoned with escape sequences and requests from the roff language. Some documents are simpler still, since their formatting packages discourage direct use of roff requests; man pages are a prominent example. Many features of the roff language are seldom needed by users; only authors of macro packages require a substantial command of them.

Preprocessors

A roff preprocessor is a program that, directly or ultimately, generates output in the roff language. Typically, each preprocessor defines a language of its own that transforms its input into that for roff or another preprocessor. As an example of the latter, chem produces pic input. Preprocessors must consequently be run in an appropriate order;

handles this automatically for all preprocessors supplied by the GNU roff system.

Portions of the document written in preprocessor languages are usually bracketed by tokens that look like roff macro calls. roff preprocessor programs transform only the regions of the document intended for them. When a preprocessor language is used by a document, its corresponding program must process it before the input is seen by the formatter, or incorrect rendering is almost guaranteed.

GNU roff provides several preprocessors, including eqn, grn, pic, tbl, refer, and soelim. See

for a complete list. Other preprocessors for roff systems are known.

dformatdepicts data structures;
grapconstructs statistical charts; and
idealdraws diagrams using a constraint-based language.

Formatter programs

A roff formatter transforms roff language input into a single file in a page description language, described in

intended for processing by a selected device. This page description language is specialized in its parameters, but not its syntax, for the selected device; the format is device-independent, but not device-agnostic. The parameters the formatter uses to arrange the document are stored in device and font description files; see

AT&T Unix had two formatters— nroff for terminals, and troff for typesetters. Often, the name troff is used loosely to refer to both. When generalizing thus, groff documentation prefers the term “roff”. In GNU roff, the formatter program is always

Devices and output drivers

To a roff system, a device is a hardware interface like a printer, a text or graphical terminal, or a standardized file format that unrelated software can interpret. An output driver is a program that parses the output of troff and produces instructions specific to the device or file format it supports. An output driver might support multiple devices, particularly if they are similar.

The names of the devices and their driver programs are not standardized. Technological fashions evolve; the devices used for document preparation when AT&T troff was first written in the 1970s are no longer used in production environments. Device capabilities have tended to increase, improving resolution and font repertoire, and adding color output and hyperlinking. Further, to reduce file size and processing time, AT&T troff’s page description language placed low limits on the magnitudes of some quantities it could represent. Its PostScript output driver,

had a resolution of 720 units per inch; groff’s

uses 72,000.

roff programming

Documents using roff are normal text files interleaved with roff formatting elements. The roff language is powerful enough to support arbitrary computation and it supplies facilities that encourage extension. The primary such facility is macro definition; with this feature, macro packages have been developed that are tailored for particular applications.

Macro packages

Macro packages can have a much smaller vocabulary than roff itself; this trait combined with their domain-specific nature can make them easy to acquire and master. The macro definitions of a package are typically kept in a file called name**.tmac** (historically, **tmac.**name ). Find details on the naming and placement of macro packages in

A macro package anticipated for use in a document can be declared to the formatter by the command-line option -m; see

It can alternatively be specified within a document using the mso request of the groff language; see

Well-known macro packages include man for traditional man pages and mdoc for BSD-style manual pages. Macro packages for typesetting books, articles, and letters include ms (from “manuscript macros”), me (named by a system administrator from the first name of its creator, Eric Allman), mm (from “memorandum macros”), and mom, a punningly named package exercising many groff extensions. See

for more.

The roff formatting language

The roff language provides requests, escape sequences, macro definition facilities, string variables, registers for storage of numbers or dimensions, and control of execution flow. The theoretically minded will observe that a roff is not a mere markup language, but Turing-complete. It has storage (registers), it can perform tests (as in conditional expressions like “( [i] >= 1)”), its “** if **” and related requests alter the flow of control, and macro definition permits unbounded recursion.

Requests and escape sequences are instructions, predefined parts of the language, that perform formatting operations, interpolate stored material, or otherwise change the state of the parser. The user can define their own request-like elements by composing together text, requests, and escape sequences ad libitum. A document writer will not (usually) note any difference in usage for requests or macros; both are found on control lines. However, there is a distinction; requests take either a fixed number of arguments (sometimes zero), silently ignoring any excess, or consume the rest of the input line, whereas macros can take a variable number of arguments. Since arguments are separated by spaces, macros require a means of embedding a space in an argument; in other words, of quoting it. This then demands a mechanism of embedding the quoting character itself, in case it is needed literally in a macro argument. AT&T troff had complex rules involving the placement and repetition of the double quote to achieve both aims. groff cuts this knot by supporting a special character escape sequence for the neutral double quote, “** \dq]”, which never performs quoting in the typesetting language, but is simply a glyph, ‘"**’.

Escape sequences start with a backslash, “** *”. They can appear almost anywhere, even in the midst of text on a line, and implement various features, including the insertion of special characters with “** *xx***” or “** *xxx]”, break suppression at input line endings with “ 

303 - Linux cli command EVP_KDF-X942-CONCATssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KDF-X942-CONCATssl and provides detailed information about the command EVP_KDF-X942-CONCATssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KDF-X942-CONCATssl.

NAME 🖥️ EVP_KDF-X942-CONCATssl 🖥️

X942-CONCAT - The X942 Concat EVP_KDF implementation

DESCRIPTION

The EVP_KDF-X942-CONCAT algorithm is identical to EVP_KDF-X963. It is used for key agreement to derive a key using input such as a shared secret key and shared info.

Identity

“X942KDF_CONCAT” is the name for this implementation; it can be used with the EVP_KDF_fetch() function.

This is an alias for “X963KDF”.

See EVP_KDF-X963 (7) for a list of supported parameters and examples.

HISTORY

This functionality was added in OpenSSL 3.0.

COPYRIGHT

Copyright 2020-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

304 - Linux cli command iso-8859-15

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso-8859-15 and provides detailed information about the command iso-8859-15, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso-8859-15.

NAME 🖥️ iso-8859-15 🖥️

15 - ISO/IEC 8859-15 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-15 encodes the characters used in many West European languages and adds the Euro sign.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-15 characters

The following table displays the characters in ISO/IEC 8859-15 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-15 is also known as Latin-9 (or sometimes as Latin-0).

SEE ALSO

ascii(7), charsets(7), cp1252(7), iso_8859-1(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

305 - Linux cli command CREATE_GROUP

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_GROUP and provides detailed information about the command CREATE_GROUP, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_GROUP.

NAME 🖥️ CREATE_GROUP 🖥️

define a new database role

SYNOPSIS

CREATE GROUP name [ [ WITH ] option [ ... ] ]

where option can be:

      SUPERUSER | NOSUPERUSER
    | CREATEDB | NOCREATEDB
    | CREATEROLE | NOCREATEROLE
    | INHERIT | NOINHERIT
    | LOGIN | NOLOGIN
    | REPLICATION | NOREPLICATION
    | BYPASSRLS | NOBYPASSRLS
    | CONNECTION LIMIT connlimit
    | [ ENCRYPTED ] PASSWORD password | PASSWORD NULL
    | VALID UNTIL timestamp
    | IN ROLE role_name [, ...]
    | IN GROUP role_name [, ...]
    | ROLE role_name [, ...]
    | ADMIN role_name [, ...]
    | USER role_name [, ...]
    | SYSID uid

DESCRIPTION

CREATE GROUP is now an alias for CREATE ROLE (CREATE_ROLE(7)).

COMPATIBILITY

There is no CREATE GROUP statement in the SQL standard.

SEE ALSO

CREATE ROLE (CREATE_ROLE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

306 - Linux cli command CREATE_SCHEMA

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_SCHEMA and provides detailed information about the command CREATE_SCHEMA, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_SCHEMA.

NAME 🖥️ CREATE_SCHEMA 🖥️

define a new schema

SYNOPSIS

CREATE SCHEMA schema_name [ AUTHORIZATION role_specification ] [ schema_element [ ... ] ]
CREATE SCHEMA AUTHORIZATION role_specification [ schema_element [ ... ] ]
CREATE SCHEMA IF NOT EXISTS schema_name [ AUTHORIZATION role_specification ]
CREATE SCHEMA IF NOT EXISTS AUTHORIZATION role_specification

where role_specification can be:

    user_name
  | CURRENT_ROLE
  | CURRENT_USER
  | SESSION_USER

DESCRIPTION

CREATE SCHEMA enters a new schema into the current database. The schema name must be distinct from the name of any existing schema in the current database.

A schema is essentially a namespace: it contains named objects (tables, data types, functions, and operators) whose names can duplicate those of other objects existing in other schemas. Named objects are accessed either by “qualifying” their names with the schema name as a prefix, or by setting a search path that includes the desired schema(s). A CREATE command specifying an unqualified object name creates the object in the current schema (the one at the front of the search path, which can be determined with the function current_schema).

Optionally, CREATE SCHEMA can include subcommands to create objects within the new schema. The subcommands are treated essentially the same as separate commands issued after creating the schema, except that if the AUTHORIZATION clause is used, all the created objects will be owned by that user.

PARAMETERS

schema_name

The name of a schema to be created. If this is omitted, the user_name is used as the schema name. The name cannot begin with pg_, as such names are reserved for system schemas.

user_name

The role name of the user who will own the new schema. If omitted, defaults to the user executing the command. To create a schema owned by another role, you must be able to SET ROLE to that role.

schema_element

An SQL statement defining an object to be created within the schema. Currently, only CREATE TABLE, CREATE VIEW, CREATE INDEX, CREATE SEQUENCE, CREATE TRIGGER and GRANT are accepted as clauses within CREATE SCHEMA. Other kinds of objects may be created in separate commands after the schema is created.

IF NOT EXISTS

Do nothing (except issuing a notice) if a schema with the same name already exists. schema_element subcommands cannot be included when this option is used.

NOTES

To create a schema, the invoking user must have the CREATE privilege for the current database. (Of course, superusers bypass this check.)

EXAMPLES

Create a schema:

CREATE SCHEMA myschema;

Create a schema for user joe; the schema will also be named joe:

CREATE SCHEMA AUTHORIZATION joe;

Create a schema named test that will be owned by user joe, unless there already is a schema named test. (It does not matter whether joe owns the pre-existing schema.)

CREATE SCHEMA IF NOT EXISTS test AUTHORIZATION joe;

Create a schema and create a table and view within it:

CREATE SCHEMA hollywood CREATE TABLE films (title text, release date, awards text[]) CREATE VIEW winners AS SELECT title, release FROM films WHERE awards IS NOT NULL;

Notice that the individual subcommands do not end with semicolons.

The following is an equivalent way of accomplishing the same result:

CREATE SCHEMA hollywood; CREATE TABLE hollywood.films (title text, release date, awards text[]); CREATE VIEW hollywood.winners AS SELECT title, release FROM hollywood.films WHERE awards IS NOT NULL;

COMPATIBILITY

The SQL standard allows a DEFAULT CHARACTER SET clause in CREATE SCHEMA, as well as more subcommand types than are presently accepted by PostgreSQL.

The SQL standard specifies that the subcommands in CREATE SCHEMA can appear in any order. The present PostgreSQL implementation does not handle all cases of forward references in subcommands; it might sometimes be necessary to reorder the subcommands in order to avoid forward references.

According to the SQL standard, the owner of a schema always owns all objects within it. PostgreSQL allows schemas to contain objects owned by users other than the schema owner. This can happen only if the schema owner grants the CREATE privilege on their schema to someone else, or a superuser chooses to create objects in it.

The IF NOT EXISTS option is a PostgreSQL extension.

SEE ALSO

ALTER SCHEMA (ALTER_SCHEMA(7)), DROP SCHEMA (DROP_SCHEMA(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

307 - Linux cli command EVP_ASYM_CIPHER-SM2ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_ASYM_CIPHER-SM2ssl and provides detailed information about the command EVP_ASYM_CIPHER-SM2ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_ASYM_CIPHER-SM2ssl.

NAME 🖥️ EVP_ASYM_CIPHER-SM2ssl 🖥️

SM2 - SM2 Asymmetric Cipher algorithm support

DESCRIPTION

Asymmetric Cipher support for the SM2 key type.

SM2 Asymmetric Cipher parameters

“digest” (OSSL_ASYM_CIPHER_PARAM_DIGEST) <UTF8 string>

“digest-props” (OSSL_ASYM_CIPHER_PARAM_DIGEST_PROPS) <UTF8 string>

See “Asymmetric Cipher Parameters” in provider-asym_cipher (7).

SEE ALSO

EVP_PKEY-SM2 (7), EVP_PKEY (3), provider-asym_cipher (7), provider-keymgmt (7), OSSL_PROVIDER-default (7)

COPYRIGHT

Copyright 2020 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

308 - Linux cli command TRUNCATE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command TRUNCATE and provides detailed information about the command TRUNCATE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the TRUNCATE.

NAME 🖥️ TRUNCATE 🖥️

empty a table or set of tables

SYNOPSIS

TRUNCATE [ TABLE ] [ ONLY ] name [ * ] [, ... ]
    [ RESTART IDENTITY | CONTINUE IDENTITY ] [ CASCADE | RESTRICT ]

DESCRIPTION

TRUNCATE quickly removes all rows from a set of tables. It has the same effect as an unqualified DELETE on each table, but since it does not actually scan the tables it is faster. Furthermore, it reclaims disk space immediately, rather than requiring a subsequent VACUUM operation. This is most useful on large tables.

PARAMETERS

name

The name (optionally schema-qualified) of a table to truncate. If ONLY is specified before the table name, only that table is truncated. If ONLY is not specified, the table and all its descendant tables (if any) are truncated. Optionally, * can be specified after the table name to explicitly indicate that descendant tables are included.

RESTART IDENTITY

Automatically restart sequences owned by columns of the truncated table(s).

CONTINUE IDENTITY

Do not change the values of sequences. This is the default.

CASCADE

Automatically truncate all tables that have foreign-key references to any of the named tables, or to any tables added to the group due to CASCADE.

RESTRICT

Refuse to truncate if any of the tables have foreign-key references from tables that are not listed in the command. This is the default.

NOTES

You must have the TRUNCATE privilege on a table to truncate it.

TRUNCATE acquires an ACCESS EXCLUSIVE lock on each table it operates on, which blocks all other concurrent operations on the table. When RESTART IDENTITY is specified, any sequences that are to be restarted are likewise locked exclusively. If concurrent access to a table is required, then the DELETE command should be used instead.

TRUNCATE cannot be used on a table that has foreign-key references from other tables, unless all such tables are also truncated in the same command. Checking validity in such cases would require table scans, and the whole point is not to do one. The CASCADE option can be used to automatically include all dependent tables — but be very careful when using this option, or else you might lose data you did not intend to! Note in particular that when the table to be truncated is a partition, siblings partitions are left untouched, but cascading occurs to all referencing tables and all their partitions with no distinction.

TRUNCATE will not fire any ON DELETE triggers that might exist for the tables. But it will fire ON TRUNCATE triggers. If ON TRUNCATE triggers are defined for any of the tables, then all BEFORE TRUNCATE triggers are fired before any truncation happens, and all AFTER TRUNCATE triggers are fired after the last truncation is performed and any sequences are reset. The triggers will fire in the order that the tables are to be processed (first those listed in the command, and then any that were added due to cascading).

TRUNCATE is not MVCC-safe. After truncation, the table will appear empty to concurrent transactions, if they are using a snapshot taken before the truncation occurred. See Section 13.6 for more details.

TRUNCATE is transaction-safe with respect to the data in the tables: the truncation will be safely rolled back if the surrounding transaction does not commit.

When RESTART IDENTITY is specified, the implied ALTER SEQUENCE RESTART operations are also done transactionally; that is, they will be rolled back if the surrounding transaction does not commit. Be aware that if any additional sequence operations are done on the restarted sequences before the transaction rolls back, the effects of these operations on the sequences will be rolled back, but not their effects on currval(); that is, after the transaction currval() will continue to reflect the last sequence value obtained inside the failed transaction, even though the sequence itself may no longer be consistent with that. This is similar to the usual behavior of currval() after a failed transaction.

TRUNCATE can be used for foreign tables if supported by the foreign data wrapper, for instance, see postgres_fdw.

EXAMPLES

Truncate the tables bigtable and fattable:

TRUNCATE bigtable, fattable;

The same, and also reset any associated sequence generators:

TRUNCATE bigtable, fattable RESTART IDENTITY;

Truncate the table othertable, and cascade to any tables that reference othertable via foreign-key constraints:

TRUNCATE othertable CASCADE;

COMPATIBILITY

The SQL:2008 standard includes a TRUNCATE command with the syntax TRUNCATE TABLE tablename. The clauses CONTINUE IDENTITY/RESTART IDENTITY also appear in that standard, but have slightly different though related meanings. Some of the concurrency behavior of this command is left implementation-defined by the standard, so the above notes should be considered and compared with other implementations if necessary.

SEE ALSO

DELETE(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

309 - Linux cli command DROP_POLICY

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_POLICY and provides detailed information about the command DROP_POLICY, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_POLICY.

NAME 🖥️ DROP_POLICY 🖥️

remove a row-level security policy from a table

SYNOPSIS

DROP POLICY [ IF EXISTS ] name ON table_name [ CASCADE | RESTRICT ]

DESCRIPTION

DROP POLICY removes the specified policy from the table. Note that if the last policy is removed for a table and the table still has row-level security enabled via ALTER TABLE, then the default-deny policy will be used. ALTER TABLE … DISABLE ROW LEVEL SECURITY can be used to disable row-level security for a table, whether policies for the table exist or not.

PARAMETERS

IF EXISTS

Do not throw an error if the policy does not exist. A notice is issued in this case.

name

The name of the policy to drop.

table_name

The name (optionally schema-qualified) of the table that the policy is on.

CASCADE
RESTRICT

These key words do not have any effect, since there are no dependencies on policies.

EXAMPLES

To drop the policy called p1 on the table named my_table:

DROP POLICY p1 ON my_table;

COMPATIBILITY

DROP POLICY is a PostgreSQL extension.

SEE ALSO

CREATE POLICY (CREATE_POLICY(7)), ALTER POLICY (ALTER_POLICY(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

310 - Linux cli command openssl-threadsssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command openssl-threadsssl and provides detailed information about the command openssl-threadsssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the openssl-threadsssl.

NAME 🖥️ openssl-threadsssl 🖥️

threads - Overview of thread safety in OpenSSL

DESCRIPTION

In this man page, we use the term thread-safe to indicate that an object or function can be used by multiple threads at the same time.

OpenSSL can be built with or without threads support. The most important use of this support is so that OpenSSL itself can use a single consistent API, as shown in “EXAMPLES” in CRYPTO_THREAD_run_once (3). Multi-platform applications can also use this API.

In particular, being configured for threads support does not imply that all OpenSSL objects are thread-safe. To emphasize: most objects are not safe for simultaneous use. Exceptions to this should be documented on the specific manual pages, and some general high-level guidance is given here.

One major use of the OpenSSL thread API is to implement reference counting. Many objects within OpenSSL are reference-counted, so resources are not released, until the last reference is removed. References are often increased automatically (such as when an X509 certificate object is added into an X509_STORE trust store). There is often an object**_up_ref**() function that can be used to increase the reference count. Failure to match object**_up_ref**() calls with the right number of object**_free**() calls is a common source of memory leaks when a program exits.

Many objects have set and get API’s to set attributes in the object. A set0 passes ownership from the caller to the object and a get0 returns a pointer but the attribute ownership remains with the object and a reference to it is returned. A set1 or get1 function does not change the ownership, but instead updates the attribute’s reference count so that the object is shared between the caller and the object; the caller must free the returned attribute when finished. Functions that involve attributes that have reference counts themselves, but are named with just set or get are historical; and the documentation must state how the references are handled. Get methods are often thread-safe as long as the ownership requirements are met and shared objects are not modified. Set methods, or modifying shared objects, are generally not thread-safe as discussed below.

Objects are thread-safe as long as the API’s being invoked don’t modify the object; in this case the parameter is usually marked in the API as const. Not all parameters are marked this way. Note that a const declaration does not mean immutable; for example X509_cmp (3) takes pointers to const objects, but the implementation uses a C cast to remove that so it can lock objects, generate and cache a DER encoding, and so on.

Another instance of thread-safety is when updates to an object’s internal state, such as cached values, are done with locks. One example of this is the reference counting API’s described above.

In all cases, however, it is generally not safe for one thread to mutate an object, such as setting elements of a private or public key, while another thread is using that object, such as verifying a signature.

The same API’s can usually be used simultaneously on different objects without interference. For example, two threads can calculate a signature using two different EVP_PKEY_CTX objects.

For implicit global state or singletons, thread-safety depends on the facility. The CRYPTO_secure_malloc (3) and related API’s have their own lock, while CRYPTO_malloc (3) assumes the underlying platform allocation will do any necessary locking. Some API’s, such as NCONF_load (3) and related do no locking at all; this can be considered a bug.

A separate, although related, issue is modifying “factory” objects when other objects have been created from that. For example, an SSL_CTX object created by SSL_CTX_new (3) is used to create per-connection SSL objects by calling SSL_new (3). In this specific case, and probably for factory methods in general, it is not safe to modify the factory object after it has been used to create other objects.

SEE ALSO

CRYPTO_THREAD_run_once (3), local system threads documentation.

BUGS

This page is admittedly very incomplete.

COPYRIGHT

Copyright 2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

311 - Linux cli command ascii

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ascii and provides detailed information about the command ascii, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ascii.

NAME 🖥️ ascii 🖥️

ASCII character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

ASCII is the American Standard Code for Information Interchange. It is a 7-bit code. Many 8-bit codes (e.g., ISO/IEC 8859-1) contain ASCII as their lower half. The international counterpart of ASCII is known as ISO/IEC 646-IRV.

The following table contains the 128 ASCII characters.

C program '\X' escapes are noted.

TABLE

Tables

For convenience, below are more compact tables in hex and decimal.

   2 3 4 5 6 7       30 40 50 60 70 80 90 100 110 120
 -------------      ---------------------------------
0:   0 @ P ` p     0:    (  2  <  F  P  Z  d   n   x
1: ! 1 A Q a q     1:    )  3  =  G  Q  [  e   o   y
2: " 2 B R b r     2:    *  4  >  H  R  \  f   p   z
3: # 3 C S c s     3: !  +  5  ?  I  S  ]  g   q   {
4: $ 4 D T d t     4: "  ,  6  @  J  T  ^  h   r   |
5: % 5 E U e u     5: #  -  7  A  K  U  _  i   s   }
6: & 6 F V f v     6: $  .  8  B  L  V  `  j   t   ~
7: ' 7 G W g w     7: %  /  9  C  M  W  a  k   u  DEL
8: ( 8 H X h x     8: &  0  :  D  N  X  b  l   v
9: ) 9 I Y i y     9: '  1  ;  E  O  Y  c  m   w
A: * : J Z j z
B: + ; K [ k {
C: , < L \ l |
D: - = M ] m }
E: . > N ^ n ~
F: / ? O _ o DEL

NOTES

History

/etc/ascii (VII) appears in the UNIX Programmer’s Manual.

On older terminals, the underscore code is displayed as a left arrow, called backarrow, the caret is displayed as an up-arrow and the vertical bar has a hole in the middle.

Uppercase and lowercase characters differ by just one bit and the ASCII character 2 differs from the double quote by just one bit, too. That made it much easier to encode characters mechanically or with a non-microcontroller-based electronic keyboard and that pairing was found on old teletypes.

The ASCII standard was published by the United States of America Standards Institute (USASI) in 1968.

SEE ALSO

charsets(7), iso_8859-1(7), iso_8859-2(7), iso_8859-3(7), iso_8859-4(7), iso_8859-5(7), iso_8859-6(7), iso_8859-7(7), iso_8859-8(7), iso_8859-9(7), iso_8859-10(7), iso_8859-11(7), iso_8859-13(7), iso_8859-14(7), iso_8859-15(7), iso_8859-16(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

312 - Linux cli command apt-patterns

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command apt-patterns and provides detailed information about the command apt-patterns, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the apt-patterns.

NAME 🖥️ apt-patterns 🖥️

patterns - Syntax and semantics of apt search patterns

DESCRIPTION

Starting with version 2.0, APT provides support for patterns, which can be used to query the apt cache for packages.

LOGIC PATTERNS

These patterns provide the basic means to combine other patterns into more complex expressions, as well as ?true and ?false patterns.

?and(PATTERN, PATTERN, …), PATTERN PATTERN …

Selects objects where all specified patterns match.

?false, ~F

Selects nothing.

?not(PATTERN), !PATTERN

Selects objects where PATTERN does not match.

?or(PATTERN, PATTERN, …), PATTERN | PATTERN | …

Selects objects where at least one of the specified patterns match.

?true, ~T

Selects all objects.

(PATTERN)

Selects the same as PATTERN, can be used to work around precedence, for example, (~ramd64|~ri386)~nfoo

NARROWING PATTERNS

?all-versions(PATTERN)

Selects packages where all versions match PATTERN. When matching versions instead, same as PATTERN.

?any-version(PATTERN)

Selects any version where the pattern matches on the version.

For example, while ?and(?version(1),?version(2)) matches a package which has one version containing 1 and one version containing 2, ?any-version(?and(?version(1),?version(2))) restricts the ?and to act on the same version.

?narrow(PATTERN…)

Selects any version matching all PATTERNs, short for ?any-version(?and(PATTERN…)).

PACKAGE PATTERNS

These patterns select specific packages.

?architecture(WILDCARD), ~rWILDCARD

Selects packages matching the specified architecture, which may contain wildcards using any.

?automatic, ~M

Selects packages that were installed automatically.

?broken, ~b

Selects packages that have broken dependencies.

?config-files, ~c

Selects packages that are not fully installed, but have solely residual configuration files left.

?essential, ~E

Selects packages that have Essential: yes set in their control file.

?exact-name(NAME)

Selects packages with the exact specified name.

?garbage, ~g

Selects packages that can be removed automatically.

?installed, ~i

Selects packages that are currently installed. Since version 2.5.4, narrowing this pattern (see narrowing patterns above) makes it only match installed versions (see version patterns below).

?name(REGEX), ~nREGEX

Selects packages where the name matches the given regular expression.

?obsolete, ~o

Selects packages that no longer exist in repositories.

?phasing

Selects packages that will be kept back in upgrades due to phasing.

?upgradable, ~U

Selects packages that can be upgraded (have a newer candidate).

?virtual, ~v

Selects all virtual packages; that is packages without a version. These exist when they are referenced somewhere in the archive, for example because something depends on that name.

VERSION PATTERNS

These patterns select specific versions of a package.

?archive(REGEX), ~AREGEX

Selects versions that come from the archive that matches the specified regular expression. Archive, here, means the values after a= in apt-cache policy.

?codename(REGEX)

Selects versions that come from the codename that matches the specified regular expression. Codename, here, means the values after n= in apt-cache policy.

?installed, ~i

Selects package versions that are currently installed. Versions prior to 2.5.4 only matched at the package level, hence ?any-version(?installed?version(2.0))matched even if 2.0 was not installed, but another version was.

?origin(REGEX), ~OREGEX

Selects versions that come from the origin that matches the specified regular expression. Origin, here, means the values after o= in apt-cache policy.

?section(REGEX), ~sREGEX

Selects versions where the section matches the specified regular expression.

?source-package(REGEX), ~eREGEX

Selects versions where the source package name matches the specified regular expression.

?source-version(REGEX)

Selects versions where the source package version matches the specified regular expression.

?version(REGEX), ~VREGEX

Selects versions where the version string matches the specified regular expression.

?priority(NAME), ~pNAME

Selects versions where the Priority string equals the given name.

?security

Selects packages that are a security update or succeed a security update.

PACKAGE RELATIONSHIP PATTERNS

These patterns match specific package versions that depend/conflict with some other packages.

?depends(PATTERN), ~DPATTERN, ?pre-depends(PATTERN), ~DPre-Depends:PATTERN, ?suggests(PATTERN), ~DSuggests:PATTERN, ?conflicts(PATTERN), ~DConflicts:PATTERN, ?replaces(PATTERN), ~DReplaces:PATTERN, ?obsoletes(PATTERN), ~DObsoletes:PATTERN, ?breaks(PATTERN), ~DBreaks:PATTERN, ?enhances(PATTERN), ~DEnhances:PATTERN

Selects versions depending/pre-depending/suggesting/conflicting/etc on/with/ packages matching PATTERN.

?reverse-depType(PATTERN), ~RDepType:PATTERN

Opposite of ?depends and friends - selects all packages that have reverse-dependencies (versions) matching PATTERN.

depType is one of the dependency types such as depends, so that we dont have to repeat the entire list from the first paragraph here.

EXAMPLES

apt remove ?garbage

Remove all packages that are automatically installed and no longer needed - same as apt autoremove

apt purge ?config-files

Purge all packages that only have configuration files left

apt list ~i !~M (~slibs|~sperl|~spython)

List all manually-installed packages in sections matching libs, perl, or python.

MIGRATING FROM APTITUDE

Patterns in apt are heavily inspired by patterns in aptitude, but with some tweaks:

·

Syntax is uniform: If there is an opening parenthesis after a term, it is always assumed to be the beginning of an argument list.

In aptitude, a syntactic form “?foo(bar)” could mean “?and(?foo,bar)” if foo does not take an argument. In APT, this will cause an error.

·

Not all patterns are supported.

·

Some additional patterns are available, for example, for finding gstreamer codecs.

·

Escaping terms with ~ is not supported.

·

A trailing comma is allowed in argument lists

·

?narrow accepts infinite arguments

·

foo cannot be used as a shortform for ?name(foo), as this can cause typos to go unnoticed: Consider ?and(…,~poptional): this requires the package to have required priority, but if you do not type the ~, it would require the package name to contain poptional.

·

Dependency types for ~D and related operators need to be specified in the canonical case.

SEE ALSO

apt-get(8), apt(8)

BUGS

APT bug page[1]. If you wish to report a bug in APT, please see /usr/share/doc/debian/bug-reporting.txt or the reportbug(1) command.

AUTHOR

APT was written by the APT team <[email protected]>.

AUTHORS

Jason Gunthorpe

APT team

NOTES

APT bug page

https://bugs.debian.org/src:apt

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

313 - Linux cli command hwdb

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command hwdb and provides detailed information about the command hwdb, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the hwdb.

NAME 🖥️ hwdb 🖥️

Hardware Database

DESCRIPTION

The hardware database is a key-value store for associating modalias-like keys to udev-property-like values. It is used primarily by udev to add the relevant properties to matching devices, but it can also be queried directly.

HARDWARE DATABASE FILES

The hwdb files are read from the files located in the system hwdb directory /usr/lib/udev/hwdb.d and the local administration directory /etc/udev/hwdb.d. All hwdb files are collectively sorted and processed in lexical order, regardless of the directories in which they live. However, files with identical filenames replace each other. Files in /etc/ have the highest priority and take precedence over files with the same name in /usr/lib/. This can be used to override a system-supplied hwdb file with a local file if needed; a symlink in /etc/ with the same name as a hwdb file in /usr/lib/, pointing to /dev/null, disables that hwdb file entirely. hwdb files must have the extension .hwdb; other extensions are ignored.

Each hwdb file contains data records consisting of matches and associated key-value pairs. Every record in the hwdb starts with one or more match strings, specifying a shell glob to compare the lookup string against. Multiple match lines are specified in consecutive lines. Every match line is compared individually, and they are combined by OR. Every match line must start at the first character of the line.

Match patterns consist of literal characters, and shell-style wildcards:

·

Asterisk “*” matches any number of characters

·

Question mark “?” matches a single character

·

Character list “[chars]” matches one of the characters chars listed between “[” and “]”. A range may be specified as with a dash as “[first-last]”. The match may be inverted with a caret “[^…]”.

The match lines are followed by one or more key-value pair lines, which are recognized by a leading space character. The key name and value are separated by “=”. An empty line signifies the end of a record. Lines beginning with “#” are ignored.

In case multiple records match a given lookup string, the key-value pairs from all records are combined. If a key is specified multiple times, the value from the record with the highest priority is used (each key can have only a single value). The priority is higher when the record is in a file that sorts later lexicographically, and in case of records in the same file, later records have higher priority.

The content of all hwdb files is read by systemd-hwdb(8) and compiled to a binary database located at /etc/udev/hwdb.bin, or alternatively /usr/lib/udev/hwdb.bin if you want ship the compiled database in an immutable image. During runtime, only the binary database is used.

EXAMPLES

Example 1. General syntax of hwdb files

/usr/lib/udev/hwdb.d/example.hwdb

# Comments can be placed before any records. This is a good spot
# to describe what that file is used for, what kind of properties
# it defines, and the ordering convention.

# A record with three matches and one property
mouse:*:name:*Trackball*:*
mouse:*:name:*trackball*:*
mouse:*:name:*TrackBall*:*
 ID_INPUT_TRACKBALL=1

# The rule above could be also be written in a form that
# matches Tb, tb, TB, tB:
mouse:*:name:*[tT]rack[bB]all*:*
 ID_INPUT_TRACKBALL=1

# A record with a single match and five properties
mouse:usb:v046dp4041:name:Logitech MX Master:*
 MOUSE_DPI=1000@166
 MOUSE_WHEEL_CLICK_ANGLE=15
 MOUSE_WHEEL_CLICK_ANGLE_HORIZONTAL=26
 MOUSE_WHEEL_CLICK_COUNT=24
 MOUSE_WHEEL_CLICK_COUNT_HORIZONTAL=14

Example 2. Overriding of properties

/usr/lib/udev/hwdb.d/60-keyboard.hwdb

evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pn*:*
 KEYBOARD_KEY_a1=help
 KEYBOARD_KEY_a2=setup
 KEYBOARD_KEY_a3=battery

# Match vendor name "Acer" and any product name starting with "X123"
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer:pnX123*:*
 KEYBOARD_KEY_a2=wlan

# /etc/udev/hwdb.d/70-keyboard.hwdb
# disable wlan key on all at keyboards
evdev:atkbd:*
 KEYBOARD_KEY_a2=reserved
 PROPERTY_WITH_SPACES=some string

If the hwdb consists of those two files, a keyboard with the lookup string “evdev:atkbd:dmi:bvnAcer:bvr:bdXXXXX:bd08/05/2010:svnAcer:pnX123:” will match all three records, and end up with the following properties:

KEYBOARD_KEY_a1=help KEYBOARD_KEY_a2=reserved KEYBOARD_KEY_a3=battery PROPERTY_WITH_SPACES=some string

SEE ALSO

systemd-hwdb(8)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

314 - Linux cli command EVP_RAND-HASH-DRBGssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_RAND-HASH-DRBGssl and provides detailed information about the command EVP_RAND-HASH-DRBGssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_RAND-HASH-DRBGssl.

NAME 🖥️ EVP_RAND-HASH-DRBGssl 🖥️

HASH-DRBG - The HASH DRBG EVP_RAND implementation

DESCRIPTION

Support for the hash deterministic random bit generator through the EVP_RAND API.

Identity

“HASH-DRBG” is the name for this implementation; it can be used with the EVP_RAND_fetch() function.

Supported parameters

The supported parameters are:

“state” (OSSL_RAND_PARAM_STATE) <integer>

“strength” (OSSL_RAND_PARAM_STRENGTH) <unsigned integer>

“max_request” (OSSL_RAND_PARAM_MAX_REQUEST) <unsigned integer>

“reseed_requests” (OSSL_DRBG_PARAM_RESEED_REQUESTS) <unsigned integer>

“reseed_time_interval” (OSSL_DRBG_PARAM_RESEED_TIME_INTERVAL) <integer>

“min_entropylen” (OSSL_DRBG_PARAM_MIN_ENTROPYLEN) <unsigned integer>

“max_entropylen” (OSSL_DRBG_PARAM_MAX_ENTROPYLEN) <unsigned integer>

“min_noncelen” (OSSL_DRBG_PARAM_MIN_NONCELEN) <unsigned integer>

“max_noncelen” (OSSL_DRBG_PARAM_MAX_NONCELEN) <unsigned integer>

“max_perslen” (OSSL_DRBG_PARAM_MAX_PERSLEN) <unsigned integer>

“max_adinlen” (OSSL_DRBG_PARAM_MAX_ADINLEN) <unsigned integer>

“reseed_counter” (OSSL_DRBG_PARAM_RESEED_COUNTER) <unsigned integer>

“properties” (OSSL_DRBG_PARAM_PROPERTIES) <UTF8 string>

“digest” (OSSL_DRBG_PARAM_DIGEST) <UTF8 string>

These parameters work as described in “PARAMETERS” in EVP_RAND (3).

NOTES

When the FIPS provider is installed using the -no_drbg_truncated_digests option to fipsinstall, only these digests are permitted (as per FIPS 140-3 IG D.R <https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf>):

SHA-1

SHA2-256

SHA2-512

SHA3-256

SHA3-512

A context for HASH DRBG can be obtained by calling:

EVP_RAND *rand = EVP_RAND_fetch(NULL, “HASH-DRBG”, NULL); EVP_RAND_CTX *rctx = EVP_RAND_CTX_new(rand, NULL);

EXAMPLES

EVP_RAND *rand; EVP_RAND_CTX *rctx; unsigned char bytes[100]; OSSL_PARAM params[2], *p = params; unsigned int strength = 128; rand = EVP_RAND_fetch(NULL, “HASH-DRBG”, NULL); rctx = EVP_RAND_CTX_new(rand, NULL); EVP_RAND_free(rand); *p++ = OSSL_PARAM_construct_utf8_string(OSSL_DRBG_PARAM_DIGEST, SN_sha512, 0); *p = OSSL_PARAM_construct_end(); EVP_RAND_instantiate(rctx, strength, 0, NULL, 0, params); EVP_RAND_generate(rctx, bytes, sizeof(bytes), strength, 0, NULL, 0); EVP_RAND_CTX_free(rctx);

CONFORMING TO

NIST SP 800-90A and SP 800-90B

SEE ALSO

EVP_RAND (3), “PARAMETERS” in EVP_RAND (3), openssl-fipsinstall (1)

HISTORY

OpenSSL 3.1.1 introduced the -no_drbg_truncated_digests option to fipsinstall which restricts the permitted digests when using the FIPS provider in a complaint manner. For details refer to FIPS 140-3 IG D.R <https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf>.

COPYRIGHT

Copyright 2020-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

315 - Linux cli command iso-8859-5

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso-8859-5 and provides detailed information about the command iso-8859-5, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso-8859-5.

NAME 🖥️ iso-8859-5 🖥️

5 - ISO/IEC 8859-5 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-5 encodes the Cyrillic characters used in many East European languages.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-5 characters

The following table displays the characters in ISO/IEC 8859-5 that are printable and unlisted in the ascii(7) manual page.

TABLE

SEE ALSO

ascii(7), charsets(7), cp1251(7), koi8-r(7), koi8-u(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

316 - Linux cli command systemd.image-policy

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command systemd.image-policy and provides detailed information about the command systemd.image-policy, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the systemd.image-policy.

NAME 🖥️ systemd.image-policy 🖥️

policy - Disk Image Dissection Policy

DESCRIPTION

In systemd, whenever a disk image (DDI) implementing the Discoverable Partitions Specification[1] is activated, a policy may be specified controlling which partitions to mount and what kind of cryptographic protection to require. Such a disk image dissection policy is a string that contains per-partition-type rules, separated by colons (":"). The individual rules consist of a partition identifier, an equal sign ("="), and one or more flags which may be set per partition. If multiple flags are specified per partition they are separated by a plus sign ("+").

The partition identifiers currently defined are: root, usr, home, srv, esp, xbootldr, swap, root-verity, root-verity-sig, usr-verity, usr-verity-sig, tmp, var. These identifiers match the relevant partition types in the Discoverable Partitions Specification, but are agnostic to CPU architectures. If the partition identifier is left empty it defines the default policy for partitions defined in the Discoverable Partitions Specification for which no policy flags are explicitly listed in the policy string.

The following partition policy flags are defined that dictate the existence/absence, the use, and the protection level of partitions:

·

unprotected for partitions that shall exist and be used, but shall come without cryptographic protection, lacking both Verity authentication and LUKS encryption.

·

verity for partitions that shall exist and be used, with Verity authentication. (Note: if a DDI image carries a data partition, along with a Verity partition and a signature partition for it, and only the verity flag is set (signed is not), then the image will be set up with Verity, but the signature data will not be used. Or in other words: any DDI with a set of partitions that qualify for signature also implicitly qualifies for verity, and in fact also unprotected).

·

signed for partitions that shall exist and be used, with Verity authentication, which are also accompanied by a PKCS#7 signature of the Verity root hash.

·

encrypted for partitions which shall exist and be used and are encrypted with LUKS.

·

unused for partitions that shall exist but shall not be used.

·

absent for partitions that shall not exist on the image.

By setting a combination of the flags above, alternatives can be declared. For example the combination “unused+absent” means: the partition may exist (in which case it shall not be used) or may be absent. The combination of “unprotected+verity+signed+encrypted+unused+absent” may be specified via the special shortcut “open”, and indicates that the partition may exist or may be absent, but if it exists is used, regardless of the protection level.

As special rule: if none of the flags above are set for a listed partition identifier, the default policy of open is implied, i.e. setting none of these flags listed above means effectively all flags listed above will be set.

The following partition policy flags are defined that dictate the state of specific GPT partition flags:

·

read-only-off, read-only-on to require that the partitions have the read-only partition flag off or on.

·

growfs-off, growfs-on to require that the partitions have the growfs partition flag off or on.

If both read-only-off and read-only-on are set for a partition, then the state of the read-only flag on the partition is not dictated by the policy. Setting neither flag is equivalent to setting both, i.e. setting neither of these two flags means effectively both will be set. A similar logic applies to growfs-off/growfs-on.

If partitions are not listed within an image policy string, the default policy flags are applied (configurable via an empty partition identifier, see above). If no default policy flags are configured in the policy string, it is implied to be “absent+unused”, except for the Verity partition and their signature partitions where the policy is automatically derived from minimal protection level of the data partition they protect, as encoded in the policy.

SPECIAL POLICIES

The special image policy string “*” is short for “use everything”, i.e. is equivalent to:

=verity+signed+encrypted+unprotected+unused+absent

The special image policy string “-” is short for “use nothing”, i.e. is equivalent to:

=unused+absent

The special image policy string “~” is short for “everything must be absent”, i.e. is equivalent to:

=absent

USE

Most systemd components that support operating with disk images support a –image-policy= command line option to specify the image policy to use, and default to relatively open policies (typically the “*” policy, as described above), under the assumption that trust in disk images is established before the images are passed to the program in question.

For the host image itself systemd-gpt-auto-generator(8) is responsible for processing the GPT partition table and making use of the included discoverable partitions. It accepts an image policy via the kernel command line option systemd.image-policy=.

Note that image policies do not dictate how the components will mount and use disk images — they only dictate which parts to avoid and which protection level and arrangement to require while mounting/using them. For example, systemd-sysext(8) only cares for the /usr/ and /opt/ trees inside a disk image, and thus ignores any /home/ partitions (and similar) in all cases, which might be included in the image, regardless whether the configured image policy would allow access to it or not. Similar, systemd-nspawn(1) is not going to make use of any discovered swap device, regardless if the policy would allow that or not.

Use the image-policy command of the systemd-analyze(8) tool to analyze image policy strings, and determine what a specific policy string means for a specific partition.

EXAMPLES

The following image policy string dictates one read-only Verity-enabled /usr/ partition must exist, plus encrypted root and swap partitions. All other partitions are ignored:

usr=verity+read-only-on:root=encrypted:swap=encrypted

The following image policy string dictates an encrypted, writable root file system, and optional /srv/ file system that must be encrypted if it exists and no swap partition may exist:

root=encrypted+read-only-off:srv=encrypted+absent:swap=absent

The following image policy string dictates a single root partition that may be encrypted, but doesnt have to be, and ignores swap partitions, and uses all other partitions if they are available, possibly with encryption.

root=unprotected+encrypted:swap=absent+unused:=unprotected+encrypted+absent

SEE ALSO

systemd(1), systemd-dissect(1), systemd-gpt-auto-generator(8), systemd-sysext(8), systemd-analyze(8)

NOTES

Discoverable Partitions Specification

https://uapi-group.org/specifications/specs/discoverable_partitions_specification

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

317 - Linux cli command man

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command man and provides detailed information about the command man, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the man.
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

318 - Linux cli command provider-keyexchssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command provider-keyexchssl and provides detailed information about the command provider-keyexchssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the provider-keyexchssl.

NAME 🖥️ provider-keyexchssl 🖥️

keyexch - The keyexch library <-> provider functions

SYNOPSIS

#include <openssl/core_dispatch.h> #include <openssl/core_names.h> /* * None of these are actual functions, but are displayed like this for * the function signatures for functions that are offered as function * pointers in OSSL_DISPATCH arrays. */ /* Context management */ void *OSSL_FUNC_keyexch_newctx(void *provctx); void OSSL_FUNC_keyexch_freectx(void *ctx); void *OSSL_FUNC_keyexch_dupctx(void *ctx); /* Shared secret derivation */ int OSSL_FUNC_keyexch_init(void *ctx, void *provkey, const OSSL_PARAM params[]); int OSSL_FUNC_keyexch_set_peer(void *ctx, void *provkey); int OSSL_FUNC_keyexch_derive(void *ctx, unsigned char *secret, size_t *secretlen, size_t outlen); /* Key Exchange parameters */ int OSSL_FUNC_keyexch_set_ctx_params(void *ctx, const OSSL_PARAM params[]); const OSSL_PARAM *OSSL_FUNC_keyexch_settable_ctx_params(void *ctx, void *provctx); int OSSL_FUNC_keyexch_get_ctx_params(void *ctx, OSSL_PARAM params[]); const OSSL_PARAM *OSSL_FUNC_keyexch_gettable_ctx_params(void *ctx, void *provctx);

DESCRIPTION

This documentation is primarily aimed at provider authors. See provider (7) for further information.

The key exchange (OSSL_OP_KEYEXCH) operation enables providers to implement key exchange algorithms and make them available to applications via EVP_PKEY_derive (3) and other related functions).

All “functions” mentioned here are passed as function pointers between libcrypto and the provider in OSSL_DISPATCH (3) arrays via OSSL_ALGORITHM (3) arrays that are returned by the provider’s provider_query_operation() function (see “Provider Functions” in provider-base (7)).

All these “functions” have a corresponding function type definition named OSSL_FUNC_{name}_fn, and a helper function to retrieve the function pointer from an OSSL_DISPATCH (3) element named OSSL_FUNC_{name}. For example, the “function” OSSL_FUNC_keyexch_newctx() has these:

typedef void *(OSSL_FUNC_keyexch_newctx_fn)(void *provctx); static ossl_inline OSSL_FUNC_keyexch_newctx_fn OSSL_FUNC_keyexch_newctx(const OSSL_DISPATCH *opf);

OSSL_DISPATCH (3) arrays are indexed by numbers that are provided as macros in openssl-core_dispatch.h (7), as follows:

OSSL_FUNC_keyexch_newctx OSSL_FUNC_KEYEXCH_NEWCTX OSSL_FUNC_keyexch_freectx OSSL_FUNC_KEYEXCH_FREECTX OSSL_FUNC_keyexch_dupctx OSSL_FUNC_KEYEXCH_DUPCTX OSSL_FUNC_keyexch_init OSSL_FUNC_KEYEXCH_INIT OSSL_FUNC_keyexch_set_peer OSSL_FUNC_KEYEXCH_SET_PEER OSSL_FUNC_keyexch_derive OSSL_FUNC_KEYEXCH_DERIVE OSSL_FUNC_keyexch_set_ctx_params OSSL_FUNC_KEYEXCH_SET_CTX_PARAMS OSSL_FUNC_keyexch_settable_ctx_params OSSL_FUNC_KEYEXCH_SETTABLE_CTX_PARAMS OSSL_FUNC_keyexch_get_ctx_params OSSL_FUNC_KEYEXCH_GET_CTX_PARAMS OSSL_FUNC_keyexch_gettable_ctx_params OSSL_FUNC_KEYEXCH_GETTABLE_CTX_PARAMS

A key exchange algorithm implementation may not implement all of these functions. In order to be a consistent set of functions a provider must implement OSSL_FUNC_keyexch_newctx, OSSL_FUNC_keyexch_freectx, OSSL_FUNC_keyexch_init and OSSL_FUNC_keyexch_derive. All other functions are optional.

A key exchange algorithm must also implement some mechanism for generating, loading or importing keys via the key management (OSSL_OP_KEYMGMT) operation. See provider-keymgmt (7) for further details.

Context Management Functions

OSSL_FUNC_keyexch_newctx() should create and return a pointer to a provider side structure for holding context information during a key exchange operation. A pointer to this context will be passed back in a number of the other key exchange operation function calls. The parameter provctx is the provider context generated during provider initialisation (see provider (7)).

OSSL_FUNC_keyexch_freectx() is passed a pointer to the provider side key exchange context in the ctx parameter. This function should free any resources associated with that context.

OSSL_FUNC_keyexch_dupctx() should duplicate the provider side key exchange context in the ctx parameter and return the duplicate copy.

Shared Secret Derivation Functions

OSSL_FUNC_keyexch_init() initialises a key exchange operation given a provider side key exchange context in the ctx parameter, and a pointer to a provider key object in the provkey parameter. The params, if not NULL, should be set on the context in a manner similar to using OSSL_FUNC_keyexch_set_params(). The key object should have been previously generated, loaded or imported into the provider using the key management (OSSL_OP_KEYMGMT) operation (see provider-keymgmt (7)>.

OSSL_FUNC_keyexch_set_peer() is called to supply the peer’s public key (in the provkey parameter) to be used when deriving the shared secret. It is also passed a previously initialised key exchange context in the ctx parameter. The key object should have been previously generated, loaded or imported into the provider using the key management (OSSL_OP_KEYMGMT) operation (see provider-keymgmt (7)>.

OSSL_FUNC_keyexch_derive() performs the actual key exchange itself by deriving a shared secret. A previously initialised key exchange context is passed in the ctx parameter. The derived secret should be written to the location secret which should not exceed outlen bytes. The length of the shared secret should be written to *secretlen. If secret is NULL then the maximum length of the shared secret should be written to *secretlen.

Key Exchange Parameters Functions

OSSL_FUNC_keyexch_set_ctx_params() sets key exchange parameters associated with the given provider side key exchange context ctx to params, see “Common Key Exchange parameters”. Any parameter settings are additional to any that were previously set. Passing NULL for params should return true.

OSSL_FUNC_keyexch_get_ctx_params() gets key exchange parameters associated with the given provider side key exchange context ctx into params, see “Common Key Exchange parameters”. Passing NULL for params should return true.

OSSL_FUNC_keyexch_settable_ctx_params() yields a constant OSSL_PARAM (3) array that describes the settable parameters, i.e. parameters that can be used with OP_signature_set_ctx_params(). If OSSL_FUNC_keyexch_settable_ctx_params() is present, OSSL_FUNC_keyexch_set_ctx_params() must also be present, and vice versa. Similarly, OSSL_FUNC_keyexch_gettable_ctx_params() yields a constant OSSL_PARAM (3) array that describes the gettable parameters, i.e. parameters that can be handled by OP_signature_get_ctx_params(). If OSSL_FUNC_keyexch_gettable_ctx_params() is present, OSSL_FUNC_keyexch_get_ctx_params() must also be present, and vice versa.

Notice that not all settable parameters are also gettable, and vice versa.

Common Key Exchange parameters

See OSSL_PARAM (3) for further details on the parameters structure used by the OSSL_FUNC_keyexch_set_ctx_params() and OSSL_FUNC_keyexch_get_ctx_params() functions.

Common parameters currently recognised by built-in key exchange algorithms are as follows.

“kdf-type” (OSSL_EXCHANGE_PARAM_KDF_TYPE) <UTF8 string>
Sets or gets the Key Derivation Function type to apply within the associated key exchange ctx.

“kdf-digest” (OSSL_EXCHANGE_PARAM_KDF_DIGEST) <UTF8 string>
Sets or gets the Digest algorithm to be used as part of the Key Derivation Function associated with the given key exchange ctx.

“kdf-digest-props” (OSSL_EXCHANGE_PARAM_KDF_DIGEST_PROPS) <UTF8 string>
Sets properties to be used upon look up of the implementation for the selected Digest algorithm for the Key Derivation Function associated with the given key exchange ctx.

“kdf-outlen” (OSSL_EXCHANGE_PARAM_KDF_OUTLEN) <unsigned integer>
Sets or gets the desired size for the output of the chosen Key Derivation Function associated with the given key exchange ctx. The length of the “kdf-outlen” parameter should not exceed that of a size_t.

“kdf-ukm” (OSSL_EXCHANGE_PARAM_KDF_UKM) <octet string>
Sets the User Key Material to be used as part of the selected Key Derivation Function associated with the given key exchange ctx.

“kdf-ukm” (OSSL_EXCHANGE_PARAM_KDF_UKM) <octet string ptr>
Gets a pointer to the User Key Material to be used as part of the selected Key Derivation Function associated with the given key exchange ctx. Providers usually do not need to support this gettable parameter as its sole purpose is to support functionality of the deprecated EVP_PKEY_CTX_get0_ecdh_kdf_ukm() and EVP_PKEY_CTX_get0_dh_kdf_ukm() functions.

RETURN VALUES

OSSL_FUNC_keyexch_newctx() and OSSL_FUNC_keyexch_dupctx() should return the newly created provider side key exchange context, or NULL on failure.

OSSL_FUNC_keyexch_init(), OSSL_FUNC_keyexch_set_peer(), OSSL_FUNC_keyexch_derive(), OSSL_FUNC_keyexch_set_params(), and OSSL_FUNC_keyexch_get_params() should return 1 for success or 0 on error.

OSSL_FUNC_keyexch_settable_ctx_params() and OSSL_FUNC_keyexch_gettable_ctx_params() should always return a constant OSSL_PARAM (3) array.

SEE ALSO

provider (7)

HISTORY

The provider KEYEXCH interface was introduced in OpenSSL 3.0.

COPYRIGHT

Copyright 2019-2022 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

319 - Linux cli command mawk-code

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command mawk-code and provides detailed information about the command mawk-code, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the mawk-code.

NAME 🖥️ mawk-code 🖥️

code - dumping mawk’s byte-code

SYNOPSIS

At startup, mawk compiles the script into byte-code. After that, it interprets the compiled byte-code. Use the -Wdump option to show the byte-code.

PROGRAM CODES

As mawk executes the program, it maintains a reference to the command to execute in cdp. After that there may be data and/or references in cdp[0], cdp[1], etc.

When an operation requires operands, mawk pushes the values (or array/string references) onto the stack, which updates the stack pointer sp. When the operation completes, mawk consumes those entries on the stack, pushing the result (if any) onto the stack.

While executing user-defined functions, mawk maintains a frame pointer fp to address the function’s local variables.

a_cat

Concatenate array-indices.

Usage:

Forms a multiple array index by concatenating the elements of sp[1-cnt..0], with each element separated by SUBSEP.

Parameters:

cdp[0]

cnt, the number of elements to concatenate follows the command.

sp[0]..sp[1-cnt]
hold reference to the elements to concatenate.

Returns the index in sp[0].

a_del

Delete an array item.

Usage:

delete array[expr]

Parameters:

sp[0]
points to array

sp[-1]
is an expr

a_length

Find the length of an array.

Usage:

length(array)

Parameters:

sp[0]
points to array.

Returns the length of the array in sp[0].

a_pusha

Push array address onto stack.

Usage:

This is used to set up a calling argument for a function.

Parameters:

cdp[0]
array reference follows the command.

Returns the array in sp[0].

a_test

Test if an expression is present in an array.

Usage:

(expression in array)

Parameters:

sp[0]
points to an array.

sp[-1]
is an expression.

Returns 1 in sp[0] if the expression is found, 0 otherwise.

add

Add two numbers.

Usage:

first + second

Parameters:

sp[0]
holds the second value.

sp[-1]
holds the first value.

Returns the sum in sp[0].

add_asg

Combined addition/assignment.

Usage:

target += source

Parameters:

sp[0]
is the source expression

sp[-1]
points to the target

Stores the sum in the target, leaving sp[0] pointing to the target.

ae_pusha

Push reference to array cell, given expression for its index.

Usage:

arrayname[expression]

Parameters:

cdp[0]
an array reference follows the command.

sp[0]
has an expression, used for the index of a cell in the array.

Returns a reference to the addressed cell in sp[0].

ae_pushi

Push contents of array cell, given expression for its index.

Usage:

arrayname[expression]

Parameters:

sp[0]
has an expression, used for the index of a cell in the array.

Returns contents of the addressed cell in sp[0].

aloop

Update reference to next cell for array loop.

Usage:

for ( i in arrayname ) statement

Parameters:

none

Mawk maintains a stack of array-loop state. It updates the array/cell references in the current loop’s state.

assign

Assigns a value.

Usage:

target = source

Parameters:

sp[0]
is the source expression

sp[-1]
points to the target

Stores the sum in the target, leaving sp[0] pointing to the target.

atan2

Compute arc-tangent of two values.

Usage:

atan2( first, second )

Parameters:

sp[0]
holds the second value

sp[-1]
holds the first value

Returns the result in sp[0].

call

Call a function.

Usage:

function()

Parameters:

cdp[0]
is a reference to the function block

cdp[1]
holds number of input arguments

Returns function value in sp[0].

cat

Concatenate two strings.

Usage:

first second

Parameters:

sp[0]
is the second string.

sp[-1]
is the first string.

Returns the result in sp[0].

close

Close the file or pipe associated with an expression.

Usage:

close( expression )

Parameters:

sp[0]
holds the expression identifying the file to close

Returns the status from closing the file, 0 on success or -1 on failure.

cos

Compute the cosine of a value in radians.

Usage:

cos( value )

Parameters:

sp[0]
is the value.

Returns the result in sp[0].

del_a

Delete an array.

Usage:

delete(array)

Parameters:

sp[0]
is the array to delete.

div

Divide one number by another.

Usage:

first / second

Parameters:

sp[0]
is the second value.

sp[-1]
is the first value.

Returns the quotient in sp[0].

div_asg

Combined division/assignment.

Usage:

target /= source

Parameters:

sp[0]
is the source

sp[-1]
points to the target

Stores the quotient in the target, leaving sp[0] pointing to the target.

eq

Compare two values.

Usage:

first == second

Parameters:

sp[0]
is the second value

sp[-1]
is the first value

Returns 1 in sp[0] if the values are equal, otherwise 0.

exit

Exits mawk with a specific exit-code.

Usage:

exit(exit_code)

Parameters:

sp[0]
is the exit_code

exit0

Exits mawk with success

Usage:

exit

Parameters:

none

exp

Compute base-e exponential function of a value.

Usage:

exp( value )

Parameters:

sp[0]
is the value

Returns the result in sp[0].

f_add_asg

Combination addition/assignment to NF.

Usage:

NF += expression

Parameters:

sp[0]
is the expression to add

f_assign

Assign an expression to NF.

Usage:

NF = expression

Parameters:

sp[0]
is the expression

f_div_asg

Combination division/assignment to NF.

Usage:

NF /= expression

Parameters:

sp[0]
is the expression

f_mod_asg

Combination modulus/assignment to NF.

Usage:

NF %= expression

Parameters:

sp[0]
is the expression

f_mul_asg

Combination multiplication/assignment to NF.

Usage:

NF *= expression

Parameters:

sp[0]
is the expression

f_post_dec

Post-decrement using NF.

Usage:

NF–

Parameters:

holds a reference to the field to use

f_post_inc

Post-increment using NF.

Usage:

NF++

Parameters:

holds a reference to the field to use

f_pow_asg

Exponentiation using NF.

Usage:

NF ^= expression

Parameters:

sp[0]
is the expression to use

f_pre_dec

Predecrement using NF.

Usage:

–NF

Parameters:

sp[0]
holds a reference to the field to use

f_pre_inc

Preincrement using NF.

Usage:

++NF

Parameters:

sp[0]
holds a reference to the field to use

f_pusha

Push array reference to data split-up as fields..

Usage:

$0 = expression
getline

Parameters:

cdp[0]
is a reference to the data to be split/assigned.

Returns the resulting array reference in sp[0].

f_pushi

Push contents of numbered field.

Usage:

$expression

Parameters:

cdp[0]
holds a reference to $expression

cdp[1]
holds expression

Returns the field’s value in sp[0].

f_sub_asg

Combination subtraction/assignment to NF.

Usage:

NF -= expression

Parameters:

sp[0]
holds a reference to the field to use

fe_pusha

Push reference to numbered field.

Usage:

$number

Parameters:

sp[0]
holds the field number

Returns a reference to the field in sp[0].

fe_pushi

Push content of numbered field.

Usage:

$number

Parameters:

sp[0]
holds the field number

Returns the field’s content in sp[0].

fflush

Flush the output file or pipe associated with an expression.

Usage:

fflush( expression )

Parameters:

sp[0]
is the expression value

Returns the result in sp[0].

gt

Test if first value is greater than the second.

Usage:

first > second

Parameters:

sp[0]
holds the second value.

sp[-1]
holds the first value.

Returns 1 in sp[0] if the first value is greater than, otherwise 0.

gte

Test if first value is greater than or equal to the second.

Usage:

first >= second

Parameters:

sp[0]
holds the second value.

sp[-1]
holds the first value.

Returns 1 in sp[0] if the first value is greater than or equal, otherwise 0.

index

Find the position of the second string in the first.

Usage:

index( first, second )

Parameters:

sp[0]
is the second string

sp[0]
is the first string

Returns the position in sp[0] starting at 1 if found, 0 if not found.

int

Returns a value truncated towards zero..

Usage:

int( value )

Parameters:

sp[0]
is the value

Returns the result in sp[0].

jmain

Go from BEGIN code to MAIN code.

Usage:

(internal state)

Parameters:

none

jmp

Jump to a new byte-code position, by a given number of bytes.

Usage:

(internal state)

Parameters:

cdp[0]
holds the (signed) number of bytes by which to jump.

jnz

Jump to a new byte-code position if sp[0] is nonzero, by a given number of bytes.

Usage:

(internal state)

Parameters:

cdp[0]

holds the (signed) number of bytes by which to jump.

sp[0]

holds a value to compare against 0.

jz

Jump to a new byte-code position if sp[0] is zero, by a given number of bytes.

Usage:

(internal state)

Parameters:

cdp[0]

holds the (signed) number of bytes by which to jump.

sp[0]

holds a value to compare against 0.

l_pusha

Push a local address onto the evaluation stack.

Usage:

(internal state)

Parameters:

cdp[0]

holds the offset from the frame pointer fp.

Returns the address in sp[0].

l_pushi

Push contents of a local variable onto the evaluation stack.

Usage:

(internal state)

Parameters:

cdp[0]

holds the offset from the frame pointer fp.

Returns the contents of the local variable in sp[0].

la_pusha

Pushes a reference to an array onto the evaluation stack.

Usage:

arrayname

Parameters:

cdp[0]

holds the offset from the frame pointer fp of a reference to an array.

Returns a reference to the array in sp[0].

lae_pusha

Pushes a reference to a given array cell onto the evaluation stack.

Usage:

arrayname[expression]

Parameters:

cdp[0]

holds the offset from the frame pointer fp of a reference to an array.

sp[0]

holds an expression

Returns a reference to the specified array cell in sp[0].

lae_pushi

Pushes the contents of a given array cell onto the evaluation stack.

Usage:

arrayname[expression]

Parameters:

cdp[0]

holds the offset from the frame pointer fp of a reference to an array.

sp[0]

holds an expression

Returns the contents of the specified array cell in sp[0].

length

Returns the length of a string or array value.

Usage:

length( value )

Parameters:

sp[0]
is the string or array reference

Returns the length in sp[0].

ljnz

Special jump for logical-OR, always preceded by test*.*

Usage:

(internal state)

Parameters:

cdp[0]

holds the (signed) number of bytes by which to jump if the value is nonzero.

sp[0]

holds a value to compare against 0.

ljz

Special jump for logical-OR, always preceded by test*.*

Usage:

(internal state)

Parameters:

cdp[0]

holds the (signed) number of bytes by which to jump if the value is zero.

sp[0]

holds a value to compare against 0.

log

Compute the natural logarithm of a value.

Usage:

log( value )

Parameters:

sp[0]
is the value

Returns the result in sp[0].

lt

Test if first value is less than the second.

Usage:

first < second

Parameters:

sp[0]
holds the second value.

sp[-1]
holds the first value.

Returns 1 in sp[0] if the first value is less than, otherwise 0.

lte

Test if first value is less than or equal to the second.

Usage:

first <= second

Parameters:

sp[0]
holds the second value.

sp[-1]
holds the first value.

Returns 1 in sp[0] if the first value is less than or equal, otherwise 0.

match0

Test if $0 matches a given regular expression.

Usage:

$0 ~ regex

Parameters:

cdp[0]

holds a reference to a regular expression.

Returns 1 in sp[0] if $0 matches the regular expression, 0 otherwise.

match1

Test if a given expression matches a given regular expression.

Usage:

expression ~ regex

Parameters:

cdp[0]

holds a reference to a regular expression.

sp[0]

holds an expression to test.

Returns 1 in sp[0] if the expression matches the regular expression, 0 otherwise.

match2

Test if an expression in sp[-1] matches the regular expression in sp[0].

Usage:

expression ~ regex

Parameters:

sp[0]

holds a reference to a regular expression.

sp[-1]

holds an expression to test.

Returns 1 in sp[0] if the expression matches the regular expression, 0 otherwise.

mktime

Converts a date specification in systime format to a timestamp.

Usage:

mktime( string )

Parameters:

sp[0]
holds the date-specification string

Returns the result in sp[0].

mod

Compute modulus/remainder with two operands.

Usage:

first % second

Parameters:

sp[0]
holds the second operand

sp[-1]
holds the first operand

Returns the remainder in sp[0].

mod_asg

Assign modulus/remainder with two operands.

Usage:

first %= second

Parameters:

sp[0]
holds the second operand

cdp[0]
holds the first operand

Returns the remainder in sp[0] as well as replacing the first value.

mul

Compute product with two operands.

Usage:

first * second

Parameters:

sp[0]
holds the second value

sp[-1]
holds the first value

Returns the product in sp[0].

mul_asg

Assign product with two operands.

Usage:

first *= second

Parameters:

sp[0]
holds the second value

sp[-1]
holds the first value

Returns the product in sp[0] as well as replacing the first value.

neq

Compare two values.

Usage:

first != second

Parameters:

sp[0]
is the second value

sp[-1]
is the first value

Returns 1 in sp[0] if the values are not equal, otherwise 0.

next

Read the next record, restart pattern testing.

Usage:

next

Parameters:

none

nextfile

Begin processing the next file listed on the command line.

Usage:

nextfile

Parameters:

none

nf_pushi

Push the number of fields (NF) onto the evaluation stack.

Usage:

(internal state)

Parameters:

none

not

Compute a logical negation.

Usage:

! value

Parameters:

sp[0]
holds a value to negate.

Returns the result on the evaluation stack, i.e., 0 if the value is nonzero and 1 otherwise.

ol_gl

Read into $0 using getline.

Usage:

getline

Parameters:

none

ol_gl_nr

Read into $0 using getline, updating NR and FNR.

Usage:

getline < file

Parameters:

none

omain

Start executing the main section of the script (between BEGIN and END).

Usage:

(internal state)

Parameters:

none

pop

Pop the evaluation stack, discarding the value.

Usage:

(internal state)

Parameters:

none

pop_al

Finish an array in loop, deallocating the state information.

Usage:

(internal state)

Parameters:

none

post_dec

Post-decrement a value.

Usage:

value –

Parameters:

sp[0]
holds the value to decrement

Returns the updated value in sp[0].

post_inc

Post-increment a value.

Usage:

value ++

Parameters:

sp[0]
holds the value to increment

Returns the updated value in sp[0].

pow

Compute the first value raised to the power of the second value.

Usage:

first ^ second

Parameters:

sp[0]
holds the second value

sp[-1]
holds the first value

Returns the result in sp[0].

pow_asg

Assign the first value raised to the power of the second value.

Usage:

variable = first ^ second

Parameters:

cdp[0]
is a reference to the variable which will be assigned the result

sp[0]
holds the second value

sp[-1]
holds the first value

pre_dec

Pre-decrement a value.

Usage:

– value

Parameters:

sp[0]
holds the value to decrement.

Returns the updated value in sp[0];.

pre_inc

Pre-increment a value.

Usage:

++ value

Parameters:

sp[0]
holds the value to decrement.

Returns the updated value in sp[0];.

pusha

Push array address onto stack.

Usage:

(internal state)

Parameters:

cdp[0]
array reference follows the command.

Returns the array in sp[0].

pushc

Push a data cell onto the evaluation stack.

Usage:

(internal state)

Parameters:

cdp[0]
is a reference to the data to push

Returns a reference to the result in sp[0].

pushd

Push a double floating value onto the evaluation stack.

Usage:

(internal state)

Parameters:

cdp[0]
is a reference to the data to push

Returns a reference to the result in sp[0].

pushi

Push contents of next referenced variable onto the evaluation stack.

Usage:

(internal state)

Parameters:

cdp[0]
is a reference to the data cell to copy.

Returns a reference to the result in sp[0].

pushint

Reserve the next slot on the evaluation stack, setting its type.

Usage:

(internal state)

Parameters:

cdp[0]
holds the type to set in the new slot, e.g., for data via I/O redirection

Returns a reference to the result in sp[0].

pushs

Push a reference to a string value onto the evaluation stack.

Usage:

(internal state)

Parameters:

cdp[0]
holds a reference to the string value

Returns a reference to the result in sp[0].

rand

Returns a random number between zero and one..

Usage:

rand()

Parameters:

none

Returns the result in sp[0].

range

Test a range pattern: pat1, pat2 { action }.

Usage:

(internal state)

Parameters:

cdp[0].op
a flag, test pat1 if on else pat2

cdp[1].op
offset of pat2 code from cdp

cdp[2].op
offset of action code from cdp

cdp[3].op
offset of code after the action from cdp

cdp[4]
start of pat1 code

sp[0]
holds arguments for the action.

ret

Return a function value.

Usage:

return value

Parameters:

sp[0]
holds the return value

When calling a function, mawk saves the current stack, creating a new one. On return, mawk restores the previous stack and returns the function value in sp[0].

ret0

Return from a function without providing a return-value.

Usage:

return

Parameters:

sp[0]
is modified to make the value uninitialized.

As in the ret operation, mawk restores the previous stack. After the return, sp[0] is an uninitialized value.

set_al

Begin an array in loop.

Usage:

for ( iterator in arrayname ) statement

Parameters:

sp[0]
holds a reference to the array

sp[-1]
holds a reference to the iteration variable

Mawk pushes a new entry onto the array loop stack, and updates cdp to point to the statement to execute.

sin

Compute the sine of a value in radians.

Usage:

sin( value )

Parameters:

sp[0]
holds the value

Returns the result in sp[0].

sprintf

Returns a string constructed from expression-list according to format.

Usage:

sprintf( format [, value1 [,… ] ] )

Parameters:

sp[0]
is the last parameter value; there can be up to 255.

Returns the resulting string in sp[0].

sqrt

Returns the square root of a value.

Usage:

sqrt( value 0

Parameters:

sp[0]
is the value

Returns the result in sp[0].

srand

Seeds the random number generator.

Usage:

srand( value )
srand( )

Parameters:

sp[0]
is the seed value, which may be uninitialized

Returns the previous seed value in sp[0].

stop

Finish a range pattern.

Usage:

(internal state)

Parameters:

none

strftime

Formats the given timestamp using the given format.

Usage:

strftime( format , timestamp , utc )
strftime( format , timestamp )
strftime( format )
strftime( )

Parameters:

Zero to three parameters may be on the stack. If all three are used, they are as follows:

sp[0]
is the utc flag

sp[-1]
is the timestamp value

sp[-2]
is the format

Returns the result in sp[0].

sub

Subtract the second value from the first.

Usage:

first - second

Parameters:

sp[0]
holds the second value

sp[-1]
holds the first value

Returns the result in sp[0].

sub_asg

Assign the difference of two values to a variable.

Usage:

target = first - second

Parameters:

cdp[0]
holds a reference to the variable to which to assign the result

sp[0]
holds the second value

sp[-1]
holds the first value

Stores the difference in the target, leaving sp[0] pointing to the target.

substr

eturns the substring of string s, starting at index i, of length n.

Usage:

substr(s,i,n)
substr(s,i)

Parameters:

Two or three parameters may be on the stack. If all three are used, they are as follows:

sp[0]
holds the length n.

sp[0]
holds the index i.

sp[0]
holds the string s.

system

Executes a command, returning the wait-status.

Usage:

status = system( command )

Parameters:

sp[0]
is the command to execute

Returns the wait-status in sp[0].

systime

Returns the current time of day as the number of seconds since the Epoch.

Usage:

systime( )

Parameters:

none

Returns the result in sp[0].

test

Test a logical expression.

Usage:

value

Parameters:

sp[0]
holds a value to test.

Returns the result on the evaluation stack, i.e., 1 if the value is nonzero and 0 otherwise.

tolower

Copy a string, converting to lowercase.

Usage:

tolower( value )

Parameters:

sp[0]
is the value to convert

Returns the result in sp[0].

toupper

Copy a string, converting to uppercase.

Usage:

toupper( value )

Parameters:

sp[0]
is the value to convert

Returns the result in sp[0].

uminus

Unitary minus.

Usage:

- value

Parameters:

sp[0]
contains a value to negate. As a side-effect, if the value is a string, it is cast to double floating point.

Returns the result in sp[0].

uplus

Unitary plus.

Usage:

+ value

Parameters:

sp[0]
contains a value to use. As a side-effect, if the value is a string, it is cast to double floating point.

Returns the result in sp[0].

REGULAR EXPRESSIONS

M_1J

mandatory jump

M_2JA

optional (undesirable) jump

M_2JB

optional (desirable) jump

M_2JC

pop pos’n, optional jump if advanced

M_ACCEPT

end of match

M_ANY

arbitrary character (.)

M_CLASS

character class

M_END

end of string ($)

M_SAVE_POS

push position onto stack

M_START

start of string (^)

M_STR

matching a literal string

M_U

arbitrary string (.*)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

320 - Linux cli command EVP_CIPHER-BLOWFISHssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_CIPHER-BLOWFISHssl and provides detailed information about the command EVP_CIPHER-BLOWFISHssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_CIPHER-BLOWFISHssl.

NAME 🖥️ EVP_CIPHER-BLOWFISHssl 🖥️

BLOWFISH - The BLOBFISH EVP_CIPHER implementations

DESCRIPTION

Support for BLOWFISH symmetric encryption using the EVP_CIPHER API.

Algorithm Names

The following algorithms are available in the legacy provider:

“BF-ECB”

“BF-CBC”

“BF-OFB”

“BF-CFB”

Parameters

This implementation supports the parameters described in “PARAMETERS” in EVP_EncryptInit (3).

SEE ALSO

provider-cipher (7), OSSL_PROVIDER-legacy (7)

COPYRIGHT

Copyright 2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

321 - Linux cli command EVP_KEYMGMT-Poly1305ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KEYMGMT-Poly1305ssl and provides detailed information about the command EVP_KEYMGMT-Poly1305ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KEYMGMT-Poly1305ssl.

NAME 🖥️ EVP_KEYMGMT-Poly1305ssl 🖥️

HMAC, EVP_KEYMGMT-HMAC, EVP_PKEY-Siphash, EVP_KEYMGMT-Siphash, EVP_PKEY-Poly1305, EVP_KEYMGMT-Poly1305, EVP_PKEY-CMAC, EVP_KEYMGMT-CMAC - EVP_PKEY legacy MAC keytypes and algorithm support

DESCRIPTION

The HMAC and CMAC key types are implemented in OpenSSL’s default and FIPS providers. Additionally the Siphash and Poly1305 key types are implemented in the default provider. Performing MAC operations via an EVP_PKEY is considered legacy and are only available for backwards compatibility purposes and for a restricted set of algorithms. The preferred way of performing MAC operations is via the EVP_MAC APIs. See EVP_MAC_init (3).

For further details on using EVP_PKEY based MAC keys see EVP_SIGNATURE-HMAC (7), EVP_SIGNATURE-Siphash (7), EVP_SIGNATURE-Poly1305 (7) or EVP_SIGNATURE-CMAC (7).

Common MAC parameters

All the MAC keytypes support the following parameters.

“priv” (OSSL_PKEY_PARAM_PRIV_KEY) <octet string>
The MAC key value.

“properties” (OSSL_PKEY_PARAM_PROPERTIES) <UTF8 string>
A property query string to be used when any algorithms are fetched.

CMAC parameters

As well as the parameters described above, the CMAC keytype additionally supports the following parameters.

“cipher” (OSSL_PKEY_PARAM_CIPHER) <UTF8 string>
The name of a cipher to be used when generating the MAC.

“engine” (OSSL_PKEY_PARAM_ENGINE) <UTF8 string>
The name of an engine to be used for the specified cipher (if any).

Common MAC key generation parameters

MAC key generation is unusual in that no new key is actually generated. Instead a new provider side key object is created with the supplied raw key value. This is done for backwards compatibility with previous versions of OpenSSL.

“priv” (OSSL_PKEY_PARAM_PRIV_KEY) <octet string>
The MAC key value.

CMAC key generation parameters

In addition to the common MAC key generation parameters, the CMAC key generation additionally recognises the following.

“cipher” (OSSL_PKEY_PARAM_CIPHER) <UTF8 string>
The name of a cipher to be used when generating the MAC.

SEE ALSO

EVP_KEYMGMT (3), EVP_PKEY (3), provider-keymgmt (7)

COPYRIGHT

Copyright 2020 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

322 - Linux cli command pid_namespaces

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command pid_namespaces and provides detailed information about the command pid_namespaces, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the pid_namespaces.

NAME 🖥️ pid_namespaces 🖥️

overview of Linux PID namespaces

DESCRIPTION

For an overview of namespaces, see namespaces(7).

PID namespaces isolate the process ID number space, meaning that processes in different PID namespaces can have the same PID. PID namespaces allow containers to provide functionality such as suspending/resuming the set of processes in the container and migrating the container to a new host while the processes inside the container maintain the same PIDs.

PIDs in a new PID namespace start at 1, somewhat like a standalone system, and calls to fork(2), vfork(2), or clone(2) will produce processes with PIDs that are unique within the namespace.

Use of PID namespaces requires a kernel that is configured with the CONFIG_PID_NS option.

The namespace init process

The first process created in a new namespace (i.e., the process created using clone(2) with the CLONE_NEWPID flag, or the first child created by a process after a call to unshare(2) using the CLONE_NEWPID flag) has the PID 1, and is the “init” process for the namespace (see init(1)). This process becomes the parent of any child processes that are orphaned because a process that resides in this PID namespace terminated (see below for further details).

If the “init” process of a PID namespace terminates, the kernel terminates all of the processes in the namespace via a SIGKILL signal. This behavior reflects the fact that the “init” process is essential for the correct operation of a PID namespace. In this case, a subsequent fork(2) into this PID namespace fail with the error ENOMEM; it is not possible to create a new process in a PID namespace whose “init” process has terminated. Such scenarios can occur when, for example, a process uses an open file descriptor for a /proc/pid/ns/pid file corresponding to a process that was in a namespace to setns(2) into that namespace after the “init” process has terminated. Another possible scenario can occur after a call to unshare(2): if the first child subsequently created by a fork(2) terminates, then subsequent calls to fork(2) fail with ENOMEM.

Only signals for which the “init” process has established a signal handler can be sent to the “init” process by other members of the PID namespace. This restriction applies even to privileged processes, and prevents other members of the PID namespace from accidentally killing the “init” process.

Likewise, a process in an ancestor namespace can—subject to the usual permission checks described in kill(2)—send signals to the “init” process of a child PID namespace only if the “init” process has established a handler for that signal. (Within the handler, the siginfo_t si_pid field described in sigaction(2) will be zero.) SIGKILL or SIGSTOP are treated exceptionally: these signals are forcibly delivered when sent from an ancestor PID namespace. Neither of these signals can be caught by the “init” process, and so will result in the usual actions associated with those signals (respectively, terminating and stopping the process).

Starting with Linux 3.4, the reboot(2) system call causes a signal to be sent to the namespace “init” process. See reboot(2) for more details.

Nesting PID namespaces

PID namespaces can be nested: each PID namespace has a parent, except for the initial (“root”) PID namespace. The parent of a PID namespace is the PID namespace of the process that created the namespace using clone(2) or unshare(2). PID namespaces thus form a tree, with all namespaces ultimately tracing their ancestry to the root namespace. Since Linux 3.7, the kernel limits the maximum nesting depth for PID namespaces to 32.

A process is visible to other processes in its PID namespace, and to the processes in each direct ancestor PID namespace going back to the root PID namespace. In this context, “visible” means that one process can be the target of operations by another process using system calls that specify a process ID. Conversely, the processes in a child PID namespace can’t see processes in the parent and further removed ancestor namespaces. More succinctly: a process can see (e.g., send signals with kill(2), set nice values with setpriority(2), etc.) only processes contained in its own PID namespace and in descendants of that namespace.

A process has one process ID in each of the layers of the PID namespace hierarchy in which is visible, and walking back though each direct ancestor namespace through to the root PID namespace. System calls that operate on process IDs always operate using the process ID that is visible in the PID namespace of the caller. A call to getpid(2) always returns the PID associated with the namespace in which the process was created.

Some processes in a PID namespace may have parents that are outside of the namespace. For example, the parent of the initial process in the namespace (i.e., the init(1) process with PID 1) is necessarily in another namespace. Likewise, the direct children of a process that uses setns(2) to cause its children to join a PID namespace are in a different PID namespace from the caller of setns(2). Calls to getppid(2) for such processes return 0.

While processes may freely descend into child PID namespaces (e.g., using setns(2) with a PID namespace file descriptor), they may not move in the other direction. That is to say, processes may not enter any ancestor namespaces (parent, grandparent, etc.). Changing PID namespaces is a one-way operation.

The NS_GET_PARENT ioctl(2) operation can be used to discover the parental relationship between PID namespaces; see ioctl_ns(2).

setns(2) and unshare(2) semantics

Calls to setns(2) that specify a PID namespace file descriptor and calls to unshare(2) with the CLONE_NEWPID flag cause children subsequently created by the caller to be placed in a different PID namespace from the caller. (Since Linux 4.12, that PID namespace is shown via the /proc/pid/ns/pid_for_children file, as described in namespaces(7).) These calls do not, however, change the PID namespace of the calling process, because doing so would change the caller’s idea of its own PID (as reported by getpid()), which would break many applications and libraries.

To put things another way: a process’s PID namespace membership is determined when the process is created and cannot be changed thereafter. Among other things, this means that the parental relationship between processes mirrors the parental relationship between PID namespaces: the parent of a process is either in the same namespace or resides in the immediate parent PID namespace.

A process may call unshare(2) with the CLONE_NEWPID flag only once. After it has performed this operation, its /proc/pid/ns/pid_for_children symbolic link will be empty until the first child is created in the namespace.

Adoption of orphaned children

When a child process becomes orphaned, it is reparented to the “init” process in the PID namespace of its parent (unless one of the nearer ancestors of the parent employed the prctl(2) PR_SET_CHILD_SUBREAPER command to mark itself as the reaper of orphaned descendant processes). Note that because of the setns(2) and unshare(2) semantics described above, this may be the “init” process in the PID namespace that is the parent of the child’s PID namespace, rather than the “init” process in the child’s own PID namespace.

Compatibility of CLONE_NEWPID with other CLONE_* flags

In current versions of Linux, CLONE_NEWPID can’t be combined with CLONE_THREAD. Threads are required to be in the same PID namespace such that the threads in a process can send signals to each other. Similarly, it must be possible to see all of the threads of a process in the proc(5) filesystem. Additionally, if two threads were in different PID namespaces, the process ID of the process sending a signal could not be meaningfully encoded when a signal is sent (see the description of the siginfo_t type in sigaction(2)). Since this is computed when a signal is enqueued, a signal queue shared by processes in multiple PID namespaces would defeat that.

In earlier versions of Linux, CLONE_NEWPID was additionally disallowed (failing with the error EINVAL) in combination with CLONE_SIGHAND (before Linux 4.3) as well as CLONE_VM (before Linux 3.12). The changes that lifted these restrictions have also been ported to earlier stable kernels.

/proc and PID namespaces

A /proc filesystem shows (in the */proc/*pid directories) only processes visible in the PID namespace of the process that performed the mount, even if the /proc filesystem is viewed from processes in other namespaces.

After creating a new PID namespace, it is useful for the child to change its root directory and mount a new procfs instance at /proc so that tools such as ps(1) work correctly. If a new mount namespace is simultaneously created by including CLONE_NEWNS in the flags argument of clone(2) or unshare(2), then it isn’t necessary to change the root directory: a new procfs instance can be mounted directly over /proc.

From a shell, the command to mount /proc is:

$ mount -t proc proc /proc

Calling readlink(2) on the path /proc/self yields the process ID of the caller in the PID namespace of the procfs mount (i.e., the PID namespace of the process that mounted the procfs). This can be useful for introspection purposes, when a process wants to discover its PID in other namespaces.

/proc files

/proc/sys/kernel/ns_last_pid (since Linux 3.3)
This file (which is virtualized per PID namespace) displays the last PID that was allocated in this PID namespace. When the next PID is allocated, the kernel will search for the lowest unallocated PID that is greater than this value, and when this file is subsequently read it will show that PID.

This file is writable by a process that has the CAP_SYS_ADMIN or (since Linux 5.9) CAP_CHECKPOINT_RESTORE capability inside the user namespace that owns the PID namespace. This makes it possible to determine the PID that is allocated to the next process that is created inside this PID namespace.

Miscellaneous

When a process ID is passed over a UNIX domain socket to a process in a different PID namespace (see the description of SCM_CREDENTIALS in unix(7)), it is translated into the corresponding PID value in the receiving process’s PID namespace.

STANDARDS

Linux.

EXAMPLES

See user_namespaces(7).

SEE ALSO

clone(2), reboot(2), setns(2), unshare(2), proc(5), capabilities(7), credentials(7), mount_namespaces(7), namespaces(7), user_namespaces(7), switch_root(8)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

323 - Linux cli command wireless

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command wireless and provides detailed information about the command wireless, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the wireless.

NAME 🖥️ wireless 🖥️

Wireless Tools and Wireless Extensions

SYNOPSIS

iwconfig
iwpriv -a

DESCRIPTION

The Wireless Extensions is an API allowing you manipulate Wireless LAN networking interfaces. It is composed of a variety of tools and configuration files. It is documented in more detail in the Linux Wireless LAN Howto.
The Wireless Tools are used to change the configuration of wireless LAN networking interfaces on the fly, to get their current configuration, to get statistics and diagnose them. They are described in their own man page, see below for references.
Wireless configuration is specific to each Linux distribution. This man page will contain in the future the configuration procedure for a few common distributions. For the time being, check the file DISTRIBUTIONS.txt included with the Wireless Tools package.

DEBIAN 3.0

In Debian 3.0 (and later) you can configure wireless LAN networking devices using the network configuration tool ifupdown(8).

File :
/etc/network/interfaces

Form :
wireless-<function> <value>
wireless-essid Home
wireless-mode Ad-Hoc

See also :
/etc/network/if-pre-up.d/wireless-tools
/usr/share/doc/wireless-tools/README.Debian

SuSE 8.0

SuSE 8.0 (and later) has integrated wireless configuration in their network scripts.

Tool :
Yast2

File :
/etc/sysconfig/network/wireless
/etc/sysconfig/network/ifcfg-*

Form :
WIRELESS_<function>=<value>
WIRELESS_ESSID=“Home”
WIRELESS_MODE=Ad-Hoc

See also :
man ifup
info scpm

ORIGINAL PCMCIA SCRIPTS

If you are using the original configuration scripts from the Pcmcia package, you can use this method.

File :
/etc/pcmcia/wireless.opts

Form :
*,*,*,*)
ESSID=“Home”
MODE=“Ad-Hoc”
;;

See also :
/etc/pcmcia/wireless
File PCMCIA.txt part of Wireless Tools package

AUTHOR

Jean Tourrilhes - [email protected]
http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/

SEE ALSO

iwconfig(8), iwlist(8), iwspy(8), iwpriv(8), iwevent(8).

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

324 - Linux cli command DROP_TABLESPACE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_TABLESPACE and provides detailed information about the command DROP_TABLESPACE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_TABLESPACE.

NAME 🖥️ DROP_TABLESPACE 🖥️

remove a tablespace

SYNOPSIS

DROP TABLESPACE [ IF EXISTS ] name

DESCRIPTION

DROP TABLESPACE removes a tablespace from the system.

A tablespace can only be dropped by its owner or a superuser. The tablespace must be empty of all database objects before it can be dropped. It is possible that objects in other databases might still reside in the tablespace even if no objects in the current database are using the tablespace. Also, if the tablespace is listed in the temp_tablespaces setting of any active session, the DROP might fail due to temporary files residing in the tablespace.

PARAMETERS

IF EXISTS

Do not throw an error if the tablespace does not exist. A notice is issued in this case.

name

The name of a tablespace.

NOTES

DROP TABLESPACE cannot be executed inside a transaction block.

EXAMPLES

To remove tablespace mystuff from the system:

DROP TABLESPACE mystuff;

COMPATIBILITY

DROP TABLESPACE is a PostgreSQL extension.

SEE ALSO

CREATE TABLESPACE (CREATE_TABLESPACE(7)), ALTER TABLESPACE (ALTER_TABLESPACE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

325 - Linux cli command ipv6

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ipv6 and provides detailed information about the command ipv6, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ipv6.

NAME 🖥️ ipv6 🖥️

Linux IPv6 protocol implementation

SYNOPSIS

#include <sys/socket.h>
#include <netinet/in.h>
tcp6_socket = socket(AF_INET6, SOCK_STREAM, 0);
raw6_socket = socket(AF_INET6, SOCK_RAW, protocol);
udp6_socket = socket(AF_INET6, SOCK_DGRAM, protocol);

DESCRIPTION

Linux 2.2 optionally implements the Internet Protocol, version 6. This man page contains a description of the IPv6 basic API as implemented by the Linux kernel and glibc 2.1. The interface is based on the BSD sockets interface; see socket(7).

The IPv6 API aims to be mostly compatible with the IPv4 API (see ip(7)). Only differences are described in this man page.

To bind an AF_INET6 socket to any process, the local address should be copied from the in6addr_any variable which has in6_addr type. In static initializations, IN6ADDR_ANY_INIT may also be used, which expands to a constant expression. Both of them are in network byte order.

The IPv6 loopback address (::1) is available in the global in6addr_loopback variable. For initializations, IN6ADDR_LOOPBACK_INIT should be used.

IPv4 connections can be handled with the v6 API by using the v4-mapped-on-v6 address type; thus a program needs to support only this API type to support both protocols. This is handled transparently by the address handling functions in the C library.

IPv4 and IPv6 share the local port space. When you get an IPv4 connection or packet to an IPv6 socket, its source address will be mapped to v6.

Address format

struct sockaddr_in6 {
    sa_family_t     sin6_family;   /* AF_INET6 */
    in_port_t       sin6_port;     /* port number */
    uint32_t        sin6_flowinfo; /* IPv6 flow information */
    struct in6_addr sin6_addr;     /* IPv6 address */
    uint32_t        sin6_scope_id; /* Scope ID (new in Linux 2.4) */
};
struct in6_addr {
    unsigned char   s6_addr[16];   /* IPv6 address */
};

sin6_family is always set to AF_INET6; sin6_port is the protocol port (see sin_port in ip(7)); sin6_flowinfo is the IPv6 flow identifier; sin6_addr is the 128-bit IPv6 address. sin6_scope_id is an ID depending on the scope of the address. It is new in Linux 2.4. Linux supports it only for link-local addresses, in that case sin6_scope_id contains the interface index (see netdevice(7))

IPv6 supports several address types: unicast to address a single host, multicast to address a group of hosts, anycast to address the nearest member of a group of hosts (not implemented in Linux), IPv4-on-IPv6 to address an IPv4 host, and other reserved address types.

The address notation for IPv6 is a group of 8 4-digit hexadecimal numbers, separated with a ‘:’. “::” stands for a string of 0 bits. Special addresses are ::1 for loopback and ::FFFF:<IPv4 address> for IPv4-mapped-on-IPv6.

The port space of IPv6 is shared with IPv4.

Socket options

IPv6 supports some protocol-specific socket options that can be set with setsockopt(2) and read with getsockopt(2). The socket option level for IPv6 is IPPROTO_IPV6. A boolean integer flag is zero when it is false, otherwise true.

IPV6_ADDRFORM
Turn an AF_INET6 socket into a socket of a different address family. Only AF_INET is currently supported for that. It is allowed only for IPv6 sockets that are connected and bound to a v4-mapped-on-v6 address. The argument is a pointer to an integer containing AF_INET. This is useful to pass v4-mapped sockets as file descriptors to programs that don’t know how to deal with the IPv6 API.

IPV6_ADD_MEMBERSHIP, IPV6_DROP_MEMBERSHIP
Control membership in multicast groups. Argument is a pointer to a struct ipv6_mreq.

IPV6_MTU
getsockopt(): Retrieve the current known path MTU of the current socket. Valid only when the socket has been connected. Returns an integer.

setsockopt(): Set the MTU to be used for the socket. The MTU is limited by the device MTU or the path MTU when path MTU discovery is enabled. Argument is a pointer to integer.

IPV6_MTU_DISCOVER
Control path-MTU discovery on the socket. See IP_MTU_DISCOVER in ip(7) for details.

IPV6_MULTICAST_HOPS
Set the multicast hop limit for the socket. Argument is a pointer to an integer. -1 in the value means use the route default, otherwise it should be between 0 and 255.

IPV6_MULTICAST_IF
Set the device for outgoing multicast packets on the socket. This is allowed only for SOCK_DGRAM and SOCK_RAW socket. The argument is a pointer to an interface index (see netdevice(7)) in an integer.

IPV6_MULTICAST_LOOP
Control whether the socket sees multicast packets that it has send itself. Argument is a pointer to boolean.

IPV6_RECVPKTINFO (since Linux 2.6.14)
Set delivery of the IPV6_PKTINFO control message on incoming datagrams. Such control messages contain a struct in6_pktinfo, as per RFC 3542. Allowed only for SOCK_DGRAM or SOCK_RAW sockets. Argument is a pointer to a boolean value in an integer.

IPV6_RTHDR, IPV6_AUTHHDR, IPV6_DSTOPTS, IPV6_HOPOPTS, IPV6_FLOWINFO, IPV6_HOPLIMIT
Set delivery of control messages for incoming datagrams containing extension headers from the received packet. IPV6_RTHDR delivers the routing header, IPV6_AUTHHDR delivers the authentication header, IPV6_DSTOPTS delivers the destination options, IPV6_HOPOPTS delivers the hop options, IPV6_FLOWINFO delivers an integer containing the flow ID, IPV6_HOPLIMIT delivers an integer containing the hop count of the packet. The control messages have the same type as the socket option. All these header options can also be set for outgoing packets by putting the appropriate control message into the control buffer of sendmsg(2). Allowed only for SOCK_DGRAM or SOCK_RAW sockets. Argument is a pointer to a boolean value.

IPV6_RECVERR
Control receiving of asynchronous error options. See IP_RECVERR in ip(7) for details. Argument is a pointer to boolean.

IPV6_ROUTER_ALERT
Pass forwarded packets containing a router alert hop-by-hop option to this socket. Allowed only for SOCK_RAW sockets. The tapped packets are not forwarded by the kernel, it is the user’s responsibility to send them out again. Argument is a pointer to an integer. A positive integer indicates a router alert option value to intercept. Packets carrying a router alert option with a value field containing this integer will be delivered to the socket. A negative integer disables delivery of packets with router alert options to this socket.

IPV6_UNICAST_HOPS
Set the unicast hop limit for the socket. Argument is a pointer to an integer. -1 in the value means use the route default, otherwise it should be between 0 and 255.

IPV6_V6ONLY (since Linux 2.4.21 and 2.6)
If this flag is set to true (nonzero), then the socket is restricted to sending and receiving IPv6 packets only. In this case, an IPv4 and an IPv6 application can bind to a single port at the same time.

If this flag is set to false (zero), then the socket can be used to send and receive packets to and from an IPv6 address or an IPv4-mapped IPv6 address.

The argument is a pointer to a boolean value in an integer.

The default value for this flag is defined by the contents of the file /proc/sys/net/ipv6/bindv6only. The default value for that file is 0 (false).

ERRORS

ENODEV
The user tried to bind(2) to a link-local IPv6 address, but the sin6_scope_id in the supplied sockaddr_in6 structure is not a valid interface index.

VERSIONS

Linux 2.4 will break binary compatibility for the sockaddr_in6 for 64-bit hosts by changing the alignment of in6_addr and adding an additional sin6_scope_id field. The kernel interfaces stay compatible, but a program including sockaddr_in6 or in6_addr into other structures may not be. This is not a problem for 32-bit hosts like i386.

The sin6_flowinfo field is new in Linux 2.4. It is transparently passed/read by the kernel when the passed address length contains it. Some programs that pass a longer address buffer and then check the outgoing address length may break.

NOTES

The sockaddr_in6 structure is bigger than the generic sockaddr. Programs that assume that all address types can be stored safely in a struct sockaddr need to be changed to use struct sockaddr_storage for that instead.

SOL_IP, SOL_IPV6, SOL_ICMPV6, and other SOL_* socket options are nonportable variants of IPPROTO_*. See also ip(7).

BUGS

The IPv6 extended API as in RFC 2292 is currently only partly implemented; although the 2.2 kernel has near complete support for receiving options, the macros for generating IPv6 options are missing in glibc 2.1.

IPSec support for EH and AH headers is missing.

Flow label management is not complete and not documented here.

This man page is not complete.

SEE ALSO

cmsg(3), ip(7)

RFC 2553: IPv6 BASIC API; Linux tries to be compliant to this. RFC 2460: IPv6 specification.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

326 - Linux cli command iso_8859_3

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso_8859_3 and provides detailed information about the command iso_8859_3, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso_8859_3.

NAME 🖥️ iso_8859_3 🖥️

3 - ISO/IEC 8859-3 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-3 encodes the characters used in certain Southeast European languages.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-3 characters

The following table displays the characters in ISO/IEC 8859-3 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-3 is also known as Latin-3.

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

327 - Linux cli command EVP_CIPHER-RC5ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_CIPHER-RC5ssl and provides detailed information about the command EVP_CIPHER-RC5ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_CIPHER-RC5ssl.

NAME 🖥️ EVP_CIPHER-RC5ssl 🖥️

RC5 - The RC5 EVP_CIPHER implementations

DESCRIPTION

Support for RC5 symmetric encryption using the EVP_CIPHER API.

Disabled by default. Use the enable-rc5 configuration option to enable.

Algorithm Names

The following algorithms are available in the legacy provider:

“RC5-CBC” or “RC5”

“RC5-ECB”

“RC5-OFB”

“RC5-CFB”

Parameters

This implementation supports the parameters described in “PARAMETERS” in EVP_EncryptInit (3).

SEE ALSO

provider-cipher (7), OSSL_PROVIDER-legacy (7)

COPYRIGHT

Copyright 2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

328 - Linux cli command EVP_PKEY-X25519ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_PKEY-X25519ssl and provides detailed information about the command EVP_PKEY-X25519ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_PKEY-X25519ssl.

NAME 🖥️ EVP_PKEY-X25519ssl 🖥️

X25519, EVP_PKEY-X448, EVP_PKEY-ED25519, EVP_PKEY-ED448, EVP_KEYMGMT-X25519, EVP_KEYMGMT-X448, EVP_KEYMGMT-ED25519, EVP_KEYMGMT-ED448 - EVP_PKEY X25519, X448, ED25519 and ED448 keytype and algorithm support

DESCRIPTION

The X25519, X448, ED25519 and ED448 keytypes are implemented in OpenSSL’s default and FIPS providers. These implementations support the associated key, containing the public key pub and the private key priv.

Keygen Parameters

“dhkem-ikm” (OSSL_PKEY_PARAM_DHKEM_IKM) <octet string>
DHKEM requires the generation of a keypair using an input key material (seed). Use this to specify the key material used for generation of the private key. This value should not be reused for other purposes. It should have a length of at least 32 for X25519, and 56 for X448. This is only supported by X25519 and X448.

Use EVP_PKEY_CTX_set_params() after calling EVP_PKEY_keygen_init().

Common X25519, X448, ED25519 and ED448 parameters

In addition to the common parameters that all keytypes should support (see “Common parameters” in provider-keymgmt (7)), the implementation of these keytypes support the following.

“group” (OSSL_PKEY_PARAM_GROUP_NAME) <UTF8 string>
This is only supported by X25519 and X448. The group name must be “x25519” or “x448” respectively for those algorithms. This is only present for consistency with other key exchange algorithms and is typically not needed.

“pub” (OSSL_PKEY_PARAM_PUB_KEY) <octet string>
The public key value.

“priv” (OSSL_PKEY_PARAM_PRIV_KEY) <octet string>
The private key value.

“encoded-pub-key” (OSSL_PKEY_PARAM_ENCODED_PUBLIC_KEY) <octet string>
Used for getting and setting the encoding of a public key for the X25519 and X448 key types. Public keys are expected be encoded in a format as defined by RFC7748.

ED25519 and ED448 parameters

“mandatory-digest” (OSSL_PKEY_PARAM_MANDATORY_DIGEST) <UTF8 string>
The empty string, signifying that no digest may be specified.

CONFORMING TO

RFC 8032

RFC 8410

EXAMPLES

An EVP_PKEY context can be obtained by calling:

EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “X25519”, NULL); EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “X448”, NULL); EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “ED25519”, NULL); EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “ED448”, NULL);

An X25519 key can be generated like this:

pkey = EVP_PKEY_Q_keygen(NULL, NULL, “X25519”);

An X448, ED25519, or ED448 key can be generated likewise.

SEE ALSO

EVP_KEYMGMT (3), EVP_PKEY (3), provider-keymgmt (7), EVP_KEYEXCH-X25519 (7), EVP_KEYEXCH-X448 (7), EVP_SIGNATURE-ED25519 (7), EVP_SIGNATURE-ED448 (7)

COPYRIGHT

Copyright 2020-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

329 - Linux cli command RESET

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command RESET and provides detailed information about the command RESET, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the RESET.

NAME 🖥️ RESET 🖥️

restore the value of a run-time parameter to the default value

SYNOPSIS

RESET configuration_parameter
RESET ALL

DESCRIPTION

RESET restores run-time parameters to their default values. RESET is an alternative spelling for

SET configuration_parameter TO DEFAULT

Refer to SET(7) for details.

The default value is defined as the value that the parameter would have had, if no SET had ever been issued for it in the current session. The actual source of this value might be a compiled-in default, the configuration file, command-line options, or per-database or per-user default settings. This is subtly different from defining it as “the value that the parameter had at session start”, because if the value came from the configuration file, it will be reset to whatever is specified by the configuration file now. See Chapter 20 for details.

The transactional behavior of RESET is the same as SET: its effects will be undone by transaction rollback.

PARAMETERS

configuration_parameter

Name of a settable run-time parameter. Available parameters are documented in Chapter 20 and on the SET(7) reference page.

ALL

Resets all settable run-time parameters to default values.

EXAMPLES

Set the timezone configuration variable to its default value:

RESET timezone;

COMPATIBILITY

RESET is a PostgreSQL extension.

SEE ALSO

SET(7), SHOW(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

330 - Linux cli command EVP_PKEY-Poly1305ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_PKEY-Poly1305ssl and provides detailed information about the command EVP_PKEY-Poly1305ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_PKEY-Poly1305ssl.

NAME 🖥️ EVP_PKEY-Poly1305ssl 🖥️

HMAC, EVP_KEYMGMT-HMAC, EVP_PKEY-Siphash, EVP_KEYMGMT-Siphash, EVP_PKEY-Poly1305, EVP_KEYMGMT-Poly1305, EVP_PKEY-CMAC, EVP_KEYMGMT-CMAC - EVP_PKEY legacy MAC keytypes and algorithm support

DESCRIPTION

The HMAC and CMAC key types are implemented in OpenSSL’s default and FIPS providers. Additionally the Siphash and Poly1305 key types are implemented in the default provider. Performing MAC operations via an EVP_PKEY is considered legacy and are only available for backwards compatibility purposes and for a restricted set of algorithms. The preferred way of performing MAC operations is via the EVP_MAC APIs. See EVP_MAC_init (3).

For further details on using EVP_PKEY based MAC keys see EVP_SIGNATURE-HMAC (7), EVP_SIGNATURE-Siphash (7), EVP_SIGNATURE-Poly1305 (7) or EVP_SIGNATURE-CMAC (7).

Common MAC parameters

All the MAC keytypes support the following parameters.

“priv” (OSSL_PKEY_PARAM_PRIV_KEY) <octet string>
The MAC key value.

“properties” (OSSL_PKEY_PARAM_PROPERTIES) <UTF8 string>
A property query string to be used when any algorithms are fetched.

CMAC parameters

As well as the parameters described above, the CMAC keytype additionally supports the following parameters.

“cipher” (OSSL_PKEY_PARAM_CIPHER) <UTF8 string>
The name of a cipher to be used when generating the MAC.

“engine” (OSSL_PKEY_PARAM_ENGINE) <UTF8 string>
The name of an engine to be used for the specified cipher (if any).

Common MAC key generation parameters

MAC key generation is unusual in that no new key is actually generated. Instead a new provider side key object is created with the supplied raw key value. This is done for backwards compatibility with previous versions of OpenSSL.

“priv” (OSSL_PKEY_PARAM_PRIV_KEY) <octet string>
The MAC key value.

CMAC key generation parameters

In addition to the common MAC key generation parameters, the CMAC key generation additionally recognises the following.

“cipher” (OSSL_PKEY_PARAM_CIPHER) <UTF8 string>
The name of a cipher to be used when generating the MAC.

SEE ALSO

EVP_KEYMGMT (3), EVP_PKEY (3), provider-keymgmt (7)

COPYRIGHT

Copyright 2020 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

331 - Linux cli command life_cycle-kdfssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command life_cycle-kdfssl and provides detailed information about the command life_cycle-kdfssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the life_cycle-kdfssl.

NAME 🖥️ life_cycle-kdfssl 🖥️

kdf - The KDF algorithm life-cycle

DESCRIPTION

All key derivation functions (KDFs) and pseudo random functions (PRFs) go through a number of stages in their life-cycle:

start
This state represents the KDF/PRF before it has been allocated. It is the starting state for any life-cycle transitions.

newed
This state represents the KDF/PRF after it has been allocated.

deriving
This state represents the KDF/PRF when it is set up and capable of generating output.

freed
This state is entered when the KDF/PRF is freed. It is the terminal state for all life-cycle transitions.

State Transition Diagram

The usual life-cycle of a KDF/PRF is illustrated: +——————-+ | start | +——————-+ | | EVP_KDF_CTX_new v +——————-+ | newed | <+ +——————-+ | | | | EVP_KDF_derive | v | EVP_KDF_CTX_reset EVP_KDF_derive +——————-+ | + - - - - - - - - | | | ’ | deriving | | + - - - - - - - -> | | -+ +——————-+ | | EVP_KDF_CTX_free v +——————-+ | freed | +——————-+

Formal State Transitions

This section defines all of the legal state transitions. This is the canonical list. Function Call ————- Current State ————- start newed deriving freed EVP_KDF_CTX_new newed EVP_KDF_derive deriving deriving EVP_KDF_CTX_free freed freed freed EVP_KDF_CTX_reset newed newed EVP_KDF_CTX_get_params newed deriving EVP_KDF_CTX_set_params newed deriving EVP_KDF_CTX_gettable_params newed deriving EVP_KDF_CTX_settable_params newed deriving

NOTES

At some point the EVP layer will begin enforcing the transitions described herein.

SEE ALSO

provider-kdf (7), EVP_KDF (3).

HISTORY

The provider KDF interface was introduced in OpenSSL 3.0.

COPYRIGHT

Copyright 2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

332 - Linux cli command EVP_KEYMGMT-Siphashssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KEYMGMT-Siphashssl and provides detailed information about the command EVP_KEYMGMT-Siphashssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KEYMGMT-Siphashssl.

NAME 🖥️ EVP_KEYMGMT-Siphashssl 🖥️

HMAC, EVP_KEYMGMT-HMAC, EVP_PKEY-Siphash, EVP_KEYMGMT-Siphash, EVP_PKEY-Poly1305, EVP_KEYMGMT-Poly1305, EVP_PKEY-CMAC, EVP_KEYMGMT-CMAC - EVP_PKEY legacy MAC keytypes and algorithm support

DESCRIPTION

The HMAC and CMAC key types are implemented in OpenSSL’s default and FIPS providers. Additionally the Siphash and Poly1305 key types are implemented in the default provider. Performing MAC operations via an EVP_PKEY is considered legacy and are only available for backwards compatibility purposes and for a restricted set of algorithms. The preferred way of performing MAC operations is via the EVP_MAC APIs. See EVP_MAC_init (3).

For further details on using EVP_PKEY based MAC keys see EVP_SIGNATURE-HMAC (7), EVP_SIGNATURE-Siphash (7), EVP_SIGNATURE-Poly1305 (7) or EVP_SIGNATURE-CMAC (7).

Common MAC parameters

All the MAC keytypes support the following parameters.

“priv” (OSSL_PKEY_PARAM_PRIV_KEY) <octet string>
The MAC key value.

“properties” (OSSL_PKEY_PARAM_PROPERTIES) <UTF8 string>
A property query string to be used when any algorithms are fetched.

CMAC parameters

As well as the parameters described above, the CMAC keytype additionally supports the following parameters.

“cipher” (OSSL_PKEY_PARAM_CIPHER) <UTF8 string>
The name of a cipher to be used when generating the MAC.

“engine” (OSSL_PKEY_PARAM_ENGINE) <UTF8 string>
The name of an engine to be used for the specified cipher (if any).

Common MAC key generation parameters

MAC key generation is unusual in that no new key is actually generated. Instead a new provider side key object is created with the supplied raw key value. This is done for backwards compatibility with previous versions of OpenSSL.

“priv” (OSSL_PKEY_PARAM_PRIV_KEY) <octet string>
The MAC key value.

CMAC key generation parameters

In addition to the common MAC key generation parameters, the CMAC key generation additionally recognises the following.

“cipher” (OSSL_PKEY_PARAM_CIPHER) <UTF8 string>
The name of a cipher to be used when generating the MAC.

SEE ALSO

EVP_KEYMGMT (3), EVP_PKEY (3), provider-keymgmt (7)

COPYRIGHT

Copyright 2020 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

333 - Linux cli command x509ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command x509ssl and provides detailed information about the command x509ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the x509ssl.

NAME 🖥️ x509ssl 🖥️

X.509 certificate handling

SYNOPSIS

#include <openssl/x509.h>

DESCRIPTION

An X.509 certificate is a structured grouping of information about an individual, a device, or anything one can imagine. An X.509 CRL (certificate revocation list) is a tool to help determine if a certificate is still valid. The exact definition of those can be found in the X.509 document from ITU-T, or in RFC3280 from PKIX. In OpenSSL, the type X509 is used to express such a certificate, and the type X509_CRL is used to express a CRL.

A related structure is a certificate request, defined in PKCS#10 from RSA Security, Inc, also reflected in RFC2896. In OpenSSL, the type X509_REQ is used to express such a certificate request.

To handle some complex parts of a certificate, there are the types X509_NAME (to express a certificate name), X509_ATTRIBUTE (to express a certificate attribute), X509_EXTENSION (to express a certificate extension) and a few more.

Finally, there’s the supertype X509_INFO, which can contain a CRL, a certificate and a corresponding private key.

**X509_**XXX, **d2i_X509_**XXX, and **i2d_X509_**XXX functions handle X.509 certificates, with some exceptions, shown below.

**X509_CRL_**XXX, **d2i_X509_CRL_**XXX, and **i2d_X509_CRL_**XXX functions handle X.509 CRLs.

**X509_REQ_**XXX, **d2i_X509_REQ_**XXX, and **i2d_X509_REQ_**XXX functions handle PKCS#10 certificate requests.

**X509_NAME_**XXX functions handle certificate names.

**X509_ATTRIBUTE_**XXX functions handle certificate attributes.

**X509_EXTENSION_**XXX functions handle certificate extensions.

SEE ALSO

X509_NAME_ENTRY_get_object (3), X509_NAME_add_entry_by_txt (3), X509_NAME_add_entry_by_NID (3), X509_NAME_print_ex (3), X509_NAME_new (3), PEM_X509_INFO_read (3), d2i_X509 (3), d2i_X509_ALGOR (3), d2i_X509_CRL (3), d2i_X509_NAME (3), d2i_X509_REQ (3), d2i_X509_SIG (3), crypto (7)

COPYRIGHT

Copyright 2003-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

334 - Linux cli command arp

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command arp and provides detailed information about the command arp, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the arp.

NAME 🖥️ arp 🖥️

Linux ARP kernel module.

DESCRIPTION

This kernel protocol module implements the Address Resolution Protocol defined in RFC 826. It is used to convert between Layer2 hardware addresses and IPv4 protocol addresses on directly connected networks. The user normally doesn’t interact directly with this module except to configure it; instead it provides a service for other protocols in the kernel.

A user process can receive ARP packets by using packet(7) sockets. There is also a mechanism for managing the ARP cache in user-space by using netlink(7) sockets. The ARP table can also be controlled via ioctl(2) on any AF_INET socket.

The ARP module maintains a cache of mappings between hardware addresses and protocol addresses. The cache has a limited size so old and less frequently used entries are garbage-collected. Entries which are marked as permanent are never deleted by the garbage-collector. The cache can be directly manipulated by the use of ioctls and its behavior can be tuned by the /proc interfaces described below.

When there is no positive feedback for an existing mapping after some time (see the /proc interfaces below), a neighbor cache entry is considered stale. Positive feedback can be gotten from a higher layer; for example from a successful TCP ACK. Other protocols can signal forward progress using the MSG_CONFIRM flag to sendmsg(2). When there is no forward progress, ARP tries to reprobe. It first tries to ask a local arp daemon app_solicit times for an updated MAC address. If that fails and an old MAC address is known, a unicast probe is sent ucast_solicit times. If that fails too, it will broadcast a new ARP request to the network. Requests are sent only when there is data queued for sending.

Linux will automatically add a nonpermanent proxy arp entry when it receives a request for an address it forwards to and proxy arp is enabled on the receiving interface. When there is a reject route for the target, no proxy arp entry is added.

Ioctls

Three ioctls are available on all AF_INET sockets. They take a pointer to a struct arpreq as their argument.

struct arpreq {
    struct sockaddr arp_pa;      /* protocol address */
    struct sockaddr arp_ha;      /* hardware address */
    int             arp_flags;   /* flags */
    struct sockaddr arp_netmask; /* netmask of protocol address */
    char            arp_dev[16];
};

SIOCSARP, SIOCDARP and SIOCGARP respectively set, delete, and get an ARP mapping. Setting and deleting ARP maps are privileged operations and may be performed only by a process with the CAP_NET_ADMIN capability or an effective UID of 0.

arp_pa must be an AF_INET address and arp_ha must have the same type as the device which is specified in arp_dev. arp_dev is a zero-terminated string which names a device.

TABLE

If the ATF_NETMASK flag is set, then arp_netmask should be valid. Linux 2.2 does not support proxy network ARP entries, so this should be set to 0xffffffff, or 0 to remove an existing proxy arp entry. ATF_USETRAILERS is obsolete and should not be used.

/proc interfaces

ARP supports a range of /proc interfaces to configure parameters on a global or per-interface basis. The interfaces can be accessed by reading or writing the /proc/sys/net/ipv4/neigh/*/* files. Each interface in the system has its own directory in /proc/sys/net/ipv4/neigh/. The setting in the “default” directory is used for all newly created devices. Unless otherwise specified, time-related interfaces are specified in seconds.

anycast_delay (since Linux 2.2)
The maximum number of jiffies to delay before replying to a IPv6 neighbor solicitation message. Anycast support is not yet implemented. Defaults to 1 second.

app_solicit (since Linux 2.2)
The maximum number of probes to send to the user space ARP daemon via netlink before dropping back to multicast probes (see mcast_solicit). Defaults to 0.

base_reachable_time (since Linux 2.2)
Once a neighbor has been found, the entry is considered to be valid for at least a random value between base_reachable_time/2 and 3*base_reachable_time/2. An entry’s validity will be extended if it receives positive feedback from higher level protocols. Defaults to 30 seconds. This file is now obsolete in favor of base_reachable_time_ms.

base_reachable_time_ms (since Linux 2.6.12)
As for base_reachable_time, but measures time in milliseconds. Defaults to 30000 milliseconds.

delay_first_probe_time (since Linux 2.2)
Delay before first probe after it has been decided that a neighbor is stale. Defaults to 5 seconds.

gc_interval (since Linux 2.2)
How frequently the garbage collector for neighbor entries should attempt to run. Defaults to 30 seconds.

gc_stale_time (since Linux 2.2)
Determines how often to check for stale neighbor entries. When a neighbor entry is considered stale, it is resolved again before sending data to it. Defaults to 60 seconds.

gc_thresh1 (since Linux 2.2)
The minimum number of entries to keep in the ARP cache. The garbage collector will not run if there are fewer than this number of entries in the cache. Defaults to 128.

gc_thresh2 (since Linux 2.2)
The soft maximum number of entries to keep in the ARP cache. The garbage collector will allow the number of entries to exceed this for 5 seconds before collection will be performed. Defaults to 512.

gc_thresh3 (since Linux 2.2)
The hard maximum number of entries to keep in the ARP cache. The garbage collector will always run if there are more than this number of entries in the cache. Defaults to 1024.

locktime (since Linux 2.2)
The minimum number of jiffies to keep an ARP entry in the cache. This prevents ARP cache thrashing if there is more than one potential mapping (generally due to network misconfiguration). Defaults to 1 second.

mcast_solicit (since Linux 2.2)
The maximum number of attempts to resolve an address by multicast/broadcast before marking the entry as unreachable. Defaults to 3.

proxy_delay (since Linux 2.2)
When an ARP request for a known proxy-ARP address is received, delay up to proxy_delay jiffies before replying. This is used to prevent network flooding in some cases. Defaults to 0.8 seconds.

proxy_qlen (since Linux 2.2)
The maximum number of packets which may be queued to proxy-ARP addresses. Defaults to 64.

retrans_time (since Linux 2.2)
The number of jiffies to delay before retransmitting a request. Defaults to 1 second. This file is now obsolete in favor of retrans_time_ms.

retrans_time_ms (since Linux 2.6.12)
The number of milliseconds to delay before retransmitting a request. Defaults to 1000 milliseconds.

ucast_solicit (since Linux 2.2)
The maximum number of attempts to send unicast probes before asking the ARP daemon (see app_solicit). Defaults to 3.

unres_qlen (since Linux 2.2)
The maximum number of packets which may be queued for each unresolved address by other network layers. Defaults to 3.

VERSIONS

The struct arpreq changed in Linux 2.0 to include the arp_dev member and the ioctl numbers changed at the same time. Support for the old ioctls was dropped in Linux 2.2.

Support for proxy arp entries for networks (netmask not equal 0xffffffff) was dropped in Linux 2.2. It is replaced by automatic proxy arp setup by the kernel for all reachable hosts on other interfaces (when forwarding and proxy arp is enabled for the interface).

The neigh/* interfaces did not exist before Linux 2.2.

BUGS

Some timer settings are specified in jiffies, which is architecture- and kernel version-dependent; see time(7).

There is no way to signal positive feedback from user space. This means connection-oriented protocols implemented in user space will generate excessive ARP traffic, because ndisc will regularly reprobe the MAC address. The same problem applies for some kernel protocols (e.g., NFS over UDP).

This man page mashes together functionality that is IPv4-specific with functionality that is shared between IPv4 and IPv6.

SEE ALSO

capabilities(7), ip(7), arpd(8)

RFC 826 for a description of ARP. RFC 2461 for a description of IPv6 neighbor discovery and the base algorithms used. Linux 2.2+ IPv4 ARP uses the IPv6 algorithms when applicable.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

335 - Linux cli command DEALLOCATE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DEALLOCATE and provides detailed information about the command DEALLOCATE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DEALLOCATE.

NAME 🖥️ DEALLOCATE 🖥️

deallocate a prepared statement

SYNOPSIS

DEALLOCATE [ PREPARE ] { name | ALL }

DESCRIPTION

DEALLOCATE is used to deallocate a previously prepared SQL statement. If you do not explicitly deallocate a prepared statement, it is deallocated when the session ends.

For more information on prepared statements, see PREPARE(7).

PARAMETERS

PREPARE

This key word is ignored.

name

The name of the prepared statement to deallocate.

ALL

Deallocate all prepared statements.

COMPATIBILITY

The SQL standard includes a DEALLOCATE statement, but it is only for use in embedded SQL.

SEE ALSO

EXECUTE(7), PREPARE(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

336 - Linux cli command DROP_EVENT_TRIGGER

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_EVENT_TRIGGER and provides detailed information about the command DROP_EVENT_TRIGGER, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_EVENT_TRIGGER.

NAME 🖥️ DROP_EVENT_TRIGGER 🖥️

remove an event trigger

SYNOPSIS

DROP EVENT TRIGGER [ IF EXISTS ] name [ CASCADE | RESTRICT ]

DESCRIPTION

DROP EVENT TRIGGER removes an existing event trigger. To execute this command, the current user must be the owner of the event trigger.

PARAMETERS

IF EXISTS

Do not throw an error if the event trigger does not exist. A notice is issued in this case.

name

The name of the event trigger to remove.

CASCADE

Automatically drop objects that depend on the trigger, and in turn all objects that depend on those objects (see Section 5.14).

RESTRICT

Refuse to drop the trigger if any objects depend on it. This is the default.

EXAMPLES

Destroy the trigger snitch:

DROP EVENT TRIGGER snitch;

COMPATIBILITY

There is no DROP EVENT TRIGGER statement in the SQL standard.

SEE ALSO

CREATE EVENT TRIGGER (CREATE_EVENT_TRIGGER(7)), ALTER EVENT TRIGGER (ALTER_EVENT_TRIGGER(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

337 - Linux cli command attributes

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command attributes and provides detailed information about the command attributes, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the attributes.

NAME 🖥️ attributes 🖥️

POSIX safety concepts

DESCRIPTION

Note: the text of this man page is based on the material taken from the “POSIX Safety Concepts” section of the GNU C Library manual. Further details on the topics described here can be found in that manual.

Various function manual pages include a section ATTRIBUTES that describes the safety of calling the function in various contexts. This section annotates functions with the following safety markings:

MT-Safe
MT-Safe or Thread-Safe functions are safe to call in the presence of other threads. MT, in MT-Safe, stands for Multi Thread.

Being MT-Safe does not imply a function is atomic, nor that it uses any of the memory synchronization mechanisms POSIX exposes to users. It is even possible that calling MT-Safe functions in sequence does not yield an MT-Safe combination. For example, having a thread call two MT-Safe functions one right after the other does not guarantee behavior equivalent to atomic execution of a combination of both functions, since concurrent calls in other threads may interfere in a destructive way.

Whole-program optimizations that could inline functions across library interfaces may expose unsafe reordering, and so performing inlining across the GNU C Library interface is not recommended. The documented MT-Safety status is not guaranteed under whole-program optimization. However, functions defined in user-visible headers are designed to be safe for inlining.

MT-Unsafe
MT-Unsafe functions are not safe to call in a multithreaded programs.

Other keywords that appear in safety notes are defined in subsequent sections.

Conditionally safe features

For some features that make functions unsafe to call in certain contexts, there are known ways to avoid the safety problem other than refraining from calling the function altogether. The keywords that follow refer to such features, and each of their definitions indicates how the whole program needs to be constrained in order to remove the safety problem indicated by the keyword. Only when all the reasons that make a function unsafe are observed and addressed, by applying the documented constraints, does the function become safe to call in a context.

init
Functions marked with init as an MT-Unsafe feature perform MT-Unsafe initialization when they are first called.

Calling such a function at least once in single-threaded mode removes this specific cause for the function to be regarded as MT-Unsafe. If no other cause for that remains, the function can then be safely called after other threads are started.

race
Functions annotated with race as an MT-Safety issue operate on objects in ways that may cause data races or similar forms of destructive interference out of concurrent execution. In some cases, the objects are passed to the functions by users; in others, they are used by the functions to return values to users; in others, they are not even exposed to users.

const
Functions marked with const as an MT-Safety issue non-atomically modify internal objects that are better regarded as constant, because a substantial portion of the GNU C Library accesses them without synchronization. Unlike race, which causes both readers and writers of internal objects to be regarded as MT-Unsafe, this mark is applied to writers only. Writers remain MT-Unsafe to call, but the then-mandatory constness of objects they modify enables readers to be regarded as MT-Safe (as long as no other reasons for them to be unsafe remain), since the lack of synchronization is not a problem when the objects are effectively constant.

The identifier that follows the const mark will appear by itself as a safety note in readers. Programs that wish to work around this safety issue, so as to call writers, may use a non-recursive read-write lock associated with the identifier, and guard all calls to functions marked with const followed by the identifier with a write lock, and all calls to functions marked with the identifier by itself with a read lock.

sig
Functions marked with sig as a MT-Safety issue may temporarily install a signal handler for internal purposes, which may interfere with other uses of the signal, identified after a colon.

This safety problem can be worked around by ensuring that no other uses of the signal will take place for the duration of the call. Holding a non-recursive mutex while calling all functions that use the same temporary signal; blocking that signal before the call and resetting its handler afterwards is recommended.

term
Functions marked with term as an MT-Safety issue may change the terminal settings in the recommended way, namely: call tcgetattr(3), modify some flags, and then call tcsetattr(3), this creates a window in which changes made by other threads are lost. Thus, functions marked with term are MT-Unsafe.

It is thus advisable for applications using the terminal to avoid concurrent and reentrant interactions with it, by not using it in signal handlers or blocking signals that might use it, and holding a lock while calling these functions and interacting with the terminal. This lock should also be used for mutual exclusion with functions marked with race:tcattr(fd), where fd is a file descriptor for the controlling terminal. The caller may use a single mutex for simplicity, or use one mutex per terminal, even if referenced by different file descriptors.

Other safety remarks

Additional keywords may be attached to functions, indicating features that do not make a function unsafe to call, but that may need to be taken into account in certain classes of programs:

locale
Functions annotated with locale as an MT-Safety issue read from the locale object without any form of synchronization. Functions annotated with locale called concurrently with locale changes may behave in ways that do not correspond to any of the locales active during their execution, but an unpredictable mix thereof.

We do not mark these functions as MT-Unsafe, however, because functions that modify the locale object are marked with const:locale and regarded as unsafe. Being unsafe, the latter are not to be called when multiple threads are running or asynchronous signals are enabled, and so the locale can be considered effectively constant in these contexts, which makes the former safe.

env
Functions marked with env as an MT-Safety issue access the environment with getenv(3) or similar, without any guards to ensure safety in the presence of concurrent modifications.

We do not mark these functions as MT-Unsafe, however, because functions that modify the environment are all marked with const:env and regarded as unsafe. Being unsafe, the latter are not to be called when multiple threads are running or asynchronous signals are enabled, and so the environment can be considered effectively constant in these contexts, which makes the former safe.

hostid
The function marked with hostid as an MT-Safety issue reads from the system-wide data structures that hold the “host ID” of the machine. These data structures cannot generally be modified atomically. Since it is expected that the “host ID” will not normally change, the function that reads from it (gethostid(3)) is regarded as safe, whereas the function that modifies it (sethostid(3)) is marked with const:hostid, indicating it may require special care if it is to be called. In this specific case, the special care amounts to system-wide (not merely intra-process) coordination.

sigintr
Functions marked with sigintr as an MT-Safety issue access the GNU C Library _sigintr internal data structure without any guards to ensure safety in the presence of concurrent modifications.

We do not mark these functions as MT-Unsafe, however, because functions that modify this data structure are all marked with const:sigintr and regarded as unsafe. Being unsafe, the latter are not to be called when multiple threads are running or asynchronous signals are enabled, and so the data structure can be considered effectively constant in these contexts, which makes the former safe.

cwd
Functions marked with cwd as an MT-Safety issue may temporarily change the current working directory during their execution, which may cause relative pathnames to be resolved in unexpected ways in other threads or within asynchronous signal or cancelation handlers.

This is not enough of a reason to mark so-marked functions as MT-Unsafe, but when this behavior is optional (e.g., nftw(3) with FTW_CHDIR), avoiding the option may be a good alternative to using full pathnames or file descriptor-relative (e.g., openat(2)) system calls.

:identifier
Annotations may sometimes be followed by identifiers, intended to group several functions that, for example, access the data structures in an unsafe way, as in race and const, or to provide more specific information, such as naming a signal in a function marked with sig. It is envisioned that it may be applied to lock and corrupt as well in the future.

In most cases, the identifier will name a set of functions, but it may name global objects or function arguments, or identifiable properties or logical components associated with them, with a notation such as, for example, :buf(arg) to denote a buffer associated with the argument arg, or :tcattr(fd) to denote the terminal attributes of a file descriptor fd.

The most common use for identifiers is to provide logical groups of functions and arguments that need to be protected by the same synchronization primitive in order to ensure safe operation in a given context.

/condition
Some safety annotations may be conditional, in that they only apply if a boolean expression involving arguments, global variables or even the underlying kernel evaluates to true. For example, /!ps and /one_per_line indicate the preceding marker only applies when argument ps is NULL, or global variable one_per_line is nonzero.

When all marks that render a function unsafe are adorned with such conditions, and none of the named conditions hold, then the function can be regarded as safe.

SEE ALSO

pthreads(7), signal-safety(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

338 - Linux cli command EVP_PKEY-DHXssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_PKEY-DHXssl and provides detailed information about the command EVP_PKEY-DHXssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_PKEY-DHXssl.

NAME 🖥️ EVP_PKEY-DHXssl 🖥️

DH, EVP_PKEY-DHX, EVP_KEYMGMT-DH, EVP_KEYMGMT-DHX - EVP_PKEY DH and DHX keytype and algorithm support

DESCRIPTION

For DH FFC key agreement, two classes of domain parameters can be used: “safe” domain parameters that are associated with approved named safe-prime groups, and a class of “FIPS186-type” domain parameters. FIPS186-type domain parameters should only be used for backward compatibility with existing applications that cannot be upgraded to use the approved safe-prime groups.

See EVP_PKEY-FFC (7) for more information about FFC keys.

The DH key type uses PKCS#3 format which saves p and g, but not the q value. The DHX key type uses X9.42 format which saves the value of q and this must be used for FIPS186-4. If key validation is required, users should be aware of the nuances associated with FIPS186-4 style parameters as discussed in “DH key validation”.

DH and DHX domain parameters

In addition to the common FCC parameters that all FFC keytypes should support (see “FFC parameters” in EVP_PKEY-FFC (7)) the DHX and DH keytype implementations support the following:

“group” (OSSL_PKEY_PARAM_GROUP_NAME) <UTF8 string>
Sets or gets a string that associates a DH or DHX named safe prime group with known values for p, q and g. The following values can be used by the OpenSSL’s default and FIPS providers: “ffdhe2048”, “ffdhe3072”, “ffdhe4096”, “ffdhe6144”, “ffdhe8192”, “modp_2048”, “modp_3072”, “modp_4096”, “modp_6144”, “modp_8192”. The following additional values can also be used by OpenSSL’s default provider: “modp_1536”, “dh_1024_160”, “dh_2048_224”, “dh_2048_256”. DH/DHX named groups can be easily validated since the parameters are well known. For protocols that only transfer p and g the value of q can also be retrieved.

DH and DHX additional parameters

“encoded-pub-key” (OSSL_PKEY_PARAM_ENCODED_PUBLIC_KEY) <octet string>
Used for getting and setting the encoding of the DH public key used in a key exchange message for the TLS protocol. See EVP_PKEY_set1_encoded_public_key() and EVP_PKEY_get1_encoded_public_key().

DH additional domain parameters

“safeprime-generator” (OSSL_PKEY_PARAM_DH_GENERATOR) <integer>
Used for DH generation of safe primes using the old safe prime generator code. The default value is 2. It is recommended to use a named safe prime group instead, if domain parameter validation is required. Randomly generated safe primes are not allowed by FIPS, so setting this value for the OpenSSL FIPS provider will instead choose a named safe prime group based on the size of p.

DH and DHX domain parameter / key generation parameters

In addition to the common FFC key generation parameters that all FFC key types should support (see “FFC key generation parameters” in EVP_PKEY-FFC (7)) the DH and DHX keytype implementation supports the following:

“type” (OSSL_PKEY_PARAM_FFC_TYPE) <UTF8 string>
Sets the type of parameter generation. For DH valid values are:

“fips186_4”

“default”

“fips186_2”

These are described in “FFC key generation parameters” in EVP_PKEY-FFC (7)

“group”
This specifies that a named safe prime name will be chosen using the “pbits” type.

“generator”
A safe prime generator. See the “safeprime-generator” type above. This is only valid for DH keys.

“pbits” (OSSL_PKEY_PARAM_FFC_PBITS) <unsigned integer>
Sets the size (in bits) of the prime ‘p’. For “fips186_4” this must be 2048. For “fips186_2” this must be 1024. For “group” this can be any one of 2048, 3072, 4096, 6144 or 8192.

“priv_len” (OSSL_PKEY_PARAM_DH_PRIV_LEN) <integer>
An optional value to set the maximum length of the generated private key. The default value used if this is not set is the maximum value of BN_num_bits(q)). The minimum value that this can be set to is 2 * s. Where s is the security strength of the key which has values of 112, 128, 152, 176 and 200 for key sizes of 2048, 3072, 4096, 6144 and 8192.

DH key validation

For DHX that is not a named group the FIPS186-4 standard specifies that the values used for FFC parameter generation are also required for parameter validation. This means that optional FFC domain parameter values for seed, pcounter and gindex or hindex may need to be stored for validation purposes. For DHX the seed and pcounter can be stored in ASN1 data (but the gindex or hindex cannot be stored). It is recommended to use a named safe prime group instead.

For DH keys, EVP_PKEY_param_check (3) behaves in the following way: The OpenSSL FIPS provider tests if the parameters are either an approved safe prime group OR that the FFC parameters conform to FIPS186-4 as defined in SP800-56Ar3 Assurances of Domain-Parameter Validity. The OpenSSL default provider uses simpler checks that allows there to be no q value for backwards compatibility.

For DH keys, EVP_PKEY_param_check_quick (3) is equivalent to EVP_PKEY_param_check (3).

For DH keys, EVP_PKEY_public_check (3) conforms to SP800-56Ar3 FFC Full Public-Key Validation.

For DH keys, EVP_PKEY_public_check_quick (3) conforms to SP800-56Ar3 FFC Partial Public-Key Validation when the DH key is an approved named safe prime group, otherwise it is the same as EVP_PKEY_public_check (3).

For DH Keys, EVP_PKEY_private_check (3) tests that the private key is in the correct range according to SP800-56Ar3. The OpenSSL FIPS provider requires the value of q to be set (note that this is set for named safe prime groups). For backwards compatibility the OpenSSL default provider only requires p to be set.

For DH keys, EVP_PKEY_pairwise_check (3) conforms to SP800-56Ar3 Owner Assurance of Pair-wise Consistency.

EXAMPLES

An EVP_PKEY context can be obtained by calling:

EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “DH”, NULL);

A DH key can be generated with a named safe prime group by calling:

int priv_len = 2 * 112; OSSL_PARAM params[3]; EVP_PKEY *pkey = NULL; EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “DH”, NULL); params[0] = OSSL_PARAM_construct_utf8_string(“group”, “ffdhe2048”, 0); /* “priv_len” is optional */ params[1] = OSSL_PARAM_construct_int(“priv_len”, &priv_len); params[2] = OSSL_PARAM_construct_end(); EVP_PKEY_keygen_init(pctx); EVP_PKEY_CTX_set_params(pctx, params); EVP_PKEY_generate(pctx, &pkey); … EVP_PKEY_free(pkey); EVP_PKEY_CTX_free(pctx);

DHX domain parameters can be generated according to FIPS186-4 by calling:

int gindex = 2; unsigned int pbits = 2048; unsigned int qbits = 256; OSSL_PARAM params[6]; EVP_PKEY *param_key = NULL; EVP_PKEY_CTX *pctx = NULL; pctx = EVP_PKEY_CTX_new_from_name(NULL, “DHX”, NULL); EVP_PKEY_paramgen_init(pctx); params[0] = OSSL_PARAM_construct_uint(“pbits”, &pbits); params[1] = OSSL_PARAM_construct_uint(“qbits”, &qbits); params[2] = OSSL_PARAM_construct_int(“gindex”, &gindex); params[3] = OSSL_PARAM_construct_utf8_string(“type”, “fips186_4”, 0); params[4] = OSSL_PARAM_construct_utf8_string(“digest”, “SHA256”, 0); params[5] = OSSL_PARAM_construct_end(); EVP_PKEY_CTX_set_params(pctx, params); EVP_PKEY_generate(pctx, &param_key); EVP_PKEY_print_params(bio_out, param_key, 0, NULL); … EVP_PKEY_free(param_key); EVP_PKEY_CTX_free(pctx);

A DH key can be generated using domain parameters by calling:

EVP_PKEY *key = NULL; EVP_PKEY_CTX *gctx = EVP_PKEY_CTX_new_from_pkey(NULL, param_key, NULL); EVP_PKEY_keygen_init(gctx); EVP_PKEY_generate(gctx, &key); EVP_PKEY_print_private(bio_out, key, 0, NULL); … EVP_PKEY_free(key); EVP_PKEY_CTX_free(gctx);

To validate FIPS186-4 DHX domain parameters decoded from PEM or DER data, additional values used during generation may be required to be set into the key.

EVP_PKEY_todata(), OSSL_PARAM_merge(), and EVP_PKEY_fromdata() are useful to add these parameters to the original key or domain parameters before the actual validation. In production code the return values should be checked.

EVP_PKEY *received_domp = …; /* parameters received and decoded */ unsigned char *seed = …; /* and additional parameters received */ size_t seedlen = …; /* by other means, required */ int gindex = …; /* for the validation */ int pcounter = …; int hindex = …; OSSL_PARAM extra_params[4]; OSSL_PARAM *domain_params = NULL; OSSL_PARAM *merged_params = NULL; EVP_PKEY_CTX *ctx = NULL, *validate_ctx = NULL; EVP_PKEY *complete_domp = NULL; EVP_PKEY_todata(received_domp, OSSL_KEYMGMT_SELECT_DOMAIN_PARAMETERS, &domain_params); extra_params[0] = OSSL_PARAM_construct_octet_string(“seed”, seed, seedlen); /* * NOTE: For unverifiable g use “hindex” instead of “gindex” * extra_params[1] = OSSL_PARAM_construct_int(“hindex”, &hindex); */ extra_params[1] = OSSL_PARAM_construct_int(“gindex”, &gindex); extra_params[2] = OSSL_PARAM_construct_int(“pcounter”, &pcounter); extra_params[3] = OSSL_PARAM_construct_end(); merged_params = OSSL_PARAM_merge(domain_params, extra_params); ctx = EVP_PKEY_CTX_new_from_name(NULL, “DHX”, NULL); EVP_PKEY_fromdata_init(ctx); EVP_PKEY_fromdata(ctx, &complete_domp, OSSL_KEYMGMT_SELECT_ALL, merged_params); validate_ctx = EVP_PKEY_CTX_new_from_pkey(NULL, complete_domp, NULL); if (EVP_PKEY_param_check(validate_ctx) > 0) /* validation_passed(); */ else /* validation_failed(); */ OSSL_PARAM_free(domain_params); OSSL_PARAM_free(merged_params); EVP_PKEY_CTX_free(ctx); EVP_PKEY_CTX_free(validate_ctx); EVP_PKEY_free(complete_domp);

CONFORMING TO

RFC 7919 (TLS ffdhe named safe prime groups)

RFC 3526 (IKE modp named safe prime groups)

RFC 5114 (Additional DH named groups for dh_1024_160", “dh_2048_224” and “dh_2048_256”).

The following sections of SP800-56Ar3:

Appendix D: FFC Safe-prime Groups

The following sections of FIPS186-4:

SEE ALSO

EVP_PKEY-FFC (7), EVP_KEYEXCH-DH (7) EVP_PKEY (3), provider-keymgmt (7), EVP_KEYMGMT (3), OSSL_PROVIDER-default (7), OSSL_PROVIDER-FIPS (7)

COPYRIGHT

Copyright 2020-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

339 - Linux cli command SM2ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command SM2ssl and provides detailed information about the command SM2ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the SM2ssl.

NAME 🖥️ SM2ssl 🖥️

SM2, EVP_KEYMGMT-SM2, SM2 - EVP_PKEY keytype support for the Chinese SM2 signature and encryption algorithms

DESCRIPTION

The SM2 algorithm was first defined by the Chinese national standard GM/T 0003-2012 and was later standardized by ISO as ISO/IEC 14888. SM2 is actually an elliptic curve based algorithm. The current implementation in OpenSSL supports both signature and encryption schemes via the EVP interface.

When doing the SM2 signature algorithm, it requires a distinguishing identifier to form the message prefix which is hashed before the real message is hashed.

Common SM2 parameters

SM2 uses the parameters defined in “Common EC parameters” in EVP_PKEY-EC (7). The following parameters are different:

“cofactor” (OSSL_PKEY_PARAM_EC_COFACTOR) <unsigned integer>
This parameter is ignored for SM2.

(OSSL_PKEY_PARAM_DEFAULT_DIGEST) <UTF8 string>
Getter that returns the default digest name. (Currently returns “SM3” as of OpenSSL 3.0).

NOTES

SM2 signatures can be generated by using the ‘DigestSign’ series of APIs, for instance, EVP_DigestSignInit(), EVP_DigestSignUpdate() and EVP_DigestSignFinal(). Ditto for the verification process by calling the ‘DigestVerify’ series of APIs. Note that the SM2 algorithm requires the presence of the public key for signatures, as such the OSSL_PKEY_PARAM_PUB_KEY option must be set on any key used in signature generation.

Before computing an SM2 signature, an EVP_PKEY_CTX needs to be created, and an SM2 ID must be set for it, like this:

EVP_PKEY_CTX_set1_id(pctx, id, id_len);

Before calling the EVP_DigestSignInit() or EVP_DigestVerifyInit() functions, that EVP_PKEY_CTX should be assigned to the EVP_MD_CTX, like this:

EVP_MD_CTX_set_pkey_ctx(mctx, pctx);

There is normally no need to pass a pctx parameter to EVP_DigestSignInit() or EVP_DigestVerifyInit() in such a scenario.

SM2 can be tested with the openssl-speed (1) application since version 3.0. Currently, the only valid algorithm name is sm2.

Since version 3.0, SM2 keys can be generated and loaded only when the domain parameters specify the SM2 elliptic curve.

EXAMPLES

This example demonstrates the calling sequence for using an EVP_PKEY to verify a message with the SM2 signature algorithm and the SM3 hash algorithm:

#include <openssl/evp.h> /* obtain an EVP_PKEY using whatever methods… */ mctx = EVP_MD_CTX_new(); pctx = EVP_PKEY_CTX_new(pkey, NULL); EVP_PKEY_CTX_set1_id(pctx, id, id_len); EVP_MD_CTX_set_pkey_ctx(mctx, pctx); EVP_DigestVerifyInit(mctx, NULL, EVP_sm3(), NULL, pkey); EVP_DigestVerifyUpdate(mctx, msg, msg_len); EVP_DigestVerifyFinal(mctx, sig, sig_len)

SEE ALSO

EVP_PKEY_CTX_new (3), EVP_DigestSignInit (3), EVP_DigestVerifyInit (3), EVP_PKEY_CTX_set1_id (3), EVP_MD_CTX_set_pkey_ctx (3)

COPYRIGHT

Copyright 2018-2024 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

340 - Linux cli command ALTER_TEXT_SEARCH_TEMPLATE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_TEXT_SEARCH_TEMPLATE and provides detailed information about the command ALTER_TEXT_SEARCH_TEMPLATE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_TEXT_SEARCH_TEMPLATE.

NAME 🖥️ ALTER_TEXT_SEARCH_TEMPLATE 🖥️

change the definition of a text search template

SYNOPSIS

ALTER TEXT SEARCH TEMPLATE name RENAME TO new_name
ALTER TEXT SEARCH TEMPLATE name SET SCHEMA new_schema

DESCRIPTION

ALTER TEXT SEARCH TEMPLATE changes the definition of a text search template. Currently, the only supported functionality is to change the templates name.

You must be a superuser to use ALTER TEXT SEARCH TEMPLATE.

PARAMETERS

name

The name (optionally schema-qualified) of an existing text search template.

new_name

The new name of the text search template.

new_schema

The new schema for the text search template.

COMPATIBILITY

There is no ALTER TEXT SEARCH TEMPLATE statement in the SQL standard.

SEE ALSO

CREATE TEXT SEARCH TEMPLATE (CREATE_TEXT_SEARCH_TEMPLATE(7)), DROP TEXT SEARCH TEMPLATE (DROP_TEXT_SEARCH_TEMPLATE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

341 - Linux cli command EVP_KEYMGMT-ED448ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KEYMGMT-ED448ssl and provides detailed information about the command EVP_KEYMGMT-ED448ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KEYMGMT-ED448ssl.

NAME 🖥️ EVP_KEYMGMT-ED448ssl 🖥️

X25519, EVP_PKEY-X448, EVP_PKEY-ED25519, EVP_PKEY-ED448, EVP_KEYMGMT-X25519, EVP_KEYMGMT-X448, EVP_KEYMGMT-ED25519, EVP_KEYMGMT-ED448 - EVP_PKEY X25519, X448, ED25519 and ED448 keytype and algorithm support

DESCRIPTION

The X25519, X448, ED25519 and ED448 keytypes are implemented in OpenSSL’s default and FIPS providers. These implementations support the associated key, containing the public key pub and the private key priv.

Keygen Parameters

“dhkem-ikm” (OSSL_PKEY_PARAM_DHKEM_IKM) <octet string>
DHKEM requires the generation of a keypair using an input key material (seed). Use this to specify the key material used for generation of the private key. This value should not be reused for other purposes. It should have a length of at least 32 for X25519, and 56 for X448. This is only supported by X25519 and X448.

Use EVP_PKEY_CTX_set_params() after calling EVP_PKEY_keygen_init().

Common X25519, X448, ED25519 and ED448 parameters

In addition to the common parameters that all keytypes should support (see “Common parameters” in provider-keymgmt (7)), the implementation of these keytypes support the following.

“group” (OSSL_PKEY_PARAM_GROUP_NAME) <UTF8 string>
This is only supported by X25519 and X448. The group name must be “x25519” or “x448” respectively for those algorithms. This is only present for consistency with other key exchange algorithms and is typically not needed.

“pub” (OSSL_PKEY_PARAM_PUB_KEY) <octet string>
The public key value.

“priv” (OSSL_PKEY_PARAM_PRIV_KEY) <octet string>
The private key value.

“encoded-pub-key” (OSSL_PKEY_PARAM_ENCODED_PUBLIC_KEY) <octet string>
Used for getting and setting the encoding of a public key for the X25519 and X448 key types. Public keys are expected be encoded in a format as defined by RFC7748.

ED25519 and ED448 parameters

“mandatory-digest” (OSSL_PKEY_PARAM_MANDATORY_DIGEST) <UTF8 string>
The empty string, signifying that no digest may be specified.

CONFORMING TO

RFC 8032

RFC 8410

EXAMPLES

An EVP_PKEY context can be obtained by calling:

EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “X25519”, NULL); EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “X448”, NULL); EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “ED25519”, NULL); EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “ED448”, NULL);

An X25519 key can be generated like this:

pkey = EVP_PKEY_Q_keygen(NULL, NULL, “X25519”);

An X448, ED25519, or ED448 key can be generated likewise.

SEE ALSO

EVP_KEYMGMT (3), EVP_PKEY (3), provider-keymgmt (7), EVP_KEYEXCH-X25519 (7), EVP_KEYEXCH-X448 (7), EVP_SIGNATURE-ED25519 (7), EVP_SIGNATURE-ED448 (7)

COPYRIGHT

Copyright 2020-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

342 - Linux cli command EVP_KEYMGMT-DSAssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KEYMGMT-DSAssl and provides detailed information about the command EVP_KEYMGMT-DSAssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KEYMGMT-DSAssl.

NAME 🖥️ EVP_KEYMGMT-DSAssl 🖥️

DSA, EVP_KEYMGMT-DSA - EVP_PKEY DSA keytype and algorithm support

DESCRIPTION

For DSA the FIPS186-4 standard specifies that the values used for FFC parameter generation are also required for parameter validation. This means that optional FFC domain parameter values for seed, pcounter and gindex may need to be stored for validation purposes. For DSA these fields are not stored in the ASN1 data so they need to be stored externally if validation is required.

DSA parameters

The DSA key type supports the FFC parameters (see “FFC parameters” in EVP_PKEY-FFC (7)).

DSA key generation parameters

The DSA key type supports the FFC key generation parameters (see “FFC key generation parameters” in EVP_PKEY-FFC (7)

The following restrictions apply to the “pbits” field:

For “fips186_4” this must be either 2048 or 3072. For “fips186_2” this must be 1024. For “group” this can be any one of 2048, 3072, 4096, 6144 or 8192.

DSA key validation

For DSA keys, EVP_PKEY_param_check (3) behaves in the following way: The OpenSSL FIPS provider conforms to the rules within the FIPS186-4 standard for FFC parameter validation. For backwards compatibility the OpenSSL default provider uses a much simpler check (see below) for parameter validation, unless the seed parameter is set.

For DSA keys, EVP_PKEY_param_check_quick (3) behaves in the following way: A simple check of L and N and partial g is performed. The default provider also supports validation of legacy “fips186_2” keys.

For DSA keys, EVP_PKEY_public_check (3), EVP_PKEY_private_check (3) and EVP_PKEY_pairwise_check (3) the OpenSSL default and FIPS providers conform to the rules within SP800-56Ar3 for public, private and pairwise tests respectively.

EXAMPLES

An EVP_PKEY context can be obtained by calling:

EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “DSA”, NULL);

The DSA domain parameters can be generated by calling:

unsigned int pbits = 2048; unsigned int qbits = 256; int gindex = 1; OSSL_PARAM params[5]; EVP_PKEY *param_key = NULL; EVP_PKEY_CTX *pctx = NULL; pctx = EVP_PKEY_CTX_new_from_name(NULL, “DSA”, NULL); EVP_PKEY_paramgen_init(pctx); params[0] = OSSL_PARAM_construct_uint(“pbits”, &pbits); params[1] = OSSL_PARAM_construct_uint(“qbits”, &qbits); params[2] = OSSL_PARAM_construct_int(“gindex”, &gindex); params[3] = OSSL_PARAM_construct_utf8_string(“digest”, “SHA384”, 0); params[4] = OSSL_PARAM_construct_end(); EVP_PKEY_CTX_set_params(pctx, params); EVP_PKEY_generate(pctx, &param_key); EVP_PKEY_CTX_free(pctx); EVP_PKEY_print_params(bio_out, param_key, 0, NULL);

A DSA key can be generated using domain parameters by calling:

EVP_PKEY *key = NULL; EVP_PKEY_CTX *gctx = NULL; gctx = EVP_PKEY_CTX_new_from_pkey(NULL, param_key, NULL); EVP_PKEY_keygen_init(gctx); EVP_PKEY_generate(gctx, &key); EVP_PKEY_CTX_free(gctx); EVP_PKEY_print_private(bio_out, key, 0, NULL);

CONFORMING TO

The following sections of FIPS186-4:

SEE ALSO

EVP_PKEY-FFC (7), EVP_SIGNATURE-DSA (7) EVP_PKEY (3), provider-keymgmt (7), EVP_KEYMGMT (3), OSSL_PROVIDER-default (7), OSSL_PROVIDER-FIPS (7)

COPYRIGHT

Copyright 2020-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

343 - Linux cli command ROLLBACK

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ROLLBACK and provides detailed information about the command ROLLBACK, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ROLLBACK.

NAME 🖥️ ROLLBACK 🖥️

abort the current transaction

SYNOPSIS

ROLLBACK [ WORK | TRANSACTION ] [ AND [ NO ] CHAIN ]

DESCRIPTION

ROLLBACK rolls back the current transaction and causes all the updates made by the transaction to be discarded.

PARAMETERS

WORK
TRANSACTION

Optional key words. They have no effect.

AND CHAIN

If AND CHAIN is specified, a new (not aborted) transaction is immediately started with the same transaction characteristics (see SET TRANSACTION (SET_TRANSACTION(7))) as the just finished one. Otherwise, no new transaction is started.

NOTES

Use COMMIT to successfully terminate a transaction.

Issuing ROLLBACK outside of a transaction block emits a warning and otherwise has no effect. ROLLBACK AND CHAIN outside of a transaction block is an error.

EXAMPLES

To abort all changes:

ROLLBACK;

COMPATIBILITY

The command ROLLBACK conforms to the SQL standard. The form ROLLBACK TRANSACTION is a PostgreSQL extension.

SEE ALSO

BEGIN(7), COMMIT(7), ROLLBACK TO SAVEPOINT (ROLLBACK_TO_SAVEPOINT(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

344 - Linux cli command EVP_MAC-BLAKE2SMACssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_MAC-BLAKE2SMACssl and provides detailed information about the command EVP_MAC-BLAKE2SMACssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_MAC-BLAKE2SMACssl.

NAME 🖥️ EVP_MAC-BLAKE2SMACssl 🖥️

BLAKE2, EVP_MAC-BLAKE2BMAC, EVP_MAC-BLAKE2SMAC - The BLAKE2 EVP_MAC implementations

DESCRIPTION

Support for computing BLAKE2 MACs through the EVP_MAC API.

Identity

These implementations are identified with one of these names and properties, to be used with EVP_MAC_fetch():

“BLAKE2BMAC”, “provider=default”

“BLAKE2SMAC”, “provider=default”

Supported parameters

The general description of these parameters can be found in “PARAMETERS” in EVP_MAC (3).

All these parameters (except for “block-size”) can be set with EVP_MAC_CTX_set_params(). Furthermore, the “size” parameter can be retrieved with EVP_MAC_CTX_get_params(), or with EVP_MAC_CTX_get_mac_size(). The length of the “size” parameter should not exceed that of a size_t. Likewise, the “block-size” parameter can be retrieved with EVP_MAC_CTX_get_params(), or with EVP_MAC_CTX_get_block_size().

“key” (OSSL_MAC_PARAM_KEY) <octet string>
Sets the MAC key. It may be at most 64 bytes for BLAKE2BMAC or 32 for BLAKE2SMAC and at least 1 byte in both cases. Setting this parameter is identical to passing a key to EVP_MAC_init (3).

“custom” (OSSL_MAC_PARAM_CUSTOM) <octet string>
Sets the customization/personalization string. It is an optional value of at most 16 bytes for BLAKE2BMAC or 8 for BLAKE2SMAC, and is empty by default.

“salt” (OSSL_MAC_PARAM_SALT) <octet string>
Sets the salt. It is an optional value of at most 16 bytes for BLAKE2BMAC or 8 for BLAKE2SMAC, and is empty by default.

“size” (OSSL_MAC_PARAM_SIZE) <unsigned integer>
Sets the MAC size. It can be any number between 1 and 32 for EVP_MAC_BLAKE2S or between 1 and 64 for EVP_MAC_BLAKE2B. It is 32 and 64 respectively by default.

“block-size” (OSSL_MAC_PARAM_BLOCK_SIZE) <unsigned integer>
Gets the MAC block size. It is 64 for EVP_MAC_BLAKE2S and 128 for EVP_MAC_BLAKE2B.

SEE ALSO

EVP_MAC_CTX_get_params (3), EVP_MAC_CTX_set_params (3), “PARAMETERS” in EVP_MAC (3), OSSL_PARAM (3)

HISTORY

The macros and functions described here were added to OpenSSL 3.0.

COPYRIGHT

Copyright 2018-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

345 - Linux cli command pcap-filter

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command pcap-filter and provides detailed information about the command pcap-filter, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the pcap-filter.

NAME 🖥️ pcap-filter 🖥️

filter - packet filter syntax

DESCRIPTION

pcap_compile(3PCAP) is used to compile a string into a filter program. The resulting filter program can then be applied to some stream of packets to determine which packets will be supplied to pcap_loop(3PCAP), pcap_dispatch(3PCAP), pcap_next(3PCAP), or pcap_next_ex(3PCAP).

The filter expression consists of one or more primitives. Primitives usually consist of an id (name or number) preceded by one or more qualifiers. There are three different kinds of qualifier:

type
type qualifiers say what kind of thing the id name or number refers to. Possible types are host, net, port and portrange. E.g., `host foo’, `net 128.3’, `port 20’, `portrange 6000-6008’. If there is no type qualifier, host is assumed.

dir
dir qualifiers specify a particular transfer direction to and/or from id. Possible directions are src, dst, src or dst, src and dst, ra, ta, addr1, addr2, addr3, and addr4. E.g., `src foo’, `dst net 128.3’, `src or dst port ftp-data’. If there is no dir qualifier, `src or dst’ is assumed. The ra, ta, addr1, addr2, addr3, and addr4 qualifiers are only valid for IEEE 802.11 Wireless LAN link layers.

proto
proto qualifiers restrict the match to a particular protocol. Possible protocols are: ether, fddi, tr, wlan, ip, ip6, arp, rarp, decnet, sctp, tcp and udp. E.g., `ether src foo’, `arp net 128.3’, `tcp port 21’, `udp portrange 7000-7009’, `wlan addr2 0:2:3:4:5:6’. If there is no proto qualifier, all protocols consistent with the type are assumed. E.g., `src foo’ means `(ip or arp or rarp) src foo’, `net bar’ means `(ip or arp or rarp) net bar’ and `port 53’ means `(tcp or udp or sctp) port 53’ (note that these examples use invalid syntax to illustrate the principle).

[fddi is actually an alias for ether; the parser treats them identically as meaning ``the data link level used on the specified network interface’’. FDDI headers contain Ethernet-like source and destination addresses, and often contain Ethernet-like packet types, so you can filter on these FDDI fields just as with the analogous Ethernet fields. FDDI headers also contain other fields, but you cannot name them explicitly in a filter expression.

Similarly, tr and wlan are aliases for ether; the previous paragraph’s statements about FDDI headers also apply to Token Ring and 802.11 wireless LAN headers. For 802.11 headers, the destination address is the DA field and the source address is the SA field; the BSSID, RA, and TA fields aren’t tested.]

In addition to the above, there are some special `primitive’ keywords that don’t follow the pattern: gateway, broadcast, less, greater and arithmetic expressions. All of these are described below.

More complex filter expressions are built up by using the words and, or and not (or equivalently: `&&’, `||’ and `!’ respectively) to combine primitives. E.g., `host foo and not port ftp and not port ftp-data’. To save typing, identical qualifier lists can be omitted. E.g., `tcp dst port ftp or ftp-data or domain’ is exactly the same as `tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain'.

Allowable primitives are:

dst host hostnameaddr
True if the IPv4/v6 destination field of the packet is hostnameaddr, which may be either an address or a name.

src host hostnameaddr
True if the IPv4/v6 source field of the packet is hostnameaddr.

host hostnameaddr
True if either the IPv4/v6 source or destination of the packet is hostnameaddr**.**

Any of the above host expressions can be prepended with the keywords, ip, arp, rarp, or ip6 as in:

ip host hostnameaddr

which is equivalent to:

ether proto \ip and host hostnameaddr

If hostnameaddr is a name with multiple IPv4/v6 addresses, each address will be checked for a match.

ether dst ethernameaddr
True if the Ethernet destination address is ethernameaddr**.** ethernameaddr may be either a name from /etc/ethers or a numerical MAC address of the form “xx:xx:xx:xx:xx:xx”, “xx.xx.xx.xx.xx.xx”, “xx-xx-xx-xx-xx-xx”, “xxxx.xxxx.xxxx”, “xxxxxxxxxxxx”, or various mixes of ‘:’, ‘.’, and ‘-’, where each “x” is a hex digit (0-9, a-f, or A-F).

ether src ethernameaddr
True if the Ethernet source address is ethernameaddr**.**

ether host ethernameaddr
True if either the Ethernet source or destination address is ethernameaddr**.**

gateway host
True if the packet used host as a gateway. I.e., the Ethernet source or destination address was host but neither the IP source nor the IP destination was host**.** Host must be a name and must be found both by the machine’s host-name-to-IP-address resolution mechanisms (host name file, DNS, NIS, etc.) and by the machine’s host-name-to-Ethernet-address resolution mechanism (/etc/ethers, etc.). (An equivalent expression is

ether host ethernameaddr and not host hostnameaddr

which can be used with either names or numbers for hostnameaddr / ethernameaddr.) This syntax does not work in IPv6-enabled configuration at this moment.

dst net netnameaddr
True if the IPv4/v6 destination address of the packet has a network number of netnameaddr. Net may be either a name from the networks database (/etc/networks, etc.) or a network number. An IPv4 network number can be written as a dotted quad (e.g., 192.168.1.0), dotted triple (e.g., 192.168.1), dotted pair (e.g, 172.16), or single number (e.g., 10); the netmask is 255.255.255.255 for a dotted quad (which means that it’s really a host match), 255.255.255.0 for a dotted triple, 255.255.0.0 for a dotted pair, or 255.0.0.0 for a single number. An IPv6 network number must be written out fully; the netmask is ff:ff:ff:ff:ff:ff:ff:ff, so IPv6 “network” matches are really always host matches, and a network match requires a netmask length.

src net netnameaddr
True if the IPv4/v6 source address of the packet has a network number of netnameaddr.

net netnameaddr
True if either the IPv4/v6 source or destination address of the packet has a network number of netnameaddr.

net netaddr mask netmask
True if the IPv4 address matches netaddr with the specific netmask. May be qualified with src or dst. Note that this syntax is not valid for IPv6 netaddr.

net netaddr/len
True if the IPv4/v6 address matches netaddr with a netmask len bits wide. May be qualified with src or dst.

dst port portnamenum
True if the packet is IPv4/v6 TCP, UDP or SCTP and has a destination port value of portnamenum. The portnamenum can be a number or a name used in /etc/services (see tcp(4P) and udp(4P)). If a name is used, both the port number and protocol are checked. If a number or ambiguous name is used, only the port number is checked (e.g., `dst port 513’ will print both tcp/login traffic and udp/who traffic, and `port domain’ will print both tcp/domain and udp/domain traffic).

src port portnamenum
True if the packet has a source port value of portnamenum.

port portnamenum
True if either the source or destination port of the packet is portnamenum.

dst portrange portnamenum1-portnamenum2
True if the packet is IPv4/v6 TCP, UDP or SCTP and has a destination port value between portnamenum1 and portnamenum2 (both inclusive). portnamenum1 and portnamenum2 are interpreted in the same fashion as the portnamenum parameter for port.

src portrange portnamenum1-portnamenum2
True if the packet has a source port value between portnamenum1 and portnamenum2 (both inclusive).

portrange portnamenum1-portnamenum2
True if either the source or destination port of the packet is between portnamenum1 and portnamenum2 (both inclusive).

Any of the above port or port range expressions can be prepended with the keywords, tcp, udp or sctp, as in:

tcp src port portnamenum

which matches only TCP packets whose source port is portnamenum.

less length
True if the packet has a length less than or equal to length. This is equivalent to:

len <= length

greater length
True if the packet has a length greater than or equal to length. This is equivalent to:

len >= length

ip proto protocol
True if the packet is an IPv4 packet (see ip(4P)) of protocol type protocol. Protocol can be a number or one of the names recognized by getprotobyname(3) (as in e.g. `getent(1) protocols’), typically from an entry in /etc/protocols, for example: ah, esp, eigrp (only in Linux, FreeBSD, NetBSD, DragonFly BSD, and macOS), icmp, igmp, igrp (only in OpenBSD), pim, sctp, tcp, udp or vrrp. Note that most of these example identifiers are also keywords and must be escaped via backslash (. Note that this primitive does not chase the protocol header chain.

icmp
Abbreviation for:

ip proto 1

ip6 proto protocol
True if the packet is an IPv6 packet of protocol type protocol. (See `ip proto’ above for the meaning of protocol.) Note that the IPv6 variant of ICMP uses a different protocol number, named ipv6-icmp in AIX, FreeBSD, illumos, Linux, macOS, NetBSD, OpenBSD, Solaris and Windows. Note that this primitive does not chase the protocol header chain.

icmp6
Abbreviation for:

ip6 proto 58

proto protocol
True if the packet is an IPv4 or IPv6 packet of protocol type protocol. (See `ip proto’ above for the meaning of protocol.) Note that this primitive does not chase the protocol header chain.

ah, esp, pim, sctp, tcp, udp
Abbreviations for:

proto \protocol

where protocol is one of the above protocols.

ip6 protochain protocol
True if the packet is IPv6 packet, and contains protocol header with type protocol in its protocol header chain. (See `ip proto’ above for the meaning of protocol.) For example,

ip6 protochain 6

matches any IPv6 packet with TCP protocol header in the protocol header chain. The packet may contain, for example, authentication header, routing header, or hop-by-hop option header, between IPv6 header and TCP header. The BPF code emitted by this primitive is complex and cannot be optimized by the BPF optimizer code, and is not supported by filter engines in the kernel, so this can be somewhat slow, and may cause more packets to be dropped.

ip protochain protocol
Equivalent to ip6 protochain protocol, but this is for IPv4. (See `ip proto’ above for the meaning of protocol.)

protochain protocol
True if the packet is an IPv4 or IPv6 packet of protocol type protocol. (See `ip proto’ above for the meaning of protocol.) Note that this primitive chases the protocol header chain.

ether broadcast
True if the packet is an Ethernet broadcast packet. The ether keyword is optional.

ip broadcast
True if the packet is an IPv4 broadcast packet. It checks for both the all-zeroes and all-ones broadcast conventions, and looks up the subnet mask on the interface on which the capture is being done.

If the subnet mask of the interface on which the capture is being done is not available, either because the interface on which capture is being done has no netmask or because the capture is being done on the Linux “any” interface, which can capture on more than one interface, this check will not work correctly.

ether multicast
True if the packet is an Ethernet multicast packet. The ether keyword is optional. This is shorthand for `ether[0] & 1 != 0’.

ip multicast
True if the packet is an IPv4 multicast packet.

ip6 multicast
True if the packet is an IPv6 multicast packet.

ether proto protocol
True if the packet is of ether type protocol. Protocol can be a number or one of the names aarp, arp, atalk, decnet, ip, ip6, ipx, iso, lat, loopback, mopdl, moprc, netbeui, rarp, sca or stp. Note these identifiers (except loopback) are also keywords and must be escaped via backslash (.

[In the case of FDDI (e.g., `fddi proto rp’), Token Ring (e.g., `tr proto rp’), and IEEE 802.11 wireless LANs (e.g., `wlan proto rp’), for most of those protocols, the protocol identification comes from the 802.2 Logical Link Control (LLC) header, which is usually layered on top of the FDDI, Token Ring, or 802.11 header.

When filtering for most protocol identifiers on FDDI, Token Ring, or 802.11, the filter checks only the protocol ID field of an LLC header in so-called SNAP format with an Organizational Unit Identifier (OUI) of 0x000000, for encapsulated Ethernet; it doesn’t check whether the packet is in SNAP format with an OUI of 0x000000. The exceptions are:

iso
the filter checks the DSAP (Destination Service Access Point) and SSAP (Source Service Access Point) fields of the LLC header;

stp and netbeui
the filter checks the DSAP of the LLC header;

atalk
the filter checks for a SNAP-format packet with an OUI of 0x080007 and the AppleTalk etype.

In the case of Ethernet, the filter checks the Ethernet type field for most of those protocols. The exceptions are:

iso, stp, and netbeui
the filter checks for an 802.3 frame and then checks the LLC header as it does for FDDI, Token Ring, and 802.11;

atalk
the filter checks both for the AppleTalk etype in an Ethernet frame and for a SNAP-format packet as it does for FDDI, Token Ring, and 802.11;

aarp
the filter checks for the AppleTalk ARP etype in either an Ethernet frame or an 802.2 SNAP frame with an OUI of 0x000000;

ipx
the filter checks for the IPX etype in an Ethernet frame, the IPX DSAP in the LLC header, the 802.3-with-no-LLC-header encapsulation of IPX, and the IPX etype in a SNAP frame.

ip, ip6, arp, rarp, atalk, aarp, decnet, iso, stp, ipx, netbeui
Abbreviations for:

ether proto \protocol

where protocol is one of the above protocols.

lat, moprc, mopdl
Abbreviations for:

ether proto \protocol

where protocol is one of the above protocols. Note that not all applications using pcap(3PCAP) currently know how to parse these protocols.

decnet src decnetaddr
True if the DECnet source address is decnetaddr, which may be an address of the form ``10.123’’, or a DECnet host name. [DECnet host name support is only available on ULTRIX systems that are configured to run DECnet.]

decnet dst decnetaddr
True if the DECnet destination address is decnetaddr.

decnet host decnetaddr
True if either the DECnet source or destination address is decnetaddr.

llc
True if the packet has an 802.2 LLC header. This includes:

Ethernet packets with a length field rather than a type field that aren’t raw NetWare-over-802.3 packets;

IEEE 802.11 data packets;

Token Ring packets (no check is done for LLC frames);

FDDI packets (no check is done for LLC frames);

LLC-encapsulated ATM packets, for SunATM on Solaris.

llc type
True if the packet has an 802.2 LLC header and has the specified type. type can be one of:

i
Information (I) PDUs

s
Supervisory (S) PDUs

u
Unnumbered (U) PDUs

rr
Receiver Ready (RR) S PDUs

rnr
Receiver Not Ready (RNR) S PDUs

rej
Reject (REJ) S PDUs

ui
Unnumbered Information (UI) U PDUs

ua
Unnumbered Acknowledgment (UA) U PDUs

disc
Disconnect (DISC) U PDUs

sabme
Set Asynchronous Balanced Mode Extended (SABME) U PDUs

test
Test (TEST) U PDUs

xid
Exchange Identification (XID) U PDUs

frmr
Frame Reject (FRMR) U PDUs

inbound
Packet was received by the host performing the capture rather than being sent by that host. This is only supported for certain link-layer types, such as SLIP and the ``cooked’’ Linux capture mode used for the ``any’’ device and for some other device types.

outbound
Packet was sent by the host performing the capture rather than being received by that host. This is only supported for certain link-layer types, such as SLIP and the ``cooked’’ Linux capture mode used for the ``any’’ device and for some other device types.

ifname interface
True if the packet was logged as coming from the specified interface (applies only to packets logged by OpenBSD’s or FreeBSD’s pf(4)).

on interface
Synonymous with the ifname modifier.

rnr num
True if the packet was logged as matching the specified PF rule number (applies only to packets logged by OpenBSD’s or FreeBSD’s pf(4)).

rulenum num
Synonymous with the rnr modifier.

reason code
True if the packet was logged with the specified PF reason code. The known codes are: match, bad-offset, fragment, short, normalize, and memory (applies only to packets logged by OpenBSD’s or FreeBSD’s pf(4)).

rset name
True if the packet was logged as matching the specified PF ruleset name of an anchored ruleset (applies only to packets logged by OpenBSD’s or FreeBSD’s pf(4)).

ruleset name
Synonymous with the rset modifier.

srnr num
True if the packet was logged as matching the specified PF rule number of an anchored ruleset (applies only to packets logged by OpenBSD’s or FreeBSD’s pf(4)).

subrulenum num
Synonymous with the srnr modifier.

action act
True if PF took the specified action when the packet was logged. Known actions are: pass and block and, with later versions of pf(4), nat, rdr, binat and scrub (applies only to packets logged by OpenBSD’s or FreeBSD’s pf(4)).

wlan ra ehost
True if the IEEE 802.11 RA is ehost. The RA field is used in all frames except for management frames.

wlan ta ehost
True if the IEEE 802.11 TA is ehost. The TA field is used in all frames except for management frames and CTS (Clear To Send) and ACK (Acknowledgment) control frames.

wlan addr1 ehost
True if the first IEEE 802.11 address is ehost.

wlan addr2 ehost
True if the second IEEE 802.11 address, if present, is ehost. The second address field is used in all frames except for CTS (Clear To Send) and ACK (Acknowledgment) control frames.

wlan addr3 ehost
True if the third IEEE 802.11 address, if present, is ehost. The third address field is used in management and data frames, but not in control frames.

wlan addr4 ehost
True if the fourth IEEE 802.11 address, if present, is ehost. The fourth address field is only used for WDS (Wireless Distribution System) frames.

type wlan_type
True if the IEEE 802.11 frame type matches the specified wlan_type. Valid wlan_types are: mgt, ctl and data.

type wlan_type subtype wlan_subtype
True if the IEEE 802.11 frame type matches the specified wlan_type and frame subtype matches the specified wlan_subtype.

If the specified wlan_type is mgt, then valid wlan_subtypes are: assoc-req, assoc-resp, reassoc-req, reassoc-resp, probe-req, probe-resp, beacon, atim, disassoc, auth and deauth.

If the specified wlan_type is ctl, then valid wlan_subtypes are: ps-poll, rts, cts, ack, cf-end and cf-end-ack.

If the specified wlan_type is data, then valid wlan_subtypes are: data, data-cf-ack, data-cf-poll, data-cf-ack-poll, null, cf-ack, cf-poll, cf-ack-poll, qos-data, qos-data-cf-ack, qos-data-cf-poll, qos-data-cf-ack-poll, qos, qos-cf-poll and qos-cf-ack-poll.

subtype wlan_subtype
True if the IEEE 802.11 frame subtype matches the specified wlan_subtype and frame has the type to which the specified wlan_subtype belongs.

dir direction
True if the IEEE 802.11 frame direction matches the specified direction. Valid directions are: nods, tods, fromds, dstods, or a numeric value.

vlan [vlan_id]
True if the packet is an IEEE 802.1Q VLAN packet. If the optional vlan_id is specified, only true if the packet has the specified vlan_id. Note that the first vlan keyword encountered in an expression changes the decoding offsets for the remainder of the expression on the assumption that the packet is a VLAN packet. The `vlan [vlan_id]` keyword may be used more than once, to filter on VLAN hierarchies. Each use of that keyword increments the filter offsets by 4.

For example:

vlan 100 && vlan 200

filters on VLAN 200 encapsulated within VLAN 100, and

vlan && vlan 300 && ip

filters IPv4 protocol encapsulated in VLAN 300 encapsulated within any higher order VLAN.

mpls [label_num]
True if the packet is an MPLS packet. If the optional label_num is specified, only true if the packet has the specified label_num. Note that the first mpls keyword encountered in an expression changes the decoding offsets for the remainder of the expression on the assumption that the packet is a MPLS-encapsulated IP packet. The `mpls [label_num]` keyword may be used more than once, to filter on MPLS hierarchies. Each use of that keyword increments the filter offsets by 4.

For example:

mpls 100000 && mpls 1024

filters packets with an outer label of 100000 and an inner label of 1024, and

mpls && mpls 1024 && host 192.9.200.1

filters packets to or from 192.9.200.1 with an inner label of 1024 and any outer label.

pppoed
True if the packet is a PPP-over-Ethernet Discovery packet (Ethernet type 0x8863).

pppoes [session_id]
True if the packet is a PPP-over-Ethernet Session packet (Ethernet type 0x8864). If the optional session_id is specified, only true if the packet has the specified session_id. Note that the first pppoes keyword encountered in an expression changes the decoding offsets for the remainder of the expression on the assumption that the packet is a PPPoE session packet.

For example:

pppoes 0x27 && ip

filters IPv4 protocol encapsulated in PPPoE session id 0x27.

geneve [vni]
True if the packet is a Geneve packet (UDP port 6081). If the optional vni is specified, only true if the packet has the specified vni. Note that when the geneve keyword is encountered in an expression, it changes the decoding offsets for the remainder of the expression on the assumption that the packet is a Geneve packet.

For example:

geneve 0xb && ip

filters IPv4 protocol encapsulated in Geneve with VNI 0xb. This will match both IPv4 directly encapsulated in Geneve as well as IPv4 contained inside an Ethernet frame.

iso proto protocol
True if the packet is an OSI packet of protocol type protocol. Protocol can be a number or one of the names clnp, esis, or isis.

clnp, esis, isis
Abbreviations for:

iso proto \protocol

where protocol is one of the above protocols.

l1, l2, iih, lsp, snp, csnp, psnp
Abbreviations for IS-IS PDU types.

vpi n
True if the packet is an ATM packet, for SunATM on Solaris, with a virtual path identifier of n.

vci n
True if the packet is an ATM packet, for SunATM on Solaris, with a virtual channel identifier of n.

lane
True if the packet is an ATM packet, for SunATM on Solaris, and is an ATM LANE packet. Note that the first lane keyword encountered in an expression changes the tests done in the remainder of the expression on the assumption that the packet is either a LANE emulated Ethernet packet or a LANE LE Control packet. If lane isn’t specified, the tests are done under the assumption that the packet is an LLC-encapsulated packet.

oamf4s
True if the packet is an ATM packet, for SunATM on Solaris, and is a segment OAM F4 flow cell (VPI=0 & VCI=3).

oamf4e
True if the packet is an ATM packet, for SunATM on Solaris, and is an end-to-end OAM F4 flow cell (VPI=0 & VCI=4).

oamf4
True if the packet is an ATM packet, for SunATM on Solaris, and is a segment or end-to-end OAM F4 flow cell (VPI=0 & (VCI=3 | VCI=4)).

oam
True if the packet is an ATM packet, for SunATM on Solaris, and is a segment or end-to-end OAM F4 flow cell (VPI=0 & (VCI=3 | VCI=4)).

metac
True if the packet is an ATM packet, for SunATM on Solaris, and is on a meta signaling circuit (VPI=0 & VCI=1).

bcc
True if the packet is an ATM packet, for SunATM on Solaris, and is on a broadcast signaling circuit (VPI=0 & VCI=2).

sc
True if the packet is an ATM packet, for SunATM on Solaris, and is on a signaling circuit (VPI=0 & VCI=5).

ilmic
True if the packet is an ATM packet, for SunATM on Solaris, and is on an ILMI circuit (VPI=0 & VCI=16).

connectmsg
True if the packet is an ATM packet, for SunATM on Solaris, and is on a signaling circuit and is a Q.2931 Setup, Call Proceeding, Connect, Connect Ack, Release, or Release Done message.

metaconnect
True if the packet is an ATM packet, for SunATM on Solaris, and is on a meta signaling circuit and is a Q.2931 Setup, Call Proceeding, Connect, Release, or Release Done message.

expr1 relop expr2
True if the relation holds. Relop is one of {>, <, >=, <=, =, ==, !=} (where = means the same as ==). Each of expr1 and expr2 is an arithmetic expression composed of integer constants (expressed in standard C syntax), the normal binary operators {+, -, *, /, %, &, |, ^, <<, >>}, a length operator, and special packet data accessors. Note that all comparisons are unsigned, so that, for example, 0x80000000 and 0xffffffff are > 0.

The % and ^ operators are currently only supported for filtering in the kernel on particular operating systems (for example: FreeBSD, Linux with 3.7 and later kernels, NetBSD); on all other systems (for example: AIX, illumos, Solaris, OpenBSD), if those operators are used, filtering will be done in user mode, which will increase the overhead of capturing packets and may cause more packets to be dropped.

The length operator, indicated by the keyword len, gives the length of the packet.

To access data inside the packet, use the following syntax:

proto [ expr : size ]

Proto is one of arp, atalk, carp, decnet, ether, fddi, icmp, icmp6, igmp, igrp, ip, ip6, lat, link, mopdl, moprc, pim, ppp, radio, rarp, sca, sctp, slip, tcp, tr, udp, vrrp or wlan, and indicates the protocol layer for the index operation. (ether, fddi, link, ppp, slip, tr and wlan all refer to the link layer. radio refers to the “radio header” added to some 802.11 captures.) Note that tcp, udp and other upper-layer protocol types only apply to IPv4, not IPv6 (this will be fixed in the future). The byte offset, relative to the indicated protocol layer, is given by expr. Size is optional and indicates the number of bytes in the field of interest; it can be either one, two, or four, and defaults to one.

For example, `ether[0] & 1 != 0’ catches all multicast traffic. The expression `ip[0] & 0xf != 5’ catches all IPv4 packets with options. The expression `ip[6:2] & 0x1fff = 0’ catches only unfragmented IPv4 datagrams and frag zero of fragmented IPv4 datagrams. This check is implicitly applied to the tcp and udp index operations. For instance, tcp[0] always means the first byte of the TCP header, and never means the first byte of an intervening fragment.

Some offsets and field values may be expressed as names rather than as numeric values. The following protocol header field offsets are available: icmptype (ICMP type field), icmp6type (ICMPv6 type field), icmpcode (ICMP code field), icmp6code (ICMPv6 code field) and tcpflags (TCP flags field).

The following ICMP type field values are available: icmp-echoreply, icmp-unreach, icmp-sourcequench, icmp-redirect, icmp-echo, icmp-routeradvert, icmp-routersolicit, icmp-timxceed, icmp-paramprob, icmp-tstamp, icmp-tstampreply, icmp-ireq, icmp-ireqreply, icmp-maskreq, icmp-maskreply.

The following ICMPv6 type field values are available: icmp6-destinationunreach, icmp6-packettoobig, icmp6-timeexceeded, icmp6-parameterproblem, icmp6-echo, icmp6-echoreply, icmp6-multicastlistenerquery, icmp6-multicastlistenerreportv1, icmp6-multicastlistenerdone, icmp6-routersolicit, icmp6-routeradvert, icmp6-neighborsolicit, icmp6-neighboradvert, icmp6-redirect, icmp6-routerrenum, icmp6-nodeinformationquery, icmp6-nodeinformationresponse, icmp6-ineighbordiscoverysolicit, icmp6-ineighbordiscoveryadvert, icmp6-multicastlistenerreportv2, icmp6-homeagentdiscoveryrequest, icmp6-homeagentdiscoveryreply, icmp6-mobileprefixsolicit, icmp6-mobileprefixadvert, icmp6-certpathsolicit, icmp6-certpathadvert, icmp6-multicastrouteradvert, icmp6-multicastroutersolicit, icmp6-multicastrouterterm.

The following TCP flags field values are available: tcp-fin, tcp-syn, tcp-rst, tcp-push, tcp-ack, tcp-urg, tcp-ece, tcp-cwr.

Primitives may be combined using:

A parenthesized group of primitives and operators.

Negation (`!’ or `not’).

Concatenation (`&&’ or `and’).

Alternation (`||’ or `or’).

Negation has the highest precedence. Alternation and concatenation have equal precedence and associate left to right. Note that explicit and tokens, not juxtaposition, are now required for concatenation.

If an identifier is given without a keyword, the most recent keyword is assumed. For example,

not host vs and ace

is short for

not host vs and host ace

which should not be confused with

not (host vs or ace)

EXAMPLES

To select all packets arriving at or departing from `sundown’:

host sundown

To select traffic between `helios’ and either `hot’ or `ace’:

host helios and (hot or ace)

To select all IPv4 packets between `ace’ and any host except `helios':

ip host ace and not helios

To select all traffic between local hosts and hosts at Berkeley:

net ucb-ether

To select all FTP traffic through Internet gateway `snup':

gateway snup and (port ftp or ftp-data)

To select IPv4 traffic neither sourced from nor destined for local hosts (if you gateway to one other net, this stuff should never make it onto your local net).

ip and not net localnet

To select the start and end packets (the SYN and FIN packets) of each TCP conversation that involves a non-local host.

tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net localnet

To select the TCP packets with flags RST and ACK both set. (i.e. select only the RST and ACK flags in the flags field, and if the result is “RST and ACK both set”, match)

tcp[tcpflags] & (tcp-rst|tcp-ack) == (tcp-rst|tcp-ack)

To select all IPv4 HTTP packets to and from port 80, i.e. print only packets that contain data, not, for example, SYN and FIN packets and ACK-only packets. (IPv6 is left as an exercise for the reader.)

tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)«2)) - ((tcp[12]&0xf0)»2)) != 0)

To select IPv4 packets longer than 576 bytes sent through gateway `snup':

gateway snup and ip[2:2] > 576

To select IPv4 broadcast or multicast packets that were not sent via Ethernet broadcast or multicast:

ether[0] & 1 = 0 and ip[16] >= 224

To select all ICMP packets that are not echo requests/replies (i.e., not ping packets):

icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply icmp6[icmp6type] != icmp6-echo and icmp6[icmp6type] != icmp6-echoreply

BACKWARD COMPATIBILITY

The ICMPv6 type code names, as well as the tcp-ece and tcp-cwr TCP flag names became available in libpcap 1.9.0.

The geneve keyword became available in libpcap 1.8.0.

SEE ALSO

pcap(3PCAP)

BUGS

To report a security issue please send an e-mail to [email protected].

To report bugs and other problems, contribute patches, request a feature, provide generic feedback etc please see the file CONTRIBUTING.md in the libpcap source tree root.

Filter expressions on fields other than those in Token Ring headers will not correctly handle source-routed Token Ring packets.

Filter expressions on fields other than those in 802.11 headers will not correctly handle 802.11 data packets with both To DS and From DS set.

`ip6 proto’ should chase header chain, but at this moment it does not. `ip6 protochain’ is supplied for this behavior. For example, to match IPv6 fragments: `ip6 protochain 44’

Arithmetic expression against transport layer headers, like tcp[0], does not work against IPv6 packets. It only looks at IPv4 packets.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

346 - Linux cli command ALTER_FUNCTION

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_FUNCTION and provides detailed information about the command ALTER_FUNCTION, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_FUNCTION.

NAME 🖥️ ALTER_FUNCTION 🖥️

change the definition of a function

SYNOPSIS

ALTER FUNCTION name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ]
    action [ ... ] [ RESTRICT ]
ALTER FUNCTION name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ]
    RENAME TO new_name
ALTER FUNCTION name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ]
    OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }
ALTER FUNCTION name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ]
    SET SCHEMA new_schema
ALTER FUNCTION name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ]
    [ NO ] DEPENDS ON EXTENSION extension_name

where action is one of:

    CALLED ON NULL INPUT | RETURNS NULL ON NULL INPUT | STRICT
    IMMUTABLE | STABLE | VOLATILE
    [ NOT ] LEAKPROOF
    [ EXTERNAL ] SECURITY INVOKER | [ EXTERNAL ] SECURITY DEFINER
    PARALLEL { UNSAFE | RESTRICTED | SAFE }
    COST execution_cost
    ROWS result_rows
    SUPPORT support_function
    SET configuration_parameter { TO | = } { value | DEFAULT }
    SET configuration_parameter FROM CURRENT
    RESET configuration_parameter
    RESET ALL

DESCRIPTION

ALTER FUNCTION changes the definition of a function.

You must own the function to use ALTER FUNCTION. To change a functions schema, you must also have CREATE privilege on the new schema. To alter the owner, you must be able to SET ROLE to the new owning role, and that role must have CREATE privilege on the functions schema. (These restrictions enforce that altering the owner doesnt do anything you couldnt do by dropping and recreating the function. However, a superuser can alter ownership of any function anyway.)

PARAMETERS

name

The name (optionally schema-qualified) of an existing function. If no argument list is specified, the name must be unique in its schema.

argmode

The mode of an argument: IN, OUT, INOUT, or VARIADIC. If omitted, the default is IN. Note that ALTER FUNCTION does not actually pay any attention to OUT arguments, since only the input arguments are needed to determine the functions identity. So it is sufficient to list the IN, INOUT, and VARIADIC arguments.

argname

The name of an argument. Note that ALTER FUNCTION does not actually pay any attention to argument names, since only the argument data types are needed to determine the functions identity.

argtype

The data type(s) of the functions arguments (optionally schema-qualified), if any.

new_name

The new name of the function.

new_owner

The new owner of the function. Note that if the function is marked SECURITY DEFINER, it will subsequently execute as the new owner.

new_schema

The new schema for the function.

DEPENDS ON EXTENSION extension_name
NO DEPENDS ON EXTENSION extension_name

This form marks the function as dependent on the extension, or no longer dependent on that extension if NO is specified. A function thats marked as dependent on an extension is dropped when the extension is dropped, even if CASCADE is not specified. A function can depend upon multiple extensions, and will be dropped when any one of those extensions is dropped.

CALLED ON NULL INPUT
RETURNS NULL ON NULL INPUT
STRICT

CALLED ON NULL INPUT changes the function so that it will be invoked when some or all of its arguments are null. RETURNS NULL ON NULL INPUT or STRICT changes the function so that it is not invoked if any of its arguments are null; instead, a null result is assumed automatically. See CREATE FUNCTION (CREATE_FUNCTION(7)) for more information.

IMMUTABLE
STABLE
VOLATILE

Change the volatility of the function to the specified setting. See CREATE FUNCTION (CREATE_FUNCTION(7)) for details.

[ EXTERNAL ] SECURITY INVOKER
[ EXTERNAL ] SECURITY DEFINER

Change whether the function is a security definer or not. The key word EXTERNAL is ignored for SQL conformance. See CREATE FUNCTION (CREATE_FUNCTION(7)) for more information about this capability.

PARALLEL

Change whether the function is deemed safe for parallelism. See CREATE FUNCTION (CREATE_FUNCTION(7)) for details.

LEAKPROOF

Change whether the function is considered leakproof or not. See CREATE FUNCTION (CREATE_FUNCTION(7)) for more information about this capability.

COST execution_cost

Change the estimated execution cost of the function. See CREATE FUNCTION (CREATE_FUNCTION(7)) for more information.

ROWS result_rows

Change the estimated number of rows returned by a set-returning function. See CREATE FUNCTION (CREATE_FUNCTION(7)) for more information.

SUPPORT support_function

Set or change the planner support function to use for this function. See Section 38.11 for details. You must be superuser to use this option.

This option cannot be used to remove the support function altogether, since it must name a new support function. Use CREATE OR REPLACE FUNCTION if you need to do that.

configuration_parameter
value

Add or change the assignment to be made to a configuration parameter when the function is called. If value is DEFAULT or, equivalently, RESET is used, the function-local setting is removed, so that the function executes with the value present in its environment. Use RESET ALL to clear all function-local settings. SET FROM CURRENT saves the value of the parameter that is current when ALTER FUNCTION is executed as the value to be applied when the function is entered.

See SET(7) and Chapter 20 for more information about allowed parameter names and values.

RESTRICT

Ignored for conformance with the SQL standard.

EXAMPLES

To rename the function sqrt for type integer to square_root:

ALTER FUNCTION sqrt(integer) RENAME TO square_root;

To change the owner of the function sqrt for type integer to joe:

ALTER FUNCTION sqrt(integer) OWNER TO joe;

To change the schema of the function sqrt for type integer to maths:

ALTER FUNCTION sqrt(integer) SET SCHEMA maths;

To mark the function sqrt for type integer as being dependent on the extension mathlib:

ALTER FUNCTION sqrt(integer) DEPENDS ON EXTENSION mathlib;

To adjust the search path that is automatically set for a function:

ALTER FUNCTION check_password(text) SET search_path = admin, pg_temp;

To disable automatic setting of search_path for a function:

ALTER FUNCTION check_password(text) RESET search_path;

The function will now execute with whatever search path is used by its caller.

COMPATIBILITY

This statement is partially compatible with the ALTER FUNCTION statement in the SQL standard. The standard allows more properties of a function to be modified, but does not provide the ability to rename a function, make a function a security definer, attach configuration parameter values to a function, or change the owner, schema, or volatility of a function. The standard also requires the RESTRICT key word, which is optional in PostgreSQL.

SEE ALSO

CREATE FUNCTION (CREATE_FUNCTION(7)), DROP FUNCTION (DROP_FUNCTION(7)), ALTER PROCEDURE (ALTER_PROCEDURE(7)), ALTER ROUTINE (ALTER_ROUTINE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

347 - Linux cli command pam

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command pam and provides detailed information about the command pam, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the pam.

NAME 🖥️ pam 🖥️

Pluggable Authentication Modules for Linux

DESCRIPTION

This manual is intended to offer a quick introduction to Linux-PAM. For more information the reader is directed to the Linux-PAM system administrators guide.

Linux-PAM is a system of libraries that handle the authentication tasks of applications (services) on the system. The library provides a stable general interface (Application Programming Interface - API) that privilege granting programs (such as login(1) and su(1)) defer to to perform standard authentication tasks.

The principal feature of the PAM approach is that the nature of the authentication is dynamically configurable. In other words, the system administrator is free to choose how individual service-providing applications will authenticate users. This dynamic configuration is set by the contents of the single Linux-PAM configuration file /etc/pam.conf. Alternatively and preferably, the configuration can be set by individual configuration files located in a pam.d directory. The presence of this directory will cause Linux-PAM to ignore /etc/pam.conf.

Vendor-supplied PAM configuration files might be installed in the system directory /usr/lib/pam.d/ or a configurable vendor specific directory instead of the machine configuration directory /etc/pam.d/. If no machine configuration file is found, the vendor-supplied file is used. All files in /etc/pam.d/ override files with the same name in other directories.

From the point of view of the system administrator, for whom this manual is provided, it is not of primary importance to understand the internal behavior of the Linux-PAM library. The important point to recognize is that the configuration file(s) define the connection between applications (services) and the pluggable authentication modules (PAMs) that perform the actual authentication tasks.

Linux-PAM separates the tasks of authentication into four independent management groups: account management; authentication management; password management; and session management. (We highlight the abbreviations used for these groups in the configuration file.)

Simply put, these groups take care of different aspects of a typical users request for a restricted service:

account - provide account verification types of service: has the users password expired?; is this user permitted access to the requested service?

authentication - authenticate a user and set up user credentials. Typically this is via some challenge-response request that the user must satisfy: if you are who you claim to be please enter your password. Not all authentications are of this type, there exist hardware based authentication schemes (such as the use of smart-cards and biometric devices), with suitable modules, these may be substituted seamlessly for more standard approaches to authentication - such is the flexibility of Linux-PAM.

password - this groups responsibility is the task of updating authentication mechanisms. Typically, such services are strongly coupled to those of the auth group. Some authentication mechanisms lend themselves well to being updated with such a function. Standard UN*X password-based access is the obvious example: please enter a replacement password.

session - this group of tasks cover things that should be done prior to a service being given and after it is withdrawn. Such tasks include the maintenance of audit trails and the mounting of the users home directory. The session management group is important as it provides both an opening and closing hook for modules to affect the services available to a user.

FILES

/etc/pam.conf

the configuration file

/etc/pam.d

the Linux-PAM configuration directory. Generally, if this directory is present, the /etc/pam.conf file is ignored.

/usr/lib/pam.d

the Linux-PAM vendor configuration directory. Files in /etc/pam.d override files with the same name in this directory.

ERRORS

Typically errors generated by the Linux-PAM system of libraries, will be written to syslog(3).

CONFORMING TO

DCE-RFC 86.0, October 1995. Contains additional features, but remains backwardly compatible with this RFC.

SEE ALSO

pam(3), pam_authenticate(3), pam_sm_setcred(3), pam_strerror(3), PAM(8)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

348 - Linux cli command esil

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command esil and provides detailed information about the command esil, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the esil.

ESIL - Evaluable Strings Intermediate Language

ESIL provides an abstract, stack-based format for representing CPU instruction semantics across various architectures, facilitating instruction emulation for analysis and debugging within the radare2 framework.

Evaluable Strings Intermediate Language (ESIL) adopts a Forth-like syntax, offering a method to describe and emulate the behavior of machine instructions in a platform-agnostic manner. It is particularly useful in reverse engineering, allowing for cross-architecture binary analysis and exploitation through radare2.

ESIL expressions use a series of operands and operations, manipulating values on an internal stack. These expressions are executed within an ESIL virtual machine (VM), enabling the simulation of CPU instructions’ effects on registers and memory.

Uppercase words are special keywords that operate on the esil VM.

Lowercase words are register names that can be used for reading or writing through operations.

Words starting with $ represent internal variables of the VM that are readonly

Numbers can be in base 10 or hexadecimal.

The rest of keywords can be added or removed via esil or arch plugins, but this document describes all the common and standard ESIL commands. Note that the list of instructions is subject to change (will be reduced over time) for simplicity reasons.

Radare2’s visual mode and various configuration options, such as `emu.str` and `asm.esil`, facilitate the inspection of ESIL evaluations alongside traditional disassembly. This dual view can greatly enhance understanding of binary behavior without requiring physical execution.

Radare2 leverages ESIL for detailed emulation of instruction execution, enabling users to step through instructions, inspect changes to registers and memory, and evaluate conditional logic in a controlled environment.

In the visual mode of radare2 you can emulate code doing single stepping, but it is also possible to debug the expressions using the `aev` command

ae: Evaluate an ESIL expression. Note that some expressions contain special characters that can be evaluated by the radare2 shell, so it’s better to prefix the command with a single quote ’ to skip that parsing.

“aev”: Enter the interactive visual debugger to debug and emulate an esil expression.

“aes”: ESIL Step: execute a single step in ESIL emulation.

“aeso”: ESIL Step Over: perform a step over call instructions in ESIL emulation.

“aesu”: ESIL Step Until: continue ESIL execution until a specified address is reached.

“ar”: Show or modify ESIL registers.

The comma separated words in an ESIL expression can be grouped into different scopes:

Prefixed with ‘$’ they represent internal states of the esil vm and are used to perform conditional

comparison flags: $z, $c, $b, $p, $s, $o, $ds, $jt, $js

current address: $$

Pop the value and the destination from the stack

“=”: strong assignment (update flags)

“:=”: weak assignment without updating flags

Basic math operations like add, sub, mul, mod, div, shift, rotate, and, or

+ - / * %

“~” sign extend

“<<” shift left (see “>>” for shift right)

“<<<” rotate left (">>>" for rotate right

“<<<<” arithmetic shift left (">>>>" for asr)

“&” binary AND

“|” binary OR

“!” negate value ins tack

“L*”: long multiplication

“*”: multiplication

“^”: xor

“~/”: signed division

“%”: mod

Comparison words update the internal flags and can be used to make conditional operations.

“<”: smaller than

“<=”: smaller or equal

“<=”: bigger or equal

“>”: bigger than

“==”: compare equality

Conditional expressions, loops

GOTO BREAK “?{” “}” “}{”

The memory access expressions contain the [] braces to read and =[] to write, address and value are popped from the stack, and size is defined between the brackets.

In order to simplify the VM and reduce the amount of keywords those combined operations may change in the future.

reading: [1] [2] [4] [8] [16]

writing: =[1] =[2] =[4] =[8] =[16]

combined: |=[2] +=[4] &=[4] –=[2]

special [*] =[*]

Represented as uppercase words, they are used to manipulate the internal esil stack, swaping, perform a cast, set flags and so on

STACK POP TODO CLEAR DUP NUM SWAP TRAP BITS SETJT SETJTS SETD

“()”: syscall “$”: interrupt “#!”: r2 command

NAN I2D U2D D2I D2F F2D F== F!= F< F<= F+ F- F* F/ -F CEIL FLOOR ROUND SQRT

Core operations in ESIL are designed to replicate basic CPU instructions’ behavior, including arithmetic, logical, and control flow.

“=” Assignment: Transfers the value from the right operand to the left operand.

“+” Addition: Adds the two topmost values on the stack, pushing the result.

“-” Subtraction: Subtracts the top value from the second top value on the stack, pushing the result.

“*” Multiplication: Multiplies the two topmost values on the stack, pushing the result.

“/” Division: Divides the second top value by the top value on the stack, pushing the result.

“[]” Memory Access: Represents reading or writing to memory, with operation size being context-dependent.

“?{” Conditional Execution: If the top value of the stack is not zero, execute the following block of instructions.

“$” Special Flags and Operations: Accesses internal VM flags for conditions like carry, zero, and overflow or performs special operations like system calls.

“<<”, “>>” Bit Shifts: Performs bitwise shift left or right operations.

“&”, “|”, “^” Bitwise Operations: Executes AND, OR, XOR on the two topmost stack values.

“!” Logical NOT: Inverts the top value on the stack.

ESIL uses internal flags to represent the outcome of operations, similar to how CPU flags work. These flags enable conditional execution and comparisons within the ESIL VM.

“$z” Zero Flag: Set if the result of an operation is zero. Used to perform equality checks.

“$c” Carry Flag: Set if an operation results in a carry out of the most significant bit. Useful for unsigned arithmetic operations.

“$s” Sign Flag: Set if the result of an operation is negative, indicating the sign in signed arithmetic.

“$o” Overflow Flag: Set if an arithmetic operation produces a result too large for the destination register, indicating overflow in signed arithmetic.

“$p” Parity Flag: Set if the number of set bits in the operation result is even. Rarely used in high-level analysis.

Flags are often used following comparison or arithmetic operations to guide conditional jumps and other control flow decisions, mimicking the behavior of physical CPUs.

Compares EAX and EBX, setting the zero flag (zf) in ESIL if they are equal. cmp eax, ebx -> ebx,eax,==,$z,zf,:="

Adds 1 to EAX, demonstrating basic arithmetic. add eax, 1 -> 1,eax,+=

Jumps to the label if the zero flag (zf) is set, illustrating conditional execution based on comparison results. jz .label -> zf,?{,.label,eip,=,}

Code-wars like game implemented on top of ESIL, this is the implementation used in the r2con conference.

https://github.com/radareorg/r2wars

https://www.radare.org/

pancake <[email protected]>

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

349 - Linux cli command java-wrappers

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command java-wrappers and provides detailed information about the command java-wrappers, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the java-wrappers.

NAME 🖥️ java-wrappers 🖥️

wrappers** - capacities shared by java wrapper scripts

DESCRIPTION

Most Java programs are not run directly, but through small shell scripts that take care of various things, such as finding a suitable Java environment and looking for libraries.

To ease the task of the maintainers, they rely on a library providing runtime detection, library detection and other features. This manual page describes the common features of all those scripts, and to which point you can configure them. This is mainly done via environment variables.

ENVIRONMENT VARIABLES

java-wrappers understands some environment variables:

JAVA_CMD
The java command that will be run. If this variable is set, it disables all lookup for a java runtime.

JAVA_BINDIR
Specifies a directory that will be looked for a java or a jdb executable (depending on the setting of JAVA_DEBUGGER). It has precedence over JAVA_HOME but not over JAVA_CMD.

JAVA_HOME
A path to a Java runtime. If this variable is set, all lookup for a Java runtime is disabled, except that if no java executable is found in the path, the command java is used.

JAVA_FLAVOR
A probably more easy-to-use version of the JAVA_HOME variable: instead of specifying the full path of the Java runtime, you name it. List of available flavors can be found in the file /usr/lib/java-wrappers/jvm-list.sh. See examples below.

JAVA_DEBUGGER
If this is set, the wrapper will try to pick up a Java debugger rather than a Java interpreter. This will fail if the jbd of the runtime found is a stub.

JAVA_CLASSPATH
Additional classpath, will have priority over the one found by the wrapper.

JAVA_ARGS
Additional arguments to the java command. They will come before all other arguments.

FORCE_CLASSPATH
If this variable is set, it will be the only classpath. You’d better know what you are doing.

DEBUG_WRAPPER
This is probably the most important variable; if it set, the wrapper will print out useful information as it goes by its business, such as which runtime it did find, and which command is run eventually.

JAVA_JARPATH
The path where the wrappers will go looking for jar archives. If not set, the wrapper will look into the default directory, /usr/share/java. Warning : the wrapper will not look anywhere else than in JAVA_JARPATH. Setting it incorrectly will most probably result in early crashes.

EXAMPLES

The examples all rely on rasterizer(1), from the package libbatik-java, but they really apply to all scripts that use java-wrappers.

Print out debugging information:

DEBUG_WRAPPER=1 rasterizer

Limit rasterizer’s memory to 80 MB:

JAVA_ARGS=-Xmx80m rasterizer

Force rasterizer to run with kaffe(1):

JAVA_HOME=/usr/lib/kaffe rasterizer

The same, but using JAVA_BINDIR:

JAVA_BINDIR=/usr/lib/kaffe/bin rasterizer

Force rasterizer to run with openjdk:

JAVA_FLAVOR=openjdk rasterizer

Debug rasterizer with Sun’s debugger, while printing debugging information from the wrapper:

DEBUG_WRAPPER=1 JAVA_CMD=/usr/lib/jvm/java-6-sun/bin/jdb rasterizer

BUGS

Care has been taken to make the wrappers bug-free. If that was not the case, please file a bug report against the java-wrappers package.

If you wish to submit any problem with a Java executable relying on java-wrappers, please also submit the output of the command run with DEBUG_WRAPPER=1. It will save one mail exchange and therefore potentially reduce the time it takes to fix the bug.

DEVELOPERS

There is currently no documentation about writing a wrapper script save the comments in /usr/lib/java-wrappers/java-wrappers.sh. If you have to write one, we suggest you base yourself upon, for instance, the rasterizer wrapper script, or any other one (just pick up any direct reverse dependency of java-wrappers and look for scripts).

SEE ALSO

java(1), jdb(1)

/usr/lib/java-wrappers/java-wrappers.sh

AUTHOR

java-wrappers and its documentation were written by Vincent Fourmond <[email protected]>

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

350 - Linux cli command x25

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command x25 and provides detailed information about the command x25, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the x25.

NAME 🖥️ x25 🖥️

ITU-T X.25 / ISO/IEC 8208 protocol interface

SYNOPSIS

#include <sys/socket.h>
#include <linux/x25.h>
x25_socket = socket(AF_X25, SOCK_SEQPACKET, 0);

DESCRIPTION

X25 sockets provide an interface to the X.25 packet layer protocol. This allows applications to communicate over a public X.25 data network as standardized by International Telecommunication Union’s recommendation X.25 (X.25 DTE-DCE mode). X25 sockets can also be used for communication without an intermediate X.25 network (X.25 DTE-DTE mode) as described in ISO/IEC 8208.

Message boundaries are preserved — a read(2) from a socket will retrieve the same chunk of data as output with the corresponding write(2) to the peer socket. When necessary, the kernel takes care of segmenting and reassembling long messages by means of the X.25 M-bit. There is no hard-coded upper limit for the message size. However, reassembling of a long message might fail if there is a temporary lack of system resources or when other constraints (such as socket memory or buffer size limits) become effective. If that occurs, the X.25 connection will be reset.

Socket addresses

The AF_X25 socket address family uses the struct sockaddr_x25 for representing network addresses as defined in ITU-T recommendation X.121.

struct sockaddr_x25 {
    sa_family_t sx25_family;    /* must be AF_X25 */
    x25_address sx25_addr;      /* X.121 Address */
};

sx25_addr contains a char array x25_addr[] to be interpreted as a null-terminated string. sx25_addr.x25_addr[] consists of up to 15 (not counting the terminating null byte) ASCII characters forming the X.121 address. Only the decimal digit characters from ‘0’ to ‘9’ are allowed.

Socket options

The following X.25-specific socket options can be set by using setsockopt(2) and read with getsockopt(2) with the level argument set to SOL_X25.

X25_QBITINCL
Controls whether the X.25 Q-bit (Qualified Data Bit) is accessible by the user. It expects an integer argument. If set to 0 (default), the Q-bit is never set for outgoing packets and the Q-bit of incoming packets is ignored. If set to 1, an additional first byte is prepended to each message read from or written to the socket. For data read from the socket, a 0 first byte indicates that the Q-bits of the corresponding incoming data packets were not set. A first byte with value 1 indicates that the Q-bit of the corresponding incoming data packets was set. If the first byte of the data written to the socket is 1, the Q-bit of the corresponding outgoing data packets will be set. If the first byte is 0, the Q-bit will not be set.

VERSIONS

The AF_X25 protocol family is a new feature of Linux 2.2.

BUGS

Plenty, as the X.25 PLP implementation is CONFIG_EXPERIMENTAL.

This man page is incomplete.

There is no dedicated application programmer’s header file yet; you need to include the kernel header file <linux/x25.h>. CONFIG_EXPERIMENTAL might also imply that future versions of the interface are not binary compatible.

X.25 N-Reset events are not propagated to the user process yet. Thus, if a reset occurred, data might be lost without notice.

SEE ALSO

socket(2), socket(7)

Jonathan Simon Naylor: “The Re-Analysis and Re-Implementation of X.25.” The URL is .

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

351 - Linux cli command DROP_ROLE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_ROLE and provides detailed information about the command DROP_ROLE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_ROLE.

NAME 🖥️ DROP_ROLE 🖥️

remove a database role

SYNOPSIS

DROP ROLE [ IF EXISTS ] name [, ...]

DESCRIPTION

DROP ROLE removes the specified role(s). To drop a superuser role, you must be a superuser yourself; to drop non-superuser roles, you must have CREATEROLE privilege and have been granted ADMIN OPTION on the role.

A role cannot be removed if it is still referenced in any database of the cluster; an error will be raised if so. Before dropping the role, you must drop all the objects it owns (or reassign their ownership) and revoke any privileges the role has been granted on other objects. The REASSIGN OWNED and DROP OWNED commands can be useful for this purpose; see Section 22.4 for more discussion.

However, it is not necessary to remove role memberships involving the role; DROP ROLE automatically revokes any memberships of the target role in other roles, and of other roles in the target role. The other roles are not dropped nor otherwise affected.

PARAMETERS

IF EXISTS

Do not throw an error if the role does not exist. A notice is issued in this case.

name

The name of the role to remove.

NOTES

PostgreSQL includes a program dropuser(1) that has the same functionality as this command (in fact, it calls this command) but can be run from the command shell.

EXAMPLES

To drop a role:

DROP ROLE jonathan;

COMPATIBILITY

The SQL standard defines DROP ROLE, but it allows only one role to be dropped at a time, and it specifies different privilege requirements than PostgreSQL uses.

SEE ALSO

CREATE ROLE (CREATE_ROLE(7)), ALTER ROLE (ALTER_ROLE(7)), SET ROLE (SET_ROLE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

352 - Linux cli command START_TRANSACTION

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command START_TRANSACTION and provides detailed information about the command START_TRANSACTION, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the START_TRANSACTION.

NAME 🖥️ START_TRANSACTION 🖥️

start a transaction block

SYNOPSIS

START TRANSACTION [ transaction_mode [, ...] ]

where transaction_mode is one of:

    ISOLATION LEVEL { SERIALIZABLE | REPEATABLE READ | READ COMMITTED | READ UNCOMMITTED }
    READ WRITE | READ ONLY
    [ NOT ] DEFERRABLE

DESCRIPTION

This command begins a new transaction block. If the isolation level, read/write mode, or deferrable mode is specified, the new transaction has those characteristics, as if SET TRANSACTION was executed. This is the same as the BEGIN command.

PARAMETERS

Refer to SET TRANSACTION (SET_TRANSACTION(7)) for information on the meaning of the parameters to this statement.

COMPATIBILITY

In the standard, it is not necessary to issue START TRANSACTION to start a transaction block: any SQL command implicitly begins a block. PostgreSQLs behavior can be seen as implicitly issuing a COMMIT after each command that does not follow START TRANSACTION (or BEGIN), and it is therefore often called “autocommit”. Other relational database systems might offer an autocommit feature as a convenience.

The DEFERRABLE transaction_mode is a PostgreSQL language extension.

The SQL standard requires commas between successive transaction_modes, but for historical reasons PostgreSQL allows the commas to be omitted.

See also the compatibility section of SET TRANSACTION (SET_TRANSACTION(7)).

SEE ALSO

BEGIN(7), COMMIT(7), ROLLBACK(7), SAVEPOINT(7), SET TRANSACTION (SET_TRANSACTION(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

353 - Linux cli command spufs

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command spufs and provides detailed information about the command spufs, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the spufs.

NAME 🖥️ spufs 🖥️

SPU filesystem

DESCRIPTION

The SPU filesystem is used on PowerPC machines that implement the Cell Broadband Engine Architecture in order to access Synergistic Processor Units (SPUs).

The filesystem provides a name space similar to POSIX shared memory or message queues. Users that have write permissions on the filesystem can use spu_create(2) to establish SPU contexts under the spufs root directory.

Every SPU context is represented by a directory containing a predefined set of files. These files can be used for manipulating the state of the logical SPU. Users can change permissions on the files, but can’t add or remove files.

Mount options

uid=<uid>
Set the user owning the mount point; the default is 0 (root).

gid=<gid>
Set the group owning the mount point; the default is 0 (root).

mode=<mode>
Set the mode of the top-level directory in spufs, as an octal mode string. The default is 0775.

Files

The files in spufs mostly follow the standard behavior for regular system calls like read(2) or write(2), but often support only a subset of the operations supported on regular filesystems. This list details the supported operations and the deviations from the standard behavior described in the respective man pages.

All files that support the read(2) operation also support readv(2) and all files that support the write(2) operation also support writev(2). All files support the access(2) and stat(2) family of operations, but for the latter call, the only fields of the returned stat structure that contain reliable information are st_mode, st_nlink, st_uid, and st_gid.

All files support the chmod(2)/ fchmod(2) and chown(2)/ fchown(2) operations, but will not be able to grant permissions that contradict the possible operations (e.g., read access on the wbox file).

The current set of files is:

/capabilities
Contains a comma-delimited string representing the capabilities of this SPU context. Possible capabilities are:

sched
This context may be scheduled.

step
This context can be run in single-step mode, for debugging.

New capabilities flags may be added in the future.

/mem
the contents of the local storage memory of the SPU. This can be accessed like a regular shared memory file and contains both code and data in the address space of the SPU. The possible operations on an open mem file are:

read(2)
pread(2)
write(2)
pwrite(2)
lseek(2)
These operate as usual, with the exception that lseek(2), write(2), and pwrite(2) are not supported beyond the end of the file. The file size is the size of the local storage of the SPU, which is normally 256 kilobytes.

mmap(2)
Mapping mem into the process address space provides access to the SPU local storage within the process address space. Only MAP_SHARED mappings are allowed.

/regs
Contains the saved general-purpose registers of the SPU context. This file contains the 128-bit values of each register, from register 0 to register 127, in order. This allows the general-purpose registers to be inspected for debugging.

Reading to or writing from this file requires that the context is scheduled out, so use of this file is not recommended in normal program operation.

The regs file is not present on contexts that have been created with the SPU_CREATE_NOSCHED flag.

/mbox
The first SPU-to-CPU communication mailbox. This file is read-only and can be read in units of 4 bytes. The file can be used only in nonblocking mode - even poll(2) cannot be used to block on this file. The only possible operation on an open mbox file is:

read(2)
If count is smaller than four, read(2) returns -1 and sets errno to EINVAL. If there is no data available in the mailbox (i.e., the SPU has not sent a mailbox message), the return value is set to -1 and errno is set to EAGAIN. When data has been read successfully, four bytes are placed in the data buffer and the value four is returned.

/ibox
The second SPU-to-CPU communication mailbox. This file is similar to the first mailbox file, but can be read in blocking I/O mode, thus calling read(2) on an open ibox file will block until the SPU has written data to its interrupt mailbox channel (unless the file has been opened with O_NONBLOCK, see below). Also, poll(2) and similar system calls can be used to monitor for the presence of mailbox data.

The possible operations on an open ibox file are:

read(2)
If count is smaller than four, read(2) returns -1 and sets errno to EINVAL. If there is no data available in the mailbox and the file descriptor has been opened with O_NONBLOCK, the return value is set to -1 and errno is set to EAGAIN.

If there is no data available in the mailbox and the file descriptor has been opened without O_NONBLOCK, the call will block until the SPU writes to its interrupt mailbox channel. When data has been read successfully, four bytes are placed in the data buffer and the value four is returned.

poll(2)
Poll on the ibox file returns (POLLIN | POLLRDNORM) whenever data is available for reading.

/wbox
The CPU-to-SPU communication mailbox. It is write-only and can be written in units of four bytes. If the mailbox is full, write(2) will block, and poll(2) can be used to block until the mailbox is available for writing again. The possible operations on an open wbox file are:

write(2)
If count is smaller than four, write(2) returns -1 and sets errno to EINVAL. If there is no space available in the mailbox and the file descriptor has been opened with O_NONBLOCK, the return value is set to -1 and errno is set to EAGAIN.

If there is no space available in the mailbox and the file descriptor has been opened without O_NONBLOCK, the call will block until the SPU reads from its PPE (PowerPC Processing Element) mailbox channel. When data has been written successfully, the system call returns four as its function result.

poll(2)
A poll on the wbox file returns (POLLOUT | POLLWRNORM) whenever space is available for writing.

/mbox_stat
/ibox_stat
/wbox_stat
These are read-only files that contain the length of the current queue of each mailbox—that is, how many words can be read from mbox or ibox or how many words can be written to wbox without blocking. The files can be read only in four-byte units and return a big-endian binary integer number. The only possible operation on an open *box_stat file is:

read(2)
If count is smaller than four, read(2) returns -1 and sets errno to EINVAL. Otherwise, a four-byte value is placed in the data buffer. This value is the number of elements that can be read from (for mbox_stat and ibox_stat) or written to (for wbox_stat) the respective mailbox without blocking or returning an EAGAIN error.

/npc
/decr
/decr_status
/spu_tag_mask
/event_mask
/event_status
/srr0
/lslr
Internal registers of the SPU. These files contain an ASCII string representing the hex value of the specified register. Reads and writes on these files (except for npc, see below) require that the SPU context be scheduled out, so frequent access to these files is not recommended for normal program operation.

The contents of these files are:

npc
Next Program Counter - valid only when the SPU is in a stopped state.

decr
SPU Decrementer

decr_status
Decrementer Status

spu_tag_mask
MFC tag mask for SPU DMA

event_mask
Event mask for SPU interrupts

event_status
Number of SPU events pending (read-only)

srr0
Interrupt Return address register

lslr
Local Store Limit Register

The possible operations on these files are:

read(2)
Reads the current register value. If the register value is larger than the buffer passed to the read(2) system call, subsequent reads will continue reading from the same buffer, until the end of the buffer is reached.

When a complete string has been read, all subsequent read operations will return zero bytes and a new file descriptor needs to be opened to read a new value.

write(2)
A write(2) operation on the file sets the register to the value given in the string. The string is parsed from the beginning until the first nonnumeric character or the end of the buffer. Subsequent writes to the same file descriptor overwrite the previous setting.

Except for the npc file, these files are not present on contexts that have been created with the SPU_CREATE_NOSCHED flag.

/fpcr
This file provides access to the Floating Point Status and Control Register (fcpr) as a binary, four-byte file. The operations on the fpcr file are:

read(2)
If count is smaller than four, read(2) returns -1 and sets errno to EINVAL. Otherwise, a four-byte value is placed in the data buffer; this is the current value of the fpcr register.

write(2)
If count is smaller than four, write(2) returns -1 and sets errno to EINVAL. Otherwise, a four-byte value is copied from the data buffer, updating the value of the fpcr register.

/signal1
/signal2
The files provide access to the two signal notification channels of an SPU. These are read-write files that operate on four-byte words. Writing to one of these files triggers an interrupt on the SPU. The value written to the signal files can be read from the SPU through a channel read or from host user space through the file. After the value has been read by the SPU, it is reset to zero. The possible operations on an open signal1 or signal2 file are:

read(2)
If count is smaller than four, read(2) returns -1 and sets errno to EINVAL. Otherwise, a four-byte value is placed in the data buffer; this is the current value of the specified signal notification register.

write(2)
If count is smaller than four, write(2) returns -1 and sets errno to EINVAL. Otherwise, a four-byte value is copied from the data buffer, updating the value of the specified signal notification register. The signal notification register will either be replaced with the input data or will be updated to the bitwise OR operation of the old value and the input data, depending on the contents of the signal1_type or signal2_type files respectively.

/signal1_type
/signal2_type
These two files change the behavior of the signal1 and signal2 notification files. They contain a numeric ASCII string which is read as either “1” or “0”. In mode 0 (overwrite), the hardware replaces the contents of the signal channel with the data that is written to it. In mode 1 (logical OR), the hardware accumulates the bits that are subsequently written to it. The possible operations on an open signal1_type or signal2_type file are:

read(2)
When the count supplied to the read(2) call is shorter than the required length for the digit (plus a newline character), subsequent reads from the same file descriptor will complete the string. When a complete string has been read, all subsequent read operations will return zero bytes and a new file descriptor needs to be opened to read the value again.

write(2)
A write(2) operation on the file sets the register to the value given in the string. The string is parsed from the beginning until the first nonnumeric character or the end of the buffer. Subsequent writes to the same file descriptor overwrite the previous setting.

/mbox_info
/ibox_info
/wbox_info
/dma_into
/proxydma_info
Read-only files that contain the saved state of the SPU mailboxes and DMA queues. This allows the SPU status to be inspected, mainly for debugging. The mbox_info and ibox_info files each contain the four-byte mailbox message that has been written by the SPU. If no message has been written to these mailboxes, then contents of these files is undefined. The mbox_stat, ibox_stat, and wbox_stat files contain the available message count.

The wbox_info file contains an array of four-byte mailbox messages, which have been sent to the SPU. With current CBEA machines, the array is four items in length, so up to 4 * 4 = 16 bytes can be read from this file. If any mailbox queue entry is empty, then the bytes read at the corresponding location are undefined.

The dma_info file contains the contents of the SPU MFC DMA queue, represented as the following structure:

struct spu_dma_info {
    uint64_t         dma_info_type;
    uint64_t         dma_info_mask;
    uint64_t         dma_info_status;
    uint64_t         dma_info_stall_and_notify;
    uint64_t         dma_info_atomic_command_status;
    struct mfc_cq_sr dma_info_command_data[16];
};

The last member of this data structure is the actual DMA queue, containing 16 entries. The mfc_cq_sr structure is defined as:

struct mfc_cq_sr {
    uint64_t mfc_cq_data0_RW;
    uint64_t mfc_cq_data1_RW;
    uint64_t mfc_cq_data2_RW;
    uint64_t mfc_cq_data3_RW;
};

The proxydma_info file contains similar information, but describes the proxy DMA queue (i.e., DMAs initiated by entities outside the SPU) instead. The file is in the following format:

struct spu_proxydma_info {
    uint64_t         proxydma_info_type;
    uint64_t         proxydma_info_mask;
    uint64_t         proxydma_info_status;
    struct mfc_cq_sr proxydma_info_command_data[8];
};

Accessing these files requires that the SPU context is scheduled out - frequent use can be inefficient. These files should not be used for normal program operation.

These files are not present on contexts that have been created with the SPU_CREATE_NOSCHED flag.

/cntl
This file provides access to the SPU Run Control and SPU status registers, as an ASCII string. The following operations are supported:

read(2)
Reads from the cntl file will return an ASCII string with the hex value of the SPU Status register.

write(2)
Writes to the cntl file will set the context’s SPU Run Control register.

/mfc
Provides access to the Memory Flow Controller of the SPU. Reading from the file returns the contents of the SPU’s MFC Tag Status register, and writing to the file initiates a DMA from the MFC. The following operations are supported:

write(2)
Writes to this file need to be in the format of a MFC DMA command, defined as follows:

struct mfc_dma_command {
    int32_t  pad;    /* reserved */
    uint32_t lsa;    /* local storage address */
    uint64_t ea;     /* effective address */
    uint16_t size;   /* transfer size */
    uint16_t tag;    /* command tag */
    uint16_t class;  /* class ID */
    uint16_t cmd;    /* command opcode */
};

Writes are required to be exactly sizeof(struct mfc_dma_command) bytes in size. The command will be sent to the SPU’s MFC proxy queue, and the tag stored in the kernel (see below).

read(2)
Reads the contents of the tag status register. If the file is opened in blocking mode (i.e., without O_NONBLOCK), then the read will block until a DMA tag (as performed by a previous write) is complete. In nonblocking mode, the MFC tag status register will be returned without waiting.

poll(2)
Calling poll(2) on the mfc file will block until a new DMA can be started (by checking for POLLOUT) or until a previously started DMA (by checking for POLLIN) has been completed.

/mss Provides access to the MFC MultiSource Synchronization (MSS) facility. By mmap(2)-ing this file, processes can access the MSS area of the SPU.

The following operations are supported:

mmap(2)
Mapping mss into the process address space gives access to the SPU MSS area within the process address space. Only MAP_SHARED mappings are allowed.

/psmap
Provides access to the whole problem-state mapping of the SPU. Applications can use this area to interface to the SPU, rather than writing to individual register files in spufs.

The following operations are supported:

mmap(2)
Mapping psmap gives a process a direct map of the SPU problem state area. Only MAP_SHARED mappings are supported.

/phys-id
Read-only file containing the physical SPU number that the SPU context is running on. When the context is not running, this file contains the string “-1”.

The physical SPU number is given by an ASCII hex string.

/object-id
Allows applications to store (or retrieve) a single 64-bit ID into the context. This ID is later used by profiling tools to uniquely identify the context.

write(2)
By writing an ASCII hex value into this file, applications can set the object ID of the SPU context. Any previous value of the object ID is overwritten.

read(2)
Reading this file gives an ASCII hex string representing the object ID for this SPU context.

EXAMPLES

To automatically mount(8) the SPU filesystem when booting, at the location /spu chosen by the user, put this line into the fstab(5) configuration file:

none /spu spufs gid=spu 0 0

SEE ALSO

close(2), spu_create(2), spu_run(2), capabilities(7)

The Cell Broadband Engine Architecture (CBEA) specification

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

354 - Linux cli command EVP_MD-MD4ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_MD-MD4ssl and provides detailed information about the command EVP_MD-MD4ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_MD-MD4ssl.

NAME 🖥️ EVP_MD-MD4ssl 🖥️

MD4 - The MD4 EVP_MD implementation

DESCRIPTION

Support for computing MD4 digests through the EVP_MD API.

Identity

This implementation is only available with the legacy provider, and is identified with the name “MD4”.

Gettable Parameters

This implementation supports the common gettable parameters described in EVP_MD-common (7).

SEE ALSO

provider-digest (7), OSSL_PROVIDER-default (7)

COPYRIGHT

Copyright 2020 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

355 - Linux cli command DROP_DOMAIN

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_DOMAIN and provides detailed information about the command DROP_DOMAIN, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_DOMAIN.

NAME 🖥️ DROP_DOMAIN 🖥️

remove a domain

SYNOPSIS

DROP DOMAIN [ IF EXISTS ] name [, ...] [ CASCADE | RESTRICT ]

DESCRIPTION

DROP DOMAIN removes a domain. Only the owner of a domain can remove it.

PARAMETERS

IF EXISTS

Do not throw an error if the domain does not exist. A notice is issued in this case.

name

The name (optionally schema-qualified) of an existing domain.

CASCADE

Automatically drop objects that depend on the domain (such as table columns), and in turn all objects that depend on those objects (see Section 5.14).

RESTRICT

Refuse to drop the domain if any objects depend on it. This is the default.

EXAMPLES

To remove the domain box:

DROP DOMAIN box;

COMPATIBILITY

This command conforms to the SQL standard, except for the IF EXISTS option, which is a PostgreSQL extension.

SEE ALSO

CREATE DOMAIN (CREATE_DOMAIN(7)), ALTER DOMAIN (ALTER_DOMAIN(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

356 - Linux cli command gitrevisions

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command gitrevisions and provides detailed information about the command gitrevisions, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the gitrevisions.

NAME 🖥️ gitrevisions 🖥️

Specifying revisions and ranges for Git

SYNOPSIS

gitrevisions

DESCRIPTION

Many Git commands take revision parameters as arguments. Depending on the command, they denote a specific commit or, for commands which walk the revision graph (such as git-log(1)), all commits which are reachable from that commit. For commands that walk the revision graph one can also specify a range of revisions explicitly.

In addition, some Git commands (such as git-show(1) and git-push(1)) can also take revision parameters which denote other objects than commits, e.g. blobs (“files”) or trees (“directories of files”).

SPECIFYING REVISIONS

A revision parameter <rev> typically, but not necessarily, names a commit object. It uses what is called an extended SHA-1 syntax. Here are various ways to spell object names. The ones listed near the end of this list name trees and blobs contained in a commit.

Note

This document shows the “raw” syntax as seen by git. The shell and other UIs might require additional quoting to protect special characters and to avoid word splitting.

<sha1>, e.g. dae86e1950b1277e545cee180551750029cfe735, dae86e

The full SHA-1 object name (40-byte hexadecimal string), or a leading substring that is unique within the repository. E.g. dae86e1950b1277e545cee180551750029cfe735 and dae86e both name the same commit object if there is no other object in your repository whose object name starts with dae86e.

<describeOutput>, e.g. v1.7.4.2-679-g3bee7fb

Output from git describe; i.e. a closest tag, optionally followed by a dash and a number of commits, followed by a dash, a g, and an abbreviated object name.

<refname>, e.g. master, heads/master, refs/heads/master

A symbolic ref name. E.g. master typically means the commit object referenced by refs/heads/master. If you happen to have both heads/master and tags/master, you can explicitly say heads/master to tell Git which one you mean. When ambiguous, a <refname> is disambiguated by taking the first match in the following rules:

1.

If $GIT_DIR/<refname> exists, that is what you mean (this is usually useful only for HEAD, FETCH_HEAD, ORIG_HEAD, MERGE_HEAD, REBASE_HEAD, REVERT_HEAD, CHERRY_PICK_HEAD, BISECT_HEAD and AUTO_MERGE);

2.

otherwise, refs/<refname> if it exists;

3.

otherwise, refs/tags/<refname> if it exists;

4.

otherwise, refs/heads/<refname> if it exists;

5.

otherwise, refs/remotes/<refname> if it exists;

6.

otherwise, refs/remotes/<refname>/HEAD if it exists.

HEAD

names the commit on which you based the changes in the working tree.

FETCH_HEAD

records the branch which you fetched from a remote repository with your last git fetch invocation.

ORIG_HEAD

is created by commands that move your HEAD in a drastic way (git am, git merge, git rebase, git reset), to record the position of the HEAD before their operation, so that you can easily change the tip of the branch back to the state before you ran them.

MERGE_HEAD

records the commit(s) which you are merging into your branch when you run git merge.

REBASE_HEAD

during a rebase, records the commit at which the operation is currently stopped, either because of conflicts or an edit command in an interactive rebase.

REVERT_HEAD

records the commit which you are reverting when you run git revert.

CHERRY_PICK_HEAD

records the commit which you are cherry-picking when you run git cherry-pick.

BISECT_HEAD

records the current commit to be tested when you run git bisect –no-checkout.

AUTO_MERGE

records a tree object corresponding to the state the ort merge strategy wrote to the working tree when a merge operation resulted in conflicts.

Note that any of the refs/* cases above may come either from the $GIT_DIR/refs directory or from the $GIT_DIR/packed-refs file. While the ref name encoding is unspecified, UTF-8 is preferred as some output processing may assume ref names in UTF-8.

@

@ alone is a shortcut for HEAD.

[<refname>]@{<date>}, e.g. master@{yesterday}, HEAD@{5 minutes ago}

A ref followed by the suffix @ with a date specification enclosed in a brace pair (e.g. {yesterday}, {1 month 2 weeks 3 days 1 hour 1 second ago} or {1979-02-26 18:30:00}) specifies the value of the ref at a prior point in time. This suffix may only be used immediately following a ref name and the ref must have an existing log ($GIT_DIR/logs/<ref>). Note that this looks up the state of your local ref at a given time; e.g., what was in your local master branch last week. If you want to look at commits made during certain times, see –since and –until.

<refname>@{<n>}, e.g. master@{1}

A ref followed by the suffix @ with an ordinal specification enclosed in a brace pair (e.g. {1}, {15}) specifies the n-th prior value of that ref. For example master@{1} is the immediate prior value of master while master@{5} is the 5th prior value of master. This suffix may only be used immediately following a ref name and the ref must have an existing log ($GIT_DIR/logs/<refname>).

@{<n>}, e.g. @{1}

You can use the @ construct with an empty ref part to get at a reflog entry of the current branch. For example, if you are on branch blabla then @{1} means the same as blabla@{1}.

@{-<n>}, e.g. @{-1}

The construct @{-<n>} means the <n>th branch/commit checked out before the current one.

[<branchname>]@{upstream}, e.g. master@{upstream}, @{u}

A branch B may be set up to build on top of a branch X (configured with branch.<name>.merge) at a remote R (configured with the branch X taken from remote R, typically found at refs/remotes/R/X.

[<branchname>]@{push}, e.g. master@{push}, @{push}

The suffix @{push} reports the branch “where we would push to” if git push were run while branchname was checked out (or the current HEAD if no branchname is specified). Like for @{upstream}, we report the remote-tracking branch that corresponds to that branch at the remote.

Here’s an example to make it more clear:

$ git config push.default current $ git config remote.pushdefault myfork $ git switch -c mybranch origin/master

$ git rev-parse --symbolic-full-name @{upstream}
refs/remotes/origin/master

$ git rev-parse --symbolic-full-name @{push}
refs/remotes/myfork/mybranch

Note in the example that we set up a triangular workflow, where we pull from one location and push to another. In a non-triangular workflow, @{push} is the same as @{upstream}, and there is no need for it.

This suffix is also accepted when spelled in uppercase, and means the same thing no matter the case.

<rev>^[<n>], e.g. HEAD^, v1.5.1^0

A suffix ^ to a revision parameter means the first parent of that commit object. ^<n> means the <n>th parent (i.e. <rev>^ is equivalent to <rev>^1). As a special rule, <rev>^0 means the commit itself and is used when <rev> is the object name of a tag object that refers to a commit object.

<rev>~[<n>], e.g. HEAD~, master~3

A suffix ~ to a revision parameter means the first parent of that commit object. A suffix ~<n> to a revision parameter means the commit object that is the <n>th generation ancestor of the named commit object, following only the first parents. I.e. <rev>~3 is equivalent to <rev>^^^ which is equivalent to <rev>^1^1^1. See below for an illustration of the usage of this form.

<rev>^{<type>}, e.g. v0.99.8^{commit}

A suffix ^ followed by an object type name enclosed in brace pair means dereference the object at <rev> recursively until an object of type <type> is found or the object cannot be dereferenced anymore (in which case, barf). For example, if <rev> is a commit-ish, <rev>^{commit} describes the corresponding commit object. Similarly, if <rev> is a tree-ish, <rev>^{tree} describes the corresponding tree object. <rev>^0 is a short-hand for <rev>^{commit}.

<rev>^{object} can be used to make sure <rev> names an object that exists, without requiring <rev> to be a tag, and without dereferencing <rev>; because a tag is already an object, it does not have to be dereferenced even once to get to an object.

<rev>^{tag} can be used to ensure that <rev> identifies an existing tag object.

<rev>^{}, e.g. v0.99.8^{}

A suffix ^ followed by an empty brace pair means the object could be a tag, and dereference the tag recursively until a non-tag object is found.

<rev>^{/<text>}, e.g. HEAD^{/fix nasty bug}

A suffix ^ to a revision parameter, followed by a brace pair that contains a text led by a slash, is the same as the :/fix nasty bug syntax below except that it returns the youngest matching commit which is reachable from the <rev> before ^.

:/<text>, e.g. :/fix nasty bug

A colon, followed by a slash, followed by a text, names a commit whose commit message matches the specified regular expression. This name returns the youngest matching commit which is reachable from any ref, including HEAD. The regular expression can match any part of the commit message. To match messages starting with a string, one can use e.g. :/^foo. The special sequence :/! is reserved for modifiers to what is matched. :/!-foo performs a negative match, while :/!!foo matches a literal ! character, followed by foo. Any other sequence beginning with :/! is reserved for now. Depending on the given text, the shell’s word splitting rules might require additional quoting.

<rev>:<path>, e.g. HEAD:README, master:./README

A suffix : followed by a path names the blob or tree at the given path in the tree-ish object named by the part before the colon. A path starting with ./ or ../ is relative to the current working directory. The given path will be converted to be relative to the working tree’s root directory. This is most useful to address a blob or tree from a commit or tree that has the same tree structure as the working tree.

:[<n>:]<path>, e.g. :0:README, :README

A colon, optionally followed by a stage number (0 to 3) and a colon, followed by a path, names a blob object in the index at the given path. A missing stage number (and the colon that follows it) names a stage 0 entry. During a merge, stage 1 is the common ancestor, stage 2 is the target branch’s version (typically the current branch), and stage 3 is the version from the branch which is being merged.

Here is an illustration, by Jon Loeliger. Both commit nodes B and C are parents of commit node A. Parent commits are ordered left-to-right.

G H I J \ / \ / D E F \ | /
\ | / | |/ | B C \ / \ / A

A = = A^0 B = A^ = A^1 = A1 C = = A^2 D = A^^ = A^1^1 = A2 E = B^2 = A^^2 F = B^3 = A^^3 G = A^^^ = A^1^1^1 = A3 H = D^2 = B^^2 = A^^^2 = A2^2 I = F^ = B^3^ = A^^3^ J = F^2 = B^3^2 = A^^3^2

SPECIFYING RANGES

History traversing commands such as git log operate on a set of commits, not just a single commit.

For these commands, specifying a single revision, using the notation described in the previous section, means the set of commits reachable from the given commit.

Specifying several revisions means the set of commits reachable from any of the given commits.

A commit’s reachable set is the commit itself and the commits in its ancestry chain.

There are several notations to specify a set of connected commits (called a “revision range”), illustrated below.

Commit Exclusions

^<rev> (caret) Notation

To exclude commits reachable from a commit, a prefix ^ notation is used. E.g. ^r1 r2 means commits reachable from r2 but exclude the ones reachable from r1 (i.e. r1 and its ancestors).

Dotted Range Notations

The .. (two-dot) Range Notation

The ^r1 r2 set operation appears so often that there is a shorthand for it. When you have two commits r1 and r2 (named according to the syntax explained in SPECIFYING REVISIONS above), you can ask for commits that are reachable from r2 excluding those that are reachable from r1 by ^r1 r2 and it can be written as r1..r2.

The … (three-dot) Symmetric Difference Notation

A similar notation r1…r2 is called symmetric difference of r1 and r2 and is defined as r1 r2 –not $(git merge-base –all r1 r2). It is the set of commits that are reachable from either one of r1 (left side) or r2 (right side) but not from both.

In these two shorthand notations, you can omit one end and let it default to HEAD. For example, origin.. is a shorthand for origin..HEAD and asks “What did I do since I forked from the origin branch?” Similarly, ..origin is a shorthand for HEAD..origin and asks “What did the origin do since I forked from them?” Note that .. would mean HEAD..HEAD which is an empty range that is both reachable and unreachable from HEAD.

Commands that are specifically designed to take two distinct ranges (e.g. “git range-diff R1 R2” to compare two ranges) do exist, but they are exceptions. Unless otherwise noted, all “git” commands that operate on a set of commits work on a single revision range. In other words, writing two “two-dot range notation” next to each other, e.g.

$ git log A..B C..D

does not specify two revision ranges for most commands. Instead it will name a single connected set of commits, i.e. those that are reachable from either B or D but are reachable from neither A or C. In a linear history like this:

—A—B—o—o—C—D

because A and B are reachable from C, the revision range specified by these two dotted ranges is a single commit D.

Other <rev>^ Parent Shorthand Notations

Three other shorthands exist, particularly useful for merge commits, for naming a set that is formed by a commit and its parent commits.

The r1^@ notation means all parents of r1.

The r1^! notation includes commit r1 but excludes all of its parents. By itself, this notation denotes the single commit r1.

The <rev>^-[<n>] notation includes <rev> but excludes the <n>th parent (i.e. a shorthand for <rev>^<n>..<rev>), with <n> = 1 if not given. This is typically useful for merge commits where you can just pass <commit>^- to get all the commits in the branch that was merged in merge commit <commit> (including <commit> itself).

While <rev>^<n> was about specifying a single commit parent, these three notations also consider its parents. For example you can say HEAD^2^@, however you cannot say HEAD^@^2.

REVISION RANGE SUMMARY

<rev>

Include commits that are reachable from <rev> (i.e. <rev> and its ancestors).

^<rev>

Exclude commits that are reachable from <rev> (i.e. <rev> and its ancestors).

<rev1>..<rev2>

Include commits that are reachable from <rev2> but exclude those that are reachable from <rev1>. When either <rev1> or <rev2> is omitted, it defaults to HEAD.

<rev1>…<rev2>

Include commits that are reachable from either <rev1> or <rev2> but exclude those that are reachable from both. When either <rev1> or <rev2> is omitted, it defaults to HEAD.

<rev>^@, e.g. HEAD^@

A suffix ^ followed by an at sign is the same as listing all parents of <rev> (meaning, include anything reachable from its parents, but not the commit itself).

<rev>^!, e.g. HEAD^!

A suffix ^ followed by an exclamation mark is the same as giving commit <rev> and all its parents prefixed with ^ to exclude them (and their ancestors).

<rev>^-<n>, e.g. HEAD^-, HEAD^-2

Equivalent to <rev>^<n>..<rev>, with <n> = 1 if not given.

Here are a handful of examples using the Loeliger illustration above, with each step in the notation’s expansion and selection carefully spelt out:

Args Expanded arguments Selected commits D G H D D F G H I J D F ^G D H D ^D B E I J F B ^D B C E I J F B C C I J F C B..C = ^B C C B…C = B ^F C G H D E B C B^- = B^..B = ^B^1 B E I J F B C^@ = C^1 = F I J F B^@ = B^1 B^2 B^3 = D E F D G H E F I J C^! = C ^C^@ = C ^C^1 = C ^F C B^! = B ^B^@ = B ^B^1 ^B^2 ^B^3 = B ^D ^E ^F B F^! D = F ^I ^J D G H D F

SEE ALSO

git-rev-parse(1)

GIT

Part of the git(1) suite

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

357 - Linux cli command DROP_OPERATOR_FAMILY

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_OPERATOR_FAMILY and provides detailed information about the command DROP_OPERATOR_FAMILY, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_OPERATOR_FAMILY.

NAME 🖥️ DROP_OPERATOR_FAMILY 🖥️

remove an operator family

SYNOPSIS

DROP OPERATOR FAMILY [ IF EXISTS ] name USING index_method [ CASCADE | RESTRICT ]

DESCRIPTION

DROP OPERATOR FAMILY drops an existing operator family. To execute this command you must be the owner of the operator family.

DROP OPERATOR FAMILY includes dropping any operator classes contained in the family, but it does not drop any of the operators or functions referenced by the family. If there are any indexes depending on operator classes within the family, you will need to specify CASCADE for the drop to complete.

PARAMETERS

IF EXISTS

Do not throw an error if the operator family does not exist. A notice is issued in this case.

name

The name (optionally schema-qualified) of an existing operator family.

index_method

The name of the index access method the operator family is for.

CASCADE

Automatically drop objects that depend on the operator family, and in turn all objects that depend on those objects (see Section 5.14).

RESTRICT

Refuse to drop the operator family if any objects depend on it. This is the default.

EXAMPLES

Remove the B-tree operator family float_ops:

DROP OPERATOR FAMILY float_ops USING btree;

This command will not succeed if there are any existing indexes that use operator classes within the family. Add CASCADE to drop such indexes along with the operator family.

COMPATIBILITY

There is no DROP OPERATOR FAMILY statement in the SQL standard.

SEE ALSO

ALTER OPERATOR FAMILY (ALTER_OPERATOR_FAMILY(7)), CREATE OPERATOR FAMILY (CREATE_OPERATOR_FAMILY(7)), ALTER OPERATOR CLASS (ALTER_OPERATOR_CLASS(7)), CREATE OPERATOR CLASS (CREATE_OPERATOR_CLASS(7)), DROP OPERATOR CLASS (DROP_OPERATOR_CLASS(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

358 - Linux cli command EVP_KEM-ECssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KEM-ECssl and provides detailed information about the command EVP_KEM-ECssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KEM-ECssl.

NAME 🖥️ EVP_KEM-ECssl 🖥️

EC - EVP_KEM EC keytype and algorithm support

DESCRIPTION

The EC keytype and its parameters are described in EVP_PKEY-EC (7). See EVP_PKEY_encapsulate (3) and EVP_PKEY_decapsulate (3) for more info.

EC KEM parameters

“operation” (OSSL_KEM_PARAM_OPERATION)<UTF8 string>
The OpenSSL EC Key Encapsulation Mechanisms only supports the following operation:

“DHKEM” (OSSL_KEM_PARAM_OPERATION_DHKEM)
The encapsulate function generates an ephemeral keypair. It produces keymaterial by doing an ECDH key exchange using the ephemeral private key and a supplied recipient public key. A HKDF operation using the keymaterial and a kem context then produces a shared secret. The shared secret and the ephemeral public key are returned. The decapsulate function uses the recipient private key and the ephemeral public key to produce the same keymaterial, which can then be used to produce the same shared secret. See <https://www.rfc-editor.org/rfc/rfc9180.html#name-dh-based-kem-dhkem>

This can be set using either EVP_PKEY_CTX_set_kem_op() or EVP_PKEY_CTX_set_params().

“ikme” (OSSL_KEM_PARAM_IKME) <octet string>
Used to specify the key material used for generation of the ephemeral key. This value should not be reused for other purposes. It can only be used for the curves “P-256”, “P-384” and “P-521” and should have a length of at least the size of the encoded private key (i.e. 32, 48 and 66 for the listed curves). If this value is not set, then a random ikm is used.

CONFORMING TO

RFC9180

SEE ALSO

EVP_PKEY_CTX_set_kem_op (3), EVP_PKEY_encapsulate (3), EVP_PKEY_decapsulate (3) EVP_KEYMGMT (3), EVP_PKEY (3), provider-keymgmt (7)

HISTORY

This functionality was added in OpenSSL 3.2.

COPYRIGHT

Copyright 2022 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

359 - Linux cli command ALTER_TYPE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_TYPE and provides detailed information about the command ALTER_TYPE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_TYPE.

NAME 🖥️ ALTER_TYPE 🖥️

change the definition of a type

SYNOPSIS

ALTER TYPE name OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }
ALTER TYPE name RENAME TO new_name
ALTER TYPE name SET SCHEMA new_schema
ALTER TYPE name RENAME ATTRIBUTE attribute_name TO new_attribute_name [ CASCADE | RESTRICT ]
ALTER TYPE name action [, ... ]
ALTER TYPE name ADD VALUE [ IF NOT EXISTS ] new_enum_value [ { BEFORE | AFTER } neighbor_enum_value ]
ALTER TYPE name RENAME VALUE existing_enum_value TO new_enum_value
ALTER TYPE name SET ( property = value [, ... ] )

where action is one of:

    ADD ATTRIBUTE attribute_name data_type [ COLLATE collation ] [ CASCADE | RESTRICT ]
    DROP ATTRIBUTE [ IF EXISTS ] attribute_name [ CASCADE | RESTRICT ]
    ALTER ATTRIBUTE attribute_name [ SET DATA ] TYPE data_type [ COLLATE collation ] [ CASCADE | RESTRICT ]

DESCRIPTION

ALTER TYPE changes the definition of an existing type. There are several subforms:

OWNER

This form changes the owner of the type.

RENAME

This form changes the name of the type.

SET SCHEMA

This form moves the type into another schema.

RENAME ATTRIBUTE

This form is only usable with composite types. It changes the name of an individual attribute of the type.

ADD ATTRIBUTE

This form adds a new attribute to a composite type, using the same syntax as CREATE TYPE.

DROP ATTRIBUTE [ IF EXISTS ]

This form drops an attribute from a composite type. If IF EXISTS is specified and the attribute does not exist, no error is thrown. In this case a notice is issued instead.

ALTER ATTRIBUTE … SET DATA TYPE

This form changes the type of an attribute of a composite type.

ADD VALUE [ IF NOT EXISTS ] [ BEFORE | AFTER ]

This form adds a new value to an enum type. The new values place in the enums ordering can be specified as being BEFORE or AFTER one of the existing values. Otherwise, the new item is added at the end of the list of values.

If IF NOT EXISTS is specified, it is not an error if the type already contains the new value: a notice is issued but no other action is taken. Otherwise, an error will occur if the new value is already present.

RENAME VALUE

This form renames a value of an enum type. The values place in the enums ordering is not affected. An error will occur if the specified value is not present or the new name is already present.

SET ( property = value [, … ] )

This form is only applicable to base types. It allows adjustment of a subset of the base-type properties that can be set in CREATE TYPE. Specifically, these properties can be changed:

·

RECEIVE can be set to the name of a binary input function, or NONE to remove the types binary input function. Using this option requires superuser privilege.

·

SEND can be set to the name of a binary output function, or NONE to remove the types binary output function. Using this option requires superuser privilege.

·

TYPMOD_IN can be set to the name of a type modifier input function, or NONE to remove the types type modifier input function. Using this option requires superuser privilege.

·

TYPMOD_OUT can be set to the name of a type modifier output function, or NONE to remove the types type modifier output function. Using this option requires superuser privilege.

·

ANALYZE can be set to the name of a type-specific statistics collection function, or NONE to remove the types statistics collection function. Using this option requires superuser privilege.

·

SUBSCRIPT can be set to the name of a type-specific subscripting handler function, or NONE to remove the types subscripting handler function. Using this option requires superuser privilege.

·

STORAGE can be set to plain, extended, external, or main (see Section 73.2 for more information about what these mean). However, changing from plain to another setting requires superuser privilege (because it requires that the types C functions all be TOAST-ready), and changing to plain from another setting is not allowed at all (since the type may already have TOASTed values present in the database). Note that changing this option doesnt by itself change any stored data, it just sets the default TOAST strategy to be used for table columns created in the future. See ALTER TABLE (ALTER_TABLE(7)) to change the TOAST strategy for existing table columns.

See CREATE TYPE (CREATE_TYPE(7)) for more details about these type properties. Note that where appropriate, a change in these properties for a base type will be propagated automatically to domains based on that type.

The ADD ATTRIBUTE, DROP ATTRIBUTE, and ALTER ATTRIBUTE actions can be combined into a list of multiple alterations to apply in parallel. For example, it is possible to add several attributes and/or alter the type of several attributes in a single command.

You must own the type to use ALTER TYPE. To change the schema of a type, you must also have CREATE privilege on the new schema. To alter the owner, you must be able to SET ROLE to the new owning role, and that role must have CREATE privilege on the types schema. (These restrictions enforce that altering the owner doesnt do anything you couldnt do by dropping and recreating the type. However, a superuser can alter ownership of any type anyway.) To add an attribute or alter an attribute type, you must also have USAGE privilege on the attributes data type.

PARAMETERS

name

The name (possibly schema-qualified) of an existing type to alter.

new_name

The new name for the type.

new_owner

The user name of the new owner of the type.

new_schema

The new schema for the type.

attribute_name

The name of the attribute to add, alter, or drop.

new_attribute_name

The new name of the attribute to be renamed.

data_type

The data type of the attribute to add, or the new type of the attribute to alter.

new_enum_value

The new value to be added to an enum types list of values, or the new name to be given to an existing value. Like all enum literals, it needs to be quoted.

neighbor_enum_value

The existing enum value that the new value should be added immediately before or after in the enum types sort ordering. Like all enum literals, it needs to be quoted.

existing_enum_value

The existing enum value that should be renamed. Like all enum literals, it needs to be quoted.

property

The name of a base-type property to be modified; see above for possible values.

CASCADE

Automatically propagate the operation to typed tables of the type being altered, and their descendants.

RESTRICT

Refuse the operation if the type being altered is the type of a typed table. This is the default.

NOTES

If ALTER TYPE … ADD VALUE (the form that adds a new value to an enum type) is executed inside a transaction block, the new value cannot be used until after the transaction has been committed.

Comparisons involving an added enum value will sometimes be slower than comparisons involving only original members of the enum type. This will usually only occur if BEFORE or AFTER is used to set the new values sort position somewhere other than at the end of the list. However, sometimes it will happen even though the new value is added at the end (this occurs if the OID counter “wrapped around” since the original creation of the enum type). The slowdown is usually insignificant; but if it matters, optimal performance can be regained by dropping and recreating the enum type, or by dumping and restoring the database.

EXAMPLES

To rename a data type:

ALTER TYPE electronic_mail RENAME TO email;

To change the owner of the type email to joe:

ALTER TYPE email OWNER TO joe;

To change the schema of the type email to customers:

ALTER TYPE email SET SCHEMA customers;

To add a new attribute to a composite type:

ALTER TYPE compfoo ADD ATTRIBUTE f3 int;

To add a new value to an enum type in a particular sort position:

ALTER TYPE colors ADD VALUE orange AFTER red;

To rename an enum value:

ALTER TYPE colors RENAME VALUE purple TO mauve;

To create binary I/O functions for an existing base type:

CREATE FUNCTION mytypesend(mytype) RETURNS bytea …; CREATE FUNCTION mytyperecv(internal, oid, integer) RETURNS mytype …; ALTER TYPE mytype SET ( SEND = mytypesend, RECEIVE = mytyperecv );

COMPATIBILITY

The variants to add and drop attributes are part of the SQL standard; the other variants are PostgreSQL extensions.

SEE ALSO

CREATE TYPE (CREATE_TYPE(7)), DROP TYPE (DROP_TYPE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

360 - Linux cli command iso_8859_5

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso_8859_5 and provides detailed information about the command iso_8859_5, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso_8859_5.

NAME 🖥️ iso_8859_5 🖥️

5 - ISO/IEC 8859-5 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-5 encodes the Cyrillic characters used in many East European languages.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-5 characters

The following table displays the characters in ISO/IEC 8859-5 that are printable and unlisted in the ascii(7) manual page.

TABLE

SEE ALSO

ascii(7), charsets(7), cp1251(7), koi8-r(7), koi8-u(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

361 - Linux cli command OSSL_PROVIDER-FIPSssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command OSSL_PROVIDER-FIPSssl and provides detailed information about the command OSSL_PROVIDER-FIPSssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the OSSL_PROVIDER-FIPSssl.

NAME 🖥️ OSSL_PROVIDER-FIPSssl 🖥️

FIPS - OpenSSL FIPS provider

DESCRIPTION

The OpenSSL FIPS provider is a special provider that conforms to the Federal Information Processing Standards (FIPS) specified in FIPS 140-3. This ‘module’ contains an approved set of cryptographic algorithms that is validated by an accredited testing laboratory.

Properties

The implementations in this provider specifically have these properties defined:

“provider=fips”

“fips=yes”

It may be used in a property query string with fetching functions such as EVP_MD_fetch (3) or EVP_CIPHER_fetch (3), as well as with other functions that take a property query string, such as EVP_PKEY_CTX_new_from_name (3).

To be FIPS compliant, it is mandatory to include fips=yes as part of all property queries. This ensures that only FIPS approved implementations are used for cryptographic operations. The fips=yes query may also include other non-crypto support operations that are not in the FIPS provider, such as asymmetric key encoders, see “Asymmetric Key Management” in OSSL_PROVIDER-default (7).

It is not mandatory to include provider=fips as part of your property query. Including provider=fips in your property query guarantees that the OpenSSL FIPS provider is used for cryptographic operations rather than other FIPS capable providers.

Provider parameters

See “Provider parameters” in provider-base (7) for a list of base parameters. Additionally the OpenSSL FIPS provider also supports the following gettable parameters:

“security-checks” (OSSL_OSSL_PROV_PARAM_SECURITY_CHECKS) <unsigned integer>
For further information refer to the openssl-fipsinstall (1) option -no_security_checks.

OPERATIONS AND ALGORITHMS

The OpenSSL FIPS provider supports these operations and algorithms:

Hashing Algorithms / Message Digests

SHA1, see EVP_MD-SHA1 (7)

SHA2, see EVP_MD-SHA2 (7)

SHA3, see EVP_MD-SHA3 (7)

KECCAK-KMAC, see EVP_MD-KECCAK-KMAC (7)

SHAKE, see EVP_MD-SHAKE (7)

Symmetric Ciphers

AES, see EVP_CIPHER-AES (7)

3DES, see EVP_CIPHER-DES (7)

This is an unapproved algorithm.

Message Authentication Code (MAC)

CMAC, see EVP_MAC-CMAC (7)

GMAC, see EVP_MAC-GMAC (7)

HMAC, see EVP_MAC-HMAC (7)

KMAC, see EVP_MAC-KMAC (7)

Key Derivation Function (KDF)

HKDF, see EVP_KDF-HKDF (7)

TLS13-KDF, see EVP_KDF-TLS13_KDF (7)

SSKDF, see EVP_KDF-SS (7)

PBKDF2, see EVP_KDF-PBKDF2 (7)

SSHKDF, see EVP_KDF-SSHKDF (7)

TLS1-PRF, see EVP_KDF-TLS1_PRF (7)

KBKDF, see EVP_KDF-KB (7)

X942KDF-ASN1, see EVP_KDF-X942-ASN1 (7)

X942KDF-CONCAT, see EVP_KDF-X942-CONCAT (7)

X963KDF, see EVP_KDF-X963 (7)

Key Exchange

DH, see EVP_KEYEXCH-DH (7)

ECDH, see EVP_KEYEXCH-ECDH (7)

X25519, see EVP_KEYEXCH-X25519 (7)

X448, see EVP_KEYEXCH-X448 (7)

TLS1-PRF

HKDF

Asymmetric Signature

RSA, see EVP_SIGNATURE-RSA (7)

DSA, see EVP_SIGNATURE-DSA (7)

ED25519, see EVP_SIGNATURE-ED25519 (7)

This is an unapproved algorithm.

ED448, see EVP_SIGNATURE-ED448 (7)
This is an unapproved algorithm.

ECDSA, see EVP_SIGNATURE-ECDSA (7)

HMAC, see EVP_SIGNATURE-HMAC (7)

CMAC, see EVP_SIGNATURE-CMAC (7)

Asymmetric Cipher

RSA, see EVP_ASYM_CIPHER-RSA (7)

Asymmetric Key Encapsulation

RSA, see EVP_KEM-RSA (7)

Asymmetric Key Management

DH, see EVP_KEYMGMT-DH (7)

DHX, see EVP_KEYMGMT-DHX (7)

DSA, see EVP_KEYMGMT-DSA (7)

RSA, see EVP_KEYMGMT-RSA (7)

RSA-PSS

EC, see EVP_KEYMGMT-EC (7)

X25519, see EVP_KEYMGMT-X25519 (7)

X448, see EVP_KEYMGMT-X448 (7)

ED25519, see EVP_KEYMGMT-ED25519 (7)

This is an unapproved algorithm.

ED448, see EVP_KEYMGMT-ED448 (7)
This is an unapproved algorithm.

TLS1-PRF

HKDF

HMAC, see EVP_KEYMGMT-HMAC (7)

CMAC, see EVP_KEYMGMT-CMAC (7)

Random Number Generation

CTR-DRBG, see EVP_RAND-CTR-DRBG (7)

HASH-DRBG, see EVP_RAND-HASH-DRBG (7)

HMAC-DRBG, see EVP_RAND-HMAC-DRBG (7)

TEST-RAND, see EVP_RAND-TEST-RAND (7)

TEST-RAND is an unapproved algorithm.

SELF TESTING

One of the requirements for the FIPS module is self testing. An optional callback mechanism is available to return information to the user using OSSL_SELF_TEST_set_callback (3).

The parameters passed to the callback are described in OSSL_SELF_TEST_new (3)

The OpenSSL FIPS module uses the following mechanism to provide information about the self tests as they run. This is useful for debugging if a self test is failing. The callback also allows forcing any self test to fail, in order to check that it operates correctly on failure. Note that all self tests run even if a self test failure occurs.

The FIPS module passes the following type(s) to OSSL_SELF_TEST_onbegin().

“Module_Integrity” (OSSL_SELF_TEST_TYPE_MODULE_INTEGRITY)
Uses HMAC SHA256 on the module file to validate that the module has not been modified. The integrity value is compared to a value written to a configuration file during installation.

“Install_Integrity” (OSSL_SELF_TEST_TYPE_INSTALL_INTEGRITY)
Uses HMAC SHA256 on a fixed string to validate that the installation process has already been performed and the self test KATS have already been tested, The integrity value is compared to a value written to a configuration file after successfully running the self tests during installation.

“KAT_Cipher” (OSSL_SELF_TEST_TYPE_KAT_CIPHER)
Known answer test for a symmetric cipher.

“KAT_AsymmetricCipher” (OSSL_SELF_TEST_TYPE_KAT_ASYM_CIPHER)
Known answer test for a asymmetric cipher.

“KAT_Digest” (OSSL_SELF_TEST_TYPE_KAT_DIGEST)
Known answer test for a digest.

“KAT_Signature” (OSSL_SELF_TEST_TYPE_KAT_SIGNATURE)
Known answer test for a signature.

“PCT_Signature” (OSSL_SELF_TEST_TYPE_PCT_SIGNATURE)
Pairwise Consistency check for a signature.

“KAT_KDF” (OSSL_SELF_TEST_TYPE_KAT_KDF)
Known answer test for a key derivation function.

“KAT_KA” (OSSL_SELF_TEST_TYPE_KAT_KA)
Known answer test for key agreement.

“DRBG” (OSSL_SELF_TEST_TYPE_DRBG)
Known answer test for a Deterministic Random Bit Generator.

“Conditional_PCT” (OSSL_SELF_TEST_TYPE_PCT)
Conditional test that is run during the generation of key pairs.

“Continuous_RNG_Test” (OSSL_SELF_TEST_TYPE_CRNG)
Continuous random number generator test.

The “Module_Integrity” self test is always run at startup. The “Install_Integrity” self test is used to check if the self tests have already been run at installation time. If they have already run then the self tests are not run on subsequent startups. All other self test categories are run once at installation time, except for the “Pairwise_Consistency_Test”.

There is only one instance of the “Module_Integrity” and “Install_Integrity” self tests. All other self tests may have multiple instances.

The FIPS module passes the following descriptions(s) to OSSL_SELF_TEST_onbegin().

“HMAC” (OSSL_SELF_TEST_DESC_INTEGRITY_HMAC)
“Module_Integrity” and “Install_Integrity” use this.

“RSA” (OSSL_SELF_TEST_DESC_PCT_RSA_PKCS1)

“ECDSA” (OSSL_SELF_TEST_DESC_PCT_ECDSA)

“DSA” (OSSL_SELF_TEST_DESC_PCT_DSA)

Key generation tests used with the “Pairwise_Consistency_Test” type.

“RSA_Encrypt” (OSSL_SELF_TEST_DESC_ASYM_RSA_ENC)

“RSA_Decrypt” (OSSL_SELF_TEST_DESC_ASYM_RSA_DEC)

“KAT_AsymmetricCipher” uses this to indicate an encrypt or decrypt KAT.

“AES_GCM” (OSSL_SELF_TEST_DESC_CIPHER_AES_GCM)

“AES_ECB_Decrypt” (OSSL_SELF_TEST_DESC_CIPHER_AES_ECB)

“TDES” (OSSL_SELF_TEST_DESC_CIPHER_TDES)

Symmetric cipher tests used with the “KAT_Cipher” type.

“SHA1” (OSSL_SELF_TEST_DESC_MD_SHA1)

“SHA2” (OSSL_SELF_TEST_DESC_MD_SHA2)

“SHA3” (OSSL_SELF_TEST_DESC_MD_SHA3)

Digest tests used with the “KAT_Digest” type.

“DSA” (OSSL_SELF_TEST_DESC_SIGN_DSA)

“RSA” (OSSL_SELF_TEST_DESC_SIGN_RSA)

“ECDSA” (OSSL_SELF_TEST_DESC_SIGN_ECDSA)

Signature tests used with the “KAT_Signature” type.

“ECDH” (OSSL_SELF_TEST_DESC_KA_ECDH)

“DH” (OSSL_SELF_TEST_DESC_KA_DH)

Key agreement tests used with the “KAT_KA” type.

“HKDF” (OSSL_SELF_TEST_DESC_KDF_HKDF)

“TLS13_KDF_EXTRACT” (OSSL_SELF_TEST_DESC_KDF_TLS13_EXTRACT)

“TLS13_KDF_EXPAND” (OSSL_SELF_TEST_DESC_KDF_TLS13_EXPAND)

“SSKDF” (OSSL_SELF_TEST_DESC_KDF_SSKDF)

“X963KDF” (OSSL_SELF_TEST_DESC_KDF_X963KDF)

“X942KDF” (OSSL_SELF_TEST_DESC_KDF_X942KDF)

“PBKDF2” (OSSL_SELF_TEST_DESC_KDF_PBKDF2)

“SSHKDF” (OSSL_SELF_TEST_DESC_KDF_SSHKDF)

“TLS12_PRF” (OSSL_SELF_TEST_DESC_KDF_TLS12_PRF)

“KBKDF” (OSSL_SELF_TEST_DESC_KDF_KBKDF)

Key Derivation Function tests used with the “KAT_KDF” type.

“CTR” (OSSL_SELF_TEST_DESC_DRBG_CTR)

“HASH” (OSSL_SELF_TEST_DESC_DRBG_HASH)

“HMAC” (OSSL_SELF_TEST_DESC_DRBG_HMAC)

DRBG tests used with the “DRBG” type. = item “RNG” (OSSL_SELF_TEST_DESC_RNG) “Continuous_RNG_Test” uses this.

EXAMPLES

A simple self test callback is shown below for illustrative purposes.

#include <openssl/self_test.h> static OSSL_CALLBACK self_test_cb; static int self_test_cb(const OSSL_PARAM params[], void *arg) { int ret = 0; const OSSL_PARAM *p = NULL; const char *phase = NULL, *type = NULL, *desc = NULL; p = OSSL_PARAM_locate_const(params, OSSL_PROV_PARAM_SELF_TEST_PHASE); if (p == NULL || p->data_type != OSSL_PARAM_UTF8_STRING) goto err; phase = (const char *)p->data; p = OSSL_PARAM_locate_const(params, OSSL_PROV_PARAM_SELF_TEST_DESC); if (p == NULL || p->data_type != OSSL_PARAM_UTF8_STRING) goto err; desc = (const char *)p->data; p = OSSL_PARAM_locate_const(params, OSSL_PROV_PARAM_SELF_TEST_TYPE); if (p == NULL || p->data_type != OSSL_PARAM_UTF8_STRING) goto err; type = (const char *)p->data; /* Do some logging */ if (strcmp(phase, OSSL_SELF_TEST_PHASE_START) == 0) BIO_printf(bio_out, “%s : (%s) : “, desc, type); if (strcmp(phase, OSSL_SELF_TEST_PHASE_PASS) == 0 || strcmp(phase, OSSL_SELF_TEST_PHASE_FAIL) == 0) BIO_printf(bio_out, “%s “, phase); /* Corrupt the SHA1 self test during the corrupt phase by returning 0 */ if (strcmp(phase, OSSL_SELF_TEST_PHASE_CORRUPT) == 0 && strcmp(desc, OSSL_SELF_TEST_DESC_MD_SHA1) == 0) { BIO_printf(bio_out, “%s %s”, phase, desc); return 0; } ret = 1; err: return ret; }

NOTES

Some released versions of OpenSSL do not include a validated FIPS provider. To determine which versions have undergone the validation process, please refer to the OpenSSL Downloads page <https://www.openssl.org/source/>. If you require FIPS-approved functionality, it is essential to build your FIPS provider using one of the validated versions listed there. Normally, it is possible to utilize a FIPS provider constructed from one of the validated versions alongside libcrypto and libssl compiled from any release within the same major release series. This flexibility enables you to address bug fixes and CVEs that fall outside the FIPS boundary.

The FIPS provider in OpenSSL 3.1 includes some non-FIPS validated algorithms, consequently the property query fips=yes is mandatory for applications that want to operate in a FIPS approved manner. The algorithms are:

Triple DES ECB

Triple DES CBC

EdDSA

SEE ALSO

openssl-fipsinstall (1), fips_config (5), OSSL_SELF_TEST_set_callback (3), OSSL_SELF_TEST_new (3), OSSL_PARAM (3), openssl-core.h (7), openssl-core_dispatch.h (7), provider (7), <https://www.openssl.org/source/>

HISTORY

This functionality was added in OpenSSL 3.0.

COPYRIGHT

Copyright 2019-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

362 - Linux cli command iso_8859-9

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso_8859-9 and provides detailed information about the command iso_8859-9, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso_8859-9.

NAME 🖥️ iso_8859-9 🖥️

9 - ISO/IEC 8859-9 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-9 encodes the characters used in Turkish.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-9 characters

The following table displays the characters in ISO/IEC 8859-9 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-9 is also known as Latin-5.

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

363 - Linux cli command ALTER_CONVERSION

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_CONVERSION and provides detailed information about the command ALTER_CONVERSION, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_CONVERSION.

NAME 🖥️ ALTER_CONVERSION 🖥️

change the definition of a conversion

SYNOPSIS

ALTER CONVERSION name RENAME TO new_name
ALTER CONVERSION name OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }
ALTER CONVERSION name SET SCHEMA new_schema

DESCRIPTION

ALTER CONVERSION changes the definition of a conversion.

You must own the conversion to use ALTER CONVERSION. To alter the owner, you must be able to SET ROLE to the new owning role, and that role must have CREATE privilege on the conversions schema. (These restrictions enforce that altering the owner doesnt do anything you couldnt do by dropping and recreating the conversion. However, a superuser can alter ownership of any conversion anyway.)

PARAMETERS

name

The name (optionally schema-qualified) of an existing conversion.

new_name

The new name of the conversion.

new_owner

The new owner of the conversion.

new_schema

The new schema for the conversion.

EXAMPLES

To rename the conversion iso_8859_1_to_utf8 to latin1_to_unicode:

ALTER CONVERSION iso_8859_1_to_utf8 RENAME TO latin1_to_unicode;

To change the owner of the conversion iso_8859_1_to_utf8 to joe:

ALTER CONVERSION iso_8859_1_to_utf8 OWNER TO joe;

COMPATIBILITY

There is no ALTER CONVERSION statement in the SQL standard.

SEE ALSO

CREATE CONVERSION (CREATE_CONVERSION(7)), DROP CONVERSION (DROP_CONVERSION(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

364 - Linux cli command ALTER_SERVER

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_SERVER and provides detailed information about the command ALTER_SERVER, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_SERVER.

NAME 🖥️ ALTER_SERVER 🖥️

change the definition of a foreign server

SYNOPSIS

ALTER SERVER name [ VERSION new_version ]
    [ OPTIONS ( [ ADD | SET | DROP ] option [value] [, ... ] ) ]
ALTER SERVER name OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }
ALTER SERVER name RENAME TO new_name

DESCRIPTION

ALTER SERVER changes the definition of a foreign server. The first form changes the server version string or the generic options of the server (at least one clause is required). The second form changes the owner of the server.

To alter the server you must be the owner of the server. Additionally to alter the owner, you must be able to SET ROLE to the new owning role, and you must have USAGE privilege on the servers foreign-data wrapper. (Note that superusers satisfy all these criteria automatically.)

PARAMETERS

name

The name of an existing server.

new_version

New server version.

OPTIONS ( [ ADD | SET | DROP ] option [value] [, … ] )

Change options for the server. ADD, SET, and DROP specify the action to be performed. ADD is assumed if no operation is explicitly specified. Option names must be unique; names and values are also validated using the servers foreign-data wrapper library.

new_owner

The user name of the new owner of the foreign server.

new_name

The new name for the foreign server.

EXAMPLES

Alter server foo, add connection options:

ALTER SERVER foo OPTIONS (host foo, dbname foodb);

Alter server foo, change version, change host option:

ALTER SERVER foo VERSION 8.4 OPTIONS (SET host baz);

COMPATIBILITY

ALTER SERVER conforms to ISO/IEC 9075-9 (SQL/MED). The OWNER TO and RENAME forms are PostgreSQL extensions.

SEE ALSO

CREATE SERVER (CREATE_SERVER(7)), DROP SERVER (DROP_SERVER(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

365 - Linux cli command signal

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command signal and provides detailed information about the command signal, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the signal.

NAME 🖥️ signal 🖥️

overview of signals

DESCRIPTION

Linux supports both POSIX reliable signals (hereinafter “standard signals”) and POSIX real-time signals.

Signal dispositions

Each signal has a current disposition, which determines how the process behaves when it is delivered the signal.

The entries in the “Action” column of the table below specify the default disposition for each signal, as follows:

Term
Default action is to terminate the process.

Ign
Default action is to ignore the signal.

Core
Default action is to terminate the process and dump core (see core(5)).

Stop
Default action is to stop the process.

Cont
Default action is to continue the process if it is currently stopped.

A process can change the disposition of a signal using sigaction(2) or signal(2). (The latter is less portable when establishing a signal handler; see signal(2) for details.) Using these system calls, a process can elect one of the following behaviors to occur on delivery of the signal: perform the default action; ignore the signal; or catch the signal with a signal handler, a programmer-defined function that is automatically invoked when the signal is delivered.

By default, a signal handler is invoked on the normal process stack. It is possible to arrange that the signal handler uses an alternate stack; see sigaltstack(2) for a discussion of how to do this and when it might be useful.

The signal disposition is a per-process attribute: in a multithreaded application, the disposition of a particular signal is the same for all threads.

A child created via fork(2) inherits a copy of its parent’s signal dispositions. During an execve(2), the dispositions of handled signals are reset to the default; the dispositions of ignored signals are left unchanged.

Sending a signal

The following system calls and library functions allow the caller to send a signal:

raise(3)
Sends a signal to the calling thread.

kill(2)
Sends a signal to a specified process, to all members of a specified process group, or to all processes on the system.

pidfd_send_signal(2)
Sends a signal to a process identified by a PID file descriptor.

killpg(3)
Sends a signal to all of the members of a specified process group.

pthread_kill(3)
Sends a signal to a specified POSIX thread in the same process as the caller.

tgkill(2)
Sends a signal to a specified thread within a specific process. (This is the system call used to implement pthread_kill(3).)

sigqueue(3)
Sends a real-time signal with accompanying data to a specified process.

Waiting for a signal to be caught

The following system calls suspend execution of the calling thread until a signal is caught (or an unhandled signal terminates the process):

pause(2)
Suspends execution until any signal is caught.

sigsuspend(2)
Temporarily changes the signal mask (see below) and suspends execution until one of the unmasked signals is caught.

Synchronously accepting a signal

Rather than asynchronously catching a signal via a signal handler, it is possible to synchronously accept the signal, that is, to block execution until the signal is delivered, at which point the kernel returns information about the signal to the caller. There are two general ways to do this:

  • sigwaitinfo(2), sigtimedwait(2), and sigwait(3) suspend execution until one of the signals in a specified set is delivered. Each of these calls returns information about the delivered signal.

  • signalfd(2) returns a file descriptor that can be used to read information about signals that are delivered to the caller. Each read(2) from this file descriptor blocks until one of the signals in the set specified in the signalfd(2) call is delivered to the caller. The buffer returned by read(2) contains a structure describing the signal.

Signal mask and pending signals

A signal may be blocked, which means that it will not be delivered until it is later unblocked. Between the time when it is generated and when it is delivered a signal is said to be pending.

Each thread in a process has an independent signal mask, which indicates the set of signals that the thread is currently blocking. A thread can manipulate its signal mask using pthread_sigmask(3). In a traditional single-threaded application, sigprocmask(2) can be used to manipulate the signal mask.

A child created via fork(2) inherits a copy of its parent’s signal mask; the signal mask is preserved across execve(2).

A signal may be process-directed or thread-directed. A process-directed signal is one that is targeted at (and thus pending for) the process as a whole. A signal may be process-directed because it was generated by the kernel for reasons other than a hardware exception, or because it was sent using kill(2) or sigqueue(3). A thread-directed signal is one that is targeted at a specific thread. A signal may be thread-directed because it was generated as a consequence of executing a specific machine-language instruction that triggered a hardware exception (e.g., SIGSEGV for an invalid memory access, or SIGFPE for a math error), or because it was targeted at a specific thread using interfaces such as tgkill(2) or pthread_kill(3).

A process-directed signal may be delivered to any one of the threads that does not currently have the signal blocked. If more than one of the threads has the signal unblocked, then the kernel chooses an arbitrary thread to which to deliver the signal.

A thread can obtain the set of signals that it currently has pending using sigpending(2). This set will consist of the union of the set of pending process-directed signals and the set of signals pending for the calling thread.

A child created via fork(2) initially has an empty pending signal set; the pending signal set is preserved across an execve(2).

Execution of signal handlers

Whenever there is a transition from kernel-mode to user-mode execution (e.g., on return from a system call or scheduling of a thread onto the CPU), the kernel checks whether there is a pending unblocked signal for which the process has established a signal handler. If there is such a pending signal, the following steps occur:

  1. The kernel performs the necessary preparatory steps for execution of the signal handler:

    (1.1)
    The signal is removed from the set of pending signals.

    (1.2)
    If the signal handler was installed by a call to sigaction(2) that specified the SA_ONSTACK flag and the thread has defined an alternate signal stack (using sigaltstack(2)), then that stack is installed.

    (1.3)
    Various pieces of signal-related context are saved into a special frame that is created on the stack. The saved information includes:

    • the program counter register (i.e., the address of the next instruction in the main program that should be executed when the signal handler returns);

    • architecture-specific register state required for resuming the interrupted program;

    • the thread’s current signal mask;

    • the thread’s alternate signal stack settings.

    (If the signal handler was installed using the sigaction(2) SA_SIGINFO flag, then the above information is accessible via the ucontext_t object that is pointed to by the third argument of the signal handler.)

    (1.4)
    Any signals specified in act->sa_mask when registering the handler with sigprocmask(2) are added to the thread’s signal mask. The signal being delivered is also added to the signal mask, unless SA_NODEFER was specified when registering the handler. These signals are thus blocked while the handler executes.

  2. The kernel constructs a frame for the signal handler on the stack. The kernel sets the program counter for the thread to point to the first instruction of the signal handler function, and configures the return address for that function to point to a piece of user-space code known as the signal trampoline (described in sigreturn(2)).

  3. The kernel passes control back to user-space, where execution commences at the start of the signal handler function.

  4. When the signal handler returns, control passes to the signal trampoline code.

  5. The signal trampoline calls sigreturn(2), a system call that uses the information in the stack frame created in step 1 to restore the thread to its state before the signal handler was called. The thread’s signal mask and alternate signal stack settings are restored as part of this procedure. Upon completion of the call to sigreturn(2), the kernel transfers control back to user space, and the thread recommences execution at the point where it was interrupted by the signal handler.

Note that if the signal handler does not return (e.g., control is transferred out of the handler using siglongjmp(3), or the handler executes a new program with execve(2)), then the final step is not performed. In particular, in such scenarios it is the programmer’s responsibility to restore the state of the signal mask (using sigprocmask(2)), if it is desired to unblock the signals that were blocked on entry to the signal handler. (Note that siglongjmp(3) may or may not restore the signal mask, depending on the savesigs value that was specified in the corresponding call to sigsetjmp(3).)

From the kernel’s point of view, execution of the signal handler code is exactly the same as the execution of any other user-space code. That is to say, the kernel does not record any special state information indicating that the thread is currently executing inside a signal handler. All necessary state information is maintained in user-space registers and the user-space stack. The depth to which nested signal handlers may be invoked is thus limited only by the user-space stack (and sensible software design!).

Standard signals

Linux supports the standard signals listed below. The second column of the table indicates which standard (if any) specified the signal: “P1990” indicates that the signal is described in the original POSIX.1-1990 standard; “P2001” indicates that the signal was added in SUSv2 and POSIX.1-2001.

SignalStandardActionComment
SIGABRTP1990CoreAbort signal from abort(3)
SIGALRMP1990TermTimer signal from alarm(2)
SIGBUSP2001CoreBus error (bad memory access)
SIGCHLDP1990IgnChild stopped or terminated
SIGCLD-IgnA synonym for SIGCHLD
SIGCONTP1990ContContinue if stopped
SIGEMT-TermEmulator trap
SIGFPEP1990CoreFloating-point exception
SIGHUPP1990TermHangup detected on controlling terminal
or death of controlling process
SIGILLP1990CoreIllegal Instruction
SIGINFO-A synonym for SIGPWR
SIGINTP1990TermInterrupt from keyboard
SIGIO-TermI/O now possible (4.2BSD)
SIGIOT-CoreIOT trap. A synonym for SIGABRT
SIGKILLP1990TermKill signal
SIGLOST-TermFile lock lost (unused)
SIGPIPEP1990TermBroken pipe: write to pipe with no
readers; see pipe(7)
SIGPOLLP2001TermPollable event (Sys V);
synonym for SIGIO
SIGPROFP2001TermProfiling timer expired
SIGPWR-TermPower failure (System V)
SIGQUITP1990CoreQuit from keyboard
SIGSEGVP1990CoreInvalid memory reference
SIGSTKFLT-TermStack fault on coprocessor (unused)
SIGSTOPP1990StopStop process
SIGTSTPP1990StopStop typed at terminal
SIGSYSP2001CoreBad system call (SVr4);
see also seccomp(2)
SIGTERMP1990TermTermination signal
SIGTRAPP2001CoreTrace/breakpoint trap
SIGTTINP1990StopTerminal input for background process
SIGTTOUP1990StopTerminal output for background process
SIGUNUSED-CoreSynonymous with SIGSYS
SIGURGP2001IgnUrgent condition on socket (4.2BSD)
SIGUSR1P1990TermUser-defined signal 1
SIGUSR2P1990TermUser-defined signal 2
SIGVTALRMP2001TermVirtual alarm clock (4.2BSD)
SIGXCPUP2001CoreCPU time limit exceeded (4.2BSD);
see setrlimit(2)
SIGXFSZP2001CoreFile size limit exceeded (4.2BSD);
see setrlimit(2)
SIGWINCH-IgnWindow resize signal (4.3BSD, Sun)

The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored.

Up to and including Linux 2.2, the default behavior for SIGSYS, SIGXCPU, SIGXFSZ, and (on architectures other than SPARC and MIPS) SIGBUS was to terminate the process (without a core dump). (On some other UNIX systems the default action for SIGXCPU and SIGXFSZ is to terminate the process without a core dump.) Linux 2.4 conforms to the POSIX.1-2001 requirements for these signals, terminating the process with a core dump.

SIGEMT is not specified in POSIX.1-2001, but nevertheless appears on most other UNIX systems, where its default action is typically to terminate the process with a core dump.

SIGPWR (which is not specified in POSIX.1-2001) is typically ignored by default on those other UNIX systems where it appears.

SIGIO (which is not specified in POSIX.1-2001) is ignored by default on several other UNIX systems.

Queueing and delivery semantics for standard signals

If multiple standard signals are pending for a process, the order in which the signals are delivered is unspecified.

Standard signals do not queue. If multiple instances of a standard signal are generated while that signal is blocked, then only one instance of the signal is marked as pending (and the signal will be delivered just once when it is unblocked). In the case where a standard signal is already pending, the siginfo_t structure (see sigaction(2)) associated with that signal is not overwritten on arrival of subsequent instances of the same signal. Thus, the process will receive the information associated with the first instance of the signal.

Signal numbering for standard signals

The numeric value for each signal is given in the table below. As shown in the table, many signals have different numeric values on different architectures. The first numeric value in each table row shows the signal number on x86, ARM, and most other architectures; the second value is for Alpha and SPARC; the third is for MIPS; and the last is for PARISC. A dash (-) denotes that a signal is absent on the corresponding architecture.

Signalx86/ARMAlpha/MIPSPARISCNotes
most othersSPARC
SIGHUP 1 1 1 1
SIGINT 2 2 2 2
SIGQUIT 3 3 3 3
SIGILL 4 4 4 4
SIGTRAP 5 5 5 5
SIGABRT 6 6 6 6
SIGIOT 6 6 6 6
SIGBUS 7101010
SIGEMT- 7 7-
SIGFPE 8 8 8 8
SIGKILL 9 9 9 9
SIGUSR110301616
SIGSEGV11111111
SIGUSR212311717
SIGPIPE13131313
SIGALRM14141414
SIGTERM15151515
SIGSTKFLT16-- 7
SIGCHLD17201818
SIGCLD--18-
SIGCONT18192526
SIGSTOP19172324
SIGTSTP20182425
SIGTTIN21212627
SIGTTOU22222728
SIGURG23162129
SIGXCPU24243012
SIGXFSZ25253130
SIGVTALRM26262820
SIGPROF27272921
SIGWINCH28282023
SIGIO29232222
SIGPOLLSame as SIGIO
SIGPWR3029/-1919
SIGINFO-29/---
SIGLOST--/29--
SIGSYS31121231
SIGUNUSED31--31

Note the following:

  • Where defined, SIGUNUSED is synonymous with SIGSYS. Since glibc 2.26, SIGUNUSED is no longer defined on any architecture.

  • Signal 29 is SIGINFO/SIGPWR (synonyms for the same value) on Alpha but SIGLOST on SPARC.

Real-time signals

Starting with Linux 2.2, Linux supports real-time signals as originally defined in the POSIX.1b real-time extensions (and now included in POSIX.1-2001). The range of supported real-time signals is defined by the macros SIGRTMIN and SIGRTMAX. POSIX.1-2001 requires that an implementation support at least _POSIX_RTSIG_MAX (8) real-time signals.

The Linux kernel supports a range of 33 different real-time signals, numbered 32 to 64. However, the glibc POSIX threads implementation internally uses two (for NPTL) or three (for LinuxThreads) real-time signals (see pthreads(7)), and adjusts the value of SIGRTMIN suitably (to 34 or 35). Because the range of available real-time signals varies according to the glibc threading implementation (and this variation can occur at run time according to the available kernel and glibc), and indeed the range of real-time signals varies across UNIX systems, programs should never refer to real-time signals using hard-coded numbers, but instead should always refer to real-time signals using the notation SIGRTMIN+n, and include suitable (run-time) checks that SIGRTMIN+n does not exceed SIGRTMAX.

Unlike standard signals, real-time signals have no predefined meanings: the entire set of real-time signals can be used for application-defined purposes.

The default action for an unhandled real-time signal is to terminate the receiving process.

Real-time signals are distinguished by the following:

  • Multiple instances of real-time signals can be queued. By contrast, if multiple instances of a standard signal are delivered while that signal is currently blocked, then only one instance is queued.

  • If the signal is sent using sigqueue(3), an accompanying value (either an integer or a pointer) can be sent with the signal. If the receiving process establishes a handler for this signal using the SA_SIGINFO flag to sigaction(2), then it can obtain this data via the si_value field of the siginfo_t structure passed as the second argument to the handler. Furthermore, the si_pid and si_uid fields of this structure can be used to obtain the PID and real user ID of the process sending the signal.

  • Real-time signals are delivered in a guaranteed order. Multiple real-time signals of the same type are delivered in the order they were sent. If different real-time signals are sent to a process, they are delivered starting with the lowest-numbered signal. (I.e., low-numbered signals have highest priority.) By contrast, if multiple standard signals are pending for a process, the order in which they are delivered is unspecified.

If both standard and real-time signals are pending for a process, POSIX leaves it unspecified which is delivered first. Linux, like many other implementations, gives priority to standard signals in this case.

According to POSIX, an implementation should permit at least _POSIX_SIGQUEUE_MAX (32) real-time signals to be queued to a process. However, Linux does things differently. Up to and including Linux 2.6.7, Linux imposes a system-wide limit on the number of queued real-time signals for all processes. This limit can be viewed and (with privilege) changed via the /proc/sys/kernel/rtsig-max file. A related file, /proc/sys/kernel/rtsig-nr, can be used to find out how many real-time signals are currently queued. In Linux 2.6.8, these /proc interfaces were replaced by the RLIMIT_SIGPENDING resource limit, which specifies a per-user limit for queued signals; see setrlimit(2) for further details.

The addition of real-time signals required the widening of the signal set structure (sigset_t) from 32 to 64 bits. Consequently, various system calls were superseded by new system calls that supported the larger signal sets. The old and new system calls are as follows:

Linux 2.0 and earlierLinux 2.2 and later
sigaction(2)rt_sigaction(2)
sigpending(2)rt_sigpending(2)
sigprocmask(2)rt_sigprocmask(2)
sigreturn(2)rt_sigreturn(2)
sigsuspend(2)rt_sigsuspend(2)
sigtimedwait(2)rt_sigtimedwait(2)

Interruption of system calls and library functions by signal handlers

If a signal handler is invoked while a system call or library function call is blocked, then either:

  • the call is automatically restarted after the signal handler returns; or

  • the call fails with the error EINTR.

Which of these two behaviors occurs depends on the interface and whether or not the signal handler was established using the SA_RESTART flag (see sigaction(2)). The details vary across UNIX systems; below, the details for Linux.

If a blocked call to one of the following interfaces is interrupted by a signal handler, then the call is automatically restarted after the signal handler returns if the SA_RESTART flag was used; otherwise the call fails with the error EINTR:

  • read(2), readv(2), write(2), writev(2), and ioctl(2) calls on “slow” devices. A “slow” device is one where the I/O call may block for an indefinite time, for example, a terminal, pipe, or socket. If an I/O call on a slow device has already transferred some data by the time it is interrupted by a signal handler, then the call will return a success status (normally, the number of bytes transferred). Note that a (local) disk is not a slow device according to this definition; I/O operations on disk devices are not interrupted by signals.

  • open(2), if it can block (e.g., when opening a FIFO; see fifo(7)).

  • wait(2), wait3(2), wait4(2), waitid(2), and waitpid(2).

  • Socket interfaces: accept(2), connect(2), recv(2), recvfrom(2), recvmmsg(2), recvmsg(2), send(2), sendto(2), and sendmsg(2), unless a timeout has been set on the socket (see below).

  • File locking interfaces: flock(2) and the F_SETLKW and F_OFD_SETLKW operations of fcntl(2)

  • POSIX message queue interfaces: mq_receive(3), mq_timedreceive(3), mq_send(3), and mq_timedsend(3).

  • futex(2) FUTEX_WAIT (since Linux 2.6.22; beforehand, always failed with EINTR).

  • getrandom(2).

  • pthread_mutex_lock(3), pthread_cond_wait(3), and related APIs.

  • futex(2) FUTEX_WAIT_BITSET.

  • POSIX semaphore interfaces: sem_wait(3) and sem_timedwait(3) (since Linux 2.6.22; beforehand, always failed with EINTR).

  • read(2) from an inotify(7) file descriptor (since Linux 3.8; beforehand, always failed with EINTR).

The following interfaces are never restarted after being interrupted by a signal handler, regardless of the use of SA_RESTART; they always fail with the error EINTR when interrupted by a signal handler:

  • “Input” socket interfaces, when a timeout (SO_RCVTIMEO) has been set on the socket using setsockopt(2): accept(2), recv(2), recvfrom(2), recvmmsg(2) (also with a non-NULL timeout argument), and recvmsg(2).

  • “Output” socket interfaces, when a timeout (SO_RCVTIMEO) has been set on the socket using setsockopt(2): connect(2), send(2), sendto(2), and sendmsg(2).

  • Interfaces used to wait for signals: pause(2), sigsuspend(2), sigtimedwait(2), and sigwaitinfo(2).

  • File descriptor multiplexing interfaces: epoll_wait(2), epoll_pwait(2), poll(2), ppoll(2), select(2), and pselect(2).

  • System V IPC interfaces: msgrcv(2), msgsnd(2), semop(2), and semtimedop(2).

  • Sleep interfaces: clock_nanosleep(2), nanosleep(2), and usleep(3).

  • io_getevents(2).

The sleep(3) function is also never restarted if interrupted by a handler, but gives a success return: the number of seconds remaining to sleep.

In certain circumstances, the seccomp(2) user-space notification feature can lead to restarting of system calls that would otherwise never be restarted by SA_RESTART; for details, see seccomp_unotify(2).

Interruption of system calls and library functions by stop signals

On Linux, even in the absence of signal handlers, certain blocking interfaces can fail with the error EINTR after the process is stopped by one of the stop signals and then resumed via SIGCONT. This behavior is not sanctioned by POSIX.1, and doesn’t occur on other systems.

The Linux interfaces that display this behavior are:

  • “Input” socket interfaces, when a timeout (SO_RCVTIMEO) has been set on the socket using setsockopt(2): accept(2), recv(2), recvfrom(2), recvmmsg(2) (also with a non-NULL timeout argument), and recvmsg(2).

  • “Output” socket interfaces, when a timeout (SO_RCVTIMEO) has been set on the socket using setsockopt(2): connect(2), send(2), sendto(2), and sendmsg(2), if a send timeout (SO_SNDTIMEO) has been set.

  • epoll_wait(2), epoll_pwait(2).

  • semop(2), semtimedop(2).

  • sigtimedwait(2), sigwaitinfo(2).

  • Linux 3.7 and earlier: read(2) from an inotify(7) file descriptor

  • Linux 2.6.21 and earlier: futex(2) FUTEX_WAIT, sem_timedwait(3), sem_wait(3).

  • Linux 2.6.8 and earlier: msgrcv(2), msgsnd(2).

  • Linux 2.4 and earlier: nanosleep(2).

STANDARDS

POSIX.1, except as noted.

NOTES

For a discussion of async-signal-safe functions, see signal-safety(7).

The /proc/pid/task/tid/status file contains various fields that show the signals that a thread is blocking (SigBlk), catching (SigCgt), or ignoring (SigIgn). (The set of signals that are caught or ignored will be the same across all threads in a process.) Other fields show the set of pending signals that are directed to the thread (SigPnd) as well as the set of pending signals that are directed to the process as a whole (ShdPnd). The corresponding fields in /proc/pid/status show the information for the main thread. See proc(5) for further details.

BUGS

There are six signals that can be delivered as a consequence of a hardware exception: SIGBUS, SIGEMT, SIGFPE, SIGILL, SIGSEGV, and SIGTRAP. Which of these signals is delivered, for any given hardware exception, is not documented and does not always make sense.

For example, an invalid memory access that causes delivery of SIGSEGV on one CPU architecture may cause delivery of SIGBUS on another architecture, or vice versa.

For another example, using the x86 int instruction with a forbidden argument (any number other than 3 or 128) causes delivery of SIGSEGV, even though SIGILL would make more sense, because of how the CPU reports the forbidden operation to the kernel.

SEE ALSO

kill(1), clone(2), getrlimit(2), kill(2), pidfd_send_signal(2), restart_syscall(2), rt_sigqueueinfo(2), setitimer(2), setrlimit(2), sgetmask(2), sigaction(2), sigaltstack(2), signal(2), signalfd(2), sigpending(2), sigprocmask(2), sigreturn(2), sigsuspend(2), sigwaitinfo(2), abort(3), bsd_signal(3), killpg(3), longjmp(3), pthread_sigqueue(3), raise(3), sigqueue(3), sigset(3), sigsetops(3), sigvec(3), sigwait(3), strsignal(3), swapcontext(3), sysv_signal(3), core(5), proc(5), nptl(7), pthreads(7), sigevent(3type)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

366 - Linux cli command ALTER_TEXT_SEARCH_CONFIGURATION

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_TEXT_SEARCH_CONFIGURATION and provides detailed information about the command ALTER_TEXT_SEARCH_CONFIGURATION, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_TEXT_SEARCH_CONFIGURATION.

NAME 🖥️ ALTER_TEXT_SEARCH_CONFIGURATION 🖥️

change the definition of a text search configuration

SYNOPSIS

ALTER TEXT SEARCH CONFIGURATION name
    ADD MAPPING FOR token_type [, ... ] WITH dictionary_name [, ... ]
ALTER TEXT SEARCH CONFIGURATION name
    ALTER MAPPING FOR token_type [, ... ] WITH dictionary_name [, ... ]
ALTER TEXT SEARCH CONFIGURATION name
    ALTER MAPPING REPLACE old_dictionary WITH new_dictionary
ALTER TEXT SEARCH CONFIGURATION name
    ALTER MAPPING FOR token_type [, ... ] REPLACE old_dictionary WITH new_dictionary
ALTER TEXT SEARCH CONFIGURATION name
    DROP MAPPING [ IF EXISTS ] FOR token_type [, ... ]
ALTER TEXT SEARCH CONFIGURATION name RENAME TO new_name
ALTER TEXT SEARCH CONFIGURATION name OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }
ALTER TEXT SEARCH CONFIGURATION name SET SCHEMA new_schema

DESCRIPTION

ALTER TEXT SEARCH CONFIGURATION changes the definition of a text search configuration. You can modify its mappings from token types to dictionaries, or change the configurations name or owner.

You must be the owner of the configuration to use ALTER TEXT SEARCH CONFIGURATION.

PARAMETERS

name

The name (optionally schema-qualified) of an existing text search configuration.

token_type

The name of a token type that is emitted by the configurations parser.

dictionary_name

The name of a text search dictionary to be consulted for the specified token type(s). If multiple dictionaries are listed, they are consulted in the specified order.

old_dictionary

The name of a text search dictionary to be replaced in the mapping.

new_dictionary

The name of a text search dictionary to be substituted for old_dictionary.

new_name

The new name of the text search configuration.

new_owner

The new owner of the text search configuration.

new_schema

The new schema for the text search configuration.

The ADD MAPPING FOR form installs a list of dictionaries to be consulted for the specified token type(s); it is an error if there is already a mapping for any of the token types. The ALTER MAPPING FOR form does the same, but first removing any existing mapping for those token types. The ALTER MAPPING REPLACE forms substitute new_dictionary for old_dictionary anywhere the latter appears. This is done for only the specified token types when FOR appears, or for all mappings of the configuration when it doesnt. The DROP MAPPING form removes all dictionaries for the specified token type(s), causing tokens of those types to be ignored by the text search configuration. It is an error if there is no mapping for the token types, unless IF EXISTS appears.

EXAMPLES

The following example replaces the english dictionary with the swedish dictionary anywhere that english is used within my_config.

ALTER TEXT SEARCH CONFIGURATION my_config ALTER MAPPING REPLACE english WITH swedish;

COMPATIBILITY

There is no ALTER TEXT SEARCH CONFIGURATION statement in the SQL standard.

SEE ALSO

CREATE TEXT SEARCH CONFIGURATION (CREATE_TEXT_SEARCH_CONFIGURATION(7)), DROP TEXT SEARCH CONFIGURATION (DROP_TEXT_SEARCH_CONFIGURATION(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

367 - Linux cli command svipc

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command svipc and provides detailed information about the command svipc, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the svipc.

NAME 🖥️ svipc 🖥️

System V interprocess communication mechanisms

DESCRIPTION

System V IPC is the name given to three interprocess communication mechanisms that are widely available on UNIX systems: message queues, semaphore, and shared memory.

Message queues

System V message queues allow data to be exchanged in units called messages. Each message can have an associated priority. POSIX message queues provide an alternative API for achieving the same result; see mq_overview(7).

The System V message queue API consists of the following system calls:

msgget(2)
Create a new message queue or obtain the ID of an existing message queue. This call returns an identifier that is used in the remaining APIs.

msgsnd(2)
Add a message to a queue.

msgrcv(2)
Remove a message from a queue.

msgctl(2)
Perform various control operations on a queue, including deletion.

Semaphore sets

System V semaphores allow processes to synchronize their actions. System V semaphores are allocated in groups called sets; each semaphore in a set is a counting semaphore. POSIX semaphores provide an alternative API for achieving the same result; see sem_overview(7).

The System V semaphore API consists of the following system calls:

semget(2)
Create a new set or obtain the ID of an existing set. This call returns an identifier that is used in the remaining APIs.

semop(2)
Perform operations on the semaphores in a set.

semctl(2)
Perform various control operations on a set, including deletion.

Shared memory segments

System V shared memory allows processes to share a region a memory (a “segment”). POSIX shared memory is an alternative API for achieving the same result; see shm_overview(7).

The System V shared memory API consists of the following system calls:

shmget(2)
Create a new segment or obtain the ID of an existing segment. This call returns an identifier that is used in the remaining APIs.

shmat(2)
Attach an existing shared memory object into the calling process’s address space.

shmdt(2)
Detach a segment from the calling process’s address space.

shmctl(2)
Perform various control operations on a segment, including deletion.

IPC namespaces

For a discussion of the interaction of System V IPC objects and IPC namespaces, see ipc_namespaces(7).

SEE ALSO

ipcmk(1), ipcrm(1), ipcs(1), lsipc(1), ipc(2), msgctl(2), msgget(2), msgrcv(2), msgsnd(2), semctl(2), semget(2), semop(2), shmat(2), shmctl(2), shmdt(2), shmget(2), ftok(3), ipc_namespaces(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

368 - Linux cli command EVP_ASYM_CIPHER-RSAssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_ASYM_CIPHER-RSAssl and provides detailed information about the command EVP_ASYM_CIPHER-RSAssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_ASYM_CIPHER-RSAssl.

NAME 🖥️ EVP_ASYM_CIPHER-RSAssl 🖥️

RSA - RSA Asymmetric Cipher algorithm support

DESCRIPTION

Asymmetric Cipher support for the RSA key type.

RSA Asymmetric Cipher parameters

“pad-mode” (OSSL_ASYM_CIPHER_PARAM_PAD_MODE) <UTF8 string>
The default provider understands these RSA padding modes in string form:

“none” (OSSL_PKEY_RSA_PAD_MODE_NONE)

“oaep” (OSSL_PKEY_RSA_PAD_MODE_OAEP)

“pkcs1” (OSSL_PKEY_RSA_PAD_MODE_PKCSV15)

“x931” (OSSL_PKEY_RSA_PAD_MODE_X931)

“pad-mode” (OSSL_ASYM_CIPHER_PARAM_PAD_MODE) <integer>

The default provider understands these RSA padding modes in integer form:

1 (RSA_PKCS1_PADDING)

3 (RSA_NO_PADDING)

4 (RSA_PKCS1_OAEP_PADDING)

5 (RSA_X931_PADDING)

See EVP_PKEY_CTX_set_rsa_padding (3) for further details.

“digest” (OSSL_ASYM_CIPHER_PARAM_OAEP_DIGEST) <UTF8 string>

“digest-props” (OSSL_ASYM_CIPHER_PARAM_OAEP_DIGEST_PROPS) <UTF8 string>

“mgf1-digest” (OSSL_ASYM_CIPHER_PARAM_MGF1_DIGEST) <UTF8 string>

“mgf1-digest-props” (OSSL_ASYM_CIPHER_PARAM_MGF1_DIGEST_PROPS) <UTF8 string>

“oaep-label” (OSSL_ASYM_CIPHER_PARAM_OAEP_LABEL) <octet string>

“tls-client-version” (OSSL_ASYM_CIPHER_PARAM_TLS_CLIENT_VERSION) <unsigned integer>

See RSA_PKCS1_WITH_TLS_PADDING on the page EVP_PKEY_CTX_set_rsa_padding (3).

“tls-negotiated-version” (OSSL_ASYM_CIPHER_PARAM_TLS_CLIENT_VERSION) <unsigned integer>
See RSA_PKCS1_WITH_TLS_PADDING on the page EVP_PKEY_CTX_set_rsa_padding (3). See “Asymmetric Cipher Parameters” in provider-asym_cipher (7) for more information.

SEE ALSO

EVP_PKEY-RSA (7), EVP_PKEY (3), provider-asym_cipher (7), provider-keymgmt (7), OSSL_PROVIDER-default (7) OSSL_PROVIDER-FIPS (7)

COPYRIGHT

Copyright 2022 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

369 - Linux cli command network_namespaces

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command network_namespaces and provides detailed information about the command network_namespaces, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the network_namespaces.

NAME 🖥️ network_namespaces 🖥️

overview of Linux network namespaces

DESCRIPTION

Network namespaces provide isolation of the system resources associated with networking: network devices, IPv4 and IPv6 protocol stacks, IP routing tables, firewall rules, the /proc/net directory (which is a symbolic link to /proc/pid/net), the /sys/class/net directory, various files under /proc/sys/net, port numbers (sockets), and so on. In addition, network namespaces isolate the UNIX domain abstract socket namespace (see unix(7)).

A physical network device can live in exactly one network namespace. When a network namespace is freed (i.e., when the last process in the namespace terminates), its physical network devices are moved back to the initial network namespace (not to the namespace of the parent of the process).

A virtual network (veth(4)) device pair provides a pipe-like abstraction that can be used to create tunnels between network namespaces, and can be used to create a bridge to a physical network device in another namespace. When a namespace is freed, the veth(4) devices that it contains are destroyed.

Use of network namespaces requires a kernel that is configured with the CONFIG_NET_NS option.

SEE ALSO

nsenter(1), unshare(1), clone(2), veth(4), proc(5), sysfs(5), namespaces(7), user_namespaces(7), brctl(8), ip(8), ip-address(8), ip-link(8), ip-netns(8), iptables(8), ovs-vsctl(8)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

370 - Linux cli command EVP_MAC-Poly1305ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_MAC-Poly1305ssl and provides detailed information about the command EVP_MAC-Poly1305ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_MAC-Poly1305ssl.

NAME 🖥️ EVP_MAC-Poly1305ssl 🖥️

Poly1305 - The Poly1305 EVP_MAC implementation

DESCRIPTION

Support for computing Poly1305 MACs through the EVP_MAC API.

Identity

This implementation is identified with this name and properties, to be used with EVP_MAC_fetch():

“POLY1305”, “provider=default”

Supported parameters

The general description of these parameters can be found in “PARAMETERS” in EVP_MAC (3).

The following parameter can be set with EVP_MAC_CTX_set_params():

“key” (OSSL_MAC_PARAM_KEY) <octet string>
Sets the MAC key. Setting this parameter is identical to passing a key to EVP_MAC_init (3).

The following parameters can be retrieved with EVP_MAC_CTX_get_params():

“size” (OSSL_MAC_PARAM_SIZE) <unsigned integer>
Gets the MAC size.

The “size” parameter can also be retrieved with with EVP_MAC_CTX_get_mac_size(). The length of the “size” parameter should not exceed that of an unsigned int.

NOTES

The OpenSSL implementation of the Poly 1305 MAC corresponds to RFC 7539.

It is critical to never reuse the key. The security implication noted in RFC 8439 applies equally to the OpenSSL implementation.

SEE ALSO

EVP_MAC_CTX_get_params (3), EVP_MAC_CTX_set_params (3), “PARAMETERS” in EVP_MAC (3), OSSL_PARAM (3)

COPYRIGHT

Copyright 2018-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

371 - Linux cli command DROP_PROCEDURE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_PROCEDURE and provides detailed information about the command DROP_PROCEDURE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_PROCEDURE.

NAME 🖥️ DROP_PROCEDURE 🖥️

remove a procedure

SYNOPSIS

DROP PROCEDURE [ IF EXISTS ] name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ] [, ...]
    [ CASCADE | RESTRICT ]

DESCRIPTION

DROP PROCEDURE removes the definition of one or more existing procedures. To execute this command the user must be the owner of the procedure(s). The argument types to the procedure(s) usually must be specified, since several different procedures can exist with the same name and different argument lists.

PARAMETERS

IF EXISTS

Do not throw an error if the procedure does not exist. A notice is issued in this case.

name

The name (optionally schema-qualified) of an existing procedure.

argmode

The mode of an argument: IN, OUT, INOUT, or VARIADIC. If omitted, the default is IN (but see below).

argname

The name of an argument. Note that DROP PROCEDURE does not actually pay any attention to argument names, since only the argument data types are used to determine the procedures identity.

argtype

The data type(s) of the procedures arguments (optionally schema-qualified), if any. See below for details.

CASCADE

Automatically drop objects that depend on the procedure, and in turn all objects that depend on those objects (see Section 5.14).

RESTRICT

Refuse to drop the procedure if any objects depend on it. This is the default.

NOTES

If there is only one procedure of the given name, the argument list can be omitted. Omit the parentheses too in this case.

In PostgreSQL, its sufficient to list the input (including INOUT) arguments, because no two routines of the same name are allowed to share the same input-argument list. Moreover, the DROP command will not actually check that you wrote the types of OUT arguments correctly; so any arguments that are explicitly marked OUT are just noise. But writing them is recommendable for consistency with the corresponding CREATE command.

For compatibility with the SQL standard, it is also allowed to write all the argument data types (including those of OUT arguments) without any argmode markers. When this is done, the types of the procedures OUT argument(s) will be verified against the command. This provision creates an ambiguity, in that when the argument list contains no argmode markers, its unclear which rule is intended. The DROP command will attempt the lookup both ways, and will throw an error if two different procedures are found. To avoid the risk of such ambiguity, its recommendable to write IN markers explicitly rather than letting them be defaulted, thus forcing the traditional PostgreSQL interpretation to be used.

The lookup rules just explained are also used by other commands that act on existing procedures, such as ALTER PROCEDURE and COMMENT ON PROCEDURE.

EXAMPLES

If there is only one procedure do_db_maintenance, this command is sufficient to drop it:

DROP PROCEDURE do_db_maintenance;

Given this procedure definition:

CREATE PROCEDURE do_db_maintenance(IN target_schema text, OUT results text) …

any one of these commands would work to drop it:

DROP PROCEDURE do_db_maintenance(IN target_schema text, OUT results text); DROP PROCEDURE do_db_maintenance(IN text, OUT text); DROP PROCEDURE do_db_maintenance(IN text); DROP PROCEDURE do_db_maintenance(text); DROP PROCEDURE do_db_maintenance(text, text); – potentially ambiguous

However, the last example would be ambiguous if there is also, say,

CREATE PROCEDURE do_db_maintenance(IN target_schema text, IN options text) …

COMPATIBILITY

This command conforms to the SQL standard, with these PostgreSQL extensions:

·

The standard only allows one procedure to be dropped per command.

·

The IF EXISTS option is an extension.

·

The ability to specify argument modes and names is an extension, and the lookup rules differ when modes are given.

SEE ALSO

CREATE PROCEDURE (CREATE_PROCEDURE(7)), ALTER PROCEDURE (ALTER_PROCEDURE(7)), DROP FUNCTION (DROP_FUNCTION(7)), DROP ROUTINE (DROP_ROUTINE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

372 - Linux cli command mqtt

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command mqtt and provides detailed information about the command mqtt, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the mqtt.

NAME 🖥️ mqtt 🖥️

MQ Telemetry Transport

SYNOPSIS

MQTT

DESCRIPTION

MQTT is a lightweight publish/subscribe messaging protocol. It is useful for use with low power sensors, but is applicable to many scenarios.

This manual describes some of the features of MQTT version 3.1.1/3.1, to assist end users in getting the most out of the protocol. For more complete information on MQTT, see http://mqtt.org/.

PUBLISH/SUBSCRIBE

The MQTT protocol is based on the principle of publishing messages and subscribing to topics, or “pub/sub”. Multiple clients connect to a broker and subscribe to topics that they are interested in. Clients also connect to the broker and publish messages to topics. Many clients may subscribe to the same topics and do with the information as they please. The broker and MQTT act as a simple, common interface for everything to connect to. This means that you if you have clients that dump subscribed messages to a database, to Twitter, Cosm or even a simple text file, then it becomes very simple to add new sensors or other data input to a database, Twitter or so on.

TOPICS/SUBSCRIPTIONS

Messages in MQTT are published on topics. There is no need to configure a topic, publishing on it is enough. Topics are treated as a hierarchy, using a slash (/) as a separator. This allows sensible arrangement of common themes to be created, much in the same way as a filesystem. For example, multiple computers may all publish their hard drive temperature information on the following topic, with their own computer and hard drive name being replaced as appropriate:

·

sensors/COMPUTER_NAME/temperature/HARDDRIVE_NAME

Clients can receive messages by creating subscriptions. A subscription may be to an explicit topic, in which case only messages to that topic will be received, or it may include wildcards. Two wildcards are available, + or #.

+ can be used as a wildcard for a single level of hierarchy. It could be used with the topic above to get information on all computers and hard drives as follows:

·

sensors/+/temperature/+

As another example, for a topic of “a/b/c/d”, the following example subscriptions will match:

·

a/b/c/d

·

+/b/c/d

·

a/+/c/d

·

a/+/+/d

·

+/+/+/+

The following subscriptions will not match:

·

a/b/c

·

b/+/c/d

·

+/+/+

# can be used as a wildcard for all remaining levels of hierarchy. This means that it must be the final character in a subscription. With a topic of “a/b/c/d”, the following example subscriptions will match:

·

a/b/c/d

·

#

·

a/#

·

a/b/#

·

a/b/c/#

·

+/b/c/#

Zero length topic levels are valid, which can lead to some slightly non-obvious behaviour. For example, a topic of “a//topic” would correctly match against a subscription of “a/+/topic”. Likewise, zero length topic levels can exist at both the beginning and the end of a topic string, so “/a/topic” would match against a subscription of “+/a/topic”, “#” or “/#”, and a topic “a/topic/” would match against a subscription of “a/topic/+” or “a/topic/#”.

QUALITY OF SERVICE

MQTT defines three levels of Quality of Service (QoS). The QoS defines how hard the broker/client will try to ensure that a message is received. Messages may be sent at any QoS level, and clients may attempt to subscribe to topics at any QoS level. This means that the client chooses the maximum QoS it will receive. For example, if a message is published at QoS 2 and a client is subscribed with QoS 0, the message will be delivered to that client with QoS 0. If a second client is also subscribed to the same topic, but with QoS 2, then it will receive the same message but with QoS 2. For a second example, if a client is subscribed with QoS 2 and a message is published on QoS 0, the client will receive it on QoS 0.

Higher levels of QoS are more reliable, but involve higher latency and have higher bandwidth requirements.

·

0: The broker/client will deliver the message once, with no confirmation.

·

1: The broker/client will deliver the message at least once, with confirmation required.

·

2: The broker/client will deliver the message exactly once by using a four step handshake.

RETAINED MESSAGES

All messages may be set to be retained. This means that the broker will keep the message even after sending it to all current subscribers. If a new subscription is made that matches the topic of the retained message, then the message will be sent to the client. This is useful as a “last known good” mechanism. If a topic is only updated infrequently, then without a retained message, a newly subscribed client may have to wait a long time to receive an update. With a retained message, the client will receive an instant update.

CLEAN SESSION / DURABLE CONNECTIONS

On connection, a client sets the “clean session” flag, which is sometimes also known as the “clean start” flag. If clean session is set to false, then the connection is treated as durable. This means that when the client disconnects, any subscriptions it has will remain and any subsequent QoS 1 or 2 messages will be stored until it connects again in the future. If clean session is true, then all subscriptions will be removed for the client when it disconnects.

WILLS

When a client connects to a broker, it may inform the broker that it has a will. This is a message that it wishes the broker to send when the client disconnects unexpectedly. The will message has a topic, QoS and retain status just the same as any other message.

SEE ALSO

mosquitto(8), mosquitto_pub(1), mosquitto_sub(1)

AUTHOR

Roger Light <[email protected]>

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

373 - Linux cli command CREATE_TEXT_SEARCH_CONFIGURATION

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_TEXT_SEARCH_CONFIGURATION and provides detailed information about the command CREATE_TEXT_SEARCH_CONFIGURATION, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_TEXT_SEARCH_CONFIGURATION.

NAME 🖥️ CREATE_TEXT_SEARCH_CONFIGURATION 🖥️

define a new text search configuration

SYNOPSIS

CREATE TEXT SEARCH CONFIGURATION name (
    PARSER = parser_name |
    COPY = source_config
)

DESCRIPTION

CREATE TEXT SEARCH CONFIGURATION creates a new text search configuration. A text search configuration specifies a text search parser that can divide a string into tokens, plus dictionaries that can be used to determine which tokens are of interest for searching.

If only the parser is specified, then the new text search configuration initially has no mappings from token types to dictionaries, and therefore will ignore all words. Subsequent ALTER TEXT SEARCH CONFIGURATION commands must be used to create mappings to make the configuration useful. Alternatively, an existing text search configuration can be copied.

If a schema name is given then the text search configuration is created in the specified schema. Otherwise it is created in the current schema.

The user who defines a text search configuration becomes its owner.

Refer to Chapter 12 for further information.

PARAMETERS

name

The name of the text search configuration to be created. The name can be schema-qualified.

parser_name

The name of the text search parser to use for this configuration.

source_config

The name of an existing text search configuration to copy.

NOTES

The PARSER and COPY options are mutually exclusive, because when an existing configuration is copied, its parser selection is copied too.

COMPATIBILITY

There is no CREATE TEXT SEARCH CONFIGURATION statement in the SQL standard.

SEE ALSO

ALTER TEXT SEARCH CONFIGURATION (ALTER_TEXT_SEARCH_CONFIGURATION(7)), DROP TEXT SEARCH CONFIGURATION (DROP_TEXT_SEARCH_CONFIGURATION(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

374 - Linux cli command keyutils

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command keyutils and provides detailed information about the command keyutils, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the keyutils.

NAME 🖥️ keyutils 🖥️

in-kernel key management utilities

DESCRIPTION

The keyutils package is a library and a set of utilities for accessing the kernel keyrings facility.

A header file is supplied to provide the definitions and declarations required to access the library:

#include <keyutils.h>

To link with the library, the following:

-lkeyutils

should be specified to the linker.

Three system calls are provided:

add_key(2)
Supply a new key to the kernel.

request_key(2)
Find an existing key for use, or, optionally, create one if one does not exist.

keyctl(2)
Control a key in various ways. The library provides a variety of wrappers around this system call and those should be used rather than calling it directly.

See the add_key(2), request_key(2), and keyctl(2) manual pages for more information.

The keyctl() wrappers are listed on the keyctl(3) manual page.

UTILITIES

A program is provided to interact with the kernel facility by a number of subcommands, e.g.:

keyctl add user foo bar @s

See the keyctl(1) manual page for information on that.

The kernel has the ability to upcall to userspace to fabricate new keys. This can be triggered by request_key(), but userspace is better off using add_key() instead if it possibly can.

The upcalling mechanism is usually routed via the request-key(8) program. What this does with any particular key is configurable in:

/etc/request-key.conf
/etc/request-key.d/

See the request-key.conf(5) and the request-key(8) manual pages for more information.

SEE ALSO

keyctl(1), keyctl(3), keyrings(7), persistent-keyring(7), process-keyring(7), session-keyring(7), thread-keyring(7), user-keyring(7), user-session-keyring(7), pam_keyinit(8)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

375 - Linux cli command ossl-guide-tls-introductionssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ossl-guide-tls-introductionssl and provides detailed information about the command ossl-guide-tls-introductionssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ossl-guide-tls-introductionssl.

NAME 🖥️ ossl-guide-tls-introductionssl 🖥️

guide-tls-introduction - OpenSSL Guide: An introduction to SSL/TLS in OpenSSL

INTRODUCTION

This page will provide an introduction to some basic SSL/TLS concepts and background and how it is used within OpenSSL. It assumes that you have a basic understanding of TCP/IP and sockets.

WHAT IS TLS?

TLS stands for Transport Layer Security. TLS allows applications to securely communicate with each other across a network such that the confidentiality of the information exchanged is protected (i.e. it prevents eavesdroppers from listening in to the communication). Additionally it protects the integrity of the information exchanged to prevent an attacker from changing it. Finally it provides authentication so that one or both parties can be sure that they are talking to who they think they are talking to and not some imposter.

Sometimes TLS is referred to by its predecessor’s name SSL (Secure Sockets Layer). OpenSSL dates from a time when the SSL name was still in common use and hence many of the functions and names used by OpenSSL contain the “SSL” abbreviation. Nonetheless OpenSSL contains a fully fledged TLS implementation.

TLS is based on a client/server model. The application that initiates a communication is known as the client. The application that responds to a remotely initiated communication is the server. The term “endpoint” refers to either of the client or the server in a communication. The term “peer” refers to the endpoint at the other side of the communication that we are currently referring to. So if we are currently talking about the client then the peer would be the server.

TLS is a standardised protocol and there are numerous different implementations of it. Due to the standards an OpenSSL client or server is able to communicate seamlessly with an application using some different implementation of TLS. TLS (and its predecessor SSL) have been around for a significant period of time and the protocol has undergone various changes over the years. Consequently there are different versions of the protocol available. TLS includes the ability to perform version negotiation so that the highest protocol version that the client and server share in common is used.

TLS acts as a security layer over some lower level transport protocol. Typically the transport layer will be TCP.

SSL AND TLS VERSIONS

SSL was initially developed by Netscape Communications and its first publicly released version was SSLv2 in 1995. Note that SSLv1 was never publicly released. SSLv3 came along quickly afterwards in 1996. Subsequently development of the protocol moved to the IETF which released the first version of TLS (TLSv1.0) in 1999 as RFC2246. TLSv1.1 was released in 2006 as RFC4346 and TLSv1.2 came along in 2008 as RFC5246. The most recent version of the standard is TLSv1.3 which was released in 2018 as RFC8446.

Today TLSv1.3 and TLSv1.2 are the most commonly deployed versions of the protocol. The IETF have formally deprecated TLSv1.1 and TLSv1.0, so anything below TLSv1.2 should be avoided since the older protocol versions are susceptible to security problems.

OpenSSL does not support SSLv2 (it was removed in OpenSSL 1.1.0). Support for SSLv3 is available as a compile time option - but it is not built by default. Support for TLSv1.0, TLSv1.1, TLSv1.2 and TLSv1.3 are all available by default in a standard build of OpenSSL. However special run-time configuration is required in order to make TLSv1.0 and TLSv1.1 work successfully.

OpenSSL will always try to negotiate the highest protocol version that it has been configured to support. In most cases this will mean either TLSv1.3 or TLSv1.2 is chosen.

CERTIFICATES

In order for a client to establish a connection to a server it must authenticate the identify of that server, i.e. it needs to confirm that the server is really the server that it claims to be and not some imposter. In order to do this the server will send to the client a digital certificate (also commonly referred to as an X.509 certificate). The certificate contains various information about the server including its full DNS hostname. Also within the certificate is the server’s public key. The server operator will have a private key which is linked to the public key and must not be published.

Along with the certificate the server will also send to the client proof that it knows the private key associated with the public key in the certificate. It does this by digitally signing a message to the client using that private key. The client can verify the signature using the public key from the certificate. If the signature verifies successfully then the client knows that the server is in possession of the correct private key.

The certificate that the server sends will also be signed by a Certificate Authority. The Certificate Authority (commonly known as a CA) is a third party organisation that is responsible for verifying the information in the server’s certificate (including its DNS hostname). The CA should only sign the certificate if it has been able to confirm that the server operator does indeed have control of the server associated with its DNS hostname and that the server operator has control of the private key.

In this way, if the client trusts the CA that has signed the server’s certificate and it can verify that the server has the right private key then it can trust that the server truly does represent the DNS hostname given in the certificate. The client must also verify that the hostname given in the certificate matches the hostname that it originally sent the request to.

Once all of these checks have been done the client has successfully verified the identify of the server. OpenSSL can perform all of these checks automatically but it must be provided with certain information in order to do so, i.e. the set of CAs that the client trusts as well as the DNS hostname for the server that this client is trying to connect to.

Note that it is common for certificates to be built up into a chain. For example a server’s certificate may be signed by a key owned by a an intermediate CA. That intermediate CA also has a certificate containing its public key which is in turn signed by a key owned by a root CA. The client may only trust the root CA, but if the server sends both its own certificate and the certificate for the intermediate CA then the client can still successfully verify the identity of the server. There is a chain of trust between the root CA and the server.

By default it is only the client that authenticates the server using this method. However it is also possible to set things up such that the server additionally authenticates the client. This is known as “client authentication”. In this approach the client will still authenticate the server in the same way, but the server will request a certificate from the client. The client sends the server its certificate and the server authenticates it in the same way that the client does.

TRUSTED CERTIFICATE STORE

The system described above only works if a chain of trust can be built between the set of CAs that the endpoint trusts and the certificate that the peer is using. The endpoint must therefore have a set of certificates for CAs that it trusts before any communication can take place. OpenSSL itself does not provide such a set of certificates. Therefore you will need to make sure you have them before you start if you are going to be verifying certificates (i.e. always if the endpoint is a client, and only if client authentication is in use for a server).

Fortunately other organisations do maintain such a set of certificates. If you have obtained your copy of OpenSSL from an Operating System (OS) vendor (e.g. a Linux distribution) then normally the set of CA certificates will also be distributed with that copy.

You can check this by running the OpenSSL command line application like this:

openssl version -d

This will display a value for OPENSSLDIR. Look in the certs sub directory of OPENSSLDIR and check its contents. For example if OPENSSLDIR is “/usr/local/ssl”, then check the contents of the “/usr/local/ssl/certs” directory.

You are expecting to see a list of files, typically with the suffix “.pem” or “.0”. If they exist then you already have a suitable trusted certificate store.

If you are running your version of OpenSSL on Windows then OpenSSL (from version 3.2 onwards) will use the default Windows set of trusted CAs.

If you have built your version of OpenSSL from source, or obtained it from some other location and it does not have a set of trusted CA certificates then you will have to obtain them yourself. One such source is the Curl project. See the page <https://curl.se/docs/caextract.html> where you can download trusted certificates in a single file. Rename the file to “cert.pem” and store it directly in OPENSSLDIR. For example if OPENSSLDIR is “/usr/local/ssl”, then save it as “/usr/local/ssl/cert.pem”.

You can also use environment variables to override the default location that OpenSSL will look for its trusted certificate store. Set the SSL_CERT_PATH environment variable to give the directory where OpenSSL should looks for its certificates or the SSL_CERT_FILE environment variable to give the name of a single file containing all of the certificates. See openssl-env (7) for further details about OpenSSL environment variables. For example you could use this capability to have multiple versions of OpenSSL all installed on the same system using different values for OPENSSLDIR but all using the same trusted certificate store.

You can test that your trusted certificate store is setup correctly by using it via the OpenSSL command line. Use the following command to connect to a TLS server:

openssl s_client www.openssl.org:443

Once the command has connected type the letter “Q” followed by “<enter>” to exit the session. This will print a lot of information on the screen about the connection. Look for a block of text like this:

SSL handshake has read 4584 bytes and written 403 bytes Verification: OK

Hopefully if everything has worked then the “Verification” line will say “OK”. If its not working as expected then you might see output like this instead:

SSL handshake has read 4584 bytes and written 403 bytes Verification error: unable to get local issuer certificate

The “unable to get local issuer certificate” error means that OpenSSL has been unable to find a trusted CA for the chain of certificates provided by the server in its trusted certificate store. Check your trusted certificate store configuration again.

Note that s_client is a testing tool and will still allow you to connect to the TLS server regardless of the verification error. Most applications should not do this and should abort the connection in the event of a verification error.

IMPORTANT OBJECTS FOR AN OPENSSL TLS APPLICATION

A TLS connection is represented by the SSL object in an OpenSSL based application. Once a connection with a remote peer has been established an endpoint can “write” data to the SSL object to send data to the peer, or “read” data from it to receive data from the server.

A new SSL object is created from an SSL_CTX object. Think of an SSL_CTX as a “factory” for creating SSL objects. You can create a single SSL_CTX object and then create multiple connections (i.e. SSL objects) from it. Typically you can set up common configuration options on the SSL_CTX so that all the SSL object created from it inherit the same configuration options.

Note that internally to OpenSSL various items that are shared between multiple SSL objects are cached in the SSL_CTX for performance reasons. Therefore it is considered best practice to create one SSL_CTX for use by multiple SSL objects instead of having one SSL_CTX for each SSL object that you create.

Each SSL object is also associated with two BIO objects. A BIO object is used for sending or receiving data from the underlying transport layer. For example you might create a BIO to represent a TCP socket. The SSL object uses one BIO for reading data and one BIO for writing data. In most cases you would use the same BIO for each direction but there could be some circumstances where you want them to be different.

It is up to the application programmer to create the BIO objects that are needed and supply them to the SSL object. See ossl-guide-tls-client-block (7) for further information.

Finally, an endpoint can establish a “session” with its peer. The session holds various TLS parameters about the connection between the client and the server. The session details can then be reused in a subsequent connection attempt to speed up the process of connecting. This is known as “resumption”. Sessions are represented in OpenSSL by the SSL_SESSION object. In TLSv1.2 there is always exactly one session per connection. In TLSv1.3 there can be any number per connection including none.

PHASES OF A TLS CONNECTION

A TLS connection starts with an initial “set up” phase. The endpoint creates the SSL_CTX (if one has not already been created) and configures it.

A client then creates an SSL object to represent the new TLS connection. Any connection specific configuration parameters are then applied and the underlying socket is created and associated with the SSL via BIO objects.

A server will create a socket for listening for incoming connection attempts from clients. Once a connection attempt is made the server will create an SSL object in the same way as for a client and associate it with a BIO for the newly created incoming socket.

After set up is complete the TLS “handshake” phase begins. A TLS handshake consists of the client and server exchanging a series of TLS handshake messages to establish the connection. The client starts by sending a “ClientHello” handshake message and the server responds with a “ServerHello”. The handshake is complete once an endpoint has sent its last message (known as the “Finished” message) and received a Finished message from its peer. Note that this might occur at slightly different times for each peer. For example in TLSv1.3 the server always sends its Finished message before the client. The client later responds with its Finished message. At this point the client has completed the handshake because it has both sent and received a Finished message. The server has sent its Finished message but the Finished message from the client may still be in-flight, so the server is still in the handshake phase. It is even possible that the server will fail to complete the handshake (if it considers there is some problem with the messages sent from the client), even though the client may have already progressed to sending application data. In TLSv1.2 this can happen the other way around, i.e. the server finishes first and the client finishes second.

Once the handshake is complete the application data transfer phase begins. Strictly speaking there are some situations where the client can start sending application data even earlier (using the TLSv1.3 “early data” capability) - but we’re going to skip over that for this basic introduction.

During application data transfer the client and server can read and write data to the connection freely. The details of this are typically left to some higher level application protocol (for example HTTP). Not all information exchanged during this phase is application data. Some protocol level messages may still be exchanged - so it is not necessarily the case that, just because the underlying socket is “readable”, that application data will be available to read.

When the connection is no longer required then it should be shutdown. A shutdown may be initiated by either the client or the server via a message known as a “close_notify” alert. The client or server that receives a close_notify may respond with one and then the connection is fully closed and application data can no longer be sent or received.

Once shutdown is complete a TLS application must clean up by freeing the SSL object.

FURTHER READING

See ossl-guide-tls-client-block (7) to see an example of applying these concepts in order to write a simple TLS client based on a blocking socket. See ossl-guide-quic-introduction (7) for an introduction to QUIC in OpenSSL.

SEE ALSO

ossl-guide-introduction (7), ossl-guide-libraries-introduction (7), ossl-guide-libssl-introduction (7), ossl-guide-tls-client-block (7), ossl-guide-quic-introduction (7)

COPYRIGHT

Copyright 2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

376 - Linux cli command ALTER_INDEX

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_INDEX and provides detailed information about the command ALTER_INDEX, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_INDEX.

NAME 🖥️ ALTER_INDEX 🖥️

change the definition of an index

SYNOPSIS

ALTER INDEX [ IF EXISTS ] name RENAME TO new_name
ALTER INDEX [ IF EXISTS ] name SET TABLESPACE tablespace_name
ALTER INDEX name ATTACH PARTITION index_name
ALTER INDEX name [ NO ] DEPENDS ON EXTENSION extension_name
ALTER INDEX [ IF EXISTS ] name SET ( storage_parameter [= value] [, ... ] )
ALTER INDEX [ IF EXISTS ] name RESET ( storage_parameter [, ... ] )
ALTER INDEX [ IF EXISTS ] name ALTER [ COLUMN ] column_number
    SET STATISTICS integer
ALTER INDEX ALL IN TABLESPACE name [ OWNED BY role_name [, ... ] ]
    SET TABLESPACE new_tablespace [ NOWAIT ]

DESCRIPTION

ALTER INDEX changes the definition of an existing index. There are several subforms described below. Note that the lock level required may differ for each subform. An ACCESS EXCLUSIVE lock is held unless explicitly noted. When multiple subcommands are listed, the lock held will be the strictest one required from any subcommand.

RENAME

The RENAME form changes the name of the index. If the index is associated with a table constraint (either UNIQUE, PRIMARY KEY, or EXCLUDE), the constraint is renamed as well. There is no effect on the stored data.

Renaming an index acquires a SHARE UPDATE EXCLUSIVE lock.

SET TABLESPACE

This form changes the indexs tablespace to the specified tablespace and moves the data file(s) associated with the index to the new tablespace. To change the tablespace of an index, you must own the index and have CREATE privilege on the new tablespace. All indexes in the current database in a tablespace can be moved by using the ALL IN TABLESPACE form, which will lock all indexes to be moved and then move each one. This form also supports OWNED BY, which will only move indexes owned by the roles specified. If the NOWAIT option is specified then the command will fail if it is unable to acquire all of the locks required immediately. Note that system catalogs will not be moved by this command, use ALTER DATABASE or explicit ALTER INDEX invocations instead if desired. See also CREATE TABLESPACE.

ATTACH PARTITION

Causes the named index to become attached to the altered index. The named index must be on a partition of the table containing the index being altered, and have an equivalent definition. An attached index cannot be dropped by itself, and will automatically be dropped if its parent index is dropped.

DEPENDS ON EXTENSION extension_name
NO DEPENDS ON EXTENSION extension_name

This form marks the index as dependent on the extension, or no longer dependent on that extension if NO is specified. An index thats marked as dependent on an extension is automatically dropped when the extension is dropped.

SET ( storage_parameter [= value] [, … ] )

This form changes one or more index-method-specific storage parameters for the index. See CREATE INDEX for details on the available parameters. Note that the index contents will not be modified immediately by this command; depending on the parameter you might need to rebuild the index with REINDEX to get the desired effects.

RESET ( storage_parameter [, … ] )

This form resets one or more index-method-specific storage parameters to their defaults. As with SET, a REINDEX might be needed to update the index entirely.

ALTER [ COLUMN ] column_number SET STATISTICS integer

This form sets the per-column statistics-gathering target for subsequent ANALYZE operations, though can be used only on index columns that are defined as an expression. Since expressions lack a unique name, we refer to them using the ordinal number of the index column. The target can be set in the range 0 to 10000; alternatively, set it to -1 to revert to using the system default statistics target (default_statistics_target). For more information on the use of statistics by the PostgreSQL query planner, refer to Section 14.2.

PARAMETERS

IF EXISTS

Do not throw an error if the index does not exist. A notice is issued in this case.

column_number

The ordinal number refers to the ordinal (left-to-right) position of the index column.

name

The name (possibly schema-qualified) of an existing index to alter.

new_name

The new name for the index.

tablespace_name

The tablespace to which the index will be moved.

extension_name

The name of the extension that the index is to depend on.

storage_parameter

The name of an index-method-specific storage parameter.

value

The new value for an index-method-specific storage parameter. This might be a number or a word depending on the parameter.

NOTES

These operations are also possible using ALTER TABLE. ALTER INDEX is in fact just an alias for the forms of ALTER TABLE that apply to indexes.

There was formerly an ALTER INDEX OWNER variant, but this is now ignored (with a warning). An index cannot have an owner different from its tables owner. Changing the tables owner automatically changes the index as well.

Changing any part of a system catalog index is not permitted.

EXAMPLES

To rename an existing index:

ALTER INDEX distributors RENAME TO suppliers;

To move an index to a different tablespace:

ALTER INDEX distributors SET TABLESPACE fasttablespace;

To change an indexs fill factor (assuming that the index method supports it):

ALTER INDEX distributors SET (fillfactor = 75); REINDEX INDEX distributors;

Set the statistics-gathering target for an expression index:

CREATE INDEX coord_idx ON measured (x, y, (z + t)); ALTER INDEX coord_idx ALTER COLUMN 3 SET STATISTICS 1000;

COMPATIBILITY

ALTER INDEX is a PostgreSQL extension.

SEE ALSO

CREATE INDEX (CREATE_INDEX(7)), REINDEX(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

377 - Linux cli command locale

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command locale and provides detailed information about the command locale, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the locale.

NAME 🖥️ locale 🖥️

description of multilanguage support

SYNOPSIS

#include <locale.h>

DESCRIPTION

A locale is a set of language and cultural rules. These cover aspects such as language for messages, different character sets, lexicographic conventions, and so on. A program needs to be able to determine its locale and act accordingly to be portable to different cultures.

The header <locale.h> declares data types, functions, and macros which are useful in this task.

The functions it declares are setlocale(3) to set the current locale, and localeconv(3) to get information about number formatting.

There are different categories for locale information a program might need; they are declared as macros. Using them as the first argument to the setlocale(3) function, it is possible to set one of these to the desired locale:

LC_ADDRESS (GNU extension, since glibc 2.2)
Change settings that describe the formats (e.g., postal addresses) used to describe locations and geography-related items. Applications that need this information can use nl_langinfo(3) to retrieve nonstandard elements, such as _NL_ADDRESS_COUNTRY_NAME (country name, in the language of the locale) and _NL_ADDRESS_LANG_NAME (language name, in the language of the locale), which return strings such as “Deutschland” and “Deutsch” (for German-language locales). (Other element names are listed in <langinfo.h>.)

LC_COLLATE
This category governs the collation rules used for sorting and regular expressions, including character equivalence classes and multicharacter collating elements. This locale category changes the behavior of the functions strcoll(3) and strxfrm(3), which are used to compare strings in the local alphabet. For example, the German sharp s is sorted as “ss”.

LC_CTYPE
This category determines the interpretation of byte sequences as characters (e.g., single versus multibyte characters), character classifications (e.g., alphabetic or digit), and the behavior of character classes. On glibc systems, this category also determines the character transliteration rules for iconv(1) and iconv(3). It changes the behavior of the character handling and classification functions, such as isupper(3) and toupper(3), and the multibyte character functions such as mblen(3) or wctomb(3).

LC_IDENTIFICATION (GNU extension, since glibc 2.2)
Change settings that relate to the metadata for the locale. Applications that need this information can use nl_langinfo(3) to retrieve nonstandard elements, such as _NL_IDENTIFICATION_TITLE (title of this locale document) and _NL_IDENTIFICATION_TERRITORY (geographical territory to which this locale document applies), which might return strings such as “English locale for the USA” and “USA”. (Other element names are listed in <langinfo.h>.)

LC_MONETARY
This category determines the formatting used for monetary-related numeric values. This changes the information returned by localeconv(3), which describes the way numbers are usually printed, with details such as decimal point versus decimal comma. This information is internally used by the function strfmon(3).

LC_MESSAGES
This category affects the language in which messages are displayed and what an affirmative or negative answer looks like. The GNU C library contains the gettext(3), ngettext(3), and rpmatch(3) functions to ease the use of this information. The GNU gettext family of functions also obey the environment variable LANGUAGE (containing a colon-separated list of locales) if the category is set to a valid locale other than “C”. This category also affects the behavior of catopen(3).

LC_MEASUREMENT (GNU extension, since glibc 2.2)
Change the settings relating to the measurement system in the locale (i.e., metric versus US customary units). Applications can use nl_langinfo(3) to retrieve the nonstandard _NL_MEASUREMENT_MEASUREMENT element, which returns a pointer to a character that has the value 1 (metric) or 2 (US customary units).

LC_NAME (GNU extension, since glibc 2.2)
Change settings that describe the formats used to address persons. Applications that need this information can use nl_langinfo(3) to retrieve nonstandard elements, such as _NL_NAME_NAME_MR (general salutation for men) and _NL_NAME_NAME_MS (general salutation for women) elements, which return strings such as “Herr” and “Frau” (for German-language locales). (Other element names are listed in <langinfo.h>.)

LC_NUMERIC
This category determines the formatting rules used for nonmonetary numeric values—for example, the thousands separator and the radix character (a period in most English-speaking countries, but a comma in many other regions). It affects functions such as printf(3), scanf(3), and strtod(3). This information can also be read with the localeconv(3) function.

LC_PAPER (GNU extension, since glibc 2.2)
Change the settings relating to the dimensions of the standard paper size (e.g., US letter versus A4). Applications that need the dimensions can obtain them by using nl_langinfo(3) to retrieve the nonstandard _NL_PAPER_WIDTH and _NL_PAPER_HEIGHT elements, which return int values specifying the dimensions in millimeters.

LC_TELEPHONE (GNU extension, since glibc 2.2)
Change settings that describe the formats to be used with telephone services. Applications that need this information can use nl_langinfo(3) to retrieve nonstandard elements, such as _NL_TELEPHONE_INT_PREFIX (international prefix used to call numbers in this locale), which returns a string such as “49” (for Germany). (Other element names are listed in <langinfo.h>.)

LC_TIME
This category governs the formatting used for date and time values. For example, most of Europe uses a 24-hour clock versus the 12-hour clock used in the United States. The setting of this category affects the behavior of functions such as strftime(3) and strptime(3).

LC_ALL
All of the above.

If the second argument to setlocale(3) is an empty string, "", for the default locale, it is determined using the following steps:

  1. If there is a non-null environment variable LC_ALL, the value of LC_ALL is used.

  2. If an environment variable with the same name as one of the categories above exists and is non-null, its value is used for that category.

  3. If there is a non-null environment variable LANG, the value of LANG is used.

Values about local numeric formatting is made available in a struct lconv returned by the localeconv(3) function, which has the following declaration:

struct lconv {
    /* Numeric (nonmonetary) information */
    char *decimal_point;     /* Radix character */
    char *thousands_sep;     /* Separator for digit groups to left
                                of radix character */
    char *grouping;     /* Each element is the number of digits in
                           a group; elements with higher indices
                           are further left.  An element with value
                           CHAR_MAX means that no further grouping
                           is done.  An element with value 0 means
                           that the previous element is used for
                           all groups further left. */
    /* Remaining fields are for monetary information */
    char *int_curr_symbol;   /* First three chars are a currency
                                symbol from ISO 4217.  Fourth char
                                is the separator.  Fifth char
                                is ''. */
    char *currency_symbol;   /* Local currency symbol */
    char *mon_decimal_point; /* Radix character */
    char *mon_thousands_sep; /* Like thousands_sep above */
    char *mon_grouping;      /* Like grouping above */
    char *positive_sign;     /* Sign for positive values */
    char *negative_sign;     /* Sign for negative values */
    char  int_frac_digits;   /* International fractional digits */
    char  frac_digits;       /* Local fractional digits */
    char  p_cs_precedes;     /* 1 if currency_symbol precedes a
                                positive value, 0 if succeeds */
    char  p_sep_by_space;    /* 1 if a space separates
                                currency_symbol from a positive
                                value */
    char  n_cs_precedes;     /* 1 if currency_symbol precedes a
                                negative value, 0 if succeeds */
    char  n_sep_by_space;    /* 1 if a space separates
                                currency_symbol from a negative
                                value */
    /* Positive and negative sign positions:
       0 Parentheses surround the quantity and currency_symbol.
       1 The sign string precedes the quantity and currency_symbol.
       2 The sign string succeeds the quantity and currency_symbol.
       3 The sign string immediately precedes the currency_symbol.
       4 The sign string immediately succeeds the currency_symbol. */
    char  p_sign_posn;
    char  n_sign_posn;
};

POSIX.1-2008 extensions to the locale API

POSIX.1-2008 standardized a number of extensions to the locale API, based on implementations that first appeared in glibc 2.3. These extensions are designed to address the problem that the traditional locale APIs do not mix well with multithreaded applications and with applications that must deal with multiple locales.

The extensions take the form of new functions for creating and manipulating locale objects (newlocale(3), freelocale(3), duplocale(3), and uselocale(3)) and various new library functions with the suffix “_l” (e.g., toupper_l(3)) that extend the traditional locale-dependent APIs (e.g., toupper(3)) to allow the specification of a locale object that should apply when executing the function.

ENVIRONMENT

The following environment variable is used by newlocale(3) and setlocale(3), and thus affects all unprivileged localized programs:

LOCPATH
A list of pathnames, separated by colons (’:’), that should be used to find locale data. If this variable is set, only the individual compiled locale data files from LOCPATH and the system default locale data path are used; any available locale archives are not used (see localedef(1)). The individual compiled locale data files are searched for under subdirectories which depend on the currently used locale. For example, when en_GB.UTF-8 is used for a category, the following subdirectories are searched for, in this order: en_GB.UTF-8, en_GB.utf8, en_GB, en.UTF-8, en.utf8, and en.

FILES

/usr/lib/locale/locale-archive
Usual default locale archive location.

/usr/lib/locale
Usual default path for compiled individual locale files.

STANDARDS

POSIX.1-2001.

SEE ALSO

iconv(1), locale(1), localedef(1), catopen(3), gettext(3), iconv(3), localeconv(3), mbstowcs(3), newlocale(3), ngettext(3), nl_langinfo(3), rpmatch(3), setlocale(3), strcoll(3), strfmon(3), strftime(3), strxfrm(3), uselocale(3), wcstombs(3), locale(5), charsets(7), unicode(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

378 - Linux cli command initramfs-tools

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command initramfs-tools and provides detailed information about the command initramfs-tools, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the initramfs-tools.

NAME 🖥️ initramfs-tools 🖥️

tools - an introduction to writing scripts for mkinitramfs

DESCRIPTION

initramfs-tools has one main script and two different sets of subscripts which will be used during different phases of execution. Each of these will be discussed separately below with the help of an imaginary tool which performs a frobnication of a lvm partition prior to mounting the root partition.

Kernel Command Line

The root filesystem used by the kernel is specified by the boot loader as always. The traditional root=/dev/sda1 style device specification is allowed. If a label is used, as in root=LABEL=rootPart the initrd will search all available devices for a filesystem with the appropriate label, and mount that device as the root filesystem. root=UUID=uuidnumber will mount the partition with that UUID as the root filesystem.

Standard

init= “<path to real init>”
the binary to hand over execution to on the root fs after the initramfs scripts are done.

initramfs.clear
clear screen at the beginning

initramfs.runsize
The size of the /run tmpfs mount point in bytes (suffixes are supported) or as percentage of your physical RAM. This parameter is used as the value of the size mount option to tmpfs. See https://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt for details. The default is 10%.

root= “<path to blockdevice>”
the device node to mount as the root file system. The recommended usage is to specify the UUID as followed “root=UUID=xxx”.

rootfstype
set the root file system type.

rootdelay
set delay in seconds. Determines how long mountroot waits for root to appear. The default is 180 seconds.

rootflags
set the file system mount option string.

nfsroot
can be either “auto” to try to get the relevant information from DHCP or a string of the form NFSSERVER:NFSPATH or NFSSERVER:NFSPATH:NFSOPTS. Use root=/dev/nfs for NFS to kick to in. NFSOPTS can be looked up in nfs(5).

ip
tells how to configure the ip address. Allows one to specify an different NFS server than the DHCP server. See Documentation/filesystems/nfsroot.txt in any recent Linux source for details. Optional parameter for NFS root.

BOOTIF
is a mac address in pxelinux format with leading “01-” and “-” as separations. pxelinux passes mac address of network card used to PXE boot on with this bootarg.

boot
either local or NFS (affects which initramfs scripts are run, see the “Subdirectories” section under boot scripts).

resume
The resume hook tries to autodetect the resume partition and uses the first swap partition as valid guess. It is possible to set the RESUME variable in /etc/initramfs-tools/conf.d/resume. The boot variable noresume overrides it.

resume_offset
Specify the offset from the partition given by “resume=” at which the swap header of the swap file is located.

quiet
reduces the amount of text output to the console during boot.

ro
mounts the rootfs read-only.

rw
mounts the rootfs read-write.

blacklist
disables load of specific modules. Use blacklist=module1,module2,module3 bootparameter.

Debug

panic
sets an timeout on panic. panic=<sec> is a documented security feature: it disables the debug shell.

debug
generates lots of output. It writes a log to /run/initramfs/initramfs.debug. Instead when invoked with an arbitrary argument output is written to console. Use for example “debug=vc”.

break
spawns a shell in the initramfs image at the chosen phase (top, modules, premount, mount, mountroot, bottom, init) before actually executing the corresponding scripts (see the “Boot scripts” section) or action. Multiple phases may be specified, delimited by commas. The default, if no phase is specified, is “premount”. Beware that if both “panic” and “break” are present, initramfs will not spawn any shells but reboot instead.

netconsole
loads netconsole linux modules with the chosen args.

all_generic_ide
loads generic IDE/ATA chipset support on boot.

SCRIPTS

Valid boot and hook scripts names consist solely of alphabetics, numerics, dashes and underscores. Other scripts are discarded.

Configuration hook scripts

These are used to override the user configuration where necessary, for example to force use of busybox instead of klibc utilities.

Hook scripts

These are used when an initramfs image is created and not included in the image itself. They can however cause files to be included in the image. Hook scripts are executed under errexit. Thus a hook script can abort the mkinitramfs build on possible errors (exitcode != 0).

Boot scripts

These are included in the initramfs image and normally executed during kernel boot in the early user-space before the root partition has been mounted.

CONFIGURATION HOOK SCRIPTS

Configuration hook scripts can be found in /usr/share/initramfs-tools/conf-hooks.d. They are sourced by mkinitramfs after the configuration files in /etc and before running any hook scripts. They can override any of the variables documented in initramfs.conf(5), but this should be done only if absolutely necessary. For example, if a package’s boot script requires commands not provided by klibc-utils, it should also install a configuration hook that sets BUSYBOX=y.

HOOK SCRIPTS

Hooks can be found in two places: /usr/share/initramfs-tools/hooks and /etc/initramfs-tools/hooks. They are executed during generation of the initramfs-image and are responsible for including all the necessary components in the image itself. No guarantees are made as to the order in which the different scripts are executed unless the prereqs are setup in the script. Please notice that PREREQ is only honored inside a single directory. So first the scripts in /usr/share/initramfs-tools are ordered according to their PREREQ values and executed. Then all scripts in /etc/initramfs-tools are ordered according to their PREREQ values and executed. This mean that currently there is no possibility to have a local script (/etc/initramfs-tools) get executed before one from the package (/usr/share/initramfs-tools).

If a hook script requires configuration beyond the exported variables listed below, it should read a private configuration file that is separate from the /etc/initramfs-tools directory. It must not read initramfs-tools configuration files directly.

In order to support prereqs, each script should begin with the following lines:

#!/bin/sh PREREQ="" prereqs() { echo “$PREREQ” }

case $1 in
prereqs)
	prereqs
	exit 0
	;;
esac

. /usr/share/initramfs-tools/hook-functions
# Begin real processing below this line

For example, if you are writing a new hook script which relies on lvm, the line starting with PREREQ should be changed to PREREQ=“lvm” which will ensure that the lvm hook script is run before your custom script.

Help functions

/usr/share/initramfs-tools/hook-functions contains a number of functions which deal with some common tasks in a hook script:

manual_add_modules adds a module (and any modules which it depends on) to the initramfs image.

Example: manual_add_modules isofs

add_modules_from_file reads a file containing a list of modules (one per line) to be added to the initramfs image. The file can contain comments (lines starting with #) and arguments to the modules by writing the arguments on the same line as the name of the module.

Example: add_modules_from_file /tmp/modlist

force_load adds a module (and its dependencies) to the initramfs image and also unconditionally loads the module during boot. Also supports passing arguments to the module by listing them after the module name.

Example: force_load cdrom debug=1

copy_modules_dir copies an entire module directory from /lib/modules/KERNELVERSION/ into the initramfs image.

Example: copy_modules_dir kernel/drivers/ata

Including binaries

If you need to copy an executable or shared library to the initramfs module, use a command like this:

copy_exec /sbin/mdadm /sbin

mkinitramfs will automatically detect which libraries it depends on and copy them to the initramfs. This means that most executables, unless compiled with klibc, will automatically include glibc in the image which will increase its size by several hundred kilobytes.

Including a system firmware preimage (early initramfs)

If you need to prepend data to the initramfs image, you need to prepare it in a file, and call the prepend_earlyinitramfs function. The file can be disposed of as soon as the function returns.

Example:

TEMP_FILE=$(mktemp ...)
  ...
prepend_earlyinitramfs ${TEMP_FILE}
rm -f ${TEMP_FILE}

Exported variables

mkinitramfs sets several variables for the hook scripts environment.

MODULESDIR
corresponds to the linux modules dir.

version
is the $(uname -r) linux version against mkinitramfs is run.

CONFDIR
is the path of the used initramfs-tools configurations.

DESTDIR
is the root path of the newly build initramfs.

DPKG_ARCH
allows arch specific hook additions.

verbose
corresponds to the verbosity of the update-initramfs run.

BUSYBOX, KEYMAP, MODULES
are as described in initramfs.conf(5).

BUSYBOXDIR
is the directory where busybox utilities should be installed from, or empty if busybox is not being used.

BOOT SCRIPTS

Similarly to hook scripts, boot scripts can be found in two places /usr/share/initramfs-tools/scripts/ and /etc/initramfs-tools/scripts/. There are a number of subdirectories to these two directories which control the boot stage at which the scripts are executed.

Header

Like for hook scripts, there are no guarantees as to the order in which the different scripts in one subdirectory (see “Subdirectories” below) are executed. In order to define a certain order, a similar header as for hook scripts should be used:

#!/bin/sh PREREQ="" prereqs() { echo “$PREREQ” }

case $1 in
prereqs)
	prereqs
	exit 0
	;;
esac

Where PREREQ is modified to list other scripts in the same subdirectory if necessary.

Help functions

A number of functions (mostly dealing with output) are provided to boot scripts in /scripts/functions :

log_success_msg Logs a success message

Example: log_success_msg “Frobnication successful”

log_failure_msg Logs a failure message

Example: log_failure_msg “Frobnication component froobz missing”

log_warning_msg Logs a warning message

Example: log_warning_msg “Only partial frobnication possible”

log_begin_msg Logs a message that some processing step has begun

log_end_msg Logs a message that some processing step is finished

Example:

log_begin_msg “Frobnication begun” # Do something log_end_msg

panic Logs an error message and executes a shell in the initramfs image to allow the user to investigate the situation.

Example: panic “Frobnication failed”

Subdirectories

Both /usr/share/initramfs-tools/scripts and /etc/initramfs-tools/scripts contains the following subdirectories.

init-top the scripts in this directory are the first scripts to be executed after sysfs and procfs have been mounted. It also runs the udev hook for populating the /dev tree (udev will keep running until init-bottom).

init-premount happens after modules specified by hooks and /etc/initramfs-tools/modules have been loaded.

local-top OR nfs-top After these scripts have been executed, the root device node is expected to be present (local) or the network interface is expected to be usable (NFS).

local-block These scripts are called with the name of a local block device. After these scripts have been executed, that device node should be present. If the local-top or local-block scripts fail to create the wanted device node, the local-block scripts will be called periodically to try again.

local-premount OR nfs-premount are run after the sanity of the root device has been verified (local) or the network interface has been brought up (NFS), but before the actual root fs has been mounted.

local-bottom OR nfs-bottom are run after the rootfs has been mounted (local) or the NFS root share has been mounted.

init-bottom are the last scripts to be executed before procfs and sysfs are moved to the real rootfs and execution is turned over to the init binary which should now be found in the mounted rootfs. udev is stopped.

Boot parameters

/conf/param.conf allows boot scripts to change exported variables that are listed on top of init. Write the new values to it. It will be sourced after an boot script run if it exists.

EXAMPLES

Hook script

An example hook script would look something like this (and would usually be placed in /etc/initramfs-tools/hooks/frobnicate):

#!/bin/sh # Example frobnication hook script

PREREQ="lvm"
prereqs()
{
	echo "$PREREQ"
}

case $1 in
prereqs)
	prereqs
	exit 0
	;;
esac

. /usr/share/initramfs-tools/hook-functions
# Begin real processing below this line

if [ ! -x "/sbin/frobnicate" ]; then
	exit 0
fi

force_load frobnicator interval=10
copy_exec /sbin/frobnicate /sbin
exit 0

Boot script

An example boot script would look something like this (and would usually be placed in /etc/initramfs-tools/scripts/local-top/frobnicate):

#!/bin/sh # Example frobnication boot script

PREREQ="lvm"
prereqs()
{
	echo "$PREREQ"
}

case $1 in
prereqs)
	prereqs
	exit 0
	;;
esac

. /scripts/functions
# Begin real processing below this line
if [ ! -x "/sbin/frobnicate" ]; then
	panic "Frobnication executable not found"
fi

if [ ! -e "/dev/mapper/frobb" ]; then
	panic "Frobnication device not found"
fi

log_begin_msg "Starting frobnication"
/sbin/frobnicate "/dev/mapper/frobb" || panic "Frobnication failed"
log_end_msg

exit 0

Exported variables

init sets several variables for the boot scripts environment.

ROOT
corresponds to the root boot option. Advanced boot scripts like cryptsetup or live-initramfs need to play tricks. Otherwise keep it alone.

ROOTDELAY, ROOTFLAGS, ROOTFSTYPE, IP
corresponds to the rootdelay, rootflags, rootfstype or ip boot option. Use of ROOTDELAY is deprecated; you should implement a local-block boot script rather than delaying or polling.

DPKG_ARCH
allows arch specific boot actions.

blacklist, panic, quiet, resume, noresume, resume_offset
set according relevant boot option.

break
Useful for manual intervention during setup and coding an boot script.

REASON
Argument passed to the panic helper function. Use to find out why you landed in the initramfs shell.

init
passes the path to init(8) usually /sbin/init.

readonly
is the default for mounting the root corresponds to the ro bootarg. Overridden by rw bootarg.

rootmnt
is the path where root gets mounted usually /root.

debug
indicates that a debug log is captured for further investigation.

UPDATING THE INITRAMFS FROM ANOTHER PACKAGE

Package maintainer scripts should not run update-initramfs directly. A package that installs hooks for initramfs-tools should include a triggers file containing:

activate-noawait update-initramfs

Kernel packages must call the kernel hooks as documented in the Debian Kernel Handbook.

A package that requires an initramfs to function, but is not a kernel package, should include a triggers file containing:

activate-await update-initramfs

KERNEL HOOKS

initramfs-tools includes hook scripts that are called by kernel packages on installation and removal, so that an initramfs is automatically created, updated or deleted as necessary. The hook scripts do nothing if the environment variable INITRD is set to No. This will be the case for kernel packages built with make deb-pkg and with CONFIG_BLK_DEV_INITRD not set in the kernel config, or built with make-kpkg and not using the –initrd option.

DEBUG

It is easy to check the generated initramfs for its content. One may need to double-check if it contains the relevant binaries, libs or modules:

lsinitramfs /boot/initrd.img-3.16-3-amd64

FILES

/run/initramfs/fsck.log
Log of fsck commands run within the initramfs, with their output.

/run/initramfs/fsck-root
Exists only if fsck ran successfully for the root filesystem.

/run/initramfs/fsck-usr
Exists only if fsck ran successfully for the /usr filesystem.

AUTHOR

The initramfs-tools are written by Maximilian Attems <[email protected]>, Jeff Bailey <[email protected]> and numerous others.

This manual was written by David Härdeman <[email protected]>, updated by Maximilian Attems <[email protected]>.

SEE ALSO

initramfs.conf(5), mkinitramfs(8), update-initramfs(8), lsinitramfs(8).

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

379 - Linux cli command ALTER_DOMAIN

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_DOMAIN and provides detailed information about the command ALTER_DOMAIN, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_DOMAIN.

NAME 🖥️ ALTER_DOMAIN 🖥️

change the definition of a domain

SYNOPSIS

ALTER DOMAIN name
    { SET DEFAULT expression | DROP DEFAULT }
ALTER DOMAIN name
    { SET | DROP } NOT NULL
ALTER DOMAIN name
    ADD domain_constraint [ NOT VALID ]
ALTER DOMAIN name
    DROP CONSTRAINT [ IF EXISTS ] constraint_name [ RESTRICT | CASCADE ]
ALTER DOMAIN name
     RENAME CONSTRAINT constraint_name TO new_constraint_name
ALTER DOMAIN name
    VALIDATE CONSTRAINT constraint_name
ALTER DOMAIN name
    OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }
ALTER DOMAIN name
    RENAME TO new_name
ALTER DOMAIN name
    SET SCHEMA new_schema

DESCRIPTION

ALTER DOMAIN changes the definition of an existing domain. There are several sub-forms:

SET/DROP DEFAULT

These forms set or remove the default value for a domain. Note that defaults only apply to subsequent INSERT commands; they do not affect rows already in a table using the domain.

SET/DROP NOT NULL

These forms change whether a domain is marked to allow NULL values or to reject NULL values. You can only SET NOT NULL when the columns using the domain contain no null values.

ADD domain_constraint [ NOT VALID ]

This form adds a new constraint to a domain using the same syntax as CREATE DOMAIN. When a new constraint is added to a domain, all columns using that domain will be checked against the newly added constraint. These checks can be suppressed by adding the new constraint using the NOT VALID option; the constraint can later be made valid using ALTER DOMAIN … VALIDATE CONSTRAINT. Newly inserted or updated rows are always checked against all constraints, even those marked NOT VALID. NOT VALID is only accepted for CHECK constraints.

DROP CONSTRAINT [ IF EXISTS ]

This form drops constraints on a domain. If IF EXISTS is specified and the constraint does not exist, no error is thrown. In this case a notice is issued instead.

RENAME CONSTRAINT

This form changes the name of a constraint on a domain.

VALIDATE CONSTRAINT

This form validates a constraint previously added as NOT VALID, that is, it verifies that all values in table columns of the domain type satisfy the specified constraint.

OWNER

This form changes the owner of the domain to the specified user.

RENAME

This form changes the name of the domain.

SET SCHEMA

This form changes the schema of the domain. Any constraints associated with the domain are moved into the new schema as well.

You must own the domain to use ALTER DOMAIN. To change the schema of a domain, you must also have CREATE privilege on the new schema. To alter the owner, you must be able to SET ROLE to the new owning role, and that role must have CREATE privilege on the domains schema. (These restrictions enforce that altering the owner doesnt do anything you couldnt do by dropping and recreating the domain. However, a superuser can alter ownership of any domain anyway.)

PARAMETERS

name

The name (possibly schema-qualified) of an existing domain to alter.

domain_constraint

New domain constraint for the domain.

constraint_name

Name of an existing constraint to drop or rename.

NOT VALID

Do not verify existing stored data for constraint validity.

CASCADE

Automatically drop objects that depend on the constraint, and in turn all objects that depend on those objects (see Section 5.14).

RESTRICT

Refuse to drop the constraint if there are any dependent objects. This is the default behavior.

new_name

The new name for the domain.

new_constraint_name

The new name for the constraint.

new_owner

The user name of the new owner of the domain.

new_schema

The new schema for the domain.

NOTES

Although ALTER DOMAIN ADD CONSTRAINT attempts to verify that existing stored data satisfies the new constraint, this check is not bulletproof, because the command cannot “see” table rows that are newly inserted or updated and not yet committed. If there is a hazard that concurrent operations might insert bad data, the way to proceed is to add the constraint using the NOT VALID option, commit that command, wait until all transactions started before that commit have finished, and then issue ALTER DOMAIN VALIDATE CONSTRAINT to search for data violating the constraint. This method is reliable because once the constraint is committed, all new transactions are guaranteed to enforce it against new values of the domain type.

Currently, ALTER DOMAIN ADD CONSTRAINT, ALTER DOMAIN VALIDATE CONSTRAINT, and ALTER DOMAIN SET NOT NULL will fail if the named domain or any derived domain is used within a container-type column (a composite, array, or range column) in any table in the database. They should eventually be improved to be able to verify the new constraint for such nested values.

EXAMPLES

To add a NOT NULL constraint to a domain:

ALTER DOMAIN zipcode SET NOT NULL;

To remove a NOT NULL constraint from a domain:

ALTER DOMAIN zipcode DROP NOT NULL;

To add a check constraint to a domain:

ALTER DOMAIN zipcode ADD CONSTRAINT zipchk CHECK (char_length(VALUE) = 5);

To remove a check constraint from a domain:

ALTER DOMAIN zipcode DROP CONSTRAINT zipchk;

To rename a check constraint on a domain:

ALTER DOMAIN zipcode RENAME CONSTRAINT zipchk TO zip_check;

To move the domain into a different schema:

ALTER DOMAIN zipcode SET SCHEMA customers;

COMPATIBILITY

ALTER DOMAIN conforms to the SQL standard, except for the OWNER, RENAME, SET SCHEMA, and VALIDATE CONSTRAINT variants, which are PostgreSQL extensions. The NOT VALID clause of the ADD CONSTRAINT variant is also a PostgreSQL extension.

SEE ALSO

CREATE DOMAIN (CREATE_DOMAIN(7)), DROP DOMAIN (DROP_DOMAIN(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

380 - Linux cli command provider-storemgmtssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command provider-storemgmtssl and provides detailed information about the command provider-storemgmtssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the provider-storemgmtssl.

NAME 🖥️ provider-storemgmtssl 🖥️

storemgmt - The OSSL_STORE library <-> provider functions

SYNOPSIS

#include <openssl/core_dispatch.h> /* * None of these are actual functions, but are displayed like this for * the function signatures for functions that are offered as function * pointers in OSSL_DISPATCH arrays. */ void *OSSL_FUNC_store_open(void *provctx, const char *uri); void *OSSL_FUNC_store_attach(void *provctx, OSSL_CORE_BIO *bio); const OSSL_PARAM *store_settable_ctx_params(void *provctx); int OSSL_FUNC_store_set_ctx_params(void *loaderctx, const OSSL_PARAM[]); int OSSL_FUNC_store_load(void *loaderctx, OSSL_CALLBACK *object_cb, void *object_cbarg, OSSL_PASSPHRASE_CALLBACK *pw_cb, void *pw_cbarg); int OSSL_FUNC_store_eof(void *loaderctx); int OSSL_FUNC_store_close(void *loaderctx); int OSSL_FUNC_store_export_object (void *loaderctx, const void *objref, size_t objref_sz, OSSL_CALLBACK *export_cb, void *export_cbarg); void *OSSL_FUNC_store_open_ex(void *provctx, const char *uri, const OSSL_PARAM params[], OSSL_PASSPHRASE_CALLBACK *pw_cb, void *pw_cbarg); int OSSL_FUNC_store_delete(void *provctx, const char *uri, const OSSL_PARAM params[], OSSL_PASSPHRASE_CALLBACK *pw_cb, void *pw_cbarg);

DESCRIPTION

The STORE operation is the provider side of the ossl_store (7) API.

The primary responsibility of the STORE operation is to load all sorts of objects from a container indicated by URI. These objects are given to the OpenSSL library in provider-native object abstraction form (see provider-object (7)). The OpenSSL library is then responsible for passing on that abstraction to suitable provided functions.

Examples of functions that the OpenSSL library can pass the abstraction to include OSSL_FUNC_keymgmt_load() (provider-keymgmt (7)), OSSL_FUNC_store_export_object() (which exports the object in parameterized form).

All “functions” mentioned here are passed as function pointers between libcrypto and the provider in OSSL_DISPATCH (3) arrays via OSSL_ALGORITHM (3) arrays that are returned by the provider’s provider_query_operation() function (see “Provider Functions” in provider-base (7)).

All these “functions” have a corresponding function type definition named OSSL_FUNC_{name}_fn, and a helper function to retrieve the function pointer from a OSSL_DISPATCH (3) element named OSSL_get_{name}. For example, the “function” OSSL_FUNC_store_attach() has these:

typedef void *(OSSL_FUNC_store_attach_fn)(void *provctx, OSSL_CORE_BIO * bio); static ossl_inline OSSL_FUNC_store_attach_fn OSSL_FUNC_store_attach(const OSSL_DISPATCH *opf);

OSSL_DISPATCH (3) arrays are indexed by numbers that are provided as macros in openssl-core_dispatch.h (7), as follows:

OSSL_FUNC_store_open OSSL_FUNC_STORE_OPEN OSSL_FUNC_store_attach OSSL_FUNC_STORE_ATTACH OSSL_FUNC_store_settable_ctx_params OSSL_FUNC_STORE_SETTABLE_CTX_PARAMS OSSL_FUNC_store_set_ctx_params OSSL_FUNC_STORE_SET_CTX_PARAMS OSSL_FUNC_store_load OSSL_FUNC_STORE_LOAD OSSL_FUNC_store_eof OSSL_FUNC_STORE_EOF OSSL_FUNC_store_close OSSL_FUNC_STORE_CLOSE OSSL_FUNC_store_export_object OSSL_FUNC_STORE_EXPORT_OBJECT OSSL_FUNC_store_delete OSSL_FUNC_STORE_DELETE OSSL_FUNC_store_open_ex OSSL_FUNC_STORE_OPEN_EX

Functions

OSSL_FUNC_store_open() should create a provider side context with data based on the input uri. The implementation is entirely responsible for the interpretation of the URI.

OSSL_FUNC_store_attach() should create a provider side context with the core BIO bio attached. This is an alternative to using a URI to find storage, supporting OSSL_STORE_attach (3).

OSSL_FUNC_store_settable_ctx_params() should return a constant array of descriptor OSSL_PARAM (3), for parameters that OSSL_FUNC_store_set_ctx_params() can handle.

OSSL_FUNC_store_set_ctx_params() should set additional parameters, such as what kind of data to expect, search criteria, and so on. More on those below, in “Load Parameters”. Whether unrecognised parameters are an error or simply ignored is at the implementation’s discretion. Passing NULL for params should return true.

OSSL_FUNC_store_load() loads the next object from the URI opened by OSSL_FUNC_store_open(), creates an object abstraction for it (see provider-object (7)), and calls object_cb with it as well as object_cbarg. object_cb will then interpret the object abstraction and do what it can to wrap it or decode it into an OpenSSL structure. In case a passphrase needs to be prompted to unlock an object, pw_cb should be called.

OSSL_FUNC_store_eof() indicates if the end of the set of objects from the URI has been reached. When that happens, there’s no point trying to do any further loading.

OSSL_FUNC_store_close() frees the provider side context ctx.

When a provider-native object is created by a store manager it would be unsuitable for direct use with a foreign provider. The export function allows for exporting the object to that foreign provider if the foreign provider supports the type of the object and provides an import function.

OSSL_FUNC_store_export_object() should export the object of size objref_sz referenced by objref as an OSSL_PARAM (3) array and pass that to the export_cb as well as the given export_cbarg.

OSSL_FUNC_store_delete() deletes the object identified by the uri. The implementation is entirely responsible for the interpretation of the URI. In case a passphrase needs to be prompted to remove an object, pw_cb should be called.

OSSL_FUNC_store_open_ex() is an extended variant of OSSL_FUNC_store_open(). If the provider does not implement this function the code internally falls back to use the original OSSL_FUNC_store_open(). This variant additionally accepts an OSSL_PARAM (3) object and a pw_cb callback that can be used to request a passphrase in cases where the whole store needs to be unlocked before performing any load operation.

Load Parameters

“expect” (OSSL_STORE_PARAM_EXPECT) <integer>
Is a hint of what type of data the OpenSSL library expects to get. This is only useful for optimization, as the library will check that the object types match the expectation too. The number that can be given through this parameter is found in <openssl/store.h>, with the macros having names starting with OSSL_STORE_INFO_. These are further described in “SUPPORTED OBJECTS” in OSSL_STORE_INFO (3).

“subject” (OSSL_STORE_PARAM_SUBJECT) <octet string>
Indicates that the caller wants to search for an object with the given subject associated. This can be used to select specific certificates by subject. The contents of the octet string is expected to be in DER form.

“issuer” (OSSL_STORE_PARAM_ISSUER) <octet string>
Indicates that the caller wants to search for an object with the given issuer associated. This can be used to select specific certificates by issuer. The contents of the octet string is expected to be in DER form.

“serial” (OSSL_STORE_PARAM_SERIAL) <integer>
Indicates that the caller wants to search for an object with the given serial number associated.

“digest” (OSSL_STORE_PARAM_DIGEST) <UTF8 string>

“fingerprint” (OSSL_STORE_PARAM_FINGERPRINT) <octet string>

Indicates that the caller wants to search for an object with the given fingerprint, computed with the given digest.

“alias” (OSSL_STORE_PARAM_ALIAS) <UTF8 string>
Indicates that the caller wants to search for an object with the given alias (some call it a “friendly name”).

“properties” (OSSL_STORE_PARAM_PROPERTIES) <utf8 string>
Property string to use when querying for algorithms such as the OSSL_DECODER decoder implementations.

“input-type” (OSSL_STORE_PARAM_INPUT_TYPE) <utf8 string>
Type of the input format as a hint to use when decoding the objects in the store.

Several of these search criteria may be combined. For example, to search for a certificate by issuer+serial, both the “issuer” and the “serial” parameters will be given.

SEE ALSO

provider (7)

HISTORY

The STORE interface was introduced in OpenSSL 3.0.

OSSL_FUNC_store_delete() callback was added in OpenSSL 3.2

COPYRIGHT

Copyright 2020-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

381 - Linux cli command iso_8859-13

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso_8859-13 and provides detailed information about the command iso_8859-13, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso_8859-13.

NAME 🖥️ iso_8859-13 🖥️

13 - ISO/IEC 8859-13 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-13 encodes the characters used in Baltic Rim languages.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-13 characters

The following table displays the characters in ISO/IEC 8859-13 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-13 is also known as Latin-7.

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

382 - Linux cli command armscii-8

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command armscii-8 and provides detailed information about the command armscii-8, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the armscii-8.

NAME 🖥️ armscii-8 🖥️

8 - Armenian character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The Armenian Standard Code for Information Interchange, 8-bit coded character set.

ArmSCII-8 characters

The following table displays the characters in ArmSCII-8 that are printable and unlisted in the ascii(7) manual page.

TABLE

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

383 - Linux cli command iso-8859-10

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso-8859-10 and provides detailed information about the command iso-8859-10, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso-8859-10.

NAME 🖥️ iso-8859-10 🖥️

10 - ISO/IEC 8859-10 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-10 encodes the characters used in Nordic languages.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-10 characters

The following table displays the characters in ISO/IEC 8859-10 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-10 is also known as Latin-6.

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

384 - Linux cli command SELECT_INTO

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command SELECT_INTO and provides detailed information about the command SELECT_INTO, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the SELECT_INTO.

NAME 🖥️ SELECT_INTO 🖥️

define a new table from the results of a query

SYNOPSIS

[ WITH [ RECURSIVE ] with_query [, ...] ]
SELECT [ ALL | DISTINCT [ ON ( expression [, ...] ) ] ]
    [ { * | expression [ [ AS ] output_name ] } [, ...] ]
    INTO [ TEMPORARY | TEMP | UNLOGGED ] [ TABLE ] new_table
    [ FROM from_item [, ...] ]
    [ WHERE condition ]
    [ GROUP BY expression [, ...] ]
    [ HAVING condition ]
    [ WINDOW window_name AS ( window_definition ) [, ...] ]
    [ { UNION | INTERSECT | EXCEPT } [ ALL | DISTINCT ] select ]
    [ ORDER BY expression [ ASC | DESC | USING operator ] [ NULLS { FIRST | LAST } ] [, ...] ]
    [ LIMIT { count | ALL } ]
    [ OFFSET start [ ROW | ROWS ] ]
    [ FETCH { FIRST | NEXT } [ count ] { ROW | ROWS } ONLY ]
    [ FOR { UPDATE | SHARE } [ OF table_name [, ...] ] [ NOWAIT ] [...] ]

DESCRIPTION

SELECT INTO creates a new table and fills it with data computed by a query. The data is not returned to the client, as it is with a normal SELECT. The new tables columns have the names and data types associated with the output columns of the SELECT.

PARAMETERS

TEMPORARY or TEMP

If specified, the table is created as a temporary table. Refer to CREATE TABLE (CREATE_TABLE(7)) for details.

UNLOGGED

If specified, the table is created as an unlogged table. Refer to CREATE TABLE (CREATE_TABLE(7)) for details.

new_table

The name (optionally schema-qualified) of the table to be created.

All other parameters are described in detail under SELECT(7).

NOTES

CREATE TABLE AS is functionally similar to SELECT INTO. CREATE TABLE AS is the recommended syntax, since this form of SELECT INTO is not available in ECPG or PL/pgSQL, because they interpret the INTO clause differently. Furthermore, CREATE TABLE AS offers a superset of the functionality provided by SELECT INTO.

In contrast to CREATE TABLE AS, SELECT INTO does not allow specifying properties like a tables access method with USING method or the tables tablespace with TABLESPACE tablespace_name. Use CREATE TABLE AS if necessary. Therefore, the default table access method is chosen for the new table. See default_table_access_method for more information.

EXAMPLES

Create a new table films_recent consisting of only recent entries from the table films:

SELECT * INTO films_recent FROM films WHERE date_prod >= 2002-01-01;

COMPATIBILITY

The SQL standard uses SELECT INTO to represent selecting values into scalar variables of a host program, rather than creating a new table. This indeed is the usage found in ECPG (see Chapter 36) and PL/pgSQL (see Chapter 43). The PostgreSQL usage of SELECT INTO to represent table creation is historical. Some other SQL implementations also use SELECT INTO in this way (but most SQL implementations support CREATE TABLE AS instead). Apart from such compatibility considerations, it is best to use CREATE TABLE AS for this purpose in new code.

SEE ALSO

CREATE TABLE AS (CREATE_TABLE_AS(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

385 - Linux cli command ALTER_LARGE_OBJECT

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_LARGE_OBJECT and provides detailed information about the command ALTER_LARGE_OBJECT, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_LARGE_OBJECT.

NAME 🖥️ ALTER_LARGE_OBJECT 🖥️

change the definition of a large object

SYNOPSIS

ALTER LARGE OBJECT large_object_oid OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }

DESCRIPTION

ALTER LARGE OBJECT changes the definition of a large object.

You must own the large object to use ALTER LARGE OBJECT. To alter the owner, you must also be able to SET ROLE to the new owning role. (However, a superuser can alter any large object anyway.) Currently, the only functionality is to assign a new owner, so both restrictions always apply.

PARAMETERS

large_object_oid

OID of the large object to be altered

new_owner

The new owner of the large object

COMPATIBILITY

There is no ALTER LARGE OBJECT statement in the SQL standard.

SEE ALSO

Chapter 35

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

386 - Linux cli command CREATE_PROCEDURE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_PROCEDURE and provides detailed information about the command CREATE_PROCEDURE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_PROCEDURE.

NAME 🖥️ CREATE_PROCEDURE 🖥️

define a new procedure

SYNOPSIS

CREATE [ OR REPLACE ] PROCEDURE
    name ( [ [ argmode ] [ argname ] argtype [ { DEFAULT | = } default_expr ] [, ...] ] )
  { LANGUAGE lang_name
    | TRANSFORM { FOR TYPE type_name } [, ... ]
    | [ EXTERNAL ] SECURITY INVOKER | [ EXTERNAL ] SECURITY DEFINER
    | SET configuration_parameter { TO value | = value | FROM CURRENT }
    | AS definition
    | AS obj_file, link_symbol
    | sql_body
  } ...

DESCRIPTION

CREATE PROCEDURE defines a new procedure. CREATE OR REPLACE PROCEDURE will either create a new procedure, or replace an existing definition. To be able to define a procedure, the user must have the USAGE privilege on the language.

If a schema name is included, then the procedure is created in the specified schema. Otherwise it is created in the current schema. The name of the new procedure must not match any existing procedure or function with the same input argument types in the same schema. However, procedures and functions of different argument types can share a name (this is called overloading).

To replace the current definition of an existing procedure, use CREATE OR REPLACE PROCEDURE. It is not possible to change the name or argument types of a procedure this way (if you tried, you would actually be creating a new, distinct procedure).

When CREATE OR REPLACE PROCEDURE is used to replace an existing procedure, the ownership and permissions of the procedure do not change. All other procedure properties are assigned the values specified or implied in the command. You must own the procedure to replace it (this includes being a member of the owning role).

The user that creates the procedure becomes the owner of the procedure.

To be able to create a procedure, you must have USAGE privilege on the argument types.

Refer to Section 38.4 for further information on writing procedures.

PARAMETERS

name

The name (optionally schema-qualified) of the procedure to create.

argmode

The mode of an argument: IN, OUT, INOUT, or VARIADIC. If omitted, the default is IN.

argname

The name of an argument.

argtype

The data type(s) of the procedures arguments (optionally schema-qualified), if any. The argument types can be base, composite, or domain types, or can reference the type of a table column.

Depending on the implementation language it might also be allowed to specify “pseudo-types” such as cstring. Pseudo-types indicate that the actual argument type is either incompletely specified, or outside the set of ordinary SQL data types.

The type of a column is referenced by writing table_name.column_name%TYPE. Using this feature can sometimes help make a procedure independent of changes to the definition of a table.

default_expr

An expression to be used as default value if the parameter is not specified. The expression has to be coercible to the argument type of the parameter. All input parameters following a parameter with a default value must have default values as well.

lang_name

The name of the language that the procedure is implemented in. It can be sql, c, internal, or the name of a user-defined procedural language, e.g., plpgsql. The default is sql if sql_body is specified. Enclosing the name in single quotes is deprecated and requires matching case.

TRANSFORM { FOR TYPE type_name } [, … ] }

Lists which transforms a call to the procedure should apply. Transforms convert between SQL types and language-specific data types; see CREATE TRANSFORM (CREATE_TRANSFORM(7)). Procedural language implementations usually have hardcoded knowledge of the built-in types, so those dont need to be listed here. If a procedural language implementation does not know how to handle a type and no transform is supplied, it will fall back to a default behavior for converting data types, but this depends on the implementation.

[EXTERNAL] SECURITY INVOKER
[EXTERNAL] SECURITY DEFINER

SECURITY INVOKER indicates that the procedure is to be executed with the privileges of the user that calls it. That is the default. SECURITY DEFINER specifies that the procedure is to be executed with the privileges of the user that owns it.

The key word EXTERNAL is allowed for SQL conformance, but it is optional since, unlike in SQL, this feature applies to all procedures not only external ones.

A SECURITY DEFINER procedure cannot execute transaction control statements (for example, COMMIT and ROLLBACK, depending on the language).

configuration_parameter
value

The SET clause causes the specified configuration parameter to be set to the specified value when the procedure is entered, and then restored to its prior value when the procedure exits. SET FROM CURRENT saves the value of the parameter that is current when CREATE PROCEDURE is executed as the value to be applied when the procedure is entered.

If a SET clause is attached to a procedure, then the effects of a SET LOCAL command executed inside the procedure for the same variable are restricted to the procedure: the configuration parameters prior value is still restored at procedure exit. However, an ordinary SET command (without LOCAL) overrides the SET clause, much as it would do for a previous SET LOCAL command: the effects of such a command will persist after procedure exit, unless the current transaction is rolled back.

If a SET clause is attached to a procedure, then that procedure cannot execute transaction control statements (for example, COMMIT and ROLLBACK, depending on the language).

See SET(7) and Chapter 20 for more information about allowed parameter names and values.

definition

A string constant defining the procedure; the meaning depends on the language. It can be an internal procedure name, the path to an object file, an SQL command, or text in a procedural language.

It is often helpful to use dollar quoting (see Section 4.1.2.4) to write the procedure definition string, rather than the normal single quote syntax. Without dollar quoting, any single quotes or backslashes in the procedure definition must be escaped by doubling them.

obj_file, link_symbol

This form of the AS clause is used for dynamically loadable C language procedures when the procedure name in the C language source code is not the same as the name of the SQL procedure. The string obj_file is the name of the shared library file containing the compiled C procedure, and is interpreted as for the LOAD command. The string link_symbol is the procedures link symbol, that is, the name of the procedure in the C language source code. If the link symbol is omitted, it is assumed to be the same as the name of the SQL procedure being defined.

When repeated CREATE PROCEDURE calls refer to the same object file, the file is only loaded once per session. To unload and reload the file (perhaps during development), start a new session.

sql_body

The body of a LANGUAGE SQL procedure. This should be a block

BEGIN ATOMIC statement; statement; … statement; END

This is similar to writing the text of the procedure body as a string constant (see definition above), but there are some differences: This form only works for LANGUAGE SQL, the string constant form works for all languages. This form is parsed at procedure definition time, the string constant form is parsed at execution time; therefore this form cannot support polymorphic argument types and other constructs that are not resolvable at procedure definition time. This form tracks dependencies between the procedure and objects used in the procedure body, so DROP … CASCADE will work correctly, whereas the form using string literals may leave dangling procedures. Finally, this form is more compatible with the SQL standard and other SQL implementations.

NOTES

See CREATE FUNCTION (CREATE_FUNCTION(7)) for more details on function creation that also apply to procedures.

Use CALL(7) to execute a procedure.

EXAMPLES

CREATE PROCEDURE insert_data(a integer, b integer) LANGUAGE SQL AS $$ INSERT INTO tbl VALUES (a); INSERT INTO tbl VALUES (b); $$;

or

CREATE PROCEDURE insert_data(a integer, b integer) LANGUAGE SQL BEGIN ATOMIC INSERT INTO tbl VALUES (a); INSERT INTO tbl VALUES (b); END;

and call like this:

CALL insert_data(1, 2);

COMPATIBILITY

A CREATE PROCEDURE command is defined in the SQL standard. The PostgreSQL implementation can be used in a compatible way but has many extensions. For details see also CREATE FUNCTION (CREATE_FUNCTION(7)).

SEE ALSO

ALTER PROCEDURE (ALTER_PROCEDURE(7)), DROP PROCEDURE (DROP_PROCEDURE(7)), CALL(7), CREATE FUNCTION (CREATE_FUNCTION(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

387 - Linux cli command ALTER_PROCEDURE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_PROCEDURE and provides detailed information about the command ALTER_PROCEDURE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_PROCEDURE.

NAME 🖥️ ALTER_PROCEDURE 🖥️

change the definition of a procedure

SYNOPSIS

ALTER PROCEDURE name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ]
    action [ ... ] [ RESTRICT ]
ALTER PROCEDURE name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ]
    RENAME TO new_name
ALTER PROCEDURE name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ]
    OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }
ALTER PROCEDURE name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ]
    SET SCHEMA new_schema
ALTER PROCEDURE name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ]
    [ NO ] DEPENDS ON EXTENSION extension_name

where action is one of:

    [ EXTERNAL ] SECURITY INVOKER | [ EXTERNAL ] SECURITY DEFINER
    SET configuration_parameter { TO | = } { value | DEFAULT }
    SET configuration_parameter FROM CURRENT
    RESET configuration_parameter
    RESET ALL

DESCRIPTION

ALTER PROCEDURE changes the definition of a procedure.

You must own the procedure to use ALTER PROCEDURE. To change a procedures schema, you must also have CREATE privilege on the new schema. To alter the owner, you must be able to SET ROLE to the new owning role, and that role must have CREATE privilege on the procedures schema. (These restrictions enforce that altering the owner doesnt do anything you couldnt do by dropping and recreating the procedure. However, a superuser can alter ownership of any procedure anyway.)

PARAMETERS

name

The name (optionally schema-qualified) of an existing procedure. If no argument list is specified, the name must be unique in its schema.

argmode

The mode of an argument: IN, OUT, INOUT, or VARIADIC. If omitted, the default is IN.

argname

The name of an argument. Note that ALTER PROCEDURE does not actually pay any attention to argument names, since only the argument data types are used to determine the procedures identity.

argtype

The data type(s) of the procedures arguments (optionally schema-qualified), if any. See DROP PROCEDURE (DROP_PROCEDURE(7)) for the details of how the procedure is looked up using the argument data type(s).

new_name

The new name of the procedure.

new_owner

The new owner of the procedure. Note that if the procedure is marked SECURITY DEFINER, it will subsequently execute as the new owner.

new_schema

The new schema for the procedure.

extension_name

This form marks the procedure as dependent on the extension, or no longer dependent on the extension if NO is specified. A procedure thats marked as dependent on an extension is dropped when the extension is dropped, even if cascade is not specified. A procedure can depend upon multiple extensions, and will be dropped when any one of those extensions is dropped.

[ EXTERNAL ] SECURITY INVOKER
[ EXTERNAL ] SECURITY DEFINER

Change whether the procedure is a security definer or not. The key word EXTERNAL is ignored for SQL conformance. See CREATE PROCEDURE (CREATE_PROCEDURE(7)) for more information about this capability.

configuration_parameter
value

Add or change the assignment to be made to a configuration parameter when the procedure is called. If value is DEFAULT or, equivalently, RESET is used, the procedure-local setting is removed, so that the procedure executes with the value present in its environment. Use RESET ALL to clear all procedure-local settings. SET FROM CURRENT saves the value of the parameter that is current when ALTER PROCEDURE is executed as the value to be applied when the procedure is entered.

See SET(7) and Chapter 20 for more information about allowed parameter names and values.

RESTRICT

Ignored for conformance with the SQL standard.

EXAMPLES

To rename the procedure insert_data with two arguments of type integer to insert_record:

ALTER PROCEDURE insert_data(integer, integer) RENAME TO insert_record;

To change the owner of the procedure insert_data with two arguments of type integer to joe:

ALTER PROCEDURE insert_data(integer, integer) OWNER TO joe;

To change the schema of the procedure insert_data with two arguments of type integer to accounting:

ALTER PROCEDURE insert_data(integer, integer) SET SCHEMA accounting;

To mark the procedure insert_data(integer, integer) as being dependent on the extension myext:

ALTER PROCEDURE insert_data(integer, integer) DEPENDS ON EXTENSION myext;

To adjust the search path that is automatically set for a procedure:

ALTER PROCEDURE check_password(text) SET search_path = admin, pg_temp;

To disable automatic setting of search_path for a procedure:

ALTER PROCEDURE check_password(text) RESET search_path;

The procedure will now execute with whatever search path is used by its caller.

COMPATIBILITY

This statement is partially compatible with the ALTER PROCEDURE statement in the SQL standard. The standard allows more properties of a procedure to be modified, but does not provide the ability to rename a procedure, make a procedure a security definer, attach configuration parameter values to a procedure, or change the owner, schema, or volatility of a procedure. The standard also requires the RESTRICT key word, which is optional in PostgreSQL.

SEE ALSO

CREATE PROCEDURE (CREATE_PROCEDURE(7)), DROP PROCEDURE (DROP_PROCEDURE(7)), ALTER FUNCTION (ALTER_FUNCTION(7)), ALTER ROUTINE (ALTER_ROUTINE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

388 - Linux cli command CREATE_CONVERSION

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_CONVERSION and provides detailed information about the command CREATE_CONVERSION, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_CONVERSION.

NAME 🖥️ CREATE_CONVERSION 🖥️

define a new encoding conversion

SYNOPSIS

CREATE [ DEFAULT ] CONVERSION name
    FOR source_encoding TO dest_encoding FROM function_name

DESCRIPTION

CREATE CONVERSION defines a new conversion between two character set encodings.

Conversions that are marked DEFAULT can be used for automatic encoding conversion between client and server. To support that usage, two conversions, from encoding A to B and from encoding B to A, must be defined.

To be able to create a conversion, you must have EXECUTE privilege on the function and CREATE privilege on the destination schema.

PARAMETERS

DEFAULT

The DEFAULT clause indicates that this conversion is the default for this particular source to destination encoding. There should be only one default encoding in a schema for the encoding pair.

name

The name of the conversion. The conversion name can be schema-qualified. If it is not, the conversion is defined in the current schema. The conversion name must be unique within a schema.

source_encoding

The source encoding name.

dest_encoding

The destination encoding name.

function_name

The function used to perform the conversion. The function name can be schema-qualified. If it is not, the function will be looked up in the path.

The function must have the following signature:

conv_proc( integer, – source encoding ID integer, – destination encoding ID cstring, – source string (null terminated C string) internal, – destination (fill with a null terminated C string) integer, – source string length boolean – if true, dont throw an error if conversion fails ) RETURNS integer;

The return value is the number of source bytes that were successfully converted. If the last argument is false, the function must throw an error on invalid input, and the return value is always equal to the source string length.

NOTES

Neither the source nor the destination encoding can be SQL_ASCII, as the servers behavior for cases involving the SQL_ASCII “encoding” is hard-wired.

Use DROP CONVERSION to remove user-defined conversions.

The privileges required to create a conversion might be changed in a future release.

EXAMPLES

To create a conversion from encoding UTF8 to LATIN1 using myfunc:

CREATE CONVERSION myconv FOR UTF8 TO LATIN1 FROM myfunc;

COMPATIBILITY

CREATE CONVERSION is a PostgreSQL extension. There is no CREATE CONVERSION statement in the SQL standard, but a CREATE TRANSLATION statement that is very similar in purpose and syntax.

SEE ALSO

ALTER CONVERSION (ALTER_CONVERSION(7)), CREATE FUNCTION (CREATE_FUNCTION(7)), DROP CONVERSION (DROP_CONVERSION(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

389 - Linux cli command bootparam

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command bootparam and provides detailed information about the command bootparam, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the bootparam.

NAME 🖥️ bootparam 🖥️

introduction to boot time parameters of the Linux kernel

DESCRIPTION

The Linux kernel accepts certain ‘command-line options’ or ‘boot time parameters’ at the moment it is started. In general, this is used to supply the kernel with information about hardware parameters that the kernel would not be able to determine on its own, or to avoid/override the values that the kernel would otherwise detect.

When the kernel is booted directly by the BIOS, you have no opportunity to specify any parameters. So, in order to take advantage of this possibility you have to use a boot loader that is able to pass parameters, such as GRUB.

The argument list

The kernel command line is parsed into a list of strings (boot arguments) separated by spaces. Most of the boot arguments have the form:

name[=value_1][,value_2]...[,value_10]

where ’name’ is a unique keyword that is used to identify what part of the kernel the associated values (if any) are to be given to. Note the limit of 10 is real, as the present code handles only 10 comma separated parameters per keyword. (However, you can reuse the same keyword with up to an additional 10 parameters in unusually complicated situations, assuming the setup function supports it.)

Most of the sorting is coded in the kernel source file init/main.c. First, the kernel checks to see if the argument is any of the special arguments ‘root=’, ’nfsroot=’, ’nfsaddrs=’, ‘ro’, ‘rw’, ‘debug’, or ‘init’. The meaning of these special arguments is described below.

Then it walks a list of setup functions to see if the specified argument string (such as ‘foo’) has been associated with a setup function (‘foo_setup()’) for a particular device or part of the kernel. If you passed the kernel the line foo=3,4,5,6 then the kernel would search the bootsetups array to see if ‘foo’ was registered. If it was, then it would call the setup function associated with ‘foo’ (foo_setup()) and hand it the arguments 3, 4, 5, and 6 as given on the kernel command line.

Anything of the form ‘foo=bar’ that is not accepted as a setup function as described above is then interpreted as an environment variable to be set. A (useless?) example would be to use ‘TERM=vt100’ as a boot argument.

Any remaining arguments that were not picked up by the kernel and were not interpreted as environment variables are then passed onto PID 1, which is usually the init(1) program. The most common argument that is passed to the init process is the word ‘single’ which instructs it to boot the computer in single user mode, and not launch all the usual daemons. Check the manual page for the version of init(1) installed on your system to see what arguments it accepts.

General non-device-specific boot arguments

‘init=…’
This sets the initial command to be executed by the kernel. If this is not set, or cannot be found, the kernel will try /sbin/init, then /etc/init, then /bin/init, then /bin/sh and panic if all of this fails.

’nfsaddrs=…’
This sets the NFS boot address to the given string. This boot address is used in case of a net boot.

’nfsroot=…’
This sets the NFS root name to the given string. If this string does not begin with ‘/’ or ‘,’ or a digit, then it is prefixed by ‘/tftpboot/’. This root name is used in case of a net boot.

‘root=…’
This argument tells the kernel what device is to be used as the root filesystem while booting. The default of this setting is determined at compile time, and usually is the value of the root device of the system that the kernel was built on. To override this value, and select the second floppy drive as the root device, one would use ‘root=/dev/fd1’.

The root device can be specified symbolically or numerically. A symbolic specification has the form /dev/XXYN, where XX designates the device type (e.g., ‘hd’ for ST-506 compatible hard disk, with Y in ‘a’–’d’; ‘sd’ for SCSI compatible disk, with Y in ‘a’–’e’), Y the driver letter or number, and N the number (in decimal) of the partition on this device.

Note that this has nothing to do with the designation of these devices on your filesystem. The ‘/dev/’ part is purely conventional.

The more awkward and less portable numeric specification of the above possible root devices in major/minor format is also accepted. (For example, /dev/sda3 is major 8, minor 3, so you could use ‘root=0x803’ as an alternative.)

‘rootdelay=’
This parameter sets the delay (in seconds) to pause before attempting to mount the root filesystem.

‘rootflags=…’
This parameter sets the mount option string for the root filesystem (see also fstab(5)).

‘rootfstype=…’
The ‘rootfstype’ option tells the kernel to mount the root filesystem as if it where of the type specified. This can be useful (for example) to mount an ext3 filesystem as ext2 and then remove the journal in the root filesystem, in fact reverting its format from ext3 to ext2 without the need to boot the box from alternate media.

‘ro’ and ‘rw’
The ‘ro’ option tells the kernel to mount the root filesystem as ‘read-only’ so that filesystem consistency check programs (fsck) can do their work on a quiescent filesystem. No processes can write to files on the filesystem in question until it is ‘remounted’ as read/write capable, for example, by ‘mount -w -n -o remount /’. (See also mount(8).)

The ‘rw’ option tells the kernel to mount the root filesystem read/write. This is the default.

‘resume=…’
This tells the kernel the location of the suspend-to-disk data that you want the machine to resume from after hibernation. Usually, it is the same as your swap partition or file. Example:

resume=/dev/hda2

‘reserve=…’
This is used to protect I/O port regions from probes. The form of the command is:

reserve=iobase,extent[,iobase,extent]...

In some machines it may be necessary to prevent device drivers from checking for devices (auto-probing) in a specific region. This may be because of hardware that reacts badly to the probing, or hardware that would be mistakenly identified, or merely hardware you don’t want the kernel to initialize.

The reserve boot-time argument specifies an I/O port region that shouldn’t be probed. A device driver will not probe a reserved region, unless another boot argument explicitly specifies that it do so.

For example, the boot line

reserve=0x300,32  blah=0x300

keeps all device drivers except the driver for ‘blah’ from probing 0x300-0x31f.

‘panic=N’
By default, the kernel will not reboot after a panic, but this option will cause a kernel reboot after N seconds (if N is greater than zero). This panic timeout can also be set by

echo N > /proc/sys/kernel/panic

‘reboot=[warm|cold][,[bios|hard]]’
Since Linux 2.0.22, a reboot is by default a cold reboot. One asks for the old default with ‘reboot=warm’. (A cold reboot may be required to reset certain hardware, but might destroy not yet written data in a disk cache. A warm reboot may be faster.) By default, a reboot is hard, by asking the keyboard controller to pulse the reset line low, but there is at least one type of motherboard where that doesn’t work. The option ‘reboot=bios’ will instead jump through the BIOS.

’nosmp’ and ‘maxcpus=N’
(Only when __SMP__ is defined.) A command-line option of ’nosmp’ or ‘maxcpus=0’ will disable SMP activation entirely; an option ‘maxcpus=N’ limits the maximum number of CPUs activated in SMP mode to N.

Boot arguments for use by kernel developers

‘debug’
Kernel messages are handed off to a daemon (e.g., klogd(8) or similar) so that they may be logged to disk. Messages with a priority above console_loglevel are also printed on the console. (For a discussion of log levels, see syslog(2).) By default, console_loglevel is set to log messages at levels higher than KERN_DEBUG. This boot argument will cause the kernel to also print messages logged at level KERN_DEBUG. The console loglevel can also be set on a booted system via the /proc/sys/kernel/printk file (described in syslog(2)), the syslog(2) SYSLOG_ACTION_CONSOLE_LEVEL operation, or dmesg(8).

‘profile=N’
It is possible to enable a kernel profiling function, if one wishes to find out where the kernel is spending its CPU cycles. Profiling is enabled by setting the variable prof_shift to a nonzero value. This is done either by specifying CONFIG_PROFILE at compile time, or by giving the ‘profile=’ option. Now the value that prof_shift gets will be N, when given, or CONFIG_PROFILE_SHIFT, when that is given, or 2, the default. The significance of this variable is that it gives the granularity of the profiling: each clock tick, if the system was executing kernel code, a counter is incremented:

profile[address >> prof_shift]++;

The raw profiling information can be read from /proc/profile. Probably you’ll want to use a tool such as readprofile.c to digest it. Writing to /proc/profile will clear the counters.

Boot arguments for ramdisk use

(Only if the kernel was compiled with CONFIG_BLK_DEV_RAM.) In general it is a bad idea to use a ramdisk under Linux—the system will use available memory more efficiently itself. But while booting, it is often useful to load the floppy contents into a ramdisk. One might also have a system in which first some modules (for filesystem or hardware) must be loaded before the main disk can be accessed.

In Linux 1.3.48, ramdisk handling was changed drastically. Earlier, the memory was allocated statically, and there was a ‘ramdisk=N’ parameter to tell its size. (This could also be set in the kernel image at compile time.) These days ram disks use the buffer cache, and grow dynamically. For a lot of information on the current ramdisk setup, see the kernel source file Documentation/blockdev/ramdisk.txt (Documentation/ramdisk.txt in older kernels).

There are four parameters, two boolean and two integral.

’load_ramdisk=N’
If N=1, do load a ramdisk. If N=0, do not load a ramdisk. (This is the default.)

‘prompt_ramdisk=N’
If N=1, do prompt for insertion of the floppy. (This is the default.) If N=0, do not prompt. (Thus, this parameter is never needed.)

‘ramdisk_size=N’ or (obsolete) ‘ramdisk=N’
Set the maximal size of the ramdisk(s) to N kB. The default is 4096 (4 MB).

‘ramdisk_start=N’
Sets the starting block number (the offset on the floppy where the ramdisk starts) to N. This is needed in case the ramdisk follows a kernel image.

’noinitrd’
(Only if the kernel was compiled with CONFIG_BLK_DEV_RAM and CONFIG_BLK_DEV_INITRD.) These days it is possible to compile the kernel to use initrd. When this feature is enabled, the boot process will load the kernel and an initial ramdisk; then the kernel converts initrd into a “normal” ramdisk, which is mounted read-write as root device; then /linuxrc is executed; afterward the “real” root filesystem is mounted, and the initrd filesystem is moved over to /initrd; finally the usual boot sequence (e.g., invocation of /sbin/init) is performed.

For a detailed description of the initrd feature, see the kernel source file Documentation/admin-guide/initrd.rst (or Documentation/initrd.txt before Linux 4.10).

The ’noinitrd’ option tells the kernel that although it was compiled for operation with initrd, it should not go through the above steps, but leave the initrd data under /dev/initrd. (This device can be used only once: the data is freed as soon as the last process that used it has closed /dev/initrd.)

Boot arguments for SCSI devices

General notation for this section:

iobase – the first I/O port that the SCSI host occupies. These are specified in hexadecimal notation, and usually lie in the range from 0x200 to 0x3ff.

irq – the hardware interrupt that the card is configured to use. Valid values will be dependent on the card in question, but will usually be 5, 7, 9, 10, 11, 12, and 15. The other values are usually used for common peripherals like IDE hard disks, floppies, serial ports, and so on.

scsi-id – the ID that the host adapter uses to identify itself on the SCSI bus. Only some host adapters allow you to change this value, as most have it permanently specified internally. The usual default value is 7, but the Seagate and Future Domain TMC-950 boards use 6.

parity – whether the SCSI host adapter expects the attached devices to supply a parity value with all information exchanges. Specifying a one indicates parity checking is enabled, and a zero disables parity checking. Again, not all adapters will support selection of parity behavior as a boot argument.

‘max_scsi_luns=…’
A SCSI device can have a number of ‘subdevices’ contained within itself. The most common example is one of the new SCSI CD-ROMs that handle more than one disk at a time. Each CD is addressed as a ‘Logical Unit Number’ (LUN) of that particular device. But most devices, such as hard disks, tape drives, and such are only one device, and will be assigned to LUN zero.

Some poorly designed SCSI devices cannot handle being probed for LUNs not equal to zero. Therefore, if the compile-time flag CONFIG_SCSI_MULTI_LUN is not set, newer kernels will by default probe only LUN zero.

To specify the number of probed LUNs at boot, one enters ‘max_scsi_luns=n’ as a boot arg, where n is a number between one and eight. To avoid problems as described above, one would use n=1 to avoid upsetting such broken devices.

SCSI tape configuration
Some boot time configuration of the SCSI tape driver can be achieved by using the following:

st=buf_size[,write_threshold[,max_bufs]]

The first two numbers are specified in units of kB. The default buf_size is 32k B, and the maximum size that can be specified is a ridiculous 16384 kB. The write_threshold is the value at which the buffer is committed to tape, with a default value of 30 kB. The maximum number of buffers varies with the number of drives detected, and has a default of two. An example usage would be:

st=32,30,2

Full details can be found in the file Documentation/scsi/st.txt (or drivers/scsi/README.st for older kernels) in the Linux kernel source.

Hard disks

IDE Disk/CD-ROM Driver Parameters
The IDE driver accepts a number of parameters, which range from disk geometry specifications, to support for broken controller chips. Drive-specific options are specified by using ‘hdX=’ with X in ‘a’–‘h’.

Non-drive-specific options are specified with the prefix ‘hd=’. Note that using a drive-specific prefix for a non-drive-specific option will still work, and the option will just be applied as expected.

Also note that ‘hd=’ can be used to refer to the next unspecified drive in the (a, …, h) sequence. For the following discussions, the ‘hd=’ option will be cited for brevity. See the file Documentation/ide/ide.txt (or Documentation/ide.txt in older kernels, or drivers/block/README.ide in ancient kernels) in the Linux kernel source for more details.

The ‘hd=cyls,heads,sects[,wpcom[,irq]]’ options
These options are used to specify the physical geometry of the disk. Only the first three values are required. The cylinder/head/sectors values will be those used by fdisk. The write precompensation value is ignored for IDE disks. The IRQ value specified will be the IRQ used for the interface that the drive resides on, and is not really a drive-specific parameter.

The ‘hd=serialize’ option
The dual IDE interface CMD-640 chip is broken as designed such that when drives on the secondary interface are used at the same time as drives on the primary interface, it will corrupt your data. Using this option tells the driver to make sure that both interfaces are never used at the same time.

The ‘hd=noprobe’ option
Do not probe for this drive. For example,

hdb=noprobe hdb=1166,7,17

would disable the probe, but still specify the drive geometry so that it would be registered as a valid block device, and hence usable.

The ‘hd=nowerr’ option
Some drives apparently have the WRERR_STAT bit stuck on permanently. This enables a work-around for these broken devices.

The ‘hd=cdrom’ option
This tells the IDE driver that there is an ATAPI compatible CD-ROM attached in place of a normal IDE hard disk. In most cases the CD-ROM is identified automatically, but if it isn’t then this may help.

Standard ST-506 Disk Driver Options (‘hd=’)
The standard disk driver can accept geometry arguments for the disks similar to the IDE driver. Note however that it expects only three values (C/H/S); any more or any less and it will silently ignore you. Also, it accepts only ‘hd=’ as an argument, that is, ‘hda=’ and so on are not valid here. The format is as follows:

hd=cyls,heads,sects

If there are two disks installed, the above is repeated with the geometry parameters of the second disk.

Ethernet devices

Different drivers make use of different parameters, but they all at least share having an IRQ, an I/O port base value, and a name. In its most generic form, it looks something like this:

ether=irq,iobase[,param_1[,...param_8]],name

The first nonnumeric argument is taken as the name. The param_n values (if applicable) usually have different meanings for each different card/driver. Typical param_n values are used to specify things like shared memory address, interface selection, DMA channel and the like.

The most common use of this parameter is to force probing for a second ethercard, as the default is to probe only for one. This can be accomplished with a simple:

ether=0,0,eth1

Note that the values of zero for the IRQ and I/O base in the above example tell the driver(s) to autoprobe.

The Ethernet-HowTo has extensive documentation on using multiple cards and on the card/driver-specific implementation of the param_n values where used. Interested readers should refer to the section in that document on their particular card.

The floppy disk driver

There are many floppy driver options, and they are all listed in Documentation/blockdev/floppy.txt (or Documentation/floppy.txt in older kernels, or drivers/block/README.fd for ancient kernels) in the Linux kernel source. See that file for the details.

The sound driver

The sound driver can also accept boot arguments to override the compiled-in values. This is not recommended, as it is rather complex. It is described in the Linux kernel source file Documentation/sound/oss/README.OSS (drivers/sound/Readme.linux in older kernel versions). It accepts a boot argument of the form:

sound=device1[,device2[,device3...[,device10]]]

where each deviceN value is of the following format 0xTaaaId and the bytes are used as follows:

T - device type: 1=FM, 2=SB, 3=PAS, 4=GUS, 5=MPU401, 6=SB16, 7=SB16-MPU401

aaa - I/O address in hex.

I - interrupt line in hex (i.e., 10=a, 11=b, …)

d - DMA channel.

As you can see, it gets pretty messy, and you are better off to compile in your own personal values as recommended. Using a boot argument of ‘sound=0’ will disable the sound driver entirely.

The line printer driver

’lp=’

Syntax:

lp=0
lp=auto
lp=reset
lp=port[,port...]

You can tell the printer driver what ports to use and what ports not to use. The latter comes in handy if you don’t want the printer driver to claim all available parallel ports, so that other drivers (e.g., PLIP, PPA) can use them instead.

The format of the argument is multiple port names. For example, lp=none,parport0 would use the first parallel port for lp1, and disable lp0. To disable the printer driver entirely, one can use lp=0.

SEE ALSO

klogd(8), mount(8)

For up-to-date information, see the kernel source file Documentation/admin-guide/kernel-parameters.txt.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

390 - Linux cli command inode

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command inode and provides detailed information about the command inode, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the inode.

NAME 🖥️ inode 🖥️

file inode information

DESCRIPTION

Each file has an inode containing metadata about the file. An application can retrieve this metadata using stat(2) (or related calls), which returns a stat structure, or statx(2), which returns a statx structure.

The following is a list of the information typically found in, or associated with, the file inode, with the names of the corresponding structure fields returned by stat(2) and statx(2):

Device where inode resides
stat.st_dev; statx.stx_dev_minor and statx.stx_dev_major

Each inode (as well as the associated file) resides in a filesystem that is hosted on a device. That device is identified by the combination of its major ID (which identifies the general class of device) and minor ID (which identifies a specific instance in the general class).

Inode number
stat.st_ino; statx.stx_ino

Each file in a filesystem has a unique inode number. Inode numbers are guaranteed to be unique only within a filesystem (i.e., the same inode numbers may be used by different filesystems, which is the reason that hard links may not cross filesystem boundaries). This field contains the file’s inode number.

File type and mode
stat.st_mode; statx.stx_mode

See the discussion of file type and mode, below.

Link count
stat.st_nlink; statx.stx_nlink

This field contains the number of hard links to the file. Additional links to an existing file are created using link(2).

User ID
stat.st_uid; statx.stx_uid

This field records the user ID of the owner of the file. For newly created files, the file user ID is the effective user ID of the creating process. The user ID of a file can be changed using chown(2).

Group ID
stat.st_gid; statx.stx_gid

The inode records the ID of the group owner of the file. For newly created files, the file group ID is either the group ID of the parent directory or the effective group ID of the creating process, depending on whether or not the set-group-ID bit is set on the parent directory (see below). The group ID of a file can be changed using chown(2).

Device represented by this inode
stat.st_rdev; statx.stx_rdev_minor and statx.stx_rdev_major

If this file (inode) represents a device, then the inode records the major and minor ID of that device.

File size
stat.st_size; statx.stx_size

This field gives the size of the file (if it is a regular file or a symbolic link) in bytes. The size of a symbolic link is the length of the pathname it contains, without a terminating null byte.

Preferred block size for I/O
stat.st_blksize; statx.stx_blksize

This field gives the “preferred” blocksize for efficient filesystem I/O. (Writing to a file in smaller chunks may cause an inefficient read-modify-rewrite.)

Number of blocks allocated to the file
stat.st_blocks; statx.stx_blocks

This field indicates the number of blocks allocated to the file, 512-byte units, (This may be smaller than st_size/512 when the file has holes.)

The POSIX.1 standard notes that the unit for the st_blocks member of the stat structure is not defined by the standard. On many implementations it is 512 bytes; on a few systems, a different unit is used, such as 1024. Furthermore, the unit may differ on a per-filesystem basis.

Last access timestamp (atime)
stat.st_atime; statx.stx_atime

This is the file’s last access timestamp. It is changed by file accesses, for example, by execve(2), mknod(2), pipe(2), utime(2), and read(2) (of more than zero bytes). Other interfaces, such as mmap(2), may or may not update the atime timestamp

Some filesystem types allow mounting in such a way that file and/or directory accesses do not cause an update of the atime timestamp. (See noatime, nodiratime, and relatime in mount(8), and related information in mount(2).) In addition, the atime timestamp is not updated if a file is opened with the O_NOATIME flag; see open(2).

File creation (birth) timestamp (btime)
(not returned in the stat structure); statx.stx_btime

The file’s creation timestamp. This is set on file creation and not changed subsequently.

The btime timestamp was not historically present on UNIX systems and is not currently supported by most Linux filesystems.

Last modification timestamp (mtime)
stat.st_mtime; statx.stx_mtime

This is the file’s last modification timestamp. It is changed by file modifications, for example, by mknod(2), truncate(2), utime(2), and write(2) (of more than zero bytes). Moreover, the mtime timestamp of a directory is changed by the creation or deletion of files in that directory. The mtime timestamp is not changed for changes in owner, group, hard link count, or mode.

Last status change timestamp (ctime)
stat.st_ctime; statx.stx_ctime

This is the file’s last status change timestamp. It is changed by writing or by setting inode information (i.e., owner, group, link count, mode, etc.).

The timestamp fields report time measured with a zero point at the Epoch, 1970-01-01 00:00:00 +0000, UTC (see time(7)).

Nanosecond timestamps are supported on XFS, JFS, Btrfs, and ext4 (since Linux 2.6.23). Nanosecond timestamps are not supported in ext2, ext3, and Reiserfs. In order to return timestamps with nanosecond precision, the timestamp fields in the stat and statx structures are defined as structures that include a nanosecond component. See stat(2) and statx(2) for details. On filesystems that do not support subsecond timestamps, the nanosecond fields in the stat and statx structures are returned with the value 0.

The file type and mode

The stat.st_mode field (for statx(2), the statx.stx_mode field) contains the file type and mode.

POSIX refers to the stat.st_mode bits corresponding to the mask S_IFMT (see below) as the file type, the 12 bits corresponding to the mask 07777 as the file mode bits and the least significant 9 bits (0777) as the file permission bits.

The following mask values are defined for the file type:

S_IFMT0170000bit mask for the file type bit field
S_IFSOCK0140000socket
S_IFLNK0120000symbolic link
S_IFREG0100000regular file
S_IFBLK0060000block device
S_IFDIR0040000directory
S_IFCHR0020000character device
S_IFIFO0010000FIFO

Thus, to test for a regular file (for example), one could write:

stat(pathname, &sb);
if ((sb.st_mode & S_IFMT) == S_IFREG) {
    /* Handle regular file */
}

Because tests of the above form are common, additional macros are defined by POSIX to allow the test of the file type in st_mode to be written more concisely:

S_ISREG(m)
is it a regular file?

S_ISDIR(m)
directory?

S_ISCHR(m)
character device?

S_ISBLK(m)
block device?

S_ISFIFO(m)
FIFO (named pipe)?

S_ISLNK(m)
symbolic link? (Not in POSIX.1-1996.)

S_ISSOCK(m)
socket? (Not in POSIX.1-1996.)

The preceding code snippet could thus be rewritten as:

stat(pathname, &sb);
if (S_ISREG(sb.st_mode)) {
    /* Handle regular file */
}

The definitions of most of the above file type test macros are provided if any of the following feature test macros is defined: _BSD_SOURCE (in glibc 2.19 and earlier), _SVID_SOURCE (in glibc 2.19 and earlier), or _DEFAULT_SOURCE (in glibc 2.20 and later). In addition, definitions of all of the above macros except S_IFSOCK and S_ISSOCK() are provided if _XOPEN_SOURCE is defined.

The definition of S_IFSOCK can also be exposed either by defining _XOPEN_SOURCE with a value of 500 or greater or (since glibc 2.24) by defining both _XOPEN_SOURCE and _XOPEN_SOURCE_EXTENDED.

The definition of S_ISSOCK() is exposed if any of the following feature test macros is defined: _BSD_SOURCE (in glibc 2.19 and earlier), _DEFAULT_SOURCE (in glibc 2.20 and later), _XOPEN_SOURCE with a value of 500 or greater, _POSIX_C_SOURCE with a value of 200112L or greater, or (since glibc 2.24) by defining both _XOPEN_SOURCE and _XOPEN_SOURCE_EXTENDED.

The following mask values are defined for the file mode component of the st_mode field:

S_ISUID04000set-user-ID bit (see execve(2))
S_ISGID02000set-group-ID bit (see below)
S_ISVTX01000sticky bit (see below)
S_IRWXU00700owner has read, write, and execute permission
S_IRUSR00400owner has read permission
S_IWUSR00200owner has write permission
S_IXUSR00100owner has execute permission
S_IRWXG00070group has read, write, and execute permission
S_IRGRP00040group has read permission
S_IWGRP00020group has write permission
S_IXGRP00010group has execute permission
S_IRWXO00007others (not in group) have read, write, and execute permission
S_IROTH00004others have read permission
S_IWOTH00002others have write permission
S_IXOTH00001others have execute permission

The set-group-ID bit (S_ISGID) has several special uses. For a directory, it indicates that BSD semantics are to be used for that directory: files created there inherit their group ID from the directory, not from the effective group ID of the creating process, and directories created there will also get the S_ISGID bit set. For an executable file, the set-group-ID bit causes the effective group ID of a process that executes the file to change as described in execve(2). For a file that does not have the group execution bit (S_IXGRP) set, the set-group-ID bit indicates mandatory file/record locking.

The sticky bit (S_ISVTX) on a directory means that a file in that directory can be renamed or deleted only by the owner of the file, by the owner of the directory, and by a privileged process.

STANDARDS

POSIX.1-2008.

HISTORY

POSIX.1-2001.

POSIX.1-1990 did not describe the S_IFMT, S_IFSOCK, S_IFLNK, S_IFREG, S_IFBLK, S_IFDIR, S_IFCHR, S_IFIFO, and S_ISVTX constants, but instead specified the use of the macros S_ISDIR() and so on.

The S_ISLNK() and S_ISSOCK() macros were not in POSIX.1-1996; the former is from SVID 4, the latter from SUSv2.

UNIX V7 (and later systems) had S_IREAD, S_IWRITE, S_IEXEC, and where POSIX prescribes the synonyms S_IRUSR, S_IWUSR, and S_IXUSR.

NOTES

For pseudofiles that are autogenerated by the kernel, the file size (stat.st_size; statx.stx_size) reported by the kernel is not accurate. For example, the value 0 is returned for many files under the /proc directory, while various files under /sys report a size of 4096 bytes, even though the file content is smaller. For such files, one should simply try to read as many bytes as possible (and append ‘�’ to the returned buffer if it is to be interpreted as a string).

SEE ALSO

stat(1), stat(2), statx(2), symlink(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

391 - Linux cli command TABLE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command TABLE and provides detailed information about the command TABLE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the TABLE.
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

392 - Linux cli command CREATE_TEXT_SEARCH_DICTIONARY

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_TEXT_SEARCH_DICTIONARY and provides detailed information about the command CREATE_TEXT_SEARCH_DICTIONARY, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_TEXT_SEARCH_DICTIONARY.

NAME 🖥️ CREATE_TEXT_SEARCH_DICTIONARY 🖥️

define a new text search dictionary

SYNOPSIS

CREATE TEXT SEARCH DICTIONARY name (
    TEMPLATE = template
    [, option = value [, ... ]]
)

DESCRIPTION

CREATE TEXT SEARCH DICTIONARY creates a new text search dictionary. A text search dictionary specifies a way of recognizing interesting or uninteresting words for searching. A dictionary depends on a text search template, which specifies the functions that actually perform the work. Typically the dictionary provides some options that control the detailed behavior of the templates functions.

If a schema name is given then the text search dictionary is created in the specified schema. Otherwise it is created in the current schema.

The user who defines a text search dictionary becomes its owner.

Refer to Chapter 12 for further information.

PARAMETERS

name

The name of the text search dictionary to be created. The name can be schema-qualified.

template

The name of the text search template that will define the basic behavior of this dictionary.

option

The name of a template-specific option to be set for this dictionary.

value

The value to use for a template-specific option. If the value is not a simple identifier or number, it must be quoted (but you can always quote it, if you wish).

The options can appear in any order.

EXAMPLES

The following example command creates a Snowball-based dictionary with a nonstandard list of stop words.

CREATE TEXT SEARCH DICTIONARY my_russian ( template = snowball, language = russian, stopwords = myrussian );

COMPATIBILITY

There is no CREATE TEXT SEARCH DICTIONARY statement in the SQL standard.

SEE ALSO

ALTER TEXT SEARCH DICTIONARY (ALTER_TEXT_SEARCH_DICTIONARY(7)), DROP TEXT SEARCH DICTIONARY (DROP_TEXT_SEARCH_DICTIONARY(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

393 - Linux cli command CREATE_COLLATION

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_COLLATION and provides detailed information about the command CREATE_COLLATION, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_COLLATION.

NAME 🖥️ CREATE_COLLATION 🖥️

define a new collation

SYNOPSIS

CREATE COLLATION [ IF NOT EXISTS ] name (
    [ LOCALE = locale, ]
    [ LC_COLLATE = lc_collate, ]
    [ LC_CTYPE = lc_ctype, ]
    [ PROVIDER = provider, ]
    [ DETERMINISTIC = boolean, ]
    [ RULES = rules, ]
    [ VERSION = version ]
)
CREATE COLLATION [ IF NOT EXISTS ] name FROM existing_collation

DESCRIPTION

CREATE COLLATION defines a new collation using the specified operating system locale settings, or by copying an existing collation.

To be able to create a collation, you must have CREATE privilege on the destination schema.

PARAMETERS

IF NOT EXISTS

Do not throw an error if a collation with the same name already exists. A notice is issued in this case. Note that there is no guarantee that the existing collation is anything like the one that would have been created.

name

The name of the collation. The collation name can be schema-qualified. If it is not, the collation is defined in the current schema. The collation name must be unique within that schema. (The system catalogs can contain collations with the same name for other encodings, but these are ignored if the database encoding does not match.)

locale

The locale name for this collation. See Section 24.2.2.3.1 and Section 24.2.2.3.2 for details.

If provider is libc, this is a shortcut for setting LC_COLLATE and LC_CTYPE at once. If you specify locale, you cannot specify either of those parameters.

lc_collate

If provider is libc, use the specified operating system locale for the LC_COLLATE locale category.

lc_ctype

If provider is libc, use the specified operating system locale for the LC_CTYPE locale category.

provider

Specifies the provider to use for locale services associated with this collation. Possible values are icu (if the server was built with ICU support) or libc. libc is the default. See Section 24.1.4 for details.

DETERMINISTIC

Specifies whether the collation should use deterministic comparisons. The default is true. A deterministic comparison considers strings that are not byte-wise equal to be unequal even if they are considered logically equal by the comparison. PostgreSQL breaks ties using a byte-wise comparison. Comparison that is not deterministic can make the collation be, say, case- or accent-insensitive. For that, you need to choose an appropriate LOCALE setting and set the collation to not deterministic here.

Nondeterministic collations are only supported with the ICU provider.

rules

Specifies additional collation rules to customize the behavior of the collation. This is supported for ICU only. See Section 24.2.3.4 for details.

version

Specifies the version string to store with the collation. Normally, this should be omitted, which will cause the version to be computed from the actual version of the collation as provided by the operating system. This option is intended to be used by pg_upgrade for copying the version from an existing installation.

See also ALTER COLLATION (ALTER_COLLATION(7)) for how to handle collation version mismatches.

existing_collation

The name of an existing collation to copy. The new collation will have the same properties as the existing one, but it will be an independent object.

NOTES

CREATE COLLATION takes a SHARE ROW EXCLUSIVE lock, which is self-conflicting, on the pg_collation system catalog, so only one CREATE COLLATION command can run at a time.

Use DROP COLLATION to remove user-defined collations.

See Section 24.2.2.3 for more information on how to create collations.

When using the libc collation provider, the locale must be applicable to the current database encoding. See CREATE DATABASE (CREATE_DATABASE(7)) for the precise rules.

EXAMPLES

To create a collation from the operating system locale fr_FR.utf8 (assuming the current database encoding is UTF8):

CREATE COLLATION french (locale = fr_FR.utf8);

To create a collation using the ICU provider using German phone book sort order:

CREATE COLLATION german_phonebook (provider = icu, locale = de-u-co-phonebk);

To create a collation using the ICU provider, based on the root ICU locale, with custom rules:

CREATE COLLATION custom (provider = icu, locale = und, rules = &V « w «< W);

See Section 24.2.3.4 for further details and examples on the rules syntax.

To create a collation from an existing collation:

CREATE COLLATION german FROM “de_DE”;

This can be convenient to be able to use operating-system-independent collation names in applications.

COMPATIBILITY

There is a CREATE COLLATION statement in the SQL standard, but it is limited to copying an existing collation. The syntax to create a new collation is a PostgreSQL extension.

SEE ALSO

ALTER COLLATION (ALTER_COLLATION(7)), DROP COLLATION (DROP_COLLATION(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

394 - Linux cli command iso_8859_9

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso_8859_9 and provides detailed information about the command iso_8859_9, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso_8859_9.

NAME 🖥️ iso_8859_9 🖥️

9 - ISO/IEC 8859-9 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-9 encodes the characters used in Turkish.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-9 characters

The following table displays the characters in ISO/IEC 8859-9 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-9 is also known as Latin-5.

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

395 - Linux cli command DROP_OWNED

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_OWNED and provides detailed information about the command DROP_OWNED, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_OWNED.

NAME 🖥️ DROP_OWNED 🖥️

remove database objects owned by a database role

SYNOPSIS

DROP OWNED BY { name | CURRENT_ROLE | CURRENT_USER | SESSION_USER } [, ...] [ CASCADE | RESTRICT ]

DESCRIPTION

DROP OWNED drops all the objects within the current database that are owned by one of the specified roles. Any privileges granted to the given roles on objects in the current database or on shared objects (databases, tablespaces, configuration parameters) will also be revoked.

PARAMETERS

name

The name of a role whose objects will be dropped, and whose privileges will be revoked.

CASCADE

Automatically drop objects that depend on the affected objects, and in turn all objects that depend on those objects (see Section 5.14).

RESTRICT

Refuse to drop the objects owned by a role if any other database objects depend on one of the affected objects. This is the default.

NOTES

DROP OWNED is often used to prepare for the removal of one or more roles. Because DROP OWNED only affects the objects in the current database, it is usually necessary to execute this command in each database that contains objects owned by a role that is to be removed.

Using the CASCADE option might make the command recurse to objects owned by other users.

The REASSIGN OWNED command is an alternative that reassigns the ownership of all the database objects owned by one or more roles. However, REASSIGN OWNED does not deal with privileges for other objects.

Databases and tablespaces owned by the role(s) will not be removed.

See Section 22.4 for more discussion.

COMPATIBILITY

The DROP OWNED command is a PostgreSQL extension.

SEE ALSO

REASSIGN OWNED (REASSIGN_OWNED(7)), DROP ROLE (DROP_ROLE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

396 - Linux cli command kernel-command-line

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command kernel-command-line and provides detailed information about the command kernel-command-line, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the kernel-command-line.

NAME 🖥️ kernel-command-line 🖥️

command-line - Kernel command line parameters

SYNOPSIS

/proc/cmdline

DESCRIPTION

The kernel, the programs running in the initrd and in the host system may be configured at boot via kernel command line arguments. In addition, various systemd tools look at the EFI variable “SystemdOptions” (if available). Both sources are combined, but the kernel command line has higher priority. Please note that the EFI variable is only used by systemd tools, and is ignored by the kernel and other user space tools, so it is not a replacement for the kernel command line.

For command line parameters understood by the kernel, please see kernel-parameters.html[1] and bootparam(7).

For command line parameters understood by the initrd, see the documentation of the specific initrd implementation of your installation.

CORE OS COMMAND LINE ARGUMENTS

systemd.unit=, rd.systemd.unit=, systemd.dump_core, systemd.crash_chvt, systemd.crash_shell, systemd.crash_action=, systemd.confirm_spawn, systemd.service_watchdogs, systemd.show_status, systemd.status_unit_format=, systemd.log_target=, systemd.log_level=, systemd.log_location=, systemd.log_color, systemd.log_ratelimit_kmsg, systemd.default_standard_output=, systemd.default_standard_error=, systemd.setenv=, systemd.machine_id=, systemd.set_credential=, systemd.set_credential_binary=, systemd.import_credentials=, systemd.reload_limit_interval_sec=, systemd.reload_limit_burst=

Parameters understood by the system and service manager to control system behavior. For details, see systemd(1).

Added in version 186.

systemd.mask=, systemd.wants=, systemd.debug_shell, systemd.default_debug_tty=

Additional parameters understood by systemd-debug-generator(8), to mask or start specific units at boot, or invoke a debug shell on tty9.

Added in version 215.

systemd.run=, systemd.run_success_action=, systemd.run_failure_action=

Additional parameters understood by systemd-run-generator(8), to run a command line specified on the kernel command line as system service after booting up.

Added in version 240.

systemd.early_core_pattern=

During early boot, the generation of core dump files is disabled until a core dump handler (if any) takes over. This parameter allows specifying an absolute path where core dump files should be stored until a handler is installed. The path should be absolute and may contain specifiers, see core(5) for details.

Added in version 240.

systemd.restore_state=

This parameter is understood by several system tools to control whether or not they should restore system state from the previous boot. For details, see [email protected](8) and systemd-rfkill.service(8).

Added in version 209.

systemd.ssh_auto=, systemd.ssh_listen=

These parameters are interpreted by systemd-ssh-generator(8) and may be used to control SSH sockets the system shall be reachable on.

Added in version 256.

systemd.volatile=

This parameter controls whether the system shall boot up in volatile mode. Takes a boolean argument, or the special value “state”. If false (the default), normal boot mode is selected, the root directory and /var/ are mounted as specified on the kernel command line or /etc/fstab, or otherwise configured. If true, full state-less boot mode is selected. In this case the root directory is mounted as volatile memory file system (“tmpfs”), and only /usr/ is mounted from the file system configured as root device, in read-only mode. This enables fully state-less boots were the vendor-supplied OS is used as shipped, with only default configuration and no stored state in effect, as /etc/ and /var/ (as well as all other resources shipped in the root file system) are reset at boot and lost on shutdown. If this setting is set to “state” the root file system is mounted read-only, however /var/ is mounted as a volatile memory file system (“tmpfs”), so that the system boots up with the normal configuration applied, but all state reset at boot and lost at shutdown. If this setting is set to “overlay” the root file system is set up as “overlayfs” mount combining the read-only root directory with a writable “tmpfs”, so that no modifications are made to disk, but the file system may be modified nonetheless with all changes being lost at reboot. For details, see systemd-volatile-root.service(8) and systemd-fstab-generator(8).

Added in version 233.

quiet

Parameter understood by both the kernel and the system and service manager to control console log verbosity. For details, see systemd(1).

Added in version 186.

debug

Parameter understood by both the kernel and the system and service manager to control console log verbosity. For details, see systemd(1).

Added in version 205.

-b, rd.emergency, emergency, rd.rescue, rescue, single, s, S, 1, 2, 3, 4, 5

Parameters understood by the system and service manager, as compatibility and convenience options. For details, see systemd(1).

Added in version 186.

locale.LANG=, locale.LANGUAGE=, locale.LC_CTYPE=, locale.LC_NUMERIC=, locale.LC_TIME=, locale.LC_COLLATE=, locale.LC_MONETARY=, locale.LC_MESSAGES=, locale.LC_PAPER=, locale.LC_NAME=, locale.LC_ADDRESS=, locale.LC_TELEPHONE=, locale.LC_MEASUREMENT=, locale.LC_IDENTIFICATION=

Parameters understood by the system and service manager to control locale and language settings. For details, see systemd(1).

Added in version 186.

fsck.mode=, fsck.repair=

Parameters understood by the file system checker services. For details, see [email protected](8).

Added in version 186.

quotacheck.mode=

Parameter understood by the file quota checker service. For details, see systemd-quotacheck.service(8).

Added in version 186.

systemd.journald.forward_to_syslog=, systemd.journald.forward_to_kmsg=, systemd.journald.forward_to_console=, systemd.journald.forward_to_wall=

Parameters understood by the journal service. For details, see systemd-journald.service(8).

Added in version 186.

vconsole.keymap=, vconsole.keymap_toggle=, vconsole.font=, vconsole.font_map=, vconsole.font_unimap=

Parameters understood by the virtual console setup logic. For details, see vconsole.conf(5).

Added in version 186.

udev.log_level=, rd.udev.log_level=, udev.children_max=, rd.udev.children_max=, udev.exec_delay=, rd.udev.exec_delay=, udev.event_timeout=, rd.udev.event_timeout=, udev.timeout_signal=, rd.udev.timeout_signal=, udev.blockdev_read_only, rd.udev.blockdev_read_only, net.ifnames=, net.naming_scheme=

Parameters understood by the device event managing daemon. For details, see systemd-udevd.service(8).

Added in version 186.

plymouth.enable=

May be used to disable the Plymouth boot splash. For details, see plymouth(8).

Added in version 186.

luks=, rd.luks=, luks.crypttab=, rd.luks.crypttab=, luks.name=, rd.luks.name=, luks.uuid=, rd.luks.uuid=, luks.options=, rd.luks.options=, luks.key=, rd.luks.key=

Configures the LUKS full-disk encryption logic at boot. For details, see systemd-cryptsetup-generator(8).

Added in version 186.

fstab=, rd.fstab=

Configures the /etc/fstab logic at boot. For details, see systemd-fstab-generator(8).

Added in version 186.

root=, rootfstype=, rootflags=, ro, rw

Configures the root file system and its file system type and mount options, as well as whether it shall be mounted read-only or read-write initially. For details, see systemd-fstab-generator(8).

If root= is not set (or set to “gpt-auto”) the automatic root partition discovery implemented by systemd-gpt-auto-generator(8) will be in effect. In this case rootfstype=, rootflags=, ro, rw will be interpreted by systemd-gpt-auto-generator.

Added in version 215.

mount.usr=, mount.usrfstype=, mount.usrflags=

Configures the /usr file system (if required) and its file system type and mount options. For details, see systemd-fstab-generator(8).

Added in version 235.

veritytab=, rd.veritytab=, roothash=, systemd.verity=, rd.systemd.verity=, systemd.verity_root_data=, systemd.verity_root_hash=, systemd.verity.root_options=, usrhash=, systemd.verity_usr_data=, systemd.verity_usr_hash=, systemd.verity_usr_options=

Configures the integrity protection root hash for the root and /usr file systems, and other related parameters. For details, see systemd-veritysetup-generator(8).

Added in version 233.

systemd.getty_auto=

Configures whether the [email protected] will run. For details, see systemd-getty-generator(8).

Added in version 250.

systemd.gpt_auto=, rd.systemd.gpt_auto=

Configures whether GPT-based partition auto-discovery shall be attempted. For details, see systemd-gpt-auto-generator(8).

Added in version 215.

systemd.image_policy=, rd.systemd.image_policy=

When GPT-based partition auto-discovery is used, configures the image dissection policy string to apply, as per systemd.image-policy(7). For details see systemd-gpt-auto-generator(8).

Added in version 254.

systemd.default_timeout_start_sec=

Overrides the default start job timeout DefaultTimeoutStartSec= at boot. For details, see systemd-system.conf(5).

Added in version 230.

systemd.default_device_timeout_sec=

Overrides the default device timeout DefaultDeviceTimeoutSec= at boot. For details, see systemd-system.conf(5).

Added in version 254.

systemd.watchdog_device=

Overrides the watchdog device path WatchdogDevice=. For details, see systemd-system.conf(5).

Added in version 236.

systemd.watchdog_sec=

Overrides the watchdog timeout settings otherwise configured with RuntimeWatchdog=, RebootWatchdog= and KExecWatchdogSec=. Takes a time value (if no unit is specified, seconds is the implicitly assumed time unit) or the special strings “off” or “default”. For details, see systemd-system.conf(5).

Added in version 250.

systemd.watchdog_pre_sec=

Overrides the watchdog pre-timeout settings otherwise configured with RuntimeWatchdogPreSec=. Takes a time value (if no unit is specified, seconds is the implicitly assumed time unit) or the special strings “off” or “default”. For details, see systemd-system.conf(5).

Added in version 251.

systemd.watchdog_pretimeout_governor=

Overrides the watchdog pre-timeout settings otherwise configured with RuntimeWatchdogPreGovernor=. Takes a string value. For details, see systemd-system.conf(5).

Added in version 251.

systemd.cpu_affinity=

Overrides the CPU affinity mask for the service manager and the default for all child processes it forks. This takes precedence over CPUAffinity=, see systemd-system.conf(5) for details.

Added in version 245.

modules_load=, rd.modules_load=

Load a specific kernel module early at boot. For details, see systemd-modules-load.service(8).

Added in version 187.

nameserver=, domain=

Configures DNS server information and search domains, see systemd-resolved.service(8) for details.

Added in version 253.

resume=, resumeflags=

Enable resume from hibernation using the specified device and timeout options. All fstab(5)-style device identifiers are supported. For details, see systemd-hibernate-resume-generator(8).

Added in version 217.

resume_offset=

Configure the page offset of the swap space from the resume device. For details, see systemd-hibernate-resume-generator(8).

Added in version 254.

systemd.firstboot=

Takes a boolean argument, defaults to on. If off, systemd-firstboot.service(8) and systemd-homed-firstboot.service(1) will not query the user for basic system settings, even if the system boots up for the first time and the relevant settings are not initialized yet. Not to be confused with systemd.condition_first_boot= (see below), which overrides the result of the ConditionFirstBoot= unit file condition, and thus controls more than just systemd-firstboot.service behaviour.

Added in version 233.

systemd.condition_needs_update=

Takes a boolean argument. If specified, overrides the result of ConditionNeedsUpdate= unit condition checks. See systemd.unit(5) for details.

Added in version 246.

systemd.condition_first_boot=

Takes a boolean argument. If specified, overrides the result of ConditionFirstBoot= unit condition checks. See systemd.unit(5) for details. Not to be confused with systemd.firstboot= which only controls behaviour of the systemd-firstboot.service system service but has no effect on the condition check (see above).

Added in version 246.

systemd.clock_usec=

Takes a decimal, numeric timestamp in μs since January 1st 1970, 00:00am, to set the system clock to. The system time is set to the specified timestamp early during boot. It is not propagated to the hardware clock (RTC).

Added in version 246.

systemd.random_seed=

Takes a base64 encoded random seed value to credit with full entropy to the kernels random pool during early service manager initialization. This option is useful in testing environments where delays due to random pool initialization in entropy starved virtual machines shall be avoided.

Note that if this option is used the seed is accessible to unprivileged programs from /proc/cmdline. This option is hence a security risk when used outside of test systems, since the (possibly) only seed used for initialization of the kernels entropy pool might be easily acquired by unprivileged programs.

It is recommended to pass 512 bytes of randomized data (as that matches the Linux kernel pool size), which may be generated with a command like the following:

dd if=/dev/urandom bs=512 count=1 status=none | base64 -w 0

Again: do not use this option outside of testing environments, its a security risk elsewhere, as secret key material derived from the entropy pool can possibly be reconstructed by unprivileged programs.

Added in version 246.

systemd.allow_userspace_verity=

Takes a boolean argument. Controls whether disk images that are Verity protected may be authenticated in userspace signature checks via /etc/verity.d/ (and related directories) public key drop-ins, or whether in-kernel signature checking only. Defaults to on.

Added in version 256.

systemd.hostname=

Accepts a hostname to set during early boot. If specified takes precedence over what is set in /etc/hostname. Note that this does not bar later runtime changes to the hostname, it simply controls the initial hostname set during early boot.

Added in version 246.

systemd.tty.term.tty=, systemd.tty.rows.tty=, systemd.tty.columns.tty=

These arguments allow configuring default values for $TERM, TTYRows=, and TTYColumns= for tty tty. Additionally, systemd.tty.term.console will configure the $TERM value used by systemd if not set explicitly using TERM on the kernel command line. The tty name should be specified without the /dev/ prefix (e.g. “systemd.tty.rows.ttyS0=80”).

Added in version 254.

systemd.battery_check=

Accepts a boolean argument. If false the boot-time battery charge check implemented by systemd-battery-check.service(8) is disabled.

Added in version 254.

ifname=, net.ifname_policy=

Controls interface naming policies, implemented by systemd-network-generator.service(8).

Added in version 245.

systemd.tpm2_wait=

Controls whether to wait for a TPM2 device at boot, implemented by systemd-tpm2-generator(8).

Added in version 256.

HISTORY

systemd 252

Kernel command-line arguments systemd.unified_cgroup_hierarchy and systemd.legacy_systemd_cgroup_controller were deprecated. Please switch to the unified cgroup hierarchy.

Added in version 252.

SEE ALSO

systemd(1), systemd-system.conf(5), bootparam(7), systemd.system-credentials(7), smbios-type-11(7), systemd-debug-generator(8), [email protected](8), systemd-quotacheck.service(8), systemd-journald.service(8), systemd-vconsole-setup.service(8), systemd-udevd.service(8), plymouth(8), systemd-cryptsetup-generator(8), systemd-veritysetup-generator(8), systemd-fstab-generator(8), systemd-getty-generator(8), systemd-gpt-auto-generator(8), systemd-volatile-root.service(8), systemd-modules-load.service(8), [email protected](8), systemd-rfkill.service(8), systemd-hibernate-resume-generator(8), systemd-firstboot.service(8), bootctl(1)

NOTES

kernel-parameters.html

https://docs.kernel.org/admin-guide/kernel-parameters.html

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

397 - Linux cli command ALTER_COLLATION

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_COLLATION and provides detailed information about the command ALTER_COLLATION, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_COLLATION.

NAME 🖥️ ALTER_COLLATION 🖥️

change the definition of a collation

SYNOPSIS

ALTER COLLATION name REFRESH VERSION

ALTER COLLATION name RENAME TO new_name
ALTER COLLATION name OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }
ALTER COLLATION name SET SCHEMA new_schema

DESCRIPTION

ALTER COLLATION changes the definition of a collation.

You must own the collation to use ALTER COLLATION. To alter the owner, you must be able to SET ROLE to the new owning role, and that role must have CREATE privilege on the collations schema. (These restrictions enforce that altering the owner doesnt do anything you couldnt do by dropping and recreating the collation. However, a superuser can alter ownership of any collation anyway.)

PARAMETERS

name

The name (optionally schema-qualified) of an existing collation.

new_name

The new name of the collation.

new_owner

The new owner of the collation.

new_schema

The new schema for the collation.

REFRESH VERSION

Update the collations version. See Notes below.

NOTES

When a collation object is created, the provider-specific version of the collation is recorded in the system catalog. When the collation is used, the current version is checked against the recorded version, and a warning is issued when there is a mismatch, for example:

WARNING: collation “xx-x-icu” has version mismatch DETAIL: The collation in the database was created using version 1.2.3.4, but the operating system provides version 2.3.4.5. HINT: Rebuild all objects affected by this collation and run ALTER COLLATION pg_catalog.“xx-x-icu” REFRESH VERSION, or build PostgreSQL with the right library version.

A change in collation definitions can lead to corrupt indexes and other problems because the database system relies on stored objects having a certain sort order. Generally, this should be avoided, but it can happen in legitimate circumstances, such as when upgrading the operating system to a new major version or when using pg_upgrade to upgrade to server binaries linked with a newer version of ICU. When this happens, all objects depending on the collation should be rebuilt, for example, using REINDEX. When that is done, the collation version can be refreshed using the command ALTER COLLATION … REFRESH VERSION. This will update the system catalog to record the current collation version and will make the warning go away. Note that this does not actually check whether all affected objects have been rebuilt correctly.

When using collations provided by libc, version information is recorded on systems using the GNU C library (most Linux systems), FreeBSD and Windows. When using collations provided by ICU, the version information is provided by the ICU library and is available on all platforms.

Note

When using the GNU C library for collations, the C librarys version is used as a proxy for the collation version. Many Linux distributions change collation definitions only when upgrading the C library, but this approach is imperfect as maintainers are free to back-port newer collation definitions to older C library releases.

When using Windows for collations, version information is only available for collations defined with BCP 47 language tags such as en-US.

For the database default collation, there is an analogous command ALTER DATABASE … REFRESH COLLATION VERSION.

The following query can be used to identify all collations in the current database that need to be refreshed and the objects that depend on them:

SELECT pg_describe_object(refclassid, refobjid, refobjsubid) AS “Collation”, pg_describe_object(classid, objid, objsubid) AS “Object” FROM pg_depend d JOIN pg_collation c ON refclassid = pg_collation::regclass AND refobjid = c.oid WHERE c.collversion <> pg_collation_actual_version(c.oid) ORDER BY 1, 2;

EXAMPLES

To rename the collation de_DE to german:

ALTER COLLATION “de_DE” RENAME TO german;

To change the owner of the collation en_US to joe:

ALTER COLLATION “en_US” OWNER TO joe;

COMPATIBILITY

There is no ALTER COLLATION statement in the SQL standard.

SEE ALSO

CREATE COLLATION (CREATE_COLLATION(7)), DROP COLLATION (DROP_COLLATION(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

398 - Linux cli command EVP_MD-SHA2ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_MD-SHA2ssl and provides detailed information about the command EVP_MD-SHA2ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_MD-SHA2ssl.

NAME 🖥️ EVP_MD-SHA2ssl 🖥️

SHA2 - The SHA2 EVP_MD implementation

DESCRIPTION

Support for computing SHA2 digests through the EVP_MD API.

Identities

This implementation includes the following varieties:

  • Available with the FIPS provider as well as the default provider:

    SHA2-224
    Known names are “SHA2-224”, “SHA-224” and “SHA224”.

    SHA2-256
    Known names are “SHA2-256”, “SHA-256” and “SHA256”.

    SHA2-384
    Known names are “SHA2-384”, “SHA-384” and “SHA384”.

    SHA2-512
    Known names are “SHA2-512”, “SHA-512” and “SHA512”.

  • Available with the default provider:

    SHA2-256/192
    Known names are “SHA2-256/192”, “SHA-256/192” and “SHA256-192”.

    SHA2-512/224
    Known names are “SHA2-512/224”, “SHA-512/224” and “SHA512-224”.

    SHA2-512/256
    Known names are “SHA2-512/256”, “SHA-512/256” and “SHA512-256”.

Gettable Parameters

This implementation supports the common gettable parameters described in EVP_MD-common (7).

SEE ALSO

provider-digest (7), OSSL_PROVIDER-FIPS (7), OSSL_PROVIDER-default (7)

COPYRIGHT

Copyright 2020-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

399 - Linux cli command ossl-guide-quic-client-blockssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ossl-guide-quic-client-blockssl and provides detailed information about the command ossl-guide-quic-client-blockssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ossl-guide-quic-client-blockssl.

NAME 🖥️ ossl-guide-quic-client-blockssl 🖥️

guide-quic-client-block - OpenSSL Guide: Writing a simple blocking QUIC client

SIMPLE BLOCKING QUIC CLIENT EXAMPLE

This page will present various source code samples demonstrating how to write a simple blocking QUIC client application which connects to a server, sends an HTTP/1.0 request to it, and reads back the response. Note that HTTP/1.0 over QUIC is non-standard and will not be supported by real world servers. This is for demonstration purposes only.

We assume that you already have OpenSSL installed on your system; that you already have some fundamental understanding of OpenSSL concepts, TLS and QUIC (see ossl-guide-libraries-introduction (7), ossl-guide-tls-introduction (7) and ossl-guide-quic-introduction (7)); and that you know how to write and build C code and link it against the libcrypto and libssl libraries that are provided by OpenSSL. It also assumes that you have a basic understanding of UDP/IP and sockets. The example code that we build in this tutorial will amend the blocking TLS client example that is covered in ossl-guide-tls-client-block (7). Only the differences between that client and this one will be discussed so we also assume that you have run through and understand that tutorial.

For this tutorial our client will be using a single QUIC stream. A subsequent tutorial will discuss how to write a multi-stream client (see ossl-guide-quic-multi-stream (7)).

The complete source code for this example blocking QUIC client is available in the demos/guide directory of the OpenSSL source distribution in the file quic-client-block.c. It is also available online at <https://github.com/openssl/openssl/blob/master/demos/guide/quic-client-block.c>.

Creating the SSL_CTX and SSL objects

In the TLS tutorial (ossl-guide-tls-client-block (7)) we created an SSL_CTX object for our client and used it to create an SSL object to represent the TLS connection. A QUIC connection works in exactly the same way. We first create an SSL_CTX object and then use it to create an SSL object to represent the QUIC connection.

As in the TLS example the first step is to create an SSL_CTX object for our client. This is done in the same way as before except that we use a different “method”. OpenSSL offers two different QUIC client methods, i.e. OSSL_QUIC_client_method (3) and OSSL_QUIC_client_thread_method (3).

The first one is the equivalent of TLS_client_method (3) but for the QUIC protocol. The second one is the same, but it will additionally create a background thread for handling time based events (known as “thread assisted mode”, see ossl-guide-quic-introduction (7)). For this tutorial we will be using OSSL_QUIC_client_method (3) because we will not be leaving the QUIC connection idle in our application and so thread assisted mode is not needed.

/* * Create an SSL_CTX which we can use to create SSL objects from. We * want an SSL_CTX for creating clients so we use OSSL_QUIC_client_method() * here. */ ctx = SSL_CTX_new(OSSL_QUIC_client_method()); if (ctx == NULL) { printf(“Failed to create the SSL_CTX “); goto end; }

The other setup steps that we applied to the SSL_CTX for TLS also apply to QUIC except for restricting the TLS versions that we are willing to accept. The QUIC protocol implementation in OpenSSL currently only supports TLSv1.3. There is no need to call SSL_CTX_set_min_proto_version (3) or SSL_CTX_set_max_proto_version (3) in an OpenSSL QUIC application, and any such call will be ignored.

Once the SSL_CTX is created, the SSL object is constructed in exactly the same way as for the TLS application.

Creating the socket and BIO

A major difference between TLS and QUIC is the underlying transport protocol. TLS uses TCP while QUIC uses UDP. The way that the QUIC socket is created in our example code is much the same as for TLS. We use the BIO_lookup_ex (3) and BIO_socket (3) helper functions as we did in the previous tutorial except that we pass SOCK_DGRAM as an argument to indicate UDP (instead of SOCK_STREAM for TCP).

/* * Lookup IP address info for the server. */ if (!BIO_lookup_ex(hostname, port, BIO_LOOKUP_CLIENT, family, SOCK_DGRAM, 0, &res)) return NULL; /* * Loop through all the possible addresses for the server and find one * we can connect to. */ for (ai = res; ai != NULL; ai = BIO_ADDRINFO_next(ai)) { /* * Create a TCP socket. We could equally use non-OpenSSL calls such * as “socket” here for this and the subsequent connect and close * functions. But for portability reasons and also so that we get * errors on the OpenSSL stack in the event of a failure we use * OpenSSLs versions of these functions. */ sock = BIO_socket(BIO_ADDRINFO_family(ai), SOCK_DGRAM, 0, 0); if (sock == -1) continue; /* Connect the socket to the servers address */ if (!BIO_connect(sock, BIO_ADDRINFO_address(ai), 0)) { BIO_closesocket(sock); sock = -1; continue; } /* Set to nonblocking mode */ if (!BIO_socket_nbio(sock, 1)) { BIO_closesocket(sock); sock = -1; continue; } break; } if (sock != -1) { *peer_addr = BIO_ADDR_dup(BIO_ADDRINFO_address(ai)); if (*peer_addr == NULL) { BIO_closesocket(sock); return NULL; } } /* Free the address information resources we allocated earlier */ BIO_ADDRINFO_free(res);

You may notice a couple of other differences between this code and the version that we used for TLS.

Firstly, we set the socket into nonblocking mode. This must always be done for an OpenSSL QUIC application. This may be surprising considering that we are trying to write a blocking client. Despite this the SSL object will still have blocking behaviour. See ossl-guide-quic-introduction (7) for further information on this.

Secondly, we take note of the IP address of the peer that we are connecting to. We store that information away. We will need it later.

See BIO_lookup_ex (3), BIO_socket (3), BIO_connect (3), BIO_closesocket (3), BIO_ADDRINFO_next (3), BIO_ADDRINFO_address (3), BIO_ADDRINFO_free (3) and BIO_ADDR_dup (3) for further information on the functions used here. In the above example code the hostname and port variables are strings, e.g. “www.example.com” and “443”.

As for our TLS client, once the socket has been created and connected we need to associate it with a BIO object:

BIO *bio; /* Create a BIO to wrap the socket */ bio = BIO_new(BIO_s_datagram()); if (bio == NULL) { BIO_closesocket(sock); return NULL; } /* * Associate the newly created BIO with the underlying socket. By * passing BIO_CLOSE here the socket will be automatically closed when * the BIO is freed. Alternatively you can use BIO_NOCLOSE, in which * case you must close the socket explicitly when it is no longer * needed. */ BIO_set_fd(bio, sock, BIO_CLOSE);

Note the use of BIO_s_datagram (3) here as opposed to BIO_s_socket (3) that we used for our TLS client. This is again due to the fact that QUIC uses UDP instead of TCP for its transport layer. See BIO_new (3), BIO_s_datagram (3) and BIO_set_fd (3) for further information on these functions.

Setting the server’s hostname

As in the TLS tutorial we need to set the server’s hostname both for SNI (Server Name Indication) and for certificate validation purposes. The steps for this are identical to the TLS tutorial and won’t be repeated here.

Setting the ALPN

ALPN (Application-Layer Protocol Negotiation) is a feature of TLS that enables the application to negotiate which protocol will be used over the connection. For example, if you intend to use HTTP/3 over the connection then the ALPN value for that is “h3” (see <https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xml#alpn-protocol-ids>). OpenSSL provides the ability for a client to specify the ALPN to use via the SSL_set_alpn_protos (3) function. This is optional for a TLS client and so our simple client that we developed in ossl-guide-tls-client-block (7) did not use it. However QUIC mandates that the TLS handshake used in establishing a QUIC connection must use ALPN.

unsigned char alpn[] = { 8, h, t, t, p, /, 1, ., 0 }; /* SSL_set_alpn_protos returns 0 for success! */ if (SSL_set_alpn_protos(ssl, alpn, sizeof(alpn)) != 0) { printf(“Failed to set the ALPN for the connection “); goto end; }

The ALPN is specified using a length prefixed array of unsigned chars (it is not a NUL terminated string). Our original TLS blocking client demo was using HTTP/1.0. We will use the same for this example. Unlike most OpenSSL functions SSL_set_alpn_protos (3) returns zero for success and nonzero for failure.

Setting the peer address

An OpenSSL QUIC application must specify the target address of the server that is being connected to. In “Creating the socket and BIO” above we saved that address away for future use. Now we need to use it via the SSL_set1_initial_peer_addr (3) function.

/* Set the IP address of the remote peer */ if (!SSL_set1_initial_peer_addr(ssl, peer_addr)) { printf(“Failed to set the initial peer address “); goto end; }

Note that we will need to free the peer_addr value that we allocated via BIO_ADDR_dup (3) earlier:

BIO_ADDR_free(peer_addr);

The handshake and application data transfer

Once initial setup of the SSL object is complete then we perform the handshake via SSL_connect (3) in exactly the same way as we did for the TLS client, so we won’t repeat it here.

We can also perform data transfer using a default QUIC stream that is automatically associated with the SSL object for us. We can transmit data using SSL_write_ex (3), and receive data using SSL_read_ex (3) in the same way as for TLS. The main difference is that we have to account for failures slightly differently. With QUIC the stream can be reset by the peer (which is fatal for that stream), but the underlying connection itself may still be healthy.

/* * Get up to sizeof(buf) bytes of the response. We keep reading until the * server closes the connection. */ while (SSL_read_ex(ssl, buf, sizeof(buf), &readbytes)) { /* * OpenSSL does not guarantee that the returned data is a string or * that it is NUL terminated so we use fwrite() to write the exact * number of bytes that we read. The data could be non-printable or * have NUL characters in the middle of it. For this simple example * were going to print it to stdout anyway. */ fwrite(buf, 1, readbytes, stdout); } /* In case the response didnt finish with a newline we add one now */ printf(” “); /* * Check whether we finished the while loop above normally or as the * result of an error. The 0 argument to SSL_get_error() is the return * code we received from the SSL_read_ex() call. It must be 0 in order * to get here. Normal completion is indicated by SSL_ERROR_ZERO_RETURN. In * QUIC terms this means that the peer has sent FIN on the stream to * indicate that no further data will be sent. */ switch (SSL_get_error(ssl, 0)) { case SSL_ERROR_ZERO_RETURN: /* Normal completion of the stream */ break; case SSL_ERROR_SSL: /* * Some stream fatal error occurred. This could be because of a stream * reset - or some failure occurred on the underlying connection. */ switch (SSL_get_stream_read_state(ssl)) { case SSL_STREAM_STATE_RESET_REMOTE: printf(“Stream reset occurred “); /* The stream has been reset but the connection is still healthy. */ break; case SSL_STREAM_STATE_CONN_CLOSED: printf(“Connection closed “); /* Connection is already closed. Skip SSL_shutdown() */ goto end; default: printf(“Unknown stream failure “); break; } break; default: /* Some other unexpected error occurred */ printf (“Failed reading remaining data “); break; }

In the above code example you can see that SSL_ERROR_SSL indicates a stream fatal error. We can use SSL_get_stream_read_state (3) to determine whether the stream has been reset, or if some other fatal error has occurred.

Shutting down the connection

In the TLS tutorial we knew that the server had finished sending data because SSL_read_ex (3) returned 0, and SSL_get_error (3) returned SSL_ERROR_ZERO_RETURN. The same is true with QUIC except that SSL_ERROR_ZERO_RETURN should be interpreted slightly differently. With TLS we knew that this meant that the server had sent a “close_notify” alert. No more data will be sent from the server on that connection.

With QUIC it means that the server has indicated “FIN” on the stream, meaning that it will no longer send any more data on that stream. However this only gives us information about the stream itself and does not tell us anything about the underlying connection. More data could still be sent from the server on some other stream. Additionally, although the server will not send any more data to the client, it does not prevent the client from sending more data to the server.

In this tutorial, once we have finished reading data from the server on the one stream that we are using, we will close the connection down. As before we do this via the SSL_shutdown (3) function. This example for QUIC is very similar to the TLS version. However the SSL_shutdown (3) function will need to be called more than once:

/* * Repeatedly call SSL_shutdown() until the connection is fully * closed. */ do { ret = SSL_shutdown(ssl); if (ret < 0) { printf(“Error shutting down: %d “, ret); goto end; } } while (ret != 1);

The shutdown process is in two stages. In the first stage we wait until all the data we have buffered for sending on any stream has been successfully sent and acknowledged by the peer, and then we send a CONNECTION_CLOSE to the peer to indicate that the connection is no longer usable. This immediately closes the connection and no more data can be sent or received. SSL_shutdown (3) returns 0 once the first stage has been completed.

In the second stage the connection enters a “closing” state. Application data cannot be sent or received in this state, but late arriving packets coming from the peer will be handled appropriately. Once this stage has completed successfully SSL_shutdown (3) will return 1 to indicate success.

FURTHER READING

See ossl-guide-quic-multi-stream (7) to read a tutorial on how to modify the client developed on this page to support multiple streams.

SEE ALSO

ossl-guide-introduction (7), ossl-guide-libraries-introduction (7), ossl-guide-libssl-introduction (7), ossl-guide-tls-introduction (7), ossl-guide-tls-client-block (7), ossl-guide-quic-introduction (7)

COPYRIGHT

Copyright 2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

400 - Linux cli command OPENSSL_API_COMPATssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command OPENSSL_API_COMPATssl and provides detailed information about the command OPENSSL_API_COMPATssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the OPENSSL_API_COMPATssl.

NAME 🖥️ OPENSSL_API_COMPATssl 🖥️

User defined macros

DESCRIPTION

User defined macros allow the programmer to control certain aspects of what is exposed by the OpenSSL headers.

NOTE: to be effective, a user defined macro must be defined before including any header file that depends on it, either in the compilation command (cc -DMACRO=value) or by defining the macro in source before including any headers.

Other manual pages may refer to this page when declarations depend on user defined macros.

The macros

OPENSSL_API_COMPAT
The value is a version number, given in one of the following two forms:

“0xMNNFF000L”
This is the form supported for all versions up to 1.1.x, where M represents the major number, NN represents the minor number, and FF represents the fix number, as a hexadecimal number. For version 1.1.0, that’s 0x10100000L. Any version number may be given, but these numbers are the current known major deprecation points, making them the most meaningful:

“0x00908000L” (version 0.9.8)

“0x10000000L” (version 1.0.0)

“0x10100000L” (version 1.1.0)

For convenience, higher numbers are accepted as well, as long as feasible. For example, 0x60000000L will work as expected. However, it is recommended to start using the second form instead:

“mmnnpp”
This form is a simple decimal number calculated with this formula: major * 10000 + minor * 100 + patch where major, minor and patch are the desired major, minor and patch components of the version number. For example:

30000 corresponds to version 3.0.0

10002 corresponds to version 1.0.2

420101 corresponds to version 42.1.1

If OPENSSL_API_COMPAT is undefined, this default value is used in its place: 30200

OPENSSL_NO_DEPRECATED
If this macro is defined, all deprecated public symbols in all OpenSSL versions up to and including the version given by OPENSSL_API_COMPAT (or the default value given above, when OPENSSL_API_COMPAT isn’t defined) will be hidden.

COPYRIGHT

Copyright 2018-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

401 - Linux cli command ALTER_FOREIGN_DATA_WRAPPER

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_FOREIGN_DATA_WRAPPER and provides detailed information about the command ALTER_FOREIGN_DATA_WRAPPER, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_FOREIGN_DATA_WRAPPER.

NAME 🖥️ ALTER_FOREIGN_DATA_WRAPPER 🖥️

change the definition of a foreign-data wrapper

SYNOPSIS

ALTER FOREIGN DATA WRAPPER name
    [ HANDLER handler_function | NO HANDLER ]
    [ VALIDATOR validator_function | NO VALIDATOR ]
    [ OPTIONS ( [ ADD | SET | DROP ] option [value] [, ... ]) ]
ALTER FOREIGN DATA WRAPPER name OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }
ALTER FOREIGN DATA WRAPPER name RENAME TO new_name

DESCRIPTION

ALTER FOREIGN DATA WRAPPER changes the definition of a foreign-data wrapper. The first form of the command changes the support functions or the generic options of the foreign-data wrapper (at least one clause is required). The second form changes the owner of the foreign-data wrapper.

Only superusers can alter foreign-data wrappers. Additionally, only superusers can own foreign-data wrappers.

PARAMETERS

name

The name of an existing foreign-data wrapper.

HANDLER handler_function

Specifies a new handler function for the foreign-data wrapper.

NO HANDLER

This is used to specify that the foreign-data wrapper should no longer have a handler function.

Note that foreign tables that use a foreign-data wrapper with no handler cannot be accessed.

VALIDATOR validator_function

Specifies a new validator function for the foreign-data wrapper.

Note that it is possible that pre-existing options of the foreign-data wrapper, or of dependent servers, user mappings, or foreign tables, are invalid according to the new validator. PostgreSQL does not check for this. It is up to the user to make sure that these options are correct before using the modified foreign-data wrapper. However, any options specified in this ALTER FOREIGN DATA WRAPPER command will be checked using the new validator.

NO VALIDATOR

This is used to specify that the foreign-data wrapper should no longer have a validator function.

OPTIONS ( [ ADD | SET | DROP ] option [value] [, … ] )

Change options for the foreign-data wrapper. ADD, SET, and DROP specify the action to be performed. ADD is assumed if no operation is explicitly specified. Option names must be unique; names and values are also validated using the foreign data wrappers validator function, if any.

new_owner

The user name of the new owner of the foreign-data wrapper.

new_name

The new name for the foreign-data wrapper.

EXAMPLES

Change a foreign-data wrapper dbi, add option foo, drop bar:

ALTER FOREIGN DATA WRAPPER dbi OPTIONS (ADD foo 1, DROP bar);

Change the foreign-data wrapper dbi validator to bob.myvalidator:

ALTER FOREIGN DATA WRAPPER dbi VALIDATOR bob.myvalidator;

COMPATIBILITY

ALTER FOREIGN DATA WRAPPER conforms to ISO/IEC 9075-9 (SQL/MED), except that the HANDLER, VALIDATOR, OWNER TO, and RENAME clauses are extensions.

SEE ALSO

CREATE FOREIGN DATA WRAPPER (CREATE_FOREIGN_DATA_WRAPPER(7)), DROP FOREIGN DATA WRAPPER (DROP_FOREIGN_DATA_WRAPPER(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

402 - Linux cli command OSSL_PROVIDER-legacyssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command OSSL_PROVIDER-legacyssl and provides detailed information about the command OSSL_PROVIDER-legacyssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the OSSL_PROVIDER-legacyssl.

NAME 🖥️ OSSL_PROVIDER-legacyssl 🖥️

legacy - OpenSSL legacy provider

DESCRIPTION

The OpenSSL legacy provider supplies OpenSSL implementations of algorithms that have been deemed legacy. Such algorithms have commonly fallen out of use, have been deemed insecure by the cryptography community, or something similar.

We can consider this the retirement home of cryptographic algorithms.

Properties

The implementations in this provider specifically has this property defined:

“provider=legacy”

It may be used in a property query string with fetching functions such as EVP_MD_fetch (3) or EVP_CIPHER_fetch (3), as well as with other functions that take a property query string, such as EVP_PKEY_CTX_new_from_name (3).

It isn’t mandatory to query for any of these properties, except to make sure to get implementations of this provider and none other.

OPERATIONS AND ALGORITHMS

The OpenSSL legacy provider supports these operations and algorithms:

Hashing Algorithms / Message Digests

MD2, see EVP_MD-MD2 (7)
Disabled by default. Use enable-md2 config option to enable.

MD4, see EVP_MD-MD4 (7)

MDC2, see EVP_MD-MDC2 (7)

WHIRLPOOL, see EVP_MD-WHIRLPOOL (7)

RIPEMD160, see EVP_MD-RIPEMD160 (7)

Symmetric Ciphers

Not all of these symmetric cipher algorithms are enabled by default.

Blowfish, see EVP_CIPHER-BLOWFISH (7)

CAST, see EVP_CIPHER-CAST (7)

DES, see EVP_CIPHER-DES (7)

The algorithm names are: DES_ECB, DES_CBC, DES_OFB, DES_CFB, DES_CFB1, DES_CFB8 and DESX_CBC.

IDEA, see EVP_CIPHER-IDEA (7)

RC2, see EVP_CIPHER-RC2 (7)

RC4, see EVP_CIPHER-RC4 (7)

RC5, see EVP_CIPHER-RC5 (7)

Disabled by default. Use enable-rc5 config option to enable.

SEED, see EVP_CIPHER-SEED (7)

Key Derivation Function (KDF)

PBKDF1

PVKKDF

SEE ALSO

OSSL_PARAM (3), openssl-core.h (7), openssl-core_dispatch.h (7), provider (7)

HISTORY

This functionality was added in OpenSSL 3.0.

COPYRIGHT

Copyright 2020-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

403 - Linux cli command iso-8859-4

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso-8859-4 and provides detailed information about the command iso-8859-4, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso-8859-4.

NAME 🖥️ iso-8859-4 🖥️

4 - ISO/IEC 8859-4 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-4 encodes the characters used in Scandinavian and Baltic languages.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-4 characters

The following table displays the characters in ISO/IEC 8859-4 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-4 is also known as Latin-4.

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

404 - Linux cli command EVP_PKEY-SM2ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_PKEY-SM2ssl and provides detailed information about the command EVP_PKEY-SM2ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_PKEY-SM2ssl.

NAME 🖥️ EVP_PKEY-SM2ssl 🖥️

SM2, EVP_KEYMGMT-SM2, SM2 - EVP_PKEY keytype support for the Chinese SM2 signature and encryption algorithms

DESCRIPTION

The SM2 algorithm was first defined by the Chinese national standard GM/T 0003-2012 and was later standardized by ISO as ISO/IEC 14888. SM2 is actually an elliptic curve based algorithm. The current implementation in OpenSSL supports both signature and encryption schemes via the EVP interface.

When doing the SM2 signature algorithm, it requires a distinguishing identifier to form the message prefix which is hashed before the real message is hashed.

Common SM2 parameters

SM2 uses the parameters defined in “Common EC parameters” in EVP_PKEY-EC (7). The following parameters are different:

“cofactor” (OSSL_PKEY_PARAM_EC_COFACTOR) <unsigned integer>
This parameter is ignored for SM2.

(OSSL_PKEY_PARAM_DEFAULT_DIGEST) <UTF8 string>
Getter that returns the default digest name. (Currently returns “SM3” as of OpenSSL 3.0).

NOTES

SM2 signatures can be generated by using the ‘DigestSign’ series of APIs, for instance, EVP_DigestSignInit(), EVP_DigestSignUpdate() and EVP_DigestSignFinal(). Ditto for the verification process by calling the ‘DigestVerify’ series of APIs. Note that the SM2 algorithm requires the presence of the public key for signatures, as such the OSSL_PKEY_PARAM_PUB_KEY option must be set on any key used in signature generation.

Before computing an SM2 signature, an EVP_PKEY_CTX needs to be created, and an SM2 ID must be set for it, like this:

EVP_PKEY_CTX_set1_id(pctx, id, id_len);

Before calling the EVP_DigestSignInit() or EVP_DigestVerifyInit() functions, that EVP_PKEY_CTX should be assigned to the EVP_MD_CTX, like this:

EVP_MD_CTX_set_pkey_ctx(mctx, pctx);

There is normally no need to pass a pctx parameter to EVP_DigestSignInit() or EVP_DigestVerifyInit() in such a scenario.

SM2 can be tested with the openssl-speed (1) application since version 3.0. Currently, the only valid algorithm name is sm2.

Since version 3.0, SM2 keys can be generated and loaded only when the domain parameters specify the SM2 elliptic curve.

EXAMPLES

This example demonstrates the calling sequence for using an EVP_PKEY to verify a message with the SM2 signature algorithm and the SM3 hash algorithm:

#include <openssl/evp.h> /* obtain an EVP_PKEY using whatever methods… */ mctx = EVP_MD_CTX_new(); pctx = EVP_PKEY_CTX_new(pkey, NULL); EVP_PKEY_CTX_set1_id(pctx, id, id_len); EVP_MD_CTX_set_pkey_ctx(mctx, pctx); EVP_DigestVerifyInit(mctx, NULL, EVP_sm3(), NULL, pkey); EVP_DigestVerifyUpdate(mctx, msg, msg_len); EVP_DigestVerifyFinal(mctx, sig, sig_len)

SEE ALSO

EVP_PKEY_CTX_new (3), EVP_DigestSignInit (3), EVP_DigestVerifyInit (3), EVP_PKEY_CTX_set1_id (3), EVP_MD_CTX_set_pkey_ctx (3)

COPYRIGHT

Copyright 2018-2024 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

405 - Linux cli command epoll

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command epoll and provides detailed information about the command epoll, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the epoll.

NAME 🖥️ epoll 🖥️

I/O event notification facility

SYNOPSIS

#include <sys/epoll.h>

DESCRIPTION

The epoll API performs a similar task to poll(2): monitoring multiple file descriptors to see if I/O is possible on any of them. The epoll API can be used either as an edge-triggered or a level-triggered interface and scales well to large numbers of watched file descriptors.

The central concept of the epoll API is the epoll instance, an in-kernel data structure which, from a user-space perspective, can be considered as a container for two lists:

  • The interest list (sometimes also called the epoll set): the set of file descriptors that the process has registered an interest in monitoring.

  • The ready list: the set of file descriptors that are “ready” for I/O. The ready list is a subset of (or, more precisely, a set of references to) the file descriptors in the interest list. The ready list is dynamically populated by the kernel as a result of I/O activity on those file descriptors.

The following system calls are provided to create and manage an epoll instance:

  • epoll_create(2) creates a new epoll instance and returns a file descriptor referring to that instance. (The more recent epoll_create1(2) extends the functionality of epoll_create(2).)

  • Interest in particular file descriptors is then registered via epoll_ctl(2), which adds items to the interest list of the epoll instance.

  • epoll_wait(2) waits for I/O events, blocking the calling thread if no events are currently available. (This system call can be thought of as fetching items from the ready list of the epoll instance.)

Level-triggered and edge-triggered

The epoll event distribution interface is able to behave both as edge-triggered (ET) and as level-triggered (LT). The difference between the two mechanisms can be described as follows. Suppose that this scenario happens:

  1. The file descriptor that represents the read side of a pipe (rfd) is registered on the epoll instance.

  2. A pipe writer writes 2 kB of data on the write side of the pipe.

  3. A call to epoll_wait(2) is done that will return rfd as a ready file descriptor.

  4. The pipe reader reads 1 kB of data from rfd.

  5. A call to epoll_wait(2) is done.

If the rfd file descriptor has been added to the epoll interface using the EPOLLET (edge-triggered) flag, the call to epoll_wait(2) done in step 5 will probably hang despite the available data still present in the file input buffer; meanwhile the remote peer might be expecting a response based on the data it already sent. The reason for this is that edge-triggered mode delivers events only when changes occur on the monitored file descriptor. So, in step 5 the caller might end up waiting for some data that is already present inside the input buffer. In the above example, an event on rfd will be generated because of the write done in 2 and the event is consumed in 3. Since the read operation done in 4 does not consume the whole buffer data, the call to epoll_wait(2) done in step 5 might block indefinitely.

An application that employs the EPOLLET flag should use nonblocking file descriptors to avoid having a blocking read or write starve a task that is handling multiple file descriptors. The suggested way to use epoll as an edge-triggered (EPOLLET) interface is as follows:

  1. with nonblocking file descriptors; and

  2. by waiting for an event only after read(2) or write(2) return EAGAIN.

By contrast, when used as a level-triggered interface (the default, when EPOLLET is not specified), epoll is simply a faster poll(2), and can be used wherever the latter is used since it shares the same semantics.

Since even with edge-triggered epoll, multiple events can be generated upon receipt of multiple chunks of data, the caller has the option to specify the EPOLLONESHOT flag, to tell epoll to disable the associated file descriptor after the receipt of an event with epoll_wait(2). When the EPOLLONESHOT flag is specified, it is the caller’s responsibility to rearm the file descriptor using epoll_ctl(2) with EPOLL_CTL_MOD.

If multiple threads (or processes, if child processes have inherited the epoll file descriptor across fork(2)) are blocked in epoll_wait(2) waiting on the same epoll file descriptor and a file descriptor in the interest list that is marked for edge-triggered (EPOLLET) notification becomes ready, just one of the threads (or processes) is awoken from epoll_wait(2). This provides a useful optimization for avoiding “thundering herd” wake-ups in some scenarios.

Interaction with autosleep

If the system is in autosleep mode via /sys/power/autosleep and an event happens which wakes the device from sleep, the device driver will keep the device awake only until that event is queued. To keep the device awake until the event has been processed, it is necessary to use the epoll_ctl(2) EPOLLWAKEUP flag.

When the EPOLLWAKEUP flag is set in the events field for a struct epoll_event, the system will be kept awake from the moment the event is queued, through the epoll_wait(2) call which returns the event until the subsequent epoll_wait(2) call. If the event should keep the system awake beyond that time, then a separate wake_lock should be taken before the second epoll_wait(2) call.

/proc interfaces

The following interfaces can be used to limit the amount of kernel memory consumed by epoll:

/proc/sys/fs/epoll/max_user_watches (since Linux 2.6.28)
This specifies a limit on the total number of file descriptors that a user can register across all epoll instances on the system. The limit is per real user ID. Each registered file descriptor costs roughly 90 bytes on a 32-bit kernel, and roughly 160 bytes on a 64-bit kernel. Currently, the default value for max_user_watches is 1/25 (4%) of the available low memory, divided by the registration cost in bytes.

Example for suggested usage

While the usage of epoll when employed as a level-triggered interface does have the same semantics as poll(2), the edge-triggered usage requires more clarification to avoid stalls in the application event loop. In this example, listener is a nonblocking socket on which listen(2) has been called. The function do_use_fd() uses the new ready file descriptor until EAGAIN is returned by either read(2) or write(2). An event-driven state machine application should, after having received EAGAIN, record its current state so that at the next call to do_use_fd() it will continue to read(2) or write(2) from where it stopped before.

#define MAX_EVENTS 10
struct epoll_event ev, events[MAX_EVENTS];
int listen_sock, conn_sock, nfds, epollfd;
/* Code to set up listening socket, 'listen_sock',
   (socket(), bind(), listen()) omitted. */
epollfd = epoll_create1(0);
if (epollfd == -1) {
    perror("epoll_create1");
    exit(EXIT_FAILURE);
}
ev.events = EPOLLIN;
ev.data.fd = listen_sock;
if (epoll_ctl(epollfd, EPOLL_CTL_ADD, listen_sock, &ev) == -1) {
    perror("epoll_ctl: listen_sock");
    exit(EXIT_FAILURE);
}
for (;;) {
    nfds = epoll_wait(epollfd, events, MAX_EVENTS, -1);
    if (nfds == -1) {
        perror("epoll_wait");
        exit(EXIT_FAILURE);
    }
    for (n = 0; n < nfds; ++n) {
        if (events[n].data.fd == listen_sock) {
            conn_sock = accept(listen_sock,
                               (struct sockaddr *) &addr, &addrlen);
            if (conn_sock == -1) {
                perror("accept");
                exit(EXIT_FAILURE);
            }
            setnonblocking(conn_sock);
            ev.events = EPOLLIN | EPOLLET;
            ev.data.fd = conn_sock;
            if (epoll_ctl(epollfd, EPOLL_CTL_ADD, conn_sock,
                        &ev) == -1) {
                perror("epoll_ctl: conn_sock");
                exit(EXIT_FAILURE);
            }
        } else {
            do_use_fd(events[n].data.fd);
        }
    }
}

When used as an edge-triggered interface, for performance reasons, it is possible to add the file descriptor inside the epoll interface (EPOLL_CTL_ADD) once by specifying (EPOLLIN|EPOLLOUT). This allows you to avoid continuously switching between EPOLLIN and EPOLLOUT calling epoll_ctl(2) with EPOLL_CTL_MOD.

Questions and answers

  • What is the key used to distinguish the file descriptors registered in an interest list?

    The key is the combination of the file descriptor number and the open file description (also known as an “open file handle”, the kernel’s internal representation of an open file).

  • What happens if you register the same file descriptor on an epoll instance twice?

    You will probably get EEXIST. However, it is possible to add a duplicate (dup(2), dup2(2), fcntl(2) F_DUPFD) file descriptor to the same epoll instance. This can be a useful technique for filtering events, if the duplicate file descriptors are registered with different events masks.

  • Can two epoll instances wait for the same file descriptor? If so, are events reported to both epoll file descriptors?

    Yes, and events would be reported to both. However, careful programming may be needed to do this correctly.

  • Is the epoll file descriptor itself poll/epoll/selectable?

    Yes. If an epoll file descriptor has events waiting, then it will indicate as being readable.

  • What happens if one attempts to put an epoll file descriptor into its own file descriptor set?

    The epoll_ctl(2) call fails (EINVAL). However, you can add an epoll file descriptor inside another epoll file descriptor set.

  • Can I send an epoll file descriptor over a UNIX domain socket to another process?

    Yes, but it does not make sense to do this, since the receiving process would not have copies of the file descriptors in the interest list.

  • Will closing a file descriptor cause it to be removed from all epoll interest lists?

    Yes, but be aware of the following point. A file descriptor is a reference to an open file description (see open(2)). Whenever a file descriptor is duplicated via dup(2), dup2(2), fcntl(2) F_DUPFD, or fork(2), a new file descriptor referring to the same open file description is created. An open file description continues to exist until all file descriptors referring to it have been closed.

    A file descriptor is removed from an interest list only after all the file descriptors referring to the underlying open file description have been closed. This means that even after a file descriptor that is part of an interest list has been closed, events may be reported for that file descriptor if other file descriptors referring to the same underlying file description remain open. To prevent this happening, the file descriptor must be explicitly removed from the interest list (using epoll_ctl(2) EPOLL_CTL_DEL) before it is duplicated. Alternatively, the application must ensure that all file descriptors are closed (which may be difficult if file descriptors were duplicated behind the scenes by library functions that used dup(2) or fork(2)).

  • If more than one event occurs between epoll_wait(2) calls, are they combined or reported separately?

    They will be combined.

  • Does an operation on a file descriptor affect the already collected but not yet reported events?

    You can do two operations on an existing file descriptor. Remove would be meaningless for this case. Modify will reread available I/O.

  • Do I need to continuously read/write a file descriptor until EAGAIN when using the EPOLLET flag (edge-triggered behavior)?

    Receiving an event from epoll_wait(2) should suggest to you that such file descriptor is ready for the requested I/O operation. You must consider it ready until the next (nonblocking) read/write yields EAGAIN. When and how you will use the file descriptor is entirely up to you.

    For packet/token-oriented files (e.g., datagram socket, terminal in canonical mode), the only way to detect the end of the read/write I/O space is to continue to read/write until EAGAIN.

    For stream-oriented files (e.g., pipe, FIFO, stream socket), the condition that the read/write I/O space is exhausted can also be detected by checking the amount of data read from / written to the target file descriptor. For example, if you call read(2) by asking to read a certain amount of data and read(2) returns a lower number of bytes, you can be sure of having exhausted the read I/O space for the file descriptor. The same is true when writing using write(2). (Avoid this latter technique if you cannot guarantee that the monitored file descriptor always refers to a stream-oriented file.)

Possible pitfalls and ways to avoid them

  • Starvation (edge-triggered)

    If there is a large amount of I/O space, it is possible that by trying to drain it the other files will not get processed causing starvation. (This problem is not specific to epoll.)

    The solution is to maintain a ready list and mark the file descriptor as ready in its associated data structure, thereby allowing the application to remember which files need to be processed but still round robin amongst all the ready files. This also supports ignoring subsequent events you receive for file descriptors that are already ready.

  • If using an event cache…

    If you use an event cache or store all the file descriptors returned from epoll_wait(2), then make sure to provide a way to mark its closure dynamically (i.e., caused by a previous event’s processing). Suppose you receive 100 events from epoll_wait(2), and in event #47 a condition causes event #13 to be closed. If you remove the structure and close(2) the file descriptor for event #13, then your event cache might still say there are events waiting for that file descriptor causing confusion.

    One solution for this is to call, during the processing of event 47, epoll_ctl(EPOLL_CTL_DEL) to delete file descriptor 13 and close(2), then mark its associated data structure as removed and link it to a cleanup list. If you find another event for file descriptor 13 in your batch processing, you will discover the file descriptor had been previously removed and there will be no confusion.

VERSIONS

Some other systems provide similar mechanisms; for example, FreeBSD has kqueue, and Solaris has /dev/poll.

STANDARDS

Linux.

HISTORY

Linux 2.5.44. glibc 2.3.2.

NOTES

The set of file descriptors that is being monitored via an epoll file descriptor can be viewed via the entry for the epoll file descriptor in the process’s /proc/pid/fdinfo directory. See proc(5) for further details.

The kcmp(2) KCMP_EPOLL_TFD operation can be used to test whether a file descriptor is present in an epoll instance.

SEE ALSO

epoll_create(2), epoll_create1(2), epoll_ctl(2), epoll_wait(2), poll(2), select(2)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

406 - Linux cli command iso_8859-6

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso_8859-6 and provides detailed information about the command iso_8859-6, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso_8859-6.

NAME 🖥️ iso_8859-6 🖥️

6 - ISO/IEC 8859-6 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-6 encodes the characters used in the Arabic language.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-6 characters

The following table displays the characters in ISO/IEC 8859-6 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-6 lacks the glyphs required for many related languages, such as Urdu and Persian (Farsi).

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

407 - Linux cli command groff_man

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command groff_man and provides detailed information about the command groff_man, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the groff_man.

Name

groff_man - compose manual pages with GNU roff

Synopsis

groff -man [*option *. . .] [*file *. . .] groff -m man [*option *. . .] [*file *. . .]

Description

The GNU implementation of the man macro package is part of the groff document formatting system. It is used to produce manual pages (“man pages”) like the one you are reading.

This document presents the macros thematically; for those needing only a quick reference, the following table lists them alphabetically, with cross references to appropriate subsections below.

Man page authors and maintainers who are not already experienced groff users should consult

an expanded version of this document, for additional explanations and advice. It covers only those concepts required for man page document maintenance, and not the full breadth of the groff typesetting system.

MacroMeaningSubsection
.BBoldFont style macros
.BIBold, italic alternatingFont style macros
.BRBold, roman alternatingFont style macros
.EEExample endDocument structure macros
.EXExample beginDocument structure macros
.IItalicFont style macros
.IBItalic, bold alternatingFont style macros
.IPIndented paragraphParagraphing macros
.IRItalic, roman alternatingFont style macros
.LPBegin paragraphParagraphing macros
.MEMail-to endHyperlink macros
.MRMan page cross referenceHyperlink macros
.MTMail-to startHyperlink macros
.PBegin paragraphParagraphing macros
.PPBegin paragraphParagraphing macros
.RBRoman, bold alternatingFont style macros
.RERelative inset endDocument structure macros
.RIRoman, italic alternatingFont style macros
.RSRelative inset startDocument structure macros
.SBSmall boldFont style macros
.SHSection headingDocument structure macros
.SMSmallFont style macros
.SSSubsection headingDocument structure macros
.SYSynopsis startCommand synopsis macros
.THTitle headingDocument structure macros
.TPTagged paragraphParagraphing macros
.TQSupplemental paragraph tagParagraphing macros
.UEURI endHyperlink macros
.URURI startHyperlink macros
.YSSynopsis endCommand synopsis macros

We discuss other macros (.AT, .DT, .HP, .OP, .PD, and .UC) in subsection “Deprecated features” below.

Throughout Unix documentation, a manual entry is referred to simply as a “man page”, regardless of its length, without gendered implication, and irrespective of the macro package selected for its composition.

Macro reference preliminaries

A tagged paragraph describes each macro. We present coupled pairs together, as with .EX and .EE.

An empty macro argument can be specified with a pair of double-quotes (""), but the man package is designed such that this should seldom be necessary. Most macro arguments will be formatted as text in the output; exceptions are noted.

Document structure macros

Document structure macros organize a man page’s content. All of them break the output line. .TH (title heading) identifies the document as a man page and configures the page headers and footers. Section headings (.SH), one of which is mandatory and many of which are conventionally expected, facilitate location of material by the reader and aid the man page writer to discuss all essential aspects of the topic. Subsection headings (.SS) are optional and permit sections that grow long to develop in a controlled way. Many technical discussions benefit from examples; lengthy ones, especially those reflecting multiple lines of input to or output from the system, are usefully bracketed by .EX and .EE. When none of the foregoing meets a structural demand, use .RS/.RE to inset a region within a (sub)section.

.TH* topic section*
[footer-middle] [footer-inside] [header-middle] Determine the contents of the page header and footer. The subject of the man page is topic and the section of the manual to which it belongs is section. See

or

for the manual sectioning applicable to your system. topic and section are positioned together at the left and right in the header (with section in parentheses immediately appended to topic). footer-middle is centered in the footer. The arrangement of the rest of the footer depends on whether double-sided layout is enabled with the option -rD1. When disabled (the default), footer-inside is positioned at the bottom left. Otherwise, footer-inside appears at the bottom left on recto (odd-numbered) pages, and at the bottom right on verso (even-numbered) pages. The outside footer is the page number, except in the continuous-rendering mode enabled by the option -rcR=1, in which case it is the topic and section, as in the header. header-middle is centered in the header. If section is an integer between 1 and 9 (inclusive), there is no need to specify header-middle; an.tmac will supply text for it. The macro package may also abbreviate topic and footer-inside with ellipses if they would overrun the space available in the header and footer, respectively. For HTML output, headers and footers are suppressed.

Additionally, this macro breaks the page, resetting the number to 1 (unless the -rC1 option is given). This feature is intended only for formatting multiple man documents in sequence.

A valid man document calls .TH once, early in the file, prior to any other macro calls.

.SH [
heading-text] Set heading-text as a section heading. If no argument is given, a one-line input trap is planted; text on the next line becomes heading-text. The left margin is reset to zero to set the heading text in bold (or the font specified by the string HF), and, on typesetting devices, slightly larger than the base type size. If the heading font \[HF] is bold, use of an italic style in heading-text is mapped to the bold-italic style if available in the font family. The inset level is reset to 1, setting the left margin to the value of the IN register. Text after heading-text is set as an ordinary paragraph (.P).

The content of heading-text and ordering of sections follows a set of common practices, as has much of the layout of material within sections. For example, a section called “Name” or “NAME” must exist, must be the first section after the .TH call, and must contain only text of the form

topic[ ,* another-topic* ]. . . \ summary-description

for a man page to be properly indexed. See

for suggestions and

for the conventions prevailing on your system.

.SS [
subheading-text] Set subheading-text as a subsection heading indented between a section heading and an ordinary paragraph (.P). If no argument is given, a one-line input trap is planted; text on the next line becomes subheading-text. The left margin is reset to the value of the SN register to set the heading text in bold (or the font specified by the string HF). If the heading font \[HF] is bold, use of an italic style in subheading-text is mapped to the bold-italic style if available in the font family. The inset level is reset to 1, setting the left margin to the value of the IN register. Text after subheading-text is set as an ordinary paragraph (.P).

.EX
.EE
Begin and end example. After .EX, filling is disabled and a constant-width (monospaced) font is selected. Calling .EE enables filling and restores the previous font.

These macros are extensions introduced in Ninth Edition Research Unix. Systems running that troff, or those from Documenter’s Workbench, Heirloom Doctools, or Plan 9 troff support them. To be certain your page will be portable to systems that do not, copy their definitions from the an-ext.tmac file of a groff installation.

.RS [
inset-amount] Start a new relative inset level. The position of the left margin is saved, then moved right by inset-amount, if specified, and by the amount of the IN register otherwise. Calls to .RS can be nested; each increments by 1 the inset level used by .RE. The level prior to any .RS calls is 1.

.RE [
level] End a relative inset. The left margin corresponding to inset level level is restored. If no argument is given, the inset level is reduced by 1.

Paragraphing macros

An ordinary paragraph (.P) is set without a first-line indentation at the current left margin. In man pages and other technical literature, definition lists are frequently encountered; these can be set as “tagged paragraphs”, which have one (.TP) or more (.TQ) leading tags followed by a paragraph that has an additional indentation. The indented paragraph (.IP) macro is useful to continue the indented content of a narrative started with .TP, or to present an itemized or ordered list. All of these macros break the output line. If another paragraph macro has occurred since the previous .SH or .SS, they (except for .TQ) follow the break with a default amount of vertical space, which can be changed by the deprecated .PD macro; see subsection “Horizontal and vertical spacing” below. They also reset the type size and font style to defaults (.TQ again excepted); see subsection “Font style macros” below.

.P
.LP
.PP
Begin a new paragraph; these macros are synonymous. The indentation is reset to the default value; the left margin, as affected by .RS and .RE, is not.

.TP [
indentation] Set a paragraph with a leading tag, and the remainder of the paragraph indented. A one-line input trap is planted; text on the next line, which can be formatted with a macro, becomes the tag, which is placed at the current left margin. The tag can be extended with the **

408 - Linux cli command ALTER_OPERATOR_FAMILY

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_OPERATOR_FAMILY and provides detailed information about the command ALTER_OPERATOR_FAMILY, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_OPERATOR_FAMILY.

NAME 🖥️ ALTER_OPERATOR_FAMILY 🖥️

change the definition of an operator family

SYNOPSIS

ALTER OPERATOR FAMILY name USING index_method ADD
  {  OPERATOR strategy_number operator_name ( op_type, op_type )
              [ FOR SEARCH | FOR ORDER BY sort_family_name ]
   | FUNCTION support_number [ ( op_type [ , op_type ] ) ]
              function_name [ ( argument_type [, ...] ) ]
  } [, ... ]

ALTER OPERATOR FAMILY name USING index_method DROP
  {  OPERATOR strategy_number ( op_type [ , op_type ] )
   | FUNCTION support_number ( op_type [ , op_type ] )
  } [, ... ]

ALTER OPERATOR FAMILY name USING index_method
    RENAME TO new_name

ALTER OPERATOR FAMILY name USING index_method
    OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }

ALTER OPERATOR FAMILY name USING index_method
    SET SCHEMA new_schema

DESCRIPTION

ALTER OPERATOR FAMILY changes the definition of an operator family. You can add operators and support functions to the family, remove them from the family, or change the familys name or owner.

When operators and support functions are added to a family with ALTER OPERATOR FAMILY, they are not part of any specific operator class within the family, but are just “loose” within the family. This indicates that these operators and functions are compatible with the familys semantics, but are not required for correct functioning of any specific index. (Operators and functions that are so required should be declared as part of an operator class, instead; see CREATE OPERATOR CLASS (CREATE_OPERATOR_CLASS(7)).) PostgreSQL will allow loose members of a family to be dropped from the family at any time, but members of an operator class cannot be dropped without dropping the whole class and any indexes that depend on it. Typically, single-data-type operators and functions are part of operator classes because they are needed to support an index on that specific data type, while cross-data-type operators and functions are made loose members of the family.

You must be a superuser to use ALTER OPERATOR FAMILY. (This restriction is made because an erroneous operator family definition could confuse or even crash the server.)

ALTER OPERATOR FAMILY does not presently check whether the operator family definition includes all the operators and functions required by the index method, nor whether the operators and functions form a self-consistent set. It is the users responsibility to define a valid operator family.

Refer to Section 38.16 for further information.

PARAMETERS

name

The name (optionally schema-qualified) of an existing operator family.

index_method

The name of the index method this operator family is for.

strategy_number

The index methods strategy number for an operator associated with the operator family.

operator_name

The name (optionally schema-qualified) of an operator associated with the operator family.

op_type

In an OPERATOR clause, the operand data type(s) of the operator, or NONE to signify a prefix operator. Unlike the comparable syntax in CREATE OPERATOR CLASS, the operand data types must always be specified.

In an ADD FUNCTION clause, the operand data type(s) the function is intended to support, if different from the input data type(s) of the function. For B-tree comparison functions and hash functions it is not necessary to specify op_type since the functions input data type(s) are always the correct ones to use. For B-tree sort support functions, B-Tree equal image functions, and all functions in GiST, SP-GiST and GIN operator classes, it is necessary to specify the operand data type(s) the function is to be used with.

In a DROP FUNCTION clause, the operand data type(s) the function is intended to support must be specified.

sort_family_name

The name (optionally schema-qualified) of an existing btree operator family that describes the sort ordering associated with an ordering operator.

If neither FOR SEARCH nor FOR ORDER BY is specified, FOR SEARCH is the default.

support_number

The index methods support function number for a function associated with the operator family.

function_name

The name (optionally schema-qualified) of a function that is an index method support function for the operator family. If no argument list is specified, the name must be unique in its schema.

argument_type

The parameter data type(s) of the function.

new_name

The new name of the operator family.

new_owner

The new owner of the operator family.

new_schema

The new schema for the operator family.

The OPERATOR and FUNCTION clauses can appear in any order.

NOTES

Notice that the DROP syntax only specifies the “slot” in the operator family, by strategy or support number and input data type(s). The name of the operator or function occupying the slot is not mentioned. Also, for DROP FUNCTION the type(s) to specify are the input data type(s) the function is intended to support; for GiST, SP-GiST and GIN indexes this might have nothing to do with the actual input argument types of the function.

Because the index machinery does not check access permissions on functions before using them, including a function or operator in an operator family is tantamount to granting public execute permission on it. This is usually not an issue for the sorts of functions that are useful in an operator family.

The operators should not be defined by SQL functions. An SQL function is likely to be inlined into the calling query, which will prevent the optimizer from recognizing that the query matches an index.

Before PostgreSQL 8.4, the OPERATOR clause could include a RECHECK option. This is no longer supported because whether an index operator is “lossy” is now determined on-the-fly at run time. This allows efficient handling of cases where an operator might or might not be lossy.

EXAMPLES

The following example command adds cross-data-type operators and support functions to an operator family that already contains B-tree operator classes for data types int4 and int2.

ALTER OPERATOR FAMILY integer_ops USING btree ADD

  -- int4 vs int2
  OPERATOR 1 < (int4, int2) ,
  OPERATOR 2 <= (int4, int2) ,
  OPERATOR 3 = (int4, int2) ,
  OPERATOR 4 >= (int4, int2) ,
  OPERATOR 5 > (int4, int2) ,
  FUNCTION 1 btint42cmp(int4, int2) ,

  -- int2 vs int4
  OPERATOR 1 < (int2, int4) ,
  OPERATOR 2 <= (int2, int4) ,
  OPERATOR 3 = (int2, int4) ,
  OPERATOR 4 >= (int2, int4) ,
  OPERATOR 5 > (int2, int4) ,
  FUNCTION 1 btint24cmp(int2, int4) ;

To remove these entries again:

ALTER OPERATOR FAMILY integer_ops USING btree DROP

  -- int4 vs int2
  OPERATOR 1 (int4, int2) ,
  OPERATOR 2 (int4, int2) ,
  OPERATOR 3 (int4, int2) ,
  OPERATOR 4 (int4, int2) ,
  OPERATOR 5 (int4, int2) ,
  FUNCTION 1 (int4, int2) ,

  -- int2 vs int4
  OPERATOR 1 (int2, int4) ,
  OPERATOR 2 (int2, int4) ,
  OPERATOR 3 (int2, int4) ,
  OPERATOR 4 (int2, int4) ,
  OPERATOR 5 (int2, int4) ,
  FUNCTION 1 (int2, int4) ;

COMPATIBILITY

There is no ALTER OPERATOR FAMILY statement in the SQL standard.

SEE ALSO

CREATE OPERATOR FAMILY (CREATE_OPERATOR_FAMILY(7)), DROP OPERATOR FAMILY (DROP_OPERATOR_FAMILY(7)), CREATE OPERATOR CLASS (CREATE_OPERATOR_CLASS(7)), ALTER OPERATOR CLASS (ALTER_OPERATOR_CLASS(7)), DROP OPERATOR CLASS (DROP_OPERATOR_CLASS(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

409 - Linux cli command raw

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command raw and provides detailed information about the command raw, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the raw.

NAME 🖥️ raw 🖥️

Linux IPv4 raw sockets

SYNOPSIS

#include <sys/socket.h>
#include <netinet/in.h>
raw_socket = socket(AF_INET, SOCK_RAW, int protocol);

DESCRIPTION

Raw sockets allow new IPv4 protocols to be implemented in user space. A raw socket receives or sends the raw datagram not including link level headers.

The IPv4 layer generates an IP header when sending a packet unless the IP_HDRINCL socket option is enabled on the socket. When it is enabled, the packet must contain an IP header. For receiving, the IP header is always included in the packet.

In order to create a raw socket, a process must have the CAP_NET_RAW capability in the user namespace that governs its network namespace.

All packets or errors matching the protocol number specified for the raw socket are passed to this socket. For a list of the allowed protocols, see the IANA list of assigned protocol numbers at and getprotobyname(3).

A protocol of IPPROTO_RAW implies enabled IP_HDRINCL and is able to send any IP protocol that is specified in the passed header. Receiving of all IP protocols via IPPROTO_RAW is not possible using raw sockets.

TABLE

If IP_HDRINCL is specified and the IP header has a nonzero destination address, then the destination address of the socket is used to route the packet. When MSG_DONTROUTE is specified, the destination address should refer to a local interface, otherwise a routing table lookup is done anyway but gatewayed routes are ignored.

If IP_HDRINCL isn’t set, then IP header options can be set on raw sockets with setsockopt(2); see ip(7) for more information.

Starting with Linux 2.2, all IP header fields and options can be set using IP socket options. This means raw sockets are usually needed only for new protocols or protocols with no user interface (like ICMP).

When a packet is received, it is passed to any raw sockets which have been bound to its protocol before it is passed to other protocol handlers (e.g., kernel protocol modules).

Address format

For sending and receiving datagrams (sendto(2), recvfrom(2), and similar), raw sockets use the standard sockaddr_in address structure defined in ip(7). The sin_port field could be used to specify the IP protocol number, but it is ignored for sending in Linux 2.2 and later, and should be always set to 0 (see BUGS). For incoming packets, sin_port is set to zero.

Socket options

Raw socket options can be set with setsockopt(2) and read with getsockopt(2) by passing the IPPROTO_RAW family flag.

ICMP_FILTER
Enable a special filter for raw sockets bound to the IPPROTO_ICMP protocol. The value has a bit set for each ICMP message type which should be filtered out. The default is to filter no ICMP messages.

In addition, all ip(7) IPPROTO_IP socket options valid for datagram sockets are supported.

Error handling

Errors originating from the network are passed to the user only when the socket is connected or the IP_RECVERR flag is enabled. For connected sockets, only EMSGSIZE and EPROTO are passed for compatibility. With IP_RECVERR, all network errors are saved in the error queue.

ERRORS

EACCES
User tried to send to a broadcast address without having the broadcast flag set on the socket.

EFAULT
An invalid memory address was supplied.

EINVAL
Invalid argument.

EMSGSIZE
Packet too big. Either Path MTU Discovery is enabled (the IP_MTU_DISCOVER socket flag) or the packet size exceeds the maximum allowed IPv4 packet size of 64 kB.

EOPNOTSUPP
Invalid flag has been passed to a socket call (like MSG_OOB).

EPERM
The user doesn’t have permission to open raw sockets. Only processes with an effective user ID of 0 or the CAP_NET_RAW attribute may do that.

EPROTO
An ICMP error has arrived reporting a parameter problem.

VERSIONS

IP_RECVERR and ICMP_FILTER are new in Linux 2.2. They are Linux extensions and should not be used in portable programs.

Linux 2.0 enabled some bug-to-bug compatibility with BSD in the raw socket code when the SO_BSDCOMPAT socket option was set; since Linux 2.2, this option no longer has that effect.

NOTES

By default, raw sockets do path MTU (Maximum Transmission Unit) discovery. This means the kernel will keep track of the MTU to a specific target IP address and return EMSGSIZE when a raw packet write exceeds it. When this happens, the application should decrease the packet size. Path MTU discovery can be also turned off using the IP_MTU_DISCOVER socket option or the /proc/sys/net/ipv4/ip_no_pmtu_disc file, see ip(7) for details. When turned off, raw sockets will fragment outgoing packets that exceed the interface MTU. However, disabling it is not recommended for performance and reliability reasons.

A raw socket can be bound to a specific local address using the bind(2) call. If it isn’t bound, all packets with the specified IP protocol are received. In addition, a raw socket can be bound to a specific network device using SO_BINDTODEVICE; see socket(7).

An IPPROTO_RAW socket is send only. If you really want to receive all IP packets, use a packet(7) socket with the ETH_P_IP protocol. Note that packet sockets don’t reassemble IP fragments, unlike raw sockets.

If you want to receive all ICMP packets for a datagram socket, it is often better to use IP_RECVERR on that particular socket; see ip(7).

Raw sockets may tap all IP protocols in Linux, even protocols like ICMP or TCP which have a protocol module in the kernel. In this case, the packets are passed to both the kernel module and the raw socket(s). This should not be relied upon in portable programs, many other BSD socket implementation have limitations here.

Linux never changes headers passed from the user (except for filling in some zeroed fields as described for IP_HDRINCL). This differs from many other implementations of raw sockets.

Raw sockets are generally rather unportable and should be avoided in programs intended to be portable.

Sending on raw sockets should take the IP protocol from sin_port; this ability was lost in Linux 2.2. The workaround is to use IP_HDRINCL.

BUGS

Transparent proxy extensions are not described.

When the IP_HDRINCL option is set, datagrams will not be fragmented and are limited to the interface MTU.

Setting the IP protocol for sending in sin_port got lost in Linux 2.2. The protocol that the socket was bound to or that was specified in the initial socket(2) call is always used.

SEE ALSO

recvmsg(2), sendmsg(2), capabilities(7), ip(7), socket(7)

RFC 1191 for path MTU discovery. RFC 791 and the <linux/ip.h> header file for the IP protocol.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

410 - Linux cli command cgroup_namespaces

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command cgroup_namespaces and provides detailed information about the command cgroup_namespaces, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the cgroup_namespaces.

NAME 🖥️ cgroup_namespaces 🖥️

overview of Linux cgroup namespaces

DESCRIPTION

For an overview of namespaces, see namespaces(7).

Cgroup namespaces virtualize the view of a process’s cgroups (see cgroups(7)) as seen via /proc/pid/cgroup and /proc/pid/mountinfo.

Each cgroup namespace has its own set of cgroup root directories. These root directories are the base points for the relative locations displayed in the corresponding records in the /proc/pid/cgroup file. When a process creates a new cgroup namespace using clone(2) or unshare(2) with the CLONE_NEWCGROUP flag, its current cgroups directories become the cgroup root directories of the new namespace. (This applies both for the cgroups version 1 hierarchies and the cgroups version 2 unified hierarchy.)

When reading the cgroup memberships of a “target” process from /proc/pid/cgroup, the pathname shown in the third field of each record will be relative to the reading process’s root directory for the corresponding cgroup hierarchy. If the cgroup directory of the target process lies outside the root directory of the reading process’s cgroup namespace, then the pathname will show ../ entries for each ancestor level in the cgroup hierarchy.

The following shell session demonstrates the effect of creating a new cgroup namespace.

First, (as superuser) in a shell in the initial cgroup namespace, we create a child cgroup in the freezer hierarchy, and place a process in that cgroup that we will use as part of the demonstration below:

# mkdir -p /sys/fs/cgroup/freezer/sub2
# sleep 10000 &     # Create a process that lives for a while
[1] 20124
# echo 20124 > /sys/fs/cgroup/freezer/sub2/cgroup.procs

We then create another child cgroup in the freezer hierarchy and put the shell into that cgroup:

# mkdir -p /sys/fs/cgroup/freezer/sub
# echo $$                      # Show PID of this shell
30655
# echo 30655 > /sys/fs/cgroup/freezer/sub/cgroup.procs
# cat /proc/self/cgroup | grep freezer
7:freezer:/sub

Next, we use unshare(1) to create a process running a new shell in new cgroup and mount namespaces:

# PS1="sh2# " unshare -Cm bash

From the new shell started by unshare(1), we then inspect the /proc/pid/cgroup files of, respectively, the new shell, a process that is in the initial cgroup namespace (init, with PID 1), and the process in the sibling cgroup (sub2):

sh2# cat /proc/self/cgroup | grep freezer
7:freezer:/
sh2# cat /proc/1/cgroup | grep freezer
7:freezer:/..
sh2# cat /proc/20124/cgroup | grep freezer
7:freezer:/../sub2

From the output of the first command, we see that the freezer cgroup membership of the new shell (which is in the same cgroup as the initial shell) is shown defined relative to the freezer cgroup root directory that was established when the new cgroup namespace was created. (In absolute terms, the new shell is in the /sub freezer cgroup, and the root directory of the freezer cgroup hierarchy in the new cgroup namespace is also /sub. Thus, the new shell’s cgroup membership is displayed as ‘/’.)

However, when we look in /proc/self/mountinfo we see the following anomaly:

sh2# cat /proc/self/mountinfo | grep freezer
155 145 0:32 /.. /sys/fs/cgroup/freezer ...

The fourth field of this line (/..) should show the directory in the cgroup filesystem which forms the root of this mount. Since by the definition of cgroup namespaces, the process’s current freezer cgroup directory became its root freezer cgroup directory, we should see ‘/’ in this field. The problem here is that we are seeing a mount entry for the cgroup filesystem corresponding to the initial cgroup namespace (whose cgroup filesystem is indeed rooted at the parent directory of sub). To fix this problem, we must remount the freezer cgroup filesystem from the new shell (i.e., perform the mount from a process that is in the new cgroup namespace), after which we see the expected results:

sh2# mount --make-rslave /     # Don't propagate mount events
                               # to other namespaces
sh2# umount /sys/fs/cgroup/freezer
sh2# mount -t cgroup -o freezer freezer /sys/fs/cgroup/freezer
sh2# cat /proc/self/mountinfo | grep freezer
155 145 0:32 / /sys/fs/cgroup/freezer rw,relatime ...

STANDARDS

Linux.

NOTES

Use of cgroup namespaces requires a kernel that is configured with the CONFIG_CGROUPS option.

The virtualization provided by cgroup namespaces serves a number of purposes:

  • It prevents information leaks whereby cgroup directory paths outside of a container would otherwise be visible to processes in the container. Such leakages could, for example, reveal information about the container framework to containerized applications.

  • It eases tasks such as container migration. The virtualization provided by cgroup namespaces allows containers to be isolated from knowledge of the pathnames of ancestor cgroups. Without such isolation, the full cgroup pathnames (displayed in /proc/self/cgroups) would need to be replicated on the target system when migrating a container; those pathnames would also need to be unique, so that they don’t conflict with other pathnames on the target system.

  • It allows better confinement of containerized processes, because it is possible to mount the container’s cgroup filesystems such that the container processes can’t gain access to ancestor cgroup directories. Consider, for example, the following scenario:

    • We have a cgroup directory, /cg/1, that is owned by user ID 9000.

    • We have a process, X, also owned by user ID 9000, that is namespaced under the cgroup /cg/1/2 (i.e., X was placed in a new cgroup namespace via clone(2) or unshare(2) with the CLONE_NEWCGROUP flag).

    In the absence of cgroup namespacing, because the cgroup directory /cg/1 is owned (and writable) by UID 9000 and process X is also owned by user ID 9000, process X would be able to modify the contents of cgroups files (i.e., change cgroup settings) not only in /cg/1/2 but also in the ancestor cgroup directory /cg/1. Namespacing process X under the cgroup directory /cg/1/2, in combination with suitable mount operations for the cgroup filesystem (as shown above), prevents it modifying files in /cg/1, since it cannot even see the contents of that directory (or of further removed cgroup ancestor directories). Combined with correct enforcement of hierarchical limits, this prevents process X from escaping the limits imposed by ancestor cgroups.

SEE ALSO

unshare(1), clone(2), setns(2), unshare(2), proc(5), cgroups(7), credentials(7), namespaces(7), user_namespaces(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

411 - Linux cli command aio

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command aio and provides detailed information about the command aio, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the aio.

NAME 🖥️ aio 🖥️

POSIX asynchronous I/O overview

DESCRIPTION

The POSIX asynchronous I/O (AIO) interface allows applications to initiate one or more I/O operations that are performed asynchronously (i.e., in the background). The application can elect to be notified of completion of the I/O operation in a variety of ways: by delivery of a signal, by instantiation of a thread, or no notification at all.

The POSIX AIO interface consists of the following functions:

aio_read(3)
Enqueue a read request. This is the asynchronous analog of read(2).

aio_write(3)
Enqueue a write request. This is the asynchronous analog of write(2).

aio_fsync(3)
Enqueue a sync request for the I/O operations on a file descriptor. This is the asynchronous analog of fsync(2) and fdatasync(2).

aio_error(3)
Obtain the error status of an enqueued I/O request.

aio_return(3)
Obtain the return status of a completed I/O request.

aio_suspend(3)
Suspend the caller until one or more of a specified set of I/O requests completes.

aio_cancel(3)
Attempt to cancel outstanding I/O requests on a specified file descriptor.

lio_listio(3)
Enqueue multiple I/O requests using a single function call.

The aiocb (“asynchronous I/O control block”) structure defines parameters that control an I/O operation. An argument of this type is employed with all of the functions listed above. This structure has the following form:

#include <aiocb.h>
struct aiocb {
    /* The order of these fields is implementation-dependent */
    int             aio_fildes;     /* File descriptor */
    off_t           aio_offset;     /* File offset */
    volatile void  *aio_buf;        /* Location of buffer */
    size_t          aio_nbytes;     /* Length of transfer */
    int             aio_reqprio;    /* Request priority */
    struct sigevent aio_sigevent;   /* Notification method */
    int             aio_lio_opcode; /* Operation to be performed;
                                       lio_listio() only */
    /* Various implementation-internal fields not shown */
};
/* Operation codes for 'aio_lio_opcode': */
enum { LIO_READ, LIO_WRITE, LIO_NOP };

The fields of this structure are as follows:

aio_fildes
The file descriptor on which the I/O operation is to be performed.

aio_offset
This is the file offset at which the I/O operation is to be performed.

aio_buf
This is the buffer used to transfer data for a read or write operation.

aio_nbytes
This is the size of the buffer pointed to by aio_buf.

aio_reqprio
This field specifies a value that is subtracted from the calling thread’s real-time priority in order to determine the priority for execution of this I/O request (see pthread_setschedparam(3)). The specified value must be between 0 and the value returned by sysconf(_SC_AIO_PRIO_DELTA_MAX). This field is ignored for file synchronization operations.

aio_sigevent
This field is a structure that specifies how the caller is to be notified when the asynchronous I/O operation completes. Possible values for aio_sigevent.sigev_notify are SIGEV_NONE, SIGEV_SIGNAL, and SIGEV_THREAD. See sigevent(3type) for further details.

aio_lio_opcode
The type of operation to be performed; used only for lio_listio(3).

In addition to the standard functions listed above, the GNU C library provides the following extension to the POSIX AIO API:

aio_init(3)
Set parameters for tuning the behavior of the glibc POSIX AIO implementation.

ERRORS

EINVAL
The aio_reqprio field of the aiocb structure was less than 0, or was greater than the limit returned by the call sysconf(_SC_AIO_PRIO_DELTA_MAX).

STANDARDS

POSIX.1-2008.

HISTORY

POSIX.1-2001. glibc 2.1.

NOTES

It is a good idea to zero out the control block buffer before use (see memset(3)). The control block buffer and the buffer pointed to by aio_buf must not be changed while the I/O operation is in progress. These buffers must remain valid until the I/O operation completes.

Simultaneous asynchronous read or write operations using the same aiocb structure yield undefined results.

The current Linux POSIX AIO implementation is provided in user space by glibc. This has a number of limitations, most notably that maintaining multiple threads to perform I/O operations is expensive and scales poorly. Work has been in progress for some time on a kernel state-machine-based implementation of asynchronous I/O (see io_submit(2), io_setup(2), io_cancel(2), io_destroy(2), io_getevents(2)), but this implementation hasn’t yet matured to the point where the POSIX AIO implementation can be completely reimplemented using the kernel system calls.

EXAMPLES

The program below opens each of the files named in its command-line arguments and queues a request on the resulting file descriptor using aio_read(3). The program then loops, periodically monitoring each of the I/O operations that is still in progress using aio_error(3). Each of the I/O requests is set up to provide notification by delivery of a signal. After all I/O requests have completed, the program retrieves their status using aio_return(3).

The SIGQUIT signal (generated by typing control-\ causes the program to request cancelation of each of the outstanding requests using aio_cancel(3).

Here is an example of what we might see when running this program. In this example, the program queues two requests to standard input, and these are satisfied by two lines of input containing “abc” and “x”.

$ ./a.out /dev/stdin /dev/stdin
opened /dev/stdin on descriptor 3
opened /dev/stdin on descriptor 4
aio_error():
    for request 0 (descriptor 3): In progress
    for request 1 (descriptor 4): In progress
abc
I/O completion signal received
aio_error():
    for request 0 (descriptor 3): I/O succeeded
    for request 1 (descriptor 4): In progress
aio_error():
    for request 1 (descriptor 4): In progress
x
I/O completion signal received
aio_error():
    for request 1 (descriptor 4): I/O succeeded
All I/O requests completed
aio_return():
    for request 0 (descriptor 3): 4
    for request 1 (descriptor 4): 2

Program source

#include <fcntl.h>
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <errno.h>
#include <aio.h>
#include <signal.h>
#define BUF_SIZE 20     /* Size of buffers for read operations */
#define errExit(msg) do { perror(msg); exit(EXIT_FAILURE); } while (0)
struct ioRequest {      /* Application-defined structure for tracking
                           I/O requests */
    int           reqNum;
    int           status;
    struct aiocb *aiocbp;
};
static volatile sig_atomic_t gotSIGQUIT = 0;
                        /* On delivery of SIGQUIT, we attempt to
                           cancel all outstanding I/O requests */
static void             /* Handler for SIGQUIT */
quitHandler(int sig)
{
    gotSIGQUIT = 1;
}
#define IO_SIGNAL SIGUSR1   /* Signal used to notify I/O completion */
static void                 /* Handler for I/O completion signal */
aioSigHandler(int sig, siginfo_t *si, void *ucontext)
{
    if (si->si_code == SI_ASYNCIO) {
        write(STDOUT_FILENO, "I/O completion signal received

“, 31); /* The corresponding ioRequest structure would be available as struct ioRequest *ioReq = si->si_value.sival_ptr; and the file descriptor would then be available via ioReq->aiocbp->aio_fildes */ } } int main(int argc, char argv[]) { struct sigaction sa; int s; int numReqs; / Total number of queued I/O requests / int openReqs; / Number of I/O requests still in progress / if (argc < 2) { fprintf(stderr, “Usage: %s … “, argv[0]); exit(EXIT_FAILURE); } numReqs = argc - 1; / Allocate our arrays. */ struct ioRequest *ioList = calloc(numReqs, sizeof(*ioList)); if (ioList == NULL) errExit(“calloc”); struct aiocb *aiocbList = calloc(numReqs, sizeof(aiocbList)); if (aiocbList == NULL) errExit(“calloc”); / Establish handlers for SIGQUIT and the I/O completion signal. / sa.sa_flags = SA_RESTART; sigemptyset(&sa.sa_mask); sa.sa_handler = quitHandler; if (sigaction(SIGQUIT, &sa, NULL) == -1) errExit(“sigaction”); sa.sa_flags = SA_RESTART | SA_SIGINFO; sa.sa_sigaction = aioSigHandler; if (sigaction(IO_SIGNAL, &sa, NULL) == -1) errExit(“sigaction”); / Open each file specified on the command line, and queue a read request on the resulting file descriptor. / for (size_t j = 0; j < numReqs; j++) { ioList[j].reqNum = j; ioList[j].status = EINPROGRESS; ioList[j].aiocbp = &aiocbList[j]; ioList[j].aiocbp->aio_fildes = open(argv[j + 1], O_RDONLY); if (ioList[j].aiocbp->aio_fildes == -1) errExit(“open”); printf(“opened %s on descriptor %d “, argv[j + 1], ioList[j].aiocbp->aio_fildes); ioList[j].aiocbp->aio_buf = malloc(BUF_SIZE); if (ioList[j].aiocbp->aio_buf == NULL) errExit(“malloc”); ioList[j].aiocbp->aio_nbytes = BUF_SIZE; ioList[j].aiocbp->aio_reqprio = 0; ioList[j].aiocbp->aio_offset = 0; ioList[j].aiocbp->aio_sigevent.sigev_notify = SIGEV_SIGNAL; ioList[j].aiocbp->aio_sigevent.sigev_signo = IO_SIGNAL; ioList[j].aiocbp->aio_sigevent.sigev_value.sival_ptr = &ioList[j]; s = aio_read(ioList[j].aiocbp); if (s == -1) errExit(“aio_read”); } openReqs = numReqs; / Loop, monitoring status of I/O requests. / while (openReqs > 0) { sleep(3); / Delay between each monitoring step / if (gotSIGQUIT) { / On receipt of SIGQUIT, attempt to cancel each of the outstanding I/O requests, and display status returned from the cancelation requests. / printf(“got SIGQUIT; canceling I/O requests: “); for (size_t j = 0; j < numReqs; j++) { if (ioList[j].status == EINPROGRESS) { printf(” Request %zu on descriptor %d:”, j, ioList[j].aiocbp->aio_fildes); s = aio_cancel(ioList[j].aiocbp->aio_fildes, ioList[j].aiocbp); if (s == AIO_CANCELED) printf(“I/O canceled “); else if (s == AIO_NOTCANCELED) printf(“I/O not canceled “); else if (s == AIO_ALLDONE) printf(“I/O all done “); else perror(“aio_cancel”); } } gotSIGQUIT = 0; } / Check the status of each I/O request that is still in progress. / printf(“aio_error(): “); for (size_t j = 0; j < numReqs; j++) { if (ioList[j].status == EINPROGRESS) { printf(” for request %zu (descriptor %d): “, j, ioList[j].aiocbp->aio_fildes); ioList[j].status = aio_error(ioList[j].aiocbp); switch (ioList[j].status) { case 0: printf(“I/O succeeded “); break; case EINPROGRESS: printf(“In progress “); break; case ECANCELED: printf(“Canceled “); break; default: perror(“aio_error”); break; } if (ioList[j].status != EINPROGRESS) openReqs–; } } } printf(“All I/O requests completed “); / Check status return of all I/O requests. */ printf(“aio_return(): “); for (size_t j = 0; j < numReqs; j++) { ssize_t s; s = aio_return(ioList[j].aiocbp); printf(” for request %zu (descriptor %d): %zd “, j, ioList[j].aiocbp->aio_fildes, s); } exit(EXIT_SUCCESS); }

SEE ALSO

io_cancel(2), io_destroy(2), io_getevents(2), io_setup(2), io_submit(2), aio_cancel(3), aio_error(3), aio_init(3), aio_read(3), aio_return(3), aio_write(3), lio_listio(3)

“Asynchronous I/O Support in Linux 2.5”, Bhattacharya, Pratt, Pulavarty, and Morgan, Proceedings of the Linux Symposium, 2003, 

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

412 - Linux cli command EVP_KEYMGMT-RSAssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KEYMGMT-RSAssl and provides detailed information about the command EVP_KEYMGMT-RSAssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KEYMGMT-RSAssl.

NAME 🖥️ EVP_KEYMGMT-RSAssl 🖥️

RSA, EVP_KEYMGMT-RSA, RSA - EVP_PKEY RSA keytype and algorithm support

DESCRIPTION

The RSA keytype is implemented in OpenSSL’s default and FIPS providers. That implementation supports the basic RSA keys, containing the modulus n, the public exponent e, the private exponent d, and a collection of prime factors, exponents and coefficient for CRT calculations, of which the first few are known as p and q, dP and dQ, and qInv.

Common RSA parameters

In addition to the common parameters that all keytypes should support (see “Common parameters” in provider-keymgmt (7)), the RSA keytype implementation supports the following.

“n” (OSSL_PKEY_PARAM_RSA_N) <unsigned integer>
The RSA modulus “n” value.

“e” (OSSL_PKEY_PARAM_RSA_E) <unsigned integer>
The RSA public exponent “e” value. This value must always be set when creating a raw key using EVP_PKEY_fromdata (3). Note that when a decryption operation is performed, that this value is used for blinding purposes to prevent timing attacks.

“d” (OSSL_PKEY_PARAM_RSA_D) <unsigned integer>
The RSA private exponent “d” value.

“rsa-factor1” (OSSL_PKEY_PARAM_RSA_FACTOR1) <unsigned integer>

“rsa-factor2” (OSSL_PKEY_PARAM_RSA_FACTOR2) <unsigned integer>

“rsa-factor3” (OSSL_PKEY_PARAM_RSA_FACTOR3) <unsigned integer>

“rsa-factor4” (OSSL_PKEY_PARAM_RSA_FACTOR4) <unsigned integer>

“rsa-factor5” (OSSL_PKEY_PARAM_RSA_FACTOR5) <unsigned integer>

“rsa-factor6” (OSSL_PKEY_PARAM_RSA_FACTOR6) <unsigned integer>

“rsa-factor7” (OSSL_PKEY_PARAM_RSA_FACTOR7) <unsigned integer>

“rsa-factor8” (OSSL_PKEY_PARAM_RSA_FACTOR8) <unsigned integer>

“rsa-factor9” (OSSL_PKEY_PARAM_RSA_FACTOR9) <unsigned integer>

“rsa-factor10” (OSSL_PKEY_PARAM_RSA_FACTOR10) <unsigned integer>

RSA prime factors. The factors are known as “p”, “q” and “r_i” in RFC8017. Up to eight additional “r_i” prime factors are supported.

“rsa-exponent1” (OSSL_PKEY_PARAM_RSA_EXPONENT1) <unsigned integer>

“rsa-exponent2” (OSSL_PKEY_PARAM_RSA_EXPONENT2) <unsigned integer>

“rsa-exponent3” (OSSL_PKEY_PARAM_RSA_EXPONENT3) <unsigned integer>

“rsa-exponent4” (OSSL_PKEY_PARAM_RSA_EXPONENT4) <unsigned integer>

“rsa-exponent5” (OSSL_PKEY_PARAM_RSA_EXPONENT5) <unsigned integer>

“rsa-exponent6” (OSSL_PKEY_PARAM_RSA_EXPONENT6) <unsigned integer>

“rsa-exponent7” (OSSL_PKEY_PARAM_RSA_EXPONENT7) <unsigned integer>

“rsa-exponent8” (OSSL_PKEY_PARAM_RSA_EXPONENT8) <unsigned integer>

“rsa-exponent9” (OSSL_PKEY_PARAM_RSA_EXPONENT9) <unsigned integer>

“rsa-exponent10” (OSSL_PKEY_PARAM_RSA_EXPONENT10) <unsigned integer>

RSA CRT (Chinese Remainder Theorem) exponents. The exponents are known as “dP”, “dQ” and “d_i” in RFC8017. Up to eight additional “d_i” exponents are supported.

“rsa-coefficient1” (OSSL_PKEY_PARAM_RSA_COEFFICIENT1) <unsigned integer>

“rsa-coefficient2” (OSSL_PKEY_PARAM_RSA_COEFFICIENT2) <unsigned integer>

“rsa-coefficient3” (OSSL_PKEY_PARAM_RSA_COEFFICIENT3) <unsigned integer>

“rsa-coefficient4” (OSSL_PKEY_PARAM_RSA_COEFFICIENT4) <unsigned integer>

“rsa-coefficient5” (OSSL_PKEY_PARAM_RSA_COEFFICIENT5) <unsigned integer>

“rsa-coefficient6” (OSSL_PKEY_PARAM_RSA_COEFFICIENT6) <unsigned integer>

“rsa-coefficient7” (OSSL_PKEY_PARAM_RSA_COEFFICIENT7) <unsigned integer>

“rsa-coefficient8” (OSSL_PKEY_PARAM_RSA_COEFFICIENT8) <unsigned integer>

“rsa-coefficient9” (OSSL_PKEY_PARAM_RSA_COEFFICIENT9) <unsigned integer>

RSA CRT (Chinese Remainder Theorem) coefficients. The coefficients are known as “qInv” and “t_i”. Up to eight additional “t_i” exponents are supported.

RSA key generation parameters

When generating RSA keys, the following key generation parameters may be used.

“bits” (OSSL_PKEY_PARAM_RSA_BITS) <unsigned integer>
The value should be the cryptographic length for the RSA cryptosystem, in bits.

“primes” (OSSL_PKEY_PARAM_RSA_PRIMES) <unsigned integer>
The value should be the number of primes for the generated RSA key. The default is 2. It isn’t permitted to specify a larger number of primes than 10. Additionally, the number of primes is limited by the length of the key being generated so the maximum number could be less. Some providers may only support a value of 2.

“e” (OSSL_PKEY_PARAM_RSA_E) <unsigned integer>
The RSA “e” value. The value may be any odd number greater than or equal to 65537. The default value is 65537. For legacy reasons a value of 3 is currently accepted but is deprecated.

RSA key generation parameters for FIPS module testing

When generating RSA keys, the following additional key generation parameters may be used for algorithm testing purposes only. Do not use these to generate RSA keys for a production environment.

“xp” (OSSL_PKEY_PARAM_RSA_TEST_XP) <unsigned integer>

“xq” (OSSL_PKEY_PARAM_RSA_TEST_XQ) <unsigned integer>

These 2 fields are normally randomly generated and are used to generate “p” and “q”.

“xp1” (OSSL_PKEY_PARAM_RSA_TEST_XP1) <unsigned integer>

“xp2” (OSSL_PKEY_PARAM_RSA_TEST_XP2) <unsigned integer>

“xq1” (OSSL_PKEY_PARAM_RSA_TEST_XQ1) <unsigned integer>

“xq2” (OSSL_PKEY_PARAM_RSA_TEST_XQ2) <unsigned integer>

These 4 fields are normally randomly generated. The prime factors “p1”, “p2”, “q1” and “q2” are determined from these values.

RSA key parameters for FIPS module testing

The following intermediate values can be retrieved only if the values specified in “RSA key generation parameters for FIPS module testing” are set. These should not be accessed in a production environment.

“p1” (OSSL_PKEY_PARAM_RSA_TEST_P1) <unsigned integer>

“p2” (OSSL_PKEY_PARAM_RSA_TEST_P2) <unsigned integer>

“q1” (OSSL_PKEY_PARAM_RSA_TEST_Q1) <unsigned integer>

“q2” (OSSL_PKEY_PARAM_RSA_TEST_Q2) <unsigned integer>

The auxiliary probable primes.

RSA key validation

For RSA keys, EVP_PKEY_param_check (3) and EVP_PKEY_param_check_quick (3) both return 1 unconditionally.

For RSA keys, EVP_PKEY_public_check (3) conforms to the SP800-56Br1 public key check when the OpenSSL FIPS provider is used. The OpenSSL default provider performs similar tests but relaxes the keysize restrictions for backwards compatibility.

For RSA keys, EVP_PKEY_public_check_quick (3) is the same as EVP_PKEY_public_check (3).

For RSA keys, EVP_PKEY_private_check (3) conforms to the SP800-56Br1 private key test.

For RSA keys, EVP_PKEY_pairwise_check (3) conforms to the SP800-56Br1 KeyPair Validation check for the OpenSSL FIPS provider. The OpenSSL default provider allows testing of the validity of multi-primes.

CONFORMING TO

FIPS186-4
Section B.3.6 Generation of Probable Primes with Conditions Based on Auxiliary Probable Primes

RFC 8017, excluding RSA-PSS and RSA-OAEP

EXAMPLES

An EVP_PKEY context can be obtained by calling:

EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “RSA”, NULL);

An RSA key can be generated simply like this:

pkey = EVP_RSA_gen(4096);

or like this:

EVP_PKEY *pkey = NULL; EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “RSA”, NULL); EVP_PKEY_keygen_init(pctx); EVP_PKEY_generate(pctx, &pkey); EVP_PKEY_CTX_free(pctx);

An RSA key can be generated with key generation parameters:

unsigned int primes = 3; unsigned int bits = 4096; OSSL_PARAM params[3]; EVP_PKEY *pkey = NULL; EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “RSA”, NULL); EVP_PKEY_keygen_init(pctx); params[0] = OSSL_PARAM_construct_uint(“bits”, &bits); params[1] = OSSL_PARAM_construct_uint(“primes”, &primes); params[2] = OSSL_PARAM_construct_end(); EVP_PKEY_CTX_set_params(pctx, params); EVP_PKEY_generate(pctx, &pkey); EVP_PKEY_print_private(bio_out, pkey, 0, NULL); EVP_PKEY_CTX_free(pctx);

SEE ALSO

EVP_RSA_gen (3), EVP_KEYMGMT (3), EVP_PKEY (3), provider-keymgmt (7)

COPYRIGHT

Copyright 2020-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

413 - Linux cli command EVP_KDF-HMAC-DRBGssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KDF-HMAC-DRBGssl and provides detailed information about the command EVP_KDF-HMAC-DRBGssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KDF-HMAC-DRBGssl.

NAME 🖥️ EVP_KDF-HMAC-DRBGssl 🖥️

HMAC-DRBG - The HMAC DRBG DETERMINISTIC EVP_KDF implementation

DESCRIPTION

Support for a deterministic HMAC DRBG using the EVP_KDF API. This is similar to EVP_RAND-HMAC-DRBG (7), but uses fixed values for its entropy and nonce values. This is used to generate deterministic nonce value required by ECDSA and DSA (as defined in RFC 6979).

Identity

“HMAC-DRBG-KDF” is the name for this implementation; it can be used with the EVP_KDF_fetch() function.

Supported parameters

The supported parameters are:

“digest” (OSSL_DRBG_PARAM_DIGEST) <UTF8 string>

“properties” (OSSL_DRBG_PARAM_PROPERTIES) <UTF8 string>

These parameters work as described in “PARAMETERS” in EVP_KDF (3).

“entropy” (OSSL_KDF_PARAM_HMACDRBG_ENTROPY) <octet string>
Sets the entropy bytes supplied to the HMAC-DRBG.

“nonce” (OSSL_KDF_PARAM_HMACDRBG_NONCE) <octet string>
Sets the nonce bytes supplied to the HMAC-DRBG.

NOTES

A context for KDF HMAC DRBG can be obtained by calling:

EVP_KDF *kdf = EVP_KDF_fetch(NULL, “HMAC-DRBG-KDF”, NULL); EVP_KDF_CTX *kdf_ctx = EVP_KDF_CTX_new(kdf, NULL);

CONFORMING TO

RFC 6979

SEE ALSO

EVP_KDF (3), “PARAMETERS” in EVP_KDF (3)

HISTORY

The EVP_KDF-HMAC-DRBG functionality was added in OpenSSL 3.2.

COPYRIGHT

Copyright 2022-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

414 - Linux cli command systemd.journal-fields

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command systemd.journal-fields and provides detailed information about the command systemd.journal-fields, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the systemd.journal-fields.

NAME 🖥️ systemd.journal-fields 🖥️

fields - Special journal fields

DESCRIPTION

Entries in the journal (as written by systemd-journald.service(8)) resemble a UNIX process environment block in syntax but with field values that may include binary data, and with non-unique field names permitted. Primarily, field values are formatted UTF-8 text strings — binary encoding is used only where formatting as UTF-8 text strings makes little sense. New fields may freely be defined by applications, but a few fields have special meanings, which are listed below. Typically, fields may only appear once per log entry, however there are special exceptions: some fields may appear more than once per entry, in which case this is explicitly mentioned below. Even though the logging subsystem makes no restrictions on which fields to accept non-unique values for, it is strongly recommended to avoid relying on this for the fields listed below (except where listed otherwise, as mentioned) in order to avoid unnecessary incompatibilities with other applications.

USER JOURNAL FIELDS

User fields are fields that are directly passed from clients and stored in the journal.

MESSAGE=

The human-readable message string for this entry. This is supposed to be the primary text shown to the user. It is usually not translated (but might be in some cases), and is not supposed to be parsed for metadata. In order to encode multiple lines in a single log entry, separate them by newline characters (ASCII code 10), but encode them as a single MESSAGE= field. Do not add multiple values of this field type to the same entry (also see above), as consuming applications generally do not expect this and are unlikely to show all values in that case.

MESSAGE_ID=

A 128-bit message identifier ID for recognizing certain message types, if this is desirable. This should contain a 128-bit ID formatted as a lower-case hexadecimal string, without any separating dashes or suchlike. This is recommended to be a UUID-compatible ID, but this is not enforced, and formatted differently. Developers can generate a new ID for this purpose with systemd-id128 new.

PRIORITY=

A priority value between 0 (“emerg”) and 7 (“debug”) formatted as a decimal string. This field is compatible with syslogs priority concept.

CODE_FILE=, CODE_LINE=, CODE_FUNC=

The code location generating this message, if known. Contains the source filename, the line number and the function name.

ERRNO=

The low-level Unix error number causing this entry, if any. Contains the numeric value of errno(3) formatted as a decimal string.

Added in version 188.

INVOCATION_ID=, USER_INVOCATION_ID=

A randomized, unique 128-bit ID identifying each runtime cycle of the unit. This is different from _SYSTEMD_INVOCATION_ID in that it is only used for messages coming from systemd code (e.g. logs from the system/user manager or from forked processes performing systemd-related setup).

Added in version 245.

SYSLOG_FACILITY=, SYSLOG_IDENTIFIER=, SYSLOG_PID=, SYSLOG_TIMESTAMP=

Syslog compatibility fields containing the facility (formatted as decimal string), the identifier string (i.e. “tag”), the client PID, and the timestamp as specified in the original datagram. (Note that the tag is usually derived from glibcs program_invocation_short_name variable, see program_invocation_short_name(3).)

Note that the journal service does not validate the values of any structured journal fields whose name is not prefixed with an underscore, and this includes any syslog related fields such as these. Hence, applications that supply a facility, PID, or log level are expected to do so properly formatted, i.e. as numeric integers formatted as decimal strings.

SYSLOG_RAW=

The original contents of the syslog line as received in the syslog datagram. This field is only included if the MESSAGE= field was modified compared to the original payload or the timestamp could not be located properly and is not included in SYSLOG_TIMESTAMP=. Message truncation occurs when the message contains leading or trailing whitespace (trailing and leading whitespace is stripped), or it contains an embedded NUL byte (the NUL byte and anything after it is not included). Thus, the original syslog line is either stored as SYSLOG_RAW= or it can be recreated based on the stored priority and facility, timestamp, identifier, and the message payload in MESSAGE=.

Added in version 240.

DOCUMENTATION=

A documentation URL with further information about the topic of the log message. Tools such as journalctl will include a hyperlink to a URL specified this way in their output. Should be an “http://”, “https://”, “file:/”, “man:” or “info:” URL.

Added in version 246.

TID=

The numeric thread ID (TID) the log message originates from.

Added in version 247.

UNIT=, USER_UNIT=

The name of a unit. Used by the system and user managers when logging about specific units.

When **–unit=**name or **–user-unit=**name are used with journalctl(1), a match pattern that includes “UNIT=name.service” or “USER_UNIT=name.service” will be generated.

Added in version 251.

TRUSTED JOURNAL FIELDS

Fields prefixed with an underscore are trusted fields, i.e. fields that are implicitly added by the journal and cannot be altered by client code.

_PID=, _UID=, _GID=

The process, user, and group ID of the process the journal entry originates from formatted as a decimal string. Note that entries obtained via “stdout” or “stderr” of forked processes will contain credentials valid for a parent process (that initiated the connection to systemd-journald).

_COMM=, _EXE=, _CMDLINE=

The name, the executable path, and the command line of the process the journal entry originates from.

_CAP_EFFECTIVE=

The effective capabilities(7) of the process the journal entry originates from.

Added in version 206.

_AUDIT_SESSION=, _AUDIT_LOGINUID=

The session and login UID of the process the journal entry originates from, as maintained by the kernel audit subsystem.

_SYSTEMD_CGROUP=, _SYSTEMD_SLICE=, _SYSTEMD_UNIT=, _SYSTEMD_USER_UNIT=, _SYSTEMD_USER_SLICE=, _SYSTEMD_SESSION=, _SYSTEMD_OWNER_UID=

The control group path in the systemd hierarchy, the systemd slice unit name, the systemd unit name, the unit name in the systemd user manager (if any), the systemd session ID (if any), and the owner UID of the systemd user unit or systemd session (if any) of the process the journal entry originates from.

_SELINUX_CONTEXT=

The SELinux security context (label) of the process the journal entry originates from.

_SOURCE_REALTIME_TIMESTAMP=

The earliest trusted timestamp of the message, if any is known that is different from the reception time of the journal. This is the time in microseconds since the epoch UTC, formatted as a decimal string.

_BOOT_ID=

The kernel boot ID for the boot the message was generated in, formatted as a 128-bit hexadecimal string.

_MACHINE_ID=

The machine ID of the originating host, as available in machine-id(5).

_SYSTEMD_INVOCATION_ID=

The invocation ID for the runtime cycle of the unit the message was generated in, as available to processes of the unit in $INVOCATION_ID (see systemd.exec(5)).

Added in version 233.

_HOSTNAME=

The name of the originating host.

_TRANSPORT=

How the entry was received by the journal service. Valid transports are:

audit

for those read from the kernel audit subsystem

Added in version 227.

driver

for internally generated messages

Added in version 205.

syslog

for those received via the local syslog socket with the syslog protocol

Added in version 205.

journal

for those received via the native journal protocol

Added in version 205.

stdout

for those read from a services standard output or error output

Added in version 205.

kernel

for those read from the kernel

Added in version 205.

_STREAM_ID=

Only applies to “_TRANSPORT=stdout” records: specifies a randomized 128-bit ID assigned to the stream connection when it was first created. This ID is useful to reconstruct individual log streams from the log records: all log records carrying the same stream ID originate from the same stream.

Added in version 235.

_LINE_BREAK=

Only applies to “_TRANSPORT=stdout” records: indicates that the log message in the standard output/error stream was not terminated with a normal newline character (" “, i.e. ASCII 10). Specifically, when set this field is one of nul (in case the line was terminated by a NUL byte), line-max (in case the maximum log line length was reached, as configured with LineMax= in journald.conf(5)), eof (if this was the last log record of a stream and the stream ended without a final newline character), or pid-change (if the process which generated the log output changed in the middle of a line). Note that this record is not generated when a normal newline character was used for marking the log line end.

Added in version 235.

_NAMESPACE=

If this file was written by a systemd-journald instance managing a journal namespace that is not the default, this field contains the namespace identifier. See systemd-journald.service(8) for details about journal namespaces.

Added in version 245.

_RUNTIME_SCOPE=

A string field that specifies the runtime scope in which the message was logged. If “initrd”, the log message was processed while the system was running inside the initrd. If “system”, the log message was generated after the system switched execution to the host root filesystem.

Added in version 252.

KERNEL JOURNAL FIELDS

Kernel fields are fields that are used by messages originating in the kernel and stored in the journal.

_KERNEL_DEVICE=

The kernel device name. If the entry is associated to a block device, contains the major and minor numbers of the device node, separated by “:” and prefixed by “b”. Similarly for character devices, but prefixed by “c”. For network devices, this is the interface index prefixed by “n”. For all other devices, this is the subsystem name prefixed by “+”, followed by “:”, followed by the kernel device name.

Added in version 189.

_KERNEL_SUBSYSTEM=

The kernel subsystem name.

Added in version 189.

_UDEV_SYSNAME=

The kernel device name as it shows up in the device tree below /sys/.

Added in version 189.

_UDEV_DEVNODE=

The device node path of this device in /dev/.

Added in version 189.

_UDEV_DEVLINK=

Additional symlink names pointing to the device node in /dev/. This field is frequently set more than once per entry.

Added in version 189.

FIELDS TO LOG ON BEHALF OF A DIFFERENT PROGRAM

Fields in this section are used by programs to specify that they are logging on behalf of another program or unit.

Fields used by the systemd-coredump coredump kernel helper:

COREDUMP_UNIT=, COREDUMP_USER_UNIT=

Used to annotate messages containing coredumps from system and session units. See coredumpctl(1).

Added in version 198.

Privileged programs (currently UID 0) may attach OBJECT_PID= to a message. This will instruct systemd-journald to attach additional fields on behalf of the caller:

OBJECT_PID=PID

PID of the program that this message pertains to.

Added in version 205.

OBJECT_UID=, OBJECT_GID=, OBJECT_COMM=, OBJECT_EXE=, OBJECT_CMDLINE=, OBJECT_AUDIT_SESSION=, OBJECT_AUDIT_LOGINUID=, OBJECT_SYSTEMD_CGROUP=, OBJECT_SYSTEMD_SESSION=, OBJECT_SYSTEMD_OWNER_UID=, OBJECT_SYSTEMD_UNIT=, OBJECT_SYSTEMD_USER_UNIT=

These are additional fields added automatically by systemd-journald. Their meaning is the same as _UID=, _GID=, _COMM=, _EXE=, _CMDLINE=, _AUDIT_SESSION=, _AUDIT_LOGINUID=, _SYSTEMD_CGROUP=, _SYSTEMD_SESSION=, _SYSTEMD_UNIT=, _SYSTEMD_USER_UNIT=, and _SYSTEMD_OWNER_UID= as described above, except that the process identified by PID is described, instead of the process which logged the message.

Added in version 205.

OBJECT_SYSTEMD_INVOCATION_ID=

An additional field added automatically by systemd-journald. The meaning is mostly the same as _SYSTEMD_INVOCATION_ID=, with the difference described above.

Added in version 235.

ADDRESS FIELDS

During serialization into external formats, such as the Journal Export Format[1] or the Journal JSON Format[2], the addresses of journal entries are serialized into fields prefixed with double underscores. Note that these are not proper fields when stored in the journal but for addressing metadata of entries. They cannot be written as part of structured log entries via calls such as sd_journal_send(3). They may also not be used as matches for sd_journal_add_match(3).

__CURSOR=

The cursor for the entry. A cursor is an opaque text string that uniquely describes the position of an entry in the journal and is portable across machines, platforms and journal files.

__REALTIME_TIMESTAMP=

The wallclock time (CLOCK_REALTIME) at the point in time the entry was received by the journal, in microseconds since the epoch UTC, formatted as a decimal string. This has different properties from “_SOURCE_REALTIME_TIMESTAMP=”, as it is usually a bit later but more likely to be monotonic.

__MONOTONIC_TIMESTAMP=

The monotonic time (CLOCK_MONOTONIC) at the point in time the entry was received by the journal in microseconds, formatted as a decimal string. To be useful as an address for the entry, this should be combined with the boot ID in “_BOOT_ID=”.

__SEQNUM=, __SEQNUM_ID=

The sequence number (and associated sequence number ID) of this journal entry in the journal file it originates from. See sd_journal_get_seqnum(3) for details.

Added in version 254.

SEE ALSO

systemd(1), systemd-journald.service(8), journalctl(1), journald.conf(5), sd-journal(3), coredumpctl(1), systemd.directives(7)

NOTES

Journal Export Format

https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-export-format

Journal JSON Format

https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-json-format

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

415 - Linux cli command iso_8859_11

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso_8859_11 and provides detailed information about the command iso_8859_11, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso_8859_11.

NAME 🖥️ iso_8859_11 🖥️

11 - ISO/IEC 8859-11 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-11 encodes the characters used in the Thai language.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-11 characters

The following table displays the characters in ISO/IEC 8859-11 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-11 is the same as TIS (Thai Industrial Standard) 620-2253, commonly known as TIS-620, except for the character in position A0: ISO/IEC 8859-11 defines this as NO-BREAK SPACE, while TIS-620 leaves it undefined.

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

416 - Linux cli command ALTER_FOREIGN_TABLE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_FOREIGN_TABLE and provides detailed information about the command ALTER_FOREIGN_TABLE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_FOREIGN_TABLE.

NAME 🖥️ ALTER_FOREIGN_TABLE 🖥️

change the definition of a foreign table

SYNOPSIS

ALTER FOREIGN TABLE [ IF EXISTS ] [ ONLY ] name [ * ]
    action [, ... ]
ALTER FOREIGN TABLE [ IF EXISTS ] [ ONLY ] name [ * ]
    RENAME [ COLUMN ] column_name TO new_column_name
ALTER FOREIGN TABLE [ IF EXISTS ] name
    RENAME TO new_name
ALTER FOREIGN TABLE [ IF EXISTS ] name
    SET SCHEMA new_schema

where action is one of:

    ADD [ COLUMN ] column_name data_type [ COLLATE collation ] [ column_constraint [ ... ] ]
    DROP [ COLUMN ] [ IF EXISTS ] column_name [ RESTRICT | CASCADE ]
    ALTER [ COLUMN ] column_name [ SET DATA ] TYPE data_type [ COLLATE collation ]
    ALTER [ COLUMN ] column_name SET DEFAULT expression
    ALTER [ COLUMN ] column_name DROP DEFAULT
    ALTER [ COLUMN ] column_name { SET | DROP } NOT NULL
    ALTER [ COLUMN ] column_name SET STATISTICS integer
    ALTER [ COLUMN ] column_name SET ( attribute_option = value [, ... ] )
    ALTER [ COLUMN ] column_name RESET ( attribute_option [, ... ] )
    ALTER [ COLUMN ] column_name SET STORAGE { PLAIN | EXTERNAL | EXTENDED | MAIN | DEFAULT }
    ALTER [ COLUMN ] column_name OPTIONS ( [ ADD | SET | DROP ] option [value] [, ... ])
    ADD table_constraint [ NOT VALID ]
    VALIDATE CONSTRAINT constraint_name
    DROP CONSTRAINT [ IF EXISTS ]  constraint_name [ RESTRICT | CASCADE ]
    DISABLE TRIGGER [ trigger_name | ALL | USER ]
    ENABLE TRIGGER [ trigger_name | ALL | USER ]
    ENABLE REPLICA TRIGGER trigger_name
    ENABLE ALWAYS TRIGGER trigger_name
    SET WITHOUT OIDS
    INHERIT parent_table
    NO INHERIT parent_table
    OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }
    OPTIONS ( [ ADD | SET | DROP ] option [value] [, ... ])

DESCRIPTION

ALTER FOREIGN TABLE changes the definition of an existing foreign table. There are several subforms:

ADD COLUMN

This form adds a new column to the foreign table, using the same syntax as CREATE FOREIGN TABLE. Unlike the case when adding a column to a regular table, nothing happens to the underlying storage: this action simply declares that some new column is now accessible through the foreign table.

DROP COLUMN [ IF EXISTS ]

This form drops a column from a foreign table. You will need to say CASCADE if anything outside the table depends on the column; for example, views. If IF EXISTS is specified and the column does not exist, no error is thrown. In this case a notice is issued instead.

SET DATA TYPE

This form changes the type of a column of a foreign table. Again, this has no effect on any underlying storage: this action simply changes the type that PostgreSQL believes the column to have.

SET/DROP DEFAULT

These forms set or remove the default value for a column. Default values only apply in subsequent INSERT or UPDATE commands; they do not cause rows already in the table to change.

SET/DROP NOT NULL

Mark a column as allowing, or not allowing, null values.

SET STATISTICS

This form sets the per-column statistics-gathering target for subsequent ANALYZE operations. See the similar form of ALTER TABLE for more details.

SET ( attribute_option = value [, … ] )
RESET ( attribute_option [, … ] )

This form sets or resets per-attribute options. See the similar form of ALTER TABLE for more details.

SET STORAGE

This form sets the storage mode for a column. See the similar form of ALTER TABLE for more details. Note that the storage mode has no effect unless the tables foreign-data wrapper chooses to pay attention to it.

ADD table_constraint [ NOT VALID ]

This form adds a new constraint to a foreign table, using the same syntax as CREATE FOREIGN TABLE. Currently only CHECK constraints are supported.

Unlike the case when adding a constraint to a regular table, nothing is done to verify the constraint is correct; rather, this action simply declares that some new condition should be assumed to hold for all rows in the foreign table. (See the discussion in CREATE FOREIGN TABLE.) If the constraint is marked NOT VALID, then it isnt assumed to hold, but is only recorded for possible future use.

VALIDATE CONSTRAINT

This form marks as valid a constraint that was previously marked as NOT VALID. No action is taken to verify the constraint, but future queries will assume that it holds.

DROP CONSTRAINT [ IF EXISTS ]

This form drops the specified constraint on a foreign table. If IF EXISTS is specified and the constraint does not exist, no error is thrown. In this case a notice is issued instead.

DISABLE/ENABLE [ REPLICA | ALWAYS ] TRIGGER

These forms configure the firing of trigger(s) belonging to the foreign table. See the similar form of ALTER TABLE for more details.

SET WITHOUT OIDS

Backward compatibility syntax for removing the oid system column. As oid system columns cannot be added anymore, this never has an effect.

INHERIT parent_table

This form adds the target foreign table as a new child of the specified parent table. See the similar form of ALTER TABLE for more details.

NO INHERIT parent_table

This form removes the target foreign table from the list of children of the specified parent table.

OWNER

This form changes the owner of the foreign table to the specified user.

OPTIONS ( [ ADD | SET | DROP ] option [value] [, … ] )

Change options for the foreign table or one of its columns. ADD, SET, and DROP specify the action to be performed. ADD is assumed if no operation is explicitly specified. Duplicate option names are not allowed (although its OK for a table option and a column option to have the same name). Option names and values are also validated using the foreign data wrapper library.

RENAME

The RENAME forms change the name of a foreign table or the name of an individual column in a foreign table.

SET SCHEMA

This form moves the foreign table into another schema.

All the actions except RENAME and SET SCHEMA can be combined into a list of multiple alterations to apply in parallel. For example, it is possible to add several columns and/or alter the type of several columns in a single command.

If the command is written as ALTER FOREIGN TABLE IF EXISTS … and the foreign table does not exist, no error is thrown. A notice is issued in this case.

You must own the table to use ALTER FOREIGN TABLE. To change the schema of a foreign table, you must also have CREATE privilege on the new schema. To alter the owner, you must be able to SET ROLE to the new owning role, and that role must have CREATE privilege on the tables schema. (These restrictions enforce that altering the owner doesnt do anything you couldnt do by dropping and recreating the table. However, a superuser can alter ownership of any table anyway.) To add a column or alter a column type, you must also have USAGE privilege on the data type.

PARAMETERS

name

The name (possibly schema-qualified) of an existing foreign table to alter. If ONLY is specified before the table name, only that table is altered. If ONLY is not specified, the table and all its descendant tables (if any) are altered. Optionally, * can be specified after the table name to explicitly indicate that descendant tables are included.

column_name

Name of a new or existing column.

new_column_name

New name for an existing column.

new_name

New name for the table.

data_type

Data type of the new column, or new data type for an existing column.

table_constraint

New table constraint for the foreign table.

constraint_name

Name of an existing constraint to drop.

CASCADE

Automatically drop objects that depend on the dropped column or constraint (for example, views referencing the column), and in turn all objects that depend on those objects (see Section 5.14).

RESTRICT

Refuse to drop the column or constraint if there are any dependent objects. This is the default behavior.

trigger_name

Name of a single trigger to disable or enable.

ALL

Disable or enable all triggers belonging to the foreign table. (This requires superuser privilege if any of the triggers are internally generated triggers. The core system does not add such triggers to foreign tables, but add-on code could do so.)

USER

Disable or enable all triggers belonging to the foreign table except for internally generated triggers.

parent_table

A parent table to associate or de-associate with this foreign table.

new_owner

The user name of the new owner of the table.

new_schema

The name of the schema to which the table will be moved.

NOTES

The key word COLUMN is noise and can be omitted.

Consistency with the foreign server is not checked when a column is added or removed with ADD COLUMN or DROP COLUMN, a NOT NULL or CHECK constraint is added, or a column type is changed with SET DATA TYPE. It is the users responsibility to ensure that the table definition matches the remote side.

Refer to CREATE FOREIGN TABLE for a further description of valid parameters.

EXAMPLES

To mark a column as not-null:

ALTER FOREIGN TABLE distributors ALTER COLUMN street SET NOT NULL;

To change options of a foreign table:

ALTER FOREIGN TABLE myschema.distributors OPTIONS (ADD opt1 value, SET opt2 value2, DROP opt3);

COMPATIBILITY

The forms ADD, DROP, and SET DATA TYPE conform with the SQL standard. The other forms are PostgreSQL extensions of the SQL standard. Also, the ability to specify more than one manipulation in a single ALTER FOREIGN TABLE command is an extension.

ALTER FOREIGN TABLE DROP COLUMN can be used to drop the only column of a foreign table, leaving a zero-column table. This is an extension of SQL, which disallows zero-column foreign tables.

SEE ALSO

CREATE FOREIGN TABLE (CREATE_FOREIGN_TABLE(7)), DROP FOREIGN TABLE (DROP_FOREIGN_TABLE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

417 - Linux cli command mq_overview

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command mq_overview and provides detailed information about the command mq_overview, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the mq_overview.

NAME 🖥️ mq_overview 🖥️

overview of POSIX message queues

DESCRIPTION

POSIX message queues allow processes to exchange data in the form of messages. This API is distinct from that provided by System V message queues (msgget(2), msgsnd(2), msgrcv(2), etc.), but provides similar functionality.

Message queues are created and opened using mq_open(3); this function returns a message queue descriptor (mqd_t), which is used to refer to the open message queue in later calls. Each message queue is identified by a name of the form /somename; that is, a null-terminated string of up to NAME_MAX (i.e., 255) characters consisting of an initial slash, followed by one or more characters, none of which are slashes. Two processes can operate on the same queue by passing the same name to mq_open(3).

Messages are transferred to and from a queue using mq_send(3) and mq_receive(3). When a process has finished using the queue, it closes it using mq_close(3), and when the queue is no longer required, it can be deleted using mq_unlink(3). Queue attributes can be retrieved and (in some cases) modified using mq_getattr(3) and mq_setattr(3). A process can request asynchronous notification of the arrival of a message on a previously empty queue using mq_notify(3).

A message queue descriptor is a reference to an open message queue description (see open(2)). After a fork(2), a child inherits copies of its parent’s message queue descriptors, and these descriptors refer to the same open message queue descriptions as the corresponding message queue descriptors in the parent. Corresponding message queue descriptors in the two processes share the flags (mq_flags) that are associated with the open message queue description.

Each message has an associated priority, and messages are always delivered to the receiving process highest priority first. Message priorities range from 0 (low) to sysconf(_SC_MQ_PRIO_MAX) - 1 (high). On Linux, sysconf(_SC_MQ_PRIO_MAX) returns 32768, but POSIX.1 requires only that an implementation support at least priorities in the range 0 to 31; some implementations provide only this range.

The remainder of this section describes some specific details of the Linux implementation of POSIX message queues.

Library interfaces and system calls

In most cases the mq_*() library interfaces listed above are implemented on top of underlying system calls of the same name. Deviations from this scheme are indicated in the following table:

Library interfaceSystem call
mq_close(3)close(2)
mq_getattr(3)mq_getsetattr(2)
mq_notify(3)mq_notify(2)
mq_open(3)mq_open(2)
mq_receive(3)mq_timedreceive(2)
mq_send(3)mq_timedsend(2)
mq_setattr(3)mq_getsetattr(2)
mq_timedreceive(3)mq_timedreceive(2)
mq_timedsend(3)mq_timedsend(2)
mq_unlink(3)mq_unlink(2)

Versions

POSIX message queues have been supported since Linux 2.6.6. glibc support has been provided since glibc 2.3.4.

Kernel configuration

Support for POSIX message queues is configurable via the CONFIG_POSIX_MQUEUE kernel configuration option. This option is enabled by default.

Persistence

POSIX message queues have kernel persistence: if not removed by mq_unlink(3), a message queue will exist until the system is shut down.

Linking

Programs using the POSIX message queue API must be compiled with cc -lrt to link against the real-time library, librt.

/proc interfaces

The following interfaces can be used to limit the amount of kernel memory consumed by POSIX message queues and to set the default attributes for new message queues:

/proc/sys/fs/mqueue/msg_default (since Linux 3.5)
This file defines the value used for a new queue’s mq_maxmsg setting when the queue is created with a call to mq_open(3) where attr is specified as NULL. The default value for this file is 10. The minimum and maximum are as for /proc/sys/fs/mqueue/msg_max. A new queue’s default mq_maxmsg value will be the smaller of msg_default and msg_max. Before Linux 2.6.28, the default mq_maxmsg was 10; from Linux 2.6.28 to Linux 3.4, the default was the value defined for the msg_max limit.

/proc/sys/fs/mqueue/msg_max
This file can be used to view and change the ceiling value for the maximum number of messages in a queue. This value acts as a ceiling on the attr->mq_maxmsg argument given to mq_open(3). The default value for msg_max is 10. The minimum value is 1 (10 before Linux 2.6.28). The upper limit is HARD_MSGMAX. The msg_max limit is ignored for privileged processes (CAP_SYS_RESOURCE), but the HARD_MSGMAX ceiling is nevertheless imposed.

The definition of HARD_MSGMAX has changed across kernel versions:

  • Up to Linux 2.6.32: 131072 / sizeof(void *)

  • Linux 2.6.33 to Linux 3.4: (32768 * sizeof(void *) / 4)

  • Since Linux 3.5: 65,536

/proc/sys/fs/mqueue/msgsize_default (since Linux 3.5)
This file defines the value used for a new queue’s mq_msgsize setting when the queue is created with a call to mq_open(3) where attr is specified as NULL. The default value for this file is 8192 (bytes). The minimum and maximum are as for /proc/sys/fs/mqueue/msgsize_max. If msgsize_default exceeds msgsize_max, a new queue’s default mq_msgsize value is capped to the msgsize_max limit. Before Linux 2.6.28, the default mq_msgsize was 8192; from Linux 2.6.28 to Linux 3.4, the default was the value defined for the msgsize_max limit.

/proc/sys/fs/mqueue/msgsize_max
This file can be used to view and change the ceiling on the maximum message size. This value acts as a ceiling on the attr->mq_msgsize argument given to mq_open(3). The default value for msgsize_max is 8192 bytes. The minimum value is 128 (8192 before Linux 2.6.28). The upper limit for msgsize_max has varied across kernel versions:

  • Before Linux 2.6.28, the upper limit is INT_MAX.

  • From Linux 2.6.28 to Linux 3.4, the limit is 1,048,576.

  • Since Linux 3.5, the limit is 16,777,216 (HARD_MSGSIZEMAX).

The msgsize_max limit is ignored for privileged process (CAP_SYS_RESOURCE), but, since Linux 3.5, the HARD_MSGSIZEMAX ceiling is enforced for privileged processes.

/proc/sys/fs/mqueue/queues_max
This file can be used to view and change the system-wide limit on the number of message queues that can be created. The default value for queues_max is 256. No ceiling is imposed on the queues_max limit; privileged processes (CAP_SYS_RESOURCE) can exceed the limit (but see BUGS).

Resource limit

The RLIMIT_MSGQUEUE resource limit, which places a limit on the amount of space that can be consumed by all of the message queues belonging to a process’s real user ID, is described in getrlimit(2).

Mounting the message queue filesystem

On Linux, message queues are created in a virtual filesystem. (Other implementations may also provide such a feature, but the details are likely to differ.) This filesystem can be mounted (by the superuser) using the following commands:

# mkdir /dev/mqueue
# mount -t mqueue none /dev/mqueue

The sticky bit is automatically enabled on the mount directory.

After the filesystem has been mounted, the message queues on the system can be viewed and manipulated using the commands usually used for files (e.g., ls(1) and rm(1)).

The contents of each file in the directory consist of a single line containing information about the queue:

$ cat /dev/mqueue/mymq
QSIZE:129     NOTIFY:2    SIGNO:0    NOTIFY_PID:8260

These fields are as follows:

QSIZE
Number of bytes of data in all messages in the queue (but see BUGS).

NOTIFY_PID
If this is nonzero, then the process with this PID has used mq_notify(3) to register for asynchronous message notification, and the remaining fields describe how notification occurs.

NOTIFY
Notification method: 0 is SIGEV_SIGNAL; 1 is SIGEV_NONE; and 2 is SIGEV_THREAD.

SIGNO
Signal number to be used for SIGEV_SIGNAL.

Linux implementation of message queue descriptors

On Linux, a message queue descriptor is actually a file descriptor. (POSIX does not require such an implementation.) This means that a message queue descriptor can be monitored using select(2), poll(2), or epoll(7). This is not portable.

The close-on-exec flag (see open(2)) is automatically set on the file descriptor returned by mq_open(2).

IPC namespaces

For a discussion of the interaction of POSIX message queue objects and IPC namespaces, see ipc_namespaces(7).

NOTES

System V message queues (msgget(2), msgsnd(2), msgrcv(2), etc.) are an older API for exchanging messages between processes. POSIX message queues provide a better designed interface than System V message queues; on the other hand POSIX message queues are less widely available (especially on older systems) than System V message queues.

Linux does not currently (Linux 2.6.26) support the use of access control lists (ACLs) for POSIX message queues.

BUGS

Since Linux 3.5 to Linux 3.14, the kernel imposed a ceiling of 1024 (HARD_QUEUESMAX) on the value to which the queues_max limit could be raised, and the ceiling was enforced even for privileged processes. This ceiling value was removed in Linux 3.14, and patches to stable Linux 3.5.x to Linux 3.13.x also removed the ceiling.

As originally implemented (and documented), the QSIZE field displayed the total number of (user-supplied) bytes in all messages in the message queue. Some changes in Linux 3.5 inadvertently changed the behavior, so that this field also included a count of kernel overhead bytes used to store the messages in the queue. This behavioral regression was rectified in Linux 4.2 (and earlier stable kernel series), so that the count once more included just the bytes of user data in messages in the queue.

EXAMPLES

An example of the use of various message queue functions is shown in mq_notify(3).

SEE ALSO

getrlimit(2), mq_getsetattr(2), poll(2), select(2), mq_close(3), mq_getattr(3), mq_notify(3), mq_open(3), mq_receive(3), mq_send(3), mq_unlink(3), epoll(7), namespaces(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

418 - Linux cli command signal-safety

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command signal-safety and provides detailed information about the command signal-safety, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the signal-safety.

NAME 🖥️ signal-safety 🖥️

safety - async-signal-safe functions

DESCRIPTION

An async-signal-safe function is one that can be safely called from within a signal handler. Many functions are not async-signal-safe. In particular, nonreentrant functions are generally unsafe to call from a signal handler.

The kinds of issues that render a function unsafe can be quickly understood when one considers the implementation of the stdio library, all of whose functions are not async-signal-safe.

When performing buffered I/O on a file, the stdio functions must maintain a statically allocated data buffer along with associated counters and indexes (or pointers) that record the amount of data and the current position in the buffer. Suppose that the main program is in the middle of a call to a stdio function such as printf(3) where the buffer and associated variables have been partially updated. If, at that moment, the program is interrupted by a signal handler that also calls printf(3), then the second call to printf(3) will operate on inconsistent data, with unpredictable results.

To avoid problems with unsafe functions, there are two possible choices:

  1. Ensure that (1) the signal handler calls only async-signal-safe functions, and (2) the signal handler itself is reentrant with respect to global variables in the main program.

  2. Block signal delivery in the main program when calling functions that are unsafe or operating on global data that is also accessed by the signal handler.

Generally, the second choice is difficult in programs of any complexity, so the first choice is taken.

POSIX.1 specifies a set of functions that an implementation must make async-signal-safe. (An implementation may provide safe implementations of additional functions, but this is not required by the standard and other implementations may not provide the same guarantees.)

In general, a function is async-signal-safe either because it is reentrant or because it is atomic with respect to signals (i.e., its execution can’t be interrupted by a signal handler).

The set of functions required to be async-signal-safe by POSIX.1 is shown in the following table. The functions not otherwise noted were required to be async-signal-safe in POSIX.1-2001; the table details changes in the subsequent standards.

FunctionNotes
abort(3)Added in POSIX.1-2001 TC1
accept(2)
access(2)
aio_error(3)
aio_return(3)
aio_suspend(3)See notes below
alarm(2)
bind(2)
cfgetispeed(3)
cfgetospeed(3)
cfsetispeed(3)
cfsetospeed(3)
chdir(2)
chmod(2)
chown(2)
clock_gettime(2)
close(2)
connect(2)
creat(2)
dup(2)
dup2(2)
execl(3)Added in POSIX.1-2008; see notes below
execle(3)See notes below
execv(3)Added in POSIX.1-2008
execve(2)
_exit(2)
_Exit(2)
faccessat(2)Added in POSIX.1-2008
fchdir(2)Added in POSIX.1-2008 TC1
fchmod(2)
fchmodat(2)Added in POSIX.1-2008
fchown(2)
fchownat(2)Added in POSIX.1-2008
fcntl(2)
fdatasync(2)
fexecve(3)Added in POSIX.1-2008
ffs(3)Added in POSIX.1-2008 TC2
fork(2)See notes below
fstat(2)
fstatat(2)Added in POSIX.1-2008
fsync(2)
ftruncate(2)
futimens(3)Added in POSIX.1-2008
getegid(2)
geteuid(2)
getgid(2)
getgroups(2)
getpeername(2)
getpgrp(2)
getpid(2)
getppid(2)
getsockname(2)
getsockopt(2)
getuid(2)
htonl(3)Added in POSIX.1-2008 TC2
htons(3)Added in POSIX.1-2008 TC2
kill(2)
link(2)
linkat(2)Added in POSIX.1-2008
listen(2)
longjmp(3)Added in POSIX.1-2008 TC2; see notes below
lseek(2)
lstat(2)
memccpy(3)Added in POSIX.1-2008 TC2
memchr(3)Added in POSIX.1-2008 TC2
memcmp(3)Added in POSIX.1-2008 TC2
memcpy(3)Added in POSIX.1-2008 TC2
memmove(3)Added in POSIX.1-2008 TC2
memset(3)Added in POSIX.1-2008 TC2
mkdir(2)
mkdirat(2)Added in POSIX.1-2008
mkfifo(3)
mkfifoat(3)Added in POSIX.1-2008
mknod(2)Added in POSIX.1-2008
mknodat(2)Added in POSIX.1-2008
ntohl(3)Added in POSIX.1-2008 TC2
ntohs(3)Added in POSIX.1-2008 TC2
open(2)
openat(2)Added in POSIX.1-2008
pause(2)
pipe(2)
poll(2)
posix_trace_event(3)
pselect(2)
pthread_kill(3)Added in POSIX.1-2008 TC1
pthread_self(3)Added in POSIX.1-2008 TC1
pthread_sigmask(3)Added in POSIX.1-2008 TC1
raise(3)
read(2)
readlink(2)
readlinkat(2)Added in POSIX.1-2008
recv(2)
recvfrom(2)
recvmsg(2)
rename(2)
renameat(2)Added in POSIX.1-2008
rmdir(2)
select(2)
sem_post(3)
send(2)
sendmsg(2)
sendto(2)
setgid(2)
setpgid(2)
setsid(2)
setsockopt(2)
setuid(2)
shutdown(2)
sigaction(2)
sigaddset(3)
sigdelset(3)
sigemptyset(3)
sigfillset(3)
sigismember(3)
siglongjmp(3)Added in POSIX.1-2008 TC2; see notes below
signal(2)
sigpause(3)
sigpending(2)
sigprocmask(2)
sigqueue(2)
sigset(3)
sigsuspend(2)
sleep(3)
sockatmark(3)Added in POSIX.1-2001 TC2
socket(2)
socketpair(2)
stat(2)
stpcpy(3)Added in POSIX.1-2008 TC2
stpncpy(3)Added in POSIX.1-2008 TC2
strcat(3)Added in POSIX.1-2008 TC2
strchr(3)Added in POSIX.1-2008 TC2
strcmp(3)Added in POSIX.1-2008 TC2
strcpy(3)Added in POSIX.1-2008 TC2
strcspn(3)Added in POSIX.1-2008 TC2
strlen(3)Added in POSIX.1-2008 TC2
strncat(3)Added in POSIX.1-2008 TC2
strncmp(3)Added in POSIX.1-2008 TC2
strncpy(3)Added in POSIX.1-2008 TC2
strnlen(3)Added in POSIX.1-2008 TC2
strpbrk(3)Added in POSIX.1-2008 TC2
strrchr(3)Added in POSIX.1-2008 TC2
strspn(3)Added in POSIX.1-2008 TC2
strstr(3)Added in POSIX.1-2008 TC2
strtok_r(3)Added in POSIX.1-2008 TC2
symlink(2)
symlinkat(2)Added in POSIX.1-2008
tcdrain(3)
tcflow(3)
tcflush(3)
tcgetattr(3)
tcgetpgrp(3)
tcsendbreak(3)
tcsetattr(3)
tcsetpgrp(3)
time(2)
timer_getoverrun(2)
timer_gettime(2)
timer_settime(2)
times(2)
umask(2)
uname(2)
unlink(2)
unlinkat(2)Added in POSIX.1-2008
utime(2)
utimensat(2)Added in POSIX.1-2008
utimes(2)Added in POSIX.1-2008
wait(2)
waitpid(2)
wcpcpy(3)Added in POSIX.1-2008 TC2
wcpncpy(3)Added in POSIX.1-2008 TC2
wcscat(3)Added in POSIX.1-2008 TC2
wcschr(3)Added in POSIX.1-2008 TC2
wcscmp(3)Added in POSIX.1-2008 TC2
wcscpy(3)Added in POSIX.1-2008 TC2
wcscspn(3)Added in POSIX.1-2008 TC2
wcslen(3)Added in POSIX.1-2008 TC2
wcsncat(3)Added in POSIX.1-2008 TC2
wcsncmp(3)Added in POSIX.1-2008 TC2
wcsncpy(3)Added in POSIX.1-2008 TC2
wcsnlen(3)Added in POSIX.1-2008 TC2
wcspbrk(3)Added in POSIX.1-2008 TC2
wcsrchr(3)Added in POSIX.1-2008 TC2
wcsspn(3)Added in POSIX.1-2008 TC2
wcsstr(3)Added in POSIX.1-2008 TC2
wcstok(3)Added in POSIX.1-2008 TC2
wmemchr(3)Added in POSIX.1-2008 TC2
wmemcmp(3)Added in POSIX.1-2008 TC2
wmemcpy(3)Added in POSIX.1-2008 TC2
wmemmove(3)Added in POSIX.1-2008 TC2
wmemset(3)Added in POSIX.1-2008 TC2
write(2)

Notes:

  • POSIX.1-2001 and POSIX.1-2001 TC2 required the functions fpathconf(3), pathconf(3), and sysconf(3) to be async-signal-safe, but this requirement was removed in POSIX.1-2008.

  • If a signal handler interrupts the execution of an unsafe function, and the handler terminates via a call to longjmp(3) or siglongjmp(3) and the program subsequently calls an unsafe function, then the behavior of the program is undefined.

  • POSIX.1-2001 TC1 clarified that if an application calls fork(2) from a signal handler and any of the fork handlers registered by pthread_atfork(3) calls a function that is not async-signal-safe, the behavior is undefined. A future revision of the standard is likely to remove fork(2) from the list of async-signal-safe functions.

  • Asynchronous signal handlers that call functions which are cancelation points and nest over regions of deferred cancelation may trigger cancelation whose behavior is as if asynchronous cancelation had occurred and may cause application state to become inconsistent.

errno

Fetching and setting the value of errno is async-signal-safe provided that the signal handler saves errno on entry and restores its value before returning.

Deviations in the GNU C library

The following known deviations from the standard occur in the GNU C library:

  • Before glibc 2.24, execl(3) and execle(3) employed realloc(3) internally and were consequently not async-signal-safe. This was fixed in glibc 2.24.

  • The glibc implementation of aio_suspend(3) is not async-signal-safe because it uses pthread_mutex_lock(3) internally.

SEE ALSO

sigaction(2), signal(7), standards(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

419 - Linux cli command ALTER_USER

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_USER and provides detailed information about the command ALTER_USER, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_USER.

NAME 🖥️ ALTER_USER 🖥️

change a database role

SYNOPSIS

ALTER USER role_specification [ WITH ] option [ ... ]

where option can be:

      SUPERUSER | NOSUPERUSER
    | CREATEDB | NOCREATEDB
    | CREATEROLE | NOCREATEROLE
    | INHERIT | NOINHERIT
    | LOGIN | NOLOGIN
    | REPLICATION | NOREPLICATION
    | BYPASSRLS | NOBYPASSRLS
    | CONNECTION LIMIT connlimit
    | [ ENCRYPTED ] PASSWORD password | PASSWORD NULL
    | VALID UNTIL timestamp

ALTER USER name RENAME TO new_name

ALTER USER { role_specification | ALL } [ IN DATABASE database_name ] SET configuration_parameter { TO | = } { value | DEFAULT }
ALTER USER { role_specification | ALL } [ IN DATABASE database_name ] SET configuration_parameter FROM CURRENT
ALTER USER { role_specification | ALL } [ IN DATABASE database_name ] RESET configuration_parameter
ALTER USER { role_specification | ALL } [ IN DATABASE database_name ] RESET ALL

where role_specification can be:

    role_name
  | CURRENT_ROLE
  | CURRENT_USER
  | SESSION_USER

DESCRIPTION

ALTER USER is now an alias for ALTER ROLE.

COMPATIBILITY

The ALTER USER statement is a PostgreSQL extension. The SQL standard leaves the definition of users to the implementation.

SEE ALSO

ALTER ROLE (ALTER_ROLE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

420 - Linux cli command CREATE_USER_MAPPING

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_USER_MAPPING and provides detailed information about the command CREATE_USER_MAPPING, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_USER_MAPPING.

NAME 🖥️ CREATE_USER_MAPPING 🖥️

define a new mapping of a user to a foreign server

SYNOPSIS

CREATE USER MAPPING [ IF NOT EXISTS ] FOR { user_name | USER | CURRENT_ROLE | CURRENT_USER | PUBLIC }
    SERVER server_name
    [ OPTIONS ( option value [ , ... ] ) ]

DESCRIPTION

CREATE USER MAPPING defines a mapping of a user to a foreign server. A user mapping typically encapsulates connection information that a foreign-data wrapper uses together with the information encapsulated by a foreign server to access an external data resource.

The owner of a foreign server can create user mappings for that server for any user. Also, a user can create a user mapping for their own user name if USAGE privilege on the server has been granted to the user.

PARAMETERS

IF NOT EXISTS

Do not throw an error if a mapping of the given user to the given foreign server already exists. A notice is issued in this case. Note that there is no guarantee that the existing user mapping is anything like the one that would have been created.

user_name

The name of an existing user that is mapped to foreign server. CURRENT_ROLE, CURRENT_USER, and USER match the name of the current user. When PUBLIC is specified, a so-called public mapping is created that is used when no user-specific mapping is applicable.

server_name

The name of an existing server for which the user mapping is to be created.

OPTIONS ( option value [, … ] )

This clause specifies the options of the user mapping. The options typically define the actual user name and password of the mapping. Option names must be unique. The allowed option names and values are specific to the servers foreign-data wrapper.

EXAMPLES

Create a user mapping for user bob, server foo:

CREATE USER MAPPING FOR bob SERVER foo OPTIONS (user bob, password secret);

COMPATIBILITY

CREATE USER MAPPING conforms to ISO/IEC 9075-9 (SQL/MED).

SEE ALSO

ALTER USER MAPPING (ALTER_USER_MAPPING(7)), DROP USER MAPPING (DROP_USER_MAPPING(7)), CREATE FOREIGN DATA WRAPPER (CREATE_FOREIGN_DATA_WRAPPER(7)), CREATE SERVER (CREATE_SERVER(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

421 - Linux cli command CREATE_RULE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_RULE and provides detailed information about the command CREATE_RULE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_RULE.

NAME 🖥️ CREATE_RULE 🖥️

define a new rewrite rule

SYNOPSIS

CREATE [ OR REPLACE ] RULE name AS ON event
    TO table_name [ WHERE condition ]
    DO [ ALSO | INSTEAD ] { NOTHING | command | ( command ; command ... ) }

where event can be one of:

    SELECT | INSERT | UPDATE | DELETE

DESCRIPTION

CREATE RULE defines a new rule applying to a specified table or view. CREATE OR REPLACE RULE will either create a new rule, or replace an existing rule of the same name for the same table.

The PostgreSQL rule system allows one to define an alternative action to be performed on insertions, updates, or deletions in database tables. Roughly speaking, a rule causes additional commands to be executed when a given command on a given table is executed. Alternatively, an INSTEAD rule can replace a given command by another, or cause a command not to be executed at all. Rules are used to implement SQL views as well. It is important to realize that a rule is really a command transformation mechanism, or command macro. The transformation happens before the execution of the command starts. If you actually want an operation that fires independently for each physical row, you probably want to use a trigger, not a rule. More information about the rules system is in Chapter 41.

Presently, ON SELECT rules can only be attached to views. Such a rule must be named “_RETURN”, must be an unconditional INSTEAD rule, and must have an action that consists of a single SELECT command. This command defines the visible contents of the view. (The view itself is basically a dummy table with no storage.) Its best to regard such a rule as an implementation detail. While a view can be redefined via CREATE OR REPLACE RULE “_RETURN” AS …, its better style to use CREATE OR REPLACE VIEW.

You can create the illusion of an updatable view by defining ON INSERT, ON UPDATE, and ON DELETE rules (or any subset of those thats sufficient for your purposes) to replace update actions on the view with appropriate updates on other tables. If you want to support INSERT RETURNING and so on, then be sure to put a suitable RETURNING clause into each of these rules.

There is a catch if you try to use conditional rules for complex view updates: there must be an unconditional INSTEAD rule for each action you wish to allow on the view. If the rule is conditional, or is not INSTEAD, then the system will still reject attempts to perform the update action, because it thinks it might end up trying to perform the action on the dummy table of the view in some cases. If you want to handle all the useful cases in conditional rules, add an unconditional DO INSTEAD NOTHING rule to ensure that the system understands it will never be called on to update the dummy table. Then make the conditional rules non-INSTEAD; in the cases where they are applied, they add to the default INSTEAD NOTHING action. (This method does not currently work to support RETURNING queries, however.)

Note

A view that is simple enough to be automatically updatable (see CREATE VIEW (CREATE_VIEW(7))) does not require a user-created rule in order to be updatable. While you can create an explicit rule anyway, the automatic update transformation will generally outperform an explicit rule.

Another alternative worth considering is to use INSTEAD OF triggers (see CREATE TRIGGER (CREATE_TRIGGER(7))) in place of rules.

PARAMETERS

name

The name of a rule to create. This must be distinct from the name of any other rule for the same table. Multiple rules on the same table and same event type are applied in alphabetical name order.

event

The event is one of SELECT, INSERT, UPDATE, or DELETE. Note that an INSERT containing an ON CONFLICT clause cannot be used on tables that have either INSERT or UPDATE rules. Consider using an updatable view instead.

table_name

The name (optionally schema-qualified) of the table or view the rule applies to.

condition

Any SQL conditional expression (returning boolean). The condition expression cannot refer to any tables except NEW and OLD, and cannot contain aggregate functions.

INSTEAD

INSTEAD indicates that the commands should be executed instead of the original command.

ALSO

ALSO indicates that the commands should be executed in addition to the original command.

If neither ALSO nor INSTEAD is specified, ALSO is the default.

command

The command or commands that make up the rule action. Valid commands are SELECT, INSERT, UPDATE, DELETE, or NOTIFY.

Within condition and command, the special table names NEW and OLD can be used to refer to values in the referenced table. NEW is valid in ON INSERT and ON UPDATE rules to refer to the new row being inserted or updated. OLD is valid in ON UPDATE and ON DELETE rules to refer to the existing row being updated or deleted.

NOTES

You must be the owner of a table to create or change rules for it.

In a rule for INSERT, UPDATE, or DELETE on a view, you can add a RETURNING clause that emits the views columns. This clause will be used to compute the outputs if the rule is triggered by an INSERT RETURNING, UPDATE RETURNING, or DELETE RETURNING command respectively. When the rule is triggered by a command without RETURNING, the rules RETURNING clause will be ignored. The current implementation allows only unconditional INSTEAD rules to contain RETURNING; furthermore there can be at most one RETURNING clause among all the rules for the same event. (This ensures that there is only one candidate RETURNING clause to be used to compute the results.) RETURNING queries on the view will be rejected if there is no RETURNING clause in any available rule.

It is very important to take care to avoid circular rules. For example, though each of the following two rule definitions are accepted by PostgreSQL, the SELECT command would cause PostgreSQL to report an error because of recursive expansion of a rule:

CREATE RULE “_RETURN” AS ON SELECT TO t1 DO INSTEAD SELECT * FROM t2;

CREATE RULE "_RETURN" AS
    ON SELECT TO t2
    DO INSTEAD
        SELECT * FROM t1;

SELECT * FROM t1;

Presently, if a rule action contains a NOTIFY command, the NOTIFY command will be executed unconditionally, that is, the NOTIFY will be issued even if there are not any rows that the rule should apply to. For example, in:

CREATE RULE notify_me AS ON UPDATE TO mytable DO ALSO NOTIFY mytable;

UPDATE mytable SET name = foo WHERE id = 42;

one NOTIFY event will be sent during the UPDATE, whether or not there are any rows that match the condition id = 42. This is an implementation restriction that might be fixed in future releases.

COMPATIBILITY

CREATE RULE is a PostgreSQL language extension, as is the entire query rewrite system.

SEE ALSO

ALTER RULE (ALTER_RULE(7)), DROP RULE (DROP_RULE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

422 - Linux cli command deb-version

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command deb-version and provides detailed information about the command deb-version, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the deb-version.

NAME 🖥️ deb-version 🖥️

version - Debian package version number format

SYNOPSIS

[epoch**:]upstream-version[-**debian-revision]

DESCRIPTION

Version numbers as used for Debian binary and source packages consist of three components. These are:

epoch
This is a single (generally small) unsigned integer. It may be omitted, in which case zero is assumed. If it is omitted then the upstream-version may not contain any colons. It is provided to allow mistakes in the version numbers of older versions of a package, and also a package’s previous version numbering schemes, to be left behind.

upstream-version
This is the main part of the version number. It is usually the version number of the original (“upstream”) package from which the .deb file has been made, if this is applicable. Usually this will be in the same format as that specified by the upstream author(s); however, it may need to be reformatted to fit into the package management system’s format and comparison scheme. The comparison behavior of the package management system with respect to the upstream-version is described below. The upstream-version portion of the version number is mandatory. The upstream-version may contain only alphanumerics (“A-Za-z0-9”) and the characters . + - : ~ (full stop, plus, hyphen, colon, tilde) and should start with a digit. If there is no debian-revision then hyphens are not allowed; if there is no epoch then colons are not allowed.

debian-revision
This part of the version number specifies the version of the Debian package based on the upstream version. It may contain only alphanumerics and the characters + . ~ (plus, full stop, tilde) and is compared in the same way as the upstream-version is. It is optional; if it isn’t present then the upstream-version may not contain a hyphen. This format represents the case where a piece of software was written specifically to be turned into a Debian package, and so there is only one “debianization” of it and therefore no revision indication is required. It is conventional to restart the debian-revision at ‘1’ each time the upstream-version is increased. Dpkg will break the version number apart at the last hyphen in the string (if there is one) to determine the upstream-version and debian-revision. The absence of a debian-revision compares earlier than the presence of one (but note that the debian-revision is the least significant part of the version number).

Sorting algorithm

The upstream-version and debian-revision parts are compared by the package management system using the same algorithm:

The strings are compared from left to right.

First the initial part of each string consisting entirely of non-digit characters is determined. These two parts (one of which may be empty) are compared lexically. If a difference is found it is returned. The lexical comparison is a comparison of ASCII values modified so that all the letters sort earlier than all the non-letters and so that a tilde sorts before anything, even the end of a part. For example, the following parts are in sorted order: ‘~~’, ‘~~a’, ‘~’, the empty part, ‘a’.

Then the initial part of the remainder of each string which consists entirely of digit characters is determined. The numerical values of these two parts are compared, and any difference found is returned as the result of the comparison. For these purposes an empty string (which can only occur at the end of one or both version strings being compared) counts as zero.

These two steps (comparing and removing initial non-digit strings and initial digit strings) are repeated until a difference is found or both strings are exhausted.

Note that the purpose of epochs is to allow us to leave behind mistakes in version numbering, and to cope with situations where the version numbering scheme changes. It is not intended to cope with version numbers containing strings of letters which the package management system cannot interpret (such as ‘ALPHA’ or ‘pre-’), or with silly orderings.

NOTES

The tilde character and its special sorting properties were introduced in dpkg 1.10 and some parts of the dpkg build scripts only gained support for it later in the 1.10.x series.

SEE ALSO

deb-control (5), deb (5), dpkg (1)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

423 - Linux cli command uts_namespaces

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command uts_namespaces and provides detailed information about the command uts_namespaces, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the uts_namespaces.

NAME 🖥️ uts_namespaces 🖥️

overview of Linux UTS namespaces

DESCRIPTION

UTS namespaces provide isolation of two system identifiers: the hostname and the NIS domain name. These identifiers are set using sethostname(2) and setdomainname(2), and can be retrieved using uname(2), gethostname(2), and getdomainname(2). Changes made to these identifiers are visible to all other processes in the same UTS namespace, but are not visible to processes in other UTS namespaces.

When a process creates a new UTS namespace using clone(2) or unshare(2) with the CLONE_NEWUTS flag, the hostname and domain name of the new UTS namespace are copied from the corresponding values in the caller’s UTS namespace.

Use of UTS namespaces requires a kernel that is configured with the CONFIG_UTS_NS option.

SEE ALSO

nsenter(1), unshare(1), clone(2), getdomainname(2), gethostname(2), setns(2), uname(2), unshare(2), namespaces(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

424 - Linux cli command ossl_storessl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ossl_storessl and provides detailed information about the command ossl_storessl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ossl_storessl.

NAME 🖥️ ossl_storessl 🖥️

Store retrieval functions

SYNOPSIS

#include <openssl/store.h>

DESCRIPTION

General

A STORE is a layer of functionality to retrieve a number of supported objects from a repository of any kind, addressable as a filename or as a URI.

The functionality supports the pattern “open a channel to the repository”, “loop and retrieve one object at a time”, and “finish up by closing the channel”.

The retrieved objects are returned as a wrapper type OSSL_STORE_INFO, from which an OpenSSL type can be retrieved.

URI schemes and loaders

Support for a URI scheme is called a STORE “loader”, and can be added dynamically from the calling application or from a loadable engine.

Support for the ‘file’ scheme is built into libcrypto. See ossl_store-file (7) for more information.

UI_METHOD and pass phrases

The OSS_STORE API does nothing to enforce any specific format or encoding on the pass phrase that the UI_METHOD provides. However, the pass phrase is expected to be UTF-8 encoded. The result of any other encoding is undefined.

EXAMPLES

A generic call

OSSL_STORE_CTX *ctx = OSSL_STORE_open(“file:/foo/bar/data.pem”); /* * OSSL_STORE_eof() simulates file semantics for any repository to signal * that no more data can be expected */ while (!OSSL_STORE_eof(ctx)) { OSSL_STORE_INFO *info = OSSL_STORE_load(ctx); /* * Do whatever is necessary with the OSSL_STORE_INFO, * here just one example */ switch (OSSL_STORE_INFO_get_type(info)) { case OSSL_STORE_INFO_CERT: /* Print the X.509 certificate text */ X509_print_fp(stdout, OSSL_STORE_INFO_get0_CERT(info)); /* Print the X.509 certificate PEM output */ PEM_write_X509(stdout, OSSL_STORE_INFO_get0_CERT(info)); break; } } OSSL_STORE_close(ctx);

SEE ALSO

OSSL_STORE_INFO (3), OSSL_STORE_LOADER (3), OSSL_STORE_open (3), OSSL_STORE_expect (3), OSSL_STORE_SEARCH (3)

COPYRIGHT

Copyright 2016-2018 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

425 - Linux cli command DROP_SERVER

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_SERVER and provides detailed information about the command DROP_SERVER, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_SERVER.

NAME 🖥️ DROP_SERVER 🖥️

remove a foreign server descriptor

SYNOPSIS

DROP SERVER [ IF EXISTS ] name [, ...] [ CASCADE | RESTRICT ]

DESCRIPTION

DROP SERVER removes an existing foreign server descriptor. To execute this command, the current user must be the owner of the server.

PARAMETERS

IF EXISTS

Do not throw an error if the server does not exist. A notice is issued in this case.

name

The name of an existing server.

CASCADE

Automatically drop objects that depend on the server (such as user mappings), and in turn all objects that depend on those objects (see Section 5.14).

RESTRICT

Refuse to drop the server if any objects depend on it. This is the default.

EXAMPLES

Drop a server foo if it exists:

DROP SERVER IF EXISTS foo;

COMPATIBILITY

DROP SERVER conforms to ISO/IEC 9075-9 (SQL/MED). The IF EXISTS clause is a PostgreSQL extension.

SEE ALSO

CREATE SERVER (CREATE_SERVER(7)), ALTER SERVER (ALTER_SERVER(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

426 - Linux cli command EVP_PKEY-CMACssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_PKEY-CMACssl and provides detailed information about the command EVP_PKEY-CMACssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_PKEY-CMACssl.

NAME 🖥️ EVP_PKEY-CMACssl 🖥️

HMAC, EVP_KEYMGMT-HMAC, EVP_PKEY-Siphash, EVP_KEYMGMT-Siphash, EVP_PKEY-Poly1305, EVP_KEYMGMT-Poly1305, EVP_PKEY-CMAC, EVP_KEYMGMT-CMAC - EVP_PKEY legacy MAC keytypes and algorithm support

DESCRIPTION

The HMAC and CMAC key types are implemented in OpenSSL’s default and FIPS providers. Additionally the Siphash and Poly1305 key types are implemented in the default provider. Performing MAC operations via an EVP_PKEY is considered legacy and are only available for backwards compatibility purposes and for a restricted set of algorithms. The preferred way of performing MAC operations is via the EVP_MAC APIs. See EVP_MAC_init (3).

For further details on using EVP_PKEY based MAC keys see EVP_SIGNATURE-HMAC (7), EVP_SIGNATURE-Siphash (7), EVP_SIGNATURE-Poly1305 (7) or EVP_SIGNATURE-CMAC (7).

Common MAC parameters

All the MAC keytypes support the following parameters.

“priv” (OSSL_PKEY_PARAM_PRIV_KEY) <octet string>
The MAC key value.

“properties” (OSSL_PKEY_PARAM_PROPERTIES) <UTF8 string>
A property query string to be used when any algorithms are fetched.

CMAC parameters

As well as the parameters described above, the CMAC keytype additionally supports the following parameters.

“cipher” (OSSL_PKEY_PARAM_CIPHER) <UTF8 string>
The name of a cipher to be used when generating the MAC.

“engine” (OSSL_PKEY_PARAM_ENGINE) <UTF8 string>
The name of an engine to be used for the specified cipher (if any).

Common MAC key generation parameters

MAC key generation is unusual in that no new key is actually generated. Instead a new provider side key object is created with the supplied raw key value. This is done for backwards compatibility with previous versions of OpenSSL.

“priv” (OSSL_PKEY_PARAM_PRIV_KEY) <octet string>
The MAC key value.

CMAC key generation parameters

In addition to the common MAC key generation parameters, the CMAC key generation additionally recognises the following.

“cipher” (OSSL_PKEY_PARAM_CIPHER) <UTF8 string>
The name of a cipher to be used when generating the MAC.

SEE ALSO

EVP_KEYMGMT (3), EVP_PKEY (3), provider-keymgmt (7)

COPYRIGHT

Copyright 2020 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

427 - Linux cli command openssl-envssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command openssl-envssl and provides detailed information about the command openssl-envssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the openssl-envssl.

NAME 🖥️ openssl-envssl 🖥️

env - OpenSSL environment variables

DESCRIPTION

The OpenSSL libraries use environment variables to override the compiled-in default paths for various data. To avoid security risks, the environment is usually not consulted when the executable is set-user-ID or set-group-ID.

CTLOG_FILE
Specifies the path to a certificate transparency log list. See CTLOG_STORE_new (3).

OPENSSL
Specifies the path to the openssl executable. Used by the rehash script (see “Script Configuration” in openssl-rehash (1)) and by the CA.pl script (see “NOTES” in CA.pl (1)

OPENSSL_CONF, OPENSSL_CONF_INCLUDE
Specifies the path to a configuration file and the directory for included files. See config (5).

OPENSSL_CONFIG
Specifies a configuration option and filename for the req and ca commands invoked by the CA.pl script. See CA.pl (1).

OPENSSL_ENGINES
Specifies the directory from which dynamic engines are loaded. See openssl-engine (1).

OPENSSL_MALLOC_FD, OPENSSL_MALLOC_FAILURES
If built with debugging, this allows memory allocation to fail. See OPENSSL_malloc (3).

OPENSSL_MODULES
Specifies the directory from which cryptographic providers are loaded. Equivalently, the generic -provider-path command-line option may be used.

OPENSSL_WIN32_UTF8
If set, then UI_OpenSSL (3) returns UTF-8 encoded strings, rather than ones encoded in the current code page, and the openssl (1) program also transcodes the command-line parameters from the current code page to UTF-8. This environment variable is only checked on Microsoft Windows platforms.

RANDFILE
The state file for the random number generator. This should not be needed in normal use. See RAND_load_file (3).

SSL_CERT_DIR, SSL_CERT_FILE
Specify the default directory or file containing CA certificates. See SSL_CTX_load_verify_locations (3).

TSGET
Additional arguments for the tsget (1) command.

OPENSSL_ia32cap, OPENSSL_sparcv9cap, OPENSSL_ppccap, OPENSSL_armcap, OPENSSL_s390xcap, OPENSSL_riscvcap
OpenSSL supports a number of different algorithm implementations for various machines and, by default, it determines which to use based on the processor capabilities and run time feature enquiry. These environment variables can be used to exert more control over this selection process. See OPENSSL_ia32cap (3), OPENSSL_s390xcap (3).

NO_PROXY, HTTPS_PROXY, HTTP_PROXY
Specify a proxy hostname. See OSSL_HTTP_parse_url (3).

COPYRIGHT

Copyright 2019-2022 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

428 - Linux cli command passphrase-encodingssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command passphrase-encodingssl and provides detailed information about the command passphrase-encodingssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the passphrase-encodingssl.

NAME 🖥️ passphrase-encodingssl 🖥️

encoding - How diverse parts of OpenSSL treat pass phrases character encoding

DESCRIPTION

In a modern world with all sorts of character encodings, the treatment of pass phrases has become increasingly complex. This manual page attempts to give an overview over how this problem is currently addressed in different parts of the OpenSSL library.

The general case

The OpenSSL library doesn’t treat pass phrases in any special way as a general rule, and trusts the application or user to choose a suitable character set and stick to that throughout the lifetime of affected objects. This means that for an object that was encrypted using a pass phrase encoded in ISO-8859-1, that object needs to be decrypted using a pass phrase encoded in ISO-8859-1. Using the wrong encoding is expected to cause a decryption failure.

PKCS#12

PKCS#12 is a bit different regarding pass phrase encoding. The standard stipulates that the pass phrase shall be encoded as an ASN.1 BMPString, which consists of the code points of the basic multilingual plane, encoded in big endian (UCS-2 BE).

OpenSSL tries to adapt to this requirements in one of the following manners:

  1. Treats the received pass phrase as UTF-8 encoded and tries to re-encode it to UTF-16 (which is the same as UCS-2 for characters U+0000 to U+D7FF and U+E000 to U+FFFF, but becomes an expansion for any other character), or failing that, proceeds with step 2.

  2. Assumes that the pass phrase is encoded in ASCII or ISO-8859-1 and opportunistically prepends each byte with a zero byte to obtain the UCS-2 encoding of the characters, which it stores as a BMPString. Note that since there is no check of your locale, this may produce UCS-2 / UTF-16 characters that do not correspond to the original pass phrase characters for other character sets, such as any ISO-8859-X encoding other than ISO-8859-1 (or for Windows, CP 1252 with exception for the extra “graphical” characters in the 0x80-0x9F range).

OpenSSL versions older than 1.1.0 do variant 2 only, and that is the reason why OpenSSL still does this, to be able to read files produced with older versions.

It should be noted that this approach isn’t entirely fault free.

A pass phrase encoded in ISO-8859-2 could very well have a sequence such as 0xC3 0xAF (which is the two characters “LATIN CAPITAL LETTER A WITH BREVE” and “LATIN CAPITAL LETTER Z WITH DOT ABOVE” in ISO-8859-2 encoding), but would be misinterpreted as the perfectly valid UTF-8 encoded code point U+00EF (LATIN SMALL LETTER I WITH DIAERESIS) if the pass phrase doesn’t contain anything that would be invalid UTF-8. A pass phrase that contains this kind of byte sequence will give a different outcome in OpenSSL 1.1.0 and newer than in OpenSSL older than 1.1.0.

0x00 0xC3 0x00 0xAF # OpenSSL older than 1.1.0 0x00 0xEF # OpenSSL 1.1.0 and newer

On the same accord, anything encoded in UTF-8 that was given to OpenSSL older than 1.1.0 was misinterpreted as ISO-8859-1 sequences.

OSSL_STORE

ossl_store (7) acts as a general interface to access all kinds of objects, potentially protected with a pass phrase, a PIN or something else. This API stipulates that pass phrases should be UTF-8 encoded, and that any other pass phrase encoding may give undefined results. This API relies on the application to ensure UTF-8 encoding, and doesn’t check that this is the case, so what it gets, it will also pass to the underlying loader.

RECOMMENDATIONS

This section assumes that you know what pass phrase was used for encryption, but that it may have been encoded in a different character encoding than the one used by your current input method. For example, the pass phrase may have been used at a time when your default encoding was ISO-8859-1 (i.e. “naïve” resulting in the byte sequence 0x6E 0x61 0xEF 0x76 0x65), and you’re now in an environment where your default encoding is UTF-8 (i.e. “naïve” resulting in the byte sequence 0x6E 0x61 0xC3 0xAF 0x76 0x65). Whenever it’s mentioned that you should use a certain character encoding, it should be understood that you either change the input method to use the mentioned encoding when you type in your pass phrase, or use some suitable tool to convert your pass phrase from your default encoding to the target encoding.

Also note that the sub-sections below discuss human readable pass phrases. This is particularly relevant for PKCS#12 objects, where human readable pass phrases are assumed. For other objects, it’s as legitimate to use any byte sequence (such as a sequence of bytes from /dev/urandom that’s been saved away), which makes any character encoding discussion irrelevant; in such cases, simply use the same byte sequence as it is.

Creating new objects

For creating new pass phrase protected objects, make sure the pass phrase is encoded using UTF-8. This is default on most modern Unixes, but may involve an effort on other platforms. Specifically for Windows, setting the environment variable OPENSSL_WIN32_UTF8 will have anything entered on [Windows] console prompt converted to UTF-8 (command line and separately prompted pass phrases alike).

Opening existing objects

For opening pass phrase protected objects where you know what character encoding was used for the encryption pass phrase, make sure to use the same encoding again.

For opening pass phrase protected objects where the character encoding that was used is unknown, or where the producing application is unknown, try one of the following:

  1. Try the pass phrase that you have as it is in the character encoding of your environment. It’s possible that its byte sequence is exactly right.

  2. Convert the pass phrase to UTF-8 and try with the result. Specifically with PKCS#12, this should open up any object that was created according to the specification.

  3. Do a naïve (i.e. purely mathematical) ISO-8859-1 to UTF-8 conversion and try with the result. This differs from the previous attempt because ISO-8859-1 maps directly to U+0000 to U+00FF, which other non-UTF-8 character sets do not. This also takes care of the case when a UTF-8 encoded string was used with OpenSSL older than 1.1.0. (for example, ï, which is 0xC3 0xAF when encoded in UTF-8, would become 0xC3 0x83 0xC2 0xAF when re-encoded in the naïve manner. The conversion to BMPString would then yield 0x00 0xC3 0x00 0xA4 0x00 0x00, the erroneous/non-compliant encoding used by OpenSSL older than 1.1.0)

SEE ALSO

evp (7), ossl_store (7), EVP_BytesToKey (3), EVP_DecryptInit (3), PEM_do_header (3), PKCS12_parse (3), PKCS12_newpass (3), d2i_PKCS8PrivateKey_bio (3)

COPYRIGHT

Copyright 2018-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

429 - Linux cli command systemd.environment-generator

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command systemd.environment-generator and provides detailed information about the command systemd.environment-generator, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the systemd.environment-generator.

NAME 🖥️ systemd.environment-generator 🖥️

generator - systemd environment file generators

SYNOPSIS

/usr/lib/systemd/system-environment-generators/some-generator

/usr/lib/systemd/user-environment-generators/some-generator

/run/systemd/system-environment-generators/*

/etc/systemd/system-environment-generators/*

/usr/local/lib/systemd/system-environment-generators/*

/usr/lib/systemd/system-environment-generators/*

/run/systemd/user-environment-generators/*

/etc/systemd/user-environment-generators/*

/usr/local/lib/systemd/user-environment-generators/*

/usr/lib/systemd/user-environment-generators/*

DESCRIPTION

Generators are small executables that live in /usr/lib/systemd/system-environment-generators/ and other directories listed above. systemd(1) will execute those binaries very early at the startup of each manager and at configuration reload time, before running the generators described in systemd.generator(7) and before starting any units. Environment generators can override the environment that the manager exports to services and other processes.

Generators are loaded from a set of paths determined during compilation, as listed above. System and user environment generators are loaded from directories with names ending in system-environment-generators/ and user-environment-generators/, respectively. Generators found in directories listed earlier override the ones with the same name in directories lower in the list [1]. A symlink to /dev/null or an empty file can be used to mask a generator, thereby preventing it from running. Please note that the order of the two directories with the highest priority is reversed with respect to the unit load path, and generators in /run/ overwrite those in /etc/.

After installing new generators or updating the configuration, systemctl daemon-reload may be executed. This will re-run all generators, updating environment configuration. It will be used for any services that are started subsequently.

Environment file generators are executed similarly to unit file generators described in systemd.generator(7), with the following differences:

·

Generators are executed sequentially in the alphanumerical order of the final component of their name. The output of each generator output is immediately parsed and used to update the environment for generators that run after that. Thus, later generators can use and/or modify the output of earlier generators.

·

Generators are run by every manager instance, their output can be different for each user.

It is recommended to use numerical prefixes for generator names to simplify ordering.

EXAMPLES

Example 1. A simple generator that extends an environment variable if a directory exists in the file system

50-xdg-data-dirs.sh

#!/bin/sh
# SPDX-License-Identifier: MIT-0

# set the default value
XDG_DATA_DIRS="${XDG_DATA_DIRS:-/usr/local/share/:/usr/share}"

# add a directory if it exists
if [ -d /opt/foo/share ]; then
    XDG_DATA_DIRS="/opt/foo/share:${XDG_DATA_DIRS}"
fi

# write our output
echo "XDG_DATA_DIRS=${XDG_DATA_DIRS}"

Example 2. A more complicated generator which reads existing configuration and mutates one variable

90-rearrange-path.py

#!/usr/bin/env python3
# SPDX-License-Identifier: MIT-0

"""

Proof-of-concept systemd environment generator that makes sure that bin dirs
are always after matching sbin dirs in the path.
(Changes /sbin:/bin:/foo/bar to /bin:/sbin:/foo/bar.)

This generator shows how to override the configuration possibly created by
earlier generators. It would be easier to write in bash, but lets have it
in Python just to prove that we can, and to serve as a template for more
interesting generators.

"""

import os
import pathlib

def rearrange_bin_sbin(path):
    """Make sure any pair of .../bin, .../sbin directories is in this order

    >>> rearrange_bin_sbin(/bin:/sbin:/usr/sbin:/usr/bin)
    /bin:/sbin:/usr/bin:/usr/sbin
    """
    items = [pathlib.Path(p) for p in path.split(:)]
    for i in range(len(items)):
        if sbin in items[i].parts:
            ind = items[i].parts.index(sbin)
            bin = pathlib.Path(*items[i].parts[:ind], bin, *items[i].parts[ind+1:])
            if bin in items[i+1:]:
                j = i + 1 + items[i+1:].index(bin)
                items[i], items[j] = items[j], items[i]
    return :.join(p.as_posix() for p in items)

if __name__ == __main__:
    path = os.environ[PATH] # This should be always set.
                              # If its not, well just crash, which is OK too.
    new = rearrange_bin_sbin(path)
    if new != path:
        print(PATH={}.format(new))

Example 3. Debugging a generator

SYSTEMD_LOG_LEVEL=debug VAR_A=something VAR_B=“something else”
/usr/lib/systemd/system-environment-generators/path-to-generator

SEE ALSO

systemd-environment-d-generator(8), systemd.generator(7), systemd(1), systemctl(1)

NOTES

💣💥🧨💥💥💣 Please note that those configuration files must be available at all times. If /usr/local/ is a separate partition, it may not be available during early boot, and must not be used for configuration.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

430 - Linux cli command DROP_RULE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_RULE and provides detailed information about the command DROP_RULE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_RULE.

NAME 🖥️ DROP_RULE 🖥️

remove a rewrite rule

SYNOPSIS

DROP RULE [ IF EXISTS ] name ON table_name [ CASCADE | RESTRICT ]

DESCRIPTION

DROP RULE drops a rewrite rule.

PARAMETERS

IF EXISTS

Do not throw an error if the rule does not exist. A notice is issued in this case.

name

The name of the rule to drop.

table_name

The name (optionally schema-qualified) of the table or view that the rule applies to.

CASCADE

Automatically drop objects that depend on the rule, and in turn all objects that depend on those objects (see Section 5.14).

RESTRICT

Refuse to drop the rule if any objects depend on it. This is the default.

EXAMPLES

To drop the rewrite rule newrule:

DROP RULE newrule ON mytable;

COMPATIBILITY

DROP RULE is a PostgreSQL language extension, as is the entire query rewrite system.

SEE ALSO

CREATE RULE (CREATE_RULE(7)), ALTER RULE (ALTER_RULE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

431 - Linux cli command ossl-guide-quic-multi-streamssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ossl-guide-quic-multi-streamssl and provides detailed information about the command ossl-guide-quic-multi-streamssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ossl-guide-quic-multi-streamssl.

NAME 🖥️ ossl-guide-quic-multi-streamssl 🖥️

guide-quic-multi-stream - OpenSSL Guide: Writing a simple multi-stream QUIC client

INTRODUCTION

This page will introduce some important concepts required to write a simple QUIC multi-stream application. It assumes a basic understanding of QUIC and how it is used in OpenSSL. See ossl-guide-quic-introduction (7) and ossl-guide-quic-client-block (7).

QUIC STREAMS

In a QUIC multi-stream application we separate out the concepts of a QUIC “connection” and a QUIC “stream”. A connection object represents the overarching details of the connection between a client and a server including all its negotiated and configured parameters. We use the SSL object for that in an OpenSSL application (known as the connection SSL object). It is created by an application calling SSL_new (3).

Separately a connection can have zero or more streams associated with it (although a connection with zero streams is probably not very useful, so normally you would have at least one). A stream is used to send and receive data between the two peers. Each stream is also represented by an SSL object. A stream is logically independent of all the other streams associated with the same connection. Data sent on a stream is guaranteed to be delivered in the order that it was sent within that stream. The same is not true across streams, e.g. if an application sends data on stream 1 first and then sends some more data on stream 2 second, then the remote peer may receive the data sent on stream 2 before it receives the data sent on stream 1.

Once the connection SSL object has completed its handshake (i.e. SSL_connect (3) has returned 1), stream SSL objects are created by the application calling SSL_new_stream (3) or SSL_accept_stream (3) (see “CREATING NEW STREAMS” below).

The same threading rules apply to SSL objects as for most OpenSSL objects (see ossl-guide-libraries-introduction (7)). In particular most OpenSSL functions are thread safe, but the SSL object is not. This means that you can use an SSL object representing one stream at the same time as another thread is using a different SSL object for a different stream on the same connection. But you cannot use the same SSL object on two different threads at the same time (without additional application level locking).

THE DEFAULT STREAM

A connection SSL object may also (optionally) be associated with a stream. This stream is known as the default stream. The default stream is automatically created and associated with the SSL object when the application calls SSL_read_ex (3), SSL_read (3), SSL_write_ex (3) or SSL_write (3) and passes the connection SSL object as a parameter.

If a client application calls SSL_write_ex (3) or SSL_write (3) first then (by default) the default stream will be a client-initiated bi-directional stream. If a client application calls SSL_read_ex (3) or SSL_read (3) first then the first stream initiated by the server will be used as the default stream (whether it is bi-directional or uni-directional).

This behaviour can be controlled via the default stream mode. See SSL_set_default_stream_mode (3) for further details.

It is recommended that new multi-stream applications should not use a default stream at all and instead should use a separate stream SSL object for each stream that is used. This requires calling SSL_set_default_stream_mode (3) and setting the mode to SSL_DEFAULT_STREAM_MODE_NONE.

CREATING NEW STREAMS

An endpoint can create a new stream by calling SSL_new_stream (3). This creates a locally initiated stream. In order to do so you must pass the QUIC connection SSL object as a parameter. You can also specify whether you want a bi-directional or a uni-directional stream.

The function returns a new QUIC stream SSL object for sending and receiving data on that stream.

The peer may also initiate streams. An application can use the function SSL_get_accept_stream_queue_len (3) to determine the number of streams that the peer has initiated that are waiting for the application to handle. An application can call SSL_accept_stream (3) to create a new SSL object for a remotely initiated stream. If the peer has not initiated any then this call will block until one is available if the connection object is in blocking mode (see SSL_set_blocking_mode (3)).

When using a default stream OpenSSL will prevent new streams from being accepted. To override this behaviour you must call SSL_set_incoming_stream_policy (3) to set the policy to SSL_INCOMING_STREAM_POLICY_ACCEPT. See the man page for further details. This is not relevant if the default stream has been disabled as described in “THE DEFAULT STREAM” above.

Any stream may be bi-directional or uni-directional. If it is uni-directional then the initiator can write to it but not read from it, and vice-versa for the peer. You can determine what type of stream an SSL object represents by calling SSL_get_stream_type (3). See the man page for further details.

USING A STREAM TO SEND AND RECEIVE DATA

Once you have a stream SSL object (which includes the connection SSL object if a default stream is in use) then you can send and receive data over it using the SSL_write_ex (3), SSL_write (3), SSL_read_ex (3) or SSL_read (3) functions. See the man pages for further details.

In the event of one of these functions not returning a success code then you should call SSL_get_error (3) to find out further details about the error. In blocking mode this will either be a fatal error (e.g. SSL_ERROR_SYSCALL or SSL_ERROR_SSL), or it will be SSL_ERROR_ZERO_RETURN which can occur when attempting to read data from a stream and the peer has indicated that the stream is concluded (i.e. “FIN” has been signalled on the stream). This means that the peer will send no more data on that stream. Note that the interpretation of SSL_ERROR_ZERO_RETURN is slightly different for a QUIC application compared to a TLS application. In TLS it occurs when the connection has been shutdown by the peer. In QUIC this only tells you that the current stream has been concluded by the peer. It tells you nothing about the underlying connection. If the peer has concluded the stream then no more data will be received on it, however an application can still send data to the peer until the send side of the stream has also been concluded. This can happen by the application calling SSL_stream_conclude (3). It is an error to attempt to send more data on a stream after SSL_stream_conclude (3) has been called.

It is also possible to abandon a stream abnormally by calling SSL_stream_reset (3).

Once a stream object is no longer needed it should be freed via a call to SSL_free (3). An application should not call SSL_shutdown (3) on it since this is only meaningful for connection level SSL objects. Freeing the stream will automatically signal STOP_SENDING to the peer.

STREAMS AND CONNECTIONS

Given a stream object it is possible to get the SSL object corresponding to the connection via a call to SSL_get0_connection (3). Multi-threaded restrictions apply so care should be taken when using the returned connection object. Specifically, if you are handling each of your stream objects in a different thread and call SSL_get0_connection (3) from within that thread then you must be careful to not to call any function that uses the connection object at the same time as one of the other threads is also using that connection object (with the exception of SSL_accept_stream (3) and SSL_get_accept_stream_queue_len (3) which are thread-safe).

A stream object does not inherit all its settings and values from its parent SSL connection object. Therefore certain function calls that are relevant to the connection as a whole will not work on a stream. For example the function SSL_get_certificate (3) can be used to obtain a handle on the peer certificate when called with a connection SSL object. When called with a stream SSL object it will return NULL.

SIMPLE MULTI-STREAM QUIC CLIENT EXAMPLE

This section will present various source code samples demonstrating how to write a simple multi-stream QUIC client application which connects to a server, send some HTTP/1.0 requests to it, and read back the responses. Note that HTTP/1.0 over QUIC is non-standard and will not be supported by real world servers. This is for demonstration purposes only.

We will build on the example code for the simple blocking QUIC client that is covered on the ossl-guide-quic-client-block (7) page and we assume that you are familiar with it. We will only describe the differences between the simple blocking QUIC client and the multi-stream QUIC client. Although the example code uses blocking SSL objects, you can equally use nonblocking SSL objects. See ossl-guide-quic-client-non-block (7) for more information about writing a nonblocking QUIC client.

The complete source code for this example multi-stream QUIC client is available in the demos/guide directory of the OpenSSL source distribution in the file quic-multi-stream.c. It is also available online at <https://github.com/openssl/openssl/blob/master/demos/guide/quic-multi-stream.c>.

Disabling the default stream

As discussed above in “THE DEFAULT STREAM” we will follow the recommendation to disable the default stream for our multi-stream client. To do this we call the SSL_set_default_stream_mode (3) function and pass in our connection SSL object and the value SSL_DEFAULT_STREAM_MODE_NONE.

/* * We will use multiple streams so we will disable the default stream mode. * This is not a requirement for using multiple streams but is recommended. */ if (!SSL_set_default_stream_mode(ssl, SSL_DEFAULT_STREAM_MODE_NONE)) { printf(“Failed to disable the default stream mode “); goto end; }

Creating the request streams

For the purposes of this example we will create two different streams to send two different HTTP requests to the server. For the purposes of demonstration the first of these will be a bi-directional stream and the second one will be a uni-directional one:

/* * We create two new client initiated streams. The first will be * bi-directional, and the second will be uni-directional. */ stream1 = SSL_new_stream(ssl, 0); stream2 = SSL_new_stream(ssl, SSL_STREAM_FLAG_UNI); if (stream1 == NULL || stream2 == NULL) { printf(“Failed to create streams “); goto end; }

Writing data to the streams

Once the streams are successfully created we can start writing data to them. In this example we will be sending a different HTTP request on each stream. To avoid repeating too much code we write a simple helper function to send an HTTP request to a stream:

int write_a_request(SSL *stream, const char *request_start, const char *hostname) { const char *request_end = "

“; size_t written; if (!SSL_write_ex(stream, request_start, strlen(request_start), &written)) return 0; if (!SSL_write_ex(stream, hostname, strlen(hostname), &written)) return 0; if (!SSL_write_ex(stream, request_end, strlen(request_end), &written)) return 0; return 1; }

We assume the strings request1_start and request2_start hold the appropriate HTTP requests. We can then call our helper function above to send the requests on the two streams. For the sake of simplicity this example does this sequentially, writing to stream1 first and, when this is successful, writing to stream2 second. Remember that our client is blocking so these calls will only return once they have been successfully completed. A real application would not need to do these writes sequentially or in any particular order. For example we could start two threads (one for each stream) and write the requests to each stream simultaneously.

/* Write an HTTP GET request on each of our streams to the peer */ if (!write_a_request(stream1, request1_start, hostname)) { printf(“Failed to write HTTP request on stream 1 “); goto end; } if (!write_a_request(stream2, request2_start, hostname)) { printf(“Failed to write HTTP request on stream 2 “); goto end; }

Reading data from a stream

In this example stream1 is a bi-directional stream so, once we have sent the request on it, we can attempt to read the response from the server back. Here we just repeatedly call SSL_read_ex (3) until that function fails (indicating either that there has been a problem, or that the peer has signalled the stream as concluded).

printf(“Stream 1 data: “); /* * Get up to sizeof(buf) bytes of the response from stream 1 (which is a * bidirectional stream). We keep reading until the server closes the * connection. */ while (SSL_read_ex(stream1, buf, sizeof(buf), &readbytes)) { /* * OpenSSL does not guarantee that the returned data is a string or * that it is NUL terminated so we use fwrite() to write the exact * number of bytes that we read. The data could be non-printable or * have NUL characters in the middle of it. For this simple example * were going to print it to stdout anyway. */ fwrite(buf, 1, readbytes, stdout); } /* In case the response didnt finish with a newline we add one now */ printf(” “);

In a blocking application like this one calls to SSL_read_ex (3) will either succeed immediately returning data that is already available, or they will block waiting for more data to become available and return it when it is, or they will fail with a 0 response code.

Once we exit the while loop above we know that the last call to SSL_read_ex (3) gave a 0 response code so we call the SSL_get_error (3) function to find out more details. Since this is a blocking application this will either return SSL_ERROR_SYSCALL or SSL_ERROR_SSL indicating a fundamental problem, or it will return SSL_ERROR_ZERO_RETURN indicating that the stream is concluded and there will be no more data available to read from it. Care must be taken to distinguish between an error at the stream level (i.e. a stream reset) and an error at the connection level (i.e. a connection closed). The SSL_get_stream_read_state (3) function can be used to distinguish between these different cases.

/* * Check whether we finished the while loop above normally or as the * result of an error. The 0 argument to SSL_get_error() is the return * code we received from the SSL_read_ex() call. It must be 0 in order * to get here. Normal completion is indicated by SSL_ERROR_ZERO_RETURN. In * QUIC terms this means that the peer has sent FIN on the stream to * indicate that no further data will be sent. */ switch (SSL_get_error(stream1, 0)) { case SSL_ERROR_ZERO_RETURN: /* Normal completion of the stream */ break; case SSL_ERROR_SSL: /* * Some stream fatal error occurred. This could be because of a stream * reset - or some failure occurred on the underlying connection. */ switch (SSL_get_stream_read_state(stream1)) { case SSL_STREAM_STATE_RESET_REMOTE: printf(“Stream reset occurred “); /* The stream has been reset but the connection is still healthy. */ break; case SSL_STREAM_STATE_CONN_CLOSED: printf(“Connection closed “); /* Connection is already closed. Skip SSL_shutdown() */ goto end; default: printf(“Unknown stream failure “); break; } break; default: /* Some other unexpected error occurred */ printf (“Failed reading remaining data “); break; }

Accepting an incoming stream

Our stream2 object that we created above was a uni-directional stream so it cannot be used to receive data from the server. In this hypothetical example we assume that the server initiates a new stream to send us back the data that we requested. To do that we call SSL_accept_stream (3). Since this is a blocking application this will wait indefinitely until the new stream has arrived and is available for us to accept. In the event of an error it will return NULL.

/* * In our hypothetical HTTP/1.0 over QUIC protocol that we are using we * assume that the server will respond with a server initiated stream * containing the data requested in our uni-directional stream. This doesnt * really make sense to do in a real protocol, but its just for * demonstration purposes. * * Were using blocking mode so this will block until a stream becomes * available. We could override this behaviour if we wanted to by setting * the SSL_ACCEPT_STREAM_NO_BLOCK flag in the second argument below. */ stream3 = SSL_accept_stream(ssl, 0); if (stream3 == NULL) { printf(“Failed to accept a new stream “); goto end; }

We can now read data from the stream in the same way that we did for stream1 above. We won’t repeat that here.

Cleaning up the streams

Once we have finished using our streams we can simply free them by calling SSL_free (3). Optionally we could call SSL_stream_conclude (3) on them if we want to indicate to the peer that we won’t be sending them any more data, but we don’t do that in this example because we assume that the HTTP application protocol supplies sufficient information for the peer to know when we have finished sending request data.

We should not call SSL_shutdown (3) or SSL_shutdown_ex (3) on the stream objects since those calls should not be used for streams.

SSL_free(stream1); SSL_free(stream2); SSL_free(stream3);

SEE ALSO

ossl-guide-introduction (7), ossl-guide-libraries-introduction (7), ossl-guide-libssl-introduction (7) ossl-guide-quic-introduction (7), ossl-guide-quic-client-block (7)

COPYRIGHT

Copyright 2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

432 - Linux cli command EVP_CIPHER-IDEAssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_CIPHER-IDEAssl and provides detailed information about the command EVP_CIPHER-IDEAssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_CIPHER-IDEAssl.

NAME 🖥️ EVP_CIPHER-IDEAssl 🖥️

IDEA - The IDEA EVP_CIPHER implementations

DESCRIPTION

Support for IDEA symmetric encryption using the EVP_CIPHER API.

Algorithm Names

The following algorithms are available in the legacy provider:

“IDEA-ECB”

“IDEA-CBC”

“IDEA-OFB” or “IDEA-OFB64”

“IDEA-CFB” or “IDEA-CFB64”

Parameters

This implementation supports the parameters described in “PARAMETERS” in EVP_EncryptInit (3).

SEE ALSO

provider-cipher (7), OSSL_PROVIDER-legacy (7)

COPYRIGHT

Copyright 2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

433 - Linux cli command editlineedit

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command editlineedit and provides detailed information about the command editlineedit, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the editlineedit.

When a program using the

library prompts for an input string using the function

it reads characters from the terminal. Invalid input bytes that do not form characters are silently discarded. For each character read, one editor command is executed. The mapping of input characters to editor commands depends on the editing mode. There are three editing modes: vi insert mode, vi command mode, and emacs mode. The default is vi insert mode. The program can switch the default to emacs mode by using the

or

functions, and the user can switch to emacs mode either in the

configuration file or interactively with the

editor command, in all three cases executing the

builtin command.

If trying to read from the terminal results in end of file or an error, the library signals end of file to the program and does not return a string.

All default bindings described below can be overridden by individual programs and can be changed with the

builtin command.

In the following tables,

indicates a character with the bit 0x40 flipped, and

indicates a character with the bit 0x80 set. In vi insert mode and in emacs mode, all Meta-characters considered printable by the current

are bound to

instead of to the editor command listed below. Consequently, in UTF-8 mode, most of the Meta-characters are not directly accessible because their code points are occupied by printable Unicode characters, and Meta-characters are usually input using the

editor command. For example, to enter

in order to call the

editor command in emacs mode, call

by pressing and releasing the escape key (or equivalently, Ctrl-[), then press and release the

key. If you have configured a Meta-key on your keyboard, for example with

the Ctrl-Meta-characters are directly accessible. For example, to enter

in order to call the

editor command in emacs mode, hold down the keys

and

at the same time. Alternatively, press and release the escape key, then press and release

In vi input mode, input characters are bound to the following editor commands by default:

All other input characters except the NUL character (Ctrl-@) are bound to

In vi command mode, input characters are bound to the following editor commands by default:

In emacs mode, input characters are bound to the following editor commands by default:

The remaining

characters in the range 0x20 to 0x7e are bound to

If standard output is not connected to a terminal device or

was used to set

to 0, all input character bindings are disabled and all characters typed are appended to the edit buffer. In that case, the edit buffer is returned to the program after a newline or carriage return character is typed, or after the first character typed if

was used to set

to non-zero.

Most editor commands accept an optional argument. The argument is entered by prefixing the editor command with one or more of the editor commands

or

When an argument is not provided, it defaults to 1. For most editor commands, the effect of an argument is to repeatedly execute the command that number of times.

When talking about a character string from a left character to a right character, the left character is included in the string, while the right character is not included.

If an editor command causes an error, the input character is discarded, no action occurs, and the terminal bell is rung. In case of a non-fatal error, the terminal bell is also rung, but the editor command takes effect anyway.

In the following list, the default key bindings are listed after each editor command.

If in argument input mode, append the input digit to the argument being read. Otherwise, switch to argument input mode and use the input digit as the most significant digit of the argument. It is an error if the input character is not a digit or if the existing argument is already greater than a million.

Clear the screen and display the edit buffer at the top. Ignore any argument.

Read a line from the terminal bypassing the normal line editing functionality and execute that line as an

builtin command. If in vi command mode, also switch back to vi insert mode. Ignore any argument.

Delete the character at the cursor position. With an argument, delete that number of characters. In emacs mode, it is an error if the cursor is at the end of the edit buffer. In vi mode, the last character in the edit buffer is deleted in that case, and it is an error if the buffer is empty.

Delete the character to the left of the cursor position. With an argument, delete that number of characters. It is an error if the cursor is at the beginning of the edit buffer.

Move to the left to the closest beginning of a word, delete the string from that position to the cursor, and save it to the cut buffer. With an argument, delete that number of words. It is an error if the cursor is at the beginning of the edit buffer.

If in argument input mode, append the input digit to the argument being read. Otherwise, call

It is an error if the input character is not a digit or if the existing argument is already greater than a million.

Discard the edit buffer and indicate end of file to the program. Ignore any argument.

Discard the input character and do nothing.

In insert mode, insert the input character left of the cursor position. In replace mode, overwrite the character at the cursor and move the cursor to the right by one character position. Accept an argument to do this repeatedly. It is an error if the input character is the NUL character (Ctrl-@). Failure to enlarge the edit buffer also results in an error.

Delete the string from the cursor position to the end of the line and save it to the cut buffer. Ignore any argument.

In vi mode, move the cursor to the first non-space character in the edit buffer. In emacs mode, move the cursor to the beginning of the edit buffer. Ignore any argument. Can be used as a movement command after

or

Move the cursor to the end of the edit buffer. Ignore any argument. Can be used as a movement command after

or

Append a newline character to the edit buffer and return the edit buffer to the program. Ignore any argument.

Move the cursor one character position to the right. With an argument, move by that number of characters. Can be used as a movement command after

or

It is an error if the cursor is already at the end of the edit buffer.

Replace the edit buffer with the next history line. That line is older than the current line. With an argument, go forward by that number of history lines. It is a non-fatal error to advance by more lines than are available.

Move the cursor down one line. With an argument, move down by that number of lines. It is an error if the edit buffer does not contain enough newline characters to the right of the cursor position.

Move the cursor one character position to the left. With an argument, move by that number of characters. Can be used as a movement command after

or

It is an error if the cursor is already at the beginning of the edit buffer.

Replace the edit buffer with the previous history line. That line is newer than the current line. With an argument, go back by that number of lines. It is a non-fatal error to back up by more lines than are available.

Move the cursor up one line. With an argument, move up by that number of lines. It is an error if the edit buffer does not contain enough newline characters to the left of the cursor position.

Move the cursor to the left to the closest beginning of a word. With an argument, repeat that number of times. Can be used as a movement command after

or

It is an error if the cursor is already at the beginning of the edit buffer.

Read one character from the terminal bypassing the normal line editing functionality and call

on it. If trying to read the character returns end of file or an error, call

instead.

Redisplay everything. Ignore any argument.

Replace the edit buffer with the next matching history entry.

Replace the edit buffer with the previous matching history entry.

Call a macro. See the section about

below for details.

Discard the contents of the edit buffer and start from scratch. Ignore any argument.

Exchange the character at the cursor position with the one to the left of it and move the cursor to the character to the right of the two exchanged characters. Ignore any argument. It is an error if the cursor is at the beginning of the edit buffer or if the edit buffer contains less than two characters.

This editor command always results in an error.

Capitalize the string from the cursor to the end of the current word. That is, if it contains at least one alphabetic character, convert the first alphabetic character to upper case, and convert all characters to the right of it to lower case. In any case, move the cursor to the next character after the end of the current word.

Copy the string from the beginning of the current word to the cursor and insert it to the left of the cursor. Move the cursor to the character after the inserted string. It is an error if the cursor is at the beginning of the edit buffer.

Copy the string from the cursor to the mark to the cut buffer. It is an error if the mark is not set.

Delete the string from the cursor to the end of the current word and save it to the cut buffer. It is an error if the cursor is at the end of the edit buffer.

If the cursor is not at the end of the line, delete the character at the cursor. If the edit buffer is empty, indicate end of file to the program. It is an error if the cursor is at the end of the edit buffer and the edit buffer is not empty.

Delete the character to the left of the cursor. It is an error if the cursor is at the beginning of the edit buffer.

Exchange the cursor and the mark.

Exchange the two characters to the left of the cursor. It is an error if the cursor is on the first or second character of the edit buffer.

Emacs incremental next search.

Emacs incremental reverse search.

Delete the entire contents of the edit buffer and save it to the cut buffer.

Delete the string from the cursor to the mark and save it to the cut buffer. It is an error if the mark is not set.

Convert the characters from the cursor to the end of the current word to lower case.

Set the bit 0x80 on the next character typed. Unless the resulting code point is printable, holding down the

key while typing that character is a simpler way to achieve the same effect.

Move the cursor to the end of the current word. Can be used as a movement command after

or

It is an error if the cursor is already at the end of the edit buffer.

Set the mark at the current cursor position.

Switch from insert to overwrite mode or vice versa.

If in argument input mode, multiply the argument by 4. Otherwise, switch to argument input mode and set the argument to 4. It is an error if the existing argument is already greater than a million.

Convert the characters from the cursor to the end of the current word to upper case.

Paste the cut buffer to the left of the cursor.

Switch to vi insert mode. Unless the cursor is already at the end of the edit buffer, move it one character position to the right.

Switch to vi insert mode and move the cursor to the end of the edit buffer.

If an alias function was defined by calling the

or

function with the argument

read one character from the terminal bypassing the normal line editing functionality, call the alias function passing the argument that was specified with

as the first argument and the character read, with an underscore prepended, as the second argument, and pass the string returned from the alias function to

It is an error if no alias function is defined or if trying to read the character results in end of file or an error.

Change the case of the character at the cursor and move the cursor one character position to the right. It is an error if the cursor is already at the end of the edit buffer.

Delete the string from the cursor to the position specified by the following movement command and save a copy of it to the cut buffer. When given twice in a row, instead delete the whole contents of the edit buffer and save a copy of it to the cut buffer. In either case, switch to vi insert mode after that.

Delete the string from the cursor position to the end of the line and save it to the cut buffer, then switch to vi insert mode.

Discard pending actions and arguments and switch to vi command mode. Unless the cursor is already at the beginning of the edit buffer, move it to the left by one character position.

Insert a

character at the beginning of the edit buffer and return the edit buffer to the program.

Delete the string from the cursor to the position specified by the following movement command and save a copy of it to the cut buffer. When given twice in a row, instead delete the whole contents of the edit buffer and save a copy of it to the cut buffer.

Delete the character to the left of the cursor. It is an error if the cursor is already at the beginning of the edit buffer.

Move the cursor to the end of the current space delimited word. Can be used as a movement command after

or

It is an error if the cursor is already at the end of the edit buffer.

Move the cursor to the end of the current word. Can be used as a movement command after

or

It is an error if the cursor is already at the end of the edit buffer.

Insert the first word from the most recent history entry after the cursor, move the cursor after to the character after the inserted word, and switch to vi insert mode. It is an error if there is no history entry or the most recent history entry is empty.

Enter insert mode.

Move the cursor to the beginning of the edit buffer and switch to vi insert mode.

Delete the string from the beginning of the edit buffer to the cursor and save it to the cut buffer.

If the edit buffer is empty, indicate end of file to the program. It is an error if the edit buffer is not empty.

Consider opening and closing parentheses, braces, and brackets as delimiters. If the cursor is not at a delimiter, move it to the right until it gets to one, then move it to the matching delimiter. Can be used as a movement command after

or

It is an error if there is no delimiter at the cursor or in the string to the right of the cursor, or if the first such delimiter has no matching delimiter.

Move the cursor to the right to the beginning of the next space delimited word. Can be used as a movement command after

or

It is an error if the cursor is already at the end of the edit buffer or on its last character.

Read one character from the terminal bypassing the normal line editing functionality and move the cursor to the right to the next instance of that character in the edit buffer. Can be used as a movement command after

or

If trying to read the character results in end of file or an error, call

instead. It is an error if the character is not found searching to the right in the edit buffer.

Move the cursor to the right to the beginning of the next word. Can be used as a movement command after

or

It is an error if the cursor is already at the end of the edit buffer or on its last character.

Insert a copy of the cut buffer to the right of the cursor. It is an error if the cut buffer is empty.

Insert a copy of the cut buffer to the left of the cursor. It is an error if the cut buffer is empty.

Move the cursor to the left to the next beginning of a space delimited word. Can be used as a movement command after

or

It is an error if the cursor is already at the beginning of the edit buffer.

Read one character from the terminal bypassing the normal line editing functionality and move the cursor to the left to the next instance of that character in the edit buffer. Can be used as a movement command after

or

If trying to read the character results in end of file or an error, call

instead. It is an error if the character is not found searching to the left in the edit buffer.

Move the cursor to the left to the next beginning of a word. Can be used as a movement command after

or

It is an error if the cursor is already at the beginning of the edit buffer.

Redo the last non-motion command.

Repeat the most recent character search in the same search direction. Can be used as a movement command after

or

Repeat the most recent character search in the opposite search direction. Can be used as a movement command after

or

Repeat the most recent history search in the same search direction.

Repeat the most recent history search in the opposite search direction.

Switch to vi replace mode, and automatically switch back to vi command mode after the next character typed. See

for a description of replace mode. It is an error if the cursor is at the end of the edit buffer.

Switch to vi replace mode. This is a variant of vi insert mode; see

for the difference.

Replace the edit buffer with the next matching history entry.

Replace the edit buffer with the previous matching history entry.

Delete the character at the cursor and switch to vi insert mode.

Delete the entire contents of the edit buffer, save a copy of it in the cut buffer, and enter vi insert mode.

Move the cursor to the column specified as the argument. Can be used as a movement command after

or

Replace the edit buffer with the specified history entry.

Read one character from the terminal bypassing the normal line editing functionality and move the cursor to the right to the character before the next instance of that character in the edit buffer. Can be used as a movement command after

or

If trying to read the character results in end of file or an error, call

instead. It is an error if the character is not found searching to the right in the edit buffer.

Read one character from the terminal bypassing the normal line editing functionality and move the cursor to the left to the character after the next instance of that character in the edit buffer. Can be used as a movement command after

or

If trying to read the character results in end of file or an error, call

instead. It is an error if the character is not found searching to the left in the edit buffer.

Undo the last change.

Undo all changes to the edit buffer.

Copy the string from the cursor to the position specified by the following movement command to the cut buffer. When given twice in a row, instead copy the whole contents of the edit buffer to the cut buffer.

Copy the string from the cursor to the end of the edit buffer to the cut buffer.

If in argument input mode, multiply the argument by ten. Otherwise, move the cursor to the beginning of the edit buffer. Can be used as a movement command after

or

If an input character is bound to the editor command

attempts to call a macro. If the input character by itself forms the name of a macro, that macro is executed. Otherwise, additional input characters are read until the string read forms the name of a macro, in which case that macro is executed, or until the string read matches the beginning of none of the existing macro names, in which case the string including the final, mismatching character is discarded and the terminal bell is rung.

There are two kinds of macros. Command macros execute a single editor command. Keyboard macros return a string of characters that is appended as a new line to the

The following command macros are defined by default in vi command mode and in emacs mode:

In vi command mode, they are also defined by default without the initial escape character.

In addition, the

library tries to bind the strings generated by the arrow keys as reported by the

database to these editor commands, unless that would clobber user settings.

In emacs mode, the two-character string

is bound to the

editor command.

The

library maintains an input queue operated in FIFO mode. Whenever it needs an input character, it takes the first character from the first line of the input queue. When the queue is empty, it reads from the terminal.

A line can be appended to the end of the input queue in several ways:

By calling one of the keyboard

By calling the editor command

By calling the editor command

By pressing a key in emacs incremental search mode that doesn’t have a special meaning in that mode but returns to normal emacs mode.

If an application program directly calls the functions

or

it can provide additional, program-specific ways of appending to the input queue.

This manual page first appeared in

and

This manual page was written by

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

434 - Linux cli command LOCK

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command LOCK and provides detailed information about the command LOCK, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the LOCK.

NAME 🖥️ LOCK 🖥️

lock a table

SYNOPSIS

LOCK [ TABLE ] [ ONLY ] name [ * ] [, ...] [ IN lockmode MODE ] [ NOWAIT ]

where lockmode is one of:

    ACCESS SHARE | ROW SHARE | ROW EXCLUSIVE | SHARE UPDATE EXCLUSIVE
    | SHARE | SHARE ROW EXCLUSIVE | EXCLUSIVE | ACCESS EXCLUSIVE

DESCRIPTION

LOCK TABLE obtains a table-level lock, waiting if necessary for any conflicting locks to be released. If NOWAIT is specified, LOCK TABLE does not wait to acquire the desired lock: if it cannot be acquired immediately, the command is aborted and an error is emitted. Once obtained, the lock is held for the remainder of the current transaction. (There is no UNLOCK TABLE command; locks are always released at transaction end.)

When a view is locked, all relations appearing in the view definition query are also locked recursively with the same lock mode.

When acquiring locks automatically for commands that reference tables, PostgreSQL always uses the least restrictive lock mode possible. LOCK TABLE provides for cases when you might need more restrictive locking. For example, suppose an application runs a transaction at the READ COMMITTED isolation level and needs to ensure that data in a table remains stable for the duration of the transaction. To achieve this you could obtain SHARE lock mode over the table before querying. This will prevent concurrent data changes and ensure subsequent reads of the table see a stable view of committed data, because SHARE lock mode conflicts with the ROW EXCLUSIVE lock acquired by writers, and your LOCK TABLE name IN SHARE MODE statement will wait until any concurrent holders of ROW EXCLUSIVE mode locks commit or roll back. Thus, once you obtain the lock, there are no uncommitted writes outstanding; furthermore none can begin until you release the lock.

To achieve a similar effect when running a transaction at the REPEATABLE READ or SERIALIZABLE isolation level, you have to execute the LOCK TABLE statement before executing any SELECT or data modification statement. A REPEATABLE READ or SERIALIZABLE transactions view of data will be frozen when its first SELECT or data modification statement begins. A LOCK TABLE later in the transaction will still prevent concurrent writes — but it wont ensure that what the transaction reads corresponds to the latest committed values.

If a transaction of this sort is going to change the data in the table, then it should use SHARE ROW EXCLUSIVE lock mode instead of SHARE mode. This ensures that only one transaction of this type runs at a time. Without this, a deadlock is possible: two transactions might both acquire SHARE mode, and then be unable to also acquire ROW EXCLUSIVE mode to actually perform their updates. (Note that a transactions own locks never conflict, so a transaction can acquire ROW EXCLUSIVE mode when it holds SHARE mode — but not if anyone else holds SHARE mode.) To avoid deadlocks, make sure all transactions acquire locks on the same objects in the same order, and if multiple lock modes are involved for a single object, then transactions should always acquire the most restrictive mode first.

More information about the lock modes and locking strategies can be found in Section 13.3.

PARAMETERS

name

The name (optionally schema-qualified) of an existing table to lock. If ONLY is specified before the table name, only that table is locked. If ONLY is not specified, the table and all its descendant tables (if any) are locked. Optionally, * can be specified after the table name to explicitly indicate that descendant tables are included.

The command LOCK TABLE a, b; is equivalent to LOCK TABLE a; LOCK TABLE b;. The tables are locked one-by-one in the order specified in the LOCK TABLE command.

lockmode

The lock mode specifies which locks this lock conflicts with. Lock modes are described in Section 13.3.

If no lock mode is specified, then ACCESS EXCLUSIVE, the most restrictive mode, is used.

NOWAIT

Specifies that LOCK TABLE should not wait for any conflicting locks to be released: if the specified lock(s) cannot be acquired immediately without waiting, the transaction is aborted.

NOTES

To lock a table, the user must have the right privilege for the specified lockmode, or be the tables owner or a superuser. If the user has UPDATE, DELETE, or TRUNCATE privileges on the table, any lockmode is permitted. If the user has INSERT privileges on the table, ROW EXCLUSIVE MODE (or a less-conflicting mode as described in Section 13.3) is permitted. If a user has SELECT privileges on the table, ACCESS SHARE MODE is permitted.

The user performing the lock on the view must have the corresponding privilege on the view. In addition, by default, the views owner must have the relevant privileges on the underlying base relations, whereas the user performing the lock does not need any permissions on the underlying base relations. However, if the view has security_invoker set to true (see CREATE VIEW), the user performing the lock, rather than the view owner, must have the relevant privileges on the underlying base relations.

LOCK TABLE is useless outside a transaction block: the lock would remain held only to the completion of the statement. Therefore PostgreSQL reports an error if LOCK is used outside a transaction block. Use BEGIN and COMMIT (or ROLLBACK) to define a transaction block.

LOCK TABLE only deals with table-level locks, and so the mode names involving ROW are all misnomers. These mode names should generally be read as indicating the intention of the user to acquire row-level locks within the locked table. Also, ROW EXCLUSIVE mode is a shareable table lock. Keep in mind that all the lock modes have identical semantics so far as LOCK TABLE is concerned, differing only in the rules about which modes conflict with which. For information on how to acquire an actual row-level lock, see Section 13.3.2 and The Locking Clause in the SELECT(7) documentation.

EXAMPLES

Obtain a SHARE lock on a primary key table when going to perform inserts into a foreign key table:

BEGIN WORK; LOCK TABLE films IN SHARE MODE; SELECT id FROM films WHERE name = Star Wars: Episode I - The Phantom Menace; – Do ROLLBACK if record was not returned INSERT INTO films_user_comments VALUES (id, GREAT! I was waiting for it for so long!); COMMIT WORK;

Take a SHARE ROW EXCLUSIVE lock on a primary key table when going to perform a delete operation:

BEGIN WORK; LOCK TABLE films IN SHARE ROW EXCLUSIVE MODE; DELETE FROM films_user_comments WHERE id IN (SELECT id FROM films WHERE rating < 5); DELETE FROM films WHERE rating < 5; COMMIT WORK;

COMPATIBILITY

There is no LOCK TABLE in the SQL standard, which instead uses SET TRANSACTION to specify concurrency levels on transactions. PostgreSQL supports that too; see SET TRANSACTION (SET_TRANSACTION(7)) for details.

Except for ACCESS SHARE, ACCESS EXCLUSIVE, and SHARE UPDATE EXCLUSIVE lock modes, the PostgreSQL lock modes and the LOCK TABLE syntax are compatible with those present in Oracle.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

435 - Linux cli command DROP_TEXT_SEARCH_CONFIGURATION

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_TEXT_SEARCH_CONFIGURATION and provides detailed information about the command DROP_TEXT_SEARCH_CONFIGURATION, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_TEXT_SEARCH_CONFIGURATION.

NAME 🖥️ DROP_TEXT_SEARCH_CONFIGURATION 🖥️

remove a text search configuration

SYNOPSIS

DROP TEXT SEARCH CONFIGURATION [ IF EXISTS ] name [ CASCADE | RESTRICT ]

DESCRIPTION

DROP TEXT SEARCH CONFIGURATION drops an existing text search configuration. To execute this command you must be the owner of the configuration.

PARAMETERS

IF EXISTS

Do not throw an error if the text search configuration does not exist. A notice is issued in this case.

name

The name (optionally schema-qualified) of an existing text search configuration.

CASCADE

Automatically drop objects that depend on the text search configuration, and in turn all objects that depend on those objects (see Section 5.14).

RESTRICT

Refuse to drop the text search configuration if any objects depend on it. This is the default.

EXAMPLES

Remove the text search configuration my_english:

DROP TEXT SEARCH CONFIGURATION my_english;

This command will not succeed if there are any existing indexes that reference the configuration in to_tsvector calls. Add CASCADE to drop such indexes along with the text search configuration.

COMPATIBILITY

There is no DROP TEXT SEARCH CONFIGURATION statement in the SQL standard.

SEE ALSO

ALTER TEXT SEARCH CONFIGURATION (ALTER_TEXT_SEARCH_CONFIGURATION(7)), CREATE TEXT SEARCH CONFIGURATION (CREATE_TEXT_SEARCH_CONFIGURATION(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

436 - Linux cli command fifo

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command fifo and provides detailed information about the command fifo, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the fifo.

NAME 🖥️ fifo 🖥️

first-in first-out special file, named pipe

DESCRIPTION

A FIFO special file (a named pipe) is similar to a pipe, except that it is accessed as part of the filesystem. It can be opened by multiple processes for reading or writing. When processes are exchanging data via the FIFO, the kernel passes all data internally without writing it to the filesystem. Thus, the FIFO special file has no contents on the filesystem; the filesystem entry merely serves as a reference point so that processes can access the pipe using a name in the filesystem.

The kernel maintains exactly one pipe object for each FIFO special file that is opened by at least one process. The FIFO must be opened on both ends (reading and writing) before data can be passed. Normally, opening the FIFO blocks until the other end is opened also.

A process can open a FIFO in nonblocking mode. In this case, opening for read-only succeeds even if no one has opened on the write side yet and opening for write-only fails with ENXIO (no such device or address) unless the other end has already been opened.

Under Linux, opening a FIFO for read and write will succeed both in blocking and nonblocking mode. POSIX leaves this behavior undefined. This can be used to open a FIFO for writing while there are no readers available. A process that uses both ends of the connection in order to communicate with itself should be very careful to avoid deadlocks.

NOTES

For details of the semantics of I/O on FIFOs, see pipe(7).

When a process tries to write to a FIFO that is not opened for read on the other side, the process is sent a SIGPIPE signal.

FIFO special files can be created by mkfifo(3), and are indicated by ls -l with the file type ‘p’.

SEE ALSO

mkfifo(1), open(2), pipe(2), sigaction(2), signal(2), socketpair(2), mkfifo(3), pipe(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

437 - Linux cli command vsock

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command vsock and provides detailed information about the command vsock, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the vsock.

NAME 🖥️ vsock 🖥️

Linux VSOCK address family

SYNOPSIS

#include <sys/socket.h>
#include <linux/vm_sockets.h>
stream_socket = socket(AF_VSOCK, SOCK_STREAM, 0);
datagram_socket = socket(AF_VSOCK, SOCK_DGRAM, 0);

DESCRIPTION

The VSOCK address family facilitates communication between virtual machines and the host they are running on. This address family is used by guest agents and hypervisor services that need a communications channel that is independent of virtual machine network configuration.

Valid socket types are SOCK_STREAM and SOCK_DGRAM. SOCK_STREAM provides connection-oriented byte streams with guaranteed, in-order delivery. SOCK_DGRAM provides a connectionless datagram packet service with best-effort delivery and best-effort ordering. Availability of these socket types is dependent on the underlying hypervisor.

A new socket is created with

socket(AF_VSOCK, socket_type, 0);

When a process wants to establish a connection, it calls connect(2) with a given destination socket address. The socket is automatically bound to a free port if unbound.

A process can listen for incoming connections by first binding to a socket address using bind(2) and then calling listen(2).

Data is transmitted using the send(2) or write(2) families of system calls and data is received using the recv(2) or read(2) families of system calls.

Address format

A socket address is defined as a combination of a 32-bit Context Identifier (CID) and a 32-bit port number. The CID identifies the source or destination, which is either a virtual machine or the host. The port number differentiates between multiple services running on a single machine.

struct sockaddr_vm {
    sa_family_t    svm_family;    /* Address family: AF_VSOCK */
    unsigned short svm_reserved1;
    unsigned int   svm_port;      /* Port # in host byte order */
    unsigned int   svm_cid;       /* Address in host byte order */
    unsigned char  svm_zero[sizeof(struct sockaddr) -
                            sizeof(sa_family_t) -
                            sizeof(unsigned short) -
                            sizeof(unsigned int) -
                            sizeof(unsigned int)];
};

svm_family is always set to AF_VSOCK. svm_reserved1 is always set to 0. svm_port contains the port number in host byte order. The port numbers below 1024 are called privileged ports. Only a process with the CAP_NET_BIND_SERVICE capability may bind(2) to these port numbers. svm_zero must be zero-filled.

There are several special addresses: VMADDR_CID_ANY (-1U) means any address for binding; VMADDR_CID_HYPERVISOR (0) is reserved for services built into the hypervisor; VMADDR_CID_LOCAL (1) is the well-known address for local communication (loopback); VMADDR_CID_HOST (2) is the well-known address of the host.

The special constant VMADDR_PORT_ANY (-1U) means any port number for binding.

Live migration

Sockets are affected by live migration of virtual machines. Connected SOCK_STREAM sockets become disconnected when the virtual machine migrates to a new host. Applications must reconnect when this happens.

The local CID may change across live migration if the old CID is not available on the new host. Bound sockets are automatically updated to the new CID.

Ioctls

The following ioctls are available on the /dev/vsock device.

IOCTL_VM_SOCKETS_GET_LOCAL_CID
Get the CID of the local machine. The argument is a pointer to an unsigned int.

ioctl(fd, IOCTL_VM_SOCKETS_GET_LOCAL_CID, &cid);

Consider using VMADDR_CID_ANY when binding instead of getting the local CID with IOCTL_VM_SOCKETS_GET_LOCAL_CID.

Local communication

VMADDR_CID_LOCAL (1) directs packets to the same host that generated them. This is useful for testing applications on a single host and for debugging.

The local CID obtained with IOCTL_VM_SOCKETS_GET_LOCAL_CID can be used for the same purpose, but it is preferable to use VMADDR_CID_LOCAL.

ERRORS

EACCES
Unable to bind to a privileged port without the CAP_NET_BIND_SERVICE capability.

EADDRINUSE
Unable to bind to a port that is already in use.

EADDRNOTAVAIL
Unable to find a free port for binding or unable to bind to a nonlocal CID.

EINVAL
Invalid parameters. This includes: attempting to bind a socket that is already bound, providing an invalid struct sockaddr_vm, and other input validation errors.

ENOPROTOOPT
Invalid socket option in setsockopt(2) or getsockopt(2).

ENOTCONN
Unable to perform operation on an unconnected socket.

EOPNOTSUPP
Operation not supported. This includes: the MSG_OOB flag that is not implemented for the send(2) family of syscalls and MSG_PEEK for the recv(2) family of syscalls.

EPROTONOSUPPORT
Invalid socket protocol number. The protocol should always be 0.

ESOCKTNOSUPPORT
Unsupported socket type in socket(2). Only SOCK_STREAM and SOCK_DGRAM are valid.

VERSIONS

Support for VMware (VMCI) has been available since Linux 3.9. KVM (virtio) is supported since Linux 4.8. Hyper-V is supported since Linux 4.14.

VMADDR_CID_LOCAL is supported since Linux 5.6. Local communication in the guest and on the host is available since Linux 5.6. Previous versions supported only local communication within a guest (not on the host), and with only some transports (VMCI and virtio).

SEE ALSO

bind(2), connect(2), listen(2), recv(2), send(2), socket(2), capabilities(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

438 - Linux cli command CREATE_TABLESPACE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_TABLESPACE and provides detailed information about the command CREATE_TABLESPACE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_TABLESPACE.

NAME 🖥️ CREATE_TABLESPACE 🖥️

define a new tablespace

SYNOPSIS

CREATE TABLESPACE tablespace_name
    [ OWNER { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER } ]
    LOCATION directory
    [ WITH ( tablespace_option = value [, ... ] ) ]

DESCRIPTION

CREATE TABLESPACE registers a new cluster-wide tablespace. The tablespace name must be distinct from the name of any existing tablespace in the database cluster.

A tablespace allows superusers to define an alternative location on the file system where the data files containing database objects (such as tables and indexes) can reside.

A user with appropriate privileges can pass tablespace_name to CREATE DATABASE, CREATE TABLE, CREATE INDEX or ADD CONSTRAINT to have the data files for these objects stored within the specified tablespace.

Warning

A tablespace cannot be used independently of the cluster in which it is defined; see Section 23.6.

PARAMETERS

tablespace_name

The name of a tablespace to be created. The name cannot begin with pg_, as such names are reserved for system tablespaces.

user_name

The name of the user who will own the tablespace. If omitted, defaults to the user executing the command. Only superusers can create tablespaces, but they can assign ownership of tablespaces to non-superusers.

directory

The directory that will be used for the tablespace. The directory must exist (CREATE TABLESPACE will not create it), should be empty, and must be owned by the PostgreSQL system user. The directory must be specified by an absolute path name.

tablespace_option

A tablespace parameter to be set or reset. Currently, the only available parameters are seq_page_cost, random_page_cost, effective_io_concurrency and maintenance_io_concurrency. Setting these values for a particular tablespace will override the planners usual estimate of the cost of reading pages from tables in that tablespace, and the executors prefetching behavior, as established by the configuration parameters of the same name (see seq_page_cost, random_page_cost, effective_io_concurrency, maintenance_io_concurrency). This may be useful if one tablespace is located on a disk which is faster or slower than the remainder of the I/O subsystem.

NOTES

CREATE TABLESPACE cannot be executed inside a transaction block.

EXAMPLES

To create a tablespace dbspace at file system location /data/dbs, first create the directory using operating system facilities and set the correct ownership:

mkdir /data/dbs chown postgres:postgres /data/dbs

Then issue the tablespace creation command inside PostgreSQL:

CREATE TABLESPACE dbspace LOCATION /data/dbs;

To create a tablespace owned by a different database user, use a command like this:

CREATE TABLESPACE indexspace OWNER genevieve LOCATION /data/indexes;

COMPATIBILITY

CREATE TABLESPACE is a PostgreSQL extension.

SEE ALSO

CREATE DATABASE (CREATE_DATABASE(7)), CREATE TABLE (CREATE_TABLE(7)), CREATE INDEX (CREATE_INDEX(7)), DROP TABLESPACE (DROP_TABLESPACE(7)), ALTER TABLESPACE (ALTER_TABLESPACE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

439 - Linux cli command CREATE_TEXT_SEARCH_TEMPLATE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_TEXT_SEARCH_TEMPLATE and provides detailed information about the command CREATE_TEXT_SEARCH_TEMPLATE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_TEXT_SEARCH_TEMPLATE.

NAME 🖥️ CREATE_TEXT_SEARCH_TEMPLATE 🖥️

define a new text search template

SYNOPSIS

CREATE TEXT SEARCH TEMPLATE name (
    [ INIT = init_function , ]
    LEXIZE = lexize_function
)

DESCRIPTION

CREATE TEXT SEARCH TEMPLATE creates a new text search template. Text search templates define the functions that implement text search dictionaries. A template is not useful by itself, but must be instantiated as a dictionary to be used. The dictionary typically specifies parameters to be given to the template functions.

If a schema name is given then the text search template is created in the specified schema. Otherwise it is created in the current schema.

You must be a superuser to use CREATE TEXT SEARCH TEMPLATE. This restriction is made because an erroneous text search template definition could confuse or even crash the server. The reason for separating templates from dictionaries is that a template encapsulates the “unsafe” aspects of defining a dictionary. The parameters that can be set when defining a dictionary are safe for unprivileged users to set, and so creating a dictionary need not be a privileged operation.

Refer to Chapter 12 for further information.

PARAMETERS

name

The name of the text search template to be created. The name can be schema-qualified.

init_function

The name of the init function for the template.

lexize_function

The name of the lexize function for the template.

The function names can be schema-qualified if necessary. Argument types are not given, since the argument list for each type of function is predetermined. The lexize function is required, but the init function is optional.

The arguments can appear in any order, not only the one shown above.

COMPATIBILITY

There is no CREATE TEXT SEARCH TEMPLATE statement in the SQL standard.

SEE ALSO

ALTER TEXT SEARCH TEMPLATE (ALTER_TEXT_SEARCH_TEMPLATE(7)), DROP TEXT SEARCH TEMPLATE (DROP_TEXT_SEARCH_TEMPLATE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

440 - Linux cli command des_modesssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command des_modesssl and provides detailed information about the command des_modesssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the des_modesssl.

NAME 🖥️ des_modesssl 🖥️

the variants of DES and other crypto algorithms of OpenSSL

DESCRIPTION

Several crypto algorithms for OpenSSL can be used in a number of modes. Those are used for using block ciphers in a way similar to stream ciphers, among other things.

OVERVIEW

Electronic Codebook Mode (ECB)

Normally, this is found as the function algorithm**_ecb_encrypt()**.

  • 64 bits are enciphered at a time.

  • The order of the blocks can be rearranged without detection.

  • The same plaintext block always produces the same ciphertext block (for the same key) making it vulnerable to a ‘dictionary attack’.

  • An error will only affect one ciphertext block.

Cipher Block Chaining Mode (CBC)

Normally, this is found as the function algorithm**_cbc_encrypt()**. Be aware that des_cbc_encrypt() is not really DES CBC (it does not update the IV); use des_ncbc_encrypt() instead.

  • a multiple of 64 bits are enciphered at a time.

  • The CBC mode produces the same ciphertext whenever the same plaintext is encrypted using the same key and starting variable.

  • The chaining operation makes the ciphertext blocks dependent on the current and all preceding plaintext blocks and therefore blocks can not be rearranged.

  • The use of different starting variables prevents the same plaintext enciphering to the same ciphertext.

  • An error will affect the current and the following ciphertext blocks.

Cipher Feedback Mode (CFB)

Normally, this is found as the function algorithm**_cfb_encrypt()**.

  • a number of bits (j) <= 64 are enciphered at a time.

  • The CFB mode produces the same ciphertext whenever the same plaintext is encrypted using the same key and starting variable.

  • The chaining operation makes the ciphertext variables dependent on the current and all preceding variables and therefore j-bit variables are chained together and can not be rearranged.

  • The use of different starting variables prevents the same plaintext enciphering to the same ciphertext.

  • The strength of the CFB mode depends on the size of k (maximal if j == k). In my implementation this is always the case.

  • Selection of a small value for j will require more cycles through the encipherment algorithm per unit of plaintext and thus cause greater processing overheads.

  • Only multiples of j bits can be enciphered.

  • An error will affect the current and the following ciphertext variables.

Output Feedback Mode (OFB)

Normally, this is found as the function algorithm**_ofb_encrypt()**.

  • a number of bits (j) <= 64 are enciphered at a time.

  • The OFB mode produces the same ciphertext whenever the same plaintext enciphered using the same key and starting variable. More over, in the OFB mode the same key stream is produced when the same key and start variable are used. Consequently, for security reasons a specific start variable should be used only once for a given key.

  • The absence of chaining makes the OFB more vulnerable to specific attacks.

  • The use of different start variables values prevents the same plaintext enciphering to the same ciphertext, by producing different key streams.

  • Selection of a small value for j will require more cycles through the encipherment algorithm per unit of plaintext and thus cause greater processing overheads.

  • Only multiples of j bits can be enciphered.

  • OFB mode of operation does not extend ciphertext errors in the resultant plaintext output. Every bit error in the ciphertext causes only one bit to be in error in the deciphered plaintext.

  • OFB mode is not self-synchronizing. If the two operation of encipherment and decipherment get out of synchronism, the system needs to be re-initialized.

  • Each re-initialization should use a value of the start variable different from the start variable values used before with the same key. The reason for this is that an identical bit stream would be produced each time from the same parameters. This would be susceptible to a ‘known plaintext’ attack.

Triple ECB Mode

Normally, this is found as the function algorithm**_ecb3_encrypt()**.

  • Encrypt with key1, decrypt with key2 and encrypt with key3 again.

  • As for ECB encryption but increases the key length to 168 bits. There are theoretic attacks that can be used that make the effective key length 112 bits, but this attack also requires 2^56 blocks of memory, not very likely, even for the NSA.

  • If both keys are the same it is equivalent to encrypting once with just one key.

  • If the first and last key are the same, the key length is 112 bits. There are attacks that could reduce the effective key strength to only slightly more than 56 bits, but these require a lot of memory.

  • If all 3 keys are the same, this is effectively the same as normal ecb mode.

Triple CBC Mode

Normally, this is found as the function algorithm**_ede3_cbc_encrypt()**.

  • Encrypt with key1, decrypt with key2 and then encrypt with key3.

  • As for CBC encryption but increases the key length to 168 bits with the same restrictions as for triple ecb mode.

NOTES

This text was been written in large parts by Eric Young in his original documentation for SSLeay, the predecessor of OpenSSL. In turn, he attributed it to:

AS 2805.5.2 Australian Standard Electronic funds transfer - Requirements for interfaces, Part 5.2: Modes of operation for an n-bit block cipher algorithm Appendix A

SEE ALSO

BF_encrypt (3), DES_crypt (3)

COPYRIGHT

Copyright 2000-2017 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

441 - Linux cli command sigevent

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command sigevent and provides detailed information about the command sigevent, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the sigevent.
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

442 - Linux cli command units

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command units and provides detailed information about the command units, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the units.

NAME 🖥️ units 🖥️

decimal and binary prefixes

DESCRIPTION

Decimal prefixes

The SI system of units uses prefixes that indicate powers of ten. A kilometer is 1000 meter, and a megawatt is 1000000 watt. Below the standard prefixes.

PrefixNameValue
qquecto10^-30 = 0.000000000000000000000000000001
rronto10^-27 = 0.000000000000000000000000001
yyocto10^-24 = 0.000000000000000000000001
zzepto10^-21 = 0.000000000000000000001
aatto10^-18 = 0.000000000000000001
ffemto10^-15 = 0.000000000000001
ppico10^-12 = 0.000000000001
nnano10^-9 = 0.000000001
µmicro10^-6 = 0.000001
mmilli10^-3 = 0.001
ccenti10^-2 = 0.01
ddeci10^-1 = 0.1
dadeka10^ 1 = 10
hhecto10^ 2 = 100
kkilo10^ 3 = 1000
Mmega10^ 6 = 1000000
Ggiga10^ 9 = 1000000000
Ttera10^12 = 1000000000000
Ppeta10^15 = 1000000000000000
Eexa10^18 = 1000000000000000000
Zzetta10^21 = 1000000000000000000000
Yyotta10^24 = 1000000000000000000000000
Rronna10^27 = 1000000000000000000000000000
Qquetta10^30 = 1000000000000000000000000000000

The symbol for micro is the Greek letter mu, often written u in an ASCII context where this Greek letter is not available.

Binary prefixes

The binary prefixes resemble the decimal ones, but have an additional ‘i’ (and “Ki” starts with a capital ‘K’). The names are formed by taking the first syllable of the names of the decimal prefix with roughly the same size, followed by “bi” for “binary”.

PrefixNameValue
Kikibi2^10 = 1024
Mimebi2^20 = 1048576
Gigibi2^30 = 1073741824
Titebi2^40 = 1099511627776
Pipebi2^50 = 1125899906842624
Eiexbi2^60 = 1152921504606846976
Zizebi2^70 = 1180591620717411303424
Yiyobi2^80 = 1208925819614629174706176

Discussion

Before these binary prefixes were introduced, it was fairly common to use k=1000 and K=1024, just like b=bit, B=byte. Unfortunately, the M is capital already, and cannot be capitalized to indicate binary-ness.

At first that didn’t matter too much, since memory modules and disks came in sizes that were powers of two, so everyone knew that in such contexts “kilobyte” and “megabyte” meant 1024 and 1048576 bytes, respectively. What originally was a sloppy use of the prefixes “kilo” and “mega” started to become regarded as the “real true meaning” when computers were involved. But then disk technology changed, and disk sizes became arbitrary numbers. After a period of uncertainty all disk manufacturers settled on the standard, namely k=1000, M=1000 k, G=1000 M.

The situation was messy: in the 14k4 modems, k=1000; in the 1.44 MB diskettes, M=1024000; and so on. In 1998 the IEC approved the standard that defines the binary prefixes given above, enabling people to be precise and unambiguous.

Thus, today, MB = 1000000 B and MiB = 1048576 B.

In the free software world programs are slowly being changed to conform. When the Linux kernel boots and says

hda: 120064896 sectors (61473 MB) w/2048KiB Cache

the MB are megabytes and the KiB are kibibytes.

SEE ALSO

The International System of Units.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

443 - Linux cli command CREATE_ACCESS_METHOD

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_ACCESS_METHOD and provides detailed information about the command CREATE_ACCESS_METHOD, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_ACCESS_METHOD.

NAME 🖥️ CREATE_ACCESS_METHOD 🖥️

define a new access method

SYNOPSIS

CREATE ACCESS METHOD name
    TYPE access_method_type
    HANDLER handler_function

DESCRIPTION

CREATE ACCESS METHOD creates a new access method.

The access method name must be unique within the database.

Only superusers can define new access methods.

PARAMETERS

name

The name of the access method to be created.

access_method_type

This clause specifies the type of access method to define. Only TABLE and INDEX are supported at present.

handler_function

handler_function is the name (possibly schema-qualified) of a previously registered function that represents the access method. The handler function must be declared to take a single argument of type internal, and its return type depends on the type of access method; for TABLE access methods, it must be table_am_handler and for INDEX access methods, it must be index_am_handler. The C-level API that the handler function must implement varies depending on the type of access method. The table access method API is described in Chapter 63 and the index access method API is described in Chapter 64.

EXAMPLES

Create an index access method heptree with handler function heptree_handler:

CREATE ACCESS METHOD heptree TYPE INDEX HANDLER heptree_handler;

COMPATIBILITY

CREATE ACCESS METHOD is a PostgreSQL extension.

SEE ALSO

DROP ACCESS METHOD (DROP_ACCESS_METHOD(7)), CREATE OPERATOR CLASS (CREATE_OPERATOR_CLASS(7)), CREATE OPERATOR FAMILY (CREATE_OPERATOR_FAMILY(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

444 - Linux cli command EVP_KEYEXCH-DHssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KEYEXCH-DHssl and provides detailed information about the command EVP_KEYEXCH-DHssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KEYEXCH-DHssl.

NAME 🖥️ EVP_KEYEXCH-DHssl 🖥️

DH - DH Key Exchange algorithm support

DESCRIPTION

Key exchange support for the DH key type.

DH key exchange parameters

“pad” (OSSL_EXCHANGE_PARAM_PAD) <unsigned integer>
Sets the padding mode for the associated key exchange ctx. Setting a value of 1 will turn padding on. Setting a value of 0 will turn padding off. If padding is off then the derived shared secret may be smaller than the largest possible secret size. If padding is on then the derived shared secret will have its first bytes filled with zeros where necessary to make the shared secret the same size as the largest possible secret size. The padding mode parameter is ignored (and padding implicitly enabled) when the KDF type is set to “X942KDF-ASN1” (OSSL_KDF_NAME_X942KDF_ASN1).

“kdf-type” (OSSL_EXCHANGE_PARAM_KDF_TYPE) <UTF8 string>
See “Common Key Exchange parameters” in provider-keyexch (7).

“kdf-digest” (OSSL_EXCHANGE_PARAM_KDF_DIGEST) <UTF8 string>
See “Common Key Exchange parameters” in provider-keyexch (7).

“kdf-digest-props” (OSSL_EXCHANGE_PARAM_KDF_DIGEST_PROPS) <UTF8 string>
See “Common Key Exchange parameters” in provider-keyexch (7).

“kdf-outlen” (OSSL_EXCHANGE_PARAM_KDF_OUTLEN) <unsigned integer>
See “Common Key Exchange parameters” in provider-keyexch (7).

“kdf-ukm” (OSSL_EXCHANGE_PARAM_KDF_UKM) <octet string>
See “Common Key Exchange parameters” in provider-keyexch (7).

“cekalg” (OSSL_KDF_PARAM_CEK_ALG) <octet string ptr>
See “KDF Parameters” in provider-kdf (7).

EXAMPLES

The examples assume a host and peer both generate keys using the same named group (or domain parameters). See “Examples” in EVP_PKEY-DH (7). Both the host and peer transfer their public key to each other.

To convert the peer’s generated key pair to a public key in DER format in order to transfer to the host:

EVP_PKEY *peer_key; /* It is assumed this contains the peers generated key */ unsigned char *peer_pub_der = NULL; int peer_pub_der_len; peer_pub_der_len = i2d_PUBKEY(peer_key, &peer_pub_der); … OPENSSL_free(peer_pub_der);

To convert the received peer’s public key from DER format on the host:

const unsigned char *pd = peer_pub_der; EVP_PKEY *peer_pub_key = d2i_PUBKEY(NULL, &pd, peer_pub_der_len); … EVP_PKEY_free(peer_pub_key);

To derive a shared secret on the host using the host’s key and the peer’s public key:

/* It is assumed that the host_key and peer_pub_key are set up */ void derive_secret(EVP_KEY *host_key, EVP_PKEY *peer_pub_key) { unsigned int pad = 1; OSSL_PARAM params[2]; unsigned char *secret = NULL; size_t secret_len = 0; EVP_PKEY_CTX *dctx = EVP_PKEY_CTX_new_from_pkey(NULL, host_key, NULL); EVP_PKEY_derive_init(dctx); /* Optionally set the padding */ params[0] = OSSL_PARAM_construct_uint(OSSL_EXCHANGE_PARAM_PAD, &pad); params[1] = OSSL_PARAM_construct_end(); EVP_PKEY_CTX_set_params(dctx, params); EVP_PKEY_derive_set_peer(dctx, peer_pub_key); /* Get the size by passing NULL as the buffer */ EVP_PKEY_derive(dctx, NULL, &secret_len); secret = OPENSSL_zalloc(secret_len); EVP_PKEY_derive(dctx, secret, &secret_len); … OPENSSL_clear_free(secret, secret_len); EVP_PKEY_CTX_free(dctx); }

Very similar code can be used by the peer to derive the same shared secret using the host’s public key and the peer’s generated key pair.

SEE ALSO

EVP_PKEY-DH (7), EVP_PKEY-FFC (7), EVP_PKEY (3), provider-keyexch (7), provider-keymgmt (7), OSSL_PROVIDER-default (7), OSSL_PROVIDER-FIPS (7),

COPYRIGHT

Copyright 2020-2022 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

445 - Linux cli command MERGE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command MERGE and provides detailed information about the command MERGE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the MERGE.

NAME 🖥️ MERGE 🖥️

conditionally insert, update, or delete rows of a table

SYNOPSIS

[ WITH with_query [, ...] ]
MERGE INTO [ ONLY ] target_table_name [ * ] [ [ AS ] target_alias ]
USING data_source ON join_condition
when_clause [...]

where data_source is:

{ [ ONLY ] source_table_name [ * ] | ( source_query ) } [ [ AS ] source_alias ]

and when_clause is:

{ WHEN MATCHED [ AND condition ] THEN { merge_update | merge_delete | DO NOTHING } |
  WHEN NOT MATCHED [ AND condition ] THEN { merge_insert | DO NOTHING } }

and merge_insert is:

INSERT [( column_name [, ...] )]
[ OVERRIDING { SYSTEM | USER } VALUE ]
{ VALUES ( { expression | DEFAULT } [, ...] ) | DEFAULT VALUES }

and merge_update is:

UPDATE SET { column_name = { expression | DEFAULT } |
             ( column_name [, ...] ) = [ ROW ] ( { expression | DEFAULT } [, ...] ) |
             ( column_name [, ...] ) = ( sub-SELECT )
           } [, ...]

and merge_delete is:

DELETE

DESCRIPTION

MERGE performs actions that modify rows in the target table identified as target_table_name, using the data_source. MERGE provides a single SQL statement that can conditionally INSERT, UPDATE or DELETE rows, a task that would otherwise require multiple procedural language statements.

First, the MERGE command performs a join from data_source to the target table producing zero or more candidate change rows. For each candidate change row, the status of MATCHED or NOT MATCHED is set just once, after which WHEN clauses are evaluated in the order specified. For each candidate change row, the first clause to evaluate as true is executed. No more than one WHEN clause is executed for any candidate change row.

MERGE actions have the same effect as regular UPDATE, INSERT, or DELETE commands of the same names. The syntax of those commands is different, notably that there is no WHERE clause and no table name is specified. All actions refer to the target table, though modifications to other tables may be made using triggers.

When DO NOTHING is specified, the source row is skipped. Since actions are evaluated in their specified order, DO NOTHING can be handy to skip non-interesting source rows before more fine-grained handling.

There is no separate MERGE privilege. If you specify an update action, you must have the UPDATE privilege on the column(s) of the target table that are referred to in the SET clause. If you specify an insert action, you must have the INSERT privilege on the target table. If you specify a delete action, you must have the DELETE privilege on the target table. If you specify a DO NOTHING action, you must have the SELECT privilege on at least one column of the target table. You will also need SELECT privilege on any column(s) of the data_source and of the target table referred to in any condition (including join_condition) or expression. Privileges are tested once at statement start and are checked whether or not particular WHEN clauses are executed.

MERGE is not supported if the target table is a materialized view, foreign table, or if it has any rules defined on it.

PARAMETERS

with_query

The WITH clause allows you to specify one or more subqueries that can be referenced by name in the MERGE query. See Section 7.8 and SELECT(7) for details. Note that WITH RECURSIVE is not supported by MERGE.

target_table_name

The name (optionally schema-qualified) of the target table to merge into. If ONLY is specified before the table name, matching rows are updated or deleted in the named table only. If ONLY is not specified, matching rows are also updated or deleted in any tables inheriting from the named table. Optionally, * can be specified after the table name to explicitly indicate that descendant tables are included. The ONLY keyword and * option do not affect insert actions, which always insert into the named table only.

target_alias

A substitute name for the target table. When an alias is provided, it completely hides the actual name of the table. For example, given MERGE INTO foo AS f, the remainder of the MERGE statement must refer to this table as f not foo.

source_table_name

The name (optionally schema-qualified) of the source table, view, or transition table. If ONLY is specified before the table name, matching rows are included from the named table only. If ONLY is not specified, matching rows are also included from any tables inheriting from the named table. Optionally, * can be specified after the table name to explicitly indicate that descendant tables are included.

source_query

A query (SELECT statement or VALUES statement) that supplies the rows to be merged into the target table. Refer to the SELECT(7) statement or VALUES(7) statement for a description of the syntax.

source_alias

A substitute name for the data source. When an alias is provided, it completely hides the actual name of the table or the fact that a query was issued.

join_condition

join_condition is an expression resulting in a value of type boolean (similar to a WHERE clause) that specifies which rows in the data_source match rows in the target table.

Warning

Only columns from the target table that attempt to match data_source rows should appear in join_condition. join_condition subexpressions that only reference the target tables columns can affect which action is taken, often in surprising ways.

when_clause

At least one WHEN clause is required.

If the WHEN clause specifies WHEN MATCHED and the candidate change row matches a row in the target table, the WHEN clause is executed if the condition is absent or it evaluates to true.

Conversely, if the WHEN clause specifies WHEN NOT MATCHED and the candidate change row does not match a row in the target table, the WHEN clause is executed if the condition is absent or it evaluates to true.

condition

An expression that returns a value of type boolean. If this expression for a WHEN clause returns true, then the action for that clause is executed for that row.

A condition on a WHEN MATCHED clause can refer to columns in both the source and the target relations. A condition on a WHEN NOT MATCHED clause can only refer to columns from the source relation, since by definition there is no matching target row. Only the system attributes from the target table are accessible.

merge_insert

The specification of an INSERT action that inserts one row into the target table. The target column names can be listed in any order. If no list of column names is given at all, the default is all the columns of the table in their declared order.

Each column not present in the explicit or implicit column list will be filled with a default value, either its declared default value or null if there is none.

If the target table is a partitioned table, each row is routed to the appropriate partition and inserted into it. If the target table is a partition, an error will occur if any input row violates the partition constraint.

Column names may not be specified more than once. INSERT actions cannot contain sub-selects.

Only one VALUES clause can be specified. The VALUES clause can only refer to columns from the source relation, since by definition there is no matching target row.

merge_update

The specification of an UPDATE action that updates the current row of the target table. Column names may not be specified more than once.

Neither a table name nor a WHERE clause are allowed.

merge_delete

Specifies a DELETE action that deletes the current row of the target table. Do not include the table name or any other clauses, as you would normally do with a DELETE(7) command.

column_name

The name of a column in the target table. The column name can be qualified with a subfield name or array subscript, if needed. (Inserting into only some fields of a composite column leaves the other fields null.) Do not include the tables name in the specification of a target column.

OVERRIDING SYSTEM VALUE

Without this clause, it is an error to specify an explicit value (other than DEFAULT) for an identity column defined as GENERATED ALWAYS. This clause overrides that restriction.

OVERRIDING USER VALUE

If this clause is specified, then any values supplied for identity columns defined as GENERATED BY DEFAULT are ignored and the default sequence-generated values are applied.

DEFAULT VALUES

All columns will be filled with their default values. (An OVERRIDING clause is not permitted in this form.)

expression

An expression to assign to the column. If used in a WHEN MATCHED clause, the expression can use values from the original row in the target table, and values from the data_source row. If used in a WHEN NOT MATCHED clause, the expression can use values from the data_source row.

DEFAULT

Set the column to its default value (which will be NULL if no specific default expression has been assigned to it).

sub-SELECT

A SELECT sub-query that produces as many output columns as are listed in the parenthesized column list preceding it. The sub-query must yield no more than one row when executed. If it yields one row, its column values are assigned to the target columns; if it yields no rows, NULL values are assigned to the target columns. The sub-query can refer to values from the original row in the target table, and values from the data_source row.

OUTPUTS

On successful completion, a MERGE command returns a command tag of the form

MERGE total_count

The total_count is the total number of rows changed (whether inserted, updated, or deleted). If total_count is 0, no rows were changed in any way.

NOTES

The following steps take place during the execution of MERGE.

1.

Perform any BEFORE STATEMENT triggers for all actions specified, whether or not their WHEN clauses match.

2.

Perform a join from source to target table. The resulting query will be optimized normally and will produce a set of candidate change rows. For each candidate change row,

1.

Evaluate whether each row is MATCHED or NOT MATCHED.

2.

Test each WHEN condition in the order specified until one returns true.

3.

When a condition returns true, perform the following actions:

1.

Perform any BEFORE ROW triggers that fire for the actions event type.

2.

Perform the specified action, invoking any check constraints on the target table.

3.

Perform any AFTER ROW triggers that fire for the actions event type.

3.

Perform any AFTER STATEMENT triggers for actions specified, whether or not they actually occur. This is similar to the behavior of an UPDATE statement that modifies no rows.

In summary, statement triggers for an event type (say, INSERT) will be fired whenever we specify an action of that kind. In contrast, row-level triggers will fire only for the specific event type being executed. So a MERGE command might fire statement triggers for both UPDATE and INSERT, even though only UPDATE row triggers were fired.

You should ensure that the join produces at most one candidate change row for each target row. In other words, a target row shouldnt join to more than one data source row. If it does, then only one of the candidate change rows will be used to modify the target row; later attempts to modify the row will cause an error. This can also occur if row triggers make changes to the target table and the rows so modified are then subsequently also modified by MERGE. If the repeated action is an INSERT, this will cause a uniqueness violation, while a repeated UPDATE or DELETE will cause a cardinality violation; the latter behavior is required by the SQL standard. This differs from historical PostgreSQL behavior of joins in UPDATE and DELETE statements where second and subsequent attempts to modify the same row are simply ignored.

If a WHEN clause omits an AND sub-clause, it becomes the final reachable clause of that kind (MATCHED or NOT MATCHED). If a later WHEN clause of that kind is specified it would be provably unreachable and an error is raised. If no final reachable clause is specified of either kind, it is possible that no action will be taken for a candidate change row.

The order in which rows are generated from the data source is indeterminate by default. A source_query can be used to specify a consistent ordering, if required, which might be needed to avoid deadlocks between concurrent transactions.

There is no RETURNING clause with MERGE. Actions of INSERT, UPDATE and DELETE cannot contain RETURNING or WITH clauses.

When MERGE is run concurrently with other commands that modify the target table, the usual transaction isolation rules apply; see Section 13.2 for an explanation on the behavior at each isolation level. You may also wish to consider using INSERT … ON CONFLICT as an alternative statement which offers the ability to run an UPDATE if a concurrent INSERT occurs. There are a variety of differences and restrictions between the two statement types and they are not interchangeable.

EXAMPLES

Perform maintenance on customer_accounts based upon new recent_transactions.

MERGE INTO customer_account ca USING recent_transactions t ON t.customer_id = ca.customer_id WHEN MATCHED THEN UPDATE SET balance = balance + transaction_value WHEN NOT MATCHED THEN INSERT (customer_id, balance) VALUES (t.customer_id, t.transaction_value);

Notice that this would be exactly equivalent to the following statement because the MATCHED result does not change during execution.

MERGE INTO customer_account ca USING (SELECT customer_id, transaction_value FROM recent_transactions) AS t ON t.customer_id = ca.customer_id WHEN MATCHED THEN UPDATE SET balance = balance + transaction_value WHEN NOT MATCHED THEN INSERT (customer_id, balance) VALUES (t.customer_id, t.transaction_value);

Attempt to insert a new stock item along with the quantity of stock. If the item already exists, instead update the stock count of the existing item. Dont allow entries that have zero stock.

MERGE INTO wines w USING wine_stock_changes s ON s.winename = w.winename WHEN NOT MATCHED AND s.stock_delta > 0 THEN INSERT VALUES(s.winename, s.stock_delta) WHEN MATCHED AND w.stock + s.stock_delta > 0 THEN UPDATE SET stock = w.stock + s.stock_delta WHEN MATCHED THEN DELETE;

The wine_stock_changes table might be, for example, a temporary table recently loaded into the database.

COMPATIBILITY

This command conforms to the SQL standard.

The WITH clause and DO NOTHING action are extensions to the SQL standard.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

446 - Linux cli command ABORT

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ABORT and provides detailed information about the command ABORT, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ABORT.

NAME 🖥️ ABORT 🖥️

abort the current transaction

SYNOPSIS

ABORT [ WORK | TRANSACTION ] [ AND [ NO ] CHAIN ]

DESCRIPTION

ABORT rolls back the current transaction and causes all the updates made by the transaction to be discarded. This command is identical in behavior to the standard SQL command ROLLBACK, and is present only for historical reasons.

PARAMETERS

WORK
TRANSACTION

Optional key words. They have no effect.

AND CHAIN

If AND CHAIN is specified, a new transaction is immediately started with the same transaction characteristics (see SET TRANSACTION) as the just finished one. Otherwise, no new transaction is started.

NOTES

Use COMMIT to successfully terminate a transaction.

Issuing ABORT outside of a transaction block emits a warning and otherwise has no effect.

EXAMPLES

To abort all changes:

ABORT;

COMPATIBILITY

This command is a PostgreSQL extension present for historical reasons. ROLLBACK is the equivalent standard SQL command.

SEE ALSO

BEGIN(7), COMMIT(7), ROLLBACK(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

447 - Linux cli command CREATE_TYPE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_TYPE and provides detailed information about the command CREATE_TYPE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_TYPE.

NAME 🖥️ CREATE_TYPE 🖥️

define a new data type

SYNOPSIS

CREATE TYPE name AS
    ( [ attribute_name data_type [ COLLATE collation ] [, ... ] ] )

CREATE TYPE name AS ENUM
    ( [ label [, ... ] ] )

CREATE TYPE name AS RANGE (
    SUBTYPE = subtype
    [ , SUBTYPE_OPCLASS = subtype_operator_class ]
    [ , COLLATION = collation ]
    [ , CANONICAL = canonical_function ]
    [ , SUBTYPE_DIFF = subtype_diff_function ]
    [ , MULTIRANGE_TYPE_NAME = multirange_type_name ]
)

CREATE TYPE name (
    INPUT = input_function,
    OUTPUT = output_function
    [ , RECEIVE = receive_function ]
    [ , SEND = send_function ]
    [ , TYPMOD_IN = type_modifier_input_function ]
    [ , TYPMOD_OUT = type_modifier_output_function ]
    [ , ANALYZE = analyze_function ]
    [ , SUBSCRIPT = subscript_function ]
    [ , INTERNALLENGTH = { internallength | VARIABLE } ]
    [ , PASSEDBYVALUE ]
    [ , ALIGNMENT = alignment ]
    [ , STORAGE = storage ]
    [ , LIKE = like_type ]
    [ , CATEGORY = category ]
    [ , PREFERRED = preferred ]
    [ , DEFAULT = default ]
    [ , ELEMENT = element ]
    [ , DELIMITER = delimiter ]
    [ , COLLATABLE = collatable ]
)

CREATE TYPE name

DESCRIPTION

CREATE TYPE registers a new data type for use in the current database. The user who defines a type becomes its owner.

If a schema name is given then the type is created in the specified schema. Otherwise it is created in the current schema. The type name must be distinct from the name of any existing type or domain in the same schema. (Because tables have associated data types, the type name must also be distinct from the name of any existing table in the same schema.)

There are five forms of CREATE TYPE, as shown in the syntax synopsis above. They respectively create a composite type, an enum type, a range type, a base type, or a shell type. The first four of these are discussed in turn below. A shell type is simply a placeholder for a type to be defined later; it is created by issuing CREATE TYPE with no parameters except for the type name. Shell types are needed as forward references when creating range types and base types, as discussed in those sections.

Composite Types

The first form of CREATE TYPE creates a composite type. The composite type is specified by a list of attribute names and data types. An attributes collation can be specified too, if its data type is collatable. A composite type is essentially the same as the row type of a table, but using CREATE TYPE avoids the need to create an actual table when all that is wanted is to define a type. A stand-alone composite type is useful, for example, as the argument or return type of a function.

To be able to create a composite type, you must have USAGE privilege on all attribute types.

Enumerated Types

The second form of CREATE TYPE creates an enumerated (enum) type, as described in Section 8.7. Enum types take a list of quoted labels, each of which must be less than NAMEDATALEN bytes long (64 bytes in a standard PostgreSQL build). (It is possible to create an enumerated type with zero labels, but such a type cannot be used to hold values before at least one label is added using ALTER TYPE.)

Range Types

The third form of CREATE TYPE creates a new range type, as described in Section 8.17.

The range types subtype can be any type with an associated b-tree operator class (to determine the ordering of values for the range type). Normally the subtypes default b-tree operator class is used to determine ordering; to use a non-default operator class, specify its name with subtype_opclass. If the subtype is collatable, and you want to use a non-default collation in the ranges ordering, specify the desired collation with the collation option.

The optional canonical function must take one argument of the range type being defined, and return a value of the same type. This is used to convert range values to a canonical form, when applicable. See Section 8.17.8 for more information. Creating a canonical function is a bit tricky, since it must be defined before the range type can be declared. To do this, you must first create a shell type, which is a placeholder type that has no properties except a name and an owner. This is done by issuing the command CREATE TYPE name, with no additional parameters. Then the function can be declared using the shell type as argument and result, and finally the range type can be declared using the same name. This automatically replaces the shell type entry with a valid range type.

The optional subtype_diff function must take two values of the subtype type as argument, and return a double precision value representing the difference between the two given values. While this is optional, providing it allows much greater efficiency of GiST indexes on columns of the range type. See Section 8.17.8 for more information.

The optional multirange_type_name parameter specifies the name of the corresponding multirange type. If not specified, this name is chosen automatically as follows. If the range type name contains the substring range, then the multirange type name is formed by replacement of the range substring with multirange in the range type name. Otherwise, the multirange type name is formed by appending a _multirange suffix to the range type name.

Base Types

The fourth form of CREATE TYPE creates a new base type (scalar type). To create a new base type, you must be a superuser. (This restriction is made because an erroneous type definition could confuse or even crash the server.)

The parameters can appear in any order, not only that illustrated above, and most are optional. You must register two or more functions (using CREATE FUNCTION) before defining the type. The support functions input_function and output_function are required, while the functions receive_function, send_function, type_modifier_input_function, type_modifier_output_function, analyze_function, and subscript_function are optional. Generally these functions have to be coded in C or another low-level language.

The input_function converts the types external textual representation to the internal representation used by the operators and functions defined for the type. output_function performs the reverse transformation. The input function can be declared as taking one argument of type cstring, or as taking three arguments of types cstring, oid, integer. The first argument is the input text as a C string, the second argument is the types own OID (except for array types, which instead receive their element types OID), and the third is the typmod of the destination column, if known (-1 will be passed if not). The input function must return a value of the data type itself. Usually, an input function should be declared STRICT; if it is not, it will be called with a NULL first parameter when reading a NULL input value. The function must still return NULL in this case, unless it raises an error. (This case is mainly meant to support domain input functions, which might need to reject NULL inputs.) The output function must be declared as taking one argument of the new data type. The output function must return type cstring. Output functions are not invoked for NULL values.

The optional receive_function converts the types external binary representation to the internal representation. If this function is not supplied, the type cannot participate in binary input. The binary representation should be chosen to be cheap to convert to internal form, while being reasonably portable. (For example, the standard integer data types use network byte order as the external binary representation, while the internal representation is in the machines native byte order.) The receive function should perform adequate checking to ensure that the value is valid. The receive function can be declared as taking one argument of type internal, or as taking three arguments of types internal, oid, integer. The first argument is a pointer to a StringInfo buffer holding the received byte string; the optional arguments are the same as for the text input function. The receive function must return a value of the data type itself. Usually, a receive function should be declared STRICT; if it is not, it will be called with a NULL first parameter when reading a NULL input value. The function must still return NULL in this case, unless it raises an error. (This case is mainly meant to support domain receive functions, which might need to reject NULL inputs.) Similarly, the optional send_function converts from the internal representation to the external binary representation. If this function is not supplied, the type cannot participate in binary output. The send function must be declared as taking one argument of the new data type. The send function must return type bytea. Send functions are not invoked for NULL values.

You should at this point be wondering how the input and output functions can be declared to have results or arguments of the new type, when they have to be created before the new type can be created. The answer is that the type should first be defined as a shell type, which is a placeholder type that has no properties except a name and an owner. This is done by issuing the command CREATE TYPE name, with no additional parameters. Then the C I/O functions can be defined referencing the shell type. Finally, CREATE TYPE with a full definition replaces the shell entry with a complete, valid type definition, after which the new type can be used normally.

The optional type_modifier_input_function and type_modifier_output_function are needed if the type supports modifiers, that is optional constraints attached to a type declaration, such as char(5) or numeric(30,2). PostgreSQL allows user-defined types to take one or more simple constants or identifiers as modifiers. However, this information must be capable of being packed into a single non-negative integer value for storage in the system catalogs. The type_modifier_input_function is passed the declared modifier(s) in the form of a cstring array. It must check the values for validity (throwing an error if they are wrong), and if they are correct, return a single non-negative integer value that will be stored as the column “typmod”. Type modifiers will be rejected if the type does not have a type_modifier_input_function. The type_modifier_output_function converts the internal integer typmod value back to the correct form for user display. It must return a cstring value that is the exact string to append to the type name; for example numerics function might return (30,2). It is allowed to omit the type_modifier_output_function, in which case the default display format is just the stored typmod integer value enclosed in parentheses.

The optional analyze_function performs type-specific statistics collection for columns of the data type. By default, ANALYZE will attempt to gather statistics using the types “equals” and “less-than” operators, if there is a default b-tree operator class for the type. For non-scalar types this behavior is likely to be unsuitable, so it can be overridden by specifying a custom analysis function. The analysis function must be declared to take a single argument of type internal, and return a boolean result. The detailed API for analysis functions appears in src/include/commands/vacuum.h.

The optional subscript_function allows the data type to be subscripted in SQL commands. Specifying this function does not cause the type to be considered a “true” array type; for example, it will not be a candidate for the result type of ARRAY[] constructs. But if subscripting a value of the type is a natural notation for extracting data from it, then a subscript_function can be written to define what that means. The subscript function must be declared to take a single argument of type internal, and return an internal result, which is a pointer to a struct of methods (functions) that implement subscripting. The detailed API for subscript functions appears in src/include/nodes/subscripting.h. It may also be useful to read the array implementation in src/backend/utils/adt/arraysubs.c, or the simpler code in contrib/hstore/hstore_subs.c. Additional information appears in Array Types below.

While the details of the new types internal representation are only known to the I/O functions and other functions you create to work with the type, there are several properties of the internal representation that must be declared to PostgreSQL. Foremost of these is internallength. Base data types can be fixed-length, in which case internallength is a positive integer, or variable-length, indicated by setting internallength to VARIABLE. (Internally, this is represented by setting typlen to -1.) The internal representation of all variable-length types must start with a 4-byte integer giving the total length of this value of the type. (Note that the length field is often encoded, as described in Section 73.2; its unwise to access it directly.)

The optional flag PASSEDBYVALUE indicates that values of this data type are passed by value, rather than by reference. Types passed by value must be fixed-length, and their internal representation cannot be larger than the size of the Datum type (4 bytes on some machines, 8 bytes on others).

The alignment parameter specifies the storage alignment required for the data type. The allowed values equate to alignment on 1, 2, 4, or 8 byte boundaries. Note that variable-length types must have an alignment of at least 4, since they necessarily contain an int4 as their first component.

The storage parameter allows selection of storage strategies for variable-length data types. (Only plain is allowed for fixed-length types.) plain specifies that data of the type will always be stored in-line and not compressed. extended specifies that the system will first try to compress a long data value, and will move the value out of the main table row if its still too long. external allows the value to be moved out of the main table, but the system will not try to compress it. main allows compression, but discourages moving the value out of the main table. (Data items with this storage strategy might still be moved out of the main table if there is no other way to make a row fit, but they will be kept in the main table preferentially over extended and external items.)

All storage values other than plain imply that the functions of the data type can handle values that have been toasted, as described in Section 73.2 and Section 38.13.1. The specific other value given merely determines the default TOAST storage strategy for columns of a toastable data type; users can pick other strategies for individual columns using ALTER TABLE SET STORAGE.

The like_type parameter provides an alternative method for specifying the basic representation properties of a data type: copy them from some existing type. The values of internallength, passedbyvalue, alignment, and storage are copied from the named type. (It is possible, though usually undesirable, to override some of these values by specifying them along with the LIKE clause.) Specifying representation this way is especially useful when the low-level implementation of the new type “piggybacks” on an existing type in some fashion.

The category and preferred parameters can be used to help control which implicit cast will be applied in ambiguous situations. Each data type belongs to a category named by a single ASCII character, and each type is either “preferred” or not within its category. The parser will prefer casting to preferred types (but only from other types within the same category) when this rule is helpful in resolving overloaded functions or operators. For more details see Chapter 10. For types that have no implicit casts to or from any other types, it is sufficient to leave these settings at the defaults. However, for a group of related types that have implicit casts, it is often helpful to mark them all as belonging to a category and select one or two of the “most general” types as being preferred within the category. The category parameter is especially useful when adding a user-defined type to an existing built-in category, such as the numeric or string types. However, it is also possible to create new entirely-user-defined type categories. Select any ASCII character other than an upper-case letter to name such a category.

A default value can be specified, in case a user wants columns of the data type to default to something other than the null value. Specify the default with the DEFAULT key word. (Such a default can be overridden by an explicit DEFAULT clause attached to a particular column.)

To indicate that a type is a fixed-length array type, specify the type of the array elements using the ELEMENT key word. For example, to define an array of 4-byte integers (int4), specify ELEMENT = int4. For more details, see Array Types below.

To indicate the delimiter to be used between values in the external representation of arrays of this type, delimiter can be set to a specific character. The default delimiter is the comma (,). Note that the delimiter is associated with the array element type, not the array type itself.

If the optional Boolean parameter collatable is true, column definitions and expressions of the type may carry collation information through use of the COLLATE clause. It is up to the implementations of the functions operating on the type to actually make use of the collation information; this does not happen automatically merely by marking the type collatable.

Array Types

Whenever a user-defined type is created, PostgreSQL automatically creates an associated array type, whose name consists of the element types name prepended with an underscore, and truncated if necessary to keep it less than NAMEDATALEN bytes long. (If the name so generated collides with an existing type name, the process is repeated until a non-colliding name is found.) This implicitly-created array type is variable length and uses the built-in input and output functions array_in and array_out. Furthermore, this type is what the system uses for constructs such as ARRAY[] over the user-defined type. The array type tracks any changes in its element types owner or schema, and is dropped if the element type is.

You might reasonably ask why there is an ELEMENT option, if the system makes the correct array type automatically. The main case where its useful to use ELEMENT is when you are making a fixed-length type that happens to be internally an array of a number of identical things, and you want to allow these things to be accessed directly by subscripting, in addition to whatever operations you plan to provide for the type as a whole. For example, type point is represented as just two floating-point numbers, which can be accessed using point[0] and point[1]. Note that this facility only works for fixed-length types whose internal form is exactly a sequence of identical fixed-length fields. For historical reasons (i.e., this is clearly wrong but its far too late to change it), subscripting of fixed-length array types starts from zero, rather than from one as for variable-length arrays.

Specifying the SUBSCRIPT option allows a data type to be subscripted, even though the system does not otherwise regard it as an array type. The behavior just described for fixed-length arrays is actually implemented by the SUBSCRIPT handler function raw_array_subscript_handler, which is used automatically if you specify ELEMENT for a fixed-length type without also writing SUBSCRIPT.

When specifying a custom SUBSCRIPT function, it is not necessary to specify ELEMENT unless the SUBSCRIPT handler function needs to consult typelem to find out what to return. Be aware that specifying ELEMENT causes the system to assume that the new type contains, or is somehow physically dependent on, the element type; thus for example changing properties of the element type wont be allowed if there are any columns of the dependent type.

PARAMETERS

name

The name (optionally schema-qualified) of a type to be created.

attribute_name

The name of an attribute (column) for the composite type.

data_type

The name of an existing data type to become a column of the composite type.

collation

The name of an existing collation to be associated with a column of a composite type, or with a range type.

label

A string literal representing the textual label associated with one value of an enum type.

subtype

The name of the element type that the range type will represent ranges of.

subtype_operator_class

The name of a b-tree operator class for the subtype.

canonical_function

The name of the canonicalization function for the range type.

subtype_diff_function

The name of a difference function for the subtype.

multirange_type_name

The name of the corresponding multirange type.

input_function

The name of a function that converts data from the types external textual form to its internal form.

output_function

The name of a function that converts data from the types internal form to its external textual form.

receive_function

The name of a function that converts data from the types external binary form to its internal form.

send_function

The name of a function that converts data from the types internal form to its external binary form.

type_modifier_input_function

The name of a function that converts an array of modifier(s) for the type into internal form.

type_modifier_output_function

The name of a function that converts the internal form of the types modifier(s) to external textual form.

analyze_function

The name of a function that performs statistical analysis for the data type.

subscript_function

The name of a function that defines what subscripting a value of the data type does.

internallength

A numeric constant that specifies the length in bytes of the new types internal representation. The default assumption is that it is variable-length.

alignment

The storage alignment requirement of the data type. If specified, it must be char, int2, int4, or double; the default is int4.

storage

The storage strategy for the data type. If specified, must be plain, external, extended, or main; the default is plain.

like_type

The name of an existing data type that the new type will have the same representation as. The values of internallength, passedbyvalue, alignment, and storage are copied from that type, unless overridden by explicit specification elsewhere in this CREATE TYPE command.

category

The category code (a single ASCII character) for this type. The default is U for “user-defined type”. Other standard category codes can be found in Table 53.65. You may also choose other ASCII characters in order to create custom categories.

preferred

True if this type is a preferred type within its type category, else false. The default is false. Be very careful about creating a new preferred type within an existing type category, as this could cause surprising changes in behavior.

default

The default value for the data type. If this is omitted, the default is null.

element

The type being created is an array; this specifies the type of the array elements.

delimiter

The delimiter character to be used between values in arrays made of this type.

collatable

True if this types operations can use collation information. The default is false.

NOTES

Because there are no restrictions on use of a data type once its been created, creating a base type or range type is tantamount to granting public execute permission on the functions mentioned in the type definition. This is usually not an issue for the sorts of functions that are useful in a type definition. But you might want to think twice before designing a type in a way that would require “secret” information to be used while converting it to or from external form.

Before PostgreSQL version 8.3, the name of a generated array type was always exactly the element types name with one underscore character (_) prepended. (Type names were therefore restricted in length to one fewer character than other names.) While this is still usually the case, the array type name may vary from this in case of maximum-length names or collisions with user type names that begin with underscore. Writing code that depends on this convention is therefore deprecated. Instead, use pg_type.typarray to locate the array type associated with a given type.

It may be advisable to avoid using type and table names that begin with underscore. While the server will change generated array type names to avoid collisions with user-given names, there is still risk of confusion, particularly with old client software that may assume that type names beginning with underscores always represent arrays.

Before PostgreSQL version 8.2, the shell-type creation syntax CREATE TYPE name did not exist. The way to create a new base type was to create its input function first. In this approach, PostgreSQL will first see the name of the new data type as the return type of the input function. The shell type is implicitly created in this situation, and then it can be referenced in the definitions of the remaining I/O functions. This approach still works, but is deprecated and might be disallowed in some future release. Also, to avoid accidentally cluttering the catalogs with shell types as a result of simple typos in function definitions, a shell type will only be made this way when the input function is written in C.

In PostgreSQL version 16 and later, it is desirable for base types input functions to return “soft” errors using the new errsave()/ereturn() mechanism, rather than throwing ereport() exceptions as in previous versions. See src/backend/utils/fmgr/README for more information.

EXAMPLES

This example creates a composite type and uses it in a function definition:

CREATE TYPE compfoo AS (f1 int, f2 text);

CREATE FUNCTION getfoo() RETURNS SETOF compfoo AS $$
    SELECT fooid, fooname FROM foo
$$ LANGUAGE SQL;

This example creates an enumerated type and uses it in a table definition:

CREATE TYPE bug_status AS ENUM (new, open, closed);

CREATE TABLE bug (
    id serial,
    description text,
    status bug_status
);

This example creates a range type:

CREATE TYPE float8_range AS RANGE (subtype = float8, subtype_diff = float8mi);

This example creates the base data type box and then uses the type in a table definition:

CREATE TYPE box;

CREATE FUNCTION my_box_in_function(cstring) RETURNS box AS ... ;
CREATE FUNCTION my_box_out_function(box) RETURNS cstring AS ... ;

CREATE TYPE box (
    INTERNALLENGTH = 16,
    INPUT = my_box_in_function,
    OUTPUT = my_box_out_function
);

CREATE TABLE myboxes (
    id integer,
    description box
);

If the internal structure of box were an array of four float4 elements, we might instead use:

CREATE TYPE box ( INTERNALLENGTH = 16, INPUT = my_box_in_function, OUTPUT = my_box_out_function, ELEMENT = float4 );

which would allow a box values component numbers to be accessed by subscripting. Otherwise the type behaves the same as before.

This example creates a large object type and uses it in a table definition:

CREATE TYPE bigobj ( INPUT = lo_filein, OUTPUT = lo_fileout, INTERNALLENGTH = VARIABLE ); CREATE TABLE big_objs ( id integer, obj bigobj );

More examples, including suitable input and output functions, are in Section 38.13.

COMPATIBILITY

The first form of the CREATE TYPE command, which creates a composite type, conforms to the SQL standard. The other forms are PostgreSQL extensions. The CREATE TYPE statement in the SQL standard also defines other forms that are not implemented in PostgreSQL.

The ability to create a composite type with zero attributes is a PostgreSQL-specific deviation from the standard (analogous to the same case in CREATE TABLE).

SEE ALSO

ALTER TYPE (ALTER_TYPE(7)), CREATE DOMAIN (CREATE_DOMAIN(7)), CREATE FUNCTION (CREATE_FUNCTION(7)), DROP TYPE (DROP_TYPE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

448 - Linux cli command mailaddr

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command mailaddr and provides detailed information about the command mailaddr, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the mailaddr.

NAME 🖥️ mailaddr 🖥️

mail addressing description

DESCRIPTION

This manual page gives a brief introduction to SMTP mail addresses, as used on the Internet. These addresses are in the general format

user@domain

where a domain is a hierarchical dot-separated list of subdomains. These examples are valid forms of the same address:

[email protected]
John Doe <[email protected]>
[email protected] (John Doe)

The domain part (“monet.example.com”) is a mail-accepting domain. It can be a host and in the past it usually was, but it doesn’t have to be. The domain part is not case sensitive.

The local part (“john.doe”) is often a username, but its meaning is defined by the local software. Sometimes it is case sensitive, although that is unusual. If you see a local-part that looks like garbage, it is usually because of a gateway between an internal e-mail system and the net, here are some examples:

"surname/admd=telemail/c=us/o=hp/prmd=hp"@some.where
USER%[email protected]
[email protected]
[email protected]

(These are, respectively, an X.400 gateway, a gateway to an arbitrary internal mail system that lacks proper internet support, an UUCP gateway, and the last one is just boring username policy.)

The real-name part (“John Doe”) can either be placed before <>, or in () at the end. (Strictly speaking the two aren’t the same, but the difference is beyond the scope of this page.) The name may have to be quoted using “”, for example, if it contains “.”:

"John Q. Doe" <[email protected]>

Abbreviation

Some mail systems let users abbreviate the domain name. For instance, users at example.com may get away with “john.doe@monet” to send mail to John Doe. This behavior is deprecated. Sometimes it works, but you should not depend on it.

Route-addrs

In the past, sometimes one had to route a message through several hosts to get it to its final destination. Addresses which show these relays are termed “route-addrs”. These use the syntax:

<@hosta,@hostb:user@hostc>

This specifies that the message should be sent to hosta, from there to hostb, and finally to hostc. Many hosts disregard route-addrs and send directly to hostc.

Route-addrs are very unusual now. They occur sometimes in old mail archives. It is generally possible to ignore all but the “user@hostc” part of the address to determine the actual address.

Postmaster

Every site is required to have a user or user alias designated “postmaster” to which problems with the mail system may be addressed. The “postmaster” address is not case sensitive.

FILES

/etc/aliases
~/.forward

SEE ALSO

mail(1), aliases(5), forward(5), sendmail(8)

IETF RFC 5322

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

449 - Linux cli command builtins

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command builtins and provides detailed information about the command builtins, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the builtins.

NAME 🖥️ builtins 🖥️

builtins - bash built-in commands, see bash(1)

SYNOPSIS

bash defines the following built-in commands: :, ., [, alias, bg, bind, break, builtin, case, cd, command, compgen, complete, continue, declare, dirs, disown, echo, enable, eval, exec, exit, export, fc, fg, getopts, hash, help, history, if, jobs, kill, let, local, logout, popd, printf, pushd, pwd, read, readonly, return, set, shift, shopt, source, suspend, test, times, trap, type, typeset, ulimit, umask, unalias, unset, until, wait, while.

BASH BUILTIN COMMANDS

SEE ALSO

bash(1), sh(1)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

450 - Linux cli command END

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command END and provides detailed information about the command END, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the END.

NAME 🖥️ END 🖥️

commit the current transaction

SYNOPSIS

END [ WORK | TRANSACTION ] [ AND [ NO ] CHAIN ]

DESCRIPTION

END commits the current transaction. All changes made by the transaction become visible to others and are guaranteed to be durable if a crash occurs. This command is a PostgreSQL extension that is equivalent to COMMIT.

PARAMETERS

WORK
TRANSACTION

Optional key words. They have no effect.

AND CHAIN

If AND CHAIN is specified, a new transaction is immediately started with the same transaction characteristics (see SET TRANSACTION (SET_TRANSACTION(7))) as the just finished one. Otherwise, no new transaction is started.

NOTES

Use ROLLBACK to abort a transaction.

Issuing END when not inside a transaction does no harm, but it will provoke a warning message.

EXAMPLES

To commit the current transaction and make all changes permanent:

END;

COMPATIBILITY

END is a PostgreSQL extension that provides functionality equivalent to COMMIT, which is specified in the SQL standard.

SEE ALSO

BEGIN(7), COMMIT(7), ROLLBACK(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

451 - Linux cli command CREATE_INDEX

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_INDEX and provides detailed information about the command CREATE_INDEX, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_INDEX.

NAME 🖥️ CREATE_INDEX 🖥️

define a new index

SYNOPSIS

CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ [ IF NOT EXISTS ] name ] ON [ ONLY ] table_name [ USING method ]
    ( { column_name | ( expression ) } [ COLLATE collation ] [ opclass [ ( opclass_parameter = value [, ... ] ) ] ] [ ASC | DESC ] [ NULLS { FIRST | LAST } ] [, ...] )
    [ INCLUDE ( column_name [, ...] ) ]
    [ NULLS [ NOT ] DISTINCT ]
    [ WITH ( storage_parameter [= value] [, ... ] ) ]
    [ TABLESPACE tablespace_name ]
    [ WHERE predicate ]

DESCRIPTION

CREATE INDEX constructs an index on the specified column(s) of the specified relation, which can be a table or a materialized view. Indexes are primarily used to enhance database performance (though inappropriate use can result in slower performance).

The key field(s) for the index are specified as column names, or alternatively as expressions written in parentheses. Multiple fields can be specified if the index method supports multicolumn indexes.

An index field can be an expression computed from the values of one or more columns of the table row. This feature can be used to obtain fast access to data based on some transformation of the basic data. For example, an index computed on upper(col) would allow the clause WHERE upper(col) = JIM to use an index.

PostgreSQL provides the index methods B-tree, hash, GiST, SP-GiST, GIN, and BRIN. Users can also define their own index methods, but that is fairly complicated.

When the WHERE clause is present, a partial index is created. A partial index is an index that contains entries for only a portion of a table, usually a portion that is more useful for indexing than the rest of the table. For example, if you have a table that contains both billed and unbilled orders where the unbilled orders take up a small fraction of the total table and yet that is an often used section, you can improve performance by creating an index on just that portion. Another possible application is to use WHERE with UNIQUE to enforce uniqueness over a subset of a table. See Section 11.8 for more discussion.

The expression used in the WHERE clause can refer only to columns of the underlying table, but it can use all columns, not just the ones being indexed. Presently, subqueries and aggregate expressions are also forbidden in WHERE. The same restrictions apply to index fields that are expressions.

All functions and operators used in an index definition must be “immutable”, that is, their results must depend only on their arguments and never on any outside influence (such as the contents of another table or the current time). This restriction ensures that the behavior of the index is well-defined. To use a user-defined function in an index expression or WHERE clause, remember to mark the function immutable when you create it.

PARAMETERS

UNIQUE

Causes the system to check for duplicate values in the table when the index is created (if data already exist) and each time data is added. Attempts to insert or update data which would result in duplicate entries will generate an error.

Additional restrictions apply when unique indexes are applied to partitioned tables; see CREATE TABLE (CREATE_TABLE(7)).

CONCURRENTLY

When this option is used, PostgreSQL will build the index without taking any locks that prevent concurrent inserts, updates, or deletes on the table; whereas a standard index build locks out writes (but not reads) on the table until its done. There are several caveats to be aware of when using this option — see Building Indexes Concurrently below.

For temporary tables, CREATE INDEX is always non-concurrent, as no other session can access them, and non-concurrent index creation is cheaper.

IF NOT EXISTS

Do not throw an error if a relation with the same name already exists. A notice is issued in this case. Note that there is no guarantee that the existing index is anything like the one that would have been created. Index name is required when IF NOT EXISTS is specified.

INCLUDE

The optional INCLUDE clause specifies a list of columns which will be included in the index as non-key columns. A non-key column cannot be used in an index scan search qualification, and it is disregarded for purposes of any uniqueness or exclusion constraint enforced by the index. However, an index-only scan can return the contents of non-key columns without having to visit the indexs table, since they are available directly from the index entry. Thus, addition of non-key columns allows index-only scans to be used for queries that otherwise could not use them.

Its wise to be conservative about adding non-key columns to an index, especially wide columns. If an index tuple exceeds the maximum size allowed for the index type, data insertion will fail. In any case, non-key columns duplicate data from the indexs table and bloat the size of the index, thus potentially slowing searches. Furthermore, B-tree deduplication is never used with indexes that have a non-key column.

Columns listed in the INCLUDE clause dont need appropriate operator classes; the clause can include columns whose data types dont have operator classes defined for a given access method.

Expressions are not supported as included columns since they cannot be used in index-only scans.

Currently, the B-tree, GiST and SP-GiST index access methods support this feature. In these indexes, the values of columns listed in the INCLUDE clause are included in leaf tuples which correspond to heap tuples, but are not included in upper-level index entries used for tree navigation.

name

The name of the index to be created. No schema name can be included here; the index is always created in the same schema as its parent table. The name of the index must be distinct from the name of any other relation (table, sequence, index, view, materialized view, or foreign table) in that schema. If the name is omitted, PostgreSQL chooses a suitable name based on the parent tables name and the indexed column name(s).

ONLY

Indicates not to recurse creating indexes on partitions, if the table is partitioned. The default is to recurse.

table_name

The name (possibly schema-qualified) of the table to be indexed.

method

The name of the index method to be used. Choices are btree, hash, gist, spgist, gin, brin, or user-installed access methods like bloom. The default method is btree.

column_name

The name of a column of the table.

expression

An expression based on one or more columns of the table. The expression usually must be written with surrounding parentheses, as shown in the syntax. However, the parentheses can be omitted if the expression has the form of a function call.

collation

The name of the collation to use for the index. By default, the index uses the collation declared for the column to be indexed or the result collation of the expression to be indexed. Indexes with non-default collations can be useful for queries that involve expressions using non-default collations.

opclass

The name of an operator class. See below for details.

opclass_parameter

The name of an operator class parameter. See below for details.

ASC

Specifies ascending sort order (which is the default).

DESC

Specifies descending sort order.

NULLS FIRST

Specifies that nulls sort before non-nulls. This is the default when DESC is specified.

NULLS LAST

Specifies that nulls sort after non-nulls. This is the default when DESC is not specified.

NULLS DISTINCT
NULLS NOT DISTINCT

Specifies whether for a unique index, null values should be considered distinct (not equal). The default is that they are distinct, so that a unique index could contain multiple null values in a column.

storage_parameter

The name of an index-method-specific storage parameter. See Index Storage Parameters below for details.

tablespace_name

The tablespace in which to create the index. If not specified, default_tablespace is consulted, or temp_tablespaces for indexes on temporary tables.

predicate

The constraint expression for a partial index.

Index Storage Parameters

The optional WITH clause specifies storage parameters for the index. Each index method has its own set of allowed storage parameters. The B-tree, hash, GiST and SP-GiST index methods all accept this parameter:

fillfactor (integer)

The fillfactor for an index is a percentage that determines how full the index method will try to pack index pages. For B-trees, leaf pages are filled to this percentage during initial index builds, and also when extending the index at the right (adding new largest key values). If pages subsequently become completely full, they will be split, leading to fragmentation of the on-disk index structure. B-trees use a default fillfactor of 90, but any integer value from 10 to 100 can be selected.

B-tree indexes on tables where many inserts and/or updates are anticipated can benefit from lower fillfactor settings at CREATE INDEX time (following bulk loading into the table). Values in the range of 50 - 90 can usefully “smooth out” the rate of page splits during the early life of the B-tree index (lowering fillfactor like this may even lower the absolute number of page splits, though this effect is highly workload dependent). The B-tree bottom-up index deletion technique described in Section 67.4.2 is dependent on having some “extra” space on pages to store “extra” tuple versions, and so can be affected by fillfactor (though the effect is usually not significant).

In other specific cases it might be useful to increase fillfactor to 100 at CREATE INDEX time as a way of maximizing space utilization. You should only consider this when you are completely sure that the table is static (i.e. that it will never be affected by either inserts or updates). A fillfactor setting of 100 otherwise risks harming performance: even a few updates or inserts will cause a sudden flood of page splits.

The other index methods use fillfactor in different but roughly analogous ways; the default fillfactor varies between methods.

B-tree indexes additionally accept this parameter:

deduplicate_items (boolean)

Controls usage of the B-tree deduplication technique described in Section 67.4.3. Set to ON or OFF to enable or disable the optimization. (Alternative spellings of ON and OFF are allowed as described in Section 20.1.) The default is ON.

Note

Turning deduplicate_items off via ALTER INDEX prevents future insertions from triggering deduplication, but does not in itself make existing posting list tuples use the standard tuple representation.

GiST indexes additionally accept this parameter:

buffering (enum)

Determines whether the buffered build technique described in Section 68.4.1 is used to build the index. With OFF buffering is disabled, with ON it is enabled, and with AUTO it is initially disabled, but is turned on on-the-fly once the index size reaches effective_cache_size. The default is AUTO. Note that if sorted build is possible, it will be used instead of buffered build unless buffering=ON is specified.

GIN indexes accept different parameters:

fastupdate (boolean)

This setting controls usage of the fast update technique described in Section 70.4.1. It is a Boolean parameter: ON enables fast update, OFF disables it. The default is ON.

Note

Turning fastupdate off via ALTER INDEX prevents future insertions from going into the list of pending index entries, but does not in itself flush previous entries. You might want to VACUUM the table or call gin_clean_pending_list function afterward to ensure the pending list is emptied.

gin_pending_list_limit (integer)

Custom gin_pending_list_limit parameter. This value is specified in kilobytes.

BRIN indexes accept different parameters:

pages_per_range (integer)

Defines the number of table blocks that make up one block range for each entry of a BRIN index (see Section 71.1 for more details). The default is 128.

autosummarize (boolean)

Defines whether a summarization run is queued for the previous page range whenever an insertion is detected on the next one. See Section 71.1.1 for more details. The default is off.

Building Indexes Concurrently

Creating an index can interfere with regular operation of a database. Normally PostgreSQL locks the table to be indexed against writes and performs the entire index build with a single scan of the table. Other transactions can still read the table, but if they try to insert, update, or delete rows in the table they will block until the index build is finished. This could have a severe effect if the system is a live production database. Very large tables can take many hours to be indexed, and even for smaller tables, an index build can lock out writers for periods that are unacceptably long for a production system.

PostgreSQL supports building indexes without locking out writes. This method is invoked by specifying the CONCURRENTLY option of CREATE INDEX. When this option is used, PostgreSQL must perform two scans of the table, and in addition it must wait for all existing transactions that could potentially modify or use the index to terminate. Thus this method requires more total work than a standard index build and takes significantly longer to complete. However, since it allows normal operations to continue while the index is built, this method is useful for adding new indexes in a production environment. Of course, the extra CPU and I/O load imposed by the index creation might slow other operations.

In a concurrent index build, the index is actually entered as an “invalid” index into the system catalogs in one transaction, then two table scans occur in two more transactions. Before each table scan, the index build must wait for existing transactions that have modified the table to terminate. After the second scan, the index build must wait for any transactions that have a snapshot (see Chapter 13) predating the second scan to terminate, including transactions used by any phase of concurrent index builds on other tables, if the indexes involved are partial or have columns that are not simple column references. Then finally the index can be marked “valid” and ready for use, and the CREATE INDEX command terminates. Even then, however, the index may not be immediately usable for queries: in the worst case, it cannot be used as long as transactions exist that predate the start of the index build.

If a problem arises while scanning the table, such as a deadlock or a uniqueness violation in a unique index, the CREATE INDEX command will fail but leave behind an “invalid” index. This index will be ignored for querying purposes because it might be incomplete; however it will still consume update overhead. The psql \d command will report such an index as INVALID:

postgres=# \d tab Table “public.tab” Column | Type | Collation | Nullable | Default ——–+———+———–+———-+——— col | integer | | | Indexes: “idx” btree (col) INVALID

The recommended recovery method in such cases is to drop the index and try again to perform CREATE INDEX CONCURRENTLY. (Another possibility is to rebuild the index with REINDEX INDEX CONCURRENTLY).

Another caveat when building a unique index concurrently is that the uniqueness constraint is already being enforced against other transactions when the second table scan begins. This means that constraint violations could be reported in other queries prior to the index becoming available for use, or even in cases where the index build eventually fails. Also, if a failure does occur in the second scan, the “invalid” index continues to enforce its uniqueness constraint afterwards.

Concurrent builds of expression indexes and partial indexes are supported. Errors occurring in the evaluation of these expressions could cause behavior similar to that described above for unique constraint violations.

Regular index builds permit other regular index builds on the same table to occur simultaneously, but only one concurrent index build can occur on a table at a time. In either case, schema modification of the table is not allowed while the index is being built. Another difference is that a regular CREATE INDEX command can be performed within a transaction block, but CREATE INDEX CONCURRENTLY cannot.

Concurrent builds for indexes on partitioned tables are currently not supported. However, you may concurrently build the index on each partition individually and then finally create the partitioned index non-concurrently in order to reduce the time where writes to the partitioned table will be locked out. In this case, building the partitioned index is a metadata only operation.

NOTES

See Chapter 11 for information about when indexes can be used, when they are not used, and in which particular situations they can be useful.

Currently, only the B-tree, GiST, GIN, and BRIN index methods support multiple-key-column indexes. Whether there can be multiple key columns is independent of whether INCLUDE columns can be added to the index. Indexes can have up to 32 columns, including INCLUDE columns. (This limit can be altered when building PostgreSQL.) Only B-tree currently supports unique indexes.

An operator class with optional parameters can be specified for each column of an index. The operator class identifies the operators to be used by the index for that column. For example, a B-tree index on four-byte integers would use the int4_ops class; this operator class includes comparison functions for four-byte integers. In practice the default operator class for the columns data type is usually sufficient. The main point of having operator classes is that for some data types, there could be more than one meaningful ordering. For example, we might want to sort a complex-number data type either by absolute value or by real part. We could do this by defining two operator classes for the data type and then selecting the proper class when creating an index. More information about operator classes is in Section 11.10 and in Section 38.16.

When CREATE INDEX is invoked on a partitioned table, the default behavior is to recurse to all partitions to ensure they all have matching indexes. Each partition is first checked to determine whether an equivalent index already exists, and if so, that index will become attached as a partition index to the index being created, which will become its parent index. If no matching index exists, a new index will be created and automatically attached; the name of the new index in each partition will be determined as if no index name had been specified in the command. If the ONLY option is specified, no recursion is done, and the index is marked invalid. (ALTER INDEX … ATTACH PARTITION marks the index valid, once all partitions acquire matching indexes.) Note, however, that any partition that is created in the future using CREATE TABLE … PARTITION OF will automatically have a matching index, regardless of whether ONLY is specified.

For index methods that support ordered scans (currently, only B-tree), the optional clauses ASC, DESC, NULLS FIRST, and/or NULLS LAST can be specified to modify the sort ordering of the index. Since an ordered index can be scanned either forward or backward, it is not normally useful to create a single-column DESC index — that sort ordering is already available with a regular index. The value of these options is that multicolumn indexes can be created that match the sort ordering requested by a mixed-ordering query, such as SELECT … ORDER BY x ASC, y DESC. The NULLS options are useful if you need to support “nulls sort low” behavior, rather than the default “nulls sort high”, in queries that depend on indexes to avoid sorting steps.

The system regularly collects statistics on all of a tables columns. Newly-created non-expression indexes can immediately use these statistics to determine an indexs usefulness. For new expression indexes, it is necessary to run ANALYZE or wait for the autovacuum daemon to analyze the table to generate statistics for these indexes.

For most index methods, the speed of creating an index is dependent on the setting of maintenance_work_mem. Larger values will reduce the time needed for index creation, so long as you dont make it larger than the amount of memory really available, which would drive the machine into swapping.

PostgreSQL can build indexes while leveraging multiple CPUs in order to process the table rows faster. This feature is known as parallel index build. For index methods that support building indexes in parallel (currently, only B-tree), maintenance_work_mem specifies the maximum amount of memory that can be used by each index build operation as a whole, regardless of how many worker processes were started. Generally, a cost model automatically determines how many worker processes should be requested, if any.

Parallel index builds may benefit from increasing maintenance_work_mem where an equivalent serial index build will see little or no benefit. Note that maintenance_work_mem may influence the number of worker processes requested, since parallel workers must have at least a 32MB share of the total maintenance_work_mem budget. There must also be a remaining 32MB share for the leader process. Increasing max_parallel_maintenance_workers may allow more workers to be used, which will reduce the time needed for index creation, so long as the index build is not already I/O bound. Of course, there should also be sufficient CPU capacity that would otherwise lie idle.

Setting a value for parallel_workers via ALTER TABLE directly controls how many parallel worker processes will be requested by a CREATE INDEX against the table. This bypasses the cost model completely, and prevents maintenance_work_mem from affecting how many parallel workers are requested. Setting parallel_workers to 0 via ALTER TABLE will disable parallel index builds on the table in all cases.

Tip

You might want to reset parallel_workers after setting it as part of tuning an index build. This avoids inadvertent changes to query plans, since parallel_workers affects all parallel table scans.

While CREATE INDEX with the CONCURRENTLY option supports parallel builds without special restrictions, only the first table scan is actually performed in parallel.

Use DROP INDEX to remove an index.

Like any long-running transaction, CREATE INDEX on a table can affect which tuples can be removed by concurrent VACUUM on any other table.

Prior releases of PostgreSQL also had an R-tree index method. This method has been removed because it had no significant advantages over the GiST method. If USING rtree is specified, CREATE INDEX will interpret it as USING gist, to simplify conversion of old databases to GiST.

Each backend running CREATE INDEX will report its progress in the pg_stat_progress_create_index view. See Section 28.4.4 for details.

EXAMPLES

To create a unique B-tree index on the column title in the table films:

CREATE UNIQUE INDEX title_idx ON films (title);

To create a unique B-tree index on the column title with included columns director and rating in the table films:

CREATE UNIQUE INDEX title_idx ON films (title) INCLUDE (director, rating);

To create a B-Tree index with deduplication disabled:

CREATE INDEX title_idx ON films (title) WITH (deduplicate_items = off);

To create an index on the expression lower(title), allowing efficient case-insensitive searches:

CREATE INDEX ON films ((lower(title)));

(In this example we have chosen to omit the index name, so the system will choose a name, typically films_lower_idx.)

To create an index with non-default collation:

CREATE INDEX title_idx_german ON films (title COLLATE “de_DE”);

To create an index with non-default sort ordering of nulls:

CREATE INDEX title_idx_nulls_low ON films (title NULLS FIRST);

To create an index with non-default fill factor:

CREATE UNIQUE INDEX title_idx ON films (title) WITH (fillfactor = 70);

To create a GIN index with fast updates disabled:

CREATE INDEX gin_idx ON documents_table USING GIN (locations) WITH (fastupdate = off);

To create an index on the column code in the table films and have the index reside in the tablespace indexspace:

CREATE INDEX code_idx ON films (code) TABLESPACE indexspace;

To create a GiST index on a point attribute so that we can efficiently use box operators on the result of the conversion function:

CREATE INDEX pointloc ON points USING gist (box(location,location)); SELECT * FROM points WHERE box(location,location) && (0,0),(1,1)::box;

To create an index without locking out writes to the table:

CREATE INDEX CONCURRENTLY sales_quantity_index ON sales_table (quantity);

COMPATIBILITY

CREATE INDEX is a PostgreSQL language extension. There are no provisions for indexes in the SQL standard.

SEE ALSO

ALTER INDEX (ALTER_INDEX(7)), DROP INDEX (DROP_INDEX(7)), REINDEX(7), Section 28.4.4

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

452 - Linux cli command EVP_SIGNATURE-ED448ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_SIGNATURE-ED448ssl and provides detailed information about the command EVP_SIGNATURE-ED448ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_SIGNATURE-ED448ssl.

NAME 🖥️ EVP_SIGNATURE-ED448ssl 🖥️

ED25519, EVP_SIGNATURE-ED448, Ed25519, Ed448 - EVP_PKEY Ed25519 and Ed448 support

DESCRIPTION

The Ed25519 and Ed448 EVP_PKEY implementation supports key generation, one-shot digest-sign and digest-verify using the EdDSA signature scheme described in RFC 8032. It has associated private and public key formats compatible with RFC 8410.

EdDSA Instances

RFC 8032 describes five EdDSA instances: Ed25519, Ed25519ctx, Ed25519ph, Ed448, Ed448ph.

The instances Ed25519, Ed25519ctx, Ed448 are referred to as PureEdDSA schemes. For these three instances, the sign and verify procedures require access to the complete message (not a digest of the message).

The instances Ed25519ph, Ed448ph are referred to as HashEdDSA schemes. For these two instances, the sign and verify procedures do not require access to the complete message; they operate on a hash of the message. For Ed25519ph, the hash function is SHA512. For Ed448ph, the hash function is SHAKE256 with an output length of 512 bits.

The instances Ed25519ctx, Ed25519ph, Ed448, Ed448ph accept an optional context-string as input to sign and verify operations (and for Ed25519ctx, the context-string must be nonempty). For the Ed25519 instance, a nonempty context-string is not permitted.

ED25519 and ED448 Signature Parameters

Two parameters can be set during signing or verification: the EdDSA instance name and the context-string value. They can be set by passing an OSSL_PARAM array to EVP_DigestSignInit_ex().

  • “instance” (OSSL_SIGNATURE_PARAM_INSTANCE) <utf8 string> One of the five strings “Ed25519”, “Ed25519ctx”, “Ed25519ph”, “Ed448”, “Ed448ph”. “Ed25519”, “Ed25519ctx”, “Ed25519ph” are valid only for an Ed25519 EVP_PKEY. “Ed448”, “Ed448ph” are valid only for an Ed448 EVP_PKEY.

  • “context-string” (OSSL_SIGNATURE_PARAM_CONTEXT_STRING) <octet string> A string of octets with length at most 255.

Both of these parameters are optional.

If the instance name is not specified, then the default “Ed25519” or “Ed448” is used.

If a context-string is not specified, then an empty context-string is used.

Note that a message digest name must NOT be specified when signing or verifying.

See EVP_PKEY-X25519 (7) for information related to X25519 and X448 keys.

The following signature parameters can be retrieved using EVP_PKEY_CTX_get_params().

  • “algorithm-id” (OSSL_SIGNATURE_PARAM_ALGORITHM_ID) <octet string>

  • “instance” (OSSL_SIGNATURE_PARAM_INSTANCE) <utf8 string>

  • “context-string” (OSSL_SIGNATURE_PARAM_CONTEXT_STRING) <octet string>

The parameters are described in provider-signature (7).

NOTES

The PureEdDSA instances do not support the streaming mechanism of other signature algorithms using, for example, EVP_DigestUpdate(). The message to sign or verify must be passed using the one-shot EVP_DigestSign() and EVP_DigestVerify() functions.

The HashEdDSA instances do not yet support the streaming mechanisms (so the one-shot functions must be used with HashEdDSA as well).

When calling EVP_DigestSignInit() or EVP_DigestVerifyInit(), the digest type parameter MUST be set to NULL.

Applications wishing to sign certificates (or other structures such as CRLs or certificate requests) using Ed25519 or Ed448 can either use X509_sign() or X509_sign_ctx() in the usual way.

Ed25519 or Ed448 private keys can be set directly using EVP_PKEY_new_raw_private_key (3) or loaded from a PKCS#8 private key file using PEM_read_bio_PrivateKey (3) (or similar function). Completely new keys can also be generated (see the example below). Setting a private key also sets the associated public key.

Ed25519 or Ed448 public keys can be set directly using EVP_PKEY_new_raw_public_key (3) or loaded from a SubjectPublicKeyInfo structure in a PEM file using PEM_read_bio_PUBKEY (3) (or similar function).

Ed25519 and Ed448 can be tested with the openssl-speed (1) application since version 1.1.1. Valid algorithm names are ed25519, ed448 and eddsa. If eddsa is specified, then both Ed25519 and Ed448 are benchmarked.

EXAMPLES

To sign a message using an ED25519 EVP_PKEY structure:

void do_sign(EVP_PKEY *ed_key, unsigned char *msg, size_t msg_len) { size_t sig_len; unsigned char *sig = NULL; EVP_MD_CTX *md_ctx = EVP_MD_CTX_new(); const OSSL_PARAM params[] = { OSSL_PARAM_utf8_string (“instance”, “Ed25519ctx”, 10), OSSL_PARAM_octet_string(“context-string”, (unsigned char *)“A protocol defined context string”, 33), OSSL_PARAM_END }; /* The input “params” is not needed if default options are acceptable. Use NULL in place of “params” in that case. */ EVP_DigestSignInit_ex(md_ctx, NULL, NULL, NULL, NULL, ed_key, params); /* Calculate the required size for the signature by passing a NULL buffer. */ EVP_DigestSign(md_ctx, NULL, &sig_len, msg, msg_len); sig = OPENSSL_zalloc(sig_len); EVP_DigestSign(md_ctx, sig, &sig_len, msg, msg_len); … OPENSSL_free(sig); EVP_MD_CTX_free(md_ctx); }

SEE ALSO

EVP_PKEY-X25519 (7) provider-signature (7), EVP_DigestSignInit (3), EVP_DigestVerifyInit (3),

COPYRIGHT

Copyright 2017-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

453 - Linux cli command EVP_CIPHER-AESssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_CIPHER-AESssl and provides detailed information about the command EVP_CIPHER-AESssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_CIPHER-AESssl.

NAME 🖥️ EVP_CIPHER-AESssl 🖥️

AES - The AES EVP_CIPHER implementations

DESCRIPTION

Support for AES symmetric encryption using the EVP_CIPHER API.

Algorithm Names

The following algorithms are available in the FIPS provider as well as the default provider:

“AES-128-CBC”, “AES-192-CBC” and “AES-256-CBC”

“AES-128-CBC-CTS”, “AES-192-CBC-CTS” and “AES-256-CBC-CTS”

“AES-128-CFB”, “AES-192-CFB”, “AES-256-CFB”, “AES-128-CFB1”, “AES-192-CFB1”, “AES-256-CFB1”, “AES-128-CFB8”, “AES-192-CFB8” and “AES-256-CFB8”

“AES-128-CTR”, “AES-192-CTR” and “AES-256-CTR”

“AES-128-ECB”, “AES-192-ECB” and “AES-256-ECB”

“AES-192-OFB”, “AES-128-OFB” and “AES-256-OFB”

“AES-128-XTS” and “AES-256-XTS”

“AES-128-CCM”, “AES-192-CCM” and “AES-256-CCM”

“AES-128-GCM”, “AES-192-GCM” and “AES-256-GCM”

“AES-128-WRAP”, “AES-192-WRAP”, “AES-256-WRAP”, “AES-128-WRAP-PAD”, “AES-192-WRAP-PAD”, “AES-256-WRAP-PAD”, “AES-128-WRAP-INV”, “AES-192-WRAP-INV”, “AES-256-WRAP-INV”, “AES-128-WRAP-PAD-INV”, “AES-192-WRAP-PAD-INV” and “AES-256-WRAP-PAD-INV”

“AES-128-CBC-HMAC-SHA1”, “AES-256-CBC-HMAC-SHA1”, “AES-128-CBC-HMAC-SHA256” and “AES-256-CBC-HMAC-SHA256”

The following algorithms are available in the default provider, but not the FIPS provider:

“AES-128-OCB”, “AES-192-OCB” and “AES-256-OCB”

“AES-128-SIV”, “AES-192-SIV” and “AES-256-SIV”

“AES-128-GCM-SIV”, “AES-192-GCM-SIV” and “AES-256-GCM-SIV”

Parameters

This implementation supports the parameters described in “PARAMETERS” in EVP_EncryptInit (3).

NOTES

The AES-SIV and AES-WRAP mode implementations do not support streaming. That means to obtain correct results there can be only one EVP_EncryptUpdate (3) or EVP_DecryptUpdate (3) call after the initialization of the context.

The AES-XTS implementations allow streaming to be performed, but each EVP_EncryptUpdate (3) or EVP_DecryptUpdate (3) call requires each input to be a multiple of the blocksize. Only the final EVP_EncryptUpdate() or EVP_DecryptUpdate() call can optionally have an input that is not a multiple of the blocksize but is larger than one block. In that case ciphertext stealing (CTS) is used to fill the block.

SEE ALSO

provider-cipher (7), OSSL_PROVIDER-FIPS (7), OSSL_PROVIDER-default (7)

HISTORY

The GCM-SIV mode ciphers were added in OpenSSL version 3.2.

COPYRIGHT

Copyright 2021-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

454 - Linux cli command ossl-guide-tls-client-non-blockssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ossl-guide-tls-client-non-blockssl and provides detailed information about the command ossl-guide-tls-client-non-blockssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ossl-guide-tls-client-non-blockssl.

NAME 🖥️ ossl-guide-tls-client-non-blockssl 🖥️

guide-tls-client-non-block - OpenSSL Guide: Writing a simple nonblocking TLS client

SIMPLE NONBLOCKING TLS CLIENT EXAMPLE

This page will build on the example developed on the ossl-guide-tls-client-block (7) page which demonstrates how to write a simple blocking TLS client. On this page we will amend that demo code so that it supports a nonblocking socket.

The complete source code for this example nonblocking TLS client is available in the demos/guide directory of the OpenSSL source distribution in the file tls-client-non-block.c. It is also available online at <https://github.com/openssl/openssl/blob/master/demos/guide/tls-client-non-block.c>.

As we saw in the previous example a blocking socket is one which waits (blocks) until data is available to read if you attempt to read from it when there is no data yet. Similarly it waits when writing if the socket is currently unable to write at the moment. This can simplify the development of code because you do not have to worry about what to do in these cases. The execution of the code will simply stop until it is able to continue. However in many cases you do not want this behaviour. Rather than stopping and waiting your application may need to go and do other tasks whilst the socket is unable to read/write, for example updating a GUI or performing operations on some other socket.

With a nonblocking socket attempting to read or write to a socket that is currently unable to read or write will return immediately with a non-fatal error. Although OpenSSL does the reading/writing to the socket this nonblocking behaviour is propagated up to the application so that OpenSSL I/O functions such as SSL_read_ex (3) or SSL_write_ex (3) will not block.

Since this page is building on the example developed on the ossl-guide-tls-client-block (7) page we assume that you are familiar with it and we only explain how this example differs.

Setting the socket to be nonblocking

The first step in writing an application that supports nonblocking is to set the socket into nonblocking mode. A socket will be default be blocking. The exact details on how to do this can differ from one platform to another. Fortunately OpenSSL offers a portable function that will do this for you:

/* Set to nonblocking mode */ if (!BIO_socket_nbio(sock, 1)) { sock = -1; continue; }

You do not have to use OpenSSL’s function for this. You can of course directly call whatever functions that your Operating System provides for this purpose on your platform.

Performing work while waiting for the socket

In a nonblocking application you will need work to perform in the event that we want to read or write to the socket, but we are currently unable to. In fact this is the whole point of using a nonblocking socket, i.e. to give the application the opportunity to do something else. Whatever it is that the application has to do, it must also be prepared to come back and retry the operation that it previously attempted periodically to see if it can now complete. Ideally it would only do this in the event that the state of the underlying socket has actually changed (e.g. become readable where it wasn’t before), but this does not have to be the case. It can retry at any time.

Note that it is important that you retry exactly the same operation that you tried last time. You cannot start something new. For example if you were attempting to write the text “Hello World” and the operation failed because the socket is currently unable to write, then you cannot then attempt to write some other text when you retry the operation.

In this demo application we will create a helper function which simulates doing other work. In fact, for the sake of simplicity, it will do nothing except wait for the state of the socket to change.

We call our function wait_for_activity() because all it does is wait until the underlying socket has become readable or writeable when it wasn’t before.

static void wait_for_activity(SSL *ssl, int write) { fd_set fds; int width, sock; /* Get hold of the underlying file descriptor for the socket */ sock = SSL_get_fd(ssl); FD_ZERO(&fds); FD_SET(sock, &fds); width = sock + 1; /* * Wait until the socket is writeable or readable. We use select here * for the sake of simplicity and portability, but you could equally use * poll/epoll or similar functions * * NOTE: For the purposes of this demonstration code this effectively * makes this demo block until it has something more useful to do. In a * real application you probably want to go and do other work here (e.g. * update a GUI, or service other connections). * * Lets say for example that you want to update the progress counter on * a GUI every 100ms. One way to do that would be to add a 100ms timeout * in the last parameter to “select” below. Then, when select returns, * you check if it did so because of activity on the file descriptors or * because of the timeout. If it is due to the timeout then update the * GUI and then restart the “select”. */ if (write) select(width, NULL, &fds, NULL, NULL); else select(width, &fds, NULL, NULL, NULL); }

In this example we are using the select function because it is very simple to use and is available on most Operating Systems. However you could use any other similar function to do the same thing. select waits for the state of the underlying socket(s) to become readable/writeable before returning. It also supports a “timeout” (as do most other similar functions) so in your own applications you can make use of this to periodically wake up and perform work while waiting for the socket state to change. But we don’t use that timeout capability in this example for the sake of simplicity.

Handling errors from OpenSSL I/O functions

An application that uses a nonblocking socket will need to be prepared to handle errors returned from OpenSSL I/O functions such as SSL_read_ex (3) or SSL_write_ex (3). Errors may be fatal (for example because the underlying connection has failed), or non-fatal (for example because we are trying to read from the underlying socket but the data has not yet arrived from the peer).

SSL_read_ex (3) and SSL_write_ex (3) will return 0 to indicate an error and SSL_read (3) and SSL_write (3) will return 0 or a negative value to indicate an error. SSL_shutdown (3) will return a negative value to incidate an error.

In the event of an error an application should call SSL_get_error (3) to find out what type of error has occurred. If the error is non-fatal and can be retried then SSL_get_error (3) will return SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE depending on whether OpenSSL wanted to read to or write from the socket but was unable to. Note that a call to SSL_read_ex (3) or SSL_read (3) can still generate SSL_ERROR_WANT_WRITE because OpenSSL may need to write protocol messages (such as to update cryptographic keys) even if the application is only trying to read data. Similarly calls to SSL_write_ex (3) or SSL_write (3) might generate SSL_ERROR_WANT_READ.

Another type of non-fatal error that may occur is SSL_ERROR_ZERO_RETURN. This indicates an EOF (End-Of-File) which can occur if you attempt to read data from an SSL object but the peer has indicated that it will not send any more data on it. In this case you may still want to write data to the connection but you will not receive any more data.

Fatal errors that may occur are SSL_ERROR_SYSCALL and SSL_ERROR_SSL. These indicate that the underlying connection has failed. You should not attempt to shut it down with SSL_shutdown (3). SSL_ERROR_SYSCALL indicates that OpenSSL attempted to make a syscall that failed. You can consult errno for further details. SSL_ERROR_SSL indicates that some OpenSSL error occurred. You can consult the OpenSSL error stack for further details (for example by calling ERR_print_errors (3) to print out details of errors that have occurred).

In our demo application we will write a function to handle these errors from OpenSSL I/O functions:

static int handle_io_failure(SSL *ssl, int res) { switch (SSL_get_error(ssl, res)) { case SSL_ERROR_WANT_READ: /* Temporary failure. Wait until we can read and try again */ wait_for_activity(ssl, 0); return 1; case SSL_ERROR_WANT_WRITE: /* Temporary failure. Wait until we can write and try again */ wait_for_activity(ssl, 1); return 1; case SSL_ERROR_ZERO_RETURN: /* EOF */ return 0; case SSL_ERROR_SYSCALL: return -1; case SSL_ERROR_SSL: /* * If the failure is due to a verification error we can get more * information about it from SSL_get_verify_result(). */ if (SSL_get_verify_result(ssl) != X509_V_OK) printf(“Verify error: %s “, X509_verify_cert_error_string(SSL_get_verify_result(ssl))); return -1; default: return -1; } }

This function takes as arguments the SSL object that represents the connection, as well as the return code from the I/O function that failed. In the event of a non-fatal failure, it waits until a retry of the I/O operation might succeed (by using the wait_for_activity() function that we developed in the previous section). It returns 1 in the event of a non-fatal error (except EOF), 0 in the event of EOF, or -1 if a fatal error occurred.

Creating the SSL_CTX and SSL objects

In order to connect to a server we must create SSL_CTX and SSL objects for this. The steps do this are the same as for a blocking client and are explained on the ossl-guide-tls-client-block (7) page. We won’t repeat that information here.

Performing the handshake

As in the demo for a blocking TLS client we use the SSL_connect (3) function to perform the TLS handshake with the server. Since we are using a nonblocking socket it is very likely that calls to this function will fail with a non-fatal error while we are waiting for the server to respond to our handshake messages. In such a case we must retry the same SSL_connect (3) call at a later time. In this demo we this in a loop:

/* Do the handshake with the server */ while ((ret = SSL_connect(ssl)) != 1) { if (handle_io_failure(ssl, ret) == 1) continue; /* Retry */ printf(“Failed to connect to server “); goto end; /* Cannot retry: error */ }

We continually call SSL_connect (3) until it gives us a success response. Otherwise we use the handle_io_failure() function that we created earlier to work out what we should do next. Note that we do not expect an EOF to occur at this stage, so such a response is treated in the same way as a fatal error.

Sending and receiving data

As with the blocking TLS client demo we use the SSL_write_ex (3) function to send data to the server. As with SSL_connect (3) above, because we are using a nonblocking socket, this call could fail with a non-fatal error. In that case we should retry exactly the same SSL_write_ex (3) call again. Note that the parameters must be exactly the same, i.e. the same pointer to the buffer to write with the same length. You must not attempt to send different data on a retry. An optional mode does exist (SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER) which will configure OpenSSL to allow the buffer being written to change from one retry to the next. However, in this case, you must still retry exactly the same data - even though the buffer that contains that data may change location. See SSL_CTX_set_mode (3) for further details. As in the TLS client blocking tutorial (ossl-guide-tls-client-block (7)) we write the request in three chunks.

/* Write an HTTP GET request to the peer */ while (!SSL_write_ex(ssl, request_start, strlen(request_start), &written)) { if (handle_io_failure(ssl, 0) == 1) continue; /* Retry */ printf(“Failed to write start of HTTP request “); goto end; /* Cannot retry: error */ } while (!SSL_write_ex(ssl, hostname, strlen(hostname), &written)) { if (handle_io_failure(ssl, 0) == 1) continue; /* Retry */ printf(“Failed to write hostname in HTTP request “); goto end; /* Cannot retry: error */ } while (!SSL_write_ex(ssl, request_end, strlen(request_end), &written)) { if (handle_io_failure(ssl, 0) == 1) continue; /* Retry */ printf(“Failed to write end of HTTP request “); goto end; /* Cannot retry: error */ }

On a write we do not expect to see an EOF response so we treat that case in the same way as a fatal error.

Reading a response back from the server is similar:

do { /* * Get up to sizeof(buf) bytes of the response. We keep reading until * the server closes the connection. */ while (!eof && !SSL_read_ex(ssl, buf, sizeof(buf), &readbytes)) { switch (handle_io_failure(ssl, 0)) { case 1: continue; /* Retry */ case 0: eof = 1; continue; case -1: default: printf(“Failed reading remaining data “); goto end; /* Cannot retry: error */ } } /* * OpenSSL does not guarantee that the returned data is a string or * that it is NUL terminated so we use fwrite() to write the exact * number of bytes that we read. The data could be non-printable or * have NUL characters in the middle of it. For this simple example * were going to print it to stdout anyway. */ if (!eof) fwrite(buf, 1, readbytes, stdout); } while (!eof); /* In case the response didnt finish with a newline we add one now */ printf(” “);

The main difference this time is that it is valid for us to receive an EOF response when trying to read data from the server. This will occur when the server closes down the connection after sending all the data in its response.

In this demo we just print out all the data we’ve received back in the response from the server. We continue going around the loop until we either encounter a fatal error, or we receive an EOF (indicating a graceful finish).

Shutting down the connection

As in the TLS blocking example we must shutdown the connection when we are finished with it.

If our application was initiating the shutdown then we would expect to see SSL_shutdown (3) give a return value of 0, and then we would continue to call it until we received a return value of 1 (meaning we have successfully completed the shutdown). In this particular example we don’t expect SSL_shutdown() to return 0 because we have already received EOF from the server indicating that it has shutdown already. So we just keep calling it until SSL_shutdown() returns 1. Since we are using a nonblocking socket we might expect to have to retry this operation several times. If SSL_shutdown (3) returns a negative result then we must call SSL_get_error (3) to work out what to do next. We use our handle_io_failure() function that we developed earlier for this:

/* * The peer already shutdown gracefully (we know this because of the * SSL_ERROR_ZERO_RETURN (i.e. EOF) above). We should do the same back. */ while ((ret = SSL_shutdown(ssl)) != 1) { if (ret < 0 && handle_io_failure(ssl, ret) == 1) continue; /* Retry */ /* * ret == 0 is unexpected here because that means “weve sent a * close_notify and were waiting for one back”. But we already know * we got one from the peer because of the SSL_ERROR_ZERO_RETURN * (i.e. EOF) above. */ printf(“Error shutting down “); goto end; /* Cannot retry: error */ }

Final clean up

As with the blocking TLS client example, once our connection is finished with we must free it. The steps to do this for this example are the same as for the blocking example, so we won’t repeat it here.

FURTHER READING

See ossl-guide-tls-client-block (7) to read a tutorial on how to write a blocking TLS client. See ossl-guide-quic-client-block (7) to see how to do the same thing for a QUIC client.

SEE ALSO

ossl-guide-introduction (7), ossl-guide-libraries-introduction (7), ossl-guide-libssl-introduction (7), ossl-guide-tls-introduction (7), ossl-guide-tls-client-block (7), ossl-guide-quic-client-block (7)

COPYRIGHT

Copyright 2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

455 - Linux cli command ALTER_TRIGGER

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_TRIGGER and provides detailed information about the command ALTER_TRIGGER, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_TRIGGER.

NAME 🖥️ ALTER_TRIGGER 🖥️

change the definition of a trigger

SYNOPSIS

ALTER TRIGGER name ON table_name RENAME TO new_name
ALTER TRIGGER name ON table_name [ NO ] DEPENDS ON EXTENSION extension_name

DESCRIPTION

ALTER TRIGGER changes properties of an existing trigger.

The RENAME clause changes the name of the given trigger without otherwise changing the trigger definition. If the table that the trigger is on is a partitioned table, then corresponding clone triggers in the partitions are renamed too.

The DEPENDS ON EXTENSION clause marks the trigger as dependent on an extension, such that if the extension is dropped, the trigger will automatically be dropped as well.

You must own the table on which the trigger acts to be allowed to change its properties.

PARAMETERS

name

The name of an existing trigger to alter.

table_name

The name of the table on which this trigger acts.

new_name

The new name for the trigger.

extension_name

The name of the extension that the trigger is to depend on (or no longer dependent on, if NO is specified). A trigger thats marked as dependent on an extension is automatically dropped when the extension is dropped.

NOTES

The ability to temporarily enable or disable a trigger is provided by ALTER TABLE, not by ALTER TRIGGER, because ALTER TRIGGER has no convenient way to express the option of enabling or disabling all of a tables triggers at once.

EXAMPLES

To rename an existing trigger:

ALTER TRIGGER emp_stamp ON emp RENAME TO emp_track_chgs;

To mark a trigger as being dependent on an extension:

ALTER TRIGGER emp_stamp ON emp DEPENDS ON EXTENSION emplib;

COMPATIBILITY

ALTER TRIGGER is a PostgreSQL extension of the SQL standard.

SEE ALSO

ALTER TABLE (ALTER_TABLE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

456 - Linux cli command EVP_RAND-SEED-SRCssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_RAND-SEED-SRCssl and provides detailed information about the command EVP_RAND-SEED-SRCssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_RAND-SEED-SRCssl.

NAME 🖥️ EVP_RAND-SEED-SRCssl 🖥️

SEED-SRC - The randomness seed source EVP_RAND implementation

DESCRIPTION

Support for deterministic random number generator seeding through the EVP_RAND API.

The seed sources used are specified at the time OpenSSL is configured for building using the –with-rand-seed= option. By default, operating system randomness sources are used.

Identity

“SEED-SRC” is the name for this implementation; it can be used with the EVP_RAND_fetch() function.

Supported parameters

The supported parameters are:

“state” (OSSL_RAND_PARAM_STATE) <integer>

“strength” (OSSL_RAND_PARAM_STRENGTH) <unsigned integer>

“max_request” (OSSL_RAND_PARAM_MAX_REQUEST) <unsigned integer>

These parameters work as described in “PARAMETERS” in EVP_RAND (3).

NOTES

A context for the seed source can be obtained by calling:

EVP_RAND *rand = EVP_RAND_fetch(NULL, “SEED-SRC”, NULL); EVP_RAND_CTX *rctx = EVP_RAND_CTX_new(rand, NULL);

EXAMPLES

EVP_RAND *rand; EVP_RAND_CTX *seed, *rctx; unsigned char bytes[100]; OSSL_PARAM params[2], *p = params; unsigned int strength = 128; /* Create and instantiate a seed source */ rand = EVP_RAND_fetch(NULL, “SEED-SRC”, NULL); seed = EVP_RAND_CTX_new(rand, NULL); EVP_RAND_instantiate(seed, strength, 0, NULL, 0, NULL); EVP_RAND_free(rand); /* Feed this into a DRBG */ rand = EVP_RAND_fetch(NULL, “CTR-DRBG”, NULL); rctx = EVP_RAND_CTX_new(rand, seed); EVP_RAND_free(rand); /* Configure the DRBG */ *p++ = OSSL_PARAM_construct_utf8_string(OSSL_DRBG_PARAM_CIPHER, SN_aes_256_ctr, 0); *p = OSSL_PARAM_construct_end(); EVP_RAND_instantiate(rctx, strength, 0, NULL, 0, params); EVP_RAND_generate(rctx, bytes, sizeof(bytes), strength, 0, NULL, 0); EVP_RAND_CTX_free(rctx); EVP_RAND_CTX_free(seed);

SEE ALSO

EVP_RAND (3), “PARAMETERS” in EVP_RAND (3)

COPYRIGHT

Copyright 2020-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

457 - Linux cli command process-keyring

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command process-keyring and provides detailed information about the command process-keyring, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the process-keyring.

NAME 🖥️ process-keyring 🖥️

keyring - per-process shared keyring

DESCRIPTION

The process keyring is a keyring used to anchor keys on behalf of a process. It is created only when a process requests it. The process keyring has the name (description) _pid.

A special serial number value, KEY_SPEC_PROCESS_KEYRING, is defined that can be used in lieu of the actual serial number of the calling process’s process keyring.

From the keyctl(1) utility, ‘@p’ can be used instead of a numeric key ID in much the same way, but since keyctl(1) is a program run after forking, this is of no utility.

A thread created using the clone(2) CLONE_THREAD flag has the same process keyring as the caller of clone(2). When a new process is created using fork() it initially has no process keyring. A process’s process keyring is cleared on execve(2). The process keyring is destroyed when the last thread that refers to it terminates.

If a process doesn’t have a process keyring when it is accessed, then the process keyring will be created if the keyring is to be modified; otherwise, the error ENOKEY results.

SEE ALSO

keyctl(1), keyctl(3), keyrings(7), persistent-keyring(7), session-keyring(7), thread-keyring(7), user-keyring(7), user-session-keyring(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

458 - Linux cli command EVP_MD-KECCAK-KMACssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_MD-KECCAK-KMACssl and provides detailed information about the command EVP_MD-KECCAK-KMACssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_MD-KECCAK-KMACssl.

NAME 🖥️ EVP_MD-KECCAK-KMACssl 🖥️

SHAKE, EVP_MD-KECCAK-KMAC - The SHAKE / KECCAK family EVP_MD implementations

DESCRIPTION

Support for computing SHAKE or KECCAK-KMAC digests through the EVP_MD API.

KECCAK-KMAC is an Extendable Output Function (XOF), with a definition similar to SHAKE, used by the KMAC EVP_MAC implementation (see EVP_MAC-KMAC (7)).

Identities

This implementation is available in the FIPS provider as well as the default provider, and includes the following varieties:

KECCAK-KMAC-128
Known names are “KECCAK-KMAC-128” and “KECCAK-KMAC128”. This is used by EVP_MAC-KMAC128 (7). Using the notation from NIST FIPS 202 (Section 6.2), we have KECCAK-KMAC-128(M, d) = KECCAK[256](M || 00, d) (see the description of KMAC128 in Appendix A of NIST SP 800-185).

KECCAK-KMAC-256
Known names are “KECCAK-KMAC-256” and “KECCAK-KMAC256”. This is used by EVP_MAC-KMAC256 (7). Using the notation from NIST FIPS 202 (Section 6.2), we have KECCAK-KMAC-256(M, d) = KECCAK[512](M || 00, d) (see the description of KMAC256 in Appendix A of NIST SP 800-185).

SHAKE-128
Known names are “SHAKE-128” and “SHAKE128”.

SHAKE-256
Known names are “SHAKE-256” and “SHAKE256”.

Gettable Parameters

This implementation supports the common gettable parameters described in EVP_MD-common (7).

Settable Context Parameters

These implementations support the following OSSL_PARAM (3) entries, settable for an EVP_MD_CTX with EVP_MD_CTX_set_params (3):

“xoflen” (OSSL_DIGEST_PARAM_XOFLEN) <unsigned integer>
Sets the digest length for extendable output functions. The length of the “xoflen” parameter should not exceed that of a size_t. For backwards compatibility reasons the default xoflen length for SHAKE-128 is 16 (bytes) which results in a security strength of only 64 bits. To ensure the maximum security strength of 128 bits, the xoflen should be set to at least 32. For backwards compatibility reasons the default xoflen length for SHAKE-256 is 32 (bytes) which results in a security strength of only 128 bits. To ensure the maximum security strength of 256 bits, the xoflen should be set to at least 64.

SEE ALSO

EVP_MD_CTX_set_params (3), provider-digest (7), OSSL_PROVIDER-default (7)

COPYRIGHT

Copyright 2020-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

459 - Linux cli command pcap-tstamp

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command pcap-tstamp and provides detailed information about the command pcap-tstamp, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the pcap-tstamp.

NAME 🖥️ pcap-tstamp 🖥️

tstamp - packet time stamps in libpcap

DESCRIPTION

When capturing traffic, each packet is given a time stamp representing, for incoming packets, the arrival time of the packet and, for outgoing packets, the transmission time of the packet. This time is an approximation of the arrival or transmission time. If it is supplied by the operating system running on the host on which the capture is being done, there are several reasons why it might not precisely represent the arrival or transmission time:

if the time stamp is applied to the packet when the networking stack receives the packet, the networking stack might not see the packet until an interrupt is delivered for the packet or a timer event causes the networking device driver to poll for packets, and the time stamp might not be applied until the packet has had some processing done by other code in the networking stack, so there might be a significant delay between the time when the last bit of the packet is received by the capture device and when the networking stack time-stamps the packet;

the timer used to generate the time stamps might have low resolution, for example, it might be a timer updated once per host operating system timer tick, with the host operating system timer ticking once every few milliseconds;

a high-resolution timer might use a counter that runs at a rate dependent on the processor clock speed, and that clock speed might be adjusted upwards or downwards over time and the timer might not be able to compensate for all those adjustments;

the host operating system’s clock might be adjusted over time to match a time standard to which the host is being synchronized, which might be done by temporarily slowing down or speeding up the clock or by making a single adjustment;

different CPU cores on a multi-core or multi-processor system might be running at different speeds, or might not have time counters all synchronized, so packets time-stamped by different cores might not have consistent time stamps;

some time sources, such as those that supply POSIX “seconds since the Epoch” time, do not count leap seconds, meaning that the seconds portion (tv_sec) of the time stamp might not be incremented for a leap second, so that the fraction-of-a-second part of the time stamp might roll over past zero but the second part would not change, or the clock might run slightly more slowly for a period before the leap second.

For these reasons, time differences between packet time stamps will not necessarily accurately reflect the time differences between the receipt or transmission times of the packets.

In addition, packets time-stamped by different cores might be time-stamped in one order and added to the queue of packets for libpcap to read in another order, so time stamps might not be monotonically increasing.

Some capture devices on some platforms can provide time stamps for packets; those time stamps are usually high-resolution time stamps, and are usually applied to the packet when the first or last bit of the packet arrives, and are thus more accurate than time stamps provided by the host operating system. Those time stamps might not, however, be synchronized with the host operating system’s clock, so that, for example, the time stamp of a packet might not correspond to the time stamp of an event on the host triggered by the arrival of that packet. If they are synchronized with the host operating system’s clock, some of the issues listed above with time stamps supplied by the host operating system may also apply to time stamps supplied by the capture device.

Depending on the capture device and the software on the host, libpcap might allow different types of time stamp to be used. The pcap_list_tstamp_types(3PCAP) routine provides, for a packet capture handle created by pcap_create(3PCAP) but not yet activated by pcap_activate(3PCAP), a list of time stamp types supported by the capture device for that handle. The list might be empty, in which case no choice of time stamp type is offered for that capture device. If the list is not empty, the pcap_set_tstamp_type(3PCAP) routine can be used after a pcap_create() call and before a pcap_activate() call to specify the type of time stamp to be used on the device. The time stamp types are listed here; the first value is the #define to use in code, the second value is the value returned by pcap_tstamp_type_val_to_name(3PCAP) and accepted by pcap_tstamp_type_name_to_val(3PCAP).

PCAP_TSTAMP_HOST - host
Time stamp provided by the host on which the capture is being done. The precision of this time stamp is unspecified; it might or might not be synchronized with the host operating system’s clock.

PCAP_TSTAMP_HOST_LOWPREC - host_lowprec
Time stamp provided by the host on which the capture is being done. This is a low-precision time stamp, synchronized with the host operating system’s clock.

PCAP_TSTAMP_HOST_HIPREC - host_hiprec
Time stamp provided by the host on which the capture is being done. This is a high-precision time stamp, synchronized with the host operating system’s clock. It might be more expensive to fetch than PCAP_TSTAMP_HOST_LOWPREC.

PCAP_TSTAMP_HOST_HIPREC_UNSYNCED - host_hiprec_unsynced
Time stamp provided by the host on which the capture is being done. This is a high-precision time stamp, not synchronized with the host operating system’s clock. It might be more expensive to fetch than PCAP_TSTAMP_HOST_LOWPREC.

PCAP_TSTAMP_ADAPTER - adapter
Time stamp provided by the network adapter on which the capture is being done. This is a high-precision time stamp, synchronized with the host operating system’s clock.

PCAP_TSTAMP_ADAPTER_UNSYNCED - adapter_unsynced
Time stamp provided by the network adapter on which the capture is being done. This is a high-precision time stamp; it is not synchronized with the host operating system’s clock.

Time stamps synchronized with the system clock can go backwards, as the system clock can go backwards. If a clock is not in sync with the system clock, that could be because the system clock isn’t keeping accurate time, because the other clock isn’t keeping accurate time, or both.

Host-provided time stamps generally correspond to the time when the time-stamping code sees the packet; this could be some unknown amount of time after the first or last bit of the packet is received by the network adapter, due to batching of interrupts for packet arrival, queueing delays, etc..

By default, when performing a live capture or reading from a savefile, time stamps are supplied as seconds since January 1, 1970, 00:00:00 UTC, and microseconds since that seconds value, even if higher-resolution time stamps are available from the capture device or in the savefile. If, when reading a savefile, the time stamps in the file have a higher resolution than one microsecond, the additional digits of resolution are discarded.

The pcap_set_tstamp_precision(3PCAP) routine can be used after a pcap_create() call and after a pcap_activate() call to specify the resolution of the time stamps to get for the device. If the hardware or software cannot supply a higher-resolution time stamp, the pcap_set_tstamp_precision() call will fail, and the time stamps supplied after the pcap_activate() call will have microsecond resolution.

When opening a savefile, the pcap_open_offline_with_tstamp_precision(3PCAP) and pcap_fopen_offline_with_tstamp_precision(3PCAP) routines can be used to specify the resolution of time stamps to be read from the file; if the time stamps in the file have a lower resolution, the fraction-of-a-second portion of the time stamps will be scaled to the specified resolution.

The pcap_get_tstamp_precision(3PCAP) routine returns the resolution of time stamps that will be supplied; when capturing packets, this does not reflect the actual precision of the time stamp supplied by the hardware or operating system and, when reading a savefile, this does not indicate the actual precision of time stamps in the file.

SEE ALSO

pcap(3PCAP)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

460 - Linux cli command providerssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command providerssl and provides detailed information about the command providerssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the providerssl.

NAME 🖥️ providerssl 🖥️

OpenSSL operation implementation providers

SYNOPSIS

#include <openssl/provider.h>

DESCRIPTION

General

This page contains information useful to provider authors.

A provider, in OpenSSL terms, is a unit of code that provides one or more implementations for various operations for diverse algorithms that one might want to perform.

An operation is something one wants to do, such as encryption and decryption, key derivation, MAC calculation, signing and verification, etc.

An algorithm is a named method to perform an operation. Very often, the algorithms revolve around cryptographic operations, but may also revolve around other types of operation, such as managing certain types of objects.

See crypto (7) for further details.

Provider

A provider offers an initialization function, as a set of base functions in the form of an OSSL_DISPATCH (3) array, and by extension, a set of OSSL_ALGORITHM (3)s (see openssl-core.h (7)). It may be a dynamically loadable module, or may be built-in, in OpenSSL libraries or in the application. If it’s a dynamically loadable module, the initialization function must be named OSSL_provider_init and must be exported. If it’s built-in, the initialization function may have any name.

The initialization function must have the following signature:

int NAME(const OSSL_CORE_HANDLE *handle, const OSSL_DISPATCH *in, const OSSL_DISPATCH **out, void **provctx);

handle is the OpenSSL library object for the provider, and works as a handle for everything the OpenSSL libraries need to know about the provider. For the provider itself, it is passed to some of the functions given in the dispatch array in.

in is a dispatch array of base functions offered by the OpenSSL libraries, and the available functions are further described in provider-base (7).

*out must be assigned a dispatch array of base functions that the provider offers to the OpenSSL libraries. The functions that may be offered are further described in provider-base (7), and they are the central means of communication between the OpenSSL libraries and the provider.

*provctx should be assigned a provider specific context to allow the provider multiple simultaneous uses. This pointer will be passed to various operation functions offered by the provider.

Note that the provider will not be made available for applications to use until the initialization function has completed and returned successfully.

One of the functions the provider offers to the OpenSSL libraries is the central mechanism for the OpenSSL libraries to get access to operation implementations for diverse algorithms. Its referred to with the number OSSL_FUNC_PROVIDER_QUERY_OPERATION and has the following signature:

const OSSL_ALGORITHM *provider_query_operation(void *provctx, int operation_id, const int *no_store);

provctx is the provider specific context that was passed back by the initialization function.

operation_id is an operation identity (see “Operations” below).

no_store is a flag back to the OpenSSL libraries which, when nonzero, signifies that the OpenSSL libraries will not store a reference to the returned data in their internal store of implementations.

The returned OSSL_ALGORITHM (3) is the foundation of any OpenSSL library API that uses providers for their implementation, most commonly in the fetching type of functions (see “ALGORITHM FETCHING” in crypto (7)).

Operations

Operations are referred to with numbers, via macros with names starting with OSSL_OP_.

With each operation comes a set of defined function types that a provider may or may not offer, depending on its needs.

Currently available operations are:

Digests
In the OpenSSL libraries, the corresponding method object is EVP_MD. The number for this operation is OSSL_OP_DIGEST. The functions the provider can offer are described in provider-digest (7).

Symmetric ciphers
In the OpenSSL libraries, the corresponding method object is EVP_CIPHER. The number for this operation is OSSL_OP_CIPHER. The functions the provider can offer are described in provider-cipher (7).

Message Authentication Code (MAC)
In the OpenSSL libraries, the corresponding method object is EVP_MAC. The number for this operation is OSSL_OP_MAC. The functions the provider can offer are described in provider-mac (7).

Key Derivation Function (KDF)
In the OpenSSL libraries, the corresponding method object is EVP_KDF. The number for this operation is OSSL_OP_KDF. The functions the provider can offer are described in provider-kdf (7).

Key Exchange
In the OpenSSL libraries, the corresponding method object is EVP_KEYEXCH. The number for this operation is OSSL_OP_KEYEXCH. The functions the provider can offer are described in provider-keyexch (7).

Asymmetric Ciphers
In the OpenSSL libraries, the corresponding method object is EVP_ASYM_CIPHER. The number for this operation is OSSL_OP_ASYM_CIPHER. The functions the provider can offer are described in provider-asym_cipher (7).

Asymmetric Key Encapsulation
In the OpenSSL libraries, the corresponding method object is EVP_KEM. The number for this operation is OSSL_OP_KEM. The functions the provider can offer are described in provider-kem (7).

Encoding
In the OpenSSL libraries, the corresponding method object is OSSL_ENCODER. The number for this operation is OSSL_OP_ENCODER. The functions the provider can offer are described in provider-encoder (7).

Decoding
In the OpenSSL libraries, the corresponding method object is OSSL_DECODER. The number for this operation is OSSL_OP_DECODER. The functions the provider can offer are described in provider-decoder (7).

Random Number Generation
The number for this operation is OSSL_OP_RAND. The functions the provider can offer for random number generation are described in provider-rand (7).

Key Management
The number for this operation is OSSL_OP_KEYMGMT. The functions the provider can offer for key management are described in provider-keymgmt (7).

Signing and Signature Verification
The number for this operation is OSSL_OP_SIGNATURE. The functions the provider can offer for digital signatures are described in provider-signature (7).

Store Management
The number for this operation is OSSL_OP_STORE. The functions the provider can offer for store management are described in provider-storemgmt (7).

Algorithm naming

Algorithm names are case insensitive. Any particular algorithm can have multiple aliases associated with it. The canonical OpenSSL naming scheme follows this format:

ALGNAME[VERSION?][-SUBNAME[VERSION?]?][-SIZE?][-MODE?]

VERSION is only present if there are multiple versions of an algorithm (e.g. MD2, MD4, MD5). It may be omitted if there is only one version.

SUBNAME may be present where multiple algorithms are combined together, e.g. MD5-SHA1.

SIZE is only present if multiple versions of an algorithm exist with different sizes (e.g. AES-128-CBC, AES-256-CBC)

MODE is only present where applicable.

Other aliases may exist for example where standards bodies or common practice use alternative names or names that OpenSSL has used historically.

OPENSSL PROVIDERS

OpenSSL provides a number of its own providers. These are the default, base, fips, legacy and null providers. See crypto (7) for an overview of these providers.

SEE ALSO

EVP_DigestInit_ex (3), EVP_EncryptInit_ex (3), OSSL_LIB_CTX (3), EVP_set_default_properties (3), EVP_MD_fetch (3), EVP_CIPHER_fetch (3), EVP_KEYMGMT_fetch (3), openssl-core.h (7), provider-base (7), provider-digest (7), provider-cipher (7), provider-keyexch (7)

HISTORY

The concept of providers and everything surrounding them was introduced in OpenSSL 3.0.

COPYRIGHT

Copyright 2019-2022 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

461 - Linux cli command EVP_KDF-HKDFssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KDF-HKDFssl and provides detailed information about the command EVP_KDF-HKDFssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KDF-HKDFssl.

NAME 🖥️ EVP_KDF-HKDFssl 🖥️

HKDF - The HKDF EVP_KDF implementation

DESCRIPTION

Support for computing the HKDF KDF through the EVP_KDF API.

The EVP_KDF-HKDF algorithm implements the HKDF key derivation function. HKDF follows the “extract-then-expand” paradigm, where the KDF logically consists of two modules. The first stage takes the input keying material and “extracts” from it a fixed-length pseudorandom key K. The second stage “expands” the key K into several additional pseudorandom keys (the output of the KDF).

Identity

“HKDF” is the name for this implementation; it can be used with the EVP_KDF_fetch() function.

Supported parameters

The supported parameters are:

“properties” (OSSL_KDF_PARAM_PROPERTIES) <UTF8 string>

“digest” (OSSL_KDF_PARAM_DIGEST) <UTF8 string>

“key” (OSSL_KDF_PARAM_KEY) <octet string>

“salt” (OSSL_KDF_PARAM_SALT) <octet string>

These parameters work as described in “PARAMETERS” in EVP_KDF (3).

“info” (OSSL_KDF_PARAM_INFO) <octet string>
This parameter sets the info value. The length of the context info buffer cannot exceed 1024 bytes; this should be more than enough for any normal use of HKDF.

“mode” (OSSL_KDF_PARAM_MODE) <UTF8 string> or <integer>
This parameter sets the mode for the HKDF operation. There are three modes that are currently defined:

“EXTRACT_AND_EXPAND” or EVP_KDF_HKDF_MODE_EXTRACT_AND_EXPAND
This is the default mode. Calling EVP_KDF_derive (3) on an EVP_KDF_CTX set up for HKDF will perform an extract followed by an expand operation in one go. The derived key returned will be the result after the expand operation. The intermediate fixed-length pseudorandom key K is not returned. In this mode the digest, key, salt and info values must be set before a key is derived otherwise an error will occur.

“EXTRACT_ONLY” or EVP_KDF_HKDF_MODE_EXTRACT_ONLY
In this mode calling EVP_KDF_derive (3) will just perform the extract operation. The value returned will be the intermediate fixed-length pseudorandom key K. The keylen parameter must match the size of K, which can be looked up by calling EVP_KDF_CTX_get_kdf_size() after setting the mode and digest. The digest, key and salt values must be set before a key is derived otherwise an error will occur.

“EXPAND_ONLY” or EVP_KDF_HKDF_MODE_EXPAND_ONLY
In this mode calling EVP_KDF_derive (3) will just perform the expand operation. The input key should be set to the intermediate fixed-length pseudorandom key K returned from a previous extract operation. The digest, key and info values must be set before a key is derived otherwise an error will occur.

NOTES

A context for HKDF can be obtained by calling:

EVP_KDF *kdf = EVP_KDF_fetch(NULL, “HKDF”, NULL); EVP_KDF_CTX *kctx = EVP_KDF_CTX_new(kdf);

The output length of an HKDF expand operation is specified via the keylen parameter to the EVP_KDF_derive (3) function. When using EVP_KDF_HKDF_MODE_EXTRACT_ONLY the keylen parameter must equal the size of the intermediate fixed-length pseudorandom key otherwise an error will occur. For that mode, the fixed output size can be looked up by calling EVP_KDF_CTX_get_kdf_size() after setting the mode and digest on the EVP_KDF_CTX.

EXAMPLES

This example derives 10 bytes using SHA-256 with the secret key “secret”, salt value “salt” and info value “label”:

EVP_KDF *kdf; EVP_KDF_CTX *kctx; unsigned char out[10]; OSSL_PARAM params[5], *p = params; kdf = EVP_KDF_fetch(NULL, “HKDF”, NULL); kctx = EVP_KDF_CTX_new(kdf); EVP_KDF_free(kdf); *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_DIGEST, SN_sha256, strlen(SN_sha256)); *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_KEY, “secret”, (size_t)6); *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_INFO, “label”, (size_t)5); *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_SALT, “salt”, (size_t)4); *p = OSSL_PARAM_construct_end(); if (EVP_KDF_derive(kctx, out, sizeof(out), params) <= 0) { error(“EVP_KDF_derive”); } EVP_KDF_CTX_free(kctx);

CONFORMING TO

RFC 5869

SEE ALSO

EVP_KDF (3), EVP_KDF_CTX_new (3), EVP_KDF_CTX_free (3), EVP_KDF_CTX_get_kdf_size (3), EVP_KDF_CTX_set_params (3), EVP_KDF_derive (3), “PARAMETERS” in EVP_KDF (3), EVP_KDF-TLS13_KDF (7)

HISTORY

This functionality was added in OpenSSL 3.0.

COPYRIGHT

Copyright 2016-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

462 - Linux cli command RELEASE_SAVEPOINT

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command RELEASE_SAVEPOINT and provides detailed information about the command RELEASE_SAVEPOINT, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the RELEASE_SAVEPOINT.

NAME 🖥️ RELEASE_SAVEPOINT 🖥️

release a previously defined savepoint

SYNOPSIS

RELEASE [ SAVEPOINT ] savepoint_name

DESCRIPTION

RELEASE SAVEPOINT releases the named savepoint and all active savepoints that were created after the named savepoint, and frees their resources. All changes made since the creation of the savepoint that didnt already get rolled back are merged into the transaction or savepoint that was active when the named savepoint was created. Changes made after RELEASE SAVEPOINT will also be part of this active transaction or savepoint.

PARAMETERS

savepoint_name

The name of the savepoint to release.

NOTES

Specifying a savepoint name that was not previously defined is an error.

It is not possible to release a savepoint when the transaction is in an aborted state; to do that, use ROLLBACK TO SAVEPOINT (ROLLBACK_TO_SAVEPOINT(7)).

If multiple savepoints have the same name, only the most recently defined unreleased one is released. Repeated commands will release progressively older savepoints.

EXAMPLES

To establish and later release a savepoint:

BEGIN; INSERT INTO table1 VALUES (3); SAVEPOINT my_savepoint; INSERT INTO table1 VALUES (4); RELEASE SAVEPOINT my_savepoint; COMMIT;

The above transaction will insert both 3 and 4.

A more complex example with multiple nested subtransactions:

BEGIN; INSERT INTO table1 VALUES (1); SAVEPOINT sp1; INSERT INTO table1 VALUES (2); SAVEPOINT sp2; INSERT INTO table1 VALUES (3); RELEASE SAVEPOINT sp2; INSERT INTO table1 VALUES (4))); – generates an error

In this example, the application requests the release of the savepoint sp2, which inserted 3. This changes the inserts transaction context to sp1. When the statement attempting to insert value 4 generates an error, the insertion of 2 and 4 are lost because they are in the same, now-rolled back savepoint, and value 3 is in the same transaction context. The application can now only choose one of these two commands, since all other commands will be ignored:

ROLLBACK; ROLLBACK TO SAVEPOINT sp1;

Choosing ROLLBACK will abort everything, including value 1, whereas ROLLBACK TO SAVEPOINT sp1 will retain value 1 and allow the transaction to continue.

COMPATIBILITY

This command conforms to the SQL standard. The standard specifies that the key word SAVEPOINT is mandatory, but PostgreSQL allows it to be omitted.

SEE ALSO

BEGIN(7), COMMIT(7), ROLLBACK(7), ROLLBACK TO SAVEPOINT (ROLLBACK_TO_SAVEPOINT(7)), SAVEPOINT(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

463 - Linux cli command iso-8859-7

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso-8859-7 and provides detailed information about the command iso-8859-7, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso-8859-7.

NAME 🖥️ iso-8859-7 🖥️

7 - ISO/IEC 8859-7 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-7 encodes the characters used in modern monotonic Greek.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-7 characters

The following table displays the characters in ISO/IEC 8859-7 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-7 was formerly known as ELOT-928 or ECMA-118:1986.

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

464 - Linux cli command term

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command term and provides detailed information about the command term, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the term.

NAME 🖥️ term 🖥️

conventions for naming terminal types

DESCRIPTION

The environment variable TERM should normally contain the type name of the terminal, console or display-device type you are using. This information is critical for all screen-oriented programs, including your editor and mailer.

A default TERM value will be set on a per-line basis by either /etc/inittab (e.g., System-V-like Unices) or /etc/ttys (BSD Unices). This will nearly always suffice for workstation and microcomputer consoles.

If you use a dialup line, the type of device attached to it may vary. Older Unix systems pre-set a very dumb terminal type like dumb or dialup on dialup lines. Newer ones may pre-set vt100, reflecting the prevalence of DEC VT100-compatible terminals and personal-computer emulators.

Modern telnets pass your TERM environment variable from the local side to the remote one. There can be problems if the remote terminfo or termcap entry for your type is not compatible with yours, but this situation is rare and can almost always be avoided by explicitly exporting vt100 (assuming you are in fact using a VT100-superset console, terminal, or terminal emulator).

In any case, you are free to override the system TERM setting to your taste in your shell profile. The tset(1) utility may be of assistance; you can give it a set of rules for deducing or requesting a terminal type based on the tty device and baud rate.

Setting your own TERM value may also be useful if you have created a custom entry incorporating options (such as visual bell or reverse-video) which you wish to override the system default type for your line.

Terminal type descriptions are stored as files of capability data underneath /etc/terminfo. To browse a list of all terminal names recognized by the system, do

toe | more

from your shell. These capability files are in a binary format optimized for retrieval speed (unlike the old text-based termcap format they replace); to examine an entry, you must use the infocmp(1) command. Invoke it as follows:

infocmp entry_name

where entry_name is the name of the type you wish to examine (and the name of its capability file the subdirectory of /etc/terminfo named for its first letter). This command dumps a capability file in the text format described by terminfo(5).

The first line of a terminfo(5) description gives the names by which terminfo knows a terminal, separated by | (pipe-bar) characters with the last name field terminated by a comma. The first name field is the type’s primary name, and is the one to use when setting TERM. The last name field (if distinct from the first) is actually a description of the terminal type (it may contain blanks; the others must be single words). Name fields between the first and last (if present) are aliases for the terminal, usually historical names retained for compatibility.

There are some conventions for how to choose terminal primary names that help keep them informative and unique. Here is a step-by-step guide to naming terminals that also explains how to parse them:

First, choose a root name. The root will consist of a lower-case letter followed by up to seven lower-case letters or digits. You need to avoid using punctuation characters in root names, because they are used and interpreted as filenames and shell meta-characters (such as !, $, *, ?, etc.) embedded in them may cause odd and unhelpful behavior. The slash (/), or any other character that may be interpreted by anyone’s file system (\ $, [, ]), is especially dangerous (terminfo is platform-independent, and choosing names with special characters could someday make life difficult for users of a future port). The dot (.) character is relatively safe as long as there is at most one per root name; some historical terminfo names use it.

The root name for a terminal or workstation console type should almost always begin with a vendor prefix (such as hp for Hewlett-Packard, wy for Wyse, or att for AT&T terminals), or a common name of the terminal line (vt for the VT series of terminals from DEC, or sun for Sun Microsystems workstation consoles, or regent for the ADDS Regent series. You can list the terminfo tree to see what prefixes are already in common use. The root name prefix should be followed when appropriate by a model number; thus vt100, hp2621, wy50.

The root name for a PC-Unix console type should be the OS name, i.e., linux, bsdos, freebsd, netbsd. It should not be console or any other generic that might cause confusion in a multi-platform environment! If a model number follows, it should indicate either the OS release level or the console driver release level.

The root name for a terminal emulator (assuming it does not fit one of the standard ANSI or vt100 types) should be the program name or a readily recognizable abbreviation of it (i.e., versaterm, ctrm).

Following the root name, you may add any reasonable number of hyphen-separated feature suffixes.

2p
Has two pages of memory. Likewise 4p, 8p, etc.

mc
Magic-cookie. Some terminals (notably older Wyses) can only support one attribute without magic-cookie lossage. Their base entry is usually paired with another that has this suffix and uses magic cookies to support multiple attributes.

-am
Enable auto-margin (right-margin wraparound).

-m
Mono mode - suppress color support.

-na
No arrow keys - termcap ignores arrow keys which are actually there on the terminal, so the user can use the arrow keys locally.

-nam
No auto-margin - suppress am capability.

-nl
No labels - suppress soft labels.

-nsl
No status line - suppress status line.

-pp
Has a printer port which is used.

-rv
Terminal in reverse video mode (black on white).

-s
Enable status line.

-vb
Use visible bell (flash) rather than beep.

-w
Wide; terminal is in 132-column mode.

Conventionally, if your terminal type is a variant intended to specify a line height, that suffix should go first. So, for a hypothetical FuBarCo model 2317 terminal in 30-line mode with reverse video, best form would be fubar-30-rv (rather than, say, fubar-rv-30).

Terminal types that are written not as standalone entries, but rather as components to be plugged into other entries via use capabilities, are distinguished by using embedded plus signs rather than dashes.

Commands which use a terminal type to control display often accept a -T option that accepts a terminal name argument. Such programs should fall back on the TERM environment variable when no -T option is specified.

FILES

/etc/terminfo
compiled terminal description database

/etc/inittab
tty line initialization (AT&T-like Unices)

/etc/ttys
tty line initialization (BSD-like Unices)

PORTABILITY

For maximum compatibility with older System V Unices, names and aliases should be unique within the first 14 characters.

SEE ALSO

ncurses(3NCURSES), term(5), terminfo(5)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

465 - Linux cli command EVP_MAC-BLAKE2BMACssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_MAC-BLAKE2BMACssl and provides detailed information about the command EVP_MAC-BLAKE2BMACssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_MAC-BLAKE2BMACssl.

NAME 🖥️ EVP_MAC-BLAKE2BMACssl 🖥️

BLAKE2, EVP_MAC-BLAKE2BMAC, EVP_MAC-BLAKE2SMAC - The BLAKE2 EVP_MAC implementations

DESCRIPTION

Support for computing BLAKE2 MACs through the EVP_MAC API.

Identity

These implementations are identified with one of these names and properties, to be used with EVP_MAC_fetch():

“BLAKE2BMAC”, “provider=default”

“BLAKE2SMAC”, “provider=default”

Supported parameters

The general description of these parameters can be found in “PARAMETERS” in EVP_MAC (3).

All these parameters (except for “block-size”) can be set with EVP_MAC_CTX_set_params(). Furthermore, the “size” parameter can be retrieved with EVP_MAC_CTX_get_params(), or with EVP_MAC_CTX_get_mac_size(). The length of the “size” parameter should not exceed that of a size_t. Likewise, the “block-size” parameter can be retrieved with EVP_MAC_CTX_get_params(), or with EVP_MAC_CTX_get_block_size().

“key” (OSSL_MAC_PARAM_KEY) <octet string>
Sets the MAC key. It may be at most 64 bytes for BLAKE2BMAC or 32 for BLAKE2SMAC and at least 1 byte in both cases. Setting this parameter is identical to passing a key to EVP_MAC_init (3).

“custom” (OSSL_MAC_PARAM_CUSTOM) <octet string>
Sets the customization/personalization string. It is an optional value of at most 16 bytes for BLAKE2BMAC or 8 for BLAKE2SMAC, and is empty by default.

“salt” (OSSL_MAC_PARAM_SALT) <octet string>
Sets the salt. It is an optional value of at most 16 bytes for BLAKE2BMAC or 8 for BLAKE2SMAC, and is empty by default.

“size” (OSSL_MAC_PARAM_SIZE) <unsigned integer>
Sets the MAC size. It can be any number between 1 and 32 for EVP_MAC_BLAKE2S or between 1 and 64 for EVP_MAC_BLAKE2B. It is 32 and 64 respectively by default.

“block-size” (OSSL_MAC_PARAM_BLOCK_SIZE) <unsigned integer>
Gets the MAC block size. It is 64 for EVP_MAC_BLAKE2S and 128 for EVP_MAC_BLAKE2B.

SEE ALSO

EVP_MAC_CTX_get_params (3), EVP_MAC_CTX_set_params (3), “PARAMETERS” in EVP_MAC (3), OSSL_PARAM (3)

HISTORY

The macros and functions described here were added to OpenSSL 3.0.

COPYRIGHT

Copyright 2018-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

466 - Linux cli command EVP_KEYMGMT-HMACssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KEYMGMT-HMACssl and provides detailed information about the command EVP_KEYMGMT-HMACssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KEYMGMT-HMACssl.

NAME 🖥️ EVP_KEYMGMT-HMACssl 🖥️

HMAC, EVP_KEYMGMT-HMAC, EVP_PKEY-Siphash, EVP_KEYMGMT-Siphash, EVP_PKEY-Poly1305, EVP_KEYMGMT-Poly1305, EVP_PKEY-CMAC, EVP_KEYMGMT-CMAC - EVP_PKEY legacy MAC keytypes and algorithm support

DESCRIPTION

The HMAC and CMAC key types are implemented in OpenSSL’s default and FIPS providers. Additionally the Siphash and Poly1305 key types are implemented in the default provider. Performing MAC operations via an EVP_PKEY is considered legacy and are only available for backwards compatibility purposes and for a restricted set of algorithms. The preferred way of performing MAC operations is via the EVP_MAC APIs. See EVP_MAC_init (3).

For further details on using EVP_PKEY based MAC keys see EVP_SIGNATURE-HMAC (7), EVP_SIGNATURE-Siphash (7), EVP_SIGNATURE-Poly1305 (7) or EVP_SIGNATURE-CMAC (7).

Common MAC parameters

All the MAC keytypes support the following parameters.

“priv” (OSSL_PKEY_PARAM_PRIV_KEY) <octet string>
The MAC key value.

“properties” (OSSL_PKEY_PARAM_PROPERTIES) <UTF8 string>
A property query string to be used when any algorithms are fetched.

CMAC parameters

As well as the parameters described above, the CMAC keytype additionally supports the following parameters.

“cipher” (OSSL_PKEY_PARAM_CIPHER) <UTF8 string>
The name of a cipher to be used when generating the MAC.

“engine” (OSSL_PKEY_PARAM_ENGINE) <UTF8 string>
The name of an engine to be used for the specified cipher (if any).

Common MAC key generation parameters

MAC key generation is unusual in that no new key is actually generated. Instead a new provider side key object is created with the supplied raw key value. This is done for backwards compatibility with previous versions of OpenSSL.

“priv” (OSSL_PKEY_PARAM_PRIV_KEY) <octet string>
The MAC key value.

CMAC key generation parameters

In addition to the common MAC key generation parameters, the CMAC key generation additionally recognises the following.

“cipher” (OSSL_PKEY_PARAM_CIPHER) <UTF8 string>
The name of a cipher to be used when generating the MAC.

SEE ALSO

EVP_KEYMGMT (3), EVP_PKEY (3), provider-keymgmt (7)

COPYRIGHT

Copyright 2020 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

467 - Linux cli command EVP_RAND-HMAC-DRBGssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_RAND-HMAC-DRBGssl and provides detailed information about the command EVP_RAND-HMAC-DRBGssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_RAND-HMAC-DRBGssl.

NAME 🖥️ EVP_RAND-HMAC-DRBGssl 🖥️

HMAC-DRBG - The HMAC DRBG EVP_RAND implementation

DESCRIPTION

Support for the HMAC deterministic random bit generator through the EVP_RAND API.

Identity

“HMAC-DRBG” is the name for this implementation; it can be used with the EVP_RAND_fetch() function.

Supported parameters

The supported parameters are:

“state” (OSSL_RAND_PARAM_STATE) <integer>

“strength” (OSSL_RAND_PARAM_STRENGTH) <unsigned integer>

“max_request” (OSSL_RAND_PARAM_MAX_REQUEST) <unsigned integer>

“reseed_requests” (OSSL_DRBG_PARAM_RESEED_REQUESTS) <unsigned integer>

“reseed_time_interval” (OSSL_DRBG_PARAM_RESEED_TIME_INTERVAL) <integer>

“min_entropylen” (OSSL_DRBG_PARAM_MIN_ENTROPYLEN) <unsigned integer>

“max_entropylen” (OSSL_DRBG_PARAM_MAX_ENTROPYLEN) <unsigned integer>

“min_noncelen” (OSSL_DRBG_PARAM_MIN_NONCELEN) <unsigned integer>

“max_noncelen” (OSSL_DRBG_PARAM_MAX_NONCELEN) <unsigned integer>

“max_perslen” (OSSL_DRBG_PARAM_MAX_PERSLEN) <unsigned integer>

“max_adinlen” (OSSL_DRBG_PARAM_MAX_ADINLEN) <unsigned integer>

“reseed_counter” (OSSL_DRBG_PARAM_RESEED_COUNTER) <unsigned integer>

“properties” (OSSL_DRBG_PARAM_PROPERTIES) <UTF8 string>

“mac” (OSSL_DRBG_PARAM_MAC) <UTF8 string>

“digest” (OSSL_DRBG_PARAM_DIGEST) <UTF8 string>

These parameters work as described in “PARAMETERS” in EVP_RAND (3).

NOTES

When using the FIPS provider, only these digests are permitted (as per FIPS 140-3 IG D.R <https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf>):

SHA-1

SHA2-256

SHA2-512

SHA3-256

SHA3-512

A context for HMAC DRBG can be obtained by calling:

EVP_RAND *rand = EVP_RAND_fetch(NULL, “HMAC-DRBG”, NULL); EVP_RAND_CTX *rctx = EVP_RAND_CTX_new(rand, NULL);

EXAMPLES

EVP_RAND *rand; EVP_RAND_CTX *rctx; unsigned char bytes[100]; OSSL_PARAM params[3], *p = params; unsigned int strength = 128; rand = EVP_RAND_fetch(NULL, “HMAC-DRBG”, NULL); rctx = EVP_RAND_CTX_new(rand, NULL); EVP_RAND_free(rand); *p++ = OSSL_PARAM_construct_utf8_string(OSSL_DRBG_PARAM_MAC, SN_hmac, 0); *p++ = OSSL_PARAM_construct_utf8_string(OSSL_DRBG_PARAM_DIGEST, SN_sha256, 0); *p = OSSL_PARAM_construct_end(); EVP_RAND_instantiate(rctx, strength, 0, NULL, 0, params); EVP_RAND_generate(rctx, bytes, sizeof(bytes), strength, 0, NULL, 0); EVP_RAND_CTX_free(rctx);

CONFORMING TO

NIST SP 800-90A and SP 800-90B

SEE ALSO

EVP_RAND (3), “PARAMETERS” in EVP_RAND (3), openssl-fipsinstall (1)

HISTORY

OpenSSL 3.1.1 introduced the -no_drbg_truncated_digests option to fipsinstall which restricts the permitted digests when using the FIPS provider in a complaint manner. For details refer to FIPS 140-3 IG D.R <https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf>).

COPYRIGHT

Copyright 2020-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

468 - Linux cli command EVP_MAC-CMACssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_MAC-CMACssl and provides detailed information about the command EVP_MAC-CMACssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_MAC-CMACssl.

NAME 🖥️ EVP_MAC-CMACssl 🖥️

CMAC - The CMAC EVP_MAC implementation

DESCRIPTION

Support for computing CMAC MACs through the EVP_MAC API.

This implementation uses EVP_CIPHER functions to get access to the underlying cipher.

Identity

This implementation is identified with this name and properties, to be used with EVP_MAC_fetch():

“CMAC”, “provider=default” or “provider=fips”

Supported parameters

The general description of these parameters can be found in “PARAMETERS” in EVP_MAC (3).

The following parameter can be set with EVP_MAC_CTX_set_params():

“key” (OSSL_MAC_PARAM_KEY) <octet string>
Sets the MAC key. Setting this parameter is identical to passing a key to EVP_MAC_init (3).

“cipher” (OSSL_MAC_PARAM_CIPHER) <UTF8 string>
Sets the name of the underlying cipher to be used. The mode of the cipher must be CBC.

“properties” (OSSL_MAC_PARAM_PROPERTIES) <UTF8 string>
Sets the properties to be queried when trying to fetch the underlying cipher. This must be given together with the cipher naming parameter to be considered valid.

The following parameters can be retrieved with EVP_MAC_CTX_get_params():

“size” (OSSL_MAC_PARAM_SIZE) <unsigned integer>
The “size” parameter can also be retrieved with with EVP_MAC_CTX_get_mac_size(). The length of the “size” parameter is equal to that of an unsigned int.

“block-size” (OSSL_MAC_PARAM_BLOCK_SIZE) <unsigned integer>
Gets the MAC block size. The “block-size” parameter can also be retrieved with EVP_MAC_CTX_get_block_size().

SEE ALSO

EVP_MAC_CTX_get_params (3), EVP_MAC_CTX_set_params (3), “PARAMETERS” in EVP_MAC (3), OSSL_PARAM (3)

COPYRIGHT

Copyright 2018-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

469 - Linux cli command ftm

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ftm and provides detailed information about the command ftm, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ftm.

NAME 🖥️ ftm 🖥️

feature test macros

DESCRIPTION

Feature test macros allow the programmer to control the definitions that are exposed by system header files when a program is compiled.

NOTE: In order to be effective, a feature test macro must be defined before including any header files. This can be done either in the compilation command (cc -DMACRO=value) or by defining the macro within the source code before including any headers. The requirement that the macro must be defined before including any header file exists because header files may freely include one another. Thus, for example, in the following lines, defining the _GNU_SOURCE macro may have no effect because the header <abc.h> itself includes <xyz.h> (POSIX explicitly allows this):

#include <abc.h>
#define _GNU_SOURCE
#include <xyz.h>

Some feature test macros are useful for creating portable applications, by preventing nonstandard definitions from being exposed. Other macros can be used to expose nonstandard definitions that are not exposed by default.

The precise effects of each of the feature test macros described below can be ascertained by inspecting the <features.h> header file. Note: applications do not need to directly include <features.h>; indeed, doing so is actively discouraged. See NOTES.

Specification of feature test macro requirements in manual pages

When a function requires that a feature test macro is defined, the manual page SYNOPSIS typically includes a note of the following form (this example from the acct(2) manual page):

#include <unistd.h>

int acct(const char *filename);

Feature Test Macro Requirements for glibc (see feature_test_macros(7)):

acct(): _BSD_SOURCE || (_XOPEN_SOURCE && _XOPEN_SOURCE < 500)

The || means that in order to obtain the declaration of acct(2) from <unistd.h>, either of the following macro definitions must be made before including any header files:

#define _BSD_SOURCE
#define _XOPEN_SOURCE        /* or any value < 500 */

Alternatively, equivalent definitions can be included in the compilation command:

cc -D_BSD_SOURCE
cc -D_XOPEN_SOURCE           # Or any value < 500

Note that, as described below, some feature test macros are defined by default, so that it may not always be necessary to explicitly specify the feature test macro(s) shown in the SYNOPSIS.

In a few cases, manual pages use a shorthand for expressing the feature test macro requirements (this example from readahead(2)):

#define _GNU_SOURCE #define _FILE_OFFSET_BITS 64 #include <fcntl.h> ssize_t readahead(int fd, off_t *offset, size_t count);

This format is employed when the feature test macros ensure that the proper function declarations are visible, and the macros are not defined by default.

Feature test macros understood by glibc

The paragraphs below explain how feature test macros are handled in glibc 2.x, x > 0.

First, though, a summary of a few details for the impatient:

  • The macros that you most likely need to use in modern source code are _POSIX_C_SOURCE (for definitions from various versions of POSIX.1), _XOPEN_SOURCE (for definitions from various versions of SUS), _GNU_SOURCE (for GNU and/or Linux specific stuff), and _DEFAULT_SOURCE (to get definitions that would normally be provided by default).

  • Certain macros are defined with default values. Thus, although one or more macros may be indicated as being required in the SYNOPSIS of a man page, it may not be necessary to define them explicitly. Full details of the defaults are given later in this man page.

  • Defining _XOPEN_SOURCE with a value of 600 or greater produces the same effects as defining _POSIX_C_SOURCE with a value of 200112L or greater. Where one sees

    _POSIX_C_SOURCE >= 200112L

    in the feature test macro requirements in the SYNOPSIS of a man page, it is implicit that the following has the same effect:

    _XOPEN_SOURCE >= 600

  • Defining _XOPEN_SOURCE with a value of 700 or greater produces the same effects as defining _POSIX_C_SOURCE with a value of 200809L or greater. Where one sees

    _POSIX_C_SOURCE >= 200809L

    in the feature test macro requirements in the SYNOPSIS of a man page, it is implicit that the following has the same effect:

    _XOPEN_SOURCE >= 700

glibc understands the following feature test macros:

__STRICT_ANSI__
ISO Standard C. This macro is implicitly defined by gcc(1) when invoked with, for example, the -std=c99 or -ansi flag.

_POSIX_C_SOURCE
Defining this macro causes header files to expose definitions as follows:

  • The value 1 exposes definitions conforming to POSIX.1-1990 and ISO C (1990).

  • The value 2 or greater additionally exposes definitions for POSIX.2-1992.

  • The value 199309L or greater additionally exposes definitions for POSIX.1b (real-time extensions).

  • The value 199506L or greater additionally exposes definitions for POSIX.1c (threads).

  • (Since glibc 2.3.3) The value 200112L or greater additionally exposes definitions corresponding to the POSIX.1-2001 base specification (excluding the XSI extension). This value also causes C95 (since glibc 2.12) and C99 (since glibc 2.10) features to be exposed (in other words, the equivalent of defining _ISOC99_SOURCE).

  • (Since glibc 2.10) The value 200809L or greater additionally exposes definitions corresponding to the POSIX.1-2008 base specification (excluding the XSI extension).

_POSIX_SOURCE
Defining this obsolete macro with any value is equivalent to defining _POSIX_C_SOURCE with the value 1.

Since this macro is obsolete, its usage is generally not documented when discussing feature test macro requirements in the man pages.

_XOPEN_SOURCE
Defining this macro causes header files to expose definitions as follows:

  • Defining with any value exposes definitions conforming to POSIX.1, POSIX.2, and XPG4.

  • The value 500 or greater additionally exposes definitions for SUSv2 (UNIX 98).

  • (Since glibc 2.2) The value 600 or greater additionally exposes definitions for SUSv3 (UNIX 03; i.e., the POSIX.1-2001 base specification plus the XSI extension) and C99 definitions.

  • (Since glibc 2.10) The value 700 or greater additionally exposes definitions for SUSv4 (i.e., the POSIX.1-2008 base specification plus the XSI extension).

If __STRICT_ANSI__ is not defined, or _XOPEN_SOURCE is defined with a value greater than or equal to 500 and neither _POSIX_SOURCE nor _POSIX_C_SOURCE is explicitly defined, then the following macros are implicitly defined:

  • _POSIX_SOURCE is defined with the value 1.

  • _POSIX_C_SOURCE is defined, according to the value of _XOPEN_SOURCE:

    _XOPEN_SOURCE < 500
    _POSIX_C_SOURCE is defined with the value 2.

    500 <= _XOPEN_SOURCE < 600
    _POSIX_C_SOURCE is defined with the value 199506L.

    600 <= _XOPEN_SOURCE < 700
    _POSIX_C_SOURCE is defined with the value 200112L.

    700 <= _XOPEN_SOURCE (since glibc 2.10)
    _POSIX_C_SOURCE is defined with the value 200809L.

In addition, defining _XOPEN_SOURCE with a value of 500 or greater produces the same effects as defining _XOPEN_SOURCE_EXTENDED.

_XOPEN_SOURCE_EXTENDED
If this macro is defined, and _XOPEN_SOURCE is defined, then expose definitions corresponding to the XPG4v2 (SUSv1) UNIX extensions (UNIX 95). Defining _XOPEN_SOURCE with a value of 500 or more also produces the same effect as defining _XOPEN_SOURCE_EXTENDED. Use of _XOPEN_SOURCE_EXTENDED in new source code should be avoided.

Since defining _XOPEN_SOURCE with a value of 500 or more has the same effect as defining _XOPEN_SOURCE_EXTENDED, the latter (obsolete) feature test macro is generally not described in the SYNOPSIS in man pages.

_ISOC99_SOURCE (since glibc 2.1.3)
Exposes declarations consistent with the ISO C99 standard.

Earlier glibc 2.1.x versions recognized an equivalent macro named _ISOC9X_SOURCE (because the C99 standard had not then been finalized). Although the use of this macro is obsolete, glibc continues to recognize it for backward compatibility.

Defining _ISOC99_SOURCE also exposes ISO C (1990) Amendment 1 (“C95”) definitions. (The primary change in C95 was support for international character sets.)

Invoking the C compiler with the option -std=c99 produces the same effects as defining this macro.

_ISOC11_SOURCE (since glibc 2.16)
Exposes declarations consistent with the ISO C11 standard. Defining this macro also enables C99 and C95 features (like _ISOC99_SOURCE).

Invoking the C compiler with the option -std=c11 produces the same effects as defining this macro.

_LARGEFILE64_SOURCE
Expose definitions for the alternative API specified by the LFS (Large File Summit) as a “transitional extension” to the Single UNIX Specification. (See .) The alternative API consists of a set of new objects (i.e., functions and types) whose names are suffixed with “64” (e.g., off64_t versus off_t, lseek64() versus lseek(), etc.). New programs should not employ this macro; instead _FILE_OFFSET_BITS=64 should be employed.

_LARGEFILE_SOURCE
This macro was historically used to expose certain functions (specifically fseeko(3) and ftello(3)) that address limitations of earlier APIs (fseek(3) and ftell(3)) that use long for file offsets. This macro is implicitly defined if _XOPEN_SOURCE is defined with a value greater than or equal to 500. New programs should not employ this macro; defining _XOPEN_SOURCE as just described or defining _FILE_OFFSET_BITS with the value 64 is the preferred mechanism to achieve the same result.

_FILE_OFFSET_BITS
Defining this macro with the value 64 automatically converts references to 32-bit functions and data types related to file I/O and filesystem operations into references to their 64-bit counterparts. This is useful for performing I/O on large files (> 2 Gigabytes) on 32-bit systems. It is also useful when calling functions like copy_file_range(2) that were added more recently and that come only in 64-bit flavors. (Defining this macro permits correctly written programs to use large files with only a recompilation being required.)

64-bit systems naturally permit file sizes greater than 2 Gigabytes, and on those systems this macro has no effect.

_TIME_BITS
Defining this macro with the value 64 changes the width of time_t(3type) to 64-bit which allows handling of timestamps beyond 2038. It is closely related to _FILE_OFFSET_BITS and depending on implementation, may require it set. This macro is available as of glibc 2.34.

_BSD_SOURCE (deprecated since glibc 2.20)
Defining this macro with any value causes header files to expose BSD-derived definitions.

In glibc versions up to and including 2.18, defining this macro also causes BSD definitions to be preferred in some situations where standards conflict, unless one or more of _SVID_SOURCE, _POSIX_SOURCE, _POSIX_C_SOURCE, _XOPEN_SOURCE, _XOPEN_SOURCE_EXTENDED, or _GNU_SOURCE is defined, in which case BSD definitions are disfavored. Since glibc 2.19, _BSD_SOURCE no longer causes BSD definitions to be preferred in case of conflicts.

Since glibc 2.20, this macro is deprecated. It now has the same effect as defining _DEFAULT_SOURCE, but generates a compile-time warning (unless _DEFAULT_SOURCE is also defined). Use _DEFAULT_SOURCE instead. To allow code that requires _BSD_SOURCE in glibc 2.19 and earlier and _DEFAULT_SOURCE in glibc 2.20 and later to compile without warnings, define both _BSD_SOURCE and _DEFAULT_SOURCE.

_SVID_SOURCE (deprecated since glibc 2.20)
Defining this macro with any value causes header files to expose System V-derived definitions. (SVID == System V Interface Definition; see standards(7).)

Since glibc 2.20, this macro is deprecated in the same fashion as _BSD_SOURCE.

_DEFAULT_SOURCE (since glibc 2.19)
This macro can be defined to ensure that the “default” definitions are provided even when the defaults would otherwise be disabled, as happens when individual macros are explicitly defined, or the compiler is invoked in one of its “standard” modes (e.g., cc -std=c99). Defining _DEFAULT_SOURCE without defining other individual macros or invoking the compiler in one of its “standard” modes has no effect.

The “default” definitions comprise those required by POSIX.1-2008 and ISO C99, as well as various definitions originally derived from BSD and System V. On glibc 2.19 and earlier, these defaults were approximately equivalent to explicitly defining the following:

cc -D_BSD_SOURCE -D_SVID_SOURCE -D_POSIX_C_SOURCE=200809

_ATFILE_SOURCE (since glibc 2.4)
Defining this macro with any value causes header files to expose declarations of a range of functions with the suffix “at”; see openat(2). Since glibc 2.10, this macro is also implicitly defined if _POSIX_C_SOURCE is defined with a value greater than or equal to 200809L.

_GNU_SOURCE
Defining this macro (with any value) implicitly defines _ATFILE_SOURCE, _LARGEFILE64_SOURCE, _ISOC99_SOURCE, _XOPEN_SOURCE_EXTENDED, _POSIX_SOURCE, _POSIX_C_SOURCE with the value 200809L (200112L before glibc 2.10; 199506L before glibc 2.5; 199309L before glibc 2.1) and _XOPEN_SOURCE with the value 700 (600 before glibc 2.10; 500 before glibc 2.2). In addition, various GNU-specific extensions are also exposed.

Since glibc 2.19, defining _GNU_SOURCE also has the effect of implicitly defining _DEFAULT_SOURCE. Before glibc 2.20, defining _GNU_SOURCE also had the effect of implicitly defining _BSD_SOURCE and _SVID_SOURCE.

_REENTRANT
Historically, on various C libraries it was necessary to define this macro in all multithreaded code. (Some C libraries may still require this.) In glibc, this macro also exposed definitions of certain reentrant functions.

However, glibc has been thread-safe by default for many years; since glibc 2.3, the only effect of defining _REENTRANT has been to enable one or two of the same declarations that are also enabled by defining _POSIX_C_SOURCE with a value of 199606L or greater.

_REENTRANT is now obsolete. In glibc 2.25 and later, defining _REENTRANT is equivalent to defining _POSIX_C_SOURCE with the value 199606L. If a higher POSIX conformance level is selected by any other means (such as _POSIX_C_SOURCE itself, _XOPEN_SOURCE, _DEFAULT_SOURCE, or _GNU_SOURCE), then defining _REENTRANT has no effect.

This macro is automatically defined if one compiles with cc -pthread.

_THREAD_SAFE
Synonym for the (deprecated) _REENTRANT, provided for compatibility with some other implementations.

_FORTIFY_SOURCE (since glibc 2.3.4)
Defining this macro causes some lightweight checks to be performed to detect some buffer overflow errors when employing various string and memory manipulation functions (for example, memcpy(3), memset(3), stpcpy(3), strcpy(3), strncpy(3), strcat(3), strncat(3), sprintf(3), snprintf(3), vsprintf(3), vsnprintf(3), gets(3), and wide character variants thereof). For some functions, argument consistency is checked; for example, a check is made that open(2) has been supplied with a mode argument when the specified flags include O_CREAT. Not all problems are detected, just some common cases.

If _FORTIFY_SOURCE is set to 1, with compiler optimization level 1 (gcc -O1) and above, checks that shouldn’t change the behavior of conforming programs are performed. With _FORTIFY_SOURCE set to 2, some more checking is added, but some conforming programs might fail.

Some of the checks can be performed at compile time (via macros logic implemented in header files), and result in compiler warnings; other checks take place at run time, and result in a run-time error if the check fails.

With _FORTIFY_SOURCE set to 3, additional checking is added to intercept some function calls used with an argument of variable size where the compiler can deduce an upper bound for its value. For example, a program where malloc(3)’s size argument is variable can now be fortified.

Use of this macro requires compiler support, available since gcc 4.0 and clang 2.6. Use of _FORTIFY_SOURCE set to 3 requires gcc 12.0 or later, or clang 9.0 or later, in conjunction with glibc 2.33 or later.

Default definitions, implicit definitions, and combining definitions

If no feature test macros are explicitly defined, then the following feature test macros are defined by default: _BSD_SOURCE (in glibc 2.19 and earlier), _SVID_SOURCE (in glibc 2.19 and earlier), _DEFAULT_SOURCE (since glibc 2.19), _POSIX_SOURCE, and _POSIX_C_SOURCE=200809L (200112L before glibc 2.10; 199506L before glibc 2.4; 199309L before glibc 2.1).

If any of __STRICT_ANSI__, _ISOC99_SOURCE, _ISOC11_SOURCE (since glibc 2.18), _POSIX_SOURCE, _POSIX_C_SOURCE, _XOPEN_SOURCE, _XOPEN_SOURCE_EXTENDED (in glibc 2.11 and earlier), _BSD_SOURCE (in glibc 2.19 and earlier), or _SVID_SOURCE (in glibc 2.19 and earlier) is explicitly defined, then _BSD_SOURCE, _SVID_SOURCE, and _DEFAULT_SOURCE are not defined by default.

If _POSIX_SOURCE and _POSIX_C_SOURCE are not explicitly defined, and either __STRICT_ANSI__ is not defined or _XOPEN_SOURCE is defined with a value of 500 or more, then

  • _POSIX_SOURCE is defined with the value 1; and

  • _POSIX_C_SOURCE is defined with one of the following values:

    • 2, if _XOPEN_SOURCE is defined with a value less than 500;

    • 199506L, if _XOPEN_SOURCE is defined with a value greater than or equal to 500 and less than 600; or

    • (since glibc 2.4) 200112L, if _XOPEN_SOURCE is defined with a value greater than or equal to 600 and less than 700.

    • (Since glibc 2.10) 200809L, if _XOPEN_SOURCE is defined with a value greater than or equal to 700.

    • Older versions of glibc do not know about the values 200112L and 200809L for _POSIX_C_SOURCE, and the setting of this macro will depend on the glibc version.

    • If _XOPEN_SOURCE is undefined, then the setting of _POSIX_C_SOURCE depends on the glibc version: 199506L, before glibc 2.4; 200112L, since glibc 2.4 to glibc 2.9; and 200809L, since glibc 2.10.

Multiple macros can be defined; the results are additive.

STANDARDS

POSIX.1 specifies _POSIX_C_SOURCE, _POSIX_SOURCE, and _XOPEN_SOURCE.

_FILE_OFFSET_BITS is not specified by any standard, but is employed on some other implementations.

_BSD_SOURCE, _SVID_SOURCE, _DEFAULT_SOURCE, _ATFILE_SOURCE, _GNU_SOURCE, _FORTIFY_SOURCE, _REENTRANT, and _THREAD_SAFE are specific to glibc.

HISTORY

_XOPEN_SOURCE_EXTENDED was specified by XPG4v2 (aka SUSv1), but is not present in SUSv2 and later.

NOTES

<features.h> is a Linux/glibc-specific header file. Other systems have an analogous file, but typically with a different name. This header file is automatically included by other header files as required: it is not necessary to explicitly include it in order to employ feature test macros.

According to which of the above feature test macros are defined, <features.h> internally defines various other macros that are checked by other glibc header files. These macros have names prefixed by two underscores (e.g., __USE_MISC). Programs should never define these macros directly: instead, the appropriate feature test macro(s) from the list above should be employed.

EXAMPLES

The program below can be used to explore how the various feature test macros are set depending on the glibc version and what feature test macros are explicitly set. The following shell session, on a system with glibc 2.10, shows some examples of what we would see:

$ cc ftm.c
$ ./a.out
_POSIX_SOURCE defined
_POSIX_C_SOURCE defined: 200809L
_BSD_SOURCE defined
_SVID_SOURCE defined
_ATFILE_SOURCE defined
$ cc -D_XOPEN_SOURCE=500 ftm.c
$ ./a.out
_POSIX_SOURCE defined
_POSIX_C_SOURCE defined: 199506L
_XOPEN_SOURCE defined: 500
$ cc -D_GNU_SOURCE ftm.c
$ ./a.out
_POSIX_SOURCE defined
_POSIX_C_SOURCE defined: 200809L
_ISOC99_SOURCE defined
_XOPEN_SOURCE defined: 700
_XOPEN_SOURCE_EXTENDED defined
_LARGEFILE64_SOURCE defined
_BSD_SOURCE defined
_SVID_SOURCE defined
_ATFILE_SOURCE defined
_GNU_SOURCE defined

Program source

/* ftm.c */
#include <stdint.h>
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
int
main(int argc, char *argv[])
{
#ifdef _POSIX_SOURCE
    printf("_POSIX_SOURCE defined

“); #endif #ifdef _POSIX_C_SOURCE printf("_POSIX_C_SOURCE defined: %jdL “, (intmax_t) _POSIX_C_SOURCE); #endif #ifdef _ISOC99_SOURCE printf("_ISOC99_SOURCE defined “); #endif #ifdef _ISOC11_SOURCE printf("_ISOC11_SOURCE defined “); #endif #ifdef _XOPEN_SOURCE printf("_XOPEN_SOURCE defined: %d “, _XOPEN_SOURCE); #endif #ifdef _XOPEN_SOURCE_EXTENDED printf("_XOPEN_SOURCE_EXTENDED defined “); #endif #ifdef _LARGEFILE64_SOURCE printf("_LARGEFILE64_SOURCE defined “); #endif #ifdef _FILE_OFFSET_BITS printf("_FILE_OFFSET_BITS defined: %d “, _FILE_OFFSET_BITS); #endif #ifdef _TIME_BITS printf("_TIME_BITS defined: %d “, _TIME_BITS); #endif #ifdef _BSD_SOURCE printf("_BSD_SOURCE defined “); #endif #ifdef _SVID_SOURCE printf("_SVID_SOURCE defined “); #endif #ifdef _DEFAULT_SOURCE printf("_DEFAULT_SOURCE defined “); #endif #ifdef _ATFILE_SOURCE printf("_ATFILE_SOURCE defined “); #endif #ifdef _GNU_SOURCE printf("_GNU_SOURCE defined “); #endif #ifdef _REENTRANT printf("_REENTRANT defined “); #endif #ifdef _THREAD_SAFE printf("_THREAD_SAFE defined “); #endif #ifdef _FORTIFY_SOURCE printf("_FORTIFY_SOURCE defined “); #endif exit(EXIT_SUCCESS); }

SEE ALSO

libc(7), standards(7), system_data_types(7)

The section “Feature Test Macros” under info libc.

/usr/include/features.h

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

470 - Linux cli command DROP_USER

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_USER and provides detailed information about the command DROP_USER, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_USER.

NAME 🖥️ DROP_USER 🖥️

remove a database role

SYNOPSIS

DROP USER [ IF EXISTS ] name [, ...]

DESCRIPTION

DROP USER is simply an alternate spelling of DROP ROLE.

COMPATIBILITY

The DROP USER statement is a PostgreSQL extension. The SQL standard leaves the definition of users to the implementation.

SEE ALSO

DROP ROLE (DROP_ROLE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

471 - Linux cli command iso-8859-14

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso-8859-14 and provides detailed information about the command iso-8859-14, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso-8859-14.

NAME 🖥️ iso-8859-14 🖥️

14 - ISO/IEC 8859-14 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-14 encodes the characters used in Celtic languages.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-14 characters

The following table displays the characters in ISO/IEC 8859-14 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-14 is also known as Latin-8.

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

472 - Linux cli command suffixes

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command suffixes and provides detailed information about the command suffixes, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the suffixes.

NAME 🖥️ suffixes 🖥️

list of file suffixes

DESCRIPTION

It is customary to indicate the contents of a file with the file suffix, which (typically) consists of a period, followed by one or more letters. Many standard utilities, such as compilers, use this to recognize the type of file they are dealing with. The make(1) utility is driven by rules based on file suffix.

Following is a list of suffixes which are likely to be found on a Linux system.

TABLE

STANDARDS

General UNIX conventions.

BUGS

This list is not exhaustive.

SEE ALSO

file(1), make(1)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

473 - Linux cli command EVP_CIPHER-RC4ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_CIPHER-RC4ssl and provides detailed information about the command EVP_CIPHER-RC4ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_CIPHER-RC4ssl.

NAME 🖥️ EVP_CIPHER-RC4ssl 🖥️

RC4 - The RC4 EVP_CIPHER implementations

DESCRIPTION

Support for RC4 symmetric encryption using the EVP_CIPHER API.

Algorithm Names

The following algorithms are available in the legacy provider:

“RC4”

“RC4-40”

“RC4-HMAC-MD5”

Parameters

This implementation supports the parameters described in “PARAMETERS” in EVP_EncryptInit (3).

SEE ALSO

provider-cipher (7), OSSL_PROVIDER-legacy (7)

COPYRIGHT

Copyright 2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

474 - Linux cli command EVP_KEYMGMT-CMACssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KEYMGMT-CMACssl and provides detailed information about the command EVP_KEYMGMT-CMACssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KEYMGMT-CMACssl.

NAME 🖥️ EVP_KEYMGMT-CMACssl 🖥️

HMAC, EVP_KEYMGMT-HMAC, EVP_PKEY-Siphash, EVP_KEYMGMT-Siphash, EVP_PKEY-Poly1305, EVP_KEYMGMT-Poly1305, EVP_PKEY-CMAC, EVP_KEYMGMT-CMAC - EVP_PKEY legacy MAC keytypes and algorithm support

DESCRIPTION

The HMAC and CMAC key types are implemented in OpenSSL’s default and FIPS providers. Additionally the Siphash and Poly1305 key types are implemented in the default provider. Performing MAC operations via an EVP_PKEY is considered legacy and are only available for backwards compatibility purposes and for a restricted set of algorithms. The preferred way of performing MAC operations is via the EVP_MAC APIs. See EVP_MAC_init (3).

For further details on using EVP_PKEY based MAC keys see EVP_SIGNATURE-HMAC (7), EVP_SIGNATURE-Siphash (7), EVP_SIGNATURE-Poly1305 (7) or EVP_SIGNATURE-CMAC (7).

Common MAC parameters

All the MAC keytypes support the following parameters.

“priv” (OSSL_PKEY_PARAM_PRIV_KEY) <octet string>
The MAC key value.

“properties” (OSSL_PKEY_PARAM_PROPERTIES) <UTF8 string>
A property query string to be used when any algorithms are fetched.

CMAC parameters

As well as the parameters described above, the CMAC keytype additionally supports the following parameters.

“cipher” (OSSL_PKEY_PARAM_CIPHER) <UTF8 string>
The name of a cipher to be used when generating the MAC.

“engine” (OSSL_PKEY_PARAM_ENGINE) <UTF8 string>
The name of an engine to be used for the specified cipher (if any).

Common MAC key generation parameters

MAC key generation is unusual in that no new key is actually generated. Instead a new provider side key object is created with the supplied raw key value. This is done for backwards compatibility with previous versions of OpenSSL.

“priv” (OSSL_PKEY_PARAM_PRIV_KEY) <octet string>
The MAC key value.

CMAC key generation parameters

In addition to the common MAC key generation parameters, the CMAC key generation additionally recognises the following.

“cipher” (OSSL_PKEY_PARAM_CIPHER) <UTF8 string>
The name of a cipher to be used when generating the MAC.

SEE ALSO

EVP_KEYMGMT (3), EVP_PKEY (3), provider-keymgmt (7)

COPYRIGHT

Copyright 2020 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

475 - Linux cli command EVP_MAC-KMACssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_MAC-KMACssl and provides detailed information about the command EVP_MAC-KMACssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_MAC-KMACssl.

NAME 🖥️ EVP_MAC-KMACssl 🖥️

KMAC, EVP_MAC-KMAC128, EVP_MAC-KMAC256 - The KMAC EVP_MAC implementations

DESCRIPTION

Support for computing KMAC MACs through the EVP_MAC API.

Identity

These implementations are identified with one of these names and properties, to be used with EVP_MAC_fetch():

“KMAC-128”, “provider=default” or “provider=fips”

“KMAC-256”, “provider=default” or “provider=fips”

Supported parameters

The general description of these parameters can be found in “PARAMETERS” in EVP_MAC (3).

All these parameters (except for “block-size”) can be set with EVP_MAC_CTX_set_params(). Furthermore, the “size” parameter can be retrieved with EVP_MAC_CTX_get_params(), or with EVP_MAC_CTX_get_mac_size(). The length of the “size” parameter should not exceed that of a size_t. Likewise, the “block-size” parameter can be retrieved with EVP_MAC_CTX_get_params(), or with EVP_MAC_CTX_get_block_size().

“key” (OSSL_MAC_PARAM_KEY) <octet string>
Sets the MAC key. Setting this parameter is identical to passing a key to EVP_MAC_init (3). The length of the key (in bytes) must be in the range 4…512.

“custom” (OSSL_MAC_PARAM_CUSTOM) <octet string>
Sets the customization string. It is an optional value with a length of at most 512 bytes, and is empty by default.

“size” (OSSL_MAC_PARAM_SIZE) <unsigned integer>
Sets the MAC size. By default, it is 32 for KMAC-128 and 64 for KMAC-256.

“block-size” (OSSL_MAC_PARAM_BLOCK_SIZE) <unsigned integer>
Gets the MAC block size. It is 168 for KMAC-128 and 136 for KMAC-256.

“xof” (OSSL_MAC_PARAM_XOF) <integer>
The “xof” parameter value is expected to be 1 or 0. Use 1 to enable XOF mode. The default value is 0.

The “custom” parameter must be set as part of or before the EVP_MAC_init() call. The “xof” and “size” parameters can be set at any time before EVP_MAC_final(). The “key” parameter is set as part of the EVP_MAC_init() call, but can be set before it instead.

EXAMPLES

#include <openssl/evp.h> #include <openssl/params.h> static int do_kmac(const unsigned char *in, size_t in_len, const unsigned char *key, size_t key_len, const unsigned char *custom, size_t custom_len, int xof_enabled, unsigned char *out, int out_len) { EVP_MAC_CTX *ctx = NULL; EVP_MAC *mac = NULL; OSSL_PARAM params[4], *p; int ret = 0; size_t l = 0; mac = EVP_MAC_fetch(NULL, “KMAC-128”, NULL); if (mac == NULL) goto err; ctx = EVP_MAC_CTX_new(mac); /* The mac can be freed after it is used by EVP_MAC_CTX_new */ EVP_MAC_free(mac); if (ctx == NULL) goto err; /* * Setup parameters required before calling EVP_MAC_init() * The parameters OSSL_MAC_PARAM_XOF and OSSL_MAC_PARAM_SIZE may also be * used at this point. */ p = params; *p++ = OSSL_PARAM_construct_octet_string(OSSL_MAC_PARAM_KEY, (void *)key, key_len); if (custom != NULL && custom_len != 0) *p++ = OSSL_PARAM_construct_octet_string(OSSL_MAC_PARAM_CUSTOM, (void *)custom, custom_len); *p = OSSL_PARAM_construct_end(); if (!EVP_MAC_CTX_set_params(ctx, params)) goto err; if (!EVP_MAC_init(ctx)) goto err; /* * Note: the following optional parameters can be set any time * before EVP_MAC_final(). */ p = params; *p++ = OSSL_PARAM_construct_int(OSSL_MAC_PARAM_XOF, &xof_enabled); *p++ = OSSL_PARAM_construct_int(OSSL_MAC_PARAM_SIZE, &out_len); *p = OSSL_PARAM_construct_end(); if (!EVP_MAC_CTX_set_params(ctx, params)) goto err; /* The update may be called multiple times here for streamed input */ if (!EVP_MAC_update(ctx, in, in_len)) goto err; if (!EVP_MAC_final(ctx, out, &l, out_len)) goto err; ret = 1; err: EVP_MAC_CTX_free(ctx); return ret; }

SEE ALSO

EVP_MAC_CTX_get_params (3), EVP_MAC_CTX_set_params (3), “PARAMETERS” in EVP_MAC (3), OSSL_PARAM (3)

COPYRIGHT

Copyright 2018-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

476 - Linux cli command ossl_store-filessl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ossl_store-filessl and provides detailed information about the command ossl_store-filessl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ossl_store-filessl.

NAME 🖥️ ossl_store-filessl 🖥️

file - The store ‘file’ scheme loader

SYNOPSIS

#include <openssl/store.h>

DESCRIPTION

Support for the ‘file’ scheme is built into libcrypto. Since files come in all kinds of formats and content types, the ‘file’ scheme has its own layer of functionality called “file handlers”, which are used to try to decode diverse types of file contents.

In case a file is formatted as PEM, each called file handler receives the PEM name (everything following any ‘-----BEGIN ’) as well as possible PEM headers, together with the decoded PEM body. Since PEM formatted files can contain more than one object, the file handlers are called upon for each such object.

If the file isn’t determined to be formatted as PEM, the content is loaded in raw form in its entirety and passed to the available file handlers as is, with no PEM name or headers.

Each file handler is expected to handle PEM and non-PEM content as appropriate. Some may refuse non-PEM content for the sake of determinism (for example, there are keys out in the wild that are represented as an ASN.1 OCTET STRING. In raw form, it’s not easily possible to distinguish those from any other data coming as an ASN.1 OCTET STRING, so such keys would naturally be accepted as PEM files only).

NOTES

When needed, the ‘file’ scheme loader will require a pass phrase by using the UI_METHOD that was passed via OSSL_STORE_open(). This pass phrase is expected to be UTF-8 encoded, anything else will give an undefined result. The files made accessible through this loader are expected to be standard compliant with regards to pass phrase encoding. Files that aren’t should be re-generated with a correctly encoded pass phrase. See passphrase-encoding (7) for more information.

SEE ALSO

ossl_store (7), passphrase-encoding (7)

COPYRIGHT

Copyright 2018 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

477 - Linux cli command DROP_MATERIALIZED_VIEW

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_MATERIALIZED_VIEW and provides detailed information about the command DROP_MATERIALIZED_VIEW, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_MATERIALIZED_VIEW.

NAME 🖥️ DROP_MATERIALIZED_VIEW 🖥️

remove a materialized view

SYNOPSIS

DROP MATERIALIZED VIEW [ IF EXISTS ] name [, ...] [ CASCADE | RESTRICT ]

DESCRIPTION

DROP MATERIALIZED VIEW drops an existing materialized view. To execute this command you must be the owner of the materialized view.

PARAMETERS

IF EXISTS

Do not throw an error if the materialized view does not exist. A notice is issued in this case.

name

The name (optionally schema-qualified) of the materialized view to remove.

CASCADE

Automatically drop objects that depend on the materialized view (such as other materialized views, or regular views), and in turn all objects that depend on those objects (see Section 5.14).

RESTRICT

Refuse to drop the materialized view if any objects depend on it. This is the default.

EXAMPLES

This command will remove the materialized view called order_summary:

DROP MATERIALIZED VIEW order_summary;

COMPATIBILITY

DROP MATERIALIZED VIEW is a PostgreSQL extension.

SEE ALSO

CREATE MATERIALIZED VIEW (CREATE_MATERIALIZED_VIEW(7)), ALTER MATERIALIZED VIEW (ALTER_MATERIALIZED_VIEW(7)), REFRESH MATERIALIZED VIEW (REFRESH_MATERIALIZED_VIEW(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

478 - Linux cli command life_cycle-cipherssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command life_cycle-cipherssl and provides detailed information about the command life_cycle-cipherssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the life_cycle-cipherssl.

NAME 🖥️ life_cycle-cipherssl 🖥️

cipher - The cipher algorithm life-cycle

DESCRIPTION

All symmetric ciphers (CIPHERs) go through a number of stages in their life-cycle:

start
This state represents the CIPHER before it has been allocated. It is the starting state for any life-cycle transitions.

newed
This state represents the CIPHER after it has been allocated.

initialised
These states represent the CIPHER when it is set up and capable of processing input. There are three possible initialised states:

initialised using EVP_CipherInit

initialised for decryption using EVP_DecryptInit

initialised for encryption using EVP_EncryptInit

updated

These states represent the CIPHER when it is set up and capable of processing additional input or generating output. The three possible states directly correspond to those for initialised above. The three different streams should not be mixed.

finaled
This state represents the CIPHER when it has generated output.

freed
This state is entered when the CIPHER is freed. It is the terminal state for all life-cycle transitions.

State Transition Diagram

The usual life-cycle of a CIPHER is illustrated: +—————————+ | | | start | | | +—————————+ + - - - - - - - - - - - - - + | ’ any of the initialised ’ | EVP_CIPHER_CTX_new ’ updated or finaled states ’ v ’ ’ +—————————+ + - - - - - - - - - - - - - + | | | | newed | | EVP_CIPHER_CTX_reset | | <—-+ +—————————+ | | | +———+ | +———+ EVP_DecryptInit | | EVP_CipherInit | EVP_EncryptInit v v v +—————————+ +—————————+ +—————————+ | | | | | | | initialised | | initialised | | initialised | | for decryption | | | | for encryption | +—————————+ +—————————+ +—————————+ | | | | EVP_DecryptUpdate | EVP_CipherUpdate EVP_EncryptUpdate | | v | | +—————————+ | | | |——————–+ | | | updated | EVP_CipherUpdate | | | | | <——————+ | v +—————————+ v +—————————+ | +—————————+ | |———————+ | | | | updated | EVP_DecryptUpdate | | | updated |——+ | for decryption | <——————-+ | | for encryption | | +—————————+ | +—————————+ | | EVP_CipherFinal | | ^ | +——-+ | +——–+ | | EVP_DecryptFinal | | | EVP_EncryptFinal +——————-+ v v v EVP_EncryptUpdate +—————————+ | |—————————–+ | finaled | | | | <—————————+ +—————————+ EVP_CIPHER_CTX_get_params | (AEAD encryption) | EVP_CIPHER_CTX_free v +—————————+ | | | freed | | | +—————————+

Formal State Transitions

This section defines all of the legal state transitions. This is the canonical list. Function Call ———————————————- Current State ———————————————– start newed initialised updated finaled initialised updated initialised updated freed decryption decryption encryption encryption EVP_CIPHER_CTX_new newed EVP_CipherInit initialised initialised initialised initialised initialised initialised initialised initialised EVP_DecryptInit initialised initialised initialised initialised initialised initialised initialised initialised decryption decryption decryption decryption decryption decryption decryption decryption EVP_EncryptInit initialised initialised initialised initialised initialised initialised initialised initialised encryption encryption encryption encryption encryption encryption encryption encryption EVP_CipherUpdate updated updated EVP_DecryptUpdate updated updated decryption decryption EVP_EncryptUpdate updated updated encryption encryption EVP_CipherFinal finaled EVP_DecryptFinal finaled EVP_EncryptFinal finaled EVP_CIPHER_CTX_free freed freed freed freed freed freed freed freed freed EVP_CIPHER_CTX_reset newed newed newed newed newed newed newed newed EVP_CIPHER_CTX_get_params newed initialised updated initialised updated initialised updated decryption decryption encryption encryption EVP_CIPHER_CTX_set_params newed initialised updated initialised updated initialised updated decryption decryption encryption encryption EVP_CIPHER_CTX_gettable_params newed initialised updated initialised updated initialised updated decryption decryption encryption encryption EVP_CIPHER_CTX_settable_params newed initialised updated initialised updated initialised updated decryption decryption encryption encryption

NOTES

At some point the EVP layer will begin enforcing the transitions described herein.

SEE ALSO

provider-cipher (7), EVP_EncryptInit (3)

COPYRIGHT

Copyright 2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

479 - Linux cli command CREATE_SUBSCRIPTION

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_SUBSCRIPTION and provides detailed information about the command CREATE_SUBSCRIPTION, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_SUBSCRIPTION.

NAME 🖥️ CREATE_SUBSCRIPTION 🖥️

define a new subscription

SYNOPSIS

CREATE SUBSCRIPTION subscription_name
    CONNECTION conninfo
    PUBLICATION publication_name [, ...]
    [ WITH ( subscription_parameter [= value] [, ... ] ) ]

DESCRIPTION

CREATE SUBSCRIPTION adds a new logical-replication subscription. The user that creates a subscription becomes the owner of the subscription. The subscription name must be distinct from the name of any existing subscription in the current database.

A subscription represents a replication connection to the publisher. Hence, in addition to adding definitions in the local catalogs, this command normally creates a replication slot on the publisher.

A logical replication worker will be started to replicate data for the new subscription at the commit of the transaction where this command is run, unless the subscription is initially disabled.

To be able to create a subscription, you must have the privileges of the the pg_create_subscription role, as well as CREATE privileges on the current database.

Additional information about subscriptions and logical replication as a whole is available at Section 31.2 and Chapter 31.

PARAMETERS

subscription_name

The name of the new subscription.

CONNECTION conninfo

The libpq connection string defining how to connect to the publisher database. For details see Section 34.1.1.

PUBLICATION publication_name [, …]

Names of the publications on the publisher to subscribe to.

WITH ( subscription_parameter [= value] [, … ] )

This clause specifies optional parameters for a subscription.

The following parameters control what happens during subscription creation:

connect (boolean)

Specifies whether the CREATE SUBSCRIPTION command should connect to the publisher at all. The default is true. Setting this to false will force the values of create_slot, enabled and copy_data to false. (You cannot combine setting connect to false with setting create_slot, enabled, or copy_data to true.)

Since no connection is made when this option is false, no tables are subscribed. To initiate replication, you must manually create the replication slot, enable the subscription, and refresh the subscription. See Section 31.2.3 for examples.

create_slot (boolean)

Specifies whether the command should create the replication slot on the publisher. The default is true.

If set to false, you are responsible for creating the publishers slot in some other way. See Section 31.2.3 for examples.

enabled (boolean)

Specifies whether the subscription should be actively replicating or whether it should just be set up but not started yet. The default is true.

slot_name (string)

Name of the publishers replication slot to use. The default is to use the name of the subscription for the slot name.

Setting slot_name to NONE means there will be no replication slot associated with the subscription. Such subscriptions must also have both enabled and create_slot set to false. Use this when you will be creating the replication slot later manually. See Section 31.2.3 for examples.

The following parameters control the subscriptions replication behavior after it has been created:

binary (boolean)

Specifies whether the subscription will request the publisher to send the data in binary format (as opposed to text). The default is false. Any initial table synchronization copy (see copy_data) also uses the same format. Binary format can be faster than the text format, but it is less portable across machine architectures and PostgreSQL versions. Binary format is very data type specific; for example, it will not allow copying from a smallint column to an integer column, even though that would work fine in text format. Even when this option is enabled, only data types having binary send and receive functions will be transferred in binary. Note that the initial synchronization requires all data types to have binary send and receive functions, otherwise the synchronization will fail (see CREATE TYPE (CREATE_TYPE(7)) for more about send/receive functions).

When doing cross-version replication, it could be that the publisher has a binary send function for some data type, but the subscriber lacks a binary receive function for that type. In such a case, data transfer will fail, and the binary option cannot be used.

If the publisher is a PostgreSQL version before 16, then any initial table synchronization will use text format even if binary = true.

copy_data (boolean)

Specifies whether to copy pre-existing data in the publications that are being subscribed to when the replication starts. The default is true.

If the publications contain WHERE clauses, it will affect what data is copied. Refer to the Notes for details.

See Notes for details of how copy_data = true can interact with the origin parameter.

streaming (enum)

Specifies whether to enable streaming of in-progress transactions for this subscription. The default value is off, meaning all transactions are fully decoded on the publisher and only then sent to the subscriber as a whole.

If set to on, the incoming changes are written to temporary files and then applied only after the transaction is committed on the publisher and received by the subscriber.

If set to parallel, incoming changes are directly applied via one of the parallel apply workers, if available. If no parallel apply worker is free to handle streaming transactions then the changes are written to temporary files and applied after the transaction is committed. Note that if an error happens in a parallel apply worker, the finish LSN of the remote transaction might not be reported in the server log.

synchronous_commit (enum)

The value of this parameter overrides the synchronous_commit setting within this subscriptions apply worker processes. The default value is off.

It is safe to use off for logical replication: If the subscriber loses transactions because of missing synchronization, the data will be sent again from the publisher.

A different setting might be appropriate when doing synchronous logical replication. The logical replication workers report the positions of writes and flushes to the publisher, and when using synchronous replication, the publisher will wait for the actual flush. This means that setting synchronous_commit for the subscriber to off when the subscription is used for synchronous replication might increase the latency for COMMIT on the publisher. In this scenario, it can be advantageous to set synchronous_commit to local or higher.

two_phase (boolean)

Specifies whether two-phase commit is enabled for this subscription. The default is false.

When two-phase commit is enabled, prepared transactions are sent to the subscriber at the time of PREPARE TRANSACTION, and are processed as two-phase transactions on the subscriber too. Otherwise, prepared transactions are sent to the subscriber only when committed, and are then processed immediately by the subscriber.

The implementation of two-phase commit requires that replication has successfully finished the initial table synchronization phase. So even when two_phase is enabled for a subscription, the internal two-phase state remains temporarily “pending” until the initialization phase completes. See column subtwophasestate of pg_subscription to know the actual two-phase state.

disable_on_error (boolean)

Specifies whether the subscription should be automatically disabled if any errors are detected by subscription workers during data replication from the publisher. The default is false.

password_required (boolean)

If set to true, connections to the publisher made as a result of this subscription must use password authentication and the password must be specified as a part of the connection string. This setting is ignored when the subscription is owned by a superuser. The default is true. Only superusers can set this value to false.

run_as_owner (boolean)

If true, all replication actions are performed as the subscription owner. If false, replication workers will perform actions on each table as the owner of that table. The latter configuration is generally much more secure; for details, see Section 31.9. The default is false.

origin (string)

Specifies whether the subscription will request the publisher to only send changes that dont have an origin or send changes regardless of origin. Setting origin to none means that the subscription will request the publisher to only send changes that dont have an origin. Setting origin to any means that the publisher sends changes regardless of their origin. The default is any.

See Notes for details of how copy_data = true can interact with the origin parameter.

When specifying a parameter of type boolean, the = value part can be omitted, which is equivalent to specifying TRUE.

NOTES

See Section 31.9 for details on how to configure access control between the subscription and the publication instance.

When creating a replication slot (the default behavior), CREATE SUBSCRIPTION cannot be executed inside a transaction block.

Creating a subscription that connects to the same database cluster (for example, to replicate between databases in the same cluster or to replicate within the same database) will only succeed if the replication slot is not created as part of the same command. Otherwise, the CREATE SUBSCRIPTION call will hang. To make this work, create the replication slot separately (using the function pg_create_logical_replication_slot with the plugin name pgoutput) and create the subscription using the parameter create_slot = false. See Section 31.2.3 for examples. This is an implementation restriction that might be lifted in a future release.

If any table in the publication has a WHERE clause, rows for which the expression evaluates to false or null will not be published. If the subscription has several publications in which the same table has been published with different WHERE clauses, a row will be published if any of the expressions (referring to that publish operation) are satisfied. In the case of different WHERE clauses, if one of the publications has no WHERE clause (referring to that publish operation) or the publication is declared as FOR ALL TABLES or FOR TABLES IN SCHEMA, rows are always published regardless of the definition of the other expressions. If the subscriber is a PostgreSQL version before 15, then any row filtering is ignored during the initial data synchronization phase. For this case, the user might want to consider deleting any initially copied data that would be incompatible with subsequent filtering. Because initial data synchronization does not take into account the publication publish parameter when copying existing table data, some rows may be copied that would not be replicated using DML. See Section 31.2.2 for examples.

Subscriptions having several publications in which the same table has been published with different column lists are not supported.

We allow non-existent publications to be specified so that users can add those later. This means pg_subscription can have non-existent publications.

When using a subscription parameter combination of copy_data = true and origin = NONE, the initial sync table data is copied directly from the publisher, meaning that knowledge of the true origin of that data is not possible. If the publisher also has subscriptions then the copied table data might have originated from further upstream. This scenario is detected and a WARNING is logged to the user, but the warning is only an indication of a potential problem; it is the users responsibility to make the necessary checks to ensure the copied data origins are really as wanted or not.

To find which tables might potentially include non-local origins (due to other subscriptions created on the publisher) try this SQL query:

substitute below with your publication name(s) to be queried

SELECT DISTINCT PT.schemaname, PT.tablename
FROM pg_publication_tables PT,
     pg_subscription_rel PS
     JOIN pg_class C ON (C.oid = PS.srrelid)
     JOIN pg_namespace N ON (N.oid = C.relnamespace)
WHERE N.nspname = PT.schemaname AND
      C.relname = PT.tablename AND
      PT.pubname IN (<pub-names>);

EXAMPLES

Create a subscription to a remote server that replicates tables in the publications mypublication and insert_only and starts replicating immediately on commit:

CREATE SUBSCRIPTION mysub CONNECTION host=192.168.1.50 port=5432 user=foo dbname=foodb PUBLICATION mypublication, insert_only;

Create a subscription to a remote server that replicates tables in the insert_only publication and does not start replicating until enabled at a later time.

CREATE SUBSCRIPTION mysub CONNECTION host=192.168.1.50 port=5432 user=foo dbname=foodb PUBLICATION insert_only WITH (enabled = false);

COMPATIBILITY

CREATE SUBSCRIPTION is a PostgreSQL extension.

SEE ALSO

ALTER SUBSCRIPTION (ALTER_SUBSCRIPTION(7)), DROP SUBSCRIPTION (DROP_SUBSCRIPTION(7)), CREATE PUBLICATION (CREATE_PUBLICATION(7)), ALTER PUBLICATION (ALTER_PUBLICATION(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

480 - Linux cli command landlock

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command landlock and provides detailed information about the command landlock, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the landlock.

NAME 🖥️ landlock 🖥️

unprivileged access-control

DESCRIPTION

Landlock is an access-control system that enables any processes to securely restrict themselves and their future children. Because Landlock is a stackable Linux Security Module (LSM), it makes it possible to create safe security sandboxes as new security layers in addition to the existing system-wide access-controls. This kind of sandbox is expected to help mitigate the security impact of bugs, and unexpected or malicious behaviors in applications.

A Landlock security policy is a set of access rights (e.g., open a file in read-only, make a directory, etc.) tied to a file hierarchy. Such policy can be configured and enforced by processes for themselves using three system calls:

  • landlock_create_ruleset(2) creates a new ruleset;

  • landlock_add_rule(2) adds a new rule to a ruleset;

  • landlock_restrict_self(2) enforces a ruleset on the calling thread.

To be able to use these system calls, the running kernel must support Landlock and it must be enabled at boot time.

Landlock rules

A Landlock rule describes an action on an object. An object is currently a file hierarchy, and the related filesystem actions are defined with access rights (see landlock_add_rule(2)). A set of rules is aggregated in a ruleset, which can then restrict the thread enforcing it, and its future children.

Filesystem actions

These flags enable to restrict a sandboxed process to a set of actions on files and directories. Files or directories opened before the sandboxing are not subject to these restrictions. See landlock_add_rule(2) and landlock_create_ruleset(2) for more context.

A file can only receive these access rights:

LANDLOCK_ACCESS_FS_EXECUTE
Execute a file.

LANDLOCK_ACCESS_FS_WRITE_FILE
Open a file with write access.

When opening files for writing, you will often additionally need the LANDLOCK_ACCESS_FS_TRUNCATE right. In many cases, these system calls truncate existing files when overwriting them (e.g., creat(2)).

LANDLOCK_ACCESS_FS_READ_FILE
Open a file with read access.

LANDLOCK_ACCESS_FS_TRUNCATE
Truncate a file with truncate(2), ftruncate(2), creat(2), or open(2) with O_TRUNC. Whether an opened file can be truncated with ftruncate(2) is determined during open(2), in the same way as read and write permissions are checked during open(2) using LANDLOCK_ACCESS_FS_READ_FILE and LANDLOCK_ACCESS_FS_WRITE_FILE. This access right is available since the third version of the Landlock ABI.

A directory can receive access rights related to files or directories. The following access right is applied to the directory itself, and the directories beneath it:

LANDLOCK_ACCESS_FS_READ_DIR
Open a directory or list its content.

However, the following access rights only apply to the content of a directory, not the directory itself:

LANDLOCK_ACCESS_FS_REMOVE_DIR
Remove an empty directory or rename one.

LANDLOCK_ACCESS_FS_REMOVE_FILE
Unlink (or rename) a file.

LANDLOCK_ACCESS_FS_MAKE_CHAR
Create (or rename or link) a character device.

LANDLOCK_ACCESS_FS_MAKE_DIR
Create (or rename) a directory.

LANDLOCK_ACCESS_FS_MAKE_REG
Create (or rename or link) a regular file.

LANDLOCK_ACCESS_FS_MAKE_SOCK
Create (or rename or link) a UNIX domain socket.

LANDLOCK_ACCESS_FS_MAKE_FIFO
Create (or rename or link) a named pipe.

LANDLOCK_ACCESS_FS_MAKE_BLOCK
Create (or rename or link) a block device.

LANDLOCK_ACCESS_FS_MAKE_SYM
Create (or rename or link) a symbolic link.

LANDLOCK_ACCESS_FS_REFER
Link or rename a file from or to a different directory (i.e., reparent a file hierarchy).

This access right is available since the second version of the Landlock ABI.

This is the only access right which is denied by default by any ruleset, even if the right is not specified as handled at ruleset creation time. The only way to make a ruleset grant this right is to explicitly allow it for a specific directory by adding a matching rule to the ruleset.

In particular, when using the first Landlock ABI version, Landlock will always deny attempts to reparent files between different directories.

In addition to the source and destination directories having the LANDLOCK_ACCESS_FS_REFER access right, the attempted link or rename operation must meet the following constraints:

  • The reparented file may not gain more access rights in the destination directory than it previously had in the source directory. If this is attempted, the operation results in an EXDEV error.

  • When linking or renaming, the LANDLOCK_ACCESS_FS_MAKE_* right for the respective file type must be granted for the destination directory. Otherwise, the operation results in an EACCES error.

  • When renaming, the LANDLOCK_ACCESS_FS_REMOVE_* right for the respective file type must be granted for the source directory. Otherwise, the operation results in an EACCES error.

If multiple requirements are not met, the EACCES error code takes precedence over EXDEV.

Layers of file path access rights

Each time a thread enforces a ruleset on itself, it updates its Landlock domain with a new layer of policy. Indeed, this complementary policy is composed with the potentially other rulesets already restricting this thread. A sandboxed thread can then safely add more constraints to itself with a new enforced ruleset.

One policy layer grants access to a file path if at least one of its rules encountered on the path grants the access. A sandboxed thread can only access a file path if all its enforced policy layers grant the access as well as all the other system access controls (e.g., filesystem DAC, other LSM policies, etc.).

Bind mounts and OverlayFS

Landlock enables restricting access to file hierarchies, which means that these access rights can be propagated with bind mounts (cf. mount_namespaces(7)) but not with OverlayFS.

A bind mount mirrors a source file hierarchy to a destination. The destination hierarchy is then composed of the exact same files, on which Landlock rules can be tied, either via the source or the destination path. These rules restrict access when they are encountered on a path, which means that they can restrict access to multiple file hierarchies at the same time, whether these hierarchies are the result of bind mounts or not.

An OverlayFS mount point consists of upper and lower layers. These layers are combined in a merge directory, result of the mount point. This merge hierarchy may include files from the upper and lower layers, but modifications performed on the merge hierarchy only reflect on the upper layer. From a Landlock policy point of view, each of the OverlayFS layers and merge hierarchies is standalone and contains its own set of files and directories, which is different from a bind mount. A policy restricting an OverlayFS layer will not restrict the resulted merged hierarchy, and vice versa. Landlock users should then only think about file hierarchies they want to allow access to, regardless of the underlying filesystem.

Inheritance

Every new thread resulting from a clone(2) inherits Landlock domain restrictions from its parent. This is similar to the seccomp(2) inheritance or any other LSM dealing with tasks’ credentials(7). For instance, one process’s thread may apply Landlock rules to itself, but they will not be automatically applied to other sibling threads (unlike POSIX thread credential changes, cf. nptl(7)).

When a thread sandboxes itself, we have the guarantee that the related security policy will stay enforced on all this thread’s descendants. This allows creating standalone and modular security policies per application, which will automatically be composed between themselves according to their run-time parent policies.

Ptrace restrictions

A sandboxed process has less privileges than a non-sandboxed process and must then be subject to additional restrictions when manipulating another process. To be allowed to use ptrace(2) and related syscalls on a target process, a sandboxed process should have a subset of the target process rules, which means the tracee must be in a sub-domain of the tracer.

Truncating files

The operations covered by LANDLOCK_ACCESS_FS_WRITE_FILE and LANDLOCK_ACCESS_FS_TRUNCATE both change the contents of a file and sometimes overlap in non-intuitive ways. It is recommended to always specify both of these together.

A particularly surprising example is creat(2). The name suggests that this system call requires the rights to create and write files. However, it also requires the truncate right if an existing file under the same name is already present.

It should also be noted that truncating files does not require the LANDLOCK_ACCESS_FS_WRITE_FILE right. Apart from the truncate(2) system call, this can also be done through open(2) with the flags O_RDONLY | O_TRUNC.

When opening a file, the availability of the LANDLOCK_ACCESS_FS_TRUNCATE right is associated with the newly created file descriptor and will be used for subsequent truncation attempts using ftruncate(2). The behavior is similar to opening a file for reading or writing, where permissions are checked during open(2), but not during the subsequent read(2) and write(2) calls.

As a consequence, it is possible to have multiple open file descriptors for the same file, where one grants the right to truncate the file and the other does not. It is also possible to pass such file descriptors between processes, keeping their Landlock properties, even when these processes do not have an enforced Landlock ruleset.

VERSIONS

Landlock was introduced in Linux 5.13.

To determine which Landlock features are available, users should query the Landlock ABI version:

ABIKernelNewly introduced access rights
___
15.13LANDLOCK_ACCESS_FS_EXECUTE
  LANDLOCK_ACCESS_FS_WRITE_FILE
  LANDLOCK_ACCESS_FS_READ_FILE
  LANDLOCK_ACCESS_FS_READ_DIR
  LANDLOCK_ACCESS_FS_REMOVE_DIR
  LANDLOCK_ACCESS_FS_REMOVE_FILE
  LANDLOCK_ACCESS_FS_MAKE_CHAR
  LANDLOCK_ACCESS_FS_MAKE_DIR
  LANDLOCK_ACCESS_FS_MAKE_REG
  LANDLOCK_ACCESS_FS_MAKE_SOCK
  LANDLOCK_ACCESS_FS_MAKE_FIFO
  LANDLOCK_ACCESS_FS_MAKE_BLOCK
  LANDLOCK_ACCESS_FS_MAKE_SYM
___
25.19LANDLOCK_ACCESS_FS_REFER
___
36.2LANDLOCK_ACCESS_FS_TRUNCATE

Users should use the Landlock ABI version rather than the kernel version to determine which features are available. The mainline kernel versions listed here are only included for orientation. Kernels from other sources may contain backported features, and their version numbers may not match.

To query the running kernel’s Landlock ABI version, programs may pass the LANDLOCK_CREATE_RULESET_VERSION flag to landlock_create_ruleset(2).

When building fallback mechanisms for compatibility with older kernels, users are advised to consider the special semantics of the LANDLOCK_ACCESS_FS_REFER access right: In ABI v1, linking and moving of files between different directories is always forbidden, so programs relying on such operations are only compatible with Landlock ABI v2 and higher.

NOTES

Landlock is enabled by CONFIG_SECURITY_LANDLOCK. The lsm=lsm1,…,lsmN command line parameter controls the sequence of the initialization of Linux Security Modules. It must contain the string landlock to enable Landlock. If the command line parameter is not specified, the initialization falls back to the value of the deprecated security= command line parameter and further to the value of CONFIG_LSM. We can check that Landlock is enabled by looking for landlock: Up and running. in kernel logs.

CAVEATS

It is currently not possible to restrict some file-related actions accessible through these system call families: chdir(2), stat(2), flock(2), chmod(2), chown(2), setxattr(2), utime(2), ioctl(2), fcntl(2), access(2). Future Landlock evolutions will enable to restrict them.

EXAMPLES

We first need to create the ruleset that will contain our rules.

For this example, the ruleset will contain rules that only allow read actions, but write actions will be denied. The ruleset then needs to handle both of these kinds of actions. See the DESCRIPTION section for the description of filesystem actions.

struct landlock_ruleset_attr attr = {0};
int ruleset_fd;
attr.handled_access_fs =
        LANDLOCK_ACCESS_FS_EXECUTE |
        LANDLOCK_ACCESS_FS_WRITE_FILE |
        LANDLOCK_ACCESS_FS_READ_FILE |
        LANDLOCK_ACCESS_FS_READ_DIR |
        LANDLOCK_ACCESS_FS_REMOVE_DIR |
        LANDLOCK_ACCESS_FS_REMOVE_FILE |
        LANDLOCK_ACCESS_FS_MAKE_CHAR |
        LANDLOCK_ACCESS_FS_MAKE_DIR |
        LANDLOCK_ACCESS_FS_MAKE_REG |
        LANDLOCK_ACCESS_FS_MAKE_SOCK |
        LANDLOCK_ACCESS_FS_MAKE_FIFO |
        LANDLOCK_ACCESS_FS_MAKE_BLOCK |
        LANDLOCK_ACCESS_FS_MAKE_SYM |
        LANDLOCK_ACCESS_FS_REFER |
        LANDLOCK_ACCESS_FS_TRUNCATE;

To be compatible with older Linux versions, we detect the available Landlock ABI version, and only use the available subset of access rights:

/*
 * Table of available file system access rights by ABI version,
 * numbers hardcoded to keep the example short.
 */
__u64 landlock_fs_access_rights[] = {
    (LANDLOCK_ACCESS_FS_MAKE_SYM << 1) - 1,  /* v1                 */
    (LANDLOCK_ACCESS_FS_REFER    << 1) - 1,  /* v2: add "refer"    */
    (LANDLOCK_ACCESS_FS_TRUNCATE << 1) - 1,  /* v3: add "truncate" */
};
int abi = landlock_create_ruleset(NULL, 0,
                                  LANDLOCK_CREATE_RULESET_VERSION);
if (abi == -1) {
    /*
     * Kernel too old, not compiled with Landlock,
     * or Landlock was not enabled at boot time.
     */
    perror("Unable to use Landlock");
    return;  /* Graceful fallback: Do nothing. */
}
abi = MIN(abi, 3);
/* Only use the available rights in the ruleset. */
attr.handled_access_fs &= landlock_fs_access_rights[abi - 1];

The available access rights for each ABI version are listed in the VERSIONS section.

If our program needed to create hard links or rename files between different directories (LANDLOCK_ACCESS_FS_REFER), we would require the following change to the backwards compatibility logic: Directory reparenting is not possible in a process restricted with Landlock ABI version 1. Therefore, if the program needed to do file reparenting, and if only Landlock ABI version 1 was available, we could not restrict the process.

Now that the ruleset attributes are determined, we create the Landlock ruleset and acquire a file descriptor as a handle to it, using landlock_create_ruleset(2):

ruleset_fd = landlock_create_ruleset(&attr, sizeof(attr), 0);
if (ruleset_fd == -1) {
    perror("Failed to create a ruleset");
    exit(EXIT_FAILURE);
}

We can now add a new rule to the ruleset through the ruleset’s file descriptor. The requested access rights must be a subset of the access rights which were specified in attr.handled_access_fs at ruleset creation time.

In this example, the rule will only allow reading the file hierarchy /usr. Without another rule, write actions would then be denied by the ruleset. To add /usr to the ruleset, we open it with the O_PATH flag and fill the struct landlock_path_beneath_attr with this file descriptor.

struct landlock_path_beneath_attr path_beneath = {0};
int err;
path_beneath.allowed_access =
        LANDLOCK_ACCESS_FS_EXECUTE |
        LANDLOCK_ACCESS_FS_READ_FILE |
        LANDLOCK_ACCESS_FS_READ_DIR;
path_beneath.parent_fd = open("/usr", O_PATH | O_CLOEXEC);
if (path_beneath.parent_fd == -1) {
    perror("Failed to open file");
    close(ruleset_fd);
    exit(EXIT_FAILURE);
}
err = landlock_add_rule(ruleset_fd, LANDLOCK_RULE_PATH_BENEATH,
                        &path_beneath, 0);
close(path_beneath.parent_fd);
if (err) {
    perror("Failed to update ruleset");
    close(ruleset_fd);
    exit(EXIT_FAILURE);
}

We now have a ruleset with one rule allowing read access to /usr while denying all other handled accesses for the filesystem. The next step is to restrict the current thread from gaining more privileges (e.g., thanks to a set-user-ID binary).

if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)) {
    perror("Failed to restrict privileges");
    close(ruleset_fd);
    exit(EXIT_FAILURE);
}

The current thread is now ready to sandbox itself with the ruleset.

if (landlock_restrict_self(ruleset_fd, 0)) {
    perror("Failed to enforce ruleset");
    close(ruleset_fd);
    exit(EXIT_FAILURE);
}
close(ruleset_fd);

If the landlock_restrict_self(2) system call succeeds, the current thread is now restricted and this policy will be enforced on all its subsequently created children as well. Once a thread is landlocked, there is no way to remove its security policy; only adding more restrictions is allowed. These threads are now in a new Landlock domain, merge of their parent one (if any) with the new ruleset.

Full working code can be found in

SEE ALSO

landlock_create_ruleset(2), landlock_add_rule(2), landlock_restrict_self(2)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

481 - Linux cli command biossl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command biossl and provides detailed information about the command biossl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the biossl.

NAME 🖥️ biossl 🖥️

Basic I/O abstraction

SYNOPSIS

#include <openssl/bio.h>

DESCRIPTION

A BIO is an I/O abstraction, it hides many of the underlying I/O details from an application. If an application uses a BIO for its I/O it can transparently handle SSL connections, unencrypted network connections and file I/O.

There are two types of BIO, a source/sink BIO and a filter BIO.

As its name implies a source/sink BIO is a source and/or sink of data, examples include a socket BIO and a file BIO.

A filter BIO takes data from one BIO and passes it through to another, or the application. The data may be left unmodified (for example a message digest BIO) or translated (for example an encryption BIO). The effect of a filter BIO may change according to the I/O operation it is performing: for example an encryption BIO will encrypt data if it is being written to and decrypt data if it is being read from.

BIOs can be joined together to form a chain (a single BIO is a chain with one component). A chain normally consists of one source/sink BIO and one or more filter BIOs. Data read from or written to the first BIO then traverses the chain to the end (normally a source/sink BIO).

Some BIOs (such as memory BIOs) can be used immediately after calling BIO_new(). Others (such as file BIOs) need some additional initialization, and frequently a utility function exists to create and initialize such BIOs.

If BIO_free() is called on a BIO chain it will only free one BIO resulting in a memory leak.

Calling BIO_free_all() on a single BIO has the same effect as calling BIO_free() on it other than the discarded return value.

Normally the type argument is supplied by a function which returns a pointer to a BIO_METHOD. There is a naming convention for such functions: a source/sink BIO typically starts with BIO_s_ and a filter BIO with BIO_f_.

TCP Fast Open

TCP Fast Open (RFC7413), abbreviated “TFO”, is supported by the BIO interface since OpenSSL 3.2. TFO is supported in the following operating systems:

  • Linux kernel 3.13 and later, where TFO is enabled by default.

  • Linux kernel 4.11 and later, using TCP_FASTOPEN_CONNECT.

  • FreeBSD 10.3 to 11.4, supports server TFO only.

  • FreeBSD 12.0 and later, supports both client and server TFO.

  • macOS 10.14 and later.

Each operating system has a slightly different API for TFO. Please refer to the operating systems’ API documentation when using sockets directly.

EXAMPLES

Create a memory BIO:

BIO *mem = BIO_new(BIO_s_mem());

SEE ALSO

BIO_ctrl (3), BIO_f_base64 (3), BIO_f_buffer (3), BIO_f_cipher (3), BIO_f_md (3), BIO_f_null (3), BIO_f_ssl (3), BIO_f_readbuffer (3), BIO_find_type (3), BIO_get_conn_mode (3), BIO_new (3), BIO_new_bio_pair (3), BIO_push (3), BIO_read_ex (3), BIO_s_accept (3), BIO_s_bio (3), BIO_s_connect (3), BIO_s_fd (3), BIO_s_file (3), BIO_s_mem (3), BIO_s_null (3), BIO_s_socket (3), BIO_set_callback (3), BIO_set_conn_mode (3), BIO_set_tfo (3), BIO_set_tfo_accept (3), BIO_should_retry (3)

COPYRIGHT

Copyright 2000-2022 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

482 - Linux cli command debuginfod-client-config

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command debuginfod-client-config and provides detailed information about the command debuginfod-client-config, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the debuginfod-client-config.

NAME 🖥️ debuginfod-client-config 🖥️

client-config - debuginfod client environment variables, cache control files and etc.

SYNOPSIS

Several environment variables and control files control the behaviour of debuginfod client applications.

ENVIRONMENT VARIABLES

$TMPDIR
This environment variable points to a file system to be used for temporary files. The default is /tmp.

$DEBUGINFOD_URLS
This environment variable contains a list of URL prefixes for trusted debuginfod instances. Alternate URL prefixes are separated by space. This environment variable may be set by /etc/profile.d scripts reading /etc/debuginfod/*.urls files.

$DEBUGINFOD_CACHE_PATH
This environment variable governs the location of the cache where downloaded files and cache-control files are kept. The default directory is chosen based on other environment variables, see below.

$DEBUGINFOD_PROGRESS
This environment variable governs the default progress function. If set, and if a progressfn is not explicitly set, then the library will configure a default progressfn. This function will append a simple progress message periodically to stderr. The default is no progress function output.

$DEBUGINFOD_VERBOSE
This environment variable governs the default file descriptor for verbose output. If set, and if a verbose fd is not explicitly set, then the verbose output will be produced on STDERR_FILENO.

$DEBUGINFOD_RETRY_LIMIT
This environment variable governs the default limit of retry attempts. If a query failed with errno other than ENOENT, will initiate several attempts within the limit.

$DEBUGINFOD_TIMEOUT
This environment variable governs the download commencing timeout for each debuginfod HTTP connection. A server that fails to provide at least 100K of data within this many seconds is skipped. The default is 90 seconds. (Zero or negative means “no timeout”.)

$DEBUGINFOD_MAXTIME
This environment variable dictates how long the client will wait to complete the download a file found on a server in seconds. It is best used to ensure that a file is downloaded quickly or be rejected. The default is 0 (infinite time).

$DEBUGINFOD_MAXSIZE
This environment variable dictates the maximum size of a file to download in bytes. This is best used if the user would like to ensure only small files are downloaded. A value of 0 causes no consideration for size, and the client may attempt to download a file of any size. The default is 0 (infinite size).

$DEBUGINFOD_HEADERS_FILE
This environment variable points to a file that supplies headers to outbound HTTP requests, one per line. The header lines shouldn’t end with CRLF, unless that’s the system newline convention. Whitespace-only lines are skipped.

CACHE

Before each query, the debuginfod client library checks for a need to clean the cache. If it’s time to clean, the library traverses the cache directory and removes downloaded debuginfo-related artifacts and newly empty directories, if they have not been accessed recently.

Control files are located directly under the cache directory. They contain simple decimal numbers to set cache-related configuration parameters. If the files do not exist, the client library creates the files with the default parameter values as content.

After each query, the debuginfod client library deposits newly received files into a directory & file that is named based on the build-id. A failed query is also cached by a special file. The naming convention used for these artifacts is deliberately undocumented.

$XDG_CACHE_HOME/debuginfod_client/
Default cache directory, if $XDG_CACHE_HOME is set.

$HOME/.cache/debuginfod_client/
Default cache directory, if $XDG_CACHE_HOME is not set.

$HOME/.debuginfod_client_cache/
Deprecated cache directory, used only if preexisting.

cache_clean_interval_s
This control file gives the interval between cache cleaning rounds, in seconds. The default is 86400, one day. 0 means “immediately”.

max_unused_age_s
This control file sets how long unaccessed debuginfo-related files are retained, in seconds. The default is 604800, one week. 0 means “immediately”.

cache_miss_s
This control file sets how long to remember a query failure, in seconds. New queries for the same artifacts within this time window are short-circuited (returning an immediate failure instead of sending a new query to servers). This accelerates queries that probably would still fail. The default is 600, 10 minutes. 0 means “forget immediately”.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

483 - Linux cli command iso-8859-13

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso-8859-13 and provides detailed information about the command iso-8859-13, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso-8859-13.

NAME 🖥️ iso-8859-13 🖥️

13 - ISO/IEC 8859-13 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-13 encodes the characters used in Baltic Rim languages.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-13 characters

The following table displays the characters in ISO/IEC 8859-13 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-13 is also known as Latin-7.

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

484 - Linux cli command SET_TRANSACTION

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command SET_TRANSACTION and provides detailed information about the command SET_TRANSACTION, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the SET_TRANSACTION.

NAME 🖥️ SET_TRANSACTION 🖥️

set the characteristics of the current transaction

SYNOPSIS

SET TRANSACTION transaction_mode [, ...]
SET TRANSACTION SNAPSHOT snapshot_id
SET SESSION CHARACTERISTICS AS TRANSACTION transaction_mode [, ...]

where transaction_mode is one of:

    ISOLATION LEVEL { SERIALIZABLE | REPEATABLE READ | READ COMMITTED | READ UNCOMMITTED }
    READ WRITE | READ ONLY
    [ NOT ] DEFERRABLE

DESCRIPTION

The SET TRANSACTION command sets the characteristics of the current transaction. It has no effect on any subsequent transactions. SET SESSION CHARACTERISTICS sets the default transaction characteristics for subsequent transactions of a session. These defaults can be overridden by SET TRANSACTION for an individual transaction.

The available transaction characteristics are the transaction isolation level, the transaction access mode (read/write or read-only), and the deferrable mode. In addition, a snapshot can be selected, though only for the current transaction, not as a session default.

The isolation level of a transaction determines what data the transaction can see when other transactions are running concurrently:

READ COMMITTED

A statement can only see rows committed before it began. This is the default.

REPEATABLE READ

All statements of the current transaction can only see rows committed before the first query or data-modification statement was executed in this transaction.

SERIALIZABLE

All statements of the current transaction can only see rows committed before the first query or data-modification statement was executed in this transaction. If a pattern of reads and writes among concurrent serializable transactions would create a situation which could not have occurred for any serial (one-at-a-time) execution of those transactions, one of them will be rolled back with a serialization_failure error.

The SQL standard defines one additional level, READ UNCOMMITTED. In PostgreSQL READ UNCOMMITTED is treated as READ COMMITTED.

The transaction isolation level cannot be changed after the first query or data-modification statement (SELECT, INSERT, DELETE, UPDATE, MERGE, FETCH, or COPY) of a transaction has been executed. See Chapter 13 for more information about transaction isolation and concurrency control.

The transaction access mode determines whether the transaction is read/write or read-only. Read/write is the default. When a transaction is read-only, the following SQL commands are disallowed: INSERT, UPDATE, DELETE, MERGE, and COPY FROM if the table they would write to is not a temporary table; all CREATE, ALTER, and DROP commands; COMMENT, GRANT, REVOKE, TRUNCATE; and EXPLAIN ANALYZE and EXECUTE if the command they would execute is among those listed. This is a high-level notion of read-only that does not prevent all writes to disk.

The DEFERRABLE transaction property has no effect unless the transaction is also SERIALIZABLE and READ ONLY. When all three of these properties are selected for a transaction, the transaction may block when first acquiring its snapshot, after which it is able to run without the normal overhead of a SERIALIZABLE transaction and without any risk of contributing to or being canceled by a serialization failure. This mode is well suited for long-running reports or backups.

The SET TRANSACTION SNAPSHOT command allows a new transaction to run with the same snapshot as an existing transaction. The pre-existing transaction must have exported its snapshot with the pg_export_snapshot function (see Section 9.27.5). That function returns a snapshot identifier, which must be given to SET TRANSACTION SNAPSHOT to specify which snapshot is to be imported. The identifier must be written as a string literal in this command, for example 00000003-0000001B-1. SET TRANSACTION SNAPSHOT can only be executed at the start of a transaction, before the first query or data-modification statement (SELECT, INSERT, DELETE, UPDATE, MERGE, FETCH, or COPY) of the transaction. Furthermore, the transaction must already be set to SERIALIZABLE or REPEATABLE READ isolation level (otherwise, the snapshot would be discarded immediately, since READ COMMITTED mode takes a new snapshot for each command). If the importing transaction uses SERIALIZABLE isolation level, then the transaction that exported the snapshot must also use that isolation level. Also, a non-read-only serializable transaction cannot import a snapshot from a read-only transaction.

NOTES

If SET TRANSACTION is executed without a prior START TRANSACTION or BEGIN, it emits a warning and otherwise has no effect.

It is possible to dispense with SET TRANSACTION by instead specifying the desired transaction_modes in BEGIN or START TRANSACTION. But that option is not available for SET TRANSACTION SNAPSHOT.

The session default transaction modes can also be set or examined via the configuration parameters default_transaction_isolation, default_transaction_read_only, and default_transaction_deferrable. (In fact SET SESSION CHARACTERISTICS is just a verbose equivalent for setting these variables with SET.) This means the defaults can be set in the configuration file, via ALTER DATABASE, etc. Consult Chapter 20 for more information.

The current transactions modes can similarly be set or examined via the configuration parameters transaction_isolation, transaction_read_only, and transaction_deferrable. Setting one of these parameters acts the same as the corresponding SET TRANSACTION option, with the same restrictions on when it can be done. However, these parameters cannot be set in the configuration file, or from any source other than live SQL.

EXAMPLES

To begin a new transaction with the same snapshot as an already existing transaction, first export the snapshot from the existing transaction. That will return the snapshot identifier, for example:

BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ; SELECT pg_export_snapshot(); pg_export_snapshot ——————— 00000003-0000001B-1 (1 row)

Then give the snapshot identifier in a SET TRANSACTION SNAPSHOT command at the beginning of the newly opened transaction:

BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ; SET TRANSACTION SNAPSHOT 00000003-0000001B-1;

COMPATIBILITY

These commands are defined in the SQL standard, except for the DEFERRABLE transaction mode and the SET TRANSACTION SNAPSHOT form, which are PostgreSQL extensions.

SERIALIZABLE is the default transaction isolation level in the standard. In PostgreSQL the default is ordinarily READ COMMITTED, but you can change it as mentioned above.

In the SQL standard, there is one other transaction characteristic that can be set with these commands: the size of the diagnostics area. This concept is specific to embedded SQL, and therefore is not implemented in the PostgreSQL server.

The SQL standard requires commas between successive transaction_modes, but for historical reasons PostgreSQL allows the commas to be omitted.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

485 - Linux cli command nptl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command nptl and provides detailed information about the command nptl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the nptl.

NAME 🖥️ nptl 🖥️

Native POSIX Threads Library

DESCRIPTION

NPTL (Native POSIX Threads Library) is the GNU C library POSIX threads implementation that is used on modern Linux systems.

NPTL and signals

NPTL makes internal use of the first two real-time signals (signal numbers 32 and 33). One of these signals is used to support thread cancelation and POSIX timers (see timer_create(2)); the other is used as part of a mechanism that ensures all threads in a process always have the same UIDs and GIDs, as required by POSIX. These signals cannot be used in applications.

To prevent accidental use of these signals in applications, which might interfere with the operation of the NPTL implementation, various glibc library functions and system call wrapper functions attempt to hide these signals from applications, as follows:

  • SIGRTMIN is defined with the value 34 (rather than 32).

  • The sigwaitinfo(2), sigtimedwait(2), and sigwait(3) interfaces silently ignore requests to wait for these two signals if they are specified in the signal set argument of these calls.

  • The sigprocmask(2) and pthread_sigmask(3) interfaces silently ignore attempts to block these two signals.

  • The sigaction(2), pthread_kill(3), and pthread_sigqueue(3) interfaces fail with the error EINVAL (indicating an invalid signal number) if these signals are specified.

  • sigfillset(3) does not include these two signals when it creates a full signal set.

NPTL and process credential changes

At the Linux kernel level, credentials (user and group IDs) are a per-thread attribute. However, POSIX requires that all of the POSIX threads in a process have the same credentials. To accommodate this requirement, the NPTL implementation wraps all of the system calls that change process credentials with functions that, in addition to invoking the underlying system call, arrange for all other threads in the process to also change their credentials.

The implementation of each of these system calls involves the use of a real-time signal that is sent (using tgkill(2)) to each of the other threads that must change its credentials. Before sending these signals, the thread that is changing credentials saves the new credential(s) and records the system call being employed in a global buffer. A signal handler in the receiving thread(s) fetches this information and then uses the same system call to change its credentials.

Wrapper functions employing this technique are provided for setgid(2), setuid(2), setegid(2), seteuid(2), setregid(2), setreuid(2), setresgid(2), setresuid(2), and setgroups(2).

STANDARDS

For details of the conformance of NPTL to the POSIX standard, see pthreads(7).

NOTES

POSIX says that any thread in any process with access to the memory containing a process-shared (PTHREAD_PROCESS_SHARED) mutex can operate on that mutex. However, on 64-bit x86 systems, the mutex definition for x86-64 is incompatible with the mutex definition for i386, meaning that 32-bit and 64-bit binaries can’t share mutexes on x86-64 systems.

SEE ALSO

credentials(7), pthreads(7), signal(7), standards(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

486 - Linux cli command cgroups

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command cgroups and provides detailed information about the command cgroups, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the cgroups.

NAME 🖥️ cgroups 🖥️

Linux control groups

DESCRIPTION

Control groups, usually referred to as cgroups, are a Linux kernel feature which allow processes to be organized into hierarchical groups whose usage of various types of resources can then be limited and monitored. The kernel’s cgroup interface is provided through a pseudo-filesystem called cgroupfs. Grouping is implemented in the core cgroup kernel code, while resource tracking and limits are implemented in a set of per-resource-type subsystems (memory, CPU, and so on).

Terminology

A cgroup is a collection of processes that are bound to a set of limits or parameters defined via the cgroup filesystem.

A subsystem is a kernel component that modifies the behavior of the processes in a cgroup. Various subsystems have been implemented, making it possible to do things such as limiting the amount of CPU time and memory available to a cgroup, accounting for the CPU time used by a cgroup, and freezing and resuming execution of the processes in a cgroup. Subsystems are sometimes also known as resource controllers (or simply, controllers).

The cgroups for a controller are arranged in a hierarchy. This hierarchy is defined by creating, removing, and renaming subdirectories within the cgroup filesystem. At each level of the hierarchy, attributes (e.g., limits) can be defined. The limits, control, and accounting provided by cgroups generally have effect throughout the subhierarchy underneath the cgroup where the attributes are defined. Thus, for example, the limits placed on a cgroup at a higher level in the hierarchy cannot be exceeded by descendant cgroups.

Cgroups version 1 and version 2

The initial release of the cgroups implementation was in Linux 2.6.24. Over time, various cgroup controllers have been added to allow the management of various types of resources. However, the development of these controllers was largely uncoordinated, with the result that many inconsistencies arose between controllers and management of the cgroup hierarchies became rather complex. A longer description of these problems can be found in the kernel source file Documentation/admin-guide/cgroup-v2.rst (or Documentation/cgroup-v2.txt in Linux 4.17 and earlier).

Because of the problems with the initial cgroups implementation (cgroups version 1), starting in Linux 3.10, work began on a new, orthogonal implementation to remedy these problems. Initially marked experimental, and hidden behind the -o __DEVEL__sane_behavior mount option, the new version (cgroups version 2) was eventually made official with the release of Linux 4.5. Differences between the two versions are described in the text below. The file cgroup.sane_behavior, present in cgroups v1, is a relic of this mount option. The file always reports “0” and is only retained for backward compatibility.

Although cgroups v2 is intended as a replacement for cgroups v1, the older system continues to exist (and for compatibility reasons is unlikely to be removed). Currently, cgroups v2 implements only a subset of the controllers available in cgroups v1. The two systems are implemented so that both v1 controllers and v2 controllers can be mounted on the same system. Thus, for example, it is possible to use those controllers that are supported under version 2, while also using version 1 controllers where version 2 does not yet support those controllers. The only restriction here is that a controller can’t be simultaneously employed in both a cgroups v1 hierarchy and in the cgroups v2 hierarchy.

CGROUPS VERSION 1

Under cgroups v1, each controller may be mounted against a separate cgroup filesystem that provides its own hierarchical organization of the processes on the system. It is also possible to comount multiple (or even all) cgroups v1 controllers against the same cgroup filesystem, meaning that the comounted controllers manage the same hierarchical organization of processes.

For each mounted hierarchy, the directory tree mirrors the control group hierarchy. Each control group is represented by a directory, with each of its child control cgroups represented as a child directory. For instance, /user/joe/1.session represents control group 1.session, which is a child of cgroup joe, which is a child of /user. Under each cgroup directory is a set of files which can be read or written to, reflecting resource limits and a few general cgroup properties.

Tasks (threads) versus processes

In cgroups v1, a distinction is drawn between processes and tasks. In this view, a process can consist of multiple tasks (more commonly called threads, from a user-space perspective, and called such in the remainder of this man page). In cgroups v1, it is possible to independently manipulate the cgroup memberships of the threads in a process.

The cgroups v1 ability to split threads across different cgroups caused problems in some cases. For example, it made no sense for the memory controller, since all of the threads of a process share a single address space. Because of these problems, the ability to independently manipulate the cgroup memberships of the threads in a process was removed in the initial cgroups v2 implementation, and subsequently restored in a more limited form (see the discussion of “thread mode” below).

Mounting v1 controllers

The use of cgroups requires a kernel built with the CONFIG_CGROUP option. In addition, each of the v1 controllers has an associated configuration option that must be set in order to employ that controller.

In order to use a v1 controller, it must be mounted against a cgroup filesystem. The usual place for such mounts is under a tmpfs(5) filesystem mounted at /sys/fs/cgroup. Thus, one might mount the cpu controller as follows:

mount -t cgroup -o cpu none /sys/fs/cgroup/cpu

It is possible to comount multiple controllers against the same hierarchy. For example, here the cpu and cpuacct controllers are comounted against a single hierarchy:

mount -t cgroup -o cpu,cpuacct none /sys/fs/cgroup/cpu,cpuacct

Comounting controllers has the effect that a process is in the same cgroup for all of the comounted controllers. Separately mounting controllers allows a process to be in cgroup /foo1 for one controller while being in /foo2/foo3 for another.

It is possible to comount all v1 controllers against the same hierarchy:

mount -t cgroup -o all cgroup /sys/fs/cgroup

(One can achieve the same result by omitting -o all, since it is the default if no controllers are explicitly specified.)

It is not possible to mount the same controller against multiple cgroup hierarchies. For example, it is not possible to mount both the cpu and cpuacct controllers against one hierarchy, and to mount the cpu controller alone against another hierarchy. It is possible to create multiple mount with exactly the same set of comounted controllers. However, in this case all that results is multiple mount points providing a view of the same hierarchy.

Note that on many systems, the v1 controllers are automatically mounted under /sys/fs/cgroup; in particular, systemd(1) automatically creates such mounts.

Unmounting v1 controllers

A mounted cgroup filesystem can be unmounted using the umount(8) command, as in the following example:

umount /sys/fs/cgroup/pids

But note well: a cgroup filesystem is unmounted only if it is not busy, that is, it has no child cgroups. If this is not the case, then the only effect of the umount(8) is to make the mount invisible. Thus, to ensure that the mount is really removed, one must first remove all child cgroups, which in turn can be done only after all member processes have been moved from those cgroups to the root cgroup.

Cgroups version 1 controllers

Each of the cgroups version 1 controllers is governed by a kernel configuration option (listed below). Additionally, the availability of the cgroups feature is governed by the CONFIG_CGROUPS kernel configuration option.

cpu (since Linux 2.6.24; CONFIG_CGROUP_SCHED)
Cgroups can be guaranteed a minimum number of “CPU shares” when a system is busy. This does not limit a cgroup’s CPU usage if the CPUs are not busy. For further information, see Documentation/scheduler/sched-design-CFS.rst (or Documentation/scheduler/sched-design-CFS.txt in Linux 5.2 and earlier).

In Linux 3.2, this controller was extended to provide CPU “bandwidth” control. If the kernel is configured with CONFIG_CFS_BANDWIDTH, then within each scheduling period (defined via a file in the cgroup directory), it is possible to define an upper limit on the CPU time allocated to the processes in a cgroup. This upper limit applies even if there is no other competition for the CPU. Further information can be found in the kernel source file Documentation/scheduler/sched-bwc.rst (or Documentation/scheduler/sched-bwc.txt in Linux 5.2 and earlier).

cpuacct (since Linux 2.6.24; CONFIG_CGROUP_CPUACCT)
This provides accounting for CPU usage by groups of processes.

Further information can be found in the kernel source file Documentation/admin-guide/cgroup-v1/cpuacct.rst (or Documentation/cgroup-v1/cpuacct.txt in Linux 5.2 and earlier).

cpuset (since Linux 2.6.24; CONFIG_CPUSETS)
This cgroup can be used to bind the processes in a cgroup to a specified set of CPUs and NUMA nodes.

Further information can be found in the kernel source file Documentation/admin-guide/cgroup-v1/cpusets.rst (or Documentation/cgroup-v1/cpusets.txt in Linux 5.2 and earlier).

memory (since Linux 2.6.25; CONFIG_MEMCG)
The memory controller supports reporting and limiting of process memory, kernel memory, and swap used by cgroups.

Further information can be found in the kernel source file Documentation/admin-guide/cgroup-v1/memory.rst (or Documentation/cgroup-v1/memory.txt in Linux 5.2 and earlier).

devices (since Linux 2.6.26; CONFIG_CGROUP_DEVICE)
This supports controlling which processes may create (mknod) devices as well as open them for reading or writing. The policies may be specified as allow-lists and deny-lists. Hierarchy is enforced, so new rules must not violate existing rules for the target or ancestor cgroups.

Further information can be found in the kernel source file Documentation/admin-guide/cgroup-v1/devices.rst (or Documentation/cgroup-v1/devices.txt in Linux 5.2 and earlier).

freezer (since Linux 2.6.28; CONFIG_CGROUP_FREEZER)
The freezer cgroup can suspend and restore (resume) all processes in a cgroup. Freezing a cgroup /A also causes its children, for example, processes in /A/B, to be frozen.

Further information can be found in the kernel source file Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst (or Documentation/cgroup-v1/freezer-subsystem.txt in Linux 5.2 and earlier).

net_cls (since Linux 2.6.29; CONFIG_CGROUP_NET_CLASSID)
This places a classid, specified for the cgroup, on network packets created by a cgroup. These classids can then be used in firewall rules, as well as used to shape traffic using tc(8). This applies only to packets leaving the cgroup, not to traffic arriving at the cgroup.

Further information can be found in the kernel source file Documentation/admin-guide/cgroup-v1/net_cls.rst (or Documentation/cgroup-v1/net_cls.txt in Linux 5.2 and earlier).

blkio (since Linux 2.6.33; CONFIG_BLK_CGROUP)
The blkio cgroup controls and limits access to specified block devices by applying IO control in the form of throttling and upper limits against leaf nodes and intermediate nodes in the storage hierarchy.

Two policies are available. The first is a proportional-weight time-based division of disk implemented with CFQ. This is in effect for leaf nodes using CFQ. The second is a throttling policy which specifies upper I/O rate limits on a device.

Further information can be found in the kernel source file Documentation/admin-guide/cgroup-v1/blkio-controller.rst (or Documentation/cgroup-v1/blkio-controller.txt in Linux 5.2 and earlier).

perf_event (since Linux 2.6.39; CONFIG_CGROUP_PERF)
This controller allows perf monitoring of the set of processes grouped in a cgroup.

Further information can be found in the kernel source files

net_prio (since Linux 3.3; CONFIG_CGROUP_NET_PRIO)
This allows priorities to be specified, per network interface, for cgroups.

Further information can be found in the kernel source file Documentation/admin-guide/cgroup-v1/net_prio.rst (or Documentation/cgroup-v1/net_prio.txt in Linux 5.2 and earlier).

hugetlb (since Linux 3.5; CONFIG_CGROUP_HUGETLB)
This supports limiting the use of huge pages by cgroups.

Further information can be found in the kernel source file Documentation/admin-guide/cgroup-v1/hugetlb.rst (or Documentation/cgroup-v1/hugetlb.txt in Linux 5.2 and earlier).

pids (since Linux 4.3; CONFIG_CGROUP_PIDS)
This controller permits limiting the number of process that may be created in a cgroup (and its descendants).

Further information can be found in the kernel source file Documentation/admin-guide/cgroup-v1/pids.rst (or Documentation/cgroup-v1/pids.txt in Linux 5.2 and earlier).

rdma (since Linux 4.11; CONFIG_CGROUP_RDMA)
The RDMA controller permits limiting the use of RDMA/IB-specific resources per cgroup.

Further information can be found in the kernel source file Documentation/admin-guide/cgroup-v1/rdma.rst (or Documentation/cgroup-v1/rdma.txt in Linux 5.2 and earlier).

Creating cgroups and moving processes

A cgroup filesystem initially contains a single root cgroup, ‘/’, which all processes belong to. A new cgroup is created by creating a directory in the cgroup filesystem:

mkdir /sys/fs/cgroup/cpu/cg1

This creates a new empty cgroup.

A process may be moved to this cgroup by writing its PID into the cgroup’s cgroup.procs file:

echo $$ > /sys/fs/cgroup/cpu/cg1/cgroup.procs

Only one PID at a time should be written to this file.

Writing the value 0 to a cgroup.procs file causes the writing process to be moved to the corresponding cgroup.

When writing a PID into the cgroup.procs, all threads in the process are moved into the new cgroup at once.

Within a hierarchy, a process can be a member of exactly one cgroup. Writing a process’s PID to a cgroup.procs file automatically removes it from the cgroup of which it was previously a member.

The cgroup.procs file can be read to obtain a list of the processes that are members of a cgroup. The returned list of PIDs is not guaranteed to be in order. Nor is it guaranteed to be free of duplicates. (For example, a PID may be recycled while reading from the list.)

In cgroups v1, an individual thread can be moved to another cgroup by writing its thread ID (i.e., the kernel thread ID returned by clone(2) and gettid(2)) to the tasks file in a cgroup directory. This file can be read to discover the set of threads that are members of the cgroup.

Removing cgroups

To remove a cgroup, it must first have no child cgroups and contain no (nonzombie) processes. So long as that is the case, one can simply remove the corresponding directory pathname. Note that files in a cgroup directory cannot and need not be removed.

Cgroups v1 release notification

Two files can be used to determine whether the kernel provides notifications when a cgroup becomes empty. A cgroup is considered to be empty when it contains no child cgroups and no member processes.

A special file in the root directory of each cgroup hierarchy, release_agent, can be used to register the pathname of a program that may be invoked when a cgroup in the hierarchy becomes empty. The pathname of the newly empty cgroup (relative to the cgroup mount point) is provided as the sole command-line argument when the release_agent program is invoked. The release_agent program might remove the cgroup directory, or perhaps repopulate it with a process.

The default value of the release_agent file is empty, meaning that no release agent is invoked.

The content of the release_agent file can also be specified via a mount option when the cgroup filesystem is mounted:

mount -o release_agent=pathname ...

Whether or not the release_agent program is invoked when a particular cgroup becomes empty is determined by the value in the notify_on_release file in the corresponding cgroup directory. If this file contains the value 0, then the release_agent program is not invoked. If it contains the value 1, the release_agent program is invoked. The default value for this file in the root cgroup is 0. At the time when a new cgroup is created, the value in this file is inherited from the corresponding file in the parent cgroup.

Cgroup v1 named hierarchies

In cgroups v1, it is possible to mount a cgroup hierarchy that has no attached controllers:

mount -t cgroup -o none,name=somename none /some/mount/point

Multiple instances of such hierarchies can be mounted; each hierarchy must have a unique name. The only purpose of such hierarchies is to track processes. (See the discussion of release notification below.) An example of this is the name=systemd cgroup hierarchy that is used by systemd(1) to track services and user sessions.

Since Linux 5.0, the cgroup_no_v1 kernel boot option (described below) can be used to disable cgroup v1 named hierarchies, by specifying cgroup_no_v1=named.

CGROUPS VERSION 2

In cgroups v2, all mounted controllers reside in a single unified hierarchy. While (different) controllers may be simultaneously mounted under the v1 and v2 hierarchies, it is not possible to mount the same controller simultaneously under both the v1 and the v2 hierarchies.

The new behaviors in cgroups v2 are summarized here, and in some cases elaborated in the following subsections.

  • Cgroups v2 provides a unified hierarchy against which all controllers are mounted.

  • “Internal” processes are not permitted. With the exception of the root cgroup, processes may reside only in leaf nodes (cgroups that do not themselves contain child cgroups). The details are somewhat more subtle than this, and are described below.

  • Active cgroups must be specified via the files cgroup.controllers and cgroup.subtree_control.

  • The tasks file has been removed. In addition, the cgroup.clone_children file that is employed by the cpuset controller has been removed.

  • An improved mechanism for notification of empty cgroups is provided by the cgroup.events file.

For more changes, see the Documentation/admin-guide/cgroup-v2.rst file in the kernel source (or Documentation/cgroup-v2.txt in Linux 4.17 and earlier).

Some of the new behaviors listed above saw subsequent modification with the addition in Linux 4.14 of “thread mode” (described below).

Cgroups v2 unified hierarchy

In cgroups v1, the ability to mount different controllers against different hierarchies was intended to allow great flexibility for application design. In practice, though, the flexibility turned out to be less useful than expected, and in many cases added complexity. Therefore, in cgroups v2, all available controllers are mounted against a single hierarchy. The available controllers are automatically mounted, meaning that it is not necessary (or possible) to specify the controllers when mounting the cgroup v2 filesystem using a command such as the following:

mount -t cgroup2 none /mnt/cgroup2

A cgroup v2 controller is available only if it is not currently in use via a mount against a cgroup v1 hierarchy. Or, to put things another way, it is not possible to employ the same controller against both a v1 hierarchy and the unified v2 hierarchy. This means that it may be necessary first to unmount a v1 controller (as described above) before that controller is available in v2. Since systemd(1) makes heavy use of some v1 controllers by default, it can in some cases be simpler to boot the system with selected v1 controllers disabled. To do this, specify the cgroup_no_v1=list option on the kernel boot command line; list is a comma-separated list of the names of the controllers to disable, or the word all to disable all v1 controllers. (This situation is correctly handled by systemd(1), which falls back to operating without the specified controllers.)

Note that on many modern systems, systemd(1) automatically mounts the cgroup2 filesystem at /sys/fs/cgroup/unified during the boot process.

Cgroups v2 mount options

The following options (mount -o) can be specified when mounting the group v2 filesystem:

nsdelegate (since Linux 4.15)
Treat cgroup namespaces as delegation boundaries. For details, see below.

memory_localevents (since Linux 5.2)
The memory.events should show statistics only for the cgroup itself, and not for any descendant cgroups. This was the behavior before Linux 5.2. Starting in Linux 5.2, the default behavior is to include statistics for descendant cgroups in memory.events, and this mount option can be used to revert to the legacy behavior. This option is system wide and can be set on mount or modified through remount only from the initial mount namespace; it is silently ignored in noninitial namespaces.

Cgroups v2 controllers

The following controllers, documented in the kernel source file Documentation/admin-guide/cgroup-v2.rst (or Documentation/cgroup-v2.txt in Linux 4.17 and earlier), are supported in cgroups version 2:

cpu (since Linux 4.15)
This is the successor to the version 1 cpu and cpuacct controllers.

cpuset (since Linux 5.0)
This is the successor of the version 1 cpuset controller.

freezer (since Linux 5.2)
This is the successor of the version 1 freezer controller.

hugetlb (since Linux 5.6)
This is the successor of the version 1 hugetlb controller.

io (since Linux 4.5)
This is the successor of the version 1 blkio controller.

memory (since Linux 4.5)
This is the successor of the version 1 memory controller.

perf_event (since Linux 4.11)
This is the same as the version 1 perf_event controller.

pids (since Linux 4.5)
This is the same as the version 1 pids controller.

rdma (since Linux 4.11)
This is the same as the version 1 rdma controller.

There is no direct equivalent of the net_cls and net_prio controllers from cgroups version 1. Instead, support has been added to iptables(8) to allow eBPF filters that hook on cgroup v2 pathnames to make decisions about network traffic on a per-cgroup basis.

The v2 devices controller provides no interface files; instead, device control is gated by attaching an eBPF (BPF_CGROUP_DEVICE) program to a v2 cgroup.

Cgroups v2 subtree control

Each cgroup in the v2 hierarchy contains the following two files:

cgroup.controllers
This read-only file exposes a list of the controllers that are available in this cgroup. The contents of this file match the contents of the cgroup.subtree_control file in the parent cgroup.

cgroup.subtree_control
This is a list of controllers that are active (enabled) in the cgroup. The set of controllers in this file is a subset of the set in the cgroup.controllers of this cgroup. The set of active controllers is modified by writing strings to this file containing space-delimited controller names, each preceded by ‘+’ (to enable a controller) or ‘-’ (to disable a controller), as in the following example:

echo '+pids -memory' > x/y/cgroup.subtree_control

An attempt to enable a controller that is not present in cgroup.controllers leads to an ENOENT error when writing to the cgroup.subtree_control file.

Because the list of controllers in cgroup.subtree_control is a subset of those cgroup.controllers, a controller that has been disabled in one cgroup in the hierarchy can never be re-enabled in the subtree below that cgroup.

A cgroup’s cgroup.subtree_control file determines the set of controllers that are exercised in the child cgroups. When a controller (e.g., pids) is present in the cgroup.subtree_control file of a parent cgroup, then the corresponding controller-interface files (e.g., pids.max) are automatically created in the children of that cgroup and can be used to exert resource control in the child cgroups.

Cgroups v2 “no internal processes” rule

Cgroups v2 enforces a so-called “no internal processes” rule. Roughly speaking, this rule means that, with the exception of the root cgroup, processes may reside only in leaf nodes (cgroups that do not themselves contain child cgroups). This avoids the need to decide how to partition resources between processes which are members of cgroup A and processes in child cgroups of A.

For instance, if cgroup /cg1/cg2 exists, then a process may reside in /cg1/cg2, but not in /cg1. This is to avoid an ambiguity in cgroups v1 with respect to the delegation of resources between processes in /cg1 and its child cgroups. The recommended approach in cgroups v2 is to create a subdirectory called leaf for any nonleaf cgroup which should contain processes, but no child cgroups. Thus, processes which previously would have gone into /cg1 would now go into /cg1/leaf. This has the advantage of making explicit the relationship between processes in /cg1/leaf and /cg1’s other children.

The “no internal processes” rule is in fact more subtle than stated above. More precisely, the rule is that a (nonroot) cgroup can’t both (1) have member processes, and (2) distribute resources into child cgroups—that is, have a nonempty cgroup.subtree_control file. Thus, it is possible for a cgroup to have both member processes and child cgroups, but before controllers can be enabled for that cgroup, the member processes must be moved out of the cgroup (e.g., perhaps into the child cgroups).

With the Linux 4.14 addition of “thread mode” (described below), the “no internal processes” rule has been relaxed in some cases.

Cgroups v2 cgroup.events file

Each nonroot cgroup in the v2 hierarchy contains a read-only file, cgroup.events, whose contents are key-value pairs (delimited by newline characters, with the key and value separated by spaces) providing state information about the cgroup:

$ cat mygrp/cgroup.events
populated 1
frozen 0

The following keys may appear in this file:

populated
The value of this key is either 1, if this cgroup or any of its descendants has member processes, or otherwise 0.

frozen (since Linux 5.2)
The value of this key is 1 if this cgroup is currently frozen, or 0 if it is not.

The cgroup.events file can be monitored, in order to receive notification when the value of one of its keys changes. Such monitoring can be done using inotify(7), which notifies changes as IN_MODIFY events, or poll(2), which notifies changes by returning the POLLPRI and POLLERR bits in the revents field.

Cgroup v2 release notification

Cgroups v2 provides a new mechanism for obtaining notification when a cgroup becomes empty. The cgroups v1 release_agent and notify_on_release files are removed, and replaced by the populated key in the cgroup.events file. This key either has the value 0, meaning that the cgroup (and its descendants) contain no (nonzombie) member processes, or 1, meaning that the cgroup (or one of its descendants) contains member processes.

The cgroups v2 release-notification mechanism offers the following advantages over the cgroups v1 release_agent mechanism:

  • It allows for cheaper notification, since a single process can monitor multiple cgroup.events files (using the techniques described earlier). By contrast, the cgroups v1 mechanism requires the expense of creating a process for each notification.

  • Notification for different cgroup subhierarchies can be delegated to different processes. By contrast, the cgroups v1 mechanism allows only one release agent for an entire hierarchy.

Cgroups v2 cgroup.stat file

Each cgroup in the v2 hierarchy contains a read-only cgroup.stat file (first introduced in Linux 4.14) that consists of lines containing key-value pairs. The following keys currently appear in this file:

nr_descendants
This is the total number of visible (i.e., living) descendant cgroups underneath this cgroup.

nr_dying_descendants
This is the total number of dying descendant cgroups underneath this cgroup. A cgroup enters the dying state after being deleted. It remains in that state for an undefined period (which will depend on system load) while resources are freed before the cgroup is destroyed. Note that the presence of some cgroups in the dying state is normal, and is not indicative of any problem.

A process can’t be made a member of a dying cgroup, and a dying cgroup can’t be brought back to life.

Limiting the number of descendant cgroups

Each cgroup in the v2 hierarchy contains the following files, which can be used to view and set limits on the number of descendant cgroups under that cgroup:

cgroup.max.depth (since Linux 4.14)
This file defines a limit on the depth of nesting of descendant cgroups. A value of 0 in this file means that no descendant cgroups can be created. An attempt to create a descendant whose nesting level exceeds the limit fails (mkdir(2) fails with the error EAGAIN).

Writing the string “max” to this file means that no limit is imposed. The default value in this file is “max”.

cgroup.max.descendants (since Linux 4.14)
This file defines a limit on the number of live descendant cgroups that this cgroup may have. An attempt to create more descendants than allowed by the limit fails (mkdir(2) fails with the error EAGAIN).

Writing the string “max” to this file means that no limit is imposed. The default value in this file is “max”.

CGROUPS DELEGATION: DELEGATING A HIERARCHY TO A LESS PRIVILEGED USER

In the context of cgroups, delegation means passing management of some subtree of the cgroup hierarchy to a nonprivileged user. Cgroups v1 provides support for delegation based on file permissions in the cgroup hierarchy but with less strict containment rules than v2 (as noted below). Cgroups v2 supports delegation with containment by explicit design. The focus of the discussion in this section is on delegation in cgroups v2, with some differences for cgroups v1 noted along the way.

Some terminology is required in order to describe delegation. A delegater is a privileged user (i.e., root) who owns a parent cgroup. A delegatee is a nonprivileged user who will be granted the permissions needed to manage some subhierarchy under that parent cgroup, known as the delegated subtree.

To perform delegation, the delegater makes certain directories and files writable by the delegatee, typically by changing the ownership of the objects to be the user ID of the delegatee. Assuming that we want to delegate the hierarchy rooted at (say) /dlgt_grp and that there are not yet any child cgroups under that cgroup, the ownership of the following is changed to the user ID of the delegatee:

/dlgt_grp
Changing the ownership of the root of the subtree means that any new cgroups created under the subtree (and the files they contain) will also be owned by the delegatee.

/dlgt_grp/cgroup.procs
Changing the ownership of this file means that the delegatee can move processes into the root of the delegated subtree.

/dlgt_grp/cgroup.subtree_control (cgroups v2 only)
Changing the ownership of this file means that the delegatee can enable controllers (that are present in /dlgt_grp/cgroup.controllers) in order to further redistribute resources at lower levels in the subtree. (As an alternative to changing the ownership of this file, the delegater might instead add selected controllers to this file.)

/dlgt_grp/cgroup.threads (cgroups v2 only)
Changing the ownership of this file is necessary if a threaded subtree is being delegated (see the description of “thread mode”, below). This permits the delegatee to write thread IDs to the file. (The ownership of this file can also be changed when delegating a domain subtree, but currently this serves no purpose, since, as described below, it is not possible to move a thread between domain cgroups by writing its thread ID to the cgroup.threads file.)

In cgroups v1, the corresponding file that should instead be delegated is the tasks file.

The delegater should not change the ownership of any of the controller interfaces files (e.g., pids.max, memory.high) in dlgt_grp. Those files are used from the next level above the delegated subtree in order to distribute resources into the subtree, and the delegatee should not have permission to change the resources that are distributed into the delegated subtree.

See also the discussion of the /sys/kernel/cgroup/delegate file in NOTES for information about further delegatable files in cgroups v2.

After the aforementioned steps have been performed, the delegatee can create child cgroups within the delegated subtree (the cgroup subdirectories and the files they contain will be owned by the delegatee) and move processes between cgroups in the subtree. If some controllers are present in dlgt_grp/cgroup.subtree_control, or the ownership of that file was passed to the delegatee, the delegatee can also control the further redistribution of the corresponding resources into the delegated subtree.

Cgroups v2 delegation: nsdelegate and cgroup namespaces

Starting with Linux 4.13, there is a second way to perform cgroup delegation in the cgroups v2 hierarchy. This is done by mounting or remounting the cgroup v2 filesystem with the nsdelegate mount option. For example, if the cgroup v2 filesystem has already been mounted, we can remount it with the nsdelegate option as follows:

mount -t cgroup2 -o remount,nsdelegate \
                 none /sys/fs/cgroup/unified

The effect of this mount option is to cause cgroup namespaces to automatically become delegation boundaries. More specifically, the following restrictions apply for processes inside the cgroup namespace:

  • Writes to controller interface files in the root directory of the namespace will fail with the error EPERM. Processes inside the cgroup namespace can still write to delegatable files in the root directory of the cgroup namespace such as cgroup.procs and cgroup.subtree_control, and can create subhierarchy underneath the root directory.

  • Attempts to migrate processes across the namespace boundary are denied (with the error ENOENT). Processes inside the cgroup namespace can still (subject to the containment rules described below) move processes between cgroups within the subhierarchy under the namespace root.

The ability to define cgroup namespaces as delegation boundaries makes cgroup namespaces more useful. To understand why, suppose that we already have one cgroup hierarchy that has been delegated to a nonprivileged user, cecilia, using the older delegation technique described above. Suppose further that cecilia wanted to further delegate a subhierarchy under the existing delegated hierarchy. (For example, the delegated hierarchy might be associated with an unprivileged container run by cecilia.) Even if a cgroup namespace was employed, because both hierarchies are owned by the unprivileged user cecilia, the following illegitimate actions could be performed:

  • A process in the inferior hierarchy could change the resource controller settings in the root directory of that hierarchy. (These resource controller settings are intended to allow control to be exercised from the parent cgroup; a process inside the child cgroup should not be allowed to modify them.)

  • A process inside the inferior hierarchy could move processes into and out of the inferior hierarchy if the cgroups in the superior hierarchy were somehow visible.

Employing the nsdelegate mount option prevents both of these possibilities.

The nsdelegate mount option only has an effect when performed in the initial mount namespace; in other mount namespaces, the option is silently ignored.

Note: On some systems, systemd(1) automatically mounts the cgroup v2 filesystem. In order to experiment with the nsdelegate operation, it may be useful to boot the kernel with the following command-line options:

cgroup_no_v1=all systemd.legacy_systemd_cgroup_controller

These options cause the kernel to boot with the cgroups v1 controllers disabled (meaning that the controllers are available in the v2 hierarchy), and tells systemd(1) not to mount and use the cgroup v2 hierarchy, so that the v2 hierarchy can be manually mounted with the desired options after boot-up.

Cgroup delegation containment rules

Some delegation containment rules ensure that the delegatee can move processes between cgroups within the delegated subtree, but can’t move processes from outside the delegated subtree into the subtree or vice versa. A nonprivileged process (i.e., the delegatee) can write the PID of a “target” process into a cgroup.procs file only if all of the following are true:

  • The writer has write permission on the cgroup.procs file in the destination cgroup.

  • The writer has write permission on the cgroup.procs file in the nearest common ancestor of the source and destination cgroups. Note that in some cases, the nearest common ancestor may be the source or destination cgroup itself. This requirement is not enforced for cgroups v1 hierarchies, with the consequence that containment in v1 is less strict than in v2. (For example, in cgroups v1 the user that owns two distinct delegated subhierarchies can move a process between the hierarchies.)

  • If the cgroup v2 filesystem was mounted with the nsdelegate option, the writer must be able to see the source and destination cgroups from its cgroup namespace.

  • In cgroups v1: the effective UID of the writer (i.e., the delegatee) matches the real user ID or the saved set-user-ID of the target process. Before Linux 4.11, this requirement also applied in cgroups v2 (This was a historical requirement inherited from cgroups v1 that was later deemed unnecessary, since the other rules suffice for containment in cgroups v2.)

Note: one consequence of these delegation containment rules is that the unprivileged delegatee can’t place the first process into the delegated subtree; instead, the delegater must place the first process (a process owned by the delegatee) into the delegated subtree.

CGROUPS VERSION 2 THREAD MODE

Among the restrictions imposed by cgroups v2 that were not present in cgroups v1 are the following:

  • No thread-granularity control: all of the threads of a process must be in the same cgroup.

  • No internal processes: a cgroup can’t both have member processes and exercise controllers on child cgroups.

Both of these restrictions were added because the lack of these restrictions had caused problems in cgroups v1. In particular, the cgroups v1 ability to allow thread-level granularity for cgroup membership made no sense for some controllers. (A notable example was the memory controller: since threads share an address space, it made no sense to split threads across different memory cgroups.)

Notwithstanding the initial design decision in cgroups v2, there were use cases for certain controllers, notably the cpu controller, for which thread-level granularity of control was meaningful and useful. To accommodate such use cases, Linux 4.14 added thread mode for cgroups v2.

Thread mode allows the following:

  • The creation of threaded subtrees in which the threads of a process may be spread across cgroups inside the tree. (A threaded subtree may contain multiple multithreaded processes.)

  • The concept of threaded controllers, which can distribute resources across the cgroups in a threaded subtree.

  • A relaxation of the “no internal processes rule”, so that, within a threaded subtree, a cgroup can both contain member threads and exercise resource control over child cgroups.

With the addition of thread mode, each nonroot cgroup now contains a new file, cgroup.type, that exposes, and in some circumstances can be used to change, the “type” of a cgroup. This file contains one of the following type values:

domain
This is a normal v2 cgroup that provides process-granularity control. If a process is a member of this cgroup, then all threads of the process are (by definition) in the same cgroup. This is the default cgroup type, and provides the same behavior that was provided for cgroups in the initial cgroups v2 implementation.

threaded
This cgroup is a member of a threaded subtree. Threads can be added to this cgroup, and controllers can be enabled for the cgroup.

domain threaded
This is a domain cgroup that serves as the root of a threaded subtree. This cgroup type is also known as “threaded root”.

domain invalid
This is a cgroup inside a threaded subtree that is in an “invalid” state. Processes can’t be added to the cgroup, and controllers can’t be enabled for the cgroup. The only thing that can be done with this cgroup (other than deleting it) is to convert it to a threaded cgroup by writing the string “threaded” to the cgroup.type file.

The rationale for the existence of this “interim” type during the creation of a threaded subtree (rather than the kernel simply immediately converting all cgroups under the threaded root to the type threaded) is to allow for possible future extensions to the thread mode model

Threaded versus domain controllers

With the addition of threads mode, cgroups v2 now distinguishes two types of resource controllers:

  • Threaded controllers: these controllers support thread-granularity for resource control and can be enabled inside threaded subtrees, with the result that the corresponding controller-interface files appear inside the cgroups in the threaded subtree. As at Linux 4.19, the following controllers are threaded: cpu, perf_event, and pids.

  • Domain controllers: these controllers support only process granularity for resource control. From the perspective of a domain controller, all threads of a process are always in the same cgroup. Domain controllers can’t be enabled inside a threaded subtree.

Creating a threaded subtree

There are two pathways that lead to the creation of a threaded subtree. The first pathway proceeds as follows:

  1. We write the string “threaded” to the cgroup.type file of a cgroup y/z that currently has the type domain. This has the following effects:

    • The type of the cgroup y/z becomes threaded.

    • The type of the parent cgroup, y, becomes domain threaded. The parent cgroup is the root of a threaded subtree (also known as the “threaded root”).

    • All other cgroups under y that were not already of type threaded (because they were inside already existing threaded subtrees under the new threaded root) are converted to type domain invalid. Any subsequently created cgroups under y will also have the type domain invalid.

  2. We write the string “threaded” to each of the domain invalid cgroups under y, in order to convert them to the type threaded. As a consequence of this step, all threads under the threaded root now have the type threaded and the threaded subtree is now fully usable. The requirement to write “threaded” to each of these cgroups is somewhat cumbersome, but allows for possible future extensions to the thread-mode model.

The second way of creating a threaded subtree is as follows:

  1. In an existing cgroup, z, that currently has the type domain, we (1.1) enable one or more threaded controllers and (1.2) make a process a member of z. (These two steps can be done in either order.) This has the following consequences:

    • The type of z becomes domain threaded.

    • All of the descendant cgroups of z that were not already of type threaded are converted to type domain invalid.

  2. As before, we make the threaded subtree usable by writing the string “threaded” to each of the domain invalid cgroups under z, in order to convert them to the type threaded.

One of the consequences of the above pathways to creating a threaded subtree is that the threaded root cgroup can be a parent only to threaded (and domain invalid) cgroups. The threaded root cgroup can’t be a parent of a domain cgroups, and a threaded cgroup can’t have a sibling that is a domain cgroup.

Using a threaded subtree

Within a threaded subtree, threaded controllers can be enabled in each subgroup whose type has been changed to threaded; upon doing so, the corresponding controller interface files appear in the children of that cgroup.

A process can be moved into a threaded subtree by writing its PID to the cgroup.procs file in one of the cgroups inside the tree. This has the effect of making all of the threads in the process members of the corresponding cgroup and makes the process a member of the threaded subtree. The threads of the process can then be spread across the threaded subtree by writing their thread IDs (see gettid(2)) to the cgroup.threads files in different cgroups inside the subtree. The threads of a process must all reside in the same threaded subtree.

As with writing to cgroup.procs, some containment rules apply when writing to the cgroup.threads file:

  • The writer must have write permission on the cgroup.threads file in the destination cgroup.

  • The writer must have write permission on the cgroup.procs file in the common ancestor of the source and destination cgroups. (In some cases, the common ancestor may be the source or destination cgroup itself.)

  • The source and destination cgroups must be in the same threaded subtree. (Outside a threaded subtree, an attempt to move a thread by writing its thread ID to the cgroup.threads file in a different domain cgroup fails with the error EOPNOTSUPP.)

The cgroup.threads file is present in each cgroup (including domain cgroups) and can be read in order to discover the set of threads that is present in the cgroup. The set of thread IDs obtained when reading this file is not guaranteed to be ordered or free of duplicates.

The cgroup.procs file in the threaded root shows the PIDs of all processes that are members of the threaded subtree. The cgroup.procs files in the other cgroups in the subtree are not readable.

Domain controllers can’t be enabled in a threaded subtree; no controller-interface files appear inside the cgroups underneath the threaded root. From the point of view of a domain controller, threaded subtrees are invisible: a multithreaded process inside a threaded subtree appears to a domain controller as a process that resides in the threaded root cgroup.

Within a threaded subtree, the “no internal processes” rule does not apply: a cgroup can both contain member processes (or thread) and exercise controllers on child cgroups.

Rules for writing to cgroup.type and creating threaded subtrees

A number of rules apply when writing to the cgroup.type file:

  • Only the string “threaded” may be written. In other words, the only explicit transition that is possible is to convert a domain cgroup to type threaded.

  • The effect of writing “threaded” depends on the current value in cgroup.type, as follows:

    • domain or domain threaded: start the creation of a threaded subtree (whose root is the parent of this cgroup) via the first of the pathways described above;

    • domain invalid: convert this cgroup (which is inside a threaded subtree) to a usable (i.e., threaded) state;

    • threaded: no effect (a “no-op”).

  • We can’t write to a cgroup.type file if the parent’s type is domain invalid. In other words, the cgroups of a threaded subtree must be converted to the threaded state in a top-down manner.

There are also some constraints that must be satisfied in order to create a threaded subtree rooted at the cgroup x:

  • There can be no member processes in the descendant cgroups of x. (The cgroup x can itself have member processes.)

  • No domain controllers may be enabled in x’s cgroup.subtree_control file.

If any of the above constraints is violated, then an attempt to write “threaded” to a cgroup.type file fails with the error ENOTSUP.

The “domain threaded” cgroup type

According to the pathways described above, the type of a cgroup can change to domain threaded in either of the following cases:

  • The string “threaded” is written to a child cgroup.

  • A threaded controller is enabled inside the cgroup and a process is made a member of the cgroup.

A domain threaded cgroup, x, can revert to the type domain if the above conditions no longer hold true—that is, if all threaded child cgroups of x are removed and either x no longer has threaded controllers enabled or no longer has member processes.

When a domain threaded cgroup x reverts to the type domain:

  • All domain invalid descendants of x that are not in lower-level threaded subtrees revert to the type domain.

  • The root cgroups in any lower-level threaded subtrees revert to the type domain threaded.

Exceptions for the root cgroup

The root cgroup of the v2 hierarchy is treated exceptionally: it can be the parent of both domain and threaded cgroups. If the string “threaded” is written to the cgroup.type file of one of the children of the root cgroup, then

  • The type of that cgroup becomes threaded.

  • The type of any descendants of that cgroup that are not part of lower-level threaded subtrees changes to domain invalid.

Note that in this case, there is no cgroup whose type becomes domain threaded. (Notionally, the root cgroup can be considered as the threaded root for the cgroup whose type was changed to threaded.)

The aim of this exceptional treatment for the root cgroup is to allow a threaded cgroup that employs the cpu controller to be placed as high as possible in the hierarchy, so as to minimize the (small) cost of traversing the cgroup hierarchy.

The cgroups v2 “cpu” controller and realtime threads

As at Linux 4.19, the cgroups v2 cpu controller does not support control of realtime threads (specifically threads scheduled under any of the policies SCHED_FIFO, SCHED_RR, described SCHED_DEADLINE; see sched(7)). Therefore, the cpu controller can be enabled in the root cgroup only if all realtime threads are in the root cgroup. (If there are realtime threads in nonroot cgroups, then a write(2) of the string "+cpu" to the cgroup.subtree_control file fails with the error EINVAL.)

On some systems, systemd(1) places certain realtime threads in nonroot cgroups in the v2 hierarchy. On such systems, these threads must first be moved to the root cgroup before the cpu controller can be enabled.

ERRORS

The following errors can occur for mount(2):

EBUSY
An attempt to mount a cgroup version 1 filesystem specified neither the name= option (to mount a named hierarchy) nor a controller name (or all).

NOTES

A child process created via fork(2) inherits its parent’s cgroup memberships. A process’s cgroup memberships are preserved across execve(2).

The clone3(2) CLONE_INTO_CGROUP flag can be used to create a child process that begins its life in a different version 2 cgroup from the parent process.

/proc files

/proc/cgroups (since Linux 2.6.24)
This file contains information about the controllers that are compiled into the kernel. An example of the contents of this file (reformatted for readability) is the following:

#subsys_name    hierarchy      num_cgroups    enabled
cpuset          4              1              1
cpu             8              1              1
cpuacct         8              1              1
blkio           6              1              1
memory          3              1              1
devices         10             84             1
freezer         7              1              1
net_cls         9              1              1
perf_event      5              1              1
net_prio        9              1              1
hugetlb         0              1              0
pids            2              1              1

The fields in this file are, from left to right:

[1]
The name of the controller.

[2]
The unique ID of the cgroup hierarchy on which this controller is mounted. If multiple cgroups v1 controllers are bound to the same hierarchy, then each will show the same hierarchy ID in this field. The value in this field will be 0 if:

  • the controller is not mounted on a cgroups v1 hierarchy;

  • the controller is bound to the cgroups v2 single unified hierarchy; or

  • the controller is disabled (see below).

[3]
The number of control groups in this hierarchy using this controller.

[4]
This field contains the value 1 if this controller is enabled, or 0 if it has been disabled (via the cgroup_disable kernel command-line boot parameter).

/proc/pid/cgroup (since Linux 2.6.24)
This file describes control groups to which the process with the corresponding PID belongs. The displayed information differs for cgroups version 1 and version 2 hierarchies.

For each cgroup hierarchy of which the process is a member, there is one entry containing three colon-separated fields:

hierarchy-ID:controller-list:cgroup-path

For example:

5:cpuacct,cpu,cpuset:/daemons

The colon-separated fields are, from left to right:

[1]
For cgroups version 1 hierarchies, this field contains a unique hierarchy ID number that can be matched to a hierarchy ID in /proc/cgroups. For the cgroups version 2 hierarchy, this field contains the value 0.

[2]
For cgroups version 1 hierarchies, this field contains a comma-separated list of the controllers bound to the hierarchy. For the cgroups version 2 hierarchy, this field is empty.

[3]
This field contains the pathname of the control group in the hierarchy to which the process belongs. This pathname is relative to the mount point of the hierarchy.

/sys/kernel/cgroup files

/sys/kernel/cgroup/delegate (since Linux 4.15)
This file exports a list of the cgroups v2 files (one per line) that are delegatable (i.e., whose ownership should be changed to the user ID of the delegatee). In the future, the set of delegatable files may change or grow, and this file provides a way for the kernel to inform user-space applications of which files must be delegated. As at Linux 4.15, one sees the following when inspecting this file:

$ cat /sys/kernel/cgroup/delegate
cgroup.procs
cgroup.subtree_control
cgroup.threads

/sys/kernel/cgroup/features (since Linux 4.15)
Over time, the set of cgroups v2 features that are provided by the kernel may change or grow, or some features may not be enabled by default. This file provides a way for user-space applications to discover what features the running kernel supports and has enabled. Features are listed one per line:

$ cat /sys/kernel/cgroup/features
nsdelegate
memory_localevents

The entries that can appear in this file are:

memory_localevents (since Linux 5.2)
The kernel supports the memory_localevents mount option.

nsdelegate (since Linux 4.15)
The kernel supports the nsdelegate mount option.

memory_recursiveprot (since Linux 5.7)
The kernel supports the memory_recursiveprot mount option.

SEE ALSO

prlimit(1), systemd(1), systemd-cgls(1), systemd-cgtop(1), clone(2), ioprio_set(2), perf_event_open(2), setrlimit(2), cgroup_namespaces(7), cpuset(7), namespaces(7), sched(7), user_namespaces(7)

The kernel source file Documentation/admin-guide/cgroup-v2.rst.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

487 - Linux cli command go-packages

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command go-packages and provides detailed information about the command go-packages, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the go-packages.

NAME 🖥️ go-packages 🖥️

tool for managing Go source code

DESCRIPTION

Many commands apply to a set of packages:

go action [packages]

Usually, [packages] is a list of import paths.

An import path that is a rooted path or that begins with a . or .. element is interpreted as a file system path and denotes the package in that directory.

Otherwise, the import path P denotes the package found in the directory DIR/src/P for some DIR listed in the GOPATH environment variable (For more details see: ‘go help gopath’).

If no import paths are given, the action applies to the package in the current directory.

There are four reserved names for paths that should not be used for packages to be built with the go tool:

  • “main” denotes the top-level package in a stand-alone executable.

  • “all” expands to all packages found in all the GOPATH trees. For example, ‘go list all’ lists all the packages on the local system. When using modules, “all” expands to all packages in the main module and their dependencies, including dependencies needed by tests of any of those.

  • “std” is like all but expands to just the packages in the standard Go library.

  • “cmd” expands to the Go repository’s commands and their internal libraries.

Import paths beginning with “cmd/” only match source code in the Go repository.

An import path is a pattern if it includes one or more “…” wildcards, each of which can match any string, including the empty string and strings containing slashes. Such a pattern expands to all package directories found in the GOPATH trees with names matching the patterns.

To make common patterns more convenient, there are two special cases. First, /… at the end of the pattern can match an empty string, so that net/… matches both net and packages in its subdirectories, like net/http. Second, any slash-separated pattern element containing a wildcard never participates in a match of the “vendor” element in the path of a vendored package, so that ./… does not match packages in subdirectories of ./vendor or ./mycode/vendor, but ./vendor/… and ./mycode/vendor/… do. Note, however, that a directory named vendor that itself contains code is not a vendored package: cmd/vendor would be a command named vendor, and the pattern cmd/… matches it. See golang.org/s/go15vendor for more about vendoring.

An import path can also name a package to be downloaded from a remote repository. Run ‘go help importpath’ for details.

Every package in a program must have a unique import path. By convention, this is arranged by starting each path with a unique prefix that belongs to you. For example, paths used internally at Google all begin with ‘google’, and paths denoting remote repositories begin with the path to the code, such as ‘github.com/user/repo’.

Packages in a program need not have unique package names, but there are two reserved package names with special meaning. The name main indicates a command, not a library. Commands are built into binaries and cannot be imported. The name documentation indicates documentation for a non-Go program in the directory. Files in package documentation are ignored by the go command.

As a special case, if the package list is a list of .go files from a single directory, the command is applied to a single synthesized package made up of exactly those files, ignoring any build constraints in those files and ignoring any other files in the directory.

Directory and file names that begin with “.” or “_” are ignored by the go tool, as are directories named “testdata”.

AUTHOR

This manual page was written by Michael Stapelberg <[email protected]> and is maintained by the Debian Go Compiler Team <[email protected]> based on the output of ‘go help packages’ for the Debian project (and may be used by others).

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

488 - Linux cli command ALTER_ROUTINE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_ROUTINE and provides detailed information about the command ALTER_ROUTINE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_ROUTINE.

NAME 🖥️ ALTER_ROUTINE 🖥️

change the definition of a routine

SYNOPSIS

ALTER ROUTINE name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ]
    action [ ... ] [ RESTRICT ]
ALTER ROUTINE name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ]
    RENAME TO new_name
ALTER ROUTINE name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ]
    OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }
ALTER ROUTINE name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ]
    SET SCHEMA new_schema
ALTER ROUTINE name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ]
    [ NO ] DEPENDS ON EXTENSION extension_name

where action is one of:

    IMMUTABLE | STABLE | VOLATILE
    [ NOT ] LEAKPROOF
    [ EXTERNAL ] SECURITY INVOKER | [ EXTERNAL ] SECURITY DEFINER
    PARALLEL { UNSAFE | RESTRICTED | SAFE }
    COST execution_cost
    ROWS result_rows
    SET configuration_parameter { TO | = } { value | DEFAULT }
    SET configuration_parameter FROM CURRENT
    RESET configuration_parameter
    RESET ALL

DESCRIPTION

ALTER ROUTINE changes the definition of a routine, which can be an aggregate function, a normal function, or a procedure. See under ALTER AGGREGATE (ALTER_AGGREGATE(7)), ALTER FUNCTION (ALTER_FUNCTION(7)), and ALTER PROCEDURE (ALTER_PROCEDURE(7)) for the description of the parameters, more examples, and further details.

EXAMPLES

To rename the routine foo for type integer to foobar:

ALTER ROUTINE foo(integer) RENAME TO foobar;

This command will work independent of whether foo is an aggregate, function, or procedure.

COMPATIBILITY

This statement is partially compatible with the ALTER ROUTINE statement in the SQL standard. See under ALTER FUNCTION (ALTER_FUNCTION(7)) and ALTER PROCEDURE (ALTER_PROCEDURE(7)) for more details. Allowing routine names to refer to aggregate functions is a PostgreSQL extension.

SEE ALSO

ALTER AGGREGATE (ALTER_AGGREGATE(7)), ALTER FUNCTION (ALTER_FUNCTION(7)), ALTER PROCEDURE (ALTER_PROCEDURE(7)), DROP ROUTINE (DROP_ROUTINE(7))

Note that there is no CREATE ROUTINE command.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

489 - Linux cli command DROP_TRANSFORM

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_TRANSFORM and provides detailed information about the command DROP_TRANSFORM, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_TRANSFORM.

NAME 🖥️ DROP_TRANSFORM 🖥️

remove a transform

SYNOPSIS

DROP TRANSFORM [ IF EXISTS ] FOR type_name LANGUAGE lang_name [ CASCADE | RESTRICT ]

DESCRIPTION

DROP TRANSFORM removes a previously defined transform.

To be able to drop a transform, you must own the type and the language. These are the same privileges that are required to create a transform.

PARAMETERS

IF EXISTS

Do not throw an error if the transform does not exist. A notice is issued in this case.

type_name

The name of the data type of the transform.

lang_name

The name of the language of the transform.

CASCADE

Automatically drop objects that depend on the transform, and in turn all objects that depend on those objects (see Section 5.14).

RESTRICT

Refuse to drop the transform if any objects depend on it. This is the default.

EXAMPLES

To drop the transform for type hstore and language plpython3u:

DROP TRANSFORM FOR hstore LANGUAGE plpython3u;

COMPATIBILITY

This form of DROP TRANSFORM is a PostgreSQL extension. See CREATE TRANSFORM (CREATE_TRANSFORM(7)) for details.

SEE ALSO

CREATE TRANSFORM (CREATE_TRANSFORM(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

490 - Linux cli command gittutorial

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command gittutorial and provides detailed information about the command gittutorial, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the gittutorial.

NAME 🖥️ gittutorial 🖥️

A tutorial introduction to Git

SYNOPSIS

git *

DESCRIPTION

This tutorial explains how to import a new project into Git, make changes to it, and share changes with other developers.

If you are instead primarily interested in using Git to fetch a project, for example, to test the latest version, you may prefer to start with the first two chapters of The Git User’s Manual[1].

First, note that you can get documentation for a command such as git log –graph with:

$ man git-log

or:

$ git help log

With the latter, you can use the manual viewer of your choice; see git-help(1) for more information.

It is a good idea to introduce yourself to Git with your name and public email address before doing any operation. The easiest way to do so is:

$ git config –global user.name “Your Name Comes Here” $ git config –global user.email [email protected]

IMPORTING A NEW PROJECT

Assume you have a tarball project.tar.gz with your initial work. You can place it under Git revision control as follows.

$ tar xzf project.tar.gz $ cd project $ git init

Git will reply

Initialized empty Git repository in .git/

You’ve now initialized the working directory—you may notice a new directory created, named .git.

Next, tell Git to take a snapshot of the contents of all files under the current directory (note the .), with git add:

$ git add .

This snapshot is now stored in a temporary staging area which Git calls the “index”. You can permanently store the contents of the index in the repository with git commit:

$ git commit

This will prompt you for a commit message. You’ve now stored the first version of your project in Git.

MAKING CHANGES

Modify some files, then add their updated contents to the index:

$ git add file1 file2 file3

You are now ready to commit. You can see what is about to be committed using git diff with the –cached option:

$ git diff –cached

(Without –cached, git diff will show you any changes that you’ve made but not yet added to the index.) You can also get a brief summary of the situation with git status:

$ git status On branch master Changes to be committed: (use “git restore –staged …” to unstage)

        modified:   file1
        modified:   file2
        modified:   file3

If you need to make any further adjustments, do so now, and then add any newly modified content to the index. Finally, commit your changes with:

$ git commit

This will again prompt you for a message describing the change, and then record a new version of the project.

Alternatively, instead of running git add beforehand, you can use

$ git commit -a

which will automatically notice any modified (but not new) files, add them to the index, and commit, all in one step.

A note on commit messages: Though not required, it’s a good idea to begin the commit message with a single short (no more than 50 characters) line summarizing the change, followed by a blank line and then a more thorough description. The text up to the first blank line in a commit message is treated as the commit title, and that title is used throughout Git. For example, git-format-patch(1) turns a commit into email, and it uses the title on the Subject line and the rest of the commit in the body.

GIT TRACKS CONTENT NOT FILES

Many revision control systems provide an add command that tells the system to start tracking changes to a new file. Git’s add command does something simpler and more powerful: git add is used both for new and newly modified files, and in both cases it takes a snapshot of the given files and stages that content in the index, ready for inclusion in the next commit.

VIEWING PROJECT HISTORY

At any point you can view the history of your changes using

$ git log

If you also want to see complete diffs at each step, use

$ git log -p

Often the overview of the change is useful to get a feel of each step

$ git log –stat –summary

MANAGING BRANCHES

A single Git repository can maintain multiple branches of development. To create a new branch named experimental, use

$ git branch experimental

If you now run

$ git branch

you’ll get a list of all existing branches:

experimental * master

The experimental branch is the one you just created, and the master branch is a default branch that was created for you automatically. The asterisk marks the branch you are currently on; type

$ git switch experimental

to switch to the experimental branch. Now edit a file, commit the change, and switch back to the master branch:

(edit file) $ git commit -a $ git switch master

Check that the change you made is no longer visible, since it was made on the experimental branch and you’re back on the master branch.

You can make a different change on the master branch:

(edit file) $ git commit -a

at this point the two branches have diverged, with different changes made in each. To merge the changes made in experimental into master, run

$ git merge experimental

If the changes don’t conflict, you’re done. If there are conflicts, markers will be left in the problematic files showing the conflict;

$ git diff

will show this. Once you’ve edited the files to resolve the conflicts,

$ git commit -a

will commit the result of the merge. Finally,

$ gitk

will show a nice graphical representation of the resulting history.

At this point you could delete the experimental branch with

$ git branch -d experimental

This command ensures that the changes in the experimental branch are already in the current branch.

If you develop on a branch crazy-idea, then regret it, you can always delete the branch with

$ git branch -D crazy-idea

Branches are cheap and easy, so this is a good way to try something out.

USING GIT FOR COLLABORATION

Suppose that Alice has started a new project with a Git repository in /home/alice/project, and that Bob, who has a home directory on the same machine, wants to contribute.

Bob begins with:

bob$ git clone /home/alice/project myrepo

This creates a new directory myrepo containing a clone of Alice’s repository. The clone is on an equal footing with the original project, possessing its own copy of the original project’s history.

Bob then makes some changes and commits them:

(edit files) bob$ git commit -a (repeat as necessary)

When he’s ready, he tells Alice to pull changes from the repository at /home/bob/myrepo. She does this with:

alice$ cd /home/alice/project alice$ git pull /home/bob/myrepo master

This merges the changes from Bob’s master branch into Alice’s current branch. If Alice has made her own changes in the meantime, then she may need to manually fix any conflicts.

The pull command thus performs two operations: it fetches changes from a remote branch, then merges them into the current branch.

Note that in general, Alice would want her local changes committed before initiating this pull. If Bob’s work conflicts with what Alice did since their histories forked, Alice will use her working tree and the index to resolve conflicts, and existing local changes will interfere with the conflict resolution process (Git will still perform the fetch but will refuse to merge — Alice will have to get rid of her local changes in some way and pull again when this happens).

Alice can peek at what Bob did without merging first, using the fetch command; this allows Alice to inspect what Bob did, using a special symbol FETCH_HEAD, in order to determine if he has anything worth pulling, like this:

alice$ git fetch /home/bob/myrepo master alice$ git log -p HEAD..FETCH_HEAD

This operation is safe even if Alice has uncommitted local changes. The range notation HEAD..FETCH_HEAD means “show everything that is reachable from the FETCH_HEAD but exclude anything that is reachable from HEAD”. Alice already knows everything that leads to her current state (HEAD), and reviews what Bob has in his state (FETCH_HEAD) that she has not seen with this command.

If Alice wants to visualize what Bob did since their histories forked she can issue the following command:

$ gitk HEAD..FETCH_HEAD

This uses the same two-dot range notation we saw earlier with git log.

Alice may want to view what both of them did since they forked. She can use three-dot form instead of the two-dot form:

$ gitk HEAD…FETCH_HEAD

This means “show everything that is reachable from either one, but exclude anything that is reachable from both of them”.

Please note that these range notation can be used with both gitk and git log.

After inspecting what Bob did, if there is nothing urgent, Alice may decide to continue working without pulling from Bob. If Bob’s history does have something Alice would immediately need, Alice may choose to stash her work-in-progress first, do a pull, and then finally unstash her work-in-progress on top of the resulting history.

When you are working in a small closely knit group, it is not unusual to interact with the same repository over and over again. By defining remote repository shorthand, you can make it easier:

alice$ git remote add bob /home/bob/myrepo

With this, Alice can perform the first part of the pull operation alone using the git fetch command without merging them with her own branch, using:

alice$ git fetch bob

Unlike the longhand form, when Alice fetches from Bob using a remote repository shorthand set up with git remote, what was fetched is stored in a remote-tracking branch, in this case bob/master. So after this:

alice$ git log -p master..bob/master

shows a list of all the changes that Bob made since he branched from Alice’s master branch.

After examining those changes, Alice could merge the changes into her master branch:

alice$ git merge bob/master

This merge can also be done by pulling from her own remote-tracking branch, like this:

alice$ git pull . remotes/bob/master

Note that git pull always merges into the current branch, regardless of what else is given on the command line.

Later, Bob can update his repo with Alice’s latest changes using

bob$ git pull

Note that he doesn’t need to give the path to Alice’s repository; when Bob cloned Alice’s repository, Git stored the location of her repository in the repository configuration, and that location is used for pulls:

bob$ git config –get remote.origin.url /home/alice/project

(The complete configuration created by git clone is visible using git config -l, and the git-config(1) man page explains the meaning of each option.)

Git also keeps a pristine copy of Alice’s master branch under the name origin/master:

bob$ git branch -r origin/master

If Bob later decides to work from a different host, he can still perform clones and pulls using the ssh protocol:

bob$ git clone alice.org:/home/alice/project myrepo

Alternatively, Git has a native protocol, or can use http; see git-pull(1) for details.

Git can also be used in a CVS-like mode, with a central repository that various users push changes to; see git-push(1) and gitcvs-migration(7).

EXPLORING HISTORY

Git history is represented as a series of interrelated commits. We have already seen that the git log command can list those commits. Note that first line of each git log entry also gives a name for the commit:

$ git log commit c82a22c39cbc32576f64f5c6b3f24b99ea8149c7 Author: Junio C Hamano [email protected] Date: Tue May 16 17:18:22 2006 -0700

    merge-base: Clarify the comments on post processing.

We can give this name to git show to see the details about this commit.

$ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7

But there are other ways to refer to commits. You can use any initial part of the name that is long enough to uniquely identify the commit:

$ git show c82a22c39c # the first few characters of the name are # usually enough $ git show HEAD # the tip of the current branch $ git show experimental # the tip of the “experimental” branch

Every commit usually has one “parent” commit which points to the previous state of the project:

$ git show HEAD^ # to see the parent of HEAD $ git show HEAD^^ # to see the grandparent of HEAD $ git show HEAD~4 # to see the great-great grandparent of HEAD

Note that merge commits may have more than one parent:

$ git show HEAD^1 # show the first parent of HEAD (same as HEAD^) $ git show HEAD^2 # show the second parent of HEAD

You can also give commits names of your own; after running

$ git tag v2.5 1b2e1d63ff

you can refer to 1b2e1d63ff by the name v2.5. If you intend to share this name with other people (for example, to identify a release version), you should create a “tag” object, and perhaps sign it; see git-tag(1) for details.

Any Git command that needs to know a commit can take any of these names. For example:

$ git diff v2.5 HEAD # compare the current HEAD to v2.5 $ git branch stable v2.5 # start a new branch named “stable” based # at v2.5 $ git reset –hard HEAD^ # reset your current branch and working # directory to its state at HEAD^

Be careful with that last command: in addition to losing any changes in the working directory, it will also remove all later commits from this branch. If this branch is the only branch containing those commits, they will be lost. Also, don’t use git reset on a publicly-visible branch that other developers pull from, as it will force needless merges on other developers to clean up the history. If you need to undo changes that you have pushed, use git revert instead.

The git grep command can search for strings in any version of your project, so

$ git grep “hello” v2.5

searches for all occurrences of “hello” in v2.5.

If you leave out the commit name, git grep will search any of the files it manages in your current directory. So

$ git grep “hello”

is a quick way to search just the files that are tracked by Git.

Many Git commands also take sets of commits, which can be specified in a number of ways. Here are some examples with git log:

$ git log v2.5..v2.6 # commits between v2.5 and v2.6 $ git log v2.5.. # commits since v2.5 $ git log –since=“2 weeks ago” # commits from the last 2 weeks $ git log v2.5.. Makefile # commits since v2.5 which modify # Makefile

You can also give git log a “range” of commits where the first is not necessarily an ancestor of the second; for example, if the tips of the branches stable and master diverged from a common commit some time ago, then

$ git log stable..master

will list commits made in the master branch but not in the stable branch, while

$ git log master..stable

will show the list of commits made on the stable branch but not the master branch.

The git log command has a weakness: it must present commits in a list. When the history has lines of development that diverged and then merged back together, the order in which git log presents those commits is meaningless.

Most projects with multiple contributors (such as the Linux kernel, or Git itself) have frequent merges, and gitk does a better job of visualizing their history. For example,

$ gitk –since=“2 weeks ago” drivers/

allows you to browse any commits from the last 2 weeks of commits that modified files under the drivers directory. (Note: you can adjust gitk’s fonts by holding down the control key while pressing “-” or “+”.)

Finally, most commands that take filenames will optionally allow you to precede any filename by a commit, to specify a particular version of the file:

$ git diff v2.5:Makefile HEAD:Makefile.in

You can also use git show to see any such file:

$ git show v2.5:Makefile

NEXT STEPS

This tutorial should be enough to perform basic distributed revision control for your projects. However, to fully understand the depth and power of Git you need to understand two simple ideas on which it is based:

·

The object database is the rather elegant system used to store the history of your project—files, directories, and commits.

·

The index file is a cache of the state of a directory tree, used to create commits, check out working directories, and hold the various trees involved in a merge.

Part two of this tutorial explains the object database, the index file, and a few other odds and ends that you’ll need to make the most of Git. You can find it at gittutorial-2(7).

If you don’t want to continue with that right away, a few other digressions that may be interesting at this point are:

·

git-format-patch(1), git-am(1): These convert series of git commits into emailed patches, and vice versa, useful for projects such as the Linux kernel which rely heavily on emailed patches.

·

git-bisect(1): When there is a regression in your project, one way to track down the bug is by searching through the history to find the exact commit that’s to blame. git bisect can help you perform a binary search for that commit. It is smart enough to perform a close-to-optimal search even in the case of complex non-linear history with lots of merged branches.

·

gitworkflows(7): Gives an overview of recommended workflows.

·

giteveryday(7): Everyday Git with 20 Commands Or So.

·

gitcvs-migration(7): Git for CVS users.

SEE ALSO

gittutorial-2(7), gitcvs-migration(7), gitcore-tutorial(7), gitglossary(7), git-help(1), gitworkflows(7), giteveryday(7), The Git User’s Manual[1]

GIT

Part of the git(1) suite

NOTES

The Git User’s Manual

file:///usr/share/doc/git/html/user-manual.html

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

491 - Linux cli command file-hierarchy

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command file-hierarchy and provides detailed information about the command file-hierarchy, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the file-hierarchy.

NAME 🖥️ file-hierarchy 🖥️

hierarchy - File system hierarchy overview

DESCRIPTION

Operating systems using the systemd(1) system and service manager are organized based on a file system hierarchy inspired by UNIX, more specifically the hierarchy described in the File System Hierarchy[1] specification and hier(7), with various extensions, partially documented in the XDG Base Directory Specification[2] and XDG User Directories[3]. This manual page describes a more generalized, though minimal and modernized subset of these specifications that defines more strictly the suggestions and restrictions systemd makes on the file system hierarchy.

Many of the paths described here can be queried with the systemd-path(1) tool.

GENERAL STRUCTURE

/

The file system root. Usually writable, but this is not required. Possibly a temporary file system (“tmpfs”). Not shared with other hosts (unless read-only).

/boot/

The boot partition used for bringing up the system. On EFI systems, this is possibly the EFI System Partition (ESP), also see systemd-gpt-auto-generator(8). This directory is usually strictly local to the host, and should be considered read-only, except when a new kernel or boot loader is installed. This directory only exists on systems that run on physical or emulated hardware that requires boot loaders.

/efi/

If the boot partition /boot/ is maintained separately from the EFI System Partition (ESP), the latter is mounted here. Tools that need to operate on the EFI system partition should look for it at this mount point first, and fall back to /boot/ — if the former doesnt qualify (for example if it is not a mount point or does not have the correct file system type MSDOS_SUPER_MAGIC).

/etc/

System-specific configuration. This directory may or may not be read-only. Frequently, this directory is pre-populated with vendor-supplied configuration files, but applications should not make assumptions about this directory being fully populated or populated at all, and should fall back to defaults if configuration is missing.

/home/

The location for normal users home directories. Possibly shared with other systems, and never read-only. This directory should only be used for normal users, never for system users. This directory and possibly the directories contained within it might only become available or writable in late boot or even only after user authentication. This directory might be placed on limited-functionality network file systems, hence applications should not assume the full set of file API is available on this directory. Applications should generally not reference this directory directly, but via the per-user $HOME environment variable, or via the home directory field of the user database.

/root/

The home directory of the root user. The root users home directory is located outside of /home/ in order to make sure the root user may log in even without /home/ being available and mounted.

/srv/

The place to store general server payload, managed by the administrator. No restrictions are made how this directory is organized internally. Generally writable, and possibly shared among systems. This directory might become available or writable only very late during boot.

/tmp/

The place for small temporary files. This directory is usually mounted as a “tmpfs” instance, and should hence not be used for larger files. (Use /var/tmp/ for larger files.) This directory is usually flushed at boot-up. Also, files that are not accessed within a certain time may be automatically deleted.

If applications find the environment variable $TMPDIR set, they should use the directory specified in it instead of /tmp/ (see environ(7) and IEEE Std 1003.1[4] for details).

Since /tmp/ is accessible to other users of the system, it is essential that files and subdirectories under this directory are only created with mkstemp(3), mkdtemp(3), and similar calls. For more details, see Using /tmp/ and /var/tmp/ Safely[5].

RUNTIME DATA

/run/

A “tmpfs” file system for system packages to place runtime data, socket files, and similar. This directory is flushed on boot, and generally writable for privileged programs only. Always writable.

/run/log/

Runtime system logs. System components may place private logs in this directory. Always writable, even when /var/log/ might not be accessible yet.

/run/user/

Contains per-user runtime directories, each usually individually mounted “tmpfs” instances. Always writable, flushed at each reboot and when the user logs out. User code should not reference this directory directly, but via the $XDG_RUNTIME_DIR environment variable, as documented in the XDG Base Directory Specification[2].

VENDOR-SUPPLIED OPERATING SYSTEM RESOURCES

/usr/

Vendor-supplied operating system resources. Usually read-only, but this is not required. Possibly shared between multiple hosts. This directory should not be modified by the administrator, except when installing or removing vendor-supplied packages.

/usr/bin/

Binaries and executables for user commands that shall appear in the $PATH search path. It is recommended not to place binaries in this directory that are not useful for invocation from a shell (such as daemon binaries); these should be placed in a subdirectory of /usr/lib/ instead.

/usr/include/

C and C++ API header files of system libraries.

/usr/lib/

Static, private vendor data that is compatible with all architectures (though not necessarily architecture-independent). Note that this includes internal executables or other binaries that are not regularly invoked from a shell. Such binaries may be for any architecture supported by the system. Do not place public libraries in this directory, use $libdir (see below), instead.

/usr/lib/arch-id/

Location for placing dynamic libraries into, also called $libdir. The architecture identifier to use is defined on Multiarch Architecture Specifiers (Tuples)[6] list. Legacy locations of $libdir are /usr/lib/, /usr/lib64/. This directory should not be used for package-specific data, unless this data is architecture-dependent, too. To query $libdir for the primary architecture of the system, invoke:

systemd-path

        system-library-arch

/usr/share/

Resources shared between multiple packages, such as documentation, man pages, time zone information, fonts and other resources. Usually, the precise location and format of files stored below this directory is subject to specifications that ensure interoperability.

Note that resources placed in this directory typically are under shared ownership, i.e. multiple different packages have provide and consume these resources, on equal footing, without any obvious primary owner. This makes makes things systematically different from /usr/lib/, where ownership is generally not shared.

/usr/share/doc/

Documentation for the operating system or system packages.

/usr/share/factory/etc/

Repository for vendor-supplied default configuration files. This directory should be populated with pristine vendor versions of all configuration files that may be placed in /etc/. This is useful to compare the local configuration of a system with vendor defaults and to populate the local configuration with defaults.

/usr/share/factory/var/

Similar to /usr/share/factory/etc/, but for vendor versions of files in the variable, persistent data directory /var/.

PERSISTENT VARIABLE SYSTEM DATA

/var/

Persistent, variable system data. Writable during normal system operation. This directory might be pre-populated with vendor-supplied data, but applications should be able to reconstruct necessary files and directories in this subhierarchy should they be missing, as the system might start up without this directory being populated. Persistency is recommended, but optional, to support ephemeral systems. This directory might become available or writable only very late during boot. Components that are required to operate during early boot hence shall not unconditionally rely on this directory.

/var/cache/

Persistent system cache data. System components may place non-essential data in this directory. Flushing this directory should have no effect on operation of programs, except for increased runtimes necessary to rebuild these caches.

/var/lib/

Persistent system data. System components may place private data in this directory.

/var/log/

Persistent system logs. System components may place private logs in this directory, though it is recommended to do most logging via the syslog(3) and sd_journal_print(3) calls.

/var/spool/

Persistent system spool data, such as printer or mail queues.

/var/tmp/

The place for larger and persistent temporary files. In contrast to /tmp/, this directory is usually mounted from a persistent physical file system and can thus accept larger files. (Use /tmp/ for small ephemeral files.) This directory is generally not flushed at boot-up, but time-based cleanup of files that have not been accessed for a certain time is applied.

If applications find the environment variable $TMPDIR set, they should use the directory specified in it instead of /var/tmp/ (see environ(7) for details).

The same security restrictions as with /tmp/ apply: mkstemp(3), mkdtemp(3), and similar calls should be used. For further details about this directory, see Using /tmp/ and /var/tmp/ Safely[5].

VIRTUAL KERNEL AND API FILE SYSTEMS

/dev/

The root directory for device nodes. Usually, this directory is mounted as a “devtmpfs” instance, but might be of a different type in sandboxed/containerized setups. This directory is managed jointly by the kernel and systemd-udevd(8), and should not be written to by other components. A number of special purpose virtual file systems might be mounted below this directory.

/dev/shm/

Place for POSIX shared memory segments, as created via shm_open(3). This directory is flushed on boot, and is a “tmpfs” file system. Since all users have write access to this directory, special care should be taken to avoid name clashes and vulnerabilities. For normal users, shared memory segments in this directory are usually deleted when the user logs out. Usually, it is a better idea to use memory mapped files in /run/ (for system programs) or $XDG_RUNTIME_DIR (for user programs) instead of POSIX shared memory segments, since these directories are not world-writable and hence not vulnerable to security-sensitive name clashes.

/proc/

A virtual kernel file system exposing the process list and other functionality. This file system is mostly an API to interface with the kernel and not a place where normal files may be stored. For details, see proc(5). A number of special purpose virtual file systems might be mounted below this directory.

/proc/sys/

A hierarchy below /proc/ that exposes a number of kernel tunables. The primary way to configure the settings in this API file tree is via sysctl.d(5) files. In sandboxed/containerized setups, this directory is generally mounted read-only.

/sys/

A virtual kernel file system exposing discovered devices and other functionality. This file system is mostly an API to interface with the kernel and not a place where normal files may be stored. In sandboxed/containerized setups, this directory is generally mounted read-only. A number of special purpose virtual file systems might be mounted below this directory.

/sys/fs/cgroup/

A virtual kernel file system exposing process control groups (cgroups). This file system is an API to interface with the kernel and not a place where normal files may be stored. On current systems running in the default “unified” mode, this directory serves as the mount point for the “cgroup2” filesystem, which provides a unified cgroup hierarchy for all resource controllers. On systems with non-default configurations, this directory may instead be a tmpfs filesystem containing mount points for various “cgroup” (v1) resource controllers; in such configurations, if “cgroup2” is mounted it will be mounted on /sys/fs/cgroup/unified/, but cgroup2 will not have resource controllers attached. In sandboxed/containerized setups, this directory may either not exist or may include a subset of functionality.

COMPATIBILITY SYMLINKS

/bin/, /sbin/, /usr/sbin/

These compatibility symlinks point to /usr/bin/, ensuring that scripts and binaries referencing these legacy paths correctly find their binaries.

/lib/

This compatibility symlink points to /usr/lib/, ensuring that programs referencing this legacy path correctly find their resources.

/lib64/

On some architecture ABIs, this compatibility symlink points to $libdir, ensuring that binaries referencing this legacy path correctly find their dynamic loader. This symlink only exists on architectures whose ABI places the dynamic loader in this path.

/var/run/

This compatibility symlink points to /run/, ensuring that programs referencing this legacy path correctly find their runtime data.

HOME DIRECTORY

User applications may want to place files and directories in the users home directory. They should follow the following basic structure. Note that some of these directories are also standardized (though more weakly) by the XDG Base Directory Specification[2]. Additional locations for high-level user resources are defined by xdg-user-dirs[3].

~/.cache/

Persistent user cache data. User programs may place non-essential data in this directory. Flushing this directory should have no effect on operation of programs, except for increased runtimes necessary to rebuild these caches. If an application finds $XDG_CACHE_HOME set, it should use the directory specified in it instead of this directory.

~/.config/

Application configuration. When a new user is created, this directory will be empty or not exist at all. Applications should fall back to defaults should their configuration in this directory be missing. If an application finds $XDG_CONFIG_HOME set, it should use the directory specified in it instead of this directory.

~/.local/bin/

Executables that shall appear in the users $PATH search path. It is recommended not to place executables in this directory that are not useful for invocation from a shell; these should be placed in a subdirectory of ~/.local/lib/ instead. Care should be taken when placing architecture-dependent binaries in this place, which might be problematic if the home directory is shared between multiple hosts with different architectures.

~/.local/lib/

Static, private vendor data that is compatible with all architectures.

~/.local/lib/arch-id/

Location for placing public dynamic libraries. The architecture identifier to use is defined on Multiarch Architecture Specifiers (Tuples)[6] list.

~/.local/share/

Resources shared between multiple packages, such as fonts or artwork. Usually, the precise location and format of files stored below this directory is subject to specifications that ensure interoperability. If an application finds $XDG_DATA_HOME set, it should use the directory specified in it instead of this directory.

~/.local/state/

Application state. When a new user is created, this directory will be empty or not exist at all. Applications should fall back to defaults should their state in this directory be missing. If an application finds $XDG_STATE_HOME set, it should use the directory specified in it instead of this directory.

WRITE ACCESS

Unprivileged Write Access

Unprivileged processes generally lack write access to most of the hierarchy.

The exceptions for normal users are /tmp/, /var/tmp/, /dev/shm/, as well as the home directory $HOME (usually found below /home/) and the runtime directory $XDG_RUNTIME_DIR (found below /run/user/) of the user, which are all writable.

For unprivileged system processes, only /tmp/, /var/tmp/ and /dev/shm/ are writable. If an unprivileged system process needs a private writable directory in /var/ or /run/, it is recommended to either create it before dropping privileges in the daemon code, to create it via tmpfiles.d(5) fragments during boot, or via the StateDirectory= and RuntimeDirectory= directives of service units (see systemd.unit(5) for details).

/tmp/, /var/tmp/ and /dev/shm/ should be mounted nosuid and nodev, which means that set-user-id mode and character or block special devices are not interpreted on those file systems. In general it is not possible to mount them noexec, because various programs use those directories for dynamically generated or optimized code, and with that flag those use cases would break. Using this flag is OK on special-purpose installations or systems where all software that may be installed is known and doesnt require such functionality. See the discussion of nosuid/nodev/noexec in mount(8) and PROT_EXEC in mmap(2).

Lack of Write Access on Read-Only Systems and during System Recovery

As noted above, some systems operate with the /usr and /etc hierarchies mounted read-only, possibly only allowing write access during package upgrades. Other part of the hierarchy are generally mounted read-write (in particular /var and /var/tmp), but may be read-only when the kernel remounts the file system read-only in response to errors, or when the system is booted read-only for recovery purposes. To the extent reasonable, applications should be prepared to execute without write access, so that for example, failure to save non-essential data to /var/cache/ or failure to create a custom log file under /var/log does not prevent the application from running.

The /run/ directory is available since the earliest boot and is always writable. It should be used for any runtime data and sockets, so that write access to e.g. /etc or /var is not needed.

NODE TYPES

Unix file systems support different types of file nodes, including regular files, directories, symlinks, character and block device nodes, sockets and FIFOs.

It is strongly recommended that /dev/ is the only location below which device nodes shall be placed. Similarly, /run/ shall be the only location to place sockets and FIFOs. Regular files, directories and symlinks may be used in all directories.

SYSTEM PACKAGES

Developers of system packages should follow strict rules when placing their files in the file system. The following table lists recommended locations for specific types of files supplied by the vendor.

Table 1. System package vendor files locations

DirectoryPurpose
/usr/bin/Package executables that shall appear in the $PATH executable search path, compiled for any of the supported architectures compatible with the operating system. It is not recommended to place internal binaries or binaries that are not commonly invoked from the shell in this directory, such as daemon binaries. As this directory is shared with most other packages of the system, special care should be taken to pick unique names for files placed here, that are unlikely to clash with other packages files.
/usr/lib/arch-id/Public shared libraries of the package. As above, be careful with using too generic names, and pick unique names for your libraries to place here to avoid name clashes.
/usr/lib/package/Private static vendor resources of the package, including private binaries and libraries, or any other kind of read-only vendor data.
/usr/lib/arch-id/package/Private other vendor resources of the package that are architecture-specific and cannot be shared between architectures. Note that this generally does not include private executables since binaries of a specific architecture may be freely invoked from any other supported system architecture.
/usr/include/package/Public C/C++ APIs of public shared libraries of the package.

Additional static vendor files with shared ownership may be installed in the /usr/share/ hierarchy to the locations defined by the various relevant specifications.

The following directories shall be used by the package for local configuration and files created during runtime:

Table 2. System package variable files locations

DirectoryPurpose
/etc/package/System-specific configuration for the package. It is recommended to default to safe fallbacks if this configuration is missing, if this is possible. Alternatively, a tmpfiles.d(5) fragment may be used to copy or symlink the necessary files and directories from /usr/share/factory/ during boot, via the "L" or "C" directives.
/run/package/Runtime data for the package. Packages must be able to create the necessary subdirectories in this tree on their own, since the directory is flushed automatically on boot. Alternatively, a tmpfiles.d(5) fragment may be used to create the necessary directories during boot, or the RuntimeDirectory= directive of service units may be used to create them at service startup (see systemd.unit(5) for details).
/run/log/package/Runtime log data for the package. As above, the package needs to make sure to create this directory if necessary, as it will be flushed on every boot.
/var/cache/package/Persistent cache data of the package. If this directory is flushed, the application should work correctly on next invocation, though possibly slowed down due to the need to rebuild any local cache files. The application must be capable of recreating this directory should it be missing and necessary. To create an empty directory, a tmpfiles.d(5) fragment or the CacheDirectory= directive of service units (see systemd.unit(5)) may be used.
/var/lib/package/Persistent private data of the package. This is the primary place to put persistent data that does not fall into the other categories listed. Packages should be able to create the necessary subdirectories in this tree on their own, since the directory might be missing on boot. To create an empty directory, a tmpfiles.d(5) fragment or the StateDirectory= directive of service units (see systemd.unit(5)) may be used.
/var/log/package/Persistent log data of the package. As above, the package should make sure to create this directory if necessary, possibly using tmpfiles.d(5) or LogsDirectory= (see systemd.exec(5)), as it might be missing.
/var/spool/package/Persistent spool/queue data of the package. As above, the package should make sure to create this directory if necessary, as it might be missing.

USER PACKAGES

Programs running in user context should follow strict rules when placing their own files in the users home directory. The following table lists recommended locations in the home directory for specific types of files supplied by the vendor if the application is installed in the home directory. (User applications installed system-wide are covered by the rules outlined above for vendor files.)

Table 3. Vendor package file locations under the home directory of the user

DirectoryPurpose
~/.local/bin/Package executables that shall appear in the $PATH executable search path. It is not recommended to place internal executables or executables that are not commonly invoked from the shell in this directory, such as daemon executables. As this directory is shared with most other packages of the user, special care should be taken to pick unique names for files placed here, that are unlikely to clash with other packages files.
~/.local/lib/arch-id/Public shared libraries of the package. As above, be careful with using overly generic names, and pick unique names for your libraries to place here to avoid name clashes.
~/.local/lib/package/Private, static vendor resources of the package, compatible with any architecture, or any other kind of read-only vendor data.
~/.local/lib/arch-id/package/Private other vendor resources of the package that are architecture-specific and cannot be shared between architectures.

Additional static vendor files with shared ownership may be installed in the ~/.local/share/ hierarchy, mirroring the subdirectories specified in the section “Vendor-supplied operating system resources” above.

The following directories shall be used by the package for per-user local configuration and files created during runtime:

Table 4. User package variable file locations

DirectoryPurpose
~/.config/package/User-specific configuration for the package. It is required to default to safe fallbacks if this configuration is missing.
$XDG_RUNTIME_DIR/package/User runtime data for the package.
~/.cache/package/Persistent cache data of the package. If this directory is flushed, the application should work correctly on next invocation, though possibly slowed down due to the need to rebuild any local cache files. The application must be capable of recreating this directory should it be missing and necessary.
~/.local/state/package/Persistent state data of the package.

SEE ALSO

systemd(1), hier(7), systemd-path(1), systemd-gpt-auto-generator(8), sysctl.d(5), tmpfiles.d(5), pkg-config(1), systemd.unit(5)

NOTES

File System Hierarchy

http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html

XDG Base Directory Specification

https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

XDG User Directories

https://www.freedesktop.org/wiki/Software/xdg-user-dirs

IEEE Std 1003.1

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03

Using /tmp/ and /var/tmp/ Safely

https://systemd.io/TEMPORARY_DIRECTORIES

Multiarch Architecture Specifiers (Tuples)

https://wiki.debian.org/Multiarch/Tuples

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

492 - Linux cli command utf8

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command utf8 and provides detailed information about the command utf8, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the utf8.

NAME 🖥️ utf8 🖥️

8 - an ASCII compatible multibyte Unicode encoding

DESCRIPTION

The Unicode 3.0 character set occupies a 16-bit code space. The most obvious Unicode encoding (known as UCS-2) consists of a sequence of 16-bit words. Such strings can contain—as part of many 16-bit characters—bytes such as ‘�’ or ‘/’, which have a special meaning in filenames and other C library function arguments. In addition, the majority of UNIX tools expect ASCII files and can’t read 16-bit words as characters without major modifications. For these reasons, UCS-2 is not a suitable external encoding of Unicode in filenames, text files, environment variables, and so on. The ISO/IEC 10646 Universal Character Set (UCS), a superset of Unicode, occupies an even larger code space—31 bits—and the obvious UCS-4 encoding for it (a sequence of 32-bit words) has the same problems.

The UTF-8 encoding of Unicode and UCS does not have these problems and is the common way in which Unicode is used on UNIX-style operating systems.

Properties

The UTF-8 encoding has the following nice properties:

  • UCS characters 0x00000000 to 0x0000007f (the classic US-ASCII characters) are encoded simply as bytes 0x00 to 0x7f (ASCII compatibility). This means that files and strings which contain only 7-bit ASCII characters have the same encoding under both ASCII and UTF-8.

  • All UCS characters greater than 0x7f are encoded as a multibyte sequence consisting only of bytes in the range 0x80 to 0xfd, so no ASCII byte can appear as part of another character and there are no problems with, for example, ‘�’ or ‘/’.

  • The lexicographic sorting order of UCS-4 strings is preserved.

  • All possible 2^31 UCS codes can be encoded using UTF-8.

  • The bytes 0xc0, 0xc1, 0xfe, and 0xff are never used in the UTF-8 encoding.

  • The first byte of a multibyte sequence which represents a single non-ASCII UCS character is always in the range 0xc2 to 0xfd and indicates how long this multibyte sequence is. All further bytes in a multibyte sequence are in the range 0x80 to 0xbf. This allows easy resynchronization and makes the encoding stateless and robust against missing bytes.

  • UTF-8 encoded UCS characters may be up to six bytes long, however the Unicode standard specifies no characters above 0x10ffff, so Unicode characters can be only up to four bytes long in UTF-8.

Encoding

The following byte sequences are used to represent a character. The sequence to be used depends on the UCS code number of the character:

0x00000000 - 0x0000007F:
0xxxxxxx

0x00000080 - 0x000007FF:
110xxxxx 10xxxxxx

0x00000800 - 0x0000FFFF:
1110xxxx 10xxxxxx 10xxxxxx

0x00010000 - 0x001FFFFF:
11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

0x00200000 - 0x03FFFFFF:
111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

0x04000000 - 0x7FFFFFFF:
1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

The xxx bit positions are filled with the bits of the character code number in binary representation, most significant bit first (big-endian). Only the shortest possible multibyte sequence which can represent the code number of the character can be used.

The UCS code values 0xd800–0xdfff (UTF-16 surrogates) as well as 0xfffe and 0xffff (UCS noncharacters) should not appear in conforming UTF-8 streams. According to RFC 3629 no point above U+10FFFF should be used, which limits characters to four bytes.

Example

The Unicode character 0xa9 = 1010 1001 (the copyright sign) is encoded in UTF-8 as

11000010 10101001 = 0xc2 0xa9

and character 0x2260 = 0010 0010 0110 0000 (the “not equal” symbol) is encoded as:

11100010 10001001 10100000 = 0xe2 0x89 0xa0

Application notes

Users have to select a UTF-8 locale, for example with

export LANG=en_GB.UTF-8

in order to activate the UTF-8 support in applications.

Application software that has to be aware of the used character encoding should always set the locale with for example

setlocale(LC_CTYPE, “”)

and programmers can then test the expression

strcmp(nl_langinfo(CODESET), “UTF-8”) == 0

to determine whether a UTF-8 locale has been selected and whether therefore all plaintext standard input and output, terminal communication, plaintext file content, filenames, and environment variables are encoded in UTF-8.

Programmers accustomed to single-byte encodings such as US-ASCII or ISO/IEC 8859 have to be aware that two assumptions made so far are no longer valid in UTF-8 locales. Firstly, a single byte does not necessarily correspond any more to a single character. Secondly, since modern terminal emulators in UTF-8 mode also support Chinese, Japanese, and Korean double-width characters as well as nonspacing combining characters, outputting a single character does not necessarily advance the cursor by one position as it did in ASCII. Library functions such as mbsrtowcs(3) and wcswidth(3) should be used today to count characters and cursor positions.

The official ESC sequence to switch from an ISO/IEC 2022 encoding scheme (as used for instance by VT100 terminals) to UTF-8 is ESC % G (“%G”). The corresponding return sequence from UTF-8 to ISO/IEC 2022 is ESC % @ (“%@”). Other ISO/IEC 2022 sequences (such as for switching the G0 and G1 sets) are not applicable in UTF-8 mode.

Security

The Unicode and UCS standards require that producers of UTF-8 shall use the shortest form possible, for example, producing a two-byte sequence with first byte 0xc0 is nonconforming. Unicode 3.1 has added the requirement that conforming programs must not accept non-shortest forms in their input. This is for security reasons: if user input is checked for possible security violations, a program might check only for the ASCII version of “/../” or “;” or NUL and overlook that there are many non-ASCII ways to represent these things in a non-shortest UTF-8 encoding.

Standards

ISO/IEC 10646-1:2000, Unicode 3.1, RFC 3629, Plan 9.

SEE ALSO

locale(1), nl_langinfo(3), setlocale(3), charsets(7), unicode(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

493 - Linux cli command CREATE_DATABASE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_DATABASE and provides detailed information about the command CREATE_DATABASE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_DATABASE.

NAME 🖥️ CREATE_DATABASE 🖥️

create a new database

SYNOPSIS

CREATE DATABASE name
    [ WITH ] [ OWNER [=] user_name ]
           [ TEMPLATE [=] template ]
           [ ENCODING [=] encoding ]
           [ STRATEGY [=] strategy ]
           [ LOCALE [=] locale ]
           [ LC_COLLATE [=] lc_collate ]
           [ LC_CTYPE [=] lc_ctype ]
           [ ICU_LOCALE [=] icu_locale ]
           [ ICU_RULES [=] icu_rules ]
           [ LOCALE_PROVIDER [=] locale_provider ]
           [ COLLATION_VERSION = collation_version ]
           [ TABLESPACE [=] tablespace_name ]
           [ ALLOW_CONNECTIONS [=] allowconn ]
           [ CONNECTION LIMIT [=] connlimit ]
           [ IS_TEMPLATE [=] istemplate ]
           [ OID [=] oid ]

DESCRIPTION

CREATE DATABASE creates a new PostgreSQL database.

To create a database, you must be a superuser or have the special CREATEDB privilege. See CREATE ROLE (CREATE_ROLE(7)).

By default, the new database will be created by cloning the standard system database template1. A different template can be specified by writing TEMPLATE name. In particular, by writing TEMPLATE template0, you can create a pristine database (one where no user-defined objects exist and where the system objects have not been altered) containing only the standard objects predefined by your version of PostgreSQL. This is useful if you wish to avoid copying any installation-local objects that might have been added to template1.

PARAMETERS

name

The name of a database to create.

user_name

The role name of the user who will own the new database, or DEFAULT to use the default (namely, the user executing the command). To create a database owned by another role, you must be able to SET ROLE to that role.

template

The name of the template from which to create the new database, or DEFAULT to use the default template (template1).

encoding

Character set encoding to use in the new database. Specify a string constant (e.g., SQL_ASCII), or an integer encoding number, or DEFAULT to use the default encoding (namely, the encoding of the template database). The character sets supported by the PostgreSQL server are described in Section 24.3.1. See below for additional restrictions.

strategy

Strategy to be used in creating the new database. If the WAL_LOG strategy is used, the database will be copied block by block and each block will be separately written to the write-ahead log. This is the most efficient strategy in cases where the template database is small, and therefore it is the default. The older FILE_COPY strategy is also available. This strategy writes a small record to the write-ahead log for each tablespace used by the target database. Each such record represents copying an entire directory to a new location at the filesystem level. While this does reduce the write-ahead log volume substantially, especially if the template database is large, it also forces the system to perform a checkpoint both before and after the creation of the new database. In some situations, this may have a noticeable negative impact on overall system performance.

locale

Sets the default collation order and character classification in the new database. Collation affects the sort order applied to strings, e.g., in queries with ORDER BY, as well as the order used in indexes on text columns. Character classification affects the categorization of characters, e.g., lower, upper, and digit. Also sets the associated aspects of the operating system environment, LC_COLLATE and LC_CTYPE. The default is the same setting as the template database. See Section 24.2.2.3.1 and Section 24.2.2.3.2 for details.

Can be overridden by setting lc_collate, lc_ctype, or icu_locale individually.

Tip

The other locale settings lc_messages, lc_monetary, lc_numeric, and lc_time are not fixed per database and are not set by this command. If you want to make them the default for a specific database, you can use ALTER DATABASE … SET.

lc_collate

Sets LC_COLLATE in the database servers operating system environment. The default is the setting of locale if specified, otherwise the same setting as the template database. See below for additional restrictions.

If locale_provider is libc, also sets the default collation order to use in the new database, overriding the setting locale.

lc_ctype

Sets LC_CTYPE in the database servers operating system environment. The default is the setting of locale if specified, otherwise the same setting as the template database. See below for additional restrictions.

If locale_provider is libc, also sets the default character classification to use in the new database, overriding the setting locale.

icu_locale

Specifies the ICU locale (see Section 24.2.2.3.2) for the database default collation order and character classification, overriding the setting locale. The locale provider must be ICU. The default is the setting of locale if specified; otherwise the same setting as the template database.

icu_rules

Specifies additional collation rules to customize the behavior of the default collation of this database. This is supported for ICU only. See Section 24.2.3.4 for details.

locale_provider

Specifies the provider to use for the default collation in this database. Possible values are icu (if the server was built with ICU support) or libc. By default, the provider is the same as that of the template. See Section 24.1.4 for details.

collation_version

Specifies the collation version string to store with the database. Normally, this should be omitted, which will cause the version to be computed from the actual version of the database collation as provided by the operating system. This option is intended to be used by pg_upgrade for copying the version from an existing installation.

See also ALTER DATABASE (ALTER_DATABASE(7)) for how to handle database collation version mismatches.

tablespace_name

The name of the tablespace that will be associated with the new database, or DEFAULT to use the template databases tablespace. This tablespace will be the default tablespace used for objects created in this database. See CREATE TABLESPACE (CREATE_TABLESPACE(7)) for more information.

allowconn

If false then no one can connect to this database. The default is true, allowing connections (except as restricted by other mechanisms, such as GRANT/REVOKE CONNECT).

connlimit

How many concurrent connections can be made to this database. -1 (the default) means no limit.

istemplate

If true, then this database can be cloned by any user with CREATEDB privileges; if false (the default), then only superusers or the owner of the database can clone it.

oid

The object identifier to be used for the new database. If this parameter is not specified, PostgreSQL will choose a suitable OID automatically. This parameter is primarily intended for internal use by pg_upgrade, and only pg_upgrade can specify a value less than 16384.

Optional parameters can be written in any order, not only the order illustrated above.

NOTES

CREATE DATABASE cannot be executed inside a transaction block.

Errors along the line of “could not initialize database directory” are most likely related to insufficient permissions on the data directory, a full disk, or other file system problems.

Use DROP DATABASE to remove a database.

The program createdb(1) is a wrapper program around this command, provided for convenience.

Database-level configuration parameters (set via ALTER DATABASE) and database-level permissions (set via GRANT) are not copied from the template database.

Although it is possible to copy a database other than template1 by specifying its name as the template, this is not (yet) intended as a general-purpose “COPY DATABASE” facility. The principal limitation is that no other sessions can be connected to the template database while it is being copied. CREATE DATABASE will fail if any other connection exists when it starts; otherwise, new connections to the template database are locked out until CREATE DATABASE completes. See Section 23.3 for more information.

The character set encoding specified for the new database must be compatible with the chosen locale settings (LC_COLLATE and LC_CTYPE). If the locale is C (or equivalently POSIX), then all encodings are allowed, but for other locale settings there is only one encoding that will work properly. (On Windows, however, UTF-8 encoding can be used with any locale.) CREATE DATABASE will allow superusers to specify SQL_ASCII encoding regardless of the locale settings, but this choice is deprecated and may result in misbehavior of character-string functions if data that is not encoding-compatible with the locale is stored in the database.

The encoding and locale settings must match those of the template database, except when template0 is used as template. This is because other databases might contain data that does not match the specified encoding, or might contain indexes whose sort ordering is affected by LC_COLLATE and LC_CTYPE. Copying such data would result in a database that is corrupt according to the new settings. template0, however, is known to not contain any data or indexes that would be affected.

There is currently no option to use a database locale with nondeterministic comparisons (see CREATE COLLATION for an explanation). If this is needed, then per-column collations would need to be used.

The CONNECTION LIMIT option is only enforced approximately; if two new sessions start at about the same time when just one connection “slot” remains for the database, it is possible that both will fail. Also, the limit is not enforced against superusers or background worker processes.

EXAMPLES

To create a new database:

CREATE DATABASE lusiadas;

To create a database sales owned by user salesapp with a default tablespace of salesspace:

CREATE DATABASE sales OWNER salesapp TABLESPACE salesspace;

To create a database music with a different locale:

CREATE DATABASE music LOCALE sv_SE.utf8 TEMPLATE template0;

In this example, the TEMPLATE template0 clause is required if the specified locale is different from the one in template1. (If it is not, then specifying the locale explicitly is redundant.)

To create a database music2 with a different locale and a different character set encoding:

CREATE DATABASE music2 LOCALE sv_SE.iso885915 ENCODING LATIN9 TEMPLATE template0;

The specified locale and encoding settings must match, or an error will be reported.

Note that locale names are specific to the operating system, so that the above commands might not work in the same way everywhere.

COMPATIBILITY

There is no CREATE DATABASE statement in the SQL standard. Databases are equivalent to catalogs, whose creation is implementation-defined.

SEE ALSO

ALTER DATABASE (ALTER_DATABASE(7)), DROP DATABASE (DROP_DATABASE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

494 - Linux cli command ossl-guide-libraries-introductionssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ossl-guide-libraries-introductionssl and provides detailed information about the command ossl-guide-libraries-introductionssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ossl-guide-libraries-introductionssl.

NAME 🖥️ ossl-guide-libraries-introductionssl 🖥️

guide-libraries-introduction - OpenSSL Guide: An introduction to the OpenSSL libraries

INTRODUCTION

OpenSSL supplies two libraries that can be used by applications known as libcrypto and libssl.

The libcrypto library provides APIs for general purpose cryptography such as encryption, digital signatures, hash functions, etc. It additionally supplies supporting APIs for cryptography related standards, e.g. for reading and writing digital certificates (also known as X.509 certificates). Finally it also supplies various additional supporting APIs that are not directly cryptography related but are nonetheless useful and depended upon by other APIs. For example the “BIO” functions provide capabilities for abstracting I/O, e.g. via a file or over a network.

The libssl library provides functions to perform secure communication between two peers across a network. Most significantly it implements support for the SSL/TLS, DTLS and QUIC standards.

The libssl library depends on and uses many of the capabilities supplied by libcrypto. Any application linked against libssl will also link against libcrypto, and most applications that do this will directly use API functions supplied by both libraries.

Applications may be written that only use libcrypto capabilities and do not link against libssl at all.

PROVIDERS

As well as the two main libraries, OpenSSL also comes with a set of providers.

A provider in OpenSSL is a component that collects together algorithm implementations (for example an implementation of the symmetric encryption algorithm AES). In order to use an algorithm you must have at least one provider loaded that contains an implementation of it. OpenSSL comes with a number of providers and they may also be obtained from third parties.

Providers may either be “built-in” or in the form of a separate loadable module file (typically one ending in “.so” or “.dll” dependent on the platform). A built-in provider is one that is either already present in libcrypto or one that the application has supplied itself directly. Third parties can also supply providers in the form of loadable modules.

If you don’t load a provider explicitly (either in program code or via config) then the OpenSSL built-in “default” provider will be automatically loaded.

See “OPENSSL PROVIDERS” below for a description of the providers that OpenSSL itself supplies.

Loading and unloading providers is quite an expensive operation. It is normally done once, early on in the application lifecycle and those providers are kept loaded for the duration of the application execution.

LIBRARY CONTEXTS

Many OpenSSL API functions make use of a library context. A library context can be thought of as a “scope” within which configuration options take effect. When a provider is loaded, it is only loaded within the scope of a given library context. In this way it is possible for different components of a complex application to each use a different library context and have different providers loaded with different configuration settings.

If an application does not explicitly create a library context then the “default” library context will be used.

Library contexts are represented by the OSSL_LIB_CTX type. Many OpenSSL API functions take a library context as a parameter. Applications can always pass NULL for this parameter to just use the default library context.

The default library context is automatically created the first time it is needed. This will automatically load any available configuration file and will initialise OpenSSL for use. Unlike in earlier versions of OpenSSL (prior to 1.1.0) no explicit initialisation steps need to be taken.

Similarly when the application exits, the default library context is automatically destroyed. No explicit de-initialisation steps need to be taken.

See OSSL_LIB_CTX (3) for more information about library contexts. See also “ALGORITHM FETCHING” in ossl-guide-libcrypto-introduction (7).

PROPERTY QUERY STRINGS

In some cases the available providers may mean that more than one implementation of any given algorithm might be available. For example the OpenSSL FIPS provider supplies alternative implementations of many of the same algorithms that are available in the OpenSSL default provider.

The process of selecting an algorithm implementation is known as “fetching”. When OpenSSL fetches an algorithm to use it is possible to specify a “property query string” to guide the selection process. For example a property query string of “provider=default” could be used to force the selection to only consider algorithm implementations in the default provider.

Property query strings can be specified explicitly as an argument to a function. It is also possible to specify a default property query string for the whole library context using the EVP_set_default_properties (3) or EVP_default_properties_enable_fips (3) functions. Where both default properties and function specific properties are specified then they are combined. Function specific properties will override default properties where there is a conflict.

See “ALGORITHM FETCHING” in ossl-guide-libcrypto-introduction (7) for more information about fetching. See property (7) for more information about properties.

MULTI-THREADED APPLICATIONS

As long as OpenSSL has been built with support for threads (the default case on most platforms) then most OpenSSL functions are thread-safe in the sense that it is safe to call the same function from multiple threads at the same time. However most OpenSSL data structures are not thread-safe. For example the BIO_write (3) and BIO_read (3) functions are thread safe. However it would not be thread safe to call BIO_write() from one thread while calling BIO_read() in another where both functions are passed the same BIO object since both of them may attempt to make changes to the same BIO object.

There are exceptions to these rules. A small number of functions are not thread safe at all. Where this is the case this restriction should be noted in the documentation for the function. Similarly some data structures may be partially or fully thread safe. For example it is always safe to use an OSSL_LIB_CTX in multiple threads.

See openssl-threads (7) for a more detailed discussion on OpenSSL threading support.

ERROR HANDLING

Most OpenSSL functions will provide a return value indicating whether the function has been successful or not. It is considered best practice to always check the return value from OpenSSL functions (where one is available).

Most functions that return a pointer value will return NULL in the event of a failure.

Most functions that return an integer value will return a positive integer for success. Some of these functions will return 0 to indicate failure. Others may return 0 or a negative value for failure.

Some functions cannot fail and have a void return type. There are also a small number of functions that do not conform to the above conventions (e.g. they may return 0 to indicate success).

Due to the above variations in behaviour it is important to check the documentation for each function for information about how to interpret the return value for it.

It is sometimes necessary to get further information about the cause of a failure (e.g. for debugging or logging purposes). Many (but not all) functions will add further information about a failure to the OpenSSL error stack. By using the error stack you can find out information such as a reason code/string for the error as well as the exact file and source line within OpenSSL that emitted the error.

OpenSSL supplies a set of error handling functions to query the error stack. See ERR_get_error (3) for information about the functions available for querying error data. Also see ERR_print_errors (3) for information on some simple helper functions for printing error data. Finally look at ERR_clear_error (3) for how to clear old errors from the error stack.

OPENSSL PROVIDERS

OpenSSL comes with a set of providers.

The algorithms available in each of these providers may vary due to build time configuration options. The openssl-list (1) command can be used to list the currently available algorithms.

The names of the algorithms shown from openssl-list (1) can be used as an algorithm identifier to the appropriate fetching function. Also see the provider specific manual pages linked below for further details about using the algorithms available in each of the providers.

As well as the OpenSSL providers third parties can also implement providers. For information on writing a provider see provider (7).

Default provider

The default provider is built-in as part of the libcrypto library and contains all of the most commonly used algorithm implementations. Should it be needed (if other providers are loaded and offer implementations of the same algorithms), the property query string “provider=default” can be used as a search criterion for these implementations. The default provider includes all of the functionality in the base provider below.

If you don’t load any providers at all then the “default” provider will be automatically loaded. If you explicitly load any provider then the “default” provider would also need to be explicitly loaded if it is required.

See OSSL_PROVIDER-default (7).

Base provider

The base provider is built in as part of the libcrypto library and contains algorithm implementations for encoding and decoding of OpenSSL keys. Should it be needed (if other providers are loaded and offer implementations of the same algorithms), the property query string “provider=base” can be used as a search criterion for these implementations. Some encoding and decoding algorithm implementations are not FIPS algorithm implementations in themselves but support algorithms from the FIPS provider and are allowed for use in “FIPS mode”. The property query string “fips=yes” can be used to select such algorithms.

See OSSL_PROVIDER-base (7).

FIPS provider

The FIPS provider is a dynamically loadable module, and must therefore be loaded explicitly, either in code or through OpenSSL configuration (see config (5)). It contains algorithm implementations that have been validated according to FIPS standards. Should it be needed (if other providers are loaded and offer implementations of the same algorithms), the property query string “provider=fips” can be used as a search criterion for these implementations. All approved algorithm implementations in the FIPS provider can also be selected with the property “fips=yes”. The FIPS provider may also contain non-approved algorithm implementations and these can be selected with the property “fips=no”.

Typically the “Base provider” will also need to be loaded because the FIPS provider does not support the encoding or decoding of keys.

See OSSL_PROVIDER-FIPS (7) and fips_module (7).

Legacy provider

The legacy provider is a dynamically loadable module, and must therefore be loaded explicitly, either in code or through OpenSSL configuration (see config (5)). It contains algorithm implementations that are considered insecure, or are no longer in common use such as MD2 or RC4. Should it be needed (if other providers are loaded and offer implementations of the same algorithms), the property “provider=legacy” can be used as a search criterion for these implementations.

See OSSL_PROVIDER-legacy (7).

Null provider

The null provider is built in as part of the libcrypto library. It contains no algorithms in it at all. When fetching algorithms the default provider will be automatically loaded if no other provider has been explicitly loaded. To prevent that from happening you can explicitly load the null provider.

You can use this if you create your own library context and want to ensure that all API calls have correctly passed the created library context and are not accidentally using the default library context. Load the null provider into the default library context so that the default library context has no algorithm implementations available.

See OSSL_PROVIDER-null (7).

CONFIGURATION

By default OpenSSL will load a configuration file when it is first used. This will set up various configuration settings within the default library context. Applications that create their own library contexts may optionally configure them with a config file using the OSSL_LIB_CTX_load_config (3) function.

The configuration file can be used to automatically load providers and set up default property query strings.

For information on the OpenSSL configuration file format see config (5).

LIBRARY CONVENTIONS

Many OpenSSL functions that “get” or “set” a value follow a naming convention using the numbers 0 and 1, i.e. “get0”, “get1”, “set0” and “set1”. This can also apply to some functions that “add” a value to an existing set, i.e. “add0” and “add1”.

For example the functions:

int X509_CRL_add0_revoked(X509_CRL *crl, X509_REVOKED *rev); int X509_add1_trust_object(X509 *x, const ASN1_OBJECT *obj);

In the 0 version the ownership of the object is passed to (for an add or set) or retained by (for a get) the parent object. For example after calling the X509_CRL_add0_revoked() function above, ownership of the rev object is passed to the crl object. Therefore, after calling this function rev should not be freed directly. It will be freed implicitly when crl is freed.

In the 1 version the ownership of the object is not passed to or retained by the parent object. Instead a copy or “up ref” of the object is performed. So after calling the X509_add1_trust_object() function above the application will still be responsible for freeing the obj value where appropriate.

Many OpenSSL functions conform to a naming convention of the form CLASSNAME_func_name(). In this naming convention the CLASSNAME is the name of an OpenSSL data structure (given in capital letters) that the function is primarily operating on. The func_name portion of the name is usually in lowercase letters and indicates the purpose of the function.

DEMO APPLICATIONS

OpenSSL is distributed with a set of demo applications which provide some examples of how to use the various API functions. To look at them download the OpenSSL source code from the OpenSSL website (<https://www.openssl.org/source/>). Extract the downloaded .tar.gz file for the version of OpenSSL that you are using and look at the various files in the demos sub-directory.

The Makefiles in the subdirectories give instructions on how to build and run the demo applications.

FURTHER READING

See ossl-guide-libcrypto-introduction (7) for a more detailed introduction to using libcrypto and ossl-guide-libssl-introduction (7) for more information on libssl.

SEE ALSO

openssl (1), ssl (7), evp (7), OSSL_LIB_CTX (3), openssl-threads (7), property (7), OSSL_PROVIDER-default (7), OSSL_PROVIDER-base (7), OSSL_PROVIDER-FIPS (7), OSSL_PROVIDER-legacy (7), OSSL_PROVIDER-null (7), openssl-glossary (7), provider (7)

COPYRIGHT

Copyright 2000-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

495 - Linux cli command cp1252

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command cp1252 and provides detailed information about the command cp1252, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the cp1252.

NAME 🖥️ cp1252 🖥️

CP 1252 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The Windows Code Pages include several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). CP 1252 encodes the characters used in many West European languages.

CP 1252 characters

The following table displays the characters in CP 1252 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

CP 1252 is also known as Windows-1252.

SEE ALSO

ascii(7), charsets(7), cp1251(7), iso_8859-1(7), iso_8859-15(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

496 - Linux cli command iso_8859-5

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso_8859-5 and provides detailed information about the command iso_8859-5, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso_8859-5.

NAME 🖥️ iso_8859-5 🖥️

5 - ISO/IEC 8859-5 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-5 encodes the Cyrillic characters used in many East European languages.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-5 characters

The following table displays the characters in ISO/IEC 8859-5 that are printable and unlisted in the ascii(7) manual page.

TABLE

SEE ALSO

ascii(7), charsets(7), cp1251(7), koi8-r(7), koi8-u(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

497 - Linux cli command user-session-keyring

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command user-session-keyring and provides detailed information about the command user-session-keyring, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the user-session-keyring.

NAME 🖥️ user-session-keyring 🖥️

session-keyring - per-user default session keyring

DESCRIPTION

The user session keyring is a keyring used to anchor keys on behalf of a user. Each UID the kernel deals with has its own user session keyring that is shared by all processes with that UID. The user session keyring has a name (description) of the form _uid_ses.<UID> where <UID> is the user ID of the corresponding user.

The user session keyring is associated with the record that the kernel maintains for the UID. It comes into existence upon the first attempt to access either the user session keyring, the user-keyring(7), or the session-keyring(7). The keyring remains pinned in existence so long as there are processes running with that real UID or files opened by those processes remain open. (The keyring can also be pinned indefinitely by linking it into another keyring.)

The user session keyring is created on demand when a thread requests it or when a thread asks for its session-keyring(7) and that keyring doesn’t exist. In the latter case, a user session keyring will be created and, if the session keyring wasn’t to be created, the user session keyring will be set as the process’s actual session keyring.

The user session keyring is searched by request_key(2) if the actual session keyring does not exist and is ignored otherwise.

A special serial number value, KEY_SPEC_USER_SESSION_KEYRING, is defined that can be used in lieu of the actual serial number of the calling process’s user session keyring.

From the keyctl(1) utility, ‘@us’ can be used instead of a numeric key ID in much the same way.

User session keyrings are independent of clone(2), fork(2), vfork(2), execve(2), and _exit(2) excepting that the keyring is destroyed when the UID record is destroyed when the last process pinning it exits.

If a user session keyring does not exist when it is accessed, it will be created.

Rather than relying on the user session keyring, it is strongly recommended—especially if the process is running as root—that a session-keyring(7) be set explicitly, for example by pam_keyinit(8).

NOTES

The user session keyring was added to support situations where a process doesn’t have a session keyring, perhaps because it was created via a pathway that didn’t involve PAM (e.g., perhaps it was a daemon started by inetd(8)). In such a scenario, the user session keyring acts as a substitute for the session-keyring(7).

SEE ALSO

keyctl(1), keyctl(3), keyrings(7), persistent-keyring(7), process-keyring(7), session-keyring(7), thread-keyring(7), user-keyring(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

498 - Linux cli command DROP_LANGUAGE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_LANGUAGE and provides detailed information about the command DROP_LANGUAGE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_LANGUAGE.

NAME 🖥️ DROP_LANGUAGE 🖥️

remove a procedural language

SYNOPSIS

DROP [ PROCEDURAL ] LANGUAGE [ IF EXISTS ] name [ CASCADE | RESTRICT ]

DESCRIPTION

DROP LANGUAGE removes the definition of a previously registered procedural language. You must be a superuser or the owner of the language to use DROP LANGUAGE.

Note

As of PostgreSQL 9.1, most procedural languages have been made into “extensions”, and should therefore be removed with DROP EXTENSION not DROP LANGUAGE.

PARAMETERS

IF EXISTS

Do not throw an error if the language does not exist. A notice is issued in this case.

name

The name of an existing procedural language.

CASCADE

Automatically drop objects that depend on the language (such as functions in the language), and in turn all objects that depend on those objects (see Section 5.14).

RESTRICT

Refuse to drop the language if any objects depend on it. This is the default.

EXAMPLES

This command removes the procedural language plsample:

DROP LANGUAGE plsample;

COMPATIBILITY

There is no DROP LANGUAGE statement in the SQL standard.

SEE ALSO

ALTER LANGUAGE (ALTER_LANGUAGE(7)), CREATE LANGUAGE (CREATE_LANGUAGE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

499 - Linux cli command session-keyring

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command session-keyring and provides detailed information about the command session-keyring, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the session-keyring.

NAME 🖥️ session-keyring 🖥️

keyring - session shared process keyring

DESCRIPTION

The session keyring is a keyring used to anchor keys on behalf of a process. It is typically created by pam_keyinit(8) when a user logs in and a link will be added that refers to the user-keyring(7). Optionally, PAM(7) may revoke the session keyring on logout. (In typical configurations, PAM does do this revocation.) The session keyring has the name (description) _ses.

A special serial number value, KEY_SPEC_SESSION_KEYRING, is defined that can be used in lieu of the actual serial number of the calling process’s session keyring.

From the keyctl(1) utility, ‘@s’ can be used instead of a numeric key ID in much the same way.

A process’s session keyring is inherited across clone(2), fork(2), and vfork(2). The session keyring is preserved across execve(2), even when the executable is set-user-ID or set-group-ID or has capabilities. The session keyring is destroyed when the last process that refers to it exits.

If a process doesn’t have a session keyring when it is accessed, then, under certain circumstances, the user-session-keyring(7) will be attached as the session keyring and under others a new session keyring will be created. (See user-session-keyring(7) for further details.)

Special operations

The keyutils library provides the following special operations for manipulating session keyrings:

keyctl_join_session_keyring(3)
This operation allows the caller to change the session keyring that it subscribes to. The caller can join an existing keyring with a specified name (description), create a new keyring with a given name, or ask the kernel to create a new “anonymous” session keyring with the name “_ses”. (This function is an interface to the keyctl(2) KEYCTL_JOIN_SESSION_KEYRING operation.)

keyctl_session_to_parent(3)
This operation allows the caller to make the parent process’s session keyring to the same as its own. For this to succeed, the parent process must have identical security attributes and must be single threaded. (This function is an interface to the keyctl(2) KEYCTL_SESSION_TO_PARENT operation.)

These operations are also exposed through the keyctl(1) utility as:

keyctl session
keyctl session - [<prog> <arg1> <arg2> ...]
keyctl session <name> [<prog> <arg1> <arg2> ...]

and:

keyctl new_session

SEE ALSO

keyctl(1), keyctl(3), keyctl_join_session_keyring(3), keyctl_session_to_parent(3), keyrings(7), PAM(7), persistent-keyring(7), process-keyring(7), thread-keyring(7), user-keyring(7), user-session-keyring(7), pam_keyinit(8)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

500 - Linux cli command ALTER_MATERIALIZED_VIEW

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_MATERIALIZED_VIEW and provides detailed information about the command ALTER_MATERIALIZED_VIEW, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_MATERIALIZED_VIEW.

NAME 🖥️ ALTER_MATERIALIZED_VIEW 🖥️

change the definition of a materialized view

SYNOPSIS

ALTER MATERIALIZED VIEW [ IF EXISTS ] name
    action [, ... ]
ALTER MATERIALIZED VIEW name
    [ NO ] DEPENDS ON EXTENSION extension_name
ALTER MATERIALIZED VIEW [ IF EXISTS ] name
    RENAME [ COLUMN ] column_name TO new_column_name
ALTER MATERIALIZED VIEW [ IF EXISTS ] name
    RENAME TO new_name
ALTER MATERIALIZED VIEW [ IF EXISTS ] name
    SET SCHEMA new_schema
ALTER MATERIALIZED VIEW ALL IN TABLESPACE name [ OWNED BY role_name [, ... ] ]
    SET TABLESPACE new_tablespace [ NOWAIT ]

where action is one of:

    ALTER [ COLUMN ] column_name SET STATISTICS integer
    ALTER [ COLUMN ] column_name SET ( attribute_option = value [, ... ] )
    ALTER [ COLUMN ] column_name RESET ( attribute_option [, ... ] )
    ALTER [ COLUMN ] column_name SET STORAGE { PLAIN | EXTERNAL | EXTENDED | MAIN | DEFAULT }
    ALTER [ COLUMN ] column_name SET COMPRESSION compression_method
    CLUSTER ON index_name
    SET WITHOUT CLUSTER
    SET ACCESS METHOD new_access_method
    SET TABLESPACE new_tablespace
    SET ( storage_parameter [= value] [, ... ] )
    RESET ( storage_parameter [, ... ] )
    OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }

DESCRIPTION

ALTER MATERIALIZED VIEW changes various auxiliary properties of an existing materialized view.

You must own the materialized view to use ALTER MATERIALIZED VIEW. To change a materialized views schema, you must also have CREATE privilege on the new schema. To alter the owner, you must be able to SET ROLE to the new owning role, and that role must have CREATE privilege on the materialized views schema. (These restrictions enforce that altering the owner doesnt do anything you couldnt do by dropping and recreating the materialized view. However, a superuser can alter ownership of any view anyway.)

The statement subforms and actions available for ALTER MATERIALIZED VIEW are a subset of those available for ALTER TABLE, and have the same meaning when used for materialized views. See the descriptions for ALTER TABLE for details.

PARAMETERS

name

The name (optionally schema-qualified) of an existing materialized view.

column_name

Name of an existing column.

extension_name

The name of the extension that the materialized view is to depend on (or no longer dependent on, if NO is specified). A materialized view thats marked as dependent on an extension is automatically dropped when the extension is dropped.

new_column_name

New name for an existing column.

new_owner

The user name of the new owner of the materialized view.

new_name

The new name for the materialized view.

new_schema

The new schema for the materialized view.

EXAMPLES

To rename the materialized view foo to bar:

ALTER MATERIALIZED VIEW foo RENAME TO bar;

COMPATIBILITY

ALTER MATERIALIZED VIEW is a PostgreSQL extension.

SEE ALSO

CREATE MATERIALIZED VIEW (CREATE_MATERIALIZED_VIEW(7)), DROP MATERIALIZED VIEW (DROP_MATERIALIZED_VIEW(7)), REFRESH MATERIALIZED VIEW (REFRESH_MATERIALIZED_VIEW(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

501 - Linux cli command OPENSSL_NO_DEPRECATEDssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command OPENSSL_NO_DEPRECATEDssl and provides detailed information about the command OPENSSL_NO_DEPRECATEDssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the OPENSSL_NO_DEPRECATEDssl.

NAME 🖥️ OPENSSL_NO_DEPRECATEDssl 🖥️

User defined macros

DESCRIPTION

User defined macros allow the programmer to control certain aspects of what is exposed by the OpenSSL headers.

NOTE: to be effective, a user defined macro must be defined before including any header file that depends on it, either in the compilation command (cc -DMACRO=value) or by defining the macro in source before including any headers.

Other manual pages may refer to this page when declarations depend on user defined macros.

The macros

OPENSSL_API_COMPAT
The value is a version number, given in one of the following two forms:

“0xMNNFF000L”
This is the form supported for all versions up to 1.1.x, where M represents the major number, NN represents the minor number, and FF represents the fix number, as a hexadecimal number. For version 1.1.0, that’s 0x10100000L. Any version number may be given, but these numbers are the current known major deprecation points, making them the most meaningful:

“0x00908000L” (version 0.9.8)

“0x10000000L” (version 1.0.0)

“0x10100000L” (version 1.1.0)

For convenience, higher numbers are accepted as well, as long as feasible. For example, 0x60000000L will work as expected. However, it is recommended to start using the second form instead:

“mmnnpp”
This form is a simple decimal number calculated with this formula: major * 10000 + minor * 100 + patch where major, minor and patch are the desired major, minor and patch components of the version number. For example:

30000 corresponds to version 3.0.0

10002 corresponds to version 1.0.2

420101 corresponds to version 42.1.1

If OPENSSL_API_COMPAT is undefined, this default value is used in its place: 30200

OPENSSL_NO_DEPRECATED
If this macro is defined, all deprecated public symbols in all OpenSSL versions up to and including the version given by OPENSSL_API_COMPAT (or the default value given above, when OPENSSL_API_COMPAT isn’t defined) will be hidden.

COPYRIGHT

Copyright 2018-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

502 - Linux cli command provider-decoderssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command provider-decoderssl and provides detailed information about the command provider-decoderssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the provider-decoderssl.

NAME 🖥️ provider-decoderssl 🖥️

decoder - The OSSL_DECODER library <-> provider functions

SYNOPSIS

#include <openssl/core_dispatch.h> /* * None of these are actual functions, but are displayed like this for * the function signatures for functions that are offered as function * pointers in OSSL_DISPATCH arrays. */ /* Decoder parameter accessor and descriptor */ const OSSL_PARAM *OSSL_FUNC_decoder_gettable_params(void *provctx); int OSSL_FUNC_decoder_get_params(OSSL_PARAM params[]); /* Functions to construct / destruct / manipulate the decoder context */ void *OSSL_FUNC_decoder_newctx(void *provctx); void OSSL_FUNC_decoder_freectx(void *ctx); const OSSL_PARAM *OSSL_FUNC_decoder_settable_ctx_params(void *provctx); int OSSL_FUNC_decoder_set_ctx_params(void *ctx, const OSSL_PARAM params[]); /* Functions to check selection support */ int OSSL_FUNC_decoder_does_selection(void *provctx, int selection); /* Functions to decode object data */ int OSSL_FUNC_decoder_decode(void *ctx, OSSL_CORE_BIO *in, int selection, OSSL_CALLBACK *data_cb, void *data_cbarg, OSSL_PASSPHRASE_CALLBACK *cb, void *cbarg); /* Functions to export a decoded object */ int OSSL_FUNC_decoder_export_object(void *ctx, const void *objref, size_t objref_sz, OSSL_CALLBACK *export_cb, void *export_cbarg);

DESCRIPTION

The term “decode” is used throughout this manual. This includes but is not limited to deserialization as individual decoders can also do decoding into intermediate data formats.

The DECODER operation is a generic method to create a provider-native object reference or intermediate decoded data from an encoded form read from the given OSSL_CORE_BIO. If the caller wants to decode data from memory, it should provide a BIO_s_mem (3) BIO. The decoded data or object reference is passed along with eventual metadata to the metadata_cb as OSSL_PARAM (3) parameters.

The decoder doesn’t need to know more about the OSSL_CORE_BIO pointer than being able to pass it to the appropriate BIO upcalls (see “Core functions” in provider-base (7)).

The DECODER implementation may be part of a chain, where data is passed from one to the next. For example, there may be an implementation to decode an object from PEM to DER, and another one that decodes DER to a provider-native object.

The last decoding step in the decoding chain is usually supposed to create a provider-native object referenced by an object reference. To import that object into a different provider the OSSL_FUNC_decoder_export_object() can be called as the final step of the decoding process.

All “functions” mentioned here are passed as function pointers between libcrypto and the provider in OSSL_DISPATCH (3) arrays via OSSL_ALGORITHM (3) arrays that are returned by the provider’s provider_query_operation() function (see “Provider Functions” in provider-base (7)).

All these “functions” have a corresponding function type definition named OSSL_FUNC_{name}_fn, and a helper function to retrieve the function pointer from an OSSL_DISPATCH (3) element named OSSL_FUNC_{name}. For example, the “function” OSSL_FUNC_decoder_decode() has these:

typedef int (OSSL_FUNC_decoder_decode_fn)(void *ctx, OSSL_CORE_BIO *in, int selection, OSSL_CALLBACK *data_cb, void *data_cbarg, OSSL_PASSPHRASE_CALLBACK *cb, void *cbarg); static ossl_inline OSSL_FUNC_decoder_decode_fn* OSSL_FUNC_decoder_decode(const OSSL_DISPATCH *opf);

OSSL_DISPATCH (3) arrays are indexed by numbers that are provided as macros in openssl-core_dispatch.h (7), as follows:

OSSL_FUNC_decoder_get_params OSSL_FUNC_DECODER_GET_PARAMS OSSL_FUNC_decoder_gettable_params OSSL_FUNC_DECODER_GETTABLE_PARAMS OSSL_FUNC_decoder_newctx OSSL_FUNC_DECODER_NEWCTX OSSL_FUNC_decoder_freectx OSSL_FUNC_DECODER_FREECTX OSSL_FUNC_decoder_set_ctx_params OSSL_FUNC_DECODER_SET_CTX_PARAMS OSSL_FUNC_decoder_settable_ctx_params OSSL_FUNC_DECODER_SETTABLE_CTX_PARAMS OSSL_FUNC_decoder_does_selection OSSL_FUNC_DECODER_DOES_SELECTION OSSL_FUNC_decoder_decode OSSL_FUNC_DECODER_DECODE OSSL_FUNC_decoder_export_object OSSL_FUNC_DECODER_EXPORT_OBJECT

Names and properties

The name of an implementation should match the target type of object it decodes. For example, an implementation that decodes an RSA key should be named “RSA”. Likewise, an implementation that decodes DER data from PEM input should be named “DER”.

Properties can be used to further specify details about an implementation:

input
This property is used to specify what format of input the implementation can decode. This property is mandatory. OpenSSL providers recognize the following input types:

pem
An implementation with that input type decodes PEM formatted data.

der
An implementation with that input type decodes DER formatted data.

msblob
An implementation with that input type decodes MSBLOB formatted data.

pvk
An implementation with that input type decodes PVK formatted data.

structure
This property is used to specify the structure that the decoded data is expected to have. This property is optional. Structures currently recognised by built-in decoders:

“type-specific”
Type specific structure.

“pkcs8”
Structure according to the PKCS#8 specification.

“SubjectPublicKeyInfo”
Encoding of public keys according to the Subject Public Key Info of RFC 5280.

The possible values of both these properties is open ended. A provider may very well specify input types and structures that libcrypto doesn’t know anything about.

Subset selections

Sometimes, an object has more than one subset of data that is interesting to treat separately or together. It’s possible to specify what subsets are to be decoded, with a set of bits selection that are passed in an int.

This set of bits depend entirely on what kind of provider-side object is to be decoded. For example, those bits are assumed to be the same as those used with provider-keymgmt (7) (see “Key Objects” in provider-keymgmt (7)) when the object is an asymmetric keypair - e.g., OSSL_KEYMGMT_SELECT_PRIVATE_KEY if the object to be decoded is supposed to contain private key components.

OSSL_FUNC_decoder_does_selection() should tell if a particular implementation supports any of the combinations given by selection.

Context functions

OSSL_FUNC_decoder_newctx() returns a context to be used with the rest of the functions.

OSSL_FUNC_decoder_freectx() frees the given ctx as created by OSSL_FUNC_decoder_newctx().

OSSL_FUNC_decoder_set_ctx_params() sets context data according to parameters from params that it recognises. Unrecognised parameters should be ignored. Passing NULL for params should return true.

OSSL_FUNC_decoder_settable_ctx_params() returns a constant OSSL_PARAM (3) array describing the parameters that OSSL_FUNC_decoder_set_ctx_params() can handle.

See OSSL_PARAM (3) for further details on the parameters structure used by OSSL_FUNC_decoder_set_ctx_params() and OSSL_FUNC_decoder_settable_ctx_params().

Export function

When a provider-native object is created by a decoder it would be unsuitable for direct use with a foreign provider. The export function allows for exporting the object into that foreign provider if the foreign provider supports the type of the object and provides an import function.

OSSL_FUNC_decoder_export_object() should export the object of size objref_sz referenced by objref as an OSSL_PARAM (3) array and pass that into the export_cb as well as the given export_cbarg.

Decoding functions

OSSL_FUNC_decoder_decode() should decode the data as read from the OSSL_CORE_BIO in to produce decoded data or an object to be passed as reference in an OSSL_PARAM (3) array along with possible other metadata that was decoded from the input. This OSSL_PARAM (3) array is then passed to the data_cb callback. The selection bits, if relevant, should determine what the input data should contain. The decoding functions also take an OSSL_PASSPHRASE_CALLBACK (3) function pointer along with a pointer to application data cbarg, which should be used when a pass phrase prompt is needed.

It’s important to understand that the return value from this function is interpreted as follows:

True (1)
This means “carry on the decoding process”, and is meaningful even though this function couldn’t decode the input into anything, because there may be another decoder implementation that can decode it into something. The data_cb callback should never be called when this function can’t decode the input into anything.

False (0)
This means “stop the decoding process”, and is meaningful when the input could be decoded into some sort of object that this function understands, but further treatment of that object results into errors that won’t be possible for some other decoder implementation to get a different result.

The conditions to stop the decoding process are at the discretion of the implementation.

Decoder operation parameters

There are currently no operation parameters currently recognised by the built-in decoders.

Parameters currently recognised by the built-in pass phrase callback:

“info” (OSSL_PASSPHRASE_PARAM_INFO) <UTF8 string>
A string of information that will become part of the pass phrase prompt. This could be used to give the user information on what kind of object it’s being prompted for.

RETURN VALUES

OSSL_FUNC_decoder_newctx() returns a pointer to a context, or NULL on failure.

OSSL_FUNC_decoder_set_ctx_params() returns 1, unless a recognised parameter was invalid or caused an error, for which 0 is returned.

OSSL_FUNC_decoder_settable_ctx_params() returns a pointer to an array of constant OSSL_PARAM (3) elements.

OSSL_FUNC_decoder_does_selection() returns 1 if the decoder implementation supports any of the selection bits, otherwise 0.

OSSL_FUNC_decoder_decode() returns 1 to signal that the decoding process should continue, or 0 to signal that it should stop.

SEE ALSO

provider (7)

HISTORY

The DECODER interface was introduced in OpenSSL 3.0.

COPYRIGHT

Copyright 2019-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

503 - Linux cli command EVP_KDF-SCRYPTssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KDF-SCRYPTssl and provides detailed information about the command EVP_KDF-SCRYPTssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KDF-SCRYPTssl.

NAME 🖥️ EVP_KDF-SCRYPTssl 🖥️

SCRYPT - The scrypt EVP_KDF implementation

DESCRIPTION

Support for computing the scrypt password-based KDF through the EVP_KDF API.

The EVP_KDF-SCRYPT algorithm implements the scrypt password-based key derivation function, as described in RFC 7914. It is memory-hard in the sense that it deliberately requires a significant amount of RAM for efficient computation. The intention of this is to render brute forcing of passwords on systems that lack large amounts of main memory (such as GPUs or ASICs) computationally infeasible.

scrypt provides three work factors that can be customized: N, r and p. N, which has to be a positive power of two, is the general work factor and scales CPU time in an approximately linear fashion. r is the block size of the internally used hash function and p is the parallelization factor. Both r and p need to be greater than zero. The amount of RAM that scrypt requires for its computation is roughly (128 * N * r * p) bytes.

In the original paper of Colin Percival (“Stronger Key Derivation via Sequential Memory-Hard Functions”, 2009), the suggested values that give a computation time of less than 5 seconds on a 2.5 GHz Intel Core 2 Duo are N = 2^20 = 1048576, r = 8, p = 1. Consequently, the required amount of memory for this computation is roughly 1 GiB. On a more recent CPU (Intel i7-5930K at 3.5 GHz), this computation takes about 3 seconds. When N, r or p are not specified, they default to 1048576, 8, and 1, respectively. The maximum amount of RAM that may be used by scrypt defaults to 1025 MiB.

Identity

“SCRYPT” is the name for this implementation; it can be used with the EVP_KDF_fetch() function.

Supported parameters

The supported parameters are:

“pass” (OSSL_KDF_PARAM_PASSWORD) <octet string>

“salt” (OSSL_KDF_PARAM_SALT) <octet string>

These parameters work as described in “PARAMETERS” in EVP_KDF (3).

“n” (OSSL_KDF_PARAM_SCRYPT_N) <unsigned integer>

“r” (OSSL_KDF_PARAM_SCRYPT_R) <unsigned integer>

“p” (OSSL_KDF_PARAM_SCRYPT_P) <unsigned integer>

“maxmem_bytes” (OSSL_KDF_PARAM_SCRYPT_MAXMEM) <unsigned integer>

These parameters configure the scrypt work factors N, r, maxmem and p. Both N and maxmem_bytes are parameters of type uint64_t. Both r and p are parameters of type uint32_t.

“properties” (OSSL_KDF_PARAM_PROPERTIES) <UTF8 string>
This can be used to set the property query string when fetching the fixed digest internally. NULL is used if this value is not set.

NOTES

A context for scrypt can be obtained by calling:

EVP_KDF *kdf = EVP_KDF_fetch(NULL, “SCRYPT”, NULL); EVP_KDF_CTX *kctx = EVP_KDF_CTX_new(kdf);

The output length of an scrypt key derivation is specified via the “keylen” parameter to the EVP_KDF_derive (3) function.

EXAMPLES

This example derives a 64-byte long test vector using scrypt with the password “password”, salt “NaCl” and N = 1024, r = 8, p = 16.

EVP_KDF *kdf; EVP_KDF_CTX *kctx; unsigned char out[64]; OSSL_PARAM params[6], *p = params; kdf = EVP_KDF_fetch(NULL, “SCRYPT”, NULL); kctx = EVP_KDF_CTX_new(kdf); EVP_KDF_free(kdf); *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_PASSWORD, “password”, (size_t)8); *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_SALT, “NaCl”, (size_t)4); *p++ = OSSL_PARAM_construct_uint64(OSSL_KDF_PARAM_SCRYPT_N, (uint64_t)1024); *p++ = OSSL_PARAM_construct_uint32(OSSL_KDF_PARAM_SCRYPT_R, (uint32_t)8); *p++ = OSSL_PARAM_construct_uint32(OSSL_KDF_PARAM_SCRYPT_P, (uint32_t)16); *p = OSSL_PARAM_construct_end(); if (EVP_KDF_derive(kctx, out, sizeof(out), params) <= 0) { error(“EVP_KDF_derive”); } { const unsigned char expected[sizeof(out)] = { 0xfd, 0xba, 0xbe, 0x1c, 0x9d, 0x34, 0x72, 0x00, 0x78, 0x56, 0xe7, 0x19, 0x0d, 0x01, 0xe9, 0xfe, 0x7c, 0x6a, 0xd7, 0xcb, 0xc8, 0x23, 0x78, 0x30, 0xe7, 0x73, 0x76, 0x63, 0x4b, 0x37, 0x31, 0x62, 0x2e, 0xaf, 0x30, 0xd9, 0x2e, 0x22, 0xa3, 0x88, 0x6f, 0xf1, 0x09, 0x27, 0x9d, 0x98, 0x30, 0xda, 0xc7, 0x27, 0xaf, 0xb9, 0x4a, 0x83, 0xee, 0x6d, 0x83, 0x60, 0xcb, 0xdf, 0xa2, 0xcc, 0x06, 0x40 }; assert(!memcmp(out, expected, sizeof(out))); } EVP_KDF_CTX_free(kctx);

CONFORMING TO

RFC 7914

SEE ALSO

EVP_KDF (3), EVP_KDF_CTX_new (3), EVP_KDF_CTX_free (3), EVP_KDF_CTX_set_params (3), EVP_KDF_derive (3), “PARAMETERS” in EVP_KDF (3)

HISTORY

This functionality was added in OpenSSL 3.0.

COPYRIGHT

Copyright 2017-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

504 - Linux cli command ALTER_EXTENSION

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_EXTENSION and provides detailed information about the command ALTER_EXTENSION, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_EXTENSION.

NAME 🖥️ ALTER_EXTENSION 🖥️

change the definition of an extension

SYNOPSIS

ALTER EXTENSION name UPDATE [ TO new_version ]
ALTER EXTENSION name SET SCHEMA new_schema
ALTER EXTENSION name ADD member_object
ALTER EXTENSION name DROP member_object

where member_object is:

  ACCESS METHOD object_name |
  AGGREGATE aggregate_name ( aggregate_signature ) |
  CAST (source_type AS target_type) |
  COLLATION object_name |
  CONVERSION object_name |
  DOMAIN object_name |
  EVENT TRIGGER object_name |
  FOREIGN DATA WRAPPER object_name |
  FOREIGN TABLE object_name |
  FUNCTION function_name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ] |
  MATERIALIZED VIEW object_name |
  OPERATOR operator_name (left_type, right_type) |
  OPERATOR CLASS object_name USING index_method |
  OPERATOR FAMILY object_name USING index_method |
  [ PROCEDURAL ] LANGUAGE object_name |
  PROCEDURE procedure_name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ] |
  ROUTINE routine_name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ] |
  SCHEMA object_name |
  SEQUENCE object_name |
  SERVER object_name |
  TABLE object_name |
  TEXT SEARCH CONFIGURATION object_name |
  TEXT SEARCH DICTIONARY object_name |
  TEXT SEARCH PARSER object_name |
  TEXT SEARCH TEMPLATE object_name |
  TRANSFORM FOR type_name LANGUAGE lang_name |
  TYPE object_name |
  VIEW object_name

and aggregate_signature is:

* |
[ argmode ] [ argname ] argtype [ , ... ] |
[ [ argmode ] [ argname ] argtype [ , ... ] ] ORDER BY [ argmode ] [ argname ] argtype [ , ... ]

DESCRIPTION

ALTER EXTENSION changes the definition of an installed extension. There are several subforms:

UPDATE

This form updates the extension to a newer version. The extension must supply a suitable update script (or series of scripts) that can modify the currently-installed version into the requested version.

SET SCHEMA

This form moves the extensions objects into another schema. The extension has to be relocatable for this command to succeed.

ADD member_object

This form adds an existing object to the extension. This is mainly useful in extension update scripts. The object will subsequently be treated as a member of the extension; notably, it can only be dropped by dropping the extension.

DROP member_object

This form removes a member object from the extension. This is mainly useful in extension update scripts. The object is not dropped, only disassociated from the extension.

See Section 38.17 for more information about these operations.

You must own the extension to use ALTER EXTENSION. The ADD/DROP forms require ownership of the added/dropped object as well.

PARAMETERS

name

The name of an installed extension.

new_version

The desired new version of the extension. This can be written as either an identifier or a string literal. If not specified, ALTER EXTENSION UPDATE attempts to update to whatever is shown as the default version in the extensions control file.

new_schema

The new schema for the extension.

object_name
aggregate_name
function_name
operator_name
procedure_name
routine_name

The name of an object to be added to or removed from the extension. Names of tables, aggregates, domains, foreign tables, functions, operators, operator classes, operator families, procedures, routines, sequences, text search objects, types, and views can be schema-qualified.

source_type

The name of the source data type of the cast.

target_type

The name of the target data type of the cast.

argmode

The mode of a function, procedure, or aggregate argument: IN, OUT, INOUT, or VARIADIC. If omitted, the default is IN. Note that ALTER EXTENSION does not actually pay any attention to OUT arguments, since only the input arguments are needed to determine the functions identity. So it is sufficient to list the IN, INOUT, and VARIADIC arguments.

argname

The name of a function, procedure, or aggregate argument. Note that ALTER EXTENSION does not actually pay any attention to argument names, since only the argument data types are needed to determine the functions identity.

argtype

The data type of a function, procedure, or aggregate argument.

left_type
right_type

The data type(s) of the operators arguments (optionally schema-qualified). Write NONE for the missing argument of a prefix operator.

PROCEDURAL

This is a noise word.

type_name

The name of the data type of the transform.

lang_name

The name of the language of the transform.

EXAMPLES

To update the hstore extension to version 2.0:

ALTER EXTENSION hstore UPDATE TO 2.0;

To change the schema of the hstore extension to utils:

ALTER EXTENSION hstore SET SCHEMA utils;

To add an existing function to the hstore extension:

ALTER EXTENSION hstore ADD FUNCTION populate_record(anyelement, hstore);

COMPATIBILITY

ALTER EXTENSION is a PostgreSQL extension.

SEE ALSO

CREATE EXTENSION (CREATE_EXTENSION(7)), DROP EXTENSION (DROP_EXTENSION(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

505 - Linux cli command iso-8859-9

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso-8859-9 and provides detailed information about the command iso-8859-9, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso-8859-9.

NAME 🖥️ iso-8859-9 🖥️

9 - ISO/IEC 8859-9 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-9 encodes the characters used in Turkish.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-9 characters

The following table displays the characters in ISO/IEC 8859-9 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-9 is also known as Latin-5.

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

506 - Linux cli command EVP_CIPHER-CAMELLIAssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_CIPHER-CAMELLIAssl and provides detailed information about the command EVP_CIPHER-CAMELLIAssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_CIPHER-CAMELLIAssl.

NAME 🖥️ EVP_CIPHER-CAMELLIAssl 🖥️

CAMELLIA - The CAMELLIA EVP_CIPHER implementations

DESCRIPTION

Support for CAMELLIA symmetric encryption using the EVP_CIPHER API.

Algorithm Names

The following algorithms are available in the default provider:

“CAMELLIA-128-CBC”, “CAMELLIA-192-CBC” and “CAMELLIA-256-CBC”

“CAMELLIA-128-CBC-CTS”, “CAMELLIA-192-CBC-CTS” and “CAMELLIA-256-CBC-CTS”

“CAMELLIA-128-CFB”, “CAMELLIA-192-CFB”, “CAMELLIA-256-CFB”, “CAMELLIA-128-CFB1”, “CAMELLIA-192-CFB1”, “CAMELLIA-256-CFB1”, “CAMELLIA-128-CFB8”, “CAMELLIA-192-CFB8” and “CAMELLIA-256-CFB8”

“CAMELLIA-128-CTR”, “CAMELLIA-192-CTR” and “CAMELLIA-256-CTR”

“CAMELLIA-128-ECB”, “CAMELLIA-192-ECB” and “CAMELLIA-256-ECB”

“CAMELLIA-192-OFB”, “CAMELLIA-128-OFB” and “CAMELLIA-256-OFB”

Parameters

This implementation supports the parameters described in “PARAMETERS” in EVP_EncryptInit (3).

SEE ALSO

provider-cipher (7), OSSL_PROVIDER-default (7)

COPYRIGHT

Copyright 2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

507 - Linux cli command EVP_CIPHER-NULLssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_CIPHER-NULLssl and provides detailed information about the command EVP_CIPHER-NULLssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_CIPHER-NULLssl.

NAME 🖥️ EVP_CIPHER-NULLssl 🖥️

NULL - The NULL EVP_CIPHER implementation

DESCRIPTION

Support for a NULL symmetric encryption using the EVP_CIPHER API. This is used when the TLS cipher suite is TLS_NULL_WITH_NULL_NULL. This does no encryption (just copies the data) and has a mac size of zero.

Algorithm Name

The following algorithm is available in the default provider:

“NULL”

Parameters

This implementation supports the following parameters:

Gettable EVP_CIPHER parameters

See “Gettable EVP_CIPHER parameters” in EVP_EncryptInit (3)

Gettable EVP_CIPHER_CTX parameters

“keylen” (OSSL_CIPHER_PARAM_KEYLEN) <unsigned integer>

“ivlen” (OSSL_CIPHER_PARAM_IVLEN and <OSSL_CIPHER_PARAM_AEAD_IVLEN) <unsigned integer>

“tls-mac” (OSSL_CIPHER_PARAM_TLS_MAC) <octet ptr>

See “PARAMETERS” in EVP_EncryptInit (3) for further information.

Settable EVP_CIPHER_CTX parameters

“tls-mac-size” (OSSL_CIPHER_PARAM_TLS_MAC_SIZE) <unsigned integer>

See “PARAMETERS” in EVP_EncryptInit (3) for further information.

CONFORMING TO

RFC 5246 section-6.2.3.1

SEE ALSO

provider-cipher (7), OSSL_PROVIDER-default (7)

COPYRIGHT

Copyright 2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

508 - Linux cli command ctssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ctssl and provides detailed information about the command ctssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ctssl.

NAME 🖥️ ctssl 🖥️

Certificate Transparency

SYNOPSIS

#include <openssl/ct.h>

DESCRIPTION

This library implements Certificate Transparency (CT) verification for TLS clients, as defined in RFC 6962. This verification can provide some confidence that a certificate has been publicly logged in a set of CT logs.

By default, these checks are disabled. They can be enabled using SSL_CTX_enable_ct (3) or SSL_enable_ct (3).

This library can also be used to parse and examine CT data structures, such as Signed Certificate Timestamps (SCTs), or to read a list of CT logs. There are functions for: - decoding and encoding SCTs in DER and TLS wire format. - printing SCTs. - verifying the authenticity of SCTs. - loading a CT log list from a CONF file.

SEE ALSO

d2i_SCT_LIST (3), CTLOG_STORE_new (3), CTLOG_STORE_get0_log_by_id (3), SCT_new (3), SCT_print (3), SCT_validate (3), SCT_validate (3), CT_POLICY_EVAL_CTX_new (3), SSL_CTX_set_ct_validation_callback (3)

HISTORY

The ct library was added in OpenSSL 1.1.0.

COPYRIGHT

Copyright 2016-2017 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

509 - Linux cli command UPDATE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command UPDATE and provides detailed information about the command UPDATE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the UPDATE.

NAME 🖥️ UPDATE 🖥️

update rows of a table

SYNOPSIS

[ WITH [ RECURSIVE ] with_query [, ...] ]
UPDATE [ ONLY ] table_name [ * ] [ [ AS ] alias ]
    SET { column_name = { expression | DEFAULT } |
          ( column_name [, ...] ) = [ ROW ] ( { expression | DEFAULT } [, ...] ) |
          ( column_name [, ...] ) = ( sub-SELECT )
        } [, ...]
    [ FROM from_item [, ...] ]
    [ WHERE condition | WHERE CURRENT OF cursor_name ]
    [ RETURNING { * | output_expression [ [ AS ] output_name ] } [, ...] ]

DESCRIPTION

UPDATE changes the values of the specified columns in all rows that satisfy the condition. Only the columns to be modified need be mentioned in the SET clause; columns not explicitly modified retain their previous values.

There are two ways to modify a table using information contained in other tables in the database: using sub-selects, or specifying additional tables in the FROM clause. Which technique is more appropriate depends on the specific circumstances.

The optional RETURNING clause causes UPDATE to compute and return value(s) based on each row actually updated. Any expression using the tables columns, and/or columns of other tables mentioned in FROM, can be computed. The new (post-update) values of the tables columns are used. The syntax of the RETURNING list is identical to that of the output list of SELECT.

You must have the UPDATE privilege on the table, or at least on the column(s) that are listed to be updated. You must also have the SELECT privilege on any column whose values are read in the expressions or condition.

PARAMETERS

with_query

The WITH clause allows you to specify one or more subqueries that can be referenced by name in the UPDATE query. See Section 7.8 and SELECT(7) for details.

table_name

The name (optionally schema-qualified) of the table to update. If ONLY is specified before the table name, matching rows are updated in the named table only. If ONLY is not specified, matching rows are also updated in any tables inheriting from the named table. Optionally, * can be specified after the table name to explicitly indicate that descendant tables are included.

alias

A substitute name for the target table. When an alias is provided, it completely hides the actual name of the table. For example, given UPDATE foo AS f, the remainder of the UPDATE statement must refer to this table as f not foo.

column_name

The name of a column in the table named by table_name. The column name can be qualified with a subfield name or array subscript, if needed. Do not include the tables name in the specification of a target column — for example, UPDATE table_name SET table_name.col = 1 is invalid.

expression

An expression to assign to the column. The expression can use the old values of this and other columns in the table.

DEFAULT

Set the column to its default value (which will be NULL if no specific default expression has been assigned to it). An identity column will be set to a new value generated by the associated sequence. For a generated column, specifying this is permitted but merely specifies the normal behavior of computing the column from its generation expression.

sub-SELECT

A SELECT sub-query that produces as many output columns as are listed in the parenthesized column list preceding it. The sub-query must yield no more than one row when executed. If it yields one row, its column values are assigned to the target columns; if it yields no rows, NULL values are assigned to the target columns. The sub-query can refer to old values of the current row of the table being updated.

from_item

A table expression allowing columns from other tables to appear in the WHERE condition and update expressions. This uses the same syntax as the FROM clause of a SELECT statement; for example, an alias for the table name can be specified. Do not repeat the target table as a from_item unless you intend a self-join (in which case it must appear with an alias in the from_item).

condition

An expression that returns a value of type boolean. Only rows for which this expression returns true will be updated.

cursor_name

The name of the cursor to use in a WHERE CURRENT OF condition. The row to be updated is the one most recently fetched from this cursor. The cursor must be a non-grouping query on the UPDATEs target table. Note that WHERE CURRENT OF cannot be specified together with a Boolean condition. See DECLARE(7) for more information about using cursors with WHERE CURRENT OF.

output_expression

An expression to be computed and returned by the UPDATE command after each row is updated. The expression can use any column names of the table named by table_name or table(s) listed in FROM. Write * to return all columns.

output_name

A name to use for a returned column.

OUTPUTS

On successful completion, an UPDATE command returns a command tag of the form

UPDATE count

The count is the number of rows updated, including matched rows whose values did not change. Note that the number may be less than the number of rows that matched the condition when updates were suppressed by a BEFORE UPDATE trigger. If count is 0, no rows were updated by the query (this is not considered an error).

If the UPDATE command contains a RETURNING clause, the result will be similar to that of a SELECT statement containing the columns and values defined in the RETURNING list, computed over the row(s) updated by the command.

NOTES

When a FROM clause is present, what essentially happens is that the target table is joined to the tables mentioned in the from_item list, and each output row of the join represents an update operation for the target table. When using FROM you should ensure that the join produces at most one output row for each row to be modified. In other words, a target row shouldnt join to more than one row from the other table(s). If it does, then only one of the join rows will be used to update the target row, but which one will be used is not readily predictable.

Because of this indeterminacy, referencing other tables only within sub-selects is safer, though often harder to read and slower than using a join.

In the case of a partitioned table, updating a row might cause it to no longer satisfy the partition constraint of the containing partition. In that case, if there is some other partition in the partition tree for which this row satisfies its partition constraint, then the row is moved to that partition. If there is no such partition, an error will occur. Behind the scenes, the row movement is actually a DELETE and INSERT operation.

There is a possibility that a concurrent UPDATE or DELETE on the row being moved will get a serialization failure error. Suppose session 1 is performing an UPDATE on a partition key, and meanwhile a concurrent session 2 for which this row is visible performs an UPDATE or DELETE operation on this row. In such case, session 2s UPDATE or DELETE will detect the row movement and raise a serialization failure error (which always returns with an SQLSTATE code 40001). Applications may wish to retry the transaction if this occurs. In the usual case where the table is not partitioned, or where there is no row movement, session 2 would have identified the newly updated row and carried out the UPDATE/DELETE on this new row version.

Note that while rows can be moved from local partitions to a foreign-table partition (provided the foreign data wrapper supports tuple routing), they cannot be moved from a foreign-table partition to another partition.

An attempt of moving a row from one partition to another will fail if a foreign key is found to directly reference an ancestor of the source partition that is not the same as the ancestor thats mentioned in the UPDATE query.

EXAMPLES

Change the word Drama to Dramatic in the column kind of the table films:

UPDATE films SET kind = Dramatic WHERE kind = Drama;

Adjust temperature entries and reset precipitation to its default value in one row of the table weather:

UPDATE weather SET temp_lo = temp_lo+1, temp_hi = temp_lo+15, prcp = DEFAULT WHERE city = San Francisco AND date = 2003-07-03;

Perform the same operation and return the updated entries:

UPDATE weather SET temp_lo = temp_lo+1, temp_hi = temp_lo+15, prcp = DEFAULT WHERE city = San Francisco AND date = 2003-07-03 RETURNING temp_lo, temp_hi, prcp;

Use the alternative column-list syntax to do the same update:

UPDATE weather SET (temp_lo, temp_hi, prcp) = (temp_lo+1, temp_lo+15, DEFAULT) WHERE city = San Francisco AND date = 2003-07-03;

Increment the sales count of the salesperson who manages the account for Acme Corporation, using the FROM clause syntax:

UPDATE employees SET sales_count = sales_count + 1 FROM accounts WHERE accounts.name = Acme Corporation AND employees.id = accounts.sales_person;

Perform the same operation, using a sub-select in the WHERE clause:

UPDATE employees SET sales_count = sales_count + 1 WHERE id = (SELECT sales_person FROM accounts WHERE name = Acme Corporation);

Update contact names in an accounts table to match the currently assigned salespeople:

UPDATE accounts SET (contact_first_name, contact_last_name) = (SELECT first_name, last_name FROM employees WHERE employees.id = accounts.sales_person);

A similar result could be accomplished with a join:

UPDATE accounts SET contact_first_name = first_name, contact_last_name = last_name FROM employees WHERE employees.id = accounts.sales_person;

However, the second query may give unexpected results if employees.id is not a unique key, whereas the first query is guaranteed to raise an error if there are multiple id matches. Also, if there is no match for a particular accounts.sales_person entry, the first query will set the corresponding name fields to NULL, whereas the second query will not update that row at all.

Update statistics in a summary table to match the current data:

UPDATE summary s SET (sum_x, sum_y, avg_x, avg_y) = (SELECT sum(x), sum(y), avg(x), avg(y) FROM data d WHERE d.group_id = s.group_id);

Attempt to insert a new stock item along with the quantity of stock. If the item already exists, instead update the stock count of the existing item. To do this without failing the entire transaction, use savepoints:

BEGIN; – other operations SAVEPOINT sp1; INSERT INTO wines VALUES(Chateau Lafite 2003, 24); – Assume the above fails because of a unique key violation, – so now we issue these commands: ROLLBACK TO sp1; UPDATE wines SET stock = stock + 24 WHERE winename = Chateau Lafite 2003; – continue with other operations, and eventually COMMIT;

Change the kind column of the table films in the row on which the cursor c_films is currently positioned:

UPDATE films SET kind = Dramatic WHERE CURRENT OF c_films;

COMPATIBILITY

This command conforms to the SQL standard, except that the FROM and RETURNING clauses are PostgreSQL extensions, as is the ability to use WITH with UPDATE.

Some other database systems offer a FROM option in which the target table is supposed to be listed again within FROM. That is not how PostgreSQL interprets FROM. Be careful when porting applications that use this extension.

According to the standard, the source value for a parenthesized sub-list of target column names can be any row-valued expression yielding the correct number of columns. PostgreSQL only allows the source value to be a row constructor or a sub-SELECT. An individual columns updated value can be specified as DEFAULT in the row-constructor case, but not inside a sub-SELECT.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

510 - Linux cli command EVP_KDF-PBKDF2ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KDF-PBKDF2ssl and provides detailed information about the command EVP_KDF-PBKDF2ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KDF-PBKDF2ssl.

NAME 🖥️ EVP_KDF-PBKDF2ssl 🖥️

PBKDF2 - The PBKDF2 EVP_KDF implementation

DESCRIPTION

Support for computing the PBKDF2 password-based KDF through the EVP_KDF API.

The EVP_KDF-PBKDF2 algorithm implements the PBKDF2 password-based key derivation function, as described in SP800-132; it derives a key from a password using a salt and iteration count.

Identity

“PBKDF2” is the name for this implementation; it can be used with the EVP_KDF_fetch() function.

Supported parameters

The supported parameters are:

“pass” (OSSL_KDF_PARAM_PASSWORD) <octet string>

“salt” (OSSL_KDF_PARAM_SALT) <octet string>

“iter” (OSSL_KDF_PARAM_ITER) <unsigned integer>

This parameter has a default value of 2048.

“properties” (OSSL_KDF_PARAM_PROPERTIES) <UTF8 string>

“digest” (OSSL_KDF_PARAM_DIGEST) <UTF8 string>

These parameters work as described in “PARAMETERS” in EVP_KDF (3).

“pkcs5” (OSSL_KDF_PARAM_PKCS5) <integer>
This parameter can be used to enable or disable SP800-132 compliance checks. Setting the mode to 0 enables the compliance checks. The checks performed are:

- the iteration count is at least 1000.

- the salt length is at least 128 bits.

- the derived key length is at least 112 bits.

The default provider uses a default mode of 1 for backwards compatibility, and the FIPS provider uses a default mode of 0. The value string is expected to be a decimal number 0 or 1.

NOTES

A typical application of this algorithm is to derive keying material for an encryption algorithm from a password in the “pass”, a salt in “salt”, and an iteration count.

Increasing the “iter” parameter slows down the algorithm which makes it harder for an attacker to perform a brute force attack using a large number of candidate passwords.

No assumption is made regarding the given password; it is simply treated as a byte sequence.

CONFORMING TO

SP800-132

SEE ALSO

EVP_KDF (3), EVP_KDF_CTX_new (3), EVP_KDF_CTX_free (3), EVP_KDF_CTX_set_params (3), EVP_KDF_derive (3), “PARAMETERS” in EVP_KDF (3)

HISTORY

This functionality was added in OpenSSL 3.0.

COPYRIGHT

Copyright 2018-2020 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

511 - Linux cli command gitcli

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command gitcli and provides detailed information about the command gitcli, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the gitcli.

NAME 🖥️ gitcli 🖥️

Git command-line interface and conventions

SYNOPSIS

gitcli

DESCRIPTION

This manual describes the convention used throughout Git CLI.

Many commands take revisions (most often “commits”, but sometimes “tree-ish”, depending on the context and command) and paths as their arguments. Here are the rules:

·

Options come first and then args. A subcommand may take dashed options (which may take their own arguments, e.g. “–max-parents 2”) and arguments. You SHOULD give dashed options first and then arguments. Some commands may accept dashed options after you have already given non-option arguments (which may make the command ambiguous), but you should not rely on it (because eventually we may find a way to fix these ambiguities by enforcing the “options then args” rule).

·

Revisions come first and then paths. E.g. in git diff v1.0 v2.0 arch/x86 include/asm-x86, v1.0 and v2.0 are revisions and arch/x86 and include/asm-x86 are paths.

·

When an argument can be misunderstood as either a revision or a path, they can be disambiguated by placing – between them. E.g. git diff – HEAD is, “I have a file called HEAD in my work tree. Please show changes between the version I staged in the index and what I have in the work tree for that file”, not “show the difference between the HEAD commit and the work tree as a whole”. You can say git diff HEAD – to ask for the latter.

·

Without disambiguating –, Git makes a reasonable guess, but errors out and asks you to disambiguate when ambiguous. E.g. if you have a file called HEAD in your work tree, git diff HEAD is ambiguous, and you have to say either git diff HEAD – or git diff – HEAD to disambiguate.

·

Because – disambiguates revisions and paths in some commands, it cannot be used for those commands to separate options and revisions. You can use –end-of-options for this (it also works for commands that do not distinguish between revisions in paths, in which case it is simply an alias for –).

When writing a script that is expected to handle random user-input, it is a good practice to make it explicit which arguments are which by placing disambiguating – at appropriate places.

·

Many commands allow wildcards in paths, but you need to protect them from getting globbed by the shell. These two mean different things:

$ git restore *.c $ git restore *.c

The former lets your shell expand the fileglob, and you are asking the dot-C files in your working tree to be overwritten with the version in the index. The latter passes the *.c to Git, and you are asking the paths in the index that match the pattern to be checked out to your working tree. After running git add hello.c; rm hello.c, you will not see hello.c in your working tree with the former, but with the latter you will.

·

Just as the filesystem . (period) refers to the current directory, using a . as a repository name in Git (a dot-repository) is a relative path and means your current repository.

Here are the rules regarding the “flags” that you should follow when you are scripting Git:

·

It’s preferred to use the non-dashed form of Git commands, which means that you should prefer git foo to git-foo.

·

Splitting short options to separate words (prefer git foo -a -b to git foo -ab, the latter may not even work).

·

When a command-line option takes an argument, use the stuck form. In other words, write git foo -oArg instead of git foo -o Arg for short options, and git foo –long-opt=Arg instead of git foo –long-opt Arg for long options. An option that takes optional option-argument must be written in the stuck form.

·

When you give a revision parameter to a command, make sure the parameter is not ambiguous with a name of a file in the work tree. E.g. do not write git log -1 HEAD but write git log -1 HEAD –; the former will not work if you happen to have a file called HEAD in the work tree.

·

Many commands allow a long option –option to be abbreviated only to their unique prefix (e.g. if there is no other option whose name begins with opt, you may be able to spell –opt to invoke the –option flag), but you should fully spell them out when writing your scripts; later versions of Git may introduce a new option whose name shares the same prefix, e.g. –optimize, to make a short prefix that used to be unique no longer unique.

ENHANCED OPTION PARSER

From the Git 1.5.4 series and further, many Git commands (not all of them at the time of the writing though) come with an enhanced option parser.

Here is a list of the facilities provided by this option parser.

Magic Options

Commands which have the enhanced option parser activated all understand a couple of magic command-line options:

-h

gives a pretty printed usage of the command.

$ git describe -h usage: git describe [] * or: git describe [] –dirty

    --contains            find the tag that comes after the commit
    --debug               debug search strategy on stderr
    --all                 use any ref
    --tags                use any tag, even unannotated
    --long                always use long format
    --abbrev[=<n>]        use <n> digits to display SHA-1s

Note that some subcommand (e.g. git grep) may behave differently when there are things on the command line other than -h, but git subcmd -h without anything else on the command line is meant to consistently give the usage.

–help-all

Some Git commands take options that are only used for plumbing or that are deprecated, and such options are hidden from the default usage. This option gives the full list of options.

Negating options

Options with long option names can be negated by prefixing –no-. For example, git branch has the option –track which is on by default. You can use –no-track to override that behaviour. The same goes for –color and –no-color.

Aggregating short options

Commands that support the enhanced option parser allow you to aggregate short options. This means that you can for example use git rm -rf or git clean -fdx.

Abbreviating long options

Commands that support the enhanced option parser accepts unique prefix of a long option as if it is fully spelled out, but use this with a caution. For example, git commit –amen behaves as if you typed git commit –amend, but that is true only until a later version of Git introduces another option that shares the same prefix, e.g. git commit –amenity option.

Separating argument from the option

You can write the mandatory option parameter to an option as a separate word on the command line. That means that all the following uses work:

$ git foo –long-opt=Arg $ git foo –long-opt Arg $ git foo -oArg $ git foo -o Arg

However, this is NOT allowed for switches with an optional value, where the stuck form must be used:

$ git describe –abbrev HEAD # correct $ git describe –abbrev=10 HEAD # correct $ git describe –abbrev 10 HEAD # NOT WHAT YOU MEANT

NOTES ON FREQUENTLY CONFUSED OPTIONS

Many commands that can work on files in the working tree and/or in the index can take –cached and/or –index options. Sometimes people incorrectly think that, because the index was originally called cache, these two are synonyms. They are not — these two options mean very different things.

·

The –cached option is used to ask a command that usually works on files in the working tree to only work with the index. For example, git grep, when used without a commit to specify from which commit to look for strings in, usually works on files in the working tree, but with the –cached option, it looks for strings in the index.

·

The –index option is used to ask a command that usually works on files in the working tree to also affect the index. For example, git stash apply usually merges changes recorded in a stash entry to the working tree, but with the –index option, it also merges changes to the index as well.

git apply command can be used with –cached and –index (but not at the same time). Usually the command only affects the files in the working tree, but with –index, it patches both the files and their index entries, and with –cached, it modifies only the index entries.

See also https://lore.kernel.org/git/[email protected]/ and https://lore.kernel.org/git/[email protected]/ for further information.

Some other commands that also work on files in the working tree and/or in the index can take –staged and/or –worktree.

·

–staged is exactly like –cached, which is used to ask a command to only work on the index, not the working tree.

·

–worktree is the opposite, to ask a command to work on the working tree only, not the index.

·

The two options can be specified together to ask a command to work on both the index and the working tree.

GIT

Part of the git(1) suite

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

512 - Linux cli command LISTEN

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command LISTEN and provides detailed information about the command LISTEN, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the LISTEN.

NAME 🖥️ LISTEN 🖥️

listen for a notification

SYNOPSIS

LISTEN channel

DESCRIPTION

LISTEN registers the current session as a listener on the notification channel named channel. If the current session is already registered as a listener for this notification channel, nothing is done.

Whenever the command NOTIFY channel is invoked, either by this session or another one connected to the same database, all the sessions currently listening on that notification channel are notified, and each will in turn notify its connected client application.

A session can be unregistered for a given notification channel with the UNLISTEN command. A sessions listen registrations are automatically cleared when the session ends.

The method a client application must use to detect notification events depends on which PostgreSQL application programming interface it uses. With the libpq library, the application issues LISTEN as an ordinary SQL command, and then must periodically call the function PQnotifies to find out whether any notification events have been received. Other interfaces such as libpgtcl provide higher-level methods for handling notify events; indeed, with libpgtcl the application programmer should not even issue LISTEN or UNLISTEN directly. See the documentation for the interface you are using for more details.

PARAMETERS

channel

Name of a notification channel (any identifier).

NOTES

LISTEN takes effect at transaction commit. If LISTEN or UNLISTEN is executed within a transaction that later rolls back, the set of notification channels being listened to is unchanged.

A transaction that has executed LISTEN cannot be prepared for two-phase commit.

There is a race condition when first setting up a listening session: if concurrently-committing transactions are sending notify events, exactly which of those will the newly listening session receive? The answer is that the session will receive all events committed after an instant during the transactions commit step. But that is slightly later than any database state that the transaction could have observed in queries. This leads to the following rule for using LISTEN: first execute (and commit!) that command, then in a new transaction inspect the database state as needed by the application logic, then rely on notifications to find out about subsequent changes to the database state. The first few received notifications might refer to updates already observed in the initial database inspection, but this is usually harmless.

NOTIFY(7) contains a more extensive discussion of the use of LISTEN and NOTIFY.

EXAMPLES

Configure and execute a listen/notify sequence from psql:

LISTEN virtual; NOTIFY virtual; Asynchronous notification “virtual” received from server process with PID 8448.

COMPATIBILITY

There is no LISTEN statement in the SQL standard.

SEE ALSO

NOTIFY(7), UNLISTEN(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

513 - Linux cli command PREPARE_TRANSACTION

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command PREPARE_TRANSACTION and provides detailed information about the command PREPARE_TRANSACTION, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the PREPARE_TRANSACTION.

NAME 🖥️ PREPARE_TRANSACTION 🖥️

prepare the current transaction for two-phase commit

SYNOPSIS

PREPARE TRANSACTION transaction_id

DESCRIPTION

PREPARE TRANSACTION prepares the current transaction for two-phase commit. After this command, the transaction is no longer associated with the current session; instead, its state is fully stored on disk, and there is a very high probability that it can be committed successfully, even if a database crash occurs before the commit is requested.

Once prepared, a transaction can later be committed or rolled back with COMMIT PREPARED or ROLLBACK PREPARED, respectively. Those commands can be issued from any session, not only the one that executed the original transaction.

From the point of view of the issuing session, PREPARE TRANSACTION is not unlike a ROLLBACK command: after executing it, there is no active current transaction, and the effects of the prepared transaction are no longer visible. (The effects will become visible again if the transaction is committed.)

If the PREPARE TRANSACTION command fails for any reason, it becomes a ROLLBACK: the current transaction is canceled.

PARAMETERS

transaction_id

An arbitrary identifier that later identifies this transaction for COMMIT PREPARED or ROLLBACK PREPARED. The identifier must be written as a string literal, and must be less than 200 bytes long. It must not be the same as the identifier used for any currently prepared transaction.

NOTES

PREPARE TRANSACTION is not intended for use in applications or interactive sessions. Its purpose is to allow an external transaction manager to perform atomic global transactions across multiple databases or other transactional resources. Unless youre writing a transaction manager, you probably shouldnt be using PREPARE TRANSACTION.

This command must be used inside a transaction block. Use BEGIN to start one.

It is not currently allowed to PREPARE a transaction that has executed any operations involving temporary tables or the sessions temporary namespace, created any cursors WITH HOLD, or executed LISTEN, UNLISTEN, or NOTIFY. Those features are too tightly tied to the current session to be useful in a transaction to be prepared.

If the transaction modified any run-time parameters with SET (without the LOCAL option), those effects persist after PREPARE TRANSACTION, and will not be affected by any later COMMIT PREPARED or ROLLBACK PREPARED. Thus, in this one respect PREPARE TRANSACTION acts more like COMMIT than ROLLBACK.

All currently available prepared transactions are listed in the pg_prepared_xacts system view.

Caution

It is unwise to leave transactions in the prepared state for a long time. This will interfere with the ability of VACUUM to reclaim storage, and in extreme cases could cause the database to shut down to prevent transaction ID wraparound (see Section 25.1.5). Keep in mind also that the transaction continues to hold whatever locks it held. The intended usage of the feature is that a prepared transaction will normally be committed or rolled back as soon as an external transaction manager has verified that other databases are also prepared to commit.

If you have not set up an external transaction manager to track prepared transactions and ensure they get closed out promptly, it is best to keep the prepared-transaction feature disabled by setting max_prepared_transactions to zero. This will prevent accidental creation of prepared transactions that might then be forgotten and eventually cause problems.

EXAMPLES

Prepare the current transaction for two-phase commit, using foobar as the transaction identifier:

PREPARE TRANSACTION foobar;

COMPATIBILITY

PREPARE TRANSACTION is a PostgreSQL extension. It is intended for use by external transaction management systems, some of which are covered by standards (such as X/Open XA), but the SQL side of those systems is not standardized.

SEE ALSO

COMMIT PREPARED (COMMIT_PREPARED(7)), ROLLBACK PREPARED (ROLLBACK_PREPARED(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

514 - Linux cli command feature_test_macros

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command feature_test_macros and provides detailed information about the command feature_test_macros, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the feature_test_macros.

NAME 🖥️ feature_test_macros 🖥️

feature test macros

DESCRIPTION

Feature test macros allow the programmer to control the definitions that are exposed by system header files when a program is compiled.

NOTE: In order to be effective, a feature test macro must be defined before including any header files. This can be done either in the compilation command (cc -DMACRO=value) or by defining the macro within the source code before including any headers. The requirement that the macro must be defined before including any header file exists because header files may freely include one another. Thus, for example, in the following lines, defining the _GNU_SOURCE macro may have no effect because the header <abc.h> itself includes <xyz.h> (POSIX explicitly allows this):

#include <abc.h>
#define _GNU_SOURCE
#include <xyz.h>

Some feature test macros are useful for creating portable applications, by preventing nonstandard definitions from being exposed. Other macros can be used to expose nonstandard definitions that are not exposed by default.

The precise effects of each of the feature test macros described below can be ascertained by inspecting the <features.h> header file. Note: applications do not need to directly include <features.h>; indeed, doing so is actively discouraged. See NOTES.

Specification of feature test macro requirements in manual pages

When a function requires that a feature test macro is defined, the manual page SYNOPSIS typically includes a note of the following form (this example from the acct(2) manual page):

#include <unistd.h>

int acct(const char *filename);

Feature Test Macro Requirements for glibc (see feature_test_macros(7)):

acct(): _BSD_SOURCE || (_XOPEN_SOURCE && _XOPEN_SOURCE < 500)

The || means that in order to obtain the declaration of acct(2) from <unistd.h>, either of the following macro definitions must be made before including any header files:

#define _BSD_SOURCE
#define _XOPEN_SOURCE        /* or any value < 500 */

Alternatively, equivalent definitions can be included in the compilation command:

cc -D_BSD_SOURCE
cc -D_XOPEN_SOURCE           # Or any value < 500

Note that, as described below, some feature test macros are defined by default, so that it may not always be necessary to explicitly specify the feature test macro(s) shown in the SYNOPSIS.

In a few cases, manual pages use a shorthand for expressing the feature test macro requirements (this example from readahead(2)):

#define _GNU_SOURCE #define _FILE_OFFSET_BITS 64 #include <fcntl.h> ssize_t readahead(int fd, off_t *offset, size_t count);

This format is employed when the feature test macros ensure that the proper function declarations are visible, and the macros are not defined by default.

Feature test macros understood by glibc

The paragraphs below explain how feature test macros are handled in glibc 2.x, x > 0.

First, though, a summary of a few details for the impatient:

  • The macros that you most likely need to use in modern source code are _POSIX_C_SOURCE (for definitions from various versions of POSIX.1), _XOPEN_SOURCE (for definitions from various versions of SUS), _GNU_SOURCE (for GNU and/or Linux specific stuff), and _DEFAULT_SOURCE (to get definitions that would normally be provided by default).

  • Certain macros are defined with default values. Thus, although one or more macros may be indicated as being required in the SYNOPSIS of a man page, it may not be necessary to define them explicitly. Full details of the defaults are given later in this man page.

  • Defining _XOPEN_SOURCE with a value of 600 or greater produces the same effects as defining _POSIX_C_SOURCE with a value of 200112L or greater. Where one sees

    _POSIX_C_SOURCE >= 200112L

    in the feature test macro requirements in the SYNOPSIS of a man page, it is implicit that the following has the same effect:

    _XOPEN_SOURCE >= 600

  • Defining _XOPEN_SOURCE with a value of 700 or greater produces the same effects as defining _POSIX_C_SOURCE with a value of 200809L or greater. Where one sees

    _POSIX_C_SOURCE >= 200809L

    in the feature test macro requirements in the SYNOPSIS of a man page, it is implicit that the following has the same effect:

    _XOPEN_SOURCE >= 700

glibc understands the following feature test macros:

__STRICT_ANSI__
ISO Standard C. This macro is implicitly defined by gcc(1) when invoked with, for example, the -std=c99 or -ansi flag.

_POSIX_C_SOURCE
Defining this macro causes header files to expose definitions as follows:

  • The value 1 exposes definitions conforming to POSIX.1-1990 and ISO C (1990).

  • The value 2 or greater additionally exposes definitions for POSIX.2-1992.

  • The value 199309L or greater additionally exposes definitions for POSIX.1b (real-time extensions).

  • The value 199506L or greater additionally exposes definitions for POSIX.1c (threads).

  • (Since glibc 2.3.3) The value 200112L or greater additionally exposes definitions corresponding to the POSIX.1-2001 base specification (excluding the XSI extension). This value also causes C95 (since glibc 2.12) and C99 (since glibc 2.10) features to be exposed (in other words, the equivalent of defining _ISOC99_SOURCE).

  • (Since glibc 2.10) The value 200809L or greater additionally exposes definitions corresponding to the POSIX.1-2008 base specification (excluding the XSI extension).

_POSIX_SOURCE
Defining this obsolete macro with any value is equivalent to defining _POSIX_C_SOURCE with the value 1.

Since this macro is obsolete, its usage is generally not documented when discussing feature test macro requirements in the man pages.

_XOPEN_SOURCE
Defining this macro causes header files to expose definitions as follows:

  • Defining with any value exposes definitions conforming to POSIX.1, POSIX.2, and XPG4.

  • The value 500 or greater additionally exposes definitions for SUSv2 (UNIX 98).

  • (Since glibc 2.2) The value 600 or greater additionally exposes definitions for SUSv3 (UNIX 03; i.e., the POSIX.1-2001 base specification plus the XSI extension) and C99 definitions.

  • (Since glibc 2.10) The value 700 or greater additionally exposes definitions for SUSv4 (i.e., the POSIX.1-2008 base specification plus the XSI extension).

If __STRICT_ANSI__ is not defined, or _XOPEN_SOURCE is defined with a value greater than or equal to 500 and neither _POSIX_SOURCE nor _POSIX_C_SOURCE is explicitly defined, then the following macros are implicitly defined:

  • _POSIX_SOURCE is defined with the value 1.

  • _POSIX_C_SOURCE is defined, according to the value of _XOPEN_SOURCE:

    _XOPEN_SOURCE < 500
    _POSIX_C_SOURCE is defined with the value 2.

    500 <= _XOPEN_SOURCE < 600
    _POSIX_C_SOURCE is defined with the value 199506L.

    600 <= _XOPEN_SOURCE < 700
    _POSIX_C_SOURCE is defined with the value 200112L.

    700 <= _XOPEN_SOURCE (since glibc 2.10)
    _POSIX_C_SOURCE is defined with the value 200809L.

In addition, defining _XOPEN_SOURCE with a value of 500 or greater produces the same effects as defining _XOPEN_SOURCE_EXTENDED.

_XOPEN_SOURCE_EXTENDED
If this macro is defined, and _XOPEN_SOURCE is defined, then expose definitions corresponding to the XPG4v2 (SUSv1) UNIX extensions (UNIX 95). Defining _XOPEN_SOURCE with a value of 500 or more also produces the same effect as defining _XOPEN_SOURCE_EXTENDED. Use of _XOPEN_SOURCE_EXTENDED in new source code should be avoided.

Since defining _XOPEN_SOURCE with a value of 500 or more has the same effect as defining _XOPEN_SOURCE_EXTENDED, the latter (obsolete) feature test macro is generally not described in the SYNOPSIS in man pages.

_ISOC99_SOURCE (since glibc 2.1.3)
Exposes declarations consistent with the ISO C99 standard.

Earlier glibc 2.1.x versions recognized an equivalent macro named _ISOC9X_SOURCE (because the C99 standard had not then been finalized). Although the use of this macro is obsolete, glibc continues to recognize it for backward compatibility.

Defining _ISOC99_SOURCE also exposes ISO C (1990) Amendment 1 (“C95”) definitions. (The primary change in C95 was support for international character sets.)

Invoking the C compiler with the option -std=c99 produces the same effects as defining this macro.

_ISOC11_SOURCE (since glibc 2.16)
Exposes declarations consistent with the ISO C11 standard. Defining this macro also enables C99 and C95 features (like _ISOC99_SOURCE).

Invoking the C compiler with the option -std=c11 produces the same effects as defining this macro.

_LARGEFILE64_SOURCE
Expose definitions for the alternative API specified by the LFS (Large File Summit) as a “transitional extension” to the Single UNIX Specification. (See .) The alternative API consists of a set of new objects (i.e., functions and types) whose names are suffixed with “64” (e.g., off64_t versus off_t, lseek64() versus lseek(), etc.). New programs should not employ this macro; instead _FILE_OFFSET_BITS=64 should be employed.

_LARGEFILE_SOURCE
This macro was historically used to expose certain functions (specifically fseeko(3) and ftello(3)) that address limitations of earlier APIs (fseek(3) and ftell(3)) that use long for file offsets. This macro is implicitly defined if _XOPEN_SOURCE is defined with a value greater than or equal to 500. New programs should not employ this macro; defining _XOPEN_SOURCE as just described or defining _FILE_OFFSET_BITS with the value 64 is the preferred mechanism to achieve the same result.

_FILE_OFFSET_BITS
Defining this macro with the value 64 automatically converts references to 32-bit functions and data types related to file I/O and filesystem operations into references to their 64-bit counterparts. This is useful for performing I/O on large files (> 2 Gigabytes) on 32-bit systems. It is also useful when calling functions like copy_file_range(2) that were added more recently and that come only in 64-bit flavors. (Defining this macro permits correctly written programs to use large files with only a recompilation being required.)

64-bit systems naturally permit file sizes greater than 2 Gigabytes, and on those systems this macro has no effect.

_TIME_BITS
Defining this macro with the value 64 changes the width of time_t(3type) to 64-bit which allows handling of timestamps beyond 2038. It is closely related to _FILE_OFFSET_BITS and depending on implementation, may require it set. This macro is available as of glibc 2.34.

_BSD_SOURCE (deprecated since glibc 2.20)
Defining this macro with any value causes header files to expose BSD-derived definitions.

In glibc versions up to and including 2.18, defining this macro also causes BSD definitions to be preferred in some situations where standards conflict, unless one or more of _SVID_SOURCE, _POSIX_SOURCE, _POSIX_C_SOURCE, _XOPEN_SOURCE, _XOPEN_SOURCE_EXTENDED, or _GNU_SOURCE is defined, in which case BSD definitions are disfavored. Since glibc 2.19, _BSD_SOURCE no longer causes BSD definitions to be preferred in case of conflicts.

Since glibc 2.20, this macro is deprecated. It now has the same effect as defining _DEFAULT_SOURCE, but generates a compile-time warning (unless _DEFAULT_SOURCE is also defined). Use _DEFAULT_SOURCE instead. To allow code that requires _BSD_SOURCE in glibc 2.19 and earlier and _DEFAULT_SOURCE in glibc 2.20 and later to compile without warnings, define both _BSD_SOURCE and _DEFAULT_SOURCE.

_SVID_SOURCE (deprecated since glibc 2.20)
Defining this macro with any value causes header files to expose System V-derived definitions. (SVID == System V Interface Definition; see standards(7).)

Since glibc 2.20, this macro is deprecated in the same fashion as _BSD_SOURCE.

_DEFAULT_SOURCE (since glibc 2.19)
This macro can be defined to ensure that the “default” definitions are provided even when the defaults would otherwise be disabled, as happens when individual macros are explicitly defined, or the compiler is invoked in one of its “standard” modes (e.g., cc -std=c99). Defining _DEFAULT_SOURCE without defining other individual macros or invoking the compiler in one of its “standard” modes has no effect.

The “default” definitions comprise those required by POSIX.1-2008 and ISO C99, as well as various definitions originally derived from BSD and System V. On glibc 2.19 and earlier, these defaults were approximately equivalent to explicitly defining the following:

cc -D_BSD_SOURCE -D_SVID_SOURCE -D_POSIX_C_SOURCE=200809

_ATFILE_SOURCE (since glibc 2.4)
Defining this macro with any value causes header files to expose declarations of a range of functions with the suffix “at”; see openat(2). Since glibc 2.10, this macro is also implicitly defined if _POSIX_C_SOURCE is defined with a value greater than or equal to 200809L.

_GNU_SOURCE
Defining this macro (with any value) implicitly defines _ATFILE_SOURCE, _LARGEFILE64_SOURCE, _ISOC99_SOURCE, _XOPEN_SOURCE_EXTENDED, _POSIX_SOURCE, _POSIX_C_SOURCE with the value 200809L (200112L before glibc 2.10; 199506L before glibc 2.5; 199309L before glibc 2.1) and _XOPEN_SOURCE with the value 700 (600 before glibc 2.10; 500 before glibc 2.2). In addition, various GNU-specific extensions are also exposed.

Since glibc 2.19, defining _GNU_SOURCE also has the effect of implicitly defining _DEFAULT_SOURCE. Before glibc 2.20, defining _GNU_SOURCE also had the effect of implicitly defining _BSD_SOURCE and _SVID_SOURCE.

_REENTRANT
Historically, on various C libraries it was necessary to define this macro in all multithreaded code. (Some C libraries may still require this.) In glibc, this macro also exposed definitions of certain reentrant functions.

However, glibc has been thread-safe by default for many years; since glibc 2.3, the only effect of defining _REENTRANT has been to enable one or two of the same declarations that are also enabled by defining _POSIX_C_SOURCE with a value of 199606L or greater.

_REENTRANT is now obsolete. In glibc 2.25 and later, defining _REENTRANT is equivalent to defining _POSIX_C_SOURCE with the value 199606L. If a higher POSIX conformance level is selected by any other means (such as _POSIX_C_SOURCE itself, _XOPEN_SOURCE, _DEFAULT_SOURCE, or _GNU_SOURCE), then defining _REENTRANT has no effect.

This macro is automatically defined if one compiles with cc -pthread.

_THREAD_SAFE
Synonym for the (deprecated) _REENTRANT, provided for compatibility with some other implementations.

_FORTIFY_SOURCE (since glibc 2.3.4)
Defining this macro causes some lightweight checks to be performed to detect some buffer overflow errors when employing various string and memory manipulation functions (for example, memcpy(3), memset(3), stpcpy(3), strcpy(3), strncpy(3), strcat(3), strncat(3), sprintf(3), snprintf(3), vsprintf(3), vsnprintf(3), gets(3), and wide character variants thereof). For some functions, argument consistency is checked; for example, a check is made that open(2) has been supplied with a mode argument when the specified flags include O_CREAT. Not all problems are detected, just some common cases.

If _FORTIFY_SOURCE is set to 1, with compiler optimization level 1 (gcc -O1) and above, checks that shouldn’t change the behavior of conforming programs are performed. With _FORTIFY_SOURCE set to 2, some more checking is added, but some conforming programs might fail.

Some of the checks can be performed at compile time (via macros logic implemented in header files), and result in compiler warnings; other checks take place at run time, and result in a run-time error if the check fails.

With _FORTIFY_SOURCE set to 3, additional checking is added to intercept some function calls used with an argument of variable size where the compiler can deduce an upper bound for its value. For example, a program where malloc(3)’s size argument is variable can now be fortified.

Use of this macro requires compiler support, available since gcc 4.0 and clang 2.6. Use of _FORTIFY_SOURCE set to 3 requires gcc 12.0 or later, or clang 9.0 or later, in conjunction with glibc 2.33 or later.

Default definitions, implicit definitions, and combining definitions

If no feature test macros are explicitly defined, then the following feature test macros are defined by default: _BSD_SOURCE (in glibc 2.19 and earlier), _SVID_SOURCE (in glibc 2.19 and earlier), _DEFAULT_SOURCE (since glibc 2.19), _POSIX_SOURCE, and _POSIX_C_SOURCE=200809L (200112L before glibc 2.10; 199506L before glibc 2.4; 199309L before glibc 2.1).

If any of __STRICT_ANSI__, _ISOC99_SOURCE, _ISOC11_SOURCE (since glibc 2.18), _POSIX_SOURCE, _POSIX_C_SOURCE, _XOPEN_SOURCE, _XOPEN_SOURCE_EXTENDED (in glibc 2.11 and earlier), _BSD_SOURCE (in glibc 2.19 and earlier), or _SVID_SOURCE (in glibc 2.19 and earlier) is explicitly defined, then _BSD_SOURCE, _SVID_SOURCE, and _DEFAULT_SOURCE are not defined by default.

If _POSIX_SOURCE and _POSIX_C_SOURCE are not explicitly defined, and either __STRICT_ANSI__ is not defined or _XOPEN_SOURCE is defined with a value of 500 or more, then

  • _POSIX_SOURCE is defined with the value 1; and

  • _POSIX_C_SOURCE is defined with one of the following values:

    • 2, if _XOPEN_SOURCE is defined with a value less than 500;

    • 199506L, if _XOPEN_SOURCE is defined with a value greater than or equal to 500 and less than 600; or

    • (since glibc 2.4) 200112L, if _XOPEN_SOURCE is defined with a value greater than or equal to 600 and less than 700.

    • (Since glibc 2.10) 200809L, if _XOPEN_SOURCE is defined with a value greater than or equal to 700.

    • Older versions of glibc do not know about the values 200112L and 200809L for _POSIX_C_SOURCE, and the setting of this macro will depend on the glibc version.

    • If _XOPEN_SOURCE is undefined, then the setting of _POSIX_C_SOURCE depends on the glibc version: 199506L, before glibc 2.4; 200112L, since glibc 2.4 to glibc 2.9; and 200809L, since glibc 2.10.

Multiple macros can be defined; the results are additive.

STANDARDS

POSIX.1 specifies _POSIX_C_SOURCE, _POSIX_SOURCE, and _XOPEN_SOURCE.

_FILE_OFFSET_BITS is not specified by any standard, but is employed on some other implementations.

_BSD_SOURCE, _SVID_SOURCE, _DEFAULT_SOURCE, _ATFILE_SOURCE, _GNU_SOURCE, _FORTIFY_SOURCE, _REENTRANT, and _THREAD_SAFE are specific to glibc.

HISTORY

_XOPEN_SOURCE_EXTENDED was specified by XPG4v2 (aka SUSv1), but is not present in SUSv2 and later.

NOTES

<features.h> is a Linux/glibc-specific header file. Other systems have an analogous file, but typically with a different name. This header file is automatically included by other header files as required: it is not necessary to explicitly include it in order to employ feature test macros.

According to which of the above feature test macros are defined, <features.h> internally defines various other macros that are checked by other glibc header files. These macros have names prefixed by two underscores (e.g., __USE_MISC). Programs should never define these macros directly: instead, the appropriate feature test macro(s) from the list above should be employed.

EXAMPLES

The program below can be used to explore how the various feature test macros are set depending on the glibc version and what feature test macros are explicitly set. The following shell session, on a system with glibc 2.10, shows some examples of what we would see:

$ cc ftm.c
$ ./a.out
_POSIX_SOURCE defined
_POSIX_C_SOURCE defined: 200809L
_BSD_SOURCE defined
_SVID_SOURCE defined
_ATFILE_SOURCE defined
$ cc -D_XOPEN_SOURCE=500 ftm.c
$ ./a.out
_POSIX_SOURCE defined
_POSIX_C_SOURCE defined: 199506L
_XOPEN_SOURCE defined: 500
$ cc -D_GNU_SOURCE ftm.c
$ ./a.out
_POSIX_SOURCE defined
_POSIX_C_SOURCE defined: 200809L
_ISOC99_SOURCE defined
_XOPEN_SOURCE defined: 700
_XOPEN_SOURCE_EXTENDED defined
_LARGEFILE64_SOURCE defined
_BSD_SOURCE defined
_SVID_SOURCE defined
_ATFILE_SOURCE defined
_GNU_SOURCE defined

Program source

/* ftm.c */
#include <stdint.h>
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
int
main(int argc, char *argv[])
{
#ifdef _POSIX_SOURCE
    printf("_POSIX_SOURCE defined

“); #endif #ifdef _POSIX_C_SOURCE printf("_POSIX_C_SOURCE defined: %jdL “, (intmax_t) _POSIX_C_SOURCE); #endif #ifdef _ISOC99_SOURCE printf("_ISOC99_SOURCE defined “); #endif #ifdef _ISOC11_SOURCE printf("_ISOC11_SOURCE defined “); #endif #ifdef _XOPEN_SOURCE printf("_XOPEN_SOURCE defined: %d “, _XOPEN_SOURCE); #endif #ifdef _XOPEN_SOURCE_EXTENDED printf("_XOPEN_SOURCE_EXTENDED defined “); #endif #ifdef _LARGEFILE64_SOURCE printf("_LARGEFILE64_SOURCE defined “); #endif #ifdef _FILE_OFFSET_BITS printf("_FILE_OFFSET_BITS defined: %d “, _FILE_OFFSET_BITS); #endif #ifdef _TIME_BITS printf("_TIME_BITS defined: %d “, _TIME_BITS); #endif #ifdef _BSD_SOURCE printf("_BSD_SOURCE defined “); #endif #ifdef _SVID_SOURCE printf("_SVID_SOURCE defined “); #endif #ifdef _DEFAULT_SOURCE printf("_DEFAULT_SOURCE defined “); #endif #ifdef _ATFILE_SOURCE printf("_ATFILE_SOURCE defined “); #endif #ifdef _GNU_SOURCE printf("_GNU_SOURCE defined “); #endif #ifdef _REENTRANT printf("_REENTRANT defined “); #endif #ifdef _THREAD_SAFE printf("_THREAD_SAFE defined “); #endif #ifdef _FORTIFY_SOURCE printf("_FORTIFY_SOURCE defined “); #endif exit(EXIT_SUCCESS); }

SEE ALSO

libc(7), standards(7), system_data_types(7)

The section “Feature Test Macros” under info libc.

/usr/include/features.h

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

515 - Linux cli command ALTER_POLICY

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_POLICY and provides detailed information about the command ALTER_POLICY, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_POLICY.

NAME 🖥️ ALTER_POLICY 🖥️

change the definition of a row-level security policy

SYNOPSIS

ALTER POLICY name ON table_name RENAME TO new_name

ALTER POLICY name ON table_name
    [ TO { role_name | PUBLIC | CURRENT_ROLE | CURRENT_USER | SESSION_USER } [, ...] ]
    [ USING ( using_expression ) ]
    [ WITH CHECK ( check_expression ) ]

DESCRIPTION

ALTER POLICY changes the definition of an existing row-level security policy. Note that ALTER POLICY only allows the set of roles to which the policy applies and the USING and WITH CHECK expressions to be modified. To change other properties of a policy, such as the command to which it applies or whether it is permissive or restrictive, the policy must be dropped and recreated.

To use ALTER POLICY, you must own the table that the policy applies to.

In the second form of ALTER POLICY, the role list, using_expression, and check_expression are replaced independently if specified. When one of those clauses is omitted, the corresponding part of the policy is unchanged.

PARAMETERS

name

The name of an existing policy to alter.

table_name

The name (optionally schema-qualified) of the table that the policy is on.

new_name

The new name for the policy.

role_name

The role(s) to which the policy applies. Multiple roles can be specified at one time. To apply the policy to all roles, use PUBLIC.

using_expression

The USING expression for the policy. See CREATE POLICY (CREATE_POLICY(7)) for details.

check_expression

The WITH CHECK expression for the policy. See CREATE POLICY (CREATE_POLICY(7)) for details.

COMPATIBILITY

ALTER POLICY is a PostgreSQL extension.

SEE ALSO

CREATE POLICY (CREATE_POLICY(7)), DROP POLICY (DROP_POLICY(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

516 - Linux cli command CREATE_ROLE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_ROLE and provides detailed information about the command CREATE_ROLE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_ROLE.

NAME 🖥️ CREATE_ROLE 🖥️

define a new database role

SYNOPSIS

CREATE ROLE name [ [ WITH ] option [ ... ] ]

where option can be:

      SUPERUSER | NOSUPERUSER
    | CREATEDB | NOCREATEDB
    | CREATEROLE | NOCREATEROLE
    | INHERIT | NOINHERIT
    | LOGIN | NOLOGIN
    | REPLICATION | NOREPLICATION
    | BYPASSRLS | NOBYPASSRLS
    | CONNECTION LIMIT connlimit
    | [ ENCRYPTED ] PASSWORD password | PASSWORD NULL
    | VALID UNTIL timestamp
    | IN ROLE role_name [, ...]
    | IN GROUP role_name [, ...]
    | ROLE role_name [, ...]
    | ADMIN role_name [, ...]
    | USER role_name [, ...]
    | SYSID uid

DESCRIPTION

CREATE ROLE adds a new role to a PostgreSQL database cluster. A role is an entity that can own database objects and have database privileges; a role can be considered a “user”, a “group”, or both depending on how it is used. Refer to Chapter 22 and Chapter 21 for information about managing users and authentication. You must have CREATEROLE privilege or be a database superuser to use this command.

Note that roles are defined at the database cluster level, and so are valid in all databases in the cluster.

During role creation it is possible to immediately assign the newly created role to be a member of an existing role, and also assign existing roles to be members of the newly created role. The rules for which initial role membership options are enabled are described below in the IN ROLE, ROLE, and ADMIN clauses. The GRANT(7) command has fine-grained option control during membership creation, and the ability to modify these options after the new role is created.

PARAMETERS

name

The name of the new role.

SUPERUSER
NOSUPERUSER

These clauses determine whether the new role is a “superuser”, who can override all access restrictions within the database. Superuser status is dangerous and should be used only when really needed. You must yourself be a superuser to create a new superuser. If not specified, NOSUPERUSER is the default.

CREATEDB
NOCREATEDB

These clauses define a roles ability to create databases. If CREATEDB is specified, the role being defined will be allowed to create new databases. Specifying NOCREATEDB will deny a role the ability to create databases. If not specified, NOCREATEDB is the default. Only superuser roles or roles with CREATEDB can specify CREATEDB.

CREATEROLE
NOCREATEROLE

These clauses determine whether a role will be permitted to create, alter, drop, comment on, and change the security label for other roles. See role creation for more details about what capabilities are conferred by this privilege. If not specified, NOCREATEROLE is the default.

INHERIT
NOINHERIT

This affects the membership inheritance status when this role is added as a member of another role, both in this and future commands. Specifically, it controls the inheritance status of memberships added with this command using the IN ROLE clause, and in later commands using the ROLE clause. It is also used as the default inheritance status when adding this role as a member using the GRANT command. If not specified, INHERIT is the default.

In PostgreSQL versions before 16, inheritance was a role-level attribute that controlled all runtime membership checks for that role.

LOGIN
NOLOGIN

These clauses determine whether a role is allowed to log in; that is, whether the role can be given as the initial session authorization name during client connection. A role having the LOGIN attribute can be thought of as a user. Roles without this attribute are useful for managing database privileges, but are not users in the usual sense of the word. If not specified, NOLOGIN is the default, except when CREATE ROLE is invoked through its alternative spelling CREATE USER.

REPLICATION
NOREPLICATION

These clauses determine whether a role is a replication role. A role must have this attribute (or be a superuser) in order to be able to connect to the server in replication mode (physical or logical replication) and in order to be able to create or drop replication slots. A role having the REPLICATION attribute is a very highly privileged role, and should only be used on roles actually used for replication. If not specified, NOREPLICATION is the default. Only superuser roles or roles with REPLICATION can specify REPLICATION.

BYPASSRLS
NOBYPASSRLS

These clauses determine whether a role bypasses every row-level security (RLS) policy. NOBYPASSRLS is the default. Only superuser roles or roles with BYPASSRLS can specify BYPASSRLS.

Note that pg_dump will set row_security to OFF by default, to ensure all contents of a table are dumped out. If the user running pg_dump does not have appropriate permissions, an error will be returned. However, superusers and the owner of the table being dumped always bypass RLS.

CONNECTION LIMIT connlimit

If role can log in, this specifies how many concurrent connections the role can make. -1 (the default) means no limit. Note that only normal connections are counted towards this limit. Neither prepared transactions nor background worker connections are counted towards this limit.

[ ENCRYPTED ] PASSWORD password
PASSWORD NULL

Sets the roles password. (A password is only of use for roles having the LOGIN attribute, but you can nonetheless define one for roles without it.) If you do not plan to use password authentication you can omit this option. If no password is specified, the password will be set to null and password authentication will always fail for that user. A null password can optionally be written explicitly as PASSWORD NULL.

Note

Specifying an empty string will also set the password to null, but that was not the case before PostgreSQL version 10. In earlier versions, an empty string could be used, or not, depending on the authentication method and the exact version, and libpq would refuse to use it in any case. To avoid the ambiguity, specifying an empty string should be avoided.

The password is always stored encrypted in the system catalogs. The ENCRYPTED keyword has no effect, but is accepted for backwards compatibility. The method of encryption is determined by the configuration parameter password_encryption. If the presented password string is already in MD5-encrypted or SCRAM-encrypted format, then it is stored as-is regardless of password_encryption (since the system cannot decrypt the specified encrypted password string, to encrypt it in a different format). This allows reloading of encrypted passwords during dump/restore.

VALID UNTIL timestamp

The VALID UNTIL clause sets a date and time after which the roles password is no longer valid. If this clause is omitted the password will be valid for all time.

IN ROLE role_name

The IN ROLE clause causes the new role to be automatically added as a member of the specified existing roles. The new membership will have the SET option enabled and the ADMIN option disabled. The INHERIT option will be enabled unless the NOINHERIT option is specified.

IN GROUP role_name

IN GROUP is an obsolete spelling of IN ROLE.

ROLE role_name

The ROLE clause causes one or more specified existing roles to be automatically added as members, with the SET option enabled. This in effect makes the new role a “group”. Roles named in this clause with the role-level INHERIT attribute will have the INHERIT option enabled in the new membership. New memberships will have the ADMIN option disabled.

ADMIN role_name

The ADMIN clause has the same effect as ROLE, but the named roles are added as members of the new role with ADMIN enabled, giving them the right to grant membership in the new role to others.

USER role_name

The USER clause is an obsolete spelling of the ROLE clause.

SYSID uid

The SYSID clause is ignored, but is accepted for backwards compatibility.

NOTES

Use ALTER ROLE to change the attributes of a role, and DROP ROLE to remove a role. All the attributes specified by CREATE ROLE can be modified by later ALTER ROLE commands.

The preferred way to add and remove members of roles that are being used as groups is to use GRANT and REVOKE.

The VALID UNTIL clause defines an expiration time for a password only, not for the role per se. In particular, the expiration time is not enforced when logging in using a non-password-based authentication method.

The role attributes defined here are non-inheritable, i.e., being a member of a role with, e.g., CREATEDB will not allow the member to create new databases even if the membership grant has the INHERIT option. Of course, if the membership grant has the SET option the member role would be able to SET ROLE to the createdb role and then create a new database.

The membership grants created by the IN ROLE, ROLE, and ADMIN clauses have the role executing this command as the grantor.

The INHERIT attribute is the default for reasons of backwards compatibility: in prior releases of PostgreSQL, users always had access to all privileges of groups they were members of. However, NOINHERIT provides a closer match to the semantics specified in the SQL standard.

PostgreSQL includes a program createuser(1) that has the same functionality as CREATE ROLE (in fact, it calls this command) but can be run from the command shell.

The CONNECTION LIMIT option is only enforced approximately; if two new sessions start at about the same time when just one connection “slot” remains for the role, it is possible that both will fail. Also, the limit is never enforced for superusers.

Caution must be exercised when specifying an unencrypted password with this command. The password will be transmitted to the server in cleartext, and it might also be logged in the clients command history or the server log. The command createuser(1), however, transmits the password encrypted. Also, psql(1) contains a command \password that can be used to safely change the password later.

EXAMPLES

Create a role that can log in, but dont give it a password:

CREATE ROLE jonathan LOGIN;

Create a role with a password:

CREATE USER davide WITH PASSWORD jw8s0F4;

(CREATE USER is the same as CREATE ROLE except that it implies LOGIN.)

Create a role with a password that is valid until the end of 2004. After one second has ticked in 2005, the password is no longer valid.

CREATE ROLE miriam WITH LOGIN PASSWORD jw8s0F4 VALID UNTIL 2005-01-01;

Create a role that can create databases and manage roles:

CREATE ROLE admin WITH CREATEDB CREATEROLE;

COMPATIBILITY

The CREATE ROLE statement is in the SQL standard, but the standard only requires the syntax

CREATE ROLE name [ WITH ADMIN role_name ]

Multiple initial administrators, and all the other options of CREATE ROLE, are PostgreSQL extensions.

The SQL standard defines the concepts of users and roles, but it regards them as distinct concepts and leaves all commands defining users to be specified by each database implementation. In PostgreSQL we have chosen to unify users and roles into a single kind of entity. Roles therefore have many more optional attributes than they do in the standard.

The behavior specified by the SQL standard is most closely approximated creating SQL-standard users as PostgreSQL roles with the NOINHERIT option, and SQL-standard roles as PostgreSQL roles with the INHERIT option.

SEE ALSO

SET ROLE (SET_ROLE(7)), ALTER ROLE (ALTER_ROLE(7)), DROP ROLE (DROP_ROLE(7)), GRANT(7), REVOKE(7), createuser(1), createrole_self_grant

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

517 - Linux cli command EVP_MD-BLAKE2ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_MD-BLAKE2ssl and provides detailed information about the command EVP_MD-BLAKE2ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_MD-BLAKE2ssl.

NAME 🖥️ EVP_MD-BLAKE2ssl 🖥️

BLAKE2 - The BLAKE2 EVP_MD implementation

DESCRIPTION

Support for computing BLAKE2 digests through the EVP_MD API.

Identities

This implementation is only available with the default provider, and includes the following varieties:

BLAKE2S-256
Known names are “BLAKE2S-256” and “BLAKE2s256”.

BLAKE2B-512
Known names are “BLAKE2B-512” and “BLAKE2b512”.

Gettable Parameters

This implementation supports the common gettable parameters described in EVP_MD-common (7).

Settable Context Parameters

The BLAKE2B-512 implementation supports the following OSSL_PARAM (3) entries which are settable for an EVP_MD_CTX with EVP_DigestInit_ex2 (3) or EVP_MD_CTX_set_params (3):

“size” (OSSL_DIGEST_PARAM_SIZE) <unsigned integer>
Sets a different digest length for the EVP_DigestFinal (3) output. The value of the “size” parameter must not exceed the default digest length (64 for BLAKE2B-512). The parameter must be set with the EVP_DigestInit_ex2 (3) call to have an immediate effect. When set with EVP_MD_CTX_set_params (3) it will have an effect only if the EVP_MD_CTX context is reinitialized.

SEE ALSO

provider-digest (7), OSSL_PROVIDER-default (7)

HISTORY

This functionality was added in OpenSSL 3.0.

The variable size support was added in OpenSSL 3.2 for BLAKE2B-512.

COPYRIGHT

Copyright 2020-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

518 - Linux cli command gitworkflows

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command gitworkflows and provides detailed information about the command gitworkflows, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the gitworkflows.

NAME 🖥️ gitworkflows 🖥️

An overview of recommended workflows with Git

SYNOPSIS

git *

DESCRIPTION

This document attempts to write down and motivate some of the workflow elements used for git.git itself. Many ideas apply in general, though the full workflow is rarely required for smaller projects with fewer people involved.

We formulate a set of rules for quick reference, while the prose tries to motivate each of them. Do not always take them literally; you should value good reasons for your actions higher than manpages such as this one.

SEPARATE CHANGES

As a general rule, you should try to split your changes into small logical steps, and commit each of them. They should be consistent, working independently of any later commits, pass the test suite, etc. This makes the review process much easier, and the history much more useful for later inspection and analysis, for example with git-blame(1) and git-bisect(1).

To achieve this, try to split your work into small steps from the very beginning. It is always easier to squash a few commits together than to split one big commit into several. Don’t be afraid of making too small or imperfect steps along the way. You can always go back later and edit the commits with git rebase –interactive before you publish them. You can use git stash push –keep-index to run the test suite independent of other uncommitted changes; see the EXAMPLES section of git-stash(1).

MANAGING BRANCHES

There are two main tools that can be used to include changes from one branch on another: git-merge(1) and git-cherry-pick(1).

Merges have many advantages, so we try to solve as many problems as possible with merges alone. Cherry-picking is still occasionally useful; see “Merging upwards” below for an example.

Most importantly, merging works at the branch level, while cherry-picking works at the commit level. This means that a merge can carry over the changes from 1, 10, or 1000 commits with equal ease, which in turn means the workflow scales much better to a large number of contributors (and contributions). Merges are also easier to understand because a merge commit is a “promise” that all changes from all its parents are now included.

There is a tradeoff of course: merges require a more careful branch management. The following subsections discuss the important points.

Graduation

As a given feature goes from experimental to stable, it also “graduates” between the corresponding branches of the software. git.git uses the following integration branches:

·

maint tracks the commits that should go into the next “maintenance release”, i.e., update of the last released stable version;

·

master tracks the commits that should go into the next release;

·

next is intended as a testing branch for topics being tested for stability for master.

There is a fourth official branch that is used slightly differently:

·

seen (patches seen by the maintainer) is an integration branch for things that are not quite ready for inclusion yet (see “Integration Branches” below).

Each of the four branches is usually a direct descendant of the one above it.

Conceptually, the feature enters at an unstable branch (usually next or seen), and “graduates” to master for the next release once it is considered stable enough.

Merging upwards

The “downwards graduation” discussed above cannot be done by actually merging downwards, however, since that would merge all changes on the unstable branch into the stable one. Hence the following:

Example 1. Merge upwards

Always commit your fixes to the oldest supported branch that requires them. Then (periodically) merge the integration branches upwards into each other.

This gives a very controlled flow of fixes. If you notice that you have applied a fix to e.g. master that is also required in maint, you will need to cherry-pick it (using git-cherry-pick(1)) downwards. This will happen a few times and is nothing to worry about unless you do it very frequently.

Topic branches

Any nontrivial feature will require several patches to implement, and may get extra bugfixes or improvements during its lifetime.

Committing everything directly on the integration branches leads to many problems: Bad commits cannot be undone, so they must be reverted one by one, which creates confusing histories and further error potential when you forget to revert part of a group of changes. Working in parallel mixes up the changes, creating further confusion.

Use of “topic branches” solves these problems. The name is pretty self explanatory, with a caveat that comes from the “merge upwards” rule above:

Example 2. Topic branches

Make a side branch for every topic (feature, bugfix, …). Fork it off at the oldest integration branch that you will eventually want to merge it into.

Many things can then be done very naturally:

·

To get the feature/bugfix into an integration branch, simply merge it. If the topic has evolved further in the meantime, merge again. (Note that you do not necessarily have to merge it to the oldest integration branch first. For example, you can first merge a bugfix to next, give it some testing time, and merge to maint when you know it is stable.)

·

If you find you need new features from the branch other to continue working on your topic, merge other to topic. (However, do not do this “just habitually”, see below.)

·

If you find you forked off the wrong branch and want to move it “back in time”, use git-rebase(1).

Note that the last point clashes with the other two: a topic that has been merged elsewhere should not be rebased. See the section on RECOVERING FROM UPSTREAM REBASE in git-rebase(1).

We should point out that “habitually” (regularly for no real reason) merging an integration branch into your topics — and by extension, merging anything upstream into anything downstream on a regular basis — is frowned upon:

Example 3. Merge to downstream only at well-defined points

Do not merge to downstream except with a good reason: upstream API changes affect your branch; your branch no longer merges to upstream cleanly; etc.

Otherwise, the topic that was merged to suddenly contains more than a single (well-separated) change. The many resulting small merges will greatly clutter up history. Anyone who later investigates the history of a file will have to find out whether that merge affected the topic in development. An upstream might even inadvertently be merged into a “more stable” branch. And so on.

Throw-away integration

If you followed the last paragraph, you will now have many small topic branches, and occasionally wonder how they interact. Perhaps the result of merging them does not even work? But on the other hand, we want to avoid merging them anywhere “stable” because such merges cannot easily be undone.

The solution, of course, is to make a merge that we can undo: merge into a throw-away branch.

Example 4. Throw-away integration branches

To test the interaction of several topics, merge them into a throw-away branch. You must never base any work on such a branch!

If you make it (very) clear that this branch is going to be deleted right after the testing, you can even publish this branch, for example to give the testers a chance to work with it, or other developers a chance to see if their in-progress work will be compatible. git.git has such an official throw-away integration branch called seen.

Branch management for a release

Assuming you are using the merge approach discussed above, when you are releasing your project you will need to do some additional branch management work.

A feature release is created from the master branch, since master tracks the commits that should go into the next feature release.

The master branch is supposed to be a superset of maint. If this condition does not hold, then maint contains some commits that are not included on master. The fixes represented by those commits will therefore not be included in your feature release.

To verify that master is indeed a superset of maint, use git log:

Example 5. Verify master is a superset of maint

git log master..maint

This command should not list any commits. Otherwise, check out master and merge maint into it.

Now you can proceed with the creation of the feature release. Apply a tag to the tip of master indicating the release version:

Example 6. Release tagging

git tag -s -m “Git X.Y.Z” vX.Y.Z master

You need to push the new tag to a public Git server (see “DISTRIBUTED WORKFLOWS” below). This makes the tag available to others tracking your project. The push could also trigger a post-update hook to perform release-related items such as building release tarballs and preformatted documentation pages.

Similarly, for a maintenance release, maint is tracking the commits to be released. Therefore, in the steps above simply tag and push maint rather than master.

Maintenance branch management after a feature release

After a feature release, you need to manage your maintenance branches.

First, if you wish to continue to release maintenance fixes for the feature release made before the recent one, then you must create another branch to track commits for that previous release.

To do this, the current maintenance branch is copied to another branch named with the previous release version number (e.g. maint-X.Y.(Z-1) where X.Y.Z is the current release).

Example 7. Copy maint

git branch maint-X.Y.(Z-1) maint

The maint branch should now be fast-forwarded to the newly released code so that maintenance fixes can be tracked for the current release:

Example 8. Update maint to new release

·

git checkout maint

·

git merge –ff-only master

If the merge fails because it is not a fast-forward, then it is possible some fixes on maint were missed in the feature release. This will not happen if the content of the branches was verified as described in the previous section.

Branch management for next and seen after a feature release

After a feature release, the integration branch next may optionally be rewound and rebuilt from the tip of master using the surviving topics on next:

Example 9. Rewind and rebuild next

·

git switch -C next master

·

git merge ai/topic_in_next1

·

git merge ai/topic_in_next2

·

…

The advantage of doing this is that the history of next will be clean. For example, some topics merged into next may have initially looked promising, but were later found to be undesirable or premature. In such a case, the topic is reverted out of next but the fact remains in the history that it was once merged and reverted. By recreating next, you give another incarnation of such topics a clean slate to retry, and a feature release is a good point in history to do so.

If you do this, then you should make a public announcement indicating that next was rewound and rebuilt.

The same rewind and rebuild process may be followed for seen. A public announcement is not necessary since seen is a throw-away branch, as described above.

DISTRIBUTED WORKFLOWS

After the last section, you should know how to manage topics. In general, you will not be the only person working on the project, so you will have to share your work.

Roughly speaking, there are two important workflows: merge and patch. The important difference is that the merge workflow can propagate full history, including merges, while patches cannot. Both workflows can be used in parallel: in git.git, only subsystem maintainers use the merge workflow, while everyone else sends patches.

Note that the maintainer(s) may impose restrictions, such as “Signed-off-by” requirements, that all commits/patches submitted for inclusion must adhere to. Consult your project’s documentation for more information.

Merge workflow

The merge workflow works by copying branches between upstream and downstream. Upstream can merge contributions into the official history; downstream base their work on the official history.

There are three main tools that can be used for this:

·

git-push(1) copies your branches to a remote repository, usually to one that can be read by all involved parties;

·

git-fetch(1) that copies remote branches to your repository; and

·

git-pull(1) that does fetch and merge in one go.

Note the last point. Do not use git pull unless you actually want to merge the remote branch.

Getting changes out is easy:

Example 10. Push/pull: Publishing branches/topics

git push <remote> <branch> and tell everyone where they can fetch from.

You will still have to tell people by other means, such as mail. (Git provides the git-request-pull(1) to send preformatted pull requests to upstream maintainers to simplify this task.)

If you just want to get the newest copies of the integration branches, staying up to date is easy too:

Example 11. Push/pull: Staying up to date

Use git fetch <remote> or git remote update to stay up to date.

Then simply fork your topic branches from the stable remotes as explained earlier.

If you are a maintainer and would like to merge other people’s topic branches to the integration branches, they will typically send a request to do so by mail. Such a request looks like

Please pull from

In that case, git pull can do the fetch and merge in one go, as follows.

Example 12. Push/pull: Merging remote topics

git pull <URL> <branch>

Occasionally, the maintainer may get merge conflicts when they try to pull changes from downstream. In this case, they can ask downstream to do the merge and resolve the conflicts themselves (perhaps they will know better how to resolve them). It is one of the rare cases where downstream should merge from upstream.

Patch workflow

If you are a contributor that sends changes upstream in the form of emails, you should use topic branches as usual (see above). Then use git-format-patch(1) to generate the corresponding emails (highly recommended over manually formatting them because it makes the maintainer’s life easier).

Example 13. format-patch/am: Publishing branches/topics

·

git format-patch -M upstream..topic to turn them into preformatted patch files

·

git send-email –to=<recipient> <patches>

See the git-format-patch(1) and git-send-email(1) manpages for further usage notes.

If the maintainer tells you that your patch no longer applies to the current upstream, you will have to rebase your topic (you cannot use a merge because you cannot format-patch merges):

Example 14. format-patch/am: Keeping topics up to date

git pull –rebase <URL> <branch>

You can then fix the conflicts during the rebase. Presumably you have not published your topic other than by mail, so rebasing it is not a problem.

If you receive such a patch series (as maintainer, or perhaps as a reader of the mailing list it was sent to), save the mails to files, create a new topic branch and use git am to import the commits:

Example 15. format-patch/am: Importing patches

git am < patch

One feature worth pointing out is the three-way merge, which can help if you get conflicts: git am -3 will use index information contained in patches to figure out the merge base. See git-am(1) for other options.

SEE ALSO

gittutorial(7), git-push(1), git-pull(1), git-merge(1), git-rebase(1), git-format-patch(1), git-send-email(1), git-am(1)

GIT

Part of the git(1) suite

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

519 - Linux cli command ALTER_SYSTEM

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_SYSTEM and provides detailed information about the command ALTER_SYSTEM, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_SYSTEM.

NAME 🖥️ ALTER_SYSTEM 🖥️

change a server configuration parameter

SYNOPSIS

ALTER SYSTEM SET configuration_parameter { TO | = } { value [, ...] | DEFAULT }

ALTER SYSTEM RESET configuration_parameter
ALTER SYSTEM RESET ALL

DESCRIPTION

ALTER SYSTEM is used for changing server configuration parameters across the entire database cluster. It can be more convenient than the traditional method of manually editing the postgresql.conf file. ALTER SYSTEM writes the given parameter setting to the postgresql.auto.conf file, which is read in addition to postgresql.conf. Setting a parameter to DEFAULT, or using the RESET variant, removes that configuration entry from the postgresql.auto.conf file. Use RESET ALL to remove all such configuration entries.

Values set with ALTER SYSTEM will be effective after the next server configuration reload, or after the next server restart in the case of parameters that can only be changed at server start. A server configuration reload can be commanded by calling the SQL function pg_reload_conf(), running pg_ctl reload, or sending a SIGHUP signal to the main server process.

Only superusers and users granted ALTER SYSTEM privilege on a parameter can change it using ALTER SYSTEM. Also, since this command acts directly on the file system and cannot be rolled back, it is not allowed inside a transaction block or function.

PARAMETERS

configuration_parameter

Name of a settable configuration parameter. Available parameters are documented in Chapter 20.

value

New value of the parameter. Values can be specified as string constants, identifiers, numbers, or comma-separated lists of these, as appropriate for the particular parameter. Values that are neither numbers nor valid identifiers must be quoted. DEFAULT can be written to specify removing the parameter and its value from postgresql.auto.conf.

For some list-accepting parameters, quoted values will produce double-quoted output to preserve whitespace and commas; for others, double-quotes must be used inside single-quoted strings to get this effect.

NOTES

This command cant be used to set data_directory, nor parameters that are not allowed in postgresql.conf (e.g., preset options).

See Section 20.1 for other ways to set the parameters.

EXAMPLES

Set the wal_level:

ALTER SYSTEM SET wal_level = replica;

Undo that, restoring whatever setting was effective in postgresql.conf:

ALTER SYSTEM RESET wal_level;

COMPATIBILITY

The ALTER SYSTEM statement is a PostgreSQL extension.

SEE ALSO

SET(7), SHOW(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

520 - Linux cli command CLUSTER

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CLUSTER and provides detailed information about the command CLUSTER, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CLUSTER.

NAME 🖥️ CLUSTER 🖥️

cluster a table according to an index

SYNOPSIS

CLUSTER [VERBOSE] table_name [ USING index_name ]
CLUSTER ( option [, ...] ) table_name [ USING index_name ]
CLUSTER [VERBOSE]

where option can be one of:

    VERBOSE [ boolean ]

DESCRIPTION

CLUSTER instructs PostgreSQL to cluster the table specified by table_name based on the index specified by index_name. The index must already have been defined on table_name.

When a table is clustered, it is physically reordered based on the index information. Clustering is a one-time operation: when the table is subsequently updated, the changes are not clustered. That is, no attempt is made to store new or updated rows according to their index order. (If one wishes, one can periodically recluster by issuing the command again. Also, setting the tables fillfactor storage parameter to less than 100% can aid in preserving cluster ordering during updates, since updated rows are kept on the same page if enough space is available there.)

When a table is clustered, PostgreSQL remembers which index it was clustered by. The form CLUSTER table_name reclusters the table using the same index as before. You can also use the CLUSTER or SET WITHOUT CLUSTER forms of ALTER TABLE to set the index to be used for future cluster operations, or to clear any previous setting.

CLUSTER without a table_name reclusters all the previously-clustered tables in the current database that the calling user owns, or all such tables if called by a superuser. This form of CLUSTER cannot be executed inside a transaction block.

When a table is being clustered, an ACCESS EXCLUSIVE lock is acquired on it. This prevents any other database operations (both reads and writes) from operating on the table until the CLUSTER is finished.

PARAMETERS

table_name

The name (possibly schema-qualified) of a table.

index_name

The name of an index.

VERBOSE

Prints a progress report as each table is clustered.

boolean

Specifies whether the selected option should be turned on or off. You can write TRUE, ON, or 1 to enable the option, and FALSE, OFF, or 0 to disable it. The boolean value can also be omitted, in which case TRUE is assumed.

NOTES

In cases where you are accessing single rows randomly within a table, the actual order of the data in the table is unimportant. However, if you tend to access some data more than others, and there is an index that groups them together, you will benefit from using CLUSTER. If you are requesting a range of indexed values from a table, or a single indexed value that has multiple rows that match, CLUSTER will help because once the index identifies the table page for the first row that matches, all other rows that match are probably already on the same table page, and so you save disk accesses and speed up the query.

CLUSTER can re-sort the table using either an index scan on the specified index, or (if the index is a b-tree) a sequential scan followed by sorting. It will attempt to choose the method that will be faster, based on planner cost parameters and available statistical information.

When an index scan is used, a temporary copy of the table is created that contains the table data in the index order. Temporary copies of each index on the table are created as well. Therefore, you need free space on disk at least equal to the sum of the table size and the index sizes.

When a sequential scan and sort is used, a temporary sort file is also created, so that the peak temporary space requirement is as much as double the table size, plus the index sizes. This method is often faster than the index scan method, but if the disk space requirement is intolerable, you can disable this choice by temporarily setting enable_sort to off.

It is advisable to set maintenance_work_mem to a reasonably large value (but not more than the amount of RAM you can dedicate to the CLUSTER operation) before clustering.

Because the planner records statistics about the ordering of tables, it is advisable to run ANALYZE on the newly clustered table. Otherwise, the planner might make poor choices of query plans.

Because CLUSTER remembers which indexes are clustered, one can cluster the tables one wants clustered manually the first time, then set up a periodic maintenance script that executes CLUSTER without any parameters, so that the desired tables are periodically reclustered.

Each backend running CLUSTER will report its progress in the pg_stat_progress_cluster view. See Section 28.4.2 for details.

Clustering a partitioned table clusters each of its partitions using the partition of the specified partitioned index. When clustering a partitioned table, the index may not be omitted. CLUSTER on a partitioned table cannot be executed inside a transaction block.

EXAMPLES

Cluster the table employees on the basis of its index employees_ind:

CLUSTER employees USING employees_ind;

Cluster the employees table using the same index that was used before:

CLUSTER employees;

Cluster all tables in the database that have previously been clustered:

CLUSTER;

COMPATIBILITY

There is no CLUSTER statement in the SQL standard.

The syntax

CLUSTER index_name ON table_name

is also supported for compatibility with pre-8.3 PostgreSQL versions.

SEE ALSO

clusterdb(1), Section 28.4.2

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

521 - Linux cli command ALTER_PUBLICATION

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_PUBLICATION and provides detailed information about the command ALTER_PUBLICATION, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_PUBLICATION.

NAME 🖥️ ALTER_PUBLICATION 🖥️

change the definition of a publication

SYNOPSIS

ALTER PUBLICATION name ADD publication_object [, ...]
ALTER PUBLICATION name SET publication_object [, ...]
ALTER PUBLICATION name DROP publication_object [, ...]
ALTER PUBLICATION name SET ( publication_parameter [= value] [, ... ] )
ALTER PUBLICATION name OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }
ALTER PUBLICATION name RENAME TO new_name

where publication_object is one of:

    TABLE [ ONLY ] table_name [ * ] [ ( column_name [, ... ] ) ] [ WHERE ( expression ) ] [, ... ]
    TABLES IN SCHEMA { schema_name | CURRENT_SCHEMA } [, ... ]

DESCRIPTION

The command ALTER PUBLICATION can change the attributes of a publication.

The first three variants change which tables/schemas are part of the publication. The SET clause will replace the list of tables/schemas in the publication with the specified list; the existing tables/schemas that were present in the publication will be removed. The ADD and DROP clauses will add and remove one or more tables/schemas from the publication. Note that adding tables/schemas to a publication that is already subscribed to will require an ALTER SUBSCRIPTION … REFRESH PUBLICATION action on the subscribing side in order to become effective. Note also that DROP TABLES IN SCHEMA will not drop any schema tables that were specified using FOR TABLE/ ADD TABLE, and the combination of DROP with a WHERE clause is not allowed.

The fourth variant of this command listed in the synopsis can change all of the publication properties specified in CREATE PUBLICATION (CREATE_PUBLICATION(7)). Properties not mentioned in the command retain their previous settings.

The remaining variants change the owner and the name of the publication.

You must own the publication to use ALTER PUBLICATION. Adding a table to a publication additionally requires owning that table. The ADD TABLES IN SCHEMA and SET TABLES IN SCHEMA to a publication requires the invoking user to be a superuser. To alter the owner, you must be able to SET ROLE to the new owning role, and that role must have CREATE privilege on the database. Also, the new owner of a FOR ALL TABLES or FOR TABLES IN SCHEMA publication must be a superuser. However, a superuser can change the ownership of a publication regardless of these restrictions.

Adding/Setting any schema when the publication also publishes a table with a column list, and vice versa is not supported.

PARAMETERS

name

The name of an existing publication whose definition is to be altered.

table_name

Name of an existing table. If ONLY is specified before the table name, only that table is affected. If ONLY is not specified, the table and all its descendant tables (if any) are affected. Optionally, * can be specified after the table name to explicitly indicate that descendant tables are included.

Optionally, a column list can be specified. See CREATE PUBLICATION (CREATE_PUBLICATION(7)) for details. Note that a subscription having several publications in which the same table has been published with different column lists is not supported. See Warning: Combining Column Lists from Multiple Publications for details of potential problems when altering column lists.

If the optional WHERE clause is specified, rows for which the expression evaluates to false or null will not be published. Note that parentheses are required around the expression. The expression is evaluated with the role used for the replication connection.

schema_name

Name of an existing schema.

SET ( publication_parameter [= value] [, … ] )

This clause alters publication parameters originally set by CREATE PUBLICATION (CREATE_PUBLICATION(7)). See there for more information.

new_owner

The user name of the new owner of the publication.

new_name

The new name for the publication.

EXAMPLES

Change the publication to publish only deletes and updates:

ALTER PUBLICATION noinsert SET (publish = update, delete);

Add some tables to the publication:

ALTER PUBLICATION mypublication ADD TABLE users (user_id, firstname), departments;

Change the set of columns published for a table:

ALTER PUBLICATION mypublication SET TABLE users (user_id, firstname, lastname), TABLE departments;

Add schemas marketing and sales to the publication sales_publication:

ALTER PUBLICATION sales_publication ADD TABLES IN SCHEMA marketing, sales;

Add tables users, departments and schema production to the publication production_publication:

ALTER PUBLICATION production_publication ADD TABLE users, departments, TABLES IN SCHEMA production;

COMPATIBILITY

ALTER PUBLICATION is a PostgreSQL extension.

SEE ALSO

CREATE PUBLICATION (CREATE_PUBLICATION(7)), DROP PUBLICATION (DROP_PUBLICATION(7)), CREATE SUBSCRIPTION (CREATE_SUBSCRIPTION(7)), ALTER SUBSCRIPTION (ALTER_SUBSCRIPTION(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

522 - Linux cli command posixoptions

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command posixoptions and provides detailed information about the command posixoptions, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the posixoptions.

NAME 🖥️ posixoptions 🖥️

optional parts of the POSIX standard

DESCRIPTION

The POSIX standard (the information below is from POSIX.1-2001) describes a set of behaviors and interfaces for a compliant system. However, many interfaces are optional and there are feature test macros to test the availability of interfaces at compile time, and functions sysconf(3), fpathconf(3), pathconf(3), confstr(3) to do this at run time. From shell scripts one can use getconf(1). For more detail, see sysconf(3).

We give the name of the POSIX abbreviation, the option, the name of the sysconf(3) parameter used to inquire about the option, and possibly a very short description. Much more precise detail can be found in the POSIX standard itself, versions of which can nowadays be accessed freely on the web.

ADV - _POSIX_ADVISORY_INFO - _SC_ADVISORY_INFO

The following advisory functions are present:

posix_fadvise()
posix_fallocate()
posix_memalign()
posix_madvise()

AIO - _POSIX_ASYNCHRONOUS_IO - _SC_ASYNCHRONOUS_IO

The header <aio.h> is present. The following functions are present:

aio_cancel()
aio_error()
aio_fsync()
aio_read()
aio_return()
aio_suspend()
aio_write()
lio_listio()

BAR - _POSIX_BARRIERS - _SC_BARRIERS

This option implies the _POSIX_THREADS and _POSIX_THREAD_SAFE_FUNCTIONS options. The following functions are present:

pthread_barrier_destroy()
pthread_barrier_init()
pthread_barrier_wait()
pthread_barrierattr_destroy()
pthread_barrierattr_init()

— - POSIX_CHOWN_RESTRICTED

If this option is in effect (as it always is under POSIX.1-2001), then only root may change the owner of a file, and nonroot can set the group of a file only to one of the groups it belongs to. This affects the following functions:

chown()
fchown()

CS - _POSIX_CLOCK_SELECTION - _SC_CLOCK_SELECTION

This option implies the _POSIX_TIMERS option. The following functions are present:

pthread_condattr_getclock()
pthread_condattr_setclock()
clock_nanosleep()

If CLOCK_REALTIME is changed by the function clock_settime(), then this affects all timers set for an absolute time.

CPT - _POSIX_CPUTIME - _SC_CPUTIME

The CLOCK_PROCESS_CPUTIME_ID clock ID is supported. The initial value of this clock is 0 for each process. This option implies the _POSIX_TIMERS option. The function clock_getcpuclockid() is present.

— - _POSIX_FILE_LOCKING - _SC_FILE_LOCKING

This option has been deleted. Not in final XPG6.

FSC - _POSIX_FSYNC - _SC_FSYNC

The function fsync() is present.

IP6 - _POSIX_IPV6 - _SC_IPV6

Internet Protocol Version 6 is supported.

— - _POSIX_JOB_CONTROL - _SC_JOB_CONTROL

If this option is in effect (as it always is under POSIX.1-2001), then the system implements POSIX-style job control, and the following functions are present:

setpgid()
tcdrain()
tcflush()
tcgetpgrp()
tcsendbreak()
tcsetattr()
tcsetpgrp()

MF - _POSIX_MAPPED_FILES - _SC_MAPPED_FILES

Shared memory is supported. The include file <sys/mman.h> is present. The following functions are present:

mmap()
msync()
munmap()

ML - _POSIX_MEMLOCK - _SC_MEMLOCK

Shared memory can be locked into core. The following functions are present:

mlockall()
munlockall()

MR/MLR - _POSIX_MEMLOCK_RANGE - _SC_MEMLOCK_RANGE

More precisely, ranges can be locked into core. The following functions are present:

mlock()
munlock()

MPR - _POSIX_MEMORY_PROTECTION - _SC_MEMORY_PROTECTION

The function mprotect() is present.

MSG - _POSIX_MESSAGE_PASSING - _SC_MESSAGE_PASSING

The include file <mqueue.h> is present. The following functions are present:

mq_close()
mq_getattr()
mq_notify()
mq_open()
mq_receive()
mq_send()
mq_setattr()
mq_unlink()

MON - _POSIX_MONOTONIC_CLOCK - _SC_MONOTONIC_CLOCK

CLOCK_MONOTONIC is supported. This option implies the _POSIX_TIMERS option. The following functions are affected:

aio_suspend()
clock_getres()
clock_gettime()
clock_settime()
timer_create()

— - _POSIX_MULTI_PROCESS - _SC_MULTI_PROCESS

This option has been deleted. Not in final XPG6.

— - _POSIX_NO_TRUNC

If this option is in effect (as it always is under POSIX.1-2001), then pathname components longer than NAME_MAX are not truncated, but give an error. This property may be dependent on the path prefix of the component.

PIO - _POSIX_PRIORITIZED_IO - _SC_PRIORITIZED_IO

This option says that one can specify priorities for asynchronous I/O. This affects the functions

aio_read()
aio_write()

PS - _POSIX_PRIORITY_SCHEDULING - _SC_PRIORITY_SCHEDULING

The include file <sched.h> is present. The following functions are present:

sched_get_priority_max()
sched_get_priority_min()
sched_getparam()
sched_getscheduler()
sched_rr_get_interval()
sched_setparam()
sched_setscheduler()
sched_yield()

If also _POSIX_SPAWN is in effect, then the following functions are present:

posix_spawnattr_getschedparam()
posix_spawnattr_getschedpolicy()
posix_spawnattr_setschedparam()
posix_spawnattr_setschedpolicy()

RS - _POSIX_RAW_SOCKETS

Raw sockets are supported. The following functions are affected:

getsockopt()
setsockopt()

— - _POSIX_READER_WRITER_LOCKS - _SC_READER_WRITER_LOCKS

This option implies the _POSIX_THREADS option. Conversely, under POSIX.1-2001 the _POSIX_THREADS option implies this option.

The following functions are present:

pthread_rwlock_destroy()
pthread_rwlock_init()
pthread_rwlock_rdlock()
pthread_rwlock_tryrdlock()
pthread_rwlock_trywrlock()
pthread_rwlock_unlock()
pthread_rwlock_wrlock()
pthread_rwlockattr_destroy()
pthread_rwlockattr_init()

RTS - _POSIX_REALTIME_SIGNALS - _SC_REALTIME_SIGNALS

Realtime signals are supported. The following functions are present:

sigqueue()
sigtimedwait()
sigwaitinfo()

— - _POSIX_REGEXP - _SC_REGEXP

If this option is in effect (as it always is under POSIX.1-2001), then POSIX regular expressions are supported and the following functions are present:

regcomp()
regerror()
regexec()
regfree()

— - _POSIX_SAVED_IDS - _SC_SAVED_IDS

If this option is in effect (as it always is under POSIX.1-2001), then a process has a saved set-user-ID and a saved set-group-ID. The following functions are affected:

exec()
kill()
seteuid()
setegid()
setgid()
setuid()

SEM - _POSIX_SEMAPHORES - _SC_SEMAPHORES

The include file <semaphore.h> is present. The following functions are present:

sem_close()
sem_destroy()
sem_getvalue()
sem_init()
sem_open()
sem_post()
sem_trywait()
sem_unlink()
sem_wait()

SHM - _POSIX_SHARED_MEMORY_OBJECTS - _SC_SHARED_MEMORY_OBJECTS

The following functions are present:

mmap()
munmap()
shm_open()
shm_unlink()

— - _POSIX_SHELL - _SC_SHELL

If this option is in effect (as it always is under POSIX.1-2001), the function system() is present.

SPN - _POSIX_SPAWN - _SC_SPAWN

This option describes support for process creation in a context where it is difficult or impossible to use fork(), for example, because no MMU is present.

If _POSIX_SPAWN is in effect, then the include file <spawn.h> and the following functions are present:

posix_spawn()
posix_spawn_file_actions_addclose()
posix_spawn_file_actions_adddup2()
posix_spawn_file_actions_addopen()
posix_spawn_file_actions_destroy()
posix_spawn_file_actions_init()
posix_spawnattr_destroy()
posix_spawnattr_getsigdefault()
posix_spawnattr_getflags()
posix_spawnattr_getpgroup()
posix_spawnattr_getsigmask()
posix_spawnattr_init()
posix_spawnattr_setsigdefault()
posix_spawnattr_setflags()
posix_spawnattr_setpgroup()
posix_spawnattr_setsigmask()
posix_spawnp()

If also _POSIX_PRIORITY_SCHEDULING is in effect, then the following functions are present:

posix_spawnattr_getschedparam()
posix_spawnattr_getschedpolicy()
posix_spawnattr_setschedparam()
posix_spawnattr_setschedpolicy()

SPI - _POSIX_SPIN_LOCKS - _SC_SPIN_LOCKS

This option implies the _POSIX_THREADS and _POSIX_THREAD_SAFE_FUNCTIONS options. The following functions are present:

pthread_spin_destroy()
pthread_spin_init()
pthread_spin_lock()
pthread_spin_trylock()
pthread_spin_unlock()

SS - _POSIX_SPORADIC_SERVER - _SC_SPORADIC_SERVER

The scheduling policy SCHED_SPORADIC is supported. This option implies the _POSIX_PRIORITY_SCHEDULING option. The following functions are affected:

sched_setparam()
sched_setscheduler()

SIO - _POSIX_SYNCHRONIZED_IO - _SC_SYNCHRONIZED_IO

The following functions are affected:

open()
msync()
fsync()
fdatasync()

TSA - _POSIX_THREAD_ATTR_STACKADDR - _SC_THREAD_ATTR_STACKADDR

The following functions are affected:

pthread_attr_getstack()
pthread_attr_getstackaddr()
pthread_attr_setstack()
pthread_attr_setstackaddr()

TSS - _POSIX_THREAD_ATTR_STACKSIZE - _SC_THREAD_ATTR_STACKSIZE

The following functions are affected:

pthread_attr_getstack()
pthread_attr_getstacksize()
pthread_attr_setstack()
pthread_attr_setstacksize()

TCT - _POSIX_THREAD_CPUTIME - _SC_THREAD_CPUTIME

The clockID CLOCK_THREAD_CPUTIME_ID is supported. This option implies the _POSIX_TIMERS option. The following functions are affected:

pthread_getcpuclockid()
clock_getres()
clock_gettime()
clock_settime()
timer_create()

TPI - _POSIX_THREAD_PRIO_INHERIT - _SC_THREAD_PRIO_INHERIT

The following functions are affected:

pthread_mutexattr_getprotocol()
pthread_mutexattr_setprotocol()

TPP - _POSIX_THREAD_PRIO_PROTECT - _SC_THREAD_PRIO_PROTECT

The following functions are affected:

pthread_mutex_getprioceiling()
pthread_mutex_setprioceiling()
pthread_mutexattr_getprioceiling()
pthread_mutexattr_getprotocol()
pthread_mutexattr_setprioceiling()
pthread_mutexattr_setprotocol()

TPS - _POSIX_THREAD_PRIORITY_SCHEDULING - _SC_THREAD_PRIORITY_SCHEDULING

If this option is in effect, the different threads inside a process can run with different priorities and/or different schedulers. The following functions are affected:

pthread_attr_getinheritsched()
pthread_attr_getschedpolicy()
pthread_attr_getscope()
pthread_attr_setinheritsched()
pthread_attr_setschedpolicy()
pthread_attr_setscope()
pthread_getschedparam()
pthread_setschedparam()
pthread_setschedprio()

TSH - _POSIX_THREAD_PROCESS_SHARED - _SC_THREAD_PROCESS_SHARED

The following functions are affected:

pthread_barrierattr_getpshared()
pthread_barrierattr_setpshared()
pthread_condattr_getpshared()
pthread_condattr_setpshared()
pthread_mutexattr_getpshared()
pthread_mutexattr_setpshared()
pthread_rwlockattr_getpshared()
pthread_rwlockattr_setpshared()

TSF - _POSIX_THREAD_SAFE_FUNCTIONS - _SC_THREAD_SAFE_FUNCTIONS

The following functions are affected:

readdir_r()
getgrgid_r()
getgrnam_r()
getpwnam_r()
getpwuid_r()
flockfile()
ftrylockfile()
funlockfile()
getc_unlocked()
getchar_unlocked()
putc_unlocked()
putchar_unlocked()
rand_r()
strerror_r()
strtok_r()
asctime_r()
ctime_r()
gmtime_r()
localtime_r()

TSP - _POSIX_THREAD_SPORADIC_SERVER - _SC_THREAD_SPORADIC_SERVER

This option implies the _POSIX_THREAD_PRIORITY_SCHEDULING option. The following functions are affected:

sched_getparam()
sched_setparam()
sched_setscheduler()

THR - _POSIX_THREADS - _SC_THREADS

Basic support for POSIX threads is available. The following functions are present:

pthread_atfork()
pthread_attr_destroy()
pthread_attr_getdetachstate()
pthread_attr_getschedparam()
pthread_attr_init()
pthread_attr_setdetachstate()
pthread_attr_setschedparam()
pthread_cancel()
pthread_cleanup_push()
pthread_cleanup_pop()
pthread_cond_broadcast()
pthread_cond_destroy()
pthread_cond_init()
pthread_cond_signal()
pthread_cond_timedwait()
pthread_cond_wait()
pthread_condattr_destroy()
pthread_condattr_init()
pthread_create()
pthread_detach()
pthread_equal()
pthread_exit()
pthread_getspecific()
pthread_join()
pthread_key_create()
pthread_key_delete()
pthread_mutex_destroy()
pthread_mutex_init()
pthread_mutex_lock()
pthread_mutex_trylock()
pthread_mutex_unlock()
pthread_mutexattr_destroy()
pthread_mutexattr_init()
pthread_once()
pthread_rwlock_destroy()
pthread_rwlock_init()
pthread_rwlock_rdlock()
pthread_rwlock_tryrdlock()
pthread_rwlock_trywrlock()
pthread_rwlock_unlock()
pthread_rwlock_wrlock()
pthread_rwlockattr_destroy()
pthread_rwlockattr_init()
pthread_self()
pthread_setcancelstate()
pthread_setcanceltype()
pthread_setspecific()
pthread_testcancel()

TMO - _POSIX_TIMEOUTS - _SC_TIMEOUTS

The following functions are present:

mq_timedreceive()
mq_timedsend()
pthread_mutex_timedlock()
pthread_rwlock_timedrdlock()
pthread_rwlock_timedwrlock()
sem_timedwait()
posix_trace_timedgetnext_event()

TMR - _POSIX_TIMERS - _SC_TIMERS

The following functions are present:

clock_getres()
clock_gettime()
clock_settime()
nanosleep()
timer_create()
timer_delete()
timer_gettime()
timer_getoverrun()
timer_settime()

TRC - _POSIX_TRACE - _SC_TRACE

POSIX tracing is available. The following functions are present:

posix_trace_attr_destroy()
posix_trace_attr_getclockres()
posix_trace_attr_getcreatetime()
posix_trace_attr_getgenversion()
posix_trace_attr_getmaxdatasize()
posix_trace_attr_getmaxsystemeventsize()
posix_trace_attr_getmaxusereventsize()
posix_trace_attr_getname()
posix_trace_attr_getstreamfullpolicy()
posix_trace_attr_getstreamsize()
posix_trace_attr_init()
posix_trace_attr_setmaxdatasize()
posix_trace_attr_setname()
posix_trace_attr_setstreamsize()
posix_trace_attr_setstreamfullpolicy()
posix_trace_clear()
posix_trace_create()
posix_trace_event()
posix_trace_eventid_equal()
posix_trace_eventid_get_name()
posix_trace_eventid_open()
posix_trace_eventtypelist_getnext_id()
posix_trace_eventtypelist_rewind()
posix_trace_flush()
posix_trace_get_attr()
posix_trace_get_status()
posix_trace_getnext_event()
posix_trace_shutdown()
posix_trace_start()
posix_trace_stop()
posix_trace_trygetnext_event()

TEF - _POSIX_TRACE_EVENT_FILTER - _SC_TRACE_EVENT_FILTER

This option implies the _POSIX_TRACE option. The following functions are present:

posix_trace_eventset_add()
posix_trace_eventset_del()
posix_trace_eventset_empty()
posix_trace_eventset_fill()
posix_trace_eventset_ismember()
posix_trace_get_filter()
posix_trace_set_filter()
posix_trace_trid_eventid_open()

TRI - _POSIX_TRACE_INHERIT - _SC_TRACE_INHERIT

Tracing children of the traced process is supported. This option implies the _POSIX_TRACE option. The following functions are present:

posix_trace_attr_getinherited()
posix_trace_attr_setinherited()

TRL - _POSIX_TRACE_LOG - _SC_TRACE_LOG

This option implies the _POSIX_TRACE option. The following functions are present:

posix_trace_attr_getlogfullpolicy()
posix_trace_attr_getlogsize()
posix_trace_attr_setlogfullpolicy()
posix_trace_attr_setlogsize()
posix_trace_close()
posix_trace_create_withlog()
posix_trace_open()
posix_trace_rewind()

TYM - _POSIX_TYPED_MEMORY_OBJECTS - _SC_TYPED_MEMORY_OBJECT

The following functions are present:

posix_mem_offset()
posix_typed_mem_get_info()
posix_typed_mem_open()

— - _POSIX_VDISABLE

Always present (probably 0). Value to set a changeable special control character to indicate that it is disabled.

X/OPEN SYSTEM INTERFACE EXTENSIONS

XSI - _XOPEN_CRYPT - _SC_XOPEN_CRYPT

The following functions are present:

crypt()
encrypt()
setkey()

XSI - _XOPEN_REALTIME - _SC_XOPEN_REALTIME

This option implies the following options:

_POSIX_ASYNCHRONOUS_IO==200112L
_POSIX_FSYNC
_POSIX_MAPPED_FILES
_POSIX_MEMLOCK==200112L
_POSIX_MEMLOCK_RANGE==200112L
_POSIX_MEMORY_PROTECTION
_POSIX_MESSAGE_PASSING==200112L
_POSIX_PRIORITIZED_IO
_POSIX_PRIORITY_SCHEDULING==200112L
_POSIX_REALTIME_SIGNALS==200112L
_POSIX_SEMAPHORES==200112L
_POSIX_SHARED_MEMORY_OBJECTS==200112L
_POSIX_SYNCHRONIZED_IO==200112L
_POSIX_TIMERS==200112L

ADV - — - —

The Advanced Realtime option group implies that the following options are all defined to 200112L:

_POSIX_ADVISORY_INFO
_POSIX_CLOCK_SELECTION
(implies _POSIX_TIMERS)

_POSIX_CPUTIME
(implies _POSIX_TIMERS)

_POSIX_MONOTONIC_CLOCK
(implies _POSIX_TIMERS)

_POSIX_SPAWN
_POSIX_SPORADIC_SERVER
(implies _POSIX_PRIORITY_SCHEDULING)

_POSIX_TIMEOUTS
_POSIX_TYPED_MEMORY_OBJECTS

XSI - _XOPEN_REALTIME_THREADS - _SC_XOPEN_REALTIME_THREADS

This option implies that the following options are all defined to 200112L:

_POSIX_THREAD_PRIO_INHERIT
_POSIX_THREAD_PRIO_PROTECT
_POSIX_THREAD_PRIORITY_SCHEDULING

ADVANCED REALTIME THREADS - — - —

This option implies that the following options are all defined to 200112L:

_POSIX_BARRIERS
(implies _POSIX_THREADS, _POSIX_THREAD_SAFE_FUNCTIONS)

_POSIX_SPIN_LOCKS
(implies _POSIX_THREADS, _POSIX_THREAD_SAFE_FUNCTIONS)

_POSIX_THREAD_CPUTIME
(implies _POSIX_TIMERS)

_POSIX_THREAD_SPORADIC_SERVER
(implies _POSIX_THREAD_PRIORITY_SCHEDULING)

TRACING - — - —

This option implies that the following options are all defined to 200112L:

_POSIX_TRACE
_POSIX_TRACE_EVENT_FILTER
_POSIX_TRACE_LOG
_POSIX_TRACE_INHERIT

STREAMS - _XOPEN_STREAMS - _SC_XOPEN_STREAMS

The following functions are present:

fattach()
fdetach()
getmsg()
getpmsg()
ioctl()
isastream()
putmsg()
putpmsg()

XSI - _XOPEN_LEGACY - _SC_XOPEN_LEGACY

Functions included in the legacy option group were previously mandatory, but are now optional in this version. The following functions are present:

bcmp()
bcopy()
bzero()
ecvt()
fcvt()
ftime()
gcvt()
getwd()
index()
mktemp()
rindex()
utimes()
wcswcs()

XSI - _XOPEN_UNIX - _SC_XOPEN_UNIX

The following functions are present:

mmap()
munmap()
msync()

This option implies the following options:

_POSIX_FSYNC
_POSIX_MAPPED_FILES
_POSIX_MEMORY_PROTECTION
_POSIX_THREAD_ATTR_STACKADDR
_POSIX_THREAD_ATTR_STACKSIZE
_POSIX_THREAD_PROCESS_SHARED
_POSIX_THREAD_SAFE_FUNCTIONS
_POSIX_THREADS

This option may imply the following options from the XSI option groups:

Encryption (_XOPEN_CRYPT)
Realtime (_XOPEN_REALTIME)
Advanced Realtime (ADB)
Realtime Threads (_XOPEN_REALTIME_THREADS)
Advanced Realtime Threads (ADVANCED REALTIME THREADS)
Tracing (TRACING)
XSI Streams (STREAMS)
Legacy (_XOPEN_LEGACY)

SEE ALSO

sysconf(3), standards(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

523 - Linux cli command iso-8859-8

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso-8859-8 and provides detailed information about the command iso-8859-8, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso-8859-8.

NAME 🖥️ iso-8859-8 🖥️

8 - ISO/IEC 8859-8 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-8 encodes the characters used in Modern Hebrew.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-8 characters

The following table displays the characters in ISO/IEC 8859-8 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-8 was also known as ISO-IR-138. ISO/IEC 8859-8 includes neither short vowels nor diacritical marks, and Yiddish is not provided for.

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

524 - Linux cli command re_format

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command re_format and provides detailed information about the command re_format, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the re_format.

NAME 🖥️ re_format 🖥️

POSIX.2 regular expressions

DESCRIPTION

Regular expressions (“RE"s), as defined in POSIX.2, come in two forms: modern REs (roughly those of egrep(1); POSIX.2 calls these “extended” REs) and obsolete REs (roughly those of ed(1); POSIX.2 “basic” REs). Obsolete REs mostly exist for backward compatibility in some old programs; they will be discussed at the end. POSIX.2 leaves some aspects of RE syntax and semantics open; “(!)” marks decisions on these aspects that may not be fully portable to other POSIX.2 implementations.

A (modern) RE is one(!) or more nonempty(!) branches, separated by ‘|’. It matches anything that matches one of the branches.

A branch is one(!) or more pieces, concatenated. It matches a match for the first, followed by a match for the second, and so on.

A piece is an atom possibly followed by a single(!) ‘*’, ‘+’, ‘?’, or bound. An atom followed by ‘*’ matches a sequence of 0 or more matches of the atom. An atom followed by ‘+’ matches a sequence of 1 or more matches of the atom. An atom followed by ‘?’ matches a sequence of 0 or 1 matches of the atom.

A bound is ‘{’ followed by an unsigned decimal integer, possibly followed by ‘,’ possibly followed by another unsigned decimal integer, always followed by ‘}’. The integers must lie between 0 and RE_DUP_MAX (255(!)) inclusive, and if there are two of them, the first may not exceed the second. An atom followed by a bound containing one integer i and no comma matches a sequence of exactly i matches of the atom. An atom followed by a bound containing one integer i and a comma matches a sequence of i or more matches of the atom. An atom followed by a bound containing two integers i and j matches a sequence of i through j (inclusive) matches of the atom.

An atom is a regular expression enclosed in “()” (matching a match for the regular expression), an empty set of “()” (matching the null string)(!), a bracket expression (see below), ‘.’ (matching any single character), ‘^’ (matching the null string at the beginning of a line), ‘$’ (matching the null string at the end of a line), a ‘\ followed by one of the characters “*^.[$()|*+?{*” (matching that character taken as an ordinary character), a ‘\ followed by any other character(!) (matching that character taken as an ordinary character, as if the ‘\ had not been present(!)), or a single character with no other significance (matching that character). A ‘{’ followed by a character other than a digit is an ordinary character, not the beginning of a bound(!). It is illegal to end an RE with ‘.

A bracket expression is a list of characters enclosed in “[]”. It normally matches any single character from the list (but see below). If the list begins with ‘^’, it matches any single character (but see below) not from the rest of the list. If two characters in the list are separated by ‘-’, this is shorthand for the full range of characters between those two (inclusive) in the collating sequence, for example, “[0-9]” in ASCII matches any decimal digit. It is illegal(!) for two ranges to share an endpoint, for example, “a-c-e”. Ranges are very collating-sequence-dependent, and portable programs should avoid relying on them.

To include a literal ‘]’ in the list, make it the first character (following a possible ‘^’). To include a literal ‘-’, make it the first or last character, or the second endpoint of a range. To use a literal ‘-’ as the first endpoint of a range, enclose it in “[.” and “.]” to make it a collating element (see below). With the exception of these and some combinations using ‘[’ (see next paragraphs), all other special characters, including ‘, lose their special significance within a bracket expression.

Within a bracket expression, a collating element (a character, a multicharacter sequence that collates as if it were a single character, or a collating-sequence name for either) enclosed in “[.” and “.]” stands for the sequence of characters of that collating element. The sequence is a single element of the bracket expression’s list. A bracket expression containing a multicharacter collating element can thus match more than one character, for example, if the collating sequence includes a “ch” collating element, then the RE “[[.ch.]]*c” matches the first five characters of “chchcc”.

Within a bracket expression, a collating element enclosed in “[=” and “=]” is an equivalence class, standing for the sequences of characters of all collating elements equivalent to that one, including itself. (If there are no other equivalent collating elements, the treatment is as if the enclosing delimiters were “[.” and “.]”.) For example, if o and ô are the members of an equivalence class, then “[[=o=]]”, “[[=ô=]]”, and “[oô]” are all synonymous. An equivalence class may not(!) be an endpoint of a range.

Within a bracket expression, the name of a character class enclosed in “[:” and “:]” stands for the list of all characters belonging to that class. Standard character class names are:

alnumdigitpunct
alphagraphspace
blanklowerupper
cntrlprintxdigit

These stand for the character classes defined in wctype(3). A locale may provide others. A character class may not be used as an endpoint of a range.

In the event that an RE could match more than one substring of a given string, the RE matches the one starting earliest in the string. If the RE could match more than one substring starting at that point, it matches the longest. Subexpressions also match the longest possible substrings, subject to the constraint that the whole match be as long as possible, with subexpressions starting earlier in the RE taking priority over ones starting later. Note that higher-level subexpressions thus take priority over their lower-level component subexpressions.

Match lengths are measured in characters, not collating elements. A null string is considered longer than no match at all. For example, “bb*” matches the three middle characters of “abbbc”, “(wee|week)(knights|nights)” matches all ten characters of “weeknights”, when “(.*).*” is matched against “abc” the parenthesized subexpression matches all three characters, and when “(a*)*” is matched against “bc” both the whole RE and the parenthesized subexpression match the null string.

If case-independent matching is specified, the effect is much as if all case distinctions had vanished from the alphabet. When an alphabetic that exists in multiple cases appears as an ordinary character outside a bracket expression, it is effectively transformed into a bracket expression containing both cases, for example, ‘x’ becomes “[xX]”. When it appears inside a bracket expression, all case counterparts of it are added to the bracket expression, so that, for example, “[x]” becomes “[xX]” and “[^x]” becomes “[^xX]”.

No particular limit is imposed on the length of REs(!). Programs intended to be portable should not employ REs longer than 256 bytes, as an implementation can refuse to accept such REs and remain POSIX-compliant.

Obsolete (“basic”) regular expressions differ in several respects. ‘|’, ‘+’, and ‘?’ are ordinary characters and there is no equivalent for their functionality. The delimiters for bounds are “*” and “*”, with ‘{’ and ‘}’ by themselves ordinary characters. The parentheses for nested subexpressions are “*” and “*”, with ‘(’ and ‘)’ by themselves ordinary characters. ‘^’ is an ordinary character except at the beginning of the RE or(!) the beginning of a parenthesized subexpression, ‘$’ is an ordinary character except at the end of the RE or(!) the end of a parenthesized subexpression, and ‘*’ is an ordinary character if it appears at the beginning of the RE or the beginning of a parenthesized subexpression (after a possible leading ‘^’).

Finally, there is one new type of atom, a back reference: ‘\ followed by a nonzero decimal digit d matches the same sequence of characters matched by the dth parenthesized subexpression (numbering subexpressions by the positions of their opening parentheses, left to right), so that, for example, “\[bc]\1” matches “bb” or “cc” but not “bc”.

BUGS

Having two kinds of REs is a botch.

The current POSIX.2 spec says that ‘)’ is an ordinary character in the absence of an unmatched ‘(’; this was an unintentional result of a wording error, and change is likely. Avoid relying on it.

Back references are a dreadful botch, posing major problems for efficient implementations. They are also somewhat vaguely defined (does “a\b\\2\d” match “abbbd”?). Avoid using them.

POSIX.2’s specification of case-independent matching is vague. The “one case implies all cases” definition given above is current consensus among implementors as to the right interpretation.

AUTHOR

This page was taken from Henry Spencer’s regex package.

SEE ALSO

grep(1), regex(3)

POSIX.2, section 2.8 (Regular Expression Notation).

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

525 - Linux cli command DECLARE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DECLARE and provides detailed information about the command DECLARE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DECLARE.

NAME 🖥️ DECLARE 🖥️

define a cursor

SYNOPSIS

DECLARE name [ BINARY ] [ ASENSITIVE | INSENSITIVE ] [ [ NO ] SCROLL ]
    CURSOR [ { WITH | WITHOUT } HOLD ] FOR query

DESCRIPTION

DECLARE allows a user to create cursors, which can be used to retrieve a small number of rows at a time out of a larger query. After the cursor is created, rows are fetched from it using FETCH.

Note

This page describes usage of cursors at the SQL command level. If you are trying to use cursors inside a PL/pgSQL function, the rules are different — see Section 43.7.

PARAMETERS

name

The name of the cursor to be created. This must be different from any other active cursor name in the session.

BINARY

Causes the cursor to return data in binary rather than in text format.

ASENSITIVE
INSENSITIVE

Cursor sensitivity determines whether changes to the data underlying the cursor, done in the same transaction, after the cursor has been declared, are visible in the cursor. INSENSITIVE means they are not visible, ASENSITIVE means the behavior is implementation-dependent. A third behavior, SENSITIVE, meaning that such changes are visible in the cursor, is not available in PostgreSQL. In PostgreSQL, all cursors are insensitive; so these key words have no effect and are only accepted for compatibility with the SQL standard.

Specifying INSENSITIVE together with FOR UPDATE or FOR SHARE is an error.

SCROLL
NO SCROLL

SCROLL specifies that the cursor can be used to retrieve rows in a nonsequential fashion (e.g., backward). Depending upon the complexity of the querys execution plan, specifying SCROLL might impose a performance penalty on the querys execution time. NO SCROLL specifies that the cursor cannot be used to retrieve rows in a nonsequential fashion. The default is to allow scrolling in some cases; this is not the same as specifying SCROLL. See Notes below for details.

WITH HOLD
WITHOUT HOLD

WITH HOLD specifies that the cursor can continue to be used after the transaction that created it successfully commits. WITHOUT HOLD specifies that the cursor cannot be used outside of the transaction that created it. If neither WITHOUT HOLD nor WITH HOLD is specified, WITHOUT HOLD is the default.

query

A SELECT or VALUES command which will provide the rows to be returned by the cursor.

The key words ASENSITIVE, BINARY, INSENSITIVE, and SCROLL can appear in any order.

NOTES

Normal cursors return data in text format, the same as a SELECT would produce. The BINARY option specifies that the cursor should return data in binary format. This reduces conversion effort for both the server and client, at the cost of more programmer effort to deal with platform-dependent binary data formats. As an example, if a query returns a value of one from an integer column, you would get a string of 1 with a default cursor, whereas with a binary cursor you would get a 4-byte field containing the internal representation of the value (in big-endian byte order).

Binary cursors should be used carefully. Many applications, including psql, are not prepared to handle binary cursors and expect data to come back in the text format.

Note

When the client application uses the “extended query” protocol to issue a FETCH command, the Bind protocol message specifies whether data is to be retrieved in text or binary format. This choice overrides the way that the cursor is defined. The concept of a binary cursor as such is thus obsolete when using extended query protocol — any cursor can be treated as either text or binary.

Unless WITH HOLD is specified, the cursor created by this command can only be used within the current transaction. Thus, DECLARE without WITH HOLD is useless outside a transaction block: the cursor would survive only to the completion of the statement. Therefore PostgreSQL reports an error if such a command is used outside a transaction block. Use BEGIN and COMMIT (or ROLLBACK) to define a transaction block.

If WITH HOLD is specified and the transaction that created the cursor successfully commits, the cursor can continue to be accessed by subsequent transactions in the same session. (But if the creating transaction is aborted, the cursor is removed.) A cursor created with WITH HOLD is closed when an explicit CLOSE command is issued on it, or the session ends. In the current implementation, the rows represented by a held cursor are copied into a temporary file or memory area so that they remain available for subsequent transactions.

WITH HOLD may not be specified when the query includes FOR UPDATE or FOR SHARE.

The SCROLL option should be specified when defining a cursor that will be used to fetch backwards. This is required by the SQL standard. However, for compatibility with earlier versions, PostgreSQL will allow backward fetches without SCROLL, if the cursors query plan is simple enough that no extra overhead is needed to support it. However, application developers are advised not to rely on using backward fetches from a cursor that has not been created with SCROLL. If NO SCROLL is specified, then backward fetches are disallowed in any case.

Backward fetches are also disallowed when the query includes FOR UPDATE or FOR SHARE; therefore SCROLL may not be specified in this case.

Caution

Scrollable cursors may give unexpected results if they invoke any volatile functions (see Section 38.7). When a previously fetched row is re-fetched, the functions might be re-executed, perhaps leading to results different from the first time. Its best to specify NO SCROLL for a query involving volatile functions. If that is not practical, one workaround is to declare the cursor SCROLL WITH HOLD and commit the transaction before reading any rows from it. This will force the entire output of the cursor to be materialized in temporary storage, so that volatile functions are executed exactly once for each row.

If the cursors query includes FOR UPDATE or FOR SHARE, then returned rows are locked at the time they are first fetched, in the same way as for a regular SELECT command with these options. In addition, the returned rows will be the most up-to-date versions.

Caution

It is generally recommended to use FOR UPDATE if the cursor is intended to be used with UPDATE … WHERE CURRENT OF or DELETE … WHERE CURRENT OF. Using FOR UPDATE prevents other sessions from changing the rows between the time they are fetched and the time they are updated. Without FOR UPDATE, a subsequent WHERE CURRENT OF command will have no effect if the row was changed since the cursor was created.

Another reason to use FOR UPDATE is that without it, a subsequent WHERE CURRENT OF might fail if the cursor query does not meet the SQL standards rules for being “simply updatable” (in particular, the cursor must reference just one table and not use grouping or ORDER BY). Cursors that are not simply updatable might work, or might not, depending on plan choice details; so in the worst case, an application might work in testing and then fail in production. If FOR UPDATE is specified, the cursor is guaranteed to be updatable.

The main reason not to use FOR UPDATE with WHERE CURRENT OF is if you need the cursor to be scrollable, or to be isolated from concurrent updates (that is, continue to show the old data). If this is a requirement, pay close heed to the caveats shown above.

The SQL standard only makes provisions for cursors in embedded SQL. The PostgreSQL server does not implement an OPEN statement for cursors; a cursor is considered to be open when it is declared. However, ECPG, the embedded SQL preprocessor for PostgreSQL, supports the standard SQL cursor conventions, including those involving DECLARE and OPEN statements.

The server data structure underlying an open cursor is called a portal. Portal names are exposed in the client protocol: a client can fetch rows directly from an open portal, if it knows the portal name. When creating a cursor with DECLARE, the portal name is the same as the cursor name.

You can see all available cursors by querying the pg_cursors system view.

EXAMPLES

To declare a cursor:

DECLARE liahona CURSOR FOR SELECT * FROM films;

See FETCH(7) for more examples of cursor usage.

COMPATIBILITY

The SQL standard allows cursors only in embedded SQL and in modules. PostgreSQL permits cursors to be used interactively.

According to the SQL standard, changes made to insensitive cursors by UPDATE … WHERE CURRENT OF and DELETE … WHERE CURRENT OF statements are visible in that same cursor. PostgreSQL treats these statements like all other data changing statements in that they are not visible in insensitive cursors.

Binary cursors are a PostgreSQL extension.

SEE ALSO

CLOSE(7), FETCH(7), MOVE(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

526 - Linux cli command EVP_SIGNATURE-RSAssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_SIGNATURE-RSAssl and provides detailed information about the command EVP_SIGNATURE-RSAssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_SIGNATURE-RSAssl.

NAME 🖥️ EVP_SIGNATURE-RSAssl 🖥️

RSA - The EVP_PKEY RSA signature implementation

DESCRIPTION

Support for computing RSA signatures. See EVP_PKEY-RSA (7) for information related to RSA keys.

Signature Parameters

The following signature parameters can be set using EVP_PKEY_CTX_set_params(). This may be called after EVP_PKEY_sign_init() or EVP_PKEY_verify_init(), and before calling EVP_PKEY_sign() or EVP_PKEY_verify().

“digest” (OSSL_SIGNATURE_PARAM_DIGEST) <UTF8 string>

“properties” (OSSL_SIGNATURE_PARAM_PROPERTIES) <UTF8 string>

These common parameters are described in provider-signature (7).

“pad-mode” (OSSL_SIGNATURE_PARAM_PAD_MODE) <UTF8 string>
The type of padding to be used. Its value can be one of the following:

“none” (OSSL_PKEY_RSA_PAD_MODE_NONE)

“pkcs1” (OSSL_PKEY_RSA_PAD_MODE_PKCSV15)

“x931” (OSSL_PKEY_RSA_PAD_MODE_X931)

“pss” (OSSL_PKEY_RSA_PAD_MODE_PSS)

“mgf1-digest” (OSSL_SIGNATURE_PARAM_MGF1_DIGEST) <UTF8 string>

The digest algorithm name to use for the maskGenAlgorithm used by “pss” mode.

“mgf1-properties” (OSSL_SIGNATURE_PARAM_MGF1_PROPERTIES) <UTF8 string>
Sets the name of the property query associated with the “mgf1-digest” algorithm. NULL is used if this optional value is not set.

“saltlen” (OSSL_SIGNATURE_PARAM_PSS_SALTLEN) <integer> or <UTF8 string>
The “pss” mode minimum salt length. The value can either be an integer, a string value representing a number or one of the following string values:

“digest” (OSSL_PKEY_RSA_PSS_SALT_LEN_DIGEST)
Use the same length as the digest size.

“max” (OSSL_PKEY_RSA_PSS_SALT_LEN_MAX)
Use the maximum salt length.

“auto” (OSSL_PKEY_RSA_PSS_SALT_LEN_AUTO)
Auto detect the salt length.

“auto-digestmax” (OSSL_PKEY_RSA_PSS_SALT_LEN_AUTO_DIGEST_MAX)
Auto detect the salt length when verifying. Maximize the salt length up to the digest size when signing to comply with FIPS 186-4 section 5.5.

The following signature parameters can be retrieved using EVP_PKEY_CTX_get_params().

“algorithm-id” (OSSL_SIGNATURE_PARAM_ALGORITHM_ID) <octet string>
This common parameter is described in provider-signature (7).

“digest” (OSSL_SIGNATURE_PARAM_DIGEST) <UTF8 string>

“pad-mode” (OSSL_SIGNATURE_PARAM_PAD_MODE) <UTF8 string>

“mgf1-digest” (OSSL_SIGNATURE_PARAM_MGF1_DIGEST) <UTF8 string>

“saltlen” (OSSL_SIGNATURE_PARAM_PSS_SALTLEN) <integer> or <UTF8 string>

These parameters are as described above.

SEE ALSO

EVP_PKEY_CTX_set_params (3), EVP_PKEY_sign (3), EVP_PKEY_verify (3), provider-signature (7),

COPYRIGHT

Copyright 2020-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

527 - Linux cli command EVP_MAC-GMACssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_MAC-GMACssl and provides detailed information about the command EVP_MAC-GMACssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_MAC-GMACssl.

NAME 🖥️ EVP_MAC-GMACssl 🖥️

GMAC - The GMAC EVP_MAC implementation

DESCRIPTION

Support for computing GMAC MACs through the EVP_MAC API.

This implementation uses EVP_CIPHER functions to get access to the underlying cipher.

Identity

This implementation is identified with this name and properties, to be used with EVP_MAC_fetch():

“GMAC”, “provider=default” or “provider=fips”

Supported parameters

The general description of these parameters can be found in “PARAMETERS” in EVP_MAC (3).

The following parameter can be set with EVP_MAC_CTX_set_params():

“key” (OSSL_MAC_PARAM_KEY) <octet string>
Sets the MAC key. Setting this parameter is identical to passing a key to EVP_MAC_init (3).

“iv” (OSSL_MAC_PARAM_IV) <octet string>
Sets the IV of the underlying cipher, when applicable.

“cipher” (OSSL_MAC_PARAM_CIPHER) <UTF8 string>
Sets the name of the underlying cipher to be used.

“properties” (OSSL_MAC_PARAM_PROPERTIES) <UTF8 string>
Sets the properties to be queried when trying to fetch the underlying cipher. This must be given together with the cipher naming parameter to be considered valid.

The following parameters can be retrieved with EVP_MAC_CTX_get_params():

“size” (OSSL_MAC_PARAM_SIZE) <unsigned integer>
Gets the MAC size.

The “size” parameter can also be retrieved with EVP_MAC_CTX_get_mac_size(). The length of the “size” parameter is equal to that of an unsigned int.

SEE ALSO

EVP_MAC_CTX_get_params (3), EVP_MAC_CTX_set_params (3), “PARAMETERS” in EVP_MAC (3), OSSL_PARAM (3)

COPYRIGHT

Copyright 2018-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

528 - Linux cli command ALTER_VIEW

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_VIEW and provides detailed information about the command ALTER_VIEW, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_VIEW.

NAME 🖥️ ALTER_VIEW 🖥️

change the definition of a view

SYNOPSIS

ALTER VIEW [ IF EXISTS ] name ALTER [ COLUMN ] column_name SET DEFAULT expression
ALTER VIEW [ IF EXISTS ] name ALTER [ COLUMN ] column_name DROP DEFAULT
ALTER VIEW [ IF EXISTS ] name OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }
ALTER VIEW [ IF EXISTS ] name RENAME [ COLUMN ] column_name TO new_column_name
ALTER VIEW [ IF EXISTS ] name RENAME TO new_name
ALTER VIEW [ IF EXISTS ] name SET SCHEMA new_schema
ALTER VIEW [ IF EXISTS ] name SET ( view_option_name [= view_option_value] [, ... ] )
ALTER VIEW [ IF EXISTS ] name RESET ( view_option_name [, ... ] )

DESCRIPTION

ALTER VIEW changes various auxiliary properties of a view. (If you want to modify the views defining query, use CREATE OR REPLACE VIEW.)

You must own the view to use ALTER VIEW. To change a views schema, you must also have CREATE privilege on the new schema. To alter the owner, you must be able to SET ROLE to the new owning role, and that role must have CREATE privilege on the views schema. (These restrictions enforce that altering the owner doesnt do anything you couldnt do by dropping and recreating the view. However, a superuser can alter ownership of any view anyway.)

PARAMETERS

name

The name (optionally schema-qualified) of an existing view.

column_name

Name of an existing column.

new_column_name

New name for an existing column.

IF EXISTS

Do not throw an error if the view does not exist. A notice is issued in this case.

SET/DROP DEFAULT

These forms set or remove the default value for a column. A view columns default value is substituted into any INSERT or UPDATE command whose target is the view, before applying any rules or triggers for the view. The views default will therefore take precedence over any default values from underlying relations.

new_owner

The user name of the new owner of the view.

new_name

The new name for the view.

new_schema

The new schema for the view.

SET ( view_option_name [= view_option_value] [, … ] )
RESET ( view_option_name [, … ] )

Sets or resets a view option. Currently supported options are:

check_option (enum)

Changes the check option of the view. The value must be local or cascaded.

security_barrier (boolean)

Changes the security-barrier property of the view. The value must be a Boolean value, such as true or false.

security_invoker (boolean)

Changes the security-invoker property of the view. The value must be a Boolean value, such as true or false.

NOTES

For historical reasons, ALTER TABLE can be used with views too; but the only variants of ALTER TABLE that are allowed with views are equivalent to the ones shown above.

EXAMPLES

To rename the view foo to bar:

ALTER VIEW foo RENAME TO bar;

To attach a default column value to an updatable view:

CREATE TABLE base_table (id int, ts timestamptz); CREATE VIEW a_view AS SELECT * FROM base_table; ALTER VIEW a_view ALTER COLUMN ts SET DEFAULT now(); INSERT INTO base_table(id) VALUES(1); – ts will receive a NULL INSERT INTO a_view(id) VALUES(2); – ts will receive the current time

COMPATIBILITY

ALTER VIEW is a PostgreSQL extension of the SQL standard.

SEE ALSO

CREATE VIEW (CREATE_VIEW(7)), DROP VIEW (DROP_VIEW(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

529 - Linux cli command CREATE_MATERIALIZED_VIEW

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_MATERIALIZED_VIEW and provides detailed information about the command CREATE_MATERIALIZED_VIEW, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_MATERIALIZED_VIEW.

NAME 🖥️ CREATE_MATERIALIZED_VIEW 🖥️

define a new materialized view

SYNOPSIS

CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] table_name
    [ (column_name [, ...] ) ]
    [ USING method ]
    [ WITH ( storage_parameter [= value] [, ... ] ) ]
    [ TABLESPACE tablespace_name ]
    AS query
    [ WITH [ NO ] DATA ]

DESCRIPTION

CREATE MATERIALIZED VIEW defines a materialized view of a query. The query is executed and used to populate the view at the time the command is issued (unless WITH NO DATA is used) and may be refreshed later using REFRESH MATERIALIZED VIEW.

CREATE MATERIALIZED VIEW is similar to CREATE TABLE AS, except that it also remembers the query used to initialize the view, so that it can be refreshed later upon demand. A materialized view has many of the same properties as a table, but there is no support for temporary materialized views.

CREATE MATERIALIZED VIEW requires CREATE privilege on the schema used for the materialized view.

PARAMETERS

IF NOT EXISTS

Do not throw an error if a materialized view with the same name already exists. A notice is issued in this case. Note that there is no guarantee that the existing materialized view is anything like the one that would have been created.

table_name

The name (optionally schema-qualified) of the materialized view to be created. The name must be distinct from the name of any other relation (table, sequence, index, view, materialized view, or foreign table) in the same schema.

column_name

The name of a column in the new materialized view. If column names are not provided, they are taken from the output column names of the query.

USING method

This optional clause specifies the table access method to use to store the contents for the new materialized view; the method needs be an access method of type TABLE. See Chapter 63 for more information. If this option is not specified, the default table access method is chosen for the new materialized view. See default_table_access_method for more information.

WITH ( storage_parameter [= value] [, … ] )

This clause specifies optional storage parameters for the new materialized view; see Storage Parameters in the CREATE TABLE (CREATE_TABLE(7)) documentation for more information. All parameters supported for CREATE TABLE are also supported for CREATE MATERIALIZED VIEW. See CREATE TABLE (CREATE_TABLE(7)) for more information.

TABLESPACE tablespace_name

The tablespace_name is the name of the tablespace in which the new materialized view is to be created. If not specified, default_tablespace is consulted.

query

A SELECT, TABLE, or VALUES command. This query will run within a security-restricted operation; in particular, calls to functions that themselves create temporary tables will fail.

WITH [ NO ] DATA

This clause specifies whether or not the materialized view should be populated at creation time. If not, the materialized view will be flagged as unscannable and cannot be queried until REFRESH MATERIALIZED VIEW is used.

COMPATIBILITY

CREATE MATERIALIZED VIEW is a PostgreSQL extension.

SEE ALSO

ALTER MATERIALIZED VIEW (ALTER_MATERIALIZED_VIEW(7)), CREATE TABLE AS (CREATE_TABLE_AS(7)), CREATE VIEW (CREATE_VIEW(7)), DROP MATERIALIZED VIEW (DROP_MATERIALIZED_VIEW(7)), REFRESH MATERIALIZED VIEW (REFRESH_MATERIALIZED_VIEW(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

530 - Linux cli command DELETE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DELETE and provides detailed information about the command DELETE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DELETE.

NAME 🖥️ DELETE 🖥️

delete rows of a table

SYNOPSIS

[ WITH [ RECURSIVE ] with_query [, ...] ]
DELETE FROM [ ONLY ] table_name [ * ] [ [ AS ] alias ]
    [ USING from_item [, ...] ]
    [ WHERE condition | WHERE CURRENT OF cursor_name ]
    [ RETURNING { * | output_expression [ [ AS ] output_name ] } [, ...] ]

DESCRIPTION

DELETE deletes rows that satisfy the WHERE clause from the specified table. If the WHERE clause is absent, the effect is to delete all rows in the table. The result is a valid, but empty table.

Tip

TRUNCATE provides a faster mechanism to remove all rows from a table.

There are two ways to delete rows in a table using information contained in other tables in the database: using sub-selects, or specifying additional tables in the USING clause. Which technique is more appropriate depends on the specific circumstances.

The optional RETURNING clause causes DELETE to compute and return value(s) based on each row actually deleted. Any expression using the tables columns, and/or columns of other tables mentioned in USING, can be computed. The syntax of the RETURNING list is identical to that of the output list of SELECT.

You must have the DELETE privilege on the table to delete from it, as well as the SELECT privilege for any table in the USING clause or whose values are read in the condition.

PARAMETERS

with_query

The WITH clause allows you to specify one or more subqueries that can be referenced by name in the DELETE query. See Section 7.8 and SELECT(7) for details.

table_name

The name (optionally schema-qualified) of the table to delete rows from. If ONLY is specified before the table name, matching rows are deleted from the named table only. If ONLY is not specified, matching rows are also deleted from any tables inheriting from the named table. Optionally, * can be specified after the table name to explicitly indicate that descendant tables are included.

alias

A substitute name for the target table. When an alias is provided, it completely hides the actual name of the table. For example, given DELETE FROM foo AS f, the remainder of the DELETE statement must refer to this table as f not foo.

from_item

A table expression allowing columns from other tables to appear in the WHERE condition. This uses the same syntax as the FROM clause of a SELECT statement; for example, an alias for the table name can be specified. Do not repeat the target table as a from_item unless you wish to set up a self-join (in which case it must appear with an alias in the from_item).

condition

An expression that returns a value of type boolean. Only rows for which this expression returns true will be deleted.

cursor_name

The name of the cursor to use in a WHERE CURRENT OF condition. The row to be deleted is the one most recently fetched from this cursor. The cursor must be a non-grouping query on the DELETEs target table. Note that WHERE CURRENT OF cannot be specified together with a Boolean condition. See DECLARE(7) for more information about using cursors with WHERE CURRENT OF.

output_expression

An expression to be computed and returned by the DELETE command after each row is deleted. The expression can use any column names of the table named by table_name or table(s) listed in USING. Write * to return all columns.

output_name

A name to use for a returned column.

OUTPUTS

On successful completion, a DELETE command returns a command tag of the form

DELETE count

The count is the number of rows deleted. Note that the number may be less than the number of rows that matched the condition when deletes were suppressed by a BEFORE DELETE trigger. If count is 0, no rows were deleted by the query (this is not considered an error).

If the DELETE command contains a RETURNING clause, the result will be similar to that of a SELECT statement containing the columns and values defined in the RETURNING list, computed over the row(s) deleted by the command.

NOTES

PostgreSQL lets you reference columns of other tables in the WHERE condition by specifying the other tables in the USING clause. For example, to delete all films produced by a given producer, one can do:

DELETE FROM films USING producers WHERE producer_id = producers.id AND producers.name = foo;

What is essentially happening here is a join between films and producers, with all successfully joined films rows being marked for deletion. This syntax is not standard. A more standard way to do it is:

DELETE FROM films WHERE producer_id IN (SELECT id FROM producers WHERE name = foo);

In some cases the join style is easier to write or faster to execute than the sub-select style.

EXAMPLES

Delete all films but musicals:

DELETE FROM films WHERE kind <> Musical;

Clear the table films:

DELETE FROM films;

Delete completed tasks, returning full details of the deleted rows:

DELETE FROM tasks WHERE status = DONE RETURNING *;

Delete the row of tasks on which the cursor c_tasks is currently positioned:

DELETE FROM tasks WHERE CURRENT OF c_tasks;

COMPATIBILITY

This command conforms to the SQL standard, except that the USING and RETURNING clauses are PostgreSQL extensions, as is the ability to use WITH with DELETE.

SEE ALSO

TRUNCATE(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

531 - Linux cli command thread-keyring

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command thread-keyring and provides detailed information about the command thread-keyring, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the thread-keyring.

NAME 🖥️ thread-keyring 🖥️

keyring - per-thread keyring

DESCRIPTION

The thread keyring is a keyring used to anchor keys on behalf of a process. It is created only when a thread requests it. The thread keyring has the name (description) _tid.

A special serial number value, KEY_SPEC_THREAD_KEYRING, is defined that can be used in lieu of the actual serial number of the calling thread’s thread keyring.

From the keyctl(1) utility, ‘@t’ can be used instead of a numeric key ID in much the same way, but as keyctl(1) is a program run after forking, this is of no utility.

Thread keyrings are not inherited across clone(2) and fork(2) and are cleared by execve(2). A thread keyring is destroyed when the thread that refers to it terminates.

Initially, a thread does not have a thread keyring. If a thread doesn’t have a thread keyring when it is accessed, then it will be created if it is to be modified; otherwise the operation fails with the error ENOKEY.

SEE ALSO

keyctl(1), keyctl(3), keyrings(7), persistent-keyring(7), process-keyring(7), session-keyring(7), user-keyring(7), user-session-keyring(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

532 - Linux cli command giteveryday

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command giteveryday and provides detailed information about the command giteveryday, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the giteveryday.

NAME 🖥️ giteveryday 🖥️

A useful minimum set of commands for Everyday Git

SYNOPSIS

Everyday Git With 20 Commands Or So

DESCRIPTION

Git users can broadly be grouped into four categories for the purposes of describing here a small set of useful commands for everyday Git.

·

Individual Developer (Standalone) commands are essential for anybody who makes a commit, even for somebody who works alone.

·

If you work with other people, you will need commands listed in the Individual Developer (Participant) section as well.

·

People who play the Integrator role need to learn some more commands in addition to the above.

·

Repository Administration commands are for system administrators who are responsible for the care and feeding of Git repositories.

INDIVIDUAL DEVELOPER (STANDALONE)

A standalone individual developer does not exchange patches with other people, and works alone in a single repository, using the following commands.

·

git-init(1) to create a new repository.

·

git-log(1) to see what happened.

·

git-switch(1) and git-branch(1) to switch branches.

·

git-add(1) to manage the index file.

·

git-diff(1) and git-status(1) to see what you are in the middle of doing.

·

git-commit(1) to advance the current branch.

·

git-restore(1) to undo changes.

·

git-merge(1) to merge between local branches.

·

git-rebase(1) to maintain topic branches.

·

git-tag(1) to mark a known point.

Examples

Use a tarball as a starting point for a new repository.

$ tar zxf frotz.tar.gz $ cd frotz $ git init $ git add . (1) $ git commit -m “import of frotz source tree.” $ git tag v2.43 (2)

1.add everything under the current directory.
2.make a lightweight, unannotated tag.

Create a topic branch and develop.

$ git switch -c alsa-audio (1) $ edit/compile/test $ git restore curses/ux_audio_oss.c (2) $ git add curses/ux_audio_alsa.c (3) $ edit/compile/test $ git diff HEAD (4) $ git commit -a -s (5) $ edit/compile/test $ git diff HEAD^ (6) $ git commit -a –amend (7) $ git switch master (8) $ git merge alsa-audio (9) $ git log –since=3 days ago (10) $ git log v2.43.. curses/ (11)

1.create a new topic branch.
2.revert your botched changes in curses/ux_audio_oss.c.
3.you need to tell Git if you added a new file; removal and modification will be caught if you do git commit -a later.
4.to see what changes you are committing.
5.commit everything, as you have tested, with your sign-off.
6.look at all your changes including the previous commit.
7.amend the previous commit, adding all your new changes, using your original message.
8.switch to the master branch.
9.merge a topic branch into your master branch.
10.review commit logs; other forms to limit output can be combined and include -10 (to show up to 10 commits), --until=2005-12-10, etc.
11.view only the changes that touch what’s in curses/ directory, since v2.43 tag.

INDIVIDUAL DEVELOPER (PARTICIPANT)

A developer working as a participant in a group project needs to learn how to communicate with others, and uses these commands in addition to the ones needed by a standalone developer.

·

git-clone(1) from the upstream to prime your local repository.

·

git-pull(1) and git-fetch(1) from “origin” to keep up-to-date with the upstream.

·

git-push(1) to shared repository, if you adopt CVS style shared repository workflow.

·

git-format-patch(1) to prepare e-mail submission, if you adopt Linux kernel-style public forum workflow.

·

git-send-email(1) to send your e-mail submission without corruption by your MUA.

·

git-request-pull(1) to create a summary of changes for your upstream to pull.

Examples

Clone the upstream and work on it. Feed changes to upstream.

$ git clone git://git.kernel.org/pub/scm/…/torvalds/linux-2.6 my2.6 $ cd my2.6 $ git switch -c mine master (1) $ edit/compile/test; git commit -a -s (2) $ git format-patch master (3) $ git send-email –to=“person [email protected]” 00*.patch (4) $ git switch master (5) $ git pull (6) $ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 (7) $ git ls-remote –heads http://git.kernel.org/.../jgarzik/libata-dev.git (8) $ git pull git://git.kernel.org/pub/…/jgarzik/libata-dev.git ALL (9) $ git reset –hard ORIG_HEAD (10) $ git gc (11)

1.checkout a new branch mine from master.
2.repeat as needed.
3.extract patches from your branch, relative to master,
4.and email them.
5.return to master, ready to see what’s new
6.git pull fetches from origin by default and merges into the current branch.
7.immediately after pulling, look at the changes done upstream since last time we checked, only in the area we are interested in.
8.check the branch names in an external repository (if not known).
9.fetch from a specific branch ALL from a specific repository and merge it.
10.revert the pull.
11.garbage collect leftover objects from reverted pull.

Push into another repository.

satellite$ git clone mothership:frotz frotz (1) satellite$ cd frotz satellite$ git config –get-regexp ^(remote|branch). (2) remote.origin.url mothership:frotz remote.origin.fetch refs/heads/:refs/remotes/origin/ branch.master.remote origin branch.master.merge refs/heads/master satellite$ git config remote.origin.push
+refs/heads/:refs/remotes/satellite/ (3) satellite$ edit/compile/test/commit satellite$ git push origin (4)

mothership$ cd frotz
mothership$ git switch master
mothership$ git merge satellite/master (5)
1.mothership machine has a frotz repository under your home directory; clone from it to start a repository on the satellite machine.
2.clone sets these configuration variables by default. It arranges git pull to fetch and store the branches of mothership machine to local remotes/origin/* remote-tracking branches.
3.arrange git push to push all local branches to their corresponding branch of the mothership machine.
4.push will stash all our work away on remotes/satellite/* remote-tracking branches on the mothership machine. You could use this as a back-up method. Likewise, you can pretend that mothership "fetched" from you (useful when access is one sided).
5.on mothership machine, merge the work done on the satellite machine into the master branch.

Branch off of a specific tag.

$ git switch -c private2.6.14 v2.6.14 (1) $ edit/compile/test; git commit -a $ git checkout master $ git cherry-pick v2.6.14..private2.6.14 (2)

1.create a private branch based on a well known (but somewhat behind) tag.
2.

forward port all changes in private2.6.14 branch to master branch without a formal "merging". Or longhand

git format-patch -k -m --stdout v2.6.14..private2.6.14 | git am -3 -k

An alternate participant submission mechanism is using the git request-pull or pull-request mechanisms (e.g. as used on GitHub (www.github.com) to notify your upstream of your contribution.

INTEGRATOR

A fairly central person acting as the integrator in a group project receives changes made by others, reviews and integrates them and publishes the result for others to use, using these commands in addition to the ones needed by participants.

This section can also be used by those who respond to git request-pull or pull-request on GitHub (www.github.com) to integrate the work of others into their history. A sub-area lieutenant for a repository will act both as a participant and as an integrator.

·

git-am(1) to apply patches e-mailed in from your contributors.

·

git-pull(1) to merge from your trusted lieutenants.

·

git-format-patch(1) to prepare and send suggested alternative to contributors.

·

git-revert(1) to undo botched commits.

·

git-push(1) to publish the bleeding edge.

Examples

A typical integrator’s Git day.

$ git status (1) $ git branch –no-merged master (2) $ mailx (3) & s 2 3 4 5 ./+to-apply & s 7 8 ./+hold-linus & q $ git switch -c topic/one master $ git am -3 -i -s ./+to-apply (4) $ compile/test $ git switch -c hold/linus && git am -3 -i -s ./+hold-linus (5) $ git switch topic/one && git rebase master (6) $ git switch -C seen next (7) $ git merge topic/one topic/two && git merge hold/linus (8) $ git switch maint $ git cherry-pick master~4 (9) $ compile/test $ git tag -s -m “GIT 0.99.9x” v0.99.9x (10) $ git fetch ko && for branch in master maint next seen (11) do git show-branch ko/$branch $branch (12) done $ git push –follow-tags ko (13)

1.see what you were in the middle of doing, if anything.
2.see which branches haven’t been merged into master yet. Likewise for any other integration branches e.g. maint, next and seen.
3.read mails, save ones that are applicable, and save others that are not quite ready (other mail readers are available).
4.apply them, interactively, with your sign-offs.
5.create topic branch as needed and apply, again with sign-offs.
6.rebase internal topic branch that has not been merged to the master or exposed as a part of a stable branch.
7.restart seen every time from the next.
8.and bundle topic branches still cooking.
9.backport a critical fix.
10.create a signed tag.
11.make sure master was not accidentally rewound beyond that already pushed out.
12.In the output from git show-branch, master should have everything ko/master has, and next should have everything ko/next has, etc.
13.push out the bleeding edge, together with new tags that point into the pushed history.

In this example, the ko shorthand points at the Git maintainer’s repository at kernel.org, and looks like this:

(in .git/config) [remote “ko”] url = kernel.org:/pub/scm/git/git.git fetch = refs/heads/:refs/remotes/ko/ push = refs/heads/master push = refs/heads/next push = +refs/heads/seen push = refs/heads/maint

REPOSITORY ADMINISTRATION

A repository administrator uses the following tools to set up and maintain access to the repository by developers.

·

git-daemon(1) to allow anonymous download from repository.

·

git-shell(1) can be used as a restricted login shell for shared central repository users.

·

git-http-backend(1) provides a server side implementation of Git-over-HTTP (“Smart http”) allowing both fetch and push services.

·

gitweb(1) provides a web front-end to Git repositories, which can be set-up using the git-instaweb(1) script.

update hook howto[1] has a good example of managing a shared central repository.

In addition there are a number of other widely deployed hosting, browsing and reviewing solutions such as:

·

gitolite, gerrit code review, cgit and others.

Examples

We assume the following in /etc/services

$ grep 9418 /etc/services git 9418/tcp # Git Version Control System

Run git-daemon to serve /pub/scm from inetd.

$ grep git /etc/inetd.conf git stream tcp nowait nobody
/usr/bin/git-daemon git-daemon –inetd –export-all /pub/scm

The actual configuration line should be on one line.

Run git-daemon to serve /pub/scm from xinetd.

$ cat /etc/xinetd.d/git-daemon # default: off # description: The Git server offers access to Git repositories service git { disable = no type = UNLISTED port = 9418 socket_type = stream wait = no user = nobody server = /usr/bin/git-daemon server_args = –inetd –export-all –base-path=/pub/scm log_on_failure += USERID }

Check your xinetd(8) documentation and setup, this is from a Fedora system. Others might be different.

Give push/pull only access to developers using git-over-ssh.

e.g. those using: $ git push/pull ssh://host.xz/pub/scm/project

$ grep git /etc/passwd (1) alice:x:1000:1000::/home/alice:/usr/bin/git-shell bob:x:1001:1001::/home/bob:/usr/bin/git-shell cindy:x:1002:1002::/home/cindy:/usr/bin/git-shell david:x:1003:1003::/home/david:/usr/bin/git-shell $ grep git /etc/shells (2) /usr/bin/git-shell

1.log-in shell is set to /usr/bin/git-shell, which does not allow anything but git push and git pull. The users require ssh access to the machine.
2.in many distributions /etc/shells needs to list what is used as the login shell.

CVS-style shared repository.

$ grep git /etc/group (1) git:x:9418:alice,bob,cindy,david $ cd /home/devo.git $ ls -l (2) lrwxrwxrwx 1 david git 17 Dec 4 22:40 HEAD -> refs/heads/master drwxrwsr-x 2 david git 4096 Dec 4 22:40 branches -rw-rw-r– 1 david git 84 Dec 4 22:40 config -rw-rw-r– 1 david git 58 Dec 4 22:40 description drwxrwsr-x 2 david git 4096 Dec 4 22:40 hooks -rw-rw-r– 1 david git 37504 Dec 4 22:40 index drwxrwsr-x 2 david git 4096 Dec 4 22:40 info drwxrwsr-x 4 david git 4096 Dec 4 22:40 objects drwxrwsr-x 4 david git 4096 Nov 7 14:58 refs drwxrwsr-x 2 david git 4096 Dec 4 22:40 remotes $ ls -l hooks/update (3) -r-xr-xr-x 1 david git 3536 Dec 4 22:40 update $ cat info/allowed-users (4) refs/heads/master alice|cindy refs/heads/doc-update bob refs/tags/v[0-9]* david

1.place the developers into the same git group.
2.and make the shared repository writable by the group.
3.use update-hook example by Carl from Documentation/howto/ for branch policy control.
4.alice and cindy can push into master, only bob can push into doc-update. david is the release manager and is the only person who can create and push version tags.

GIT

Part of the git(1) suite

NOTES

update hook howto

file:///usr/share/doc/git/html/howto/update-hook-example.html

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

533 - Linux cli command gitremote-helpers

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command gitremote-helpers and provides detailed information about the command gitremote-helpers, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the gitremote-helpers.

NAME 🖥️ gitremote-helpers 🖥️

helpers - Helper programs to interact with remote repositories

SYNOPSIS

git remote-<transport> <repository> [<URL>]

DESCRIPTION

Remote helper programs are normally not used directly by end users, but they are invoked by Git when it needs to interact with remote repositories Git does not support natively. A given helper will implement a subset of the capabilities documented here. When Git needs to interact with a repository using a remote helper, it spawns the helper as an independent process, sends commands to the helper’s standard input, and expects results from the helper’s standard output. Because a remote helper runs as an independent process from Git, there is no need to re-link Git to add a new helper, nor any need to link the helper with the implementation of Git.

Every helper must support the “capabilities” command, which Git uses to determine what other commands the helper will accept. Those other commands can be used to discover and update remote refs, transport objects between the object database and the remote repository, and update the local object store.

Git comes with a “curl” family of remote helpers, that handle various transport protocols, such as git-remote-http, git-remote-https, git-remote-ftp and git-remote-ftps. They implement the capabilities fetch, option, and push.

INVOCATION

Remote helper programs are invoked with one or (optionally) two arguments. The first argument specifies a remote repository as in Git; it is either the name of a configured remote or a URL. The second argument specifies a URL; it is usually of the form <transport>://<address>, but any arbitrary string is possible. The GIT_DIR environment variable is set up for the remote helper and can be used to determine where to store additional data or from which directory to invoke auxiliary Git commands.

When Git encounters a URL of the form <transport>://<address>, where <transport> is a protocol that it cannot handle natively, it automatically invokes git remote-<transport> with the full URL as the second argument. If such a URL is encountered directly on the command line, the first argument is the same as the second, and if it is encountered in a configured remote, the first argument is the name of that remote.

A URL of the form <transport>::<address> explicitly instructs Git to invoke git remote-<transport> with <address> as the second argument. If such a URL is encountered directly on the command line, the first argument is <address>, and if it is encountered in a configured remote, the first argument is the name of that remote.

Additionally, when a configured remote has remote.<name>.vcs set to <transport>, Git explicitly invokes git remote-<transport> with <name> as the first argument. If set, the second argument is remote.<name>.url; otherwise, the second argument is omitted.

INPUT FORMAT

Git sends the remote helper a list of commands on standard input, one per line. The first command is always the capabilities command, in response to which the remote helper must print a list of the capabilities it supports (see below) followed by a blank line. The response to the capabilities command determines what commands Git uses in the remainder of the command stream.

The command stream is terminated by a blank line. In some cases (indicated in the documentation of the relevant commands), this blank line is followed by a payload in some other protocol (e.g., the pack protocol), while in others it indicates the end of input.

Capabilities

Each remote helper is expected to support only a subset of commands. The operations a helper supports are declared to Git in the response to the capabilities command (see COMMANDS, below).

In the following, we list all defined capabilities and for each we list which commands a helper with that capability must provide.

Capabilities for Pushing

connect

Can attempt to connect to git receive-pack (for pushing), git upload-pack, etc for communication using git’s native packfile protocol. This requires a bidirectional, full-duplex connection.

Supported commands: connect.

stateless-connect

Experimental; for internal use only. Can attempt to connect to a remote server for communication using git’s wire-protocol version 2. See the documentation for the stateless-connect command for more information.

Supported commands: stateless-connect.

push

Can discover remote refs and push local commits and the history leading up to them to new or existing remote refs.

Supported commands: list for-push, push.

export

Can discover remote refs and push specified objects from a fast-import stream to remote refs.

Supported commands: list for-push, export.

If a helper advertises connect, Git will use it if possible and fall back to another capability if the helper requests so when connecting (see the connect command under COMMANDS). When choosing between push and export, Git prefers push. Other frontends may have some other order of preference.

no-private-update

When using the refspec capability, git normally updates the private ref on successful push. This update is disabled when the remote-helper declares the capability no-private-update.

Capabilities for Fetching

connect

Can try to connect to git upload-pack (for fetching), git receive-pack, etc for communication using the Git’s native packfile protocol. This requires a bidirectional, full-duplex connection.

Supported commands: connect.

stateless-connect

Experimental; for internal use only. Can attempt to connect to a remote server for communication using git’s wire-protocol version 2. See the documentation for the stateless-connect command for more information.

Supported commands: stateless-connect.

fetch

Can discover remote refs and transfer objects reachable from them to the local object store.

Supported commands: list, fetch.

import

Can discover remote refs and output objects reachable from them as a stream in fast-import format.

Supported commands: list, import.

check-connectivity

Can guarantee that when a clone is requested, the received pack is self contained and is connected.

get

Can use the get command to download a file from a given URI.

If a helper advertises connect, Git will use it if possible and fall back to another capability if the helper requests so when connecting (see the connect command under COMMANDS). When choosing between fetch and import, Git prefers fetch. Other frontends may have some other order of preference.

Miscellaneous capabilities

option

For specifying settings like verbosity (how much output to write to stderr) and depth (how much history is wanted in the case of a shallow clone) that affect how other commands are carried out.

refspec <refspec>

For remote helpers that implement import or export, this capability allows the refs to be constrained to a private namespace, instead of writing to refs/heads or refs/remotes directly. It is recommended that all importers providing the import capability use this. It’s mandatory for export.

A helper advertising the capability refspec refs/heads/*:refs/svn/origin/branches/* is saying that, when it is asked to import refs/heads/topic, the stream it outputs will update the refs/svn/origin/branches/topic ref.

This capability can be advertised multiple times. The first applicable refspec takes precedence. The left-hand of refspecs advertised with this capability must cover all refs reported by the list command. If no refspec capability is advertised, there is an implied refspec *:*.

When writing remote-helpers for decentralized version control systems, it is advised to keep a local copy of the repository to interact with, and to let the private namespace refs point to this local repository, while the refs/remotes namespace is used to track the remote repository.

bidi-import

This modifies the import capability. The fast-import commands cat-blob and ls can be used by remote-helpers to retrieve information about blobs and trees that already exist in fast-import’s memory. This requires a channel from fast-import to the remote-helper. If it is advertised in addition to “import”, Git establishes a pipe from fast-import to the remote-helper’s stdin. It follows that Git and fast-import are both connected to the remote-helper’s stdin. Because Git can send multiple commands to the remote-helper it is required that helpers that use bidi-import buffer all import commands of a batch before sending data to fast-import. This is to prevent mixing commands and fast-import responses on the helper’s stdin.

export-marks <file>

This modifies the export capability, instructing Git to dump the internal marks table to <file> when complete. For details, read up on –export-marks=<file> in git-fast-export(1).

import-marks <file>

This modifies the export capability, instructing Git to load the marks specified in <file> before processing any input. For details, read up on –import-marks=<file> in git-fast-export(1).

signed-tags

This modifies the export capability, instructing Git to pass –signed-tags=verbatim to git-fast-export(1). In the absence of this capability, Git will use –signed-tags=warn-strip.

object-format

This indicates that the helper is able to interact with the remote side using an explicit hash algorithm extension.

COMMANDS

Commands are given by the caller on the helper’s standard input, one per line.

capabilities

Lists the capabilities of the helper, one per line, ending with a blank line. Each capability may be preceded with *, which marks them mandatory for Git versions using the remote helper to understand. Any unknown mandatory capability is a fatal error.

Support for this command is mandatory.

list

Lists the refs, one per line, in the format “<value> <name> [<attr> …]”. The value may be a hex sha1 hash, “@<dest>” for a symref, “:<keyword> <value>” for a key-value pair, or “?” to indicate that the helper could not get the value of the ref. A space-separated list of attributes follows the name; unrecognized attributes are ignored. The list ends with a blank line.

See REF LIST ATTRIBUTES for a list of currently defined attributes. See REF LIST KEYWORDS for a list of currently defined keywords.

Supported if the helper has the “fetch” or “import” capability.

list for-push

Similar to list, except that it is used if and only if the caller wants to the resulting ref list to prepare push commands. A helper supporting both push and fetch can use this to distinguish for which operation the output of list is going to be used, possibly reducing the amount of work that needs to be performed.

Supported if the helper has the “push” or “export” capability.

option <name> <value>

Sets the transport helper option <name> to <value>. Outputs a single line containing one of ok (option successfully set), unsupported (option not recognized) or error <msg> (option <name> is supported but <value> is not valid for it). Options should be set before other commands, and may influence the behavior of those commands.

See OPTIONS for a list of currently defined options.

Supported if the helper has the “option” capability.

fetch <sha1> <name>

Fetches the given object, writing the necessary objects to the database. Fetch commands are sent in a batch, one per line, terminated with a blank line. Outputs a single blank line when all fetch commands in the same batch are complete. Only objects which were reported in the output of list with a sha1 may be fetched this way.

Optionally may output a lock <file> line indicating the full path of a file under $GIT_DIR/objects/pack which is keeping a pack until refs can be suitably updated. The path must end with .keep. This is a mechanism to name a <pack,idx,keep> tuple by giving only the keep component. The kept pack will not be deleted by a concurrent repack, even though its objects may not be referenced until the fetch completes. The .keep file will be deleted at the conclusion of the fetch.

If option check-connectivity is requested, the helper must output connectivity-ok if the clone is self-contained and connected.

Supported if the helper has the “fetch” capability.

push +<src>:<dst>

Pushes the given local <src> commit or branch to the remote branch described by <dst>. A batch sequence of one or more push commands is terminated with a blank line (if there is only one reference to push, a single push command is followed by a blank line). For example, the following would be two batches of push, the first asking the remote-helper to push the local ref master to the remote ref master and the local HEAD to the remote branch, and the second asking to push ref foo to ref bar (forced update requested by the +).

push refs/heads/master:refs/heads/master push HEAD:refs/heads/branch

push +refs/heads/foo:refs/heads/bar

Zero or more protocol options may be entered after the last push command, before the batch’s terminating blank line.

When the push is complete, outputs one or more ok <dst> or error <dst> <why>? lines to indicate success or failure of each pushed ref. The status report output is terminated by a blank line. The option field <why> may be quoted in a C style string if it contains an LF.

Supported if the helper has the “push” capability.

import <name>

Produces a fast-import stream which imports the current value of the named ref. It may additionally import other refs as needed to construct the history efficiently. The script writes to a helper-specific private namespace. The value of the named ref should be written to a location in this namespace derived by applying the refspecs from the “refspec” capability to the name of the ref.

Especially useful for interoperability with a foreign versioning system.

Just like push, a batch sequence of one or more import is terminated with a blank line. For each batch of import, the remote helper should produce a fast-import stream terminated by a done command.

Note that if the bidi-import capability is used the complete batch sequence has to be buffered before starting to send data to fast-import to prevent mixing of commands and fast-import responses on the helper’s stdin.

Supported if the helper has the “import” capability.

export

Instructs the remote helper that any subsequent input is part of a fast-import stream (generated by git fast-export) containing objects which should be pushed to the remote.

Especially useful for interoperability with a foreign versioning system.

The export-marks and import-marks capabilities, if specified, affect this command in so far as they are passed on to git fast-export, which then will load/store a table of marks for local objects. This can be used to implement for incremental operations.

Supported if the helper has the “export” capability.

connect <service>

Connects to given service. Standard input and standard output of helper are connected to specified service (git prefix is included in service name so e.g. fetching uses git-upload-pack as service) on remote side. Valid replies to this command are empty line (connection established), fallback (no smart transport support, fall back to dumb transports) and just exiting with error message printed (can’t connect, don’t bother trying to fall back). After line feed terminating the positive (empty) response, the output of service starts. After the connection ends, the remote helper exits.

Supported if the helper has the “connect” capability.

stateless-connect <service>

Experimental; for internal use only. Connects to the given remote service for communication using git’s wire-protocol version 2. Valid replies to this command are empty line (connection established), fallback (no smart transport support, fall back to dumb transports) and just exiting with error message printed (can’t connect, don’t bother trying to fall back). After line feed terminating the positive (empty) response, the output of the service starts. Messages (both request and response) must consist of zero or more PKT-LINEs, terminating in a flush packet. Response messages will then have a response end packet after the flush packet to indicate the end of a response. The client must not expect the server to store any state in between request-response pairs. After the connection ends, the remote helper exits.

Supported if the helper has the “stateless-connect” capability.

get <uri> <path>

Downloads the file from the given <uri> to the given <path>. If <path>.temp exists, then Git assumes that the .temp file is a partial download from a previous attempt and will resume the download from that position.

If a fatal error occurs, the program writes the error message to stderr and exits. The caller should expect that a suitable error message has been printed if the child closes the connection without completing a valid response for the current command.

Additional commands may be supported, as may be determined from capabilities reported by the helper.

REF LIST ATTRIBUTES

The list command produces a list of refs in which each ref may be followed by a list of attributes. The following ref list attributes are defined.

unchanged

This ref is unchanged since the last import or fetch, although the helper cannot necessarily determine what value that produced.

REF LIST KEYWORDS

The list command may produce a list of key-value pairs. The following keys are defined.

object-format

The refs are using the given hash algorithm. This keyword is only used if the server and client both support the object-format extension.

OPTIONS

The following options are defined and (under suitable circumstances) set by Git if the remote helper has the option capability.

option verbosity <n>

Changes the verbosity of messages displayed by the helper. A value of 0 for <n> means that processes operate quietly, and the helper produces only error output. 1 is the default level of verbosity, and higher values of <n> correspond to the number of -v flags passed on the command line.

option progress {true|false}

Enables (or disables) progress messages displayed by the transport helper during a command.

option depth <depth>

Deepens the history of a shallow repository.

option deepen-since <timestamp>

Deepens the history of a shallow repository based on time.

option deepen-not <ref>

Deepens the history of a shallow repository excluding ref. Multiple options add up.

option deepen-relative {true|false}

Deepens the history of a shallow repository relative to current boundary. Only valid when used with “option depth”.

option followtags {true|false}

If enabled the helper should automatically fetch annotated tag objects if the object the tag points at was transferred during the fetch command. If the tag is not fetched by the helper a second fetch command will usually be sent to ask for the tag specifically. Some helpers may be able to use this option to avoid a second network connection.

option dry-run {true|false}: If true, pretend the operation completed successfully, but don’t actually change any repository data. For most helpers this only applies to the push, if supported.

option servpath <c-style-quoted-path>

Sets service path (–upload-pack, –receive-pack etc.) for next connect. Remote helper may support this option, but must not rely on this option being set before connect request occurs.

option check-connectivity {true|false}

Request the helper to check connectivity of a clone.

option force {true|false}

Request the helper to perform a force update. Defaults to false.

option cloning {true|false}

Notify the helper this is a clone request (i.e. the current repository is guaranteed empty).

option update-shallow {true|false}

Allow to extend .git/shallow if the new refs require it.

option pushcert {true|false}

GPG sign pushes.

option push-option <string>

Transmit <string> as a push option. As the push option must not contain LF or NUL characters, the string is not encoded.

option from-promisor {true|false}

Indicate that these objects are being fetched from a promisor.

option no-dependents {true|false}

Indicate that only the objects wanted need to be fetched, not their dependents.

option atomic {true|false}

When pushing, request the remote server to update refs in a single atomic transaction. If successful, all refs will be updated, or none will. If the remote side does not support this capability, the push will fail.

option object-format {true|algorithm}

If true, indicate that the caller wants hash algorithm information to be passed back from the remote. This mode is used when fetching refs.

If set to an algorithm, indicate that the caller wants to interact with the remote side using that algorithm.

SEE ALSO

git-remote(1)

git-remote-ext(1)

git-remote-fd(1)

git-fast-import(1)

GIT

Part of the git(1) suite

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

534 - Linux cli command provider-basessl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command provider-basessl and provides detailed information about the command provider-basessl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the provider-basessl.

NAME 🖥️ provider-basessl 🖥️

base - The basic OpenSSL library <-> provider functions

SYNOPSIS

#include <openssl/core_dispatch.h> /* * None of these are actual functions, but are displayed like this for * the function signatures for functions that are offered as function * pointers in OSSL_DISPATCH arrays. */ /* Functions offered by libcrypto to the providers */ const OSSL_ITEM *core_gettable_params(const OSSL_CORE_HANDLE *handle); int core_get_params(const OSSL_CORE_HANDLE *handle, OSSL_PARAM params[]); typedef void (*OSSL_thread_stop_handler_fn)(void *arg); int core_thread_start(const OSSL_CORE_HANDLE *handle, OSSL_thread_stop_handler_fn handfn, void *arg); OPENSSL_CORE_CTX *core_get_libctx(const OSSL_CORE_HANDLE *handle); void core_new_error(const OSSL_CORE_HANDLE *handle); void core_set_error_debug(const OSSL_CORE_HANDLE *handle, const char *file, int line, const char *func); void core_vset_error(const OSSL_CORE_HANDLE *handle, uint32_t reason, const char *fmt, va_list args); int core_obj_add_sigid(const OSSL_CORE_HANDLE *prov, const char *sign_name, const char *digest_name, const char *pkey_name); int core_obj_create(const OSSL_CORE_HANDLE *handle, const char *oid, const char *sn, const char *ln); /* * Some OpenSSL functionality is directly offered to providers via * dispatch */ void *CRYPTO_malloc(size_t num, const char *file, int line); void *CRYPTO_zalloc(size_t num, const char *file, int line); void CRYPTO_free(void *ptr, const char *file, int line); void CRYPTO_clear_free(void *ptr, size_t num, const char *file, int line); void *CRYPTO_realloc(void *addr, size_t num, const char *file, int line); void *CRYPTO_clear_realloc(void *addr, size_t old_num, size_t num, const char *file, int line); void *CRYPTO_secure_malloc(size_t num, const char *file, int line); void *CRYPTO_secure_zalloc(size_t num, const char *file, int line); void CRYPTO_secure_free(void *ptr, const char *file, int line); void CRYPTO_secure_clear_free(void *ptr, size_t num, const char *file, int line); int CRYPTO_secure_allocated(const void *ptr); void OPENSSL_cleanse(void *ptr, size_t len); unsigned char *OPENSSL_hexstr2buf(const char *str, long *buflen); OSSL_CORE_BIO *BIO_new_file(const char *filename, const char *mode); OSSL_CORE_BIO *BIO_new_membuf(const void *buf, int len); int BIO_read_ex(OSSL_CORE_BIO *bio, void *data, size_t data_len, size_t *bytes_read); int BIO_write_ex(OSSL_CORE_BIO *bio, const void *data, size_t data_len, size_t *written); int BIO_up_ref(OSSL_CORE_BIO *bio); int BIO_free(OSSL_CORE_BIO *bio); int BIO_vprintf(OSSL_CORE_BIO *bio, const char *format, va_list args); int BIO_vsnprintf(char *buf, size_t n, const char *fmt, va_list args); void OSSL_SELF_TEST_set_callback(OSSL_LIB_CTX *libctx, OSSL_CALLBACK *cb, void *cbarg); size_t get_entropy(const OSSL_CORE_HANDLE *handle, unsigned char **pout, int entropy, size_t min_len, size_t max_len); size_t get_user_entropy(const OSSL_CORE_HANDLE *handle, unsigned char **pout, int entropy, size_t min_len, size_t max_len); void cleanup_entropy(const OSSL_CORE_HANDLE *handle, unsigned char *buf, size_t len); void cleanup_user_entropy(const OSSL_CORE_HANDLE *handle, unsigned char *buf, size_t len); size_t get_nonce(const OSSL_CORE_HANDLE *handle, unsigned char **pout, size_t min_len, size_t max_len, const void *salt, size_t salt_len); size_t get_user_nonce(const OSSL_CORE_HANDLE *handle, unsigned char **pout, size_t min_len, size_t max_len, const void *salt, size_t salt_len); void cleanup_nonce(const OSSL_CORE_HANDLE *handle, unsigned char *buf, size_t len); void cleanup_user_nonce(const OSSL_CORE_HANDLE *handle, unsigned char *buf, size_t len); /* Functions for querying the providers in the application library context */ int provider_register_child_cb(const OSSL_CORE_HANDLE *handle, int (*create_cb)(const OSSL_CORE_HANDLE *provider, void *cbdata), int (*remove_cb)(const OSSL_CORE_HANDLE *provider, void *cbdata), int (*global_props_cb)(const char *props, void *cbdata), void *cbdata); void provider_deregister_child_cb(const OSSL_CORE_HANDLE *handle); const char *provider_name(const OSSL_CORE_HANDLE *prov); void *provider_get0_provider_ctx(const OSSL_CORE_HANDLE *prov); const OSSL_DISPATCH *provider_get0_dispatch(const OSSL_CORE_HANDLE *prov); int provider_up_ref(const OSSL_CORE_HANDLE *prov, int activate); int provider_free(const OSSL_CORE_HANDLE *prov, int deactivate); /* Functions offered by the provider to libcrypto */ void provider_teardown(void *provctx); const OSSL_ITEM *provider_gettable_params(void *provctx); int provider_get_params(void *provctx, OSSL_PARAM params[]); const OSSL_ALGORITHM *provider_query_operation(void *provctx, int operation_id, const int *no_store); void provider_unquery_operation(void *provctx, int operation_id, const OSSL_ALGORITHM *algs); const OSSL_ITEM *provider_get_reason_strings(void *provctx); int provider_get_capabilities(void *provctx, const char *capability, OSSL_CALLBACK *cb, void *arg); int provider_self_test(void *provctx);

DESCRIPTION

All “functions” mentioned here are passed as function pointers between libcrypto and the provider in OSSL_DISPATCH (3) arrays, in the call of the provider initialization function. See “Provider” in provider (7) for a description of the initialization function. They are known as “upcalls”.

All these “functions” have a corresponding function type definition named OSSL_FUNC_{name}_fn, and a helper function to retrieve the function pointer from a OSSL_DISPATCH (3) element named OSSL_FUNC_{name}. For example, the “function” core_gettable_params() has these:

typedef OSSL_PARAM * (OSSL_FUNC_core_gettable_params_fn)(const OSSL_CORE_HANDLE *handle); static ossl_inline OSSL_NAME_core_gettable_params_fn OSSL_FUNC_core_gettable_params(const OSSL_DISPATCH *opf);

OSSL_DISPATCH (3) arrays are indexed by numbers that are provided as macros in openssl-core_dispatch.h (7), as follows:

For in (the OSSL_DISPATCH (3) array passed from libcrypto to the provider):

core_gettable_params OSSL_FUNC_CORE_GETTABLE_PARAMS core_get_params OSSL_FUNC_CORE_GET_PARAMS core_thread_start OSSL_FUNC_CORE_THREAD_START core_get_libctx OSSL_FUNC_CORE_GET_LIBCTX core_new_error OSSL_FUNC_CORE_NEW_ERROR core_set_error_debug OSSL_FUNC_CORE_SET_ERROR_DEBUG core_vset_error OSSL_FUNC_CORE_VSET_ERROR core_obj_add_sigid OSSL_FUNC_CORE_OBJ_ADD_SIGID core_obj_create OSSL_FUNC_CORE_OBJ_CREATE CRYPTO_malloc OSSL_FUNC_CRYPTO_MALLOC CRYPTO_zalloc OSSL_FUNC_CRYPTO_ZALLOC CRYPTO_free OSSL_FUNC_CRYPTO_FREE CRYPTO_clear_free OSSL_FUNC_CRYPTO_CLEAR_FREE CRYPTO_realloc OSSL_FUNC_CRYPTO_REALLOC CRYPTO_clear_realloc OSSL_FUNC_CRYPTO_CLEAR_REALLOC CRYPTO_secure_malloc OSSL_FUNC_CRYPTO_SECURE_MALLOC CRYPTO_secure_zalloc OSSL_FUNC_CRYPTO_SECURE_ZALLOC CRYPTO_secure_free OSSL_FUNC_CRYPTO_SECURE_FREE CRYPTO_secure_clear_free OSSL_FUNC_CRYPTO_SECURE_CLEAR_FREE CRYPTO_secure_allocated OSSL_FUNC_CRYPTO_SECURE_ALLOCATED BIO_new_file OSSL_FUNC_BIO_NEW_FILE BIO_new_mem_buf OSSL_FUNC_BIO_NEW_MEMBUF BIO_read_ex OSSL_FUNC_BIO_READ_EX BIO_write_ex OSSL_FUNC_BIO_WRITE_EX BIO_up_ref OSSL_FUNC_BIO_UP_REF BIO_free OSSL_FUNC_BIO_FREE BIO_vprintf OSSL_FUNC_BIO_VPRINTF BIO_vsnprintf OSSL_FUNC_BIO_VSNPRINTF BIO_puts OSSL_FUNC_BIO_PUTS BIO_gets OSSL_FUNC_BIO_GETS BIO_ctrl OSSL_FUNC_BIO_CTRL OPENSSL_cleanse OSSL_FUNC_OPENSSL_CLEANSE OSSL_SELF_TEST_set_callback OSSL_FUNC_SELF_TEST_CB ossl_rand_get_entropy OSSL_FUNC_GET_ENTROPY ossl_rand_get_user_entropy OSSL_FUNC_GET_USER_ENTROPY ossl_rand_cleanup_entropy OSSL_FUNC_CLEANUP_ENTROPY ossl_rand_cleanup_user_entropy OSSL_FUNC_CLEANUP_USER_ENTROPY ossl_rand_get_nonce OSSL_FUNC_GET_NONCE ossl_rand_get_user_nonce OSSL_FUNC_GET_USER_NONCE ossl_rand_cleanup_nonce OSSL_FUNC_CLEANUP_NONCE ossl_rand_cleanup_user_nonce OSSL_FUNC_CLEANUP_USER_NONCE provider_register_child_cb OSSL_FUNC_PROVIDER_REGISTER_CHILD_CB provider_deregister_child_cb OSSL_FUNC_PROVIDER_DEREGISTER_CHILD_CB provider_name OSSL_FUNC_PROVIDER_NAME provider_get0_provider_ctx OSSL_FUNC_PROVIDER_GET0_PROVIDER_CTX provider_get0_dispatch OSSL_FUNC_PROVIDER_GET0_DISPATCH provider_up_ref OSSL_FUNC_PROVIDER_UP_REF provider_free OSSL_FUNC_PROVIDER_FREE

For *out (the OSSL_DISPATCH (3) array passed from the provider to libcrypto):

provider_teardown OSSL_FUNC_PROVIDER_TEARDOWN provider_gettable_params OSSL_FUNC_PROVIDER_GETTABLE_PARAMS provider_get_params OSSL_FUNC_PROVIDER_GET_PARAMS provider_query_operation OSSL_FUNC_PROVIDER_QUERY_OPERATION provider_unquery_operation OSSL_FUNC_PROVIDER_UNQUERY_OPERATION provider_get_reason_strings OSSL_FUNC_PROVIDER_GET_REASON_STRINGS provider_get_capabilities OSSL_FUNC_PROVIDER_GET_CAPABILITIES provider_self_test OSSL_FUNC_PROVIDER_SELF_TEST

Core functions

core_gettable_params() returns a constant array of descriptor OSSL_PARAM (3), for parameters that core_get_params() can handle.

core_get_params() retrieves parameters from the core for the given handle. See “Core parameters” below for a description of currently known parameters.

The core_thread_start() function informs the core that the provider has stated an interest in the current thread. The core will inform the provider when the thread eventually stops. It must be passed the handle for this provider, as well as a callback handfn which will be called when the thread stops. The callback will subsequently be called, with the supplied argument arg, from the thread that is stopping and gets passed the provider context as an argument. This may be useful to perform thread specific clean up such as freeing thread local variables.

core_get_libctx() retrieves the core context in which the library object for the current provider is stored, accessible through the handle. This function is useful only for built-in providers such as the default provider. Never cast this to OSSL_LIB_CTX in a provider that is not built-in as the OSSL_LIB_CTX of the library loading the provider might be a completely different structure than the OSSL_LIB_CTX of the library the provider is linked to. Use OSSL_LIB_CTX_new_child (3) instead to obtain a proper library context that is linked to the application library context.

core_new_error(), core_set_error_debug() and core_vset_error() are building blocks for reporting an error back to the core, with reference to the handle.

core_new_error()
allocates a new thread specific error record. This corresponds to the OpenSSL function ERR_new (3).

core_set_error_debug()
sets debugging information in the current thread specific error record. The debugging information includes the name of the file file, the line line and the function name func where the error occurred. This corresponds to the OpenSSL function ERR_set_debug (3).

core_vset_error()
sets the reason for the error, along with any addition data. The reason is a number defined by the provider and used to index the reason strings table that’s returned by provider_get_reason_strings(). The additional data is given as a format string fmt and a set of arguments args, which are treated in the same manner as with BIO_vsnprintf(). file and line may also be passed to indicate exactly where the error occurred or was reported. This corresponds to the OpenSSL function ERR_vset_error (3).

The core_obj_create() function registers a new OID and associated short name sn and long name ln for the given handle. It is similar to the OpenSSL function OBJ_create (3) except that it returns 1 on success or 0 on failure. It will treat as success the case where the OID already exists (even if the short name sn or long name ln provided as arguments differ from those associated with the existing OID, in which case the new names are not associated).

The core_obj_add_sigid() function registers a new composite signature algorithm (sign_name) consisting of an underlying signature algorithm (pkey_name) and digest algorithm (digest_name) for the given handle. It assumes that the OIDs for the composite signature algorithm as well as for the underlying signature and digest algorithms are either already known to OpenSSL or have been registered via a call to core_obj_create(). It corresponds to the OpenSSL function OBJ_add_sigid (3), except that the objects are identified by name rather than a numeric NID. Any name (OID, short name or long name) can be used to identify the object. It will treat as success the case where the composite signature algorithm already exists (even if registered against a different underlying signature or digest algorithm). For digest_name, NULL or an empty string is permissible for signature algorithms that do not need a digest to operate correctly. The function returns 1 on success or 0 on failure.

CRYPTO_malloc(), CRYPTO_zalloc(), CRYPTO_free(), CRYPTO_clear_free(), CRYPTO_realloc(), CRYPTO_clear_realloc(), CRYPTO_secure_malloc(), CRYPTO_secure_zalloc(), CRYPTO_secure_free(), CRYPTO_secure_clear_free(), CRYPTO_secure_allocated(), BIO_new_file(), BIO_new_mem_buf(), BIO_read_ex(), BIO_write_ex(), BIO_up_ref(), BIO_free(), BIO_vprintf(), BIO_vsnprintf(), BIO_gets(), BIO_puts(), BIO_ctrl(), OPENSSL_cleanse() and OPENSSL_hexstr2buf() correspond exactly to the public functions with the same name. As a matter of fact, the pointers in the OSSL_DISPATCH (3) array are typically direct pointers to those public functions. Note that the BIO functions take an OSSL_CORE_BIO type rather than the standard BIO type. This is to ensure that a provider does not mix BIOs from the core with BIOs used on the provider side (the two are not compatible). OSSL_SELF_TEST_set_callback() is used to set an optional callback that can be passed into a provider. This may be ignored by a provider.

get_entropy() retrieves seeding material from the operating system. The seeding material will have at least entropy bytes of randomness and the output will have at least min_len and at most max_len bytes. The buffer address is stored in *pout and the buffer length is returned to the caller. On error, zero is returned.

get_user_entropy() is the same as get_entropy() except that it will attempt to gather seed material via the seed source specified by a call to RAND_set_seed_source_type (3) or via “Random Configuration” in config (5).

cleanup_entropy() is used to clean up and free the buffer returned by get_entropy(). The entropy pointer returned by get_entropy() is passed in buf and its length in len.

cleanup_user_entropy() is used to clean up and free the buffer returned by get_user_entropy(). The entropy pointer returned by get_user_entropy() is passed in buf and its length in len.

get_nonce() retrieves a nonce using the passed salt parameter of length salt_len and operating system specific information. The salt should contain uniquely identifying information and this is included, in an unspecified manner, as part of the output. The output is stored in a buffer which contains at least min_len and at most max_len bytes. The buffer address is stored in *pout and the buffer length returned to the caller. On error, zero is returned.

get_user_nonce() is the same as get_nonce() except that it will attempt to gather seed material via the seed source specified by a call to RAND_set_seed_source_type (3) or via “Random Configuration” in config (5).

cleanup_nonce() is used to clean up and free the buffer returned by get_nonce(). The nonce pointer returned by get_nonce() is passed in buf and its length in len.

cleanup_user_nonce() is used to clean up and free the buffer returned by get_user_nonce(). The nonce pointer returned by get_user_nonce() is passed in buf and its length in len.

provider_register_child_cb() registers callbacks for being informed about the loading and unloading of providers in the application’s library context. handle is this provider’s handle and cbdata is this provider’s data that will be passed back to the callbacks. It returns 1 on success or 0 otherwise. These callbacks may be called while holding locks in libcrypto. In order to avoid deadlocks the callback implementation must not be long running and must not call other OpenSSL API functions or upcalls.

create_cb is a callback that will be called when a new provider is loaded into the application’s library context. It is also called for any providers that are already loaded at the point that this callback is registered. The callback is passed the handle being used for the new provider being loadded and this provider’s data in cbdata. It should return 1 on success or 0 on failure.

remove_cb is a callback that will be called when a new provider is unloaded from the application’s library context. It is passed the handle being used for the provider being unloaded and this provider’s data in cbdata. It should return 1 on success or 0 on failure.

global_props_cb is a callback that will be called when the global properties from the parent library context are changed. It should return 1 on success or 0 on failure.

provider_deregister_child_cb() unregisters callbacks previously registered via provider_register_child_cb(). If provider_register_child_cb() has been called then provider_deregister_child_cb() should be called at or before the point that this provider’s teardown function is called.

provider_name() returns a string giving the name of the provider identified by handle.

provider_get0_provider_ctx() returns the provider context that is associated with the provider identified by prov.

provider_get0_dispatch() gets the dispatch table registered by the provider identified by prov when it initialised.

provider_up_ref() increments the reference count on the provider prov. If activate is nonzero then the provider is also loaded if it is not already loaded. It returns 1 on success or 0 on failure.

provider_free() decrements the reference count on the provider prov. If deactivate is nonzero then the provider is also unloaded if it is not already loaded. It returns 1 on success or 0 on failure.

Provider functions

provider_teardown() is called when a provider is shut down and removed from the core’s provider store. It must free the passed provctx.

provider_gettable_params() should return a constant array of descriptor OSSL_PARAM (3), for parameters that provider_get_params() can handle.

provider_get_params() should process the OSSL_PARAM (3) array params, setting the values of the parameters it understands.

provider_query_operation() should return a constant OSSL_ALGORITHM (3) that corresponds to the given operation_id. It should indicate if the core may store a reference to this array by setting *no_store to 0 (core may store a reference) or 1 (core may not store a reference).

provider_unquery_operation() informs the provider that the result of a provider_query_operation() is no longer directly required and that the function pointers have been copied. The operation_id should match that passed to provider_query_operation() and algs should be its return value.

provider_get_reason_strings() should return a constant OSSL_ITEM (3) array that provides reason strings for reason codes the provider may use when reporting errors using core_put_error().

The provider_get_capabilities() function should call the callback cb passing it a set of OSSL_PARAM (3)s and the caller supplied argument arg. The OSSL_PARAM (3)s should provide details about the capability with the name given in the capability argument relevant for the provider context provctx. If a provider supports multiple capabilities with the given name then it may call the callback multiple times (one for each capability). Capabilities can be useful for describing the services that a provider can offer. For further details see the “CAPABILITIES” section below. It should return 1 on success or 0 on error.

The provider_self_test() function should perform known answer tests on a subset of the algorithms that it uses, and may also verify the integrity of the provider module. It should return 1 on success or 0 on error. It will return 1 if this function is not used.

None of these functions are mandatory, but a provider is fairly useless without at least provider_query_operation(), and provider_gettable_params() is fairly useless if not accompanied by provider_get_params().

Provider parameters

provider_get_params() can return the following provider parameters to the core:

“name” (OSSL_PROV_PARAM_NAME) <UTF8 ptr>
This points to a string that should give a unique name for the provider.

“version” (OSSL_PROV_PARAM_VERSION) <UTF8 ptr>
This points to a string that is a version number associated with this provider. OpenSSL in-built providers use OPENSSL_VERSION_STR, but this may be different for any third party provider. This string is for informational purposes only.

“buildinfo” (OSSL_PROV_PARAM_BUILDINFO) <UTF8 ptr>
This points to a string that is a build information associated with this provider. OpenSSL in-built providers use OPENSSL_FULL_VERSION_STR, but this may be different for any third party provider.

“status” (OSSL_PROV_PARAM_STATUS) <unsigned integer>
This returns 0 if the provider has entered an error state, otherwise it returns 1.

provider_gettable_params() should return the above parameters.

Core parameters

core_get_params() can retrieve the following core parameters for each provider:

“openssl-version” (OSSL_PROV_PARAM_CORE_VERSION) <UTF8 string ptr>
This points to the OpenSSL libraries’ full version string, i.e. the string expanded from the macro OPENSSL_VERSION_STR.

“provider-name” (OSSL_PROV_PARAM_CORE_PROV_NAME) <UTF8 string ptr>
This points to the OpenSSL libraries’ idea of what the calling provider is named.

“module-filename” (OSSL_PROV_PARAM_CORE_MODULE_FILENAME) <UTF8 string ptr>
This points to a string containing the full filename of the providers module file.

Additionally, provider specific configuration parameters from the config file are available, in dotted name form. The dotted name form is a concatenation of section names and final config command name separated by periods.

For example, let’s say we have the following config example:

config_diagnostics = 1 openssl_conf = openssl_init [openssl_init] providers = providers_sect [providers_sect] foo = foo_sect [foo_sect] activate = 1 data1 = 2 data2 = str more = foo_more [foo_more] data3 = foo,bar

The provider will have these additional parameters available:

“activate”
pointing at the string “1”

“data1”
pointing at the string “2”

“data2”
pointing at the string “str”

“more.data3”
pointing at the string “foo,bar”

For more information on handling parameters, see OSSL_PARAM (3) as OSSL_PARAM_int (3).

CAPABILITIES

Capabilities describe some of the services that a provider can offer. Applications can query the capabilities to discover those services.

“TLS-GROUP” Capability

The “TLS-GROUP” capability can be queried by libssl to discover the list of TLS groups that a provider can support. Each group supported can be used for key exchange (KEX) or key encapsulation method (KEM) during a TLS handshake. TLS clients can advertise the list of TLS groups they support in the supported_groups extension, and TLS servers can select a group from the offered list that they also support. In this way a provider can add to the list of groups that libssl already supports with additional ones.

Each TLS group that a provider supports should be described via the callback passed in through the provider_get_capabilities function. Each group should have the following details supplied (all are mandatory, except OSSL_CAPABILITY_TLS_GROUP_IS_KEM):

“tls-group-name” (OSSL_CAPABILITY_TLS_GROUP_NAME) <UTF8 string>
The name of the group as given in the IANA TLS Supported Groups registry <https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8>.

“tls-group-name-internal” (OSSL_CAPABILITY_TLS_GROUP_NAME_INTERNAL) <UTF8 string>
The name of the group as known by the provider. This could be the same as the “tls-group-name”, but does not have to be.

“tls-group-id” (OSSL_CAPABILITY_TLS_GROUP_ID) <unsigned integer>
The TLS group id value as given in the IANA TLS Supported Groups registry.

“tls-group-alg” (OSSL_CAPABILITY_TLS_GROUP_ALG) <UTF8 string>
The name of a Key Management algorithm that the provider offers and that should be used with this group. Keys created should be able to support key exchange or key encapsulation method (KEM), as implied by the optional OSSL_CAPABILITY_TLS_GROUP_IS_KEM flag. The algorithm must support key and parameter generation as well as the key/parameter generation parameter, OSSL_PKEY_PARAM_GROUP_NAME. The group name given via “tls-group-name-internal” above will be passed via OSSL_PKEY_PARAM_GROUP_NAME when libssl wishes to generate keys/parameters.

“tls-group-sec-bits” (OSSL_CAPABILITY_TLS_GROUP_SECURITY_BITS) <unsigned integer>
The number of bits of security offered by keys in this group. The number of bits should be comparable with the ones given in table 2 and 3 of the NIST SP800-57 document.

“tls-group-is-kem” (OSSL_CAPABILITY_TLS_GROUP_IS_KEM) <unsigned integer>
Boolean flag to describe if the group should be used in key exchange (KEX) mode (0, default) or in key encapsulation method (KEM) mode (1). This parameter is optional: if not specified, KEX mode is assumed as the default mode for the group. In KEX mode, in a typical Diffie-Hellman fashion, both sides execute keygen then derive against the peer public key. To operate in KEX mode, the group implementation must support the provider functions as described in provider-keyexch (7). In KEM mode, the client executes keygen and sends its public key, the server executes encapsulate using the client’s public key and sends back the resulting ciphertext, finally the client executes decapsulate to retrieve the same shared secret generated by the server’s encapsulate. To operate in KEM mode, the group implementation must support the provider functions as described in provider-kem (7). Both in KEX and KEM mode, the resulting shared secret is then used according to the protocol specification.

“tls-min-tls” (OSSL_CAPABILITY_TLS_GROUP_MIN_TLS) <integer>

“tls-max-tls” (OSSL_CAPABILITY_TLS_GROUP_MAX_TLS) <integer>

“tls-min-dtls” (OSSL_CAPABILITY_TLS_GROUP_MIN_DTLS) <integer>

“tls-max-dtls” (OSSL_CAPABILITY_TLS_GROUP_MAX_DTLS) <integer>

These parameters can be used to describe the minimum and maximum TLS and DTLS versions supported by the group. The values equate to the on-the-wire encoding of the various TLS versions. For example TLSv1.3 is 0x0304 (772 decimal), and TLSv1.2 is 0x0303 (771 decimal). A 0 indicates that there is no defined minimum or maximum. A -1 indicates that the group should not be used in that protocol.

“TLS-SIGALG” Capability

The “TLS-SIGALG” capability can be queried by libssl to discover the list of TLS signature algorithms that a provider can support. Each signature supported can be used for client- or server-authentication in addition to the built-in signature algorithms. TLS1.3 clients can advertise the list of TLS signature algorithms they support in the signature_algorithms extension, and TLS servers can select an algorithm from the offered list that they also support. In this way a provider can add to the list of signature algorithms that libssl already supports with additional ones.

Each TLS signature algorithm that a provider supports should be described via the callback passed in through the provider_get_capabilities function. Each algorithm can have the following details supplied:

“iana-name” (OSSL_CAPABILITY_TLS_SIGALG_IANA_NAME) <UTF8 string>
The name of the signature algorithm as given in the IANA TLS Signature Scheme registry as “Description”: <https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-signaturescheme>. This value must be supplied.

“iana-code-point” (OSSL_CAPABILITY_TLS_SIGALG_CODE_POINT) <unsigned integer>
The TLS algorithm ID value as given in the IANA TLS SignatureScheme registry. This value must be supplied.

“sigalg-name” (OSSL_CAPABILITY_TLS_SIGALG_NAME) <UTF8 string>
A name for the full (possibly composite hash-and-signature) signature algorithm. The provider may, but is not obligated to, provide a signature implementation with this name; if it doesn’t, this is assumed to be a composite of a pure signature algorithm and a hash algorithm, which must be given with the parameters “sig-name” and “hash-name”. This value must be supplied.

“sigalg-oid” (OSSL_CAPABILITY_TLS_SIGALG_OID) <UTF8 string>
The OID of the “sigalg-name” algorithm in canonical numeric text form. If this parameter is given, OBJ_create() will be used to create an OBJ and a NID for this OID, using the “sigalg-name” parameter for its (short) name. Otherwise, it’s assumed to already exist in the object database, possibly done by the provider with the core_obj_create() upcall. This value is optional.

“sig-name” (OSSL_CAPABILITY_TLS_SIGALG_SIG_NAME) <UTF8 string>
The name of the pure signature algorithm that is part of a composite “sigalg-name”. If “sigalg-name” is implemented by the provider, this parameter is redundant and must not be given. This value is optional.

“sig-oid” (OSSL_CAPABILITY_TLS_SIGALG_SIG_OID) <UTF8 string>
The OID of the “sig-name” algorithm in canonical numeric text form. If this parameter is given, OBJ_create() will be used to create an OBJ and a NID for this OID, using the “sig-name” parameter for its (short) name. Otherwise, it is assumed to already exist in the object database. This can be done by the provider using the core_obj_create() upcall. This value is optional.

“hash-name” (OSSL_CAPABILITY_TLS_SIGALG_HASH_NAME) <UTF8 string>
The name of the hash algorithm that is part of a composite “sigalg-name”. If “sigalg-name” is implemented by the provider, this parameter is redundant and must not be given. This value is optional.

“hash-oid” (OSSL_CAPABILITY_TLS_SIGALG_HASH_OID) <UTF8 string>
The OID of the “hash-name” algorithm in canonical numeric text form. If this parameter is given, OBJ_create() will be used to create an OBJ and a NID for this OID, using the “hash-name” parameter for its (short) name. Otherwise, it’s assumed to already exist in the object database, possibly done by the provider with the core_obj_create() upcall. This value is optional.

“key-type” (OSSL_CAPABILITY_TLS_SIGALG_KEYTYPE) <UTF8 string>
The key type of the public key of applicable certificates. If this parameter isn’t present, it’s assumed to be the same as “sig-name” if that’s present, otherwise “sigalg-name”. This value is optional.

“key-type-oid” (OSSL_CAPABILITY_TLS_SIGALG_KEYTYPE_OID) <UTF8 string>
The OID of the “key-type” in canonical numeric text form. If this parameter is given, OBJ_create() will be used to create an OBJ and a NID for this OID, using the “key-type” parameter for its (short) name. Otherwise, it’s assumed to already exist in the object database, possibly done by the provider with the core_obj_create() upcall. This value is optional.

“sec-bits” (OSSL_CAPABILITY_TLS_SIGALG_SECURITY_BITS) <unsigned integer>
The number of bits of security offered by keys of this algorithm. The number of bits should be comparable with the ones given in table 2 and 3 of the NIST SP800-57 document. This number is used to determine the security strength of the algorithm if no digest algorithm has been registered that otherwise defines the security strength. If the signature algorithm implements its own digest internally, this value needs to be set to properly reflect the overall security strength. This value must be supplied.

“tls-min-tls” (OSSL_CAPABILITY_TLS_SIGALG_MIN_TLS) <integer>

“tls-max-tls” (OSSL_CAPABILITY_TLS_SIGALG_MAX_TLS) <integer>

These parameters can be used to describe the minimum and maximum TLS versions supported by the signature algorithm. The values equate to the on-the-wire encoding of the various TLS versions. For example TLSv1.3 is 0x0304 (772 decimal), and TLSv1.2 is 0x0303 (771 decimal). A 0 indicates that there is no defined minimum or maximum. A -1 indicates that the signature algorithm should not be used in that protocol. Presently values representing anything other than TLS1.3 mean that the complete algorithm is ignored.

NOTES

The core_obj_create() and core_obj_add_sigid() functions were not thread safe in OpenSSL 3.0.

EXAMPLES

This is an example of a simple provider made available as a dynamically loadable module. It implements the fictitious algorithm FOO for the fictitious operation BAR.

#include <malloc.h> #include <openssl/core.h> #include <openssl/core_dispatch.h> /* Errors used in this provider */ #define E_MALLOC 1 static const OSSL_ITEM reasons[] = { { E_MALLOC, “memory allocation failure” }. OSSL_DISPATCH_END }; /* * To ensure we get the function signature right, forward declare * them using function types provided by openssl/core_dispatch.h */ OSSL_FUNC_bar_newctx_fn foo_newctx; OSSL_FUNC_bar_freectx_fn foo_freectx; OSSL_FUNC_bar_init_fn foo_init; OSSL_FUNC_bar_update_fn foo_update; OSSL_FUNC_bar_final_fn foo_final; OSSL_FUNC_provider_query_operation_fn p_query; OSSL_FUNC_provider_get_reason_strings_fn p_reasons; OSSL_FUNC_provider_teardown_fn p_teardown; OSSL_provider_init_fn OSSL_provider_init; OSSL_FUNC_core_put_error *c_put_error = NULL; /* Provider context */ struct prov_ctx_st { OSSL_CORE_HANDLE *handle; } /* operation context for the algorithm FOO */ struct foo_ctx_st { struct prov_ctx_st *provctx; int b; }; static void *foo_newctx(void *provctx) { struct foo_ctx_st *fooctx = malloc(sizeof(*fooctx)); if (fooctx != NULL) fooctx->provctx = provctx; else c_put_error(provctx->handle, E_MALLOC, _ _FILE_ _, _ _LINE_ _); return fooctx; } static void foo_freectx(void *fooctx) { free(fooctx); } static int foo_init(void *vfooctx) { struct foo_ctx_st *fooctx = vfooctx; fooctx->b = 0x33; } static int foo_update(void *vfooctx, unsigned char *in, size_t inl) { struct foo_ctx_st *fooctx = vfooctx; /* did you expect something serious? */ if (inl == 0) return 1; for (; inl– > 0; in++) *in ^= fooctx->b; return 1; } static int foo_final(void *vfooctx) { struct foo_ctx_st *fooctx = vfooctx; fooctx->b = 0x66; } static const OSSL_DISPATCH foo_fns[] = { { OSSL_FUNC_BAR_NEWCTX, (void (*)(void))foo_newctx }, { OSSL_FUNC_BAR_FREECTX, (void (*)(void))foo_freectx }, { OSSL_FUNC_BAR_INIT, (void (*)(void))foo_init }, { OSSL_FUNC_BAR_UPDATE, (void (*)(void))foo_update }, { OSSL_FUNC_BAR_FINAL, (void (*)(void))foo_final }, OSSL_DISPATCH_END }; static const OSSL_ALGORITHM bars[] = { { “FOO”, “provider=chumbawamba”, foo_fns }, { NULL, NULL, NULL } }; static const OSSL_ALGORITHM *p_query(void *provctx, int operation_id, int *no_store) { switch (operation_id) { case OSSL_OP_BAR: return bars; } return NULL; } static const OSSL_ITEM *p_reasons(void *provctx) { return reasons; } static void p_teardown(void *provctx) { free(provctx); } static const OSSL_DISPATCH prov_fns[] = { { OSSL_FUNC_PROVIDER_TEARDOWN, (void (*)(void))p_teardown }, { OSSL_FUNC_PROVIDER_QUERY_OPERATION, (void (*)(void))p_query }, { OSSL_FUNC_PROVIDER_GET_REASON_STRINGS, (void (*)(void))p_reasons }, OSSL_DISPATCH_END }; int OSSL_provider_init(const OSSL_CORE_HANDLE *handle, const OSSL_DISPATCH *in, const OSSL_DISPATCH **out, void **provctx) { struct prov_ctx_st *pctx = NULL; for (; in->function_id != 0; in++) switch (in->function_id) { case OSSL_FUNC_CORE_PUT_ERROR: c_put_error = OSSL_FUNC_core_put_error(in); break; } *out = prov_fns; if ((pctx = malloc(sizeof(*pctx))) == NULL) { /* * ALEA IACTA EST, if the core retrieves the reason table * regardless, that string will be displayed, otherwise not. */ c_put_error(handle, E_MALLOC, _ _FILE_ _, _ _LINE_ _); return 0; } pctx->handle = handle; return 1; }

This relies on a few things existing in openssl/core_dispatch.h:

#define OSSL_OP_BAR 4711 #define OSSL_FUNC_BAR_NEWCTX 1 typedef void *(OSSL_FUNC_bar_newctx_fn)(void *provctx); static ossl_inline OSSL_FUNC_bar_newctx(const OSSL_DISPATCH *opf) { return (OSSL_FUNC_bar_newctx_fn *)opf->function; } #define OSSL_FUNC_BAR_FREECTX 2 typedef void (OSSL_FUNC_bar_freectx_fn)(void *ctx); static ossl_inline OSSL_FUNC_bar_freectx(const OSSL_DISPATCH *opf) { return (OSSL_FUNC_bar_freectx_fn *)opf->function; } #define OSSL_FUNC_BAR_INIT 3 typedef void *(OSSL_FUNC_bar_init_fn)(void *ctx); static ossl_inline OSSL_FUNC_bar_init(const OSSL_DISPATCH *opf) { return (OSSL_FUNC_bar_init_fn *)opf->function; } #define OSSL_FUNC_BAR_UPDATE 4 typedef void *(OSSL_FUNC_bar_update_fn)(void *ctx, unsigned char *in, size_t inl); static ossl_inline OSSL_FUNC_bar_update(const OSSL_DISPATCH *opf) { return (OSSL_FUNC_bar_update_fn *)opf->function; } #define OSSL_FUNC_BAR_FINAL 5 typedef void *(OSSL_FUNC_bar_final_fn)(void *ctx); static ossl_inline OSSL_FUNC_bar_final(const OSSL_DISPATCH *opf) { return (OSSL_FUNC_bar_final_fn *)opf->function; }

SEE ALSO

provider (7)

HISTORY

The concept of providers and everything surrounding them was introduced in OpenSSL 3.0.

COPYRIGHT

Copyright 2019-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

535 - Linux cli command iso_8859-11

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso_8859-11 and provides detailed information about the command iso_8859-11, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso_8859-11.

NAME 🖥️ iso_8859-11 🖥️

11 - ISO/IEC 8859-11 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-11 encodes the characters used in the Thai language.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-11 characters

The following table displays the characters in ISO/IEC 8859-11 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-11 is the same as TIS (Thai Industrial Standard) 620-2253, commonly known as TIS-620, except for the character in position A0: ISO/IEC 8859-11 defines this as NO-BREAK SPACE, while TIS-620 leaves it undefined.

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

536 - Linux cli command ossl-guide-tls-client-blockssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ossl-guide-tls-client-blockssl and provides detailed information about the command ossl-guide-tls-client-blockssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ossl-guide-tls-client-blockssl.

NAME 🖥️ ossl-guide-tls-client-blockssl 🖥️

guide-tls-client-block - OpenSSL Guide: Writing a simple blocking TLS client

SIMPLE BLOCKING TLS CLIENT EXAMPLE

This page will present various source code samples demonstrating how to write a simple TLS client application which connects to a server, sends an HTTP/1.0 request to it, and reads back the response.

We use a blocking socket for the purposes of this example. This means that attempting to read data from a socket that has no data available on it to read will block (and the function will not return), until data becomes available. For example, this can happen if we have sent our request, but we are still waiting for the server’s response. Similarly any attempts to write to a socket that is not able to write at the moment will block until writing is possible.

This blocking behaviour simplifies the implementation of a client because you do not have to worry about what happens if data is not yet available. The application will simply wait until it is available.

The complete source code for this example blocking TLS client is available in the demos/guide directory of the OpenSSL source distribution in the file tls-client-block.c. It is also available online at <https://github.com/openssl/openssl/blob/master/demos/guide/tls-client-block.c>.

We assume that you already have OpenSSL installed on your system; that you already have some fundamental understanding of OpenSSL concepts and TLS (see ossl-guide-libraries-introduction (7) and ossl-guide-tls-introduction (7)); and that you know how to write and build C code and link it against the libcrypto and libssl libraries that are provided by OpenSSL. It also assumes that you have a basic understanding of TCP/IP and sockets.

Creating the SSL_CTX and SSL objects

The first step is to create an SSL_CTX object for our client. We use the SSL_CTX_new (3) function for this purpose. We could alternatively use SSL_CTX_new_ex (3) if we want to associate the SSL_CTX with a particular OSSL_LIB_CTX (see ossl-guide-libraries-introduction (7) to learn about OSSL_LIB_CTX). We pass as an argument the return value of the function TLS_client_method (3). You should use this method whenever you are writing a TLS client. This method will automatically use TLS version negotiation to select the highest version of the protocol that is mutually supported by both the client and the server.

/* * Create an SSL_CTX which we can use to create SSL objects from. We * want an SSL_CTX for creating clients so we use TLS_client_method() * here. */ ctx = SSL_CTX_new(TLS_client_method()); if (ctx == NULL) { printf(“Failed to create the SSL_CTX “); goto end; }

Since we are writing a client we must ensure that we verify the server’s certificate. We do this by calling the SSL_CTX_set_verify (3) function and pass the SSL_VERIFY_PEER value to it. The final argument to this function is a callback that you can optionally supply to override the default handling for certificate verification. Most applications do not need to do this so this can safely be set to NULL to get the default handling.

/* * Configure the client to abort the handshake if certificate * verification fails. Virtually all clients should do this unless you * really know what you are doing. */ SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, NULL);

In order for certificate verification to be successful you must have configured where the trusted certificate store to be used is located (see ossl-guide-tls-introduction (7)). In most cases you just want to use the default store so we call SSL_CTX_set_default_verify_paths (3).

/* Use the default trusted certificate store */ if (!SSL_CTX_set_default_verify_paths(ctx)) { printf(“Failed to set the default trusted certificate store “); goto end; }

We would also like to restrict the TLS versions that we are willing to accept to TLSv1.2 or above. TLS protocol versions earlier than that are generally to be avoided where possible. We can do that using SSL_CTX_set_min_proto_version (3):

/* * TLSv1.1 or earlier are deprecated by IETF and are generally to be * avoided if possible. We require a minimum TLS version of TLSv1.2. */ if (!SSL_CTX_set_min_proto_version(ctx, TLS1_2_VERSION)) { printf(“Failed to set the minimum TLS protocol version “); goto end; }

That is all the setup that we need to do for the SSL_CTX, so next we need to create an SSL object to represent the TLS connection. In a real application we might expect to be creating more than one TLS connection over time. In that case we would expect to reuse the SSL_CTX that we already created each time. There is no need to repeat those steps. In fact it is best not to since certain internal resources are cached in the SSL_CTX. You will get better performance by reusing an existing SSL_CTX instead of creating a new one each time.

Creating the SSL object is a simple matter of calling the SSL_new (3) function and passing the SSL_CTX we created as an argument.

/* Create an SSL object to represent the TLS connection */ ssl = SSL_new(ctx); if (ssl == NULL) { printf(“Failed to create the SSL object “); goto end; }

Creating the socket and BIO

TLS data is transmitted over an underlying transport layer. Normally a TCP socket. It is the application’s responsibility for ensuring that the socket is created and associated with an SSL object (via a BIO).

Socket creation for use by a client is typically a 2 step process, i.e. constructing the socket; and connecting the socket.

How to construct a socket is platform specific - but most platforms (including Windows) provide a POSIX compatible interface via the socket function, e.g. to create an IPv4 TCP socket:

int sock; sock = socket(AF_INET, SOCK_STREAM, 0); if (sock == -1) return NULL;

Once the socket is constructed it must be connected to the remote server. Again the details are platform specific but most platforms (including Windows) provide the POSIX compatible connect function. For example:

struct sockaddr_in serveraddr; struct hostent *server; server = gethostbyname(“www.openssl.org”); if (server == NULL) { close(sock); return NULL; } memset(&serveraddr, 0, sizeof(serveraddr)); serveraddr.sin_family = server->h_addrtype; serveraddr.sin_port = htons(443); memcpy(&serveraddr.sin_addr.s_addr, server->h_addr, server->h_length); if (connect(sock, (struct sockaddr *)&serveraddr, sizeof(serveraddr)) == -1) { close(sock); return NULL; }

OpenSSL provides portable helper functions to do these tasks which also integrate into the OpenSSL error system to log error data, e.g.

int sock = -1; BIO_ADDRINFO *res; const BIO_ADDRINFO *ai = NULL; /* * Lookup IP address info for the server. */ if (!BIO_lookup_ex(hostname, port, BIO_LOOKUP_CLIENT, family, SOCK_STREAM, 0, &res)) return NULL; /* * Loop through all the possible addresses for the server and find one * we can connect to. */ for (ai = res; ai != NULL; ai = BIO_ADDRINFO_next(ai)) { /* * Create a TCP socket. We could equally use non-OpenSSL calls such * as “socket” here for this and the subsequent connect and close * functions. But for portability reasons and also so that we get * errors on the OpenSSL stack in the event of a failure we use * OpenSSLs versions of these functions. */ sock = BIO_socket(BIO_ADDRINFO_family(ai), SOCK_STREAM, 0, 0); if (sock == -1) continue; /* Connect the socket to the servers address */ if (!BIO_connect(sock, BIO_ADDRINFO_address(ai), BIO_SOCK_NODELAY)) { BIO_closesocket(sock); sock = -1; continue; } /* We have a connected socket so break out of the loop */ break; } /* Free the address information resources we allocated earlier */ BIO_ADDRINFO_free(res);

See BIO_lookup_ex (3), BIO_socket (3), BIO_connect (3), BIO_closesocket (3), BIO_ADDRINFO_next (3), BIO_ADDRINFO_address (3) and BIO_ADDRINFO_free (3) for further information on the functions used here. In the above example code the hostname and port variables are strings, e.g. “www.example.com” and “443”. Note also the use of the family variable, which can take the values of AF_INET or AF_INET6 based on the command line -6 option, to allow specific connections to an ipv4 or ipv6 enabled host.

Sockets created using the methods described above will automatically be blocking sockets - which is exactly what we want for this example.

Once the socket has been created and connected we need to associate it with a BIO object:

BIO *bio; /* Create a BIO to wrap the socket */ bio = BIO_new(BIO_s_socket()); if (bio == NULL) { BIO_closesocket(sock); return NULL; } /* * Associate the newly created BIO with the underlying socket. By * passing BIO_CLOSE here the socket will be automatically closed when * the BIO is freed. Alternatively you can use BIO_NOCLOSE, in which * case you must close the socket explicitly when it is no longer * needed. */ BIO_set_fd(bio, sock, BIO_CLOSE);

See BIO_new (3), BIO_s_socket (3) and BIO_set_fd (3) for further information on these functions.

Finally we associate the SSL object we created earlier with the BIO using the SSL_set_bio (3) function. Note that this passes ownership of the BIO object to the SSL object. Once ownership is passed the SSL object is responsible for its management and will free it automatically when the SSL is freed. So, once SSL_set_bio (3) has been been called, you should not call BIO_free (3) on the BIO.

SSL_set_bio(ssl, bio, bio);

Setting the server’s hostname

We have already connected our underlying socket to the server, but the client still needs to know the server’s hostname. It uses this information for 2 key purposes and we need to set the hostname for each one.

Firstly, the server’s hostname is included in the initial ClientHello message sent by the client. This is known as the Server Name Indication (SNI). This is important because it is common for multiple hostnames to be fronted by a single server that handles requests for all of them. In other words a single server may have multiple hostnames associated with it and it is important to indicate which one we want to connect to. Without this information we may get a handshake failure, or we may get connected to the “default” server which may not be the one we were expecting.

To set the SNI hostname data we call the SSL_set_tlsext_host_name (3) function like this:

/* * Tell the server during the handshake which hostname we are attempting * to connect to in case the server supports multiple hosts. */ if (!SSL_set_tlsext_host_name(ssl, hostname)) { printf(“Failed to set the SNI hostname “); goto end; }

Here the hostname argument is a string representing the hostname of the server, e.g. “www.example.com”.

Secondly, we need to tell OpenSSL what hostname we expect to see in the certificate coming back from the server. This is almost always the same one that we asked for in the original request. This is important because, without this, we do not verify that the hostname in the certificate is what we expect it to be and any certificate is acceptable unless your application explicitly checks this itself. We do this via the SSL_set1_host (3) function:

/* * Ensure we check during certificate verification that the server has * supplied a certificate for the hostname that we were expecting. * Virtually all clients should do this unless you really know what you * are doing. */ if (!SSL_set1_host(ssl, hostname)) { printf(“Failed to set the certificate verification hostname”); goto end; }

All of the above steps must happen before we attempt to perform the handshake otherwise they will have no effect.

Performing the handshake

Before we can start sending or receiving application data over a TLS connection the TLS handshake must be performed. We can do this explicitly via the SSL_connect (3) function.

/* Do the handshake with the server */ if (SSL_connect(ssl) < 1) { printf(“Failed to connect to the server “); /* * If the failure is due to a verification error we can get more * information about it from SSL_get_verify_result(). */ if (SSL_get_verify_result(ssl) != X509_V_OK) printf(“Verify error: %s “, X509_verify_cert_error_string(SSL_get_verify_result(ssl))); goto end; }

The SSL_connect (3) function can return 1, 0 or less than 0. Only a return value of 1 is considered a success. For a simple blocking client we only need to concern ourselves with whether the call was successful or not. Anything else indicates that we have failed to connect to the server.

A common cause of failures at this stage is due to a problem verifying the server’s certificate. For example if the certificate has expired, or it is not signed by a CA in our trusted certificate store. We can use the SSL_get_verify_result (3) function to find out more information about the verification failure. A return value of X509_V_OK indicates that the verification was successful (so the connection error must be due to some other cause). Otherwise we use the X509_verify_cert_error_string (3) function to get a human readable error message.

Sending and receiving data

Once the handshake is complete we are able to send and receive application data. Exactly what data is sent and in what order is usually controlled by some application level protocol. In this example we are using HTTP 1.0 which is a very simple request and response protocol. The client sends a request to the server. The server sends the response data and then immediately closes down the connection.

To send data to the server we use the SSL_write_ex (3) function and to receive data from the server we use the SSL_read_ex (3) function. In HTTP 1.0 the client always writes data first. Our HTTP request will include the hostname that we are connecting to. For simplicity, we write the HTTP request in three chunks. First we write the start of the request. Secondly we write the hostname we are sending the request to. Finally we send the end of the request.

size_t written; const char *request_start = “GET / HTTP/1.0 Connection: close Host: “; const char *request_end = "

“; /* Write an HTTP GET request to the peer */ if (!SSL_write_ex(ssl, request_start, strlen(request_start), &written)) { printf(“Failed to write start of HTTP request “); goto end; } if (!SSL_write_ex(ssl, hostname, strlen(hostname), &written)) { printf(“Failed to write hostname in HTTP request “); goto end; } if (!SSL_write_ex(ssl, request_end, strlen(request_end), &written)) { printf(“Failed to write end of HTTP request “); goto end; }

The SSL_write_ex (3) function returns 0 if it fails and 1 if it is successful. If it is successful then we can proceed to waiting for a response from the server.

size_t readbytes; char buf[160]; /* * Get up to sizeof(buf) bytes of the response. We keep reading until the * server closes the connection. */ while (SSL_read_ex(ssl, buf, sizeof(buf), &readbytes)) { /* * OpenSSL does not guarantee that the returned data is a string or * that it is NUL terminated so we use fwrite() to write the exact * number of bytes that we read. The data could be non-printable or * have NUL characters in the middle of it. For this simple example * were going to print it to stdout anyway. */ fwrite(buf, 1, readbytes, stdout); } /* In case the response didnt finish with a newline we add one now */ printf(” “);

We use the SSL_read_ex (3) function to read the response. We don’t know exactly how much data we are going to receive back so we enter a loop reading blocks of data from the server and printing each block that we receive to the screen. The loop ends as soon as SSL_read_ex (3) returns 0 - meaning that it failed to read any data.

A failure to read data could mean that there has been some error, or it could simply mean that server has sent all the data that it wants to send and has indicated that it has finished by sending a “close_notify” alert. This alert is a TLS protocol level message indicating that the endpoint has finished sending all of its data and it will not send any more. Both of these conditions result in a 0 return value from SSL_read_ex (3) and we need to use the function SSL_get_error (3) to determine the cause of the 0 return value.

/* * Check whether we finished the while loop above normally or as the * result of an error. The 0 argument to SSL_get_error() is the return * code we received from the SSL_read_ex() call. It must be 0 in order * to get here. Normal completion is indicated by SSL_ERROR_ZERO_RETURN. */ if (SSL_get_error(ssl, 0) != SSL_ERROR_ZERO_RETURN) { /* * Some error occurred other than a graceful close down by the * peer */ printf (“Failed reading remaining data “); goto end; }

If SSL_get_error (3) returns SSL_ERROR_ZERO_RETURN then we know that the server has finished sending its data. Otherwise an error has occurred.

Shutting down the connection

Once we have finished reading data from the server then we are ready to close the connection down. We do this via the SSL_shutdown (3) function which has the effect of sending a TLS protocol level message (a “close_notify” alert) to the server saying that we have finished writing data:

/* * The peer already shutdown gracefully (we know this because of the * SSL_ERROR_ZERO_RETURN above). We should do the same back. */ ret = SSL_shutdown(ssl); if (ret < 1) { /* * ret < 0 indicates an error. ret == 0 would be unexpected here * because that means “weve sent a close_notify and were waiting * for one back”. But we already know we got one from the peer * because of the SSL_ERROR_ZERO_RETURN above. */ printf(“Error shutting down “); goto end; }

The SSL_shutdown (3) function will either return 1, 0, or less than 0. A return value of 1 is a success, and a return value less than 0 is an error. More precisely a return value of 1 means that we have sent a “close_notify” alert to the server, and that we have also received one back. A return value of 0 means that we have sent a “close_notify” alert to the server, but we have not yet received one back. Usually in this scenario you would call SSL_shutdown (3) again which (with a blocking socket) would block until the “close_notify” is received. However in this case we already know that the server has sent us a “close_notify” because of the SSL_ERROR_ZERO_RETURN that we received from the call to SSL_read_ex (3). So this scenario should never happen in practice. We just treat it as an error in this example.

Final clean up

Before the application exits we have to clean up some memory that we allocated. If we are exiting due to an error we might also want to display further information about that error if it is available to the user:

/* Success! */ res = EXIT_SUCCESS; end: /* * If something bad happened then we will dump the contents of the * OpenSSL error stack to stderr. There might be some useful diagnostic * information there. */ if (res == EXIT_FAILURE) ERR_print_errors_fp(stderr); /* * Free the resources we allocated. We do not free the BIO object here * because ownership of it was immediately transferred to the SSL object * via SSL_set_bio(). The BIO will be freed when we free the SSL object. */ SSL_free(ssl); SSL_CTX_free(ctx); return res;

To display errors we make use of the ERR_print_errors_fp (3) function which simply dumps out the contents of any errors on the OpenSSL error stack to the specified location (in this case stderr).

We need to free up the SSL object that we created for the connection via the SSL_free (3) function. Also, since we are not going to be creating any more TLS connections we must also free up the SSL_CTX via a call to SSL_CTX_free (3).

TROUBLESHOOTING

There are a number of things that might go wrong when running the demo application. This section describes some common things you might encounter.

Failure to connect the underlying socket

This could occur for numerous reasons. For example if there is a problem in the network route between the client and the server; or a firewall is blocking the communication; or the server is not in DNS. Check the network configuration.

Verification failure of the server certificate

A verification failure of the server certificate would result in a failure when running the SSL_connect (3) function. ERR_print_errors_fp (3) would display an error which would look something like this:

Verify error: unable to get local issuer certificate 40E74AF1F47F0000:error:0A000086:SSL routines:tls_post_process_server_certificate:certificate verify failed:ssl/statem/statem_clnt.c:2069:

A server certificate verification failure could be caused for a number of reasons. For example

Failure to correctly setup the trusted certificate store
See the page ossl-guide-tls-introduction (7) and check that your trusted certificate store is correctly configured

Unrecognised CA
If the CA used by the server’s certificate is not in the trusted certificate store for the client then this will cause a verification failure during connection. Often this can occur if the server is using a self-signed certificate (i.e. a test certificate that has not been signed by a CA at all).

Missing intermediate CAs
This is a server misconfiguration where the client has the relevant root CA in its trust store, but the server has not supplied all of the intermediate CA certificates between that root CA and the server’s own certificate. Therefore a trust chain cannot be established.

Mismatched hostname
If for some reason the hostname of the server that the client is expecting does not match the hostname in the certificate then this will cause verification to fail.

Expired certificate
The date that the server’s certificate is valid to has passed.

The “unable to get local issuer certificate” we saw in the example above means that we have been unable to find the issuer of the server’s certificate (or one of its intermediate CA certificates) in our trusted certificate store (e.g. because the trusted certificate store is misconfigured, or there are missing intermediate CAs, or the issuer is simply unrecognised).

FURTHER READING

See ossl-guide-tls-client-non-block (7) to read a tutorial on how to modify the client developed on this page to support a nonblocking socket.

See ossl-guide-quic-client-block (7) to read a tutorial on how to modify the client developed on this page to support QUIC instead of TLS.

SEE ALSO

ossl-guide-introduction (7), ossl-guide-libraries-introduction (7), ossl-guide-libssl-introduction (7), ossl-guide-tls-introduction (7), ossl-guide-tls-client-non-block (7), ossl-guide-quic-client-block (7)

COPYRIGHT

Copyright 2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

537 - Linux cli command DROP_AGGREGATE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_AGGREGATE and provides detailed information about the command DROP_AGGREGATE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_AGGREGATE.

NAME 🖥️ DROP_AGGREGATE 🖥️

remove an aggregate function

SYNOPSIS

DROP AGGREGATE [ IF EXISTS ] name ( aggregate_signature ) [, ...] [ CASCADE | RESTRICT ]

where aggregate_signature is:

* |
[ argmode ] [ argname ] argtype [ , ... ] |
[ [ argmode ] [ argname ] argtype [ , ... ] ] ORDER BY [ argmode ] [ argname ] argtype [ , ... ]

DESCRIPTION

DROP AGGREGATE removes an existing aggregate function. To execute this command the current user must be the owner of the aggregate function.

PARAMETERS

IF EXISTS

Do not throw an error if the aggregate does not exist. A notice is issued in this case.

name

The name (optionally schema-qualified) of an existing aggregate function.

argmode

The mode of an argument: IN or VARIADIC. If omitted, the default is IN.

argname

The name of an argument. Note that DROP AGGREGATE does not actually pay any attention to argument names, since only the argument data types are needed to determine the aggregate functions identity.

argtype

An input data type on which the aggregate function operates. To reference a zero-argument aggregate function, write * in place of the list of argument specifications. To reference an ordered-set aggregate function, write ORDER BY between the direct and aggregated argument specifications.

CASCADE

Automatically drop objects that depend on the aggregate function (such as views using it), and in turn all objects that depend on those objects (see Section 5.14).

RESTRICT

Refuse to drop the aggregate function if any objects depend on it. This is the default.

NOTES

Alternative syntaxes for referencing ordered-set aggregates are described under ALTER AGGREGATE (ALTER_AGGREGATE(7)).

EXAMPLES

To remove the aggregate function myavg for type integer:

DROP AGGREGATE myavg(integer);

To remove the hypothetical-set aggregate function myrank, which takes an arbitrary list of ordering columns and a matching list of direct arguments:

DROP AGGREGATE myrank(VARIADIC “any” ORDER BY VARIADIC “any”);

To remove multiple aggregate functions in one command:

DROP AGGREGATE myavg(integer), myavg(bigint);

COMPATIBILITY

There is no DROP AGGREGATE statement in the SQL standard.

SEE ALSO

ALTER AGGREGATE (ALTER_AGGREGATE(7)), CREATE AGGREGATE (CREATE_AGGREGATE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

538 - Linux cli command pcap-linktype

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command pcap-linktype and provides detailed information about the command pcap-linktype, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the pcap-linktype.

NAME 🖥️ pcap-linktype 🖥️

linktype - link-layer header types supported by libpcap

DESCRIPTION

For a live capture or ``savefile’’, libpcap supplies, as the return value of the pcap_datalink(3PCAP) routine, a value that indicates the type of link-layer header at the beginning of the packets it provides. This is not necessarily the type of link-layer header that the packets being captured have on the network from which they’re being captured; for example, packets from an IEEE 802.11 network might be provided by libpcap with Ethernet headers that the network adapter or the network adapter driver generates from the 802.11 headers. The names for those values begin with DLT_, so they are sometimes called “DLT_ values”.

The values stored in the link-layer header type field in the savefile header are, in most but not all cases, the same as the values returned by pcap_datalink(). The names for those values begin with LINKTYPE_.

The link-layer header types supported by libpcap are described at https://www.tcpdump.org/linktypes.html .

SEE ALSO

pcap(3PCAP)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

539 - Linux cli command ALTER_DATABASE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_DATABASE and provides detailed information about the command ALTER_DATABASE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_DATABASE.

NAME 🖥️ ALTER_DATABASE 🖥️

change a database

SYNOPSIS

ALTER DATABASE name [ [ WITH ] option [ ... ] ]

where option can be:

    ALLOW_CONNECTIONS allowconn
    CONNECTION LIMIT connlimit
    IS_TEMPLATE istemplate

ALTER DATABASE name RENAME TO new_name

ALTER DATABASE name OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }

ALTER DATABASE name SET TABLESPACE new_tablespace

ALTER DATABASE name REFRESH COLLATION VERSION

ALTER DATABASE name SET configuration_parameter { TO | = } { value | DEFAULT }
ALTER DATABASE name SET configuration_parameter FROM CURRENT
ALTER DATABASE name RESET configuration_parameter
ALTER DATABASE name RESET ALL

DESCRIPTION

ALTER DATABASE changes the attributes of a database.

The first form changes certain per-database settings. (See below for details.) Only the database owner or a superuser can change these settings.

The second form changes the name of the database. Only the database owner or a superuser can rename a database; non-superuser owners must also have the CREATEDB privilege. The current database cannot be renamed. (Connect to a different database if you need to do that.)

The third form changes the owner of the database. To alter the owner, you must be able to SET ROLE to the new owning role, and you must have the CREATEDB privilege. (Note that superusers have all these privileges automatically.)

The fourth form changes the default tablespace of the database. Only the database owner or a superuser can do this; you must also have create privilege for the new tablespace. This command physically moves any tables or indexes in the databases old default tablespace to the new tablespace. The new default tablespace must be empty for this database, and no one can be connected to the database. Tables and indexes in non-default tablespaces are unaffected.

The remaining forms change the session default for a run-time configuration variable for a PostgreSQL database. Whenever a new session is subsequently started in that database, the specified value becomes the session default value. The database-specific default overrides whatever setting is present in postgresql.conf or has been received from the postgres command line. Only the database owner or a superuser can change the session defaults for a database. Certain variables cannot be set this way, or can only be set by a superuser.

PARAMETERS

name

The name of the database whose attributes are to be altered.

allowconn

If false then no one can connect to this database.

connlimit

How many concurrent connections can be made to this database. -1 means no limit.

istemplate

If true, then this database can be cloned by any user with CREATEDB privileges; if false, then only superusers or the owner of the database can clone it.

new_name

The new name of the database.

new_owner

The new owner of the database.

new_tablespace

The new default tablespace of the database.

This form of the command cannot be executed inside a transaction block.

REFRESH COLLATION VERSION

Update the database collation version. See Notes for background.

configuration_parameter
value

Set this databases session default for the specified configuration parameter to the given value. If value is DEFAULT or, equivalently, RESET is used, the database-specific setting is removed, so the system-wide default setting will be inherited in new sessions. Use RESET ALL to clear all database-specific settings. SET FROM CURRENT saves the sessions current value of the parameter as the database-specific value.

See SET(7) and Chapter 20 for more information about allowed parameter names and values.

NOTES

It is also possible to tie a session default to a specific role rather than to a database; see ALTER ROLE (ALTER_ROLE(7)). Role-specific settings override database-specific ones if there is a conflict.

EXAMPLES

To disable index scans by default in the database test:

ALTER DATABASE test SET enable_indexscan TO off;

COMPATIBILITY

The ALTER DATABASE statement is a PostgreSQL extension.

SEE ALSO

CREATE DATABASE (CREATE_DATABASE(7)), DROP DATABASE (DROP_DATABASE(7)), SET(7), CREATE TABLESPACE (CREATE_TABLESPACE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

540 - Linux cli command CREATE_STATISTICS

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_STATISTICS and provides detailed information about the command CREATE_STATISTICS, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_STATISTICS.

NAME 🖥️ CREATE_STATISTICS 🖥️

define extended statistics

SYNOPSIS

CREATE STATISTICS [ [ IF NOT EXISTS ] statistics_name ]
    ON ( expression )
    FROM table_name

CREATE STATISTICS [ [ IF NOT EXISTS ] statistics_name ]
    [ ( statistics_kind [, ... ] ) ]
    ON { column_name | ( expression ) }, { column_name | ( expression ) } [, ...]
    FROM table_name

DESCRIPTION

CREATE STATISTICS will create a new extended statistics object tracking data about the specified table, foreign table or materialized view. The statistics object will be created in the current database and will be owned by the user issuing the command.

The CREATE STATISTICS command has two basic forms. The first form allows univariate statistics for a single expression to be collected, providing benefits similar to an expression index without the overhead of index maintenance. This form does not allow the statistics kind to be specified, since the various statistics kinds refer only to multivariate statistics. The second form of the command allows multivariate statistics on multiple columns and/or expressions to be collected, optionally specifying which statistics kinds to include. This form will also automatically cause univariate statistics to be collected on any expressions included in the list.

If a schema name is given (for example, CREATE STATISTICS myschema.mystat …) then the statistics object is created in the specified schema. Otherwise it is created in the current schema. If given, the name of the statistics object must be distinct from the name of any other statistics object in the same schema.

PARAMETERS

IF NOT EXISTS

Do not throw an error if a statistics object with the same name already exists. A notice is issued in this case. Note that only the name of the statistics object is considered here, not the details of its definition. Statistics name is required when IF NOT EXISTS is specified.

statistics_name

The name (optionally schema-qualified) of the statistics object to be created. If the name is omitted, PostgreSQL chooses a suitable name based on the parent tables name and the defined column name(s) and/or expression(s).

statistics_kind

A multivariate statistics kind to be computed in this statistics object. Currently supported kinds are ndistinct, which enables n-distinct statistics, dependencies, which enables functional dependency statistics, and mcv which enables most-common values lists. If this clause is omitted, all supported statistics kinds are included in the statistics object. Univariate expression statistics are built automatically if the statistics definition includes any complex expressions rather than just simple column references. For more information, see Section 14.2.2 and Section 76.2.

column_name

The name of a table column to be covered by the computed statistics. This is only allowed when building multivariate statistics. At least two column names or expressions must be specified, and their order is not significant.

expression

An expression to be covered by the computed statistics. This may be used to build univariate statistics on a single expression, or as part of a list of multiple column names and/or expressions to build multivariate statistics. In the latter case, separate univariate statistics are built automatically for each expression in the list.

table_name

The name (optionally schema-qualified) of the table containing the column(s) the statistics are computed on; see ANALYZE(7) for an explanation of the handling of inheritance and partitions.

NOTES

You must be the owner of a table to create a statistics object reading it. Once created, however, the ownership of the statistics object is independent of the underlying table(s).

Expression statistics are per-expression and are similar to creating an index on the expression, except that they avoid the overhead of index maintenance. Expression statistics are built automatically for each expression in the statistics object definition.

Extended statistics are not currently used by the planner for selectivity estimations made for table joins. This limitation will likely be removed in a future version of PostgreSQL.

EXAMPLES

Create table t1 with two functionally dependent columns, i.e., knowledge of a value in the first column is sufficient for determining the value in the other column. Then functional dependency statistics are built on those columns:

CREATE TABLE t1 ( a int, b int );

INSERT INTO t1 SELECT i/100, i/500
                 FROM generate_series(1,1000000) s(i);

ANALYZE t1;

-- the number of matching rows will be drastically underestimated:
EXPLAIN ANALYZE SELECT * FROM t1 WHERE (a = 1) AND (b = 0);

CREATE STATISTICS s1 (dependencies) ON a, b FROM t1;

ANALYZE t1;

-- now the row count estimate is more accurate:
EXPLAIN ANALYZE SELECT * FROM t1 WHERE (a = 1) AND (b = 0);

Without functional-dependency statistics, the planner would assume that the two WHERE conditions are independent, and would multiply their selectivities together to arrive at a much-too-small row count estimate. With such statistics, the planner recognizes that the WHERE conditions are redundant and does not underestimate the row count.

Create table t2 with two perfectly correlated columns (containing identical data), and an MCV list on those columns:

CREATE TABLE t2 ( a int, b int );

INSERT INTO t2 SELECT mod(i,100), mod(i,100)
                 FROM generate_series(1,1000000) s(i);

CREATE STATISTICS s2 (mcv) ON a, b FROM t2;

ANALYZE t2;

-- valid combination (found in MCV)
EXPLAIN ANALYZE SELECT * FROM t2 WHERE (a = 1) AND (b = 1);

-- invalid combination (not found in MCV)
EXPLAIN ANALYZE SELECT * FROM t2 WHERE (a = 1) AND (b = 2);

The MCV list gives the planner more detailed information about the specific values that commonly appear in the table, as well as an upper bound on the selectivities of combinations of values that do not appear in the table, allowing it to generate better estimates in both cases.

Create table t3 with a single timestamp column, and run queries using expressions on that column. Without extended statistics, the planner has no information about the data distribution for the expressions, and uses default estimates. The planner also does not realize that the value of the date truncated to the month is fully determined by the value of the date truncated to the day. Then expression and ndistinct statistics are built on those two expressions:

CREATE TABLE t3 ( a timestamp );

INSERT INTO t3 SELECT i FROM generate_series(2020-01-01::timestamp,
                                             2020-12-31::timestamp,
                                             1 minute::interval) s(i);

ANALYZE t3;

-- the number of matching rows will be drastically underestimated:
EXPLAIN ANALYZE SELECT * FROM t3
  WHERE date_trunc(month, a) = 2020-01-01::timestamp;

EXPLAIN ANALYZE SELECT * FROM t3
  WHERE date_trunc(day, a) BETWEEN 2020-01-01::timestamp
                                 AND 2020-06-30::timestamp;

EXPLAIN ANALYZE SELECT date_trunc(month, a), date_trunc(day, a)
   FROM t3 GROUP BY 1, 2;

-- build ndistinct statistics on the pair of expressions (per-expression
-- statistics are built automatically)
CREATE STATISTICS s3 (ndistinct) ON date_trunc(month, a), date_trunc(day, a) FROM t3;

ANALYZE t3;

-- now the row count estimates are more accurate:
EXPLAIN ANALYZE SELECT * FROM t3
  WHERE date_trunc(month, a) = 2020-01-01::timestamp;

EXPLAIN ANALYZE SELECT * FROM t3
  WHERE date_trunc(day, a) BETWEEN 2020-01-01::timestamp
                                 AND 2020-06-30::timestamp;

EXPLAIN ANALYZE SELECT date_trunc(month, a), date_trunc(day, a)
   FROM t3 GROUP BY 1, 2;

Without expression and ndistinct statistics, the planner has no information about the number of distinct values for the expressions, and has to rely on default estimates. The equality and range conditions are assumed to have 0.5% selectivity, and the number of distinct values in the expression is assumed to be the same as for the column (i.e. unique). This results in a significant underestimate of the row count in the first two queries. Moreover, the planner has no information about the relationship between the expressions, so it assumes the two WHERE and GROUP BY conditions are independent, and multiplies their selectivities together to arrive at a severe overestimate of the group count in the aggregate query. This is further exacerbated by the lack of accurate statistics for the expressions, forcing the planner to use a default ndistinct estimate for the expression derived from ndistinct for the column. With such statistics, the planner recognizes that the conditions are correlated, and arrives at much more accurate estimates.

COMPATIBILITY

There is no CREATE STATISTICS command in the SQL standard.

SEE ALSO

ALTER STATISTICS (ALTER_STATISTICS(7)), DROP STATISTICS (DROP_STATISTICS(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

541 - Linux cli command DO

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DO and provides detailed information about the command DO, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DO.

NAME 🖥️ DO 🖥️

execute an anonymous code block

SYNOPSIS

DO [ LANGUAGE lang_name ] code

DESCRIPTION

DO executes an anonymous code block, or in other words a transient anonymous function in a procedural language.

The code block is treated as though it were the body of a function with no parameters, returning void. It is parsed and executed a single time.

The optional LANGUAGE clause can be written either before or after the code block.

PARAMETERS

code

The procedural language code to be executed. This must be specified as a string literal, just as in CREATE FUNCTION. Use of a dollar-quoted literal is recommended.

lang_name

The name of the procedural language the code is written in. If omitted, the default is plpgsql.

NOTES

The procedural language to be used must already have been installed into the current database by means of CREATE EXTENSION. plpgsql is installed by default, but other languages are not.

The user must have USAGE privilege for the procedural language, or must be a superuser if the language is untrusted. This is the same privilege requirement as for creating a function in the language.

If DO is executed in a transaction block, then the procedure code cannot execute transaction control statements. Transaction control statements are only allowed if DO is executed in its own transaction.

EXAMPLES

Grant all privileges on all views in schema public to role webuser:

DO $$DECLARE r record; BEGIN FOR r IN SELECT table_schema, table_name FROM information_schema.tables WHERE table_type = VIEW AND table_schema = public LOOP EXECUTE GRANT ALL ON || quote_ident(r.table_schema) || . || quote_ident(r.table_name) || TO webuser; END LOOP; END$$;

COMPATIBILITY

There is no DO statement in the SQL standard.

SEE ALSO

CREATE LANGUAGE (CREATE_LANGUAGE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

542 - Linux cli command EVP_PKEY-ED448ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_PKEY-ED448ssl and provides detailed information about the command EVP_PKEY-ED448ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_PKEY-ED448ssl.

NAME 🖥️ EVP_PKEY-ED448ssl 🖥️

X25519, EVP_PKEY-X448, EVP_PKEY-ED25519, EVP_PKEY-ED448, EVP_KEYMGMT-X25519, EVP_KEYMGMT-X448, EVP_KEYMGMT-ED25519, EVP_KEYMGMT-ED448 - EVP_PKEY X25519, X448, ED25519 and ED448 keytype and algorithm support

DESCRIPTION

The X25519, X448, ED25519 and ED448 keytypes are implemented in OpenSSL’s default and FIPS providers. These implementations support the associated key, containing the public key pub and the private key priv.

Keygen Parameters

“dhkem-ikm” (OSSL_PKEY_PARAM_DHKEM_IKM) <octet string>
DHKEM requires the generation of a keypair using an input key material (seed). Use this to specify the key material used for generation of the private key. This value should not be reused for other purposes. It should have a length of at least 32 for X25519, and 56 for X448. This is only supported by X25519 and X448.

Use EVP_PKEY_CTX_set_params() after calling EVP_PKEY_keygen_init().

Common X25519, X448, ED25519 and ED448 parameters

In addition to the common parameters that all keytypes should support (see “Common parameters” in provider-keymgmt (7)), the implementation of these keytypes support the following.

“group” (OSSL_PKEY_PARAM_GROUP_NAME) <UTF8 string>
This is only supported by X25519 and X448. The group name must be “x25519” or “x448” respectively for those algorithms. This is only present for consistency with other key exchange algorithms and is typically not needed.

“pub” (OSSL_PKEY_PARAM_PUB_KEY) <octet string>
The public key value.

“priv” (OSSL_PKEY_PARAM_PRIV_KEY) <octet string>
The private key value.

“encoded-pub-key” (OSSL_PKEY_PARAM_ENCODED_PUBLIC_KEY) <octet string>
Used for getting and setting the encoding of a public key for the X25519 and X448 key types. Public keys are expected be encoded in a format as defined by RFC7748.

ED25519 and ED448 parameters

“mandatory-digest” (OSSL_PKEY_PARAM_MANDATORY_DIGEST) <UTF8 string>
The empty string, signifying that no digest may be specified.

CONFORMING TO

RFC 8032

RFC 8410

EXAMPLES

An EVP_PKEY context can be obtained by calling:

EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “X25519”, NULL); EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “X448”, NULL); EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “ED25519”, NULL); EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “ED448”, NULL);

An X25519 key can be generated like this:

pkey = EVP_PKEY_Q_keygen(NULL, NULL, “X25519”);

An X448, ED25519, or ED448 key can be generated likewise.

SEE ALSO

EVP_KEYMGMT (3), EVP_PKEY (3), provider-keymgmt (7), EVP_KEYEXCH-X25519 (7), EVP_KEYEXCH-X448 (7), EVP_SIGNATURE-ED25519 (7), EVP_SIGNATURE-ED448 (7)

COPYRIGHT

Copyright 2020-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

543 - Linux cli command EVP_RAND-CTR-DRBGssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_RAND-CTR-DRBGssl and provides detailed information about the command EVP_RAND-CTR-DRBGssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_RAND-CTR-DRBGssl.

NAME 🖥️ EVP_RAND-CTR-DRBGssl 🖥️

CTR-DRBG - The CTR DRBG EVP_RAND implementation

DESCRIPTION

Support for the counter deterministic random bit generator through the EVP_RAND API.

Identity

“CTR-DRBG” is the name for this implementation; it can be used with the EVP_RAND_fetch() function.

Supported parameters

The supported parameters are:

“state” (OSSL_RAND_PARAM_STATE) <integer>

“strength” (OSSL_RAND_PARAM_STRENGTH) <unsigned integer>

“max_request” (OSSL_RAND_PARAM_MAX_REQUEST) <unsigned integer>

“reseed_requests” (OSSL_DRBG_PARAM_RESEED_REQUESTS) <unsigned integer>

“reseed_time_interval” (OSSL_DRBG_PARAM_RESEED_TIME_INTERVAL) <integer>

“min_entropylen” (OSSL_DRBG_PARAM_MIN_ENTROPYLEN) <unsigned integer>

“max_entropylen” (OSSL_DRBG_PARAM_MAX_ENTROPYLEN) <unsigned integer>

“min_noncelen” (OSSL_DRBG_PARAM_MIN_NONCELEN) <unsigned integer>

“max_noncelen” (OSSL_DRBG_PARAM_MAX_NONCELEN) <unsigned integer>

“max_perslen” (OSSL_DRBG_PARAM_MAX_PERSLEN) <unsigned integer>

“max_adinlen” (OSSL_DRBG_PARAM_MAX_ADINLEN) <unsigned integer>

“reseed_counter” (OSSL_DRBG_PARAM_RESEED_COUNTER) <unsigned integer>

“properties” (OSSL_DRBG_PARAM_PROPERTIES) <UTF8 string>

“cipher” (OSSL_DRBG_PARAM_CIPHER) <UTF8 string>

These parameters work as described in “PARAMETERS” in EVP_RAND (3).

“use_derivation_function” (OSSL_DRBG_PARAM_USE_DF) <integer>
This Boolean indicates if a derivation function should be used or not. A nonzero value (the default) uses the derivation function. A zero value does not.

NOTES

A context for CTR DRBG can be obtained by calling:

EVP_RAND *rand = EVP_RAND_fetch(NULL, “CTR-DRBG”, NULL); EVP_RAND_CTX *rctx = EVP_RAND_CTX_new(rand, NULL);

EXAMPLES

EVP_RAND *rand; EVP_RAND_CTX *rctx; unsigned char bytes[100]; OSSL_PARAM params[2], *p = params; unsigned int strength = 128; rand = EVP_RAND_fetch(NULL, “CTR-DRBG”, NULL); rctx = EVP_RAND_CTX_new(rand, NULL); EVP_RAND_free(rand); *p++ = OSSL_PARAM_construct_utf8_string(OSSL_DRBG_PARAM_CIPHER, SN_aes_256_ctr, 0); *p = OSSL_PARAM_construct_end(); EVP_RAND_instantiate(rctx, strength, 0, NULL, 0, params); EVP_RAND_generate(rctx, bytes, sizeof(bytes), strength, 0, NULL, 0); EVP_RAND_CTX_free(rctx);

CONFORMING TO

NIST SP 800-90A and SP 800-90B

SEE ALSO

EVP_RAND (3), “PARAMETERS” in EVP_RAND (3)

COPYRIGHT

Copyright 2020-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

544 - Linux cli command packet

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command packet and provides detailed information about the command packet, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the packet.

NAME 🖥️ packet 🖥️

packet interface on device level

SYNOPSIS

#include <sys/socket.h>
#include <linux/if_packet.h>
#include <net/ethernet.h> /* the L2 protocols */
packet_socket = socket(AF_PACKET, int socket_type, int protocol);

DESCRIPTION

Packet sockets are used to receive or send raw packets at the device driver (OSI Layer 2) level. They allow the user to implement protocol modules in user space on top of the physical layer.

The socket_type is either SOCK_RAW for raw packets including the link-level header or SOCK_DGRAM for cooked packets with the link-level header removed. The link-level header information is available in a common format in a sockaddr_ll structure. protocol is the IEEE 802.3 protocol number in network byte order. See the <linux/if_ether.h> include file for a list of allowed protocols. When protocol is set to htons(ETH_P_ALL), then all protocols are received. All incoming packets of that protocol type will be passed to the packet socket before they are passed to the protocols implemented in the kernel. If protocol is set to zero, no packets are received. bind(2) can optionally be called with a nonzero sll_protocol to start receiving packets for the protocols specified.

In order to create a packet socket, a process must have the CAP_NET_RAW capability in the user namespace that governs its network namespace.

SOCK_RAW packets are passed to and from the device driver without any changes in the packet data. When receiving a packet, the address is still parsed and passed in a standard sockaddr_ll address structure. When transmitting a packet, the user-supplied buffer should contain the physical-layer header. That packet is then queued unmodified to the network driver of the interface defined by the destination address. Some device drivers always add other headers. SOCK_RAW is similar to but not compatible with the obsolete AF_INET/SOCK_PACKET of Linux 2.0.

SOCK_DGRAM operates on a slightly higher level. The physical header is removed before the packet is passed to the user. Packets sent through a SOCK_DGRAM packet socket get a suitable physical-layer header based on the information in the sockaddr_ll destination address before they are queued.

By default, all packets of the specified protocol type are passed to a packet socket. To get packets only from a specific interface use bind(2) specifying an address in a struct sockaddr_ll to bind the packet socket to an interface. Fields used for binding are sll_family (should be AF_PACKET), sll_protocol, and sll_ifindex.

The connect(2) operation is not supported on packet sockets.

When the MSG_TRUNC flag is passed to recvmsg(2), recv(2), or recvfrom(2), the real length of the packet on the wire is always returned, even when it is longer than the buffer.

Address types

The sockaddr_ll structure is a device-independent physical-layer address.

struct sockaddr_ll {
    unsigned short sll_family;   /* Always AF_PACKET */
    unsigned short sll_protocol; /* Physical-layer protocol */
    int            sll_ifindex;  /* Interface number */
    unsigned short sll_hatype;   /* ARP hardware type */
    unsigned char  sll_pkttype;  /* Packet type */
    unsigned char  sll_halen;    /* Length of address */
    unsigned char  sll_addr[8];  /* Physical-layer address */
};

The fields of this structure are as follows:

sll_protocol
is the standard ethernet protocol type in network byte order as defined in the <linux/if_ether.h> include file. It defaults to the socket’s protocol.

sll_ifindex
is the interface index of the interface (see netdevice(7)); 0 matches any interface (only permitted for binding). sll_hatype is an ARP type as defined in the <linux/if_arp.h> include file.

sll_pkttype
contains the packet type. Valid types are PACKET_HOST for a packet addressed to the local host, PACKET_BROADCAST for a physical-layer broadcast packet, PACKET_MULTICAST for a packet sent to a physical-layer multicast address, PACKET_OTHERHOST for a packet to some other host that has been caught by a device driver in promiscuous mode, and PACKET_OUTGOING for a packet originating from the local host that is looped back to a packet socket. These types make sense only for receiving.

sll_addr
sll_halen
contain the physical-layer (e.g., IEEE 802.3) address and its length. The exact interpretation depends on the device.

When you send packets, it is enough to specify sll_family, sll_addr, sll_halen, sll_ifindex, and sll_protocol. The other fields should be 0. sll_hatype and sll_pkttype are set on received packets for your information.

Socket options

Packet socket options are configured by calling setsockopt(2) with level SOL_PACKET.

PACKET_ADD_MEMBERSHIP

PACKET_DROP_MEMBERSHIP

Packet sockets can be used to configure physical-layer multicasting and promiscuous mode. PACKET_ADD_MEMBERSHIP adds a binding and PACKET_DROP_MEMBERSHIP drops it. They both expect a packet_mreq structure as argument:

struct packet_mreq {
    int            mr_ifindex;    /* interface index */
    unsigned short mr_type;       /* action */
    unsigned short mr_alen;       /* address length */
    unsigned char  mr_address[8]; /* physical-layer address */
};

mr_ifindex contains the interface index for the interface whose status should be changed. The mr_type field specifies which action to perform. PACKET_MR_PROMISC enables receiving all packets on a shared medium (often known as “promiscuous mode”), PACKET_MR_MULTICAST binds the socket to the physical-layer multicast group specified in mr_address and mr_alen, and PACKET_MR_ALLMULTI sets the socket up to receive all multicast packets arriving at the interface.

In addition, the traditional ioctls SIOCSIFFLAGS, SIOCADDMULTI, SIOCDELMULTI can be used for the same purpose.

PACKET_AUXDATA (since Linux 2.6.21)
If this binary option is enabled, the packet socket passes a metadata structure along with each packet in the recvmsg(2) control field. The structure can be read with cmsg(3). It is defined as

struct tpacket_auxdata {
    __u32 tp_status;
    __u32 tp_len;      /* packet length */
    __u32 tp_snaplen;  /* captured length */
    __u16 tp_mac;
    __u16 tp_net;
    __u16 tp_vlan_tci;
    __u16 tp_vlan_tpid; /* Since Linux 3.14; earlier, these
                           were unused padding bytes */
};

PACKET_FANOUT (since Linux 3.1)
To scale processing across threads, packet sockets can form a fanout group. In this mode, each matching packet is enqueued onto only one socket in the group. A socket joins a fanout group by calling setsockopt(2) with level SOL_PACKET and option PACKET_FANOUT. Each network namespace can have up to 65536 independent groups. A socket selects a group by encoding the ID in the first 16 bits of the integer option value. The first packet socket to join a group implicitly creates it. To successfully join an existing group, subsequent packet sockets must have the same protocol, device settings, fanout mode, and flags (see below). Packet sockets can leave a fanout group only by closing the socket. The group is deleted when the last socket is closed.

Fanout supports multiple algorithms to spread traffic between sockets, as follows:

  • The default mode, PACKET_FANOUT_HASH, sends packets from the same flow to the same socket to maintain per-flow ordering. For each packet, it chooses a socket by taking the packet flow hash modulo the number of sockets in the group, where a flow hash is a hash over network-layer address and optional transport-layer port fields.

  • The load-balance mode PACKET_FANOUT_LB implements a round-robin algorithm.

  • PACKET_FANOUT_CPU selects the socket based on the CPU that the packet arrived on.

  • PACKET_FANOUT_ROLLOVER processes all data on a single socket, moving to the next when one becomes backlogged.

  • PACKET_FANOUT_RND selects the socket using a pseudo-random number generator.

  • PACKET_FANOUT_QM (available since Linux 3.14) selects the socket using the recorded queue_mapping of the received skb.

Fanout modes can take additional options. IP fragmentation causes packets from the same flow to have different flow hashes. The flag PACKET_FANOUT_FLAG_DEFRAG, if set, causes packets to be defragmented before fanout is applied, to preserve order even in this case. Fanout mode and options are communicated in the second 16 bits of the integer option value. The flag PACKET_FANOUT_FLAG_ROLLOVER enables the roll over mechanism as a backup strategy: if the original fanout algorithm selects a backlogged socket, the packet rolls over to the next available one.

PACKET_LOSS (with PACKET_TX_RING)
When a malformed packet is encountered on a transmit ring, the default is to reset its tp_status to TP_STATUS_WRONG_FORMAT and abort the transmission immediately. The malformed packet blocks itself and subsequently enqueued packets from being sent. The format error must be fixed, the associated tp_status reset to TP_STATUS_SEND_REQUEST, and the transmission process restarted via send(2). However, if PACKET_LOSS is set, any malformed packet will be skipped, its tp_status reset to TP_STATUS_AVAILABLE, and the transmission process continued.

PACKET_RESERVE (with PACKET_RX_RING)
By default, a packet receive ring writes packets immediately following the metadata structure and alignment padding. This integer option reserves additional headroom.

PACKET_RX_RING
Create a memory-mapped ring buffer for asynchronous packet reception. The packet socket reserves a contiguous region of application address space, lays it out into an array of packet slots and copies packets (up to tp_snaplen) into subsequent slots. Each packet is preceded by a metadata structure similar to tpacket_auxdata. The protocol fields encode the offset to the data from the start of the metadata header. tp_net stores the offset to the network layer. If the packet socket is of type SOCK_DGRAM, then tp_mac is the same. If it is of type SOCK_RAW, then that field stores the offset to the link-layer frame. Packet socket and application communicate the head and tail of the ring through the tp_status field. The packet socket owns all slots with tp_status equal to TP_STATUS_KERNEL. After filling a slot, it changes the status of the slot to transfer ownership to the application. During normal operation, the new tp_status value has at least the TP_STATUS_USER bit set to signal that a received packet has been stored. When the application has finished processing a packet, it transfers ownership of the slot back to the socket by setting tp_status equal to TP_STATUS_KERNEL.

Packet sockets implement multiple variants of the packet ring. The implementation details are described in Documentation/networking/packet_mmap.rst in the Linux kernel source tree.

PACKET_STATISTICS
Retrieve packet socket statistics in the form of a structure

struct tpacket_stats {
    unsigned int tp_packets;  /* Total packet count */
    unsigned int tp_drops;    /* Dropped packet count */
};

Receiving statistics resets the internal counters. The statistics structure differs when using a ring of variant TPACKET_V3.

PACKET_TIMESTAMP (with PACKET_RX_RING; since Linux 2.6.36)
The packet receive ring always stores a timestamp in the metadata header. By default, this is a software generated timestamp generated when the packet is copied into the ring. This integer option selects the type of timestamp. Besides the default, it support the two hardware formats described in Documentation/networking/timestamping.rst in the Linux kernel source tree.

PACKET_TX_RING (since Linux 2.6.31)
Create a memory-mapped ring buffer for packet transmission. This option is similar to PACKET_RX_RING and takes the same arguments. The application writes packets into slots with tp_status equal to TP_STATUS_AVAILABLE and schedules them for transmission by changing tp_status to TP_STATUS_SEND_REQUEST. When packets are ready to be transmitted, the application calls send(2) or a variant thereof. The buf and len fields of this call are ignored. If an address is passed using sendto(2) or sendmsg(2), then that overrides the socket default. On successful transmission, the socket resets tp_status to TP_STATUS_AVAILABLE. It immediately aborts the transmission on error unless PACKET_LOSS is set.

PACKET_VERSION (with PACKET_RX_RING; since Linux 2.6.27)
By default, PACKET_RX_RING creates a packet receive ring of variant TPACKET_V1. To create another variant, configure the desired variant by setting this integer option before creating the ring.

PACKET_QDISC_BYPASS (since Linux 3.14)
By default, packets sent through packet sockets pass through the kernel’s qdisc (traffic control) layer, which is fine for the vast majority of use cases. For traffic generator appliances using packet sockets that intend to brute-force flood the network—for example, to test devices under load in a similar fashion to pktgen—this layer can be bypassed by setting this integer option to 1. A side effect is that packet buffering in the qdisc layer is avoided, which will lead to increased drops when network device transmit queues are busy; therefore, use at your own risk.

Ioctls

SIOCGSTAMP can be used to receive the timestamp of the last received packet. Argument is a struct timeval variable.

In addition, all standard ioctls defined in netdevice(7) and socket(7) are valid on packet sockets.

Error handling

Packet sockets do no error handling other than errors occurred while passing the packet to the device driver. They don’t have the concept of a pending error.

ERRORS

EADDRNOTAVAIL
Unknown multicast group address passed.

EFAULT
User passed invalid memory address.

EINVAL
Invalid argument.

EMSGSIZE
Packet is bigger than interface MTU.

ENETDOWN
Interface is not up.

ENOBUFS
Not enough memory to allocate the packet.

ENODEV
Unknown device name or interface index specified in interface address.

ENOENT
No packet received.

ENOTCONN
No interface address passed.

ENXIO
Interface address contained an invalid interface index.

EPERM
User has insufficient privileges to carry out this operation.

In addition, other errors may be generated by the low-level driver.

VERSIONS

AF_PACKET is a new feature in Linux 2.2. Earlier Linux versions supported only SOCK_PACKET.

NOTES

For portable programs it is suggested to use AF_PACKET via pcap(3); although this covers only a subset of the AF_PACKET features.

The SOCK_DGRAM packet sockets make no attempt to create or parse the IEEE 802.2 LLC header for a IEEE 802.3 frame. When ETH_P_802_3 is specified as protocol for sending the kernel creates the 802.3 frame and fills out the length field; the user has to supply the LLC header to get a fully conforming packet. Incoming 802.3 packets are not multiplexed on the DSAP/SSAP protocol fields; instead they are supplied to the user as protocol ETH_P_802_2 with the LLC header prefixed. It is thus not possible to bind to ETH_P_802_3; bind to ETH_P_802_2 instead and do the protocol multiplex yourself. The default for sending is the standard Ethernet DIX encapsulation with the protocol filled in.

Packet sockets are not subject to the input or output firewall chains.

Compatibility

In Linux 2.0, the only way to get a packet socket was with the call:

socket(AF_INET, SOCK_PACKET, protocol)

This is still supported, but deprecated and strongly discouraged. The main difference between the two methods is that SOCK_PACKET uses the old struct sockaddr_pkt to specify an interface, which doesn’t provide physical-layer independence.

struct sockaddr_pkt {
    unsigned short spkt_family;
    unsigned char  spkt_device[14];
    unsigned short spkt_protocol;
};

spkt_family contains the device type, spkt_protocol is the IEEE 802.3 protocol type as defined in <sys/if_ether.h> and spkt_device is the device name as a null-terminated string, for example, eth0.

This structure is obsolete and should not be used in new code.

BUGS

LLC header handling

The IEEE 802.2/803.3 LLC handling could be considered as a bug.

MSG_TRUNC issues

The MSG_TRUNC recvmsg(2) extension is an ugly hack and should be replaced by a control message. There is currently no way to get the original destination address of packets via SOCK_DGRAM.

spkt_device device name truncation

The spkt_device field of sockaddr_pkt has a size of 14 bytes, which is less than the constant IFNAMSIZ defined in <net/if.h> which is 16 bytes and describes the system limit for a network interface name. This means the names of network devices longer than 14 bytes will be truncated to fit into spkt_device. All these lengths include the terminating null byte (‘�’)).

Issues from this with old code typically show up with very long interface names used by the Predictable Network Interface Names feature enabled by default in many modern Linux distributions.

The preferred solution is to rewrite code to avoid SOCK_PACKET. Possible user solutions are to disable Predictable Network Interface Names or to rename the interface to a name of at most 13 bytes, for example using the ip(8) tool.

Documentation issues

Socket filters are not documented.

SEE ALSO

socket(2), pcap(3), capabilities(7), ip(7), raw(7), socket(7), ip(8),

RFC 894 for the standard IP Ethernet encapsulation. RFC 1700 for the IEEE 802.3 IP encapsulation.

The <linux/if_ether.h> include file for physical-layer protocols.

The Linux kernel source tree. Documentation/networking/filter.rst describes how to apply Berkeley Packet Filters to packet sockets. tools/testing/selftests/net/psock_tpacket.c contains example source code for all available versions of PACKET_RX_RING and PACKET_TX_RING.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

545 - Linux cli command EVP_PKEY-FFCssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_PKEY-FFCssl and provides detailed information about the command EVP_PKEY-FFCssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_PKEY-FFCssl.

NAME 🖥️ EVP_PKEY-FFCssl 🖥️

FFC - EVP_PKEY DSA and DH/DHX shared FFC parameters.

DESCRIPTION

Finite field cryptography (FFC) is a method of implementing discrete logarithm cryptography using finite field mathematics. DSA is an example of FFC and Diffie-Hellman key establishment algorithms specified in SP800-56A can also be implemented as FFC.

The DSA, DH and DHX keytypes are implemented in OpenSSL’s default and FIPS providers. The implementations support the basic DSA, DH and DHX keys, containing the public and private keys pub and priv as well as the three main domain parameters p, q and g.

For DSA (and DH that is not a named group) the FIPS186-4 standard specifies that the values used for FFC parameter generation are also required for parameter validation. This means that optional FFC domain parameter values for seed, pcounter and gindex may need to be stored for validation purposes. For DH the seed and pcounter can be stored in ASN1 data (but the gindex is not). For DSA however, these fields are not stored in the ASN1 data so they need to be stored externally if validation is required.

The DH key type uses PKCS#3 format which saves p and g, but not the ‘q’ value. The DHX key type uses X9.42 format which saves the value of ‘q’ and this must be used for FIPS186-4.

FFC parameters

In addition to the common parameters that all keytypes should support (see “Common parameters” in provider-keymgmt (7)), the DSA, DH and DHX keytype implementations support the following.

“pub” (OSSL_PKEY_PARAM_PUB_KEY) <unsigned integer>
The public key value.

“priv” (OSSL_PKEY_PARAM_PRIV_KEY) <unsigned integer>
The private key value.

FFC DSA, DH and DHX domain parameters

“p” (OSSL_PKEY_PARAM_FFC_P) <unsigned integer>
A DSA or Diffie-Hellman prime “p” value.

“g” (OSSL_PKEY_PARAM_FFC_G) <unsigned integer>
A DSA or Diffie-Hellman generator “g” value.

FFC DSA and DHX domain parameters

“q” (OSSL_PKEY_PARAM_FFC_Q) <unsigned integer>
A DSA or Diffie-Hellman prime “q” value.

“seed” (OSSL_PKEY_PARAM_FFC_SEED) <octet string>
An optional domain parameter seed value used during generation and validation of p, q and canonical g. For validation this needs to set the seed that was produced during generation.

“gindex” (OSSL_PKEY_PARAM_FFC_GINDEX) <integer>
Sets the index to use for canonical generation and verification of the generator g. Set this to a positive value from 0..FF to use this mode. This gindex can then be reused during key validation to verify the value of g. If this value is not set or is -1 then unverifiable generation of the generator g will be used.

“pcounter” (OSSL_PKEY_PARAM_FFC_PCOUNTER) <integer>
An optional domain parameter counter value that is output during generation of p. This value must be saved if domain parameter validation is required.

“hindex” (OSSL_PKEY_PARAM_FFC_H) <integer>
For unverifiable generation of the generator g this value is output during generation of g. Its value is the first integer larger than one that satisfies g = h^j mod p (where g != 1 and “j” is the cofactor).

“j” (OSSL_PKEY_PARAM_FFC_COFACTOR) <unsigned integer>
An optional informational cofactor parameter that should equal to (p - 1) / q.

“validate-pq” (OSSL_PKEY_PARAM_FFC_VALIDATE_PQ) <unsigned integer>

“validate-g” (OSSL_PKEY_PARAM_FFC_VALIDATE_G) <unsigned integer>

These boolean values are used during FIPS186-4 or FIPS186-2 key validation checks (See EVP_PKEY_param_check (3)) to select validation options. By default validate-pq and validate-g are both set to 1 to check that p,q and g are valid. Either of these may be set to 0 to skip a test, which is mainly useful for testing purposes.

“validate-legacy” (OSSL_PKEY_PARAM_FFC_VALIDATE_LEGACY) <unsigned integer>
This boolean value is used during key validation checks (See EVP_PKEY_param_check (3)) to select the validation type. The default value of 0 selects FIPS186-4 validation. Setting this value to 1 selects FIPS186-2 validation.

FFC key generation parameters

The following key generation types are available for DSA and DHX algorithms:

“type” (OSSL_PKEY_PARAM_FFC_TYPE) <UTF8 string>
Sets the type of parameter generation. The shared valid values are:

“fips186_4”
The current standard.

“fips186_2”
The old standard that should only be used for legacy purposes.

“default”
This can choose one of “fips186_4” or “fips186_2” depending on other parameters set for parameter generation.

“pbits” (OSSL_PKEY_PARAM_FFC_PBITS) <unsigned integer>
Sets the size (in bits) of the prime ‘p’.

“qbits” (OSSL_PKEY_PARAM_FFC_QBITS) <unsigned integer>
Sets the size (in bits) of the prime ‘q’. For “fips186_4” this can be either 224 or 256. For “fips186_2” this has a size of 160.

“digest” (OSSL_PKEY_PARAM_FFC_DIGEST) <UTF8 string>
Sets the Digest algorithm to be used as part of the Key Generation Function associated with the given Key Generation ctx. This must also be set for key validation.

“properties” (OSSL_PKEY_PARAM_FFC_DIGEST_PROPS) <UTF8 string>
Sets properties to be used upon look up of the implementation for the selected Digest algorithm for the Key Generation Function associated with the given key generation ctx. This may also be set for key validation.

“seed” (OSSL_PKEY_PARAM_FFC_SEED) <octet string>
For “fips186_4” or “fips186_2” generation this sets the seed data to use instead of generating a random seed internally. This should be used for testing purposes only. This will either produce fixed values for the generated parameters OR it will fail if the seed did not generate valid primes.

“gindex” (OSSL_PKEY_PARAM_FFC_GINDEX) <integer>

“pcounter” (OSSL_PKEY_PARAM_FFC_PCOUNTER) <integer>

“hindex” (OSSL_PKEY_PARAM_FFC_H) <integer>

These types are described above.

CONFORMING TO

The following sections of SP800-56Ar3:

The following sections of FIPS186-4:

SEE ALSO

EVP_PKEY-DSA (7), EVP_PKEY-DH (7), EVP_SIGNATURE-DSA (7), EVP_KEYEXCH-DH (7) EVP_KEYMGMT (3), EVP_PKEY (3), provider-keymgmt (7), OSSL_PROVIDER-default (7), OSSL_PROVIDER-FIPS (7),

COPYRIGHT

Copyright 2020-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

546 - Linux cli command ddp

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ddp and provides detailed information about the command ddp, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ddp.

NAME 🖥️ ddp 🖥️

Linux AppleTalk protocol implementation

SYNOPSIS

#include <sys/socket.h>
#include <netatalk/at.h>
ddp_socket = socket(AF_APPLETALK, SOCK_DGRAM, 0);
raw_socket = socket(AF_APPLETALK, SOCK_RAW, protocol);

DESCRIPTION

Linux implements the AppleTalk protocols described in Inside AppleTalk. Only the DDP layer and AARP are present in the kernel. They are designed to be used via the netatalk protocol libraries. This page documents the interface for those who wish or need to use the DDP layer directly.

The communication between AppleTalk and the user program works using a BSD-compatible socket interface. For more information on sockets, see socket(7).

An AppleTalk socket is created by calling the socket(2) function with a AF_APPLETALK socket family argument. Valid socket types are SOCK_DGRAM to open a ddp socket or SOCK_RAW to open a raw socket. protocol is the AppleTalk protocol to be received or sent. For SOCK_RAW you must specify ATPROTO_DDP.

Raw sockets may be opened only by a process with effective user ID 0 or when the process has the CAP_NET_RAW capability.

Address format

An AppleTalk socket address is defined as a combination of a network number, a node number, and a port number.

struct at_addr {
    unsigned short s_net;
    unsigned char  s_node;
};
struct sockaddr_atalk {
    sa_family_t    sat_family;    /* address family */
    unsigned char  sat_port;      /* port */
    struct at_addr sat_addr;      /* net/node */
};

sat_family is always set to AF_APPLETALK. sat_port contains the port. The port numbers below 129 are known as reserved ports. Only processes with the effective user ID 0 or the CAP_NET_BIND_SERVICE capability may bind(2) to these sockets. sat_addr is the host address. The net member of struct at_addr contains the host network in network byte order. The value of AT_ANYNET is a wildcard and also implies “this network.” The node member of struct at_addr contains the host node number. The value of AT_ANYNODE is a wildcard and also implies “this node.” The value of ATADDR_BCAST is a link local broadcast address.

Socket options

No protocol-specific socket options are supported.

/proc interfaces

IP supports a set of /proc interfaces to configure some global AppleTalk parameters. The parameters can be accessed by reading or writing files in the directory /proc/sys/net/atalk/.

aarp-expiry-time
The time interval (in seconds) before an AARP cache entry expires.

aarp-resolve-time
The time interval (in seconds) before an AARP cache entry is resolved.

aarp-retransmit-limit
The number of retransmissions of an AARP query before the node is declared dead.

aarp-tick-time
The timer rate (in seconds) for the timer driving AARP.

The default values match the specification and should never need to be changed.

Ioctls

All ioctls described in socket(7) apply to DDP.

ERRORS

EACCES
The user tried to execute an operation without the necessary permissions. These include sending to a broadcast address without having the broadcast flag set, and trying to bind to a reserved port without effective user ID 0 or CAP_NET_BIND_SERVICE.

EADDRINUSE
Tried to bind to an address already in use.

EADDRNOTAVAIL
A nonexistent interface was requested or the requested source address was not local.

EAGAIN
Operation on a nonblocking socket would block.

EALREADY
A connection operation on a nonblocking socket is already in progress.

ECONNABORTED
A connection was closed during an accept(2).

EHOSTUNREACH
No routing table entry matches the destination address.

EINVAL
Invalid argument passed.

EISCONN
connect(2) was called on an already connected socket.

EMSGSIZE
Datagram is bigger than the DDP MTU.

ENODEV
Network device not available or not capable of sending IP.

ENOENT
SIOCGSTAMP was called on a socket where no packet arrived.

ENOMEM and ENOBUFS
Not enough memory available.

ENOPKG
A kernel subsystem was not configured.

ENOPROTOOPT and EOPNOTSUPP
Invalid socket option passed.

ENOTCONN
The operation is defined only on a connected socket, but the socket wasn’t connected.

EPERM
User doesn’t have permission to set high priority, make a configuration change, or send signals to the requested process or group.

EPIPE
The connection was unexpectedly closed or shut down by the other end.

ESOCKTNOSUPPORT
The socket was unconfigured, or an unknown socket type was requested.

VERSIONS

AppleTalk is supported by Linux 2.0 or higher. The /proc interfaces exist since Linux 2.2.

NOTES

Be very careful with the SO_BROADCAST option; it is not privileged in Linux. It is easy to overload the network with careless sending to broadcast addresses.

Compatibility

The basic AppleTalk socket interface is compatible with netatalk on BSD-derived systems. Many BSD systems fail to check SO_BROADCAST when sending broadcast frames; this can lead to compatibility problems.

The raw socket mode is unique to Linux and exists to support the alternative CAP package and AppleTalk monitoring tools more easily.

BUGS

There are too many inconsistent error values.

The ioctls used to configure routing tables, devices, AARP tables, and other devices are not yet described.

SEE ALSO

recvmsg(2), sendmsg(2), capabilities(7), socket(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

547 - Linux cli command EVP_PKEY-ED25519ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_PKEY-ED25519ssl and provides detailed information about the command EVP_PKEY-ED25519ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_PKEY-ED25519ssl.

NAME 🖥️ EVP_PKEY-ED25519ssl 🖥️

X25519, EVP_PKEY-X448, EVP_PKEY-ED25519, EVP_PKEY-ED448, EVP_KEYMGMT-X25519, EVP_KEYMGMT-X448, EVP_KEYMGMT-ED25519, EVP_KEYMGMT-ED448 - EVP_PKEY X25519, X448, ED25519 and ED448 keytype and algorithm support

DESCRIPTION

The X25519, X448, ED25519 and ED448 keytypes are implemented in OpenSSL’s default and FIPS providers. These implementations support the associated key, containing the public key pub and the private key priv.

Keygen Parameters

“dhkem-ikm” (OSSL_PKEY_PARAM_DHKEM_IKM) <octet string>
DHKEM requires the generation of a keypair using an input key material (seed). Use this to specify the key material used for generation of the private key. This value should not be reused for other purposes. It should have a length of at least 32 for X25519, and 56 for X448. This is only supported by X25519 and X448.

Use EVP_PKEY_CTX_set_params() after calling EVP_PKEY_keygen_init().

Common X25519, X448, ED25519 and ED448 parameters

In addition to the common parameters that all keytypes should support (see “Common parameters” in provider-keymgmt (7)), the implementation of these keytypes support the following.

“group” (OSSL_PKEY_PARAM_GROUP_NAME) <UTF8 string>
This is only supported by X25519 and X448. The group name must be “x25519” or “x448” respectively for those algorithms. This is only present for consistency with other key exchange algorithms and is typically not needed.

“pub” (OSSL_PKEY_PARAM_PUB_KEY) <octet string>
The public key value.

“priv” (OSSL_PKEY_PARAM_PRIV_KEY) <octet string>
The private key value.

“encoded-pub-key” (OSSL_PKEY_PARAM_ENCODED_PUBLIC_KEY) <octet string>
Used for getting and setting the encoding of a public key for the X25519 and X448 key types. Public keys are expected be encoded in a format as defined by RFC7748.

ED25519 and ED448 parameters

“mandatory-digest” (OSSL_PKEY_PARAM_MANDATORY_DIGEST) <UTF8 string>
The empty string, signifying that no digest may be specified.

CONFORMING TO

RFC 8032

RFC 8410

EXAMPLES

An EVP_PKEY context can be obtained by calling:

EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “X25519”, NULL); EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “X448”, NULL); EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “ED25519”, NULL); EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “ED448”, NULL);

An X25519 key can be generated like this:

pkey = EVP_PKEY_Q_keygen(NULL, NULL, “X25519”);

An X448, ED25519, or ED448 key can be generated likewise.

SEE ALSO

EVP_KEYMGMT (3), EVP_PKEY (3), provider-keymgmt (7), EVP_KEYEXCH-X25519 (7), EVP_KEYEXCH-X448 (7), EVP_SIGNATURE-ED25519 (7), EVP_SIGNATURE-ED448 (7)

COPYRIGHT

Copyright 2020-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

548 - Linux cli command proxy-certificatesssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command proxy-certificatesssl and provides detailed information about the command proxy-certificatesssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the proxy-certificatesssl.

NAME 🖥️ proxy-certificatesssl 🖥️

certificates - Proxy certificates in OpenSSL

DESCRIPTION

Proxy certificates are defined in RFC 3820. They are used to extend rights to some other entity (a computer process, typically, or sometimes to the user itself). This allows the entity to perform operations on behalf of the owner of the EE (End Entity) certificate.

The requirements for a valid proxy certificate are:

  • They are issued by an End Entity, either a normal EE certificate, or another proxy certificate.

  • They must not have the subjectAltName or issuerAltName extensions.

  • They must have the proxyCertInfo extension.

  • They must have the subject of their issuer, with one commonName added.

Enabling proxy certificate verification

OpenSSL expects applications that want to use proxy certificates to be specially aware of them, and make that explicit. This is done by setting an X509 verification flag:

X509_STORE_CTX_set_flags(ctx, X509_V_FLAG_ALLOW_PROXY_CERTS);

or

X509_VERIFY_PARAM_set_flags(param, X509_V_FLAG_ALLOW_PROXY_CERTS);

See “NOTES” for a discussion on this requirement.

Creating proxy certificates

Creating proxy certificates can be done using the openssl-x509 (1) command, with some extra extensions:

[ proxy ] # A proxy certificate MUST NEVER be a CA certificate. basicConstraints = CA:FALSE # Usual authority key ID authorityKeyIdentifier = keyid,issuer:always # The extension which marks this certificate as a proxy proxyCertInfo = critical,language:id-ppl-anyLanguage,pathlen:1,policy:text:AB

It’s also possible to specify the proxy extension in a separate section:

proxyCertInfo = critical,@proxy_ext [ proxy_ext ] language = id-ppl-anyLanguage pathlen = 0 policy = text:BC

The policy value has a specific syntax, syntag:string, where the syntag determines what will be done with the string. The following syntags are recognised:

text
indicates that the string is a byte sequence, without any encoding: policy=text:räksmörgås

hex
indicates the string is encoded hexadecimal encoded binary data, with colons between each byte (every second hex digit): policy=hex:72:E4:6B:73:6D:F6:72:67:E5:73

file
indicates that the text of the policy should be taken from a file. The string is then a filename. This is useful for policies that are more than a few lines, such as XML or other markup.

Note that the proxy policy value is what determines the rights granted to the process during the proxy certificate, and it is up to the application to interpret and combine these policies.>

With a proxy extension, creating a proxy certificate is a matter of two commands:

openssl req -new -config proxy.cnf \ -out proxy.req -keyout proxy.key \ -subj “/DC=org/DC=openssl/DC=users/CN=proxy” openssl x509 -req -CAcreateserial -in proxy.req -out proxy.crt \ -CA user.crt -CAkey user.key -days 7 \ -extfile proxy.cnf -extensions proxy

You can also create a proxy certificate using another proxy certificate as issuer. Note that this example uses a different configuration section for the proxy extensions:

openssl req -new -config proxy.cnf \ -out proxy2.req -keyout proxy2.key \ -subj “/DC=org/DC=openssl/DC=users/CN=proxy/CN=proxy 2” openssl x509 -req -CAcreateserial -in proxy2.req -out proxy2.crt \ -CA proxy.crt -CAkey proxy.key -days 7 \ -extfile proxy.cnf -extensions proxy_2

Using proxy certs in applications

To interpret proxy policies, the application would normally start with some default rights (perhaps none at all), then compute the resulting rights by checking the rights against the chain of proxy certificates, user certificate and CA certificates.

The complicated part is figuring out how to pass data between your application and the certificate validation procedure.

The following ingredients are needed for such processing:

  • a callback function that will be called for every certificate being validated. The callback is called several times for each certificate, so you must be careful to do the proxy policy interpretation at the right time. You also need to fill in the defaults when the EE certificate is checked.

  • a data structure that is shared between your application code and the callback.

  • a wrapper function that sets it all up.

  • an ex_data index function that creates an index into the generic ex_data store that is attached to an X509 validation context.

The following skeleton code can be used as a starting point:

#include <string.h> #include <netdb.h> #include <openssl/x509.h> #include <openssl/x509v3.h> #define total_rights 25 /* * In this example, I will use a view of granted rights as a bit * array, one bit for each possible right. */ typedef struct your_rights { unsigned char rights[(total_rights + 7) / 8]; } YOUR_RIGHTS; /* * The following procedure will create an index for the ex_data * store in the X509 validation context the first time its * called. Subsequent calls will return the same index. */ static int get_proxy_auth_ex_data_idx(X509_STORE_CTX *ctx) { static volatile int idx = -1; if (idx < 0) { X509_STORE_lock(X509_STORE_CTX_get0_store(ctx)); if (idx < 0) { idx = X509_STORE_CTX_get_ex_new_index(0, “for verify callback”, NULL,NULL,NULL); } X509_STORE_unlock(X509_STORE_CTX_get0_store(ctx)); } return idx; } /* Callback to be given to the X509 validation procedure. */ static int verify_callback(int ok, X509_STORE_CTX *ctx) { if (ok == 1) { /* * Its REALLY important you keep the proxy policy check * within this section. Its important to know that when * ok is 1, the certificates are checked from top to * bottom. You get the CA root first, followed by the * possible chain of intermediate CAs, followed by the EE * certificate, followed by the possible proxy * certificates. */ X509 *xs = X509_STORE_CTX_get_current_cert(ctx); if (X509_get_extension_flags(xs) & EXFLAG_PROXY) { YOUR_RIGHTS *rights = (YOUR_RIGHTS *)X509_STORE_CTX_get_ex_data(ctx, get_proxy_auth_ex_data_idx(ctx)); PROXY_CERT_INFO_EXTENSION *pci = X509_get_ext_d2i(xs, NID_proxyCertInfo, NULL, NULL); switch (OBJ_obj2nid(pci->proxyPolicy->policyLanguage)) { case NID_Independent: /* * Do whatever you need to grant explicit rights * to this particular proxy certificate, usually * by pulling them from some database. If there * are none to be found, clear all rights (making * this and any subsequent proxy certificate void * of any rights). */ memset(rights->rights, 0, sizeof(rights->rights)); break; case NID_id_ppl_inheritAll: /* * This is basically a NOP, we simply let the * current rights stand as they are. */ break; default: /* * This is usually the most complex section of * code. You really do whatever you want as long * as you follow RFC 3820. In the example we use * here, the simplest thing to do is to build * another, temporary bit array and fill it with * the rights granted by the current proxy * certificate, then use it as a mask on the * accumulated rights bit array, and voilà, you * now have a new accumulated rights bit array. */ { int i; YOUR_RIGHTS tmp_rights; memset(tmp_rights.rights, 0, sizeof(tmp_rights.rights)); /* * process_rights() is supposed to be a * procedure that takes a string and its * length, interprets it and sets the bits * in the YOUR_RIGHTS pointed at by the * third argument. */ process_rights((char *) pci->proxyPolicy->policy->data, pci->proxyPolicy->policy->length, &tmp_rights); for(i = 0; i < total_rights / 8; i++) rights->rights[i] &= tmp_rights.rights[i]; } break; } PROXY_CERT_INFO_EXTENSION_free(pci); } else if (!(X509_get_extension_flags(xs) & EXFLAG_CA)) { /* We have an EE certificate, lets use it to set default! */ YOUR_RIGHTS *rights = (YOUR_RIGHTS *)X509_STORE_CTX_get_ex_data(ctx, get_proxy_auth_ex_data_idx(ctx)); /* * The following procedure finds out what rights the * owner of the current certificate has, and sets them * in the YOUR_RIGHTS structure pointed at by the * second argument. */ set_default_rights(xs, rights); } } return ok; } static int my_X509_verify_cert(X509_STORE_CTX *ctx, YOUR_RIGHTS *needed_rights) { int ok; int (*save_verify_cb)(int ok,X509_STORE_CTX *ctx) = X509_STORE_CTX_get_verify_cb(ctx); YOUR_RIGHTS rights; X509_STORE_CTX_set_verify_cb(ctx, verify_callback); X509_STORE_CTX_set_ex_data(ctx, get_proxy_auth_ex_data_idx(ctx), &rights); X509_STORE_CTX_set_flags(ctx, X509_V_FLAG_ALLOW_PROXY_CERTS); ok = X509_verify_cert(ctx); if (ok == 1) { ok = check_needed_rights(rights, needed_rights); } X509_STORE_CTX_set_verify_cb(ctx, save_verify_cb); return ok; }

If you use SSL or TLS, you can easily set up a callback to have the certificates checked properly, using the code above:

SSL_CTX_set_cert_verify_callback(s_ctx, my_X509_verify_cert, &needed_rights);

NOTES

To this date, it seems that proxy certificates have only been used in environments that are aware of them, and no one seems to have investigated how they can be used or misused outside of such an environment.

For that reason, OpenSSL requires that applications aware of proxy certificates must also make that explicit.

subjectAltName and issuerAltName are forbidden in proxy certificates, and this is enforced in OpenSSL. The subject must be the same as the issuer, with one commonName added on.

SEE ALSO

X509_STORE_CTX_set_flags (3), X509_STORE_CTX_set_verify_cb (3), X509_VERIFY_PARAM_set_flags (3), SSL_CTX_set_cert_verify_callback (3), openssl-req (1), openssl-x509 (1), RFC 3820 <https://tools.ietf.org/html/rfc3820>

COPYRIGHT

Copyright 2019-2020 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

549 - Linux cli command CREATE_SERVER

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_SERVER and provides detailed information about the command CREATE_SERVER, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_SERVER.

NAME 🖥️ CREATE_SERVER 🖥️

define a new foreign server

SYNOPSIS

CREATE SERVER [ IF NOT EXISTS ] server_name [ TYPE server_type ] [ VERSION server_version ]
    FOREIGN DATA WRAPPER fdw_name
    [ OPTIONS ( option value [, ... ] ) ]

DESCRIPTION

CREATE SERVER defines a new foreign server. The user who defines the server becomes its owner.

A foreign server typically encapsulates connection information that a foreign-data wrapper uses to access an external data resource. Additional user-specific connection information may be specified by means of user mappings.

The server name must be unique within the database.

Creating a server requires USAGE privilege on the foreign-data wrapper being used.

PARAMETERS

IF NOT EXISTS

Do not throw an error if a server with the same name already exists. A notice is issued in this case. Note that there is no guarantee that the existing server is anything like the one that would have been created.

server_name

The name of the foreign server to be created.

server_type

Optional server type, potentially useful to foreign-data wrappers.

server_version

Optional server version, potentially useful to foreign-data wrappers.

fdw_name

The name of the foreign-data wrapper that manages the server.

OPTIONS ( option value [, … ] )

This clause specifies the options for the server. The options typically define the connection details of the server, but the actual names and values are dependent on the servers foreign-data wrapper.

NOTES

When using the dblink module, a foreign servers name can be used as an argument of the dblink_connect(3) function to indicate the connection parameters. It is necessary to have the USAGE privilege on the foreign server to be able to use it in this way.

If the foreign server supports sort pushdown, it is necessary for it to have the same sort ordering as the local server.

EXAMPLES

Create a server myserver that uses the foreign-data wrapper postgres_fdw:

CREATE SERVER myserver FOREIGN DATA WRAPPER postgres_fdw OPTIONS (host foo, dbname foodb, port 5432);

See postgres_fdw for more details.

COMPATIBILITY

CREATE SERVER conforms to ISO/IEC 9075-9 (SQL/MED).

SEE ALSO

ALTER SERVER (ALTER_SERVER(7)), DROP SERVER (DROP_SERVER(7)), CREATE FOREIGN DATA WRAPPER (CREATE_FOREIGN_DATA_WRAPPER(7)), CREATE FOREIGN TABLE (CREATE_FOREIGN_TABLE(7)), CREATE USER MAPPING (CREATE_USER_MAPPING(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

550 - Linux cli command xkeyboard-config

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command xkeyboard-config and provides detailed information about the command xkeyboard-config, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the xkeyboard-config.

NAME 🖥️ xkeyboard-config 🖥️

config - XKB data description files

DESCRIPTION

xkeyboard-config provides the description files for the X Keyboard Extension (XKB) and for libxkbcommon. Typically it is the task of the desktop environment to apply the requested configuration. Users running an X server can also use the setxkbmap(1) tool to apply keyboard configuration at runtime or configure XKB settings in the xorg.conf(5).

XKB DATA FILES LOAD PATHS

xkeyboard-config provides the XKB data files installed in /usr/share/X11/xkb. User-specific data files may be elsewhere but it depends on the tool whether those files are loaded. For example, the libxkbcommon library will by default load XKB data files from the user’s home directory. See the libxkbcommon documentation for details.

THE CUSTOM LAYOUT

The “custom” layout is a layout that is listed as available to tools reading the data files but is not actually provided by xkeyboard-config. A user may save a layout specification in the /usr/share/X11/xkb/symbols/custom file and that layout will be available to most tools interacting with the xkeyboard-config data files. This is primarily aimed at systems running X where additional lookup paths cannot easily be added.

Because the “custom” layout is merely listed as available but not provided by xkeyboard-config, the layout will not be overwritten on updates.

MODELS

ModelDescription
pc86Generic 86-key PC
pc101Generic 101-key PC
pc102Generic 102-key PC
pc104Generic 104-key PC
pc104altGeneric 104-key PC with L-shaped Enter key
pc105Generic 105-key PC
a4techKB21A4Tech KB-21
a4techKBS8A4Tech KBS-8
a4_rfkb23A4Tech Wireless Desktop RFKB-23
airkeyAcer AirKey V
acer_c300Acer C300
acer_ferrari4kAcer Ferrari 4000
acer_laptopAcer laptop
scorpiusAdvance Scorpius KI
appleApple
applealu_ansiApple Aluminium (ANSI)
applealu_isoApple Aluminium (ISO)
applealu_jisApple Aluminium (JIS)
asus_laptopAsus laptop
azonaRF2300Azona RF2300 Wireless Internet
benqxBenQ X-Touch
benqx730BenQ X-Touch 730
benqx800BenQ X-Touch 800
brotherBrother Internet
btc5090BTC 5090
btc5113rfBTC 5113RF Multimedia
btc5126tBTC 5126T
btc6301urfBTC 6301URF
btc9000BTC 9000
btc9000aBTC 9000A
btc9001ahBTC 9001AH
btc9019uBTC 9019U
btc9116uBTC 9116U Mini Wireless Internet and Gaming
cherryblueCherry Blue Line CyBo@rd
cherryblueaCherry Blue Line CyBo@rd (alt.)
cherrybunlimCherry B.UNLIMITED
cherrycyboardCherry CyBo@rd USB-Hub
cherrycmexpertCherry CyMotion Expert
cymotionlinuxCherry CyMotion Master Linux
cherrybluebCherry CyMotion Master XPress
chiconyChicony Internet
chicony9885Chicony KB-9885
chicony0108Chicony KU-0108
chicony0420Chicony KU-0420
chromebookChromebook
compalfl90Compal FL90
armadaCompaq Armada laptop
compaqeak8Compaq Easy Access
compaqik7Compaq Internet (7 keys)
compaqik13Compaq Internet (13 keys)
compaqik18Compaq Internet (18 keys)
ipaqCompaq iPaq
presarioCompaq Presario laptop
creativedw7000Creative Desktop Wireless 7000
dellDell
dell101Dell 101-key PC
latitudeDell Latitude laptop
inspironDell Inspiron 6000/8000 laptop
precision_mDell Precision M laptop
dellm65Dell Precision M65 laptop
dellsk8125Dell SK-8125
dellsk8135Dell SK-8135
dellusbmmDell USB Multimedia
dexxaDexxa Wireless Desktop
diamondDiamond 9801/9802
dtk2000DTK2000
emachineseMachines m6800 laptop
ennyah_dkb1008Ennyah DKB-1008
everexEverex STEPnote
fscaa1667gFujitsu-Siemens Amilo laptop
geniusGenius Comfy KB-16M/Multimedia KWD-910
geniuscomfyGenius Comfy KB-12e
geniuscomfy2Genius Comfy KB-21e-Scroll
geniuskb19eGenius KB-19e NB
geniuskkb2050hsGenius KKB-2050HS
gyrationGyration
hhkHappy Hacking
hpi6Hewlett-Packard Internet
hpmini110Hewlett-Packard Mini 110 laptop
hpnx9020Hewlett-Packard nx9020
hp5xxHewlett-Packard Omnibook 500
hp500faHewlett-Packard Omnibook 500 FA
hp6000Hewlett-Packard Omnibook 6000/6100
hpxe3gcHewlett-Packard Omnibook XE3 GC
hpxe3gfHewlett-Packard Omnibook XE3 GF
hpxt1000Hewlett-Packard Omnibook XT1000
hpdv5Hewlett-Packard Pavilion dv5
hpzt11xxHewlett-Packard Pavilion ZT1100
hp250xHewlett-Packard SK-2501 Multimedia
honeywell_euroboardHoneywell Euroboard
rapidaccessIBM Rapid Access
rapidaccess2IBM Rapid Access II
ibm_spacesaverIBM Space Saver
thinkpadIBM ThinkPad 560Z/600/600E/A22E
thinkpad60IBM ThinkPad R60/T60/R61/T61
thinkpadz60IBM ThinkPad Z60m/Z60t/Z61m/Z61t
flexproKeytronic FlexPro
kinesisKinesis
logitech_baseLogitech
logiaccessLogitech Access
logicdLogitech Cordless Desktop
logicdaLogitech Cordless Desktop (alt.)
logiex110Logitech Cordless Desktop EX110
logicd_itLogitech Cordless Desktop iTouch
logiclx300Logitech Cordless Desktop LX-300
logicd_navLogitech Cordless Desktop Navigator
logicd_optLogitech Cordless Desktop Optical
logidinovoLogitech diNovo
logidinovoedgeLogitech diNovo Edge
logitech_g15Logitech G15 extra keys via G15daemon
logiikLogitech Internet
logii350Logitech Internet 350
logimelLogitech Internet 350
logicinkLogitech Internet Navigator
itouchLogitech iTouch
logiitcLogitech iTouch Cordless Y-RB6
logiinkseLogitech iTouch Internet Navigator SE
logiinkseusbLogitech iTouch Internet Navigator SE USB
logiultraxLogitech Ultra-X
logiultraxcLogitech Ultra-X Cordless Media Desktop
mx1998Memorex MX1998
mx2500Memorex MX2500 EZ-Access
mx2750Memorex MX2750
microsoftccurve2kMicrosoft Comfort Curve 2000
microsoftinetMicrosoft Internet
microsoftproseMicrosoft Internet Pro (Swedish)
microsoftMicrosoft Natural
microsofteliteMicrosoft Natural Elite
microsoft4000Microsoft Natural Ergonomic 4000
microsoft7000Microsoft Natural Wireless Ergonomic 7000
microsoftproMicrosoft Natural Pro/Internet Pro
microsoftprousbMicrosoft Natural Pro USB/Internet Pro
microsoftprooemMicrosoft Natural Pro OEM
microsoftofficeMicrosoft Office Keyboard
microsoftsurfaceMicrosoft Surface
microsoftmultMicrosoft Wireless Multimedia 1.0A
sk1300NEC SK-1300
sk2500NEC SK-2500
sk6200NEC SK-6200
sk7100NEC SK-7100
omnikey101Northgate OmniKey 101
olpcOLPC
oretecOrtek Multimedia/Internet MCK-800
pc98PC-98
ppkbPinePhone Keyboard
propellerPropeller Voyager KTEZ-1000
qtronixQTronix Scorpius 98N+
samsung4500Samsung SDM 4500P
samsung4510Samsung SDM 4510P
sanwaskbkg3Sanwa Supply SKB-KG3
silvercrestSilvercrest Multimedia Wireless
apex300SteelSeries Apex 300 (Apex RAW)
sun_type6_jpSun Type 6 (Japanese)
sun_type6_jp_usbSun Type 6 USB (Japanese)
sun_type6_unix_usbSun Type 6 USB (Unix)
sun_type6_usbSun Type 6/7 USB
sun_type6_euro_usbSun Type 6/7 USB (European)
sun_type7_usbSun Type 7 USB
sun_type7_euro_usbSun Type 7 USB (European)
sun_type7_jp_usbSun Type 7 USB (Japanese)/Japanese 106-key
sun_type7_unix_usbSun Type 7 USB (Unix)
sp_inetSuper Power Multimedia
svenSVEN Ergonomic 2500
sven303SVEN Slim 303
symplonSymplon PaceBook tablet
targa_v811Targa Visionary 811
toshiba_s3000Toshiba Satellite S3000
teck227Truly Ergonomic 227
teck229Truly Ergonomic 229
trustdaTrust Direct Access
trust_slimlineTrust Slimline
trustTrust Wireless Classic
tm2020TypeMatrix EZ-Reach 2020
tm2030PS2TypeMatrix EZ-Reach 2030 PS2
tm2030USBTypeMatrix EZ-Reach 2030 USB
tm2030USB-102TypeMatrix EZ-Reach 2030 USB (102/105:EU mode)
tm2030USB-106TypeMatrix EZ-Reach 2030 USB (106:JP mode)
unitekkb1925Unitek KB-1925
vsonku306ViewSonic KU-306 Internet
winbookWinbook Model XP5
yahooYahoo! Internet

LAYOUTS

Layout(Variant)Description
alAlbanian
al(plisi)Albanian (Plisi)
al(veqilharxhi)Albanian (Veqilharxhi)
_
etAmharic
_
amArmenian
am(phonetic)Armenian (phonetic)
am(phonetic-alt)Armenian (alt. phonetic)
am(eastern)Armenian (eastern)
am(eastern-alt)Armenian (alt. eastern)
am(western)Armenian (western)
_
araArabic
ara(digits)Arabic (Eastern Arabic numerals)
ara(azerty)Arabic (AZERTY)
ara(azerty_digits)Arabic (AZERTY, Eastern Arabic numerals)
ara(buckwalter)Arabic (Buckwalter)
ara(mac)Arabic (Macintosh)
ara(mac-phonetic)Arabic (Macintosh, phonetic)
ara(olpc)Arabic (OLPC)
_
egArabic (Egypt)
_
iqArabic (Iraq)
iq(ku)Kurdish (Iraq, Latin Q)
iq(ku_alt)Kurdish (Iraq, Latin Alt-Q)
iq(ku_f)Kurdish (Iraq, F)
iq(ku_ara)Kurdish (Iraq, Arabic-Latin)
_
maArabic (Morocco)
ma(tifinagh)Berber (Morocco, Tifinagh)
ma(tifinagh-alt)Berber (Morocco, Tifinagh alt.)
ma(tifinagh-alt-phonetic)Berber (Morocco, Tifinagh phonetic, alt.)
ma(tifinagh-extended)Berber (Morocco, Tifinagh extended)
ma(tifinagh-phonetic)Berber (Morocco, Tifinagh phonetic)
ma(tifinagh-extended-phonetic)Berber (Morocco, Tifinagh extended phonetic)
ma(french)French (Morocco)
ma(rif)Tarifit
_
syArabic (Syria)
sy(syc)Syriac
sy(syc_phonetic)Syriac (phonetic)
sy(ku)Kurdish (Syria, Latin Q)
sy(ku_alt)Kurdish (Syria, Latin Alt-Q)
sy(ku_f)Kurdish (Syria, F)
_
azAzerbaijani
az(cyrillic)Azerbaijani (Cyrillic)
_
mlBambara
ml(fr-oss)French (Mali, alt.)
ml(us-mac)English (Mali, US, Macintosh)
ml(us-intl)English (Mali, US, intl.)
_
bdBangla
bd(probhat)Bangla (Probhat)
_
byBelarusian
by(legacy)Belarusian (legacy)
by(latin)Belarusian (Latin)
by(intl)Belarusian (intl.)
by(phonetic)Belarusian (phonetic)
by(ru)Russian (Belarus)
_
beBelgian
be(oss)Belgian (alt.)
be(oss_latin9)Belgian (Latin-9 only, alt.)
be(iso-alternate)Belgian (ISO, alt.)
be(nodeadkeys)Belgian (no dead keys)
be(wang)Belgian (Wang 724 AZERTY)
_
dzBerber (Algeria, Latin)
dz(ber)Berber (Algeria, Tifinagh)
dz(azerty-deadkeys)Kabyle (AZERTY, with dead keys)
dz(qwerty-gb-deadkeys)Kabyle (QWERTY, UK, with dead keys)
dz(qwerty-us-deadkeys)Kabyle (QWERTY, US, with dead keys)
dz(ar)Arabic (Algeria)
_
baBosnian
ba(alternatequotes)Bosnian (with guillemets)
ba(unicode)Bosnian (with Bosnian digraphs)
ba(unicodeus)Bosnian (US, with Bosnian digraphs)
ba(us)Bosnian (US)
_
braiBraille
brai(left_hand)Braille (left-handed)
brai(left_hand_invert)Braille (left-handed inverted thumb)
brai(right_hand)Braille (right-handed)
brai(right_hand_invert)Braille (right-handed inverted thumb)
_
bgBulgarian
bg(phonetic)Bulgarian (traditional phonetic)
bg(bas_phonetic)Bulgarian (new phonetic)
bg(bekl)Bulgarian (enhanced)
_
mmBurmese
mm(zawgyi)Burmese (Zawgyi)
mm(mnw)Mon
mm(mnw-a1)Mon (A1)
mm(shn)Shan
mm(zgt)Shan (Zawgyi)
_
cnChinese
cn(altgr-pinyin)Hanyu Pinyin Letters (with AltGr dead keys)
cn(mon_trad)Mongolian (Bichig)
cn(mon_trad_todo)Mongolian (Todo)
cn(mon_trad_xibe)Mongolian (Xibe)
cn(mon_trad_manchu)Mongolian (Manchu)
cn(mon_trad_galik)Mongolian (Galik)
cn(mon_todo_galik)Mongolian (Todo Galik)
cn(mon_manchu_galik)Mongolian (Manchu Galik)
cn(tib)Tibetan
cn(tib_asciinum)Tibetan (with ASCII numerals)
cn(ug)Uyghur
_
hrCroatian
hr(alternatequotes)Croatian (with guillemets)
hr(unicode)Croatian (with Croatian digraphs)
hr(unicodeus)Croatian (US, with Croatian digraphs)
hr(us)Croatian (US)
_
czCzech
cz(bksl)Czech (extra backslash)
cz(qwerty)Czech (QWERTY)
cz(qwerty_bksl)Czech (QWERTY, extra backslash)
cz(winkeys)Czech (QWERTZ, Windows)
cz(winkeys-qwerty)Czech (QWERTY, Windows)
cz(qwerty-mac)Czech (QWERTY, Macintosh)
cz(ucw)Czech (UCW, only accented letters)
cz(dvorak-ucw)Czech (US, Dvorak, UCW support)
cz(rus)Russian (Czechia, phonetic)
_
dkDanish
dk(nodeadkeys)Danish (no dead keys)
dk(winkeys)Danish (Windows)
dk(mac)Danish (Macintosh)
dk(mac_nodeadkeys)Danish (Macintosh, no dead keys)
dk(dvorak)Danish (Dvorak)
_
afDari
af(ps)Pashto
af(uz)Uzbek (Afghanistan)
af(fa-olpc)Dari (Afghanistan, OLPC)
af(ps-olpc)Pashto (Afghanistan, OLPC)
af(uz-olpc)Uzbek (Afghanistan, OLPC)
_
mvDhivehi
_
nlDutch
nl(us)Dutch (US)
nl(mac)Dutch (Macintosh)
nl(std)Dutch (standard)
_
btDzongkha
_
auEnglish (Australia)
_
cmEnglish (Cameroon)
cm(french)French (Cameroon)
cm(qwerty)Cameroon Multilingual (QWERTY, intl.)
cm(azerty)Cameroon (AZERTY, intl.)
cm(dvorak)Cameroon (Dvorak, intl.)
cm(mmuock)Mmuock
_
ghEnglish (Ghana)
gh(generic)English (Ghana, multilingual)
gh(gillbt)English (Ghana, GILLBT)
gh(akan)Akan
gh(avn)Avatime
gh(ewe)Ewe
gh(fula)Fula
gh(ga)Ga
gh(hausa)Hausa (Ghana)
_
nzEnglish (New Zealand)
nz(mao)Maori
_
ngEnglish (Nigeria)
ng(hausa)Hausa (Nigeria)
ng(igbo)Igbo
ng(yoruba)Yoruba
_
zaEnglish (South Africa)
_
gbEnglish (UK)
gb(extd)English (UK, extended, Windows)
gb(intl)English (UK, intl., with dead keys)
gb(dvorak)English (UK, Dvorak)
gb(dvorakukp)English (UK, Dvorak, with UK punctuation)
gb(mac)English (UK, Macintosh)
gb(mac_intl)English (UK, Macintosh, intl.)
gb(colemak)English (UK, Colemak)
gb(colemak_dh)English (UK, Colemak-DH)
gb(gla)Scottish Gaelic
gb(pl)Polish (British keyboard)
_
usEnglish (US)
us(euro)English (US, euro on 5)
us(intl)English (US, intl., with dead keys)
us(alt-intl)English (US, alt. intl.)
us(altgr-intl)English (intl., with AltGr dead keys)
us(mac)English (Macintosh)
us(colemak)English (Colemak)
us(colemak_dh)English (Colemak-DH)
us(colemak_dh_wide)English (Colemak-DH Wide)
us(colemak_dh_ortho)English (Colemak-DH Ortholinear)
us(colemak_dh_iso)English (Colemak-DH ISO)
us(colemak_dh_wide_iso)English (Colemak-DH Wide ISO)
us(dvorak)English (Dvorak)
us(dvorak-intl)English (Dvorak, intl., with dead keys)
us(dvorak-alt-intl)English (Dvorak, alt. intl.)
us(dvorak-l)English (Dvorak, left-handed)
us(dvorak-r)English (Dvorak, right-handed)
us(dvorak-classic)English (classic Dvorak)
us(dvp)English (programmer Dvorak)
us(dvorak-mac)English (Dvorak, Macintosh)
us(norman)English (Norman)
us(symbolic)English (US, Symbolic)
us(workman)English (Workman)
us(workman-intl)English (Workman, intl., with dead keys)
us(olpc2)English (the divide/multiply toggle the layout)
us(chr)Cherokee
us(haw)Hawaiian
us(rus)Russian (US, phonetic)
us(hbs)Serbo-Croatian (US)
_
epoEsperanto
epo(legacy)Esperanto (legacy)
_
eeEstonian
ee(nodeadkeys)Estonian (no dead keys)
ee(dvorak)Estonian (Dvorak)
ee(us)Estonian (US)
_
foFaroese
fo(nodeadkeys)Faroese (no dead keys)
_
phFilipino
ph(qwerty-bay)Filipino (QWERTY, Baybayin)
ph(capewell-dvorak)Filipino (Capewell-Dvorak, Latin)
ph(capewell-dvorak-bay)Filipino (Capewell-Dvorak, Baybayin)
ph(capewell-qwerf2k6)Filipino (Capewell-QWERF 2006, Latin)
ph(capewell-qwerf2k6-bay)Filipino (Capewell-QWERF 2006, Baybayin)
ph(colemak)Filipino (Colemak, Latin)
ph(colemak-bay)Filipino (Colemak, Baybayin)
ph(dvorak)Filipino (Dvorak, Latin)
ph(dvorak-bay)Filipino (Dvorak, Baybayin)
_
fiFinnish
fi(winkeys)Finnish (Windows)
fi(classic)Finnish (classic)
fi(nodeadkeys)Finnish (classic, no dead keys)
fi(mac)Finnish (Macintosh)
fi(smi)Northern Saami (Finland)
_
frFrench
fr(nodeadkeys)French (no dead keys)
fr(oss)French (alt.)
fr(oss_nodeadkeys)French (alt., no dead keys)
fr(oss_latin9)French (alt., Latin-9 only)
fr(latin9)French (legacy, alt.)
fr(latin9_nodeadkeys)French (legacy, alt., no dead keys)
fr(azerty)French (AZERTY)
fr(afnor)French (AZERTY, AFNOR)
fr(bepo)French (BEPO)
fr(bepo_latin9)French (BEPO, Latin-9 only)
fr(bepo_afnor)French (BEPO, AFNOR)
fr(dvorak)French (Dvorak)
fr(ergol)French (Ergo‑L)
fr(ergol_iso)French (Ergo‑L, ISO variant)
fr(mac)French (Macintosh)
fr(us)French (US)
fr(bre)Breton (France)
fr(oci)Occitan
fr(geo)Georgian (France, AZERTY Tskapo)
_
caFrench (Canada)
ca(fr-dvorak)French (Canada, Dvorak)
ca(fr-legacy)French (Canada, legacy)
ca(multix)Canadian (CSA)
ca(eng)English (Canada)
ca(ike)Inuktitut
_
cdFrench (Democratic Republic of the Congo)
_
tgFrench (Togo)
_
geGeorgian
ge(ergonomic)Georgian (ergonomic)
ge(mess)Georgian (MESS)
ge(os)Ossetian (Georgia)
ge(ru)Russian (Georgia)
_
deGerman
de(deadacute)German (dead acute)
de(deadgraveacute)German (dead grave acute)
de(deadtilde)German (dead tilde)
de(nodeadkeys)German (no dead keys)
de(e1)German (E1)
de(e2)German (E2)
de(T3)German (T3)
de(us)German (US)
de(dvorak)German (Dvorak)
de(mac)German (Macintosh)
de(mac_nodeadkeys)German (Macintosh, no dead keys)
de(neo)German (Neo 2)
de(qwerty)German (QWERTY)
de(dsb)Lower Sorbian
de(dsb_qwertz)Lower Sorbian (QWERTZ)
de(ro)Romanian (Germany)
de(ro_nodeadkeys)Romanian (Germany, no dead keys)
de(ru)Russian (Germany, phonetic)
de(tr)Turkish (Germany)
_
atGerman (Austria)
at(nodeadkeys)German (Austria, no dead keys)
at(mac)German (Austria, Macintosh)
_
chGerman (Switzerland)
ch(de_nodeadkeys)German (Switzerland, no dead keys)
ch(de_mac)German (Switzerland, Macintosh)
ch(legacy)German (Switzerland, legacy)
ch(fr)French (Switzerland)
ch(fr_nodeadkeys)French (Switzerland, no dead keys)
ch(fr_mac)French (Switzerland, Macintosh)
_
grGreek
gr(simple)Greek (simple)
gr(nodeadkeys)Greek (no dead keys)
gr(polytonic)Greek (polytonic)
_
ilHebrew
il(si2)Hebrew (SI-1452-2)
il(lyx)Hebrew (lyx)
il(phonetic)Hebrew (phonetic)
il(biblical)Hebrew (Biblical, Tiro)
_
huHungarian
hu(standard)Hungarian (standard)
hu(nodeadkeys)Hungarian (no dead keys)
hu(qwerty)Hungarian (QWERTY)
hu(101_qwertz_comma_dead)Hungarian (QWERTZ, 101-key, comma, dead keys)
hu(101_qwertz_comma_nodead)Hungarian (QWERTZ, 101-key, comma, no dead keys)
hu(101_qwertz_dot_dead)Hungarian (QWERTZ, 101-key, dot, dead keys)
hu(101_qwertz_dot_nodead)Hungarian (QWERTZ, 101-key, dot, no dead keys)
hu(101_qwerty_comma_dead)Hungarian (QWERTY, 101-key, comma, dead keys)
hu(101_qwerty_comma_nodead)Hungarian (QWERTY, 101-key, comma, no dead keys)
hu(101_qwerty_dot_dead)Hungarian (QWERTY, 101-key, dot, dead keys)
hu(101_qwerty_dot_nodead)Hungarian (QWERTY, 101-key, dot, no dead keys)
hu(102_qwertz_comma_dead)Hungarian (QWERTZ, 102-key, comma, dead keys)
hu(102_qwertz_comma_nodead)Hungarian (QWERTZ, 102-key, comma, no dead keys)
hu(102_qwertz_dot_dead)Hungarian (QWERTZ, 102-key, dot, dead keys)
hu(102_qwertz_dot_nodead)Hungarian (QWERTZ, 102-key, dot, no dead keys)
hu(102_qwerty_comma_dead)Hungarian (QWERTY, 102-key, comma, dead keys)
hu(102_qwerty_comma_nodead)Hungarian (QWERTY, 102-key, comma, no dead keys)
hu(102_qwerty_dot_dead)Hungarian (QWERTY, 102-key, dot, dead keys)
hu(102_qwerty_dot_nodead)Hungarian (QWERTY, 102-key, dot, no dead keys)
_
isIcelandic
is(mac_legacy)Icelandic (Macintosh, legacy)
is(mac)Icelandic (Macintosh)
is(dvorak)Icelandic (Dvorak)
_
inIndian
in(asm-kagapa)Assamese (KaGaPa, phonetic)
in(ben)Bangla (India)
in(ben_probhat)Bangla (India, Probhat)
in(ben_baishakhi)Bangla (India, Baishakhi)
in(ben_bornona)Bangla (India, Bornona)
in(ben-kagapa)Bangla (India, KaGaPa, phonetic)
in(ben_gitanjali)Bangla (India, Gitanjali)
in(ben_inscript)Bangla (India, Baishakhi InScript)
in(eng)English (India, with rupee)
in(guj)Gujarati
in(guj-kagapa)Gujarati (KaGaPa, phonetic)
in(bolnagri)Hindi (Bolnagri)
in(hin-wx)Hindi (Wx)
in(hin-kagapa)Hindi (KaGaPa, phonetic)
in(kan)Kannada
in(kan-kagapa)Kannada (KaGaPa, phonetic)
in(mal)Malayalam
in(mal_lalitha)Malayalam (Lalitha)
in(mal_enhanced)Malayalam (enhanced InScript, with rupee)
in(mal_poorna)Malayalam (Poorna, extended InScript)
in(mni)Manipuri (Meitei)
in(mar-kagapa)Marathi (KaGaPa, phonetic)
in(marathi)Marathi (enhanced InScript)
in(ori)Oriya
in(ori-bolnagri)Oriya (Bolnagri)
in(ori-wx)Oriya (Wx)
in(guru)Punjabi (Gurmukhi)
in(jhelum)Punjabi (Gurmukhi Jhelum)
in(san-kagapa)Sanskrit (KaGaPa, phonetic)
in(sat)Santali (Ol Chiki)
in(tamilnet)Tamil (TamilNet '99)
in(tamilnet_tamilnumbers)Tamil (TamilNet '99 with Tamil numerals)
in(tamilnet_TAB)Tamil (TamilNet '99, TAB encoding)
in(tamilnet_TSCII)Tamil (TamilNet '99, TSCII encoding)
in(tam)Tamil (InScript, with Arabic numerals)
in(tam_tamilnumbers)Tamil (InScript, with Tamil numerals)
in(tel)Telugu
in(tel-kagapa)Telugu (KaGaPa, phonetic)
in(tel-sarala)Telugu (Sarala)
in(urd-phonetic)Urdu (phonetic)
in(urd-phonetic3)Urdu (alt. phonetic)
in(urd-winkeys)Urdu (Windows)
in(iipa)Indic IPA
_
idIndonesian (Latin)
id(melayu-phonetic)Indonesian (Arab Melayu, phonetic)
id(melayu-phoneticx)Indonesian (Arab Melayu, extended phonetic)
id(pegon-phonetic)Indonesian (Arab Pegon, phonetic)
id(javanese)Javanese
_
ieIrish
ie(UnicodeExpert)Irish (UnicodeExpert)
ie(CloGaelach)CloGaelach
ie(ogam)Ogham
ie(ogam_is434)Ogham (IS434)
_
itItalian
it(nodeadkeys)Italian (no dead keys)
it(winkeys)Italian (Windows)
it(mac)Italian (Macintosh)
it(us)Italian (US)
it(ibm)Italian (IBM 142)
it(fur)Friulian (Italy)
it(scn)Sicilian
it(geo)Georgian (Italy)
_
jpJapanese
jp(kana)Japanese (Kana)
jp(kana86)Japanese (Kana 86)
jp(OADG109A)Japanese (OADG 109A)
jp(mac)Japanese (Macintosh)
jp(dvorak)Japanese (Dvorak)
_
kzKazakh
kz(kazrus)Kazakh (with Russian)
kz(ext)Kazakh (extended)
kz(latin)Kazakh (Latin)
kz(ruskaz)Russian (Kazakhstan, with Kazakh)
_
khKhmer (Cambodia)
_
krKorean
kr(kr104)Korean (101/104-key compatible)
_
kgKyrgyz
kg(phonetic)Kyrgyz (phonetic)
_
laLao
la(stea)Lao (STEA)
_
lvLatvian
lv(apostrophe)Latvian (apostrophe)
lv(tilde)Latvian (tilde)
lv(fkey)Latvian (F)
lv(modern)Latvian (Modern Latin)
lv(modern-cyr)Latvian (Modern Cyrillic)
lv(ergonomic)Latvian (ergonomic, ŪGJRMV)
lv(adapted)Latvian (adapted)
_
ltLithuanian
lt(std)Lithuanian (standard)
lt(us)Lithuanian (US)
lt(ibm)Lithuanian (IBM)
lt(lekp)Lithuanian (LEKP)
lt(lekpa)Lithuanian (LEKPa)
lt(ratise)Lithuanian (Ratise)
lt(sgs)Samogitian
_
mkMacedonian
mk(nodeadkeys)Macedonian (no dead keys)
_
myMalay (Jawi, Arabic Keyboard)
my(phonetic)Malay (Jawi, phonetic)
_
mtMaltese
mt(us)Maltese (US)
mt(alt-us)Maltese (US, with AltGr overrides)
mt(alt-gb)Maltese (UK, with AltGr overrides)
_
mdMoldavian
md(gag)Gagauz (Moldova)
_
mnMongolian
_
meMontenegrin
me(cyrillic)Montenegrin (Cyrillic)
me(cyrillicyz)Montenegrin (Cyrillic, ZE and ZHE swapped)
me(cyrillicalternatequotes)Montenegrin (Cyrillic, with guillemets)
me(latinunicode)Montenegrin (Latin, Unicode)
me(latinyz)Montenegrin (Latin, QWERTY)
me(latinunicodeyz)Montenegrin (Latin, Unicode, QWERTY)
me(latinalternatequotes)Montenegrin (Latin, with guillemets)
_
npNepali
_
gnN'Ko (AZERTY)
_
noNorwegian
no(nodeadkeys)Norwegian (no dead keys)
no(winkeys)Norwegian (Windows)
no(mac)Norwegian (Macintosh)
no(mac_nodeadkeys)Norwegian (Macintosh, no dead keys)
no(colemak)Norwegian (Colemak)
no(colemak_dh)Norwegian (Colemak-DH)
no(colemak_dh_wide)Norwegian (Colemak-DH Wide)
no(dvorak)Norwegian (Dvorak)
no(smi)Northern Saami (Norway)
no(smi_nodeadkeys)Northern Saami (Norway, no dead keys)
_
irPersian
ir(pes_keypad)Persian (with Persian keypad)
ir(winkeys)Persian (Windows)
ir(azb)Azerbaijani (Iran)
ir(ku)Kurdish (Iran, Latin Q)
ir(ku_alt)Kurdish (Iran, Latin Alt-Q)
ir(ku_f)Kurdish (Iran, F)
ir(ku_ara)Kurdish (Iran, Arabic-Latin)
_
plPolish
pl(legacy)Polish (legacy)
pl(qwertz)Polish (QWERTZ)
pl(dvorak)Polish (Dvorak)
pl(dvorak_quotes)Polish (Dvorak, with Polish quotes on quotemark key)
pl(dvorak_altquotes)Polish (Dvorak, with Polish quotes on key 1)
pl(dvp)Polish (programmer Dvorak)
pl(csb)Kashubian
pl(szl)Silesian
pl(ru_phonetic_dvorak)Russian (Poland, phonetic Dvorak)
_
ptPortuguese
pt(nodeadkeys)Portuguese (no dead keys)
pt(mac)Portuguese (Macintosh)
pt(mac_nodeadkeys)Portuguese (Macintosh, no dead keys)
pt(nativo)Portuguese (Nativo)
pt(nativo-us)Portuguese (Nativo for US keyboards)
pt(nativo-epo)Esperanto (Portugal, Nativo)
_
brPortuguese (Brazil)
br(nodeadkeys)Portuguese (Brazil, no dead keys)
br(dvorak)Portuguese (Brazil, Dvorak)
br(nativo)Portuguese (Brazil, Nativo)
br(nativo-us)Portuguese (Brazil, Nativo for US keyboards)
br(thinkpad)Portuguese (Brazil, IBM/Lenovo ThinkPad)
br(nativo-epo)Esperanto (Brazil, Nativo)
br(rus)Russian (Brazil, phonetic)
_
roRomanian
ro(std)Romanian (standard)
ro(winkeys)Romanian (Windows)
_
ruRussian
ru(phonetic)Russian (phonetic)
ru(phonetic_winkeys)Russian (phonetic, Windows)
ru(phonetic_YAZHERTY)Russian (phonetic, YAZHERTY)
ru(phonetic_azerty)Russian (phonetic, AZERTY)
ru(phonetic_dvorak)Russian (phonetic, Dvorak)
ru(typewriter)Russian (typewriter)
ru(ruchey_ru)Russian (engineering, RU)
ru(ruchey_en)Russian (engineering, EN)
ru(legacy)Russian (legacy)
ru(typewriter-legacy)Russian (typewriter, legacy)
ru(dos)Russian (DOS)
ru(mac)Russian (Macintosh)
ru(ab)Abkhazian (Russia)
ru(bak)Bashkirian
ru(cv)Chuvash
ru(cv_latin)Chuvash (Latin)
ru(xal)Kalmyk
ru(kom)Komi
ru(chm)Mari
ru(os_legacy)Ossetian (legacy)
ru(os_winkeys)Ossetian (Windows)
ru(srp)Serbian (Russia)
ru(tt)Tatar
ru(udm)Udmurt
ru(sah)Yakut
_
rsSerbian
rs(alternatequotes)Serbian (Cyrillic, with guillemets)
rs(yz)Serbian (Cyrillic, ZE and ZHE swapped)
rs(latin)Serbian (Latin)
rs(latinalternatequotes)Serbian (Latin, with guillemets)
rs(latinunicode)Serbian (Latin, Unicode)
rs(latinyz)Serbian (Latin, QWERTY)
rs(latinunicodeyz)Serbian (Latin, Unicode, QWERTY)
rs(rue)Pannonian Rusyn
_
lkSinhala (phonetic)
lk(us)Sinhala (US)
lk(tam_unicode)Tamil (Sri Lanka, TamilNet '99)
lk(tam_TAB)Tamil (Sri Lanka, TamilNet '99, TAB encoding)
_
skSlovak
sk(bksl)Slovak (extra backslash)
sk(qwerty)Slovak (QWERTY)
sk(qwerty_bksl)Slovak (QWERTY, extra backslash)
_
siSlovenian
si(alternatequotes)Slovenian (with guillemets)
si(us)Slovenian (US)
_
esSpanish
es(nodeadkeys)Spanish (no dead keys)
es(deadtilde)Spanish (dead tilde)
es(winkeys)Spanish (Windows)
es(dvorak)Spanish (Dvorak)
es(ast)Asturian (Spain, with bottom-dot H and L)
es(cat)Catalan (Spain, with middle-dot L)
_
latamSpanish (Latin American)
latam(nodeadkeys)Spanish (Latin American, no dead keys)
latam(deadtilde)Spanish (Latin American, dead tilde)
latam(dvorak)Spanish (Latin American, Dvorak)
latam(colemak)Spanish (Latin American, Colemak)
_
keSwahili (Kenya)
ke(kik)Kikuyu
_
tzSwahili (Tanzania)
_
seSwedish
se(nodeadkeys)Swedish (no dead keys)
se(dvorak)Swedish (Dvorak)
se(us_dvorak)Swedish (Dvorak, intl.)
se(svdvorak)Swedish (Svdvorak)
se(mac)Swedish (Macintosh)
se(us)Swedish (US)
se(swl)Swedish Sign Language
se(smi)Northern Saami (Sweden)
se(rus)Russian (Sweden, phonetic)
_
twTaiwanese
tw(indigenous)Taiwanese (indigenous)
tw(saisiyat)Saisiyat (Taiwan)
_
tjTajik
tj(legacy)Tajik (legacy)
_
thThai
th(tis)Thai (TIS-820.2538)
th(pat)Thai (Pattachote)
_
bwTswana
_
tmTurkmen
tm(alt)Turkmen (Alt-Q)
_
trTurkish
tr(f)Turkish (F)
tr(e)Turkish (E)
tr(alt)Turkish (Alt-Q)
tr(intl)Turkish (intl., with dead keys)
tr(ku)Kurdish (Turkey, Latin Q)
tr(ku_f)Kurdish (Turkey, F)
tr(ku_alt)Kurdish (Turkey, Latin Alt-Q)
_
uaUkrainian
ua(phonetic)Ukrainian (phonetic)
ua(typewriter)Ukrainian (typewriter)
ua(winkeys)Ukrainian (Windows)
ua(macOS)Ukrainian (macOS)
ua(legacy)Ukrainian (legacy)
ua(homophonic)Ukrainian (homophonic)
ua(crh)Crimean Tatar (Turkish Q)
ua(crh_f)Crimean Tatar (Turkish F)
ua(crh_alt)Crimean Tatar (Turkish Alt-Q)
_
pkUrdu (Pakistan)
pk(urd-crulp)Urdu (Pakistan, CRULP)
pk(urd-nla)Urdu (Pakistan, NLA)
pk(ara)Arabic (Pakistan)
pk(snd)Sindhi
_
uzUzbek
uz(latin)Uzbek (Latin)
_
vnVietnamese
vn(us)Vietnamese (US)
vn(fr)Vietnamese (France)
_
snWolof
_
customA user-defined custom Layout

OPTIONS

Switching to another layout

OptionDescription
grp:switchRight Alt (while pressed)
grp:lswitchLeft Alt (while pressed)
grp:lwin_switchLeft Win (while pressed)
grp:rwin_switchRight Win (while pressed)
grp:win_switchAny Win (while pressed)
grp:menu_switchMenu (while pressed), Shift+Menu for Menu
grp:caps_switchCaps Lock (while pressed), Alt+Caps Lock for the original Caps Lock action
grp:rctrl_switchRight Ctrl (while pressed)
grp:toggleRight Alt
grp:lalt_toggleLeft Alt
grp:caps_toggleCaps Lock
grp:shift_caps_toggleShift+Caps Lock
grp:caps_selectCaps Lock to first layout; Shift+Caps Lock to second layout
grp:win_menu_selectLeft Win to first layout; Right Win/Menu to second layout
grp:ctrl_selectLeft Ctrl to first layout; Right Ctrl to second layout
grp:alt_caps_toggleAlt+Caps Lock
grp:shifts_toggleBoth Shifts together
grp:alts_toggleBoth Alts together
grp:alt_altgr_toggleBoth Alts together; AltGr alone chooses third level
grp:ctrls_toggleBoth Ctrls together
grp:ctrl_shift_toggleCtrl+Shift
grp:lctrl_lshift_toggleLeft Ctrl+Left Shift
grp:rctrl_rshift_toggleRight Ctrl+Right Shift
grp:ctrl_shift_toggle_bidirLeft Ctrl+Left Shift chooses previous layout, Right Ctrl + Right Shift chooses next layout
grp:ctrl_alt_toggleAlt+Ctrl
grp:lctrl_lalt_toggleLeft Alt+Left Ctrl
grp:rctrl_ralt_toggleRight Alt+Right Ctrl
grp:ctrl_alt_toggle_bidirLeft Ctrl+Left Alt chooses previous layout, Right Ctrl + Right Alt chooses next layout
grp:alt_shift_toggleAlt+Shift
grp:lalt_lshift_toggleLeft Alt+Left Shift
grp:ralt_rshift_toggleRight Alt+Right Shift
grp:alt_shift_toggle_bidirLeft Alt+Left Shift chooses previous layout, Right Alt + Right Shift chooses next layout
grp:menu_toggleMenu
grp:lwin_toggleLeft Win
grp:alt_space_toggleAlt+Space
grp:win_space_toggleWin+Space
grp:ctrl_space_toggleCtrl+Space
grp:rwin_toggleRight Win
grp:lshift_toggleLeft Shift
grp:rshift_toggleRight Shift
grp:lctrl_toggleLeft Ctrl
grp:rctrl_toggleRight Ctrl
grp:sclk_toggleScroll Lock
grp:lctrl_lwin_rctrl_menuCtrl+Left Win to first layout; Ctrl+Menu to second layout
grp:lctrl_lwin_toggleLeft Ctrl+Left Win

Key to choose the 2nd level

OptionDescription
lv2:lsgt_switchThe "< >" key

Key to choose the 3rd level

OptionDescription
lv3:switchRight Ctrl
lv3:menu_switchMenu
lv3:win_switchAny Win
lv3:lwin_switchLeft Win
lv3:rwin_switchRight Win
lv3:alt_switchAny Alt
lv3:lalt_switchLeft Alt
lv3:ralt_switchRight Alt
lv3:ralt_switch_multikeyRight Alt; Shift+Right Alt as Compose
lv3:ralt_altRight Alt never chooses 3rd level
lv3:enter_switchEnter on keypad
lv3:caps_switchCaps Lock
lv3:bksl_switchBackslash
lv3:lsgt_switchThe "< >" key
lv3:caps_switch_latchCaps Lock; acts as onetime lock when pressed together with another 3rd-level chooser
lv3:bksl_switch_latchBackslash; acts as onetime lock when pressed together with another 3rd level chooser
lv3:lsgt_switch_latchThe "< >" key; acts as onetime lock when pressed together with another 3rd level chooser

Ctrl position

OptionDescription
ctrl:nocapsCaps Lock as Ctrl
ctrl:lctrl_metaLeft Ctrl as Meta
ctrl:swapcapsSwap Ctrl and Caps Lock
ctrl:grouptoggle_capscontrolCaps Lock as Ctrl, Left Control switches to another layout
ctrl:hyper_capscontrolCaps Lock as Ctrl, Ctrl as Hyper
ctrl:ac_ctrlTo the left of "A"
ctrl:aa_ctrlAt the bottom left
ctrl:rctrl_raltRight Ctrl as Right Alt
ctrl:ralt_rctrlRight Alt as Right Control
ctrl:menu_rctrlMenu as Right Ctrl
ctrl:swap_lalt_lctlSwap Left Alt with Left Ctrl
ctrl:swap_ralt_rctlSwap Right Alt with Right Ctrl
ctrl:swap_lwin_lctlSwap Left Win with Left Ctrl
ctrl:swap_rwin_rctlSwap Right Win with Right Ctrl
ctrl:swap_lalt_lctl_lwinLeft Alt as Ctrl, Left Ctrl as Win, Left Win as Left Alt

Use keyboard LED to show alternative layout

OptionDescription
grp_led:numNum Lock
grp_led:capsCaps Lock
grp_led:scrollScroll Lock

Use keyboard LED to indicate modifiers

OptionDescription
mod_led:composeCompose

Layout of numeric keypad

OptionDescription
keypad:legacyLegacy
keypad:ossUnicode arrows and math operators
keypad:futureUnicode arrows and math operators on default level
keypad:legacy_wangLegacy Wang 724
keypad:oss_wangWang 724 keypad with Unicode arrows and math operators
keypad:future_wangWang 724 keypad with Unicode arrows and math operators on default level
keypad:hexHexadecimal
keypad:atmPhone and ATM style

Numeric keypad Delete behavior

OptionDescription
kpdl:dotLegacy key with dot
kpdl:commaLegacy key with comma
kpdl:dotossFour-level key with dot
kpdl:dotoss_latin9Four-level key with dot, Latin-9 only
kpdl:commaossFour-level key with comma
kpdl:momayyezossFour-level key with momayyez
kpdl:kpossFour-level key with abstract separators
kpdl:semiSemicolon on third level

Caps Lock behavior

OptionDescription
caps:internalCaps Lock uses internal capitalization; Shift "pauses" Caps Lock
caps:internal_nocancelCaps Lock uses internal capitalization; Shift does not affect Caps Lock
caps:shiftCaps Lock acts as Shift with locking; Shift "pauses" Caps Lock
caps:shift_nocancelCaps Lock acts as Shift with locking; Shift does not affect Caps Lock
caps:capslockCaps Lock toggles normal capitalization of alphabetic characters
caps:shiftlockCaps Lock toggles Shift Lock (affects all keys)
caps:swapescapeSwap Esc and Caps Lock
caps:escapeMake Caps Lock an additional Esc
caps:escape_shifted_capslockMake Caps Lock an additional Esc, but Shift + Caps Lock is the regular Caps Lock
caps:backspaceMake Caps Lock an additional Backspace
caps:superMake Caps Lock an additional Super
caps:hyperMake Caps Lock an additional Hyper
caps:menuMake Caps Lock an additional Menu key
caps:numlockMake Caps Lock an additional Num Lock
caps:ctrl_modifierMake Caps Lock act as an additional Ctrl modifier, but keep identifying as Caps Lock
caps:digits_rowCaps Lock gives digits on the digits row (Azerty layouts)
caps:noneCaps Lock is disabled

Alt and Win behavior

OptionDescription
altwin:menuAdd the standard behavior to Menu key
altwin:menu_winMenu is mapped to Win
altwin:meta_altAlt and Meta are on Alt
altwin:alt_winAlt is mapped to Win and the usual Alt
altwin:ctrl_winCtrl is mapped to Win and the usual Ctrl
altwin:ctrl_rwinCtrl is mapped to Right Win and the usual Ctrl
altwin:ctrl_alt_winCtrl is mapped to Alt, Alt to Win
altwin:meta_winMeta is mapped to Win
altwin:left_meta_winMeta is mapped to Left Win
altwin:hyper_winHyper is mapped to Win
altwin:alt_super_winAlt is mapped to Right Win, Super to Menu
altwin:swap_lalt_lwinLeft Alt is swapped with Left Win
altwin:swap_alt_winAlt is swapped with Win
altwin:prtsc_rwinWin is mapped to PrtSc and the usual Win

Position of Compose key

OptionDescription
compose:raltRight Alt
compose:lwinLeft Win
compose:lwin-altgr3rd level of Left Win
compose:rwinRight Win
compose:rwin-altgr3rd level of Right Win
compose:menuMenu
compose:menu-altgr3rd level of Menu
compose:lctrlLeft Ctrl
compose:lctrl-altgr3rd level of Left Ctrl
compose:rctrlRight Ctrl
compose:rctrl-altgr3rd level of Right Ctrl
compose:capsCaps Lock
compose:caps-altgr3rd level of Caps Lock
compose:102The "< >" key
compose:102-altgr3rd level of the "< >" key
compose:pausPause
compose:insInsert
compose:prscPrtSc
compose:sclkScroll Lock

Compatibility options

OptionDescription
numpad:pcDefault numeric keypad keys
numpad:macNumeric keypad always enters digits (as in macOS)
numpad:microsoftNum Lock on: digits; Shift for arrows. Num Lock off: arrows (as in Windows)
numpad:shift3Shift does not cancel Num Lock, chooses 3rd level instead
scrolllock:mod3Map Scroll Lock to Mod3
srvrkeys:noneSpecial keys (Ctrl+Alt+<key>) handled in a server
apple:alupckeysApple Aluminium emulates Pause, PrtSc, Scroll Lock
apple:jp_oadg109aJapanese Apple keyboards emulate OADG109A backslash
apple:jp_pc106Japanese Apple keyboards emulate PC106 backslash
shift:breaks_capsShift cancels Caps Lock
misc:typoEnable extra typographic characters
misc:aplEnable APL overlay characters
shift:both_capslockBoth Shifts together enable Caps Lock
shift:both_capslock_cancelBoth Shifts together enable Caps Lock; one Shift key disables it
shift:both_shiftlockBoth Shifts together enable Shift Lock
keypad:pointerkeysShift + Num Lock enables PointerKeys
grab:break_actionsAllow breaking grabs with keyboard actions (warning: security risk)
grab:debugAllow grab and window tree logging

Currency signs

OptionDescription
eurosign:eEuro on E, third level
eurosign:EEuro on E, fourth level
eurosign:2Euro on 2
eurosign:4Euro on 4
eurosign:5Euro on 5
rupeesign:4Rupee on 4

Key to choose the 5th level

OptionDescription
lv5:caps_switchCaps Lock chooses 5th level
lv5:lsgt_switchThe "< >" key chooses 5th level
lv5:ralt_switchRight Alt chooses 5th level
lv5:menu_switchMenu chooses 5th level
lv5:rctrl_switchRight Ctrl chooses 5th level
lv5:lsgt_switch_lockThe "< >" key chooses 5th level and acts as a one-time lock if pressed with another 5th level chooser
lv5:ralt_switch_lockRight Alt chooses 5th level and acts as a one-time lock if pressed with another 5th level chooser
lv5:lwin_switch_lockLeft Win chooses 5th level and acts as a one-time lock if pressed with another 5th level chooser
lv5:rwin_switch_lockRight Win chooses 5th level and acts as a one-time lock if pressed with another 5th level chooser

Non-breaking space input

OptionDescription
nbsp:noneUsual space at any level
nbsp:level2Non-breaking space at the 2nd level
nbsp:level3Non-breaking space at the 3rd level
nbsp:level3nNon-breaking space at the 3rd level, thin non-breaking space at the 4th level
nbsp:level4Non-breaking space at the 4th level
nbsp:level4nNon-breaking space at the 4th level, thin non-breaking space at the 6th level
nbsp:level4nlNon-breaking space at the 4th level, thin non-breaking space at the 6th level (via Ctrl+Shift)
nbsp:zwnj2Zero-width non-joiner at the 2nd level
nbsp:zwnj2zwj3Zero-width non-joiner at the 2nd level, zero-width joiner at the 3rd level
nbsp:zwnj2zwj3nb4Zero-width non-joiner at the 2nd level, zero-width joiner at the 3rd level, non-breaking space at the 4th level
nbsp:zwnj2nb3Zero-width non-joiner at the 2nd level, non-breaking space at the 3rd level
nbsp:zwnj2nb3zwj4Zero-width non-joiner at the 2nd level, non-breaking space at the 3rd level, zero-width joiner at the 4th level
nbsp:zwnj2nb3nnb4Zero-width non-joiner at the 2nd level, non-breaking space at the 3rd level, thin non-breaking space at the 4th level
nbsp:zwnj3zwj4Zero-width non-joiner at the 3rd level, zero-width joiner at the 4th level

Japanese keyboard options

OptionDescription
japan:kana_lockKana Lock key is locking
japan:nicola_f_bsNICOLA-F style Backspace
japan:hztg_escapeMake Zenkaku Hankaku an additional Esc

Korean Hangul/Hanja keys

OptionDescription
korean:ralt_hangulMake right Alt a Hangul key
korean:rctrl_hangulMake right Ctrl a Hangul key
korean:ralt_hanjaMake right Alt a Hanja key
korean:rctrl_hanjaMake right Ctrl a Hanja key

Esperanto letters with superscripts

OptionDescription
esperanto:qwertyAt the corresponding key in a QWERTY layout
esperanto:dvorakAt the corresponding key in a Dvorak layout
esperanto:colemakAt the corresponding key in a Colemak layout

Old Solaris keycodes compatibility

OptionDescription
solaris:sun_compatSun key compatibility

Key sequence to kill the X server

OptionDescription
terminate:ctrl_alt_bkspCtrl+Alt+Backspace

Miscellaneous options

OptionDescription
custom:typesUse user-defined custom XKB types

FILES

/usr/share/X11/xkb/compat

/usr/share/X11/xkb/compiled

/usr/share/X11/xkb/geometry

/usr/share/X11/xkb/keycodes

/usr/share/X11/xkb/keymap

/usr/share/X11/xkb/rules

/usr/share/X11/xkb/semantics

/usr/share/X11/xkb/symbols

/usr/share/X11/xkb/types

SEE ALSO

setxkbmap(1)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

551 - Linux cli command symlink

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command symlink and provides detailed information about the command symlink, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the symlink.

NAME 🖥️ symlink 🖥️

symbolic link handling

DESCRIPTION

Symbolic links are files that act as pointers to other files. To understand their behavior, you must first understand how hard links work.

A hard link to a file is indistinguishable from the original file because it is a reference to the object underlying the original filename. (To be precise: each of the hard links to a file is a reference to the same inode number, where an inode number is an index into the inode table, which contains metadata about all files on a filesystem. See stat(2).) Changes to a file are independent of the name used to reference the file. Hard links may not refer to directories (to prevent the possibility of loops within the filesystem tree, which would confuse many programs) and may not refer to files on different filesystems (because inode numbers are not unique across filesystems).

A symbolic link is a special type of file whose contents are a string that is the pathname of another file, the file to which the link refers. (The contents of a symbolic link can be read using readlink(2).) In other words, a symbolic link is a pointer to another name, and not to an underlying object. For this reason, symbolic links may refer to directories and may cross filesystem boundaries.

There is no requirement that the pathname referred to by a symbolic link should exist. A symbolic link that refers to a pathname that does not exist is said to be a dangling link.

Because a symbolic link and its referenced object coexist in the filesystem name space, confusion can arise in distinguishing between the link itself and the referenced object. On historical systems, commands and system calls adopted their own link-following conventions in a somewhat ad-hoc fashion. Rules for a more uniform approach, as they are implemented on Linux and other systems, are outlined here. It is important that site-local applications also conform to these rules, so that the user interface can be as consistent as possible.

There is a special class of symbolic-link-like objects known as “magic links”, which can be found in certain pseudofilesystems such as proc(5) (examples include /proc/pid/exe and /proc/pid/fd/*). Unlike normal symbolic links, magic links are not resolved through pathname-expansion, but instead act as direct references to the kernel’s own representation of a file handle. As such, these magic links allow users to access files which cannot be referenced with normal paths (such as unlinked files still referenced by a running program ).

Because they can bypass ordinary mount_namespaces(7)-based restrictions, magic links have been used as attack vectors in various exploits.

The owner and group of an existing symbolic link can be changed using lchown(2). The ownership of a symbolic link matters when the link is being removed or renamed in a directory that has the sticky bit set (see inode(7)), and when the fs.protected_symlinks sysctl is set (see proc(5)).

The last access and last modification timestamps of a symbolic link can be changed using utimensat(2) or lutimes(3).

On Linux, the permissions of an ordinary symbolic link are not used in any operations; the permissions are always 0777 (read, write, and execute for all user categories), and can’t be changed.

However, magic links do not follow this rule. They can have a non-0777 mode, though this mode is not currently used in any permission checks.

Using the combination of the O_PATH and O_NOFOLLOW flags to open(2) yields a file descriptor that can be passed as the dirfd argument in system calls such as fstatat(2), fchownat(2), fchmodat(2), linkat(2), and readlinkat(2), in order to operate on the symbolic link itself (rather than the file to which it refers).

By default (i.e., if the AT_SYMLINK_FOLLOW flag is not specified), if name_to_handle_at(2) is applied to a symbolic link, it yields a handle for the symbolic link (rather than the file to which it refers). One can then obtain a file descriptor for the symbolic link (rather than the file to which it refers) by specifying the O_PATH flag in a subsequent call to open_by_handle_at(2). Again, that file descriptor can be used in the aforementioned system calls to operate on the symbolic link itself.

Symbolic links are handled either by operating on the link itself, or by operating on the object referred to by the link. In the latter case, an application or system call is said to follow the link. Symbolic links may refer to other symbolic links, in which case the links are dereferenced until an object that is not a symbolic link is found, a symbolic link that refers to a file which does not exist is found, or a loop is detected. (Loop detection is done by placing an upper limit on the number of links that may be followed, and an error results if this limit is exceeded.)

There are three separate areas that need to be discussed. They are as follows:

  • Symbolic links used as filename arguments for system calls.

  • Symbolic links specified as command-line arguments to utilities that are not traversing a file tree.

  • Symbolic links encountered by utilities that are traversing a file tree (either specified on the command line or encountered as part of the file hierarchy walk).

Before describing the treatment of symbolic links by system calls and commands, we require some terminology. Given a pathname of the form a/b/c, the part preceding the final slash (i.e., a/b) is called the dirname component, and the part following the final slash (i.e., c) is called the basename component.

The first area is symbolic links used as filename arguments for system calls.

The treatment of symbolic links within a pathname passed to a system call is as follows:

  1. Within the dirname component of a pathname, symbolic links are always followed in nearly every system call. (This is also true for commands.) The one exception is openat2(2), which provides flags that can be used to explicitly prevent following of symbolic links in the dirname component.

  2. Except as noted below, all system calls follow symbolic links in the basename component of a pathname. For example, if there were a symbolic link slink which pointed to a file named afile, the system call open(“slink” …) would return a file descriptor referring to the file afile.

Various system calls do not follow links in the basename component of a pathname, and operate on the symbolic link itself. They are: lchown(2), lgetxattr(2), llistxattr(2), lremovexattr(2), lsetxattr(2), lstat(2), readlink(2), rename(2), rmdir(2), and unlink(2).

Certain other system calls optionally follow symbolic links in the basename component of a pathname. They are: faccessat(2), fchownat(2), fstatat(2), linkat(2), name_to_handle_at(2), open(2), openat(2), open_by_handle_at(2), and utimensat(2); see their manual pages for details. Because remove(3) is an alias for unlink(2), that library function also does not follow symbolic links. When rmdir(2) is applied to a symbolic link, it fails with the error ENOTDIR.

link(2) warrants special discussion. POSIX.1-2001 specifies that link(2) should dereference oldpath if it is a symbolic link. However, Linux does not do this. (By default, Solaris is the same, but the POSIX.1-2001 specified behavior can be obtained with suitable compiler options.) POSIX.1-2008 changed the specification to allow either behavior in an implementation.

Commands not traversing a file tree

The second area is symbolic links, specified as command-line filename arguments, to commands which are not traversing a file tree.

Except as noted below, commands follow symbolic links named as command-line arguments. For example, if there were a symbolic link slink which pointed to a file named afile, the command cat slink would display the contents of the file afile.

It is important to realize that this rule includes commands which may optionally traverse file trees; for example, the command chown file is included in this rule, while the command chown -R file, which performs a tree traversal, is not. (The latter is described in the third area, below.)

If it is explicitly intended that the command operate on the symbolic link instead of following the symbolic link—for example, it is desired that chown slink change the ownership of the file that slink is, whether it is a symbolic link or not—then the -h option should be used. In the above example, chown root slink would change the ownership of the file referred to by slink, while chown -h root slink would change the ownership of slink itself.

There are some exceptions to this rule:

  • The mv(1) and rm(1) commands do not follow symbolic links named as arguments, but respectively attempt to rename and delete them. (Note, if the symbolic link references a file via a relative path, moving it to another directory may very well cause it to stop working, since the path may no longer be correct.)

  • The ls(1) command is also an exception to this rule. For compatibility with historic systems (when ls(1) is not doing a tree walk—that is, -R option is not specified), the ls(1) command follows symbolic links named as arguments if the -H or -L option is specified, or if the -F, -d, or -l options are not specified. (The ls(1) command is the only command where the -H and -L options affect its behavior even though it is not doing a walk of a file tree.)

  • The file(1) command is also an exception to this rule. The file(1) command does not follow symbolic links named as argument by default. The file(1) command does follow symbolic links named as argument if the -L option is specified.

Commands traversing a file tree

The following commands either optionally or always traverse file trees: chgrp(1), chmod(1), chown(1), cp(1), du(1), find(1), ls(1), pax(1), rm(1), and tar(1).

It is important to realize that the following rules apply equally to symbolic links encountered during the file tree traversal and symbolic links listed as command-line arguments.

The first rule applies to symbolic links that reference files other than directories. Operations that apply to symbolic links are performed on the links themselves, but otherwise the links are ignored.

The command rm -r slink directory will remove slink, as well as any symbolic links encountered in the tree traversal of directory, because symbolic links may be removed. In no case will rm(1) affect the file referred to by slink.

The second rule applies to symbolic links that refer to directories. Symbolic links that refer to directories are never followed by default. This is often referred to as a “physical” walk, as opposed to a “logical” walk (where symbolic links that refer to directories are followed).

Certain conventions are (should be) followed as consistently as possible by commands that perform file tree walks:

  • A command can be made to follow any symbolic links named on the command line, regardless of the type of file they reference, by specifying the -H (for “half-logical”) flag. This flag is intended to make the command-line name space look like the logical name space. (Note, for commands that do not always do file tree traversals, the -H flag will be ignored if the -R flag is not also specified.)

    For example, the command chown -HR user slink will traverse the file hierarchy rooted in the file pointed to by slink. Note, the -H is not the same as the previously discussed -h flag. The -H flag causes symbolic links specified on the command line to be dereferenced for the purposes of both the action to be performed and the tree walk, and it is as if the user had specified the name of the file to which the symbolic link pointed.

  • A command can be made to follow any symbolic links named on the command line, as well as any symbolic links encountered during the traversal, regardless of the type of file they reference, by specifying the -L (for “logical”) flag. This flag is intended to make the entire name space look like the logical name space. (Note, for commands that do not always do file tree traversals, the -L flag will be ignored if the -R flag is not also specified.)

    For example, the command chown -LR user slink will change the owner of the file referred to by slink. If slink refers to a directory, chown will traverse the file hierarchy rooted in the directory that it references. In addition, if any symbolic links are encountered in any file tree that chown traverses, they will be treated in the same fashion as slink.

  • A command can be made to provide the default behavior by specifying the -P (for “physical”) flag. This flag is intended to make the entire name space look like the physical name space.

For commands that do not by default do file tree traversals, the -H, -L, and -P flags are ignored if the -R flag is not also specified. In addition, you may specify the -H, -L, and -P options more than once; the last one specified determines the command’s behavior. This is intended to permit you to alias commands to behave one way or the other, and then override that behavior on the command line.

The ls(1) and rm(1) commands have exceptions to these rules:

  • The rm(1) command operates on the symbolic link, and not the file it references, and therefore never follows a symbolic link. The rm(1) command does not support the -H, -L, or -P options.

  • To maintain compatibility with historic systems, the ls(1) command acts a little differently. If you do not specify the -F, -d, or -l options, ls(1) will follow symbolic links specified on the command line. If the -L flag is specified, ls(1) follows all symbolic links, regardless of their type, whether specified on the command line or encountered in the tree walk.

SEE ALSO

chgrp(1), chmod(1), find(1), ln(1), ls(1), mv(1), namei(1), rm(1), lchown(2), link(2), lstat(2), readlink(2), rename(2), symlink(2), unlink(2), utimensat(2), lutimes(3), path_resolution(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

552 - Linux cli command REINDEX

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command REINDEX and provides detailed information about the command REINDEX, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the REINDEX.

NAME 🖥️ REINDEX 🖥️

rebuild indexes

SYNOPSIS

REINDEX [ ( option [, ...] ) ] { INDEX | TABLE | SCHEMA } [ CONCURRENTLY ] name
REINDEX [ ( option [, ...] ) ] { DATABASE | SYSTEM } [ CONCURRENTLY ] [ name ]

where option can be one of:

    CONCURRENTLY [ boolean ]
    TABLESPACE new_tablespace
    VERBOSE [ boolean ]

DESCRIPTION

REINDEX rebuilds an index using the data stored in the indexs table, replacing the old copy of the index. There are several scenarios in which to use REINDEX:

·

An index has become corrupted, and no longer contains valid data. Although in theory this should never happen, in practice indexes can become corrupted due to software bugs or hardware failures. REINDEX provides a recovery method.

·

An index has become “bloated”, that is it contains many empty or nearly-empty pages. This can occur with B-tree indexes in PostgreSQL under certain uncommon access patterns. REINDEX provides a way to reduce the space consumption of the index by writing a new version of the index without the dead pages. See Section 25.2 for more information.

·

You have altered a storage parameter (such as fillfactor) for an index, and wish to ensure that the change has taken full effect.

·

If an index build fails with the CONCURRENTLY option, this index is left as “invalid”. Such indexes are useless but it can be convenient to use REINDEX to rebuild them. Note that only REINDEX INDEX is able to perform a concurrent build on an invalid index.

PARAMETERS

INDEX

Recreate the specified index. This form of REINDEX cannot be executed inside a transaction block when used with a partitioned index.

TABLE

Recreate all indexes of the specified table. If the table has a secondary “TOAST” table, that is reindexed as well. This form of REINDEX cannot be executed inside a transaction block when used with a partitioned table.

SCHEMA

Recreate all indexes of the specified schema. If a table of this schema has a secondary “TOAST” table, that is reindexed as well. Indexes on shared system catalogs are also processed. This form of REINDEX cannot be executed inside a transaction block.

DATABASE

Recreate all indexes within the current database, except system catalogs. Indexes on system catalogs are not processed. This form of REINDEX cannot be executed inside a transaction block.

SYSTEM

Recreate all indexes on system catalogs within the current database. Indexes on shared system catalogs are included. Indexes on user tables are not processed. This form of REINDEX cannot be executed inside a transaction block.

name

The name of the specific index, table, or database to be reindexed. Index and table names can be schema-qualified. Presently, REINDEX DATABASE and REINDEX SYSTEM can only reindex the current database. Their parameter is optional, and it must match the current databases name.

CONCURRENTLY

When this option is used, PostgreSQL will rebuild the index without taking any locks that prevent concurrent inserts, updates, or deletes on the table; whereas a standard index rebuild locks out writes (but not reads) on the table until its done. There are several caveats to be aware of when using this option — see Rebuilding Indexes Concurrently below.

For temporary tables, REINDEX is always non-concurrent, as no other session can access them, and non-concurrent reindex is cheaper.

TABLESPACE

Specifies that indexes will be rebuilt on a new tablespace.

VERBOSE

Prints a progress report as each index is reindexed.

boolean

Specifies whether the selected option should be turned on or off. You can write TRUE, ON, or 1 to enable the option, and FALSE, OFF, or 0 to disable it. The boolean value can also be omitted, in which case TRUE is assumed.

new_tablespace

The tablespace where indexes will be rebuilt.

NOTES

If you suspect corruption of an index on a user table, you can simply rebuild that index, or all indexes on the table, using REINDEX INDEX or REINDEX TABLE.

Things are more difficult if you need to recover from corruption of an index on a system table. In this case its important for the system to not have used any of the suspect indexes itself. (Indeed, in this sort of scenario you might find that server processes are crashing immediately at start-up, due to reliance on the corrupted indexes.) To recover safely, the server must be started with the -P option, which prevents it from using indexes for system catalog lookups.

One way to do this is to shut down the server and start a single-user PostgreSQL server with the -P option included on its command line. Then, REINDEX DATABASE, REINDEX SYSTEM, REINDEX TABLE, or REINDEX INDEX can be issued, depending on how much you want to reconstruct. If in doubt, use REINDEX SYSTEM to select reconstruction of all system indexes in the database. Then quit the single-user server session and restart the regular server. See the postgres(1) reference page for more information about how to interact with the single-user server interface.

Alternatively, a regular server session can be started with -P included in its command line options. The method for doing this varies across clients, but in all libpq-based clients, it is possible to set the PGOPTIONS environment variable to -P before starting the client. Note that while this method does not require locking out other clients, it might still be wise to prevent other users from connecting to the damaged database until repairs have been completed.

REINDEX is similar to a drop and recreate of the index in that the index contents are rebuilt from scratch. However, the locking considerations are rather different. REINDEX locks out writes but not reads of the indexs parent table. It also takes an ACCESS EXCLUSIVE lock on the specific index being processed, which will block reads that attempt to use that index. In particular, the query planner tries to take an ACCESS SHARE lock on every index of the table, regardless of the query, and so REINDEX blocks virtually any queries except for some prepared queries whose plan has been cached and which dont use this very index. In contrast, DROP INDEX momentarily takes an ACCESS EXCLUSIVE lock on the parent table, blocking both writes and reads. The subsequent CREATE INDEX locks out writes but not reads; since the index is not there, no read will attempt to use it, meaning that there will be no blocking but reads might be forced into expensive sequential scans.

Reindexing a single index or table requires being the owner of that index or table. Reindexing a schema or database requires being the owner of that schema or database. Note specifically that its thus possible for non-superusers to rebuild indexes of tables owned by other users. However, as a special exception, when REINDEX DATABASE, REINDEX SCHEMA or REINDEX SYSTEM is issued by a non-superuser, indexes on shared catalogs will be skipped unless the user owns the catalog (which typically wont be the case). Of course, superusers can always reindex anything.

Reindexing partitioned indexes or partitioned tables is supported with REINDEX INDEX or REINDEX TABLE, respectively. Each partition of the specified partitioned relation is reindexed in a separate transaction. Those commands cannot be used inside a transaction block when working on a partitioned table or index.

When using the TABLESPACE clause with REINDEX on a partitioned index or table, only the tablespace references of the leaf partitions are updated. As partitioned indexes are not updated, it is recommended to separately use ALTER TABLE ONLY on them so as any new partitions attached inherit the new tablespace. On failure, it may not have moved all the indexes to the new tablespace. Re-running the command will rebuild all the leaf partitions and move previously-unprocessed indexes to the new tablespace.

If SCHEMA, DATABASE or SYSTEM is used with TABLESPACE, system relations are skipped and a single WARNING will be generated. Indexes on TOAST tables are rebuilt, but not moved to the new tablespace.

Rebuilding Indexes Concurrently

Rebuilding an index can interfere with regular operation of a database. Normally PostgreSQL locks the table whose index is rebuilt against writes and performs the entire index build with a single scan of the table. Other transactions can still read the table, but if they try to insert, update, or delete rows in the table they will block until the index rebuild is finished. This could have a severe effect if the system is a live production database. Very large tables can take many hours to be indexed, and even for smaller tables, an index rebuild can lock out writers for periods that are unacceptably long for a production system.

PostgreSQL supports rebuilding indexes with minimum locking of writes. This method is invoked by specifying the CONCURRENTLY option of REINDEX. When this option is used, PostgreSQL must perform two scans of the table for each index that needs to be rebuilt and wait for termination of all existing transactions that could potentially use the index. This method requires more total work than a standard index rebuild and takes significantly longer to complete as it needs to wait for unfinished transactions that might modify the index. However, since it allows normal operations to continue while the index is being rebuilt, this method is useful for rebuilding indexes in a production environment. Of course, the extra CPU, memory and I/O load imposed by the index rebuild may slow down other operations.

The following steps occur in a concurrent reindex. Each step is run in a separate transaction. If there are multiple indexes to be rebuilt, then each step loops through all the indexes before moving to the next step.

1.

A new transient index definition is added to the catalog pg_index. This definition will be used to replace the old index. A SHARE UPDATE EXCLUSIVE lock at session level is taken on the indexes being reindexed as well as their associated tables to prevent any schema modification while processing.

2.

A first pass to build the index is done for each new index. Once the index is built, its flag pg_index.indisready is switched to “true” to make it ready for inserts, making it visible to other sessions once the transaction that performed the build is finished. This step is done in a separate transaction for each index.

3.

Then a second pass is performed to add tuples that were added while the first pass was running. This step is also done in a separate transaction for each index.

4.

All the constraints that refer to the index are changed to refer to the new index definition, and the names of the indexes are changed. At this point, pg_index.indisvalid is switched to “true” for the new index and to “false” for the old, and a cache invalidation is done causing all sessions that referenced the old index to be invalidated.

5.

The old indexes have pg_index.indisready switched to “false” to prevent any new tuple insertions, after waiting for running queries that might reference the old index to complete.

6.

The old indexes are dropped. The SHARE UPDATE EXCLUSIVE session locks for the indexes and the table are released.

If a problem arises while rebuilding the indexes, such as a uniqueness violation in a unique index, the REINDEX command will fail but leave behind an “invalid” new index in addition to the pre-existing one. This index will be ignored for querying purposes because it might be incomplete; however it will still consume update overhead. The psql \d command will report such an index as INVALID:

postgres=# \d tab Table “public.tab” Column | Type | Modifiers ——–+———+———– col | integer | Indexes: “idx” btree (col) “idx_ccnew” btree (col) INVALID

If the index marked INVALID is suffixed ccnew, then it corresponds to the transient index created during the concurrent operation, and the recommended recovery method is to drop it using DROP INDEX, then attempt REINDEX CONCURRENTLY again. If the invalid index is instead suffixed ccold, it corresponds to the original index which could not be dropped; the recommended recovery method is to just drop said index, since the rebuild proper has been successful.

Regular index builds permit other regular index builds on the same table to occur simultaneously, but only one concurrent index build can occur on a table at a time. In both cases, no other types of schema modification on the table are allowed meanwhile. Another difference is that a regular REINDEX TABLE or REINDEX INDEX command can be performed within a transaction block, but REINDEX CONCURRENTLY cannot.

Like any long-running transaction, REINDEX on a table can affect which tuples can be removed by concurrent VACUUM on any other table.

REINDEX SYSTEM does not support CONCURRENTLY since system catalogs cannot be reindexed concurrently.

Furthermore, indexes for exclusion constraints cannot be reindexed concurrently. If such an index is named directly in this command, an error is raised. If a table or database with exclusion constraint indexes is reindexed concurrently, those indexes will be skipped. (It is possible to reindex such indexes without the CONCURRENTLY option.)

Each backend running REINDEX will report its progress in the pg_stat_progress_create_index view. See Section 28.4.4 for details.

EXAMPLES

Rebuild a single index:

REINDEX INDEX my_index;

Rebuild all the indexes on the table my_table:

REINDEX TABLE my_table;

Rebuild all indexes in a particular database, without trusting the system indexes to be valid already:

$ export PGOPTIONS="-P" $ psql broken_db … broken_db=> REINDEX DATABASE broken_db; broken_db=> \q

Rebuild indexes for a table, without blocking read and write operations on involved relations while reindexing is in progress:

REINDEX TABLE CONCURRENTLY my_broken_table;

COMPATIBILITY

There is no REINDEX command in the SQL standard.

SEE ALSO

CREATE INDEX (CREATE_INDEX(7)), DROP INDEX (DROP_INDEX(7)), reindexdb(1), Section 28.4.4

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

553 - Linux cli command ALTER_TEXT_SEARCH_DICTIONARY

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_TEXT_SEARCH_DICTIONARY and provides detailed information about the command ALTER_TEXT_SEARCH_DICTIONARY, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_TEXT_SEARCH_DICTIONARY.

NAME 🖥️ ALTER_TEXT_SEARCH_DICTIONARY 🖥️

change the definition of a text search dictionary

SYNOPSIS

ALTER TEXT SEARCH DICTIONARY name (
    option [ = value ] [, ... ]
)
ALTER TEXT SEARCH DICTIONARY name RENAME TO new_name
ALTER TEXT SEARCH DICTIONARY name OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }
ALTER TEXT SEARCH DICTIONARY name SET SCHEMA new_schema

DESCRIPTION

ALTER TEXT SEARCH DICTIONARY changes the definition of a text search dictionary. You can change the dictionarys template-specific options, or change the dictionarys name or owner.

You must be the owner of the dictionary to use ALTER TEXT SEARCH DICTIONARY.

PARAMETERS

name

The name (optionally schema-qualified) of an existing text search dictionary.

option

The name of a template-specific option to be set for this dictionary.

value

The new value to use for a template-specific option. If the equal sign and value are omitted, then any previous setting for the option is removed from the dictionary, allowing the default to be used.

new_name

The new name of the text search dictionary.

new_owner

The new owner of the text search dictionary.

new_schema

The new schema for the text search dictionary.

Template-specific options can appear in any order.

EXAMPLES

The following example command changes the stopword list for a Snowball-based dictionary. Other parameters remain unchanged.

ALTER TEXT SEARCH DICTIONARY my_dict ( StopWords = newrussian );

The following example command changes the language option to dutch, and removes the stopword option entirely.

ALTER TEXT SEARCH DICTIONARY my_dict ( language = dutch, StopWords );

The following example command “updates” the dictionarys definition without actually changing anything.

ALTER TEXT SEARCH DICTIONARY my_dict ( dummy );

(The reason this works is that the option removal code doesnt complain if there is no such option.) This trick is useful when changing configuration files for the dictionary: the ALTER will force existing database sessions to re-read the configuration files, which otherwise they would never do if they had read them earlier.

COMPATIBILITY

There is no ALTER TEXT SEARCH DICTIONARY statement in the SQL standard.

SEE ALSO

CREATE TEXT SEARCH DICTIONARY (CREATE_TEXT_SEARCH_DICTIONARY(7)), DROP TEXT SEARCH DICTIONARY (DROP_TEXT_SEARCH_DICTIONARY(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

554 - Linux cli command go-testfunc

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command go-testfunc and provides detailed information about the command go-testfunc, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the go-testfunc.

NAME 🖥️ go-testfunc 🖥️

tool for managing Go source code

DESCRIPTION

The ‘go test’ command expects to find test, benchmark, and example functions in the “*_test.go” files corresponding to the package under test.

A test function is one named TestXxx (where Xxx does not start with a lower case letter) and should have the signature,

func TestXxx(t *testing.T) { … }

A benchmark function is one named BenchmarkXxx and should have the signature,

func BenchmarkXxx(b *testing.B) { … }

A fuzz test is one named FuzzXxx and should have the signature,

func FuzzXxx(f *testing.F) { … }

An example function is similar to a test function but, instead of using *testing.T to report success or failure, prints output to os.Stdout. If the last comment in the function starts with “Output:” then the output is compared exactly against the comment (see examples below). If the last comment begins with “Unordered output:” then the output is compared to the comment, however the order of the lines is ignored. An example with no such comment is compiled but not executed. An example with no text after “Output:” is compiled, executed, and expected to produce no output.

Godoc displays the body of ExampleXxx to demonstrate the use of the function, constant, or variable Xxx. An example of a method M with receiver type T or *T is named ExampleT_M. There may be multiple examples for a given function, constant, or variable, distinguished by a trailing _xxx, where xxx is a suffix not beginning with an upper case letter.

Here is an example of an example:

func ExamplePrintln() { Println(“The output of this example.”) // Output: The output of // this example. }

Here is another example where the ordering of the output is ignored:

func ExamplePerm() { for _, value := range Perm(4) { fmt.Println(value) } // Unordered output: 4 // 2 // 1 // 3 // 0 }

The entire test file is presented as the example when it contains a single example function, at least one other function, type, variable, or constant declaration, and no tests, benchmarks, or fuzz tests.

See the documentation of the testing package for more information.

AUTHOR

This manual page was written by Michael Stapelberg <[email protected]> and is maintained by the Debian Go Compiler Team <[email protected]> based on the output of ‘go help testfunc’ for the Debian project (and may be used by others).

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

555 - Linux cli command DROP_USER_MAPPING

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_USER_MAPPING and provides detailed information about the command DROP_USER_MAPPING, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_USER_MAPPING.

NAME 🖥️ DROP_USER_MAPPING 🖥️

remove a user mapping for a foreign server

SYNOPSIS

DROP USER MAPPING [ IF EXISTS ] FOR { user_name | USER | CURRENT_ROLE | CURRENT_USER | PUBLIC } SERVER server_name

DESCRIPTION

DROP USER MAPPING removes an existing user mapping from foreign server.

The owner of a foreign server can drop user mappings for that server for any user. Also, a user can drop a user mapping for their own user name if USAGE privilege on the server has been granted to the user.

PARAMETERS

IF EXISTS

Do not throw an error if the user mapping does not exist. A notice is issued in this case.

user_name

User name of the mapping. CURRENT_ROLE, CURRENT_USER, and USER match the name of the current user. PUBLIC is used to match all present and future user names in the system.

server_name

Server name of the user mapping.

EXAMPLES

Drop a user mapping bob, server foo if it exists:

DROP USER MAPPING IF EXISTS FOR bob SERVER foo;

COMPATIBILITY

DROP USER MAPPING conforms to ISO/IEC 9075-9 (SQL/MED). The IF EXISTS clause is a PostgreSQL extension.

SEE ALSO

CREATE USER MAPPING (CREATE_USER_MAPPING(7)), ALTER USER MAPPING (ALTER_USER_MAPPING(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

556 - Linux cli command EVP_CIPHER-SM4ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_CIPHER-SM4ssl and provides detailed information about the command EVP_CIPHER-SM4ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_CIPHER-SM4ssl.

NAME 🖥️ EVP_CIPHER-SM4ssl 🖥️

SM4 - The SM4 EVP_CIPHER implementations

DESCRIPTION

Support for SM4 symmetric encryption using the EVP_CIPHER API.

Algorithm Names

The following algorithms are available in the default provider:

“SM4-CBC:SM4”

“SM4-ECB”

“SM4-CTR”

“SM4-OFB” or “SM4-OFB128”

“SM4-CFB” or “SM4-CFB128”

“SM4-GCM”

“SM4-CCM”

“SM4-XTS”

Parameters

This implementation supports the parameters described in “PARAMETERS” in EVP_EncryptInit (3).

NOTES

The SM4-XTS implementation allows streaming to be performed, but each EVP_EncryptUpdate (3) or EVP_DecryptUpdate (3) call requires each input to be a multiple of the blocksize. Only the final EVP_EncryptUpdate() or EVP_DecryptUpdate() call can optionally have an input that is not a multiple of the blocksize but is larger than one block. In that case ciphertext stealing (CTS) is used to fill the block.

SEE ALSO

provider-cipher (7), OSSL_PROVIDER-default (7)

COPYRIGHT

Copyright 2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

557 - Linux cli command nfs.systemd

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command nfs.systemd and provides detailed information about the command nfs.systemd, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the nfs.systemd.

NAME 🖥️ nfs.systemd 🖥️

managing NFS services through systemd.

SYNOPSIS

nfs-utils.service
nfs-server.service
nfs-client.target
etc

DESCRIPTION

The nfs-utils package provides a suite of systemd unit files which allow the various services to be started and managed. These unit files ensure that the services are started in the correct order, and the prerequisites are active before dependant services start. As there are quite few unit files, it is not immediately obvious how best to achieve certain results. The following subsections attempt to cover the issues that are most likely to come up.

Configuration

The standard systemd unit files do not provide any easy way to pass any command line arguments to daemons so as to configure their behavior. In many case such configuration can be performed by making changes to /etc/nfs.conf or other configuration files. When that is not convenient, a distribution might provide systemd “drop-in” files which replace the ExecStart= setting to start the program with different arguments. For example a drop-in file systemd/system/nfs-mountd.service.d/local.conf containing

[Service] EnvironmentFile=/etc/sysconfig/nfs ExecStart= ExecStart= /usr/sbin/rpc.mountd $RPCMOUNTDOPTS

would cause the nfs-mountd.service unit to run the rpc.mountd program using, for arguments, the value given for RPCMOUNTDOPTS in /etc/sysconfig/nfs. This allows for seamless integration with existing configuration tools.

Enabling unit files

There are three unit files which are designed to be manually enabled. All others are automatically run as required. The three are:

nfs-client.target
This should be enabled on any host which ever serves as an NFS client. There is little cost in transparently enabling it whenever NFS client software is installed.

nfs-server.service
This must be enabled to provide NFS service to clients. It starts and configures the required daemons in the required order.

nfs-blkmap.service
The blkmapd daemon is only required on NFS clients which are using pNFS (parallel NFS), and particularly using the blocklayout layout protocol. If you might use this particular extension to NFS, the nfs-blkmap.service unit should be enabled.

Several other units which might be considered to be optional, such as rpc-gssd.service are careful to only start if the required configuration file exists. rpc-gssd.service will not start if the krb5.keytab file does not exist (typically in /etc).

Restarting NFS services

Most NFS daemons can be restarted at any time. They will reload any state that they need, and continue servicing requests. This is rarely necessary though.

When configuration changesare make, it can be hard to know exactly which services need to be restarted to ensure that the configuration takes effect. The simplest approach, which is often the best, is to restart everything. To help with this, the nfs-utils.service unit is provided. It declares appropriate dependencies with other unit files so that

systemctl restart nfs-utils

will restart all NFS daemons that are running. This will cause all configuration changes to take effect except for changes to mount options lists in /etc/fstab or /etc/nfsmount.conf. Mount options can only be changed by unmounting and remounting filesystem. This can be a disruptive operation so it should only be done when the value justifies the cost. The command

umount -a -t nfs; mount -a -t nfs

should unmount and remount all NFS filesystems.

Masking unwanted services

Rarely there may be a desire to prohibit some services from running even though there are normally part of a working NFS system. This may be needed to reduce system load to an absolute minimum, or to reduce attack surface by not running daemons that are not absolutely required.

Three particular services which this can apply to are rpcbind, idmapd, and rpc-gssd. rpcbind is not part of the nfs-utils package, but it used by several NFS services. However it is not needed when only NFSv4 is in use. If a site will never use NFSv3 (or NFSv2) and does not want rpcbind to be running, the correct approach is to run

systemctl mask rpcbind

This will disable rpcbind, and the various NFS services which depend on it (and are only needed for NFSv3) will refuse to start, without interfering with the operation of NFSv4 services. In particular, rpc.statd will not run when rpcbind is masked.

idmapd is only needed for NFSv4, and even then is not needed when the client and server agree to use user-ids rather than user-names to identify the owners of files. If idmapd is not needed and not wanted, it can be masked with

systemctl mask idmapd

rpc-gssd is assumed to be needed if the krb5.keytab file is present. If a site needs this file present but does not want rpc-gssd running, it can be masked with

systemctl mask rpc-gssd

FILES

/etc/nfs.conf
/etc/nfsmount.conf
/etc/idmapd.conf

SEE ALSO

systemd.unit(5), nfs.conf(5), nfsmount.conf(5).

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

558 - Linux cli command openssl-core_dispatch.hssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command openssl-core_dispatch.hssl and provides detailed information about the command openssl-core_dispatch.hssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the openssl-core_dispatch.hssl.

NAME 🖥️ openssl-core_dispatch.hssl 🖥️

OpenSSL provider dispatch numbers and function types

SYNOPSIS

#include <openssl/core_dispatch.h>

DESCRIPTION

The <openssl/core_dispatch.h> header defines all the operation numbers, dispatch numbers and provider interface function types currently available.

The operation and dispatch numbers are represented with macros, which are named as follows:

operation numbers
These macros have the form OSSL_OP_opname.

dipatch numbers
These macros have the form OSSL_FUNC_opname_funcname, where opname is the same as in the macro for the operation this function belongs to.

With every dispatch number, there is an associated function type.

For further information, please see the provider (7)

SEE ALSO

provider (7)

HISTORY

The types and macros described here were added in OpenSSL 3.0.

COPYRIGHT

Copyright 2020 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

559 - Linux cli command CREATE_FOREIGN_TABLE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_FOREIGN_TABLE and provides detailed information about the command CREATE_FOREIGN_TABLE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_FOREIGN_TABLE.

NAME 🖥️ CREATE_FOREIGN_TABLE 🖥️

define a new foreign table

SYNOPSIS

CREATE FOREIGN TABLE [ IF NOT EXISTS ] table_name ( [
  { column_name data_type [ OPTIONS ( option value [, ... ] ) ] [ COLLATE collation ] [ column_constraint [ ... ] ]
    | table_constraint }
    [, ... ]
] )
[ INHERITS ( parent_table [, ... ] ) ]
  SERVER server_name
[ OPTIONS ( option value [, ... ] ) ]

CREATE FOREIGN TABLE [ IF NOT EXISTS ] table_name
  PARTITION OF parent_table [ (
  { column_name [ WITH OPTIONS ] [ column_constraint [ ... ] ]
    | table_constraint }
    [, ... ]
) ]
{ FOR VALUES partition_bound_spec | DEFAULT }
  SERVER server_name
[ OPTIONS ( option value [, ... ] ) ]

where column_constraint is:

[ CONSTRAINT constraint_name ]
{ NOT NULL |
  NULL |
  CHECK ( expression ) [ NO INHERIT ] |
  DEFAULT default_expr |
  GENERATED ALWAYS AS ( generation_expr ) STORED }

and table_constraint is:

[ CONSTRAINT constraint_name ]
CHECK ( expression ) [ NO INHERIT ]

and partition_bound_spec is:

IN ( partition_bound_expr [, ...] ) |
FROM ( { partition_bound_expr | MINVALUE | MAXVALUE } [, ...] )
  TO ( { partition_bound_expr | MINVALUE | MAXVALUE } [, ...] ) |
WITH ( MODULUS numeric_literal, REMAINDER numeric_literal )

DESCRIPTION

CREATE FOREIGN TABLE creates a new foreign table in the current database. The table will be owned by the user issuing the command.

If a schema name is given (for example, CREATE FOREIGN TABLE myschema.mytable …) then the table is created in the specified schema. Otherwise it is created in the current schema. The name of the foreign table must be distinct from the name of any other relation (table, sequence, index, view, materialized view, or foreign table) in the same schema.

CREATE FOREIGN TABLE also automatically creates a data type that represents the composite type corresponding to one row of the foreign table. Therefore, foreign tables cannot have the same name as any existing data type in the same schema.

If PARTITION OF clause is specified then the table is created as a partition of parent_table with specified bounds.

To be able to create a foreign table, you must have USAGE privilege on the foreign server, as well as USAGE privilege on all column types used in the table.

PARAMETERS

IF NOT EXISTS

Do not throw an error if a relation with the same name already exists. A notice is issued in this case. Note that there is no guarantee that the existing relation is anything like the one that would have been created.

table_name

The name (optionally schema-qualified) of the table to be created.

column_name

The name of a column to be created in the new table.

data_type

The data type of the column. This can include array specifiers. For more information on the data types supported by PostgreSQL, refer to Chapter 8.

COLLATE collation

The COLLATE clause assigns a collation to the column (which must be of a collatable data type). If not specified, the column data types default collation is used.

INHERITS ( parent_table [, … ] )

The optional INHERITS clause specifies a list of tables from which the new foreign table automatically inherits all columns. Parent tables can be plain tables or foreign tables. See the similar form of CREATE TABLE for more details.

PARTITION OF parent_table { FOR VALUES partition_bound_spec | DEFAULT }

This form can be used to create the foreign table as partition of the given parent table with specified partition bound values. See the similar form of CREATE TABLE for more details. Note that it is currently not allowed to create the foreign table as a partition of the parent table if there are UNIQUE indexes on the parent table. (See also ALTER TABLE ATTACH PARTITION.)

CONSTRAINT constraint_name

An optional name for a column or table constraint. If the constraint is violated, the constraint name is present in error messages, so constraint names like col must be positive can be used to communicate helpful constraint information to client applications. (Double-quotes are needed to specify constraint names that contain spaces.) If a constraint name is not specified, the system generates a name.

NOT NULL

The column is not allowed to contain null values.

NULL

The column is allowed to contain null values. This is the default.

This clause is only provided for compatibility with non-standard SQL databases. Its use is discouraged in new applications.

CHECK ( expression ) [ NO INHERIT ]

The CHECK clause specifies an expression producing a Boolean result which each row in the foreign table is expected to satisfy; that is, the expression should produce TRUE or UNKNOWN, never FALSE, for all rows in the foreign table. A check constraint specified as a column constraint should reference that columns value only, while an expression appearing in a table constraint can reference multiple columns.

Currently, CHECK expressions cannot contain subqueries nor refer to variables other than columns of the current row. The system column tableoid may be referenced, but not any other system column.

A constraint marked with NO INHERIT will not propagate to child tables.

DEFAULT default_expr

The DEFAULT clause assigns a default data value for the column whose column definition it appears within. The value is any variable-free expression (subqueries and cross-references to other columns in the current table are not allowed). The data type of the default expression must match the data type of the column.

The default expression will be used in any insert operation that does not specify a value for the column. If there is no default for a column, then the default is null.

GENERATED ALWAYS AS ( generation_expr ) STORED

This clause creates the column as a generated column. The column cannot be written to, and when read the result of the specified expression will be returned.

The keyword STORED is required to signify that the column will be computed on write. (The computed value will be presented to the foreign-data wrapper for storage and must be returned on reading.)

The generation expression can refer to other columns in the table, but not other generated columns. Any functions and operators used must be immutable. References to other tables are not allowed.

server_name

The name of an existing foreign server to use for the foreign table. For details on defining a server, see CREATE SERVER (CREATE_SERVER(7)).

OPTIONS ( option value [, …] )

Options to be associated with the new foreign table or one of its columns. The allowed option names and values are specific to each foreign data wrapper and are validated using the foreign-data wrappers validator function. Duplicate option names are not allowed (although its OK for a table option and a column option to have the same name).

NOTES

Constraints on foreign tables (such as CHECK or NOT NULL clauses) are not enforced by the core PostgreSQL system, and most foreign data wrappers do not attempt to enforce them either; that is, the constraint is simply assumed to hold true. There would be little point in such enforcement since it would only apply to rows inserted or updated via the foreign table, and not to rows modified by other means, such as directly on the remote server. Instead, a constraint attached to a foreign table should represent a constraint that is being enforced by the remote server.

Some special-purpose foreign data wrappers might be the only access mechanism for the data they access, and in that case it might be appropriate for the foreign data wrapper itself to perform constraint enforcement. But you should not assume that a wrapper does that unless its documentation says so.

Although PostgreSQL does not attempt to enforce constraints on foreign tables, it does assume that they are correct for purposes of query optimization. If there are rows visible in the foreign table that do not satisfy a declared constraint, queries on the table might produce errors or incorrect answers. It is the users responsibility to ensure that the constraint definition matches reality.

Caution

When a foreign table is used as a partition of a partitioned table, there is an implicit constraint that its contents must satisfy the partitioning rule. Again, it is the users responsibility to ensure that that is true, which is best done by installing a matching constraint on the remote server.

Within a partitioned table containing foreign-table partitions, an UPDATE that changes the partition key value can cause a row to be moved from a local partition to a foreign-table partition, provided the foreign data wrapper supports tuple routing. However, it is not currently possible to move a row from a foreign-table partition to another partition. An UPDATE that would require doing that will fail due to the partitioning constraint, assuming that that is properly enforced by the remote server.

Similar considerations apply to generated columns. Stored generated columns are computed on insert or update on the local PostgreSQL server and handed to the foreign-data wrapper for writing out to the foreign data store, but it is not enforced that a query of the foreign table returns values for stored generated columns that are consistent with the generation expression. Again, this might result in incorrect query results.

EXAMPLES

Create foreign table films, which will be accessed through the server film_server:

CREATE FOREIGN TABLE films ( code char(5) NOT NULL, title: varchar(40) NOT NULL, did integer NOT NULL, date_prod date, kind varchar(10), len interval hour to minute ) SERVER film_server;

Create foreign table measurement_y2016m07, which will be accessed through the server server_07, as a partition of the range partitioned table measurement:

CREATE FOREIGN TABLE measurement_y2016m07 PARTITION OF measurement FOR VALUES FROM (2016-07-01) TO (2016-08-01) SERVER server_07;

COMPATIBILITY

The CREATE FOREIGN TABLE command largely conforms to the SQL standard; however, much as with CREATE TABLE, NULL constraints and zero-column foreign tables are permitted. The ability to specify column default values is also a PostgreSQL extension. Table inheritance, in the form defined by PostgreSQL, is nonstandard.

SEE ALSO

ALTER FOREIGN TABLE (ALTER_FOREIGN_TABLE(7)), DROP FOREIGN TABLE (DROP_FOREIGN_TABLE(7)), CREATE TABLE (CREATE_TABLE(7)), CREATE SERVER (CREATE_SERVER(7)), IMPORT FOREIGN SCHEMA (IMPORT_FOREIGN_SCHEMA(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

560 - Linux cli command cryptossl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command cryptossl and provides detailed information about the command cryptossl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the cryptossl.

NAME 🖥️ cryptossl 🖥️

guide-libcrypto-introduction, crypto - OpenSSL Guide: An introduction to libcrypto

INTRODUCTION

The OpenSSL cryptography library (libcrypto) enables access to a wide range of cryptographic algorithms used in various Internet standards. The services provided by this library are used by the OpenSSL implementations of TLS and CMS, and they have also been used to implement many other third party products and protocols.

The functionality includes symmetric encryption, public key cryptography, key agreement, certificate handling, cryptographic hash functions, cryptographic pseudo-random number generators, message authentication codes (MACs), key derivation functions (KDFs), and various utilities.

Algorithms

Cryptographic primitives such as the SHA256 digest, or AES encryption are referred to in OpenSSL as “algorithms”. Each algorithm may have multiple implementations available for use. For example the RSA algorithm is available as a “default” implementation suitable for general use, and a “fips” implementation which has been validated to FIPS 140 standards for situations where that is important. It is also possible that a third party could add additional implementations such as in a hardware security module (HSM).

Algorithms are implemented in providers. See ossl-guide-libraries-introduction (7) for information about providers.

Operations

Different algorithms can be grouped together by their purpose. For example there are algorithms for encryption, and different algorithms for digesting data. These different groups are known as “operations” in OpenSSL. Each operation has a different set of functions associated with it. For example to perform an encryption operation using AES (or any other encryption algorithm) you would use the encryption functions detailed on the EVP_EncryptInit (3) page. Or to perform a digest operation using SHA256 then you would use the digesting functions on the EVP_DigestInit (3) page.

ALGORITHM FETCHING

In order to use an algorithm an implementation for it must first be “fetched”. Fetching is the process of looking through the available implementations, applying selection criteria (via a property query string), and finally choosing the implementation that will be used.

Two types of fetching are supported by OpenSSL - “Explicit fetching” and “Implicit fetching”.

Explicit fetching

Explicit fetching involves directly calling a specific API to fetch an algorithm implementation from a provider. This fetched object can then be passed to other APIs. These explicit fetching functions usually have the name APINAME_fetch, where APINAME is the name of the operation. For example EVP_MD_fetch (3) can be used to explicitly fetch a digest algorithm implementation. The user is responsible for freeing the object returned from the APINAME_fetch function using APINAME_free when it is no longer needed.

These fetching functions follow a fairly common pattern, where three arguments are passed:

The library context
See OSSL_LIB_CTX (3) for a more detailed description. This may be NULL to signify the default (global) library context, or a context created by the user. Only providers loaded in this library context (see OSSL_PROVIDER_load (3)) will be considered by the fetching function. In case no provider has been loaded in this library context then the default provider will be loaded as a fallback (see OSSL_PROVIDER-default (7)).

An identifier
For all currently implemented fetching functions this is the algorithm name. Each provider supports a list of algorithm implementations. See the provider specific documentation for information on the algorithm implementations available in each provider: “OPERATIONS AND ALGORITHMS” in OSSL_PROVIDER-default (7), “OPERATIONS AND ALGORITHMS” in OSSL_PROVIDER-FIPS (7), “OPERATIONS AND ALGORITHMS” in OSSL_PROVIDER-legacy (7) and “OPERATIONS AND ALGORITHMS” in OSSL_PROVIDER-base (7). Note, while providers may register algorithms against a list of names using a string with a colon separated list of names, fetching algorithms using that format is currently unsupported.

A property query string
The property query string used to guide selection of the algorithm implementation. See “PROPERTY QUERY STRINGS” in ossl-guide-libraries-introduction (7).

The algorithm implementation that is fetched can then be used with other diverse functions that use them. For example the EVP_DigestInit_ex (3) function takes as a parameter an EVP_MD object which may have been returned from an earlier call to EVP_MD_fetch (3).

Implicit fetching

OpenSSL has a number of functions that return an algorithm object with no associated implementation, such as EVP_sha256 (3), EVP_aes_128_cbc (3), EVP_get_cipherbyname (3) or EVP_get_digestbyname (3). These are present for compatibility with OpenSSL before version 3.0 where explicit fetching was not available.

When they are used with functions like EVP_DigestInit_ex (3) or EVP_CipherInit_ex (3), the actual implementation to be used is fetched implicitly using default search criteria (which uses NULL for the library context and property query string).

In some cases implicit fetching can also occur when a NULL algorithm parameter is supplied. In this case an algorithm implementation is implicitly fetched using default search criteria and an algorithm name that is consistent with the context in which it is being used.

Functions that use an EVP_PKEY_CTX or an EVP_PKEY (3), such as EVP_DigestSignInit (3), all fetch the implementations implicitly. Usually the algorithm to fetch is determined based on the type of key that is being used and the function that has been called.

Performance

If you perform the same operation many times with the same algorithm then it is recommended to use a single explicit fetch of the algorithm and then reuse the explicitly fetched algorithm each subsequent time. This will typically be faster than implicitly fetching the algorithm every time you use it. See an example of Explicit fetching in “USING ALGORITHMS IN APPLICATIONS”.

Prior to OpenSSL 3.0, functions such as EVP_sha256() which return a “const” object were used directly to indicate the algorithm to use in various function calls. If you pass the return value of one of these convenience functions to an operation then you are using implicit fetching. If you are converting an application that worked with an OpenSSL version prior to OpenSSL 3.0 then consider changing instances of implicit fetching to explicit fetching instead.

If an explicitly fetched object is not passed to an operation, then any implicit fetch will use an internally cached prefetched object, but it will still be slower than passing the explicitly fetched object directly.

The following functions can be used for explicit fetching:

EVP_MD_fetch (3)
Fetch a message digest/hashing algorithm implementation.

EVP_CIPHER_fetch (3)
Fetch a symmetric cipher algorithm implementation.

EVP_KDF_fetch (3)
Fetch a Key Derivation Function (KDF) algorithm implementation.

EVP_MAC_fetch (3)
Fetch a Message Authentication Code (MAC) algorithm implementation.

EVP_KEM_fetch (3)
Fetch a Key Encapsulation Mechanism (KEM) algorithm implementation

OSSL_ENCODER_fetch (3)
Fetch an encoder algorithm implementation (e.g. to encode keys to a specified format).

OSSL_DECODER_fetch (3)
Fetch a decoder algorithm implementation (e.g. to decode keys from a specified format).

EVP_RAND_fetch (3)
Fetch a Pseudo Random Number Generator (PRNG) algorithm implementation.

See “OPERATIONS AND ALGORITHMS” in OSSL_PROVIDER-default (7), “OPERATIONS AND ALGORITHMS” in OSSL_PROVIDER-FIPS (7), “OPERATIONS AND ALGORITHMS” in OSSL_PROVIDER-legacy (7) and “OPERATIONS AND ALGORITHMS” in OSSL_PROVIDER-base (7) for a list of algorithm names that can be fetched.

FETCHING EXAMPLES

The following section provides a series of examples of fetching algorithm implementations.

Fetch any available implementation of SHA2-256 in the default context. Note that some algorithms have aliases. So “SHA256” and “SHA2-256” are synonymous:

EVP_MD *md = EVP_MD_fetch(NULL, “SHA2-256”, NULL); … EVP_MD_free(md);

Fetch any available implementation of AES-128-CBC in the default context:

EVP_CIPHER *cipher = EVP_CIPHER_fetch(NULL, “AES-128-CBC”, NULL); … EVP_CIPHER_free(cipher);

Fetch an implementation of SHA2-256 from the default provider in the default context:

EVP_MD *md = EVP_MD_fetch(NULL, “SHA2-256”, “provider=default”); … EVP_MD_free(md);

Fetch an implementation of SHA2-256 that is not from the default provider in the default context:

EVP_MD *md = EVP_MD_fetch(NULL, “SHA2-256”, “provider!=default”); … EVP_MD_free(md);

Fetch an implementation of SHA2-256 that is preferably from the FIPS provider in the default context:

EVP_MD *md = EVP_MD_fetch(NULL, “SHA2-256”, “provider=?fips”); … EVP_MD_free(md);

Fetch an implementation of SHA2-256 from the default provider in the specified library context:

EVP_MD *md = EVP_MD_fetch(libctx, “SHA2-256”, “provider=default”); … EVP_MD_free(md);

Load the legacy provider into the default context and then fetch an implementation of WHIRLPOOL from it:

/* This only needs to be done once - usually at application start up */ OSSL_PROVIDER *legacy = OSSL_PROVIDER_load(NULL, “legacy”); EVP_MD *md = EVP_MD_fetch(NULL, “WHIRLPOOL”, “provider=legacy”); … EVP_MD_free(md);

Note that in the above example the property string “provider=legacy” is optional since, assuming no other providers have been loaded, the only implementation of the “whirlpool” algorithm is in the “legacy” provider. Also note that the default provider should be explicitly loaded if it is required in addition to other providers:

/* This only needs to be done once - usually at application start up */ OSSL_PROVIDER *legacy = OSSL_PROVIDER_load(NULL, “legacy”); OSSL_PROVIDER *default = OSSL_PROVIDER_load(NULL, “default”); EVP_MD *md_whirlpool = EVP_MD_fetch(NULL, “whirlpool”, NULL); EVP_MD *md_sha256 = EVP_MD_fetch(NULL, “SHA2-256”, NULL); … EVP_MD_free(md_whirlpool); EVP_MD_free(md_sha256);

USING ALGORITHMS IN APPLICATIONS

Cryptographic algorithms are made available to applications through use of the “EVP” APIs. Each of the various operations such as encryption, digesting, message authentication codes, etc., have a set of EVP function calls that can be invoked to use them. See the evp (7) page for further details.

Most of these follow a common pattern. A “context” object is first created. For example for a digest operation you would use an EVP_MD_CTX, and for an encryption/decryption operation you would use an EVP_CIPHER_CTX. The operation is then initialised ready for use via an “init” function - optionally passing in a set of parameters (using the OSSL_PARAM (3) type) to configure how the operation should behave. Next data is fed into the operation in a series of “update” calls. The operation is finalised using a “final” call which will typically provide some kind of output. Finally the context is cleaned up and freed.

The following shows a complete example for doing this process for digesting data using SHA256. The process is similar for other operations such as encryption/decryption, signatures, message authentication codes, etc. Additional examples can be found in the OpenSSL demos (see “DEMO APPLICATIONS” in ossl-guide-libraries-introduction (7)).

#include <stdio.h> #include <openssl/evp.h> #include <openssl/bio.h> #include <openssl/err.h> int main(void) { EVP_MD_CTX *ctx = NULL; EVP_MD *sha256 = NULL; const unsigned char msg[] = { 0x00, 0x01, 0x02, 0x03 }; unsigned int len = 0; unsigned char *outdigest = NULL; int ret = 1; /* Create a context for the digest operation */ ctx = EVP_MD_CTX_new(); if (ctx == NULL) goto err; /* * Fetch the SHA256 algorithm implementation for doing the digest. Were * using the “default” library context here (first NULL parameter), and * were not supplying any particular search criteria for our SHA256 * implementation (second NULL parameter). Any SHA256 implementation will * do. * In a larger application this fetch would just be done once, and could * be used for multiple calls to other operations such as EVP_DigestInit_ex(). */ sha256 = EVP_MD_fetch(NULL, “SHA256”, NULL); if (sha256 == NULL) goto err; /* Initialise the digest operation */ if (!EVP_DigestInit_ex(ctx, sha256, NULL)) goto err; /* * Pass the message to be digested. This can be passed in over multiple * EVP_DigestUpdate calls if necessary */ if (!EVP_DigestUpdate(ctx, msg, sizeof(msg))) goto err; /* Allocate the output buffer */ outdigest = OPENSSL_malloc(EVP_MD_get_size(sha256)); if (outdigest == NULL) goto err; /* Now calculate the digest itself */ if (!EVP_DigestFinal_ex(ctx, outdigest, &len)) goto err; /* Print out the digest result */ BIO_dump_fp(stdout, outdigest, len); ret = 0; err: /* Clean up all the resources we allocated */ OPENSSL_free(outdigest); EVP_MD_free(sha256); EVP_MD_CTX_free(ctx); if (ret != 0) ERR_print_errors_fp(stderr); return ret; }

ENCODING AND DECODING KEYS

Many algorithms require the use of a key. Keys can be generated dynamically using the EVP APIs (for example see EVP_PKEY_Q_keygen (3)). However it is often necessary to save or load keys (or their associated parameters) to or from some external format such as PEM or DER (see openssl-glossary (7)). OpenSSL uses encoders and decoders to perform this task.

Encoders and decoders are just algorithm implementations in the same way as any other algorithm implementation in OpenSSL. They are implemented by providers. The OpenSSL encoders and decoders are available in the default provider. They are also duplicated in the base provider.

For information about encoders see OSSL_ENCODER_CTX_new_for_pkey (3). For information about decoders see OSSL_DECODER_CTX_new_for_pkey (3).

As well as using encoders/decoders directly there are also some helper functions that can be used for certain well known and commonly used formats. For example see PEM_read_PrivateKey (3) and PEM_write_PrivateKey (3) for information about reading and writing key data from PEM encoded files.

FURTHER READING

See ossl-guide-libssl-introduction (7) for an introduction to using libssl.

SEE ALSO

openssl (1), ssl (7), evp (7), OSSL_LIB_CTX (3), openssl-threads (7), property (7), OSSL_PROVIDER-default (7), OSSL_PROVIDER-base (7), OSSL_PROVIDER-FIPS (7), OSSL_PROVIDER-legacy (7), OSSL_PROVIDER-null (7), openssl-glossary (7), provider (7)

COPYRIGHT

Copyright 2000-2024 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

561 - Linux cli command provider-digestssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command provider-digestssl and provides detailed information about the command provider-digestssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the provider-digestssl.

NAME 🖥️ provider-digestssl 🖥️

digest - The digest library <-> provider functions

SYNOPSIS

#include <openssl/core_dispatch.h> #include <openssl/core_names.h> /* * Digests support the following function signatures in OSSL_DISPATCH arrays. * (The function signatures are not actual functions). */ /* Context management */ void *OSSL_FUNC_digest_newctx(void *provctx); void OSSL_FUNC_digest_freectx(void *dctx); void *OSSL_FUNC_digest_dupctx(void *dctx); /* Digest generation */ int OSSL_FUNC_digest_init(void *dctx, const OSSL_PARAM params[]); int OSSL_FUNC_digest_update(void *dctx, const unsigned char *in, size_t inl); int OSSL_FUNC_digest_final(void *dctx, unsigned char *out, size_t *outl, size_t outsz); int OSSL_FUNC_digest_digest(void *provctx, const unsigned char *in, size_t inl, unsigned char *out, size_t *outl, size_t outsz); /* Digest parameter descriptors */ const OSSL_PARAM *OSSL_FUNC_digest_gettable_params(void *provctx); /* Digest operation parameter descriptors */ const OSSL_PARAM *OSSL_FUNC_digest_gettable_ctx_params(void *dctx, void *provctx); const OSSL_PARAM *OSSL_FUNC_digest_settable_ctx_params(void *dctx, void *provctx); /* Digest parameters */ int OSSL_FUNC_digest_get_params(OSSL_PARAM params[]); /* Digest operation parameters */ int OSSL_FUNC_digest_set_ctx_params(void *dctx, const OSSL_PARAM params[]); int OSSL_FUNC_digest_get_ctx_params(void *dctx, OSSL_PARAM params[]);

DESCRIPTION

This documentation is primarily aimed at provider authors. See provider (7) for further information.

The DIGEST operation enables providers to implement digest algorithms and make them available to applications via the API functions EVP_DigestInit_ex (3), EVP_DigestUpdate (3) and EVP_DigestFinal (3) (and other related functions).

All “functions” mentioned here are passed as function pointers between libcrypto and the provider in OSSL_DISPATCH (3) arrays via OSSL_ALGORITHM (3) arrays that are returned by the provider’s provider_query_operation() function (see “Provider Functions” in provider-base (7)).

All these “functions” have a corresponding function type definition named OSSL_FUNC_{name}_fn, and a helper function to retrieve the function pointer from an OSSL_DISPATCH (3) element named OSSL_FUNC_{name}. For example, the “function” OSSL_FUNC_digest_newctx() has these:

typedef void *(OSSL_FUNC_digest_newctx_fn)(void *provctx); static ossl_inline OSSL_FUNC_digest_newctx_fn OSSL_FUNC_digest_newctx(const OSSL_DISPATCH *opf);

OSSL_DISPATCH (3) arrays are indexed by numbers that are provided as macros in openssl-core_dispatch.h (7), as follows:

OSSL_FUNC_digest_newctx OSSL_FUNC_DIGEST_NEWCTX OSSL_FUNC_digest_freectx OSSL_FUNC_DIGEST_FREECTX OSSL_FUNC_digest_dupctx OSSL_FUNC_DIGEST_DUPCTX OSSL_FUNC_digest_init OSSL_FUNC_DIGEST_INIT OSSL_FUNC_digest_update OSSL_FUNC_DIGEST_UPDATE OSSL_FUNC_digest_final OSSL_FUNC_DIGEST_FINAL OSSL_FUNC_digest_digest OSSL_FUNC_DIGEST_DIGEST OSSL_FUNC_digest_get_params OSSL_FUNC_DIGEST_GET_PARAMS OSSL_FUNC_digest_get_ctx_params OSSL_FUNC_DIGEST_GET_CTX_PARAMS OSSL_FUNC_digest_set_ctx_params OSSL_FUNC_DIGEST_SET_CTX_PARAMS OSSL_FUNC_digest_gettable_params OSSL_FUNC_DIGEST_GETTABLE_PARAMS OSSL_FUNC_digest_gettable_ctx_params OSSL_FUNC_DIGEST_GETTABLE_CTX_PARAMS OSSL_FUNC_digest_settable_ctx_params OSSL_FUNC_DIGEST_SETTABLE_CTX_PARAMS

A digest algorithm implementation may not implement all of these functions. In order to be usable all or none of OSSL_FUNC_digest_newctx, OSSL_FUNC_digest_freectx, OSSL_FUNC_digest_init, OSSL_FUNC_digest_update and OSSL_FUNC_digest_final should be implemented. All other functions are optional.

Context Management Functions

OSSL_FUNC_digest_newctx() should create and return a pointer to a provider side structure for holding context information during a digest operation. A pointer to this context will be passed back in a number of the other digest operation function calls. The parameter provctx is the provider context generated during provider initialisation (see provider (7)).

OSSL_FUNC_digest_freectx() is passed a pointer to the provider side digest context in the dctx parameter. This function should free any resources associated with that context.

OSSL_FUNC_digest_dupctx() should duplicate the provider side digest context in the dctx parameter and return the duplicate copy.

Digest Generation Functions

OSSL_FUNC_digest_init() initialises a digest operation given a newly created provider side digest context in the dctx parameter. The params, if not NULL, should be set on the context in a manner similar to using OSSL_FUNC_digest_set_ctx_params().

OSSL_FUNC_digest_update() is called to supply data to be digested as part of a previously initialised digest operation. The dctx parameter contains a pointer to a previously initialised provider side context. OSSL_FUNC_digest_update() should digest inl bytes of data at the location pointed to by in. OSSL_FUNC_digest_update() may be called multiple times for a single digest operation.

OSSL_FUNC_digest_final() generates a digest started through previous OSSL_FUNC_digest_init() and OSSL_FUNC_digest_update() calls. The dctx parameter contains a pointer to the provider side context. The digest should be written to *out and the length of the digest to *outl. The digest should not exceed outsz bytes.

OSSL_FUNC_digest_digest() is a “oneshot” digest function. No provider side digest context is used. Instead the provider context that was created during provider initialisation is passed in the provctx parameter (see provider (7)). inl bytes at in should be digested and the result should be stored at out. The length of the digest should be stored in *outl which should not exceed outsz bytes.

Digest Parameters

See OSSL_PARAM (3) for further details on the parameters structure used by these functions.

OSSL_FUNC_digest_get_params() gets details of the algorithm implementation and stores them in params.

OSSL_FUNC_digest_set_ctx_params() sets digest operation parameters for the provider side digest context dctx to params. Any parameter settings are additional to any that were previously set. Passing NULL for params should return true.

OSSL_FUNC_digest_get_ctx_params() gets digest operation details details from the given provider side digest context dctx and stores them in params. Passing NULL for params should return true.

OSSL_FUNC_digest_gettable_params() returns a constant OSSL_PARAM (3) array containing descriptors of the parameters that OSSL_FUNC_digest_get_params() can handle.

OSSL_FUNC_digest_gettable_ctx_params() and OSSL_FUNC_digest_settable_ctx_params() both return constant OSSL_PARAM (3) arrays as descriptors of the parameters that OSSL_FUNC_digest_get_ctx_params() and OSSL_FUNC_digest_set_ctx_params() can handle, respectively. The array is based on the current state of the provider side context if dctx is not NULL and on the provider side algorithm provctx otherwise.

Parameters currently recognised by built-in digests with this function are as follows. Not all parameters are relevant to, or are understood by all digests:

“blocksize” (OSSL_DIGEST_PARAM_BLOCK_SIZE) <unsigned integer>
The digest block size. The length of the “blocksize” parameter should not exceed that of a size_t.

“size” (OSSL_DIGEST_PARAM_SIZE) <unsigned integer>
The digest output size. The length of the “size” parameter should not exceed that of a size_t.

“flags” (OSSL_DIGEST_PARAM_FLAGS) <unsigned integer>
Diverse flags that describe exceptional behaviour for the digest:

EVP_MD_FLAG_ONESHOT
This digest method can only handle one block of input.

EVP_MD_FLAG_XOF
This digest method is an extensible-output function (XOF) and supports setting the OSSL_DIGEST_PARAM_XOFLEN parameter.

EVP_MD_FLAG_DIGALGID_NULL
When setting up a DigestAlgorithmIdentifier, this flag will have the parameter set to NULL by default. Use this for PKCS#1. Note: if combined with EVP_MD_FLAG_DIGALGID_ABSENT, the latter will override.

EVP_MD_FLAG_DIGALGID_ABSENT
When setting up a DigestAlgorithmIdentifier, this flag will have the parameter be left absent by default. Note: if combined with EVP_MD_FLAG_DIGALGID_NULL, the latter will be overridden.

EVP_MD_FLAG_DIGALGID_CUSTOM
Custom DigestAlgorithmIdentifier handling via ctrl, with EVP_MD_FLAG_DIGALGID_ABSENT as default. Note: if combined with EVP_MD_FLAG_DIGALGID_NULL, the latter will be overridden. Currently unused.

The length of the “flags” parameter should equal that of an unsigned long int.

Digest Context Parameters

OSSL_FUNC_digest_set_ctx_params() sets digest parameters associated with the given provider side digest context dctx to params. Any parameter settings are additional to any that were previously set. See OSSL_PARAM (3) for further details on the parameters structure.

OSSL_FUNC_digest_get_ctx_params() gets details of currently set parameters values associated with the give provider side digest context dctx and stores them in params. See OSSL_PARAM (3) for further details on the parameters structure.

RETURN VALUES

OSSL_FUNC_digest_newctx() and OSSL_FUNC_digest_dupctx() should return the newly created provider side digest context, or NULL on failure.

OSSL_FUNC_digest_init(), OSSL_FUNC_digest_update(), OSSL_FUNC_digest_final(), OSSL_FUNC_digest_digest(), OSSL_FUNC_digest_set_params() and OSSL_FUNC_digest_get_params() should return 1 for success or 0 on error.

OSSL_FUNC_digest_size() should return the digest size.

OSSL_FUNC_digest_block_size() should return the block size of the underlying digest algorithm.

BUGS

The EVP_Q_digest(), EVP_Digest() and EVP_DigestFinal_ex() API calls do not expect the digest size to be larger than EVP_MAX_MD_SIZE. Any algorithm which produces larger digests is unusable with those API calls.

SEE ALSO

provider (7), OSSL_PROVIDER-FIPS (7), OSSL_PROVIDER-default (7), OSSL_PROVIDER-legacy (7), EVP_MD-common (7), EVP_MD-BLAKE2 (7), EVP_MD-MD2 (7), EVP_MD-MD4 (7), EVP_MD-MD5 (7), EVP_MD-MD5-SHA1 (7), EVP_MD-MDC2 (7), EVP_MD-RIPEMD160 (7), EVP_MD-SHA1 (7), EVP_MD-SHA2 (7), EVP_MD-SHA3 (7), EVP_MD-KECCAK (7) EVP_MD-SHAKE (7), EVP_MD-SM3 (7), EVP_MD-WHIRLPOOL (7), EVP_MD-NULL (7), life_cycle-digest (7), EVP_DigestInit (3)

HISTORY

The provider DIGEST interface was introduced in OpenSSL 3.0.

COPYRIGHT

Copyright 2019-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

562 - Linux cli command user_namespaces

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command user_namespaces and provides detailed information about the command user_namespaces, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the user_namespaces.

NAME 🖥️ user_namespaces 🖥️

overview of Linux user namespaces

DESCRIPTION

For an overview of namespaces, see namespaces(7).

User namespaces isolate security-related identifiers and attributes, in particular, user IDs and group IDs (see credentials(7)), the root directory, keys (see keyrings(7)), and capabilities (see capabilities(7)). A process’s user and group IDs can be different inside and outside a user namespace. In particular, a process can have a normal unprivileged user ID outside a user namespace while at the same time having a user ID of 0 inside the namespace; in other words, the process has full privileges for operations inside the user namespace, but is unprivileged for operations outside the namespace.

Nested namespaces, namespace membership

User namespaces can be nested; that is, each user namespace—except the initial (“root”) namespace—has a parent user namespace, and can have zero or more child user namespaces. The parent user namespace is the user namespace of the process that creates the user namespace via a call to unshare(2) or clone(2) with the CLONE_NEWUSER flag.

The kernel imposes (since Linux 3.11) a limit of 32 nested levels of user namespaces. Calls to unshare(2) or clone(2) that would cause this limit to be exceeded fail with the error EUSERS.

Each process is a member of exactly one user namespace. A process created via fork(2) or clone(2) without the CLONE_NEWUSER flag is a member of the same user namespace as its parent. A single-threaded process can join another user namespace with setns(2) if it has the CAP_SYS_ADMIN in that namespace; upon doing so, it gains a full set of capabilities in that namespace.

A call to clone(2) or unshare(2) with the CLONE_NEWUSER flag makes the new child process (for clone(2)) or the caller (for unshare(2)) a member of the new user namespace created by the call.

The NS_GET_PARENT ioctl(2) operation can be used to discover the parental relationship between user namespaces; see ioctl_ns(2).

A task that changes one of its effective IDs will have its dumpability reset to the value in /proc/sys/fs/suid_dumpable. This may affect the ownership of proc files of child processes and may thus cause the parent to lack the permissions to write to mapping files of child processes running in a new user namespace. In such cases making the parent process dumpable, using PR_SET_DUMPABLE in a call to prctl(2), before creating a child process in a new user namespace may rectify this problem. See prctl(2) and proc(5) for details on how ownership is affected.

Capabilities

The child process created by clone(2) with the CLONE_NEWUSER flag starts out with a complete set of capabilities in the new user namespace. Likewise, a process that creates a new user namespace using unshare(2) or joins an existing user namespace using setns(2) gains a full set of capabilities in that namespace. On the other hand, that process has no capabilities in the parent (in the case of clone(2)) or previous (in the case of unshare(2) and setns(2)) user namespace, even if the new namespace is created or joined by the root user (i.e., a process with user ID 0 in the root namespace).

Note that a call to execve(2) will cause a process’s capabilities to be recalculated in the usual way (see capabilities(7)). Consequently, unless the process has a user ID of 0 within the namespace, or the executable file has a nonempty inheritable capabilities mask, the process will lose all capabilities. See the discussion of user and group ID mappings, below.

A call to clone(2) or unshare(2) using the CLONE_NEWUSER flag or a call to setns(2) that moves the caller into another user namespace sets the “securebits” flags (see capabilities(7)) to their default values (all flags disabled) in the child (for clone(2)) or caller (for unshare(2) or setns(2)). Note that because the caller no longer has capabilities in its original user namespace after a call to setns(2), it is not possible for a process to reset its “securebits” flags while retaining its user namespace membership by using a pair of setns(2) calls to move to another user namespace and then return to its original user namespace.

The rules for determining whether or not a process has a capability in a particular user namespace are as follows:

  • A process has a capability inside a user namespace if it is a member of that namespace and it has the capability in its effective capability set. A process can gain capabilities in its effective capability set in various ways. For example, it may execute a set-user-ID program or an executable with associated file capabilities. In addition, a process may gain capabilities via the effect of clone(2), unshare(2), or setns(2), as already described.

  • If a process has a capability in a user namespace, then it has that capability in all child (and further removed descendant) namespaces as well.

  • When a user namespace is created, the kernel records the effective user ID of the creating process as being the “owner” of the namespace. A process that resides in the parent of the user namespace and whose effective user ID matches the owner of the namespace has all capabilities in the namespace. By virtue of the previous rule, this means that the process has all capabilities in all further removed descendant user namespaces as well. The NS_GET_OWNER_UID ioctl(2) operation can be used to discover the user ID of the owner of the namespace; see ioctl_ns(2).

Effect of capabilities within a user namespace

Having a capability inside a user namespace permits a process to perform operations (that require privilege) only on resources governed by that namespace. In other words, having a capability in a user namespace permits a process to perform privileged operations on resources that are governed by (nonuser) namespaces owned by (associated with) the user namespace (see the next subsection).

On the other hand, there are many privileged operations that affect resources that are not associated with any namespace type, for example, changing the system (i.e., calendar) time (governed by CAP_SYS_TIME), loading a kernel module (governed by CAP_SYS_MODULE), and creating a device (governed by CAP_MKNOD). Only a process with privileges in the initial user namespace can perform such operations.

Holding CAP_SYS_ADMIN within the user namespace that owns a process’s mount namespace allows that process to create bind mounts and mount the following types of filesystems:

  • /proc (since Linux 3.8)

  • /sys (since Linux 3.8)

  • devpts (since Linux 3.9)

  • tmpfs(5) (since Linux 3.9)

  • ramfs (since Linux 3.9)

  • mqueue (since Linux 3.9)

  • bpf (since Linux 4.4)

  • overlayfs (since Linux 5.11)

Holding CAP_SYS_ADMIN within the user namespace that owns a process’s cgroup namespace allows (since Linux 4.6) that process to the mount the cgroup version 2 filesystem and cgroup version 1 named hierarchies (i.e., cgroup filesystems mounted with the “none,name=” option).

Holding CAP_SYS_ADMIN within the user namespace that owns a process’s PID namespace allows (since Linux 3.8) that process to mount /proc filesystems.

Note, however, that mounting block-based filesystems can be done only by a process that holds CAP_SYS_ADMIN in the initial user namespace.

Interaction of user namespaces and other types of namespaces

Starting in Linux 3.8, unprivileged processes can create user namespaces, and the other types of namespaces can be created with just the CAP_SYS_ADMIN capability in the caller’s user namespace.

When a nonuser namespace is created, it is owned by the user namespace in which the creating process was a member at the time of the creation of the namespace. Privileged operations on resources governed by the nonuser namespace require that the process has the necessary capabilities in the user namespace that owns the nonuser namespace.

If CLONE_NEWUSER is specified along with other CLONE_NEW* flags in a single clone(2) or unshare(2) call, the user namespace is guaranteed to be created first, giving the child (clone(2)) or caller (unshare(2)) privileges over the remaining namespaces created by the call. Thus, it is possible for an unprivileged caller to specify this combination of flags.

When a new namespace (other than a user namespace) is created via clone(2) or unshare(2), the kernel records the user namespace of the creating process as the owner of the new namespace. (This association can’t be changed.) When a process in the new namespace subsequently performs privileged operations that operate on global resources isolated by the namespace, the permission checks are performed according to the process’s capabilities in the user namespace that the kernel associated with the new namespace. For example, suppose that a process attempts to change the hostname (sethostname(2)), a resource governed by the UTS namespace. In this case, the kernel will determine which user namespace owns the process’s UTS namespace, and check whether the process has the required capability (CAP_SYS_ADMIN) in that user namespace.

The NS_GET_USERNS ioctl(2) operation can be used to discover the user namespace that owns a nonuser namespace; see ioctl_ns(2).

User and group ID mappings: uid_map and gid_map

When a user namespace is created, it starts out without a mapping of user IDs (group IDs) to the parent user namespace. The /proc/pid/uid_map and /proc/pid/gid_map files (available since Linux 3.5) expose the mappings for user and group IDs inside the user namespace for the process pid. These files can be read to view the mappings in a user namespace and written to (once) to define the mappings.

The description in the following paragraphs explains the details for uid_map; gid_map is exactly the same, but each instance of “user ID” is replaced by “group ID”.

The uid_map file exposes the mapping of user IDs from the user namespace of the process pid to the user namespace of the process that opened uid_map (but see a qualification to this point below). In other words, processes that are in different user namespaces will potentially see different values when reading from a particular uid_map file, depending on the user ID mappings for the user namespaces of the reading processes.

Each line in the uid_map file specifies a 1-to-1 mapping of a range of contiguous user IDs between two user namespaces. (When a user namespace is first created, this file is empty.) The specification in each line takes the form of three numbers delimited by white space. The first two numbers specify the starting user ID in each of the two user namespaces. The third number specifies the length of the mapped range. In detail, the fields are interpreted as follows:

  1. The start of the range of user IDs in the user namespace of the process pid.

  2. The start of the range of user IDs to which the user IDs specified by field one map. How field two is interpreted depends on whether the process that opened uid_map and the process pid are in the same user namespace, as follows:

    1. If the two processes are in different user namespaces: field two is the start of a range of user IDs in the user namespace of the process that opened uid_map.

    2. If the two processes are in the same user namespace: field two is the start of the range of user IDs in the parent user namespace of the process pid. This case enables the opener of uid_map (the common case here is opening /proc/self/uid_map) to see the mapping of user IDs into the user namespace of the process that created this user namespace.

  3. The length of the range of user IDs that is mapped between the two user namespaces.

System calls that return user IDs (group IDs)—for example, getuid(2), getgid(2), and the credential fields in the structure returned by stat(2)—return the user ID (group ID) mapped into the caller’s user namespace.

When a process accesses a file, its user and group IDs are mapped into the initial user namespace for the purpose of permission checking and assigning IDs when creating a file. When a process retrieves file user and group IDs via stat(2), the IDs are mapped in the opposite direction, to produce values relative to the process user and group ID mappings.

The initial user namespace has no parent namespace, but, for consistency, the kernel provides dummy user and group ID mapping files for this namespace. Looking at the uid_map file (gid_map is the same) from a shell in the initial namespace shows:

$ cat /proc/$$/uid_map
         0          0 4294967295

This mapping tells us that the range starting at user ID 0 in this namespace maps to a range starting at 0 in the (nonexistent) parent namespace, and the length of the range is the largest 32-bit unsigned integer. This leaves 4294967295 (the 32-bit signed -1 value) unmapped. This is deliberate: (uid_t) -1 is used in several interfaces (e.g., setreuid(2)) as a way to specify “no user ID”. Leaving (uid_t) -1 unmapped and unusable guarantees that there will be no confusion when using these interfaces.

Defining user and group ID mappings: writing to uid_map and gid_map

After the creation of a new user namespace, the uid_map file of one of the processes in the namespace may be written to once to define the mapping of user IDs in the new user namespace. An attempt to write more than once to a uid_map file in a user namespace fails with the error EPERM. Similar rules apply for gid_map files.

The lines written to uid_map (gid_map) must conform to the following validity rules:

  • The three fields must be valid numbers, and the last field must be greater than 0.

  • Lines are terminated by newline characters.

  • There is a limit on the number of lines in the file. In Linux 4.14 and earlier, this limit was (arbitrarily) set at 5 lines. Since Linux 4.15, the limit is 340 lines. In addition, the number of bytes written to the file must be less than the system page size, and the write must be performed at the start of the file (i.e., lseek(2) and pwrite(2) can’t be used to write to nonzero offsets in the file).

  • The range of user IDs (group IDs) specified in each line cannot overlap with the ranges in any other lines. In the initial implementation (Linux 3.8), this requirement was satisfied by a simplistic implementation that imposed the further requirement that the values in both field 1 and field 2 of successive lines must be in ascending numerical order, which prevented some otherwise valid maps from being created. Linux 3.9 and later fix this limitation, allowing any valid set of nonoverlapping maps.

  • At least one line must be written to the file.

Writes that violate the above rules fail with the error EINVAL.

In order for a process to write to the /proc/pid/uid_map (/proc/pid/gid_map) file, all of the following permission requirements must be met:

  • The writing process must have the CAP_SETUID (CAP_SETGID) capability in the user namespace of the process pid.

  • The writing process must either be in the user namespace of the process pid or be in the parent user namespace of the process pid.

  • The mapped user IDs (group IDs) must in turn have a mapping in the parent user namespace.

  • If updating /proc/pid/uid_map to create a mapping that maps UID 0 in the parent namespace, then one of the following must be true:

    1. if writing process is in the parent user namespace, then it must have the CAP_SETFCAP capability in that user namespace; or

    2. if the writing process is in the child user namespace, then the process that created the user namespace must have had the CAP_SETFCAP capability when the namespace was created.

    This rule has been in place since Linux 5.12. It eliminates an earlier security bug whereby a UID 0 process that lacks the CAP_SETFCAP capability, which is needed to create a binary with namespaced file capabilities (as described in capabilities(7)), could nevertheless create such a binary, by the following steps:

    1. Create a new user namespace with the identity mapping (i.e., UID 0 in the new user namespace maps to UID 0 in the parent namespace), so that UID 0 in both namespaces is equivalent to the same root user ID.

    2. Since the child process has the CAP_SETFCAP capability, it could create a binary with namespaced file capabilities that would then be effective in the parent user namespace (because the root user IDs are the same in the two namespaces).

  • One of the following two cases applies:

    1. Either the writing process has the CAP_SETUID (CAP_SETGID) capability in the parent user namespace.

      • No further restrictions apply: the process can make mappings to arbitrary user IDs (group IDs) in the parent user namespace.

    2. Or otherwise all of the following restrictions apply:

      • The data written to uid_map (gid_map) must consist of a single line that maps the writing process’s effective user ID (group ID) in the parent user namespace to a user ID (group ID) in the user namespace.

      • The writing process must have the same effective user ID as the process that created the user namespace.

      • In the case of gid_map, use of the setgroups(2) system call must first be denied by writing “deny” to the /proc/pid/setgroups file (see below) before writing to gid_map.

Writes that violate the above rules fail with the error EPERM.

Project ID mappings: projid_map

Similarly to user and group ID mappings, it is possible to create project ID mappings for a user namespace. (Project IDs are used for disk quotas; see setquota(8) and quotactl(2).)

Project ID mappings are defined by writing to the /proc/pid/projid_map file (present since Linux 3.7).

The validity rules for writing to the /proc/pid/projid_map file are as for writing to the uid_map file; violation of these rules causes write(2) to fail with the error EINVAL.

The permission rules for writing to the /proc/pid/projid_map file are as follows:

  • The writing process must either be in the user namespace of the process pid or be in the parent user namespace of the process pid.

  • The mapped project IDs must in turn have a mapping in the parent user namespace.

Violation of these rules causes write(2) to fail with the error EPERM.

Interaction with system calls that change process UIDs or GIDs

In a user namespace where the uid_map file has not been written, the system calls that change user IDs will fail. Similarly, if the gid_map file has not been written, the system calls that change group IDs will fail. After the uid_map and gid_map files have been written, only the mapped values may be used in system calls that change user and group IDs.

For user IDs, the relevant system calls include setuid(2), setfsuid(2), setreuid(2), and setresuid(2). For group IDs, the relevant system calls include setgid(2), setfsgid(2), setregid(2), setresgid(2), and setgroups(2).

Writing “deny” to the /proc/pid/setgroups file before writing to /proc/pid/gid_map will permanently disable setgroups(2) in a user namespace and allow writing to /proc/pid/gid_map without having the CAP_SETGID capability in the parent user namespace.

The /proc/pid/setgroups file

The /proc/pid/setgroups file displays the string “allow” if processes in the user namespace that contains the process pid are permitted to employ the setgroups(2) system call; it displays “deny” if setgroups(2) is not permitted in that user namespace. Note that regardless of the value in the /proc/pid/setgroups file (and regardless of the process’s capabilities), calls to setgroups(2) are also not permitted if /proc/pid/gid_map has not yet been set.

A privileged process (one with the CAP_SYS_ADMIN capability in the namespace) may write either of the strings “allow” or “deny” to this file before writing a group ID mapping for this user namespace to the file /proc/pid/gid_map. Writing the string “deny” prevents any process in the user namespace from employing setgroups(2).

The essence of the restrictions described in the preceding paragraph is that it is permitted to write to /proc/pid/setgroups only so long as calling setgroups(2) is disallowed because /proc/pid/gid_map has not been set. This ensures that a process cannot transition from a state where setgroups(2) is allowed to a state where setgroups(2) is denied; a process can transition only from setgroups(2) being disallowed to setgroups(2) being allowed.

The default value of this file in the initial user namespace is “allow”.

Once /proc/pid/gid_map has been written to (which has the effect of enabling setgroups(2) in the user namespace), it is no longer possible to disallow setgroups(2) by writing “deny” to /proc/pid/setgroups (the write fails with the error EPERM).

A child user namespace inherits the /proc/pid/setgroups setting from its parent.

If the setgroups file has the value “deny”, then the setgroups(2) system call can’t subsequently be reenabled (by writing “allow” to the file) in this user namespace. (Attempts to do so fail with the error EPERM.) This restriction also propagates down to all child user namespaces of this user namespace.

The /proc/pid/setgroups file was added in Linux 3.19, but was backported to many earlier stable kernel series, because it addresses a security issue. The issue concerned files with permissions such as “rwx—rwx”. Such files give fewer permissions to “group” than they do to “other”. This means that dropping groups using setgroups(2) might allow a process file access that it did not formerly have. Before the existence of user namespaces this was not a concern, since only a privileged process (one with the CAP_SETGID capability) could call setgroups(2). However, with the introduction of user namespaces, it became possible for an unprivileged process to create a new namespace in which the user had all privileges. This then allowed formerly unprivileged users to drop groups and thus gain file access that they did not previously have. The /proc/pid/setgroups file was added to address this security issue, by denying any pathway for an unprivileged process to drop groups with setgroups(2).

Unmapped user and group IDs

There are various places where an unmapped user ID (group ID) may be exposed to user space. For example, the first process in a new user namespace may call getuid(2) before a user ID mapping has been defined for the namespace. In most such cases, an unmapped user ID is converted to the overflow user ID (group ID); the default value for the overflow user ID (group ID) is 65534. See the descriptions of /proc/sys/kernel/overflowuid and /proc/sys/kernel/overflowgid in proc(5).

The cases where unmapped IDs are mapped in this fashion include system calls that return user IDs (getuid(2), getgid(2), and similar), credentials passed over a UNIX domain socket, credentials returned by stat(2), waitid(2), and the System V IPC “ctl” IPC_STAT operations, credentials exposed by /proc/pid/status and the files in /proc/sysvipc/*, credentials returned via the si_uid field in the siginfo_t received with a signal (see sigaction(2)), credentials written to the process accounting file (see acct(5)), and credentials returned with POSIX message queue notifications (see mq_notify(3)).

There is one notable case where unmapped user and group IDs are not converted to the corresponding overflow ID value. When viewing a uid_map or gid_map file in which there is no mapping for the second field, that field is displayed as 4294967295 (-1 as an unsigned integer).

Accessing files

In order to determine permissions when an unprivileged process accesses a file, the process credentials (UID, GID) and the file credentials are in effect mapped back to what they would be in the initial user namespace and then compared to determine the permissions that the process has on the file. The same is also true of other objects that employ the credentials plus permissions mask accessibility model, such as System V IPC objects.

Certain capabilities allow a process to bypass various kernel-enforced restrictions when performing operations on files owned by other users or groups. These capabilities are: CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH, CAP_FOWNER, and CAP_FSETID.

Within a user namespace, these capabilities allow a process to bypass the rules if the process has the relevant capability over the file, meaning that:

  • the process has the relevant effective capability in its user namespace; and

  • the file’s user ID and group ID both have valid mappings in the user namespace.

The CAP_FOWNER capability is treated somewhat exceptionally: it allows a process to bypass the corresponding rules so long as at least the file’s user ID has a mapping in the user namespace (i.e., the file’s group ID does not need to have a valid mapping).

Set-user-ID and set-group-ID programs

When a process inside a user namespace executes a set-user-ID (set-group-ID) program, the process’s effective user (group) ID inside the namespace is changed to whatever value is mapped for the user (group) ID of the file. However, if either the user or the group ID of the file has no mapping inside the namespace, the set-user-ID (set-group-ID) bit is silently ignored: the new program is executed, but the process’s effective user (group) ID is left unchanged. (This mirrors the semantics of executing a set-user-ID or set-group-ID program that resides on a filesystem that was mounted with the MS_NOSUID flag, as described in mount(2).)

Miscellaneous

When a process’s user and group IDs are passed over a UNIX domain socket to a process in a different user namespace (see the description of SCM_CREDENTIALS in unix(7)), they are translated into the corresponding values as per the receiving process’s user and group ID mappings.

STANDARDS

Linux.

NOTES

Over the years, there have been a lot of features that have been added to the Linux kernel that have been made available only to privileged users because of their potential to confuse set-user-ID-root applications. In general, it becomes safe to allow the root user in a user namespace to use those features because it is impossible, while in a user namespace, to gain more privilege than the root user of a user namespace has.

Global root

The term “global root” is sometimes used as a shorthand for user ID 0 in the initial user namespace.

Availability

Use of user namespaces requires a kernel that is configured with the CONFIG_USER_NS option. User namespaces require support in a range of subsystems across the kernel. When an unsupported subsystem is configured into the kernel, it is not possible to configure user namespaces support.

As at Linux 3.8, most relevant subsystems supported user namespaces, but a number of filesystems did not have the infrastructure needed to map user and group IDs between user namespaces. Linux 3.9 added the required infrastructure support for many of the remaining unsupported filesystems (Plan 9 (9P), Andrew File System (AFS), Ceph, CIFS, CODA, NFS, and OCFS2). Linux 3.12 added support for the last of the unsupported major filesystems, XFS.

EXAMPLES

The program below is designed to allow experimenting with user namespaces, as well as other types of namespaces. It creates namespaces as specified by command-line options and then executes a command inside those namespaces. The comments and usage() function inside the program provide a full explanation of the program. The following shell session demonstrates its use.

First, we look at the run-time environment:

$ uname -rs     # Need Linux 3.8 or later
Linux 3.8.0
$ id -u         # Running as unprivileged user
1000
$ id -g
1000

Now start a new shell in new user (-U), mount (-m), and PID (-p) namespaces, with user ID (-M) and group ID (-G) 1000 mapped to 0 inside the user namespace:

$ ./userns_child_exec -p -m -U -M '0 1000 1' -G '0 1000 1' bash

The shell has PID 1, because it is the first process in the new PID namespace:

bash$ echo $$
1

Mounting a new /proc filesystem and listing all of the processes visible in the new PID namespace shows that the shell can’t see any processes outside the PID namespace:

bash$ mount -t proc proc /proc
bash$ ps ax
  PID TTY      STAT   TIME COMMAND
    1 pts/3    S      0:00 bash
   22 pts/3    R+     0:00 ps ax

Inside the user namespace, the shell has user and group ID 0, and a full set of permitted and effective capabilities:

bash$ cat /proc/$$/status | egrep '^[UG]id'
Uid:	0	0	0	0
Gid:	0	0	0	0
bash$ cat /proc/$$/status | egrep '^Cap(Prm|Inh|Eff)'
CapInh:	0000000000000000
CapPrm:	0000001fffffffff
CapEff:	0000001fffffffff

Program source

/* userns_child_exec.c
   Licensed under GNU General Public License v2 or later
   Create a child process that executes a shell command in new
   namespace(s); allow UID and GID mappings to be specified when
   creating a user namespace.
*/
#define _GNU_SOURCE
#include <err.h>
#include <sched.h>
#include <unistd.h>
#include <stdint.h>
#include <stdlib.h>
#include <sys/wait.h>
#include <signal.h>
#include <fcntl.h>
#include <stdio.h>
#include <string.h>
#include <limits.h>
#include <errno.h>
struct child_args {
    char **argv;        /* Command to be executed by child, with args */
    int    pipe_fd[2];  /* Pipe used to synchronize parent and child */
};
static int verbose;
static void
usage(char *pname)
{
    fprintf(stderr, "Usage: %s [options] cmd [arg...]

“, pname); fprintf(stderr, “Create a child process that executes a shell " “command in a new user namespace, " “and possibly also other new namespace(s).

“); fprintf(stderr, “Options can be:

“); #define fpe(str) fprintf(stderr, " %s”, str); fpe("-i New IPC namespace “); fpe("-m New mount namespace “); fpe("-n New network namespace “); fpe("-p New PID namespace “); fpe("-u New UTS namespace “); fpe("-U New user namespace “); fpe("-M uid_map Specify UID map for user namespace “); fpe("-G gid_map Specify GID map for user namespace “); fpe("-z Map user’s UID and GID to 0 in user namespace “); fpe(” (equivalent to: -M ‘0 1’ -G ‘0 1’) “); fpe("-v Display verbose messages “); fpe(” “); fpe(“If -z, -M, or -G is specified, -U is required. “); fpe(“It is not permitted to specify both -z and either -M or -G. “); fpe(” “); fpe(“Map strings for -M and -G consist of records of the form: “); fpe(” “); fpe(” ID-inside-ns ID-outside-ns len “); fpe(” “); fpe(“A map string can contain multiple records, separated” " by commas; “); fpe(“the commas are replaced by newlines before writing” " to map files. “); exit(EXIT_FAILURE); } /* Update the mapping file ‘map_file’, with the value provided in ‘mapping’, a string that defines a UID or GID mapping. A UID or GID mapping consists of one or more newline-delimited records of the form: ID_inside-ns ID-outside-ns length Requiring the user to supply a string that contains newlines is of course inconvenient for command-line use. Thus, we permit the use of commas to delimit records in this string, and replace them with newlines before writing the string to the file. */ static void update_map(char *mapping, char map_file) { int fd; size_t map_len; / Length of ‘mapping’ / / Replace commas in mapping string with newlines. / map_len = strlen(mapping); for (size_t j = 0; j < map_len; j++) if (mapping[j] == ‘,’) mapping[j] = ' ‘; fd = open(map_file, O_RDWR); if (fd == -1) { fprintf(stderr, “ERROR: open %s: %s “, map_file, strerror(errno)); exit(EXIT_FAILURE); } if (write(fd, mapping, map_len) != map_len) { fprintf(stderr, “ERROR: write %s: %s “, map_file, strerror(errno)); exit(EXIT_FAILURE); } close(fd); } / Linux 3.19 made a change in the handling of setgroups(2) and the ‘gid_map’ file to address a security issue. The issue allowed unprivileged users to employ user namespaces in order to drop groups. The upshot of the 3.19 changes is that in order to update the ‘gid_maps’ file, use of the setgroups() system call in this user namespace must first be disabled by writing “deny” to one of the /proc/PID/setgroups files for this namespace. That is the purpose of the following function. */ static void proc_setgroups_write(pid_t child_pid, char str) { char setgroups_path[PATH_MAX]; int fd; snprintf(setgroups_path, PATH_MAX, “/proc/%jd/setgroups”, (intmax_t) child_pid); fd = open(setgroups_path, O_RDWR); if (fd == -1) { / We may be on a system that doesn’t support /proc/PID/setgroups. In that case, the file won’t exist, and the system won’t impose the restrictions that Linux 3.19 added. That’s fine: we don’t need to do anything in order to permit ‘gid_map’ to be updated. However, if the error from open() was something other than the ENOENT error that is expected for that case, let the user know. / if (errno != ENOENT) fprintf(stderr, “ERROR: open %s: %s “, setgroups_path, strerror(errno)); return; } if (write(fd, str, strlen(str)) == -1) fprintf(stderr, “ERROR: write %s: %s “, setgroups_path, strerror(errno)); close(fd); } static int / Start function for cloned child */ childFunc(void *arg) { struct child_args args = arg; char ch; / Wait until the parent has updated the UID and GID mappings. See the comment in main(). We wait for end of file on a pipe that will be closed by the parent process once it has updated the mappings. / close(args->pipe_fd[1]); / Close our descriptor for the write end of the pipe so that we see EOF when parent closes its descriptor. / if (read(args->pipe_fd[0], &ch, 1) != 0) { fprintf(stderr, “Failure in child: read from pipe returned != 0 “); exit(EXIT_FAILURE); } close(args->pipe_fd[0]); / Execute a shell command. / printf(“About to exec %s “, args->argv[0]); execvp(args->argv[0], args->argv); err(EXIT_FAILURE, “execvp”); } #define STACK_SIZE (1024 * 1024) static char child_stack[STACK_SIZE]; / Space for child’s stack */ int main(int argc, char *argv[]) { int flags, opt, map_zero; pid_t child_pid; struct child_args args; char *uid_map, gid_map; const int MAP_BUF_SIZE = 100; char map_buf[MAP_BUF_SIZE]; char map_path[PATH_MAX]; / Parse command-line options. The initial ‘+’ character in the final getopt() argument prevents GNU-style permutation of command-line options. That’s useful, since sometimes the ‘command’ to be executed by this program itself has command-line options. We don’t want getopt() to treat those as options to this program. / flags = 0; verbose = 0; gid_map = NULL; uid_map = NULL; map_zero = 0; while ((opt = getopt(argc, argv, “+imnpuUM:G:zv”)) != -1) { switch (opt) { case ‘i’: flags |= CLONE_NEWIPC; break; case ’m’: flags |= CLONE_NEWNS; break; case ’n’: flags |= CLONE_NEWNET; break; case ‘p’: flags |= CLONE_NEWPID; break; case ‘u’: flags |= CLONE_NEWUTS; break; case ‘v’: verbose = 1; break; case ‘z’: map_zero = 1; break; case ‘M’: uid_map = optarg; break; case ‘G’: gid_map = optarg; break; case ‘U’: flags |= CLONE_NEWUSER; break; default: usage(argv[0]); } } / -M or -G without -U is nonsensical / if (((uid_map != NULL || gid_map != NULL || map_zero) && !(flags & CLONE_NEWUSER)) || (map_zero && (uid_map != NULL || gid_map != NULL))) usage(argv[0]); args.argv = &argv[optind]; / We use a pipe to synchronize the parent and child, in order to ensure that the parent sets the UID and GID maps before the child calls execve(). This ensures that the child maintains its capabilities during the execve() in the common case where we want to map the child’s effective user ID to 0 in the new user namespace. Without this synchronization, the child would lose its capabilities if it performed an execve() with nonzero user IDs (see the capabilities(7) man page for details of the transformation of a process’s capabilities during execve()). / if (pipe(args.pipe_fd) == -1) err(EXIT_FAILURE, “pipe”); / Create the child in new namespace(s). / child_pid = clone(childFunc, child_stack + STACK_SIZE, flags | SIGCHLD, &args); if (child_pid == -1) err(EXIT_FAILURE, “clone”); / Parent falls through to here. / if (verbose) printf("%s: PID of child created by clone() is %jd “, argv[0], (intmax_t) child_pid); / Update the UID and GID maps in the child. / if (uid_map != NULL || map_zero) { snprintf(map_path, PATH_MAX, “/proc/%jd/uid_map”, (intmax_t) child_pid); if (map_zero) { snprintf(map_buf, MAP_BUF_SIZE, “0 %jd 1”, (intmax_t) getuid()); uid_map = map_buf; } update_map(uid_map, map_path); } if (gid_map != NULL || map_zero) { proc_setgroups_write(child_pid, “deny”); snprintf(map_path, PATH_MAX, “/proc/%jd/gid_map”, (intmax_t) child_pid); if (map_zero) { snprintf(map_buf, MAP_BUF_SIZE, “0 %ld 1”, (intmax_t) getgid()); gid_map = map_buf; } update_map(gid_map, map_path); } / Close the write end of the pipe, to signal to the child that we have updated the UID and GID maps. / close(args.pipe_fd[1]); if (waitpid(child_pid, NULL, 0) == -1) / Wait for child */ err(EXIT_FAILURE, “waitpid”); if (verbose) printf("%s: terminating “, argv[0]); exit(EXIT_SUCCESS); }

SEE ALSO

newgidmap(1), newuidmap(1), clone(2), ptrace(2), setns(2), unshare(2), proc(5), subgid(5), subuid(5), capabilities(7), cgroup_namespaces(7), credentials(7), namespaces(7), pid_namespaces(7)

The kernel source file Documentation/admin-guide/namespaces/resource-control.rst.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

563 - Linux cli command EVP_KDF-TLS13_KDFssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KDF-TLS13_KDFssl and provides detailed information about the command EVP_KDF-TLS13_KDFssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KDF-TLS13_KDFssl.

NAME 🖥️ EVP_KDF-TLS13_KDFssl 🖥️

TLS13_KDF - The TLS 1.3 EVP_KDF implementation

DESCRIPTION

Support for computing the TLS 1.3 version of the HKDF KDF through the EVP_KDF API.

The EVP_KDF-TLS13_KDF algorithm implements the HKDF key derivation function as used by TLS 1.3.

Identity

“TLS13-KDF” is the name for this implementation; it can be used with the EVP_KDF_fetch() function.

Supported parameters

The supported parameters are:

“properties” (OSSL_KDF_PARAM_PROPERTIES) <UTF8 string>

“digest” (OSSL_KDF_PARAM_DIGEST) <UTF8 string>

“key” (OSSL_KDF_PARAM_KEY) <octet string>

“salt” (OSSL_KDF_PARAM_SALT) <octet string>

These parameters work as described in “PARAMETERS” in EVP_KDF (3).

“prefix” (OSSL_KDF_PARAM_PREFIX) <octet string>
This parameter sets the label prefix on the specified TLS 1.3 KDF context. For TLS 1.3 this should be set to the ASCII string “tls13 " without a trailing zero byte. Refer to RFC 8446 section 7.1 “Key Schedule” for details.

“label” (OSSL_KDF_PARAM_LABEL) <octet string>
This parameter sets the label on the specified TLS 1.3 KDF context. Refer to RFC 8446 section 7.1 “Key Schedule” for details.

“data” (OSSL_KDF_PARAM_DATA) <octet string>
This parameter sets the context data on the specified TLS 1.3 KDF context. Refer to RFC 8446 section 7.1 “Key Schedule” for details.

“mode” (OSSL_KDF_PARAM_MODE) <UTF8 string> or <integer>
This parameter sets the mode for the TLS 1.3 KDF operation. There are two modes that are currently defined:

“EXTRACT_ONLY” or EVP_KDF_HKDF_MODE_EXTRACT_ONLY
In this mode calling EVP_KDF_derive (3) will just perform the extract operation. The value returned will be the intermediate fixed-length pseudorandom key K. The keylen parameter must match the size of K, which can be looked up by calling EVP_KDF_CTX_get_kdf_size() after setting the mode and digest. The digest, key and salt values must be set before a key is derived otherwise an error will occur.

“EXPAND_ONLY” or EVP_KDF_HKDF_MODE_EXPAND_ONLY
In this mode calling EVP_KDF_derive (3) will just perform the expand operation. The input key should be set to the intermediate fixed-length pseudorandom key K returned from a previous extract operation. The digest, key and info values must be set before a key is derived otherwise an error will occur.

NOTES

This KDF is intended for use by the TLS 1.3 implementation in libssl. It does not support all the options and capabilities that HKDF does.

The OSSL_PARAM array passed to EVP_KDF_derive (3) or EVP_KDF_CTX_set_params (3) must specify all of the parameters required. This KDF does not support a piecemeal approach to providing these.

A context for a TLS 1.3 KDF can be obtained by calling:

EVP_KDF *kdf = EVP_KDF_fetch(NULL, “TLS13-KDF”, NULL); EVP_KDF_CTX *kctx = EVP_KDF_CTX_new(kdf);

The output length of a TLS 1.3 KDF expand operation is specified via the keylen parameter to the EVP_KDF_derive (3) function. When using EVP_KDF_HKDF_MODE_EXTRACT_ONLY the keylen parameter must equal the size of the intermediate fixed-length pseudorandom key otherwise an error will occur. For that mode, the fixed output size can be looked up by calling EVP_KDF_CTX_get_kdf_size() after setting the mode and digest on the EVP_KDF_CTX.

CONFORMING TO

RFC 8446

SEE ALSO

EVP_KDF (3), EVP_KDF_CTX_new (3), EVP_KDF_CTX_free (3), EVP_KDF_CTX_get_kdf_size (3), EVP_KDF_CTX_set_params (3), EVP_KDF_derive (3), “PARAMETERS” in EVP_KDF (3), EVP_KDF-HKDF (7)

HISTORY

This functionality was added in OpenSSL 3.0.

COPYRIGHT

Copyright 2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

564 - Linux cli command koi8-u

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command koi8-u and provides detailed information about the command koi8-u, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the koi8-u.

NAME 🖥️ koi8-u 🖥️

u - Ukrainian character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

RFC 2310 defines an 8-bit character set, KOI8-U. KOI8-U encodes the characters used in Ukrainian and Byelorussian.

KOI8-U characters

The following table displays the characters in KOI8-U that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

The differences from KOI8-R are in the hex positions A4, A6, A7, AD, B4, B6, B7, and BD.

SEE ALSO

ascii(7), charsets(7), cp1251(7), iso_8859-5(7), koi8-r(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

565 - Linux cli command EVP_MAC-Siphashssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_MAC-Siphashssl and provides detailed information about the command EVP_MAC-Siphashssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_MAC-Siphashssl.

NAME 🖥️ EVP_MAC-Siphashssl 🖥️

Siphash - The Siphash EVP_MAC implementation

DESCRIPTION

Support for computing Siphash MACs through the EVP_MAC API.

Identity

This implementation is identified with this name and properties, to be used with EVP_MAC_fetch():

“SIPHASH”, “provider=default”

Supported parameters

The general description of these parameters can be found in “PARAMETERS” in EVP_MAC (3).

All these parameters can be set with EVP_MAC_CTX_set_params(). Furthermore, the “size” parameter can be retrieved with EVP_MAC_CTX_get_params(), or with EVP_MAC_CTX_get_mac_size(). The length of the “size” parameter should not exceed that of a size_t.

“key” (OSSL_MAC_PARAM_KEY) <octet string>
Sets the MAC key. Setting this parameter is identical to passing a key to EVP_MAC_init (3).

“size” (OSSL_MAC_PARAM_SIZE) <unsigned integer>
Sets the MAC size.

“c-rounds” (OSSL_MAC_PARAM_C_ROUNDS) <unsigned integer>
Specifies the number of rounds per message block. By default this is 2.

“d-rounds” (OSSL_MAC_PARAM_D_ROUNDS) <unsigned integer>
Specifies the number of finalisation rounds. By default this is 4.

SEE ALSO

EVP_MAC_CTX_get_params (3), EVP_MAC_CTX_set_params (3), “PARAMETERS” in EVP_MAC (3), OSSL_PARAM (3)

COPYRIGHT

Copyright 2018-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

566 - Linux cli command iso_8859-7

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso_8859-7 and provides detailed information about the command iso_8859-7, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso_8859-7.

NAME 🖥️ iso_8859-7 🖥️

7 - ISO/IEC 8859-7 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-7 encodes the characters used in modern monotonic Greek.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-7 characters

The following table displays the characters in ISO/IEC 8859-7 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-7 was formerly known as ELOT-928 or ECMA-118:1986.

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

567 - Linux cli command EVP_MD-MD5ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_MD-MD5ssl and provides detailed information about the command EVP_MD-MD5ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_MD-MD5ssl.

NAME 🖥️ EVP_MD-MD5ssl 🖥️

MD5 - The MD5 EVP_MD implementation

DESCRIPTION

Support for computing MD5 digests through the EVP_MD API.

Identity

This implementation is only available with the default provider, and is identified with the name “MD5”.

Gettable Parameters

This implementation supports the common gettable parameters described in EVP_MD-common (7).

SEE ALSO

provider-digest (7), OSSL_PROVIDER-default (7)

COPYRIGHT

Copyright 2020 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

568 - Linux cli command DROP_OPERATOR_CLASS

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_OPERATOR_CLASS and provides detailed information about the command DROP_OPERATOR_CLASS, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_OPERATOR_CLASS.

NAME 🖥️ DROP_OPERATOR_CLASS 🖥️

remove an operator class

SYNOPSIS

DROP OPERATOR CLASS [ IF EXISTS ] name USING index_method [ CASCADE | RESTRICT ]

DESCRIPTION

DROP OPERATOR CLASS drops an existing operator class. To execute this command you must be the owner of the operator class.

DROP OPERATOR CLASS does not drop any of the operators or functions referenced by the class. If there are any indexes depending on the operator class, you will need to specify CASCADE for the drop to complete.

PARAMETERS

IF EXISTS

Do not throw an error if the operator class does not exist. A notice is issued in this case.

name

The name (optionally schema-qualified) of an existing operator class.

index_method

The name of the index access method the operator class is for.

CASCADE

Automatically drop objects that depend on the operator class (such as indexes), and in turn all objects that depend on those objects (see Section 5.14).

RESTRICT

Refuse to drop the operator class if any objects depend on it. This is the default.

NOTES

DROP OPERATOR CLASS will not drop the operator family containing the class, even if there is nothing else left in the family (in particular, in the case where the family was implicitly created by CREATE OPERATOR CLASS). An empty operator family is harmless, but for the sake of tidiness you might wish to remove the family with DROP OPERATOR FAMILY; or perhaps better, use DROP OPERATOR FAMILY in the first place.

EXAMPLES

Remove the B-tree operator class widget_ops:

DROP OPERATOR CLASS widget_ops USING btree;

This command will not succeed if there are any existing indexes that use the operator class. Add CASCADE to drop such indexes along with the operator class.

COMPATIBILITY

There is no DROP OPERATOR CLASS statement in the SQL standard.

SEE ALSO

ALTER OPERATOR CLASS (ALTER_OPERATOR_CLASS(7)), CREATE OPERATOR CLASS (CREATE_OPERATOR_CLASS(7)), DROP OPERATOR FAMILY (DROP_OPERATOR_FAMILY(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

569 - Linux cli command X448ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command X448ssl and provides detailed information about the command X448ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the X448ssl.

NAME 🖥️ X448ssl 🖥️

EVP_PKEY X25519 and X448 support

DESCRIPTION

The X25519 and X448 EVP_PKEY implementation supports key generation and key derivation using X25519 and X448. It has associated private and public key formats compatible with RFC 8410.

No additional parameters can be set during key generation.

The peer public key must be set using EVP_PKEY_derive_set_peer() when performing key derivation.

NOTES

A context for the X25519 algorithm can be obtained by calling:

EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_id(EVP_PKEY_X25519, NULL);

For the X448 algorithm a context can be obtained by calling:

EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_id(EVP_PKEY_X448, NULL);

X25519 or X448 private keys can be set directly using EVP_PKEY_new_raw_private_key (3) or loaded from a PKCS#8 private key file using PEM_read_bio_PrivateKey (3) (or similar function). Completely new keys can also be generated (see the example below). Setting a private key also sets the associated public key.

X25519 or X448 public keys can be set directly using EVP_PKEY_new_raw_public_key (3) or loaded from a SubjectPublicKeyInfo structure in a PEM file using PEM_read_bio_PUBKEY (3) (or similar function).

EXAMPLES

This example generates an X25519 private key and writes it to standard output in PEM format:

#include <openssl/evp.h> #include <openssl/pem.h> … EVP_PKEY *pkey = NULL; EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_id(EVP_PKEY_X25519, NULL); EVP_PKEY_keygen_init(pctx); EVP_PKEY_keygen(pctx, &pkey); EVP_PKEY_CTX_free(pctx); PEM_write_PrivateKey(stdout, pkey, NULL, NULL, 0, NULL, NULL);

The key derivation example in EVP_PKEY_derive (3) can be used with X25519 and X448.

SEE ALSO

EVP_PKEY_CTX_new (3), EVP_PKEY_keygen (3), EVP_PKEY_derive (3), EVP_PKEY_derive_set_peer (3)

COPYRIGHT

Copyright 2017-2020 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

570 - Linux cli command systemd.offline-updates

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command systemd.offline-updates and provides detailed information about the command systemd.offline-updates, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the systemd.offline-updates.

NAME 🖥️ systemd.offline-updates 🖥️

updates - Implementation of offline updates in systemd

IMPLEMENTING OFFLINE SYSTEM UPDATES

This man page describes how to implement “offline” system updates with systemd. By “offline” OS updates we mean package installations and updates that are run with the system booted into a special system update mode, in order to avoid problems related to conflicts of libraries and services that are currently running with those on disk. This document is inspired by this GNOME design whiteboard[1].

The logic:

1.

The package manager prepares system updates by downloading all (.rpm or .deb or whatever) packages to update off-line in a special directory /var/lib/system-update (or another directory of the package/upgrade managers choice).

2.

When the user OKed the update, the symlink /system-update or /etc/system-update is created that points to /var/lib/system-update (or wherever the directory with the upgrade files is located) and the system is rebooted. This symlink is in the root directory, since we need to check for it very early at boot, at a time where /var/ is not available yet.

3.

Very early in the new boot systemd-system-update-generator(8) checks whether /system-update or /etc/system-update exists. If so, it (temporarily and for this boot only) redirects (i.e. symlinks) default.target to system-update.target, a special target that pulls in the base system (i.e. sysinit.target, so that all file systems are mounted but little else) and the system update units.

4.

The system now continues to boot into default.target, and thus into system-update.target. This target pulls in all system update units. Only one service should perform an update (see the next point), and all the other ones should exit cleanly with a “success” return code and without doing anything. Update services should be ordered after sysinit.target so that the update starts after all file systems have been mounted.

5.

As the first step, an update service should check if the /system-update or /etc/system-update symlink points to the location used by that update service. In case it does not exist or points to a different location, the service must exit without error. It is possible for multiple update services to be installed, and for multiple update services to be launched in parallel, and only the one that corresponds to the tool that created the symlink before reboot should perform any actions. It is unsafe to run multiple updates in parallel.

6.

The update service should now do its job. If applicable and possible, it should create a file system snapshot, then install all packages. After completion (regardless whether the update succeeded or failed) the machine must be rebooted, for example by calling systemctl reboot. In addition, on failure the script should revert to the old file system snapshot (without the symlink).

7.

The update scripts should exit only after the update is finished. It is expected that the service which performs the update will cause the machine to reboot after it is done. If the system-update.target is successfully reached, i.e. all update services have run, and the /system-update or /etc/system-update symlink still exists, it will be removed and the machine rebooted as a safety measure.

8.

After a reboot, now that the /system-update and /etc/system-update symlink is gone, the generator wont redirect default.target anymore and the system now boots into the default target again.

RECOMMENDATIONS

1.

To make things a bit more robust we recommend hooking the update script into system-update.target via a .wants/ symlink in the distribution package, rather than depending on systemctl enable in the postinst scriptlets of your package. More specifically, for your update script create a .service file, without [Install] section, and then add a symlink like /usr/lib/systemd/system/system-update.target.wants/foobar.service → ../foobar.service to your package.

2.

Make sure to remove the /system-update and /etc/system-update symlinks as early as possible in the update script to avoid reboot loops in case the update fails.

3.

Use FailureAction=reboot in the service file for your update script to ensure that a reboot is automatically triggered if the update fails. FailureAction= makes sure that the specified unit is activated if your script exits uncleanly (by non-zero error code, or signal/coredump). If your script succeeds you should trigger the reboot in your own code, for example by invoking loginds Reboot() call or calling systemctl reboot. See org.freedesktop.login1(5) for details about the logind D-Bus API.

4.

The update service should declare DefaultDependencies=no, Requires=sysinit.target, After=sysinit.target, After=system-update-pre.target, Before=system-update.target and explicitly pull in any other services it requires.

5.

It may be desirable to always run an auxiliary unit when booting into offline-updates mode, which itself does not install updates. To do this create a .service file with Wants=system-update-pre.target and Before=system-update-pre.target and add a symlink to that file under /usr/lib/systemd/system-update.target.wants .

SEE ALSO

systemd(1), systemd.generator(7), systemd-system-update-generator(8), dnf.plugin.system-upgrade(8)

NOTES

GNOME design whiteboard

https://wiki.gnome.org/Design/OS/SoftwareUpdates

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

571 - Linux cli command DROP_FUNCTION

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_FUNCTION and provides detailed information about the command DROP_FUNCTION, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_FUNCTION.

NAME 🖥️ DROP_FUNCTION 🖥️

remove a function

SYNOPSIS

DROP FUNCTION [ IF EXISTS ] name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ] [, ...]
    [ CASCADE | RESTRICT ]

DESCRIPTION

DROP FUNCTION removes the definition of an existing function. To execute this command the user must be the owner of the function. The argument types to the function must be specified, since several different functions can exist with the same name and different argument lists.

PARAMETERS

IF EXISTS

Do not throw an error if the function does not exist. A notice is issued in this case.

name

The name (optionally schema-qualified) of an existing function. If no argument list is specified, the name must be unique in its schema.

argmode

The mode of an argument: IN, OUT, INOUT, or VARIADIC. If omitted, the default is IN. Note that DROP FUNCTION does not actually pay any attention to OUT arguments, since only the input arguments are needed to determine the functions identity. So it is sufficient to list the IN, INOUT, and VARIADIC arguments.

argname

The name of an argument. Note that DROP FUNCTION does not actually pay any attention to argument names, since only the argument data types are needed to determine the functions identity.

argtype

The data type(s) of the functions arguments (optionally schema-qualified), if any.

CASCADE

Automatically drop objects that depend on the function (such as operators or triggers), and in turn all objects that depend on those objects (see Section 5.14).

RESTRICT

Refuse to drop the function if any objects depend on it. This is the default.

EXAMPLES

This command removes the square root function:

DROP FUNCTION sqrt(integer);

Drop multiple functions in one command:

DROP FUNCTION sqrt(integer), sqrt(bigint);

If the function name is unique in its schema, it can be referred to without an argument list:

DROP FUNCTION update_employee_salaries;

Note that this is different from

DROP FUNCTION update_employee_salaries();

which refers to a function with zero arguments, whereas the first variant can refer to a function with any number of arguments, including zero, as long as the name is unique.

COMPATIBILITY

This command conforms to the SQL standard, with these PostgreSQL extensions:

·

The standard only allows one function to be dropped per command.

·

The IF EXISTS option

·

The ability to specify argument modes and names

SEE ALSO

CREATE FUNCTION (CREATE_FUNCTION(7)), ALTER FUNCTION (ALTER_FUNCTION(7)), DROP PROCEDURE (DROP_PROCEDURE(7)), DROP ROUTINE (DROP_ROUTINE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

572 - Linux cli command operator

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command operator and provides detailed information about the command operator, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the operator.

NAME 🖥️ operator 🖥️

C operator precedence and order of evaluation

DESCRIPTION

This manual page lists C operators and their precedence in evaluation.

OperatorAssociativityNotes
[] () . -> ++ --left to right[1]
++ -- & * + - ~ ! sizeofright to left[2]
(type)right to left
* / %left to right
+ -left to right
<< >>left to right
< > <= >=left to right
== !=left to right
&left to right
^left to right
|left to right
&&left to right
||left to right
?:right to left
= *= /= %= += -= <<= >>= &= ^= |=right to left
,left to right

The following notes provide further information to the above table:

[1]
The ++ and – operators at this precedence level are the postfix flavors of the operators.

[2]
The ++ and – operators at this precedence level are the prefix flavors of the operators.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

573 - Linux cli command iso_8859_4

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso_8859_4 and provides detailed information about the command iso_8859_4, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso_8859_4.

NAME 🖥️ iso_8859_4 🖥️

4 - ISO/IEC 8859-4 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-4 encodes the characters used in Scandinavian and Baltic languages.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-4 characters

The following table displays the characters in ISO/IEC 8859-4 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-4 is also known as Latin-4.

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

574 - Linux cli command ALTER_AGGREGATE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_AGGREGATE and provides detailed information about the command ALTER_AGGREGATE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_AGGREGATE.

NAME 🖥️ ALTER_AGGREGATE 🖥️

change the definition of an aggregate function

SYNOPSIS

ALTER AGGREGATE name ( aggregate_signature ) RENAME TO new_name
ALTER AGGREGATE name ( aggregate_signature )
                OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }
ALTER AGGREGATE name ( aggregate_signature ) SET SCHEMA new_schema

where aggregate_signature is:

* |
[ argmode ] [ argname ] argtype [ , ... ] |
[ [ argmode ] [ argname ] argtype [ , ... ] ] ORDER BY [ argmode ] [ argname ] argtype [ , ... ]

DESCRIPTION

ALTER AGGREGATE changes the definition of an aggregate function.

You must own the aggregate function to use ALTER AGGREGATE. To change the schema of an aggregate function, you must also have CREATE privilege on the new schema. To alter the owner, you must be able to SET ROLE to the new owning role, and that role must have CREATE privilege on the aggregate functions schema. (These restrictions enforce that altering the owner doesnt do anything you couldnt do by dropping and recreating the aggregate function. However, a superuser can alter ownership of any aggregate function anyway.)

PARAMETERS

name

The name (optionally schema-qualified) of an existing aggregate function.

argmode

The mode of an argument: IN or VARIADIC. If omitted, the default is IN.

argname

The name of an argument. Note that ALTER AGGREGATE does not actually pay any attention to argument names, since only the argument data types are needed to determine the aggregate functions identity.

argtype

An input data type on which the aggregate function operates. To reference a zero-argument aggregate function, write * in place of the list of argument specifications. To reference an ordered-set aggregate function, write ORDER BY between the direct and aggregated argument specifications.

new_name

The new name of the aggregate function.

new_owner

The new owner of the aggregate function.

new_schema

The new schema for the aggregate function.

NOTES

The recommended syntax for referencing an ordered-set aggregate is to write ORDER BY between the direct and aggregated argument specifications, in the same style as in CREATE AGGREGATE. However, it will also work to omit ORDER BY and just run the direct and aggregated argument specifications into a single list. In this abbreviated form, if VARIADIC “any” was used in both the direct and aggregated argument lists, write VARIADIC “any” only once.

EXAMPLES

To rename the aggregate function myavg for type integer to my_average:

ALTER AGGREGATE myavg(integer) RENAME TO my_average;

To change the owner of the aggregate function myavg for type integer to joe:

ALTER AGGREGATE myavg(integer) OWNER TO joe;

To move the ordered-set aggregate mypercentile with direct argument of type float8 and aggregated argument of type integer into schema myschema:

ALTER AGGREGATE mypercentile(float8 ORDER BY integer) SET SCHEMA myschema;

This will work too:

ALTER AGGREGATE mypercentile(float8, integer) SET SCHEMA myschema;

COMPATIBILITY

There is no ALTER AGGREGATE statement in the SQL standard.

SEE ALSO

CREATE AGGREGATE (CREATE_AGGREGATE(7)), DROP AGGREGATE (DROP_AGGREGATE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

575 - Linux cli command DROP_STATISTICS

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_STATISTICS and provides detailed information about the command DROP_STATISTICS, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_STATISTICS.

NAME 🖥️ DROP_STATISTICS 🖥️

remove extended statistics

SYNOPSIS

DROP STATISTICS [ IF EXISTS ] name [, ...] [ CASCADE | RESTRICT ]

DESCRIPTION

DROP STATISTICS removes statistics object(s) from the database. Only the statistics objects owner, the schema owner, or a superuser can drop a statistics object.

PARAMETERS

IF EXISTS

Do not throw an error if the statistics object does not exist. A notice is issued in this case.

name

The name (optionally schema-qualified) of the statistics object to drop.

CASCADE
RESTRICT

These key words do not have any effect, since there are no dependencies on statistics.

EXAMPLES

To destroy two statistics objects in different schemas, without failing if they dont exist:

DROP STATISTICS IF EXISTS accounting.users_uid_creation, public.grants_user_role;

COMPATIBILITY

There is no DROP STATISTICS command in the SQL standard.

SEE ALSO

ALTER STATISTICS (ALTER_STATISTICS(7)), CREATE STATISTICS (CREATE_STATISTICS(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

576 - Linux cli command fips_modulessl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command fips_modulessl and provides detailed information about the command fips_modulessl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the fips_modulessl.

NAME 🖥️ fips_modulessl 🖥️

OpenSSL fips module guide

SYNOPSIS

See the individual manual pages for details.

DESCRIPTION

This guide details different ways that OpenSSL can be used in conjunction with the FIPS module. Which is the correct approach to use will depend on your own specific circumstances and what you are attempting to achieve.

For information related to installing the FIPS module see <https://github.com/openssl/openssl/blob/master/README-FIPS.md>.

Note that the old functions FIPS_mode() and FIPS_mode_set() are no longer present so you must remove them from your application if you use them.

Applications written to use the OpenSSL 3.0 FIPS module should not use any legacy APIs or features that avoid the FIPS module. Specifically this includes:

  • Low level cryptographic APIs (use the high level APIs, such as EVP, instead)

  • Engines

  • Any functions that create or modify custom “METHODS” (for example EVP_MD_meth_new(), EVP_CIPHER_meth_new(), EVP_PKEY_meth_new(), RSA_meth_new(), EC_KEY_METHOD_new(), etc.)

All of the above APIs are deprecated in OpenSSL 3.0 - so a simple rule is to avoid using all deprecated functions. See ossl-guide-migration (7) for a list of deprecated functions.

Making all applications use the FIPS module by default

One simple approach is to cause all applications that are using OpenSSL to only use the FIPS module for cryptographic algorithms by default.

This approach can be done purely via configuration. As long as applications are built and linked against OpenSSL 3.0 and do not override the loading of the default config file or its settings then they can automatically start using the FIPS module without the need for any further code changes.

To do this the default OpenSSL config file will have to be modified. The location of this config file will depend on the platform, and any options that were given during the build process. You can check the location of the config file by running this command:

$ openssl version -d OPENSSLDIR: “/usr/local/ssl”

Caution: Many Operating Systems install OpenSSL by default. It is a common error to not have the correct version of OpenSSL in your $PATH. Check that you are running an OpenSSL 3.0 version like this:

$ openssl version -v OpenSSL 3.0.0-dev xx XXX xxxx (Library: OpenSSL 3.0.0-dev xx XXX xxxx)

The OPENSSLDIR value above gives the directory name for where the default config file is stored. So in this case the default config file will be called /usr/local/ssl/openssl.cnf.

Edit the config file to add the following lines near the beginning:

config_diagnostics = 1 openssl_conf = openssl_init .include /usr/local/ssl/fipsmodule.cnf [openssl_init] providers = provider_sect alg_section = algorithm_sect [provider_sect] fips = fips_sect base = base_sect [base_sect] activate = 1 [algorithm_sect] default_properties = fips=yes

Obviously the include file location above should match the path and name of the FIPS module config file that you installed earlier. See <https://github.com/openssl/openssl/blob/master/README-FIPS.md>.

For FIPS usage, it is recommended that the config_diagnostics option is enabled to prevent accidental use of non-FIPS validated algorithms via broken or mistaken configuration. See config (5).

Any applications that use OpenSSL 3.0 and are started after these changes are made will start using only the FIPS module unless those applications take explicit steps to avoid this default behaviour. Note that this configuration also activates the “base” provider. The base provider does not include any cryptographic algorithms (and therefore does not impact the validation status of any cryptographic operations), but does include other supporting algorithms that may be required. It is designed to be used in conjunction with the FIPS module.

This approach has the primary advantage that it is simple, and no code changes are required in applications in order to benefit from the FIPS module. There are some disadvantages to this approach:

  • You may not want all applications to use the FIPS module. It may be the case that some applications should and some should not use the FIPS module.

  • If applications take explicit steps to not load the default config file or set different settings. This method will not work for these cases.

  • The algorithms available in the FIPS module are a subset of the algorithms that are available in the default OpenSSL Provider. If any applications attempt to use any algorithms that are not present, then they will fail.

  • Usage of certain deprecated APIs avoids the use of the FIPS module. If any applications use those APIs then the FIPS module will not be used.

Selectively making applications use the FIPS module by default

A variation on the above approach is to do the same thing on an individual application basis. The default OpenSSL config file depends on the compiled in value for OPENSSLDIR as described in the section above. However it is also possible to override the config file to be used via the OPENSSL_CONF environment variable. For example the following, on Unix, will cause the application to be executed with a non-standard config file location:

$ OPENSSL_CONF=/my/nondefault/openssl.cnf myapplication

Using this mechanism you can control which config file is loaded (and hence whether the FIPS module is loaded) on an application by application basis.

This removes the disadvantage listed above that you may not want all applications to use the FIPS module. All the other advantages and disadvantages still apply.

Programmatically loading the FIPS module (default library context)

Applications may choose to load the FIPS provider explicitly rather than relying on config to do this. The config file is still necessary in order to hold the FIPS module config data (such as its self test status and integrity data). But in this case we do not automatically activate the FIPS provider via that config file.

To do things this way configure as per “Making all applications use the FIPS module by default” above, but edit the fipsmodule.cnf file to remove or comment out the line which says activate = 1 (note that setting this value to 0 is not sufficient). This means all the required config information will be available to load the FIPS module, but it is not automatically loaded when the application starts. The FIPS provider can then be loaded programmatically like this:

#include <openssl/provider.h> int main(void) { OSSL_PROVIDER *fips; OSSL_PROVIDER *base; fips = OSSL_PROVIDER_load(NULL, “fips”); if (fips == NULL) { printf(“Failed to load FIPS provider “); exit(EXIT_FAILURE); } base = OSSL_PROVIDER_load(NULL, “base”); if (base == NULL) { OSSL_PROVIDER_unload(fips); printf(“Failed to load base provider “); exit(EXIT_FAILURE); } /* Rest of application */ OSSL_PROVIDER_unload(base); OSSL_PROVIDER_unload(fips); exit(EXIT_SUCCESS); }

Note that this should be one of the first things that you do in your application. If any OpenSSL functions get called that require the use of cryptographic functions before this occurs then, if no provider has yet been loaded, then the default provider will be automatically loaded. If you then later explicitly load the FIPS provider then you will have both the FIPS and the default provider loaded at the same time. It is undefined which implementation of an algorithm will be used if multiple implementations are available and you have not explicitly specified via a property query (see below) which one should be used.

Also note that in this example we have additionally loaded the “base” provider. This loads a sub-set of algorithms that are also available in the default provider - specifically non cryptographic ones which may be used in conjunction with the FIPS provider. For example this contains algorithms for encoding and decoding keys. If you decide not to load the default provider then you will usually want to load the base provider instead.

In this example we are using the “default” library context. OpenSSL functions operate within the scope of a library context. If no library context is explicitly specified then the default library context is used. For further details about library contexts see the OSSL_LIB_CTX (3) man page.

Loading the FIPS module at the same time as other providers

It is possible to have the FIPS provider and other providers (such as the default provider) all loaded at the same time into the same library context. You can use a property query string during algorithm fetches to specify which implementation you would like to use.

For example to fetch an implementation of SHA256 which conforms to FIPS standards you can specify the property query fips=yes like this:

EVP_MD *sha256; sha256 = EVP_MD_fetch(NULL, “SHA2-256”, “fips=yes”);

If no property query is specified, or more than one implementation matches the property query then it is undefined which implementation of a particular algorithm will be returned.

This example shows an explicit request for an implementation of SHA256 from the default provider:

EVP_MD *sha256; sha256 = EVP_MD_fetch(NULL, “SHA2-256”, “provider=default”);

It is also possible to set a default property query string. The following example sets the default property query of fips=yes for all fetches within the default library context:

EVP_set_default_properties(NULL, “fips=yes”);

If a fetch function has both an explicit property query specified, and a default property query is defined then the two queries are merged together and both apply. The local property query overrides the default properties if the same property name is specified in both.

There are two important built-in properties that you should be aware of:

The “provider” property enables you to specify which provider you want an implementation to be fetched from, e.g. provider=default or provider=fips. All algorithms implemented in a provider have this property set on them.

There is also the fips property. All FIPS algorithms match against the property query fips=yes. There are also some non-cryptographic algorithms available in the default and base providers that also have the fips=yes property defined for them. These are the encoder and decoder algorithms that can (for example) be used to write out a key generated in the FIPS provider to a file. The encoder and decoder algorithms are not in the FIPS module itself but are allowed to be used in conjunction with the FIPS algorithms.

It is possible to specify default properties within a config file. For example the following config file automatically loads the default and FIPS providers and sets the default property value to be fips=yes. Note that this config file does not load the “base” provider. All supporting algorithms that are in “base” are also in “default”, so it is unnecessary in this case:

config_diagnostics = 1 openssl_conf = openssl_init .include /usr/local/ssl/fipsmodule.cnf [openssl_init] providers = provider_sect alg_section = algorithm_sect [provider_sect] fips = fips_sect default = default_sect [default_sect] activate = 1 [algorithm_sect] default_properties = fips=yes

Programmatically loading the FIPS module (nondefault library context)

In addition to using properties to separate usage of the FIPS module from other usages this can also be achieved using library contexts. In this example we create two library contexts. In one we assume the existence of a config file called openssl-fips.cnf that automatically loads and configures the FIPS and base providers. The other library context will just use the default provider.

OSSL_LIB_CTX *fips_libctx, *nonfips_libctx; OSSL_PROVIDER *defctxnull = NULL; EVP_MD *fipssha256 = NULL, *nonfipssha256 = NULL; int ret = 1; /* * Create two nondefault library contexts. One for fips usage and * one for non-fips usage */ fips_libctx = OSSL_LIB_CTX_new(); nonfips_libctx = OSSL_LIB_CTX_new(); if (fips_libctx == NULL || nonfips_libctx == NULL) goto err; /* Prevent anything from using the default library context */ defctxnull = OSSL_PROVIDER_load(NULL, “null”); /* * Load config file for the FIPS library context. We assume that * this config file will automatically activate the FIPS and base * providers so we dont need to explicitly load them here. */ if (!OSSL_LIB_CTX_load_config(fips_libctx, “openssl-fips.cnf”)) goto err; /* * Set the default property query on the FIPS library context to * ensure that only FIPS algorithms can be used. There are a few non-FIPS * approved algorithms in the FIPS provider for backward compatibility reasons. */ if (!EVP_set_default_properties(fips_libctx, “fips=yes”)) goto err; /* * We dont need to do anything special to load the default * provider into nonfips_libctx. This happens automatically if no * other providers are loaded. * Because we dont call OSSL_LIB_CTX_load_config() explicitly for * nonfips_libctx it will just use the default config file. */ /* As an example get some digests */ /* Get a FIPS validated digest */ fipssha256 = EVP_MD_fetch(fips_libctx, “SHA2-256”, NULL); if (fipssha256 == NULL) goto err; /* Get a non-FIPS validated digest */ nonfipssha256 = EVP_MD_fetch(nonfips_libctx, “SHA2-256”, NULL); if (nonfipssha256 == NULL) goto err; /* Use the digests */ printf(“Success “); ret = 0; err: EVP_MD_free(fipssha256); EVP_MD_free(nonfipssha256); OSSL_LIB_CTX_free(fips_libctx); OSSL_LIB_CTX_free(nonfips_libctx); OSSL_PROVIDER_unload(defctxnull); return ret;

Note that we have made use of the special “null” provider here which we load into the default library context. We could have chosen to use the default library context for FIPS usage, and just create one additional library context for other usages - or vice versa. However if code has not been converted to use library contexts then the default library context will be automatically used. This could be the case for your own existing applications as well as certain parts of OpenSSL itself. Not all parts of OpenSSL are library context aware. If this happens then you could “accidentally” use the wrong library context for a particular operation. To be sure this doesn’t happen you can load the “null” provider into the default library context. Because a provider has been explicitly loaded, the default provider will not automatically load. This means code using the default context by accident will fail because no algorithms will be available.

See “Library Context” in ossl-guide-migration (7) for additional information about the Library Context.

Using Encoders and Decoders with the FIPS module

Encoders and decoders are used to read and write keys or parameters from or to some external format (for example a PEM file). If your application generates keys or parameters that then need to be written into PEM or DER format then it is likely that you will need to use an encoder to do this. Similarly you need a decoder to read previously saved keys and parameters. In most cases this will be invisible to you if you are using APIs that existed in OpenSSL 1.1.1 or earlier such as i2d_PrivateKey (3). However the appropriate encoder/decoder will need to be available in the library context associated with the key or parameter object. The built-in OpenSSL encoders and decoders are implemented in both the default and base providers and are not in the FIPS module boundary. However since they are not cryptographic algorithms themselves it is still possible to use them in conjunction with the FIPS module, and therefore these encoders/decoders have the fips=yes property against them. You should ensure that either the default or base provider is loaded into the library context in this case.

Using the FIPS module in SSL/TLS

Writing an application that uses libssl in conjunction with the FIPS module is much the same as writing a normal libssl application. If you are using global properties and the default library context to specify usage of FIPS validated algorithms then this will happen automatically for all cryptographic algorithms in libssl. If you are using a nondefault library context to load the FIPS provider then you can supply this to libssl using the function SSL_CTX_new_ex (3). This works as a drop in replacement for the function SSL_CTX_new (3) except it provides you with the capability to specify the library context to be used. You can also use the same function to specify libssl specific properties to use.

In this first example we create two SSL_CTX objects using two different library contexts.

/* * We assume that a nondefault library context with the FIPS * provider loaded has been created called fips_libctx. */ SSL_CTX *fips_ssl_ctx = SSL_CTX_new_ex(fips_libctx, “fips=yes”, TLS_method()); /* * We assume that a nondefault library context with the default * provider loaded has been created called non_fips_libctx. */ SSL_CTX *non_fips_ssl_ctx = SSL_CTX_new_ex(non_fips_libctx, NULL, TLS_method());

In this second example we create two SSL_CTX objects using different properties to specify FIPS usage:

/* * The “fips=yes” property includes all FIPS approved algorithms * as well as encoders from the default provider that are allowed * to be used. The NULL below indicates that we are using the * default library context. */ SSL_CTX *fips_ssl_ctx = SSL_CTX_new_ex(NULL, “fips=yes”, TLS_method()); /* * The “provider!=fips” property allows algorithms from any * provider except the FIPS provider */ SSL_CTX *non_fips_ssl_ctx = SSL_CTX_new_ex(NULL, “provider!=fips”, TLS_method());

Confirming that an algorithm is being provided by the FIPS module

A chain of links needs to be followed to go from an algorithm instance to the provider that implements it. The process is similar for all algorithms. Here the example of a digest is used.

To go from an EVP_MD_CTX to an EVP_MD, use EVP_MD_CTX_md (3) . To go from the EVP_MD to its OSSL_PROVIDER, use EVP_MD_get0_provider (3). To extract the name from the OSSL_PROVIDER, use OSSL_PROVIDER_get0_name (3).

NOTES

Some released versions of OpenSSL do not include a validated FIPS provider. To determine which versions have undergone the validation process, please refer to the OpenSSL Downloads page <https://www.openssl.org/source/>. If you require FIPS-approved functionality, it is essential to build your FIPS provider using one of the validated versions listed there. Normally, it is possible to utilize a FIPS provider constructed from one of the validated versions alongside libcrypto and libssl compiled from any release within the same major release series. This flexibility enables you to address bug fixes and CVEs that fall outside the FIPS boundary.

The FIPS provider in OpenSSL 3.1 includes some non-FIPS validated algorithms, consequently the property query fips=yes is mandatory for applications that want to operate in a FIPS approved manner. The algorithms are:

Triple DES ECB

Triple DES CBC

EdDSA

SEE ALSO

ossl-guide-migration (7), crypto (7), fips_config (5), <https://www.openssl.org/source/>

HISTORY

The FIPS module guide was created for use with the new FIPS provider in OpenSSL 3.0.

COPYRIGHT

Copyright 2021-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

577 - Linux cli command EVP_KEYMGMT-ED25519ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_KEYMGMT-ED25519ssl and provides detailed information about the command EVP_KEYMGMT-ED25519ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_KEYMGMT-ED25519ssl.

NAME 🖥️ EVP_KEYMGMT-ED25519ssl 🖥️

X25519, EVP_PKEY-X448, EVP_PKEY-ED25519, EVP_PKEY-ED448, EVP_KEYMGMT-X25519, EVP_KEYMGMT-X448, EVP_KEYMGMT-ED25519, EVP_KEYMGMT-ED448 - EVP_PKEY X25519, X448, ED25519 and ED448 keytype and algorithm support

DESCRIPTION

The X25519, X448, ED25519 and ED448 keytypes are implemented in OpenSSL’s default and FIPS providers. These implementations support the associated key, containing the public key pub and the private key priv.

Keygen Parameters

“dhkem-ikm” (OSSL_PKEY_PARAM_DHKEM_IKM) <octet string>
DHKEM requires the generation of a keypair using an input key material (seed). Use this to specify the key material used for generation of the private key. This value should not be reused for other purposes. It should have a length of at least 32 for X25519, and 56 for X448. This is only supported by X25519 and X448.

Use EVP_PKEY_CTX_set_params() after calling EVP_PKEY_keygen_init().

Common X25519, X448, ED25519 and ED448 parameters

In addition to the common parameters that all keytypes should support (see “Common parameters” in provider-keymgmt (7)), the implementation of these keytypes support the following.

“group” (OSSL_PKEY_PARAM_GROUP_NAME) <UTF8 string>
This is only supported by X25519 and X448. The group name must be “x25519” or “x448” respectively for those algorithms. This is only present for consistency with other key exchange algorithms and is typically not needed.

“pub” (OSSL_PKEY_PARAM_PUB_KEY) <octet string>
The public key value.

“priv” (OSSL_PKEY_PARAM_PRIV_KEY) <octet string>
The private key value.

“encoded-pub-key” (OSSL_PKEY_PARAM_ENCODED_PUBLIC_KEY) <octet string>
Used for getting and setting the encoding of a public key for the X25519 and X448 key types. Public keys are expected be encoded in a format as defined by RFC7748.

ED25519 and ED448 parameters

“mandatory-digest” (OSSL_PKEY_PARAM_MANDATORY_DIGEST) <UTF8 string>
The empty string, signifying that no digest may be specified.

CONFORMING TO

RFC 8032

RFC 8410

EXAMPLES

An EVP_PKEY context can be obtained by calling:

EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “X25519”, NULL); EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “X448”, NULL); EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “ED25519”, NULL); EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “ED448”, NULL);

An X25519 key can be generated like this:

pkey = EVP_PKEY_Q_keygen(NULL, NULL, “X25519”);

An X448, ED25519, or ED448 key can be generated likewise.

SEE ALSO

EVP_KEYMGMT (3), EVP_PKEY (3), provider-keymgmt (7), EVP_KEYEXCH-X25519 (7), EVP_KEYEXCH-X448 (7), EVP_SIGNATURE-ED25519 (7), EVP_SIGNATURE-ED448 (7)

COPYRIGHT

Copyright 2020-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

578 - Linux cli command sched

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command sched and provides detailed information about the command sched, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the sched.

NAME 🖥️ sched 🖥️

overview of CPU scheduling

DESCRIPTION

Since Linux 2.6.23, the default scheduler is CFS, the “Completely Fair Scheduler”. The CFS scheduler replaced the earlier “O(1)” scheduler.

API summary

Linux provides the following system calls for controlling the CPU scheduling behavior, policy, and priority of processes (or, more precisely, threads).

nice(2)
Set a new nice value for the calling thread, and return the new nice value.

getpriority(2)
Return the nice value of a thread, a process group, or the set of threads owned by a specified user.

setpriority(2)
Set the nice value of a thread, a process group, or the set of threads owned by a specified user.

sched_setscheduler(2)
Set the scheduling policy and parameters of a specified thread.

sched_getscheduler(2)
Return the scheduling policy of a specified thread.

sched_setparam(2)
Set the scheduling parameters of a specified thread.

sched_getparam(2)
Fetch the scheduling parameters of a specified thread.

sched_get_priority_max(2)
Return the maximum priority available in a specified scheduling policy.

sched_get_priority_min(2)
Return the minimum priority available in a specified scheduling policy.

sched_rr_get_interval(2)
Fetch the quantum used for threads that are scheduled under the “round-robin” scheduling policy.

sched_yield(2)
Cause the caller to relinquish the CPU, so that some other thread be executed.

sched_setaffinity(2)
(Linux-specific) Set the CPU affinity of a specified thread.

sched_getaffinity(2)
(Linux-specific) Get the CPU affinity of a specified thread.

sched_setattr(2)
Set the scheduling policy and parameters of a specified thread. This (Linux-specific) system call provides a superset of the functionality of sched_setscheduler(2) and sched_setparam(2).

sched_getattr(2)
Fetch the scheduling policy and parameters of a specified thread. This (Linux-specific) system call provides a superset of the functionality of sched_getscheduler(2) and sched_getparam(2).

Scheduling policies

The scheduler is the kernel component that decides which runnable thread will be executed by the CPU next. Each thread has an associated scheduling policy and a static scheduling priority, sched_priority. The scheduler makes its decisions based on knowledge of the scheduling policy and static priority of all threads on the system.

For threads scheduled under one of the normal scheduling policies (SCHED_OTHER, SCHED_IDLE, SCHED_BATCH), sched_priority is not used in scheduling decisions (it must be specified as 0).

Processes scheduled under one of the real-time policies (SCHED_FIFO, SCHED_RR) have a sched_priority value in the range 1 (low) to 99 (high). (As the numbers imply, real-time threads always have higher priority than normal threads.) Note well: POSIX.1 requires an implementation to support only a minimum 32 distinct priority levels for the real-time policies, and some systems supply just this minimum. Portable programs should use sched_get_priority_min(2) and sched_get_priority_max(2) to find the range of priorities supported for a particular policy.

Conceptually, the scheduler maintains a list of runnable threads for each possible sched_priority value. In order to determine which thread runs next, the scheduler looks for the nonempty list with the highest static priority and selects the thread at the head of this list.

A thread’s scheduling policy determines where it will be inserted into the list of threads with equal static priority and how it will move inside this list.

All scheduling is preemptive: if a thread with a higher static priority becomes ready to run, the currently running thread will be preempted and returned to the wait list for its static priority level. The scheduling policy determines the ordering only within the list of runnable threads with equal static priority.

SCHED_FIFO: First in-first out scheduling

SCHED_FIFO can be used only with static priorities higher than 0, which means that when a SCHED_FIFO thread becomes runnable, it will always immediately preempt any currently running SCHED_OTHER, SCHED_BATCH, or SCHED_IDLE thread. SCHED_FIFO is a simple scheduling algorithm without time slicing. For threads scheduled under the SCHED_FIFO policy, the following rules apply:

  • A running SCHED_FIFO thread that has been preempted by another thread of higher priority will stay at the head of the list for its priority and will resume execution as soon as all threads of higher priority are blocked again.

  • When a blocked SCHED_FIFO thread becomes runnable, it will be inserted at the end of the list for its priority.

  • If a call to sched_setscheduler(2), sched_setparam(2), sched_setattr(2), pthread_setschedparam(3), or pthread_setschedprio(3) changes the priority of the running or runnable SCHED_FIFO thread identified by pid the effect on the thread’s position in the list depends on the direction of the change to the thread’s priority:

    1. If the thread’s priority is raised, it is placed at the end of the list for its new priority. As a consequence, it may preempt a currently running thread with the same priority.

    2. If the thread’s priority is unchanged, its position in the run list is unchanged.

    3. If the thread’s priority is lowered, it is placed at the front of the list for its new priority.

    According to POSIX.1-2008, changes to a thread’s priority (or policy) using any mechanism other than pthread_setschedprio(3) should result in the thread being placed at the end of the list for its priority.

  • A thread calling sched_yield(2) will be put at the end of the list.

No other events will move a thread scheduled under the SCHED_FIFO policy in the wait list of runnable threads with equal static priority.

A SCHED_FIFO thread runs until either it is blocked by an I/O request, it is preempted by a higher priority thread, or it calls sched_yield(2).

SCHED_RR: Round-robin scheduling

SCHED_RR is a simple enhancement of SCHED_FIFO. Everything described above for SCHED_FIFO also applies to SCHED_RR, except that each thread is allowed to run only for a maximum time quantum. If a SCHED_RR thread has been running for a time period equal to or longer than the time quantum, it will be put at the end of the list for its priority. A SCHED_RR thread that has been preempted by a higher priority thread and subsequently resumes execution as a running thread will complete the unexpired portion of its round-robin time quantum. The length of the time quantum can be retrieved using sched_rr_get_interval(2).

SCHED_DEADLINE: Sporadic task model deadline scheduling

Since Linux 3.14, Linux provides a deadline scheduling policy (SCHED_DEADLINE). This policy is currently implemented using GEDF (Global Earliest Deadline First) in conjunction with CBS (Constant Bandwidth Server). To set and fetch this policy and associated attributes, one must use the Linux-specific sched_setattr(2) and sched_getattr(2) system calls.

A sporadic task is one that has a sequence of jobs, where each job is activated at most once per period. Each job also has a relative deadline, before which it should finish execution, and a computation time, which is the CPU time necessary for executing the job. The moment when a task wakes up because a new job has to be executed is called the arrival time (also referred to as the request time or release time). The start time is the time at which a task starts its execution. The absolute deadline is thus obtained by adding the relative deadline to the arrival time.

The following diagram clarifies these terms:

arrival/wakeup                    absolute deadline
     |    start time                    |
     |        |                         |
     v        v                         v
-----x--------xooooooooooooooooo--------x--------x---
              |<- comp. time ->|
     |<------- relative deadline ------>|
     |<-------------- period ------------------->|

When setting a SCHED_DEADLINE policy for a thread using sched_setattr(2), one can specify three parameters: Runtime, Deadline, and Period. These parameters do not necessarily correspond to the aforementioned terms: usual practice is to set Runtime to something bigger than the average computation time (or worst-case execution time for hard real-time tasks), Deadline to the relative deadline, and Period to the period of the task. Thus, for SCHED_DEADLINE scheduling, we have:

arrival/wakeup                    absolute deadline
     |    start time                    |
     |        |                         |
     v        v                         v
-----x--------xooooooooooooooooo--------x--------x---
              |<-- Runtime ------->|
     |<----------- Deadline ----------->|
     |<-------------- Period ------------------->|

The three deadline-scheduling parameters correspond to the sched_runtime, sched_deadline, and sched_period fields of the sched_attr structure; see sched_setattr(2). These fields express values in nanoseconds. If sched_period is specified as 0, then it is made the same as sched_deadline.

The kernel requires that:

sched_runtime <= sched_deadline <= sched_period

In addition, under the current implementation, all of the parameter values must be at least 1024 (i.e., just over one microsecond, which is the resolution of the implementation), and less than 2^63. If any of these checks fails, sched_setattr(2) fails with the error EINVAL.

The CBS guarantees non-interference between tasks, by throttling threads that attempt to over-run their specified Runtime.

To ensure deadline scheduling guarantees, the kernel must prevent situations where the set of SCHED_DEADLINE threads is not feasible (schedulable) within the given constraints. The kernel thus performs an admittance test when setting or changing SCHED_DEADLINE policy and attributes. This admission test calculates whether the change is feasible; if it is not, sched_setattr(2) fails with the error EBUSY.

For example, it is required (but not necessarily sufficient) for the total utilization to be less than or equal to the total number of CPUs available, where, since each thread can maximally run for Runtime per Period, that thread’s utilization is its Runtime divided by its Period.

In order to fulfill the guarantees that are made when a thread is admitted to the SCHED_DEADLINE policy, SCHED_DEADLINE threads are the highest priority (user controllable) threads in the system; if any SCHED_DEADLINE thread is runnable, it will preempt any thread scheduled under one of the other policies.

A call to fork(2) by a thread scheduled under the SCHED_DEADLINE policy fails with the error EAGAIN, unless the thread has its reset-on-fork flag set (see below).

A SCHED_DEADLINE thread that calls sched_yield(2) will yield the current job and wait for a new period to begin.

SCHED_OTHER: Default Linux time-sharing scheduling

SCHED_OTHER can be used at only static priority 0 (i.e., threads under real-time policies always have priority over SCHED_OTHER processes). SCHED_OTHER is the standard Linux time-sharing scheduler that is intended for all threads that do not require the special real-time mechanisms.

The thread to run is chosen from the static priority 0 list based on a dynamic priority that is determined only inside this list. The dynamic priority is based on the nice value (see below) and is increased for each time quantum the thread is ready to run, but denied to run by the scheduler. This ensures fair progress among all SCHED_OTHER threads.

In the Linux kernel source code, the SCHED_OTHER policy is actually named SCHED_NORMAL.

The nice value

The nice value is an attribute that can be used to influence the CPU scheduler to favor or disfavor a process in scheduling decisions. It affects the scheduling of SCHED_OTHER and SCHED_BATCH (see below) processes. The nice value can be modified using nice(2), setpriority(2), or sched_setattr(2).

According to POSIX.1, the nice value is a per-process attribute; that is, the threads in a process should share a nice value. However, on Linux, the nice value is a per-thread attribute: different threads in the same process may have different nice values.

The range of the nice value varies across UNIX systems. On modern Linux, the range is -20 (high priority) to +19 (low priority). On some other systems, the range is -20..20. Very early Linux kernels (before Linux 2.0) had the range -infinity..15.

The degree to which the nice value affects the relative scheduling of SCHED_OTHER processes likewise varies across UNIX systems and across Linux kernel versions.

With the advent of the CFS scheduler in Linux 2.6.23, Linux adopted an algorithm that causes relative differences in nice values to have a much stronger effect. In the current implementation, each unit of difference in the nice values of two processes results in a factor of 1.25 in the degree to which the scheduler favors the higher priority process. This causes very low nice values (+19) to truly provide little CPU to a process whenever there is any other higher priority load on the system, and makes high nice values (-20) deliver most of the CPU to applications that require it (e.g., some audio applications).

On Linux, the RLIMIT_NICE resource limit can be used to define a limit to which an unprivileged process’s nice value can be raised; see setrlimit(2) for details.

For further details on the nice value, see the subsections on the autogroup feature and group scheduling, below.

SCHED_BATCH: Scheduling batch processes

(Since Linux 2.6.16.) SCHED_BATCH can be used only at static priority 0. This policy is similar to SCHED_OTHER in that it schedules the thread according to its dynamic priority (based on the nice value). The difference is that this policy will cause the scheduler to always assume that the thread is CPU-intensive. Consequently, the scheduler will apply a small scheduling penalty with respect to wakeup behavior, so that this thread is mildly disfavored in scheduling decisions.

This policy is useful for workloads that are noninteractive, but do not want to lower their nice value, and for workloads that want a deterministic scheduling policy without interactivity causing extra preemptions (between the workload’s tasks).

SCHED_IDLE: Scheduling very low priority jobs

(Since Linux 2.6.23.) SCHED_IDLE can be used only at static priority 0; the process nice value has no influence for this policy.

This policy is intended for running jobs at extremely low priority (lower even than a +19 nice value with the SCHED_OTHER or SCHED_BATCH policies).

Resetting scheduling policy for child processes

Each thread has a reset-on-fork scheduling flag. When this flag is set, children created by fork(2) do not inherit privileged scheduling policies. The reset-on-fork flag can be set by either:

  • ORing the SCHED_RESET_ON_FORK flag into the policy argument when calling sched_setscheduler(2) (since Linux 2.6.32); or

  • specifying the SCHED_FLAG_RESET_ON_FORK flag in attr.sched_flags when calling sched_setattr(2).

Note that the constants used with these two APIs have different names. The state of the reset-on-fork flag can analogously be retrieved using sched_getscheduler(2) and sched_getattr(2).

The reset-on-fork feature is intended for media-playback applications, and can be used to prevent applications evading the RLIMIT_RTTIME resource limit (see getrlimit(2)) by creating multiple child processes.

More precisely, if the reset-on-fork flag is set, the following rules apply for subsequently created children:

  • If the calling thread has a scheduling policy of SCHED_FIFO or SCHED_RR, the policy is reset to SCHED_OTHER in child processes.

  • If the calling process has a negative nice value, the nice value is reset to zero in child processes.

After the reset-on-fork flag has been enabled, it can be reset only if the thread has the CAP_SYS_NICE capability. This flag is disabled in child processes created by fork(2).

Privileges and resource limits

Before Linux 2.6.12, only privileged (CAP_SYS_NICE) threads can set a nonzero static priority (i.e., set a real-time scheduling policy). The only change that an unprivileged thread can make is to set the SCHED_OTHER policy, and this can be done only if the effective user ID of the caller matches the real or effective user ID of the target thread (i.e., the thread specified by pid) whose policy is being changed.

A thread must be privileged (CAP_SYS_NICE) in order to set or modify a SCHED_DEADLINE policy.

Since Linux 2.6.12, the RLIMIT_RTPRIO resource limit defines a ceiling on an unprivileged thread’s static priority for the SCHED_RR and SCHED_FIFO policies. The rules for changing scheduling policy and priority are as follows:

  • If an unprivileged thread has a nonzero RLIMIT_RTPRIO soft limit, then it can change its scheduling policy and priority, subject to the restriction that the priority cannot be set to a value higher than the maximum of its current priority and its RLIMIT_RTPRIO soft limit.

  • If the RLIMIT_RTPRIO soft limit is 0, then the only permitted changes are to lower the priority, or to switch to a non-real-time policy.

  • Subject to the same rules, another unprivileged thread can also make these changes, as long as the effective user ID of the thread making the change matches the real or effective user ID of the target thread.

  • Special rules apply for the SCHED_IDLE policy. Before Linux 2.6.39, an unprivileged thread operating under this policy cannot change its policy, regardless of the value of its RLIMIT_RTPRIO resource limit. Since Linux 2.6.39, an unprivileged thread can switch to either the SCHED_BATCH or the SCHED_OTHER policy so long as its nice value falls within the range permitted by its RLIMIT_NICE resource limit (see getrlimit(2)).

Privileged (CAP_SYS_NICE) threads ignore the RLIMIT_RTPRIO limit; as with older kernels, they can make arbitrary changes to scheduling policy and priority. See getrlimit(2) for further information on RLIMIT_RTPRIO.

Limiting the CPU usage of real-time and deadline processes

A nonblocking infinite loop in a thread scheduled under the SCHED_FIFO, SCHED_RR, or SCHED_DEADLINE policy can potentially block all other threads from accessing the CPU forever. Before Linux 2.6.25, the only way of preventing a runaway real-time process from freezing the system was to run (at the console) a shell scheduled under a higher static priority than the tested application. This allows an emergency kill of tested real-time applications that do not block or terminate as expected.

Since Linux 2.6.25, there are other techniques for dealing with runaway real-time and deadline processes. One of these is to use the RLIMIT_RTTIME resource limit to set a ceiling on the CPU time that a real-time process may consume. See getrlimit(2) for details.

Since Linux 2.6.25, Linux also provides two /proc files that can be used to reserve a certain amount of CPU time to be used by non-real-time processes. Reserving CPU time in this fashion allows some CPU time to be allocated to (say) a root shell that can be used to kill a runaway process. Both of these files specify time values in microseconds:

/proc/sys/kernel/sched_rt_period_us
This file specifies a scheduling period that is equivalent to 100% CPU bandwidth. The value in this file can range from 1 to INT_MAX, giving an operating range of 1 microsecond to around 35 minutes. The default value in this file is 1,000,000 (1 second).

/proc/sys/kernel/sched_rt_runtime_us
The value in this file specifies how much of the “period” time can be used by all real-time and deadline scheduled processes on the system. The value in this file can range from -1 to INT_MAX-1. Specifying -1 makes the run time the same as the period; that is, no CPU time is set aside for non-real-time processes (which was the behavior before Linux 2.6.25). The default value in this file is 950,000 (0.95 seconds), meaning that 5% of the CPU time is reserved for processes that don’t run under a real-time or deadline scheduling policy.

Response time

A blocked high priority thread waiting for I/O has a certain response time before it is scheduled again. The device driver writer can greatly reduce this response time by using a “slow interrupt” interrupt handler.

Miscellaneous

Child processes inherit the scheduling policy and parameters across a fork(2). The scheduling policy and parameters are preserved across execve(2).

Memory locking is usually needed for real-time processes to avoid paging delays; this can be done with mlock(2) or mlockall(2).

The autogroup feature

Since Linux 2.6.38, the kernel provides a feature known as autogrouping to improve interactive desktop performance in the face of multiprocess, CPU-intensive workloads such as building the Linux kernel with large numbers of parallel build processes (i.e., the make(1) -j flag).

This feature operates in conjunction with the CFS scheduler and requires a kernel that is configured with CONFIG_SCHED_AUTOGROUP. On a running system, this feature is enabled or disabled via the file /proc/sys/kernel/sched_autogroup_enabled; a value of 0 disables the feature, while a value of 1 enables it. The default value in this file is 1, unless the kernel was booted with the noautogroup parameter.

A new autogroup is created when a new session is created via setsid(2); this happens, for example, when a new terminal window is started. A new process created by fork(2) inherits its parent’s autogroup membership. Thus, all of the processes in a session are members of the same autogroup. An autogroup is automatically destroyed when the last process in the group terminates.

When autogrouping is enabled, all of the members of an autogroup are placed in the same kernel scheduler “task group”. The CFS scheduler employs an algorithm that equalizes the distribution of CPU cycles across task groups. The benefits of this for interactive desktop performance can be described via the following example.

Suppose that there are two autogroups competing for the same CPU (i.e., presume either a single CPU system or the use of taskset(1) to confine all the processes to the same CPU on an SMP system). The first group contains ten CPU-bound processes from a kernel build started with make -j10. The other contains a single CPU-bound process: a video player. The effect of autogrouping is that the two groups will each receive half of the CPU cycles. That is, the video player will receive 50% of the CPU cycles, rather than just 9% of the cycles, which would likely lead to degraded video playback. The situation on an SMP system is more complex, but the general effect is the same: the scheduler distributes CPU cycles across task groups such that an autogroup that contains a large number of CPU-bound processes does not end up hogging CPU cycles at the expense of the other jobs on the system.

A process’s autogroup (task group) membership can be viewed via the file /proc/pid/autogroup:

$ cat /proc/1/autogroup
/autogroup-1 nice 0

This file can also be used to modify the CPU bandwidth allocated to an autogroup. This is done by writing a number in the “nice” range to the file to set the autogroup’s nice value. The allowed range is from +19 (low priority) to -20 (high priority). (Writing values outside of this range causes write(2) to fail with the error EINVAL.)

The autogroup nice setting has the same meaning as the process nice value, but applies to distribution of CPU cycles to the autogroup as a whole, based on the relative nice values of other autogroups. For a process inside an autogroup, the CPU cycles that it receives will be a product of the autogroup’s nice value (compared to other autogroups) and the process’s nice value (compared to other processes in the same autogroup.

The use of the cgroups(7) CPU controller to place processes in cgroups other than the root CPU cgroup overrides the effect of autogrouping.

The autogroup feature groups only processes scheduled under non-real-time policies (SCHED_OTHER, SCHED_BATCH, and SCHED_IDLE). It does not group processes scheduled under real-time and deadline policies. Those processes are scheduled according to the rules described earlier.

The nice value and group scheduling

When scheduling non-real-time processes (i.e., those scheduled under the SCHED_OTHER, SCHED_BATCH, and SCHED_IDLE policies), the CFS scheduler employs a technique known as “group scheduling”, if the kernel was configured with the CONFIG_FAIR_GROUP_SCHED option (which is typical).

Under group scheduling, threads are scheduled in “task groups”. Task groups have a hierarchical relationship, rooted under the initial task group on the system, known as the “root task group”. Task groups are formed in the following circumstances:

  • All of the threads in a CPU cgroup form a task group. The parent of this task group is the task group of the corresponding parent cgroup.

  • If autogrouping is enabled, then all of the threads that are (implicitly) placed in an autogroup (i.e., the same session, as created by setsid(2)) form a task group. Each new autogroup is thus a separate task group. The root task group is the parent of all such autogroups.

  • If autogrouping is enabled, then the root task group consists of all processes in the root CPU cgroup that were not otherwise implicitly placed into a new autogroup.

  • If autogrouping is disabled, then the root task group consists of all processes in the root CPU cgroup.

  • If group scheduling was disabled (i.e., the kernel was configured without CONFIG_FAIR_GROUP_SCHED), then all of the processes on the system are notionally placed in a single task group.

Under group scheduling, a thread’s nice value has an effect for scheduling decisions only relative to other threads in the same task group. This has some surprising consequences in terms of the traditional semantics of the nice value on UNIX systems. In particular, if autogrouping is enabled (which is the default in various distributions), then employing setpriority(2) or nice(1) on a process has an effect only for scheduling relative to other processes executed in the same session (typically: the same terminal window).

Conversely, for two processes that are (for example) the sole CPU-bound processes in different sessions (e.g., different terminal windows, each of whose jobs are tied to different autogroups), modifying the nice value of the process in one of the sessions has no effect in terms of the scheduler’s decisions relative to the process in the other session. A possibly useful workaround here is to use a command such as the following to modify the autogroup nice value for all of the processes in a terminal session:

$ echo 10 > /proc/self/autogroup

Real-time features in the mainline Linux kernel

Since Linux 2.6.18, Linux is gradually becoming equipped with real-time capabilities, most of which are derived from the former realtime-preempt patch set. Until the patches have been completely merged into the mainline kernel, they must be installed to achieve the best real-time performance. These patches are named:

patch-kernelversion-rtpatchversion

and can be downloaded from .

Without the patches and prior to their full inclusion into the mainline kernel, the kernel configuration offers only the three preemption classes CONFIG_PREEMPT_NONE, CONFIG_PREEMPT_VOLUNTARY, and CONFIG_PREEMPT_DESKTOP which respectively provide no, some, and considerable reduction of the worst-case scheduling latency.

With the patches applied or after their full inclusion into the mainline kernel, the additional configuration item CONFIG_PREEMPT_RT becomes available. If this is selected, Linux is transformed into a regular real-time operating system. The FIFO and RR scheduling policies are then used to run a thread with true real-time priority and a minimum worst-case scheduling latency.

NOTES

The cgroups(7) CPU controller can be used to limit the CPU consumption of groups of processes.

Originally, Standard Linux was intended as a general-purpose operating system being able to handle background processes, interactive applications, and less demanding real-time applications (applications that need to usually meet timing deadlines). Although the Linux 2.6 allowed for kernel preemption and the newly introduced O(1) scheduler ensures that the time needed to schedule is fixed and deterministic irrespective of the number of active tasks, true real-time computing was not possible up to Linux 2.6.17.

SEE ALSO

chcpu(1), chrt(1), lscpu(1), ps(1), taskset(1), top(1), getpriority(2), mlock(2), mlockall(2), munlock(2), munlockall(2), nice(2), sched_get_priority_max(2), sched_get_priority_min(2), sched_getaffinity(2), sched_getparam(2), sched_getscheduler(2), sched_rr_get_interval(2), sched_setaffinity(2), sched_setparam(2), sched_setscheduler(2), sched_yield(2), setpriority(2), pthread_getaffinity_np(3), pthread_getschedparam(3), pthread_setaffinity_np(3), sched_getcpu(3), capabilities(7), cpuset(7)

Programming for the real world - POSIX.4 by Bill O. Gallmeister, O’Reilly & Associates, Inc., ISBN 1-56592-074-0.

The Linux kernel source files Documentation/scheduler/sched-deadline.txt, Documentation/scheduler/sched-rt-group.txt, Documentation/scheduler/sched-design-CFS.txt, and Documentation/scheduler/sched-nice-design.txt

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

579 - Linux cli command kernel_lockdown

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command kernel_lockdown and provides detailed information about the command kernel_lockdown, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the kernel_lockdown.

NAME 🖥️ kernel_lockdown 🖥️

kernel image access prevention feature

DESCRIPTION

The Kernel Lockdown feature is designed to prevent both direct and indirect access to a running kernel image, attempting to protect against unauthorized modification of the kernel image and to prevent access to security and cryptographic data located in kernel memory, whilst still permitting driver modules to be loaded.

If a prohibited or restricted feature is accessed or used, the kernel will emit a message that looks like:

Lockdown: X: Y is restricted, see man kernel_lockdown.7

where X indicates the process name and Y indicates what is restricted.

On an EFI-enabled x86 or arm64 machine, lockdown will be automatically enabled if the system boots in EFI Secure Boot mode.

Coverage

When lockdown is in effect, a number of features are disabled or have their use restricted. This includes special device files and kernel services that allow direct access of the kernel image:

/dev/mem
/dev/kmem
/dev/kcore
/dev/ioports
BPF
kprobes

and the ability to directly configure and control devices, so as to prevent the use of a device to access or modify a kernel image:

  • The use of module parameters that directly specify hardware parameters to drivers through the kernel command line or when loading a module.

  • The use of direct PCI BAR access.

  • The use of the ioperm and iopl instructions on x86.

  • The use of the KD*IO console ioctls.

  • The use of the TIOCSSERIAL serial ioctl.

  • The alteration of MSR registers on x86.

  • The replacement of the PCMCIA CIS.

  • The overriding of ACPI tables.

  • The use of ACPI error injection.

  • The specification of the ACPI RDSP address.

  • The use of ACPI custom methods.

Certain facilities are restricted:

  • Only validly signed modules may be loaded (waived if the module file being loaded is vouched for by IMA appraisal).

  • Only validly signed binaries may be kexec’d (waived if the binary image file to be executed is vouched for by IMA appraisal).

  • Unencrypted hibernation/suspend to swap are disallowed as the kernel image is saved to a medium that can then be accessed.

  • Use of debugfs is not permitted as this allows a whole range of actions including direct configuration of, access to and driving of hardware.

  • IMA requires the addition of the “secure_boot” rules to the policy, whether or not they are specified on the command line, for both the built-in and custom policies in secure boot lockdown mode.

VERSIONS

The Kernel Lockdown feature was added in Linux 5.4.

NOTES

The Kernel Lockdown feature is enabled by CONFIG_SECURITY_LOCKDOWN_LSM. The lsm=lsm1,…,lsmN command line parameter controls the sequence of the initialization of Linux Security Modules. It must contain the string lockdown to enable the Kernel Lockdown feature. If the command line parameter is not specified, the initialization falls back to the value of the deprecated security= command line parameter and further to the value of CONFIG_LSM.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

580 - Linux cli command latin5

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command latin5 and provides detailed information about the command latin5, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the latin5.

NAME 🖥️ latin5 🖥️

9 - ISO/IEC 8859-9 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-9 encodes the characters used in Turkish.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-9 characters

The following table displays the characters in ISO/IEC 8859-9 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-9 is also known as Latin-5.

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

581 - Linux cli command user-keyring

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command user-keyring and provides detailed information about the command user-keyring, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the user-keyring.

NAME 🖥️ user-keyring 🖥️

keyring - per-user keyring

DESCRIPTION

The user keyring is a keyring used to anchor keys on behalf of a user. Each UID the kernel deals with has its own user keyring that is shared by all processes with that UID. The user keyring has a name (description) of the form _uid.<UID> where <UID> is the user ID of the corresponding user.

The user keyring is associated with the record that the kernel maintains for the UID. It comes into existence upon the first attempt to access either the user keyring, the user-session-keyring(7), or the session-keyring(7). The keyring remains pinned in existence so long as there are processes running with that real UID or files opened by those processes remain open. (The keyring can also be pinned indefinitely by linking it into another keyring.)

Typically, the user keyring is created by pam_keyinit(8) when a user logs in.

The user keyring is not searched by default by request_key(2). When pam_keyinit(8) creates a session keyring, it adds to it a link to the user keyring so that the user keyring will be searched when the session keyring is.

A special serial number value, KEY_SPEC_USER_KEYRING, is defined that can be used in lieu of the actual serial number of the calling process’s user keyring.

From the keyctl(1) utility, ‘@u’ can be used instead of a numeric key ID in much the same way.

User keyrings are independent of clone(2), fork(2), vfork(2), execve(2), and _exit(2) excepting that the keyring is destroyed when the UID record is destroyed when the last process pinning it exits.

If it is necessary for a key associated with a user to exist beyond the UID record being garbage collected—for example, for use by a cron(8) script—then the persistent-keyring(7) should be used instead.

If a user keyring does not exist when it is accessed, it will be created.

SEE ALSO

keyctl(1), keyctl(3), keyrings(7), persistent-keyring(7), process-keyring(7), session-keyring(7), thread-keyring(7), user-session-keyring(7), pam_keyinit(8)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

582 - Linux cli command system_data_types

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command system_data_types and provides detailed information about the command system_data_types, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the system_data_types.

NAME 🖥️ system_data_types 🖥️

overview of system data types

DESCRIPTION

siginfo_t

Include: <signal.h>. Alternatively, <sys/wait.h>.

typedef struct {
    int      si_signo;  /* Signal number */
    int      si_code;   /* Signal code */
    pid_t    si_pid;    /* Sending process ID */
    uid_t    si_uid;    /* Real user ID of sending process */
    void    *si_addr;   /* Memory location which caused fault */
    int      si_status; /* Exit value or signal */
    union sigval si_value;  /* Signal value */
} siginfo_t;

Information associated with a signal. For further details on this structure (including additional, Linux-specific fields), see sigaction(2).

Conforming to: POSIX.1-2001 and later.

See also: pidfd_send_signal(2), rt_sigqueueinfo(2), sigaction(2), sigwaitinfo(2), psiginfo(3)

sigset_t

Include: <signal.h>. Alternatively, <spawn.h>, or <sys/select.h>.

This is a type that represents a set of signals. According to POSIX, this shall be an integer or structure type.

Conforming to: POSIX.1-2001 and later.

See also: epoll_pwait(2), ppoll(2), pselect(2), sigaction(2), signalfd(2), sigpending(2), sigprocmask(2), sigsuspend(2), sigwaitinfo(2), signal(7)

NOTES

The structures described in this manual page shall contain, at least, the members shown in their definition, in no particular order.

Most of the integer types described in this page don’t have a corresponding length modifier for the printf(3) and the scanf(3) families of functions. To print a value of an integer type that doesn’t have a length modifier, it should be converted to intmax_t or uintmax_t by an explicit cast. To scan into a variable of an integer type that doesn’t have a length modifier, an intermediate temporary variable of type intmax_t or uintmax_t should be used. When copying from the temporary variable to the destination variable, the value could overflow. If the type has upper and lower limits, the user should check that the value is within those limits, before actually copying the value. The example below shows how these conversions should be done.

Conventions used in this page

In “Conforming to” we only concern ourselves with C99 and later and POSIX.1-2001 and later. Some types may be specified in earlier versions of one of these standards, but in the interests of simplicity we omit details from earlier standards.

In “Include”, we first note the “primary” header(s) that define the type according to either the C or POSIX.1 standards. Under “Alternatively”, we note additional headers that the standards specify shall define the type.

EXAMPLES

The program shown below scans from a string and prints a value stored in a variable of an integer type that doesn’t have a length modifier. The appropriate conversions from and to intmax_t, and the appropriate range checks, are used as explained in the notes section above.

#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
int
main (void)
{
    static const char *const str = "500000 us in half a second";
    suseconds_t us;
    intmax_t    tmp;
    /* Scan the number from the string into the temporary variable. */
    sscanf(str, "%jd", &tmp);
    /* Check that the value is within the valid range of suseconds_t. */
    if (tmp < -1 || tmp > 1000000) {
        fprintf(stderr, "Scanned value outside valid range!

“); exit(EXIT_FAILURE); } /* Copy the value to the suseconds_t variable ‘us’. / us = tmp; / Even though suseconds_t can hold the value -1, this isn’t a sensible number of microseconds. / if (us < 0) { fprintf(stderr, “Scanned value shouldn’t be negative! “); exit(EXIT_FAILURE); } / Print the value. */ printf(“There are %jd microseconds in half a second. “, (intmax_t) us); exit(EXIT_SUCCESS); }

SEE ALSO

feature_test_macros(7), standards(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

583 - Linux cli command iso_8859-3

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso_8859-3 and provides detailed information about the command iso_8859-3, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso_8859-3.

NAME 🖥️ iso_8859-3 🖥️

3 - ISO/IEC 8859-3 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-3 encodes the characters used in certain Southeast European languages.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-3 characters

The following table displays the characters in ISO/IEC 8859-3 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-3 is also known as Latin-3.

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

584 - Linux cli command iso-8859-3

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso-8859-3 and provides detailed information about the command iso-8859-3, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso-8859-3.

NAME 🖥️ iso-8859-3 🖥️

3 - ISO/IEC 8859-3 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-3 encodes the characters used in certain Southeast European languages.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-3 characters

The following table displays the characters in ISO/IEC 8859-3 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-3 is also known as Latin-3.

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

585 - Linux cli command DROP_CAST

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_CAST and provides detailed information about the command DROP_CAST, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_CAST.

NAME 🖥️ DROP_CAST 🖥️

remove a cast

SYNOPSIS

DROP CAST [ IF EXISTS ] (source_type AS target_type) [ CASCADE | RESTRICT ]

DESCRIPTION

DROP CAST removes a previously defined cast.

To be able to drop a cast, you must own the source or the target data type. These are the same privileges that are required to create a cast.

PARAMETERS

IF EXISTS

Do not throw an error if the cast does not exist. A notice is issued in this case.

source_type

The name of the source data type of the cast.

target_type

The name of the target data type of the cast.

CASCADE
RESTRICT

These key words do not have any effect, since there are no dependencies on casts.

EXAMPLES

To drop the cast from type text to type int:

DROP CAST (text AS int);

COMPATIBILITY

The DROP CAST command conforms to the SQL standard.

SEE ALSO

CREATE CAST (CREATE_CAST(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

586 - Linux cli command VALUES

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command VALUES and provides detailed information about the command VALUES, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the VALUES.

NAME 🖥️ VALUES 🖥️

compute a set of rows

SYNOPSIS

VALUES ( expression [, ...] ) [, ...]
    [ ORDER BY sort_expression [ ASC | DESC | USING operator ] [, ...] ]
    [ LIMIT { count | ALL } ]
    [ OFFSET start [ ROW | ROWS ] ]
    [ FETCH { FIRST | NEXT } [ count ] { ROW | ROWS } ONLY ]

DESCRIPTION

VALUES computes a row value or set of row values specified by value expressions. It is most commonly used to generate a “constant table” within a larger command, but it can be used on its own.

When more than one row is specified, all the rows must have the same number of elements. The data types of the resulting tables columns are determined by combining the explicit or inferred types of the expressions appearing in that column, using the same rules as for UNION (see Section 10.5).

Within larger commands, VALUES is syntactically allowed anywhere that SELECT is. Because it is treated like a SELECT by the grammar, it is possible to use the ORDER BY, LIMIT (or equivalently FETCH FIRST), and OFFSET clauses with a VALUES command.

PARAMETERS

expression

A constant or expression to compute and insert at the indicated place in the resulting table (set of rows). In a VALUES list appearing at the top level of an INSERT, an expression can be replaced by DEFAULT to indicate that the destination columns default value should be inserted. DEFAULT cannot be used when VALUES appears in other contexts.

sort_expression

An expression or integer constant indicating how to sort the result rows. This expression can refer to the columns of the VALUES result as column1, column2, etc. For more details see ORDER BY Clause in the SELECT(7) documentation.

operator

A sorting operator. For details see ORDER BY Clause in the SELECT(7) documentation.

count

The maximum number of rows to return. For details see LIMIT Clause in the SELECT(7) documentation.

start

The number of rows to skip before starting to return rows. For details see LIMIT Clause in the SELECT(7) documentation.

NOTES

VALUES lists with very large numbers of rows should be avoided, as you might encounter out-of-memory failures or poor performance. VALUES appearing within INSERT is a special case (because the desired column types are known from the INSERTs target table, and need not be inferred by scanning the VALUES list), so it can handle larger lists than are practical in other contexts.

EXAMPLES

A bare VALUES command:

VALUES (1, one), (2, two), (3, three);

This will return a table of two columns and three rows. Its effectively equivalent to:

SELECT 1 AS column1, one AS column2 UNION ALL SELECT 2, two UNION ALL SELECT 3, three;

More usually, VALUES is used within a larger SQL command. The most common use is in INSERT:

INSERT INTO films (code, title, did, date_prod, kind) VALUES (T_601, Yojimbo, 106, 1961-06-16, Drama);

In the context of INSERT, entries of a VALUES list can be DEFAULT to indicate that the column default should be used here instead of specifying a value:

INSERT INTO films VALUES (UA502, Bananas, 105, DEFAULT, Comedy, 82 minutes), (T_601, Yojimbo, 106, DEFAULT, Drama, DEFAULT);

VALUES can also be used where a sub-SELECT might be written, for example in a FROM clause:

SELECT f.* FROM films f, (VALUES(MGM, Horror), (UA, Sci-Fi)) AS t (studio, kind) WHERE f.studio = t.studio AND f.kind = t.kind;

UPDATE employees SET salary = salary * v.increase
  FROM (VALUES(1, 200000, 1.2), (2, 400000, 1.4)) AS v (depno, target, increase)
  WHERE employees.depno = v.depno AND employees.sales >= v.target;

Note that an AS clause is required when VALUES is used in a FROM clause, just as is true for SELECT. It is not required that the AS clause specify names for all the columns, but its good practice to do so. (The default column names for VALUES are column1, column2, etc. in PostgreSQL, but these names might be different in other database systems.)

When VALUES is used in INSERT, the values are all automatically coerced to the data type of the corresponding destination column. When its used in other contexts, it might be necessary to specify the correct data type. If the entries are all quoted literal constants, coercing the first is sufficient to determine the assumed type for all:

SELECT * FROM machines WHERE ip_address IN (VALUES(192.168.0.1::inet), (192.168.0.10), (192.168.1.43));

Tip

For simple IN tests, its better to rely on the list-of-scalars form of IN than to write a VALUES query as shown above. The list of scalars method requires less writing and is often more efficient.

COMPATIBILITY

VALUES conforms to the SQL standard. LIMIT and OFFSET are PostgreSQL extensions; see also under SELECT(7).

SEE ALSO

INSERT(7), SELECT(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

587 - Linux cli command EVP_SIGNATURE-Poly1305ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_SIGNATURE-Poly1305ssl and provides detailed information about the command EVP_SIGNATURE-Poly1305ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_SIGNATURE-Poly1305ssl.

NAME 🖥️ EVP_SIGNATURE-Poly1305ssl 🖥️

HMAC, EVP_SIGNATURE-Siphash, EVP_SIGNATURE-Poly1305, EVP_SIGNATURE-CMAC - The legacy EVP_PKEY MAC signature implementations

DESCRIPTION

The algorithms described here have legacy support for creating MACs using EVP_DigestSignInit (3) and related functions. This is not the preferred way of creating MACs. Instead you should use the newer EVP_MAC_init (3) functions. This mechanism is provided for backwards compatibility with older versions of OpenSSL.

The same signature parameters can be set using EVP_PKEY_CTX_set_params() as can be set via EVP_MAC_CTX_set_params() for the underlying EVP_MAC. See EVP_MAC-HMAC (7), EVP_MAC-Siphash (7), EVP_MAC-Poly1305 (7) and EVP_MAC-CMAC (7) for details.

See L<EVP_PKEY-HMAC(7)>, L<EVP_PKEY-Siphash(7)>, L<EVP_PKEY-Poly1305(7)> or L<EVP_PKEY-CMAC(7)> for details about parameters that are supported during the creation of an EVP_PKEY.

SEE ALSO

EVP_MAC_init (3), EVP_DigestSignInit (3), EVP_PKEY-HMAC (7), EVP_PKEY-Siphash (7), EVP_PKEY-Poly1305 (7), EVP_PKEY-CMAC (7), EVP_MAC-HMAC (7), EVP_MAC-Siphash (7), EVP_MAC-Poly1305 (7), EVP_MAC-CMAC (7), provider-signature (7),

COPYRIGHT

Copyright 2020 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

588 - Linux cli command iso_8859_7

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso_8859_7 and provides detailed information about the command iso_8859_7, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso_8859_7.

NAME 🖥️ iso_8859_7 🖥️

7 - ISO/IEC 8859-7 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-7 encodes the characters used in modern monotonic Greek.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-7 characters

The following table displays the characters in ISO/IEC 8859-7 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-7 was formerly known as ELOT-928 or ECMA-118:1986.

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

589 - Linux cli command provider-encoderssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command provider-encoderssl and provides detailed information about the command provider-encoderssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the provider-encoderssl.

NAME 🖥️ provider-encoderssl 🖥️

encoder - The OSSL_ENCODER library <-> provider functions

SYNOPSIS

#include <openssl/core_dispatch.h> /* * None of these are actual functions, but are displayed like this for * the function signatures for functions that are offered as function * pointers in OSSL_DISPATCH arrays. */ /* Encoder parameter accessor and descriptor */ const OSSL_PARAM *OSSL_FUNC_encoder_gettable_params(void *provctx); int OSSL_FUNC_encoder_get_params(OSSL_PARAM params[]); /* Functions to construct / destruct / manipulate the encoder context */ void *OSSL_FUNC_encoder_newctx(void *provctx); void OSSL_FUNC_encoder_freectx(void *ctx); int OSSL_FUNC_encoder_set_ctx_params(void *ctx, const OSSL_PARAM params[]); const OSSL_PARAM *OSSL_FUNC_encoder_settable_ctx_params(void *provctx); /* Functions to check selection support */ int OSSL_FUNC_encoder_does_selection(void *provctx, int selection); /* Functions to encode object data */ int OSSL_FUNC_encoder_encode(void *ctx, OSSL_CORE_BIO *out, const void *obj_raw, const OSSL_PARAM obj_abstract[], int selection, OSSL_PASSPHRASE_CALLBACK *cb, void *cbarg); /* Functions to import and free a temporary object to be encoded */ void *OSSL_FUNC_encoder_import_object(void *ctx, int selection, const OSSL_PARAM params[]); void OSSL_FUNC_encoder_free_object(void *obj);

DESCRIPTION

We use the wide term “encode” in this manual. This includes but is not limited to serialization.

The ENCODER operation is a generic method to encode a provider-native object (obj_raw) or an object abstraction (object_abstract, see provider-object (7)) into an encoded form, and write the result to the given OSSL_CORE_BIO. If the caller wants to get the encoded stream to memory, it should provide a BIO_s_mem (3) BIO.

The encoder doesn’t need to know more about the OSSL_CORE_BIO pointer than being able to pass it to the appropriate BIO upcalls (see “Core functions” in provider-base (7)).

The ENCODER implementation may be part of a chain, where data is passed from one to the next. For example, there may be an implementation to encode an object to DER (that object is assumed to be provider-native and thereby passed via obj_raw), and another one that encodes DER to PEM (that one would receive the DER encoding via obj_abstract).

The encoding using the OSSL_PARAM (3) array form allows a encoder to be used for data that’s been exported from another provider, and thereby allow them to exist independently of each other.

The encoding using a provider side object can only be safely used with provider data coming from the same provider, for example keys with the KEYMGMT provider.

All “functions” mentioned here are passed as function pointers between libcrypto and the provider in OSSL_DISPATCH (3) arrays via OSSL_ALGORITHM (3) arrays that are returned by the provider’s provider_query_operation() function (see “Provider Functions” in provider-base (7)).

All these “functions” have a corresponding function type definition named OSSL_FUNC_{name}_fn, and a helper function to retrieve the function pointer from an OSSL_DISPATCH (3) element named OSSL_FUNC_{name}. For example, the “function” OSSL_FUNC_encoder_encode() has these:

typedef int (OSSL_FUNC_encoder_encode_fn)(void *ctx, OSSL_CORE_BIO *out, const void *obj_raw, const OSSL_PARAM obj_abstract[], int selection, OSSL_PASSPHRASE_CALLBACK *cb, void *cbarg); static ossl_inline OSSL_FUNC_encoder_encode_fn OSSL_FUNC_encoder_encode(const OSSL_DISPATCH *opf);

OSSL_DISPATCH (3) arrays are indexed by numbers that are provided as macros in openssl-core_dispatch.h (7), as follows:

OSSL_FUNC_encoder_get_params OSSL_FUNC_ENCODER_GET_PARAMS OSSL_FUNC_encoder_gettable_params OSSL_FUNC_ENCODER_GETTABLE_PARAMS OSSL_FUNC_encoder_newctx OSSL_FUNC_ENCODER_NEWCTX OSSL_FUNC_encoder_freectx OSSL_FUNC_ENCODER_FREECTX OSSL_FUNC_encoder_set_ctx_params OSSL_FUNC_ENCODER_SET_CTX_PARAMS OSSL_FUNC_encoder_settable_ctx_params OSSL_FUNC_ENCODER_SETTABLE_CTX_PARAMS OSSL_FUNC_encoder_does_selection OSSL_FUNC_ENCODER_DOES_SELECTION OSSL_FUNC_encoder_encode OSSL_FUNC_ENCODER_ENCODE OSSL_FUNC_encoder_import_object OSSL_FUNC_ENCODER_IMPORT_OBJECT OSSL_FUNC_encoder_free_object OSSL_FUNC_ENCODER_FREE_OBJECT

Names and properties

The name of an implementation should match the type of object it handles. For example, an implementation that encodes an RSA key should be named “RSA”. Likewise, an implementation that further encodes DER should be named “DER”.

Properties can be used to further specify details about an implementation:

output
This property is used to specify what type of output the implementation produces. This property is mandatory. OpenSSL providers recognize the following output types:

text
An implementation with that output type outputs human readable text, making that implementation suitable for -text output in diverse openssl (1) commands.

pem
An implementation with that output type outputs PEM formatted data.

der
An implementation with that output type outputs DER formatted data.

msblob
An implementation with that output type outputs MSBLOB formatted data.

pvk
An implementation with that output type outputs PVK formatted data.

structure
This property is used to specify the structure that is used for the encoded object. An example could be pkcs8, to specify explicitly that an object (presumably an asymmetric key pair, in this case) will be wrapped in a PKCS#8 structure as part of the encoding. This property is optional.

The possible values of both these properties is open ended. A provider may very well specify output types and structures that libcrypto doesn’t know anything about.

Subset selections

Sometimes, an object has more than one subset of data that is interesting to treat separately or together. It’s possible to specify what subsets are to be encoded, with a set of bits selection that are passed in an int.

This set of bits depend entirely on what kind of provider-side object is passed. For example, those bits are assumed to be the same as those used with provider-keymgmt (7) (see “Key Objects” in provider-keymgmt (7)) when the object is an asymmetric keypair.

ENCODER implementations are free to regard the selection as a set of hints, but must do so with care. In the end, the output must make sense, and if there’s a corresponding decoder, the resulting decoded object must match the original object that was encoded.

OSSL_FUNC_encoder_does_selection() should tell if a particular implementation supports any of the combinations given by selection.

Context functions

OSSL_FUNC_encoder_newctx() returns a context to be used with the rest of the functions.

OSSL_FUNC_encoder_freectx() frees the given ctx, if it was created by OSSL_FUNC_encoder_newctx().

OSSL_FUNC_encoder_set_ctx_params() sets context data according to parameters from params that it recognises. Unrecognised parameters should be ignored. Passing NULL for params should return true.

OSSL_FUNC_encoder_settable_ctx_params() returns a constant OSSL_PARAM (3) array describing the parameters that OSSL_FUNC_encoder_set_ctx_params() can handle.

See OSSL_PARAM (3) for further details on the parameters structure used by OSSL_FUNC_encoder_set_ctx_params() and OSSL_FUNC_encoder_settable_ctx_params().

Import functions

A provider-native object may be associated with a foreign provider, and may therefore be unsuitable for direct use with a given ENCODER implementation. Provided that the foreign provider’s implementation to handle the object has a function to export that object in OSSL_PARAM (3) array form, the ENCODER implementation should be able to import that array and create a suitable object to be passed to OSSL_FUNC_encoder_encode()’s obj_raw.

OSSL_FUNC_encoder_import_object() should import the subset of params given with selection to create a provider-native object that can be passed as obj_raw to OSSL_FUNC_encoder_encode().

OSSL_FUNC_encoder_free_object() should free the object that was created with OSSL_FUNC_encoder_import_object().

Encoding functions

OSSL_FUNC_encoder_encode() should take a provider-native object (in obj_raw) or an object abstraction (in obj_abstract), and should output the object in encoded form to the OSSL_CORE_BIO. The selection bits, if relevant, should determine in greater detail what will be output. The encoding functions also take an OSSL_PASSPHRASE_CALLBACK (3) function pointer along with a pointer to application data cbarg, which should be used when a pass phrase prompt is needed.

Encoder operation parameters

Operation parameters currently recognised by built-in encoders are as follows:

“cipher” (OSSL_ENCODER_PARAM_CIPHER) <UTF8 string>
The name of the encryption cipher to be used when generating encrypted encoding. This is used when encoding private keys, as well as other objects that need protection. If this name is invalid for the encoding implementation, the implementation should refuse to perform the encoding, i.e. OSSL_FUNC_encoder_encode_data() and OSSL_FUNC_encoder_encode_object() should return an error.

“properties” (OSSL_ENCODER_PARAM_PROPERTIES) <UTF8 string>
The properties to be queried when trying to fetch the algorithm given with the “cipher” parameter. This must be given together with the “cipher” parameter to be considered valid. The encoding implementation isn’t obligated to use this value. However, it is recommended that implementations that do not handle property strings return an error on receiving this parameter unless its value NULL or the empty string.

“save-parameters” (OSSL_ENCODER_PARAM_SAVE_PARAMETERS) <integer>
If set to 0 disables saving of key domain parameters. Default is 1. It currently has an effect only on DSA keys.

Parameters currently recognised by the built-in pass phrase callback:

“info” (OSSL_PASSPHRASE_PARAM_INFO) <UTF8 string>
A string of information that will become part of the pass phrase prompt. This could be used to give the user information on what kind of object it’s being prompted for.

RETURN VALUES

OSSL_FUNC_encoder_newctx() returns a pointer to a context, or NULL on failure.

OSSL_FUNC_encoder_set_ctx_params() returns 1, unless a recognised parameter was invalid or caused an error, for which 0 is returned.

OSSL_FUNC_encoder_settable_ctx_params() returns a pointer to an array of constant OSSL_PARAM (3) elements.

OSSL_FUNC_encoder_does_selection() returns 1 if the encoder implementation supports any of the selection bits, otherwise 0.

OSSL_FUNC_encoder_encode() returns 1 on success, or 0 on failure.

SEE ALSO

provider (7)

HISTORY

The ENCODER interface was introduced in OpenSSL 3.0.

COPYRIGHT

Copyright 2019-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

590 - Linux cli command groff_diff

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command groff_diff and provides detailed information about the command groff_diff, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the groff_diff.

Name

groff_diff - differences between GNU roff and AT&T troff

Description

The GNU roff text processing system, groff, is an extension of AT&T troff, the typesetting system originating in Unix systems of the 1970s. groff removes many arbitrary limitations and adds features, both to the input language and to the page description language output by the troff formatter. Differences arising from groff’s implementation of AT&T troff features are also noted. See

for background.

Language

GNU troff features identifiers of arbitrary length; supports color output, non-integral type sizes, and user-defined characters; adds more conditional expression operators; recognizes additional scaling units and numeric operators; enables general file I/O (in “unsafe mode” only); and exposes more formatter state.

Long names

GNU troff introduces many new requests; with three exceptions (cp, do, rj), they have names longer than two characters. The names of registers, fonts, strings/macros/diversions, environments, special characters, streams, and colors can be of any length. Anywhere AT&T troff supports a parameterized escape sequence that uses an opening parenthesis “(” to introduce a two-character argument, groff supports a square-bracketed form “[]” where the argument within can be of arbitrary length.

Font families, abstract styles, and translation

GNU troff can group text typefaces into families containing each of the styles “R”, “I”, “B”, and “BI”. So that a document need not be coupled to a specific font family, an output device can associate a style in the abstract sense with a mounting position. Thus the default family can be combined with a style dynamically, producing a resolved font name. A document can translate, or remap, fonts with the ftr request.

Applying the requests cs, bd, tkf, uf, or fspecial to an abstract style affects the member of the default family corresponding to that style. The default family can be set with the fam request or -f command-line option. The styles directive in the output device’s DESC file controls which mounting positions (if any) are initially associated with abstract styles rather than fonts, and the sty request can update this association.

Colors

groff supports color output with a variety of color spaces and up to 16 bits per channel. Some devices, particularly terminals, may be more limited. When color support is enabled, two colors are current at any given time: the stroke color, with which glyphs, rules (lines), and geometric figures are drawn, and the fill color, which paints the interior of filled geometric figures. The color, defcolor, gcolor, and fcolor requests; \m and \M escape sequences; and .color, .m, and .M registers exercise color support.

Fractional type sizes and new scaling units

AT&T troff interpreted all type size measurements in points. Combined with integer arithmetic, this design choice made it impossible to support, for instance, ten and a half-point type. In GNU troff, an output device can select a scaling factor that subdivides a point into “scaled points”. A type size expressed in scaled points can thus represent a non-integral type size.

A scaled point is equal to 1/sizescale points, where sizescale is specified in the device description file, DESC, and defaults to 1; see

Requests and escape sequences in GNU troff interpret arguments that represent a type size in points, which the formatter multiplies by sizescale and converts to an integer. Arguments treated in this way comprise those to the escape sequences \H and \s, to the request ps, the third argument to the cs request, and the second and fourth arguments to the tkf request. Scaled points may be specified explicitly with the z scaling unit. In GNU troff, the register ** [.s]** can interpolate a non-integral type size. The register ** [.ps]** interpolates the type size in scaled points.

For example, if sizescale is 1000, then a scaled point is one thousandth of a point. Consequently, “.ps 10.5” is synonymous with “.ps 10.5z”; both set the type size to 10,500 scaled points, or 10.5 points.

It makes no sense to use the “z” scaling unit in a numeric expression whose default scaling unit is neither “u” nor “z”, so GNU troff disallows this. Similarly, it is nonsensical to use a scaling unit other than “z” or “u” in a numeric expression whose default scaling unit is “z”, so GNU troff disallows this as well.

Another new scaling unit, “s”, multiplies by the number of basic units in a scaled point. Thus, “ ** [.ps]s**” is equal to “1m” by definition. Do not confuse the “s” and “z” scaling units.

Output devices may be limited in the type sizes they can employ. The .s and .ps registers represent the type size as selected by the output driver as it understands a device’s capability. The last requested type size is interpolated in scaled points by the read-only register .psr and in points as a decimal fraction by the read-only string-valued register .sr. Both are associated with the environment. For example, if a type size of 10.95 points is requested, and the nearest size permitted by a sizes request (or by the sizes or sizescale directives in the device’s DESC file) is 11 points, the output driver uses the latter value.

A further two new measurement units available in groff are “M”, which indicates hundredths of an em, and “f ”, which multiplies by 65,536. The latter provides convenient fractions for color definitions with the defcolor request. For example, 0.5f equals 32768u.

Numeric expressions

GNU troff permits spaces in a numeric expression within parentheses, and offers three new operators.

e1**>?**e2
Interpolate the greater of e1 and e2.

e1**<?**e2
Interpolate the lesser of e1 and e2.

(c;e)
Evaluate e using c as the default scaling unit, ignoring scaling units in e if c is empty.

Conditional expressions

More conditions can be tested with the “ if ” and ie requests, as well as the new “while” request.

**c **chr
True if a character chr is available, where chr is an ordinary character (Unicode basic Latin excluding control characters and the space), a special character, or **\N’**index ’.

**d **nam
True if a string, macro, diversion, or request nam is defined.

**F **fnt
True if a font fnt is available; fnt can be an abstract style or a font name. fnt is handled as if it were accessed with the ft request (that is, abstract styles and font translation are applied), but fnt cannot be a mounting position, and no font is mounted.

**m **col
True if a color col is defined.

**r **reg
True if a register reg is defined.

**S **sty
True if a style sty is registered. Font translation applies.

v
Always false. This condition is for compatibility with certain other troff implementations only. (This refers to vtroff, a translator that would convert the C/A/T output from early-vintage AT&T troff to a form suitable for Versatec and Benson-Varian plotters.)

Drawing commands

GNU troff offers drawing commands to create filled circles and ellipses, and polygons. Stroked (outlined) objects are drawn with the stroke color and filled (solid) ones shaded with the fill color. These are independent properties; if you want a filled, stroked figure, you must draw the same figure twice using each drawing command. A filled figure is always smaller than a stroked one because the former is drawn only within its defined area, whereas strokes have a line thickness (set with another new drawing command, \D’t’).

Escape sequences

groff introduces several new escape sequences and extends the syntax of a few AT&T troff escape sequences (namely, \D, ** **, \k, ** **, \s, ***, and ***). In the following list, escape sequences are collated alphabetically at first, and then by symbol roughly in Unicode code point order.

\A’anything’
Interpolate 1 if anything is a valid identifier, and 0 otherwise. Because invalid input characters are removed, invalid identifiers are empty or contain spaces, tabs, or newlines. You can employ \A to validate a macro argument before using it to construct another escape sequence or identifier.

\B’anything’
Interpolate 1 if anything is a valid numeric expression, and 0 otherwise. You might use \B along with the “ if ” request to filter out invalid macro arguments.

\D’C d’
Draw filled circle of diameter d with its leftmost point at the drawing position.

\D’E h v’
Draw filled ellipse with h and v as the axes and the leftmost point at the drawing position.

**\D’p h1 v1 **
. . . hn vn ’ Draw polygon with vertices at drawing position and each point in sequence. GNU troff closes the polygon by drawing a line from (hn, vn) back to the initial drawing position; DWB and Heirloom troffs do not. Afterward, the drawing position is left at (hn, vn).

**\D’P h1 v1 **
. . . hn vn ’ As \D’p’, but the polygon is filled.

\D’t n’
Set line thickness of geometric objects to to n basic units. A zero n selects the minimal supported thickness. A negative n selects a thickness proportional to the type size; this is the default.


Embed an escape character that is not interpreted in copy mode (compare with  and ** **). You can use it to ease the writing of nested macro definitions. It is also convenient to define strings containing escape sequences that need to work when used in copy mode (for example, as macro arguments), or which will be interpolated at varying macro nesting depths.

** [font]**
Select font, which may be a mounting position, abstract style, or font name, to choose the typeface. ** []** and ** P** are synonyms; we recommend the former.

\Ff
**\F(fm
\F[family]
Select default font family. \F[] makes the previous font family the default. \FP is unlike ** P; it selects font family “P” as the default. See the fam request below.

**\k(**rg
\k[reg]
Mark horizontal drawing position in two-character register name rg or arbitrary register name reg.

\mc
**\m(**cl
\m[col]
Set the stroke color. \m[] restores the previous stroke color, or the default if there is none.

\Mc
**\M(**cl
\M[col]
Set the fill color. \M[] restores the previous fill color, or the default if there is none.

** [reg]**
Interpolate register reg.

\On
\O[n]
Suppress troff output of glyphs and geometric objects. The sequences \O2, \O3, \O4, and \O5 are intended for internal use by

\O0
\O1
Disable and enable, respectively, the emission of glyphs and geometric objects to the output driver, provided that this sequence occurs at the outermost suppression level (see \O3 and \O4). Horizontal motions corresponding to non-overstruck glyph widths still occur. These sequences also reset the registers opminx, opminy, opmaxx, and opmaxy to -1. These four registers mark the top left and bottom right hand corners of a box encompassing all written or drawn output.

\O2
At the outermost suppression level, enable emission of glyphs and geometric objects, and write to the standard error stream the page number and values of the four aforementioned registers encompassing glyphs written since the last interpolation of a \O sequence, as well as the page offset, line length, image file name (if any), horizontal and vertical device motion quanta, and input file name. Numeric values are in basic units.

\O3
\O4
Begin and end a nested suppression level, respectively. grohtml uses this mechanism to create images of output preprocessed with pic, eqn, and tbl. At startup, troff is at the outermost suppression level. pre-grohtml generates these sequences when processing the document, using troff with the ps output device, Ghostscript, and the PNM tools to produce images in PNG format. These sequences start a new page if the device is not html or xhtml, to reduce the number of images crossing a page boundary.

\O5[Pfile]
At the outermost suppression level, write the name file to the standard error stream at position P, which must be one of l, r, c, or i, corresponding to left, right, centered, and inline alignments within the document, respectively. file is is a name associated with the production of the next image.

\R’name ±n’
Synonymous with “.nr name ±n”.

\s[±n**]**
\s*±[n]
\s’±n***’**
\s*±*’n’
Set the type size to, or increment or decrement it by, n scaled points.

\Ve
**\V(**ev
\V[env]
Interpolate contents of the environment variable env, as returned by

\V is interpreted even in copy mode.

\X’anything’
Within \X arguments, the escape sequences ***, ***, ***, and ** are ignored; ****space and ** are converted to single space characters; and ** is reduced to ***. So that the basic Latin subset of the Unicode character set (that is, ISO 646:1991-IRV or, popularly, “US-ASCII”) can be reliably encoded in anything, the special character escape sequences ****, \aq], \dq], \ga], \ha], \rs], and \ti] are mapped to basic Latin characters; see

For this transformation, character translations and definitions are ignored. Other escape sequences are not supported.

If the use_charnames_in_special directive appears in the output device’s DESC file, the use of special character escape sequences is not an error; they are simply output verbatim (with the exception of the seven mapped to Unicode basic Latin characters, discussed above). use_charnames_in_special is currently employed only by

\Ym
**\Y(**ma
\Y[mac]
Interpolate a macro as a device control command. This is similar to \X’\[mac]’, except the contents of mac are not interpreted, and mac can be a macro and thus contain newlines, whereas the argument to \X cannot. This inclusion of newlines requires an extension to the AT&T troff output format, and will confuse postprocessors that do not know about it.

\Z’anything’
Save the drawing position, format anything, then restore it. Tabs and leaders in the argument are ignored with an error diagnostic.

**
Everything up to and including the next newline is ignored. This escape sequence is interpreted even in copy mode. ** is like ****, except that ** does not ignore a newline; the latter therefore cannot be used by itself for a whole-line comment—it leaves a blank line on the input stream.

\0
Interpolate the name by which the macro being interpreted was called. In GNU troff this name can vary; see the als request.

**(**nn
\[nnn]
In a macro or string definition, interpolate the nnth or nnnth argument. Macros and strings can have an unlimited number of arguments.

\*
In a macro or string definition, interpolate the catenation of all arguments, separated by spaces.

@
In a macro or string definition, interpolate the catenation of all arguments, with each surrounded by double quotes and separated by spaces.

^
In a macro or string definition, interpolate the catenation of all arguments constructed in a form suitable for passage to the ds request.

**
Interpolate a transparent dummy character—one that is ignored by end-of-sentence detection. It behaves as ****, except that ** is treated as letters and numerals normally are after “.”, “?”, and “!”; ** cancels end-of-sentence detection, and ** does not.

\[*“string *
[arg . . .] ] Interpolate string, passing it arg . . . as arguments.

**
Apply an italic correction: modify the spacing of the preceding glyph so that the distance between it and the following glyph is correct if the latter is of upright shape. For example, if an italic “f ” is followed immediately by a roman right parenthesis, then in many fonts the top right portion of the “f ” overlaps the top left of the right parenthesis, which is ugly. Inserting / between them

avoids this problem. Use this escape sequence whenever an oblique glyph is immediately followed by an upright glyph without any intervening space.

**
Apply a left italic correction: modify the spacing of the following glyph so that the distance between it and the preceding glyph is correct if the latter is of upright shape. For example, if a roman left parenthesis is immediately followed by an italic “f ”, then in many fonts the bottom left portion of the “f ” overlaps the bottom of the left parenthesis, which is ugly. Inserting ** between them

avoids this problem. Use this escape sequence whenever an upright glyph is followed immediately by an oblique glyph without any intervening space.

**
Insert a non-printing break point. That is, a word can break there, but the soft hyphen character does not mark the break point if it does (in contrast to “ ****”). This escape sequence is an input word boundary, so the remainder of the word is subject to hyphenation as normal.

*anything*
When used in a diversion, this transparently embeds anything in the diversion. anything is read in copy mode. When the diversion is reread, anything is interpreted. anything may not contain newlines; use ** if you want to embed newlines in a diversion. The escape sequence ** is also recognized in copy mode and becomes an internal code; it is this code that terminates anything. Thus

.nr x 1
.nf
.di d
\?\?\\?\\\\

x\??? .di .nr x 2 .di e .d .di .nr x 3 .di f .e .di .nr x 4 .f

prints  4.

*char]*
Typeset the special character char.

*base-char combining-component *
. . .] Typeset a composite glyph consisting of base-char overlaid with one or more combining-components. For example, “ \A ho] ” is a capital letter “A” with a “hook accent” (ogonek). See the composite request below; Groff: The GNU Implementation of troff, the groff Texinfo manual, for details of composite glyph name construction; and

for a list of components used in composite glyph names.

**
Insert an unbreakable space that is adjustable like an ordinary space. It is discarded from the end of an output line if a break is forced.

Restricted requests

To mitigate risks from untrusted input documents, the pi and sy requests are disabled by default.

-U option enables the formatter’s “unsafe mode”, restoring their function (and enabling additional groff extension requests, open, opena, and pso).

New requests

**.aln **new old
Create alias new for existing register named old, causing the names to refer to the same stored value. If old is undefined, a warning in category “reg” is generated and the request is ignored. To remove a register alias, invoke rr on its name. A register’s contents do not become inaccessible until it has no more names.

**.als **new old
Create alias new for existing request, string, macro, or diversion named old, causing the names to refer to the same stored object. If old is undefined, a warning in category “mac” is produced, and the request is ignored. The “am”, “as”, da, de, di, and ds requests (together with their variants) create a new object only if the name of the macro, diversion, or string is currently undefined or if it is defined as a request; normally, they modify the value of an existing object. To remove an alias, invoke rm on its name. The object itself is not destroyed until it has no more names.

When a request, macro, string, or diversion is aliased, redefinitions and appendments “write through” alias names. To replace an alias with a separately defined object, you must use the rm request on its name first.

**.am1 ***name *
[end-name] As “am”, but compatibility mode is disabled while the appendment to name is interpreted: a “compatibility save” token is inserted at its beginning, and a “compatibility restore” token at its end. As a consequence, the requests “am”, am1, de, and de1 can be intermixed freely since the compatibility save/restore tokens affect only the parts of the macro populated by am1 and de1.

**.ami ***name *
[end-name] Append to macro indirectly. See dei below.

**.ami1 ***name *
[end-name] As ami, but compatibility mode is disabled during interpretation of the appendment.

**.as1 ***name *
[contents] As “as”, but compatibility mode is disabled while the appendment to name is interpreted: a “compatibility save” token is inserted at the beginning of contents, and a “compatibility restore” token after it. As a consequence, the requests “as”, as1, ds, and ds1 can be intermixed freely since the compatibility save/restore tokens affect only the portions of the strings populated by as1 and ds1.

**.asciify **div
Unformat the diversion div in a way such that Unicode basic Latin (ASCII) characters, characters translated with the trin request, space characters, and some escape sequences, that were formatted in the diversion div are treated like ordinary input characters when div is reread. Doing so can be useful in conjunction with the writem request. asciify can be also used for gross hacks; for example, the following sets register n to 1.

.tr @.
.di x
@nr n 1
.br
.di
.tr @@
.asciify x
.x

asciify cannot return all items in a diversion to their source equivalent: nodes such as those produced by \N[. . .] will remain nodes, so the result cannot be guaranteed to be a pure string. See section “Copy mode” in

Glyph parameters such as the type face and size are not preserved; use unformat to achieve that.

.backtrace
Write backtrace of input stack to the standard error stream. See the -b option of

**.blm **[
name] Set a blank line macro (trap). If a blank line macro is thus defined, groff executes macro when a blank line is encountered in the input file, instead of the usual behavior. A line consisting only of spaces is also treated as blank and subject to this trap. If no argument is supplied, the default blank line behavior is (re-)established.

**.box **[
name]

**.boxa **[ name] Divert (or append) output to name, similarly to the di and da requests, respectively. Any pending output line is not included in the diversion. Without an argument, stop diverting output; any pending output line inside the diversion is discarded.

.break
Exit a “while” loop. Do not confuse this request with a typographical break or the br request. See “continue”.

.brp
Break and adjust line; this is the AT&T troff escape sequence \p in request form.

**.cflags ***n c1 c2 *
. . . Assign properties encoded by the number n to characters c1, c2, and so on. Ordinary and special characters have certain associated properties. (Glyphs don’t: to GNU troff, like AT&T device-independent troff, a glyph is an identifier corresponding to a rectangle with some metrics; see

The first argument is the sum of the desired flags and the remaining arguments are the characters to be assigned those properties. Spaces between the cn arguments are optional. Any argument cn can be a character class defined with the class request rather than an individual character.

The non-negative integer n is the sum of any of the following. Some combinations are nonsensical, such as “33” (1 + 32).

  1. Recognize the character as ending a sentence if followed by a newline or two spaces. Initially, characters “.?!” have this property.

  2. Enable breaks before the character. A line is not broken at a character with this property unless the characters on each side both have non-zero hyphenation codes. This exception can be overridden by adding 64. Initially, no characters have this property.

  3. Enable breaks after the character. A line is not broken at a character with this property unless the characters on each side both have non-zero hyphenation codes. This exception can be overridden by adding 64. Initially, characters “-\hy]\em] ” have this property.

  4. Mark the glyph associated with this character as overlapping other instances of itself horizontally. Initially, characters “ \ul]\rn]\ru]\radicalex]\sqrtex] ” have this property.

  5. Mark the glyph associated with this character as overlapping other instances of itself vertically. Initially, the character “ \br] ” has this property.

  6. Mark the character as transparent for the purpose of end-of-sentence recognition. In other words, an end-of-sentence character followed by any number of characters with this property is treated as the end of a sentence if followed by a newline or two spaces. This is the same as having a zero space factor in TeX. Initially, characters “ ’ " )]*\dg]\dd]\rq]\[cq] ” have this property.

  7. Ignore hyphenation codes of the surrounding characters. Use this value in combination with values 2 and 4. Initially, no characters have this property.

    For example, if you need an automatic break point after the en-dash in numeric ranges like “3000–5000”, insert

    .cflags 68 [en]

    into your document. However, this can lead to bad layout if done without thinking; in most situations, a better solution than changing the cflags value is inserting “****” right after the hyphen at the places that really need a break point.

The remaining values were implemented for East Asian language support; those who use alphabetic scripts exclusively can disregard them.

  1. Prohibit a break before the character, but allow a break after the character. This works only in combination with values 256 and 512 and has no effect otherwise. Initially, no characters have this property.

  2. Prohibit a break after the character, but allow a break before the character. This works only in combination with values 128 and 512 and has no effect otherwise. Initially, no characters have this property.

  3. Allow a break before or after the character. This works only in combination with values 128 and 256 and has no effect otherwise. Initially, no characters have this property.

In contrast to values 2 and 4, the values 128, 256, and 512 work pairwise. If, for example, the left character has value 512, and the right character 128, no break will be automatically inserted between them. If we use value 6 instead for the left character, a break after the character can’t be suppressed since the neighboring character on the right doesn’t get examined.

**.char **c contents
Define the ordinary or special character c as contents, which can be empty. More precisely, char defines a groff object (or redefines an existing one) that is accessed with the name c on input, and produces contents on output. Every time c is to be formatted, contents is processed in a temporary environment and the result is wrapped up into a single object. Compatibility mode is turned off and the escape character is set to ** while contents is processed. Any emboldening, constant spacing, or track kerning is applied to this object as a whole, not to each character in contents.

An object defined by this request can be used just like a glyph provided by the output device. In particular, other characters can be translated to it with the tr request; it can be made the tab or leader fill character with the tc and lc requests; sequences of it can be drawn with the \l and \L escape sequences; and, if the hcode request is used on c, it is subject to automatic hyphenation.

To prevent infinite recursion, occurrences of c within its own definition are treated normally (as if it were not being defined with char). The tr and trin requests take precedence if char both apply to c. A character definition can be removed with the rchar request.

**.chop **object
Remove the last character from the macro, string, or diversion object. This is useful for removing the newline from the end of a diversion that is to be interpolated as a string. This request can be used repeatedly on the same object; see section “gtroff Internals” in Groff: The GNU Implementation of troff, the groff Texinfo manual, for discussion of nodes inserted by groff.

**.class ***name c1 c2 *
. . . Define a character class (or simply “class”) name comprising the characters or range expressions c1, c2, and so on.

A class thus defined can then be referred to in lieu of listing all the characters within it. Currently, only the cflags request can handle references to character classes.

In the request’s simplest form, each cn is a character (or special character).

.class [quotes] ’ [aq] [dq] [oq] [cq] [lq] [rq]

Since class and special character names share the same name space, we recommend starting and ending the class name with “[” and “]”, respectively, to avoid collisions with existing character names defined by groff or the user (with char and related requests). This practice applies the presence of “]” in the class name to prevent the usage of the special character escape form “**. . .]**”, thus you must use the \C escape to access a class with such a name.

You can also use a character range expression consisting of a start character followed by “-” and then an end character. Internally, GNU troff converts these two character names to Unicode code points (according to the groff glyph list [GGL]), which determine the start and end values of the range. If that fails, the class definition is skipped. Furthermore, classes can be nested.

.class [prepunct] , : ; > } .class [prepunctx] \C’[prepunct]’ [u2013]-[u2016]

The class “[prepunctx]” thus contains the contents of the class “[prepunct]” and characters in the range U+2013–U+2016.

If you want to include “-” in a class, it must be the first character value in the argument list, otherwise it gets misinterpreted as part of the range syntax.

It is not possible to use class names as end points of range definitions.

A typical use of the class request is to control line-breaking and hyphenation rules as defined by the cflags request. For example, to inhibit line breaks before the characters belonging to the “[prepunctx]” class defined in the previous example, you can write the following.

.cflags 2 \C’[prepunctx]'

**.close **stream
Close the stream named stream, invalidating it as an argument to the write request. See open.

**.composite **c1 c2
Map character name c1 to character name c2 when c1 is a combining component in a composite glyph. Typically, this remaps a spacing glyph to a combining one.

.continue
Skip the remainder of a “while” loop’s body, immediately starting the next iteration. See break.

**.color **n
If n is non-zero or missing, enable colors (the default), otherwise disable them.

**.cp **n
If n is non-zero or missing, enable compatibility mode, otherwise disable it. In compatibility mode, long names are not recognized, and the incompatibilities they cause do not arise.

**.defcolor ***ident scheme color-component *
. . . Define a color named ident. scheme identifies a color space and determines the number of required color-components; it must be one of “rgb” (three components), “cmy” (three components), “cmyk” (four components), or “gray” (one component). “grey” is accepted as a synonym of “gray”. The color components can be encoded as a hexadecimal value starting with # or ##. The former indicates that each component is in the range 0–255 (0–FF), the latter the range 0–65535 (0–FFFF). Alternatively, each color component can be specified as a decimal fraction in the range 0–1, interpreted using a default scaling unit of “f”, which multiplies its value by 65,536 (but clamps it at 65,535).

Each output device has a color named “default”, which cannot be redefined. A device’s default stroke and fill colors are not necessarily the same.

**.de1 ***name *
[end-name] Define a macro to be interpreted with compatibility mode disabled. When name is called, compatibility mode enablement status is saved; it is restored when the call completes.

**.dei ***name *
[end-name] Define macro indirectly, with the name of the macro to be defined in string name and the name of the end macro terminating its definition in string end-name.

**.dei1 ***name *
[end-name] As dei, but compatibility mode is disabled while the definition of the macro named in string name is interpreted.

**.device **anything
Write anything, read in copy mode, to troff output as a device control command. An initial neutral double quote is stripped to allow the embedding of leading spaces.

**.devicem **name
Write contents of macro or string name to troff output as a device control command.

**.do ***name *
[arg . . .] Interpret the string, request, diversion, or macro name (along with any arguments) with compatibility mode disabled. Compatibility mode is restored (only if it was active) when the expansion of name is interpreted; that is, the restored compatibility state applies to the contents of the macro, string, or diversion name as well as data read from files or pipes if name is any of the so, soquiet, mso, msoquiet, or pso requests.

For example,

.de mac1 FOO .. .de1 mac2 groff .mac1 .. .de mac3 compatibility .mac1 .. .de ma $1 .. .cp 1 .do mac1 .do mac2 " mac2, defined with .de1, calls “mac1” .do mac3 " mac3 calls “ma” with argument “c1” .do mac3 [ti] " groff syntax accepted in .do arguments

results in

FOO groff FOO compatibility c1 ~

as output.

**.ds1 **name contents
As ds, but compatibility mode is disabled while name is interpreted: a “compatibility save” token is inserted at the beginning of contents, and a “compatibility restore” token after it.

.ecr
Restore the escape character saved with ecs, or set escape character to “ ****” if none has been saved.

.ecs
Save the current escape character.

**.evc **env
Copy the properties of environment env to the current environment, except for the following data.

  • a partially collected line, if present;

  • the interruption status of the previous input line (due to use of the **

591 - Linux cli command libsmbclient

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command libsmbclient and provides detailed information about the command libsmbclient, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the libsmbclient.

NAME 🖥️ libsmbclient 🖥️

An extension library for browsers and that can be used as a generic browsing API.

SYNOPSIS

Browser URL: smb://[[[domain:]user[:password@]]server[/share[/path[/file]]]] [?options]

DESCRIPTION

This tool is part of the samba(7) suite.

libsmbclient is a library toolset that permits applications to manipulate CIFS/SMB network resources using many of the standards POSIX functions available for manipulating local UNIX/Linux files. It permits much more than just browsing, files can be opened and read or written, permissions changed, file times modified, attributes and ACLs can be manipulated, and so on. Of course, its functionality includes all the capabilities commonly called browsing.

libsmbclient can not be used directly from the command line, instead it provides an extension of the capabilities of tools such as file managers and browsers. This man page describes the configuration options for this tool so that the user may obtain greatest utility of use.

OPTIONS

What the URLs mean:

smb://

Shows all workgroups or domains that are visible in the network. The behavior matches that of the Microsoft Windows Explorer.

The method of locating the list of workgroups (domains also) varies depending on the setting of the context variable (context->options.browse_max_lmb_count). It is the responsibility of the application that calls this library to set this to a sensible value. This is a compile-time option. This value determines the maximum number of local master browsers to query for the list of workgroups. In order to ensure that the list is complete for those present on the network, all master browsers must be queried. If there are a large number of workgroups on the network, the time spent querying will be significant. For small networks (just a few workgroups), it is suggested to set this value to 0, instructing libsmbclient to query all local master browsers. In an environment that has many workgroups a more reasonable setting may be around 3.

smb://name/

This command causes libsmbclient to perform a name look-up. If the NAME<1D> or NAME<1B> exists (workgroup name), libsmbclient will list all servers in the workgroup (or domain). Otherwise, a name look-up for the NAME<20> (machine name) will be performed, and the list of shared resources on the server will be displayed.

When libsmbclient is invoked by an application it searches for a directory called .smb in the $HOME directory that is specified in the users shell environment. It then searches for a file called smb.conf which, if present, will fully over-ride the system /etc/samba/smb.conf file. If instead libsmbclient finds a file called ~/.smb/smb.conf.append, it will read the system /etc/samba/smb.conf and then append the contents of the ~/.smb/smb.conf.append to it.

libsmbclient will check the users shell environment for the USER parameter and will use its value when if the user parameter was not included in the URL.

PROGRAMMERS GUIDE

Watch this space for future updates.

VERSION

This man page is part of version 4.20.1-Debian of the Samba suite.

AUTHOR

The original Samba software and related utilities were created by Andrew Tridgell. Samba is now developed by the Samba Team as an Open Source project similar to the way the Linux kernel is developed.

The libsmbclient manpage page was written by John H Terpstra.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

592 - Linux cli command DROP_COLLATION

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_COLLATION and provides detailed information about the command DROP_COLLATION, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_COLLATION.

NAME 🖥️ DROP_COLLATION 🖥️

remove a collation

SYNOPSIS

DROP COLLATION [ IF EXISTS ] name [ CASCADE | RESTRICT ]

DESCRIPTION

DROP COLLATION removes a previously defined collation. To be able to drop a collation, you must own the collation.

PARAMETERS

IF EXISTS

Do not throw an error if the collation does not exist. A notice is issued in this case.

name

The name of the collation. The collation name can be schema-qualified.

CASCADE

Automatically drop objects that depend on the collation, and in turn all objects that depend on those objects (see Section 5.14).

RESTRICT

Refuse to drop the collation if any objects depend on it. This is the default.

EXAMPLES

To drop the collation named german:

DROP COLLATION german;

COMPATIBILITY

The DROP COLLATION command conforms to the SQL standard, apart from the IF EXISTS option, which is a PostgreSQL extension.

SEE ALSO

ALTER COLLATION (ALTER_COLLATION(7)), CREATE COLLATION (CREATE_COLLATION(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

593 - Linux cli command iso_8859_10

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso_8859_10 and provides detailed information about the command iso_8859_10, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso_8859_10.

NAME 🖥️ iso_8859_10 🖥️

10 - ISO/IEC 8859-10 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-10 encodes the characters used in Nordic languages.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-10 characters

The following table displays the characters in ISO/IEC 8859-10 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-10 is also known as Latin-6.

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

594 - Linux cli command EVP_PKEY-RSAssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_PKEY-RSAssl and provides detailed information about the command EVP_PKEY-RSAssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_PKEY-RSAssl.

NAME 🖥️ EVP_PKEY-RSAssl 🖥️

RSA, EVP_KEYMGMT-RSA, RSA - EVP_PKEY RSA keytype and algorithm support

DESCRIPTION

The RSA keytype is implemented in OpenSSL’s default and FIPS providers. That implementation supports the basic RSA keys, containing the modulus n, the public exponent e, the private exponent d, and a collection of prime factors, exponents and coefficient for CRT calculations, of which the first few are known as p and q, dP and dQ, and qInv.

Common RSA parameters

In addition to the common parameters that all keytypes should support (see “Common parameters” in provider-keymgmt (7)), the RSA keytype implementation supports the following.

“n” (OSSL_PKEY_PARAM_RSA_N) <unsigned integer>
The RSA modulus “n” value.

“e” (OSSL_PKEY_PARAM_RSA_E) <unsigned integer>
The RSA public exponent “e” value. This value must always be set when creating a raw key using EVP_PKEY_fromdata (3). Note that when a decryption operation is performed, that this value is used for blinding purposes to prevent timing attacks.

“d” (OSSL_PKEY_PARAM_RSA_D) <unsigned integer>
The RSA private exponent “d” value.

“rsa-factor1” (OSSL_PKEY_PARAM_RSA_FACTOR1) <unsigned integer>

“rsa-factor2” (OSSL_PKEY_PARAM_RSA_FACTOR2) <unsigned integer>

“rsa-factor3” (OSSL_PKEY_PARAM_RSA_FACTOR3) <unsigned integer>

“rsa-factor4” (OSSL_PKEY_PARAM_RSA_FACTOR4) <unsigned integer>

“rsa-factor5” (OSSL_PKEY_PARAM_RSA_FACTOR5) <unsigned integer>

“rsa-factor6” (OSSL_PKEY_PARAM_RSA_FACTOR6) <unsigned integer>

“rsa-factor7” (OSSL_PKEY_PARAM_RSA_FACTOR7) <unsigned integer>

“rsa-factor8” (OSSL_PKEY_PARAM_RSA_FACTOR8) <unsigned integer>

“rsa-factor9” (OSSL_PKEY_PARAM_RSA_FACTOR9) <unsigned integer>

“rsa-factor10” (OSSL_PKEY_PARAM_RSA_FACTOR10) <unsigned integer>

RSA prime factors. The factors are known as “p”, “q” and “r_i” in RFC8017. Up to eight additional “r_i” prime factors are supported.

“rsa-exponent1” (OSSL_PKEY_PARAM_RSA_EXPONENT1) <unsigned integer>

“rsa-exponent2” (OSSL_PKEY_PARAM_RSA_EXPONENT2) <unsigned integer>

“rsa-exponent3” (OSSL_PKEY_PARAM_RSA_EXPONENT3) <unsigned integer>

“rsa-exponent4” (OSSL_PKEY_PARAM_RSA_EXPONENT4) <unsigned integer>

“rsa-exponent5” (OSSL_PKEY_PARAM_RSA_EXPONENT5) <unsigned integer>

“rsa-exponent6” (OSSL_PKEY_PARAM_RSA_EXPONENT6) <unsigned integer>

“rsa-exponent7” (OSSL_PKEY_PARAM_RSA_EXPONENT7) <unsigned integer>

“rsa-exponent8” (OSSL_PKEY_PARAM_RSA_EXPONENT8) <unsigned integer>

“rsa-exponent9” (OSSL_PKEY_PARAM_RSA_EXPONENT9) <unsigned integer>

“rsa-exponent10” (OSSL_PKEY_PARAM_RSA_EXPONENT10) <unsigned integer>

RSA CRT (Chinese Remainder Theorem) exponents. The exponents are known as “dP”, “dQ” and “d_i” in RFC8017. Up to eight additional “d_i” exponents are supported.

“rsa-coefficient1” (OSSL_PKEY_PARAM_RSA_COEFFICIENT1) <unsigned integer>

“rsa-coefficient2” (OSSL_PKEY_PARAM_RSA_COEFFICIENT2) <unsigned integer>

“rsa-coefficient3” (OSSL_PKEY_PARAM_RSA_COEFFICIENT3) <unsigned integer>

“rsa-coefficient4” (OSSL_PKEY_PARAM_RSA_COEFFICIENT4) <unsigned integer>

“rsa-coefficient5” (OSSL_PKEY_PARAM_RSA_COEFFICIENT5) <unsigned integer>

“rsa-coefficient6” (OSSL_PKEY_PARAM_RSA_COEFFICIENT6) <unsigned integer>

“rsa-coefficient7” (OSSL_PKEY_PARAM_RSA_COEFFICIENT7) <unsigned integer>

“rsa-coefficient8” (OSSL_PKEY_PARAM_RSA_COEFFICIENT8) <unsigned integer>

“rsa-coefficient9” (OSSL_PKEY_PARAM_RSA_COEFFICIENT9) <unsigned integer>

RSA CRT (Chinese Remainder Theorem) coefficients. The coefficients are known as “qInv” and “t_i”. Up to eight additional “t_i” exponents are supported.

RSA key generation parameters

When generating RSA keys, the following key generation parameters may be used.

“bits” (OSSL_PKEY_PARAM_RSA_BITS) <unsigned integer>
The value should be the cryptographic length for the RSA cryptosystem, in bits.

“primes” (OSSL_PKEY_PARAM_RSA_PRIMES) <unsigned integer>
The value should be the number of primes for the generated RSA key. The default is 2. It isn’t permitted to specify a larger number of primes than 10. Additionally, the number of primes is limited by the length of the key being generated so the maximum number could be less. Some providers may only support a value of 2.

“e” (OSSL_PKEY_PARAM_RSA_E) <unsigned integer>
The RSA “e” value. The value may be any odd number greater than or equal to 65537. The default value is 65537. For legacy reasons a value of 3 is currently accepted but is deprecated.

RSA key generation parameters for FIPS module testing

When generating RSA keys, the following additional key generation parameters may be used for algorithm testing purposes only. Do not use these to generate RSA keys for a production environment.

“xp” (OSSL_PKEY_PARAM_RSA_TEST_XP) <unsigned integer>

“xq” (OSSL_PKEY_PARAM_RSA_TEST_XQ) <unsigned integer>

These 2 fields are normally randomly generated and are used to generate “p” and “q”.

“xp1” (OSSL_PKEY_PARAM_RSA_TEST_XP1) <unsigned integer>

“xp2” (OSSL_PKEY_PARAM_RSA_TEST_XP2) <unsigned integer>

“xq1” (OSSL_PKEY_PARAM_RSA_TEST_XQ1) <unsigned integer>

“xq2” (OSSL_PKEY_PARAM_RSA_TEST_XQ2) <unsigned integer>

These 4 fields are normally randomly generated. The prime factors “p1”, “p2”, “q1” and “q2” are determined from these values.

RSA key parameters for FIPS module testing

The following intermediate values can be retrieved only if the values specified in “RSA key generation parameters for FIPS module testing” are set. These should not be accessed in a production environment.

“p1” (OSSL_PKEY_PARAM_RSA_TEST_P1) <unsigned integer>

“p2” (OSSL_PKEY_PARAM_RSA_TEST_P2) <unsigned integer>

“q1” (OSSL_PKEY_PARAM_RSA_TEST_Q1) <unsigned integer>

“q2” (OSSL_PKEY_PARAM_RSA_TEST_Q2) <unsigned integer>

The auxiliary probable primes.

RSA key validation

For RSA keys, EVP_PKEY_param_check (3) and EVP_PKEY_param_check_quick (3) both return 1 unconditionally.

For RSA keys, EVP_PKEY_public_check (3) conforms to the SP800-56Br1 public key check when the OpenSSL FIPS provider is used. The OpenSSL default provider performs similar tests but relaxes the keysize restrictions for backwards compatibility.

For RSA keys, EVP_PKEY_public_check_quick (3) is the same as EVP_PKEY_public_check (3).

For RSA keys, EVP_PKEY_private_check (3) conforms to the SP800-56Br1 private key test.

For RSA keys, EVP_PKEY_pairwise_check (3) conforms to the SP800-56Br1 KeyPair Validation check for the OpenSSL FIPS provider. The OpenSSL default provider allows testing of the validity of multi-primes.

CONFORMING TO

FIPS186-4
Section B.3.6 Generation of Probable Primes with Conditions Based on Auxiliary Probable Primes

RFC 8017, excluding RSA-PSS and RSA-OAEP

EXAMPLES

An EVP_PKEY context can be obtained by calling:

EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “RSA”, NULL);

An RSA key can be generated simply like this:

pkey = EVP_RSA_gen(4096);

or like this:

EVP_PKEY *pkey = NULL; EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “RSA”, NULL); EVP_PKEY_keygen_init(pctx); EVP_PKEY_generate(pctx, &pkey); EVP_PKEY_CTX_free(pctx);

An RSA key can be generated with key generation parameters:

unsigned int primes = 3; unsigned int bits = 4096; OSSL_PARAM params[3]; EVP_PKEY *pkey = NULL; EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, “RSA”, NULL); EVP_PKEY_keygen_init(pctx); params[0] = OSSL_PARAM_construct_uint(“bits”, &bits); params[1] = OSSL_PARAM_construct_uint(“primes”, &primes); params[2] = OSSL_PARAM_construct_end(); EVP_PKEY_CTX_set_params(pctx, params); EVP_PKEY_generate(pctx, &pkey); EVP_PKEY_print_private(bio_out, pkey, 0, NULL); EVP_PKEY_CTX_free(pctx);

SEE ALSO

EVP_RSA_gen (3), EVP_KEYMGMT (3), EVP_PKEY (3), provider-keymgmt (7)

COPYRIGHT

Copyright 2020-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

595 - Linux cli command SAVEPOINT

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command SAVEPOINT and provides detailed information about the command SAVEPOINT, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the SAVEPOINT.

NAME 🖥️ SAVEPOINT 🖥️

define a new savepoint within the current transaction

SYNOPSIS

SAVEPOINT savepoint_name

DESCRIPTION

SAVEPOINT establishes a new savepoint within the current transaction.

A savepoint is a special mark inside a transaction that allows all commands that are executed after it was established to be rolled back, restoring the transaction state to what it was at the time of the savepoint.

PARAMETERS

savepoint_name

The name to give to the new savepoint. If savepoints with the same name already exist, they will be inaccessible until newer identically-named savepoints are released.

NOTES

Use ROLLBACK TO to rollback to a savepoint. Use RELEASE SAVEPOINT to destroy a savepoint, keeping the effects of commands executed after it was established.

Savepoints can only be established when inside a transaction block. There can be multiple savepoints defined within a transaction.

EXAMPLES

To establish a savepoint and later undo the effects of all commands executed after it was established:

BEGIN; INSERT INTO table1 VALUES (1); SAVEPOINT my_savepoint; INSERT INTO table1 VALUES (2); ROLLBACK TO SAVEPOINT my_savepoint; INSERT INTO table1 VALUES (3); COMMIT;

The above transaction will insert the values 1 and 3, but not 2.

To establish and later destroy a savepoint:

BEGIN; INSERT INTO table1 VALUES (3); SAVEPOINT my_savepoint; INSERT INTO table1 VALUES (4); RELEASE SAVEPOINT my_savepoint; COMMIT;

The above transaction will insert both 3 and 4.

To use a single savepoint name:

BEGIN; INSERT INTO table1 VALUES (1); SAVEPOINT my_savepoint; INSERT INTO table1 VALUES (2); SAVEPOINT my_savepoint; INSERT INTO table1 VALUES (3);

    -- rollback to the second savepoint
    ROLLBACK TO SAVEPOINT my_savepoint;
    SELECT * FROM table1;               -- shows rows 1 and 2

    -- release the second savepoint
    RELEASE SAVEPOINT my_savepoint;

    -- rollback to the first savepoint
    ROLLBACK TO SAVEPOINT my_savepoint;
    SELECT * FROM table1;               -- shows only row 1
COMMIT;

The above transaction shows row 3 being rolled back first, then row 2.

COMPATIBILITY

SQL requires a savepoint to be destroyed automatically when another savepoint with the same name is established. In PostgreSQL, the old savepoint is kept, though only the more recent one will be used when rolling back or releasing. (Releasing the newer savepoint with RELEASE SAVEPOINT will cause the older one to again become accessible to ROLLBACK TO SAVEPOINT and RELEASE SAVEPOINT.) Otherwise, SAVEPOINT is fully SQL conforming.

SEE ALSO

BEGIN(7), COMMIT(7), RELEASE SAVEPOINT (RELEASE_SAVEPOINT(7)), ROLLBACK(7), ROLLBACK TO SAVEPOINT (ROLLBACK_TO_SAVEPOINT(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

596 - Linux cli command CREATE_EXTENSION

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_EXTENSION and provides detailed information about the command CREATE_EXTENSION, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_EXTENSION.

NAME 🖥️ CREATE_EXTENSION 🖥️

install an extension

SYNOPSIS

CREATE EXTENSION [ IF NOT EXISTS ] extension_name
    [ WITH ] [ SCHEMA schema_name ]
             [ VERSION version ]
             [ CASCADE ]

DESCRIPTION

CREATE EXTENSION loads a new extension into the current database. There must not be an extension of the same name already loaded.

Loading an extension essentially amounts to running the extensions script file. The script will typically create new SQL objects such as functions, data types, operators and index support methods. CREATE EXTENSION additionally records the identities of all the created objects, so that they can be dropped again if DROP EXTENSION is issued.

The user who runs CREATE EXTENSION becomes the owner of the extension for purposes of later privilege checks, and normally also becomes the owner of any objects created by the extensions script.

Loading an extension ordinarily requires the same privileges that would be required to create its component objects. For many extensions this means superuser privileges are needed. However, if the extension is marked trusted in its control file, then it can be installed by any user who has CREATE privilege on the current database. In this case the extension object itself will be owned by the calling user, but the contained objects will be owned by the bootstrap superuser (unless the extensions script explicitly assigns them to the calling user). This configuration gives the calling user the right to drop the extension, but not to modify individual objects within it.

PARAMETERS

IF NOT EXISTS

Do not throw an error if an extension with the same name already exists. A notice is issued in this case. Note that there is no guarantee that the existing extension is anything like the one that would have been created from the currently-available script file.

extension_name

The name of the extension to be installed. PostgreSQL will create the extension using details from the file SHAREDIR/extension/extension_name.control.

schema_name

The name of the schema in which to install the extensions objects, given that the extension allows its contents to be relocated. The named schema must already exist. If not specified, and the extensions control file does not specify a schema either, the current default object creation schema is used.

If the extension specifies a schema parameter in its control file, then that schema cannot be overridden with a SCHEMA clause. Normally, an error will be raised if a SCHEMA clause is given and it conflicts with the extensions schema parameter. However, if the CASCADE clause is also given, then schema_name is ignored when it conflicts. The given schema_name will be used for installation of any needed extensions that do not specify schema in their control files.

Remember that the extension itself is not considered to be within any schema: extensions have unqualified names that must be unique database-wide. But objects belonging to the extension can be within schemas.

version

The version of the extension to install. This can be written as either an identifier or a string literal. The default version is whatever is specified in the extensions control file.

CASCADE

Automatically install any extensions that this extension depends on that are not already installed. Their dependencies are likewise automatically installed, recursively. The SCHEMA clause, if given, applies to all extensions that get installed this way. Other options of the statement are not applied to automatically-installed extensions; in particular, their default versions are always selected.

NOTES

Before you can use CREATE EXTENSION to load an extension into a database, the extensions supporting files must be installed. Information about installing the extensions supplied with PostgreSQL can be found in Additional Supplied Modules.

The extensions currently available for loading can be identified from the pg_available_extensions or pg_available_extension_versions system views.

Caution

Installing an extension as superuser requires trusting that the extensions author wrote the extension installation script in a secure fashion. It is not terribly difficult for a malicious user to create trojan-horse objects that will compromise later execution of a carelessly-written extension script, allowing that user to acquire superuser privileges. However, trojan-horse objects are only hazardous if they are in the search_path during script execution, meaning that they are in the extensions installation target schema or in the schema of some extension it depends on. Therefore, a good rule of thumb when dealing with extensions whose scripts have not been carefully vetted is to install them only into schemas for which CREATE privilege has not been and will not be granted to any untrusted users. Likewise for any extensions they depend on.

The extensions supplied with PostgreSQL are believed to be secure against installation-time attacks of this sort, except for a few that depend on other extensions. As stated in the documentation for those extensions, they should be installed into secure schemas, or installed into the same schemas as the extensions they depend on, or both.

For information about writing new extensions, see Section 38.17.

EXAMPLES

Install the hstore extension into the current database, placing its objects in schema addons:

CREATE EXTENSION hstore SCHEMA addons;

Another way to accomplish the same thing:

SET search_path = addons; CREATE EXTENSION hstore;

COMPATIBILITY

CREATE EXTENSION is a PostgreSQL extension.

SEE ALSO

ALTER EXTENSION (ALTER_EXTENSION(7)), DROP EXTENSION (DROP_EXTENSION(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

597 - Linux cli command regex

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command regex and provides detailed information about the command regex, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the regex.

NAME 🖥️ regex 🖥️

POSIX.2 regular expressions

DESCRIPTION

Regular expressions (“RE"s), as defined in POSIX.2, come in two forms: modern REs (roughly those of egrep(1); POSIX.2 calls these “extended” REs) and obsolete REs (roughly those of ed(1); POSIX.2 “basic” REs). Obsolete REs mostly exist for backward compatibility in some old programs; they will be discussed at the end. POSIX.2 leaves some aspects of RE syntax and semantics open; “(!)” marks decisions on these aspects that may not be fully portable to other POSIX.2 implementations.

A (modern) RE is one(!) or more nonempty(!) branches, separated by ‘|’. It matches anything that matches one of the branches.

A branch is one(!) or more pieces, concatenated. It matches a match for the first, followed by a match for the second, and so on.

A piece is an atom possibly followed by a single(!) ‘*’, ‘+’, ‘?’, or bound. An atom followed by ‘*’ matches a sequence of 0 or more matches of the atom. An atom followed by ‘+’ matches a sequence of 1 or more matches of the atom. An atom followed by ‘?’ matches a sequence of 0 or 1 matches of the atom.

A bound is ‘{’ followed by an unsigned decimal integer, possibly followed by ‘,’ possibly followed by another unsigned decimal integer, always followed by ‘}’. The integers must lie between 0 and RE_DUP_MAX (255(!)) inclusive, and if there are two of them, the first may not exceed the second. An atom followed by a bound containing one integer i and no comma matches a sequence of exactly i matches of the atom. An atom followed by a bound containing one integer i and a comma matches a sequence of i or more matches of the atom. An atom followed by a bound containing two integers i and j matches a sequence of i through j (inclusive) matches of the atom.

An atom is a regular expression enclosed in “()” (matching a match for the regular expression), an empty set of “()” (matching the null string)(!), a bracket expression (see below), ‘.’ (matching any single character), ‘^’ (matching the null string at the beginning of a line), ‘$’ (matching the null string at the end of a line), a ‘\ followed by one of the characters “*^.[$()|*+?{*” (matching that character taken as an ordinary character), a ‘\ followed by any other character(!) (matching that character taken as an ordinary character, as if the ‘\ had not been present(!)), or a single character with no other significance (matching that character). A ‘{’ followed by a character other than a digit is an ordinary character, not the beginning of a bound(!). It is illegal to end an RE with ‘.

A bracket expression is a list of characters enclosed in “[]”. It normally matches any single character from the list (but see below). If the list begins with ‘^’, it matches any single character (but see below) not from the rest of the list. If two characters in the list are separated by ‘-’, this is shorthand for the full range of characters between those two (inclusive) in the collating sequence, for example, “[0-9]” in ASCII matches any decimal digit. It is illegal(!) for two ranges to share an endpoint, for example, “a-c-e”. Ranges are very collating-sequence-dependent, and portable programs should avoid relying on them.

To include a literal ‘]’ in the list, make it the first character (following a possible ‘^’). To include a literal ‘-’, make it the first or last character, or the second endpoint of a range. To use a literal ‘-’ as the first endpoint of a range, enclose it in “[.” and “.]” to make it a collating element (see below). With the exception of these and some combinations using ‘[’ (see next paragraphs), all other special characters, including ‘, lose their special significance within a bracket expression.

Within a bracket expression, a collating element (a character, a multicharacter sequence that collates as if it were a single character, or a collating-sequence name for either) enclosed in “[.” and “.]” stands for the sequence of characters of that collating element. The sequence is a single element of the bracket expression’s list. A bracket expression containing a multicharacter collating element can thus match more than one character, for example, if the collating sequence includes a “ch” collating element, then the RE “[[.ch.]]*c” matches the first five characters of “chchcc”.

Within a bracket expression, a collating element enclosed in “[=” and “=]” is an equivalence class, standing for the sequences of characters of all collating elements equivalent to that one, including itself. (If there are no other equivalent collating elements, the treatment is as if the enclosing delimiters were “[.” and “.]”.) For example, if o and ô are the members of an equivalence class, then “[[=o=]]”, “[[=ô=]]”, and “[oô]” are all synonymous. An equivalence class may not(!) be an endpoint of a range.

Within a bracket expression, the name of a character class enclosed in “[:” and “:]” stands for the list of all characters belonging to that class. Standard character class names are:

alnumdigitpunct
alphagraphspace
blanklowerupper
cntrlprintxdigit

These stand for the character classes defined in wctype(3). A locale may provide others. A character class may not be used as an endpoint of a range.

In the event that an RE could match more than one substring of a given string, the RE matches the one starting earliest in the string. If the RE could match more than one substring starting at that point, it matches the longest. Subexpressions also match the longest possible substrings, subject to the constraint that the whole match be as long as possible, with subexpressions starting earlier in the RE taking priority over ones starting later. Note that higher-level subexpressions thus take priority over their lower-level component subexpressions.

Match lengths are measured in characters, not collating elements. A null string is considered longer than no match at all. For example, “bb*” matches the three middle characters of “abbbc”, “(wee|week)(knights|nights)” matches all ten characters of “weeknights”, when “(.*).*” is matched against “abc” the parenthesized subexpression matches all three characters, and when “(a*)*” is matched against “bc” both the whole RE and the parenthesized subexpression match the null string.

If case-independent matching is specified, the effect is much as if all case distinctions had vanished from the alphabet. When an alphabetic that exists in multiple cases appears as an ordinary character outside a bracket expression, it is effectively transformed into a bracket expression containing both cases, for example, ‘x’ becomes “[xX]”. When it appears inside a bracket expression, all case counterparts of it are added to the bracket expression, so that, for example, “[x]” becomes “[xX]” and “[^x]” becomes “[^xX]”.

No particular limit is imposed on the length of REs(!). Programs intended to be portable should not employ REs longer than 256 bytes, as an implementation can refuse to accept such REs and remain POSIX-compliant.

Obsolete (“basic”) regular expressions differ in several respects. ‘|’, ‘+’, and ‘?’ are ordinary characters and there is no equivalent for their functionality. The delimiters for bounds are “*” and “*”, with ‘{’ and ‘}’ by themselves ordinary characters. The parentheses for nested subexpressions are “*” and “*”, with ‘(’ and ‘)’ by themselves ordinary characters. ‘^’ is an ordinary character except at the beginning of the RE or(!) the beginning of a parenthesized subexpression, ‘$’ is an ordinary character except at the end of the RE or(!) the end of a parenthesized subexpression, and ‘*’ is an ordinary character if it appears at the beginning of the RE or the beginning of a parenthesized subexpression (after a possible leading ‘^’).

Finally, there is one new type of atom, a back reference: ‘\ followed by a nonzero decimal digit d matches the same sequence of characters matched by the dth parenthesized subexpression (numbering subexpressions by the positions of their opening parentheses, left to right), so that, for example, “\[bc]\1” matches “bb” or “cc” but not “bc”.

BUGS

Having two kinds of REs is a botch.

The current POSIX.2 spec says that ‘)’ is an ordinary character in the absence of an unmatched ‘(’; this was an unintentional result of a wording error, and change is likely. Avoid relying on it.

Back references are a dreadful botch, posing major problems for efficient implementations. They are also somewhat vaguely defined (does “a\b\\2\d” match “abbbd”?). Avoid using them.

POSIX.2’s specification of case-independent matching is vague. The “one case implies all cases” definition given above is current consensus among implementors as to the right interpretation.

AUTHOR

This page was taken from Henry Spencer’s regex package.

SEE ALSO

grep(1), regex(3)

POSIX.2, section 2.8 (Regular Expression Notation).

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

598 - Linux cli command CREATE_CAST

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_CAST and provides detailed information about the command CREATE_CAST, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_CAST.

NAME 🖥️ CREATE_CAST 🖥️

define a new cast

SYNOPSIS

CREATE CAST (source_type AS target_type)
    WITH FUNCTION function_name [ (argument_type [, ...]) ]
    [ AS ASSIGNMENT | AS IMPLICIT ]

CREATE CAST (source_type AS target_type)
    WITHOUT FUNCTION
    [ AS ASSIGNMENT | AS IMPLICIT ]

CREATE CAST (source_type AS target_type)
    WITH INOUT
    [ AS ASSIGNMENT | AS IMPLICIT ]

DESCRIPTION

CREATE CAST defines a new cast. A cast specifies how to perform a conversion between two data types. For example,

SELECT CAST(42 AS float8);

converts the integer constant 42 to type float8 by invoking a previously specified function, in this case float8(int4). (If no suitable cast has been defined, the conversion fails.)

Two types can be binary coercible, which means that the conversion can be performed “for free” without invoking any function. This requires that corresponding values use the same internal representation. For instance, the types text and varchar are binary coercible both ways. Binary coercibility is not necessarily a symmetric relationship. For example, the cast from xml to text can be performed for free in the present implementation, but the reverse direction requires a function that performs at least a syntax check. (Two types that are binary coercible both ways are also referred to as binary compatible.)

You can define a cast as an I/O conversion cast by using the WITH INOUT syntax. An I/O conversion cast is performed by invoking the output function of the source data type, and passing the resulting string to the input function of the target data type. In many common cases, this feature avoids the need to write a separate cast function for conversion. An I/O conversion cast acts the same as a regular function-based cast; only the implementation is different.

By default, a cast can be invoked only by an explicit cast request, that is an explicit CAST(x AS typename) or x::typename construct.

If the cast is marked AS ASSIGNMENT then it can be invoked implicitly when assigning a value to a column of the target data type. For example, supposing that foo.f1 is a column of type text, then:

INSERT INTO foo (f1) VALUES (42);

will be allowed if the cast from type integer to type text is marked AS ASSIGNMENT, otherwise not. (We generally use the term assignment cast to describe this kind of cast.)

If the cast is marked AS IMPLICIT then it can be invoked implicitly in any context, whether assignment or internally in an expression. (We generally use the term implicit cast to describe this kind of cast.) For example, consider this query:

SELECT 2 + 4.0;

The parser initially marks the constants as being of type integer and numeric respectively. There is no integer + numeric operator in the system catalogs, but there is a numeric + numeric operator. The query will therefore succeed if a cast from integer to numeric is available and is marked AS IMPLICIT — which in fact it is. The parser will apply the implicit cast and resolve the query as if it had been written

SELECT CAST ( 2 AS numeric ) + 4.0;

Now, the catalogs also provide a cast from numeric to integer. If that cast were marked AS IMPLICIT — which it is not — then the parser would be faced with choosing between the above interpretation and the alternative of casting the numeric constant to integer and applying the integer + integer operator. Lacking any knowledge of which choice to prefer, it would give up and declare the query ambiguous. The fact that only one of the two casts is implicit is the way in which we teach the parser to prefer resolution of a mixed numeric-and-integer expression as numeric; there is no built-in knowledge about that.

It is wise to be conservative about marking casts as implicit. An overabundance of implicit casting paths can cause PostgreSQL to choose surprising interpretations of commands, or to be unable to resolve commands at all because there are multiple possible interpretations. A good rule of thumb is to make a cast implicitly invokable only for information-preserving transformations between types in the same general type category. For example, the cast from int2 to int4 can reasonably be implicit, but the cast from float8 to int4 should probably be assignment-only. Cross-type-category casts, such as text to int4, are best made explicit-only.

Note

Sometimes it is necessary for usability or standards-compliance reasons to provide multiple implicit casts among a set of types, resulting in ambiguity that cannot be avoided as above. The parser has a fallback heuristic based on type categories and preferred types that can help to provide desired behavior in such cases. See CREATE TYPE (CREATE_TYPE(7)) for more information.

To be able to create a cast, you must own the source or the target data type and have USAGE privilege on the other type. To create a binary-coercible cast, you must be superuser. (This restriction is made because an erroneous binary-coercible cast conversion can easily crash the server.)

PARAMETERS

source_type

The name of the source data type of the cast.

target_type

The name of the target data type of the cast.

function_name[(argument_type [, …])]

The function used to perform the cast. The function name can be schema-qualified. If it is not, the function will be looked up in the schema search path. The functions result data type must match the target type of the cast. Its arguments are discussed below. If no argument list is specified, the function name must be unique in its schema.

WITHOUT FUNCTION

Indicates that the source type is binary-coercible to the target type, so no function is required to perform the cast.

WITH INOUT

Indicates that the cast is an I/O conversion cast, performed by invoking the output function of the source data type, and passing the resulting string to the input function of the target data type.

AS ASSIGNMENT

Indicates that the cast can be invoked implicitly in assignment contexts.

AS IMPLICIT

Indicates that the cast can be invoked implicitly in any context.

Cast implementation functions can have one to three arguments. The first argument type must be identical to or binary-coercible from the casts source type. The second argument, if present, must be type integer; it receives the type modifier associated with the destination type, or -1 if there is none. The third argument, if present, must be type boolean; it receives true if the cast is an explicit cast, false otherwise. (Bizarrely, the SQL standard demands different behaviors for explicit and implicit casts in some cases. This argument is supplied for functions that must implement such casts. It is not recommended that you design your own data types so that this matters.)

The return type of a cast function must be identical to or binary-coercible to the casts target type.

Ordinarily a cast must have different source and target data types. However, it is allowed to declare a cast with identical source and target types if it has a cast implementation function with more than one argument. This is used to represent type-specific length coercion functions in the system catalogs. The named function is used to coerce a value of the type to the type modifier value given by its second argument.

When a cast has different source and target types and a function that takes more than one argument, it supports converting from one type to another and applying a length coercion in a single step. When no such entry is available, coercion to a type that uses a type modifier involves two cast steps, one to convert between data types and a second to apply the modifier.

A cast to or from a domain type currently has no effect. Casting to or from a domain uses the casts associated with its underlying type.

NOTES

Use DROP CAST to remove user-defined casts.

Remember that if you want to be able to convert types both ways you need to declare casts both ways explicitly.

It is normally not necessary to create casts between user-defined types and the standard string types (text, varchar, and char(n), as well as user-defined types that are defined to be in the string category). PostgreSQL provides automatic I/O conversion casts for that. The automatic casts to string types are treated as assignment casts, while the automatic casts from string types are explicit-only. You can override this behavior by declaring your own cast to replace an automatic cast, but usually the only reason to do so is if you want the conversion to be more easily invokable than the standard assignment-only or explicit-only setting. Another possible reason is that you want the conversion to behave differently from the types I/O function; but that is sufficiently surprising that you should think twice about whether its a good idea. (A small number of the built-in types do indeed have different behaviors for conversions, mostly because of requirements of the SQL standard.)

While not required, it is recommended that you continue to follow this old convention of naming cast implementation functions after the target data type. Many users are used to being able to cast data types using a function-style notation, that is typename(x). This notation is in fact nothing more nor less than a call of the cast implementation function; it is not specially treated as a cast. If your conversion functions are not named to support this convention then you will have surprised users. Since PostgreSQL allows overloading of the same function name with different argument types, there is no difficulty in having multiple conversion functions from different types that all use the target types name.

Note

Actually the preceding paragraph is an oversimplification: there are two cases in which a function-call construct will be treated as a cast request without having matched it to an actual function. If a function call name(x) does not exactly match any existing function, but name is the name of a data type and pg_cast provides a binary-coercible cast to this type from the type of x, then the call will be construed as a binary-coercible cast. This exception is made so that binary-coercible casts can be invoked using functional syntax, even though they lack any function. Likewise, if there is no pg_cast entry but the cast would be to or from a string type, the call will be construed as an I/O conversion cast. This exception allows I/O conversion casts to be invoked using functional syntax.

Note

There is also an exception to the exception: I/O conversion casts from composite types to string types cannot be invoked using functional syntax, but must be written in explicit cast syntax (either CAST or :: notation). This exception was added because after the introduction of automatically-provided I/O conversion casts, it was found too easy to accidentally invoke such a cast when a function or column reference was intended.

EXAMPLES

To create an assignment cast from type bigint to type int4 using the function int4(bigint):

CREATE CAST (bigint AS int4) WITH FUNCTION int4(bigint) AS ASSIGNMENT;

(This cast is already predefined in the system.)

COMPATIBILITY

The CREATE CAST command conforms to the SQL standard, except that SQL does not make provisions for binary-coercible types or extra arguments to implementation functions. AS IMPLICIT is a PostgreSQL extension, too.

SEE ALSO

CREATE FUNCTION (CREATE_FUNCTION(7)), CREATE TYPE (CREATE_TYPE(7)), DROP CAST (DROP_CAST(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

599 - Linux cli command unicode

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command unicode and provides detailed information about the command unicode, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the unicode.

NAME 🖥️ unicode 🖥️

universal character set

DESCRIPTION

The international standard ISO/IEC 10646 defines the Universal Character Set (UCS). UCS contains all characters of all other character set standards. It also guarantees “round-trip compatibility”; in other words, conversion tables can be built such that no information is lost when a string is converted from any other encoding to UCS and back.

UCS contains the characters required to represent practically all known languages. This includes not only the Latin, Greek, Cyrillic, Hebrew, Arabic, Armenian, and Georgian scripts, but also Chinese, Japanese and Korean Han ideographs as well as scripts such as Hiragana, Katakana, Hangul, Devanagari, Bengali, Gurmukhi, Gujarati, Oriya, Tamil, Telugu, Kannada, Malayalam, Thai, Lao, Khmer, Bopomofo, Tibetan, Runic, Ethiopic, Canadian Syllabics, Cherokee, Mongolian, Ogham, Myanmar, Sinhala, Thaana, Yi, and others. For scripts not yet covered, research on how to best encode them for computer usage is still going on and they will be added eventually. This might eventually include not only Hieroglyphs and various historic Indo-European languages, but even some selected artistic scripts such as Tengwar, Cirth, and Klingon. UCS also covers a large number of graphical, typographical, mathematical, and scientific symbols, including those provided by TeX, Postscript, APL, MS-DOS, MS-Windows, Macintosh, OCR fonts, as well as many word processing and publishing systems, and more are being added.

The UCS standard (ISO/IEC 10646) describes a 31-bit character set architecture consisting of 128 24-bit groups, each divided into 256 16-bit planes made up of 256 8-bit rows with 256 column positions, one for each character. Part 1 of the standard (ISO/IEC 10646-1) defines the first 65534 code positions (0x0000 to 0xfffd), which form the Basic Multilingual Plane (BMP), that is plane 0 in group 0. Part 2 of the standard (ISO/IEC 10646-2) adds characters to group 0 outside the BMP in several supplementary planes in the range 0x10000 to 0x10ffff. There are no plans to add characters beyond 0x10ffff to the standard, therefore of the entire code space, only a small fraction of group 0 will ever be actually used in the foreseeable future. The BMP contains all characters found in the commonly used other character sets. The supplemental planes added by ISO/IEC 10646-2 cover only more exotic characters for special scientific, dictionary printing, publishing industry, higher-level protocol and enthusiast needs.

The representation of each UCS character as a 2-byte word is referred to as the UCS-2 form (only for BMP characters), whereas UCS-4 is the representation of each character by a 4-byte word. In addition, there exist two encoding forms UTF-8 for backward compatibility with ASCII processing software and UTF-16 for the backward-compatible handling of non-BMP characters up to 0x10ffff by UCS-2 software.

The UCS characters 0x0000 to 0x007f are identical to those of the classic US-ASCII character set and the characters in the range 0x0000 to 0x00ff are identical to those in ISO/IEC 8859-1 (Latin-1).

Combining characters

Some code points in UCS have been assigned to combining characters. These are similar to the nonspacing accent keys on a typewriter. A combining character just adds an accent to the previous character. The most important accented characters have codes of their own in UCS, however, the combining character mechanism allows us to add accents and other diacritical marks to any character. The combining characters always follow the character which they modify. For example, the German character Umlaut-A (“Latin capital letter A with diaeresis”) can either be represented by the precomposed UCS code 0x00c4, or alternatively as the combination of a normal “Latin capital letter A” followed by a “combining diaeresis”: 0x0041 0x0308.

Combining characters are essential for instance for encoding the Thai script or for mathematical typesetting and users of the International Phonetic Alphabet.

Implementation levels

As not all systems are expected to support advanced mechanisms like combining characters, ISO/IEC 10646-1 specifies the following three implementation levels of UCS:

Level 1
Combining characters and Hangul Jamo (a variant encoding of the Korean script, where a Hangul syllable glyph is coded as a triplet or pair of vowel/consonant codes) are not supported.

Level 2
In addition to level 1, combining characters are now allowed for some languages where they are essential (e.g., Thai, Lao, Hebrew, Arabic, Devanagari, Malayalam).

Level 3
All UCS characters are supported.

The Unicode 3.0 Standard published by the Unicode Consortium contains exactly the UCS Basic Multilingual Plane at implementation level 3, as described in ISO/IEC 10646-1:2000. Unicode 3.1 added the supplemental planes of ISO/IEC 10646-2. The Unicode standard and technical reports published by the Unicode Consortium provide much additional information on the semantics and recommended usages of various characters. They provide guidelines and algorithms for editing, sorting, comparing, normalizing, converting, and displaying Unicode strings.

Unicode under Linux

Under GNU/Linux, the C type wchar_t is a signed 32-bit integer type. Its values are always interpreted by the C library as UCS code values (in all locales), a convention that is signaled by the GNU C library to applications by defining the constant __STDC_ISO_10646__ as specified in the ISO C99 standard.

UCS/Unicode can be used just like ASCII in input/output streams, terminal communication, plaintext files, filenames, and environment variables in the ASCII compatible UTF-8 multibyte encoding. To signal the use of UTF-8 as the character encoding to all applications, a suitable locale has to be selected via environment variables (e.g., “LANG=en_GB.UTF-8”).

The nl_langinfo(CODESET) function returns the name of the selected encoding. Library functions such as wctomb(3) and mbsrtowcs(3) can be used to transform the internal wchar_t characters and strings into the system character encoding and back and wcwidth(3) tells how many positions (0–2) the cursor is advanced by the output of a character.

Private Use Areas (PUA)

In the Basic Multilingual Plane, the range 0xe000 to 0xf8ff will never be assigned to any characters by the standard and is reserved for private usage. For the Linux community, this private area has been subdivided further into the range 0xe000 to 0xefff which can be used individually by any end-user and the Linux zone in the range 0xf000 to 0xf8ff where extensions are coordinated among all Linux users. The registry of the characters assigned to the Linux zone is maintained by LANANA and the registry itself is Documentation/admin-guide/unicode.rst in the Linux kernel sources (or Documentation/unicode.txt before Linux 4.10).

Two other planes are reserved for private usage, plane 15 (Supplementary Private Use Area-A, range 0xf0000 to 0xffffd) and plane 16 (Supplementary Private Use Area-B, range 0x100000 to 0x10fffd).

Literature

  • Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 1: Architecture and Basic Multilingual Plane. International Standard ISO/IEC 10646-1, International Organization for Standardization, Geneva, 2000.

    This is the official specification of UCS. Available from .

  • The Unicode Standard, Version 3.0. The Unicode Consortium, Addison-Wesley, Reading, MA, 2000, ISBN 0-201-61633-5.

  • S. Harbison, G. Steele. C: A Reference Manual. Fourth edition, Prentice Hall, Englewood Cliffs, 1995, ISBN 0-13-326224-3.

    A good reference book about the C programming language. The fourth edition covers the 1994 Amendment 1 to the ISO C90 standard, which adds a large number of new C library functions for handling wide and multibyte character encodings, but it does not yet cover ISO C99, which improved wide and multibyte character support even further.

  • Unicode Technical Reports.

  • Markus Kuhn: UTF-8 and Unicode FAQ for UNIX/Linux.

  • Bruno Haible: Unicode HOWTO.

SEE ALSO

locale(1), setlocale(3), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

600 - Linux cli command iso_8859_15

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso_8859_15 and provides detailed information about the command iso_8859_15, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso_8859_15.

NAME 🖥️ iso_8859_15 🖥️

15 - ISO/IEC 8859-15 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-15 encodes the characters used in many West European languages and adds the Euro sign.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-15 characters

The following table displays the characters in ISO/IEC 8859-15 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-15 is also known as Latin-9 (or sometimes as Latin-0).

SEE ALSO

ascii(7), charsets(7), cp1252(7), iso_8859-1(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

601 - Linux cli command latin7

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command latin7 and provides detailed information about the command latin7, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the latin7.

NAME 🖥️ latin7 🖥️

13 - ISO/IEC 8859-13 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-13 encodes the characters used in Baltic Rim languages.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-13 characters

The following table displays the characters in ISO/IEC 8859-13 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-13 is also known as Latin-7.

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

602 - Linux cli command OSSL_STORE-winstoressl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command OSSL_STORE-winstoressl and provides detailed information about the command OSSL_STORE-winstoressl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the OSSL_STORE-winstoressl.

NAME 🖥️ OSSL_STORE-winstoressl 🖥️

winstore - OpenSSL built in OSSL_STORE for Windows

DESCRIPTION

The OSSL_STORE implementation for Windows provides access to Windows’ system ROOT certificate store through URIs, using the URI scheme org.openssl.winstore.

Supported URIs

There is only one supported URI:

org.openssl.winstore:

No authority (host, etc), no path, no query, no fragment.

Supported OSSL_STORE_SEARCH operations

OSSL_STORE_SEARCH_by_name (3)
As a matter of fact, this must be used. It is not possible to enumerate all available certificates in the store.

Windows certificate store features

Apart from diverse constraints present in the certificates themselves, the Windows certificate store also has the ability to associate additional constraining properties alongside a certificate in the store. This includes both documented and undocumented capabilities:

  • The documented capability to override EKU

  • The undocumented capability to add name constraints

  • The undocumented capability to override the certificate expiry date

Such constraints are not checked by this OSSL_STORE implementation, and thereby not honoured.

However, once extracted with OSSL_STORE_load (3), certificates that have constraints in their X.509 extensions will go through the usual constraint checks when used by OpenSSL, and are thereby honoured.

SEE ALSO

ossl_store (7), OSSL_STORE_open_ex (3), OSSL_STORE_SEARCH (3)

HISTORY

The winstore (org.openssl.winstore) implementation was added in OpenSSL 3.2.0.

NOTES

OpenSSL uses OSSL_DECODER (3) implementations under the hood. To influence what OSSL_DECODER (3) implementations are used, it’s advisable to use OSSL_STORE_open_ex (3) and set the propq argument.

COPYRIGHT

Copyright 2024 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

603 - Linux cli command iso-8859-11

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command iso-8859-11 and provides detailed information about the command iso-8859-11, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the iso-8859-11.

NAME 🖥️ iso-8859-11 🖥️

11 - ISO/IEC 8859-11 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-11 encodes the characters used in the Thai language.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-11 characters

The following table displays the characters in ISO/IEC 8859-11 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-11 is the same as TIS (Thai Industrial Standard) 620-2253, commonly known as TIS-620, except for the character in position A0: ISO/IEC 8859-11 defines this as NO-BREAK SPACE, while TIS-620 leaves it undefined.

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

604 - Linux cli command tis-620

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command tis-620 and provides detailed information about the command tis-620, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the tis-620.

NAME 🖥️ tis-620 🖥️

11 - ISO/IEC 8859-11 character set encoded in octal, decimal, and hexadecimal

DESCRIPTION

The ISO/IEC 8859 standard includes several 8-bit extensions to the ASCII character set (also known as ISO/IEC 646-IRV). ISO/IEC 8859-11 encodes the characters used in the Thai language.

ISO/IEC 8859 alphabets

The full set of ISO/IEC 8859 alphabets includes:

ISO/IEC 8859-1West European languages (Latin-1)
ISO/IEC 8859-2Central and East European languages (Latin-2)
ISO/IEC 8859-3Southeast European and miscellaneous languages (Latin-3)
ISO/IEC 8859-4Scandinavian/Baltic languages (Latin-4)
ISO/IEC 8859-5Latin/Cyrillic
ISO/IEC 8859-6Latin/Arabic
ISO/IEC 8859-7Latin/Greek
ISO/IEC 8859-8Latin/Hebrew
ISO/IEC 8859-9Latin-1 modification for Turkish (Latin-5)
ISO/IEC 8859-10Lappish/Nordic/Eskimo languages (Latin-6)
ISO/IEC 8859-11Latin/Thai
ISO/IEC 8859-13Baltic Rim languages (Latin-7)
ISO/IEC 8859-14Celtic (Latin-8)
ISO/IEC 8859-15West European languages (Latin-9)
ISO/IEC 8859-16Romanian (Latin-10)

ISO/IEC 8859-11 characters

The following table displays the characters in ISO/IEC 8859-11 that are printable and unlisted in the ascii(7) manual page.

TABLE

NOTES

ISO/IEC 8859-11 is the same as TIS (Thai Industrial Standard) 620-2253, commonly known as TIS-620, except for the character in position A0: ISO/IEC 8859-11 defines this as NO-BREAK SPACE, while TIS-620 leaves it undefined.

SEE ALSO

ascii(7), charsets(7), utf-8(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

605 - Linux cli command REFRESH_MATERIALIZED_VIEW

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command REFRESH_MATERIALIZED_VIEW and provides detailed information about the command REFRESH_MATERIALIZED_VIEW, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the REFRESH_MATERIALIZED_VIEW.

NAME 🖥️ REFRESH_MATERIALIZED_VIEW 🖥️

replace the contents of a materialized view

SYNOPSIS

REFRESH MATERIALIZED VIEW [ CONCURRENTLY ] name
    [ WITH [ NO ] DATA ]

DESCRIPTION

REFRESH MATERIALIZED VIEW completely replaces the contents of a materialized view. To execute this command you must be the owner of the materialized view. The old contents are discarded. If WITH DATA is specified (or defaults) the backing query is executed to provide the new data, and the materialized view is left in a scannable state. If WITH NO DATA is specified no new data is generated and the materialized view is left in an unscannable state.

CONCURRENTLY and WITH NO DATA may not be specified together.

PARAMETERS

CONCURRENTLY

Refresh the materialized view without locking out concurrent selects on the materialized view. Without this option a refresh which affects a lot of rows will tend to use fewer resources and complete more quickly, but could block other connections which are trying to read from the materialized view. This option may be faster in cases where a small number of rows are affected.

This option is only allowed if there is at least one UNIQUE index on the materialized view which uses only column names and includes all rows; that is, it must not be an expression index or include a WHERE clause.

This option may not be used when the materialized view is not already populated.

Even with this option only one REFRESH at a time may run against any one materialized view.

name

The name (optionally schema-qualified) of the materialized view to refresh.

NOTES

If there is an ORDER BY clause in the materialized views defining query, the original contents of the materialized view will be ordered that way; but REFRESH MATERIALIZED VIEW does not guarantee to preserve that ordering.

EXAMPLES

This command will replace the contents of the materialized view called order_summary using the query from the materialized views definition, and leave it in a scannable state:

REFRESH MATERIALIZED VIEW order_summary;

This command will free storage associated with the materialized view annual_statistics_basis and leave it in an unscannable state:

REFRESH MATERIALIZED VIEW annual_statistics_basis WITH NO DATA;

COMPATIBILITY

REFRESH MATERIALIZED VIEW is a PostgreSQL extension.

SEE ALSO

CREATE MATERIALIZED VIEW (CREATE_MATERIALIZED_VIEW(7)), ALTER MATERIALIZED VIEW (ALTER_MATERIALIZED_VIEW(7)), DROP MATERIALIZED VIEW (DROP_MATERIALIZED_VIEW(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

606 - Linux cli command ccze-plugin

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ccze-plugin and provides detailed information about the command ccze-plugin, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ccze-plugin.

NAME 🖥️ ccze-plugin 🖥️

A robust log colorizer, plugin infrastructure

SYNOPSIS

#include <ccze.h>

/* Plugin support */
typedef void (*ccze_plugin_startup_t) (void);
typedef void (*ccze_plugin_shutdown_t) (void);
typedef int (*ccze_plugin_handle_t) (const char *str, size_t length, char **rest);

CCZE_DEFINE_PLUGIN (name, type, desc);
CCZE_DEFINE_PLUGINS (plugins…);

/* Display */
void ccze_addstr (ccze_color_t col, const char *str);
void ccze_newline (void);
void ccze_space (void);
void ccze_wordcolor_process_one (char *word, int slookup);

/* Helpers */
ccze_color_t ccze_http_action (const char *method);
void ccze_print_date (const char *date);

/* Command line */
char **ccze_plugin_argv_get (const char *name);
const char *ccze_plugin_name_get (void);

DESCRIPTION

This manual page attempts to outline the internals of CCZE plugins: how they work, how they are implemented, and how to add new ones.

There are four required entry points in a plugin: a startup, a shutdown and a handler routine (more on these later), and an informational structure.

The startup function must be of type ccze_plugin_startup_t. This is called right after the module is loaded. Its purpose is to initialise all kinds of module-specific global variables, such as the regular expressions.

The shutdown function is its counterpart: this is used to deallocate any memory reserved by the startup code.

The core part of a plugin is the handler, of type ccze_plugin_handle_t. This does the actual coloring. The string to process is passed in the str argument, its length in length. The third argument, rest is a pointer to a string. Unlike the first two, this argument is used only for output.

When a handler processed a string, it must return a non-zero value, in case it could not process it, the handler must return with zero. If the string could be processed only partially, the part which was deemed unknown by the handler must be passed back in the rest variable.

The fourth part, although the smallest part, is the most important. Without this, the module is useless, it cannot be loaded. This part tells CCZE what the startup, shutdown and handler functions are called.

To encourage good style, the little details of this structure will not be disclosed in this manual page. Instead, the helper macro, CCZE_DEFINE_PLUGIN will be explained.

CCZE_DEFINE_PLUGIN is the macro to use if one wants to make the plugin loadable. Its first argument is an unquoted string: the name of the plugin. The second part is the type of the plugin, it can be FULL, PARTIAL or ANY. The last argument is a short description of the plugin.

It is assumed that the three functions mentioned earlier are called ccze_name_setup, ccze_name_shutdown and ccze_name_handle, respectively.

A FULL plugin is one that accepts raw input, untouched by any other plugin before, and processes it. On the other hand, a PARTIAL plugin relies on previous ones preprocessing the input. For example, syslog is a full plugin, on which ulogd, a partial plugin relies. The syslog plugin processes the raw input from the logfile, adds colour to most of it, save the actual message sent by a process, that is left to subsequent plugins, like ulogd. An ANY plugin is one can act as both other types.

With CCZE_DEFINE_PLUGINS one can place more than one plugin into one shared object.

There are two other helper functions, ccze_plugin_argv_get and ccze_plugin_name_get. One can pass arguments to CCZE plugins, and these is the function to retrieve them. While ccze_plugin_name_get returns the name of the current plugin, ccze_plugin_argv_get returns a NULL-terminated array, with each entry containing an argument.

DISPLAY METHODS

The so-called display methods are the only supported interface to emit something to the display. These handle both the normal, ncurses-based, and the HTML output. This is a kind of abstraction so plugins will not have to worry about the differences between the output formats.

The most important one is ccze_addstr, which takes a color (see ccze.h for a list of supported color tags) and a string, and displays it appropriately. The ccze_space and ccze_newline functions emit a space and a newline, respectively.

Our last function, ccze_wordcolor_process_one passes word to the word colourising engine. If the second argument, slookup is non-zero, the engine will perform service lookups (like getent and friends).

HELPER METHODS

We only have two helper methods: ccze_print_date, which simply prints out the date in the appropriate colour, and ccze_http_action, which given a HTTP method, returns the associated colour, in a format suitable for ccze_addstr.

EXAMPLE

#include <ccze.h>
#include <stddef.h>
#include <string.h>

static char **ccze_foo_argv;

static int
ccze_foo_handle (const char *str, size_t length, char **rest)
{
  int i = 1;

  if (strstr (str, "foo"))
    {
      ccze_addstr (CCZE_COLOR_GOODWORD, str);
      return 1;
    }

  while (ccze_foo_argv[i])
    {
      if (strstr (str, ccze_foo_argv[i]))
        {
          ccze_addstr (CCZE_COLOR_GOODWORD, str);
          return 1;
        }
      i++;
    }
  return 0;
}

static void
ccze_foo_startup (void)
{
  ccze_foo_argv = ccze_plugin_argv_get (ccze_plugin_name_get ());
}

static void
ccze_foo_shutdown (void)
{
}

CCZE_DEFINE_PLUGIN (foo, PARTIAL, "Partial FOO coloriser.");

SEE ALSO

ccze(1)

AUTHOR

ccze was written by Gergely Nagy <[email protected]>, based on colorize by Istvan Karaszi <[email protected]>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

607 - Linux cli command pipe

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command pipe and provides detailed information about the command pipe, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the pipe.

NAME 🖥️ pipe 🖥️

overview of pipes and FIFOs

DESCRIPTION

Pipes and FIFOs (also known as named pipes) provide a unidirectional interprocess communication channel. A pipe has a read end and a write end. Data written to the write end of a pipe can be read from the read end of the pipe.

A pipe is created using pipe(2), which creates a new pipe and returns two file descriptors, one referring to the read end of the pipe, the other referring to the write end. Pipes can be used to create a communication channel between related processes; see pipe(2) for an example.

A FIFO (short for First In First Out) has a name within the filesystem (created using mkfifo(3)), and is opened using open(2). Any process may open a FIFO, assuming the file permissions allow it. The read end is opened using the O_RDONLY flag; the write end is opened using the O_WRONLY flag. See fifo(7) for further details. Note: although FIFOs have a pathname in the filesystem, I/O on FIFOs does not involve operations on the underlying device (if there is one).

I/O on pipes and FIFOs

The only difference between pipes and FIFOs is the manner in which they are created and opened. Once these tasks have been accomplished, I/O on pipes and FIFOs has exactly the same semantics.

If a process attempts to read from an empty pipe, then read(2) will block until data is available. If a process attempts to write to a full pipe (see below), then write(2) blocks until sufficient data has been read from the pipe to allow the write to complete.

Nonblocking I/O is possible by using the fcntl(2) F_SETFL operation to enable the O_NONBLOCK open file status flag or by opening a fifo(7) with O_NONBLOCK. If any process has the pipe open for writing, reads fail with EAGAIN; otherwise—with no potential writers—reads succeed and return empty.

The communication channel provided by a pipe is a byte stream: there is no concept of message boundaries.

If all file descriptors referring to the write end of a pipe have been closed, then an attempt to read(2) from the pipe will see end-of-file (read(2) will return 0). If all file descriptors referring to the read end of a pipe have been closed, then a write(2) will cause a SIGPIPE signal to be generated for the calling process. If the calling process is ignoring this signal, then write(2) fails with the error EPIPE. An application that uses pipe(2) and fork(2) should use suitable close(2) calls to close unnecessary duplicate file descriptors; this ensures that end-of-file and SIGPIPE/EPIPE are delivered when appropriate.

It is not possible to apply lseek(2) to a pipe.

Pipe capacity

A pipe has a limited capacity. If the pipe is full, then a write(2) will block or fail, depending on whether the O_NONBLOCK flag is set (see below). Different implementations have different limits for the pipe capacity. Applications should not rely on a particular capacity: an application should be designed so that a reading process consumes data as soon as it is available, so that a writing process does not remain blocked.

Before Linux 2.6.11, the capacity of a pipe was the same as the system page size (e.g., 4096 bytes on i386). Since Linux 2.6.11, the pipe capacity is 16 pages (i.e., 65,536 bytes in a system with a page size of 4096 bytes). Since Linux 2.6.35, the default pipe capacity is 16 pages, but the capacity can be queried and set using the fcntl(2) F_GETPIPE_SZ and F_SETPIPE_SZ operations. See fcntl(2) for more information.

The following ioctl(2) operation, which can be applied to a file descriptor that refers to either end of a pipe, places a count of the number of unread bytes in the pipe in the int buffer pointed to by the final argument of the call:

ioctl(fd, FIONREAD, &nbytes);

The FIONREAD operation is not specified in any standard, but is provided on many implementations.

/proc files

On Linux, the following files control how much memory can be used for pipes:

/proc/sys/fs/pipe-max-pages (only in Linux 2.6.34)
An upper limit, in pages, on the capacity that an unprivileged user (one without the CAP_SYS_RESOURCE capability) can set for a pipe.

The default value for this limit is 16 times the default pipe capacity (see above); the lower limit is two pages.

This interface was removed in Linux 2.6.35, in favor of /proc/sys/fs/pipe-max-size.

/proc/sys/fs/pipe-max-size (since Linux 2.6.35)
The maximum size (in bytes) of individual pipes that can be set by users without the CAP_SYS_RESOURCE capability. The value assigned to this file may be rounded upward, to reflect the value actually employed for a convenient implementation. To determine the rounded-up value, display the contents of this file after assigning a value to it.

The default value for this file is 1048576 (1 MiB). The minimum value that can be assigned to this file is the system page size. Attempts to set a limit less than the page size cause write(2) to fail with the error EINVAL.

Since Linux 4.9, the value on this file also acts as a ceiling on the default capacity of a new pipe or newly opened FIFO.

/proc/sys/fs/pipe-user-pages-hard (since Linux 4.5)
The hard limit on the total size (in pages) of all pipes created or set by a single unprivileged user (i.e., one with neither the CAP_SYS_RESOURCE nor the CAP_SYS_ADMIN capability). So long as the total number of pages allocated to pipe buffers for this user is at this limit, attempts to create new pipes will be denied, and attempts to increase a pipe’s capacity will be denied.

When the value of this limit is zero (which is the default), no hard limit is applied.

/proc/sys/fs/pipe-user-pages-soft (since Linux 4.5)
The soft limit on the total size (in pages) of all pipes created or set by a single unprivileged user (i.e., one with neither the CAP_SYS_RESOURCE nor the CAP_SYS_ADMIN capability). So long as the total number of pages allocated to pipe buffers for this user is at this limit, individual pipes created by a user will be limited to one page, and attempts to increase a pipe’s capacity will be denied.

When the value of this limit is zero, no soft limit is applied. The default value for this file is 16384, which permits creating up to 1024 pipes with the default capacity.

Before Linux 4.9, some bugs affected the handling of the pipe-user-pages-soft and pipe-user-pages-hard limits; see BUGS.

PIPE_BUF

POSIX.1 says that writes of less than PIPE_BUF bytes must be atomic: the output data is written to the pipe as a contiguous sequence. Writes of more than PIPE_BUF bytes may be nonatomic: the kernel may interleave the data with data written by other processes. POSIX.1 requires PIPE_BUF to be at least 512 bytes. (On Linux, PIPE_BUF is 4096 bytes.) The precise semantics depend on whether the file descriptor is nonblocking (O_NONBLOCK), whether there are multiple writers to the pipe, and on n, the number of bytes to be written:

O_NONBLOCK disabled, n <= PIPE_BUF
All n bytes are written atomically; write(2) may block if there is not room for n bytes to be written immediately

O_NONBLOCK enabled, n <= PIPE_BUF
If there is room to write n bytes to the pipe, then write(2) succeeds immediately, writing all n bytes; otherwise write(2) fails, with errno set to EAGAIN.

O_NONBLOCK disabled, n > PIPE_BUF
The write is nonatomic: the data given to write(2) may be interleaved with write(2)s by other process; the write(2) blocks until n bytes have been written.

O_NONBLOCK enabled, n > PIPE_BUF
If the pipe is full, then write(2) fails, with errno set to EAGAIN. Otherwise, from 1 to n bytes may be written (i.e., a “partial write” may occur; the caller should check the return value from write(2) to see how many bytes were actually written), and these bytes may be interleaved with writes by other processes.

Open file status flags

The only open file status flags that can be meaningfully applied to a pipe or FIFO are O_NONBLOCK and O_ASYNC.

Setting the O_ASYNC flag for the read end of a pipe causes a signal (SIGIO by default) to be generated when new input becomes available on the pipe. The target for delivery of signals must be set using the fcntl(2) F_SETOWN command. On Linux, O_ASYNC is supported for pipes and FIFOs only since Linux 2.6.

Portability notes

On some systems (but not Linux), pipes are bidirectional: data can be transmitted in both directions between the pipe ends. POSIX.1 requires only unidirectional pipes. Portable applications should avoid reliance on bidirectional pipe semantics.

BUGS

Before Linux 4.9, some bugs affected the handling of the pipe-user-pages-soft and pipe-user-pages-hard limits when using the fcntl(2) F_SETPIPE_SZ operation to change a pipe’s capacity:

  1. When increasing the pipe capacity, the checks against the soft and hard limits were made against existing consumption, and excluded the memory required for the increased pipe capacity. The new increase in pipe capacity could then push the total memory used by the user for pipes (possibly far) over a limit. (This could also trigger the problem described next.)

    Starting with Linux 4.9, the limit checking includes the memory required for the new pipe capacity.

  2. The limit checks were performed even when the new pipe capacity was less than the existing pipe capacity. This could lead to problems if a user set a large pipe capacity, and then the limits were lowered, with the result that the user could no longer decrease the pipe capacity.

    Starting with Linux 4.9, checks against the limits are performed only when increasing a pipe’s capacity; an unprivileged user can always decrease a pipe’s capacity.

  3. The accounting and checking against the limits were done as follows:

Test whether the user has exceeded the limit.

1.  Make the new pipe buffer allocation.

2.  Account new allocation against the limits.

This was racey. Multiple processes could pass point (1) simultaneously, and then allocate pipe buffers that were accounted for only in step (3), with the result that the user's pipe buffer allocation could be pushed over the limit.

Starting with Linux 4.9, the accounting step is performed before doing the allocation, and the operation fails if the limit would be exceeded.

Before Linux 4.9, bugs similar to points (a) and (c) could also occur when the kernel allocated memory for a new pipe buffer; that is, when calling pipe(2) and when opening a previously unopened FIFO.

SEE ALSO

mkfifo(1), dup(2), fcntl(2), open(2), pipe(2), poll(2), select(2), socketpair(2), splice(2), stat(2), tee(2), vmsplice(2), mkfifo(3), epoll(7), fifo(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

608 - Linux cli command EVP_MD-KECCAKssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_MD-KECCAKssl and provides detailed information about the command EVP_MD-KECCAKssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_MD-KECCAKssl.

NAME 🖥️ EVP_MD-KECCAKssl 🖥️

KECCAK - The KECCAK EVP_MD implementations

DESCRIPTION

Support for computing KECCAK digests through the EVP_MD API.

Identities

This implementation is available in the default provider and includes the following varieties:

“KECCAK-224”

“KECCAK-256”

“KECCAK-384”

“KECCAK-512”

Gettable Parameters

This implementation supports the common gettable parameters described in EVP_MD-common (7).

SEE ALSO

provider-digest (7), OSSL_PROVIDER-default (7)

COPYRIGHT

Copyright 2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

609 - Linux cli command LOAD

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command LOAD and provides detailed information about the command LOAD, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the LOAD.

NAME 🖥️ LOAD 🖥️

load a shared library file

SYNOPSIS

LOAD filename

DESCRIPTION

This command loads a shared library file into the PostgreSQL servers address space. If the file has been loaded already, the command does nothing. Shared library files that contain C functions are automatically loaded whenever one of their functions is called. Therefore, an explicit LOAD is usually only needed to load a library that modifies the servers behavior through “hooks” rather than providing a set of functions.

The library file name is typically given as just a bare file name, which is sought in the servers library search path (set by dynamic_library_path). Alternatively it can be given as a full path name. In either case the platforms standard shared library file name extension may be omitted. See Section 38.10.1 for more information on this topic.

Non-superusers can only apply LOAD to library files located in $libdir/plugins/ — the specified filename must begin with exactly that string. (It is the database administrators responsibility to ensure that only “safe” libraries are installed there.)

COMPATIBILITY

LOAD is a PostgreSQL extension.

SEE ALSO

CREATE FUNCTION (CREATE_FUNCTION(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

610 - Linux cli command vdso

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command vdso and provides detailed information about the command vdso, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the vdso.

NAME 🖥️ vdso 🖥️

overview of the virtual ELF dynamic shared object

SYNOPSIS

#include <sys/auxv.h>
void *vdso = (uintptr_t) getauxval(AT_SYSINFO_EHDR);

DESCRIPTION

The “vDSO” (virtual dynamic shared object) is a small shared library that the kernel automatically maps into the address space of all user-space applications. Applications usually do not need to concern themselves with these details as the vDSO is most commonly called by the C library. This way you can code in the normal way using standard functions and the C library will take care of using any functionality that is available via the vDSO.

Why does the vDSO exist at all? There are some system calls the kernel provides that user-space code ends up using frequently, to the point that such calls can dominate overall performance. This is due both to the frequency of the call as well as the context-switch overhead that results from exiting user space and entering the kernel.

The rest of this documentation is geared toward the curious and/or C library writers rather than general developers. If you’re trying to call the vDSO in your own application rather than using the C library, you’re most likely doing it wrong.

Example background

Making system calls can be slow. In x86 32-bit systems, you can trigger a software interrupt (int $0x80) to tell the kernel you wish to make a system call. However, this instruction is expensive: it goes through the full interrupt-handling paths in the processor’s microcode as well as in the kernel. Newer processors have faster (but backward incompatible) instructions to initiate system calls. Rather than require the C library to figure out if this functionality is available at run time, the C library can use functions provided by the kernel in the vDSO.

Note that the terminology can be confusing. On x86 systems, the vDSO function used to determine the preferred method of making a system call is named “__kernel_vsyscall”, but on x86-64, the term “vsyscall” also refers to an obsolete way to ask the kernel what time it is or what CPU the caller is on.

One frequently used system call is gettimeofday(2). This system call is called both directly by user-space applications as well as indirectly by the C library. Think timestamps or timing loops or polling—all of these frequently need to know what time it is right now. This information is also not secret—any application in any privilege mode (root or any unprivileged user) will get the same answer. Thus the kernel arranges for the information required to answer this question to be placed in memory the process can access. Now a call to gettimeofday(2) changes from a system call to a normal function call and a few memory accesses.

Finding the vDSO

The base address of the vDSO (if one exists) is passed by the kernel to each program in the initial auxiliary vector (see getauxval(3)), via the AT_SYSINFO_EHDR tag.

You must not assume the vDSO is mapped at any particular location in the user’s memory map. The base address will usually be randomized at run time every time a new process image is created (at execve(2) time). This is done for security reasons, to prevent “return-to-libc” attacks.

For some architectures, there is also an AT_SYSINFO tag. This is used only for locating the vsyscall entry point and is frequently omitted or set to 0 (meaning it’s not available). This tag is a throwback to the initial vDSO work (see History below) and its use should be avoided.

File format

Since the vDSO is a fully formed ELF image, you can do symbol lookups on it. This allows new symbols to be added with newer kernel releases, and allows the C library to detect available functionality at run time when running under different kernel versions. Oftentimes the C library will do detection with the first call and then cache the result for subsequent calls.

All symbols are also versioned (using the GNU version format). This allows the kernel to update the function signature without breaking backward compatibility. This means changing the arguments that the function accepts as well as the return value. Thus, when looking up a symbol in the vDSO, you must always include the version to match the ABI you expect.

Typically the vDSO follows the naming convention of prefixing all symbols with “__vdso_” or “__kernel_” so as to distinguish them from other standard symbols. For example, the “gettimeofday” function is named “__vdso_gettimeofday”.

You use the standard C calling conventions when calling any of these functions. No need to worry about weird register or stack behavior.

NOTES

Source

When you compile the kernel, it will automatically compile and link the vDSO code for you. You will frequently find it under the architecture-specific directory:

find arch/$ARCH/ -name '*vdso*.so*' -o -name '*gate*.so*'

vDSO names

The name of the vDSO varies across architectures. It will often show up in things like glibc’s ldd(1) output. The exact name should not matter to any code, so do not hardcode it.

user ABIvDSO name
aarch64linux-vdso.so.1
armlinux-vdso.so.1
ia64linux-gate.so.1
mipslinux-vdso.so.1
ppc/32linux-vdso32.so.1
ppc/64linux-vdso64.so.1
riscvlinux-vdso.so.1
s390linux-vdso32.so.1
s390xlinux-vdso64.so.1
shlinux-gate.so.1
i386linux-gate.so.1
x86-64linux-vdso.so.1
x86/x32linux-vdso.so.1

strace(1), seccomp(2), and the vDSO

When tracing system calls with strace(1), symbols (system calls) that are exported by the vDSO will not appear in the trace output. Those system calls will likewise not be visible to seccomp(2) filters.

ARCHITECTURE-SPECIFIC NOTES

The subsections below provide architecture-specific notes on the vDSO.

Note that the vDSO that is used is based on the ABI of your user-space code and not the ABI of the kernel. Thus, for example, when you run an i386 32-bit ELF binary, you’ll get the same vDSO regardless of whether you run it under an i386 32-bit kernel or under an x86-64 64-bit kernel. Therefore, the name of the user-space ABI should be used to determine which of the sections below is relevant.

ARM functions

The table below lists the symbols exported by the vDSO.

symbolversion
__vdso_gettimeofdayLINUX_2.6 (exported since Linux 4.1)
__vdso_clock_gettimeLINUX_2.6 (exported since Linux 4.1)

Additionally, the ARM port has a code page full of utility functions. Since it’s just a raw page of code, there is no ELF information for doing symbol lookups or versioning. It does provide support for different versions though.

For information on this code page, it’s best to refer to the kernel documentation as it’s extremely detailed and covers everything you need to know: Documentation/arm/kernel_user_helpers.rst.

aarch64 functions

The table below lists the symbols exported by the vDSO.

symbolversion
__kernel_rt_sigreturnLINUX_2.6.39
__kernel_gettimeofdayLINUX_2.6.39
__kernel_clock_gettimeLINUX_2.6.39
__kernel_clock_getresLINUX_2.6.39

bfin (Blackfin) functions (port removed in Linux 4.17)

As this CPU lacks a memory management unit (MMU), it doesn’t set up a vDSO in the normal sense. Instead, it maps at boot time a few raw functions into a fixed location in memory. User-space applications then call directly into that region. There is no provision for backward compatibility beyond sniffing raw opcodes, but as this is an embedded CPU, it can get away with things—some of the object formats it runs aren’t even ELF based (they’re bFLT/FLAT).

For information on this code page, it’s best to refer to the public documentation:
http://docs.blackfin.uclinux.org/doku.php?id=linux-kernel:fixed-code

mips functions

The table below lists the symbols exported by the vDSO.

symbolversion
__kernel_gettimeofdayLINUX_2.6 (exported since Linux 4.4)
__kernel_clock_gettimeLINUX_2.6 (exported since Linux 4.4)

ia64 (Itanium) functions

The table below lists the symbols exported by the vDSO.

symbolversion
__kernel_sigtrampLINUX_2.5
__kernel_syscall_via_breakLINUX_2.5
__kernel_syscall_via_epcLINUX_2.5

The Itanium port is somewhat tricky. In addition to the vDSO above, it also has “light-weight system calls” (also known as “fast syscalls” or “fsys”). You can invoke these via the __kernel_syscall_via_epc vDSO helper. The system calls listed here have the same semantics as if you called them directly via syscall(2), so refer to the relevant documentation for each. The table below lists the functions available via this mechanism.

function
_
clock_gettime
getcpu
getpid
getppid
gettimeofday
set_tid_address

parisc (hppa) functions

The parisc port has a code page with utility functions called a gateway page. Rather than use the normal ELF auxiliary vector approach, it passes the address of the page to the process via the SR2 register. The permissions on the page are such that merely executing those addresses automatically executes with kernel privileges and not in user space. This is done to match the way HP-UX works.

Since it’s just a raw page of code, there is no ELF information for doing symbol lookups or versioning. Simply call into the appropriate offset via the branch instruction, for example:

ble <offset>(%sr2, %r0)
offsetfunction
00b0lws_entry (CAS operations)
00e0set_thread_pointer (used by glibc)
0100linux_gateway_entry (syscall)

ppc/32 functions

The table below lists the symbols exported by the vDSO. The functions marked with a * are available only when the kernel is a PowerPC64 (64-bit) kernel.

symbolversion
__kernel_clock_getresLINUX_2.6.15
__kernel_clock_gettimeLINUX_2.6.15
__kernel_clock_gettime64LINUX_5.11
__kernel_datapage_offsetLINUX_2.6.15
__kernel_get_syscall_mapLINUX_2.6.15
__kernel_get_tbfreqLINUX_2.6.15
__kernel_getcpu *LINUX_2.6.15
__kernel_gettimeofdayLINUX_2.6.15
__kernel_sigtramp_rt32LINUX_2.6.15
__kernel_sigtramp32LINUX_2.6.15
__kernel_sync_dicacheLINUX_2.6.15
__kernel_sync_dicache_p5LINUX_2.6.15

Before Linux 5.6, the CLOCK_REALTIME_COARSE and CLOCK_MONOTONIC_COARSE clocks are not supported by the __kernel_clock_getres and __kernel_clock_gettime interfaces; the kernel falls back to the real system call.

ppc/64 functions

The table below lists the symbols exported by the vDSO.

symbolversion
__kernel_clock_getresLINUX_2.6.15
__kernel_clock_gettimeLINUX_2.6.15
__kernel_datapage_offsetLINUX_2.6.15
__kernel_get_syscall_mapLINUX_2.6.15
__kernel_get_tbfreqLINUX_2.6.15
__kernel_getcpuLINUX_2.6.15
__kernel_gettimeofdayLINUX_2.6.15
__kernel_sigtramp_rt64LINUX_2.6.15
__kernel_sync_dicacheLINUX_2.6.15
__kernel_sync_dicache_p5LINUX_2.6.15

Before Linux 4.16, the CLOCK_REALTIME_COARSE and CLOCK_MONOTONIC_COARSE clocks are not supported by the __kernel_clock_getres and __kernel_clock_gettime interfaces; the kernel falls back to the real system call.

riscv functions

The table below lists the symbols exported by the vDSO.

symbolversion
__vdso_rt_sigreturnLINUX_4.15
__vdso_gettimeofdayLINUX_4.15
__vdso_clock_gettimeLINUX_4.15
__vdso_clock_getresLINUX_4.15
__vdso_getcpuLINUX_4.15
__vdso_flush_icacheLINUX_4.15

s390 functions

The table below lists the symbols exported by the vDSO.

symbolversion
__kernel_clock_getresLINUX_2.6.29
__kernel_clock_gettimeLINUX_2.6.29
__kernel_gettimeofdayLINUX_2.6.29

s390x functions

The table below lists the symbols exported by the vDSO.

symbolversion
__kernel_clock_getresLINUX_2.6.29
__kernel_clock_gettimeLINUX_2.6.29
__kernel_gettimeofdayLINUX_2.6.29

sh (SuperH) functions

The table below lists the symbols exported by the vDSO.

symbolversion
__kernel_rt_sigreturnLINUX_2.6
__kernel_sigreturnLINUX_2.6
__kernel_vsyscallLINUX_2.6

i386 functions

The table below lists the symbols exported by the vDSO.

symbolversion
__kernel_sigreturnLINUX_2.5
__kernel_rt_sigreturnLINUX_2.5
__kernel_vsyscallLINUX_2.5
__vdso_clock_gettimeLINUX_2.6 (exported since Linux 3.15)
__vdso_gettimeofdayLINUX_2.6 (exported since Linux 3.15)
__vdso_timeLINUX_2.6 (exported since Linux 3.15)

x86-64 functions

The table below lists the symbols exported by the vDSO. All of these symbols are also available without the “__vdso_” prefix, but you should ignore those and stick to the names below.

symbolversion
__vdso_clock_gettimeLINUX_2.6
__vdso_getcpuLINUX_2.6
__vdso_gettimeofdayLINUX_2.6
__vdso_timeLINUX_2.6

x86/x32 functions

The table below lists the symbols exported by the vDSO.

symbolversion
__vdso_clock_gettimeLINUX_2.6
__vdso_getcpuLINUX_2.6
__vdso_gettimeofdayLINUX_2.6
__vdso_timeLINUX_2.6

History

The vDSO was originally just a single function—the vsyscall. In older kernels, you might see that name in a process’s memory map rather than “vdso”. Over time, people realized that this mechanism was a great way to pass more functionality to user space, so it was reconceived as a vDSO in the current format.

SEE ALSO

syscalls(2), getauxval(3), proc(5)

The documents, examples, and source code in the Linux source code tree:

Documentation/ABI/stable/vdso
Documentation/ia64/fsys.rst
Documentation/vDSO/* (includes examples of using the vDSO)
find arch/ -iname '*vdso*' -o -iname '*gate*'

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

611 - Linux cli command math_error

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command math_error and provides detailed information about the command math_error, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the math_error.

NAME 🖥️ math_error 🖥️

detecting errors from mathematical functions

SYNOPSIS

#include <math.h>
#include <errno.h>
#include <fenv.h>

DESCRIPTION

When an error occurs, most library functions indicate this fact by returning a special value (e.g., -1 or NULL). Because they typically return a floating-point number, the mathematical functions declared in <math.h> indicate an error using other mechanisms. There are two error-reporting mechanisms: the older one sets errno; the newer one uses the floating-point exception mechanism (the use of feclearexcept(3) and fetestexcept(3), as outlined below) described in fenv(3).

A portable program that needs to check for an error from a mathematical function should set errno to zero, and make the following call

feclearexcept(FE_ALL_EXCEPT);

before calling a mathematical function.

Upon return from the mathematical function, if errno is nonzero, or the following call (see fenv(3)) returns nonzero

fetestexcept(FE_INVALID | FE_DIVBYZERO | FE_OVERFLOW |
             FE_UNDERFLOW);

then an error occurred in the mathematical function.

The error conditions that can occur for mathematical functions are described below.

Domain error

A domain error occurs when a mathematical function is supplied with an argument whose value falls outside the domain for which the function is defined (e.g., giving a negative argument to log(3)). When a domain error occurs, math functions commonly return a NaN (though some functions return a different value in this case); errno is set to EDOM, and an “invalid” (FE_INVALID) floating-point exception is raised.

Pole error

A pole error occurs when the mathematical result of a function is an exact infinity (e.g., the logarithm of 0 is negative infinity). When a pole error occurs, the function returns the (signed) value HUGE_VAL, HUGE_VALF, or HUGE_VALL, depending on whether the function result type is double, float, or long double. The sign of the result is that which is mathematically correct for the function. errno is set to ERANGE, and a “divide-by-zero” (FE_DIVBYZERO) floating-point exception is raised.

Range error

A range error occurs when the magnitude of the function result means that it cannot be represented in the result type of the function. The return value of the function depends on whether the range error was an overflow or an underflow.

A floating result overflows if the result is finite, but is too large to represented in the result type. When an overflow occurs, the function returns the value HUGE_VAL, HUGE_VALF, or HUGE_VALL, depending on whether the function result type is double, float, or long double. errno is set to ERANGE, and an “overflow” (FE_OVERFLOW) floating-point exception is raised.

A floating result underflows if the result is too small to be represented in the result type. If an underflow occurs, a mathematical function typically returns 0.0 (C99 says a function shall return “an implementation-defined value whose magnitude is no greater than the smallest normalized positive number in the specified type”). errno may be set to ERANGE, and an “underflow” (FE_UNDERFLOW) floating-point exception may be raised.

Some functions deliver a range error if the supplied argument value, or the correct function result, would be subnormal. A subnormal value is one that is nonzero, but with a magnitude that is so small that it can’t be presented in normalized form (i.e., with a 1 in the most significant bit of the significand). The representation of a subnormal number will contain one or more leading zeros in the significand.

NOTES

The math_errhandling identifier specified by C99 and POSIX.1 is not supported by glibc. This identifier is supposed to indicate which of the two error-notification mechanisms (errno, exceptions retrievable via fetestexcept(3)) is in use. The standards require that at least one be in use, but permit both to be available. The current (glibc 2.8) situation under glibc is messy. Most (but not all) functions raise exceptions on errors. Some also set errno. A few functions set errno, but don’t raise an exception. A very few functions do neither. See the individual manual pages for details.

To avoid the complexities of using errno and fetestexcept(3) for error checking, it is often advised that one should instead check for bad argument values before each call. For example, the following code ensures that log(3)’s argument is not a NaN and is not zero (a pole error) or less than zero (a domain error):

double x, r;
if (isnan(x) || islessequal(x, 0)) {
    /* Deal with NaN / pole error / domain error */
}
r = log(x);

The discussion on this page does not apply to the complex mathematical functions (i.e., those declared by <complex.h>), which in general are not required to return errors by C99 and POSIX.1.

The gcc(1) -fno-math-errno option causes the executable to employ implementations of some mathematical functions that are faster than the standard implementations, but do not set errno on error. (The gcc(1) -ffast-math option also enables -fno-math-errno.) An error can still be tested for using fetestexcept(3).

SEE ALSO

gcc(1), errno(3), fenv(3), fpclassify(3), INFINITY(3), isgreater(3), matherr(3), nan(3)

info libc

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

612 - Linux cli command CREATE_FOREIGN_DATA_WRAPPER

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_FOREIGN_DATA_WRAPPER and provides detailed information about the command CREATE_FOREIGN_DATA_WRAPPER, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_FOREIGN_DATA_WRAPPER.

NAME 🖥️ CREATE_FOREIGN_DATA_WRAPPER 🖥️

define a new foreign-data wrapper

SYNOPSIS

CREATE FOREIGN DATA WRAPPER name
    [ HANDLER handler_function | NO HANDLER ]
    [ VALIDATOR validator_function | NO VALIDATOR ]
    [ OPTIONS ( option value [, ... ] ) ]

DESCRIPTION

CREATE FOREIGN DATA WRAPPER creates a new foreign-data wrapper. The user who defines a foreign-data wrapper becomes its owner.

The foreign-data wrapper name must be unique within the database.

Only superusers can create foreign-data wrappers.

PARAMETERS

name

The name of the foreign-data wrapper to be created.

HANDLER handler_function

handler_function is the name of a previously registered function that will be called to retrieve the execution functions for foreign tables. The handler function must take no arguments, and its return type must be fdw_handler.

It is possible to create a foreign-data wrapper with no handler function, but foreign tables using such a wrapper can only be declared, not accessed.

VALIDATOR validator_function

validator_function is the name of a previously registered function that will be called to check the generic options given to the foreign-data wrapper, as well as options for foreign servers, user mappings and foreign tables using the foreign-data wrapper. If no validator function or NO VALIDATOR is specified, then options will not be checked at creation time. (Foreign-data wrappers will possibly ignore or reject invalid option specifications at run time, depending on the implementation.) The validator function must take two arguments: one of type text[], which will contain the array of options as stored in the system catalogs, and one of type oid, which will be the OID of the system catalog containing the options. The return type is ignored; the function should report invalid options using the ereport(ERROR) function.

OPTIONS ( option value [, … ] )

This clause specifies options for the new foreign-data wrapper. The allowed option names and values are specific to each foreign data wrapper and are validated using the foreign-data wrappers validator function. Option names must be unique.

NOTES

PostgreSQLs foreign-data functionality is still under active development. Optimization of queries is primitive (and mostly left to the wrapper, too). Thus, there is considerable room for future performance improvements.

EXAMPLES

Create a useless foreign-data wrapper dummy:

CREATE FOREIGN DATA WRAPPER dummy;

Create a foreign-data wrapper file with handler function file_fdw_handler:

CREATE FOREIGN DATA WRAPPER file HANDLER file_fdw_handler;

Create a foreign-data wrapper mywrapper with some options:

CREATE FOREIGN DATA WRAPPER mywrapper OPTIONS (debug true);

COMPATIBILITY

CREATE FOREIGN DATA WRAPPER conforms to ISO/IEC 9075-9 (SQL/MED), with the exception that the HANDLER and VALIDATOR clauses are extensions and the standard clauses LIBRARY and LANGUAGE are not implemented in PostgreSQL.

Note, however, that the SQL/MED functionality as a whole is not yet conforming.

SEE ALSO

ALTER FOREIGN DATA WRAPPER (ALTER_FOREIGN_DATA_WRAPPER(7)), DROP FOREIGN DATA WRAPPER (DROP_FOREIGN_DATA_WRAPPER(7)), CREATE SERVER (CREATE_SERVER(7)), CREATE USER MAPPING (CREATE_USER_MAPPING(7)), CREATE FOREIGN TABLE (CREATE_FOREIGN_TABLE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

613 - Linux cli command dpkg-build-api

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command dpkg-build-api and provides detailed information about the command dpkg-build-api, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the dpkg-build-api.

NAME 🖥️ dpkg-build-api 🖥️

build-api - source package dpkg build API level

SYNOPSIS

Build-Depends: dpkg-build-api (= 1),

DESCRIPTION

The source package dpkg build API level, defines a versioned interface for source packages, where each API level provides specific behaviors and guarantees.

These interfaces can then be adopted by packages in a gradual way, and phased out more easily than with global behavior changes.

The declaration of this API level is done through build-dependencies, in one of Build-Depends, Build-Depends-Indep or Build-Depends-Arch, or via the environment variable DPKG_BUILD_API, which will override these if both are present, and might emit a warning in case they are different.

API LEVELS

v2
This level is still under development, and cannot be declared via build-dependencies.

v1
This is the recommended level. Since dpkg 1.22.0. Changes from v0 are:

  • dpkg-shlibdeps no longer uses the LD_LIBRARY_PATH environment variable. The -l option should be used instead.

  • dpkg-buildpackage defaults to Rules-Requires-Root value no. To restore the v0 behavior Rules-Requires-Root should be set to binary-targets.

  • dpkg-buildpackage expects all required debian/rules targets to be supported and no longer has backwards compatibility fallback code. The required targets are clean, build, build-indep, build-arch, binary-indep and binary-arch.

  • vendor.mk defaults to using dpkg_vendor_derives_from_v1 for the dpkg_vendor_derives_from macro. To restore the v0 behavior set dpkg_vendor_derives_from to dpkg_vendor_derives_from_v0.

  • default.mk defaults to including buildtools.mk.

v0
This is the current global level, equivalent to not specifying one. The interfaces and behaviors provided are subject to the normal global interface updates, which tend to require longer deprecation cycles and/or coordinated transitions.

SEE ALSO

deb-src-control (5).

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

614 - Linux cli command openssl-quicssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command openssl-quicssl and provides detailed information about the command openssl-quicssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the openssl-quicssl.

NAME 🖥️ openssl-quicssl 🖥️

quic - OpenSSL QUIC

DESCRIPTION

OpenSSL 3.2 and later features support for the QUIC transport protocol. Currently, only client connectivity is supported. This man page describes the usage of QUIC client functionality for both existing and new applications.

QUIC functionality uses the standard SSL API. A QUIC connection is represented by an SSL object in the same way that a TLS connection is. Only minimal changes are needed to existing applications making use of the libssl APIs to make use of QUIC client functionality. To make use of QUIC, use the SSL method OSSL_QUIC_client_method (3) or OSSL_QUIC_client_thread_method (3) with SSL_CTX_new (3).

When a QUIC connection is created, by default, it operates in default stream mode, which is intended to provide compatibility with existing non-QUIC application usage patterns. In this mode, the connection has a single stream associated with it. Calls to SSL_read (3) and SSL_write (3) on the QUIC connection SSL object read and write from that stream. Whether the stream is client-initiated or server-initiated from a QUIC perspective depends on whether SSL_read (3) or SSL_write (3) is called first. See the MODES OF OPERATION section for more information.

The default stream mode is intended for compatibility with existing applications. New applications using QUIC are recommended to disable default stream mode and use the multi-stream API; see the MODES OF OPERATION section and the RECOMMENDATIONS FOR NEW APPLICATIONS section for more information.

The remainder of this man page discusses, in order:

  • Default stream mode versus multi-stream mode;

  • The changes to existing libssl APIs which are driven by QUIC-related implementation requirements, which existing applications should bear in mind;

  • Aspects which must be considered by existing applications when adopting QUIC, including potential changes which may be needed.

  • Recommended usage approaches for new applications.

  • New, QUIC-specific APIs.

MODES OF OPERATION

Default Stream Mode

A QUIC client connection can be used in either default stream mode or multi-stream mode. By default, a newly created QUIC connection SSL object uses default stream mode.

In default stream mode, a stream is implicitly created and bound to the QUIC connection SSL object; SSL_read (3) and SSL_write (3) calls to the QUIC connection SSL object work by default and are mapped to that stream.

When default stream mode is used, any API function which can be called on a QUIC stream SSL object can also be called on a QUIC connection SSL object, in which case it affects the default stream bound to the connection.

The identity of a QUIC stream, including its stream ID, varies depending on whether a stream is client-initiated or server-initiated. In default stream mode, if a client application calls SSL_read (3) first before any call to SSL_write (3) on the connection, it is assumed that the application protocol is using a server-initiated stream, and the SSL_read (3) call will not complete (either blocking, or failing appropriately if nonblocking mode is configured) until the server initiates a stream. Conversely, if the client application calls SSL_write (3) before any call to SSL_read (3) on the connection, it is assumed that a client-initiated stream is to be used and such a stream is created automatically.

Default stream mode is intended to aid compatibility with legacy applications. New applications adopting QUIC should use multi-stream mode, described below, and avoid use of the default stream functionality.

It is possible to use additional streams in default stream mode using SSL_new_stream (3) and SSL_accept_stream (3); note that the default incoming stream policy will need to be changed using SSL_set_incoming_stream_policy (3) in order to use SSL_accept_stream (3) in this case. However, applications using additional streams are strongly recommended to use multi-stream mode instead.

Calling SSL_new_stream (3) or SSL_accept_stream (3) before a default stream has been associated with the QUIC connection SSL object will inhibit future creation of a default stream.

Multi-Stream Mode

The recommended usage mode for new applications adopting QUIC is multi-stream mode, in which no default stream is attached to the QUIC connection SSL object and attempts to call SSL_read (3) and SSL_write (3) on the QUIC connection SSL object fail. Instead, an application calls SSL_new_stream (3) or SSL_accept_stream (3) to create individual stream SSL objects for sending and receiving application data using SSL_read (3) and SSL_write (3).

To use multi-stream mode, call SSL_set_default_stream_mode (3) with an argument of SSL_DEFAULT_STREAM_MODE_NONE; this function must be called prior to initiating the connection. The default stream mode cannot be changed after initiating a connection.

When multi-stream mode is used, meaning that no default stream is associated with the connection, calls to API functions which are defined as operating on a QUIC stream fail if called on the QUIC connection SSL object. For example, calls such as SSL_write (3) or SSL_get_stream_id (3) will fail.

CHANGES TO EXISTING APIS

Most SSL APIs, such as SSL_read (3) and SSL_write (3), function as they do for TLS connections and do not have changed semantics, with some exceptions. The changes to the semantics of existing APIs are as follows:

  • Since QUIC uses UDP, SSL_set_bio (3), SSL_set0_rbio (3) and SSL_set0_wbio (3) function as before, but must now receive a BIO with datagram semantics. There are broadly four options for applications to use as a network BIO:

    • BIO_s_datagram (3), recommended for most applications, replaces BIO_s_socket (3) and provides a UDP socket.

    • BIO_s_dgram_pair (3) provides BIO pair-like functionality but with datagram semantics, and is recommended for existing applications which use a BIO pair or memory BIO to manage libssl’s communication with the network.

    • BIO_s_dgram_mem (3) provides a simple memory BIO-like interface but with datagram semantics. Unlike BIO_s_dgram_pair (3), it is unidirectional.

    • An application may also choose to implement a custom BIO. The new BIO_sendmmsg (3) and BIO_recvmmsg (3) APIs must be supported.

  • SSL_set_fd (3), SSL_set_rfd (3) and SSL_set_wfd (3) traditionally instantiate a BIO_s_socket (3). For QUIC, these functions instead instantiate a BIO_s_datagram (3). This is equivalent to instantiating a BIO_s_datagram (3) and using SSL_set0_rbio (3) and SSL_set0_wbio (3).

  • Traditionally, whether the application-level I/O APIs (such as SSL_read (3) and SSL_write (3) operated in a blocking fashion was directly correlated with whether the underlying network socket was configured in a blocking fashion. This is no longer the case; applications must explicitly configure the desired application-level blocking mode using SSL_set_blocking_mode (3). See SSL_set_blocking_mode (3) for details.

  • Network-level I/O must always be performed in a nonblocking manner. The application can still enjoy blocking semantics for calls to application-level I/O functions such as SSL_read (3) and SSL_write (3), but the underlying network BIO provided to QUIC (such as a BIO_s_datagram (3)) must be configured in nonblocking mode. For application-level blocking functionality, see SSL_set_blocking_mode (3).

  • BIO_new_ssl_connect (3) has been changed to automatically use a BIO_s_datagram (3) when used with QUIC, therefore applications which use this do not need to change the BIO they use.

  • BIO_new_buffer_ssl_connect (3) cannot be used with QUIC and applications must change to use BIO_new_ssl_connect (3) instead.

  • SSL_shutdown (3) has significant changes in relation to how QUIC connections must be shut down. In particular, applications should be advised that the full RFC-conformant QUIC shutdown process may take an extended amount of time. This may not be suitable for short-lived processes which should exit immediately after their usage of a QUIC connection is completed. A rapid shutdown mode is available for such applications. For details, see SSL_shutdown (3).

  • SSL_want (3), SSL_want_read (3) and SSL_want_write (3) no longer reflect the I/O state of the network BIO passed to the QUIC SSL object, but instead reflect the flow control state of the QUIC stream associated with the SSL object. When used in nonblocking mode, SSL_ERROR_WANT_READ indicates that the receive part of a QUIC stream does not currently have any more data available to be read, and SSL_ERROR_WANT_WRITE indicates that the stream’s internal buffer is full. To determine if the QUIC implementation currently wishes to be informed of incoming network datagrams, use the new function SSL_net_read_desired (3); likewise, to determine if the QUIC implementation currently wishes to be informed when it is possible to transmit network datagrams, use the new function SSL_net_write_desired (3). Only applications which wish to manage their own event loops need to use these functions; see APPLICATION-DRIVEN EVENT LOOPS for further discussion.

  • The use of ALPN is mandatory when using QUIC. Attempts to connect without configuring ALPN will fail. For information on how to configure ALPN, see SSL_set_alpn_protos (3).

  • Whether QUIC operates in a client or server mode is determined by the SSL_METHOD used, rather than by calls to SSL_set_connect_state (3) or SSL_set_accept_state (3). It is not necessary to call either of SSL_set_connect_state (3) or SSL_set_accept_state (3) before connecting, but if either of these are called, the function called must be congruent with the SSL_METHOD being used. Currently, only client mode is supported.

  • The SSL_set_min_proto_version (3) and SSL_set_max_proto_version (3) APIs are not used and the values passed to them are ignored, as OpenSSL QUIC currently always uses TLS 1.3.

  • The following libssl functionality is not available when used with QUIC.

    • Async functionality

    • SSL_MODE_AUTO_RETRY

    • Record Padding and Fragmentation (SSL_set_block_padding (3), etc.)

    • SSL_stateless (3) support

    • SRTP functionality

    • TLSv1.3 Early Data

    • TLS Next Protocol Negotiation cannot be used and is superseded by ALPN, which must be used instead. The use of ALPN is mandatory with QUIC.

    • Post-Handshake Client Authentication is not available as QUIC prohibits its use.

    • QUIC requires the use of TLSv1.3 or later, therefore functionality only relevant to older TLS versions is not available.

    • Some cipher suites which are generally available for TLSv1.3 are not available for QUIC, such as TLS_AES_128_CCM_8_SHA256. Your application may need to adjust the list of acceptable cipher suites it passes to libssl.

    • CCM mode is not currently supported.

    The following libssl functionality is also not available when used with QUIC, but calls to the relevant functions are treated as no-ops:

    • Readahead (SSL_set_read_ahead (3), etc.)

CONSIDERATIONS FOR EXISTING APPLICATIONS

Existing applications seeking to adopt QUIC should apply the following list to determine what changes they will need to make:

  • An application wishing to use QUIC must use OSSL_QUIC_client_method (3) or OSSL_QUIC_client_thread_method (3) as its SSL method. For more information on the differences between these two methods, see THREAD ASSISTED MODE.

  • Determine how to provide QUIC with network access. Determine which of the below apply for your application:

    • Your application uses BIO_s_socket (3) to construct a BIO which is passed to the SSL object to provide it with network access. Changes needed: Change your application to use BIO_s_datagram (3) instead when using QUIC. The socket must be configured in nonblocking mode. You may or may not need to use SSL_set1_initial_peer_addr (3) to set the initial peer address; see the QUIC-SPECIFIC APIS section for details.

    • Your application uses BIO_new_ssl_connect (3) to construct a BIO which is passed to the SSL object to provide it with network access. Changes needed: No changes needed. Use of QUIC is detected automatically and a datagram socket is created instead of a normal TCP socket.

    • Your application uses any other I/O strategy in this list but combines it with a BIO_f_buffer (3), for example using BIO_push (3). Changes needed: Disable the usage of BIO_f_buffer (3) when using QUIC. Usage of such a buffer is incompatible with QUIC as QUIC requires datagram semantics in its interaction with the network.

    • Your application uses a BIO pair to cause the SSL object to read and write network traffic to a memory buffer. Your application manages the transmission and reception of buffered data itself in a way unknown to libssl. Changes needed: Switch from using a conventional BIO pair to using BIO_s_dgram_pair (3) instead, which has the necessary datagram semantics. You will need to modify your application to transmit and receive using a UDP socket and to use datagram semantics when interacting with the BIO_s_dgram_pair (3) instance.

    • Your application uses a custom BIO method to provide the SSL object with network access. Changes needed: The custom BIO must be re-architected to have datagram semantics. BIO_sendmmsg (3) and BIO_recvmmsg (3) must be implemented. These calls must operate in a nonblocking fashion. Optionally, implement the BIO_get_rpoll_descriptor (3) and BIO_get_wpoll_descriptor (3) methods if desired. Implementing these methods is required if blocking semantics at the SSL API level are desired.

  • An application must explicitly configure whether it wishes to use the SSL APIs in blocking mode or not. Traditionally, an SSL object has automatically operated in blocking or nonblocking mode based on whether the underlying network BIO operates in blocking or nonblocking mode. QUIC requires the use of a nonblocking network BIO, therefore the blocking mode at the application level must be explicitly configured by the application using the new SSL_set_blocking_mode (3) API. The default mode is blocking. If an application wishes to use the SSL object APIs at application level in a nonblocking manner, it must add a call to SSL_set_blocking_mode (3) to disable blocking mode.

  • If your application does not choose to use thread assisted mode, it must ensure that it calls an I/O function on the SSL object (for example, SSL_read (3) or SSL_write (3)), or the new function SSL_handle_events (3), regularly. If the SSL object is used in blocking mode, an ongoing blocking call to an I/O function satisfies this requirement. This is required to ensure that timer events required by QUIC are handled in a timely fashion. Most applications will service the SSL object by calling SSL_read (3) or SSL_write (3) regularly. If an application does not do this, it should ensure that SSL_handle_events (3) is called regularly. SSL_get_event_timeout (3) can be used to determine when SSL_handle_events (3) must next be called. If the SSL object is being used with an underlying network BIO which is pollable (such as BIO_s_datagram (3)), the application can use SSL_get_rpoll_descriptor (3), SSL_get_wpoll_descriptor (3) to obtain resources which can be used to determine when SSL_handle_events (3) should be called due to network I/O. Applications which use thread assisted mode do not need to be concerned with this requirement, as the QUIC implementation ensures timeout events are handled in a timely manner. See THREAD ASSISTED MODE for details.

  • Ensure that your usage of SSL_want (3), SSL_want_read (3) and SSL_want_write (3) reflects the API changes described in CHANGES TO EXISTING APIS. In particular, you should use these APIs to determine the ability of a QUIC stream to receive or provide application data, not to to determine if network I/O is required.

  • Evaluate your application’s use of SSL_shutdown (3) in light of the changes discussed in CHANGES TO EXISTING APIS. Depending on whether your application wishes to prioritise RFC conformance or rapid shutdown, consider using the new SSL_shutdown_ex (3) API instead. See QUIC-SPECIFIC APIS for details.

RECOMMENDED USAGE IN NEW APPLICATIONS

The recommended usage in new applications varies depending on three independent design decisions:

  • Whether the application will use blocking or nonblocking I/O at the application level (configured using SSL_set_blocking_mode (3)). If the application does nonblocking I/O at the application level it can choose to manage its own polling and event loop; see APPLICATION-DRIVEN EVENT LOOPS.

  • Whether the application intends to give the QUIC implementation direct access to a network socket (e.g. via BIO_s_datagram (3)) or whether it intends to buffer transmitted and received datagrams via a BIO_s_dgram_pair (3) or custom BIO. The former is preferred where possible as it reduces latency to the network, which enables QUIC to achieve higher performance and more accurate connection round trip time (RTT) estimation.

  • Whether thread assisted mode will be used (see THREAD ASSISTED MODE).

Simple demos for QUIC usage under these various scenarios can be found at <https://github.com/openssl/openssl/tree/master/doc/designs/ddd>.

Applications which wish to implement QUIC-specific protocols should be aware of the APIs listed under QUIC-SPECIFIC APIS which provide access to QUIC-specific functionality. For example, SSL_stream_conclude (3) can be used to indicate the end of the sending part of a stream, and SSL_shutdown_ex (3) can be used to provide a QUIC application error code when closing a connection.

Regardless of the design decisions chosen above, it is recommended that new applications avoid use of the default stream mode and use the multi-stream API by calling SSL_set_default_stream_mode (3); see the MODES OF OPERATION section for details.

QUIC-SPECIFIC APIS

This section details new APIs which are directly or indirectly related to QUIC. For details on the operation of each API, see the referenced man pages.

The following SSL APIs are new but relevant to both QUIC and DTLS:

SSL_get_event_timeout (3)
Determines when the QUIC implementation should next be woken up via a call to SSL_handle_events (3) (or another I/O function such as SSL_read (3) or SSL_write (3)), if ever. This can also be used with DTLS and supersedes DTLSv1_get_timeout (3) for new usage.

SSL_handle_events (3)
This is a non-specific I/O operation which makes a best effort attempt to perform any pending I/O or timeout processing. It can be used to advance the QUIC state machine by processing incoming network traffic, generating outgoing network traffic and handling any expired timeout events. Most other I/O functions on an SSL object, such as SSL_read (3) and SSL_write (3) implicitly perform event handling on the SSL object, so calling this function is only needed if no other I/O function is to be called. This can also be used with DTLS and supersedes DTLSv1_handle_timeout (3) for new usage.

The following SSL APIs are specific to QUIC:

SSL_set_blocking_mode (3), SSL_get_blocking_mode (3)
Configures whether blocking semantics are used at the application level. This determines whether calls to functions such as SSL_read (3) and SSL_write (3) will block.

SSL_get_rpoll_descriptor (3), SSL_get_wpoll_descriptor (3)
These functions facilitate operation in nonblocking mode. When an SSL object is being used with an underlying network read BIO which supports polling, SSL_get_rpoll_descriptor (3) outputs an OS resource which can be used to synchronise on network readability events which should result in a call to SSL_handle_events (3). SSL_get_wpoll_descriptor (3) works in an analogous fashion for the underlying network write BIO. The poll descriptors provided by these functions need only be used when SSL_net_read_desired (3) and SSL_net_write_desired (3) return 1, respectively.

SSL_net_read_desired (3), SSL_net_write_desired (3)
These functions facilitate operation in nonblocking mode and are used in conjunction with SSL_get_rpoll_descriptor (3) and SSL_get_wpoll_descriptor (3) respectively. They determine whether the respective poll descriptor is currently relevant for the purposes of polling.

SSL_set1_initial_peer_addr (3)
This function can be used to set the initial peer address for an outgoing QUIC connection. This function must be used in the general case when creating an outgoing QUIC connection; however, the correct initial peer address can be autodetected in some cases. See SSL_set1_initial_peer_addr (3) for details.

SSL_shutdown_ex (3)
This augments SSL_shutdown (3) by allowing an application error code to be specified. It also allows a client to decide how quickly it wants a shutdown to be performed, potentially by trading off strict RFC compliance.

SSL_stream_conclude (3)
This allows an application to indicate the normal end of the sending part of a QUIC stream. This corresponds to the FIN flag in the QUIC RFC. The receiving part of a stream remains usable.

SSL_stream_reset (3)
This allows an application to indicate the non-normal termination of the sending part of a stream. This corresponds to the RESET_STREAM frame in the QUIC RFC.

SSL_get_stream_write_state (3) and SSL_get_stream_read_state (3)
This allows an application to determine the current stream states for the sending and receiving parts of a stream respectively.

SSL_get_stream_write_error_code (3) and SSL_get_stream_read_error_code (3)
This allows an application to determine the application error code which was signalled by a peer which has performed a non-normal stream termination of the respective sending or receiving part of a stream, if any.

SSL_get_conn_close_info (3)
This allows an application to determine the error code which was signalled when the local or remote endpoint terminated the QUIC connection.

SSL_get0_connection (3)
Gets the QUIC connection SSL object from a QUIC stream SSL object.

SSL_is_connection (3)
Returns 1 if a SSL object is not a QUIC stream SSL object.

SSL_get_stream_type (3)
Provides information on the kind of QUIC stream which is attached to the SSL object.

SSL_get_stream_id (3)
Returns the QUIC stream ID which the QUIC protocol has associated with a QUIC stream.

SSL_new_stream (3)
Creates a new QUIC stream SSL object representing a new, locally-initiated QUIC stream.

SSL_accept_stream (3)
Potentially yields a new QUIC stream SSL object representing a new remotely-initiated QUIC stream, blocking until one is available if the connection is configured to do so.

SSL_get_accept_stream_queue_len (3)
Provides information on the number of pending remotely-initiated streams.

SSL_set_incoming_stream_policy (3)
Configures how incoming, remotely-initiated streams are handled. The incoming stream policy can be used to automatically reject streams created by the peer, or allow them to be handled using SSL_accept_stream (3).

SSL_set_default_stream_mode (3)
Used to configure or disable default stream mode; see the MODES OF OPERATION section for details.

The following BIO APIs are not specific to QUIC but have been added to facilitate QUIC-specific requirements and are closely associated with its use:

BIO_s_dgram_pair (3)
This is a new BIO method which is similar to a conventional BIO pair but provides datagram semantics.

BIO_get_rpoll_descriptor (3), BIO_get_wpoll_descriptor (3)
This is a new BIO API which allows a BIO to expose a poll descriptor. This API is used to implement the corresponding SSL APIs SSL_get_rpoll_descriptor (3) and SSL_get_wpoll_descriptor (3).

BIO_sendmmsg (3), BIO_recvmmsg (3)
This is a new BIO API which can be implemented by BIOs which implement datagram semantics. It is implemented by BIO_s_datagram (3) and BIO_s_dgram_pair (3). It is used by the QUIC implementation to send and receive UDP datagrams.

BIO_dgram_set_no_trunc (3), BIO_dgram_get_no_trunc (3)
By default, BIO_s_dgram_pair (3) has semantics comparable to those of Berkeley sockets being used with datagram semantics. This allows an alternative mode to be enabled in which datagrams will not be silently truncated if they are too large.

BIO_dgram_set_caps (3), BIO_dgram_get_caps (3)
These functions are used to allow the user of one end of a BIO_s_dgram_pair (3) to indicate its capabilities to the other end of a BIO_s_dgram_pair (3). In particular, this allows an application to inform the QUIC implementation of whether it is prepared to handle local and/or peer addresses in transmitted datagrams and to provide the applicable information in received datagrams.

BIO_dgram_get_local_addr_cap (3), BIO_dgram_set_local_addr_enable (3), BIO_dgram_get_local_addr_enable (3)
Local addressing support refers to the ability of a BIO with datagram semantics to allow a source address to be specified on transmission and to report the destination address on reception. These functions can be used to determine if a BIO can support local addressing and to enable local addressing support if it can.

BIO_err_is_non_fatal (3)
This is used to determine if an error while calling BIO_sendmmsg (3) or BIO_recvmmsg (3) is ephemeral in nature, such as “would block” errors.

THREAD ASSISTED MODE

The optional thread assisted mode can be used with OSSL_QUIC_client_thread_method (3). In this mode, a background thread is created automatically. The OpenSSL QUIC implementation then takes responsibility for ensuring that timeout events are handled on a timely basis even if no SSL I/O function such as SSL_read (3) or SSL_write (3) is called by the application for a long time.

All necessary locking is handled automatically internally, but the thread safety guarantees for the public SSL API are unchanged. Therefore, an application must still do its own locking if it wishes to make concurrent use of the public SSL APIs.

Because this method relies on threads, it is not available on platforms where threading support is not available or not supported by OpenSSL. However, it does provide the simplest mode of usage for an application.

The implementation may or may not use a common thread or thread pool to service multiple SSL objects in the same SSL_CTX.

APPLICATION-DRIVEN EVENT LOOPS

OpenSSL’s QUIC implementation is designed to facilitate applications which wish to use the SSL APIs in a blocking fashion, but is also designed to facilitate applications which wish to use the SSL APIs in a nonblocking fashion and manage their own event loops and polling directly. This is useful when it is desirable to host OpenSSL’s QUIC implementation on top of an application’s existing nonblocking I/O infrastructure.

This is supported via the concept of poll descriptors; see BIO_get_rpoll_descriptor (3) for details. Broadly, a BIO_POLL_DESCRIPTOR is a structure which expresses some kind of OS resource which can be used to synchronise on I/O events. The QUIC implementation provides a BIO_POLL_DESCRIPTOR based on the poll descriptor provided by the underlying network BIO. This is typically an OS socket handle, though custom BIOs could choose to implement their own custom poll descriptor format.

Broadly, an application which wishes to manage its own event loop should interact with the SSL object as follows:

  • It should provide read and write BIOs with nonblocking datagram semantics to the SSL object using SSL_set0_rbio (3) and SSL_set0_wbio (3). This could be a BIO abstracting a network socket such as BIO_s_datagram (3), or a BIO abstracting some kind of memory buffer such as BIO_s_dgram_pair (3). Use of a custom BIO is also possible.

  • It should configure the SSL object into nonblocking mode by calling SSL_set_blocking_mode (3).

  • It should configure the SSL object as desired, set an initial peer as needed using SSL_set1_initial_peer_addr (3), and trigger the connection process by calling SSL_connect (3).

  • If the network read and write BIOs provided were pollable (for example, a BIO_s_datagram (3), or a custom BIO which implements BIO_get_rpoll_descriptor (3) and BIO_get_wpoll_descriptor (3)), it should perform the following steps repeatedly:

    • The application should call SSL_get_rpoll_descriptor (3) and SSL_get_wpoll_descriptor (3) to identify OS resources which can be used for synchronisation.

    • It should call SSL_net_read_desired (3) and SSL_net_write_desired (3) to determine whether the QUIC implementation is currently interested in readability and writability events on the underlying network BIO which was provided, and call SSL_get_event_timeout (3) to determine if any timeout event will become applicable in the future.

    • It should wait until one of the following events occurs:

      • The poll descriptor returned by SSL_get_rpoll_descriptor (3) becomes readable (if SSL_net_read_desired (3) returned 1);

      • The poll descriptor returned by SSL_get_wpoll_descriptor (3) becomes writable (if SSL_net_write_desired (3) returned 1);

      • The timeout returned by SSL_get_event_timeout (3) (if any) expires.

      Once any of these events occurs, SSL_handle_events (3) should be called.

  • If the network read and write BIOs provided were not pollable (for example, in the case of BIO_s_dgram_pair (3)), the application is responsible for managing and synchronising network I/O. It should call SSL_handle_events (3) after it writes data to a BIO_s_dgram_pair (3) or otherwise takes action so that the QUIC implementation can read new datagrams via a call to BIO_recvmmsg (3) on the underlying network BIO. The QUIC implementation may output datagrams via a call to BIO_sendmmsg (3) and the application is responsible for ensuring these are transmitted. The application must call SSL_get_event_timeout (3) after every call to SSL_handle_events (3) (or another I/O function on the SSL object), and ensure that a call to SSL_handle_events (3) is performed after the specified timeout (if any).

SEE ALSO

SSL_handle_events (3), SSL_get_event_timeout (3), SSL_net_read_desired (3), SSL_net_write_desired (3), SSL_get_rpoll_descriptor (3), SSL_get_wpoll_descriptor (3), SSL_set_blocking_mode (3), SSL_shutdown_ex (3), SSL_set1_initial_peer_addr (3), SSL_stream_conclude (3), SSL_stream_reset (3), SSL_get_stream_read_state (3), SSL_get_stream_read_error_code (3), SSL_get_conn_close_info (3), SSL_get0_connection (3), SSL_get_stream_type (3), SSL_get_stream_id (3), SSL_new_stream (3), SSL_accept_stream (3), SSL_set_incoming_stream_policy (3), SSL_set_default_stream_mode (3)

COPYRIGHT

Copyright 2022-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

615 - Linux cli command DROP_PUBLICATION

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command DROP_PUBLICATION and provides detailed information about the command DROP_PUBLICATION, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the DROP_PUBLICATION.

NAME 🖥️ DROP_PUBLICATION 🖥️

remove a publication

SYNOPSIS

DROP PUBLICATION [ IF EXISTS ] name [, ...] [ CASCADE | RESTRICT ]

DESCRIPTION

DROP PUBLICATION removes an existing publication from the database.

A publication can only be dropped by its owner or a superuser.

PARAMETERS

IF EXISTS

Do not throw an error if the publication does not exist. A notice is issued in this case.

name

The name of an existing publication.

CASCADE
RESTRICT

These key words do not have any effect, since there are no dependencies on publications.

EXAMPLES

Drop a publication:

DROP PUBLICATION mypublication;

COMPATIBILITY

DROP PUBLICATION is a PostgreSQL extension.

SEE ALSO

CREATE PUBLICATION (CREATE_PUBLICATION(7)), ALTER PUBLICATION (ALTER_PUBLICATION(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

616 - Linux cli command CREATE_LANGUAGE

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_LANGUAGE and provides detailed information about the command CREATE_LANGUAGE, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_LANGUAGE.

NAME 🖥️ CREATE_LANGUAGE 🖥️

define a new procedural language

SYNOPSIS

CREATE [ OR REPLACE ] [ TRUSTED ] [ PROCEDURAL ] LANGUAGE name
    HANDLER call_handler [ INLINE inline_handler ] [ VALIDATOR valfunction ]
CREATE [ OR REPLACE ] [ TRUSTED ] [ PROCEDURAL ] LANGUAGE name

DESCRIPTION

CREATE LANGUAGE registers a new procedural language with a PostgreSQL database. Subsequently, functions and procedures can be defined in this new language.

CREATE LANGUAGE effectively associates the language name with handler function(s) that are responsible for executing functions written in the language. Refer to Chapter 58 for more information about language handlers.

CREATE OR REPLACE LANGUAGE will either create a new language, or replace an existing definition. If the language already exists, its parameters are updated according to the command, but the languages ownership and permissions settings do not change, and any existing functions written in the language are assumed to still be valid.

One must have the PostgreSQL superuser privilege to register a new language or change an existing languages parameters. However, once the language is created it is valid to assign ownership of it to a non-superuser, who may then drop it, change its permissions, rename it, or assign it to a new owner. (Do not, however, assign ownership of the underlying C functions to a non-superuser; that would create a privilege escalation path for that user.)

The form of CREATE LANGUAGE that does not supply any handler function is obsolete. For backwards compatibility with old dump files, it is interpreted as CREATE EXTENSION. That will work if the language has been packaged into an extension of the same name, which is the conventional way to set up procedural languages.

PARAMETERS

TRUSTED

TRUSTED specifies that the language does not grant access to data that the user would not otherwise have. If this key word is omitted when registering the language, only users with the PostgreSQL superuser privilege can use this language to create new functions.

PROCEDURAL

This is a noise word.

name

The name of the new procedural language. The name must be unique among the languages in the database.

HANDLER call_handler

call_handler is the name of a previously registered function that will be called to execute the procedural languages functions. The call handler for a procedural language must be written in a compiled language such as C with version 1 call convention and registered with PostgreSQL as a function taking no arguments and returning the language_handler type, a placeholder type that is simply used to identify the function as a call handler.

INLINE inline_handler

inline_handler is the name of a previously registered function that will be called to execute an anonymous code block (DO command) in this language. If no inline_handler function is specified, the language does not support anonymous code blocks. The handler function must take one argument of type internal, which will be the DO commands internal representation, and it will typically return void. The return value of the handler is ignored.

VALIDATOR valfunction

valfunction is the name of a previously registered function that will be called when a new function in the language is created, to validate the new function. If no validator function is specified, then a new function will not be checked when it is created. The validator function must take one argument of type oid, which will be the OID of the to-be-created function, and will typically return void.

A validator function would typically inspect the function body for syntactical correctness, but it can also look at other properties of the function, for example if the language cannot handle certain argument types. To signal an error, the validator function should use the ereport() function. The return value of the function is ignored.

NOTES

Use DROP LANGUAGE to drop procedural languages.

The system catalog pg_language (see Section 53.29) records information about the currently installed languages. Also, the psql command \dL lists the installed languages.

To create functions in a procedural language, a user must have the USAGE privilege for the language. By default, USAGE is granted to PUBLIC (i.e., everyone) for trusted languages. This can be revoked if desired.

Procedural languages are local to individual databases. However, a language can be installed into the template1 database, which will cause it to be available automatically in all subsequently-created databases.

EXAMPLES

A minimal sequence for creating a new procedural language is:

CREATE FUNCTION plsample_call_handler() RETURNS language_handler AS $libdir/plsample LANGUAGE C; CREATE LANGUAGE plsample HANDLER plsample_call_handler;

Typically that would be written in an extensions creation script, and users would do this to install the extension:

CREATE EXTENSION plsample;

COMPATIBILITY

CREATE LANGUAGE is a PostgreSQL extension.

SEE ALSO

ALTER LANGUAGE (ALTER_LANGUAGE(7)), CREATE FUNCTION (CREATE_FUNCTION(7)), DROP LANGUAGE (DROP_LANGUAGE(7)), GRANT(7), REVOKE(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

617 - Linux cli command hostname

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command hostname and provides detailed information about the command hostname, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the hostname.

NAME 🖥️ hostname 🖥️

hostname resolution description

DESCRIPTION

Hostnames are domains, where a domain is a hierarchical, dot-separated list of subdomains; for example, the machine “monet”, in the “example” subdomain of the “com” domain would be represented as “monet.example.com”.

Each element of the hostname must be from 1 to 63 characters long and the entire hostname, including the dots, can be at most 253 characters long. Valid characters for hostnames are ASCII(7) letters from a to z, the digits from 0 to 9, and the hyphen (-). A hostname may not start with a hyphen.

Hostnames are often used with network client and server programs, which must generally translate the name to an address for use. (This task is generally performed by either getaddrinfo(3) or the obsolete gethostbyname(3).)

Hostnames are resolved by the NSS framework in glibc according to the hosts configuration in nsswitch.conf(5). The DNS-based name resolver (in the dns NSS service module) resolves them in the following fashion.

If the name consists of a single component, that is, contains no dot, and if the environment variable HOSTALIASES is set to the name of a file, that file is searched for any string matching the input hostname. The file should consist of lines made up of two white-space separated strings, the first of which is the hostname alias, and the second of which is the complete hostname to be substituted for that alias. If a case-insensitive match is found between the hostname to be resolved and the first field of a line in the file, the substituted name is looked up with no further processing.

If the input name ends with a trailing dot, the trailing dot is removed, and the remaining name is looked up with no further processing.

If the input name does not end with a trailing dot, it is looked up by searching through a list of domains until a match is found. The default search list includes first the local domain, then its parent domains with at least 2 name components (longest first). For example, in the domain cs.example.com, the name lithium.cchem will be checked first as lithium.cchem.cs.example and then as lithium.cchem.example.com. lithium.cchem.com will not be tried, as there is only one component remaining from the local domain. The search path can be changed from the default by a system-wide configuration file (see resolver(5)).

SEE ALSO

getaddrinfo(3), gethostbyname(3), nsswitch.conf(5), resolver(5), mailaddr(7), named(8)

IETF RFC 1123

IETF RFC 1178

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

618 - Linux cli command COMMIT

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command COMMIT and provides detailed information about the command COMMIT, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the COMMIT.

NAME 🖥️ COMMIT 🖥️

commit the current transaction

SYNOPSIS

COMMIT [ WORK | TRANSACTION ] [ AND [ NO ] CHAIN ]

DESCRIPTION

COMMIT commits the current transaction. All changes made by the transaction become visible to others and are guaranteed to be durable if a crash occurs.

PARAMETERS

WORK
TRANSACTION

Optional key words. They have no effect.

AND CHAIN

If AND CHAIN is specified, a new transaction is immediately started with the same transaction characteristics (see SET TRANSACTION (SET_TRANSACTION(7))) as the just finished one. Otherwise, no new transaction is started.

NOTES

Use ROLLBACK(7) to abort a transaction.

Issuing COMMIT when not inside a transaction does no harm, but it will provoke a warning message. COMMIT AND CHAIN when not inside a transaction is an error.

EXAMPLES

To commit the current transaction and make all changes permanent:

COMMIT;

COMPATIBILITY

The command COMMIT conforms to the SQL standard. The form COMMIT TRANSACTION is a PostgreSQL extension.

SEE ALSO

BEGIN(7), ROLLBACK(7)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

619 - Linux cli command gittutorial-2

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command gittutorial-2 and provides detailed information about the command gittutorial-2, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the gittutorial-2.

NAME 🖥️ gittutorial-2 🖥️

2 - A tutorial introduction to Git: part two

SYNOPSIS

git *

DESCRIPTION

You should work through gittutorial(7) before reading this tutorial.

The goal of this tutorial is to introduce two fundamental pieces of Git’s architecture—the object database and the index file—and to provide the reader with everything necessary to understand the rest of the Git documentation.

THE GIT OBJECT DATABASE

Let’s start a new project and create a small amount of history:

$ mkdir test-project $ cd test-project $ git init Initialized empty Git repository in .git/ $ echo hello world > file.txt $ git add . $ git commit -a -m “initial commit” [master (root-commit) 54196cc] initial commit 1 file changed, 1 insertion(+) create mode 100644 file.txt $ echo hello world! >file.txt $ git commit -a -m “add emphasis” [master c4d59f3] add emphasis 1 file changed, 1 insertion(+), 1 deletion(-)

What are the 7 digits of hex that Git responded to the commit with?

We saw in part one of the tutorial that commits have names like this. It turns out that every object in the Git history is stored under a 40-digit hex name. That name is the SHA-1 hash of the object’s contents; among other things, this ensures that Git will never store the same data twice (since identical data is given an identical SHA-1 name), and that the contents of a Git object will never change (since that would change the object’s name as well). The 7 char hex strings here are simply the abbreviation of such 40 character long strings. Abbreviations can be used everywhere where the 40 character strings can be used, so long as they are unambiguous.

It is expected that the content of the commit object you created while following the example above generates a different SHA-1 hash than the one shown above because the commit object records the time when it was created and the name of the person performing the commit.

We can ask Git about this particular object with the cat-file command. Don’t copy the 40 hex digits from this example but use those from your own version. Note that you can shorten it to only a few characters to save yourself typing all 40 hex digits:

$ git cat-file -t 54196cc2 commit $ git cat-file commit 54196cc2 tree 92b8b694ffb1675e5975148e1121810081dbdffe author J. Bruce Fields [email protected] 1143414668 -0500 committer J. Bruce Fields [email protected] 1143414668 -0500

initial commit

A tree can refer to one or more “blob” objects, each corresponding to a file. In addition, a tree can also refer to other tree objects, thus creating a directory hierarchy. You can examine the contents of any tree using ls-tree (remember that a long enough initial portion of the SHA-1 will also work):

$ git ls-tree 92b8b694 100644 blob 3b18e512dba79e4c8300dd08aeb37f8e728b8dad file.txt

Thus we see that this tree has one file in it. The SHA-1 hash is a reference to that file’s data:

$ git cat-file -t 3b18e512 blob

A “blob” is just file data, which we can also examine with cat-file:

$ git cat-file blob 3b18e512 hello world

Note that this is the old file data; so the object that Git named in its response to the initial tree was a tree with a snapshot of the directory state that was recorded by the first commit.

All of these objects are stored under their SHA-1 names inside the Git directory:

$ find .git/objects/ .git/objects/ .git/objects/pack .git/objects/info .git/objects/3b .git/objects/3b/18e512dba79e4c8300dd08aeb37f8e728b8dad .git/objects/92 .git/objects/92/b8b694ffb1675e5975148e1121810081dbdffe .git/objects/54 .git/objects/54/196cc2703dc165cbd373a65a4dcf22d50ae7f7 .git/objects/a0 .git/objects/a0/423896973644771497bdc03eb99d5281615b51 .git/objects/d0 .git/objects/d0/492b368b66bdabf2ac1fd8c92b39d3db916e59 .git/objects/c4 .git/objects/c4/d59f390b9cfd4318117afde11d601c1085f241

and the contents of these files is just the compressed data plus a header identifying their length and their type. The type is either a blob, a tree, a commit, or a tag.

The simplest commit to find is the HEAD commit, which we can find from .git/HEAD:

$ cat .git/HEAD ref: refs/heads/master

As you can see, this tells us which branch we’re currently on, and it tells us this by naming a file under the .git directory, which itself contains a SHA-1 name referring to a commit object, which we can examine with cat-file:

$ cat .git/refs/heads/master c4d59f390b9cfd4318117afde11d601c1085f241 $ git cat-file -t c4d59f39 commit $ git cat-file commit c4d59f39 tree d0492b368b66bdabf2ac1fd8c92b39d3db916e59 parent 54196cc2703dc165cbd373a65a4dcf22d50ae7f7 author J. Bruce Fields [email protected] 1143418702 -0500 committer J. Bruce Fields [email protected] 1143418702 -0500

add emphasis

The “tree” object here refers to the new state of the tree:

$ git ls-tree d0492b36 100644 blob a0423896973644771497bdc03eb99d5281615b51 file.txt $ git cat-file blob a0423896 hello world!

and the “parent” object refers to the previous commit:

$ git cat-file commit 54196cc2 tree 92b8b694ffb1675e5975148e1121810081dbdffe author J. Bruce Fields [email protected] 1143414668 -0500 committer J. Bruce Fields [email protected] 1143414668 -0500

initial commit

The tree object is the tree we examined first, and this commit is unusual in that it lacks any parent.

Most commits have only one parent, but it is also common for a commit to have multiple parents. In that case the commit represents a merge, with the parent references pointing to the heads of the merged branches.

Besides blobs, trees, and commits, the only remaining type of object is a “tag”, which we won’t discuss here; refer to git-tag(1) for details.

So now we know how Git uses the object database to represent a project’s history:

·

“commit” objects refer to “tree” objects representing the snapshot of a directory tree at a particular point in the history, and refer to “parent” commits to show how they’re connected into the project history.

·

“tree” objects represent the state of a single directory, associating directory names to “blob” objects containing file data and “tree” objects containing subdirectory information.

·

“blob” objects contain file data without any other structure.

·

References to commit objects at the head of each branch are stored in files under .git/refs/heads/.

·

The name of the current branch is stored in .git/HEAD.

Note, by the way, that lots of commands take a tree as an argument. But as we can see above, a tree can be referred to in many different ways—by the SHA-1 name for that tree, by the name of a commit that refers to the tree, by the name of a branch whose head refers to that tree, etc.–and most such commands can accept any of these names.

In command synopses, the word “tree-ish” is sometimes used to designate such an argument.

THE INDEX FILE

The primary tool we’ve been using to create commits is git-commit -a, which creates a commit including every change you’ve made to your working tree. But what if you want to commit changes only to certain files? Or only certain changes to certain files?

If we look at the way commits are created under the cover, we’ll see that there are more flexible ways creating commits.

Continuing with our test-project, let’s modify file.txt again:

$ echo “hello world, again” »file.txt

but this time instead of immediately making the commit, let’s take an intermediate step, and ask for diffs along the way to keep track of what’s happening:

$ git diff — a/file.txt +++ b/file.txt @@ -1 +1,2 @@ hello world! +hello world, again $ git add file.txt $ git diff

The last diff is empty, but no new commits have been made, and the head still doesn’t contain the new line:

$ git diff HEAD diff –git a/file.txt b/file.txt index a042389..513feba 100644 — a/file.txt +++ b/file.txt @@ -1 +1,2 @@ hello world! +hello world, again

So git diff is comparing against something other than the head. The thing that it’s comparing against is actually the index file, which is stored in .git/index in a binary format, but whose contents we can examine with ls-files:

$ git ls-files –stage 100644 513feba2e53ebbd2532419ded848ba19de88ba00 0 file.txt $ git cat-file -t 513feba2 blob $ git cat-file blob 513feba2 hello world! hello world, again

So what our git add did was store a new blob and then put a reference to it in the index file. If we modify the file again, we’ll see that the new modifications are reflected in the git diff output:

$ echo again? »file.txt $ git diff index 513feba..ba3da7b 100644 — a/file.txt +++ b/file.txt @@ -1,2 +1,3 @@ hello world! hello world, again +again?

With the right arguments, git diff can also show us the difference between the working directory and the last commit, or between the index and the last commit:

$ git diff HEAD diff –git a/file.txt b/file.txt index a042389..ba3da7b 100644 — a/file.txt +++ b/file.txt @@ -1 +1,3 @@ hello world! +hello world, again +again? $ git diff –cached diff –git a/file.txt b/file.txt index a042389..513feba 100644 — a/file.txt +++ b/file.txt @@ -1 +1,2 @@ hello world! +hello world, again

At any time, we can create a new commit using git commit (without the “-a” option), and verify that the state committed only includes the changes stored in the index file, not the additional change that is still only in our working tree:

$ git commit -m “repeat” $ git diff HEAD diff –git a/file.txt b/file.txt index 513feba..ba3da7b 100644 — a/file.txt +++ b/file.txt @@ -1,2 +1,3 @@ hello world! hello world, again +again?

So by default git commit uses the index to create the commit, not the working tree; the “-a” option to commit tells it to first update the index with all changes in the working tree.

Finally, it’s worth looking at the effect of git add on the index file:

$ echo “goodbye, world” >closing.txt $ git add closing.txt

The effect of the git add was to add one entry to the index file:

$ git ls-files –stage 100644 8b9743b20d4b15be3955fc8d5cd2b09cd2336138 0 closing.txt 100644 513feba2e53ebbd2532419ded848ba19de88ba00 0 file.txt

And, as you can see with cat-file, this new entry refers to the current contents of the file:

$ git cat-file blob 8b9743b2 goodbye, world

The “status” command is a useful way to get a quick summary of the situation:

$ git status On branch master Changes to be committed: (use “git restore –staged …” to unstage)

        new file:   closing.txt

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)

        modified:   file.txt

Since the current state of closing.txt is cached in the index file, it is listed as “Changes to be committed”. Since file.txt has changes in the working directory that aren’t reflected in the index, it is marked “changed but not updated”. At this point, running “git commit” would create a commit that added closing.txt (with its new contents), but that didn’t modify file.txt.

Also, note that a bare git diff shows the changes to file.txt, but not the addition of closing.txt, because the version of closing.txt in the index file is identical to the one in the working directory.

In addition to being the staging area for new commits, the index file is also populated from the object database when checking out a branch, and is used to hold the trees involved in a merge operation. See gitcore-tutorial(7) and the relevant man pages for details.

WHAT NEXT?

At this point you should know everything necessary to read the man pages for any of the git commands; one good place to start would be with the commands mentioned in giteveryday(7). You should be able to find any unknown jargon in gitglossary(7).

The Git User’s Manual[1] provides a more comprehensive introduction to Git.

gitcvs-migration(7) explains how to import a CVS repository into Git, and shows how to use Git in a CVS-like way.

For some interesting examples of Git use, see the howtos[2].

For Git developers, gitcore-tutorial(7) goes into detail on the lower-level Git mechanisms involved in, for example, creating a new commit.

SEE ALSO

gittutorial(7), gitcvs-migration(7), gitcore-tutorial(7), gitglossary(7), git-help(1), giteveryday(7), The Git User’s Manual[1]

GIT

Part of the git(1) suite

NOTES

Git User’s Manual

file:///usr/share/doc/git/html/user-manual.html

howtos

file:///usr/share/doc/git/html/howto-index.html

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

620 - Linux cli command CREATE_DOMAIN

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CREATE_DOMAIN and provides detailed information about the command CREATE_DOMAIN, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CREATE_DOMAIN.

NAME 🖥️ CREATE_DOMAIN 🖥️

define a new domain

SYNOPSIS

CREATE DOMAIN name [ AS ] data_type
    [ COLLATE collation ]
    [ DEFAULT expression ]
    [ constraint [ ... ] ]

where constraint is:

[ CONSTRAINT constraint_name ]
{ NOT NULL | NULL | CHECK (expression) }

DESCRIPTION

CREATE DOMAIN creates a new domain. A domain is essentially a data type with optional constraints (restrictions on the allowed set of values). The user who defines a domain becomes its owner.

If a schema name is given (for example, CREATE DOMAIN myschema.mydomain …) then the domain is created in the specified schema. Otherwise it is created in the current schema. The domain name must be unique among the types and domains existing in its schema.

Domains are useful for abstracting common constraints on fields into a single location for maintenance. For example, several tables might contain email address columns, all requiring the same CHECK constraint to verify the address syntax. Define a domain rather than setting up each tables constraint individually.

To be able to create a domain, you must have USAGE privilege on the underlying type.

PARAMETERS

name

The name (optionally schema-qualified) of a domain to be created.

data_type

The underlying data type of the domain. This can include array specifiers.

collation

An optional collation for the domain. If no collation is specified, the domain has the same collation behavior as its underlying data type. The underlying type must be collatable if COLLATE is specified.

DEFAULT expression

The DEFAULT clause specifies a default value for columns of the domain data type. The value is any variable-free expression (but subqueries are not allowed). The data type of the default expression must match the data type of the domain. If no default value is specified, then the default value is the null value.

The default expression will be used in any insert operation that does not specify a value for the column. If a default value is defined for a particular column, it overrides any default associated with the domain. In turn, the domain default overrides any default value associated with the underlying data type.

CONSTRAINT constraint_name

An optional name for a constraint. If not specified, the system generates a name.

NOT NULL

Values of this domain are prevented from being null (but see notes below).

NULL

Values of this domain are allowed to be null. This is the default.

This clause is only intended for compatibility with nonstandard SQL databases. Its use is discouraged in new applications.

CHECK (expression)

CHECK clauses specify integrity constraints or tests which values of the domain must satisfy. Each constraint must be an expression producing a Boolean result. It should use the key word VALUE to refer to the value being tested. Expressions evaluating to TRUE or UNKNOWN succeed. If the expression produces a FALSE result, an error is reported and the value is not allowed to be converted to the domain type.

Currently, CHECK expressions cannot contain subqueries nor refer to variables other than VALUE.

When a domain has multiple CHECK constraints, they will be tested in alphabetical order by name. (PostgreSQL versions before 9.5 did not honor any particular firing order for CHECK constraints.)

NOTES

Domain constraints, particularly NOT NULL, are checked when converting a value to the domain type. It is possible for a column that is nominally of the domain type to read as null despite there being such a constraint. For example, this can happen in an outer-join query, if the domain column is on the nullable side of the outer join. A more subtle example is

INSERT INTO tab (domcol) VALUES ((SELECT domcol FROM tab WHERE false));

The empty scalar sub-SELECT will produce a null value that is considered to be of the domain type, so no further constraint checking is applied to it, and the insertion will succeed.

It is very difficult to avoid such problems, because of SQLs general assumption that a null value is a valid value of every data type. Best practice therefore is to design a domains constraints so that a null value is allowed, and then to apply column NOT NULL constraints to columns of the domain type as needed, rather than directly to the domain type.

PostgreSQL assumes that CHECK constraints conditions are immutable, that is, they will always give the same result for the same input value. This assumption is what justifies examining CHECK constraints only when a value is first converted to be of a domain type, and not at other times. (This is essentially the same as the treatment of table CHECK constraints, as described in Section 5.4.1.)

An example of a common way to break this assumption is to reference a user-defined function in a CHECK expression, and then change the behavior of that function. PostgreSQL does not disallow that, but it will not notice if there are stored values of the domain type that now violate the CHECK constraint. That would cause a subsequent database dump and restore to fail. The recommended way to handle such a change is to drop the constraint (using ALTER DOMAIN), adjust the function definition, and re-add the constraint, thereby rechecking it against stored data.

Its also good practice to ensure that domain CHECK expressions will not throw errors.

EXAMPLES

This example creates the us_postal_code data type and then uses the type in a table definition. A regular expression test is used to verify that the value looks like a valid US postal code:

CREATE DOMAIN us_postal_code AS TEXT CHECK( VALUE ~ ^\d{5}$ OR VALUE ~ ^\d{5}-\d{4}$ );

CREATE TABLE us_snail_addy (
  address_id SERIAL PRIMARY KEY,
  street1 TEXT NOT NULL,
  street2 TEXT,
  street3 TEXT,
  city TEXT NOT NULL,
  postal us_postal_code NOT NULL
);

COMPATIBILITY

The command CREATE DOMAIN conforms to the SQL standard.

SEE ALSO

ALTER DOMAIN (ALTER_DOMAIN(7)), DROP DOMAIN (DROP_DOMAIN(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

621 - Linux cli command ossl-guide-libssl-introductionssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ossl-guide-libssl-introductionssl and provides detailed information about the command ossl-guide-libssl-introductionssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ossl-guide-libssl-introductionssl.

NAME 🖥️ ossl-guide-libssl-introductionssl 🖥️

guide-libssl-introduction, ssl - OpenSSL Guide: An introduction to libssl

INTRODUCTION

The OpenSSL libssl library provides implementations of several secure network communications protocols. Specifically it provides SSL/TLS (SSLv3, TLSv1, TLSv1.1, TLSv1.2 and TLSv1.3), DTLS (DTLSv1 and DTLSv1.2) and QUIC (client side only). The library depends on libcrypto for its underlying cryptographic operations (see ossl-guide-libcrypto-introduction (7)).

The set of APIs supplied by libssl is common across all of these different network protocols, so a developer familiar with writing applications using one of these protocols should be able to transition to using another with relative ease.

An application written to use libssl will include the <openssl/ssl.h> header file and will typically use two main data structures, i.e. SSL and SSL_CTX.

An SSL object is used to represent a connection to a remote peer. Once a connection with a remote peer has been established data can be exchanged with that peer.

When using DTLS any data that is exchanged uses “datagram” semantics, i.e. the packets of data can be delivered in any order, and they are not guaranteed to arrive at all. In this case the SSL object used for the connection is also used for exchanging data with the peer.

Both TLS and QUIC support the concept of a “stream” of data. Data sent via a stream is guaranteed to be delivered in order without any data loss. A stream can be uni- or bi-directional.

SSL/TLS only supports one stream of data per connection and it is always bi-directional. In this case the SSL object used for the connection also represents that stream. See ossl-guide-tls-introduction (7) for more information.

The QUIC protocol can support multiple streams per connection and they can be uni- or bi-directional. In this case an SSL object can represent the underlying connection, or a stream, or both. Where multiple streams are in use a separate SSL object is used for each one. See ossl-guide-quic-introduction (7) for more information.

An SSL_CTX object is used to create the SSL object for the underlying connection. A single SSL_CTX object can be used to create many connections (each represented by a separate SSL object). Many API functions in libssl exist in two forms: one that takes an SSL_CTX and one that takes an SSL. Typically settings that you apply to the SSL_CTX will then be inherited by any SSL object that you create from it. Alternatively you can apply settings directly to the SSL object without affecting other SSL objects. Note that you should not normally make changes to an SSL_CTX after the first SSL object has been created from it.

DATA STRUCTURES

As well as SSL_CTX and SSL there are a number of other data structures that an application may need to use. They are summarised below.

SSL_METHOD (SSL Method)
This structure is used to indicate the kind of connection you want to make, e.g. whether it is to represent the client or the server, and whether it is to use SSL/TLS, DTLS or QUIC (client only). It is passed as a parameter when creating the SSL_CTX.

SSL_SESSION (SSL Session)
After establishing a connection with a peer the agreed cryptographic material can be reused to create future connections with the same peer more rapidly. The set of data used for such a future connection establishment attempt is collected together into an SSL_SESSION object. A single successful connection with a peer may generate zero or more such SSL_SESSION objects for use in future connection attempts.

SSL_CIPHER (SSL Cipher)
During connection establishment the client and server agree upon cryptographic algorithms they are going to use for encryption and other uses. A single set of cryptographic algorithms that are to be used together is known as a ciphersuite. Such a set is represented by an SSL_CIPHER object. The set of available ciphersuites that can be used are configured in the SSL_CTX or SSL.

FURTHER READING

See ossl-guide-tls-introduction (7) for an introduction to the SSL/TLS protocol and ossl-guide-quic-introduction (7) for an introduction to QUIC.

See ossl-guide-libcrypto-introduction (7) for an introduction to libcrypto.

SEE ALSO

ossl-guide-libcrypto-introduction (7), ossl-guide-tls-introduction (7), ossl-guide-quic-introduction (7)

COPYRIGHT

Copyright 2000-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

622 - Linux cli command queue

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command queue and provides detailed information about the command queue, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the queue.

NAME 🖥️ queue 🖥️

implementations of linked lists and queues

DESCRIPTION

The <sys/queue.h> header file provides a set of macros that define and operate on the following data structures:

SLIST
singly linked lists

LIST
doubly linked lists

STAILQ
singly linked tail queues

TAILQ
doubly linked tail queues

CIRCLEQ
doubly linked circular queues

All structures support the following functionality:

  • Insertion of a new entry at the head of the list.

  • Insertion of a new entry after any element in the list.

  • O(1) removal of an entry from the head of the list.

  • Forward traversal through the list.

Code size and execution time depend on the complexity of the data structure being used, so programmers should take care to choose the appropriate one.

Singly linked lists (SLIST)

Singly linked lists are the simplest and support only the above functionality. Singly linked lists are ideal for applications with large datasets and few or no removals, or for implementing a LIFO queue. Singly linked lists add the following functionality:

  • O(n) removal of any entry in the list.

Singly linked tail queues (STAILQ)

Singly linked tail queues add the following functionality:

  • Entries can be added at the end of a list.

  • O(n) removal of any entry in the list.

  • They may be concatenated.

However:

  • All list insertions must specify the head of the list.

  • Each head entry requires two pointers rather than one.

Singly linked tail queues are ideal for applications with large datasets and few or no removals, or for implementing a FIFO queue.

Doubly linked data structures

All doubly linked types of data structures (lists and tail queues) additionally allow:

  • Insertion of a new entry before any element in the list.

  • O(1) removal of any entry in the list.

However:

  • Each element requires two pointers rather than one.

Doubly linked lists (LIST)

Linked lists are the simplest of the doubly linked data structures. They add the following functionality over the above:

  • They may be traversed backwards.

However:

  • To traverse backwards, an entry to begin the traversal and the list in which it is contained must be specified.

Doubly linked tail queues (TAILQ)

Tail queues add the following functionality:

  • Entries can be added at the end of a list.

  • They may be traversed backwards, from tail to head.

  • They may be concatenated.

However:

  • All list insertions and removals must specify the head of the list.

  • Each head entry requires two pointers rather than one.

Doubly linked circular queues (CIRCLEQ)

Circular queues add the following functionality over the above:

  • The first and last entries are connected.

However:

  • The termination condition for traversal is more complex.

STANDARDS

BSD.

HISTORY

<sys/queue.h> macros first appeared in 4.4BSD.

NOTES

Some BSDs provide SIMPLEQ instead of STAILQ. They are identical, but for historical reasons they were named differently on different BSDs. STAILQ originated on FreeBSD, and SIMPLEQ originated on NetBSD. For compatibility reasons, some systems provide both sets of macros. glibc provides both STAILQ and SIMPLEQ, which are identical except for a missing SIMPLEQ equivalent to STAILQ_CONCAT().

SEE ALSO

circleq(3), insque(3), list(3), slist(3), stailq(3), tailq(3)

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

623 - Linux cli command ALTER_TEXT_SEARCH_PARSER

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ALTER_TEXT_SEARCH_PARSER and provides detailed information about the command ALTER_TEXT_SEARCH_PARSER, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ALTER_TEXT_SEARCH_PARSER.

NAME 🖥️ ALTER_TEXT_SEARCH_PARSER 🖥️

change the definition of a text search parser

SYNOPSIS

ALTER TEXT SEARCH PARSER name RENAME TO new_name
ALTER TEXT SEARCH PARSER name SET SCHEMA new_schema

DESCRIPTION

ALTER TEXT SEARCH PARSER changes the definition of a text search parser. Currently, the only supported functionality is to change the parsers name.

You must be a superuser to use ALTER TEXT SEARCH PARSER.

PARAMETERS

name

The name (optionally schema-qualified) of an existing text search parser.

new_name

The new name of the text search parser.

new_schema

The new schema for the text search parser.

COMPATIBILITY

There is no ALTER TEXT SEARCH PARSER statement in the SQL standard.

SEE ALSO

CREATE TEXT SEARCH PARSER (CREATE_TEXT_SEARCH_PARSER(7)), DROP TEXT SEARCH PARSER (DROP_TEXT_SEARCH_PARSER(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

624 - Linux cli command EVP_MD-RIPEMD160ssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command EVP_MD-RIPEMD160ssl and provides detailed information about the command EVP_MD-RIPEMD160ssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the EVP_MD-RIPEMD160ssl.

NAME 🖥️ EVP_MD-RIPEMD160ssl 🖥️

RIPEMD160 - The RIPEMD160 EVP_MD implementation

DESCRIPTION

Support for computing RIPEMD160 digests through the EVP_MD API.

Identities

This implementation is available in both the default and legacy providers, and is identified with any of the names “RIPEMD-160”, “RIPEMD160”, “RIPEMD” and “RMD160”.

Gettable Parameters

This implementation supports the common gettable parameters described in EVP_MD-common (7).

SEE ALSO

provider-digest (7), OSSL_PROVIDER-default (7)

HISTORY

This digest was added to the default provider in OpenSSL 3.0.7.

COPYRIGHT

Copyright 2020 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

625 - Linux cli command CALL

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command CALL and provides detailed information about the command CALL, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the CALL.

NAME 🖥️ CALL 🖥️

invoke a procedure

SYNOPSIS

CALL name ( [ argument ] [, ...] )

DESCRIPTION

CALL executes a procedure.

If the procedure has any output parameters, then a result row will be returned, containing the values of those parameters.

PARAMETERS

name

The name (optionally schema-qualified) of the procedure.

argument

An argument expression for the procedure call.

Arguments can include parameter names, using the syntax name => value. This works the same as in ordinary function calls; see Section 4.3 for details.

Arguments must be supplied for all procedure parameters that lack defaults, including OUT parameters. However, arguments matching OUT parameters are not evaluated, so its customary to just write NULL for them. (Writing something else for an OUT parameter might cause compatibility problems with future PostgreSQL versions.)

NOTES

The user must have EXECUTE privilege on the procedure in order to be allowed to invoke it.

To call a function (not a procedure), use SELECT instead.

If CALL is executed in a transaction block, then the called procedure cannot execute transaction control statements. Transaction control statements are only allowed if CALL is executed in its own transaction.

PL/pgSQL handles output parameters in CALL commands differently; see Section 43.6.3.

EXAMPLES

CALL do_db_maintenance();

COMPATIBILITY

CALL conforms to the SQL standard, except for the handling of output parameters. The standard says that users should write variables to receive the values of output parameters.

SEE ALSO

CREATE PROCEDURE (CREATE_PROCEDURE(7))

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

626 - Linux cli command provider-kemssl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command provider-kemssl and provides detailed information about the command provider-kemssl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the provider-kemssl.

NAME 🖥️ provider-kemssl 🖥️

kem - The kem library <-> provider functions

SYNOPSIS

#include <openssl/core_dispatch.h> #include <openssl/core_names.h> /* * None of these are actual functions, but are displayed like this for * the function signatures for functions that are offered as function * pointers in OSSL_DISPATCH arrays. */ /* Context management */ void *OSSL_FUNC_kem_newctx(void *provctx); void OSSL_FUNC_kem_freectx(void *ctx); void *OSSL_FUNC_kem_dupctx(void *ctx); /* Encapsulation */ int OSSL_FUNC_kem_encapsulate_init(void *ctx, void *provkey, const OSSL_PARAM params[]); int OSSL_FUNC_kem_auth_encapsulate_init(void *ctx, void *provkey, void *provauthkey, const OSSL_PARAM params[]); int OSSL_FUNC_kem_encapsulate(void *ctx, unsigned char *out, size_t *outlen, unsigned char *secret, size_t *secretlen); /* Decapsulation */ int OSSL_FUNC_kem_decapsulate_init(void *ctx, void *provkey); int OSSL_FUNC_kem_auth_decapsulate_init(void *ctx, void *provkey, void *provauthkey, const OSSL_PARAM params[]); int OSSL_FUNC_kem_decapsulate(void *ctx, unsigned char *out, size_t *outlen, const unsigned char *in, size_t inlen); /* KEM parameters */ int OSSL_FUNC_kem_get_ctx_params(void *ctx, OSSL_PARAM params[]); const OSSL_PARAM *OSSL_FUNC_kem_gettable_ctx_params(void *ctx, void *provctx); int OSSL_FUNC_kem_set_ctx_params(void *ctx, const OSSL_PARAM params[]); const OSSL_PARAM *OSSL_FUNC_kem_settable_ctx_params(void *ctx, void *provctx);

DESCRIPTION

This documentation is primarily aimed at provider authors. See provider (7) for further information.

The asymmetric kem (OSSL_OP_KEM) operation enables providers to implement asymmetric kem algorithms and make them available to applications via the API functions EVP_PKEY_encapsulate (3), EVP_PKEY_decapsulate (3) and other related functions.

All “functions” mentioned here are passed as function pointers between libcrypto and the provider in OSSL_DISPATCH (3) arrays via OSSL_ALGORITHM (3) arrays that are returned by the provider’s provider_query_operation() function (see “Provider Functions” in provider-base (7)).

All these “functions” have a corresponding function type definition named OSSL_FUNC_{name}_fn, and a helper function to retrieve the function pointer from an OSSL_DISPATCH (3) element named OSSL_FUNC_{name}. For example, the “function” OSSL_FUNC_kem_newctx() has these:

typedef void *(OSSL_FUNC_kem_newctx_fn)(void *provctx); static ossl_inline OSSL_FUNC_kem_newctx_fn OSSL_FUNC_kem_newctx(const OSSL_DISPATCH *opf);

OSSL_DISPATCH (3) arrays are indexed by numbers that are provided as macros in openssl-core_dispatch.h (7), as follows:

OSSL_FUNC_kem_newctx OSSL_FUNC_KEM_NEWCTX OSSL_FUNC_kem_freectx OSSL_FUNC_KEM_FREECTX OSSL_FUNC_kem_dupctx OSSL_FUNC_KEM_DUPCTX OSSL_FUNC_kem_encapsulate_init OSSL_FUNC_KEM_ENCAPSULATE_INIT OSSL_FUNC_kem_auth_encapsulate_init OSSL_FUNC_KEM_AUTH_ENCAPSULATE_INIT OSSL_FUNC_kem_encapsulate OSSL_FUNC_KEM_ENCAPSULATE OSSL_FUNC_kem_decapsulate_init OSSL_FUNC_KEM_DECAPSULATE_INIT OSSL_FUNC_kem_auth_decapsulate_init OSSL_FUNC_KEM_AUTH_DECAPSULATE_INIT OSSL_FUNC_kem_decapsulate OSSL_FUNC_KEM_DECAPSULATE OSSL_FUNC_kem_get_ctx_params OSSL_FUNC_KEM_GET_CTX_PARAMS OSSL_FUNC_kem_gettable_ctx_params OSSL_FUNC_KEM_GETTABLE_CTX_PARAMS OSSL_FUNC_kem_set_ctx_params OSSL_FUNC_KEM_SET_CTX_PARAMS OSSL_FUNC_kem_settable_ctx_params OSSL_FUNC_KEM_SETTABLE_CTX_PARAMS

An asymmetric kem algorithm implementation may not implement all of these functions. In order to be a consistent set of functions a provider must implement OSSL_FUNC_kem_newctx and OSSL_FUNC_kem_freectx. It must also implement both of OSSL_FUNC_kem_encapsulate_init and OSSL_FUNC_kem_encapsulate, or both of OSSL_FUNC_kem_decapsulate_init and OSSL_FUNC_kem_decapsulate. OSSL_FUNC_kem_auth_encapsulate_init is optional but if it is present then so must OSSL_FUNC_kem_auth_decapsulate_init. OSSL_FUNC_kem_get_ctx_params is optional but if it is present then so must OSSL_FUNC_kem_gettable_ctx_params. Similarly, OSSL_FUNC_kem_set_ctx_params is optional but if it is present then OSSL_FUNC_kem_settable_ctx_params must also be present.

An asymmetric kem algorithm must also implement some mechanism for generating, loading or importing keys via the key management (OSSL_OP_KEYMGMT) operation. See provider-keymgmt (7) for further details.

Context Management Functions

OSSL_FUNC_kem_newctx() should create and return a pointer to a provider side structure for holding context information during an asymmetric kem operation. A pointer to this context will be passed back in a number of the other asymmetric kem operation function calls. The parameter provctx is the provider context generated during provider initialisation (see provider (7)).

OSSL_FUNC_kem_freectx() is passed a pointer to the provider side asymmetric kem context in the ctx parameter. This function should free any resources associated with that context.

OSSL_FUNC_kem_dupctx() should duplicate the provider side asymmetric kem context in the ctx parameter and return the duplicate copy.

Asymmetric Key Encapsulation Functions

OSSL_FUNC_kem_encapsulate_init() initialises a context for an asymmetric encapsulation given a provider side asymmetric kem context in the ctx parameter, a pointer to a provider key object in the provkey parameter and the name of the algorithm. The params, if not NULL, should be set on the context in a manner similar to using OSSL_FUNC_kem_set_ctx_params(). The key object should have been previously generated, loaded or imported into the provider using the key management (OSSL_OP_KEYMGMT) operation (see provider-keymgmt (7)>.

OSSL_FUNC_kem_auth_encapsulate_init() is similar to OSSL_FUNC_kem_encapsulate_init(), but also passes an additional authentication key provauthkey which cannot be NULL.

OSSL_FUNC_kem_encapsulate() performs the actual encapsulation itself. A previously initialised asymmetric kem context is passed in the ctx parameter. Unless out is NULL, the data to be encapsulated is internally generated, and returned into the buffer pointed to by the secret parameter and the encapsulated data should also be written to the location pointed to by the out parameter. The length of the encapsulated data should be written to *outlen and the length of the generated secret should be written to *secretlen.

If out is NULL then the maximum length of the encapsulated data should be written to *outlen, and the maximum length of the generated secret should be written to *secretlen.

Decapsulation Functions

OSSL_FUNC_kem_decapsulate_init() initialises a context for an asymmetric decapsulation given a provider side asymmetric kem context in the ctx parameter, a pointer to a provider key object in the provkey parameter, and a name of the algorithm. The key object should have been previously generated, loaded or imported into the provider using the key management (OSSL_OP_KEYMGMT) operation (see provider-keymgmt (7)>.

OSSL_FUNC_kem_auth_decapsulate_init() is similar to OSSL_FUNC_kem_decapsulate_init(), but also passes an additional authentication key provauthkey which cannot be NULL.

OSSL_FUNC_kem_decapsulate() performs the actual decapsulation itself. A previously initialised asymmetric kem context is passed in the ctx parameter. The data to be decapsulated is pointed to by the in parameter which is inlen bytes long. Unless out is NULL, the decapsulated data should be written to the location pointed to by the out parameter. The length of the decapsulated data should be written to *outlen. If out is NULL then the maximum length of the decapsulated data should be written to *outlen.

Asymmetric Key Encapsulation Parameters

See OSSL_PARAM (3) for further details on the parameters structure used by the OSSL_FUNC_kem_get_ctx_params() and OSSL_FUNC_kem_set_ctx_params() functions.

OSSL_FUNC_kem_get_ctx_params() gets asymmetric kem parameters associated with the given provider side asymmetric kem context ctx and stores them in params. Passing NULL for params should return true.

OSSL_FUNC_kem_set_ctx_params() sets the asymmetric kem parameters associated with the given provider side asymmetric kem context ctx to params. Any parameter settings are additional to any that were previously set. Passing NULL for params should return true.

No parameters are currently recognised by built-in asymmetric kem algorithms.

OSSL_FUNC_kem_gettable_ctx_params() and OSSL_FUNC_kem_settable_ctx_params() get a constant OSSL_PARAM (3) array that describes the gettable and settable parameters, i.e. parameters that can be used with OSSL_FUNC_kem_get_ctx_params() and OSSL_FUNC_kem_set_ctx_params() respectively.

RETURN VALUES

OSSL_FUNC_kem_newctx() and OSSL_FUNC_kem_dupctx() should return the newly created provider side asymmetric kem context, or NULL on failure.

All other functions should return 1 for success or 0 on error.

SEE ALSO

provider (7)

HISTORY

The provider KEM interface was introduced in OpenSSL 3.0.

OSSL_FUNC_kem_auth_encapsulate_init() and OSSL_FUNC_kem_auth_decapsulate_init() were added in OpenSSL 3.2.

COPYRIGHT

Copyright 2020-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the “License”). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

627 - Linux cli command systemd.index

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command systemd.index and provides detailed information about the command systemd.index, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the systemd.index.

NAME 🖥️ systemd.index 🖥️

List all manpages from the systemd project

3

30-systemd-environment-d-generator(8) — Load variables specified by environment.d

B

binfmt.d(5) — Configure additional binary formats for executables at boot
bootctl(1) — Control EFI firmware boot settings and manage boot loader
bootup(7) — System bootup process
busctl(1) — Introspect the bus

C

[email protected](5) — System unit for the capsule service manager
coredump.conf(5) — Core dump storage configuration files
coredump.conf.d(5) — Core dump storage configuration files
coredumpctl(1) — Retrieve and process saved core dumps and metadata
crypttab(5) — Configuration for encrypted block devices

D

daemon(7) — Writing and packaging system daemons
dnssec-trust-anchors.d(5) — DNSSEC trust anchor configuration files

E

environment.d(5) — Definition of user service environment
extension-release(5) — Operating system identification

F

file-hierarchy(7) — File system hierarchy overview

H

halt(8) — Power off, reboot, or halt the machine
homectl(1) — Create, remove, change or inspect home directories
homed.conf(5) — Home area/user account manager configuration files
homed.conf.d(5) — Home area/user account manager configuration files
hostname(5) — Local hostname configuration file
hostnamectl(1) — Control the system hostname
hwdb(7) — Hardware Database

I

importctl(1) — Download, import or export disk images
init(1) — systemd system and service manager
initrd-release(5) — Operating system identification
integritytab(5) — Configuration for integrity block devices
iocost.conf(5) — Configuration files for the iocost solution manager

J

journal-remote.conf(5) — Configuration files for the service accepting remote journal uploads
journal-remote.conf.d(5) — Configuration files for the service accepting remote journal uploads
journal-upload.conf(5) — Configuration files for the journal upload service
journal-upload.conf.d(5) — Configuration files for the journal upload service
journalctl(1) — Print log entries from the systemd journal
journald.conf(5) — Journal service configuration files
journald.conf.d(5) — Journal service configuration files
[email protected](5) — Journal service configuration files

K

kernel-command-line(7) — Kernel command line parameters
kernel-install(8) — Add and remove kernel and initrd images to and from the boot partition

L

libnss_myhostname.so.2(8) — Hostname resolution for the locally configured system hostname
libnss_mymachines.so.2(8) — Hostname resolution for local container instances
libnss_resolve.so.2(8) — Hostname resolution via systemd-resolved.service
libnss_systemd.so.2(8) — UNIX user and group name resolution for user/group lookup via Varlink
libsystemd(3) — Functions for implementing services and interacting with systemd
libudev(3) — API for enumerating and introspecting local devices
linuxaa64.efi.stub(7) — A simple UEFI kernel boot stub
linuxia32.efi.stub(7) — A simple UEFI kernel boot stub
linuxx64.efi.stub(7) — A simple UEFI kernel boot stub
loader.conf(5) — Configuration file for systemd-boot
locale.conf(5) — Configuration file for locale settings
localectl(1) — Control the system locale and keyboard layout settings
localtime(5) — Local timezone configuration file
loginctl(1) — Control the systemd login manager
logind.conf(5) — Login manager configuration files
logind.conf.d(5) — Login manager configuration files

M

machine-id(5) — Local machine ID configuration file
machine-info(5) — Local machine information file
machinectl(1) — Control the systemd machine manager
modules-load.d(5) — Configure kernel modules to load at boot
mount.ddi(1) — Dissect Discoverable Disk Images (DDIs)

N

networkctl(1) — Query or modify the status of network links
networkd.conf(5) — Global Network configuration files
networkd.conf.d(5) — Global Network configuration files
nss-myhostname(8) — Hostname resolution for the locally configured system hostname
nss-mymachines(8) — Hostname resolution for local container instances
nss-resolve(8) — Hostname resolution via systemd-resolved.service
nss-systemd(8) — UNIX user and group name resolution for user/group lookup via Varlink

O

oomctl(1) — Analyze the state stored in systemd-oomd
oomd.conf(5) — Global systemd-oomd configuration files
oomd.conf.d(5) — Global systemd-oomd configuration files
org.freedesktop.home1(5) — The D-Bus interface of systemd-homed
org.freedesktop.hostname1(5) — The D-Bus interface of systemd-hostnamed
org.freedesktop.import1(5) — The D-Bus interface of systemd-importd
org.freedesktop.locale1(5) — The D-Bus interface of systemd-localed
org.freedesktop.LogControl1(5) — D-Bus interface to query and set logging configuration
org.freedesktop.login1(5) — The D-Bus interface of systemd-logind
org.freedesktop.machine1(5) — The D-Bus interface of systemd-machined
org.freedesktop.network1(5) — The D-Bus interface of systemd-networkd
org.freedesktop.oom1(5) — The D-Bus interface of systemd-oomd
org.freedesktop.portable1(5) — The D-Bus interface of systemd-portabled
org.freedesktop.resolve1(5) — The D-Bus interface of systemd-resolved
org.freedesktop.systemd1(5) — The D-Bus interface of systemd
org.freedesktop.timedate1(5) — The D-Bus interface of systemd-timedated
os-release(5) — Operating system identification

P

pam_systemd(8) — Register user sessions in the systemd login manager
pam_systemd_home(8) — Authenticate users and mount home directories via systemd-homed.service
pam_systemd_loadkey(8) — Read password from kernel keyring and set it as PAM authtok
portablectl(1) — Attach, detach or inspect portable service images
poweroff(8) — Power off, reboot, or halt the machine
pstore.conf(5) — PStore configuration file
pstore.conf.d(5) — PStore configuration file

R

rc-local.service(8) — Compatibility generator and service to start /etc/rc.local during boot
reboot(8) — Power off, reboot, or halt the machine
repart.d(5) — Partition Definition Files for Automatic Boot-Time Repartitioning
resolvconf(1) — Resolve domain names, IPV4 and IPv6 addresses, DNS resource records, and services; introspect and reconfigure the DNS resolver
resolvectl(1) — Resolve domain names, IPV4 and IPv6 addresses, DNS resource records, and services; introspect and reconfigure the DNS resolver
resolved.conf(5) — Network Name Resolution configuration files
resolved.conf.d(5) — Network Name Resolution configuration files
run0(1) — Elevate privileges
runlevel(8) — Print previous and current SysV runlevel

S

sd-boot(7) — A simple UEFI boot manager
sd-bus(3) — A lightweight D-Bus IPC client library
sd-bus-errors(3) — Standard D-Bus error names
sd-daemon(3) — APIs for new-style daemons
sd-device(3) — API for enumerating and introspecting local devices
sd-event(3) — A generic event loop implementation
sd-hwdb(3) — Read-only access to the hardware description database
sd-id128(3) — APIs for processing 128-bit IDs
sd-journal(3) — APIs for submitting and querying log entries to and from the journal
sd-login(3) — APIs for tracking logins
sd-stub(7) — A simple UEFI kernel boot stub
SD_ALERT(3) — APIs for new-style daemons
sd_booted(3) — Test whether the system is running the systemd init system
sd_bus_add_fallback(3) — Declare properties and methods for a D-Bus path
sd_bus_add_fallback_vtable(3) — Declare properties and methods for a D-Bus path
sd_bus_add_filter(3) — Declare properties and methods for a D-Bus path
sd_bus_add_match(3) — Add a match rule for incoming message dispatching
sd_bus_add_match_async(3) — Add a match rule for incoming message dispatching
sd_bus_add_node_enumerator(3) — Add a node enumerator for a D-Bus object path prefix
sd_bus_add_object(3) — Declare properties and methods for a D-Bus path
sd_bus_add_object_manager(3) — Add a D-Bus object manager for a D-Bus object sub-tree
sd_bus_add_object_vtable(3) — Declare properties and methods for a D-Bus path
sd_bus_attach_event(3) — Attach a bus connection object to an event loop
sd_bus_call(3) — Invoke a D-Bus method call
sd_bus_call_async(3) — Invoke a D-Bus method call
sd_bus_call_method(3) — Initialize a bus message object and invoke the corresponding D-Bus method call
sd_bus_call_method_async(3) — Initialize a bus message object and invoke the corresponding D-Bus method call
sd_bus_call_method_asyncv(3) — Initialize a bus message object and invoke the corresponding D-Bus method call
sd_bus_call_methodv(3) — Initialize a bus message object and invoke the corresponding D-Bus method call
sd_bus_can_send(3) — Check which types can be sent over a bus object
sd_bus_close(3) — Close and flush a bus connection
sd_bus_close_unref(3) — Create a new bus object and create or destroy references to it
sd_bus_close_unrefp(3) — Create a new bus object and create or destroy references to it
sd_bus_creds_get_audit_login_uid(3) — Retrieve fields from a credentials object
sd_bus_creds_get_audit_session_id(3) — Retrieve fields from a credentials object
sd_bus_creds_get_augmented_mask(3) — Retrieve credentials object for the specified PID
sd_bus_creds_get_cgroup(3) — Retrieve fields from a credentials object
sd_bus_creds_get_cmdline(3) — Retrieve fields from a credentials object
sd_bus_creds_get_comm(3) — Retrieve fields from a credentials object
sd_bus_creds_get_description(3) — Retrieve fields from a credentials object
sd_bus_creds_get_egid(3) — Retrieve fields from a credentials object
sd_bus_creds_get_euid(3) — Retrieve fields from a credentials object
sd_bus_creds_get_exe(3) — Retrieve fields from a credentials object
sd_bus_creds_get_fsgid(3) — Retrieve fields from a credentials object
sd_bus_creds_get_fsuid(3) — Retrieve fields from a credentials object
sd_bus_creds_get_gid(3) — Retrieve fields from a credentials object
sd_bus_creds_get_mask(3) — Retrieve credentials object for the specified PID
sd_bus_creds_get_owner_uid(3) — Retrieve fields from a credentials object
sd_bus_creds_get_pid(3) — Retrieve fields from a credentials object
sd_bus_creds_get_pidfd_dup(3) — Retrieve fields from a credentials object
sd_bus_creds_get_ppid(3) — Retrieve fields from a credentials object
sd_bus_creds_get_selinux_context(3) — Retrieve fields from a credentials object
sd_bus_creds_get_session(3) — Retrieve fields from a credentials object
sd_bus_creds_get_sgid(3) — Retrieve fields from a credentials object
sd_bus_creds_get_slice(3) — Retrieve fields from a credentials object
sd_bus_creds_get_suid(3) — Retrieve fields from a credentials object
sd_bus_creds_get_supplementary_gids(3) — Retrieve fields from a credentials object
sd_bus_creds_get_tid(3) — Retrieve fields from a credentials object
sd_bus_creds_get_tid_comm(3) — Retrieve fields from a credentials object
sd_bus_creds_get_tty(3) — Retrieve fields from a credentials object
sd_bus_creds_get_uid(3) — Retrieve fields from a credentials object
sd_bus_creds_get_unique_name(3) — Retrieve fields from a credentials object
sd_bus_creds_get_unit(3) — Retrieve fields from a credentials object
sd_bus_creds_get_user_slice(3) — Retrieve fields from a credentials object
sd_bus_creds_get_user_unit(3) — Retrieve fields from a credentials object
sd_bus_creds_get_well_known_names(3) — Retrieve fields from a credentials object
sd_bus_creds_has_bounding_cap(3) — Retrieve fields from a credentials object
sd_bus_creds_has_effective_cap(3) — Retrieve fields from a credentials object
sd_bus_creds_has_inheritable_cap(3) — Retrieve fields from a credentials object
sd_bus_creds_has_permitted_cap(3) — Retrieve fields from a credentials object
sd_bus_creds_new_from_pid(3) — Retrieve credentials object for the specified PID
sd_bus_creds_new_from_pidfd(3) — Retrieve credentials object for the specified PID
sd_bus_creds_ref(3) — Retrieve credentials object for the specified PID
sd_bus_creds_unref(3) — Retrieve credentials object for the specified PID
sd_bus_creds_unrefp(3) — Retrieve credentials object for the specified PID
sd_bus_default(3) — Acquire a connection to a system or user bus
sd_bus_default_flush_close(3) — Close and flush a bus connection
sd_bus_default_system(3) — Acquire a connection to a system or user bus
sd_bus_default_user(3) — Acquire a connection to a system or user bus
sd_bus_destroy_t(3) — Define the callback function for resource cleanup
sd_bus_detach_event(3) — Attach a bus connection object to an event loop
sd_bus_emit_interfaces_added(3) — Convenience functions for emitting (standard) D-Bus signals
sd_bus_emit_interfaces_added_strv(3) — Convenience functions for emitting (standard) D-Bus signals
sd_bus_emit_interfaces_removed(3) — Convenience functions for emitting (standard) D-Bus signals
sd_bus_emit_interfaces_removed_strv(3) — Convenience functions for emitting (standard) D-Bus signals
sd_bus_emit_object_added(3) — Convenience functions for emitting (standard) D-Bus signals
sd_bus_emit_object_removed(3) — Convenience functions for emitting (standard) D-Bus signals
sd_bus_emit_properties_changed(3) — Convenience functions for emitting (standard) D-Bus signals
sd_bus_emit_properties_changed_strv(3) — Convenience functions for emitting (standard) D-Bus signals
sd_bus_emit_signal(3) — Convenience functions for emitting (standard) D-Bus signals
sd_bus_emit_signal_to(3) — Convenience functions for emitting (standard) D-Bus signals
sd_bus_emit_signal_tov(3) — Convenience functions for emitting (standard) D-Bus signals
sd_bus_emit_signalv(3) — Convenience functions for emitting (standard) D-Bus signals
sd_bus_enqueue_for_read(3) — Re-enqueue a bus message on a bus connection, for reading
sd_bus_error(3) — sd-bus error handling
SD_BUS_ERROR_ACCESS_DENIED(3) — Standard D-Bus error names
sd_bus_error_add_map(3) — Additional sd-dbus error mappings
SD_BUS_ERROR_ADDRESS_IN_USE(3) — Standard D-Bus error names
SD_BUS_ERROR_AUTH_FAILED(3) — Standard D-Bus error names
SD_BUS_ERROR_BAD_ADDRESS(3) — Standard D-Bus error names
sd_bus_error_copy(3) — sd-bus error handling
SD_BUS_ERROR_DISCONNECTED(3) — Standard D-Bus error names
SD_BUS_ERROR_END(3) — Additional sd-dbus error mappings
SD_BUS_ERROR_FAILED(3) — Standard D-Bus error names
SD_BUS_ERROR_FILE_EXISTS(3) — Standard D-Bus error names
SD_BUS_ERROR_FILE_NOT_FOUND(3) — Standard D-Bus error names
sd_bus_error_free(3) — sd-bus error handling
sd_bus_error_get_errno(3) — sd-bus error handling
sd_bus_error_has_name(3) — sd-bus error handling
sd_bus_error_has_names(3) — sd-bus error handling
sd_bus_error_has_names_sentinel(3) — sd-bus error handling
SD_BUS_ERROR_INCONSISTENT_MESSAGE(3) — Standard D-Bus error names
SD_BUS_ERROR_INTERACTIVE_AUTHORIZATION_REQUIRED(3) — Standard D-Bus error names
SD_BUS_ERROR_INVALID_ARGS(3) — Standard D-Bus error names
SD_BUS_ERROR_INVALID_FILE_CONTENT(3) — Standard D-Bus error names
SD_BUS_ERROR_INVALID_SIGNATURE(3) — Standard D-Bus error names
SD_BUS_ERROR_IO_ERROR(3) — Standard D-Bus error names
sd_bus_error_is_set(3) — sd-bus error handling
SD_BUS_ERROR_LIMITS_EXCEEDED(3) — Standard D-Bus error names
SD_BUS_ERROR_MAKE_CONST(3) — sd-bus error handling
sd_bus_error_map(3) — Additional sd-dbus error mappings
SD_BUS_ERROR_MAP(3) — Additional sd-dbus error mappings
SD_BUS_ERROR_MATCH_RULE_INVALID(3) — Standard D-Bus error names
SD_BUS_ERROR_MATCH_RULE_NOT_FOUND(3) — Standard D-Bus error names
sd_bus_error_move(3) — sd-bus error handling
SD_BUS_ERROR_NAME_HAS_NO_OWNER(3) — Standard D-Bus error names
SD_BUS_ERROR_NO_MEMORY(3) — Standard D-Bus error names
SD_BUS_ERROR_NO_NETWORK(3) — Standard D-Bus error names
SD_BUS_ERROR_NO_REPLY(3) — Standard D-Bus error names
SD_BUS_ERROR_NO_SERVER(3) — Standard D-Bus error names
SD_BUS_ERROR_NOT_SUPPORTED(3) — Standard D-Bus error names
SD_BUS_ERROR_NULL(3) — sd-bus error handling
SD_BUS_ERROR_OBJECT_PATH_IN_USE(3) — Standard D-Bus error names
SD_BUS_ERROR_PROPERTY_READ_ONLY(3) — Standard D-Bus error names
SD_BUS_ERROR_SELINUX_SECURITY_CONTEXT_UNKNOWN(3) — Standard D-Bus error names
SD_BUS_ERROR_SERVICE_UNKNOWN(3) — Standard D-Bus error names
sd_bus_error_set(3) — sd-bus error handling
sd_bus_error_set_const(3) — sd-bus error handling
sd_bus_error_set_errno(3) — sd-bus error handling
sd_bus_error_set_errnof(3) — sd-bus error handling
sd_bus_error_set_errnofv(3) — sd-bus error handling
sd_bus_error_setf(3) — sd-bus error handling
sd_bus_error_setfv(3) — sd-bus error handling
SD_BUS_ERROR_TIMED_OUT(3) — Standard D-Bus error names
SD_BUS_ERROR_TIMEOUT(3) — Standard D-Bus error names
SD_BUS_ERROR_UNIX_PROCESS_ID_UNKNOWN(3) — Standard D-Bus error names
SD_BUS_ERROR_UNKNOWN_INTERFACE(3) — Standard D-Bus error names
SD_BUS_ERROR_UNKNOWN_METHOD(3) — Standard D-Bus error names
SD_BUS_ERROR_UNKNOWN_OBJECT(3) — Standard D-Bus error names
SD_BUS_ERROR_UNKNOWN_PROPERTY(3) — Standard D-Bus error names
sd_bus_flush(3) — Close and flush a bus connection
sd_bus_flush_close_unref(3) — Create a new bus object and create or destroy references to it
sd_bus_flush_close_unrefp(3) — Create a new bus object and create or destroy references to it
sd_bus_get_address(3) — Set or query the address of the bus connection
sd_bus_get_allow_interactive_authorization(3) — Set or query properties of a bus object
sd_bus_get_bus_id(3) — Configure connection mode for a bus object
sd_bus_get_close_on_exit(3) — Control whether to close the bus connection during the event loop exit phase
sd_bus_get_connected_signal(3) — Control emission of local connection establishment signal on bus connections
sd_bus_get_creds_mask(3) — Control feature negotiation on bus connections
sd_bus_get_current_handler(3) — Query information of the callback a bus object is currently running
sd_bus_get_current_message(3) — Query information of the callback a bus object is currently running
sd_bus_get_current_slot(3) — Query information of the callback a bus object is currently running
sd_bus_get_current_userdata(3) — Query information of the callback a bus object is currently running
sd_bus_get_description(3) — Set or query properties of a bus object
sd_bus_get_event(3) — Attach a bus connection object to an event loop
sd_bus_get_events(3) — Get the file descriptor, I/O events and timeout to wait for from a message bus object
sd_bus_get_exit_on_disconnect(3) — Control the exit behavior when the bus object disconnects
sd_bus_get_fd(3) — Get the file descriptor, I/O events and timeout to wait for from a message bus object
sd_bus_get_method_call_timeout(3) — Set or query the default D-Bus method call timeout of a bus object
sd_bus_get_n_queued_read(3) — Get the number of pending bus messages in the read and write queues of a bus connection object
sd_bus_get_n_queued_write(3) — Get the number of pending bus messages in the read and write queues of a bus connection object
sd_bus_get_name_creds(3) — Query bus client credentials
sd_bus_get_name_machine_id(3) — Retrieve a bus clients machine identity
sd_bus_get_owner_creds(3) — Query bus client credentials
sd_bus_get_property(3) — Set or query D-Bus service properties
sd_bus_get_property_string(3) — Set or query D-Bus service properties
sd_bus_get_property_strv(3) — Set or query D-Bus service properties
sd_bus_get_property_trivial(3) — Set or query D-Bus service properties
sd_bus_get_scope(3) — Set or query properties of a bus object
sd_bus_get_sender(3) — Configure default sender for outgoing messages
sd_bus_get_tid(3) — Set or query properties of a bus object
sd_bus_get_timeout(3) — Get the file descriptor, I/O events and timeout to wait for from a message bus object
sd_bus_get_unique_name(3) — Set or query properties of a bus object
sd_bus_get_watch_bind(3) — Control socket binding watching on bus connections
sd_bus_interface_name_is_valid(3) — Check if a string is a valid bus name or object path
sd_bus_is_anonymous(3) — Set or query properties of a bus object
sd_bus_is_bus_client(3) — Configure connection mode for a bus object
sd_bus_is_monitor(3) — Configure connection mode for a bus object
sd_bus_is_open(3) — Check whether the bus connection is open or ready
sd_bus_is_ready(3) — Check whether the bus connection is open or ready
sd_bus_is_server(3) — Configure connection mode for a bus object
sd_bus_is_trusted(3) — Set or query properties of a bus object
sd_bus_list_names(3) — Retrieve information about registered names on a bus
sd_bus_match_signal(3) — Add a match rule for incoming message dispatching
sd_bus_match_signal_async(3) — Add a match rule for incoming message dispatching
sd_bus_member_name_is_valid(3) — Check if a string is a valid bus name or object path
sd_bus_message_append(3) — Attach fields to a D-Bus message based on a type string
sd_bus_message_append_array(3) — Append an array of fields to a D-Bus message
sd_bus_message_append_array_iovec(3) — Append an array of fields to a D-Bus message
sd_bus_message_append_array_memfd(3) — Append an array of fields to a D-Bus message
sd_bus_message_append_array_space(3) — Append an array of fields to a D-Bus message
sd_bus_message_append_basic(3) — Attach a single field to a message
sd_bus_message_append_string_iovec(3) — Attach a string to a message
sd_bus_message_append_string_memfd(3) — Attach a string to a message
sd_bus_message_append_string_space(3) — Attach a string to a message
sd_bus_message_append_strv(3) — Attach an array of strings to a message
sd_bus_message_appendv(3) — Attach fields to a D-Bus message based on a type string
sd_bus_message_at_end(3) — Check if a message has been fully read
sd_bus_message_close_container(3) — Create and move between containers in D-Bus messages
sd_bus_message_copy(3) — Copy the contents of one message to another
sd_bus_message_dump(3) — Produce a string representation of a message for debugging purposes
sd_bus_message_enter_container(3) — Create and move between containers in D-Bus messages
sd_bus_message_exit_container(3) — Create and move between containers in D-Bus messages
sd_bus_message_get_allow_interactive_authorization(3) — Set and query bus message metadata
sd_bus_message_get_auto_start(3) — Set and query bus message metadata
sd_bus_message_get_bus(3) — Create a new bus message object and create or destroy references to it
sd_bus_message_get_cookie(3) — Returns the transaction cookie of a message
sd_bus_message_get_creds(3) — Query bus message addressing/credentials metadata
sd_bus_message_get_destination(3) — Set and query bus message addressing information
sd_bus_message_get_errno(3) — Query bus message addressing/credentials metadata
sd_bus_message_get_error(3) — Query bus message addressing/credentials metadata
sd_bus_message_get_expect_reply(3) — Set and query bus message metadata
sd_bus_message_get_interface(3) — Set and query bus message addressing information
sd_bus_message_get_member(3) — Set and query bus message addressing information
sd_bus_message_get_monotonic_usec(3) — Retrieve the sender timestamps and sequence number of a message
sd_bus_message_get_path(3) — Set and query bus message addressing information
sd_bus_message_get_realtime_usec(3) — Retrieve the sender timestamps and sequence number of a message
sd_bus_message_get_reply_cookie(3) — Returns the transaction cookie of a message
sd_bus_message_get_sender(3) — Set and query bus message addressing information
sd_bus_message_get_seqnum(3) — Retrieve the sender timestamps and sequence number of a message
sd_bus_message_get_signature(3) — Query bus message signature
sd_bus_message_get_type(3) — Query bus message addressing/credentials metadata
sd_bus_message_has_signature(3) — Query bus message signature
sd_bus_message_is_empty(3) — Query bus message signature
sd_bus_message_is_method_call(3) — Query bus message addressing/credentials metadata
sd_bus_message_is_method_error(3) — Query bus message addressing/credentials metadata
sd_bus_message_is_signal(3) — Query bus message addressing/credentials metadata
SD_BUS_MESSAGE_METHOD_CALL(3) — Create a new bus message object and create or destroy references to it
SD_BUS_MESSAGE_METHOD_ERROR(3) — Create a new bus message object and create or destroy references to it
SD_BUS_MESSAGE_METHOD_RETURN(3) — Create a new bus message object and create or destroy references to it
sd_bus_message_new(3) — Create a new bus message object and create or destroy references to it
sd_bus_message_new_method_call(3) — Create a method call message
sd_bus_message_new_method_errno(3) — Create an error reply for a method call
sd_bus_message_new_method_errnof(3) — Create an error reply for a method call
sd_bus_message_new_method_error(3) — Create an error reply for a method call
sd_bus_message_new_method_errorf(3) — Create an error reply for a method call
sd_bus_message_new_method_return(3) — Create a method call message
sd_bus_message_new_signal(3) — Create a signal message
sd_bus_message_new_signal_to(3) — Create a signal message
sd_bus_message_open_container(3) — Create and move between containers in D-Bus messages
sd_bus_message_peek_type(3) — Read a sequence of values from a message
sd_bus_message_read(3) — Read a sequence of values from a message
sd_bus_message_read_array(3) — Access an array of elements in a message
sd_bus_message_read_basic(3) — Read a basic type from a message
sd_bus_message_read_strv(3) — Access an array of strings in a message
sd_bus_message_read_strv_extend(3) — Access an array of strings in a message
sd_bus_message_readv(3) — Read a sequence of values from a message
sd_bus_message_ref(3) — Create a new bus message object and create or destroy references to it
sd_bus_message_rewind(3) — Return to beginning of message or current container
sd_bus_message_seal(3) — Prepare a D-Bus message for transmission
sd_bus_message_send(3) — Queue a D-Bus message for transfer
sd_bus_message_sensitive(3) — Mark a message object as containing sensitive data
sd_bus_message_set_allow_interactive_authorization(3) — Set and query bus message metadata
sd_bus_message_set_auto_start(3) — Set and query bus message metadata
sd_bus_message_set_destination(3) — Set and query bus message addressing information
sd_bus_message_set_expect_reply(3) — Set and query bus message metadata
sd_bus_message_set_sender(3) — Set and query bus message addressing information
SD_BUS_MESSAGE_SIGNAL(3) — Create a new bus message object and create or destroy references to it
sd_bus_message_skip(3) — Skip elements in a bus message
sd_bus_message_unref(3) — Create a new bus message object and create or destroy references to it
sd_bus_message_unrefp(3) — Create a new bus message object and create or destroy references to it
sd_bus_message_verify_type(3) — Check if the message has specified type at the current location
SD_BUS_METHOD(3) — Declare properties and methods for a D-Bus path
SD_BUS_METHOD_WITH_NAMES(3) — Declare properties and methods for a D-Bus path
SD_BUS_METHOD_WITH_NAMES_OFFSET(3) — Declare properties and methods for a D-Bus path
SD_BUS_METHOD_WITH_OFFSET(3) — Declare properties and methods for a D-Bus path
sd_bus_negotiate_creds(3) — Control feature negotiation on bus connections
sd_bus_negotiate_fds(3) — Control feature negotiation on bus connections
sd_bus_negotiate_timestamp(3) — Control feature negotiation on bus connections
sd_bus_new(3) — Create a new bus object and create or destroy references to it
sd_bus_object_path_is_valid(3) — Check if a string is a valid bus name or object path
sd_bus_open(3) — Acquire a connection to a system or user bus
sd_bus_open_system(3) — Acquire a connection to a system or user bus
sd_bus_open_system_machine(3) — Acquire a connection to a system or user bus
sd_bus_open_system_remote(3) — Acquire a connection to a system or user bus
sd_bus_open_system_with_description(3) — Acquire a connection to a system or user bus
sd_bus_open_user(3) — Acquire a connection to a system or user bus
sd_bus_open_user_machine(3) — Acquire a connection to a system or user bus
sd_bus_open_user_with_description(3) — Acquire a connection to a system or user bus
sd_bus_open_with_description(3) — Acquire a connection to a system or user bus
SD_BUS_PARAM(3) — Declare properties and methods for a D-Bus path
sd_bus_path_decode(3) — Convert an external identifier into an object path and back
sd_bus_path_decode_many(3) — Convert an external identifier into an object path and back
sd_bus_path_encode(3) — Convert an external identifier into an object path and back
sd_bus_path_encode_many(3) — Convert an external identifier into an object path and back
sd_bus_process(3) — Drive the connection
SD_BUS_PROPERTY(3) — Declare properties and methods for a D-Bus path
sd_bus_query_sender_creds(3) — Query bus message sender credentials/privileges
sd_bus_query_sender_privilege(3) — Query bus message sender credentials/privileges
sd_bus_ref(3) — Create a new bus object and create or destroy references to it
sd_bus_release_name(3) — Request or release a well-known service name on a bus
sd_bus_release_name_async(3) — Request or release a well-known service name on a bus
sd_bus_reply_method_errno(3) — Reply with an error to a D-Bus method call
sd_bus_reply_method_errnof(3) — Reply with an error to a D-Bus method call
sd_bus_reply_method_errnofv(3) — Reply with an error to a D-Bus method call
sd_bus_reply_method_error(3) — Reply with an error to a D-Bus method call
sd_bus_reply_method_errorf(3) — Reply with an error to a D-Bus method call
sd_bus_reply_method_errorfv(3) — Reply with an error to a D-Bus method call
sd_bus_reply_method_return(3) — Reply to a D-Bus method call
sd_bus_reply_method_returnv(3) — Reply to a D-Bus method call
sd_bus_request_name(3) — Request or release a well-known service name on a bus
sd_bus_request_name_async(3) — Request or release a well-known service name on a bus
sd_bus_send(3) — Queue a D-Bus message for transfer
sd_bus_send_to(3) — Queue a D-Bus message for transfer
sd_bus_service_name_is_valid(3) — Check if a string is a valid bus name or object path
sd_bus_set_address(3) — Set or query the address of the bus connection
sd_bus_set_allow_interactive_authorization(3) — Set or query properties of a bus object
sd_bus_set_anonymous(3) — Set or query properties of a bus object
sd_bus_set_bus_client(3) — Configure connection mode for a bus object
sd_bus_set_close_on_exit(3) — Control whether to close the bus connection during the event loop exit phase
sd_bus_set_connected_signal(3) — Control emission of local connection establishment signal on bus connections
sd_bus_set_description(3) — Set or query properties of a bus object
sd_bus_set_exec(3) — Set or query the address of the bus connection
sd_bus_set_exit_on_disconnect(3) — Control the exit behavior when the bus object disconnects
sd_bus_set_fd(3) — Set the file descriptors to use for bus communication
sd_bus_set_method_call_timeout(3) — Set or query the default D-Bus method call timeout of a bus object
sd_bus_set_monitor(3) — Configure connection mode for a bus object
sd_bus_set_property(3) — Set or query D-Bus service properties
sd_bus_set_propertyv(3) — Set or query D-Bus service properties
sd_bus_set_sender(3) — Configure default sender for outgoing messages
sd_bus_set_server(3) — Configure connection mode for a bus object
sd_bus_set_trusted(3) — Set or query properties of a bus object
sd_bus_set_watch_bind(3) — Control socket binding watching on bus connections
SD_BUS_SIGNAL(3) — Declare properties and methods for a D-Bus path
SD_BUS_SIGNAL_WITH_NAMES(3) — Declare properties and methods for a D-Bus path
sd_bus_slot_get_bus(3) — Query information attached to a bus slot object
sd_bus_slot_get_current_handler(3) — Query information attached to a bus slot object
sd_bus_slot_get_current_message(3) — Query information attached to a bus slot object
sd_bus_slot_get_current_userdata(3) — Query information attached to a bus slot object
sd_bus_slot_get_description(3) — Set or query the description of bus slot objects
sd_bus_slot_get_destroy_callback(3) — Define the callback function for resource cleanup
sd_bus_slot_get_floating(3) — Control whether a bus slot object is “floating”
sd_bus_slot_get_userdata(3) — Set and query the value in the “userdata” field
sd_bus_slot_ref(3) — Create and destroy references to a bus slot object
sd_bus_slot_set_description(3) — Set or query the description of bus slot objects
sd_bus_slot_set_destroy_callback(3) — Define the callback function for resource cleanup
sd_bus_slot_set_floating(3) — Control whether a bus slot object is “floating”
sd_bus_slot_set_userdata(3) — Set and query the value in the “userdata” field
sd_bus_slot_unref(3) — Create and destroy references to a bus slot object
sd_bus_slot_unrefp(3) — Create and destroy references to a bus slot object
sd_bus_start(3) — Initiate a bus connection to the D-bus broker daemon
sd_bus_track_add_name(3) — Add, remove and retrieve bus peers tracked in a bus peer tracking object
sd_bus_track_add_sender(3) — Add, remove and retrieve bus peers tracked in a bus peer tracking object
sd_bus_track_contains(3) — Add, remove and retrieve bus peers tracked in a bus peer tracking object
sd_bus_track_count(3) — Add, remove and retrieve bus peers tracked in a bus peer tracking object
sd_bus_track_count_name(3) — Add, remove and retrieve bus peers tracked in a bus peer tracking object
sd_bus_track_count_sender(3) — Add, remove and retrieve bus peers tracked in a bus peer tracking object
sd_bus_track_first(3) — Add, remove and retrieve bus peers tracked in a bus peer tracking object
sd_bus_track_get_bus(3) — Track bus peers
sd_bus_track_get_destroy_callback(3) — Define the callback function for resource cleanup
sd_bus_track_get_recursive(3) — Track bus peers
sd_bus_track_get_userdata(3) — Track bus peers
sd_bus_track_new(3) — Track bus peers
sd_bus_track_next(3) — Add, remove and retrieve bus peers tracked in a bus peer tracking object
sd_bus_track_ref(3) — Track bus peers
sd_bus_track_remove_name(3) — Add, remove and retrieve bus peers tracked in a bus peer tracking object
sd_bus_track_remove_sender(3) — Add, remove and retrieve bus peers tracked in a bus peer tracking object
sd_bus_track_set_destroy_callback(3) — Define the callback function for resource cleanup
sd_bus_track_set_recursive(3) — Track bus peers
sd_bus_track_set_userdata(3) — Track bus peers
sd_bus_track_unref(3) — Track bus peers
sd_bus_track_unrefp(3) — Track bus peers
sd_bus_unref(3) — Create a new bus object and create or destroy references to it
sd_bus_unrefp(3) — Create a new bus object and create or destroy references to it
SD_BUS_VTABLE_CAPABILITY(3) — Declare properties and methods for a D-Bus path
SD_BUS_VTABLE_END(3) — Declare properties and methods for a D-Bus path
SD_BUS_VTABLE_START(3) — Declare properties and methods for a D-Bus path
sd_bus_wait(3) — Wait for I/O on a bus connection
SD_BUS_WRITABLE_PROPERTY(3) — Declare properties and methods for a D-Bus path
SD_CRIT(3) — APIs for new-style daemons
SD_DEBUG(3) — APIs for new-style daemons
sd_device_get_devname(3) — Returns various fields of device objects
sd_device_get_devnum(3) — Returns various fields of device objects
sd_device_get_devpath(3) — Returns various fields of device objects
sd_device_get_devtype(3) — Returns various fields of device objects
sd_device_get_diskseq(3) — Returns various fields of device objects
sd_device_get_driver(3) — Returns various fields of device objects
sd_device_get_ifindex(3) — Returns various fields of device objects
sd_device_get_subsystem(3) — Returns various fields of device objects
sd_device_get_sysname(3) — Returns various fields of device objects
sd_device_get_sysnum(3) — Returns various fields of device objects
sd_device_get_syspath(3) — Returns various fields of device objects
sd_device_ref(3) — Create or destroy references to a device object
sd_device_unref(3) — Create or destroy references to a device object
sd_device_unrefp(3) — Create or destroy references to a device object
SD_EMERG(3) — APIs for new-style daemons
SD_ERR(3) — APIs for new-style daemons
sd_event(3) — Acquire and release an event loop object
sd_event_add_child(3) — Add a child process state change event source to an event loop
sd_event_add_child_pidfd(3) — Add a child process state change event source to an event loop
sd_event_add_defer(3) — Add static event sources to an event loop
sd_event_add_exit(3) — Add static event sources to an event loop
sd_event_add_inotify(3) — Add an “inotify” file system inode event source to an event loop
sd_event_add_inotify_fd(3) — Add an “inotify” file system inode event source to an event loop
sd_event_add_io(3) — Add an I/O event source to an event loop
sd_event_add_memory_pressure(3) — Add and configure an event source run as result of memory pressure
sd_event_add_post(3) — Add static event sources to an event loop
sd_event_add_signal(3) — Add a UNIX process signal event source to an event loop
sd_event_add_time(3) — Add a timer event source to an event loop
sd_event_add_time_relative(3) — Add a timer event source to an event loop
SD_EVENT_ARMED(3) — Low-level event loop operations
sd_event_child_handler_t(3) — Add a child process state change event source to an event loop
sd_event_default(3) — Acquire and release an event loop object
sd_event_destroy_t(3) — Define the callback function for resource cleanup
sd_event_dispatch(3) — Low-level event loop operations
sd_event_exit(3) — Ask the event loop to exit
SD_EVENT_EXITING(3) — Low-level event loop operations
SD_EVENT_FINISHED(3) — Low-level event loop operations
sd_event_get_exit_code(3) — Ask the event loop to exit
sd_event_get_fd(3) — Obtain a file descriptor to poll for event loop events
sd_event_get_iteration(3) — Low-level event loop operations
sd_event_get_state(3) — Low-level event loop operations
sd_event_get_tid(3) — Acquire and release an event loop object
sd_event_get_watchdog(3) — Enable event loop watchdog support
sd_event_handler_t(3) — Add static event sources to an event loop
SD_EVENT_INITIAL(3) — Low-level event loop operations
sd_event_inotify_handler_t(3) — Add an “inotify” file system inode event source to an event loop
sd_event_io_handler_t(3) — Add an I/O event source to an event loop
sd_event_loop(3) — Run an event loop
sd_event_new(3) — Acquire and release an event loop object
sd_event_now(3) — Retrieve current event loop iteration timestamp
SD_EVENT_OFF(3) — Enable or disable event sources
SD_EVENT_ON(3) — Enable or disable event sources
SD_EVENT_ONESHOT(3) — Enable or disable event sources
SD_EVENT_PENDING(3) — Low-level event loop operations
sd_event_prepare(3) — Low-level event loop operations
SD_EVENT_PREPARING(3) — Low-level event loop operations
SD_EVENT_PRIORITY_IDLE(3) — Set or retrieve the priority of event sources
SD_EVENT_PRIORITY_IMPORTANT(3) — Set or retrieve the priority of event sources
SD_EVENT_PRIORITY_NORMAL(3) — Set or retrieve the priority of event sources
sd_event_ref(3) — Acquire and release an event loop object
sd_event_run(3) — Run an event loop
SD_EVENT_RUNNING(3) — Low-level event loop operations
sd_event_set_signal_exit(3) — Automatically leave event loop on SIGINT and SIGTERM
sd_event_set_watchdog(3) — Enable event loop watchdog support
sd_event_signal_handler_t(3) — Add a UNIX process signal event source to an event loop
SD_EVENT_SIGNAL_PROCMASK(3) — Add a UNIX process signal event source to an event loop
sd_event_source(3) — Add an I/O event source to an event loop
sd_event_source_disable_unref(3) — Increase or decrease event source reference counters
sd_event_source_disable_unrefp(3) — Increase or decrease event source reference counters
sd_event_source_get_child_pid(3) — Add a child process state change event source to an event loop
sd_event_source_get_child_pidfd(3) — Add a child process state change event source to an event loop
sd_event_source_get_child_pidfd_own(3) — Add a child process state change event source to an event loop
sd_event_source_get_child_process_own(3) — Add a child process state change event source to an event loop
sd_event_source_get_description(3) — Set or retrieve descriptive names of event sources
sd_event_source_get_destroy_callback(3) — Define the callback function for resource cleanup
sd_event_source_get_enabled(3) — Enable or disable event sources
sd_event_source_get_event(3) — Retrieve the event loop of an event source
sd_event_source_get_exit_on_failure(3) — Set or retrieve the exit-on-failure feature of event sources
sd_event_source_get_floating(3) — Set or retrieve floating state of event sources
sd_event_source_get_inotify_mask(3) — Add an “inotify” file system inode event source to an event loop
sd_event_source_get_inotify_path(3) — Add an “inotify” file system inode event source to an event loop
sd_event_source_get_io_events(3) — Add an I/O event source to an event loop
sd_event_source_get_io_fd(3) — Add an I/O event source to an event loop
sd_event_source_get_io_fd_own(3) — Add an I/O event source to an event loop
sd_event_source_get_io_revents(3) — Add an I/O event source to an event loop
sd_event_source_get_pending(3) — Determine pending state of event sources
sd_event_source_get_priority(3) — Set or retrieve the priority of event sources
sd_event_source_get_ratelimit(3) — Configure rate limiting on event sources
sd_event_source_get_signal(3) — Add a UNIX process signal event source to an event loop
sd_event_source_get_time(3) — Add a timer event source to an event loop
sd_event_source_get_time_accuracy(3) — Add a timer event source to an event loop
sd_event_source_get_time_clock(3) — Add a timer event source to an event loop
sd_event_source_get_userdata(3) — Set or retrieve user data pointer of event sources
sd_event_source_is_ratelimited(3) — Configure rate limiting on event sources
sd_event_source_leave_ratelimit(3) — Configure rate limiting on event sources
sd_event_source_ref(3) — Increase or decrease event source reference counters
sd_event_source_send_child_signal(3) — Add a child process state change event source to an event loop
sd_event_source_set_child_pidfd_own(3) — Add a child process state change event source to an event loop
sd_event_source_set_child_process_own(3) — Add a child process state change event source to an event loop
sd_event_source_set_description(3) — Set or retrieve descriptive names of event sources
sd_event_source_set_destroy_callback(3) — Define the callback function for resource cleanup
sd_event_source_set_enabled(3) — Enable or disable event sources
sd_event_source_set_exit_on_failure(3) — Set or retrieve the exit-on-failure feature of event sources
sd_event_source_set_floating(3) — Set or retrieve floating state of event sources
sd_event_source_set_io_events(3) — Add an I/O event source to an event loop
sd_event_source_set_io_fd(3) — Add an I/O event source to an event loop
sd_event_source_set_io_fd_own(3) — Add an I/O event source to an event loop
sd_event_source_set_memory_pressure_period(3) — Add and configure an event source run as result of memory pressure
sd_event_source_set_memory_pressure_type(3) — Add and configure an event source run as result of memory pressure
sd_event_source_set_prepare(3) — Set a preparation callback for event sources
sd_event_source_set_priority(3) — Set or retrieve the priority of event sources
sd_event_source_set_ratelimit(3) — Configure rate limiting on event sources
sd_event_source_set_ratelimit_expire_callback(3) — Configure rate limiting on event sources
sd_event_source_set_time(3) — Add a timer event source to an event loop
sd_event_source_set_time_accuracy(3) — Add a timer event source to an event loop
sd_event_source_set_time_relative(3) — Add a timer event source to an event loop
sd_event_source_set_userdata(3) — Set or retrieve user data pointer of event sources
sd_event_source_unref(3) — Increase or decrease event source reference counters
sd_event_source_unrefp(3) — Increase or decrease event source reference counters
sd_event_time_handler_t(3) — Add a timer event source to an event loop
sd_event_trim_memory(3) — Add and configure an event source run as result of memory pressure
sd_event_unref(3) — Acquire and release an event loop object
sd_event_unrefp(3) — Acquire and release an event loop object
sd_event_wait(3) — Low-level event loop operations
sd_get_machine_names(3) — Determine available seats, sessions, logged in users and virtual machines/containers
sd_get_seats(3) — Determine available seats, sessions, logged in users and virtual machines/containers
sd_get_sessions(3) — Determine available seats, sessions, logged in users and virtual machines/containers
sd_get_uids(3) — Determine available seats, sessions, logged in users and virtual machines/containers
sd_hwdb_enumerate(3) — Seek to a location in hwdb or access entries
SD_HWDB_FOREACH_PROPERTY(3) — Seek to a location in hwdb or access entries
sd_hwdb_get(3) — Seek to a location in hwdb or access entries
sd_hwdb_new(3) — Create a new hwdb object and create or destroy references to it
sd_hwdb_new_from_path(3) — Create a new hwdb object and create or destroy references to it
sd_hwdb_ref(3) — Create a new hwdb object and create or destroy references to it
sd_hwdb_seek(3) — Seek to a location in hwdb or access entries
sd_hwdb_unref(3) — Create a new hwdb object and create or destroy references to it
SD_ID128_ALLF(3) — APIs for processing 128-bit IDs
SD_ID128_CONST_STR(3) — APIs for processing 128-bit IDs
sd_id128_equal(3) — APIs for processing 128-bit IDs
SD_ID128_FORMAT_STR(3) — APIs for processing 128-bit IDs
SD_ID128_FORMAT_VAL(3) — APIs for processing 128-bit IDs
sd_id128_from_string(3) — Format or parse 128-bit IDs as strings
sd_id128_get_app_specific(3) — Retrieve 128-bit IDs
sd_id128_get_boot(3) — Retrieve 128-bit IDs
sd_id128_get_boot_app_specific(3) — Retrieve 128-bit IDs
sd_id128_get_invocation(3) — Retrieve 128-bit IDs
sd_id128_get_machine(3) — Retrieve 128-bit IDs
sd_id128_get_machine_app_specific(3) — Retrieve 128-bit IDs
sd_id128_in_set(3) — APIs for processing 128-bit IDs
sd_id128_in_set_sentinel(3) — APIs for processing 128-bit IDs
sd_id128_in_setv(3) — APIs for processing 128-bit IDs
sd_id128_is_allf(3) — APIs for processing 128-bit IDs
sd_id128_is_null(3) — APIs for processing 128-bit IDs
SD_ID128_MAKE(3) — APIs for processing 128-bit IDs
SD_ID128_MAKE_STR(3) — APIs for processing 128-bit IDs
SD_ID128_MAKE_UUID_STR(3) — APIs for processing 128-bit IDs
SD_ID128_NULL(3) — APIs for processing 128-bit IDs
sd_id128_randomize(3) — Generate 128-bit IDs
sd_id128_string_equal(3) — APIs for processing 128-bit IDs
SD_ID128_STRING_MAX(3) — Format or parse 128-bit IDs as strings
sd_id128_t(3) — APIs for processing 128-bit IDs
sd_id128_to_string(3) — Format or parse 128-bit IDs as strings
SD_ID128_TO_STRING(3) — Format or parse 128-bit IDs as strings
sd_id128_to_uuid_string(3) — Format or parse 128-bit IDs as strings
SD_ID128_TO_UUID_STRING(3) — Format or parse 128-bit IDs as strings
SD_ID128_UUID_FORMAT_STR(3) — APIs for processing 128-bit IDs
SD_ID128_UUID_STRING_MAX(3) — Format or parse 128-bit IDs as strings
SD_INFO(3) — APIs for new-style daemons
sd_is_fifo(3) — Check the type of a file descriptor
sd_is_mq(3) — Check the type of a file descriptor
sd_is_socket(3) — Check the type of a file descriptor
sd_is_socket_inet(3) — Check the type of a file descriptor
sd_is_socket_sockaddr(3) — Check the type of a file descriptor
sd_is_socket_unix(3) — Check the type of a file descriptor
sd_is_special(3) — Check the type of a file descriptor
sd_journal(3) — Open the system journal for reading
sd_journal_add_conjunction(3) — Add or remove entry matches
sd_journal_add_disjunction(3) — Add or remove entry matches
sd_journal_add_match(3) — Add or remove entry matches
SD_JOURNAL_ALL_NAMESPACES(3) — Open the system journal for reading
SD_JOURNAL_APPEND(3) — Journal change notification interface
sd_journal_close(3) — Open the system journal for reading
SD_JOURNAL_CURRENT_USER(3) — Open the system journal for reading
sd_journal_enumerate_available_data(3) — Read data fields from the current journal entry
sd_journal_enumerate_available_unique(3) — Read unique data fields from the journal
sd_journal_enumerate_data(3) — Read data fields from the current journal entry
sd_journal_enumerate_fields(3) — Read used field names from the journal
sd_journal_enumerate_unique(3) — Read unique data fields from the journal
sd_journal_flush_matches(3) — Add or remove entry matches
SD_JOURNAL_FOREACH(3) — Advance or set back the read pointer in the journal
SD_JOURNAL_FOREACH_BACKWARDS(3) — Advance or set back the read pointer in the journal
SD_JOURNAL_FOREACH_DATA(3) — Read data fields from the current journal entry
SD_JOURNAL_FOREACH_FIELD(3) — Read used field names from the journal
SD_JOURNAL_FOREACH_UNIQUE(3) — Read unique data fields from the journal
sd_journal_get_catalog(3) — Retrieve message catalog entry
sd_journal_get_catalog_for_message_id(3) — Retrieve message catalog entry
sd_journal_get_cursor(3) — Get cursor string for or test cursor string against the current journal entry
sd_journal_get_cutoff_monotonic_usec(3) — Read cut-off timestamps from the current journal entry
sd_journal_get_cutoff_realtime_usec(3) — Read cut-off timestamps from the current journal entry
sd_journal_get_data(3) — Read data fields from the current journal entry
sd_journal_get_data_threshold(3) — Read data fields from the current journal entry
sd_journal_get_events(3) — Journal change notification interface
sd_journal_get_fd(3) — Journal change notification interface
sd_journal_get_monotonic_usec(3) — Read timestamps from the current journal entry
sd_journal_get_realtime_usec(3) — Read timestamps from the current journal entry
sd_journal_get_seqnum(3) — Read sequence number from the current journal entry
sd_journal_get_timeout(3) — Journal change notification interface
sd_journal_get_usage(3) — Journal disk usage
sd_journal_has_persistent_files(3) — Query availability of runtime or persistent journal files
sd_journal_has_runtime_files(3) — Query availability of runtime or persistent journal files
SD_JOURNAL_INCLUDE_DEFAULT_NAMESPACE(3) — Open the system journal for reading
SD_JOURNAL_INVALIDATE(3) — Journal change notification interface
SD_JOURNAL_LOCAL_ONLY(3) — Open the system journal for reading
sd_journal_next(3) — Advance or set back the read pointer in the journal
sd_journal_next_skip(3) — Advance or set back the read pointer in the journal
SD_JOURNAL_NOP(3) — Journal change notification interface
sd_journal_open(3) — Open the system journal for reading
sd_journal_open_directory(3) — Open the system journal for reading
sd_journal_open_directory_fd(3) — Open the system journal for reading
sd_journal_open_files(3) — Open the system journal for reading
sd_journal_open_files_fd(3) — Open the system journal for reading
sd_journal_open_namespace(3) — Open the system journal for reading
SD_JOURNAL_OS_ROOT(3) — Open the system journal for reading
sd_journal_perror(3) — Submit log entries to the journal
sd_journal_perror_with_location(3) — Submit log entries to the journal
sd_journal_previous(3) — Advance or set back the read pointer in the journal
sd_journal_previous_skip(3) — Advance or set back the read pointer in the journal
sd_journal_print(3) — Submit log entries to the journal
sd_journal_print_with_location(3) — Submit log entries to the journal
sd_journal_printv(3) — Submit log entries to the journal
sd_journal_printv_with_location(3) — Submit log entries to the journal
sd_journal_process(3) — Journal change notification interface
sd_journal_query_unique(3) — Read unique data fields from the journal
sd_journal_reliable_fd(3) — Journal change notification interface
sd_journal_restart_data(3) — Read data fields from the current journal entry
sd_journal_restart_fields(3) — Read used field names from the journal
sd_journal_restart_unique(3) — Read unique data fields from the journal
SD_JOURNAL_RUNTIME_ONLY(3) — Open the system journal for reading
sd_journal_seek_cursor(3) — Seek to a position in the journal
sd_journal_seek_head(3) — Seek to a position in the journal
sd_journal_seek_monotonic_usec(3) — Seek to a position in the journal
sd_journal_seek_realtime_usec(3) — Seek to a position in the journal
sd_journal_seek_tail(3) — Seek to a position in the journal
sd_journal_send(3) — Submit log entries to the journal
sd_journal_send_with_location(3) — Submit log entries to the journal
sd_journal_sendv(3) — Submit log entries to the journal
sd_journal_sendv_with_location(3) — Submit log entries to the journal
sd_journal_set_data_threshold(3) — Read data fields from the current journal entry
sd_journal_step_one(3) — Advance or set back the read pointer in the journal
sd_journal_stream_fd(3) — Create log stream file descriptor to the journal
sd_journal_stream_fd_with_namespace(3) — Create log stream file descriptor to the journal
SD_JOURNAL_SUPPRESS_LOCATION(3) — Submit log entries to the journal
SD_JOURNAL_SYSTEM(3) — Open the system journal for reading
SD_JOURNAL_TAKE_DIRECTORY_FD(3) — Open the system journal for reading
sd_journal_test_cursor(3) — Get cursor string for or test cursor string against the current journal entry
sd_journal_wait(3) — Journal change notification interface
sd_listen_fds(3) — Check for file descriptors passed by the system manager
SD_LISTEN_FDS_START(3) — Check for file descriptors passed by the system manager
sd_listen_fds_with_names(3) — Check for file descriptors passed by the system manager
sd_login_monitor(3) — Monitor login sessions, seats, users and virtual machines/containers
sd_login_monitor_flush(3) — Monitor login sessions, seats, users and virtual machines/containers
sd_login_monitor_get_events(3) — Monitor login sessions, seats, users and virtual machines/containers
sd_login_monitor_get_fd(3) — Monitor login sessions, seats, users and virtual machines/containers
sd_login_monitor_get_timeout(3) — Monitor login sessions, seats, users and virtual machines/containers
sd_login_monitor_new(3) — Monitor login sessions, seats, users and virtual machines/containers
sd_login_monitor_unref(3) — Monitor login sessions, seats, users and virtual machines/containers
sd_login_monitor_unrefp(3) — Monitor login sessions, seats, users and virtual machines/containers
sd_machine_get_class(3) — Determine the class and network interface indices of a locally running virtual machine or container
sd_machine_get_ifindices(3) — Determine the class and network interface indices of a locally running virtual machine or container
SD_NOTICE(3) — APIs for new-style daemons
sd_notify(3) — Notify service manager about start-up completion and other service status changes
sd_notify_barrier(3) — Notify service manager about start-up completion and other service status changes
sd_notifyf(3) — Notify service manager about start-up completion and other service status changes
sd_path_lookup(3) — Query well-known file system paths
sd_path_lookup_strv(3) — Query well-known file system paths
sd_peer_get_cgroup(3) — Determine the owner uid of the user unit or session, or the session, user unit, system unit, container/VM or slice that a specific PID or socket peer belongs to
sd_peer_get_machine_name(3) — Determine the owner uid of the user unit or session, or the session, user unit, system unit, container/VM or slice that a specific PID or socket peer belongs to
sd_peer_get_owner_uid(3) — Determine the owner uid of the user unit or session, or the session, user unit, system unit, container/VM or slice that a specific PID or socket peer belongs to
sd_peer_get_session(3) — Determine the owner uid of the user unit or session, or the session, user unit, system unit, container/VM or slice that a specific PID or socket peer belongs to
sd_peer_get_slice(3) — Determine the owner uid of the user unit or session, or the session, user unit, system unit, container/VM or slice that a specific PID or socket peer belongs to
sd_peer_get_unit(3) — Determine the owner uid of the user unit or session, or the session, user unit, system unit, container/VM or slice that a specific PID or socket peer belongs to
sd_peer_get_user_slice(3) — Determine the owner uid of the user unit or session, or the session, user unit, system unit, container/VM or slice that a specific PID or socket peer belongs to
sd_peer_get_user_unit(3) — Determine the owner uid of the user unit or session, or the session, user unit, system unit, container/VM or slice that a specific PID or socket peer belongs to
sd_pid_get_cgroup(3) — Determine the owner uid of the user unit or session, or the session, user unit, system unit, container/VM or slice that a specific PID or socket peer belongs to
sd_pid_get_machine_name(3) — Determine the owner uid of the user unit or session, or the session, user unit, system unit, container/VM or slice that a specific PID or socket peer belongs to
sd_pid_get_owner_uid(3) — Determine the owner uid of the user unit or session, or the session, user unit, system unit, container/VM or slice that a specific PID or socket peer belongs to
sd_pid_get_session(3) — Determine the owner uid of the user unit or session, or the session, user unit, system unit, container/VM or slice that a specific PID or socket peer belongs to
sd_pid_get_slice(3) — Determine the owner uid of the user unit or session, or the session, user unit, system unit, container/VM or slice that a specific PID or socket peer belongs to
sd_pid_get_unit(3) — Determine the owner uid of the user unit or session, or the session, user unit, system unit, container/VM or slice that a specific PID or socket peer belongs to
sd_pid_get_user_slice(3) — Determine the owner uid of the user unit or session, or the session, user unit, system unit, container/VM or slice that a specific PID or socket peer belongs to
sd_pid_get_user_unit(3) — Determine the owner uid of the user unit or session, or the session, user unit, system unit, container/VM or slice that a specific PID or socket peer belongs to
sd_pid_notify(3) — Notify service manager about start-up completion and other service status changes
sd_pid_notify_barrier(3) — Notify service manager about start-up completion and other service status changes
sd_pid_notify_with_fds(3) — Notify service manager about start-up completion and other service status changes
sd_pid_notifyf(3) — Notify service manager about start-up completion and other service status changes
sd_pid_notifyf_with_fds(3) — Notify service manager about start-up completion and other service status changes
sd_pidfd_get_cgroup(3) — Determine the owner uid of the user unit or session, or the session, user unit, system unit, container/VM or slice that a specific PID or socket peer belongs to
sd_pidfd_get_machine_name(3) — Determine the owner uid of the user unit or session, or the session, user unit, system unit, container/VM or slice that a specific PID or socket peer belongs to
sd_pidfd_get_owner_uid(3) — Determine the owner uid of the user unit or session, or the session, user unit, system unit, container/VM or slice that a specific PID or socket peer belongs to
sd_pidfd_get_session(3) — Determine the owner uid of the user unit or session, or the session, user unit, system unit, container/VM or slice that a specific PID or socket peer belongs to
sd_pidfd_get_slice(3) — Determine the owner uid of the user unit or session, or the session, user unit, system unit, container/VM or slice that a specific PID or socket peer belongs to
sd_pidfd_get_unit(3) — Determine the owner uid of the user unit or session, or the session, user unit, system unit, container/VM or slice that a specific PID or socket peer belongs to
sd_pidfd_get_user_slice(3) — Determine the owner uid of the user unit or session, or the session, user unit, system unit, container/VM or slice that a specific PID or socket peer belongs to
sd_pidfd_get_user_unit(3) — Determine the owner uid of the user unit or session, or the session, user unit, system unit, container/VM or slice that a specific PID or socket peer belongs to
sd_seat_can_graphical(3) — Determine state of a specific seat
sd_seat_can_tty(3) — Determine state of a specific seat
sd_seat_get_active(3) — Determine state of a specific seat
sd_seat_get_sessions(3) — Determine state of a specific seat
sd_session_get_class(3) — Determine state of a specific session
sd_session_get_desktop(3) — Determine state of a specific session
sd_session_get_display(3) — Determine state of a specific session
sd_session_get_leader(3) — Determine state of a specific session
sd_session_get_remote_host(3) — Determine state of a specific session
sd_session_get_remote_user(3) — Determine state of a specific session
sd_session_get_seat(3) — Determine state of a specific session
sd_session_get_service(3) — Determine state of a specific session
sd_session_get_start_time(3) — Determine state of a specific session
sd_session_get_state(3) — Determine state of a specific session
sd_session_get_tty(3) — Determine state of a specific session
sd_session_get_type(3) — Determine state of a specific session
sd_session_get_uid(3) — Determine state of a specific session
sd_session_get_username(3) — Determine state of a specific session
sd_session_get_vt(3) — Determine state of a specific session
sd_session_is_active(3) — Determine state of a specific session
sd_session_is_remote(3) — Determine state of a specific session
sd_uid_get_display(3) — Determine login state of a specific Unix user ID
sd_uid_get_login_time(3) — Determine login state of a specific Unix user ID
sd_uid_get_seats(3) — Determine login state of a specific Unix user ID
sd_uid_get_sessions(3) — Determine login state of a specific Unix user ID
sd_uid_get_state(3) — Determine login state of a specific Unix user ID
sd_uid_is_on_seat(3) — Determine login state of a specific Unix user ID
SD_WARNING(3) — APIs for new-style daemons
sd_watchdog_enabled(3) — Check whether the service manager expects watchdog keep-alive notifications from a service
shutdown(8) — Halt, power off or reboot the machine
sleep.conf.d(5) — Suspend and hibernation configuration file
smbios-type-11(7) — SMBIOS Type 11 strings
sysctl.d(5) — Configure kernel parameters at boot
system.conf.d(5) — System and session service manager configuration files
systemctl(1) — Control the systemd system and service manager
systemd(1) — systemd system and service manager
systemd-ac-power(1) — Report whether we are connected to an external power source
systemd-analyze(1) — Analyze and debug system manager
systemd-ask-password(1) — Query the user for a system password
systemd-ask-password-console.path(8) — Query the user for system passwords on the console and via wall
systemd-ask-password-console.service(8) — Query the user for system passwords on the console and via wall
systemd-ask-password-wall.path(8) — Query the user for system passwords on the console and via wall
systemd-ask-password-wall.service(8) — Query the user for system passwords on the console and via wall
systemd-backlight(8) — Load and save the display backlight brightness at boot and shutdown
[email protected](8) — Load and save the display backlight brightness at boot and shutdown
systemd-battery-check(8) — Check battery level whether theres enough charge, and power off if not
systemd-battery-check.service(8) — Check battery level whether theres enough charge, and power off if not
systemd-binfmt(8) — Configure additional binary formats for executables at boot
systemd-binfmt.service(8) — Configure additional binary formats for executables at boot
systemd-bless-boot(8) — Mark current boot process as successful
systemd-bless-boot-generator(8) — Pull systemd-bless-boot.service into the initial boot transaction when boot counting is in effect
systemd-bless-boot.service(8) — Mark current boot process as successful
systemd-boot(7) — A simple UEFI boot manager
systemd-boot-check-no-failures(8) — verify that the system booted up cleanly
systemd-boot-check-no-failures.service(8) — verify that the system booted up cleanly
systemd-boot-random-seed.service(8) — Refresh boot loader random seed at boot
systemd-bsod(8) — Displays boot-time emergency log message in full screen
systemd-bsod.service(8) — Displays boot-time emergency log message in full screen
systemd-cat(1) — Connect a pipeline or programs output with the journal
systemd-cgls(1) — Recursively show control group contents
systemd-cgtop(1) — Show top control groups by their resource usage
systemd-confext(8) — Activates System Extension Images
systemd-confext.service(8) — Activates System Extension Images
systemd-coredump(8) — Acquire, save and process core dumps
systemd-coredump.socket(8) — Acquire, save and process core dumps
[email protected](8) — Acquire, save and process core dumps
systemd-creds(1) — Lists, shows, encrypts and decrypts service credentials
systemd-cryptenroll(1) — Enroll PKCS#11, FIDO2, TPM2 token/devices to LUKS2 encrypted volumes
systemd-cryptsetup(8) — Full disk decryption logic
systemd-cryptsetup-generator(8) — Unit generator for /etc/crypttab
[email protected](8) — Full disk decryption logic
systemd-debug-generator(8) — Generator for enabling a runtime debug shell and masking specific units at boot
systemd-delta(1) — Find overridden configuration files
systemd-detect-virt(1) — Detect execution in a virtualized environment
systemd-dissect(1) — Dissect Discoverable Disk Images (DDIs)
systemd-environment-d-generator(8) — Load variables specified by environment.d
systemd-escape(1) — Escape strings for usage in systemd unit names
systemd-firstboot(1) — Initialize basic system settings on or before the first boot-up of a system
systemd-firstboot.service(1) — Initialize basic system settings on or before the first boot-up of a system
systemd-fsck(8) — File system checker logic
systemd-fsck-root.service(8) — File system checker logic
systemd-fsck-usr.service(8) — File system checker logic
[email protected](8) — File system checker logic
systemd-fstab-generator(8) — Unit generator for /etc/fstab
systemd-getty-generator(8) — Generator for enabling getty instances on the console
systemd-gpt-auto-generator(8) — Generator for automatically discovering and mounting root, /home/ , /srv/ , /var/ and /var/tmp/ partitions, as well as discovering and enabling swap partitions, based on GPT partition type GUIDs
systemd-growfs(8) — Creating and growing file systems on demand
systemd-growfs-root.service(8) — Creating and growing file systems on demand
[email protected](8) — Creating and growing file systems on demand
systemd-halt.service(8) — System shutdown logic
systemd-hibernate-clear.service(8) — Resume from hibernation
systemd-hibernate-resume(8) — Resume from hibernation
systemd-hibernate-resume-generator(8) — Unit generator for resume= kernel parameter
systemd-hibernate-resume.service(8) — Resume from hibernation
systemd-hibernate.service(8) — System sleep state logic
systemd-homed(8) — Home Area/User Account Manager
systemd-homed-firstboot.service(1) — Create, remove, change or inspect home directories
systemd-homed.service(8) — Home Area/User Account Manager
systemd-hostnamed(8) — Daemon to control system hostname from programs
systemd-hostnamed.service(8) — Daemon to control system hostname from programs
systemd-hwdb(8) — hardware database management tool
systemd-hybrid-sleep.service(8) — System sleep state logic
systemd-id128(1) — Generate and print sd-128 identifiers
systemd-importd(8) — VM and container image import and export service
systemd-importd.service(8) — VM and container image import and export service
systemd-inhibit(1) — Execute a program with an inhibition lock taken
systemd-initctl(8) — /dev/initctl compatibility
systemd-initctl.service(8) — /dev/initctl compatibility
systemd-initctl.socket(8) — /dev/initctl compatibility
systemd-integritysetup(8) — Disk integrity protection logic
systemd-integritysetup-generator(8) — Unit generator for integrity protected block devices
[email protected](8) — Disk integrity protection logic
systemd-journal-gatewayd(8) — HTTP server for journal events
systemd-journal-gatewayd.service(8) — HTTP server for journal events
systemd-journal-gatewayd.socket(8) — HTTP server for journal events
systemd-journal-remote(8) — Receive journal messages over the network
systemd-journal-remote.service(8) — Receive journal messages over the network
systemd-journal-remote.socket(8) — Receive journal messages over the network
systemd-journal-upload(8) — Send journal messages over the network
systemd-journal-upload.service(8) — Send journal messages over the network
systemd-journald(8) — Journal service
systemd-journald-audit.socket(8) — Journal service
systemd-journald-dev-log.socket(8) — Journal service
[email protected](8) — Journal service
systemd-journald.service(8) — Journal service
systemd-journald.socket(8) — Journal service
[email protected](8) — Journal service
[email protected](8) — Journal service
systemd-kexec.service(8) — System shutdown logic
systemd-localed(8) — Locale bus mechanism
systemd-localed.service(8) — Locale bus mechanism
systemd-logind(8) — Login manager
systemd-logind.service(8) — Login manager
systemd-machine-id-commit.service(8) — Commit a transient machine ID to disk
systemd-machine-id-setup(1) — Initialize the machine ID in /etc/machine-id
systemd-machined(8) — Virtual machine and container registration manager
systemd-machined.service(8) — Virtual machine and container registration manager
systemd-makefs(8) — Creating and growing file systems on demand
[email protected](8) — Creating and growing file systems on demand
systemd-measure(1) — Pre-calculate and sign expected TPM2 PCR values for booted unified kernel images
[email protected](8) — Creating and growing file systems on demand
systemd-modules-load(8) — Load kernel modules at boot
systemd-modules-load.service(8) — Load kernel modules at boot
systemd-mount(1) — Establish and destroy transient mount or auto-mount points
systemd-mountfsd(8) — Disk Image File System Mount Service
systemd-mountfsd.service(8) — Disk Image File System Mount Service
systemd-network-generator(8) — Generate network configuration from the kernel command line
systemd-network-generator.service(8) — Generate network configuration from the kernel command line
systemd-networkd(8) — Network manager
systemd-networkd-wait-online(8) — Wait for network to come online
systemd-networkd-wait-online.service(8) — Wait for network to come online
[email protected](8) — Wait for network to come online
systemd-networkd.service(8) — Network manager
systemd-notify(1) — Notify service manager about start-up completion and other daemon status changes
systemd-nspawn(1) — Spawn a command or OS in a light-weight container
systemd-nsresourced(8) — User Namespace Resource Delegation Service
systemd-nsresourced.service(8) — User Namespace Resource Delegation Service
systemd-oomd(8) — A userspace out-of-memory (OOM) killer
systemd-oomd.service(8) — A userspace out-of-memory (OOM) killer
systemd-path(1) — List and query system and user paths
systemd-pcrextend(8) — Measure boot phase into TPM2 PCR 11, machine ID and file system identity into PCR 15
systemd-pcrfs-root.service(8) — Measure boot phase into TPM2 PCR 11, machine ID and file system identity into PCR 15
[email protected](8) — Measure boot phase into TPM2 PCR 11, machine ID and file system identity into PCR 15
systemd-pcrlock(8) — Analyze and predict TPM2 PCR states and generate an access policy from the prediction
systemd-pcrlock-file-system.service(8) — Analyze and predict TPM2 PCR states and generate an access policy from the prediction
systemd-pcrlock-firmware-code.service(8) — Analyze and predict TPM2 PCR states and generate an access policy from the prediction
systemd-pcrlock-firmware-config.service(8) — Analyze and predict TPM2 PCR states and generate an access policy from the prediction
systemd-pcrlock-machine-id.service(8) — Analyze and predict TPM2 PCR states and generate an access policy from the prediction
systemd-pcrlock-make-policy.service(8) — Analyze and predict TPM2 PCR states and generate an access policy from the prediction
systemd-pcrlock-secureboot-authority.service(8) — Analyze and predict TPM2 PCR states and generate an access policy from the prediction
systemd-pcrlock-secureboot-policy.service(8) — Analyze and predict TPM2 PCR states and generate an access policy from the prediction
systemd-pcrmachine.service(8) — Measure boot phase into TPM2 PCR 11, machine ID and file system identity into PCR 15
systemd-pcrphase-initrd.service(8) — Measure boot phase into TPM2 PCR 11, machine ID and file system identity into PCR 15
systemd-pcrphase-sysinit.service(8) — Measure boot phase into TPM2 PCR 11, machine ID and file system identity into PCR 15
systemd-pcrphase.service(8) — Measure boot phase into TPM2 PCR 11, machine ID and file system identity into PCR 15
systemd-portabled(8) — Portable service manager
systemd-portabled.service(8) — Portable service manager
systemd-poweroff.service(8) — System shutdown logic
systemd-pstore(8) — A service to archive contents of pstore
systemd-pstore.service(8) — A service to archive contents of pstore
systemd-quotacheck(8) — File system quota checker logic
systemd-quotacheck.service(8) — File system quota checker logic
systemd-random-seed(8) — Load and save the OS system random seed at boot and shutdown
systemd-random-seed.service(8) — Load and save the OS system random seed at boot and shutdown
systemd-rc-local-generator(8) — Compatibility generator and service to start /etc/rc.local during boot
systemd-reboot.service(8) — System shutdown logic
systemd-remount-fs(8) — Remount root and kernel file systems
systemd-remount-fs.service(8) — Remount root and kernel file systems
systemd-repart(8) — Automatically grow and add partitions
systemd-repart.service(8) — Automatically grow and add partitions
systemd-resolved(8) — Network Name Resolution manager
systemd-resolved.service(8) — Network Name Resolution manager
systemd-rfkill(8) — Load and save the RF kill switch state at boot and change
systemd-rfkill.service(8) — Load and save the RF kill switch state at boot and change
systemd-rfkill.socket(8) — Load and save the RF kill switch state at boot and change
systemd-run(1) — Run programs in transient scope units, service units, or path-, socket-, or timer-triggered service units
systemd-run-generator(8) — Generator for invoking commands specified on the kernel command line as system service
systemd-shutdown(8) — System shutdown logic
systemd-sleep(8) — System sleep state logic
systemd-sleep.conf(5) — Suspend and hibernation configuration file
systemd-socket-activate(1) — Test socket activation of daemons
systemd-socket-proxyd(8) — Bidirectionally proxy local sockets to another (possibly remote) socket
systemd-soft-reboot.service(8) — Userspace reboot operation
systemd-ssh-generator(8) — Generator for binding a socket-activated SSH server to local AF_VSOCK and AF_UNIX sockets
systemd-ssh-proxy(1) — SSH client plugin for connecting to AF_VSOCK and AF_UNIX sockets
systemd-stdio-bridge(1) — D-Bus proxy
systemd-storagetm(8) — Exposes all local block devices as NVMe-TCP mass storage devices
systemd-storagetm.service(8) — Exposes all local block devices as NVMe-TCP mass storage devices
systemd-stub(7) — A simple UEFI kernel boot stub
systemd-suspend-then-hibernate.service(8) — System sleep state logic
systemd-suspend.service(8) — System sleep state logic
systemd-sysctl(8) — Configure kernel parameters at boot
systemd-sysctl.service(8) — Configure kernel parameters at boot
systemd-sysext(8) — Activates System Extension Images
systemd-sysext.service(8) — Activates System Extension Images
systemd-system-update-generator(8) — Generator for redirecting boot to offline update mode
systemd-system.conf(5) — System and session service manager configuration files
systemd-sysupdate(8) — Automatically Update OS or Other Resources
systemd-sysupdate-reboot.service(8) — Automatically Update OS or Other Resources
systemd-sysupdate-reboot.timer(8) — Automatically Update OS or Other Resources
systemd-sysupdate.service(8) — Automatically Update OS or Other Resources
systemd-sysupdate.timer(8) — Automatically Update OS or Other Resources
systemd-sysusers(8) — Allocate system users and groups
systemd-sysusers.service(8) — Allocate system users and groups
systemd-sysv-generator(8) — Unit generator for SysV init scripts
systemd-time-wait-sync(8) — Wait until kernel time is synchronized
systemd-time-wait-sync.service(8) — Wait until kernel time is synchronized
systemd-timedated(8) — Time and date bus mechanism
systemd-timedated.service(8) — Time and date bus mechanism
systemd-timesyncd(8) — Network Time Synchronization
systemd-timesyncd.service(8) — Network Time Synchronization
systemd-tmpfiles(8) — Create, delete, and clean up files and directories
systemd-tmpfiles-clean.service(8) — Create, delete, and clean up files and directories
systemd-tmpfiles-clean.timer(8) — Create, delete, and clean up files and directories
systemd-tmpfiles-setup-dev-early.service(8) — Create, delete, and clean up files and directories
systemd-tmpfiles-setup-dev.service(8) — Create, delete, and clean up files and directories
systemd-tmpfiles-setup.service(8) — Create, delete, and clean up files and directories
systemd-tpm2-generator(8) — Generator for inserting TPM2 synchronization point in the boot process
systemd-tpm2-setup(8) — Set up the TPM2 Storage Root Key (SRK) at boot
systemd-tpm2-setup-early.service(8) — Set up the TPM2 Storage Root Key (SRK) at boot
systemd-tpm2-setup.service(8) — Set up the TPM2 Storage Root Key (SRK) at boot
systemd-tty-ask-password-agent(1) — List or process pending systemd password requests
systemd-udev-settle.service(8) — Wait for all pending udev events to be handled
systemd-udevd(8) — Device event managing daemon
systemd-udevd-control.socket(8) — Device event managing daemon
systemd-udevd-kernel.socket(8) — Device event managing daemon
systemd-udevd.service(8) — Device event managing daemon
systemd-umount(1) — Establish and destroy transient mount or auto-mount points
systemd-update-done(8) — Mark /etc/ and /var/ fully updated
systemd-update-done.service(8) — Mark /etc/ and /var/ fully updated
systemd-update-utmp(8) — Write audit and utmp updates at bootup, runlevel changes and shutdown
systemd-update-utmp-runlevel.service(8) — Write audit and utmp updates at bootup, runlevel changes and shutdown
systemd-update-utmp.service(8) — Write audit and utmp updates at bootup, runlevel changes and shutdown
systemd-user-runtime-dir(5) — System units to start the user manager
systemd-user-sessions(8) — Permit user logins after boot, prohibit user logins at shutdown
systemd-user-sessions.service(8) — Permit user logins after boot, prohibit user logins at shutdown
systemd-user.conf(5) — System and session service manager configuration files
systemd-userdbd(8) — JSON User/Group Record Query Multiplexer/NSS Compatibility
systemd-userdbd.service(8) — JSON User/Group Record Query Multiplexer/NSS Compatibility
systemd-veritysetup(8) — Disk verity protection logic
systemd-veritysetup-generator(8) — Unit generator for verity protected block devices
[email protected](8) — Disk verity protection logic
systemd-volatile-root(8) — Make the root file system volatile
systemd-volatile-root.service(8) — Make the root file system volatile
systemd-vpick(1) — Resolve paths to .v/ versioned directories
systemd-xdg-autostart-generator(8) — User unit generator for XDG autostart files
systemd.automount(5) — Automount unit configuration
systemd.device(5) — Device unit configuration
systemd.directives(7) — Index of configuration directives
systemd.dnssd(5) — DNS-SD configuration
systemd.environment-generator(7) — systemd environment file generators
systemd.exec(5) — Execution environment configuration
systemd.generator(7) — systemd unit generators
systemd.image-policy(7) — Disk Image Dissection Policy
systemd.journal-fields(7) — Special journal fields
systemd.kill(5) — Process killing procedure configuration
systemd.link(5) — Network device configuration
systemd.mount(5) — Mount unit configuration
systemd.negative(5) — DNSSEC trust anchor configuration files
systemd.net-naming-scheme(7) — Network device naming schemes
systemd.netdev(5) — Virtual Network Device configuration
systemd.network(5) — Network configuration
systemd.nspawn(5) — Container settings
systemd.offline-updates(7) — Implementation of offline updates in systemd
systemd.path(5) — Path unit configuration
systemd.pcrlock(5) — PCR measurement prediction files
systemd.pcrlock.d(5) — PCR measurement prediction files
systemd.positive(5) — DNSSEC trust anchor configuration files
systemd.preset(5) — Service enablement presets
systemd.resource-control(5) — Resource control unit settings
systemd.scope(5) — Scope unit configuration
systemd.service(5) — Service unit configuration
systemd.slice(5) — Slice unit configuration
systemd.socket(5) — Socket unit configuration
systemd.special(7) — Special systemd units
systemd.swap(5) — Swap unit configuration
systemd.syntax(7) — General syntax of systemd configuration files
systemd.system-credentials(7) — System Credentials
systemd.target(5) — Target unit configuration
systemd.time(7) — Time and date specifications
systemd.timer(5) — Timer unit configuration
systemd.unit(5) — Unit configuration
systemd.v(7) — Directory with Versioned Resources
sysupdate.d(5) — Transfer Definition Files for Automatic Updates
sysusers.d(5) — Declarative allocation of system users and groups

T

telinit(8) — Change SysV runlevel
timedatectl(1) — Control the system time and date
timesyncd.conf(5) — Network Time Synchronization configuration files
timesyncd.conf.d(5) — Network Time Synchronization configuration files
tmpfiles.d(5) — Configuration for creation, deletion, and cleaning of files and directories

U

udev(7) — Dynamic device management
udev.conf(5) — Configuration for device event managing daemon
udev.conf.d(5) — Configuration for device event managing daemon
udev_device_get_action(3) — Query device properties
udev_device_get_current_tags_list_entry(3) — Retrieve or set device attributes
udev_device_get_devlinks_list_entry(3) — Retrieve or set device attributes
udev_device_get_devnode(3) — Query device properties
udev_device_get_devnum(3) — Query device properties
udev_device_get_devpath(3) — Query device properties
udev_device_get_devtype(3) — Query device properties
udev_device_get_driver(3) — Query device properties
udev_device_get_is_initialized(3) — Query device properties
udev_device_get_parent(3) — Query device properties
udev_device_get_parent_with_subsystem_devtype(3) — Query device properties
udev_device_get_properties_list_entry(3) — Retrieve or set device attributes
udev_device_get_property_value(3) — Retrieve or set device attributes
udev_device_get_subsystem(3) — Query device properties
udev_device_get_sysattr_list_entry(3) — Retrieve or set device attributes
udev_device_get_sysattr_value(3) — Retrieve or set device attributes
udev_device_get_sysname(3) — Query device properties
udev_device_get_sysnum(3) — Query device properties
udev_device_get_syspath(3) — Query device properties
udev_device_get_tags_list_entry(3) — Retrieve or set device attributes
udev_device_get_udev(3) — Query device properties
udev_device_has_current_tag(3) — Retrieve or set device attributes
udev_device_has_tag(3) — Retrieve or set device attributes
udev_device_new_from_device_id(3) — Create, acquire and release a udev device object
udev_device_new_from_devnum(3) — Create, acquire and release a udev device object
udev_device_new_from_environment(3) — Create, acquire and release a udev device object
udev_device_new_from_subsystem_sysname(3) — Create, acquire and release a udev device object
udev_device_new_from_syspath(3) — Create, acquire and release a udev device object
udev_device_ref(3) — Create, acquire and release a udev device object
udev_device_set_sysattr_value(3) — Retrieve or set device attributes
udev_device_unref(3) — Create, acquire and release a udev device object
udev_enumerate_add_match_is_initialized(3) — Modify filters
udev_enumerate_add_match_parent(3) — Modify filters
udev_enumerate_add_match_property(3) — Modify filters
udev_enumerate_add_match_subsystem(3) — Modify filters
udev_enumerate_add_match_sysattr(3) — Modify filters
udev_enumerate_add_match_sysname(3) — Modify filters
udev_enumerate_add_match_tag(3) — Modify filters
udev_enumerate_add_nomatch_subsystem(3) — Modify filters
udev_enumerate_add_nomatch_sysattr(3) — Modify filters
udev_enumerate_add_syspath(3) — Query or modify a udev enumerate object
udev_enumerate_get_list_entry(3) — Query or modify a udev enumerate object
udev_enumerate_get_udev(3) — Query or modify a udev enumerate object
udev_enumerate_new(3) — Create, acquire and release a udev enumerate object
udev_enumerate_ref(3) — Create, acquire and release a udev enumerate object
udev_enumerate_scan_devices(3) — Query or modify a udev enumerate object
udev_enumerate_scan_subsystems(3) — Query or modify a udev enumerate object
udev_enumerate_unref(3) — Create, acquire and release a udev enumerate object
udev_list_entry(3) — Iterate and access udev lists
udev_list_entry_get_by_name(3) — Iterate and access udev lists
udev_list_entry_get_name(3) — Iterate and access udev lists
udev_list_entry_get_next(3) — Iterate and access udev lists
udev_list_entry_get_value(3) — Iterate and access udev lists
udev_monitor_enable_receiving(3) — Query and modify device monitor
udev_monitor_filter_add_match_subsystem_devtype(3) — Modify filters
udev_monitor_filter_add_match_tag(3) — Modify filters
udev_monitor_filter_remove(3) — Modify filters
udev_monitor_filter_update(3) — Modify filters
udev_monitor_get_fd(3) — Query and modify device monitor
udev_monitor_get_udev(3) — Query and modify device monitor
udev_monitor_new_from_netlink(3) — Create, acquire and release a udev monitor object
udev_monitor_receive_device(3) — Query and modify device monitor
udev_monitor_ref(3) — Create, acquire and release a udev monitor object
udev_monitor_set_receive_buffer_size(3) — Query and modify device monitor
udev_monitor_unref(3) — Create, acquire and release a udev monitor object
udev_new(3) — Create, acquire and release a udev context object
udev_ref(3) — Create, acquire and release a udev context object
udev_unref(3) — Create, acquire and release a udev context object
udevadm(8) — udev management tool
ukify(1) — Combine components into a signed Unified Kernel Image for UEFI systems
[email protected](5) — System units to start the user manager
user.conf.d(5) — System and session service manager configuration files
[email protected](5) — System units to start the user manager
userdbctl(1) — Inspect users, groups and group memberships

V

varlinkctl(1) — Introspect with and invoke Varlink services
veritytab(5) — Configuration for verity block devices

SEE ALSO

systemd.directives(7)

This index contains 1172 entries, referring to 404 individual manual pages.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░