[PATCH] login-utils: import environment from user manager on systemd systems

[PATCH] login-utils: import environment from user manager on systemd systems

[Ray Strode]

From: Ray Strode <rstrode@redhat.com>

If the user is using a systemd system, then its useful to grab the
environment from the systemd user manager process.

This allows administrators to initialize the environment of the sessions
via systemd configuration.

Reference: https://github.com/systemd/systemd/pull/3904
Signed-off-by: Ray Strode <rstrode@redhat.com>
---
 login-utils/Makemodule.am |  5 +++
 login-utils/login.c       | 84 +++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 89 insertions(+)

diff --git a/login-utils/Makemodule.am b/login-utils/Makemodule.am
index be07ace..d65bfc1 100644
--- a/login-utils/Makemodule.am
+++ b/login-utils/Makemodule.am
@@ -16,70 +16,75 @@ endif
 if BUILD_SULOGIN
 sbin_PROGRAMS += sulogin
 dist_man_MANS += login-utils/sulogin.8
 sulogin_SOURCES = \
 	login-utils/sulogin.c \
 	login-utils/sulogin-consoles.c \
 	login-utils/sulogin-consoles.h
 sulogin_LDADD = $(LDADD) libcommon.la
 
 if HAVE_LIBCRYPT
 sulogin_LDADD += -lcrypt
 endif
 if HAVE_SELINUX
 sulogin_LDADD += -lselinux
 endif
 
 check_PROGRAMS += test_consoles
 test_consoles_SOURCES = login-utils/sulogin-consoles.c
 test_consoles_CFLAGS = $(AM_CFLAGS) -DTEST_PROGRAM
 test_consoles_LDADD = $(LDADD) libcommon.la
 endif # BUILD_SULOGIN
 
 
 if BUILD_LOGIN
 bin_PROGRAMS += login
 dist_man_MANS += login-utils/login.1
 login_SOURCES = \
 	login-utils/login.c \
 	login-utils/logindefs.c \
 	login-utils/logindefs.h
+login_CFLAGS =
 login_LDADD = $(LDADD) libcommon.la -lpam
 if HAVE_LINUXPAM
 login_LDADD += -lpam_misc
 endif
 if HAVE_AUDIT
 login_LDADD += -laudit
 endif
 if HAVE_SELINUX
 login_LDADD += -lselinux
 endif
+if HAVE_SYSTEMD
+login_LDADD += $(SYSTEMD_LIBS)
+login_CFLAGS += $(SYSTEMD_CFLAGS)
+endif
 endif # BUILD_LOGIN
 
 
 if BUILD_NOLOGIN
 sbin_PROGRAMS += nologin
 dist_man_MANS += login-utils/nologin.8
 nologin_SOURCES = login-utils/nologin.c
 endif
 
 
 if BUILD_UTMPDUMP
 usrbin_exec_PROGRAMS += utmpdump
 dist_man_MANS += login-utils/utmpdump.1
 utmpdump_SOURCES = login-utils/utmpdump.c
 utmpdump_LDADD = $(LDADD) libcommon.la
 endif
 
 
 if BUILD_CHFN_CHSH
 usrbin_exec_PROGRAMS += chfn chsh
 dist_man_MANS += \
 	login-utils/chfn.1 \
 	login-utils/chsh.1
 
 chfn_chsh_sources = \
 	login-utils/ch-common.h \
 	login-utils/ch-common.c
 chfn_chsh_cflags = $(SUID_CFLAGS) $(AM_CFLAGS)
 chfn_chsh_ldflags = $(SUID_LDFLAGS) $(AM_LDFLAGS)
 chfn_chsh_ldadd = libcommon.la
