Re: init system policy

classic Classic list List threaded Threaded
58 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: init system policy

Matthias Urlichs-3
Hi,

[ redirecting to debian-devel, as -policy isn't the correct list for this IMHO ]

Eric Valette:
> <html>

Text emails, please.

>     I've been fighting with some script conversion to systemd and I think
>     a reasonnably complex exemple should be of great help. I've been

What's "reasonably complex" to you is "absurdly simple" to one reader and
"needlessly arcane" to somebody else. :-/

>     trying to convert minidlna sysv init file to systemd, managed to have
>     a working unit file but failed to split the configuration mimicing
>     the ../default/minidlna content with the hability to make USER and
>     GROUP configurable.

You _can_ do

>     ExecStart=sudo -u $USER_MINIDLNA -g GROUP_MINIDLNA /usr/sbin/minidlnad -S

but that's not the optimal solution here.

It's better IMHO to use a fixed user in your packaging -- why should that
user be configurable in the first place? If the sysadmin _really_ needs to
use a different user+group, they can add an overriding unit file to
/etc/systemd/system/ (files get merged, so no need to copy the whole thing).

>     ExecStartPre=/bin/mkdir -p /var/run/minidlna

You might want to use this opportunity to replace /var/run with /run.

>     ExecStartPre=/bin/chown $USER /var/run/minidlna

You should use "%u"; see systemd.unit(5).

Also, one ExecStartPre stanza is sufficient:

> ExecStartPre=/usr/bin/install -o %u -g %g -m 0750 -d /run/minidlna

(or whichever mode is appropriate)

--
-- Matthias Urlichs

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: init system policy

Ansgar Burchardt-5
Hi,

On 11/18/2014 05:39 PM, Matthias Urlichs wrote:

>>     trying to convert minidlna sysv init file to systemd, managed to have
>>     a working unit file but failed to split the configuration mimicing
>>     the ../default/minidlna content with the hability to make USER and
>>     GROUP configurable.
>
> You _can_ do
>
>>     ExecStart=sudo -u $USER_MINIDLNA -g GROUP_MINIDLNA /usr/sbin/minidlnad -S
>
> but that's not the optimal solution here.
>
> It's better IMHO to use a fixed user in your packaging -- why should that
> user be configurable in the first place? If the sysadmin _really_ needs to
> use a different user+group, they can add an overriding unit file to
> /etc/systemd/system/ (files get merged, so no need to copy the whole thing).

Ack.

>
>>     ExecStartPre=/bin/mkdir -p /var/run/minidlna
>
> You might want to use this opportunity to replace /var/run with /run.
>
>>     ExecStartPre=/bin/chown $USER /var/run/minidlna

Both of these can be replaced with

  RuntimeDirectory=minidlda

which will create /run/minidlna, chown it to the user given in User= and
even remove it again once the service is stopped.

There's RuntimeDirectoryMode= if you need different permissions.

All of this is documented in systemd.exec(5) if you want more information.

Ansgar


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/546B77DD.1090004@...

Reply | Threaded
Open this post in threaded view
|

Re: init system policy

Eric Valette
In reply to this post by Matthias Urlichs-3
On 18/11/2014 17:39, Matthias Urlichs wrote:

> Text emails, please.

I alway forget that in my company my mailer is configured for html as
outlook discussion cut is absurd...



> You _can_ do
>
>>      ExecStart=sudo -u $USER_MINIDLNA -g GROUP_MINIDLNA /usr/sbin/minidlnad -S
>
> but that's not the optimal solution here.

Yes not really. And given the number of damons that chnage the uid/gid,
it would rather be good to define a best practice!!!

>
> It's better IMHO to use a fixed user in your packaging -- why should that
> user be configurable in the first place? If the sysadmin _really_ needs to
> use a different user+group, they can add an overriding unit file to
> /etc/systemd/system/ (files get merged, so no need to copy the whole thing).

That's typical: instead of answering the question, you try to say the
actual packaging is absurd. Its current debian packaging for systemv!
The system V init script has the ability to change the user and this is
really useful because the multimedia file are likely owned by you and in
your home directory by daemon and not minidlna and why should you belong
to minidlna group?...

And running anything that use upnp as root I suggest to not do for
security reasons...


>
>>      ExecStartPre=/bin/mkdir -p /var/run/minidlna
>
> You might want to use this opportunity to replace /var/run with /run.

Sure.

> Also, one ExecStartPre stanza is sufficient:
>
>> ExecStartPre=/usr/bin/install -o %u -g %g -m 0750 -d /run/minidlna


But again this does not really slpit the script to configurable option
that will not be overwritten when upgrading...


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/546B8049.3030403@...

Reply | Threaded
Open this post in threaded view
|

Re: init system policy

Eric Valette
In reply to this post by Ansgar Burchardt-5
On 18/11/2014 17:46, Ansgar Burchardt wrote:

> Hi,
>
> On 11/18/2014 05:39 PM, Matthias Urlichs wrote:
>>>      trying to convert minidlna sysv init file to systemd, managed to have
>>>      a working unit file but failed to split the configuration mimicing
>>>      the ../default/minidlna content with the hability to make USER and
>>>      GROUP configurable.
>>
>> You _can_ do
>>
>>>      ExecStart=sudo -u $USER_MINIDLNA -g GROUP_MINIDLNA /usr/sbin/minidlnad -S
>>
>> but that's not the optimal solution here.
>>
>> It's better IMHO to use a fixed user in your packaging -- why should that
>> user be configurable in the first place? If the sysadmin _really_ needs to
>> use a different user+group, they can add an overriding unit file to
>> /etc/systemd/system/ (files get merged, so no need to copy the whole thing).
>
> Ack.

In the file they just need to set User and Group then?


> Both of these can be replaced with
>
>    RuntimeDirectory=minidlda
>
> which will create /run/minidlna, chown it to the user given in User= and
> even remove it again once the service is stopped.
>
> There's RuntimeDirectoryMode= if you need different permissions.
>
> All of this is documented in systemd.exec(5) if you want more information.

Thanks. I read them for trying to fix the User= dynamic problem but did
not found this.

-- eric



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/546B8114.7050409@...

Reply | Threaded
Open this post in threaded view
|

Re: init system policy

Ansgar Burchardt-5
Hi,

On 11/18/2014 06:25 PM, Eric Valette wrote:
> In the file they just need to set User and Group then?

With systemd you can ship a default configuration in
/lib/systemd/system and administrators can override specific options,
for example:

+---
| [Unit]
| Description=Some Helpful Description
| Documentation=man:minidlda(1)
|
| [Service]
| User=minidlda
| ExecStart=/usr/sbin/minidldad -S
+---[ /lib/systemd/system/minidlda.service ]

Then an admin can override the entire file by writing his own
/etc/systemd/system/minidlda.service or only override specific settings:

+---
| [Service]
| User=some-other-user
+---[ /etc/systemd/system/miniblda.service.d/user.conf ]

Ansgar


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/546B83B2.3010103@...

Reply | Threaded
Open this post in threaded view
|

Re: init system policy

Eric Valette
On 18/11/2014 18:36, Ansgar Burchardt wrote:

> Hi,
>
> On 11/18/2014 06:25 PM, Eric Valette wrote:
>> In the file they just need to set User and Group then?
>
> With systemd you can ship a default configuration in
> /lib/systemd/system and administrators can override specific options,
> for example:
>
> +---
> | [Unit]
> | Description=Some Helpful Description
> | Documentation=man:minidlda(1)
> |
> | [Service]
> | User=minidlda
> | ExecStart=/usr/sbin/minidldad -S
> +---[ /lib/systemd/system/minidlda.service ]
>
> Then an admin can override the entire file by writing his own
> /etc/systemd/system/minidlda.service or only override specific settings:
>
> +---
> | [Service]
> | User=some-other-user
> +---[ /etc/systemd/system/miniblda.service.d/user.conf ]

That's crystal clear and solves my problem (cannot reuse the system v
default config file but that's a minor and expected problem)

Thanks for your time

--eric




--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/546B8997.2030402@...

Reply | Threaded
Open this post in threaded view
|

Re: init system policy

Henrique de Moraes Holschuh
In reply to this post by Matthias Urlichs-3
On Tue, 18 Nov 2014, Matthias Urlichs wrote:

> >     trying to convert minidlna sysv init file to systemd, managed to have
> >     a working unit file but failed to split the configuration mimicing
> >     the ../default/minidlna content with the hability to make USER and
> >     GROUP configurable.
>
> You _can_ do
>
> >     ExecStart=sudo -u $USER_MINIDLNA -g GROUP_MINIDLNA /usr/sbin/minidlnad -S
>
> but that's not the optimal solution here.
>
> It's better IMHO to use a fixed user in your packaging -- why should that
> user be configurable in the first place? If the sysadmin _really_ needs to
> use a different user+group, they can add an overriding unit file to
> /etc/systemd/system/ (files get merged, so no need to copy the whole thing).

Failing to address this would be a severe regression, of the kind that
introduces a security hole.  You'd need to abort package configuration on
upgrades if you cannot handle it automatically.

Several packages will need to address this same issue.  We should try to
find a really good answer for this scenario.

A first option would be a way to load config data from a VAR=VALUE text file
in systemd units, and pass some of those vars as the value for User= /
Group= (from systemd.exec(5)).  Is that possible in jessie's systemd ?

A second option is to migrate on upgrade the uid/gid information into an
override in /etc/systemd/system.  Requires dealing with a dynamically
generated config file in preinst/postinst, though, which means the tools
that help proper config file handling in maintainer scripts (ucf, and
sometimes dpkg-maintscript-helper) will be of limited help.

There's also the "sudo" solution described above, which has its own
problems, but which is likely to be workable in most of the cases.

Any other ideas?

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/20141118182722.GC2684@...

Reply | Threaded
Open this post in threaded view
|

Re: init system policy

Matthias Urlichs-3
In reply to this post by Eric Valette
Hi,

Eric Valette:
> >It's better IMHO to use a fixed user in your packaging -- why should that
> >user be configurable in the first place? If the sysadmin _really_ needs to
> >use a different user+group, they can add an overriding unit file to
> >/etc/systemd/system/ (files get merged, so no need to copy the whole thing).
>
> That's typical: instead of answering the question, you try to say the actual
> packaging is absurd.

I didn't say it's absurd. I merely doubted that doing this is a good idea
in general.

Your specific package may well have different and non-general requirements,
in which case

> >>     ExecStart=sudo -u $USER_MINIDLNA -g GROUP_MINIDLNA /usr/sbin/minidlnad -S

is an adequate and perfectly serviceable answer to your question.

> init script has the ability to change the user and this is really useful
> because the multimedia file are likely owned by you and in your home
> directory by daemon and not minidlna and why should you belong to minidlna
> group?...
>
Maybe because Debian is a multiuser system AIUI, so running the daemon as a
specific "normal" user didn't even occur to me. Sorry!

> But again this does not really slpit the script to configurable option that
> will not be overwritten when upgrading...

The idea is for the package to ship a /lib/systemd/system/PACKAGE.service
file which uses a "generic" user+group. You can then add a file
/etc/systemd/system/PACKAGE.service which merely overwrites user+group
settings and does not contain any other entries, in which case they'll
be inherited from the file in /lib. No overwriting on update will happen.

If you already do have an /etc/default/PACKAGE file, the sudo method's
advantage is that you can just use an EnvironmentFile= stanza, and thus
don't need to keep that and /etc/systemd/system/PACKAGE.service in sync
somehow.

--
-- Matthias Urlichs

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: init system policy

Simon McVittie-7
In reply to this post by Henrique de Moraes Holschuh
On 18/11/14 18:27, Henrique de Moraes Holschuh wrote:
> Failing to address this would be a severe regression, of the kind that
> introduces a security hole.

I can see the functional regression ("minidlna is running as a totally
unprivileged user now, and can't read my music any more!") but not the
security hole: its default user presumably has as little access as
"nobody", so I don't see how that's insecure?

I suppose if the default configuration is more permissive than what the
user has configured for a different uid to use, going back to the
default configuration might be a security regression.

> A first option would be a way to load config data from a VAR=VALUE
> text file in systemd units

This already exists (and I think Eric is already using it for something
else), look for EnvironmentFile in systemd.exec(5)...

> and pass some of those vars as the value for User= /
> Group=

... but as far as I know, this is not implemented: the assumption is
that a system service uses a fixed system user, typically either root, a
well-known uid like www-data, or an unprivileged user specifically
created for that service (e.g. "messagebus" for D-Bus).

> A second option is to migrate on upgrade the uid/gid information into
> an override in /etc/systemd/system.  Requires dealing with a
> dynamically generated config file in preinst/postinst, though, which
> means the tools that help proper config file handling in maintainer
> scripts (ucf, and sometimes dpkg-maintscript-helper) will be of
> limited help.

I think I'd be inclined to do this, as a one-time migration, and perhaps
also document it as deprecated/discouraged: running minidlna under its
own dedicated uid, and giving it read access to the media it should be
allowed to read (and only those files) via setfacl or whatever, seems
considerably safer than running a network-facing service under the uid
of a "real user" who might also own private documents.

    S


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/546B95AB.7040409@...

Reply | Threaded
Open this post in threaded view
|

Re: init system policy

Eric Valette
In reply to this post by Matthias Urlichs-3
On 18/11/2014 19:47, Matthias Urlichs wrote:

>>>>      ExecStart=sudo -u $USER_MINIDLNA -g GROUP_MINIDLNA /usr/sbin/minidlnad -S
>
> is an adequate and perfectly serviceable answer to your question.

On the other hand, the documented way to do this in systemd man pages is
to use User and Group. If the User and Group variables have been added
to unit files I naively think it was for a reason but I may be wrong.

I just mentioned that naively combining User=$TOTO or ${TOTO} TOTO being
defined in an default/package file parsed by EnvironmentFile= does not
seem to work as documented in man pages (seen the very same question
being asked on various distro mailing list without definitive answer).

> Maybe because Debian is a multiuser system AIUI, so running the daemon as a
> specific "normal" user didn't even occur to me. Sorry!

Sure but what percentage is used by a single user? And for multiple
users, to index multimedia files, you should either define a single
location and a import script or play with groups and permission..

systemd for servers systems may still have some way to go for converting
complex init scripts for firewall,openssh,VM's IMHO.

> If you already do have an /etc/default/PACKAGE file, the sudo method's
> advantage is that you can just use an EnvironmentFile= stanza, and thus
> don't need to keep that and /etc/systemd/system/PACKAGE.service in sync
> somehow.

The syntax may not always been compatible as it may use shell tricks to
define variables. I do not mind duplicating the file as only one init
system will be used at a time and transition should be the job of
package setup when default init system changes (I know some backward
compatibility is planned).

Thanks for your time.

-- eric



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/546B9C43.4050402@...

Reply | Threaded
Open this post in threaded view
|

Re: init system policy

Simon McVittie-7
On 18/11/14 19:21, Eric Valette wrote:
> I just mentioned that naively combining User=$TOTO or ${TOTO} TOTO being
> defined in an default/package file parsed by EnvironmentFile= does not
> seem to work as documented in man pages

To be clear, the environment variable substitution in systemd units'
field values is not general: it only works in the fields where it is
specifically implemented, which I think is only the ExecWhatever family
of fields. That's why it's documented in the descriptions of those
fields in systemd.service(5), and not in the general information about
units, systemd.unit(5). I think the intention might be to avoid ever
getting into recursive expansion.

The %x specifiers (%u, etc.) are interpreted in rather more places than
environment variables are.

Parsing User=$TOTO as "the User is the value of the environment variable
TOTO as given by Environment or EnvironmentFile" might be a reasonable
feature request, but it is not currently an implemented feature.

> systemd for servers systems may still have some way to go for converting
> complex init scripts for firewall,openssh,VM's IMHO.

If you do need the full power of shell script, you can always keep the
LSB init script, or have a native systemd unit where the ExecWhatever
lines execute shell scripts.

    S


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/546BA107.2010006@...

Reply | Threaded
Open this post in threaded view
|

Re: init system policy

Russ Allbery-2
In reply to this post by Simon McVittie-7
Simon McVittie <[hidden email]> writes:

> I can see the functional regression ("minidlna is running as a totally
> unprivileged user now, and can't read my music any more!") but not the
> security hole: its default user presumably has as little access as
> "nobody", so I don't see how that's insecure?

The scenario I'd be concerned about is if the init script were modified to
run the program as a different user that was subject to, say, a SELinux
policy.  Changing users back might escape additional security measures
like that.

Another scenario is if the default Debian user conflicted with some user
on the local system that was already being used to do something else.

In general, I would treat anything involving running daemons as users
other than the intended user as a potential security vulnerability unless
proven otherwise, given how fundamental user and group are to the entire
UNIX security model.

>> A second option is to migrate on upgrade the uid/gid information into
>> an override in /etc/systemd/system.  Requires dealing with a
>> dynamically generated config file in preinst/postinst, though, which
>> means the tools that help proper config file handling in maintainer
>> scripts (ucf, and sometimes dpkg-maintscript-helper) will be of limited
>> help.

> I think I'd be inclined to do this, as a one-time migration,

Yeah, this seems like the right solution to me too.  Drop a configuration
fragment in /etc/systemd that overrides the user and group and then don't
touch it again.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/877fys6wqz.fsf@...

Reply | Threaded
Open this post in threaded view
|

Re: Re: init system policy

Eric Valette
In reply to this post by Simon McVittie-7
> Parsing User=$TOTO as "the User is the value of the environment variable
> TOTO as given by Environment or EnvironmentFile" might be a reasonable
> feature request, but it is not currently an implemented feature.

I think anything that simplify transitioning from an init system to
another new one is valuable as long as it does not breaks the original
new design intention.

There has been a good and valuable effort trying to split original
upstream packages provided init system scripts by debian developers into
/etc/default/X and /etc/init.d/X file and storing most commonly changed
sysv init options in the default file part (including start or not).
Wasting this work due to systemd transition would be a bad idea IMHO.


Being able to reuse the sysv default config file or automate its back
and forth conversion (like passwd and shadow or group and gshadow with
grpck and pwck) would be helping both init system transition for debian
devs and administrators that have been developing their own sysv scripts.


Looking at ways to replace start-stop-daemon various parameters by
corresponding unit file sequences/file layout would probably help (-g
and -c are just examples for their User and Group systemd counterpart)


--eric


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/546BB622.5000102@...

Reply | Threaded
Open this post in threaded view
|

Re: init system policy

Sam Hartman-3
In reply to this post by Russ Allbery-2
>>>>> "Russ" == Russ Allbery <[hidden email]> writes:

    >>> A second option is to migrate on upgrade the uid/gid information
    >>> into an override in /etc/systemd/system.  Requires dealing with
    >>> a dynamically generated config file in preinst/postinst, though,
    >>> which means the tools that help proper config file handling in
    >>> maintainer scripts (ucf, and sometimes dpkg-maintscript-helper)
    >>> will be of limited help.

    >> I think I'd be inclined to do this, as a one-time migration,

    Russ> Yeah, this seems like the right solution to me too.  Drop a
    Russ> configuration fragment in /etc/systemd that overrides the user
    Russ> and group and then don't touch it again.

well, debconf seems like a win here.
There's no reasonable default so it's desirable to make it easy for the
admin to specify and so you'd probably want to use normal best practice
for debconf updates.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/00000149c5dd1eb8-694ee9c8-e191-4683-8ced-987af790a4bf-000000@...

Reply | Threaded
Open this post in threaded view
|

Re: init system policy

Russ Allbery-2
Sam Hartman <[hidden email]> writes:
>>>>>> "Russ" == Russ Allbery <[hidden email]> writes:

>     Russ> Yeah, this seems like the right solution to me too.  Drop a
>     Russ> configuration fragment in /etc/systemd that overrides the user
>     Russ> and group and then don't touch it again.

> well, debconf seems like a win here.
> There's no reasonable default so it's desirable to make it easy for the
> admin to specify and so you'd probably want to use normal best practice
> for debconf updates.

Ah, sorry, I mixed two threads.  Yes, for the original author's problem,
where the user should configure the user/group for the daemon, debconf
makes sense.  I had mixed that up with cases where people modified init
scripts to run things under a different user than the default, which is a
somewhat harder problem.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/87d28jvr2h.fsf@...

Reply | Threaded
Open this post in threaded view
|

Re: init system policy

Steve Langasek
In reply to this post by Matthias Urlichs-3
On Tue, Nov 18, 2014 at 07:47:59PM +0100, Matthias Urlichs wrote:
> Your specific package may well have different and non-general requirements,
> in which case

> > >>     ExecStart=sudo -u $USER_MINIDLNA -g GROUP_MINIDLNA /usr/sbin/minidlnad -S

> is an adequate and perfectly serviceable answer to your question.

> > init script has the ability to change the user and this is really useful
> > because the multimedia file are likely owned by you and in your home
> > directory by daemon and not minidlna and why should you belong to minidlna
> > group?...

> Maybe because Debian is a multiuser system AIUI, so running the daemon as a
> specific "normal" user didn't even occur to me. Sorry!

> > But again this does not really slpit the script to configurable option that
> > will not be overwritten when upgrading...

> The idea is for the package to ship a /lib/systemd/system/PACKAGE.service
> file which uses a "generic" user+group. You can then add a file
> /etc/systemd/system/PACKAGE.service which merely overwrites user+group
> settings and does not contain any other entries, in which case they'll
> be inherited from the file in /lib. No overwriting on update will happen.

> If you already do have an /etc/default/PACKAGE file, the sudo method's
> advantage is that you can just use an EnvironmentFile= stanza, and thus
> don't need to keep that and /etc/systemd/system/PACKAGE.service in sync
> somehow.

The disadvantage of the sudo method is that you are spawning a PAM session,
which is not desirable for any service.

Preferable would be to parse any existing config file for non-default user
settings as part of the package upgrade and write out
/etc/systemd/system/PACKAGE.service with only these non-default values,
avoiding any variable substitution or sudo invocation entirely.

--
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 Developer                                    http://www.debian.org/
[hidden email]                                     [hidden email]

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: init system policy

Matthias Urlichs-3
Hi,

Steve Langasek:
> The disadvantage of the sudo method is that you are spawning a PAM session,
> which is not desirable for any service.
>
Ah. Thanks for the reminder; mentioning the session issue completely
slipped my mind. :-/

If one does need to use a sudo intermediate to start services, the
'pam_session', 'pam_setcred', and 'use_pty' flags should be turned off,
as well as sudo's internal logging.

This will cause sudo to not create a PAM session, and directly exec() the
daemon instead of running an intermediate fork.

See "man 5 sudoers" for details.

--
-- Matthias Urlichs

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: init system policy

Vincent Bernat-3
 ❦ 19 novembre 2014 08:45 +0100, Matthias Urlichs <[hidden email]> :

>> The disadvantage of the sudo method is that you are spawning a PAM session,
>> which is not desirable for any service.
>>
> Ah. Thanks for the reminder; mentioning the session issue completely
> slipped my mind. :-/
>
> If one does need to use a sudo intermediate to start services, the
> 'pam_session', 'pam_setcred', and 'use_pty' flags should be turned off,
> as well as sudo's internal logging.
>
> This will cause sudo to not create a PAM session, and directly exec() the
> daemon instead of running an intermediate fork.
There is chpst for this kind of task. Unfortunately, being part of
runit, it may not be suitable for a dependency.
--
 /* Thanks to Rob `CmdrTaco' Malda for not influencing this code in any
  * way.
  */
        2.4.3 linux/net/core/netfilter.c

signature.asc (834 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re: init system policy

Eric Valette
In reply to this post by Sam Hartman-3
> well, debconf seems like a win here.
> There's no reasonable default so it's desirable to make it easy for the
> admin to specify and so you'd probably want to use normal best practice
> for debconf updates.
I agree with this but unfortunately original minidlna package as no
debconf setup :-)

-- eric


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/546C6051.2040506@...

Reply | Threaded
Open this post in threaded view
|

Re: Re: init system policy

Laurent Bigonville-5
In reply to this post by Matthias Urlichs-3
Matthias Urlichs wrote:

> Hi,
>
> Steve Langasek:
> > The disadvantage of the sudo method is that you are spawning a PAM
> > session, which is not desirable for any service.
> >
> Ah. Thanks for the reminder; mentioning the session issue completely
> slipped my mind. :-/
>
> If one does need to use a sudo intermediate to start services, the
> 'pam_session', 'pam_setcred', and 'use_pty' flags should be turned
> off, as well as sudo's internal logging.
>
> This will cause sudo to not create a PAM session, and directly exec()
> the daemon instead of running an intermediate fork.
>
> See "man 5 sudoers" for details.

You probably want to use "runuser" that has been introduced recently in
utils-linux

Cheers,

Laurent Bigonville


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/20141119112407.70d93709@...

123