On Sat, 2008-02-09 at 17:41 -0500, Matt McCutchen wrote: > Instead, > let's recommend daemon administrators to copy the necessary encoding > helper libraries into the module and daemon-exclude them.
Ouch, this brings up a serious problem. Any writable chrooted module that accepts --iconv has to protect the locations where the C library looks for iconv helper libraries really well (whether or not the libraries are actually present!), because a client who can create/modify libraries in these locations can cause arbitrary code to be run in the daemon process. The chroot will stop an injected daemon process from doing certain kinds of damage, but we still absolutely don't want clients circumventing policies that the daemon administrator has put in place. (Here is a rare example where chroot actually *decreases* security.) IMO, we can't afford for rsync 3.0.0 daemons to be insecure by default, so they should not allow --iconv for writable chrooted modules. A daemon administrator who has set up appropriate security measures (either file permissions, or daemon excludes + the accompanying option refusals recommended in the recent advisory) should be able to override this. If the --iconv refusal can be incorporated compatibly into the existing "refuse options" parameter, great; otherwise let's have a separate daemon parameter called "allow iconv" that defaults to "read only || !(use chroot)". In general, we need to be more careful about what C library features chrooted daemons use. Does anyone know if loading of untrusted time zone files is a risk? BTW, I found this previous mention of the conflict between chroot and iconv in the archives, but the discussion never went anywhere: http://lists.samba.org/archive/rsync/2006-October/016627.html I guess I must not have seen that message at the time because I was bogged down with college applications. :( Matt -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
