Require CAP_PWRITE (CAP_WRITE | CAP_SEEK) for posix_fallocate.

Per discussion on the recent capsicum call, posix_fallocate could require CAP_PWRITE (aka CAP_WRITE | CAP_SEEK) instead of just CAP_WRITE.

👍 (thumbs up) from me. I've applied this to my local test tree.

In D12037#260784, @ygy wrote:

@emaste Can I commit it myself?

PR: 190660
Reviewed by: allanjude
Approved by: emaste
Differential_Revision: https://reviews.freebsd.org/D12037

readelf -a output collected at https://people.freebsd.org/~emaste/gets/

exp-run is PR222796.

leave gets in old symver

LGTM as a first set of changes.

In D12328#259554, @loader wrote:

Nope, only on the doc/zh_CN tree ...

One comment from https://wiki.freebsd.org/Phabricator - for future reviews please create diffs with full context as it makes review easier in the UI. One of:

git diff -U999999 other-branch
svn diff --diff-cmd=diff -x -U999999

From in-person working group session, a suggestion to rename libcasper.h to libcasper.h.in and run unifdef on it during install.

For future updates please include full context (e.g. git diff -U9999)

In D12391#257162, @cem wrote:

I see. I was looking at the C file subr_capability.c and didn't know to look in that header.

From sys/sys/caprights.h:

/*
 * The top two bits in the first element of the cr_rights[] array contain
 * total number of elements in the array - 2. This means if those two bits are
 * equal to 0, we have 2 array elements.
 * The top two bits in all remaining array elements should be 0.
 * The next five bits contain array index. Only one bit is used and bit position
 * in this five-bits range defines array index. This means there can be at most
 * five array elements.
 */

and sys/kern/subr_capability.c:

static __inline int
right_to_index(uint64_t right)
{
        static const int bit2idx[] = {
                -1, 0, 1, -1, 2, -1, -1, -1, 3, -1, -1, -1, -1, -1, -1, -1,    
                4, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1  
        };
        int idx;

In D12380#256984, @ed wrote:

The reason that empty calls are disallowed is because that would expand to cap_rights_is_set(, 0ULL); notice the bad comma. The advantage of the existing code is that it carefully avoids using ##__VA_ARGS__, which is only permitted in C (not C++) as of C99.

In D12380#256853, @cem wrote:

Probably the goal of the original version was to avoid the non-standard "foo, ## bar" compiler extension. I am ok with the change, though.

I agree with @imp, for future changes like this you could just go ahead and commit the style / whitespace fix and then submit the review from that.

The whitespace changes make this a bit hard to read - do you have them as a separate local change that could be committed first?

Indeed, make that D9680.

In D12343#255946, @kib wrote:

Perhaps also mention that dotdot is not allowed on non-local fs, unless vfs.lookup_cap_dotdot ise set.

In D10931#256074, @eric_metricspace.net wrote:

I'm unsure as to what needs to happen now. Do I need to do anything to my patches yet?

Hrm, although the ENOTCAPABLE errors should really be augmented with "... and the process is in capability mode."

In D9680#239393, @imp wrote:

Why not 50MB instead of 512kb? That's stupidly small and precludes any and all future use of UEFI programs as well as boot block bloat. bz2 compressed, the size difference is trivial.

In D10931#255107, @imp wrote:

Once again I ask: where are we with makefs and FAT filesystems? :)

In D10931#255082, @allanjude wrote:

maybe switch to xz (doesn't save any space over bzip, but is one of the only remaining uses of bzip in buildworld)

D12298 is what I tried during Vixie's talk

disallow arch-specific differences in fs images by enforcing known 0x2d offset

Update usage message as suggested by @ngie

Looks good to me.

In D12284#254878, @rlibby wrote:

It appears to have been in upstream: ftp://ftp.iana.org/tz/code/zic.c (see oadd).

As for when we might sync with upstream next, I have no idea. Last sync appears to have been in 2010.