Mounting regular files without passing them as untrusted args

[rampage644]

I'd like to propose a feature to pass files from host filesystem (just as with @somefile) but without passing its untrusted filename as untrusted argument.

For example: zvsh some.nexe @file1 @file2 @file3. Right now zvsh will create three channels (/dev/1.file1, /dev/2.file2, /dev/3.file3) and pass their untrusted paths as command line arguments.

It would be handy to somehow mark files just to mount. Like this: zvsh some.nexe @file1,<flag-for-only-mount>.

I faced with need of this feature already :) What do you think?

[mgeisler]

What does it mean to "just mount" a file? How is this different from using --zvm-image?

[rampage644]

It's exactly the same as --zvm-image. But in case of mounting tar its filename doesn't go to argument list.

[larsbutler]

I thought --zvm-image was intended for tar files. In fact, it seems that zvsh will try to treat each --zvm-image as a tar, always.

[mgeisler]

Okay... I'm still not sure I understand exactly what you mean :-) You want

$ zvsh some.nexe @foo,only-mount

to result in the tar file foo being mounted as an image and then you want what path to be passed to the nexe inside ZeroVM?

[mgeisler]

I asked Lars what you mean and he suggested that the issue could be reformulated to this:

Today,

zvsh some.nexe @file1 @file2 @file3

will result in a command line like this inside the sandbox:

some.nexe /dev/1.file1 /dev/2.file2 /dev/3.file3

The paths are translated from the host OS into the corresponding paths inside the sandbox.

It would be handy to somehow specify where the files should be mounted. Like this:

zvsh some.nexe @file1,/etc/foo

This should result in file1 being made available at /etc/foo inside the sandbox and the nexe should be started as

some.nexe /etc/foo

@rampage644 Does this make sense?

[pkit]

When we do tar mount for FS instead of channels all of that will be irrelevant.
So, let's just wait for that feature. Yaroslav actually fixed some bugs that prevented us from using tars.

[pkit]

see #36

[rampage644]

@mgeisler Almost. All i want is to be able to run zvsh some.nexe @file,<only-mount> and have nexe started as some.nexe. Just without arguments.

See? no /dev/1.file in command line. That what I want.

[rampage644]

@pkit, how would #36 address command line arguments? As for me, putting everything in tar is just a matter of implementation of some feature that only could affect, but not necessary. Am I wrong?

[larsbutler]

In that case, I wouldn't recommend using the @ syntax for this. Instead, I would add a new command line flag, similar in function to --zvm-image, something like --mount-file file,mount-point.

On 22 Apr 2014, at 17:32, Sergei Turukin [email protected] wrote:

@mgeisler Almost. All i want is to be able to run zvsh some.nexe @file, and have nexe started as some.nexe. Just without arguments.

See? no /dev/1.file in command line. That what I want.

—
Reply to this email directly or view it on GitHub.

[pkit]

@rampage644 why do you need to add files to session that were not explicitly stated in the command line? What is the use case?

[rampage644]

@pkit which command line are you talking about? zvsh one? or untrusted sided?

• zvsh one. I'm not saying i want to mount files that are not stated here.
• untrusted side. Why do i ever want to pass every file as command line argument? I could easily read/stat/whatever some hard-coded file. That what i want. Or just mimic zerocloud middleware: pass /dev/input and /dev/output into untrusted side without polluting nexe's command line.

@larsbutler, totally agree. I would prefer adding new option like --mount-file for regular files as --zvm-image for tar's. But we still may have @ with simpilfied syntax.

[larsbutler]

@rampage644

I would prefer adding new option like --mount-file for regular files as --zvm-image for tar's. But we still may have @ with simpilfied syntax.

Personally, I don't think the @ syntax is simplified, but maybe it's just me. =) If you want something some short and concise, we could instead make an alias for the --mount-file flag; something like -m. So instead of this:

zvsh some.nexe @file.txt,<only-mount>

You would have this:

zvsh --mount-file file.txt some.nexe
or
zvsh -m file.txt some.nexe

What do you think about that?

[rampage644]

I think this option would simplify source code a little (or not a little?). I see no real difference in using @ or -m/--mount, so if i should have a choice, i will change the syntax.

[larsbutler]

@rampage644

