Page MenuHomeFreeBSD

yzhong_freebsdfoundation.org (Yang Zhong)
User

Projects

User does not belong to any projects.

User Details

User Since
Sep 8 2020, 4:19 PM (6 w, 4 d)

Recent Activity

Yesterday

yzhong_freebsdfoundation.org added inline comments to D26917: sort(1): Capsicumize.
Fri, Oct 23, 3:20 PM
yzhong_freebsdfoundation.org updated the summary of D26917: sort(1): Capsicumize.
Fri, Oct 23, 3:19 PM
yzhong_freebsdfoundation.org requested review of D26917: sort(1): Capsicumize.
Fri, Oct 23, 3:16 PM

Thu, Oct 22

yzhong_freebsdfoundation.org updated the diff for D24327: Add new casper execution service.

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.

Thu, Oct 22, 3:51 PM · capsicum

Tue, Oct 20

yzhong_freebsdfoundation.org added inline comments to D24327: Add new casper execution service.
Tue, Oct 20, 5:41 PM · capsicum

Mon, Oct 19

yzhong_freebsdfoundation.org added a comment to D24327: Add new casper execution service.

Yes, that makes sense.

Mon, Oct 19, 5:36 PM · capsicum
yzhong_freebsdfoundation.org added a comment to D24327: Add new casper execution service.
Mon, Oct 19, 5:26 PM · capsicum
yzhong_freebsdfoundation.org added a comment to D24327: Add new casper execution service.

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.

Mon, Oct 19, 5:20 PM · capsicum
yzhong_freebsdfoundation.org added a comment to D24327: Add new casper execution service.

Doing the work on the user interface side was a conscious decision on my part. What are the disadvantages of doing it this way?

Mon, Oct 19, 5:06 PM · capsicum
yzhong_freebsdfoundation.org added a comment to D24327: Add new casper execution service.

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

Mon, Oct 19, 4:41 PM · capsicum
yzhong_freebsdfoundation.org added a comment to D24327: Add new casper execution service.

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

Mon, Oct 19, 4:12 PM · capsicum
yzhong_freebsdfoundation.org added a comment to D24327: Add new casper execution service.

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.

Mon, Oct 19, 4:07 PM · capsicum
yzhong_freebsdfoundation.org updated the diff for D24327: Add new casper execution service.

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

Mon, Oct 19, 3:44 PM · capsicum
yzhong_freebsdfoundation.org retitled D24327: Add new casper execution service from Add new casper execuion service to Add new casper execution service.
Mon, Oct 19, 3:08 PM · capsicum
yzhong_freebsdfoundation.org commandeered D24327: Add new casper execution service.
Mon, Oct 19, 3:05 PM · capsicum

Thu, Oct 1

yzhong_freebsdfoundation.org updated the diff for D26614: fix skein1024.

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

Thu, Oct 1, 8:23 PM

Wed, Sep 30

yzhong_freebsdfoundation.org requested review of D26614: fix skein1024.
Wed, Sep 30, 8:25 PM
yzhong_freebsdfoundation.org requested review of D26609: periodic(8): Improve error messaging.
Wed, Sep 30, 3:38 PM

Fri, Sep 25

yzhong_freebsdfoundation.org updated the diff for D26536: col(1): fix incorrect output and segfault.

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

Fri, Sep 25, 6:02 PM

Sep 24 2020

yzhong_freebsdfoundation.org updated the diff for D26536: col(1): fix incorrect output and segfault.

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 24 2020, 5:45 PM

Sep 23 2020

yzhong_freebsdfoundation.org requested review of D26536: col(1): fix incorrect output and segfault.
Sep 23 2020, 7:00 PM

Sep 22 2020

yzhong_freebsdfoundation.org updated the diff for D26456: syslogd: Support locale when removing unsafe characters.
Sep 22 2020, 6:48 PM

Sep 21 2020

yzhong_freebsdfoundation.org updated the diff for D26456: syslogd: Support locale when removing unsafe characters.
Sep 21 2020, 3:57 PM

Sep 17 2020

yzhong_freebsdfoundation.org updated the diff for D26456: syslogd: Support locale when removing unsafe characters.

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.

Sep 17 2020, 6:03 PM
yzhong_freebsdfoundation.org added inline comments to D26456: syslogd: Support locale when removing unsafe characters.
Sep 17 2020, 5:06 PM
yzhong_freebsdfoundation.org updated the summary of D26456: syslogd: Support locale when removing unsafe characters.
Sep 17 2020, 4:48 PM
yzhong_freebsdfoundation.org updated the diff for D26456: syslogd: Support locale when removing unsafe characters.

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 17 2020, 4:22 PM

Sep 16 2020

yzhong_freebsdfoundation.org added a comment to D26456: syslogd: Support locale when removing unsafe characters.

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.

Sep 16 2020, 5:48 PM
yzhong_freebsdfoundation.org requested review of D26456: syslogd: Support locale when removing unsafe characters.
Sep 16 2020, 5:36 PM