diff --git a/login-utils/login.c b/login-utils/login.c
index 2350fc3..9a9a86e 100644
--- a/login-utils/login.c
+++ b/login-utils/login.c
@@ -37,69 +37,74 @@
 #include <sys/time.h>
 #include <sys/resource.h>
 #include <sys/file.h>
 #include <termios.h>
 #include <string.h>
 #include <sys/ioctl.h>
 #include <sys/wait.h>
 #include <signal.h>
 #include <errno.h>
 #include <grp.h>
 #include <pwd.h>
 #include <utmp.h>
 #include <stdlib.h>
 #include <sys/syslog.h>
 #ifdef HAVE_LINUX_MAJOR_H
 # include <linux/major.h>
 #endif
 #include <netdb.h>
 #include <security/pam_appl.h>
 #ifdef HAVE_SECURITY_PAM_MISC_H
 # include <security/pam_misc.h>
 #elif defined(HAVE_SECURITY_OPENPAM_H)
 # include <security/openpam.h>
 #endif
 #include <sys/sendfile.h>
 
 #ifdef HAVE_LIBAUDIT
 # include <libaudit.h>
 #endif
 
+#ifdef HAVE_LIBSYSTEMD
+# include <systemd/sd-bus.h>
+#endif
+
 #include "c.h"
 #include "setproctitle.h"
 #include "pathnames.h"
 #include "strutils.h"
 #include "nls.h"
 #include "env.h"
 #include "xalloc.h"
 #include "all-io.h"
 #include "fileutils.h"
+#include "strv.h"
 #include "ttyutils.h"
 
 #include "logindefs.h"
 
 #define is_pam_failure(_rc)	((_rc) != PAM_SUCCESS)
 
 #define LOGIN_MAX_TRIES        3
 #define LOGIN_EXIT_TIMEOUT     5
 #define LOGIN_TIMEOUT          60
 
 #ifdef USE_TTY_GROUP
 # define TTY_MODE 0620
 #else
 # define TTY_MODE 0600
 #endif
 
 #define	TTYGRPNAME	"tty"	/* name of group to own ttys */
 #define VCS_PATH_MAX	64
 
 /*
  * Login control struct
  */
 struct login_context {
 	const char	*tty_path;	/* ttyname() return value */
 	const char	*tty_name;	/* tty_path without /dev prefix */
 	const char	*tty_number;	/* end of the tty_path */
 	mode_t		tty_mode;	/* chmod() mode */
 
 	char		*username;	/* from command line or PAM */
 
@@ -994,108 +999,187 @@ static void fork_session(struct login_context *cxt)
 
 	/*
 	 * child
 	 */
 	sigaction(SIGHUP, &oldsa_hup, NULL);		/* restore old state */
 	sigaction(SIGTERM, &oldsa_term, NULL);
 	if (got_sig)
 		exit(EXIT_FAILURE);
 
 	/*
 	 * Problem: if the user's shell is a shell like ash that doesn't do
 	 * setsid() or setpgrp(), then a ctrl-\, sending SIGQUIT to every
 	 * process in the pgrp, will kill us.
 	 */
 
 	/* start new session */
 	setsid();
 
 	/* make sure we have a controlling tty */
 	open_tty(cxt->tty_path);
 	openlog("login", LOG_ODELAY, LOG_AUTHPRIV);	/* reopen */
 
 	/*
 	 * TIOCSCTTY: steal tty from other process group.
 	 */
 	if (ioctl(0, TIOCSCTTY, 1))
 		syslog(LOG_ERR, _("TIOCSCTTY failed: %m"));
 	signal(SIGINT, SIG_DFL);
 }
 
