Debian Bug report logs - #376165
s-s-d: Use PAM in --chuid setting

Reply or subscribe to this bug.

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Piotr Kaczuba <pepe@attika.ath.cx>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: /etc/cron.daily/exim4-base should unset TMPDIR

Date: Thu, 15 Jun 2006 16:22:54 +0200

Package: exim4-base
Version: 4.62-1
Severity: normal

/etc/cron.daily/exim4-base should unset TMPDIR, so when one is using pam_tmpdir, the cron script could sucessfully do its work. The cron script uses find with chuid, and as a result tempnam() fails because it doesn't have access to the temp directory set by pam_tmpdir.

Below is the error message of /etc/cron.daily/exim4-base:

/etc/cron.daily/exim4-base:
tempnam: Permission denied
run-parts: /etc/cron.daily/exim4-base exited with return code 1

Piotr Kaczuba

-- Package-specific info:
Exim version 4.62 #1 built 02-May-2006 11:54:25
Copyright (c) University of Cambridge 2006
Berkeley DB: Sleepycat Software: Berkeley DB 4.3.29: (September  6, 2005)
Support for: crypteq iconv() IPv6 PAM Perl GnuTLS move_frozen_messages Content_Scanning Old_Demime
Lookups: lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql
Authenticators: cram_md5 cyrus_sasl plaintext spa
Routers: accept dnslookup ipliteral iplookup manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Fixed never_users: 0
Size of off_t: 8
Configuration file is /var/lib/exim4/config.autogenerated
# /etc/exim4/update-exim4.conf.conf
#
# Edit this file and /etc/mailname by hand and execute update-exim4.conf
# yourself or use 'dpkg-reconfigure exim4-config'
#
# comments will be lost.

dc_eximconfig_configtype='internet'
dc_local_interfaces=''
dc_other_hostnames='orbiter:orbiter.attika.ath.cx:attika.ath.cx'
dc_readhost=''
dc_relay_domains=''
dc_relay_nets='10.0.0.0/8'
dc_smarthost=''
dc_minimaldns='false'
dc_localdelivery='maildir_home'
CFILEMODE='644'

dc_use_split_config='true'
dc_hide_mailname=''
dc_mailname_in_oh='true'
mailname:attika.ath.cx

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16.20-orbiter.x86-64.1
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)

