- User Since
- Sep 8 2020, 4:19 PM (6 w, 4 d)
Thu, Oct 22
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.
Tue, Oct 20
Mon, Oct 19
Yes, that makes sense.
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.
Doing the work on the user interface side was a conscious decision on my part. What are the disadvantages of doing it this way?
Would such an approach work if I don't have the full path of the program to be executed?
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).
Thu, Oct 1
Went through and looked for all instances of &&: all of them should be changed.
Wed, Sep 30
Fri, Sep 25
Fixed the whitespace problem. Can't believe I didn't see it, considering I saw the other one
Sep 24 2020
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.
Sep 23 2020
Sep 22 2020
Sep 21 2020
Sep 17 2020
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.
Sep 16 2020
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.