The code (in my proposed branch #31 ) which processes all of these args is here: https://github.com/zerovm/zerovm-cli/pull/31/files#diff-223caf4ea7215230ce53fe9e09425fa8R874

Assuming the change is based on my branch, it might not really make a difference how you implement it (in terms of complexity of the code change), but I think that overloading the @ syntax with even more functionality is not the way to go, especially since it is entirely undocumented so far in the zvsh --help! I'm afraid that this will confuse users. I think adding a new explicit flag --mount-image / -m (or whatever) is a cleaner approach.

With your suggestion, an argument prefixed with @ would mean three things:

• environment variable, discarded from the untrusted args
• single file channel, replaced with a channel alias for use in the untrusted args
• single file channel, discarded from the untrusted args

In my opinion that's too many orthogonal concepts for a single symbol @.

@pkit @mgeisler What do you guys think?

[rampage644]

As for me, i totally agree that syntax should be as much cleaner as possible. For example, I didn't even know about @ENV possiblity until i opened source code! =)

[larsbutler]

@rampage644 Same here; I only learned about it last week when I re-writing that part of the code. =P

[pkit]

@rampage644
I still do not understand a use case.
argv is an array, usually programs that hardcode things do not read it.
So, just add the needed file to a command line, and then everybody will be happy.

Regarding @ syntax, there was no documentation about it ever. But the idea is simple: any command line argument that starts with @ is a host thing that is passed to the sandbox.

[mgeisler]

Lars Butler [email protected] writes:

Assuming the change is based on my branch,

I think we should take care not to let branches be based on each other.
First, it entangles concerns: we use branches so we can keep separated
things separate. We can merge either branch without having to deal with
the other and that's important.

Second, if Sergei bases code on your branch, you're suddenly restricted
in how you can treat your branch -- what you think is work in progress,
now becomes fixed. This hampers you ability to respond to review
comments or to simply change your mind :-)

With your suggestion, an argument prefixed with @ would mean three
things:

• environment variable, discarded from the untrusted args
• single file channel, replaced with a channel alias for use in the
  untrusted args
• single file channel, discarded from the untrusted args

In my opinion that's too many orthogonal concepts for a single symbol
@.

Yes, I agree. I think it's useful to use @foo to do these two things:

• setup a device for foo on the inside of the sandbox
• pass the path of this device in argv of the nexe

That's a common usecase and the solution is fairly elegant (except that
I don't think you can escape the @).

I like the idea of giving zvsh a -m flag for mounting other files
without necessarily passing them on the command line. With a -m,

zvsh some.nexe @foo

could be seen as the same as

zvsh -m foo some.nexe /dev/foo

if the foo file appears as the /dev/foo device in the sandbox.

Martin Geisler

[rampage644]

argv is an array, usually programs that hardcode things do not read it.

We shouldn't assume how programs are written.

So, just add the needed file to a command line, and then everybody will be happy.

That will work, but what if my program uses argv? Parses it?

Please, don't ask to list projects that will need this feature. We're discussing it longer than it will take to implement it. What's your point? Implement same logic through exporting tar via #36?

[pkit]

@rampage644
Yep, I would like to implement all the "let's bring some parts of host fs with me" approach with the tar import/export in #36

[larsbutler]

@mgeisler

Assuming the change is based on my branch,

I think we should take care not to let branches be based on each other.
First, it entangles concerns: we use branches so we can keep separated
things separate. We can merge either branch without having to deal with
the other and that's important.

Second, if Sergei bases code on your branch, you're suddenly restricted
in how you can treat your branch -- what you think is work in progress,
now becomes fixed. This hampers you ability to respond to review
comments or to simply change your mind :-)

Actually, it's a pretty safe assumption based on this: #34 (comment)

And as far I can tell, my branch will be accepted once @pkit has written some functional tests and checked that all functions are implemented correctly. Of course he can correct me if I'm wrong. =)

[mgeisler]

Lars Butler [email protected] writes:

Assuming the change is based on my branch,

I think we should take care not to let branches be based on each
other. First, it entangles concerns: we use branches so we can keep
separated things separate. We can merge either branch without having
to deal with the other and that's important.

Second, if Sergei bases code on your branch, you're suddenly
restricted in how you can treat your branch -- what you think is work
in progress, now becomes fixed. This hampers you ability to respond
to review comments or to simply change your mind :-)

Actually, it's a pretty safe assumption based on this:
#34 (comment)

I saw that comment -- and I don't agree completely with it :)

It is a normal and workflow to let the small branches go in and then
continiously rebase the big branches on top of the underlying churn.
That way nobody is blocked by reviews taking place for the big branch.

Martin Geisler