[Bug 487729] Re: /etc/login.defs propagates incorrect information

[ceg]

** Changed in: shadow (Ubuntu)
       Status: New => Fix Released

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

Title:
  /etc/login.defs propagates incorrect information

Status in “shadow” package in Ubuntu:
  Fix Released

Bug description:
  
  The part about the UMASK setting is not correct and misleading.

  As a contribution here is the corresponding section containing
  corrected information (for inclusion in the next update).

  --8<----- cut here ----------
  #
  # Login configuration initializations:
  #
  # ERASECHAR Terminal ERASE character ('\010' = backspace).
  # KILLCHAR Terminal KILL character ('\025' = CTRL/U).
  # UMASK Default "umask" value.
  #
  # The ERASECHAR and KILLCHAR are used only on System V machines.
  # Prefix these values with "0" to get octal, "0x" to get hexadecimal.
  #
  ERASECHAR 0177
  KILLCHAR 025
  #
  # On PAM-enabled systems the UMASK setting in this file is used as a global
  # default by pam_umask. (See man pam_umask for global and per user
  # overrides.) Setting the umask in shell rc files (i.e. /etc/profile and
  # others) is now discouraged in favour of the pam_umask mechanism.
  #
  # On non-PAM systems setting the umask in shell rc files, in addition
  # to the UMASK setting here, can catches some more classes of user
  # entries to system. (Logins through su, cron, ssh etc.)
  # At the same time, using shell rc to set umask won't catch entries which use
  # non-shell executables in place of login shell, like /usr/sbin/pppd for "ppp"
  # user and alike.
  # For discussion, see #314539 and #248150 as well as the thread starting at
  # http://lists.debian.org/debian-devel/2005/06/msg01598.html
  #
  #
  # UMASK 022 is the "historical" value in Debian,
  # 027 or even 077 could be considered better for privacy if the users
  # in their groups can not trust each other. There is no
  # One True Answer here: Each sysadmin must make up his/her mind.
  #
  # Note that with login's USERGROUPS_ENAB feature, or the usergroups
  # feature of pam_umask, if a user has a user private group
  # the user's group permission umask byte is adjusted to match
  # the user permission byte.
  # This enables flawless collaboration of users in group directories
  UMASK 022

  --8<---------------

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