Bug 219487

Summary:	setcap Command Does Not Support End-of-Options Marker --
Product:	Tools	Reporter:	spectatorian (bo0od)
Component:	libcap	Assignee:	Tools/Libcap default virtual assignee (tools_libcap)
Status:	RESOLVED WILL_NOT_FIX
Severity:	normal	CC:	morgan
Priority:	P3
Hardware:	All
OS:	Linux
Kernel Version:		Subsystem:
Regression:	No	Bisected commit-id:

Description spectatorian 2024-11-10 03:01:35 UTC

Dear Maintainer,


I am writing to report a potential issue with the setcap command, where it does not properly support the end-of-options marker --. This behavior is inconsistent with the getcap command, which correctly recognizes -- as an indication that subsequent arguments are filenames or paths rather than options.

Problem Description:

In typical command-line usage, -- is used to signal the end of command options, allowing paths or filenames that start with a dash (-) to be handled correctly. However, setcap fails when -- is provided in the command syntax. For instance:

setcap -r -- /bin/ping


This command results in an error:

Failed to set capabilities on file '--': No such file or directory


It appears that setcap is treating -- as if it were a target filename, rather than recognizing it as an end-of-options marker.
Expected Behavior

setcap should accept -- to allow filenames or paths starting with - without misinterpreting them as options. This behavior is currently supported by getcap and aligns with standard POSIX conventions for command-line arguments.
Steps to Reproduce

Run the following command:


setcap -r -- /bin/ping


Observe that setcap fails with an error indicating -- is treated as a file rather than as an end-of-options marker.

Workaround:

To avoid the error, -- can be omitted when working with paths that do not start with - . However, the lack of end-of-options support may still lead to issues for paths or filenames beginning with -.
Suggested Solution

Implement -- as an end-of-options marker in setcap, consistent with the handling in getcap and other standard utilities. This change would improve usability and align setcap with common command-line conventions.

Thank you for your attention to this issue.

Best regards

Comment 1 Andrew G. Morgan 2024-11-10 08:35:02 UTC

You can always specify the file with a "./" prefix, such as ./-this .

I'm reserving the libcap-2.72 release for a complete rewrite of libpsx. I'll address this request in libcap-2.73.

Comment 2 Andrew G. Morgan 2024-11-19 05:21:07 UTC

I've been looking at the setcap command and it doesn't work this way. The idea that it be used to set the same capabilities on more than one file at a time isn't how it was designed.

The usage message:

setcap ... (-r|-|<caps>) <filename> [ ... (-r|-|<capsN>) filenameN> ]

makes it clear that the user is expected to supply "a capability" and a "filename" in pairs. Given this, conventional meaning for "--" doesn't apply to this utility.

I won't be implementing support for it. As noted above, you can specify any filename you need by prefixing it with its path (relative or absolute).