Package: gdm
Version: 2.4.1.6-1
Severity: important

Since version 2.4.1.6-1, gdm doesn't read /etc/environment anymore. This
is caused by the new PAM settings being quite sparse: while
/etc/pam.d/gdm-autologin uses pam_env.so, /etc/pam.d/gdm doesn't, and
this is especially annoying for locale settings.

Regards,

reassign 207394 libpam-runtime
retitle 207394 libpam-runtime: default common-* configs should have more modules by default
thanks

The default global /etc/pam.d/common-* files should list more modules than
pam_unix.  Specifically, common-auth should include:

auth       requisite  pam_nologin.so
auth       required   pam_env.so

Additionally, all modules should be listed commented-out with comments that
describe what they are for (similar to the way login does in its pam setup
file).  Modules that only tend to be used in text mode should probably be
excluded -- or perhaps a seperate session-common-text that contains
these (mostly commented) modules.

If every package ends up specifying all of the modules that form the
default Debian pam policy, there is little advantage to the common-*
setup, except to solve the md5 passwords problem, which would be a
shame.

auth       requisite  pam_nologin.so
auth       required   pam_env.so

I've reassigned the bug to libpam-runtime to have the defaults changed.

The fact is, the two modules you list above are not truly common to all
PAM services shipped by Debian.  The pam_nologin module is certainly
only used by applications which provide local or remote login services
(login, ssh, display managers), leaving many other applications --
remote file services, su/sudo, POP/IMAP/SMTP services -- which do not.
Adding pam_nologin.so to the common-auth config would certainly
represent an incompatible behavior change for these applications, and
not one for the better, IMHO.

The pam_env.so module might be safe to include in the common config, but
the fact that few services actually include it today indicates that most
package maintainers don't view it as important to their applications.

This is not the only advantage; it also gives administrators a single
set of files to edit when making common changes to their authentication
setup (such as switching to LDAP), and (post-sarge) facilitates admin
tools for updating this config through the package manager directly.

It should be used for them all -- the system startup scripts use this to
not allow logins while the system is still starting up.

Given that the system startup scripts expect this behaviour already, I think
the default pam config should definately be including this.

Users want the "system default" locale set -- this should probably be done
for all logins, to make it truly default.  This still leaves the
question of what non-PAM using things (such as startup scripts) should do
to set the locale, tho.

Again, this only applies to passwords.  It's not giving them a default
pam config that they can edit in one place, to include (or not
include) things such as limits setting in all applications with one
change.  I do hope that hasn't been overlooked in this new setup.

tags 207394 wontfix
thanks

Hi.  One major negative side effect of the way we are doing the PAM
transition is that no facility is provided for changing the common-*
files until administrative tools are updated to do so automatically.
The common-* files are *not* conffiles, but instead are configuration
files without an update mechanism.


When I authorized Steve's NMU, I mentioned that it was important that
we got the contents of the common-* files right the first time because
they would not change until after Sarge.

I actually find Steve's argument against pam_nologin.so
compelling--sudo and other non-login services do not want that module.

But even if the argument were compelling, it would not be compelling
for sarge.  I realize that I can introduce code to check for known
md5sums and if the md5sum is known then replace the file.  I'm not
willing to do that unless things are completely broken.

I do think use of pam_limits is an appropriate use of common-session.

But the primary goal of this transition is to support authentication
systems other than pam_unix easily.

By this, I hope you are meaning "won't fix for sarge", and not "won't fix
ever".

Why was the transition done this way, especially when the version
introducing the changes was in the archive before the transition was
announced?

It sounds like we really need a seperate auth (although, actually,
#84091 should be fixed, and then this can go in account where it
belongs) setup for su/sudo/etc vs logins.  This should also be a
common configfile, and it could be added without requiring any of the
md5 sum changes, as they would be new files.

You're unwilling to fix bugs at this stage for your base package?  Major
changes are still allowed by the posted timetable.

What a shame that more thought had not gone into how to make this a truely
useful common PAM setup for sarge, so that future transitions would be
far less likely.

    Ryan> On Mon, Sep 01, 2003 at 05:55:33PM -0400, Sam Hartman wrote:
    >> tags 207394 wontfix thanks

    Ryan> By this, I hope you are meaning "won't fix for sarge", and
    Ryan> not "won't fix ever".

Well, yes.  I won't fix any of this for sarge, and I'll only fix the
parts of this that I believe are bugs in the long run.


    >> Hi.  One major negative side effect of the way we are doing the
    >> PAM transition is that no facility is provided for changing the
    >> common-*

    >> When I authorized Steve's NMU, I mentioned that it was
    >> important that we got the contents of the common-* files right
    >> the first time because they would not change until after Sarge.

    Ryan> Why was the transition done this way, especially when the
    Ryan> version introducing the changes was in the archive before
    Ryan> the transition was announced?

This was a response to a longish discussion on debian-devel months
ago.  Your comments on what would have been desirable would have been
welcome during that discussion.  I think Steve and I might still have
disagreed with you, but we certainly would have considered the issues
you brought up.

