Re: correct use of su
On Sun, May 11, 2014 at 11:12:08AM +1000, Brian May wrote: What about the task of running a short program for a brief duration, e.g. from cron scripts? Is using su considered acceptable? e.g. /etc/cron.daily/spamassassin on wheezy has numerous references to su. There are two reasons I use su in /etc/cron.daily/spamassassin. One is to change uid/gid, and the other is to reset the shell environment to a base state. The need for this was highlighted in bug 738951. I doubt that this is a problem unique to spamassassin. 'su -l' takes care of both uid switching and environment cleansing. start-stop-daemon only helps with the first. The appropriate solution for resetting the environment isn't apparent. Should s-s-d be extended with such functionality? Or is there a more appropriate tool that I'm missing? noah signature.asc Description: Digital signature
Re: MBF (Re: correct use of su)
El Mon, 12 de May 2014 a las 10:53 PM, Brian May br...@microcomaustralia.com.au escribió: On 13 May 2014 15:44, Cameron Norman camerontnor...@gmail.com wrote: I found another use of su that may need to be added to your list. rabbitmq (oddly) wraps itself up in a shell script, /usr/sbin/rabbitmq-server, which asserts the user is root or rabbitmq, and drops down to rabbitmq if it is root (using su), then starts the actual binary. The problem with this one is that it is upstream code and cannot use s-s-d for obvious reasons. I would imagine that the init.d script just needs to be modified to use the -c option of start-stop-daemon, and that way /usr/sbin/rabbitmq-server will be called with the correct user and won't run su. It looks like it already does this. I assume the user running the command manually would not hurt anything, correct? I assume that the init.d script could also call the actual binary directly. Yeah I dealing with issues with the PID being seemingly unpredictable (for some other thing I was doing), and that is how I fixed it. Do wonder how many packages call su in this manner though. It seems like there is a very real use case for it, I would assume a few more than what we have seen. Certainly not anything too formidable though. Best, -- Cameron Norman
Re: MBF (Re: correct use of su)
On 13 May 2014 16:15, Cameron Norman camerontnor...@gmail.com wrote: It looks like it already does this. I assume the user running the command manually would not hurt anything, correct? I think the user running the command manually would have the same problems. Especially as it is a daemon. Is this is something Debian needs to support or not? Perhaps not, as we already have a well defined interface for starting it that does the correct thing. Do wonder how many packages call su in this manner though. It seems like there is a very real use case for it, I would assume a few more than what we have seen. Certainly not anything too formidable though. I have written local scripts that do this. Or maybe I used sudo. Can't remember now. Probably nothing to worry about in any case, from memory, they are just short run administration tasks. AFAIK, using sudo is ok for non-interactive commands, right? Just need to make sure it is installed, and isn't installed by default. I think somebody already said that, just double checking. -- Brian May br...@microcomaustralia.com.au
Re: correct use of su
Hi! On Mon, 2014-05-12 at 22:50:39 -0700, Noah Meyerhans wrote: There are two reasons I use su in /etc/cron.daily/spamassassin. One is to change uid/gid, and the other is to reset the shell environment to a base state. The need for this was highlighted in bug 738951. I doubt that this is a problem unique to spamassassin. 'su -l' takes care of both uid switching and environment cleansing. start-stop-daemon only helps with the first. The appropriate solution for resetting the environment isn't apparent. Should s-s-d be extended with such functionality? Or is there a more appropriate tool that I'm missing? Ok, there seems to be two issues here, one is the environment inherited by the cronjob from cron(8), which is the one inherited by the daemon itself, depending on how it was started. The other (I take) is the environment inherited by the cron script when invoked from the maintainer script. While both are related they have different origin. There's https://bugs.debian.org/720163 against s-s-d, although as I mention there I'm not really comfortable resetting the environment by default as that implies a somewhat Debian specific policy hardcoded in s-s-d, but adding a new option or set of options for that would be appropriate. Or maybe just possibly taking the whitelist from a file shipped as part of base-files or similar would be fine too. Then there's https://bugs.debian.org/631081#58 against dpkg. But also as I mention there, the fix might need to be applied somewhere else, probably invoke-rc.d(8) or service(8). The problem with both those requests, if implemented, is that they would still not cover all entry points and people would still end up with dirty environments, say when invoking /etc/init.d/script directly, or because the environment might still affect other parts of the maint or init scripts besides the ones under dpkg or s-s-d control. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140513064731.ga14...@gaara.hadrons.org
Re: correct use of su
On Mon, 12 May 2014, Noah Meyerhans wrote:
On Sun, May 11, 2014 at 11:12:08AM +1000, Brian May wrote:
What about the task of running a short program for a brief duration, e.g.
from cron scripts? Is using su considered acceptable?
I thought s-s-d is for starting dæmons, not for things like that¹.
'su -l' takes care of both uid switching and environment cleansing.
start-stop-daemon only helps with the first. The appropriate solution
tglase@tglase:~ $ cat /usr/bin/cleanenv
#!/bin/sh
# $MirOS: src/scripts/cleanenv,v 1.4+notz+xorg 2009/03/29 13:04:20 tg Exp $
p=/bin:/usr/bin:/sbin:/usr/sbin
if test x$1 = x-; then
shift
exec /usr/bin/env -i \
PATH=$p HOME=/ \
$@
fi
exec /usr/bin/env -i \
PATH=$p $(locale 2/dev/null | fgrep LC_CTYPE) \
DISPLAY=$DISPLAY HOME=${HOME:-/} TERM=${TERM:-vt100} USER=${USER} \
$@
I’m using this like: 'cd /; cleanenv - /etc/init.d/apache2 start'
for resetting the environment isn't apparent. Should s-s-d be extended
with such functionality? Or is there a more appropriate tool that I'm
s-s-d is already way too complex, see also ① above.
On Tue, 13 May 2014, Colin Watson wrote:
perl -e '@pwd = getpwnam(man); $( = $) = $pwd[3]; $ = $ = $pwd[2];
exec /usr/bin/mandb, @ARGV' -- $@ || true
Would this work?
chroot --userspec=man:man / /usr/bin/mandb
This, like su(1), has the benefit of being in base.
It does not, like the other solutions, address things
like environment cleaning, setting up the environment
variables that should be changed for the new user, etc.
People use su(1) because ⓐ it’s in base, and ⓑ it’s
the right tool for the job on other Unix-like OSes
and has been it on GNU/Linux systems. Abusing chroot(8)
like this is… an “interesting” solution, but it avoids
pulling in (and configuring!) sudo(8). After all, the
local admin controls sudoers(5), and there is absolutely
no guarantee that root is permitted to use it, without
questioning for a password, logging, etc.
bye,
//mirabilos
--
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database” ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/alpine.deb.2.10.1405131126500.23...@tglase.lan.tarent.de
Re: MBF (Re: correct use of su)
Le 13 mai 2014 03:01, Michael Biebl bi...@debian.org a =C3=A9crit : Am 13.05.2014 02:54, schrieb Russ Allbery: Yeah, that's just what I was thinking. Any software that doesn't honor an invoke-rc.d policy is RC-buggy anyway, and it would be good to catch and fix that. Could you also open a big against Lintian: - describing how to detect this problem - a tag description with reference and solution It will help to avoid to reintroduce this kind of problem. Lintian has detected this for years as well as it's able. See: maintainer-script-should-not-use-start-stop-daemon maintainer-script-calls-init-script-directly I don't think there's anything further required in Lintian. --=20 Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87wqdpzo8o@windlord.stanford.edu
Re: MBF (Re: correct use of su)
Le 13 mai 2014 17:42, Russ Allbery r...@debian.org a écrit : Le 13 mai 2014 03:01, Michael Biebl bi...@debian.org a =C3=A9crit : Am 13.05.2014 02:54, schrieb Russ Allbery: Yeah, that's just what I was thinking. Any software that doesn't honor an invoke-rc.d policy is RC-buggy anyway, and it would be good to catch and fix that. Could you also open a big against Lintian: - describing how to detect this problem - a tag description with reference and solution It will help to avoid to reintroduce this kind of problem. Lintian has detected this for years as well as it's able. See: maintainer-script-should-not-use-start-stop-daemon maintainer-script-calls-init-script-directly I don't think there's anything further required in Lintian. It seems we now need to detect su I could easilly add detection of su but I need a description and solution Bastien --=20 Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87wqdpzo8o@windlord.stanford.edu
Re: correct use of su
On Sat, May 10, 2014 at 11:11:10PM -0700, Steve Langasek wrote:
On Sun, May 11, 2014 at 11:12:08AM +1000, Brian May wrote:
The name start-stop-daemon would suggest this is inappropriate for cron
jobs, is that an invalid assumption I made?
Perhaps a better name could have been chosen, in hindsight. But in
practice, s-s-d is the best available tool for uid switching in any
noninteractive scripts.
There are situations where start-stop-daemon is disabled to avoid
daemons starting up in inappropriate contexts (such as during d-i), yet
we still need to switch uids because the task at hand is not one of
those that should be disabled in such contexts. The example of this I'm
familiar with is in man-db.postinst, which has this code:
run_mandb () {
db_get man-db/auto-update
[ $RET = true ] || return 0
# start-stop-daemon isn't available when running from debootstrap.
perl -e '@pwd = getpwnam(man); $( = $) = $pwd[3]; $ = $ = $pwd[2];
exec /usr/bin/mandb, @ARGV' -- $@ || true
}
(This is not relevant for Brian's cron job case, of course, but I still
think it's worth mentioning as any noninteractive scripts is quite a
sweeping statement.)
It's a shame that there is, as far as I know, no low-level tool for this
in an Essential package.
--
Colin Watson [cjwat...@debian.org]
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140513002108.ga10...@riva.ucam.org
Re: correct use of su
On Tue, May 13, 2014 at 01:21:08AM +0100, Colin Watson wrote:
On Sat, May 10, 2014 at 11:11:10PM -0700, Steve Langasek wrote:
On Sun, May 11, 2014 at 11:12:08AM +1000, Brian May wrote:
The name start-stop-daemon would suggest this is inappropriate for cron
jobs, is that an invalid assumption I made?
Perhaps a better name could have been chosen, in hindsight. But in
practice, s-s-d is the best available tool for uid switching in any
noninteractive scripts.
There are situations where start-stop-daemon is disabled to avoid
daemons starting up in inappropriate contexts (such as during d-i), yet
we still need to switch uids because the task at hand is not one of
those that should be disabled in such contexts. The example of this I'm
familiar with is in man-db.postinst, which has this code:
run_mandb () {
db_get man-db/auto-update
[ $RET = true ] || return 0
# start-stop-daemon isn't available when running from debootstrap.
perl -e '@pwd = getpwnam(man); $( = $) = $pwd[3]; $ = $ = $pwd[2];
exec /usr/bin/mandb, @ARGV' -- $@ || true
}
(This is not relevant for Brian's cron job case, of course, but I still
think it's worth mentioning as any noninteractive scripts is quite a
sweeping statement.)
It's a shame that there is, as far as I know, no low-level tool for this
in an Essential package.
AFAIK, d-i disabling of s-s-d is a historical workaround for packages not
using invoke-rc.d (back in the days before it was a Policy must). Maybe
it's time to drop this diversion of s-s-d?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
Re: correct use of su
Steve Langasek vor...@debian.org writes: AFAIK, d-i disabling of s-s-d is a historical workaround for packages not using invoke-rc.d (back in the days before it was a Policy must). Maybe it's time to drop this diversion of s-s-d? Yeah, that's just what I was thinking. Any software that doesn't honor an invoke-rc.d policy is RC-buggy anyway, and it would be good to catch and fix that. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87oaz2a46e@windlord.stanford.edu
MBF (Re: correct use of su)
Am 13.05.2014 02:54, schrieb Russ Allbery: Steve Langasek vor...@debian.org writes: AFAIK, d-i disabling of s-s-d is a historical workaround for packages not using invoke-rc.d (back in the days before it was a Policy must). Maybe it's time to drop this diversion of s-s-d? Yeah, that's just what I was thinking. Any software that doesn't honor an invoke-rc.d policy is RC-buggy anyway, and it would be good to catch and fix that. Given the responses so far, I might consider doing a MBF based on the list I posted at [0]. I think this list is pretty complete wrt SysV init scripts. I could extend that to cronjobs etc if there is interest. Is there some general agreement that such a MBF would be worthwile/appreciated? Steve, Bigon, in such a case, would you be willing to help draft the MBF text? Michael [0] https://lists.debian.org/debian-devel/2014/05/msg00459.html -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: MBF (Re: correct use of su)
On Tue, May 13, 2014 at 03:01:10AM +0200, Michael Biebl wrote: Am 13.05.2014 02:54, schrieb Russ Allbery: Steve Langasek vor...@debian.org writes: AFAIK, d-i disabling of s-s-d is a historical workaround for packages not using invoke-rc.d (back in the days before it was a Policy must). Maybe it's time to drop this diversion of s-s-d? Yeah, that's just what I was thinking. Any software that doesn't honor an invoke-rc.d policy is RC-buggy anyway, and it would be good to catch and fix that. Given the responses so far, I might consider doing a MBF based on the list I posted at [0]. I think this list is pretty complete wrt SysV init scripts. I could extend that to cronjobs etc if there is interest. Is there some general agreement that such a MBF would be worthwile/appreciated? Sounds appropriate to me. Steve, Bigon, in such a case, would you be willing to help draft the MBF text? Sure. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: MBF (Re: correct use of su)
El Mon, 12 de May 2014 a las 6:01 PM, Michael Biebl bi...@debian.org escribió: Am 13.05.2014 02:54, schrieb Russ Allbery: Steve Langasek vor...@debian.org writes: AFAIK, d-i disabling of s-s-d is a historical workaround for packages not using invoke-rc.d (back in the days before it was a Policy must). Maybe it's time to drop this diversion of s-s-d? Yeah, that's just what I was thinking. Any software that doesn't honor an invoke-rc.d policy is RC-buggy anyway, and it would be good to catch and fix that. Given the responses so far, I might consider doing a MBF based on the list I posted at [0]. I think this list is pretty complete wrt SysV init scripts. I could extend that to cronjobs etc if there is interest. I found another use of su that may need to be added to your list. rabbitmq (oddly) wraps itself up in a shell script, /usr/sbin/rabbitmq-server, which asserts the user is root or rabbitmq, and drops down to rabbitmq if it is root (using su), then starts the actual binary. The problem with this one is that it is upstream code and cannot use s-s-d for obvious reasons. If I am wrong in thinking this usage would be buggy, then carry on. Best, -- Cameron Norman
Re: MBF (Re: correct use of su)
On 13 May 2014 15:44, Cameron Norman camerontnor...@gmail.com wrote: I found another use of su that may need to be added to your list. rabbitmq (oddly) wraps itself up in a shell script, /usr/sbin/rabbitmq-server, which asserts the user is root or rabbitmq, and drops down to rabbitmq if it is root (using su), then starts the actual binary. The problem with this one is that it is upstream code and cannot use s-s-d for obvious reasons. I would imagine that the init.d script just needs to be modified to use the -c option of start-stop-daemon, and that way /usr/sbin/rabbitmq-server will be called with the correct user and won't run su. I assume that the init.d script could also call the actual binary directly. Do wonder how many packages call su in this manner though. -- Brian May br...@microcomaustralia.com.au
Re: MBF (Re: correct use of su)
Le 13 mai 2014 03:01, Michael Biebl bi...@debian.org a écrit : Am 13.05.2014 02:54, schrieb Russ Allbery: Steve Langasek vor...@debian.org writes: AFAIK, d-i disabling of s-s-d is a historical workaround for packages not using invoke-rc.d (back in the days before it was a Policy must). Maybe it's time to drop this diversion of s-s-d? Yeah, that's just what I was thinking. Any software that doesn't honor an invoke-rc.d policy is RC-buggy anyway, and it would be good to catch and fix that. Could you also open a big against Lintian: - describing how to detect this problem - a tag description with reference and solution It will help to avoid to reintroduce this kind of problem. Thank you Given the responses so far, I might consider doing a MBF based on the list I posted at [0]. I think this list is pretty complete wrt SysV init scripts. I could extend that to cronjobs etc if there is interest. Is there some general agreement that such a MBF would be worthwile/appreciated? Steve, Bigon, in such a case, would you be willing to help draft the MBF text? Michael [0] https://lists.debian.org/debian-devel/2014/05/msg00459.html -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Re: correct use of su
On Sun, May 11, 2014 at 11:12:08AM +1000, Brian May wrote: On 11 May 2014 03:13, Matthias Urlichs matth...@urlichs.de wrote: su does a bunch of things that are perfectly appropriate for something that creates a new login. That's its job. I am still a bit confused, isn't this only when you use the -l su flag? The '-l' flag is defined rather vaguely in the documentation, but in practice it appears to only impact the inheritance of environment variables. Does su do stuff (e.g. pam session stuff) even without the -l flag? Yes. This has been the case for su in Debian since 1999, and to do otherwise would break a variety of configurations where session setup is required in order for, e.g., the su process to have access to the files of the target user. Running a daemon under its own UID is an almost-completely different problem. We already have a tool which does this (start-stop-daemon), which has been recommended for this task for umpteen years, and which still works if there is no .service file – for whatever reason. As a debian developer I was unaware of this. What about the task of running a short program for a brief duration, e.g. from cron scripts? Is using su considered acceptable? e.g. /etc/cron.daily/spamassassin on wheezy has numerous references to su. I think there might be other packages, this is just one I could find the quickest. Cronjobs are not always shortlived either, and can also cause these sorts of phantom sessions to show up to logind. I don't think we want to use su for cronjobs. The name start-stop-daemon would suggest this is inappropriate for cron jobs, is that an invalid assumption I made? Perhaps a better name could have been chosen, in hindsight. But in practice, s-s-d is the best available tool for uid switching in any noninteractive scripts. Systemd (as upstart) sidesteps this problem to a large degree by handling uid switching as a native directive, avoiding the need to call out to a separate command. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: correct use of su
On Sat, 10 May 2014 23:11:10 -0700, Steve Langasek vor...@debian.org wrote: On Sun, May 11, 2014 at 11:12:08AM +1000, Brian May wrote: The name start-stop-daemon would suggest this is inappropriate for cron jobs, is that an invalid assumption I made? Perhaps a better name could have been chosen, in hindsight. But in practice, s-s-d is the best available tool for uid switching in any noninteractive scripts. Maybe we should change s-s-d to something like su-non-interactive (bad name, didn't come up with something any better) and provide s-s-d as a link. Just out of curiosity: Which use is left to su if it is not supposed to be used around init scripts and cron jobs any more? In interactive sessions, we usually use sudo for fifteen years, is su really completely deprecated for a decade and more? Systemd (as upstart) sidesteps this problem to a large degree by handling uid switching as a native directive, avoiding the need to call out to a separate command. Just out of curiosity: What do I do when I convert an init script that parses a mode 600 configuration file (containing passwords), does necessary things as root and then starts a non-root daemon to systemd? How do I do that with using a native directive? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1wjo5e-0001sl...@swivel.zugschlus.de
Re: correct use of su
Le 11/05/2014 09:22, Marc Haber a écrit : Systemd (as upstart) sidesteps this problem to a large degree by handling uid switching as a native directive, avoiding the need to call out to a separate command. Just out of curiosity: What do I do when I convert an init script that parses a mode 600 configuration file (containing passwords), does necessary things as root and then starts a non-root daemon to systemd? How do I do that with using a native directive? In systemd, the ExecStartPre directive can be helpful. But the documentation doesn't say if it is executed as the user defined in the User directive, or as root. I guess the latter is done, but I'm too lazy right now to test it :) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/536f2d21.8070...@antipoul.fr
Re: correct use of su
On Sun, May 11, 2014 at 09:56:17AM +0200, Adrien Clerc wrote: In systemd, the ExecStartPre directive can be helpful. But the documentation doesn't say if it is executed as the user defined in the User directive, or as root. I guess the latter is done, but I'm too lazy right now to test it :) From the systemd.service[0] manual page (search for User=): PermissionsStartOnly= Takes a boolean argument. If true, the permission-related execution options, as configured with User= and similar options (see systemd.exec(5) for more information), are only applied to the process started with ExecStart=, and not to the various other ExecStartPre=, ExecStartPost=, ExecReload=, ExecStop=, and ExecStopPost= commands. If false, the setting is applied to all configured commands the same way. Defaults to false. [0]: http://www.freedesktop.org/software/systemd/man/systemd.service.html -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140511080509.ga32...@havelock.liw.fi
Re: correct use of su
previously on this list Steve Langasek contributed: Yes. This has been the case for su in Debian since 1999, and to do otherwise would break a variety of configurations where session setup is required in order for, e.g., the su process to have access to the files of the target user. It seems to me that someone needlessly? dropped the ball in 1999 then and this should have perhaps been a new flag or added to -l where PAM is in use, as it fundamentally changes the behaviour contrary to the varying titles of su. Now done of course and for so long I wouldn't know what the fallout to debian and other things would be and so the best way to fix this bug today at all. I do know that I would much prefer if a script in rc.local that uses su to drop priviledges and maybe even then sudo to re-gain one or two worked on all unix-like systems and without having to deal with debians overly complex scripts in comparison to bsd or create a systemd unit (I think it's clear I wouldn't). However as I don't use polkit and use sudo to handle my suspending and shutdowns I think I probably could without issue anyway? Not being a PAM fan but only locking it down a little on systems with it. I can't say I fully understand the weight of grounds with which must not was stated though. I hope I don't get flamed as I am not enjoying or intentionally bashing these things for any political reason and I'm actually rather busy. I simply strive for what I see as simpler and better alternatives in ease of use/config and lack of exploits and don't believe I should have to hide anything. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/248613.30904...@smtp148.mail.ir2.yahoo.com
correct use of su
On 11 May 2014 03:13, Matthias Urlichs matth...@urlichs.de wrote: su does a bunch of things that are perfectly appropriate for something that creates a new login. That's its job. I am still a bit confused, isn't this only when you use the -l su flag? Does su do stuff (e.g. pam session stuff) even without the -l flag? Running a daemon under its own UID is an almost-completely different problem. We already have a tool which does this (start-stop-daemon), which has been recommended for this task for umpteen years, and which still works if there is no .service file – for whatever reason. As a debian developer I was unaware of this. What about the task of running a short program for a brief duration, e.g. from cron scripts? Is using su considered acceptable? e.g. /etc/cron.daily/spamassassin on wheezy has numerous references to su. I think there might be other packages, this is just one I could find the quickest. The name start-stop-daemon would suggest this is inappropriate for cron jobs, is that an invalid assumption I made? (please don't turn this into a systemd debate - I simply want to know what is considered best practise for Debian packaging) -- Brian May br...@microcomaustralia.com.au
