[sandbox] non permanent '-H'

[Christoph A.]

Hi,

I like to run firefox instances where modifications to the profile are
not permanent but with the feature of permanently installed addons,
bookmarks, ...

To accomplish that one can start firefox via
sanbox -X -i ~/.mozilla ....
and it will simply work.

The problem arises if one would like to have different "templates"
sandbox -X -i ~/sandboxes/fftemplate1/.mozilla ...
sandbox -X -i ~/sandboxes/fftemplate2/.mozilla ...

this wont work because the path within the sandbox will also be
~/sandboxes/fftemp.... instead of ~/.mozilla

Is there a way to accomplish what I want?
Or is there something like -H needed with the difference that it
shouldn't store modifications?

kind regards,
Christoph A.
btw: I didn't find a way to tell firefox to look for the profile folder
at a different location.

[Christoph A.]

On 05/16/2011 12:57 AM, Christoph A. wrote:
>  Hi,
>  
>  I like to run firefox instances where modifications to the profile are
>  not permanent but with the feature of permanently installed addons,
>  bookmarks, ...
>  
>  To accomplish that one can start firefox via
>  sanbox -X -i ~/.mozilla ....
>  and it will simply work.
>  
>  The problem arises if one would like to have different "templates"
>  sandbox -X -i ~/sandboxes/fftemplate1/.mozilla ...
>  sandbox -X -i ~/sandboxes/fftemplate2/.mozilla ...
>  
>  this wont work because the path within the sandbox will also be
>  ~/sandboxes/fftemp.... instead of ~/.mozilla
>  
>  Is there a way to accomplish what I want?
>  Or is there something like -H needed with the difference that it
>  shouldn't store modifications? 
The solution would be:
The -i parameter should accept a second (optional) argument that
specifies the destination of the file copied into the sandbox.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/20/2011 09:47 AM, Christoph A. wrote:
>  On 05/16/2011 12:57 AM, Christoph A. wrote:
> > Hi,
> >
> > I like to run firefox instances where modifications to the profile are
> > not permanent but with the feature of permanently installed addons,
> > bookmarks, ...
> >
> > To accomplish that one can start firefox via
> > sanbox -X -i ~/.mozilla ....
> > and it will simply work.
> >
> > The problem arises if one would like to have different "templates"
> > sandbox -X -i ~/sandboxes/fftemplate1/.mozilla ...
> > sandbox -X -i ~/sandboxes/fftemplate2/.mozilla ...
> >
> > this wont work because the path within the sandbox will also be
> > ~/sandboxes/fftemp.... instead of ~/.mozilla
> >
> > Is there a way to accomplish what I want?
> > Or is there something like -H needed with the difference that it
> > shouldn't store modifications?
>
>  The solution would be:
>  The -i parameter should accept a second (optional) argument that
>  specifies the destination of the file copied into the sandbox.
>
>
>
>
>
>
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux 
I guess I would need a
syntax that would make sense.  Remember you can do

sandbox -X -i ~/.mozilla -i ~/.gnome ...

I guess you could use some syntax where the we had a separator, that
showed the destination directory

sandbox -X -i ~/.sandbox/ffftemplate1/.mozilla:~/.mozilla

But the separator would need to be something not likely to be in a file
system.


> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk3bq6oACgkQrlYvE4MpobOCSQCZAVkhqxk3fTBWylB0N7+g4Wgs
> n7QAn3bmXuM7BCfKyXF0lxqmZs1xBUxC
> =ABGM
> -----END PGP SIGNATURE-----

[sandbox] specifying the destination of '-i' files/dirs

[Christoph A.]

On 05/24/2011 02:59 PM, Daniel J Walsh wrote:
>  I guess I would need a syntax that would make sense.  Remember you
> can do
>  
>  sandbox -X -i ~/.mozilla -i ~/.gnome ...
>  
>  I guess you could use some syntax where the we had a separator, that
>  showed the destination directory
>  
>  sandbox -X -i ~/.sandbox/ffftemplate1/.mozilla:~/.mozilla
>  
>  But the separator would need to be something not likely to be in a file
>  system. 
Yes, I'm aware about the possibility of multiple '-i',
but I think it would still be possible to implement this without a
special separator. Though I have to admit that it won't be very nice ;)

sandbox -X -i ~/foo evince
(evince is the last argument and is therefore the cmd)

sandbox -X -i ~/a/b ~/b evince
(~/b is the destination)

sandbox -X -i ~/a/b/c ~/d  -i ~/f/c evince

is also clear.
Is there a risk of an ambiguous syntax?

One would have to implement a "collision detection" for cases like:
sandbox -X -i ~/a/b/c ~/c -i ~/c evince

I also thought about a change to the '-i' switch so that everything
would be copied to ~

example:
sandbox -X -i ~/a/b/c evince
would automatically copy ~/a/b/c to ~/c

