Re: Xsession doesn't use umask setting from /etc/login.defs
* Branden Robinson | I'm not thrilled with it, but maybe you can make something useful out of | that. | | Thanks again for the lightning-fast coding. :) Thanks for the description; the package is now sitting in the NEW queue. Sorry for taking a bit of time, I have been away on vacation. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Xsession doesn't use umask setting from /etc/login.defs
On Mon, Oct 18, 2004 at 09:41:45PM +0200, Tomas Fasth wrote: > I have re-read your mail and I beg you for pardon. I was wrong. Thanks. My anger dissipates with a wave of the hand. :) > | And, by the way: X-No-CC: I subscribe to this list; do not CC me > | on replies. > > I'm very sorry but I'm not perfect. My earlier reply did not cc: > you. Could you please wait for it to happen a second time in the > same thread before complaining? You seem a bit touchy about it. It's one of my long-standing pet peeves. > | Please get an MUA that respects Mail-Copies-To:. > > Thanks for the advice, but I prefer Firefox for the time being. I > may try to persuade the Mozilla people to accept a patch. Can you > give me a reference to a RFC-draft or something equivalent? The best I can do is my usual boilerplate message, which has some references at the bottom. [The following is a form letter.] Hello, You recently sent a message to a Debian Project mailing list to which I am subscribed, and also included me in the To or CC header. Please don't do this. The Debian Mailing List Code of Conduct says: When using the Debian mailing lists, please follow these rules: [...] * When replying to messages on the mailing list, do not send a carbon copy (CC) to the original poster unless they explicitly request to be copied. (You can review the entire Debian Mailing List Code of Conduct at http://www.debian.org/MailingLists/>.) Rationally interpreted, this of course includes anything that works equivalently to a CC, such including the original poster in the To: or Bcc: headers, forwarding the message to the original poster, or using the "bounce" feature of some mailers to send the message again, but rewriting the SMTP envelope to address the original poster instead of the list. Some people feel that it is best to send email to everyone who might possibly be interested in a message, indifferent to whom might be subscribed to various mailing lists, be part of the expansion of various mailing lists, be behind an SMTP exploder, and so forth -- in other words, that it is the responsibility of the recipient of duplicate mail messages to handle them. The Debian Mailing List Code of Conduct does not endorse that philosophy. There are proven limitations with using procmail rules to eliminate duplicate message based on Message-ID, for instance. More importantly, the Debian Mailing List Code of Conduct expects the *senders* of mail to exercise discretion and good judgement; it does not place the burden of pruning unwanted copies of mail messages upon the recipient. You can find discussions of this aspect of the Mailing List Code of Conduct in the Debian mailing lists themselves, if you are interested: please see http://lists.debian.org/search.html> to perform a search. The subject has come up several times over the past years, and time and again, the existing policy has been affirmed as the wisest course of action. Many people, myself included, use the Mail-Followup-To and Mail-Copies-To message headers, which are honored by mail user agents such as Mutt to control the distribution of replies to mailing lists. Using such headers, a person can easily indicate that he does (or does not) want to be sent copies of replies to his message. You may want to use an MUA that honors these headers, as they are in fairly wide usage on the Debian mailing lists, and may help you avoid mistakes resulting in inadvertent violations of Debian's Mailing List Code of Conduct. You can read more about the Mail-Followup-To and Mail-Copies-To message headers at: http://www.ietf.org/proceedings/98dec/I-D/draft-ietf-drums-mail-followup-to-00.txt http://www.newsreaders.com/misc/mail-copies-to.html Please note that no assertions of deliberate misconduct on your part are intended by this message. It is meant only to advise you as to how to communicate more harmoniously with people involved with the Debian Project. Thank you for your patience with this form letter, for your respect for the Debian Project's mailing list conventions, and for your participation in Debian. -- G. Branden Robinson|When we call others dogmatic, what Debian GNU/Linux |we really object to is their [EMAIL PROTECTED] |holding dogmas that are different http://people.debian.org/~branden/ |from our own. -- Charles Issawi signature.asc Description: Digital signature
Re: Xsession doesn't use umask setting from /etc/login.defs
On Mon, Oct 18, 2004 at 09:43:33AM +0200, Jan Nieuwenhuizen wrote: > I wonder if filing a bug report against the offending MUA would be > more efficient? I think such bugs are best filed by those who actually use the MUA in question (I use Mutt, which already respects M-C-T and M-F-T). After all, if I can't persuade the users of those MUAs that honoring people's wishes is a good idea, I don't suspect I'll make much more headway with anyone else. -- G. Branden Robinson| Debian GNU/Linux | If ignorance is bliss, [EMAIL PROTECTED] | is omniscience hell? http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Xsession doesn't use umask setting from /etc/login.defs
On Mon, Oct 18, 2004 at 10:57:24AM +0200, Tollef Fog Heen wrote: > * Branden Robinson > > | On Fri, Oct 15, 2004 at 12:06:36PM -0700, Steve Langasek wrote: > | > environment variables, at least, are trivial to accomplish using the > | > pam_env module. Properly setting a umask would call for something else > | > yet. > | > | Would pam_umask.so be a worthwhile exercise for some enterprising person? > | > | I somehow suspect that umasks predate environment variables in the misty > | early history of Unix, else the umask would've been made one. > > Give me a decent description for it (as in, what goes into the long > description in debian/control) and it's on its way to incoming. Wow, thanks! Hmmm. This PAM module sets the umask for successfully authenticated sessions. The umask affects the permissions assigned to newly created files by default. . This package is useful to ensure that users' umasks are set consistently whether their session is initiated by login, SSH, a display manager for the X Window System, or some other means. I'm not thrilled with it, but maybe you can make something useful out of that. Thanks again for the lightning-fast coding. :) -- G. Branden Robinson|The basic test of freedom is Debian GNU/Linux |perhaps less in what we are free to [EMAIL PROTECTED] |do than in what we are free not to http://people.debian.org/~branden/ |do. -- Eric Hoffer signature.asc Description: Digital signature
Re: Xsession doesn't use umask setting from /etc/login.defs
* Tomas Fasth | Branden Robinson wrote: | | Would pam_umask.so be a worthwhile exercise for some enterprising | | person? | | May I suggest pam_logindefs.so? No, that's a bad idea for a variety of reasons, for instance that we already have pam_limits and as pam modules often are security-critical which means we should have small modules instead of one, larger module doing more. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Xsession doesn't use umask setting from /etc/login.defs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steve Langasek wrote: | On Mon, Oct 18, 2004 at 02:06:16AM -0500, Branden Robinson wrote: |> On Fri, Oct 15, 2004 at 12:06:36PM -0700, Steve Langasek wrote: |>> environment variables, at least, are trivial to accomplish |>> using the pam_env module. Properly setting a umask would |>> call for something else yet. | |> Would pam_umask.so be a worthwhile exercise for some |> enterprising person? | | (after discussing on IRC) Considering we already have a | pam_limits.so for ulimits, yes. Good thinking. I looked at the source. It (pam_limits) already (conditionally) support things like Linux system capabilities. Should be able to handle support for umask as well, preferably upstream. I have sent the authors (redhat staff) a query. // 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 iD8DBQFBdGVewYdzVZ/o1QQRAkwuAJ9IGMwWtNBZV6r5zfcsHe0m5WGoKgCfR1Aa mGjyqtPZk06hr7UkwTI1GO0= =exV9 -END PGP SIGNATURE-
Re: Xsession doesn't use umask setting from /etc/login.defs
On Mon, Oct 18, 2004 at 02:06:16AM -0500, Branden Robinson wrote: > On Fri, Oct 15, 2004 at 12:06:36PM -0700, Steve Langasek wrote: > > environment variables, at least, are trivial to accomplish using the > > pam_env module. Properly setting a umask would call for something else > > yet. > Would pam_umask.so be a worthwhile exercise for some enterprising person? (after discussing on IRC) Considering we already have a pam_limits.so for ulimits, yes. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Xsession doesn't use umask setting from /etc/login.defs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Branden Robinson wrote: | On Fri, Oct 15, 2004 at 12:06:36PM -0700, Steve Langasek wrote: | |> environment variables, at least, are trivial to accomplish |> using the pam_env module. Properly setting a umask would call |> for something else yet. | | Would pam_umask.so be a worthwhile exercise for some enterprising | person? May I suggest pam_logindefs.so? | I somehow suspect that umasks predate environment variables in | the misty early history of Unix, else the umask would've been | made one. I don't think so. I think it is a result of careful and thorough system design. Environment variables are excellent for tailoring user space activities. Umask (ulimit, nice) is kernel business, belong in it's data structures and therefore manipulated only through system calls. // 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 iD8DBQFBdDQ3wYdzVZ/o1QQRAtufAJ40I0q4CHw1qRlf/MJH9e3pnb1jWwCfbzie +VTh0TnXv6qGrHgtuVZE6Ug= =3UTD -END PGP SIGNATURE-
Re: Xsession doesn't use umask setting from /etc/login.defs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Branden, Branden Robinson wrote: | On Sat, Oct 16, 2004 at 01:28:31PM +0200, Tomas Fasth wrote: | |> 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. | | | I don't. Kindly stop putting words in my mouth, and re-read my | original mail. If you can discuss this subject without indulging | yourself in straw-man attacks like this, please follow-up with a | more reasonable message. I have re-read your mail and I beg you for pardon. I was wrong. | And, by the way: X-No-CC: I subscribe to this list; do not CC me | on replies. I'm very sorry but I'm not perfect. My earlier reply did not cc: you. Could you please wait for it to happen a second time in the same thread before complaining? You seem a bit touchy about it. I found the following when I was googling for X-No-CC: ~ From: Stepan Kasal ~ Subject: Re: Paragraph indentation suppression ~ Date: Tue, 8 Apr 2003 10:00:55 +0200 [...] ~ PS: I'm not sending cc to the original poster, as I'm scared by ~ this: X-No-CC: If you CC me on this list, I will feed you to ~ Branden Robinson. (It seems that Karl has already been fed.) I couldn't but smile. "Oh no, please have mercy, don't feed me to Branden!" Poor Karl :) | Please get an MUA that respects Mail-Copies-To:. Thanks for the advice, but I prefer Firefox for the time being. I may try to persuade the Mozilla people to accept a patch. Can you give me a reference to a RFC-draft or something equivalent? Live in peace, 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 iD8DBQFBdBw+wYdzVZ/o1QQRAuYQAJ91qTyek/fp58fX3TSGWRUmc0oUZgCfVFyA 8iz8rKvhvF3QuEX0VL4nH/c= =cKe+ -END PGP SIGNATURE-
Re: Xsession doesn't use umask setting from /etc/login.defs
* Branden Robinson | On Fri, Oct 15, 2004 at 12:06:36PM -0700, Steve Langasek wrote: | > environment variables, at least, are trivial to accomplish using the | > pam_env module. Properly setting a umask would call for something else | > yet. | | Would pam_umask.so be a worthwhile exercise for some enterprising person? | | I somehow suspect that umasks predate environment variables in the misty | early history of Unix, else the umask would've been made one. Give me a decent description for it (as in, what goes into the long description in debian/control) and it's on its way to incoming. (Yes, I've written one just now.) -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Xsession doesn't use umask setting from /etc/login.defs
Branden Robinson writes: When I see complaints like these > And, by the way: > X-No-CC: I subscribe to this list; do not CC me on replies. > > Please get an MUA that respects Mail-Copies-To:. I wonder if filing a bug report against the offending MUA would be more efficient? In this case, the headers say X-Enigmail-Version: 0.86.1.0 and $ apt-cache search enigmail mozilla-thunderbird-enigmail - Enigmail - GPG support for Mozilla Thunderbird so we might be seeing more of these if mozilla isn't fixed. Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: Xsession doesn't use umask setting from /etc/login.defs
On Sat, Oct 16, 2004 at 01:28:31PM +0200, Tomas Fasth wrote: > 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). Yes, we know that. [...] > 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. I don't. Kindly stop putting words in my mouth, and re-read my original mail. If you can discuss this subject without indulging yourself in straw-man attacks like this, please follow-up with a more reasonable message. And, by the way: X-No-CC: I subscribe to this list; do not CC me on replies. Please get an MUA that respects Mail-Copies-To:. -- G. Branden Robinson|I must despise the world which does Debian GNU/Linux |not know that music is a higher [EMAIL PROTECTED] |revelation than all wisdom and http://people.debian.org/~branden/ |philosophy. -- Ludwig van Beethoven signature.asc Description: Digital signature
Re: Xsession doesn't use umask setting from /etc/login.defs
On Fri, Oct 15, 2004 at 12:06:36PM -0700, Steve Langasek wrote: > environment variables, at least, are trivial to accomplish using the > pam_env module. Properly setting a umask would call for something else > yet. Would pam_umask.so be a worthwhile exercise for some enterprising person? I somehow suspect that umasks predate environment variables in the misty early history of Unix, else the umask would've been made one. -- G. Branden Robinson| The Bible is probably the most Debian GNU/Linux | genocidal book ever written. [EMAIL PROTECTED] | -- Noam Chomsky http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Xsession doesn't use umask setting from /etc/login.defs
-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-
Re: Xsession doesn't use umask setting from /etc/login.defs
On Fri, Oct 15, 2004 at 01:23:40PM +0100, Colin Watson wrote: > On Fri, Oct 15, 2004 at 01:19:59AM -0500, Branden Robinson wrote: > > On Thu, Oct 14, 2004 at 12:14:58AM +0200, Tomas Fasth wrote: > > > Branden Robinson wrote: > > > >/etc/login.defs explicitly indicates that it is "Configuration > > > >control definitions for the login package", and many of its > > > >parameters are inapplicable to display managers, or already > > > >implemented in parallel (e.g., how long do wait after a failed > > > >login before displaying the prompt/greeter again?). > > > > > > 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. > This was exactly the opinion I came to when people asked (as they have > on a number of occasions) for OpenSSH to honour the ENV_SUPATH and > ENV_PATH settings in /etc/login.defs. > > 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 don't think everything in /etc/login.defs is provided by PAM yet, > although I'm willing to be corrected on this. I agree that's the right > place for programs like sshd and Xsession to get this information. environment variables, at least, are trivial to accomplish using the pam_env module. Properly setting a umask would call for something else yet. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Xsession doesn't use umask setting from /etc/login.defs
On Fri, Oct 15, 2004 at 01:19:59AM -0500, Branden Robinson wrote: > On Thu, Oct 14, 2004 at 12:14:58AM +0200, Tomas Fasth wrote: > > Branden Robinson wrote: > > >/etc/login.defs explicitly indicates that it is "Configuration > > >control definitions for the login package", and many of its > > >parameters are inapplicable to display managers, or already > > >implemented in parallel (e.g., how long do wait after a failed > > >login before displaying the prompt/greeter again?). > > > > 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. This was exactly the opinion I came to when people asked (as they have on a number of occasions) for OpenSSH to honour the ENV_SUPATH and ENV_PATH settings in /etc/login.defs. > 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 don't think everything in /etc/login.defs is provided by PAM yet, although I'm willing to be corrected on this. I agree that's the right place for programs like sshd and Xsession to get this information. -- Colin Watson [EMAIL PROTECTED]
Re: Xsession doesn't use umask setting from /etc/login.defs
On Thu, Oct 14, 2004 at 12:14:58AM +0200, Tomas Fasth wrote: > Branden Robinson wrote: > >/etc/login.defs explicitly indicates that it is "Configuration > >control definitions for the login package", and many of its > >parameters are inapplicable to display managers, or already > >implemented in parallel (e.g., how long do wait after a failed > >login before displaying the prompt/greeter again?). > > 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. $ 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? -- G. Branden Robinson| If God had intended for man to go Debian GNU/Linux | about naked, we would have been [EMAIL PROTECTED] | born that way. http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Xsession doesn't use umask setting from /etc/login.defs
At Thu, 14 Oct 2004 00:14:58 +0200, Tomas Fasth wrote: > > /etc/login.defs explicitly indicates that it is "Configuration > > control definitions for the login package", and many of its > > parameters are inapplicable to display managers, or already > > implemented in parallel (e.g., how long do wait after a failed > > login before displaying the prompt/greeter again?). > > I believe that /etc/login.defs _is_ the right place to define the > default umask property. It's just my wishlist, but I think it's good idea to provide a summary that describes what file affects the bootstrap configuration in debian, by a professional of this kind of area... Regards, -- gotom
Re: Xsession doesn't use umask setting from /etc/login.defs
Branden Robinson wrote:
[Redirecting to debian-devel; followups set.]
On Mon, Sep 20, 2004 at 02:29:32PM +0200, Wouter Hanegraaff
wrote:
Hi,
After a fresh sarge install, I'm having problems with umask
settings. In /etc/login.defs I set umask to 002, and that works
for logging in on the console or remote via ssh. However, if I
use {g,x,k}dm I keep getting an umask of 022, because Xsession
is started by the display manager which has a default umask of
022.
It seems that Xsession doesn't change the UMASK at all. Should
it do so? If not, which program should set the umask during a
graphical login?
Searching Google for "xsession umask" will give you some hints.
/etc/login.defs explicitly indicates that it is "Configuration
control definitions for the login package", and many of its
parameters are inapplicable to display managers, or already
implemented in parallel (e.g., how long do wait after a failed
login before displaying the prompt/greeter again?).
I believe that /etc/login.defs _is_ the right place to define the
default umask property.
// Tomas
--
Tomas Fasth <[EMAIL PROTECTED]>
GnuPG 0x9FE8D504
Re: Xsession doesn't use umask setting from /etc/login.defs
[Redirecting to debian-devel; followups set.]
On Mon, Sep 20, 2004 at 02:29:32PM +0200, Wouter Hanegraaff wrote:
> Hi,
>
> After a fresh sarge install, I'm having problems with umask settings. In
> /etc/login.defs I set umask to 002, and that works for logging in on the
> console or remote via ssh. However, if I use {g,x,k}dm I keep getting an
> umask of 022, because Xsession is started by the display manager which
> has a default umask of 022.
>
> It seems that Xsession doesn't change the UMASK at all. Should it do so?
> If not, which program should set the umask during a graphical login?
Good question.
debian-devel folks, what do you think? I'm having difficulty deciding how
to think about this issue.
/etc/login.defs explicitly indicates that it is "Configuration control
definitions for the login package", and many of its parameters are
inapplicable to display managers, or already implemented in parallel (e.g.,
how long do wait after a failed login before displaying the prompt/greeter
again?).
By analogy, /etc/environment is a PAM thing and should only be dealt with
by PAM. (We can't use it anyway since the umask is not an environment
variable.)
* What's the path of least resistance?
* What would violate user expectations the least?
* What would be a good ideal approach, if code changes weren't an issue?
--
G. Branden Robinson| You could wire up a dead rat to a
Debian GNU/Linux | DIMM socket and the PC BIOS memory
[EMAIL PROTECTED] | test would pass it just fine.
http://people.debian.org/~branden/ | -- Ethan Benson
signature.asc
Description: Digital signature
Xsession doesn't use UMASK setting from /etc/login.defs
Hi,
After a fresh sarge install, I'm having problems with umask settings. In
/etc/login.defs I set umask to 002, and that works for logging in on the
console or remote via ssh. However, if I use {g,x,k}dm I keep getting an
umask of 022, because Xsession is started by the display manager which
has a default umask of 022.
It seems that Xsession doesn't change the UMASK at all. Should it do so?
If not, which program should set the umask during a graphical login?
Wouter
