Change default value of RemoveIPC in logind.conf #2039

Closed
msekletar opened this Issue Nov 26, 2015 · 10 comments

Comments

6 participants
@msekletar
Contributor

msekletar commented Nov 26, 2015

We received bug reports that default of RemoveIPC=yes in logind.conf may break 3rd party software not shipped as part of distribution. For example, consider software running various daemons which use SYSV or Posix defined IPC mechanism for communication and synchronization. At the same time, there is some maintenance script scheduled with cron which runs under same UID as daemons mentioned before. In such case, session will be created for this user and once cron job ends then session is released and given user has no active sessions (from logind's POV). logind will then do cleanup of allocated IPC resources, which is wrong because they still maybe needed by the daemon processes.

@poettering

This comment has been minimized.

Show comment
Hide comment
@poettering

poettering Nov 26, 2015

Member

Well, it's configurable, because it can break stuff.

But I am pretty sure the usecase you describe is borked... The cleanup stuff already excludes system users, i.e. all daemon users. As it appears the customer created a non-system account for this stuff, and that's what should be fixed.

Sorry, but this is nothing to fix upstream... Please ask the customer to disable RemoveIPC= locally, or fix his users to become proper system users.

Sorry.

Member

poettering commented Nov 26, 2015

Well, it's configurable, because it can break stuff.

But I am pretty sure the usecase you describe is borked... The cleanup stuff already excludes system users, i.e. all daemon users. As it appears the customer created a non-system account for this stuff, and that's what should be fixed.

Sorry, but this is nothing to fix upstream... Please ask the customer to disable RemoveIPC= locally, or fix his users to become proper system users.

Sorry.

@poettering poettering closed this Nov 26, 2015

@msekletar

This comment has been minimized.

Show comment
Hide comment
@msekletar

msekletar Nov 27, 2015

Contributor

Ahh, I missed that if statement in clean_ipc. There is really nothing to fix in systemd then. At any rate, thanks for looking it this.

Contributor

msekletar commented Nov 27, 2015

Ahh, I missed that if statement in clean_ipc. There is really nothing to fix in systemd then. At any rate, thanks for looking it this.

@ringerc

This comment has been minimized.

Show comment
Hide comment
@ringerc

ringerc Jul 11, 2016

Overall this seems like a helpful change. From a sysadmin PoV I'd really like to know more about what the behaviour is expected to be though.

Related thread: https://lists.freedesktop.org/archives/systemd-devel/2014-April/018373.html

What does systemd consider a "system user" for this purpose? The thread there discusses a hardcoded uid, but reached no clear conclusion. There's no "system user" flag in the traditional password database. Are you using a uid threshold from login.defs as was discussed as a possibility in that thread?

Where's the system user specific part of this behaviour documented? I found a note in NEWS:

        * logind will now automatically remove all IPC objects owned
          by a user if she or he fully logs out. This makes sure that
          users who are logged out cannot continue to consume IPC
          resources. This covers SysV memory, semaphores and message
          queues as well as POSIX shared memory and message
          queues. Traditionally, SysV and POSIX IPC had no life-cycle
          limits. With this functionality, that is corrected. This may
          be turned off by using the RemoveIPC= switch of logind.conf.

but it doesn't describe the system uesr behaviour. Similarly, in man/logind.conf.xml

        <term><varname>RemoveIPC=</varname></term>

        <listitem><para>Controls whether System V and POSIX IPC objects belonging to the user shall be removed when the
        user fully logs out. Takes a boolean argument. If enabled, the user may not consume IPC resources after the
        last of the user's sessions terminated. This covers System V semaphores, shared memory and message queues, as
        well as POSIX shared memory and message queues. Note that IPC objects of the root user and other system users
        are excluded from the effect of this setting. Defaults to <literal>yes</literal>.</para></listitem>

it mentions system users, but doesn't define what systemd considers to be a "system user", how to make a user a system user, what consequences or other behaviour differences are experienced by system users, etc.

Is the system-user-ness of a user tied to sysusers.d or is that just a convenience mechanism for creating system users?

Is there any wrapper command that allows a user to spawn a daemon that survives their session for where legacy behaviour is needed? Or a systemd API a wrapper (or something like pg_ctl) could call? I couldn't find one when I went looking. Or can a "normal" user be exempted on a user-by-user basis from RemoveIPC, perhaps via some group membership? Again, I didn't find any such mechanism when I looked.

For sites that manage deployed service users via LDAP, etc, is there any way they can safely create "system users" in their directory that won't suffer from uid collisions vs local users?

This is useful enough that I don't think most sites will want to just turn it off, but they're going to have to unless there's enough information to actually use it correctly.

ringerc commented Jul 11, 2016

Overall this seems like a helpful change. From a sysadmin PoV I'd really like to know more about what the behaviour is expected to be though.

Related thread: https://lists.freedesktop.org/archives/systemd-devel/2014-April/018373.html

What does systemd consider a "system user" for this purpose? The thread there discusses a hardcoded uid, but reached no clear conclusion. There's no "system user" flag in the traditional password database. Are you using a uid threshold from login.defs as was discussed as a possibility in that thread?

Where's the system user specific part of this behaviour documented? I found a note in NEWS:

        * logind will now automatically remove all IPC objects owned
          by a user if she or he fully logs out. This makes sure that
          users who are logged out cannot continue to consume IPC
          resources. This covers SysV memory, semaphores and message
          queues as well as POSIX shared memory and message
          queues. Traditionally, SysV and POSIX IPC had no life-cycle
          limits. With this functionality, that is corrected. This may
          be turned off by using the RemoveIPC= switch of logind.conf.

but it doesn't describe the system uesr behaviour. Similarly, in man/logind.conf.xml

        <term><varname>RemoveIPC=</varname></term>

        <listitem><para>Controls whether System V and POSIX IPC objects belonging to the user shall be removed when the
        user fully logs out. Takes a boolean argument. If enabled, the user may not consume IPC resources after the
        last of the user's sessions terminated. This covers System V semaphores, shared memory and message queues, as
        well as POSIX shared memory and message queues. Note that IPC objects of the root user and other system users
        are excluded from the effect of this setting. Defaults to <literal>yes</literal>.</para></listitem>

it mentions system users, but doesn't define what systemd considers to be a "system user", how to make a user a system user, what consequences or other behaviour differences are experienced by system users, etc.

Is the system-user-ness of a user tied to sysusers.d or is that just a convenience mechanism for creating system users?

Is there any wrapper command that allows a user to spawn a daemon that survives their session for where legacy behaviour is needed? Or a systemd API a wrapper (or something like pg_ctl) could call? I couldn't find one when I went looking. Or can a "normal" user be exempted on a user-by-user basis from RemoveIPC, perhaps via some group membership? Again, I didn't find any such mechanism when I looked.

For sites that manage deployed service users via LDAP, etc, is there any way they can safely create "system users" in their directory that won't suffer from uid collisions vs local users?

This is useful enough that I don't think most sites will want to just turn it off, but they're going to have to unless there's enough information to actually use it correctly.

@ringerc

This comment has been minimized.

Show comment
Hide comment
@ringerc

ringerc Jul 12, 2016

Examination of the code shows that it seems to use thelogin.defs user threshold ... determined at compile time.

ringerc commented Jul 12, 2016

Examination of the code shows that it seems to use thelogin.defs user threshold ... determined at compile time.

@poettering

This comment has been minimized.

Show comment
Hide comment
@poettering

poettering Jul 12, 2016

Member

This is an issue tracker, not a support forum. Please direct your questions to a proper support forum, such as the systemd mailing lists. Thank you.

Member

poettering commented Jul 12, 2016

This is an issue tracker, not a support forum. Please direct your questions to a proper support forum, such as the systemd mailing lists. Thank you.

@oberstet

This comment has been minimized.

Show comment
Hide comment
@oberstet

oberstet Aug 1, 2016

The default of this option should be off.

It has cost me literally many days to track down PostgreSQL instability to this (a collegue found this).

Sorry, but this is nothing to fix upstream... Please ask the customer to disable RemoveIPC= locally, or fix his users to become proper system users.

Your arrogance is breathtaking.

oberstet commented Aug 1, 2016

The default of this option should be off.

It has cost me literally many days to track down PostgreSQL instability to this (a collegue found this).

Sorry, but this is nothing to fix upstream... Please ask the customer to disable RemoveIPC= locally, or fix his users to become proper system users.

Your arrogance is breathtaking.

@oberstet

This comment has been minimized.

Show comment
Hide comment
@oberstet

oberstet Aug 1, 2016

For others coming along, Oracle Linux has configured away this misfeature by default: https://docs.oracle.com/cd/E52668_01/E67200/html/section-t51_kcn_f5.html

They call it a feature "intended for laptops";)