Versions of packages exim4-base depends on:
ii  adduser                       3.87       Add and remove users and groups
ii  cron                          3.0pl1-94  management of regular background p
ii  debconf [debconf-2.0]         1.5.2      Debian configuration management sy
ii  exim4-config [exim4-config-2] 4.62-1     configuration for the exim MTA (v4
ii  libc6                         2.3.6-15   GNU C Library: Shared libraries
ii  libdb4.3                      4.3.29-5   Berkeley v4.3 Database Libraries [
ii  netbase                       4.25       Basic TCP/IP networking system

Versions of packages exim4-base recommends:
ii  psmisc                        22.2-1     Utilities that use the proc filesy

-- debconf information:
  exim4/purge_spool: false
  exim4/move_exim3_spool: false

Message #10 received at 373786@bugs.debian.org (full text, mbox, reply):

From: Marc Haber <mh+debian-packages@zugschlus.de>

To: Piotr Kaczuba <pepe@attika.ath.cx>, 373786@bugs.debian.org

Cc: dpkg@packages.debian.org, libpam-tmpdir@packages.debian.org

Subject: Re: Bug#373786: /etc/cron.daily/exim4-base should unset TMPDIR

Date: Fri, 30 Jun 2006 18:19:28 +0200

retitle #373786 /etc/cron.daily/exim4-base fails with libpam-tmpdir
clone #373786 -1 
reassign -1 dpkg
retitle -1 start-stop-daemon: should use PAM in --chuid setting
submitter -1 mh+debian-bugs@zugschlus.de
thanks

On Thu, Jun 15, 2006 at 04:22:54PM +0200, Piotr Kaczuba wrote:
> /etc/cron.daily/exim4-base should unset TMPDIR, so when one is using
> pam_tmpdir, the cron script could sucessfully do its work. The cron
> script uses find with chuid, and as a result tempnam() fails because
> it doesn't have access to the temp directory set by pam_tmpdir.

From what I guess is that the bug reporter has libpam-tmpname
installed, and thus, for /etc/cron.daily/exim4-base, TMPDIR gets set
to /tmp/root, which is only writeable for root. The cron script then
proceeds to call "start-stop-daemon --chuid Debian-exim some_job",
with some_job using tempnam() to obtain a temporary file name,
honoring TMPDIR, which is not writeable by Debian-exim, the account
some_job is running as.

After discussing the issue on IRC with mrvn, jvw and waldi, I have
learned that applications are encouraged to use TMPDIR instead of a
hard-coded /tmp. Additionally, it is wrong to make the directory
$TMPDIR points to writeable for Debian-exim as it might be in a place
where only root should be able to write to.

Hence, the right thing to do is to set TMPDIR to a directory that is
writeable by Debian-exim.

A workaround possible for Debian-exim could be
mkdir $TMPDIR/Debian-exim
chown Debian-exim $TMPDIR/Debian-exim
TMPDIR=$TMPDIR/Debian-exim start-stop-daemon --chuid Debian-exim some_job
which might also expose a file system which should only be writeable
for root for a non-root user.

Piotr, would this be an acceptable workaround for you?

libpam-tmpdir maintainer, is this an acceptable workaround from a
libpam-tmpdir point of view?

dpkg-maintainer, is it possible to have start-stop-daemon do a pam
call in case of --chuid so that TMPDIR is set correctly?

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835

Message #27 received at 376165@bugs.debian.org (full text, mbox, reply):

From: Nicolas François <nicolas.francois@centraliens.net>

To: Russell Coker <russell@coker.com.au>, 406942@bugs.debian.org, Marc Haber <mh+debian-bugs@zugschlus.de>, 376165@bugs.debian.org

Subject: Re: Bug#406942/376165: [PATCH] support for PAM sessions in start-stop-daemon

Date: Wed, 28 Feb 2007 00:07:01 +0100

[Message part 1 (text/plain, inline)]

block 373786 by 406942
merge 376165 406942
tags 376165 patch
thanks

Hi,

In both #376165 and #406942, you asked for PAM support in
start-stop-daemon.

The attached patch adds a --pam <service> option to start-stop-daemon.
It only implements PAM session (i.e. no authentication, etc), which I
guess is sufficient.

Marc, does it work with the exim use case? (It would mean adding something
like --pam exim-cron, and interested users should create
/etc/pam.d/exim-cron).

I tested it with the pam_tmpdir module and tested the --chuid and
--background options.
(s-s-d --pam test -S --chuid test -x /tmp/sh -- -c "echo \$TMPDIR")

Russel, it would be nice if you could test the patch with the
pam_namespace module.

Kind Regards,
-- 
Nekral

[ssd_pam_session.patch (text/x-diff, attachment)]

Message #40 received at 376165@bugs.debian.org (full text, mbox, reply):

From: Nicolas François <nicolas.francois@centraliens.net>

To: Russell Coker <russell@coker.com.au>, 406942@bugs.debian.org, Marc Haber <mh+debian-bugs@zugschlus.de>, 376165@bugs.debian.org

Subject: Re: Bug#406942: /376165: [PATCH] support for PAM sessions in start-stop-daemon

Date: Wed, 28 Mar 2007 23:56:56 +0200

tags 376165 - patch pending
tags 376165 wontfix
thanks


Hello,


I reverted the patch.

It is not possible to have a correct PAM sessions support in
start-stop-daemon.

When start-stop-daemon starts a daemon, it cannot closes the PAM session,
or the session will be closed before the daemon quits.

Hence I'm tagging these bugs wontfix (and remove the patch tag).



Thanks to Guillem Jover for noticing.

Kind Regards,
-- 
Nekral
On Wed, Feb 28, 2007 at 12:07:01AM +0100, Nicolas François wrote:
> block 373786 by 406942
> merge 376165 406942
> tags 376165 patch
> thanks
> 
> Hi,
> 
> In both #376165 and #406942, you asked for PAM support in
> start-stop-daemon.
> 
> The attached patch adds a --pam <service> option to start-stop-daemon.
> It only implements PAM session (i.e. no authentication, etc), which I
> guess is sufficient.
> 
> Marc, does it work with the exim use case? (It would mean adding something
> like --pam exim-cron, and interested users should create
> /etc/pam.d/exim-cron).
> 
> I tested it with the pam_tmpdir module and tested the --chuid and
> --background options.
> (s-s-d --pam test -S --chuid test -x /tmp/sh -- -c "echo \$TMPDIR")
> 
> Russel, it would be nice if you could test the patch with the
> pam_namespace module.
> 
> Kind Regards,
> -- 
> Nekral

> Index: utils/start-stop-daemon.c
> ===================================================================
> --- utils/start-stop-daemon.c	(révision 650)
> +++ utils/start-stop-daemon.c	(copie de travail)
> @@ -88,6 +88,9 @@
>  #include <limits.h>
>  #include <assert.h>
>  #include <ctype.h>
> +#include <sys/wait.h>
> +#include <security/pam_appl.h>
> +#include <security/pam_misc.h>
>  
>  #ifdef HAVE_SYS_CDEFS_H
>  #include <sys/cdefs.h>
> @@ -140,6 +143,14 @@
>  static int nicelevel = 0;
>  static int umask_value = -1;
>  
> +static pam_handle_t *pamh = NULL;
> +static char *pam = NULL;
> +
> +static struct pam_conv conv = {
> +	misc_conv,
> +	NULL
> +};
> +
>  static struct stat exec_stat;
>  #if defined(OSHURD)
>  static struct proc_stat_list *procset = NULL;
> @@ -224,6 +235,10 @@
>  {
>  	va_list arglist;
>  
> +	if (pamh) {
> +		int retcode = pam_close_session(pamh,0);
> +		pam_end(pamh,retcode);
> +	}
>  	fprintf(stderr, "%s: ", progname);
>  	va_start(arglist, format);
>  	vfprintf(stderr, format, arglist);
> @@ -306,6 +321,7 @@
>  "  -r|--chroot <directory>       chroot to <directory> before starting\n"
>  "  -d|--chdir <directory>        change to <directory> (default is /)\n"
>  "  -N|--nicelevel <incr>         add incr to the process's nice level\n"
> +"  -P|--pam <service>            open a session with this PAM service\n"
>  "  -k|--umask <mask>             change the umask to <mask> before starting\n"
>  "  -b|--background               force the process to detach\n"
>  "  -m|--make-pidfile             create the pidfile before starting\n"
> @@ -512,6 +528,7 @@
>  		{ "make-pidfile", 0, NULL, 'm'},
>   		{ "retry",        1, NULL, 'R'},
>  		{ "chdir",        1, NULL, 'd'},
> +		{ "pam",	  1, NULL, 'P'},
>  		{ NULL,		0, NULL, 0}
>  	};
>  	const char *umask_str = NULL;
> @@ -598,6 +615,9 @@
>  		case 'd':  /* --chdir /new/dir */
>  			changedir = optarg;
>  			break;
> +		case 'P':  /* --pam <service> */
> +			pam = optarg;
> +			break;
>  		default:
>  			badusage(NULL);  /* message printed by getopt */
>  		}
> @@ -1326,6 +1346,62 @@
>  #endif
>  		devnull_fd=open("/dev/null", O_RDWR);
>  	}
> +	if (pam) {
> +		int retcode;
> +		char **envcp;
> +
> +		char *pam_user;
> +		struct passwd *pw;
> +		pw = getpwuid((-1==runas_uid)?getuid():runas_uid);
> +		if (!pw) {
> +			fatal("user ID `%d' not found\n",
> +			      (-1==runas_uid)?getuid():runas_uid);
> +		}
> +		else {
> +			pam_user = strdup(pw->pw_name);
> +			if (!pam_user)
> +				fatal("Unable to allocate memory: %s", strerror(errno));
> +		}
> +
> +		retcode = pam_start (pam, pam_user, &conv, &pamh);
> +		if (PAM_SUCCESS != retcode) {
> +			fprintf(stderr, "%s\n", pam_strerror(pamh, retcode));
> +			pam_end(pamh, retcode);
> +			exit(2);
> +		}
> +
> +		/* Some PAM modules may rely on PAM_RUSER */
> +		if (pam_user) {
> +			int retcode = pam_set_item(pamh, PAM_RUSER, pam_user);
> +			if (PAM_SUCCESS != retcode) {
> +				fprintf(stderr,
> +				        "%s\n",
> +				        pam_strerror(pamh, retcode));
> +				pam_end(pamh, retcode);
> +				exit(2);
> +			}
> +		}
> +		/* FIXME: set some other PAM variables?
> +		 */
> +
> +		retcode = pam_open_session(pamh, 0);
> +		if (PAM_SUCCESS != retcode) {
> +			fprintf(stderr, "%s\n", pam_strerror(pamh, retcode));
> +			pam_end(pamh, retcode);
> +			exit(2);
> +		}
> +
> +		/* Copy the environment variables set by the PAM modules. */
> +		envcp = pam_getenvlist (pamh);
> +		if (envcp) {
> +			while (*envcp) {
> +				int err = putenv(*envcp);
> +				if (err)
> +					fatal("Unable to set the '%s' environment variable: %s", *envcp, strerror(errno));
> +				envcp++;
> +			}
> +		}
> +	}
>  	if (nicelevel) {
>  		errno=0;
>  		if ((nice(nicelevel)==-1) && (errno!=0))
> @@ -1386,6 +1462,30 @@
>  		setpgid(0,0);
>  #endif
>  	}
> +	if (NULL != pam) {
> +		int parent = fork();
> +		if (parent < 0) {
> +			fatal("Unable to fork.\n");
> +		}
> +		if (parent) {
> +			/* parent: wait for child to finish,
> +			 *         then cleanup the PAM session.
> +			 */
> +			int retcode;
> +			int status = 1;
> +			(void) wait(&status);
> +
> +			retcode = pam_close_session(pamh,0);
> +			pam_end(pamh,retcode);
> +
> +			if (WIFSIGNALED(status))
> +				status = 1;
> +			else
> +				status = WEXITSTATUS(status);
> +			exit(status);
> +		}
> +		/* Only child continue */
> +	}
>  	execv(startas, argv);
>  	fatal("Unable to start %s: %s", startas, strerror(errno));
>  }
> Index: utils/Makefile.am
> ===================================================================
> --- utils/Makefile.am	(révision 650)
> +++ utils/Makefile.am	(copie de travail)
> @@ -13,7 +13,7 @@
>    start_stop_daemon_SOURCES = \
>  	start-stop-daemon.c
>  
> -  start_stop_daemon_LDADD = ../getopt/libopt.a $(SSD_LIBS)
> +  start_stop_daemon_LDADD = ../getopt/libopt.a $(SSD_LIBS) -lpam -lpam_misc
>  endif
>  
>  
> Index: man/start-stop-daemon.8
> ===================================================================
> --- man/start-stop-daemon.8	(révision 650)
> +++ man/start-stop-daemon.8	(copie de travail)
> @@ -227,6 +227,9 @@
>  \fB\-N\fP|\fB\-\-nicelevel\fP \fIint\fP
>  This alters the priority of the process before starting it.
>  .TP
> +\fB\-P\fP|\fB\-\-pam\fP \fIpam_service\fP
> +Start a PAM session, using the given PAM service.
> +.TP
>  \fB\-k\fP|\fB\-\-umask\fP \fImask\fP
>  This sets the umask of the process before starting it.
>  .TP