but this behaviour would result in problems with commands like this:

sandbox -X -i ~/a/c -i ~/x/c evince
because two distinct files/folders would have the same destination.

[sandbox] specifying the destination of '-i' files/dirs

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/24/2011 09:17 AM, Christoph A. wrote:
>  On 05/24/2011 02:59 PM, Daniel J Walsh wrote:
> > I guess I would need a syntax that would make sense.  Remember you can do
> >
> > sandbox -X -i ~/.mozilla -i ~/.gnome ...
> >
> > I guess you could use some syntax where the we had a separator, that
> > showed the destination directory
> >
> > sandbox -X -i ~/.sandbox/ffftemplate1/.mozilla:~/.mozilla
> >
> > But the separator would need to be something not likely to be in a file
> > system.
>  
>  Yes, I'm aware about the possibility of multiple '-i',
>  but I think it would still be possible to implement this without a
>  special separator. Though I have to admit that it won't be very nice ;)
>  
>  sandbox -X -i ~/foo evince
>  (evince is the last argument and is therefore the cmd)
>  
>  sandbox -X -i ~/a/b ~/b evince
>  (~/b is the destination)
>  
>  sandbox -X -i ~/a/b/c ~/d  -i ~/f/c evince
>  
>  is also clear.
>  Is there a risk of an ambiguous syntax?
>  
>  One would have to implement a "collision detection" for cases like:
>  sandbox -X -i ~/a/b/c ~/c -i ~/c evince
>  
>  I also thought about a change to the '-i' switch so that everything
>  would be copied to ~
>  
>  example:
>  sandbox -X -i ~/a/b/c evince
>  would automatically copy ~/a/b/c to ~/c
>  
>  but this behaviour would result in problems with commands like this:
>  
>  sandbox -X -i ~/a/c -i ~/x/c evince
>  because two distinct files/folders would have the same destination.
>   
I guess I could live with

sandbox -X -i ~/a/b/c ~/d  -i ~/f/c evince

I would say

sandbox -X -i ~/a/b/c ~/c -i ~/c evince

Would copy the contents of both directories to ~/c within the sandbox.
then you don't need to worry about conflicts.


Patches welcome.  :^)

However if you could figure out why firefox no longer works within
matchbox-windowmanager and even fix it, I would send you a Red Hat.

:^)

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk3buCEACgkQrlYvE4MpobM3BQCaAlTnUhKMKDjF8IxpawU6jTzZ
> IfMAnRXvwePGDtf8hKJX7B51qQrhTZCy
> =A8o1
> -----END PGP SIGNATURE-----

[sandbox] specifying the destination of '-i' files/dirs

[Christoph A.]

On 05/24/2011 03:52 PM, Daniel J Walsh wrote:
>  I guess I could live with
>  
>  sandbox -X -i ~/a/b/c ~/d  -i ~/f/c evince
>  
>  I would say
>  
>  sandbox -X -i ~/a/b/c ~/c -i ~/c evince
>  
>  Would copy the contents of both directories to ~/c within the sandbox.
>  then you don't need to worry about conflicts. 
What if ~/a/b/c is a file and ~/c is a directory,
of what if ~/a/b/c and ~/c are both directories containing files with
the same name?
I would rather issue a warning and exit instead of trying to merge two
folders.

>  However if you could figure out why firefox no longer works within
>  matchbox-windowmanager and even fix it, I would send you a Red Hat. 
It doesn't work anymore for you?

[sandbox] specifying the destination of '-i' files/dirs

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/24/2011 10:08 AM, Christoph A. wrote:
>  On 05/24/2011 03:52 PM, Daniel J Walsh wrote:
> > I guess I could live with
> >
> > sandbox -X -i ~/a/b/c ~/d  -i ~/f/c evince
> >
> > I would say
> >
> > sandbox -X -i ~/a/b/c ~/c -i ~/c evince
> >
> > Would copy the contents of both directories to ~/c within the sandbox.
> > then you don't need to worry about conflicts.
>  
>  What if ~/a/b/c is a file and ~/c is a directory,
>  of what if ~/a/b/c and ~/c are both directories containing files with
>  the same name?
>  I would rather issue a warning and exit instead of trying to merge two
>  folders.
>   
Another option would be to allow the last one to win, but I guess we can
check if the destination is specified twice and throw an error.

> > However if you could figure out why firefox no longer works
> within
> > matchbox-windowmanager and even fix it, I would send you a Red Hat.
>  
>  It doesn't work anymore for you?
>   
No I get a black screen.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk3bvP8ACgkQrlYvE4MpobM+ggCfT6nn58+im9dpdRtWyjOd6rPV
> jiIAoNes6IvoWaEF52ofRRndra+svvid
> =GbVy
> -----END PGP SIGNATURE-----

[Genes MailLists]

