How do applications remember authentication for sometime?

Question

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?

Answer 1

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 [e-mail]
      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.

Answer 2

This is because of the cache. The concept of cache is very simple. It is a way faster memory than the normal disks. Whenever you want to find something or run a command the cpu first contact cache, if it is in cache then, the fetching happens very fast. But if not then it goes to normal memory and find then fetches and the whole process takes some time.

Linux understands and uses the concept of caching. After a file been accessed for first time, the contents are kept in memory(if free) for future use. Next time you run the same command, the CPU just fetch the content from the memory, without going or reading anything. So it increases the overall speed of execution.

Let's say you opened terminal and then type the command pwd. For the first time it will require some time to display the current working directory. Now run the pwd again, this time you'll see that the execution is very fast. Because while running the second time, the current working directory was already saved in the memory. CPU just fetched the information.

Hope you have got some idea by now.

Thank you.