Support » Plugin: File Away » Update to 3.9.7.7 produces empty listing

  • Resolved stoneyb

    (@stoneyb)


    As with htmanning’s problem, I updated from 3.9.6.1 to 3.9.7.7 and my file listings disappeared.

    This was reported to me on my main site, so I looked at my localhost copy, and found that it worked, but File Away was out of date. Once I updated it, it stopped working.

    I have WordPress in a sub-dir to my domain dir, /home/username/domainname/wp. The files I want to display are in /home/username/domainname/files, though. Something changed without my realizing it, since I used to be able to point File Away directly at this directory, but now I can’t edit the name through /wp. I added a symlink in wp/files that pointed at ../files, but that didn’t help. Going by your question about “..” in the path, I changed the symlink target to an absolute path, but that didn’t help either. Replacing the symlink with a copy of the files directory worked, though!

    I also tried adding a “..” to the base dir in File Away, but that didn’t work either.

    Ultimately, I moved the files dir into my wp dir and made a symlink to it from the domain root. This isn’t a good solution, as I’m more likely to delete my files dir accidentally.

    Is there a problem with File Away parsing “..” or opening dirs via symlinks?

    My main site is on a linux host and my development copy is on Mac. My Site Address and WordPress address are the same, and end in /wp.

    Thanks for any help getting this back to normal.

Viewing 15 replies - 1 through 15 (of 22 total)
  • Plugin Author thomstark

    (@thomstark)

    File Away no longer supports using “..” in any base or sub path, per WordPress’s security requirements, so that won’t work. I agree the symlink isn’t a good solution.

    I will take a closer look at the specifics of your situation when I get back to my desk.

    In the meantime, can you verify what your Root Directory setting is set to. It should be set to Site Root.

    Plugin Author thomstark

    (@thomstark)

    Oh, I see you have the same site address and wordpress address url. That is not the same setup as the other issue from yesterday. I will set mine up that way when I get back and see if I can reproduce.

    Yes, my Root Directory is set to “Site Root Directory”

    Plugin Author thomstark

    (@thomstark)

    Do you have an .htaccess in your root that forces all traffic to the wp directory? Is that how yours is set up?

    Plugin Author thomstark

    (@thomstark)

    Another question: go to your file away settings and delete everything from a base directory (or look at an empty one if they’re not all used). Dont save. Just tell me what the innermost directory is before you are able to start typing. Is it “domainname” or “wp”? Does it change when you change the Root Directory setting, hit save, and let it reload?

    My root .htaccess does not rewrite all accesses to the wp directory, just the top level.

    Redirect permanent /index.html /wp/

    The innermost directory that I can’t edit is “wp”. The base dirs are all /home/username/dommainname/wp/

    Changing the Root Directory to “WP Install Directory” does not change the Base Directories, or make them editable.

    Plugin Author thomstark

    (@thomstark)

    Ok so you just have a standard install. I cant figure out how you ever pointed back outside the wp directory in the first place, without using ..

    Maybe I misunderstood. Were you always using a symlink and the symlink is no longer working?

    I’m puzzled by that too. From backups, I see that I had a symlink in wp before, but somehow it disappeared.

    The one in a recent backup points to ../files, so if you changed something to disallow following “..” in a path, that would have broken it. I don’t know what happened to the symlink itself, though. Perhaps I was mistaken about it being missing.

    Since an absolute path in the symlink didn’t work, did you also disable following symlinks altogether?

    Plugin Author thomstark

    (@thomstark)

    I haven’t explicitly disallowed symlinks but perhaps indirectly by my use of realpath() to validate the path. Officially speaking, pointing outside the WP directory–either the install (which in your case is the only option) or where the domain is pointed (not your setup)–has never been supported. But I will play around with symlinks to see if I can find a clean way to do it. Are you using non-encrypted download links for your file downloads?

    The site is https, so files get DL’d that way, but there’s no encryption of the links themselves.

    Plugin Author thomstark

    (@thomstark)

    All right. Thank you. I will see if I can come up with a solution.

    Plugin Author thomstark

    (@thomstark)

    I just submitted a new version… that one is not for you. FYI

    Plugin Author thomstark

    (@thomstark)

    Hey, @stoneyb. I’ve got a symlink fix that is working for me with encryption both enabled and disabled. I still use realpath, but if the realpath doesn’t equal the specified path, then I iterate through the specified path to see if at any point there is a symlink. If there is a symlink, I check to see if the symlink target plus whatever child directories beyond the symlink are specified equal the realpath.

    Kind of like this:

    
    /realpath/to/files
    /realpath/to/wp/symlink
    

    Base_1 = /realpath/to/wp/symlink/newsletters

    realpath(Base_1) will equal /realpath/to/files/newsletters

    So if Base_1 does not equal realpath(Base_1), I do the following:

    Is /realpath/to/wp/symlink/newsletters a symlink?

    The answer will be NO because newsletters is not a symlink.

    So then I ask: Is /realpath/to/wp/symlink a symlink?

    In this case, then answer will be yes. So if I get a yes, I then do:

    Does the target of /realpath/to/wp/symlink + /newsletters equal /realpath/to/files/newsletters. If yes, you get a pass. If no, you get a fail.

    And it’s working for me.

    Give me a few minutes to commit the new version and I’ll let you know when it’s up.

    What is the problem just using realpath() directly? I assume that’s what you used to do. Some sort of security problem?

    I’ll try the upcoming new version and let you know.

    Plugin Author thomstark

    (@thomstark)

    3.9.7.9 is now up.

    The issue is when you’re using a symlink, the path to the symlink is not the same as the path to the target, and realpath() returns the path to the target. My new security checks make sure that the path provided to the file display function does not differ in any way as a string literal from the realpath() of the path provided. That was causing symlinks not to work. (It will also cause “..” not to work, but that is intentional and will not be changed.) I’ve now updated the function to check if there is a symlink involved if the path provided does not equal the realpath().

Viewing 15 replies - 1 through 15 (of 22 total)
  • You must be logged in to reply to this topic.