In D17128#371823, @des wrote:

I would strongly recommend submitting the sshbuf_{get,put,free}_passwd() part of this patch upstream.

I would prefer to commit this version. Sorry for me not responding for a while.

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#598927, @yzhong_freebsdfoundation.org wrote:

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.

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.

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.

Thats right, cap_exec_init, cap_exec_open, cap_exec_close are done potentialy in the sandboxed process.

In D24327#598914, @yzhong_freebsdfoundation.org wrote:

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.

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.
exec_command is called by Casper which is a different process, so doing work there is desirable.
It's the pattern I've seen from other Casper services.
I could be wrong though, would appreciate if someone could confirm.

I was mistaken we need service like this, we just need to work a little bit more on it.

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.

Note that in Casper service user interface and Casper backend are separate processes. Casper does all the work and the user interface simply passes and receives parameters.
One issue I noticed is that the code is doing the actual work (closing fds) in the user interface commands cap_exec_open() and cap_exec_close(), this should be done from exec_command(), perhaps via functions cap_exec_command_open() and cap_exec_command_close(). cap_fileargs.c has a good example of how to do this.
Do you plan to add some test cases?

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

Ou but I guess you wan't your new process not being in sandbox, right?

Please don't take this an a criticisms I just would like to know the advantages of this approach.

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.

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

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).

Please be sure to talk with upstream (Christos) before making changes.

• Fixed indents
• Added 2 comments

Minor fix

• Code for opening the filesystem has been shifted to main.c so that different cases for HAVE_CAPSICUM could use a similar call to checkfilesys()
• Added caph_enter_caspe() instead of caph_enter()
• Other minor fixes

I'll do some testing of this.

• Removed #ifndef HAVE_GETIPNODEBYNAME block completely and added a comment near the usage of getipnodebyname()
• Used nitems inside cap_dns_type_limit() and cap_dns_family_limit()
• Moved the logic for opening cap_dns to a new function capdns_open()

This looks ok to me modulo the outstanding comments.

• Added cap_fileargs for multiple filesystems as arguments.
• 2 instances of cap_fileargs have been used to imitate the open() calls for different flag cases
• Wrapped the sandboxing logic under HAVE_CAPSICUM flag

• Minor fix to let all cases of open() calls work

• Added #ifdef HAVE_CAPSICUM

Looks good to me as long as the capscium specific code were wrapped with #ifdef's as this is shared with other platforms.

Don't we need a makefile change as well, to set -DWITH_CASPER?

Minor fixes

• Removed unnecessary ifdefs
• Added some capsicum helper functions

Updated with context and removed a bug where it didn't work with the -I flag in the fist diff

• Added MK_CASPER check to the Makefile
• Added WITH_CASPER defines instead of HAVE_LIBCASPER
• Checked for errno after cap_enter() call
• Removed cansandbox variable

Updated the diff with context

In D25552#565512, @greg_unrelenting.technology wrote:

In D25552#565508, @markj wrote:

• these checks should really be lifted into a subroutine,

Yeah I thought about that..

Please let me know if you'd like to write patches for this, otherwise I will work on it.

Feel free to make the better version of the patch yourself, the patch review process would just be a slowdown :)

In D25552#565508, @markj wrote:

• these checks should really be lifted into a subroutine,

This looks ok to me. I'm happy to commit the patch as-is, but:

• these checks should really be lifted into a subroutine,
• cpuset_(get|set)domain() are not listed in capabilities.conf and so aren't available in capability mode at all, though clearly they should be.

I wonder if this should be incorporated as part of cap_net (D24688) instead?

Incorporate feedback

OK from manpages.

Updated license.

update license

effectively ignoring the $ORIGIN at all

So lets untangle this.

In D23043#505145, @kib wrote:

How do you define 'work' ? Show the ktrace of the test with patched rtld, I doubt that the library is loaded.

How do you define 'work' ? Show the ktrace of the test with patched rtld, I doubt that the library is loaded. Rtld never parses "#NNNN" in a path as a reference to a directory descriptor.

Superceded by D17128, committed in rS339216.