Simply put, we followed the procedure for making changes in
Debian--asking debian-devel--and we implemented what we believed the
right solution was based on that discussion.


    >> I actually find Steve's argument against pam_nologin.so
    >> compelling--sudo and other non-login services do not want that
    >> module.

    Ryan> It sounds like we really need a seperate auth (although,
    Ryan> actually, #84091 should be fixed, and then this can go in
    Ryan> account where it belongs) setup for su/sudo/etc vs logins.

I'm not sure I agree.

    >> But even if the argument were compelling, it would not be
    >> compelling for sarge.  I realize that I can introduce code to
    >> check for known md5sums and if the md5sum is known then replace
    >> the file.  I'm not willing to do that unless things are
    >> completely broken.

    Ryan> You're unwilling to fix bugs at this stage for your base
    Ryan> package?  Major changes are still allowed by the posted
    Ryan> timetable.

I'm unwilling to introduce a mechanism for changing the common-* files
that is hackish and that will complicate the correct solution later.
If there were an RC bug or a bug that I agreed was important that
needed to be fixed, I would believe the change was worth the
complexity.  This bug is not something I believe is worth the
complexity of the change needed to fix it.

I feel the common-* files are misnamed, and should be named
password-*, to indicate their true purpose.  (or authtype-*, or
something to indicate that this is the only use).  Maybe one day
someone will come up with an actual common pam system for use in
Debian, but this definately isn't it, as you've made clear.

You're arguing based on what you believe *should* be common to all
PAMified services in Debian; the default contents of those files are
based on what has actually been found to *be* common to all PAMified
services at present.  There's nothing wrong with a local admin adding
pam_nologin to their own common-auth file if that's how they wish their
systems to work, but it would be inappropriate at this juncture to
attempt to impose such a change on other PAM apps by default.  Indeed,
adding any modules to those files other than pam_unix (or equivalent)
should be preceded by public discussion.

Hi.  A while back, I indicated that I would be enable to fix the fact
that /etc/pam.d/common-auth does not call pam_env or pam_nologin.  I
ended up needing to add support for updating /etc/pam.d/common-* for
another set of problems so I'm going to close out that bug too.

For these two modules at least, having them called both by common-auth
and by an application specific pam configuration should not cause any
problems.


I'm choosing not to implement your suggestion of having all the other
pam modules in common-auth commented out.  My hope is that
/etc/pam.d/common-* will be auto-generated in sarge+1 and so I don't
think this is appropriate.

I'm also not implementing the proposal of having a set of modules for
text-based sessions at this time.  I think it is a good one and there
is a bug open for it, but I don't think making a change that requires
all packages dependent on pam to change this late in the release
process is desirable.

On second thought, I'm actually not sure you want pam_nologin for
services like samba and imap servers.  Traditionally they  do not respect pam_nologin.

I'm also unsure of whether services that do not start user sessions
want pam_env.  I think it is probably harmless, but would prefer to
seek a few second opinions before uploading this change.


So I'm not as sure as I was a few minutes ago that common-auth should
call pam_nologin or pam_env.  I have a few days before I'm making what
I hope will be the final upload of PAM, so I will try and get input
before that upload.

[Sam Hartman]

Make sense to me.

In Debian Edu, /etc/environment is used to set the required HTTP proxy
globally.  It would be nice if it actually took effect for all services.
:)

As far as I know, there is no other alternative for /etc/environment for
variables that should be set everywhere for every user and process on
the machine. :)

    Petter> In Debian Edu, /etc/environment is used to set the required
    Petter> HTTP proxy globally.  It would be nice if it actually took
    Petter> effect for all services.  :)

    Petter> As far as I know, there is no other alternative for
    Petter> /etc/environment for variables that should be set everywhere
    Petter> for every user and process on the machine. :) -- Happy
    Petter> hacking Petter Reinholdtsen

I'd argue that this should be set in the systemd unit for the service
for a service that does not traditionally use sessions.
Also, I believe there is a way to get systemd to inject environment
variables into init's environment, so they are inherited until the
environment is cleared.
I'd generally agree that applications should either preserve their
environment, or use pam_env.

Hi,
set in some services. (like sudo -i)

So we should go around and ask every service, that could
need a proxy to properly read /etc/environment either via
pam_env or via systemd's EnvirontFile (or whatever the name
was)?


I have another question:

Can you imagine a (sane) setting in /etc/environment
breaking a (sane) application, when we add pam_env to
common-session*?

Settings, that are not for the system as a whole, should be
in another file. For example the locale is in
/etc/default/locale, and it is sensible to only load it for
local (interactive) users. So we have a clear set of
applications, that we need to modify.

But for /etc/environment I can't imagine any application,
that should not read it.


Greetings

    Elrond

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
     ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***

To limit from where root can log in, I set in /etc/security/access.conf:

+:root:tty1
-:root:ALL

but when running: systemctl disable some_service, systemd prompts for the root password
and succesfully runs the command.

As a fix I added "account required pam_access.so" to the top of /etc/pam.d/common-auth,
this successfully prevents authentication via systemctl.