Linux – How do applications remember authentication for sometime

authenticationlinuxpassword-management

In linux some of the applications are able to remember authentication for sometime. For example,

  • File manager remember authentication for a while, when we provide password to mount a partition. If we mount another partition soon after mounting first one, it won't ask for a password.

  • Terminal applications, if we execute some task with sudo and provide password, it won't ask for next sudo action if it is performed within a time period.

How this functionality is implemented? How can I make my application to remember root authentication for sometime?

Best Answer

Having a program "remember" something is easy: write it to a file somewhere, then read it back later. That's how all settings/preferences work. (For that matter, it's how regular files work.)

(They might be stored as a file in ~/.config/ on disk; a file in RAM in /run; an abstract settings storage like GConf or the Windows Registry; it varies.)

In both of your examples, the relevant programs/services remember not the authentication details, but only the fact that authentication was successful recently (and that the action was ultimately allowed) – in other words, an authorization.

  • When mounting a disk via GUI, the mount request is sent to UDisks, which then asks polkit for confirmation. ("Hey, user X is trying to mount disk Y, is that allowed?")

    Since polkit is a permanently running service, it keeps track of recent authentications entirely within the process' own memory, in a linked list (a GList). You can search its src/polkitbackend for the words temporary_authorization.

    If you were implementing the same feature, a simplified example would be:

    authorizations = list()
...
authorizations.append({user: "niyasc",
                       action: "mount drive",
                       expires: time.now() + 3600})

    Your program can also use polkit.

  • sudo, on the other hand, is a one-shot tool, so it stores the same information externally – as files under (/var)/run/sudo/ts. The file's "last-modified" timestamp is compared to see if it's recent enough, and updated after every use.

    # ls -l /run/sudo/ts
total 4
-rw------- 1 root grawity 80 Jul 29 12:15 /run/sudo/ts/grawity

    The algorithm in both cases is, roughly:

    def check_authorization(user) {
    if has_old_authorization(user) {
        expires = read_authorization(user);
        if expires > time.now() {
            return true;
        }
    }
    success = ask_for_authentication(user);
    if success {
        store_authorization(user, expires=time.now()+3600);
    }
    return success;
}

There are other methods for "remembering authentication", but all of them boil down to storing a bunch of bytes in a file:

  • Many network-based apps (e.g. mail clients such as Thunderbird or Outlook) actually store the username & password itself directly on disk. A simplified example would be the ~/.netrc file:

    machine imap.example.com
    login niyasc@example.com
    password foobar

    Often it's encrypted before storing (the app might use OS facilities such as GNOME-Keyring, or it might support a "master password"), but in the end it's just a piece of data that can be stored in a file.

  • Many web-based apps use cookies to remember the fact that you're logged in. Upon login, the server asks your browser to remember something like "session_id=SGVsbG8gd29ybGQh", and to send it back with every next visit. Browsers usually have a text-based or SQLite-based database of all cookies issued by all websites (the "cookie jar").

    The server also has a 'session' database which contains information about each issued cookie, so that when it receives the same "session_id=SGVsbG8gd29ybGQh" it knows you're niyasc:

    SESSION_ID         USERNAME   ISSUED          EXPIRES
SGVsbG8gd29ybGQh   niyasc     Jul 29, 11:47   Aug 29, 11:47
6kJnRcg4KBAPrMJ4   fred       Jun 14, 22:13   Sep 14, 22:13
...

  • Some network protocols, such as Kerberos or SAML, use a form of cookies called "tickets" or "tokens", which themselves have the information about when they were issued and for whom. (They're also digitally signed by the authentication service as proof.) This also allows the 'authentication' server and the 'application' server to be separate for increased security.

  • Yet other protocols, such as SSH or SSL/TLS, use digital signatures – instead of having a password at all, the client has a private keypair (usually RSA or [EC]DSA), which is also stored as a file on disk – e.g. the ~/.ssh/id_rsa file.

    For every connection, the server sends a "challenge" (a series of random bytes); the client signs it with its private key; the server then verifies the signature and checks if it's signed by one of the "allowed" keys.

Related Question