ulimits not set according to /etc/security/limits.conf for root - update documentation

Bug #65244 reported by Václav Šmilauer on 2006-10-11
18
This bug affects 2 people
Affects Status Importance Assigned to Milestone
pam (Ubuntu)
Medium
Jonathan Marsden
Declined for Jaunty by Steve Langasek

Bug Description

Binary package hint: libpam-modules

Hello, I am desperately trying to allow root big or unlimited coredumps. I set "* soft core 102400" and "* hard core 102400" in /etc/security/limits.conf to no avail, after root login over ssh, I still get the stubborn answer "# ulimit -c" → "0". I don't know if this is a bug in pam itself; it works OK for other users.

I also tried to add pam_limits.so to /etc/pam.d/common-session, nothing happens. The same result when putting "ulimit -c unlimited" into /etc/environment.

If this is not a bug in PAM but only my inability to find the right solution, please consider it a documentation bug report. It prevent us from debugging crashing gdm daemon (see
http://bugzilla.gnome.org/show_bug.cgi?id=357632 and https://launchpad.net/bugs/62139)

Thanks, Vaclav Smilauer

Jean-Baptiste Lallement (jibel) wrote :

Thanks for your report. As you said this is not a bug in pam but a documentation issue.
The fact to allow explicitly allow limits for user root has been addressed a while ago (30 Aug 2000) but you need to explicitly name user root to apply the limits.
For example (/etc/security/limits.conf):
* soft core 0
root soft core 0

The first line doesn't affect superuser (zero core dump size), but the second one does.
Group and default limits aren't processed, per-user limits get applied even if the user is root.

Changed in pam:
status: New → Confirmed
Steve Langasek (vorlon) on 2008-07-30
Changed in pam:
importance: Undecided → Medium
Jonathan Marsden (jmarsden) wrote :

I have added information and an additional example configuration line to both /etc/security/limits.conf and to the XML source for its man page, limits.conf.5.xml .

However, the build process for the package does not seem to regenerate the man page from the XML, and I am currently struggling to work out how to make it do so!

Meanwhile, here is the current state of my work as a debdiff.

Jonathan

Changed in pam:
assignee: nobody → jmarsden
status: Confirmed → In Progress
Steve Langasek (vorlon) wrote :

Hi Jonathan,

Rather than creating a new patch for this, please add your changes to the existing 027_pam_limits_better_init_allow_explicit_root patch (ugh, horrible name, that is) so that the changes and documentation are kept together.

As for the manpage regeneration, I'm afraid the best solution I have for getting documentation changes into the manpages is by stealing the xsltproc command from Make.xml.rules and running it by hand. :/

Also, please note that there's a bzr branch for pam now at lp:~ubuntu-core-dev/pam/ubuntu/, so you're welcome to propose your changes as a branch merge when done.

Jonathan Marsden (jmarsden) wrote :

Steve,

I must have missed your email on this back in August! I've updated to the current Intrepid sources, appended my patch to the 027- patch file, and it looks decent.

I also discovered (after much reading of Makefile.in and configure scripts) how to build the docs "properly"! If you sudo apt-get install ldp-docbook-xsl (and all its recommended hangers-on), when you then run ./configure the Makefiles now include the Make.xml.rules file. At this point you can do (this is my example, but the principle applies to many subdirs)

  cd modules/pam_limits
  rm limits.conf.5 pam_limits.8 README
  make limits.conf.5 pam_limits.8 README

and the docs get regenerated :-)

Possibly better yet, if you edit Make.xml.rules and uncomment the final line

  CLEANFILES += $(man_MANS) README

you can then do something more like

  cd modules/pam_limits
  make clean
  make install_man

and all the documentation pages in that directory will be regenerated (it then fails to install them because you're not root, but this is good. There's no Makefile target to just build all doc files in a given directory, as far as I can see.)

bzr: Hmm. I know cvs and svn pretty well, but have so far managed to avoid all these new-fangled distributed VCSes <grin>... maybe I need to learn? Is there a "bzr for MOTUs" type of document around somewhere to get me started?

Anyway, I'll try to get a fresh debdiff with the single 027 patch file and the updated documentation files in a few hours and upload it here.

Jonathan Marsden (jmarsden) wrote :

Here's the debdiff. It builds for me in a jaunty pbuilder.

On Sun, Nov 09, 2008 at 08:12:42PM -0000, Jonathan Marsden wrote:
> I also discovered (after much reading of Makefile.in and configure
> scripts) how to build the docs "properly"! If you sudo apt-get install
> ldp-docbook-xsl (and all its recommended hangers-on), when you then run
> ./configure the Makefiles now include the Make.xml.rules file. At this
> point you can do (this is my example, but the principle applies to many
> subdirs)

> cd modules/pam_limits
> rm limits.conf.5 pam_limits.8 README
> make limits.conf.5 pam_limits.8 README

