Adding portability to FreeBSD about openrsync HOT 10 CLOSED

First, recallocarray and realloc are not the same, so using this patch will break things in dangerous ways.

Second, stripping out the security mechanisms is a bad idea. I understand you're just trying to get a compile, but a great part of reimplementing something is to fit in some proper security. Capsicum isn't easy to work with, but it's what you have. The system is already outfitted with openat and equivalent, so you should be able to follow the pledges (and unveils) neatly.

All that being said, I'm not considering portability yet. I don't want to discourage you: the code is just moving way too quickly to be tracking with patches.

Once I tag out with an initial version, I'll turn to questions of portability. As you can see, it's really not difficult. The hard part is Capsicum---and frankly, without Capsicum bits, the port is only partial.

Meawhile, this might be a good time to get recallocarray into FreeBSD's libc... ;)

from openrsync.

reallocarray(3) is in FreeBSD, starting with 11.0-RELEASE. :)

from openrsync.

And recallocarray? (Note the c.)

from openrsync.

I understand where you are coming from and if this patch is premature (either in quality or time-wise due to coding changes) then there are no hard feelings if it is rejected. I would like to share a few thoughts in response to the points you made above:

1. I agree, recallocarry and realloc are not the same. This should be updated later, probably with a memset call. For now I just want to get openrsync to compile. Then polish the port.

2. I agree, stripping security is bad. But I want to get this working on not just FreeBSD, but also Linux. To do that I've got to work around functions that don't exist on those platforms. I've been careful to leave the calls intact in my patch on the native (OpenBSD) platform.

3. I agree carrying patches is not a great idea. But I think these could be applied upstream with no negative impact on the native platform, and it'll give other porters a place to start.

I agree, getting all of these secure functions into FreeBSD would be ideal. Not really in the scope of what I am doing personally, but I'd love to see someone put recallocarray and unveil in FreeBSD.

from openrsync.

Whoops, sorry, I missed the c. recallocarray indeed does not exist on FreeBSD. Sorry for the noise!

from openrsync.

As noted in the README, I was able to use oconfigure to easily port the system to FreeBSD (and Linux). (On FreeBSD, you'll also need to make endian.h -> sys/endian.h.) However, also as mentioned, any port is not complete without having the appropriate security mechanisms. If your system's security model is hard to implement---please talk to them about it. But in this day and age, having a critical network-facing utility accepting binary data on the wire without some means of sandbox is irresponsible.

from openrsync.

Porting to Capsicum should be fairly straightforward as openrsync already makes extensive use of the *at() functions; on a quick look it appears now that only rsync_sender calls plain open() for files. Then it's just calling cap_enter() at the appropriate point, probably at the where the final pledge() is done now after setup/initialization and before starting to parse/interact with network traffic or untrusted data. One of my co-op students will probably take a look at this shortly.

from openrsync.

Porting the receiver to Capsicum should be fairly straightforward, because of the use of *at() functions.

Accepting multiple files/directories on the command line makes the sender side more complicated; we've recently added the cap_fileargs service to support this use. The second issue is the path for fts - we'll need to add a fts_openat or such to operate relative to a provided directory file descriptor.

from openrsync.

If/when you get these, feel free to submit them. Til then I've put a compatibility shim so it should compile on freebsd.

from openrsync.

I agree it makes sense to close this issue (and I will submit patches for a Capsicumized FreeBSD port when they're fully ready).

For reference the current WIP/discussion is in https://reviews.freebsd.org/D19407 - this is (intentionally) not upstreamable as is, we just removed/replaced existing pledge/unveil calls to be able to review/comprehend the change.

The current dependency we need to address is a sandbox-friendly fts(3); we have a plan, just need to implement it.

from openrsync.