Bug 287701 - PATH_MAX patch seems incomplete
PATH_MAX patch seems incomplete
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: acl (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jiri Moskovcak
Fedora Extras Quality Assurance
: EasyFix
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-12 10:54 EDT by Dmitry Butskoy
Modified: 2015-02-01 17:47 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-09-20 10:06:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
probably fixed patch variant (684 bytes, patch)
2007-09-12 10:54 EDT, Dmitry Butskoy
no flags Details | Diff

  None (edit)
Description 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] ...
Comment 1 Dmitry Butskoy 2007-09-12 10:54:15 EDT
Created attachment 193501 [details]
probably fixed patch variant
Comment 2 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 ...

Comment 3 Dmitry Butskoy 2007-09-13 08:09:48 EDT
Sorry, surely [(4*PATH_MAX)+6], because PATH_MAX counts raw bytes, not symbols... :)
Comment 4 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
Comment 5 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 ...
Comment 6 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
Comment 7 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 ...
Comment 8 Jiri Moskovcak 2007-09-19 10:43:00 EDT
Oh, thank you, now it's obvious. You're right, in this case, it fails.
Comment 9 Jiri Moskovcak 2007-09-20 10:06:47 EDT
Fixed in rawhide.
Comment 10 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).
Comment 11 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

Note You need to log in before you can comment on or make changes to this bug.