> and the docs get regenerated :-)

Ah, that seems perfectly reasonable, wonder why I didn't notice that. :)

> bzr: Hmm. I know cvs and svn pretty well, but have so far managed to
> avoid all these new-fangled distributed VCSes <grin>... maybe I need to
> learn? Is there a "bzr for MOTUs" type of document around somewhere to
> get me started?

For this, I think you want <https://wiki.ubuntu.com/BzrContributorHowto>.

> Anyway, I'll try to get a fresh debdiff with the single 027 patch file
> and the updated documentation files in a few hours and upload it here.

Thanks, I've applied this to the bzr branch now.

Cheers,
--
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/
<email address hidden> <email address hidden>

Changed in pam:
status: In Progress → Fix Committed
Steve Langasek (vorlon) wrote :

This bug was fixed in the upload of pam 1.0.1-5ubuntu1. Changes:

pam (1.0.1-5ubuntu1) jaunty; urgency=low

  * Merge from Debian unstable
  * Remaining changes:
    - debian/libpam-modules.postinst: Add PATH to /etc/environment if it's not
      present there or in /etc/security/pam_env.conf. (should send to Debian).
    - debian/libpam0g.postinst: only ask questions during update-manager when
      there are non-default services running.
    - debian/patches-applied/series: Ubuntu patches are as below ...
    - debian/patches-applied/ubuntu-fix_standard_types: Use standard u_int8_t
      type rather than __u8.
    - debian/patches-applied/ubuntu-no-error-if-missingok: add a new, magic
      module option 'missingok' which will suppress logging of errors by
      libpam if the module is not found.
    - debian/patches-applied/ubuntu-regression_fix_securetty: prompt for
      password on bad username.
    - debian/patches-applied/ubuntu-rlimit_nice_correction: Explicitly
      initialise RLIMIT_NICE rather than relying on the kernel limits.
    - debian/patches-applied/ubuntu-user_defined_environment: Look at
      ~/.pam_environment too, with the same format as
      /etc/security/pam_env.conf. (Originally patch 100; converted to quilt.)
    - Change Vcs-Bzr to point at the Ubuntu branch.
    - debian/local/pam-auth-update (et al): new interface for managing
      /etc/pam.d/common-*, using drop-in config snippets provided by module
      packages.
    - debian/local/common-password, debian/pam-configs/unix: switch from
      "md5" to "sha512" as password crypt default.
  * Bump the version numbers referenced in the config files, again, as pam
    has revved in Debian and moved the bar.
  * pam-auth-update: If /var/lib/pam/seen is absent, treat this the same
    as a present but empty file; thanks to Greg Price for the patch.
    LP: #294513.
  * pam-auth-update: Ignore removed profiles when detecting an empty set
    of currently-enabled modules. Thanks to Greg Price for this as well.
  * debian/control: libpam-runtime needs a versioned dependency on
    debconf, because it uses the x_loadtemplatefile extension that's
    not supported by debconf versions before hardy. LP: #295135.
  * pam-auth-update: trim leading whitespace from multiline fields when
    parsing PAM profiles. LP: #295441.
  * pam-auth-update: factor out the duplicate code used for returning
    the lines for a given module

  [ Jonathan Marsden ]
  * debian/patches/027_pam_limits_better_init_allow_explicit_root:
    Add to patch, documenting how to set limits for root user.
    Include an example. Alters limits.conf, limits.conf.5.xml,
    and limits.conf.5 . (LP: #65244)

Changed in pam:
status: Fix Committed → Fix Released
Abdusamed Ahmed (sir508) wrote :

I can't say if it fixed, changing the ulimit on /etc/security/limits.conf doesn't affect the default ulimit which is 1024. My ubuntu is updated to the date the post was posted on

Vincent Gerris (vgerris) wrote :

you may need to change the setting in the right /etc/pam.d/file .
Must say I tried it (common-session and sudo) but it did not work for me.
I tried :
* - nofile 8192
root - nofile 8192
The * one does not work, the one with root only works for root.
Shouldn't the * be activated for all users?

Sasikiran (sasikiran-vaddi) wrote :

I have added configurations in /etc/security/limits.conf
* soft core unlimited
root soft core unlimited

then after, i have given a process crash, kill -s SEGV <mysql_id>. I got a core dump file for mysql.

But after this if i start the service by "service mysql start"(service is getting start). Then if I give crash i'm not able to get core dump file and I have checked "ulimit -c" which is 0. why is it happening?

In the same case instead of "service mysql start" if I give "service mysql restart", then if I give crash i'm able to get core dump file.

As a workaround i have added "ulimit -c unlimited" to "start" section of /etc/init.d/mysql, then the core dump file is created in both the scenarios.

But how to configure "ulimit -c unlimited" in the "start" section of each and every service that is present in /etc/init.d(like prescript before executing start) . Or is there any way to resolve this.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers