Re: Xsession doesn't use umask setting from /etc/login.defs

2004-10-18 Thread Tomas Fasth

-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

2004-10-18 Thread Tomas Fasth

-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

2004-10-18 Thread Tomas Fasth

-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

2004-10-16 Thread Tomas Fasth

-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

2004-10-13 Thread Tomas Fasth

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