Call drain earlier so that mmc_delayed_attach() and mmc_delete_cards() can't run concurrently.

${abs##*/} doesn't work if you enter a path that looks like a/b/c/ - it just gives the empty string back if I remember correctly. I see the problem with basename as well, now.

Added some simple tests, and made changes according to feedback. The biggest change is the addition of cap_exec_t structures, which behave very similarly to fileargs_t structures in cap_fileargs. Now there is no global state on the user's side, and you can now open multiple cap_exec services without issue.

Yes, that makes sense.

In D24327#598924, @tig_freebsdfoundation.org wrote:

From my understanding, doing work in the user interface functions is the same as doing work in user program, as they are the same process. It won't be allowed if program is in cap mode.

I understand what you mean. That's why I used pdfork - having the process descriptor lets me wait for the program even in Capability mode. All the current functionality works, so I'd prefer to keep things as it is unless we want the service to do more.

Doing the work on the user interface side was a conscious decision on my part. What are the disadvantages of doing it this way? And yes, I do plan to write tests.

Would such an approach work if I don't have the full path of the program to be executed?

In D24327#598833, @oshogbo wrote:

I wonder we can't just use fileargs and fexecve?

Thinking about it more, the change to FILE* makes it somewhat unintuitive (or impossible?) to execute commands that you neither read from nor write to. Initially, I made the change because I was doing:
1 - get a file descriptor from cap_exec_open
2 - call fdopen() on it to get a FILE* to work with
3 - later, close the file descriptor with cap_exec_close
But at this point I'm left with a 'dangling' FILE*. I can't call fclose on it as it gives me an unsurprising "bad file descriptor" error. So at this point I felt that it was more sensible for cap_exec to work with FILE*s, since it matches popen in any case. But now, I see that returning a FILE* doesn't make sense in all cases.

In the process of Capsicumizing sort(1), I found that I couldn't properly close the file descriptors that came from this service. It used to return the file descriptor of a FILE* opened via popen(3). This meant that the user can't use pclose to close the file descriptor they receive; pclose expects the same FILE * that popen returned, which the user can't recover. Pclose is responsible for waiting until the opened process ends, and if it isn't called, the user will get concurrency issues (like writing to a file, "closing" it, and then trying to read from it before the write actually finishes).

Went through and looked for all instances of &&: all of them should be changed.

Fixed the whitespace problem. Can't believe I didn't see it, considering I saw the other one

Added tests for the issues fixed directly by this patch.
Also added some tests for half line feeds, as I found that it was very easy to affect how they behave when changing the whitespace calculation code.

Fixed another issue: mbrtoc32() returns the error value (size_t)-2 if it reads a C1 control character. This wouldn't be a problem by itself, as the rest of the function takes care of it, but this screws up mbrtoc32()'s internal state for all of the characters afterwards. Switching to the non-restartable mbtowc() resolves that issue. However, I am not sure if this has any bad implications.

I tested it more thoroughly and found an additional problem (on line 984, it used to test if a size_t was less than 0), along with the ones markj pointed out. They should all be fixed now.

The only change I made to the original patch was to re-order some of the #include directives, as more had been added after the original patch was submitted.