casa/bikeshed
casa
/
bikeshed
9
0
Fork 0
Code Issues Pull Requests Releases Activity
bikeshed/rfb/rfb7.txt

530 lines
17 KiB
Plaintext
Raw Permalink Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Bikeshedding Working Group ~lucidiot, Ed.
Request for Bikeshedding: 7 Bikeshedding Microsystems
Category: Informational August 5, 2021
The Colon Delimited Shit Format
Abstract
This document standardizes the text format commonly seen in UNIX
configuration files such as /etc/passwd, to ensure proper
interoperability.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Bikeshedding Microsystems Working
Task Force (BM-WTF). It represents the consensus of the bikeshedding
community. It has received public review and has been approved for
publication by the Bikeshedding Engineering Steering Group (BESG).
Not all documents approved by the BESG are a candidate for any level
of Bikeshedding Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained on the tildepals
mailing list.
Copyright Notice
Copyright (c) 2021 The Bikeshedding Microsystems and the persons
identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the Bikeshedding Microsystems'
Legal Provisions Relating to Bikeshedding Documents in effect on the
date of publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
~lucidiot Informational [Page 1]
RFB 7 CDS Format August 2021
Table of Contents
1. Introduction ..................................................2
1.1. Notational Conventions ..................................2
2. Format Definition .............................................3
3. Notable Uses ..................................................4
3.1. /etc/passwd .............................................4
3.2. /etc/shadow .............................................4
3.3. /etc/group ..............................................5
4. Security Considerations .......................................5
5. Internationalization Considerations ...........................5
6. Privacy Considerations ........................................5
7. Interoperability Considerations ...............................6
8. Morality Considerations .......................................6
8.1. Likelihood of misuse by depraved or sick individuals ....6
8.2. Likelihood of misuse by misguided individuals ...........6
8.3. Likelihood of misuse by large, multi-national
corporations ............................................6
8.4. Availability of oversight facilities ....................7
8.5. Inter-SDO impact ........................................7
8.6. Care and concern for avian carriers .....................7
9. BANANA Considerations .........................................7
10. References ....................................................8
10.1. Normative References .....................................8
10.2. Informative References ...................................8
Appendix A. Warranty Exclusion Statement ...........................9
Acknowledgements ...................................................9
Author's Address ...................................................9
1. Introduction
UNIX systems have been since the 1960s storing user, group, and
password data in plain text files [PASSWD]. Unlike what many may
believe, a text file format is not necessarily any better than a
binary file format; it being readable in a text editor only means
that the reader has to parse the contents to understand them, instead
of having a piece of software do the parsing and present the data in
a more readable way, in which human parsing becomes negligible.
This file format, despite being rather uniform between UNIX variants,
has never been standardized, and never got a name. This document
aims to fix this issue, to prevent later interoperability issues,
in a similar spirit as for the CSV format [RFC4180], by defining it
as the Colon Delimited Shit format.
1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document SHALL NOT be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
~lucidiot Informational [Page 2]
RFB 7 CDS Format August 2021
2. Format Definition
While there are various specifications and implementations for the
Colon Delimited Shit format, there is no formal and unique
specification in existence, which can allow for varied interpretation
and small incompatibilities. This section documents the format in
its strictest sense, the one that was the most commonly observed on
various systems, including Linux and BSD, with the most restrictions:
1. Each record is located on a separate line, delimited by a line
feed (LF):
root:x:0:0:root:/root:/bin/bash LF
lucidiot:x:1000:1000:lucidiot:/home/lucidiot:/usr/bin/zsh LF
2. The last record in the file may or may not have an ending line
feed (LF):
root:x:0:0:root:/root:/bin/bash LF
lucidiot:x:1000:1000:lucidiot:/home/lucidiot:/usr/bin/zsh
3. Within each record, there MUST be one or more fields, separated
by colons (:). Each line SHOULD contain the same number of
fields throuhgout the file. Spaces are considered part of a
field and SHOULD NOT be ignored. A field MAY be empty. The last
field in the record MUST NOT be followed by a colon. A field
MUST NOT contain a colon.
root:x:0:0
4. Quotes SHOULD NOT be interpreted as delimiting a field like they
could in a CSV file, and there are no escape characters. For
example:
"root":x\::"a:b"
This record contains five fields:
- "root"
- x\
- [An empty field]
- "a
- b"
The ABNF grammar [RFC5234] appears as follows:
file = record *(LF record) [LF]
record = field *(COLON field)
field = <any character except COLON>
~lucidiot Informational [Page 3]
RFB 7 CDS Format August 2021
COLON = %x3A
LF = %x0A ;as per section 6.1 of [RFC2234]
3. Notable Uses
In modern UNIX systems, there are three common uses of the Colon
Delimited Shit format.
3.1. /etc/passwd
The /etc/passwd file holds the list of users on this machine, with
the following fields:
- Username
- Password (set to `x` if it is stored in /etc/shadow)
- User ID
- Primary group ID
- User name or comment field (also known as GECOS field)
- Home directory
- Login shell
You can usually refer to `man 5 passwd` on these systems to learn
about the specific format used by a particular system.
3.2. /etc/shadow
While /etc/passwd is readable by all users, the /etc/shadow file was
introduced to hold the encrypted passwords of the users and only be
accessible to root. The passwords used to not be encrypted at all in
very early UNIX systems, which could allow someone to steal all the
passwords on a machine at once. Setting the password to just `x` in
/etc/passwd instructs the authentication system to get a password
from /etc/shadow instead. The file usually holds the following
fields:
- Username
- Encrypted password
- Timestamp of the last password change
- Minimum password age
- Maximum password age
~lucidiot Informational [Page 4]
RFB 7 CDS Format August 2021
- Password warning period
- Password inactivity period
- Account expiration date
- A reserved field
You can usually refer to `man 5 shadow` on these systems to learn
about the specific format used by a particular system.
3.3. /etc/group
The /etc/group file defines the groups on a UNIX system. It usually
has the following fields:
- Group name
- Encrypted password, may be empty
- Group ID
- Comma-separated list of users in the group, usually empty as most
implementations will only care about the group ID from
/etc/passwd.
You can usually refer to `man 5 group` on these systems to learn
about the specific format used by a particular system.
4. Security Considerations
UNIX systems that still store unencrypted passwords in /etc/passwd
or /etc/shadow, or encrypted passwords in /etc/passwd, SHOULD
urgently be updated.
Care should be taken to ensure that commands such as getent(1) are
able to handle improper input from the files, as there is no escape
mechanism; are empty fields tolerated, or fields with spaces, or
fields with quotes, with backslashes, records with not enough or too
many fields, etc.
5. Internationalization Considerations
Although most Colon Delimited Shit used to be in ASCII, modern UNIX
systems now tolerate UTF-8 text [RFC3629], and using UTF-8 is
therefore RECOMMENDED to avoid internationalization issues.
6. Privacy Considerations
The Colon Delimited Shit format does not directly cause any privacy-
related concerns.
~lucidiot Informational [Page 5]
RFB 7 CDS Format August 2021
Sensitive information SHOULD NOT be kept in the GECOS field of
/etc/passwd, although such a problem is nowadays highly unexpected.
7. Interoperability Considerations
Interoperability concerns are left up to the Protocol Police
[RFC8962].
8. Morality Considerations
This section contains morality considerations consistent with the
demands of [RFC4041].
8.1. Likelihood of misuse by depraved or sick individuals
Being a text file, a Colon Delimited Shit file cannot be used to
distribute blue, smutty or plain disgusting images.
8.2. Likelihood of misuse by misguided individuals
In a situation when a regular Comma-Separated Values file would make
more sense, it is RECOMMENDED to prefer CSV over Comma Delimited Shit
so as to avoid any potential abuse due to incomprehensions with the
lack of escaping and quoting mechanisms. Those situations MAY be
described as "anywhere except in /etc/passwd, /etc/group and
/etc/shadow".
8.3. Likelihood of misuse by large, multi-national corporations
Colon Delimited Shit alone could be used as an argument to mention
how other, possibly proprietary formats are clearly superior. When
used as the UNIX authentication system, it could be used as an
argument for other, more complex systems such as LDAP, Active
Directory, Kerberos, etc. We believe that, since those changes can
only impact the multi-national corporations themselves, negative
consequences of a misuse by large, multi-national corporations can
be ignored.
8.4. Availability of oversight facilities
As the few files in UNIX systems that use the Colon Delimited Shit
format have been here for decades, and most UNIX system users will
take them for granted without thinking about changing them. Should
a major change occur, it is the responsibility of operating system
distribution maintainers to accept or reject changes based on their
own ethics and policies.
~lucidiot Informational [Page 6]
RFB 7 CDS Format August 2021
8.5. Inter-SDO impact
As the files that use Colon Delimited Shit in UNIX systems have been
here for decades, and had very little changes in their fields, and as
this RFB merely describes the format they use, we believe that there
is no impact for other standards development organizations.
8.6. Care and concern for avian carriers
Birbs are important. Users and implementors MUST NOT hurt a birb
while implementing or using the Colon Delimited Shit format.
9. BANANA Considerations
This document registers the "text/vnd.unix.cds" media type.
Type name: text
Subtype name: vnd.unix.cds
Required parameters: N/A
Optional parameters: charset
Encoding considerations: Prefer UTF-8.
See Section 5 of this document.
Security considerations: See Section 4 of this document.
Interoperability considerations: See Section 7 of this document.
Published specification: This document
Applications that use this media type: Most UNIX systems.
See Section 3 of this document.
Additional information:
Deprecated alias names for this type: N/A
Magic numbers: N/A
File extension(s): N/A
Macintosh file type code(s): TEXT
Person & email address to contact for further information: See
Author's Address section.
Intended usage: COMMON
Restrictions on usage: N/A
~lucidiot Informational [Page 7]
RFB 7 CDS Format August 2021
Author: See Author's Address section.
Change controller: See Author's Address section.
Provisional registration? (standards tree only): No
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC4041] Farrel, A., "Requirements for Morality Sections in Routing
Area Drafts", RFC 4041, DOI 10.17487/RFC4041, April 2005,
<https://www.rfc-editor.org/info/rfc4041>.
[RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma-
Separated Values (CSV) Files", RFC 4180,
DOI 10.17487/RFC4180, October 2005,
<https://www.rfc-editor.org/info/rfc4180>.
[RFC5234] Crocker, D., Overell, P., "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC2234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8962] Grover, G., ten Oever, N., Cath, C., Sahib, S.,
"Establishing the Protocol Police", RFC 8962,
DOI 10.17487/RFC8962, April 2021,
<https://www.rfc-editor.org/info/rfc8962>.
10.2. Informative References
[PASSWD] Garfinkel, S., Schwartz, A., Spafford, G., "Practical Unix
& Internet Security, 3rd Edition", "4.3. How Unix
Implements Passwords", ISBN 0-596-00323-4, February 2003,
<https://docstore.mik.ua/orelly/other/puis3rd/
0596003234_puis3-chp-4-sect-3.html>
~lucidiot Informational [Page 8]
RFB 7 CDS Format August 2021
Appendix A. Warranty Exclusion Statement
This document and the information contained herein is provided on an
"AS IS" basis and TILDE.TOWN DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgements
The author would like to thank all subscribers of tildepals for
participating in, or at least putting up with, the Bikeshedding
Company's bikeshedding activities, and most importantly thank
themselves for existing and bringing such great shitposts to the
greater community.
The author would like to thank, in particular, ~m455 for prompting
the standardization of the Colon Delimited Shit format.
The author is additionally grateful about the existence of a
Wikipedia article on RFCs published on April 1st of each year, as
they provide for an endless source of unnecessary text in RFBs.
Author's Address
~lucidiot (editor)
Bikeshedding Microsystems
m455.casa
138.197.184.222
The Internet
Email: lucidiot@brainshit.fr
URI: https://tilde.town/~lucidiot/
~lucidiot Informational [Page 9]
Reference in New Issue View Git Blame Copy Permalink