sorcerykid
/
auth_rx_wiki
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
auth_rx_wiki/Technical-Information.md

4.6 KiB
Raw Permalink Blame History

At server startup, the master database will be read into memory, and a journal file named "auth.dbx" will be created in the same directory, if it does not already exist. The master database will then be audited against the journal for inconsistencies. A roll-forward operation will be performed, if necessary, by re-applying any outstanding transactions within the journal and saving the master database in its entirety. On shutdown, the master database will be saved in its entirety as a temporary file "~auth.db". If successful, the master database will be renamed to "auth.db" and the commit operation will be logged in the journal.

Besides protecting against data loss and corruption, the journal serves as a continuous security audit trail that can be analyzed using virtually any text-processing utility like awk, grep, Python, or Perl. For this reason database transactions in Auth Redux represent discrete events (input) rather than atomic operations (output).

All database transactions are recorded with a minimum of two space-delimited fields: optime and opcode. The optime is a UNIX timestamp identifying when the transaction was posted. The opcode is an integer identifying the type of transaction.

LOG_STARTED = 10                  -- <timestamp> 10
LOG_CHECKED = 11                  -- <timestamp> 11
LOG_STOPPED = 12                  -- <timestamp> 12
TX_CREATE = 20                    -- <timestamp> 20 <username> <password>
TX_DELETE = 21                    -- <timestamp> 21 <username>
TX_SET_PASSWORD = 40              -- <timestamp> 40 <username> <password>
TX_SET_APPROVED_ADDRS = 41        -- <timestamp> 41 <username> <approved_addrs>
TX_SET_ASSIGNED_PRIVS = 42        -- <timestamp> 42 <username> <assigned_privs>
TX_SESSION_OPENED = 50            -- <timestamp> 50 <username>
TX_SESSION_CLOSED = 51            -- <timestamp> 51 <username>
TX_LOGIN_ATTEMPT = 30             -- <timestamp> 30 <username> <ip>
TX_LOGIN_FAILURE = 31             -- <timestamp> 31 <username> <ip>
TX_LOGIN_SUCCESS = 32             -- <timestamp> 32 <username>

The TX opcodes pertain to database transactions, whereas the LOG opcodes are journal-specific transactions.

  • LOG_STARTED
    Posted when database logging begins during a server startup event
  • LOG_STOPPED
    Posted when database logging ends during a server shutdown event (this includes most abnormal server termination)
  • LOG_CHECKED
    Posted at the tail of the journal to confirm that logging is still active
  • TX_CREATE
    Posted when a player's account is added (creates record)
  • TX_DELETE
    Posted when a player's account is removed (deletes record).
  • TX_SET_PASSWORD
    Posted when a player's password is modified (updates: password)
  • TX_SET_ASSIGNED_PRIVS
    Posted when a player's assigned privileges are modified (updates: assigned_privs)
  • TX_SESSION_OPENED
    Posted when a player joins the server (updates: total_sessions)
  • TX_SESSION_CLOSED
    Posted when a player leaves the server (updates: lifetime)
  • TX_LOGIN_ATTEMPT
    Posted when an existing player connects to the server (updates: total_attempts)
  • TX_LOGIN_FAILURES
    Posted when an existing player supplies an incorrect password at login (updates: total_failures)
  • TX_LOGIN_SUCCESS
    Posted when an existing player supplies the correct password at login (updates: newlogin)

The master database is a plain text file consisting to ten colon-delimited fields for every account.

  • Username - registered account name
  • Password - hashed account password
  • OldLogin - timestamp of the original login
  • NewLogin - timestamp of the recent login
  • Lifetime - cumulative time spent playing
  • TotalSessions - total count of successful logins
  • TotalAttempts - total count of login requests
  • TotalFailures - total count of unsuccessful logins
  • AssignedPrivs - comma-separated list of privileges
  • ApprovedAddrs - not currently used

For backwards compatibility, the get_auth( ) method of the registered authentication handler allows for querying a player's Username, Password, NewLogin and AssignedPrivs. The other fields are not directly accessible using the Minetest API. But in a forthcoming release, several additional methods will be available.

For reference, the following table summarizes exactly what type of file operations each script performs:

Notice that the Auth Redux mod never directly manipulates files that were created by Minetest under any circumstances.