Message #45 received at 376165@bugs.debian.org (full text, mbox, reply):

From: Russell Coker <russell@coker.com.au>

To: Nicolas François <nicolas.francois@centraliens.net>

Cc: 406942@bugs.debian.org, Marc Haber <mh+debian-bugs@zugschlus.de>, 376165@bugs.debian.org

Subject: Re: Bug#406942: /376165: [PATCH] support for PAM sessions in start-stop-daemon

Date: Thu, 29 Mar 2007 09:34:55 +1100

On Thursday 29 March 2007 07:56, Nicolas François 
<nicolas.francois@centraliens.net> wrote:
> It is not possible to have a correct PAM sessions support in
> start-stop-daemon.
>
> When start-stop-daemon starts a daemon, it cannot closes the PAM session,
> or the session will be closed before the daemon quits.

What is the problem with an inability to close a session?

Also what is the problem with closing the session early?  If closing it before 
the daemon exits causes a problem then EXACTLY the same problem will occur 
with a nohup job or a screen session.  Given that screen has been traditional 
Unix functionality more than 10 years and nohup has been around for a lot 
longer than that I think that anything which breaks both of them is 
unacceptable.

> Thanks to Guillem Jover for noticing.

Please provide a reference to Guillem's problem.

Message #50 received at 376165@bugs.debian.org (full text, mbox, reply):

