[PATCH] pathname cleanups

[Jeremy Allison]

On Fri, May 19, 2017 at 08:37:03AM +0200, Volker Lendecke wrote:
> 
> To support the dumb clients the heuristic would have to be to try
> inserting @GMT at all places where / now is if we lose the place the
> client sent the @GMT initially. We can't rely on the flag being set I
> believe. We're talking FreeBSD, (I believe AIX) and other custom SMB
> clients that used to work.

Thinking about this some more, the natural fix for this is
for clients that don't set the flag to just pass in the
unmodified pathname into the VFS (which my patch fixes
smbd to do), and shadow_copy2 then will sort this out in the same
way as it always did.

The security changes didn't modify the code that uses
strstr_m(name, "@GMT-") to find the timestamp in the
incoming path, so shadow_copy2 still copes with both
canonicalized and non-canonicalized paths (at least
the non-canonicalized paths work as well as they
ever did, which means there are probably some
failure cases that clients rarely come across :-).

That should fix it for your customer for now.

Then when I add in the time_t value to struct smb_filename,
so long as I simply add the processing of the timestamp
passed in as an alternative to the existing method
of searching for the @GMT timestamp, but don't remove
the @GMT search for struct smb_filenames without the
timestamp, then both the old clients that don't set the
flag, and new clients that use SMB2 or correctly set the
flag in SMB1 will still continue to work !

The only thing that would fail would be for people
who want to use @GMT snapshots via shadow_copy2, but
also have paths that contain @GMT names. This is a very
small subset of customers I think :-) :-).

That does unfortunately keep all the horrible complexity
in vfs_shadow_copy2 that adding the timestamp to
struct smb_filename was supposed to remove, but it's
then no worse than it is today :-).

Sound like a plan ?

Cheers,

	Jeremy.