On 06/11/2017 16:14, Michael Fritscher wrote:
> The main thing was the question whether to make a sort of "hack" to
> emulate the *at commands (which is the way used by the patch, the main
> idea using /proc//fd information) or make a 9pfs_local_windows
> variant which uses the native ntdll api. Wh
Hi,
> Sorry for the late reply... Since I have only limited bandwidth, I'll only
> be able to provide some limited feedback.
No problem!
>
> A global remark to start with: it is a usual practice to prefix each patch
> title with the component's name, as explained here:
>
> https://wiki.qemu.org/C
On Fri, 29 Sep 2017 13:13:05 +0200
Michael Fritscher wrote:
> Good day,
>
Hi,
Sorry for the late reply... Since I have only limited bandwidth, I'll only
be able to provide some limited feedback.
A global remark to start with: it is a usual practice to prefix each patch
title with the componen
>> I see one thing: symlinks somewhere in the path (which seemed to be the
>> reason introducing the *at family). But I think that this can be handled
>> by canonlizing the path, too. realpath should do the job quite well.
>>
>
> Unfortunately now because we have TOCTOU condition here: some path el
On 15.10.2017 21:50, Greg Kurz wrote:
>> Hi again,
>>
>> I see one thing: symlinks somewhere in the path (which seemed to be the
>> reason introducing the *at family). But I think that this can be handled
>> by canonlizing the path, too. realpath should do the job quite well.
>>
>
> Unfortunately
On Sun, 15 Oct 2017 21:13:34 +0200
"Michael Fritscher" wrote:
> >
> > Hi,
> >
> > dumb question: what is the advantage of openat vs. open - only the thing
> > that someone doesn't need to build the path together by hand?
> >
> > If I understand the man page of openat correctly, it does _not_ prev
On Sun, 15 Oct 2017 21:02:56 +0200
"Michael Fritscher" wrote:
> > On 29/09/2017 16:14, Michael Fritscher wrote:
> >>> Yes, that's pretty much the only way to do it; it's not the easiest
> >>> thing because you have to use NT kernel APIs (NtCreateFile) rather than
> >>> e.g. CreateFile. Likewis
>
> Hi,
>
> dumb question: what is the advantage of openat vs. open - only the thing
> that someone doesn't need to build the path together by hand?
>
> If I understand the man page of openat correctly, it does _not_ prevent
> someone to break out of the jail by using e.g. ../../../blah .
> If this
> On 29/09/2017 16:14, Michael Fritscher wrote:
>>> Yes, that's pretty much the only way to do it; it's not the easiest
>>> thing because you have to use NT kernel APIs (NtCreateFile) rather than
>>> e.g. CreateFile. Likewise for NtQueryAttributesFile,
>>> NtQueryDirectoryObject, etc. NtOpenDirect