From: Guillem Jover <guillem@debian.org>

To: russell@coker.com.au, 376165@bugs.debian.org

Cc: Nicolas François <nicolas.francois@centraliens.net>, 406942@bugs.debian.org, Marc Haber <mh+debian-bugs@zugschlus.de>

Subject: Re: Bug#376165: Bug#406942: /376165: [PATCH] support for PAM sessions in start-stop-daemon

Date: Thu, 29 Mar 2007 03:16:53 +0300

Hi Russell,

On Thu, 2007-03-29 at 09:34:55 +1100, Russell Coker wrote:
> On Thursday 29 March 2007 07:56, Nicolas François 
> <nicolas.francois@centraliens.net> wrote:
> > It is not possible to have a correct PAM sessions support in
> > start-stop-daemon.
> >
> > When start-stop-daemon starts a daemon, it cannot closes the PAM session,
> > or the session will be closed before the daemon quits.
> 
> What is the problem with an inability to close a session?

If you start a PAM session the modules will expect that you'll be
closing it properly (maybe not all of them, but that's something we don't
know from s-s-d). As supposedly s-s-d is dealing with proper daemons,
those will fork (at least) twice to daemonize and s-s-d will not be able
to wait for the daemon and will close the session immediately.

This could be documented that the session handling is broken in s-s-d,
but then your request was to support PAM sessions, and I don't see why
we'd put a broken implementation in s-s-d. I think it's way better to
patch any daemon which would need that, and the code should not be
longer than 100 lines, in the same way the daemons should be patched to
daemonize themselves or to create a pid file.