+#ifdef HAVE_LIBSYSTEMD
+/*
+ * Import environment from systemd user manager
+ */
+static void import_systemd_user_environ(struct login_context *cxt)
+{
+	struct passwd *pwd = cxt->pwd;
+	int rc;
+	sd_bus *bus = NULL;
+	sd_bus_error error = SD_BUS_ERROR_NULL;
+	sd_bus_message *reply = NULL;
+	char *env_entry = NULL;
+	uid_t old_euid = geteuid();
+	int euid_changed = 0;
+
+	if (pwd->pw_uid != 0) {
+		assert(old_euid == getuid());
+
+		if (seteuid(pwd->pw_uid) < 0) {
+			syslog(LOG_ERR, _("seteuid failed: %m"));
+			return;
+		}
+		euid_changed = 1;
+	}
+
+	rc = sd_bus_default_user(&bus);
+
+	if (rc < 0) {
+		syslog(LOG_NOTICE, _("user bus unavailable: %m"));
+		return;
+	}
+
+	rc = sd_bus_get_property(bus,
+				 "org.freedesktop.systemd1",
+				 "/org/freedesktop/systemd1",
+				 "org.freedesktop.systemd1.Manager",
+				 "Environment",
+				 &error,
+				 &reply,
+				 "as");
+
+	if (rc < 0) {
+		syslog(LOG_NOTICE, _("user bus unable to return environment: %m"));
+		goto out;
+	}
+
+	rc = sd_bus_message_enter_container(reply, SD_BUS_TYPE_ARRAY, "s");
+
+	if (rc < 0)
+		goto out;
+
+	while ((rc = sd_bus_message_read_basic(reply, SD_BUS_TYPE_STRING, &env_entry)) > 0) {
+		char **env_tuple;
+
+		env_tuple = strv_split(env_entry, "=");
+
+		if (env_tuple && env_tuple[0] && env_tuple[1])
+			xsetenv(env_tuple[0], env_tuple[1], 0);
+
+		strv_free (env_tuple);
+	}
+	sd_bus_message_exit_container(reply);
+
+out:
+	sd_bus_error_free(&error);
+	reply = sd_bus_message_unref(reply);
+	bus = sd_bus_unref(bus);
+
+	if (euid_changed && seteuid(old_euid) < 0) {
+		syslog(LOG_ALERT, _("seteuid() failed"));
+		exit(EXIT_FAILURE);
+	}
+}
+#endif
+
 /*
  * Initialize $TERM, $HOME, ...
  */
 static void init_environ(struct login_context *cxt)
 {
 	struct passwd *pwd = cxt->pwd;
 	char *termenv, **env;
 	char tmp[PATH_MAX];
 	int len, i;
 
 	termenv = getenv("TERM");
 	if (termenv)
 		termenv = xstrdup(termenv);
 
 	/* destroy environment unless user has requested preservation (-p) */
 	if (!cxt->keep_env) {
 		environ = xmalloc(sizeof(char *));
 		memset(environ, 0, sizeof(char *));
 	}
 
 	xsetenv("HOME", pwd->pw_dir, 0);	/* legal to override */
 	xsetenv("USER", pwd->pw_name, 1);
 	xsetenv("SHELL", pwd->pw_shell, 1);
 	xsetenv("TERM", termenv ? termenv : "dumb", 1);
 	free(termenv);
 
 	if (pwd->pw_uid) {
 		if (logindefs_setenv("PATH", "ENV_PATH", _PATH_DEFPATH) != 0)
 			err(EXIT_FAILURE, _("failed to set the %s environment variable"), "PATH");
 
 	} else if (logindefs_setenv("PATH", "ENV_ROOTPATH", NULL) != 0 &&
 		   logindefs_setenv("PATH", "ENV_SUPATH", _PATH_DEFPATH_ROOT) != 0) {
 			err(EXIT_FAILURE, _("failed to set the %s environment variable"), "PATH");
 	}
 
 	/* mailx will give a funny error msg if you forget this one */
 	len = snprintf(tmp, sizeof(tmp), "%s/%s", _PATH_MAILDIR, pwd->pw_name);
 	if (len > 0 && (size_t) len < sizeof(tmp))
 		xsetenv("MAIL", tmp, 0);
 
 	/* LOGNAME is not documented in login(1) but HP-UX 6.5 does it. We'll
 	 * not allow modifying it.
 	 */
 	xsetenv("LOGNAME", pwd->pw_name, 1);
 
 	env = pam_getenvlist(cxt->pamh);
 	for (i = 0; env && env[i]; i++)
 		putenv(env[i]);
+
+#ifdef HAVE_LIBSYSTEMD
+	import_systemd_user_environ(cxt);
+#endif
 }
 
 /*
  * This is called for the -h option, initializes cxt->{hostname,hostaddress}.
  */
 static void init_remote_info(struct login_context *cxt, char *remotehost)
 {
 	const char *domain;
 	char *p;
 	struct addrinfo hints, *info = NULL;
 
 	cxt->remote = 1;
 
 	get_thishost(cxt, &domain);
 
 	if (domain && (p = strchr(remotehost, '.')) &&
 	    strcasecmp(p + 1, domain) == 0)
 		*p = '\0';
 
 	cxt->hostname = xstrdup(remotehost);
 
 	memset(&hints, 0, sizeof(hints));
 	hints.ai_flags = AI_ADDRCONFIG;
 	cxt->hostaddress[0] = 0;
 
 	if (getaddrinfo(cxt->hostname, NULL, &hints, &info) == 0 && info) {
 		if (info->ai_family == AF_INET) {
 			struct sockaddr_in *sa =
 				    (struct sockaddr_in *) info->ai_addr;
 
-- 
2.7.4

Re: [PATCH] login-utils: import environment from user manager on systemd systems

[Linda Walsh]

Ray Strode wrote:
> From: Ray Strode <rstrode@redhat.com>
>
> If the user is using a systemd system, then its useful to grab the
> environment from the systemd user manager process.
>
> This allows administrators to initialize the environment of the sessions
> via systemd configuration.
>   
---
    Isn't pam_env supposed to allow setting vars in setting up
a user's first login session?

(from /etc/security/pam_env.conf)
# This is the configuration file for pam_env, a PAM module to load in
# a configurable list of environment variables for an _authorized_ session.
#
# The original idea for this came from Andrew G. Morgan ...
#<quote>
#   Mmm. Perhaps you might like to write a pam_env module that reads a
#   default environment from a file? I can see that as REALLY
#   useful... Note it would be an "auth" module that returns PAM_IGNORE
#   for the auth part and sets the environment returning PAM_SUCCESS in
#   the setcred function...
#</quote>
#
# What I wanted was the REMOTEHOST variable set...

As an aside, I use that to set my DISPLAY to the remote host on 1st login.

It's only available when a user is establishing a session from a
remote system.   Calling it at other times won't have remotehost set.
(basically values of REMOTEHOST & DISPLAY should be kept intact much like
the TERM or LANG settigns.

Re: [PATCH] login-utils: import environment from user manager on systemd systems

[Ray Strode]

Hi,
>    Isn't pam_env supposed to allow setting vars in setting up
> a user's first login session?
It can, but it has a few problems

1) the file format is kind of weird
2) not all distros set user_readenv=1 so users cant set the
environment variables they want
3) pam_env doesn't provide a facility for 3rd party applications to
adjust the environment
4) PAM modules run in the context of a user but as root. Having a
bunch of independent plugins all running as root, and not necessarily
integrating with each other is a recipe for security problems,
especially if you throw environment variables into the mix.
(if pam_env is erroneously in the session stack before a pam_exec
call, the user could easily get root access)


