loginguard

Overview ¶

Package loginguard limits how many wrong sign-in attempts an account and an address may make, for every door a password can be typed at: the web form, WebDAV, FTPS, SFTP.

What is counted, and where ¶

Two counters, held in MEMORY and written through to the database (login_throttle, migration 00072) on every change:

• per ACCOUNT IDENTIFIER: the normalized text the caller typed (identity.Normalize), whether or not an account by that name exists. The answer to "how many tries are left" is therefore the same for a real name and a made-up one — the limit is not an account-enumeration oracle;
• per ADDRESS: the client address (internal/clientip).

Every decision is read from memory; the table is what a restart or a deploy comes back to (Load fills the memory from it at start), so neither hands an attacker a fresh set of guesses. A write the table refuses (full disk, lost connection) does NOT change the decision — the limit goes on from memory, neither failing open nor locking everyone out — and the counter is written again at the next write that succeeds, or at the next tick.

The settings (the switch, the numbers, the allow-list, the trusted proxies) are held the same way: read from the table at start, written to the table AND put in force in memory on every save (SaveSetting), so a change applies to the next attempt — and read from the table again every minute (Tick), so a change saved on another instance is in force here within a minute. A settings read the table refuses keeps the last value known (the default when there was none).

The housekeeping runs on its own clock, not on the traffic: Run (started with the server) ticks every minute — the settings are read again, locks that ran out are released and audited, idle counters leave memory, owed writes are retried and the table is pruned.

⚠ The COUNTERS are per PROCESS. Instances sharing one database each count in their own memory (the table is read once, at Load): with N instances a guesser spread over all of them gets up to N times the limit per account, a lock placed by one is not seen by the others until they restart, and the table holds whichever instance wrote a counter last. The settings are shared (above). Run the limit on one instance, or in front of all of them, if that matters.

The guard sits ABOVE the driver chain. Local, LDAP, recovery and any provider added later are judged behind it; none of them has to know it exists, and none of them can forget it.

The rules ¶

• A subject that reaches its limit inside the window is LOCKED. The first lock lasts login.lock_base_seconds; each further lock in a row doubles it up to login.lock_max_seconds. The doubling forgets after a quiet spell and after a success.
• While a lock is in force even the RIGHT password is refused, and the refused attempt is not counted. A lock the correct answer lifts is no lock at all against somebody working through the space.
• An address on login.ip_allowlist is exempt from the per-address limit, and may sign in to any locked account (with the right password): the lock is not applied to that address. Its wrong attempts are audited but counted against nobody. NO account is privileged — the bootstrap administrator is limited like everyone else, and the way back in is an allow-listed address. The one exception is a public demo's SHARED account (FILEX_DEMO_MODE): its password is published, so the per-account lock on it would be a switch any stranger flips for every visitor; it is counted per address only (exempt.go).
• A success resets the ACCOUNT's counter. It does NOT reset the address's: otherwise one valid login between guesses would keep a spraying address under its limit for ever.

Known limits ¶

Locking an account by typing its name wrongly is possible by design (that is what a lock is); the allow-list is the remedy, and the escalating lock keeps the cost of the attack on the attacker's side of the door. The memory holds at most MaxCounters counters: past that, the counters a sweep would drop go first, then the oldest — a counter with no lock in force before one with — so a flood of made-up names or addresses cannot grow it without bound.

Package loginguard — proxyseed.go ¶

FILEX_TRUSTED_PROXIES is a SEED since 0.57 (task #258, the owner's decision of 2026-10-15), like every other setting a variable gives a first value to (package dbsetting):

a start where `login.trusted_proxies` holds nothing  → the configuration's
    list (FILEX_TRUSTED_PROXIES over config.yaml trusted_proxies) is
    written into it, as typed
from then on                                          → the stored list
    wins; the variable is not read again, and a start whose variable says
    something else logs it once
`filex settings reseed login.trusted_proxies`         → writes the
    configuration's list over the stored one, on purpose

Until 0.57 the variable was read at every start, as the fallback under an empty setting. An install upgraded with the variable set and no row (the usual case: the list was never edited on the page) gets that very list written at its first 0.57 start, so nothing it trusts changes - `auto` and a list such as "auto, <the proxy's address>" included.

⚠ The fallback under an empty row stays (Guard.TrustedProxySource): a start that could not write the seed, or a list removed on the page during this run, still trusts what the configuration says rather than falling to `auto` until the next start re-seeds it. "Remove the saved list" therefore means what it always meant: back to the configuration's list.