Bug 2035241 - WorkingDirectory path containing whitespace in service unit not handled correctly
Summary: WorkingDirectory path containing whitespace in service unit not handled corre...
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: systemd
Version: 7.9
Hardware: x86_64
OS: Linux
Target Milestone: rc
: ---
Assignee: systemd-maint
QA Contact: Frantisek Sumsal
Depends On:
TreeView+ depends on / blocked
Reported: 2021-12-23 11:06 UTC by xyqfff
Modified: 2022-01-25 12:03 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2022-01-25 12:02:56 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-106507 0 None None None 2021-12-23 11:10:54 UTC

Description xyqfff 2021-12-23 11:06:27 UTC
Description of problem:

It is impossible to create a properly working service unit file which has, for its WorkingDirectory, a path containing whitespace. None of the following will work:
* double- or single-quoting the path
* escaping the whitespace characters with backslashes
* substituting the output of 'systemd-escape -p <path>' for the path

When an attempt is made to use a unit file employing the first or third schemes above, the message "systemd[1]: [<unit file>:<line number>] Not an absolute path, ignoring: <path>" is sent to the journal; however the service does indeed run. (If backslash-escaping is tried, the error is different and the service will not start.)

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

Systemd is up to date on my system: "systemctl --version" reports "systemd 219". 

How reproducible:

Steps to Reproduce:
1.  Create a short script, for example:

pwd > /tmp/<output file>

2.  Create a test service unit, for example:

Description=Test service

WorkingDirectory=<path containing spaces, using any of the 3 schemes quoted above>
ExecStart=<path to script>
User=<my user>
Group=<my group>


3.  Start the service using systemctl.  

Actual results:

When this service is started using systemctl, the working directory will be revealed as "/" for the first and third schemes above, and the service will fail to start for the second scheme above.

If a path not containing whitespace is entered in the unit file for WorkingDirectory (and is one accessible to the quoted user), the service will start without errors and the called script will output the correct working directory to the output file. 

Expected results:

There should be a way of specifying a path containing whitespace for WorkingDirectory.  

Additional info:

Comment 3 RHEL Program Management 2021-12-24 09:51:04 UTC
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.

Comment 4 xyqfff 2022-01-25 09:00:40 UTC
Explanations would be appreciated as to why this bug report is regarded as a "request", and as to why it has been "declined".

Comment 6 David Tardon 2022-01-25 12:02:56 UTC
(In reply to xyqfff from comment #4)
> Explanations would be appreciated as to why this bug report is regarded as a
> "request", and as to why it has been "declined".

Canned text follows:

RHEL 7 is currently in Maintenance Support 2 Phase.

The support of the product in this phase is limited, and not every bug should be getting fixed and is defined as this:

"During the Maintenance Support Phase for Red Hat Enterprise Linux Version 8 and Maintenance Support 2 Phase for Red Hat Enterprise Linux version 6, and 7, Red Hat defined Critical and Importantix impact Security Advisories (RHSAs) and selected (at Red Hat discretion) Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available. Other errata advisories may be delivered as appropriate.

New functionality and new hardware enablement are not planned for availability in the Maintenance Support (RHEL 8) Phase and Maintenance Support 2 (RHEL 6, 7) Phase. Minor releases with updated installation images may be made available in this Phase."

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