Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp313452pxu; Tue, 6 Oct 2020 07:07:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzVsiGu8qU9QyraE8UljiLGxRgTEXyHva4Ghxobiec4rOVG5Q/WJn3kn9tr2WntD/4tTYoJ X-Received: by 2002:aa7:dcc2:: with SMTP id w2mr5729650edu.121.1601993221192; Tue, 06 Oct 2020 07:07:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601993221; cv=none; d=google.com; s=arc-20160816; b=WnJf6SMGgGBxYhYYIMOdX3Ga6gIoRCjCKkwKuSA1EgWJOQKzP30w6wzfDDJzHeo9/e ZO/WfMHV4TruV8ejTX6+1/MZ8f1oX1ejaUydQVRphERIhcunIUx94i76DT/cVS+jDYAo ZRbrVrqNUYP1cY6PDFnGLqs3razqIlv/En6XveMGWbjnMLns17njqavs+e6pXTiQAY47 ByEsgfQv0m3LRaKD5YRLHfo1hEPhlFcgQ4fIrbv1MHHj7xdkj0O3bHrCOtJeIE07F/co cjhSA9XRY9ppKB0L5jXAv5yyX3bHnWG8gVccx1SjBHRxrCov4tZmjEZEg9+OJkElqdyO bS0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=2yxabMMKN4IToF4+ItE8/blrPnv0D7lEzxQD/atQovo=; b=arn7i+FBgyTAlSgDhcQbRcmn1lmlYWD/NtTW8TPpactFJmkyDehycmhUoq93eTrSY1 4ShY+oXIczL9IYpimyJFsIk/7o0b49pnRVb/5Uyjm9rYHKEuj32nwgU218nBFtLIYhlu RtGiJ1yzfkrQopdQr8dFGGTUIuvYW7kBprcGjgFtijxc4Jc9OOXe0WD7bNcRCRcUYVSX Zlq+BhuDM6/0ipKOf0lP3LzDvldmlrnE4/Xn8b01T/0GbBfTxQQI5XCSC3TaK5/srf9I AtufnjMXo03nJcFYClTViOgV1Vz5M71hKDIGg+2UtIRveVthigV+SCw3Mq7dvlUeBIkW RRKw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=YaTNefLs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k19si2071111ejx.75.2020.10.06.07.06.36; Tue, 06 Oct 2020 07:07:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=YaTNefLs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726770AbgJFOE4 (ORCPT + 99 others); Tue, 6 Oct 2020 10:04:56 -0400 Received: from mail.kernel.org ([198.145.29.99]:33610 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726476AbgJFOD4 (ORCPT ); Tue, 6 Oct 2020 10:03:56 -0400 Received: from mail.kernel.org (ip5f5ad5bd.dynamic.kabel-deutschland.de [95.90.213.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 99E5B20760; Tue, 6 Oct 2020 14:03:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1601993034; bh=VDfOGlsJYZesR9L6Qb+5QlSLDI9X9oF0Ascq4FkKHDo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YaTNefLs870gQhLKc7Cakny9yscg9/lP1hK4KC4D6jatlvs4NWA6IMFCfBDEGf5Jo mPOfajCSmGpRH9GqGOPcNaNdwSbZh6Z8FkBNo+UVk4mmVAunLO8pk+uPHczdm2cvS/ dyKqmp3tvIMfo1ETfBTmUk7wxh5UrUXc97nkNPUU= Received: from mchehab by mail.kernel.org with local (Exim 4.94) (envelope-from ) id 1kPnZI-0019G3-GN; Tue, 06 Oct 2020 16:03:52 +0200 From: Mauro Carvalho Chehab To: Linux Doc Mailing List , Jonathan Corbet Cc: Mauro Carvalho Chehab , "Theodore Y. Ts'o" , Eric Biggers , Jaegeuk Kim , linux-fscrypt@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v5 35/52] docs: fs: fscrypt.rst: get rid of :c:type: tags Date: Tue, 6 Oct 2020 16:03:32 +0200 Message-Id: <81cd5da550e06de8e85dcadef4909ff5f1d23319.1601992016.git.mchehab+huawei@kernel.org> X-Mailer: git-send-email 2.26.2 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: Mauro Carvalho Chehab Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The :c:type: tag has problems with Sphinx 3.x, as structs there should be declared with c:struct. So, remove them, relying at automarkup.py extension to convert them into cross-references. Signed-off-by: Mauro Carvalho Chehab --- Documentation/filesystems/fscrypt.rst | 51 ++++++++++++--------------- 1 file changed, 23 insertions(+), 28 deletions(-) diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst index 4f858b38a412..46a9d1bd2ab5 100644 --- a/Documentation/filesystems/fscrypt.rst +++ b/Documentation/filesystems/fscrypt.rst @@ -437,8 +437,7 @@ FS_IOC_SET_ENCRYPTION_POLICY The FS_IOC_SET_ENCRYPTION_POLICY ioctl sets an encryption policy on an empty directory or verifies that a directory or regular file already has the specified encryption policy. It takes in a pointer to a -struct fscrypt_policy_v1 or a :c:type:`struct -fscrypt_policy_v2`, defined as follows:: +struct fscrypt_policy_v1 or a struct fscrypt_policy_v2, defined as follows:: #define FSCRYPT_POLICY_V1 0 #define FSCRYPT_KEY_DESCRIPTOR_SIZE 8 @@ -464,11 +463,10 @@ fscrypt_policy_v2`, defined as follows:: This structure must be initialized as follows: -- ``version`` must be FSCRYPT_POLICY_V1 (0) if the struct is - :c:type:`fscrypt_policy_v1` or FSCRYPT_POLICY_V2 (2) if the struct - is :c:type:`fscrypt_policy_v2`. (Note: we refer to the original - policy version as "v1", though its version code is really 0.) For - new encrypted directories, use v2 policies. +- ``version`` must be FSCRYPT_POLICY_V1 (0) if struct fscrypt_policy_v1 + is used or FSCRYPT_POLICY_V2 (2) if struct fscrypt_policy_v2 is used. + (Note: we refer to the original policy version as "v1", though its + version code is really 0.) For new encrypted directories, use v2 policies. - ``contents_encryption_mode`` and ``filenames_encryption_mode`` must be set to constants from ```` which identify the @@ -509,8 +507,7 @@ This structure must be initialized as follows: be arbitrarily chosen. Instead, the key must first be added using `FS_IOC_ADD_ENCRYPTION_KEY`_. Then, the ``key_spec.u.identifier`` the kernel returned in the struct fscrypt_add_key_arg must - be used as the ``master_key_identifier`` in the :c:type:`struct - fscrypt_policy_v2`. + be used as the ``master_key_identifier`` in struct fscrypt_policy_v2. If the file is not yet encrypted, then FS_IOC_SET_ENCRYPTION_POLICY verifies that the file is an empty directory. If so, the specified @@ -637,9 +634,8 @@ The FS_IOC_GET_ENCRYPTION_POLICY ioctl can also retrieve the encryption policy, if any, for a directory or regular file. However, unlike `FS_IOC_GET_ENCRYPTION_POLICY_EX`_, FS_IOC_GET_ENCRYPTION_POLICY only supports the original policy -version. It takes in a pointer directly to a :c:type:`struct -fscrypt_policy_v1` rather than a :c:type:`struct -fscrypt_get_policy_ex_arg`. +version. It takes in a pointer directly to struct fscrypt_policy_v1 +rather than struct fscrypt_get_policy_ex_arg. The error codes for FS_IOC_GET_ENCRYPTION_POLICY are the same as those for FS_IOC_GET_ENCRYPTION_POLICY_EX, except that @@ -717,10 +713,9 @@ as follows: ``key_spec.type`` must contain FSCRYPT_KEY_SPEC_TYPE_DESCRIPTOR, and ``key_spec.u.descriptor`` must contain the descriptor of the key being added, corresponding to the value in the - ``master_key_descriptor`` field of :c:type:`struct - fscrypt_policy_v1`. To add this type of key, the calling process - must have the CAP_SYS_ADMIN capability in the initial user - namespace. + ``master_key_descriptor`` field of struct fscrypt_policy_v1. + To add this type of key, the calling process must have the + CAP_SYS_ADMIN capability in the initial user namespace. Alternatively, if the key is being added for use by v2 encryption policies, then ``key_spec.type`` must contain @@ -737,8 +732,8 @@ as follows: - ``key_id`` is 0 if the raw key is given directly in the ``raw`` field. Otherwise ``key_id`` is the ID of a Linux keyring key of - type "fscrypt-provisioning" whose payload is a :c:type:`struct - fscrypt_provisioning_key_payload` whose ``raw`` field contains the + type "fscrypt-provisioning" whose payload is + struct fscrypt_provisioning_key_payload whose ``raw`` field contains the raw key and whose ``type`` field matches ``key_spec.type``. Since ``raw`` is variable-length, the total size of this key's payload must be ``sizeof(struct fscrypt_provisioning_key_payload)`` plus the @@ -956,8 +951,8 @@ FS_IOC_GET_ENCRYPTION_KEY_STATUS The FS_IOC_GET_ENCRYPTION_KEY_STATUS ioctl retrieves the status of a master encryption key. It can be executed on any file or directory on the target filesystem, but using the filesystem's root directory is -recommended. It takes in a pointer to a :c:type:`struct -fscrypt_get_key_status_arg`, defined as follows:: +recommended. It takes in a pointer to struct fscrypt_get_key_status_arg, +defined as follows:: struct fscrypt_get_key_status_arg { /* input */ @@ -1148,12 +1143,12 @@ Implementation details Encryption context ------------------ -An encryption policy is represented on-disk by a :c:type:`struct -fscrypt_context_v1` or a struct fscrypt_context_v2. It is -up to individual filesystems to decide where to store it, but normally -it would be stored in a hidden extended attribute. It should *not* be -exposed by the xattr-related system calls such as getxattr() and -setxattr() because of the special semantics of the encryption xattr. +An encryption policy is represented on-disk by struct fscrypt_context_v1 +or struct fscrypt_context_v2. It is up to individual filesystems to decide +where to store it, but normally it would be stored in a hidden extended +attribute. It should *not* be exposed by the xattr-related system calls +such as getxattr() and setxattr() because of the special semantics of the +encryption xattr. (In particular, there would be much confusion if an encryption policy were to be added to or removed from anything other than an empty directory.) These structs are defined as follows:: @@ -1249,8 +1244,8 @@ a strong "hash" of the ciphertext filename, along with the optional filesystem-specific hash(es) needed for directory lookups. This allows the filesystem to still, with a high degree of confidence, map the filename given in ->lookup() back to a particular directory entry -that was previously listed by readdir(). See :c:type:`struct -fscrypt_nokey_name` in the source for more details. +that was previously listed by readdir(). See struct fscrypt_nokey_name +in the source for more details. Note that the precise way that filenames are presented to userspace without the key is subject to change in the future. It is only meant -- 2.26.2