Bug 287701 - PATH_MAX patch seems incomplete
 Summary: PATH_MAX patch seems incomplete
 Status: Product: CLOSED RAWHIDE Aliases: None Fedora Fedora acl (Show other bugs) --- rawhide All Linux medium Severity medium --- Target Release: --- Jiri Moskovcak Fedora Extras Quality Assurance EasyFix Show dependency tree / graph

 Reported: 2007-09-12 10:54 EDT by Dmitry Butskoy 2015-02-01 17:47 EST (History) 2 users (show) dfediuck steved Bug Fix --- 2007-09-20 10:06:47 EDT --- --- --- --- --- --- ---

 Dmitry Butskoy 2007-09-12 10:54:15 EDT In the acl-2.3.39-path_max.patch the size of linebif' array was changed from 1024 to PATH_MAX (which is 4096 for Linux). But actually, when "getfattr" writes the long non-ascii filenames, it uses "\xxx" quotes for each non-ascii byte. That way a typical 2-bytes utf-8 symbol will occupy 2*4=8 characters in the output! (i.e., "\abc\def") IOW instead of [PATH_MAX+6], we should use at least [(8*PATH_MAX)+6] ... Dmitry Butskoy 2007-09-12 10:54:15 EDT Created attachment 193501 [details] probably fixed patch variant Dmitry Butskoy 2007-09-12 11:06:59 EDT Please note, that with too long "# file: " line, the rest of the line might be unread at all, which can lead to unexpected results. Under my old FC5 system, it leads to setxattr ("cutted_filename", "# owner: foo", ...) instead of setxattr ("full_filename", "system.posix_acl_access", ...), i.e. a garbage instead of right attribute name. Fortunately setxattr() just returns EOPNOTSUPP ...  Dmitry Butskoy 2007-09-13 08:09:48 EDT Sorry, surely [(4*PATH_MAX)+6], because PATH_MAX counts raw bytes, not symbols... :) Jiri Moskovcak 2007-09-17 05:30:14 EDT Hi, could you please send me an example file name? I'm not able to create a file with name long enough to reproduce this bug - always get error message:"File name too long"(using Fedora 7). And another thing, which filesystem do you use? Actual filename length limit for ext3 is 255 ascii chars so even in the worst case with some special 3bytes utf symbols it should fit in the 4096 bytes array. Thank you. Jirka Dmitry Butskoy 2007-09-18 08:18:25 EDT > Actual filename length limit for ext3 is 255 ascii chars Yep, a limit for each path component (i.e. /usr/some/where/foo-256chars/bar-256chars/etc...) PATH_MAX is a limit for the whole path, it is 4096 raw bytes. > I'm not able to create a file with name long enough Well, you should not create "long-filename" file, no. You should create file with a lot of "non-ascii" characters. The problem is: "getfacl" writes non-ascii raw bytes enquoted, each such a byte is printed as "\xxx", where "xxx" is its octal code. Then, when "setfacl" reads such a dump, it reserves PATH_MAX bytes for the filename, but actually, if the filename contains raw non-ascii bytes, the input could be much more than just PATH_MAX (as for plain ascii case) -- because each non-ascii byte takes 4 bytes in the dump ("\xxx"). I.e. 4*PATH_MAX For the test, create a very long filepath (near the PATH_MAX), which contains only of non-ascii characters (I'm sure there are such ones in your locale anyway). Since ext3 has a limit of 256 for individual path component, it seems you should create at least 8 such "long non-ascii" subdirectories. Then run "getfacl -R" on it and see the output for the tested filepath. It should contain the filepath in the form of lot "\xxx" in it, and the whole size of such enquoted filepath will be much more than just PATH_MAX ... Jiri Moskovcak 2007-09-19 08:43:03 EDT I still don't see any problem, if I try to create the path as you've suggested, I get output from getfacl for "# file" about 16k chars long, but it prints the whole name - nothing stripped. I don't understand how you mean "setfacl reads such a dump". Even if i try "$setfacl long_path_with_utf_chars" everything works fine(for the same path, that makes 16k chars long output from getfacl). Jirka Dmitry Butskoy 2007-09-19 08:51:09 EDT > Even if i try "$setfacl long_path_with_utf_chars" Aaah, No. The case is "getfacl -R . >dump_file" and then "setfacl --restore=dump_file" > I get output from getfacl for "# file" about 16k chars long, but it prints the > whole name - nothing stripped. Yep, about 16k. But then, when you run "setfacl --restore=dump_filename", setfacl actually preserves PATH_MAX only bytes for "# file" line, whereas your line is 16k, much more than PATH_MAX=4096 ... Jiri Moskovcak 2007-09-19 10:43:00 EDT Oh, thank you, now it's obvious. You're right, in this case, it fails. Jiri Moskovcak 2007-09-20 10:06:47 EDT Fixed in rawhide. Dmitry Butskoy 2007-09-20 10:24:48 EDT Hmm... a little bit more needed. Actually, the prefix is "# file: ", i.e. is 8 bytes long, whereas we add only 6 bytes to 4*PATH_MAX ... Perhaps we should count '\0' (terminating null) too... Surely it is for a corner case, but to be robast against any future changes, please, change "+6" to, say "+16" . Additionally, I would vote for update for F-7 branch as well. The bug itself has "high" severity for non-latin environments (where, as in my "ru" locale, a lot of non-ascii symbolas in filenames is a usual case).  Jiri Moskovcak 2007-09-20 10:32:45 EDT Yes I'm updating the F7 packages right now.. and you're right about the "# file " prefix, I noticed that and forgot to change it. jirka`