Jira (PUP-6635) An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf
Title: Message Title Josh Cooper updated an issue Puppet / PUP-6635 An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf Change By: Josh Cooper Labels: exec linux platform-os security type_and_provider Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.147763.1471518328000.41559.1664925360760%40Atlassian.JIRA.
Jira (PUP-6635) An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf
Title: Message Title Branan Riley updated an issue Puppet / PUP-6635 An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf Change By: Branan Riley Labels: needs_epic exec linux triaged type_and_provider Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6635) An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf
Title: Message Title Reid Wahl commented on PUP-6635 Re: An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf I think it's doable but will require separate calls to Process.setrlimit() after first determining the rlimits of the user we're trying to execute the command as. This is new to me and I have an actual job so someone else might beat me to getting this one sorted out... I welcome it. Add Comment This message was sent by Atlassian JIRA (v7.0.2#70111-sha1:88534db) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6635) An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf
Title: Message Title
Reid Wahl commented on PUP-6635
Re: An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf
Launched /bin/sleep 120 as user test2 via exec and via sudo -u. The process of the sleep launched via Puppet AND its parent (ruby-mri) have the root user's ulimits. The sleep process launched via sudo AND its parent (sudo) have the test2 user's ulimits.
[root@laptop /proc]# ps -eo euser,pid,ppid,ruser,suser,fuser,f,comm,label | awk '$1 == "test2" || $2 ~ /15298|15063/'
root 15063 15062 root root root 4 ruby-mriunconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
root 15298 12982 root root root 4 sudounconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
test215304 15298 test2test2test24 sleep unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
test215452 15063 test2test2test24 sleep unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[root@laptop /proc]# grep 'open files' {15063,15298,15304,15452}/limits
15063/limits:Max open files1024 4096 files
Jira (PUP-6635) An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf
Title: Message Title
Reid Wahl updated an issue
Puppet / PUP-6635
An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf
Change By:
Reid Wahl
Comment:
Hmm. I missed the {{provider => shell}} til now. Not familiar enough with Ruby to recognize right away how this comes into play and whether the Ruby Process::UID method is still being called, but I believe it is.
Add Comment
This message was sent by Atlassian JIRA (v7.0.2#70111-sha1:88534db)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6635) An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf
Title: Message Title Reid Wahl commented on PUP-6635 Re: An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf Hmm. I missed the provider => shell til now. Add Comment This message was sent by Atlassian JIRA (v7.0.2#70111-sha1:88534db) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6635) An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf
Title: Message Title
Reid Wahl commented on PUP-6635
Re: An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf
Heheheh...
require File.expand_path('../../../../spec_helper', __FILE__)
describe "Process::UID.change_privilege" do
it "needs to be reviewed for spec completeness"
end
Add Comment
This message was sent by Atlassian JIRA (v7.0.2#70111-sha1:88534db)
Jira (PUP-6635) An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf
Title: Message Title Reid Wahl commented on PUP-6635 Re: An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf We can trace the implementation of exec with a user attribute set, all the way down to the Ruby Process::UID.change_privileges method: From exec.rb: output = Puppet::Util::Execution.execute(command, :failonfail => false, :combine => true, :uid => resource[:user], :gid => resource[:group], :override_locale => false, :custom_environment => environment, :sensitive => sensitive) From execution.rb's execute: elsif Puppet.features.posix? child_pid = nil begin
Jira (PUP-6635) An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf
Title: Message Title Joe Pinsonault updated an issue Puppet / PUP-6635 An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf Change By: Joe Pinsonault Labels: needs_epic triaged Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6635) An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf
Title: Message Title Geoff Nichols updated an issue Puppet / PUP-6635 An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf Change By: Geoff Nichols Sprint: Agent Accepted Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6635) An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf
Title: Message Title Geoff Nichols updated an issue Puppet / PUP-6635 An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf Change By: Geoff Nichols Labels: needs_epic Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6635) An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf
Title: Message Title Eric Sorenson updated an issue Puppet / PUP-6635 An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf Change By: Eric Sorenson Sprint: AP Grooming Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6635) An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf
Title: Message Title Eric Sorenson updated an issue Puppet / PUP-6635 An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf Change By: Eric Sorenson Team: Agent & Platform Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6635) An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf
Title: Message Title
Eric Sorenson updated an issue
Puppet / PUP-6635
An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf
Change By:
Eric Sorenson
In a case where limits (such as no of file handles allowed etc.) have been set for a user on a system using either /etc/security/limits.conf or a separate file under /etc/security/limits.d/, when an exec resource is run as this user, these limits are ignored and defaults are used. This can be easily reproduced by creating a user (oracle in my tests and in customer ticket) and setting {{nofile}} hard and soft limits for this user in either /etc/security/limits.conf or by creating a file under /etc/security/limits.d/ with the appropriate prefix and username.{code}[root@pe-201621-agent vagrant]# cat /etc/security/limits.conf | grep oracleoracle softnofile 4096oracle hardnofile 63536[root@pe-201621-agent vagrant]#{code}Running a simple script to print the limits to the console as user oracle will print the values as defined:{code}[oracle@pe-201621-agent vagrant]$ cat /tmp/test_ulimit.shecho "Hard:"/bin/bash -c 'ulimit -Hn'echo "Soft:"/bin/bash -c 'ulimit -Sn'[oracle@pe-201621-agent vagrant]$ /tmp/test_ulimit.shHard:63536Soft:4096[oracle@pe-201621-agent vagrant]${code}However, when this same script is called using puppet code, running puppet as root, different values are noted:{code:puppet}[root@pe-201621-agent vagrant]# cat test_ulimit.ppinclude test_ulimitclass test_ulimit { exec { "test_ulimit":provider => "shell",user => "oracle",path => "/tmp",command => "test_ulimit.sh",logoutput => "true" }}{code} {code} [root@pe-201621-agent vagrant]# puppet apply test_ulimit.ppNotice: Compiled catalog for pe-201621-agent.puppetdebug.vlan in environment production in 0.07 secondsNotice: /Stage[main]/Test_ulimit/Exec[test_ulimit]/returns: Hard:Notice: /Stage[main]/Test_ulimit/Exec[test_ulimit]/returns: 4096Notice: /Stage[main]/Test_ulimit/Exec[test_ulimit]/returns: Soft:Notice: /Stage[main]/Test_ulimit/Exec[test_ulimit]/returns: 1024Notice: /Stage[main]/Test_ulimit/Exec[test_ulimit]/returns: executed successfullyNotice: Applied catalog in 0.06 seconds[root@pe-201621-agent vagrant]#{code}I suspect that the script called by the exec resource is actually inheriting the limit values from the puppet process, while it does actually run as the user specified in the exec resource in puppet code.The issue is that the customer is using this exec to kick off processes which interact with an oracle database as the oracle user, and needs the increased number of open file descriptors.Is this a natural by-product of using an exec resource, or is it a bug? Is there a way to resolve this either in the puppet code written by the customer in the exec resource or in the product itself?If I have linked to the wrong scrum team, please re-assign.
Jira (PUP-6635) An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf
Title: Message Title
Eric Sorenson updated an issue
Puppet / PUP-6635
An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf
Change By:
Eric Sorenson
In a case where limits (such as no of file handles allowed etc.) have been set for a user on a system using either /etc/security/limits.conf or a separate file under /etc/security/limits.d/, when an exec resource is run as this user, these limits are ignored and defaults are used. This can be easily reproduced by creating a user (oracle in my tests and in customer ticket) and setting {{nofile}} hard and soft limits for this user in either /etc/security/limits.conf or by creating a file under /etc/security/limits.d/ with the appropriate prefix and username.{ { code} [root@pe-201621-agent vagrant]# cat /etc/security/limits.conf | grep oracleoracle softnofile 4096oracle hardnofile 63536[root@pe-201621-agent vagrant]# {code } } Running a simple script to print the limits to the console as user oracle will print the values as defined:{ { code} [oracle@pe-201621-agent vagrant]$ cat /tmp/test_ulimit.shecho "Hard:"/bin/bash -c 'ulimit -Hn'echo "Soft:"/bin/bash -c 'ulimit -Sn'[oracle@pe-201621-agent vagrant]$ /tmp/test_ulimit.shHard:63536Soft:4096[oracle@pe-201621-agent vagrant]$ {code } } However, when this same script is called using puppet code, running puppet as root, different values are noted:{ { code:puppet} [root@pe-201621-agent vagrant]# cat test_ulimit.ppinclude test_ulimitclass test_ulimit { exec { "test_ulimit":provider => "shell",user => "oracle",path => "/tmp",command => "test_ulimit.sh",logoutput => "true" }} {code} [root@pe-201621-agent vagrant]# puppet apply test_ulimit.ppNotice: Compiled catalog for pe-201621-agent.puppetdebug.vlan in environment production in 0.07 secondsNotice: /Stage[main]/Test_ulimit/Exec[test_ulimit]/returns: Hard:Notice: /Stage[main]/Test_ulimit/Exec[test_ulimit]/returns: 4096Notice: /Stage[main]/Test_ulimit/Exec[test_ulimit]/returns: Soft:Notice: /Stage[main]/Test_ulimit/Exec[test_ulimit]/returns: 1024Notice: /Stage[main]/Test_ulimit/Exec[test_ulimit]/returns: executed successfullyNotice: Applied catalog in 0.06 seconds[root@pe-201621-agent vagrant]# {code } } I suspect that the script called by the exec resource is actually inheriting the limit values from the puppet process, while it does actually run as the user specified in the exec resource in puppet code.The issue is that the customer is using this exec to kick off processes which interact with an oracle database as the oracle user, and needs the increased number of open file descriptors.Is this a natural by-product of using an exec resource, or is it a bug? Is there a way to resolve this either in the puppet code written by the customer in the exec resource or in the product itself?If I have linked to the wrong scrum team, please re-assign.
Jira (PUP-6635) An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf
Title: Message Title
Stefan Pijnappels updated an issue
Puppet / PUP-6635
An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf
Change By:
Stefan Pijnappels
In a case where limits (such as no of file handles allowed etc.) have been set for a user on a system using either /etc/security/limits.conf or a separate file under /etc/security/limits.d/, when an exec resource is run as this user, these limits are ignored and defaults are used. This can be easily reproduced by creating a user (oracle in my tests and in customer ticket) and setting {{nofile}} hard and soft limits for this user in either /etc/security/limits.conf or by creating a file under /etc/security/limits.d/ with the appropriate prefix and username.{{[root@pe-201621-agent vagrant]# cat /etc/security/limits.conf | grep oracleoracle softnofile 4096oracle hardnofile 63536[root@pe-201621-agent vagrant]#}}Running a simple script to print the limits to the console as user oracle will print the values as defined:{{[oracle@pe-201621-agent vagrant]$ cat /tmp/test_ulimit.shecho "Hard:"/bin/bash -c 'ulimit -Hn'echo "Soft:"/bin/bash -c 'ulimit -Sn'[oracle@pe-201621-agent vagrant]$ /tmp/test_ulimit.shHard:63536Soft:4096[oracle@pe-201621-agent vagrant]$}}However, when this same script is called using puppet code, running puppet as root, different values are noted:{{[root@pe-201621-agent vagrant]# cat test_ulimit.ppinclude test_ulimitclass test_ulimit { exec { "test_ulimit":provider => "shell",user => "oracle",path => "/tmp",command => "test_ulimit.sh",logoutput => "true" }}[root@pe-201621-agent vagrant]# puppet apply test_ulimit.ppNotice: Compiled catalog for pe-201621-agent.puppetdebug.vlan in environment production in 0.07 secondsNotice: /Stage[main]/Test_ulimit/Exec[test_ulimit]/returns: Hard:Notice: /Stage[main]/Test_ulimit/Exec[test_ulimit]/returns: 4096Notice: /Stage[main]/Test_ulimit/Exec[test_ulimit]/returns: Soft:Notice: /Stage[main]/Test_ulimit/Exec[test_ulimit]/returns: 1024Notice: /Stage[main]/Test_ulimit/Exec[test_ulimit]/returns: executed successfullyNotice: Applied catalog in 0.06 seconds[root@pe-201621-agent vagrant]#}}I suspect that the script called by the exec resource is actually inheriting the limit values from the puppet process, while it does actually run as the user specified in the exec resource in puppet code.The issue is that the customer is using this exec to kick off processes which interact with an oracle database as the oracle user, and needs the increased number of open file descriptors.Is this a natural by-product of using an exec resource, or is it a bug? Is there a way to resolve this either in the puppet code written by the customer in the exec resource or in the product itself? The customer ticket is https://puppetlabs.zendesk.com/agent/tickets/20532 If I have linked to the wrong scrum team, please re-assign.
Jira (PUP-6635) An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf
Title: Message Title Kylo Ginsberg commented on PUP-6635 Re: An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf Yep, done. Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6635) An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf
Title: Message Title Kylo Ginsberg moved an issue Puppet / PUP-6635 An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf Change By: Kylo Ginsberg Affects Version/s: PE 2016.2.1 Affects Version/s: PE 2016.1.1 Component/s: puppet Key: PE PUP - 17169 6635 Project: Puppet Enterprise [Internal] Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups
