Is it possible to define the root directory in a cross compiled program

Is it possible to define the root directory in a cross compiled program

[Roger Kaufman]

When I cross compile the following program, opening /dev/null fails and 
instead the whole install path of /cygwin64/dev/null is visible.

Is there a way to make fopen respect / as the root directory in a cross 
compiled program for windows?

example output...

Roger@interocitor:~
$ x86_64-w64-mingw32-g++ -o writenull.exe write2null.cc

Roger@interocitor:~
$ writenull.exe
/dev/null did not succeed


Roger@interocitor:~
$ gcc -o writenull write2null.cc

Roger@interocitor:~
$ writenull
/cygwin64/dev/null did not succeed


C Code that was compiled...

#include <cstdio>

int main(int argc, char **argv)
{
   FILE *errfile1 = fopen("/dev/null", "w");
   if (!errfile1) // must be a valid pointer
     errfile1 = stderr;

   FILE *errfile2 = fopen("/cygwin64/dev/null", "w");
   if (!errfile2) // must be a valid pointer
     errfile2 = stderr;

   fprintf(errfile1, "/dev/null did not succeed\n");
   fprintf(errfile2, "/cygwin64/dev/null did not succeed\n");

   return 0;
}

Re: Is it possible to define the root directory in a cross compiled program

[Brian Inglis]

On 2021-01-04 18:34, Roger Kaufman wrote:
> When I cross compile the following program, opening /dev/null fails and instead 
> the whole install path of /cygwin64/dev/null is visible.
> 
> Is there a way to make fopen respect / as the root directory in a cross compiled 
> program for windows?
> 
> example output...
> 
> Roger@interocitor:~
> $ x86_64-w64-mingw32-g++ -o writenull.exe write2null.cc
> 
> Roger@interocitor:~
> $ writenull.exe
> /dev/null did not succeed
> 
> Roger@interocitor:~
> $ gcc -o writenull write2null.cc
> 
> Roger@interocitor:~
> $ writenull
> /cygwin64/dev/null did not succeed
> 
> C Code that was compiled...
> 
> #include <cstdio>
> 
> int main(int argc, char **argv)
> {
>    FILE *errfile1 = fopen("/dev/null", "w");
>    if (!errfile1) // must be a valid pointer
>      errfile1 = stderr;
> 
>    FILE *errfile2 = fopen("/cygwin64/dev/null", "w");
>    if (!errfile2) // must be a valid pointer
>      errfile2 = stderr;
> 
>    fprintf(errfile1, "/dev/null did not succeed\n");
>    fprintf(errfile2, "/cygwin64/dev/null did not succeed\n");
> 
>    return 0;
> }

It's a Windows program - it can do whatever you program it to do!
On Windows the device is NUL, the root is the drive root C:\,
and anything else depends on the Windows subsystem.

To do otherwise you have to program it to emulate the Cygwin emulation,
or build it as a Cygwin program using the Cygwin toolchain.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: Is it possible to define the root directory in a cross compiled program

[Eliot Moss]

On 1/4/2021 10:17 PM, Brian Inglis wrote:
> On 2021-01-04 18:34, Roger Kaufman wrote:
>> When I cross compile the following program, opening /dev/null fails and instead the whole install 
>> path of /cygwin64/dev/null is visible.
>>
>> Is there a way to make fopen respect / as the root directory in a cross compiled program for windows?
>>
>> example output...
>>
>> Roger@interocitor:~
>> $ x86_64-w64-mingw32-g++ -o writenull.exe write2null.cc
>>
>> Roger@interocitor:~
>> $ writenull.exe
>> /dev/null did not succeed
>>
>> Roger@interocitor:~
>> $ gcc -o writenull write2null.cc
>>
>> Roger@interocitor:~
>> $ writenull
>> /cygwin64/dev/null did not succeed
>>
>> C Code that was compiled...
>>
>> #include <cstdio>
>>
>> int main(int argc, char **argv)
>> {
>>    FILE *errfile1 = fopen("/dev/null", "w");
>>    if (!errfile1) // must be a valid pointer
>>      errfile1 = stderr;
>>
>>    FILE *errfile2 = fopen("/cygwin64/dev/null", "w");
>>    if (!errfile2) // must be a valid pointer
>>      errfile2 = stderr;
>>
>>    fprintf(errfile1, "/dev/null did not succeed\n");
>>    fprintf(errfile2, "/cygwin64/dev/null did not succeed\n");
>>
>>    return 0;
>> }
> 
> It's a Windows program - it can do whatever you program it to do!
> On Windows the device is NUL, the root is the drive root C:\,
> and anything else depends on the Windows subsystem.
> 
> To do otherwise you have to program it to emulate the Cygwin emulation,
> or build it as a Cygwin program using the Cygwin toolchain.

Is there a Windows equivalent to chroot (either the program or the library/system call)?

Regards - Eliot

Re: Is it possible to define the root directory in a cross compiled program

