On Sun, 15 Oct 2017 21:02:56 +0200 "Michael Fritscher" <mich...@fritscher.net> 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. Likewise for NtQueryAttributesFile, > >>> NtQueryDirectoryObject, etc. NtOpenDirectoryObject. :( > >>> > >>> Paolo > >>> > >> Hi, > >> > >> why do I need the NT* functions instead of the "normal" ones from > >> kernel32? And it was working even with the posix functions some time ago > >> (Which I'll port to current qemu atm) > > > > openat lets you create a file from a directory handle and relative path. > > CreateFile doesn't let you do that, only the ntdll functions can. > > > > Paolo > > > > Hi, > 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 . Look at v9fs_walk(): if (not_same_qid(&pdu->s->root_qid, &qid) || strcmp("..", wnames[name_idx].data)) { err = v9fs_co_name_to_path(pdu, &dpath, wnames[name_idx].data, &path); If we have reached the jail root and the path element is "..", we skip it, ie, it isn't possible to go beyond the jail root. Cheers, -- Greg > If this assumption is correctly perhaps it is better to avoid using the > *at function family (as it was some time ago) and sanitize the path (by > somehow canonizing it and than check if the beginning is ok). > > Then I could use the "normal" posix function again and avoid using the NT* > Functions directly which is not soooo nice for various reasons. > > Best regards, > Michael Fritscher >