11.02.2019 17:29, Thorsten Kukuk пишет:

On Mon, Feb 11, Patrick Shanahan wrote:

...

* Matwey V. Kornilov [02-11-19 07:24]:

...

...

What is the recommended way to start the socket unit just after installation?

I see that cups.socket is also inactive just after cups installation, but erlang really relies on epmd.socket running.

there really are man pages and examples systemctl start <particular service> systemctl start cups

This is something you can do on the commandline, but never! from a pre/post script. And I think this is what Matwey was asking for: if the package get's installed, it should start automatically.

Yes, this is exactly what I asked. Thank you.

We never do that for security and stability reasons.

That is sad. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

11.02.2019 18:51, Jan Engelhardt пишет:

On Monday 2019-02-11 16:46, Matwey V. Kornilov wrote:

...

...

We never do that for security and stability reasons.

That is sad.

What part of it? That Debian does start services and thus fails in the two points? ;-)

I am just thinking how to achieve good user experience with stuff like that: https://bugzilla.opensuse.org/show_bug.cgi?id=1124947 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

11.02.2019 20:35, Patrick Shanahan пишет:

* Matwey V. Kornilov [02-11-19 10:59]:

...

11.02.2019 18:51, Jan Engelhardt пишет:

...

On Monday 2019-02-11 16:46, Matwey V. Kornilov wrote:

...

...

We never do that for security and stability reasons.

That is sad.

What part of it? That Debian does start services and thus fails in the two points? ;-)

I am just thinking how to achieve good user experience with stuff like that: https://bugzilla.opensuse.org/show_bug.cgi?id=1124947

you want to bypass security for convenience?

I want to find an elegant solution satisfying all constraints. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

11.02.2019 20:37, Jan Engelhardt пишет:

On Monday 2019-02-11 16:57, Matwey V. Kornilov wrote:

...

11.02.2019 18:51, Jan Engelhardt пишет:

...

On Monday 2019-02-11 16:46, Matwey V. Kornilov wrote:

...

...

We never do that for security and stability reasons.

That is sad.

What part of it? That Debian does start services and thus fails in the two points? ;-)

I am just thinking how to achieve good user experience with stuff like that: https://bugzilla.opensuse.org/show_bug.cgi?id=1124947

It's 2019. Why are we still depending on portmappers?

The real deal here is that an unprivileged user should, only under specific circumstances be able to cause root processes to come into existence. Else you could cause undesirable resource use - up to a DoS.

It looks to me like what erl really should be doing is connect to a *user-local* mapper by default, and only use a *global* mapper if run as root. That global mapper also better have some form of authentication or authorization. Like, how dbus is modeled.

It does have authorization. This port mapper is common for all erlang nodes running on the same host. You can discover the node (until the node is 'hidden') in epmd, but it doesn't mean that you may connect to this node, you usually need to know the node cookie which is usually randomly generated. The main issue that that erl tries to spawn epmd process every time when it cannot connect to epmd on start (using its own hard-coded tcp/ip port number). And this is an issue because epmd process belongs to arbitrarily systemd cgroup then. Some system service group or user session one. Sooner or later, it will be terminated as a part of the cgroup and all unrelated local erlang nodes will crash. This is why we need separate systemd service for running epmd. We can specify that it is a separate service and can define dependencies between the services. So when you try to start rabbitmq then systemd knows that it should to start epmd first. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

11.02.2019 21:57, Jan Engelhardt пишет:

On Monday 2019-02-11 18:55, Matwey V. Kornilov wrote:

...

...

It's 2019. Why are we still depending on portmappers?

[epmd] does have authorization. This port mapper is common for all erlang nodes running on the same host. You can discover the node (until the node is 'hidden') in epmd, but it doesn't mean that you may connect to this node, you usually need to know the node cookie which is usually randomly generated.

Even so, you get a list of services, which could be considered an information leak.

...

The main issue that that erl tries to spawn epmd process every time when it cannot connect to epmd on start

and if it were using a user-local epmd, all would be better methinks:

- do not announce own presence to unrelated users

- do not spin up a process in another users's context ^ security guys won't be as mad anymore ^ if epmd screws up, it'll be limited to one's own user identity

- epmd started in the user systemd session is bound to the session lifetime / cgroup. Outlives the login shell generally.

- won't drag other users' erl nodes down when your epmd terminates

This ideas are probably cool, but they are something to be discussed with upstream erlang/otp community. This is not something which could be done during packaging stage. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 12/02/2019 19:20, Ludwig Nussel wrote:

Thorsten Kukuk schrieb:

...

On Mon, Feb 11, Patrick Shanahan wrote:

...

* Matwey V. Kornilov [02-11-19 07:24]:

...

...

What is the recommended way to start the socket unit just after installation?

I see that cups.socket is also inactive just after cups installation, but erlang really relies on epmd.socket running.

there really are man pages and examples    systemctl start <particular service>    systemctl start cups

This is something you can do on the commandline, but never! from a pre/post script. And I think this is what Matwey was asking for: if the package get's installed, it should start automatically. We never do that for security and stability reasons.

Unless it's a dbus service. When set up correctly a dbus services will autolaunch just fine right after installation as soon as some program asks for it on the bus. If that is ok I actually don't see a reason to not allow the same for sockets. It's just that AFAIK infrastructure is not in place to do that properly. Clearly explicit "systemctl start" lines in %post woulnd't be the right way. We'd have to extend the presets mechanism so activating sockets happens transparently and package(r)s don't have to worry.

cu Ludwig

Once we get to the point of discussing changes like this we probably should be doing it on the factory list because there's a number of people interested in the discussion that are not on this list. Cheers -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

12.02.2019 12:07, Adam Majer пишет:

