Santiago Vila <sanv...@unex.es> wrote: [...] > Problems like that are expected to happen, and I think we should be > ready to fix them as they are found, so that the umask setting can > really be a choice of the system admin, not an imposition of certain > key programs who do not work well enough on systems having UPG and a > default umask of 002.
> I remember that procmail had a similar problem, and the author > implemented a build macro for systems having UPG. From the changelog: > 1999/03/02: v3.12 > Changes to procmail: > - Don't use $HOME/.procmailrc if it's group-writable or in a > group-writable directory, unless it's the user's default group > and GROUP_PER_USER is set in config.h Hello, afaiui we have this problem: #1 Debian supports both UPG and non-UPG setups. #2 UPG with umask 022 is useless. #3 non-UPG with umask 002 is insecure. #4 We cannot reliably detect UPG-setups. (The setting USERGROUPS=yes/no in /etc/adduser.conf is not relevant, e.g. in a NIS szenario users are generated on the master system.) The solution applied to procmail, disabling .procmailrc permission sanity check at compile time is not really a bugfix, but a policy change, dropping #1 in favour of #2. cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1512c7-iq3....@argenau.downhill.at.eu.org