On 05/24/2011 08:59 AM, Daniel J Walsh wrote:


 On a (somewhat) related not - have you managed to make any progress
with google-chrome being able to run in sandbox ?

 thanks!

  gene

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/24/2011 10:48 AM, Genes MailLists wrote:
>  On 05/24/2011 08:59 AM, Daniel J Walsh wrote:
>  
>  
>   On a (somewhat) related not - have you managed to make any progress
>  with google-chrome being able to run in sandbox ?
>  
>   thanks!
>  
>    gene
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux
>  
>   
Well chromium-browser is complaining about

Failed to more to new PID namespace: Operation not permitted

Even in permissive mode.  I guess the problem is that chromium can not
run within a sandbox.

If you execute

mkdir -P ~/sandbox/tmp
mkdir -P ~/sandbox/home
seunshare -t ~/sandbox/tmp -h ~/sandbox/home -- /usr/bin/chromium-browser

You will get the error.

I am not sure you can clone within a clone...
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk3by+wACgkQrlYvE4MpobNduQCgkGwD007Qlnst0Jvdj5pjlt8a
> bNEAn03esa1U6DO0Fo+RVIXNXh86TOCL
> =W+2D
> -----END PGP SIGNATURE-----

[Genes MailLists]

On 05/24/2011 11:17 AM, Daniel J Walsh wrote:

>  Well chromium-browser is complaining about
>  
>  Failed to more to new PID namespace: Operation not permitted
>  
>  Even in permissive mode.  I guess the problem is that chromium can not
>  run within a sandbox.
>  
>  If you execute
>  
>  mkdir -P ~/sandbox/tmp
>  mkdir -P ~/sandbox/home
>  seunshare -t ~/sandbox/tmp -h ~/sandbox/home -- /usr/bin/chromium-browser
>  
>  You will get the error.
>  
>  I am not sure you can clone within a clone...
>  -- 
>   

  Right it doesn't work for sure - I had vague recollections someone
(you I think?) saying they might try touch base with the google folks
about co-coordinating to try make selinux sandbox work .. that was a few
months ago ... but dont remember when exactly ...

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/24/2011 11:33 AM, Genes MailLists wrote:
>  On 05/24/2011 11:17 AM, Daniel J Walsh wrote:
>  
> > Well chromium-browser is complaining about
> >
> > Failed to more to new PID namespace: Operation not permitted
> >
> > Even in permissive mode.  I guess the problem is that chromium can not
> > run within a sandbox.
> >
> > If you execute
> >
> > mkdir -P ~/sandbox/tmp
> > mkdir -P ~/sandbox/home
> > seunshare -t ~/sandbox/tmp -h ~/sandbox/home -- /usr/bin/chromium-browser
> >
> > You will get the error.
> >
> > I am not sure you can clone within a clone...
> > --
>  
> >
>  
>  
>    Right it doesn't work for sure - I had vague recollections someone
>  (you I think?) saying they might try touch base with the google folks
>  about co-coordinating to try make selinux sandbox work .. that was a few
>  months ago ... but dont remember when exactly ...
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux 
Basically it looks like the clone call within the chromium-browser is
failing.

I have a feeling this has something to do wit seunshare calling

unshare(CLONE_NEWNS);

And then later chromium calling

clone(...)


> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk3b0GEACgkQrlYvE4MpobNMUQCgqj7qTg47ZWhCUoMQ5laIR73d
> EAUAoJ806vPuMvfv2zdvWwOYF/Tuh4Q5
> =OlNj
> -----END PGP SIGNATURE-----

[mike cloaked]

On Tue, May 24, 2011 at 4:36 PM, Daniel J Walsh <dwalsh(a)redhat.com&gt; wrote:

>  Basically it looks like the clone call within the chromium-browser
> is
>  failing.
>
>  I have a feeling this has something to do wit seunshare calling
>
>  unshare(CLONE_NEWNS);
>
>  And then later chromium calling
>
>  clone(...)
>  
I know this is a chromium discussion but does the same apply to chrome?
-- 
mike c

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/24/2011 11:44 AM, mike cloaked wrote:
>  On Tue, May 24, 2011 at 4:36 PM, Daniel J Walsh
> <dwalsh(a)redhat.com&gt; wrote:
>  
> > Basically it looks like the clone call within the chromium-browser is
> > failing.
> >
> > I have a feeling this has something to do wit seunshare calling
> >
> > unshare(CLONE_NEWNS);
> >
> > And then later chromium calling
> >
> > clone(...)
> >
>  
>  I know this is a chromium discussion but does the same apply to chrome? 
I would
think they are the same.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk3b8fMACgkQrlYvE4MpobM9YQCfRusVoLEvYZaTxHAQU4PRljMn
> ooUAoOorHSE4A86tGTuYIEYqEW1sYzhy
> =RYPe
> -----END PGP SIGNATURE-----