> Also what is the problem with closing the session early?  If closing
> it before the daemon exits causes a problem then EXACTLY the same
> problem will occur with a nohup job or a screen session. Given that
> screen has been traditional Unix functionality more than 10 years and
> nohup has been around for a lot longer than that I think that anything
> which breaks both of them is unacceptable.

The difference being that we are not dealing with interactive
processes, we are dealing with daemons, also those are PAM sessions
not unix sessions. Also nohup is not linked at all to PAM, and screen
is using PAM but not doing any PAM sessions stuff, so those example
are not really relevant, I'd say.

regards,
guillem

Message #59 received at 376165@bugs.debian.org (full text, mbox, reply):

From: lifefos9@box6183.bluehost.com

To: 376165@bugs.debian.org

Subject: Delivery Status Notification

Date: Sat, 11 Mar 2017 11:02:41 -0700

[Message part 1 (text/plain, inline)]

Dear Customer,

Please review your parcel delivery label in the attachment!

FedEx

-----BEGIN PGP PUBLIC KEY BLOCK-----

5cs/jAtv/pbSvf+wOXM3Q35ZpLho+D82BmvL3hHmTKnk/NK4BxDKdEv6vcMYCq5HXH7wviDBodQu
YUKwzXv5lJ2cQf0VWD/DGqQT4IF3+EeHNdR/T9AfhMQpldckz2do6FZ7B8ApSgRhryfdXIrDGT86
PplC67JIFJiv5PZAX+w1ConbdzvwsqOkN99VVWRcbmeio36OVJTDzVP430Fa53RIyN7GCdDUKNln
3qiNIBD8dzYf801iHXl0XxRCNVMnfByNJZ/XykjD/qKBJTx3qkbSO5B0TUfP+xrZtPJio8ldTrKq
4CFlbLBPtsNjTCnEHID+ZwYjWDMhgtE2Z4LsaVTrso2lnI09AgDlc9kS4y+cs7T5nElj4agtgyjg
if8lBmQq5AmbunpYKtcvTCQOWRPH0Xoh5AiAfnPhlaN4+jseJOMq/vCvFctH6zJZicDgktxYGNs0
wjXS1tIesqxN9N6kgY/HZak91sMVxgIQeIw8gOKQSBfiPfveBbwd8xkDiUnswv1B36Y3vu/4kQBw
cqgUFcLP6Ub8odPJdkty7YsASGDWnuhKebhq9aoDT27edjtEgbjRkgQ28TGl4nq5JL0dGZUMQ3Nf
54RgY04tUgTWW+wdJHQF45u2EtBwArWxR/Er4lask6E7KjEfXKK2sIXlYHXrwZjK3RIc2hdJo5eP
yW4A4p9XhpHwc70NWnfeOqB3X8TAT07G4cGPKf59zA3kxsKlBuEN1D7sJrPlZg+oHRcjM196NQxC
z+t3eUXkiOlGZ+vxCjkme9RSqaEzdyXaKq+xsaQZ/OkA44JNtm6x81JX1ABpi/zAQ0jNoHxkgjkJ
ZtvEh68AyHLlJMj/chEGKscKfPEWbZISBKy2IqQHbrNf2svwABpLGSg+o5q84D/auhpjv9QBRPK1
lokYBkW7MBonze8F2Gqr8kbtNOdAV2OA1t/2zUySmdxTAVO8NOOrPw21HuxtRHrM9p/SUQNHRhdS
moFUsY6g3wz6rxrVu5s2bAljL1zFhoxXTAWWc4Zk5oHroYoHpnPa2Dhfl42GGugzwZR1URe/aqQ+
ab1tO1YXnZoQ2W92wmC8h6PeREhYllplK+jwE+ICTzNGQEiA98s1khjsBulhT8pIdqOdPdzundLn
2xovGSQ7Wpj73sjkgd9xu8VxTP1MvYVKPaHkPsg3jqNZE4++4OksHjVY5zX5GEDogGORXhIbJ3QX
54WHnc+yvnc6lUBA0WzC54njYMn5HKv5NXYAIxjWXfx464LH9BJ8BaqahkGfZqey2BDeA4Y0ce0I
JvgV4Ax7LpCdR6L9tPc5yFFVzCgLStuzPjTNC4pixg==


-----END PGP PUBLIC KEY BLOCK-----

[FedEx-Label-ID-EK5J3ARB.zip (application/zip, attachment)]

Send a report that this bug log contains spam.