-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Branden Robinson wrote: | On Thu, Oct 14, 2004 at 12:14:58AM +0200, Tomas Fasth wrote: [...] |> I believe that /etc/login.defs _is_ the right place to define |> the default umask property. | | It feels wrong to me to make display managers selectively parse | the configuration file of a different piece of software for | configuration parameters that might be of interest to them.
However, umask is not an ordinary software configuration property, it's a process property initially inherited from init which, by the way, set it to 022 (I just checked the source of sysvinit in unstable).
Now, I can understand that an administrative domain need to change the default value of umask according to site policy. What I don't understand is why you think the umask preference should be applied differently depending on the type of interface the user choose to initiate an interactive session with.
In order to achieve good interoperability there should be a backward compatibility requirement for display managers to adhere. I also think text terminal logins as well as graphical equivalents should all have the same source of default process and environment properties. If you agree that there should be a common source for this information, but do not agree that login.defs file and passwd GECOS field extension (the latter which can be provided by other sources, like LDAP) is acceptable as source, then what do you suggest we use instead?
| $ man 5 login.defs | | No mention of X Window System display managers there. | | Huh, well... | | BUGS Much of the functionality that used to be provided by the | shadow password suite is now handled by PAM. Thus, | /etc/login.defs is no longer used by programs such as login(1), | passwd(1) and su(1). Please refer to the corresponding PAM | configuration files instead. | | Maybe that's the direction we should head?
I think the key word here is "Much", meaning "Not all". And the assertion that /etc/login.defs is no longer used by programs such as login is not accurate, at least not according to "The Source" (tm). It may be so in the future, but not for the time being.
// Tomas
- -- Tomas Fasth <[EMAIL PROTECTED]> GnuPG 0x9FE8D504 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBcQXbwYdzVZ/o1QQRAh3OAJ9k+tU2m4Lqxp6V4j6ZPAH5P5N/GwCfWsrc pklh+ry/fCweLMcBSPXgGe4= =Czmv -----END PGP SIGNATURE-----