[Bill Stewart]

On Tue, Jan 5, 2021 at 6:34 AM Eliot Moss wrote:

> Is there a Windows equivalent to chroot (either the program or the library/system call)?

See: https://cygwin.com/cygwin-ug-net/highlights.html

Quoting:

"Chroot is supported. Kind of. Chroot is not a concept known by
Windows. This implies some serious restrictions. First of all, the
chroot call isn't a privileged call. Any user may call it. Second, the
chroot environment isn't safe against native windows processes. Given
that, chroot in Cygwin is only a hack which pretends security where
there is none. For that reason the usage of chroot is discouraged.
Don't use it unless you really, really know what you're doing."

What I have found is that the cygwin chroot is not a security boundary
(it seems it is possible for an account to "escape" from the "chroot
jail"). However, whatever account is being used by the cygwin process
is still subject to its rights/permissions in Windows (i.e.,
"escaping" from a "chroot jail" does not give additional rights and/or
permissions to an account that it didn't have before).

Bill

Re: Is it possible to define the root directory in a cross compiled program

[Eliot Moss]

On 1/5/2021 10:02 AM, Bill Stewart wrote:
 > On Tue, Jan 5, 2021 at 6:34 AM Eliot Moss wrote:
 >
 >> Is there a Windows equivalent to chroot (either the program or the library/system call)?
 >
 > See: https://cygwin.com/cygwin-ug-net/highlights.html
 >
 > Quoting:
 >
 > "Chroot is supported. Kind of. Chroot is not a concept known by
 > Windows. This implies some serious restrictions. First of all, the
 > chroot call isn't a privileged call. Any user may call it. Second, the
 > chroot environment isn't safe against native windows processes. Given
 > that, chroot in Cygwin is only a hack which pretends security where
 > there is none. For that reason the usage of chroot is discouraged.
 > Don't use it unless you really, really know what you're doing."
 >
 > What I have found is that the cygwin chroot is not a security boundary

Right.  My impression was that the OP was more interested in having the
functionality of where / is, though I could be wrong, of course.

I also saw web posts about Windows' RUNAS command, which deals with some of
the security implications, but does not re-root your file hierarchy.

Best - Eliot

Re: Is it possible to define the root directory in a cross compiled program

[Roger Kaufman]

Hi All,

> On 1/5/2021 10:02 AM, Bill Stewart wrote:
> > On Tue, Jan 5, 2021 at 6:34 AM Eliot Moss wrote:
> >
> >> Is there a Windows equivalent to chroot (either the program or the 
> library/system call)?
> >
> > See: https://cygwin.com/cygwin-ug-net/highlights.html
> >
> > Quoting:
> >
> > "Chroot is supported. Kind of. Chroot is not a concept known by
> > Windows. This implies some serious restrictions. First of all, the
> > chroot call isn't a privileged call. Any user may call it. Second, the
> > chroot environment isn't safe against native windows processes. Given
> > that, chroot in Cygwin is only a hack which pretends security where
> > there is none. For that reason the usage of chroot is discouraged.
> > Don't use it unless you really, really know what you're doing."
> >
> > What I have found is that the cygwin chroot is not a security boundary
>
> Right.  My impression was that the OP was more interested in having the
> functionality of where / is, though I could be wrong, of course.
>
> I also saw web posts about Windows' RUNAS command, which deals with 
> some of
> the security implications, but does not re-root your file hierarchy.
>
> Best - Eliot 

This is the OP. We can close this out. Brian Inglis mentioned the 
Windows /dev/null is "nul"
and so that solved the problem in this case. In the code below, both 
fopen's succeed
when compiled with gcc and the "nul" fopen succeeds when cross compiled with
x86_64-w64-mingw32-g++

The backstory is, I cross compile because I have code only compatible 
when cross
compiled. However, I run the code in the bash shell. Now in the bash 
shell, I can't change
directory higher than / which is expected (I know of cygdrive/c of course)

However since it is now technically a windows  program it can "see out" 
into the
file system. I have for that program, an environment variable path I 
also have to prefix e.g.
/cygwin64/home... its just something I have to live with. But it does 
make portability
imperfect as the same code compiles in Linux.

#include <cstdio>

int main(int argc, char **argv)
{
   FILE *errfile1 = fopen("/dev/null", "w");
   if (!errfile1) // must be a valid pointer
     errfile1 = stderr;

   FILE *errfile2 = fopen("nul", "w");
   if (!errfile2) // must be a valid pointer
     errfile2 = stderr;

   fprintf(errfile1, "/dev/null did not succeed\n");
   fprintf(errfile2, "nul did not succeed\n");

   return 0;
}

Roger

Re: Is it possible to define the root directory in a cross compiled program

[Brian Inglis]

On 2021-01-05 09:49, Roger Kaufman wrote:
>> On 1/5/2021 10:02 AM, Bill Stewart wrote:
>> > On Tue, Jan 5, 2021 at 6:34 AM Eliot Moss wrote:
>> >
>> >> Is there a Windows equivalent to chroot (either the program or the 
>> library/system call)?
>> >
>> > See: https://cygwin.com/cygwin-ug-net/highlights.html
>> >
>> > Quoting:
>> >
>> > "Chroot is supported. Kind of. Chroot is not a concept known by
>> > Windows. This implies some serious restrictions. First of all, the
>> > chroot call isn't a privileged call. Any user may call it. Second, the
>> > chroot environment isn't safe against native windows processes. Given
>> > that, chroot in Cygwin is only a hack which pretends security where
>> > there is none. For that reason the usage of chroot is discouraged.
>> > Don't use it unless you really, really know what you're doing."
>> >
>> > What I have found is that the cygwin chroot is not a security boundary
>>
>> Right.  My impression was that the OP was more interested in having the
>> functionality of where / is, though I could be wrong, of course.
>>
>> I also saw web posts about Windows' RUNAS command, which deals with some of
>> the security implications, but does not re-root your file hierarchy.

> This is the OP. We can close this out. Brian Inglis mentioned the Windows 
> /dev/null is "nul" and so that solved the problem in this case. In the code
> below, both fopen's succeed when compiled with gcc and the "nul" fopen
> succeeds when cross compiled with x86_64-w64-mingw32-g++
> 
> The backstory is, I cross compile because I have code only compatible when
> cross compiled. However, I run the code in the bash shell. Now in the bash
> shell, I can't change directory higher than / which is expected (I know of
> cygdrive/c of course)
> 
> However since it is now technically a windows  program it can "see out" into
> the file system. I have for that program, an environment variable path I also
> have to prefix e.g. /cygwin64/home... its just something I have to live with.
> But it does make portability imperfect as the same code compiles in Linux. >
> #include <cstdio>

You can adapt at runtime to the OS, check which device and root path exists 
(good programming practices anyway) as a default, and override if env var exists 
and includes a valid path which is also safe, or conditionally compile to 
hardwire included or excluded behaviour, with the same portable source: SMOP.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: Is it possible to define the root directory in a cross compiled program

[Andrey Repin]

Greetings, Brian Inglis!

> On 2021-01-04 18:34, Roger Kaufman wrote:
>> When I cross compile the following program, opening /dev/null fails and instead 
>> the whole install path of /cygwin64/dev/null is visible.
>> 
>> Is there a way to make fopen respect / as the root directory in a cross compiled 
>> program for windows?
>> 
>> example output...
>> 
>> Roger@interocitor:~
>> $ x86_64-w64-mingw32-g++ -o writenull.exe write2null.cc
>> 
>> Roger@interocitor:~
>> $ writenull.exe
>> /dev/null did not succeed
>> 
>> Roger@interocitor:~
>> $ gcc -o writenull write2null.cc
>> 
>> Roger@interocitor:~
>> $ writenull
>> /cygwin64/dev/null did not succeed
>> 
>> C Code that was compiled...
>> 
>> #include <cstdio>
>> 
>> int main(int argc, char **argv)
>> {
>>    FILE *errfile1 = fopen("/dev/null", "w");
>>    if (!errfile1) // must be a valid pointer
>>      errfile1 = stderr;
>> 
>>    FILE *errfile2 = fopen("/cygwin64/dev/null", "w");
>>    if (!errfile2) // must be a valid pointer
>>      errfile2 = stderr;
>> 
>>    fprintf(errfile1, "/dev/null did not succeed\n");
>>    fprintf(errfile2, "/cygwin64/dev/null did not succeed\n");
>> 
>>    return 0;
>> }

> It's a Windows program - it can do whatever you program it to do!
> On Windows the device is NUL, the root is the drive root C:\,

%SystemDrive%\ to be precise. Even though it IS C:\ in majority of cases, it
is not necessarily true all the time.

> and anything else depends on the Windows subsystem.

> To do otherwise you have to program it to emulate the Cygwin emulation,
> or build it as a Cygwin program using the Cygwin toolchain.



-- 
With best regards,
Andrey Repin
Wednesday, January 6, 2021 0:03:57

Sorry for my terrible english...

Re: Is it possible to define the root directory in a cross compiled program

[Hans-Bernhard Bröker]

Am 05.01.2021 um 22:04 schrieb Andrey Repin:
>> It's a Windows program - it can do whatever you program it to do!
>> On Windows the device is NUL, the root is the drive root C:\,
> 
> %SystemDrive%\ to be precise. 

Well, since we're being precise: no.

%SystemDrive%\ is the root of the drive the system is on.  That's not 
"the" root any more than c:\, \ or any other such thing.

The actual answer would be: no DOS-style path (i.e. neither c:\ nor \) 
can be usefully called "the" root on a Windows machine.

The closest to an actual root on a Windows system would be something 
like \\?\ or \\.\