Bug 747554 - Can't execute remote commands when client mounts /tmp with "nosuid"
Summary: Can't execute remote commands when client mounts /tmp with "nosuid"
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Spacewalk
Classification: Community
Component: Clients
Version: 1.6
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Milan Zázrivec
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
Depends On:
Blocks: space16 750766
TreeView+ depends on / blocked
 
Reported: 2011-10-20 09:41 UTC by Duncan Innes
Modified: 2011-12-22 16:49 UTC (History)
1 user (show)

Fixed In Version: rhncfg-5.10.7-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-22 16:49:09 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 514428 1 None None None 2021-01-20 06:05:38 UTC

Internal Links: 514428

Description Duncan Innes 2011-10-20 09:41:14 UTC
Description of problem:
Can't execute remote commands when client mounts /tmp with "nosuid"

Version-Release number of selected component (if applicable):


How reproducible:
Every time I schedule a remote command

Steps to Reproduce:
1. Configure /tmp to mount with "nosuid" (a common security hardening step)
2. Run a remote command via Spacewalk
  
Actual results: Fail


Expected results: Script runs


Additional info:  Can configure the TEMPDIR parameter to point somewhere else, but I think this is a messy solution.

Comment 1 Duncan Innes 2011-10-20 10:12:25 UTC
And I've just realised I've sleep-walked into creating this as a Spacewalk bug.  I see the issue on Satellite 5.4.1 and haven't actually tried it on Spacewalk yet - sorry.

The scripts fail due to "noexec" and "nosuid" being applied to the /tmp mount as per most of the security lock-down benchmarks available for RHEL.

My hints for a solution would be to use a private secure directory (somewhere in /var/spool perhaps) rather than /tmp

If this issue doesn't bother Spacewalk, then please forgive my intrusion.

Comment 2 Milan Zázrivec 2011-10-21 14:32:10 UTC
You are right in saying this problem shows in RHEL (the stock RHEL,
without any Spacewalk client stuff updated).

The thing though has been fixed in spacewalk.git master, commit:
be9c7586090e42f56f06fea67512c625883434b3 and released with Spacewalk 1.5.

With this change in place, the default temporary directory will be
'/var/spool/rhn' and is customizable with 'script_tmp_dir' option
in 'rhncfg-client.conf'.

Comment 3 Duncan Innes 2011-10-25 10:25:02 UTC
Sounds perfect.  Now to get it into Satellite :-)

Comment 4 Milan Zázrivec 2011-10-25 12:06:29 UTC
(In reply to comment #3)
> Sounds perfect.  Now to get it into Satellite :-)

If Satellite is a priority, may I suggest to clone this bug for Satellite
and reach out to Red Hat support -- a customer ticket attached to a bug
report will make a stronger statement when prioritizing bugs for a future
rhncfg errata.

Thank you.

Comment 5 Duncan Innes 2011-10-25 12:48:17 UTC
Already done Milan.  Bug raised, downgraded to an RFE by Red Hat support, linked back to this ticket now that it's already been done in Spacewalk.

Many thanks

Duncan

Comment 6 Milan Zázrivec 2011-12-22 16:49:09 UTC
Spacewalk 1.6 has been released.


Note You need to log in before you can comment on or make changes to this bug.