Relative paths resolve incorrectly -

[thewacokid]

I don't have an exhaustive comparison of how paths are expanded, but they do seem to resolve improperly for special dirs like "." and ".." for source and destination.

I'll put in a pull request soon for the updates to the pfcp/pfcm/pfls scripts that launch pftool, I added an absolute path resolver in them so that pftool only has to deal with absolute paths (for now). The assumption I had to make is that nobody will have "/var/lib/perceus/vnfs/" along with "/rootfs/" in their path. I believe that's fairly safe, but I'm documenting it here just in case someone uses it outside of LANL and decides to Google.

[thewacokid]

Python fixed here: 95ddc32

[brettkettering]

This needs to be fixed at some point, but the pf* wrapper scripts now change relative paths to full paths. So, we can get by without fixing this for Secure Campaign because we'll only allow users to use these wrapper scripts.

[jti-lanl]

pftool could generate absolute paths by either (a) calling realpath(), or (b) simulating realpath() by prepending cwd and then canonicalizing using just regular expressions.

However, for marfs paths, the former approach would fail on back-end nodes where there is no marfs fuse-mount. The latter approach would produce unexpected results for paths that include symlinks that refer to directories with parents that are different from the parent of the symlink. (For example: "./my_dir_link/../blah" is not necessarily the same as "./blah".)

Rather than having pf-scripts do explicit string-processing on the paths, it seems like one simple and safe alternative would be for pf-scripts to invoke realpath(). The nice thing about that approach is that those scripts run on the front-ends, with e.g. marfs_fuse mounted, so symlinks can be followed.

Another option is for pftool to implement its own realpath(), using Path::readlink(), etc.

[jti-lanl]

On second thought, there's more to be discussed here.

[jti-lanl]

Another issue is that pftool called from pf-scripts doesn't know what the working-dir was, when the pf-scripts were invoked. This information could be passed as another argument to pftool, but it's starting to look easier to just call realpath() in the scripts.

[garygrider]

Seems like realpath in the scripts gets us pretty far

Is there a scriptable version of realpath or do we need to write a 4 line C program?

From: Jeff Inman [mailto:notifications@github.com]
Sent: Friday, July 22, 2016 10:48 AM
To: pftool/pftool
Subject: Re: [pftool/pftool] Relative paths resolve incorrectly - (#15)

Another issue is that pftool called from pf-scripts doesn't know what the working-dir was, when the pf-scripts were invoked. This information could be passed as another argument to pftool, but it's starting to look easier to just call realpath() in the scripts.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com//issues/15#issuecomment-234595236, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ALNxmfqGiY5fGax5rfX0Fjye9vPvL--Qks5qYPQxgaJpZM4H57vm.

[thewacokid]

I already modified the pf-scripts to use abspath to get rid of weirdness with relative paths, switching that over to realpath would be very trivial (or a combination of both).

os.path.realpath(path) https://docs.python.org/2/library/os.path.html#os.path.realpath
Return the canonical path of the specified filename, eliminating any symbolic links encountered in the path (if they are supported by the operating system).

New in version 2.2.

• Dave

On Jul 22, 2016, at 11:23 AM, garygrider notifications@github.com wrote:

Seems like realpath in the scripts gets us pretty far

Is there a scriptable version of realpath or do we need to write a 4 line C program?

From: Jeff Inman [mailto:notifications@github.com]
Sent: Friday, July 22, 2016 10:48 AM
To: pftool/pftool
Subject: Re: [pftool/pftool] Relative paths resolve incorrectly - (#15)

Another issue is that pftool called from pf-scripts doesn't know what the working-dir was, when the pf-scripts were invoked. This information could be passed as another argument to pftool, but it's starting to look easier to just call realpath() in the scripts.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com//issues/15#issuecomment-234595236, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ALNxmfqGiY5fGax5rfX0Fjye9vPvL--Qks5qYPQxgaJpZM4H57vm.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub #15 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ADRbVdmc0zKbAQQF0GHH5VsHZ73Wpp5kks5qYPyAgaJpZM4H57vm.

[thewacokid]

@so, this popped up in production this week. I need to test it, but DNE is creating headaches. I used os.path.abspath in my patch, but not os.path.realpath. The former does not resolve symlinks, and DNE uses symlinks to shuffle users around between metadata servers.

Anyone see any problems with simply resolving symlinks prior to handing them to pftool?

Update: I can confirm this works with DNE.

[cadejager]

I think that will suffice for the next release. Leave the issue open so that someone can actually dig into the pftool issue.

[cadejager]

This has been fixed by 5e4fe55 in pftool proper.