CALIFE.AUTH(5)

πŸ“¦
version 3.0.6 Β· 2 versions
, in ubuntu resolute, ubuntu stonking

πŸ’– NAME πŸ’–

calife.auth β€” bestie, this is the format of the calife authorization file. it's giving ✨permissions✨, no cap.


πŸŽ€ DESCRIPTION πŸŽ€

okay so picture this: a calife.auth file is literally just a bunch of records, newline separated, one per user, and each record has three fields split by colons (:). the way that colon is the whole personality of this file. here's the breakdown:

  • name β€” the user's login name / @group / %group. like, the vibe check of who we're talking about πŸ’…
  • shell β€” the user's shell. their command interpreter of choice 🐚
  • user1,user2,...,usern β€” the list of logins that this user is allowed to become. it's giving ✨entourage✨

so the name field is the login used to access the computer account. that's the main character right there πŸ‘‘

and now the rules, bestie, listen up:

the login name must never begin with a hyphen (-). fr fr, never.

also it is strongly suggested that neither upper-case characters nor dots (.) be part of the name, because apparently that "tends to confuse mailers". not me feeling bad for the mailers 😭 they're just little guys.

and no field may contain a colon (:) β€” because historically that colon has been used to separate the fields in the user database. so like, the colon is taken. it's booked. do not use it. periodt.


one alternative syntax: use @group to say that any user in the given group is allowed to use calife to become root. iconic group energy 🌈

and there's also an alternative syntax using %group, which is allowed just like sudo. yes bestie, just like sudo, we love a familiar format 🫢


the shell field is the command interpreter the user prefers. simple enough πŸ’…

but β€” if there is nothing in the shell field, then the user's current shell as found in the (/etc/passwd) file is assumed. so it just goes and checks. lowkey convenient.

and if the shell field is *, then the account is considered as locked and access is denied. it's giving do-not-pass-go πŸ’€ no entry, bestie.


and if that third parameter is specified, it is assumed to be the list of logins the current user has the right to become. this enables use of calife for non-root only accounts. yes, you heard that right, it's not just for root, we're expanding the roster ✨

and where does calife.auth live? it's placed in /etc. that's home. 🏠


🌸 EXAMPLE 🌸

here's the example, verbatim, slay:

# calife.auth-dist
#
# Format
#
# name[:shell_to_be_run][:user1,user2,usern]
#
fcb
roberto:/bin/tcsh
pb::guest,blaireau
%wheel

πŸ¦‹ SEE ALSO πŸ¦‹

go read those too, bestie, they're the supporting cast πŸŽ€


⭐ HISTORY ⭐

so a calife.auth file format appeared in DG/UX and SunOS, written for Antenne 2 in 1991. yes, 1991, it's a vintage icon πŸ‘‘

it has evolved with the extra shell specification. glow up ✨

and the login list was reintroduced in 2.7. welcome back king 🫢


πŸ‘‘ AUTHOR πŸ‘‘

Ollivier Robert <roberto@keltia.frmug.fr.net>


okay that's the whole thing bestie!! this page is from the Debian version of the manual, dated September 25, 1994 β€” a certified classic, and yes the file formats manual section is where it lives. go forth and write your calife.auth correctly πŸ’–βœ¨πŸŽ€πŸ¦‹

πŸ“¦ where this page comes from