Bug 287701

Created attachment 193501 [details]
probably fixed patch variant

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 ...

Sorry, surely [(4*PATH_MAX)+6], because PATH_MAX counts raw bytes, not symbols... :)

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

> 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 ...

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

> 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 ...

Oh, thank you, now it's obvious. You're right, in this case, it fails.

Fixed in rawhide.

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).

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