On 2/11/19 3:29 PM, Thorsten Kukuk wrote:

...

And I think this is what Matwey was asking for: if the package get's installed, it should start automatically. We never do that for security and stability reasons.

Then maybe we need a compromise when it comes to this. Like requiring AppArmor profile before services can be autostarted? This would be a little clearer picture than current nebulous definition of what and what not qualifies.

The "never" is also actually "mostly". There are services that are auto-enabled as otherwise we would have bad user experience despite it being more secure.

https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines#Enabling_syste...

epmd.socket is auto-enabled and always been so. Auto-enabling does not assumes auto-starting. So epmd.socket is active after the next reboot, but it is not active until then.

- Adam

-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 2/12/19 10:32 AM, aplanas@suse.de wrote:

On Tuesday, February 12, 2019 10:21:04 AM CET Matwey V. Kornilov wrote:

...

12.02.2019 12:07, Adam Majer пишет:

...

The "never" is also actually "mostly". There are services that are auto-enabled as otherwise we would have bad user experience despite it being more secure.

https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines#Enabling_sys temd_unit_files

...

epmd.socket is auto-enabled and always been so. Auto-enabling does not assumes auto-starting. So epmd.socket is active after the next reboot, but it is not active until then.

The reason is about the configuration file. Sometime the defaults are insecure, useless or simply wrong. Starting a service in those conditions will

The important keyword here is "sometimes" but how do these apply to enabled services? Can I get logical answers? 1. If something is enabled by default, why is it not started by default? 2. Does reboot automatically makes things better when things are automatically started? 3. If default configuration is wrong or needs customization, why was the service enabled by default? Either the service is enabled and then started or we have it disabled in the first place until the user configures it. Configuration clearly includes enabling the service. - Adam -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tuesday 2019-02-12 10:32, aplanas@suse.de wrote:

On Tuesday, February 12, 2019 10:21:04 AM CET Matwey V. Kornilov wrote:

...

12.02.2019 12:07, Adam Majer пишет:

...

On 2/11/19 3:29 PM, Thorsten Kukuk wrote:

...

And I think this is what Matwey was asking for: if the package get's installed, it should start automatically. We never do that for security and stability reasons.

Then maybe we need a compromise when it comes to this. Like requiring AppArmor profile before services can be autostarted? This would be a little clearer picture than current nebulous definition of what and what not qualifies.

The "never" is also actually "mostly". There are services that are auto-enabled as otherwise we would have bad user experience despite it being more secure.

https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines#Enabling_sys temd_unit_files epmd.socket is auto-enabled and always been so. Auto-enabling does not assumes auto-starting. So epmd.socket is active after the next reboot, but it is not active until then.

That is a very valid point.

FWIW, auto-enabling sockets is in essence auto-starting the daemon: as soon as the socket is there, any rogue program trying to connect to it in a busyloop can cause the service unit behind the socket unit to start. sockets are just a way of making the actual daemon have a "delayed startup", but otherwise, their enablement means the actual service is enabled. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

12.02.2019 12:32, aplanas@suse.de пишет:

On Tuesday, February 12, 2019 10:21:04 AM CET Matwey V. Kornilov wrote:

...

12.02.2019 12:07, Adam Majer пишет:

...

On 2/11/19 3:29 PM, Thorsten Kukuk wrote:

...

And I think this is what Matwey was asking for: if the package get's installed, it should start automatically. We never do that for security and stability reasons.

Then maybe we need a compromise when it comes to this. Like requiring AppArmor profile before services can be autostarted? This would be a little clearer picture than current nebulous definition of what and what not qualifies.

The "never" is also actually "mostly". There are services that are auto-enabled as otherwise we would have bad user experience despite it being more secure.

https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines#Enabling_sys temd_unit_files epmd.socket is auto-enabled and always been so. Auto-enabling does not assumes auto-starting. So epmd.socket is active after the next reboot, but it is not active until then.

That is a very valid point.

I want to add about the user experience topic that this is mostly related with the user expectations. When openSUSE install a new package that contains a systemd service file is not expected that the service is started.

The reason is about the configuration file. Sometime the defaults are insecure, useless or simply wrong. Starting a service in those conditions will ruin completely the user experience. Is expected that the user can adjust the configuration file before she / he start the service. Even if is enabled by default.

IMHO following the openSUSE guidelines about systemd services is helping the user experience.

Generally, I am agree with you. But I think that the following exceptions are important in this particular case. 1. User may not expect that the package contains some services. epmd.socket is internal erlang thing. 2. epmd.socket is listening on 127.0.0.1 by default. Though currently it leads to constant complaining, this was required by security team at the time when epmd.socket was introduced. It is minimal working local configuration and it should be fine until you really need distribution setup. 3. erlang has its own default hard-coded way to start epmd. It just execs new epmd process every time when it cannot connect to existing one. So, while epmd.socket is not active, any erl command invocation leads to starting new epmd process that listens on 0.0.0.0. Is it more secure? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Hello, Am Dienstag, 12. Februar 2019, 10:32:47 CET schrieb aplanas@suse.de:

The reason is about the configuration file. Sometime the defaults are insecure,

If you know or find an insecure default config, that clearly qualifies as a bug and is worth a bugreport. Our defaults should always be secure or at least "as secure as possible".

useless or simply wrong.

These are not nice, but still somewhat ok. People will notice, and change to a more useful config. Nevertheless, if you know a better default config, it might be worth a bugreport ;-) Regards, Christian Boltz --

...

the wiki should be stable again. :) What was the reason? The /.-ing or something else? who needs slashdot if you can kill your box with just announcing a new release? [> houghi and Marcus Rueckert in opensuse]

-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org