[Libguestfs] [PATCH 1/3] New API: case-sensitive-path to return case sensitive path on NTFS 3g fs

Matthew Booth mbooth at redhat.com
Mon Oct 26 13:54:23 UTC 2009


On 26/10/09 13:25, Richard W.M. Jones wrote:
> On Mon, Oct 26, 2009 at 01:16:15PM +0000, Matthew Booth wrote:
>> .. or the guestfish user who types 'cat
>> win:c:\windows\system32\blah.txt' and doesn't get the result they
>> intended. Essentially you need to do this in 2 cases: you read a path
>> from a config file, or you're accessing a file whose location you
>> already know. In either case, the additional call is just untidiness.
>
> I don't understand this point.
>
> Who told them to look at "c:\windows\system32\blah.txt"?
> It must have come from a Windows config file, a Windows document or a
> book, and that path is not case-sensitive.
>
>>> In any other case, using case_sensitive_path is almost certainly
>>> wrong, in fact not just slow but quite likely to be insecure too.  You
>>> don't want a Linux config file that specifies /etc/something to
>>> randomly pick /etc/SOMETHING.
>>
>> It's a very good point. You can fix this, though. When iterating down
>> the directory structure, you'll open a file to check if it's a
>> directory. At the same time, to fstatfs() to check what filesystem it's
>> on. By doing this you can choose directory-by-directory whether or not
>> to be case-sensitive. This should always be safe.
>
> fstatfs doesn't tell you if a filesystem is case sensitive, and in any
> case that is irrelevant.  Think of the imaginary Windows-on-ext3 case
> where you'd still have Windows containing case-insensitive
> configuration paths, even if the filesystem is case-sensitive.
>

Bleargh. Let me start again on this one.

So I have 2 real objections here:

1. It's *really* ugly
2. It can be done automatically

So, let's say that some file on Windows has a well-defined location. 
Maybe it's some driver in system32 or something. The library user can't 
just use this location, they have to manually 'resolve' it first. It's 
the same case as getting a path from a config file, only less explicit. 
Either way, there's an ugly additional step required.

It's also an entirely guest OS specific api addition. I know we have 
others (SELinux, for eg), but that's no excuse to add more without 
trying very hard not to.

The alternative here, is to do 2 things:

1. Change the implementation of every existing API call which takes a 
Guest path to call the new path resolution function first.
2. Fix up the path resolution function so this is safe to do.

The first shouldn't be too hard because it's all auto-generated. The 
second should be hard to do either, because it's a relatively small 
change to your existing patch to make it check the filesystem type 
first, before deciding whether to be case-sensitive or case-insensitive.

The result is that reading a file out of a windows config file and then 
accessing it will Just Work, as will accessing a file with a 
well-defined path on Windows. The library user doesn't need to do 
anything extra, and there is no addition to the API.

Matt
-- 
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team

M:       +44 (0)7977 267231
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490




More information about the Libguestfs mailing list