This topic was discussed a bit in the cited systemd pull request, I think.

--Ray

Re: [PATCH] login-utils: import environment from user manager on systemd systems

[L. Walsh]

Ray Strode wrote:
> Hi,
>   
>>    Isn't pam_env supposed to allow setting vars in setting up
>> a user's first login session?
>>     
> It can, but it has a few problems
>
> 1) the file format is kind of weird
>   
---
    People looking at systemd's config files have said similar.

> 2) not all distros set user_readenv=1 so users cant set the
> environment variables they want
>   
----
    pam_env wasn't designed for reading user-set environment variables.
Can users modify systemd config files at will?  Can't users put their
envvars in their profiles? 

> 3) pam_env doesn't provide a facility for 3rd party applications to
> adjust the environment
>   
---
    I wasn't aware systemd could read users' profiles.  I've seen
many 3rd party apps add their needed env vars to the system "profile.d"
directory (for system wide changes) and some to a user's shell if they
were user-specific changes.
> 4) PAM modules run in the context of a user but as root.
----
    Most login related and system security processes do.  They are not
part of the kernel.  Systemd runs in a user-context as root, as well.
Are you saying that is insecure?

`   Pam_env is designed to be run before the user's first session has
been setup and not again.  Some environment variables are meant to have
the same lifetime as the login-(or audit) UID.  Just like TERM, any X
programs rely on DISPLAY and those things don't change unless a
new first-contact session is created when a user first accesses a
secure network from an outside location. 

> Having a
> bunch of independent plugins all running as root, and not necessarily
> integrating with each other is a recipe for security problems,
> especially if you throw environment variables into the mix.
>   
----
    True.  The pam modules have been vetted for about 10+ years and have 
good
security record, yet you seem quite willing to jump to a new solution
without such a track record. 
> (if pam_env is erroneously in the session stack before a pam_exec
> call, the user could easily get root access).
>   
If an administrator  misconfigures ANY system security and 
authentication modules a user could gain root access.  Pam_env was 
designed for a
first-contact to the system, as that's the only time 'REMOTEHOST' is set 
(presuming the user came from another system).  Does systemd set REMOTEHOST
and allow for a users DISPLAY variable to be defaulted to a dependent 
setting?
> This topic was discussed a bit in the cited systemd pull request, I think.
>   
----
    how is that relevant to a util-linux list?
-l

Re: [PATCH] login-utils: import environment from user manager on systemd systems

[L. Walsh]

Ray Strode wrote:
> From: Ray Strode <rstrode@redhat.com>
>
> If the user is using a systemd system, then its useful to grab the
> environment from the systemd user manager process.
>   
----
    The other issue you don't really touch on, is why should this be hard-
coded in various programs when this is seems exactly like why PAM was
invented. 

    I.e. why not have a PAM module, say "pam_sysd_env", that gets the
env from the systemd user module(s), so any programs using
PAM can include in their security/authentication stack, the same
way pam_env might be used now (not that they are necessarily mutually
exclusive).

    One of the issues with systemd is that it is doesn't re-use
existing interfaces, but tends to force programs to make changes to work
with sysd, where if it used the existing interfaces, no program-specific
changes might be required and no explicit dependencies are built in
tools so that the same tools can be used on sysd systems, vs. non-sysd
systems. 

    Minimizing code changes in existing, working code seems like a
safer design decision.  It is especially true that the more code paths
that are added to programs, the more test paths and opportunities for 
failure
are added.

Re: [PATCH] login-utils: import environment from user manager on systemd systems

[Ray Strode]

Hi,

> ----
>    Most login related and system security processes do.  They are not
> part of the kernel.  Systemd runs in a user-context as root, as well.
> Are you saying that is insecure?
I'm not sure why you're bringing up the kernel, that's a weird segue, but
no I'm not saying it's necessarily insecure to run user session code as root,
I'm just saying if you minimize the code running as root, you minimize risk.
Environment variables in particular are a large surface area for problems.

> Pam_env is designed to be run before the user's first session has
> been setup and not again.
That's not correct. Most distributions that use pam_env, run it for
any login session. But what does that have to do with my patch?

> Some environment variables are meant to have
> the same lifetime as the login-(or audit) UID.  Just like TERM, any X
> programs rely on DISPLAY and those things don't change unless a
> new first-contact session is created when a user first accesses a
> secure network from an outside location.
You lost me.  I think you're trying to explain to me what the scope
of DISPLAY and TERM are, but I'm not sure, and I don't know why you
would be doing that.  Can you reiterate your point more clearly?

>    True.  The pam modules have been vetted for about 10+ years and have good
> security record,
An okay track record, sure, but that doesn't somehow invalidate my point.
pam_env, in particular, has had a couple of CVEs, but either way it misses
the point.  This is about preemptive mitigation, we can choose where to put the
code, and one spot is inherently less risky than the other.

> yet you seem quite willing to jump to a new solution without such a track record.
This was all discussed on the systemd pull request that you for some reason
 won't read
(why? it's just a link with background information).

Originally, there was a patch to put the code in pam_systemd, but that idea was
ultimately rejected, because environment variables are an easy way to perturb a
system in unexpected ways.  Could it be done there? sure. Is it
riskier? yes!  why
incur the risk?

> Pam_env was designed for a
> first-contact to the system, as that's the only time 'REMOTEHOST' is set
> (presuming the user came from another system).
what? I think you have some side point, but you're not articulating it well.
pam_env can be configured to set REMOTEHOST from PAM_RHOST.
If so configured it will happen from any remotely initiated connection, not
just the first.

And indeed, REMOTEHOST is a commented out example provided in the
default pam_env conf file.  It's not used by default, but I really don't see
how this has anything to do with my patch.

> Does systemd set REMOTEHOST
> and allow for a users DISPLAY variable to be defaulted to a dependent
> setting?
No of course not.  The patch is about importing non-session-specific,
user environment variables into new sessions.  systemd --user runs
outside of a typical user session, and this makes sure environment
variables configured for systemd --user get picked up by new login
sessions.

If you want REMOTEHOST set to PAM_RHOST fine, but that's nothing
to do with this. Anyway, ssh already sets DISPLAY for you.  If you're
using rsh or telnet, well...I don't know what to say other than this patch
isn't getting in your way.

>> This topic was discussed a bit in the cited systemd pull request, I think.
>    how is that relevant to a util-linux list?
It's extremely relevant to the patch, since the patch is motivated by the
discussion there. How is that relevance not clear?

Do you just have mental block because "systemd" != "util-linux" ?  util-linux
already integrates with systemd.  It's not like this is the first
 #ifdef HAVE_LIBSYSTEMD added to the code.

Anyway, I talked with Karel about this approach before I started, and he's
tentatively onboard with the concept (again, see the cited url!)

I'd appreciate patch review, if you want to jump in, but I don't want to get
bogged down in a rehash of a discussion that's already been had elsewhere.

--Ray

Re: [PATCH] login-utils: import environment from user manager on systemd systems

[Ray Strode]

Hi,

>    The other issue you don't really touch on, is why should this be hard-
> coded in various programs when this is seems exactly like why PAM was
> invented.
Oh this was touched on, thoroughly, in the URL cited in the patch.

>    One of the issues with systemd is that it is doesn't re-use
> existing interfaces, but tends to force programs to make changes to work
> with sysd
There is no existing interface that meets the needs here. The closest you
can get is a pam session stack module, but as stated before, that idea has
been rejected (and I've already covered why on this thread and on the
systemd pull request).

>    Minimizing code changes in existing, working code seems like a
> safer design decision.
Safer than needlessly running code as root that doesn't need to be? We're
just going to have to agree to disagree I guess.

> It is especially true that the more code paths
> that are added to programs, the more test paths and opportunities for
> failure are added.
This I totally agree with!

--Ray

Re: [PATCH] login-utils: import environment from user manager on systemd systems

[Ray Strode]

Hi Karel,

On Tue, Oct 25, 2016 at 4:34 PM, Ray Strode <halfline@gmail.com> wrote:
> From: Ray Strode <rstrode@redhat.com>
>
> If the user is using a systemd system, then its useful to grab the
> environment from the systemd user manager process.
>
> This allows administrators to initialize the environment of the sessions
> via systemd configuration.

Any news on this?

--Ray

Re: [PATCH] login-utils: import environment from user manager on systemd systems

[Ruediger Meier]

On Wednesday 07 December 2016, Ray Strode wrote:
> Hi Karel,
>
> On Tue, Oct 25, 2016 at 4:34 PM, Ray Strode <halfline@gmail.com> 
wrote:
> > From: Ray Strode <rstrode@redhat.com>
> >
> > If the user is using a systemd system, then its useful to grab the
> > environment from the systemd user manager process.
> >
> > This allows administrators to initialize the environment of the
> > sessions via systemd configuration.
>
> Any news on this?

I really don't like this as already discussed.

> --Ray
> --
> To unsubscribe from this list: send the line "unsubscribe util-linux"
> in the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] login-utils: import environment from user manager on systemd systems

[Karel Zak]

On Wed, Dec 07, 2016 at 09:04:35PM +0100, Ruediger Meier wrote:
> On Wednesday 07 December 2016, Ray Strode wrote:
> > Hi Karel,
> >
> > On Tue, Oct 25, 2016 at 4:34 PM, Ray Strode <halfline@gmail.com> 
> wrote:
> > > From: Ray Strode <rstrode@redhat.com>
> > >
> > > If the user is using a systemd system, then its useful to grab the
> > > environment from the systemd user manager process.
> > >
> > > This allows administrators to initialize the environment of the
> > > sessions via systemd configuration.
> >
> > Any news on this?
> 
> I really don't like this as already discussed.

I had discussion about it with Ray on IRC, the conclusion has
been that the ideal solution would be to extend PAM to support 
another stack of modules. This stack will be executed on open PAM
session after switch from root to non-root user (after setuid()).

We had positive feedback about it from Red Hat PAM maintainer, but it
would be probably better to discuss it with PAM upstream. This change
will require a new stuff in PAM API.

The question is what to do *now* before the PAM will be extended. The
most simple solution will be to temporary merge Ray's patch for only
util-linux v2.30 (= for year 2017) to provide guys time to found a better
solution. 

It's important to say that v2.30 is expected in March/April, it's a long 
time to do a change in PAM...


Note, the issue is not about "bad boys from systemd camp". The
motivation for the change is wayland. The systemd has been selected as
a place where is possible to solve the problem.

Although I'm not sure why we need systemd as mediator, would be
possible to read the environment setting directly by login(1)? Or it's
expected that something (e.g. script) will be executed to get the session
initialized?

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: [PATCH] login-utils: import environment from user manager on systemd systems

[Ray Strode]

[-- Attachment #1: Type: text/plain, Size: 1092 bytes --]

Hi,

On Thu, Dec 8, 2016 at 6:24 AM Karel Zak <kzak@redhat.com> wrote:

> We had positive feedback about it from Red Hat PAM maintainer, but it
> would be probably better to discuss it with PAM upstream. This change
> will require a new stuff in PAM API.
>
Pretty sure Tomas is one of the upstream maintainers, but you're right,
discussion should take place upstream.

Although I'm not sure why we need systemd as mediator, would be
> possible to read the environment setting directly by login(1)? Or it's
> expected that something (e.g. script) will be executed to get the session
> initialized?
>
The point is, the environment of systemd --user services and processes
started
inside a logind registered session should get the same environment.  It
doesn't
really make sense for them to get out of sync. login(1) could try to read
all the
same environment configuration files as systemd, but systemd gets its
environment
from a variety of places (user.conf / systemd service files /
/etc/environment.d), so
I think getting the environment from the user manager is the best way to go.

--Ray

[-- Attachment #2: Type: text/html, Size: 2014 bytes --]

Fwd: [PATCH] login-utils: import environment from user manager on systemd systems

[Ray Strode]

(resending because gmail.com sent it as html email first time around)

Hi,

On Thu, Dec 8, 2016 at 6:24 AM Karel Zak <kzak@redhat.com> wrote:
>
> We had positive feedback about it from Red Hat PAM maintainer, but it
> would be probably better to discuss it with PAM upstream. This change
> will require a new stuff in PAM API.

Pretty sure Tomas is one of the upstream maintainers, but you're right,
discussion should take place upstream.

> Although I'm not sure why we need systemd as mediator, would be
> possible to read the environment setting directly by login(1)? Or it's
> expected that something (e.g. script) will be executed to get the session
> initialized?

The point is, the environment of systemd --user services and processes started
inside a logind registered session should get the same environment.  It doesn't
really make sense for them to get out of sync. login(1) could try to
read all the
same environment configuration files as systemd, but systemd gets its
environment
from a variety of places (user.conf / systemd service files /
/etc/environment.d), so
I think getting the environment from the user manager is the best way to go.

--Ray