[Bug 871943] Re: pam_motd somtimes inherits umask of user (via pam_umask)

[Steve Langasek]

** Changed in: pam (Ubuntu)
       Status: New => In Progress

** Changed in: pam (Ubuntu)
       Status: In Progress => Triaged

** Changed in: pam (Ubuntu)
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to pam in Ubuntu.
https://bugs.launchpad.net/bugs/871943

Title:
  pam_motd somtimes inherits umask of user (via pam_umask)

Status in “pam” package in Ubuntu:
  Triaged

Bug description:
  When performing install audits, I noticed that /run/motd had the following permissions:
  $ ls -l /run/motd
  -rw-rw-r-- 1 root root 198 2011-10-10 13:20 /run/motd

  I found this odd and remembered
  https://blueprints.launchpad.net/ubuntu/+spec/umask-to-0002. While
  /etc/init/mounted-run.conf creates this initially on reboot, it turns
  out that the permissions are changed on login, via pam_motd.

  TEST CASE:
  1. login
  2. sudo chmod 644 /run/motd
  3. Check the permissions of /run/motd. Eg:
  $ ls -l /run/motd
  -rw-r--r-- 1 root root 198 2011-10-10 13:20 /run/motd
  4. login via ssh (eg ssh 127.0.0.1)
  5. Check the permissions of /run/motd. Eg:
  $ ls -l /run/motd
  -rw-rw-r-- 1 root root 198 2011-10-10 13:38 /run/motd

  So, this happens on ssh logins and not console logins because pam_motd
  in console logins is earlier in the stack (before common-session,
  which has pam_umask in it). With ssh logins, pam_motd is after common-
  session.

  This does not seem to be a security issue as the umask has to be
  adjusted via /etc/login.defs; however the side-effect is undesirable.
  While we could adjust the stacking, it seems a reasonable hardening
  measure would be for pam_motd to explicitly set its umask.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pam/+bug/871943/+subscriptions