oberstet commented Aug 1, 2016

For others coming along, Oracle Linux has configured away this misfeature by default: https://docs.oracle.com/cd/E52668_01/E67200/html/section-t51_kcn_f5.html

They call it a feature "intended for laptops";)

@evverx evverx referenced this issue Nov 1, 2016

Closed

RemoveIPC prematurely removes IPC segments #4532

1 of 2 tasks complete
@CyberShadow

This comment has been minimized.

Show comment
Hide comment
@CyberShadow

CyberShadow Feb 12, 2017

Contributor

Hello,

But I am pretty sure the usecase you describe is borked... The cleanup stuff already excludes system users, i.e. all daemon users. As it appears the customer created a non-system account for this stuff, and that's what should be fixed.

What about situations such as ...

  • The user launched a background task using disown and logs out

  • The user has a program running in a screen/tmux session

  • The user has a cronjob configured, and the program launched from the cronjob is running at the moment when the user logs out (or their SSH connection drops)

I think systemd should check whether the user has any processes running, not just whether they have any active login sessions.

Contributor

CyberShadow commented Feb 12, 2017

Hello,

But I am pretty sure the usecase you describe is borked... The cleanup stuff already excludes system users, i.e. all daemon users. As it appears the customer created a non-system account for this stuff, and that's what should be fixed.

What about situations such as ...

  • The user launched a background task using disown and logs out

  • The user has a program running in a screen/tmux session

  • The user has a cronjob configured, and the program launched from the cronjob is running at the moment when the user logs out (or their SSH connection drops)

I think systemd should check whether the user has any processes running, not just whether they have any active login sessions.

@semmerson

This comment has been minimized.

Show comment
Hide comment
@semmerson

semmerson Nov 27, 2017

Sorry, but this is nothing to fix upstream... Please ask the customer to disable RemoveIPC= locally, or fix his users to become proper system users.

I agree. Capricious and arbitrary changes should not be sacrificed on the alter of backward-compatibility.

Sorry, but this is nothing to fix upstream... Please ask the customer to disable RemoveIPC= locally, or fix his users to become proper system users.

I agree. Capricious and arbitrary changes should not be sacrificed on the alter of backward-compatibility.

@ringerc

This comment has been minimized.

Show comment
Hide comment
@ringerc

ringerc Nov 28, 2017

@poettering It's being discussed here because it's a misfeature/bug for which changes are being suggested.

ringerc commented Nov 28, 2017

@poettering It's being discussed here because it's a misfeature/bug for which changes are being suggested.

@systemd systemd locked and limited conversation to collaborators Nov 28, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.