On Friday 22 December 2006 02:54, Otto Moerbeek wrote: > > Judging from the amount of noise this post made > > I'm guessing that either a) no one cared or b) I > > didn't supply enough relevant info for anyone to > > bother to chime in with a hint or a pointer. > > > > I don't know much about systrace to be able to > > make any realistic progress with this, but some > > hints would be welcome. > > > > > > One thing I do find interesting is that the files > > patch fails on end up being 260 chars long (full > > path) or longer with the ".bak.orig" extension. > > > > > > $ env FLAVOR="hardened no_curl ..." make show=WRKDIR > > /usr/ports/www/php5/extensions/w-php-5.1.4-hardened-no_curl-no_dba- > >no_dbase-no_filepro-no_imap-no_ldap-no_mbstring-no_mysql-no_mysqli-n > >o_ncurses-no_odbc-no_shmop-no_soap-no_snmp-no_sqlite-no_sybase_ct-no > >_xmlrpc-no_xsl > > > > > > Which is 217 chars in length. Adding to that > > "/php-5.1.4" (10 chars in length) gives 227. > > > > The shortest of the files that failed to patch > > is 23 chars in length. The longest successfully > > patched file is 22 chars in length. The patched > > file is appended ".bak.orig" (9 chars long). > > > > So base path of 227 + '/' + 31 (longest patched > > file length: 22 + 9) gives 259. Anything longer > > seems to fail. > > > > It seems like a file-name length limit or something > > along those lines that make patch fail when under > > systrace. > > I find this interesting, I'll loo into this tonight. In the meantime, > you could try to isolate a single test case: a source file and a > patch file that fails. Tha would help me a lot. It looks like > systrace is enforcing the file name length limit NAME_MAX (which is > 255). Note that this is a different limit compared to PATH_MAX (which > is 1024). > > -Otto
Hi Otto, I'm working on arj/unarj ports for use with clamav, and I'm struggling to regain all the things I've forgotten about C. ;-) While searching the archives, I stumbled across this tread from a couple weeks ago but I'm still wondering if I've got the right idea... <stdio.h> #define FILENAME_MAX 1024 /* must be <= PATH_MAX <sys/syslimits.h> */ <sys/syslimits.h> #define NAME_MAX 255 /* max bytes in a file name */ #define PATH_MAX 1024 /* max bytes in pathname */ If I understand things correctly: -A fully qualified path including file name (i.e. canonical path) can not exceed 1024 bytes. -The file name itself (without path) can not exceed 255 bytes. Please correct or confirm the above. (more below) On Saturday 23 December 2006 03:13, Otto Moerbeek wrote: > It's systrace not capable of allocating mem for the args to > rename(2). The args are replaced by their canonical path (which is > absolute and thus quite long) and systrace uses the stackgap of 512 > bytes for that. Obviously two path names of each more than 300 chars > won't fit. > > In another case systrace returns ENOMEM if stackgap_alloc() fails, in > this case EINVAL. I think ENOMEM is better. > > I have no idea yet if it's feasible to increase the stackgap. > > -Otto If the limit on a canonical path is 1024 bytes and you need two such paths/strings for rename(2), then the result is you need 2048 bytes available and the 512 byte limit of the stackgap should be considered a bug. It seems you can't use systrace with the system as it's #defined. I expect people will want to use systrace on unarj when doing antivirus scanning inside the ARJ archives with clamav. Unfortunately, the current unarj port does not do any length checking on path/file names during extraction so I'm trying to add checking. If the archive contains brutally long path/file names, I expect it will get clobbered by systrace. -any suggestions? Thanks, JCR
