Topic: N3940: Injectability of filesystem access and


Author: Jonas Persson <l.j.persson@gmail.com>
Date: Tue, 28 Apr 2015 17:19:08 +0200
Raw View
--e89a8f3ba349521f460514ca62ac
Content-Type: text/plain; charset=UTF-8

There was a proposal on boost last year about making filesystem more
generic. I think his solution might be interesting for your use case too.
http://lists.boost.org/Archives/boost/2014/01/210470.php

  /Jonas

On Tue, Apr 28, 2015 at 3:34 PM, Ed Schouten <ed@nuxi.nl> wrote:

> Hello everyone,
>
> Earlier today I got pointed to proposal N3940, which attempts to
> extend the C++ standard library with filesystem access routines. While
> reading through the proposal and its list of issues (N4096), I thought
> I should get in touch to express my concerns.
>
> Over the last couple of years there has been a lot of development in
> the area of capability-based security. The University of Cambridge
> Computer Laboratory has developed a system called Capsicum [1] that is
> part of FreeBSD and in the process of being merged into Linux. My
> company, Nuxi, is working on a cross-platform computing environment
> called CloudABI that can be used to develop secure, sandboxed
> UNIX-like applications [2].
>
> The intent behind Capsicum and CloudABI is that applications can only
> access resources by using a capability -- a token. There is no global
> namespace. The filesystem can only be accessed through handles that
> only expose (parts of) the filesystem namespace. More concretely, it
> means that the following construct is not permitted when using
> Capsicum:
>
> int fd = open("/etc/passwd", O_RDONLY);
>
> The following construct, however, is allowed, assuming some_directory
> is a file descriptor to an open directory:
>
> int fd = openat(some_directory, "my/file.txt", O_RDONLY);
>
> The idea is that this method allows you to programmatically determine
> which actions an application is allowed to perform. For example, a
> simple web server may only possess a file descriptor to its web root
> directory during execution, meaning its access is restricted to just
> the files it should serve through the web.
>
> This is good from a security point-of-view. It allows software
> developers to reduce the impact of a security vulnerability without
> requiring a complex static set of rules to be provided up front (say,
> like AppArmor). Another advantage is that software becomes easier to
> test. Different parts of the filesystem are used if a program is
> invoked with a different set of file descriptors. System testing of
> applications may become trivial.
>
> The reason why I'm getting in touch is that the interfaces described
> in N3940 seems to have complete disregard for separate filesystem
> namespaces. It assumes that the system only provides a single global
> filesystem namespace. It looks like an almost direct mapping to POSIX
> prior to the 2008 edition. If applications are built on top of this
> interface, they will be hard to adapt to systems that use Capsicum.
>
> I would strongly suggest that all of the global functions are placed
> in a separate 'class filesystem'. By default there would only be a
> single instance that attempts to access the global filesystem
> namespace. If an implementation supports the POSIX 2008 interface, it
> may provide extensions to construct filesystem instances based on file
> descriptors to directories.
>
> This would also address the issues raised in comment #54 in N4096,
> raised by Google (who also happened to fund the development of
> Capsicum). It could permit filesystem access that is less prone to
> race-conditions, but also make it possible to construct artificial
> filesystems as part of unit tests.
>
> I hope that concerns in this area can be addressed before
> standardization, as right now this proposal would negatively affect
> projects like Capsicum and CloudABI. If needed, I am willing to help
> out.
>
> Relevant links:
>
> [1] Capsicum: http://www.cl.cam.ac.uk/research/security/capsicum/
> [2] Nuxi CloudABI: https://github.com/NuxiNL/cloudlibc
>
> Best regards,
> --
> Ed Schouten <ed@nuxi.nl>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--e89a8f3ba349521f460514ca62ac
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">There was a proposal on boost last year about making files=
ystem more generic. I think his solution might be interesting for your use =
case too.<div><a href=3D"http://lists.boost.org/Archives/boost/2014/01/2104=
70.php">http://lists.boost.org/Archives/boost/2014/01/210470.php</a></div><=
div><br></div><div>=C2=A0 /Jonas</div></div><div class=3D"gmail_extra"><br>=
<div class=3D"gmail_quote">On Tue, Apr 28, 2015 at 3:34 PM, Ed Schouten <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:ed@nuxi.nl" target=3D"_blank">ed@nuxi.=
nl</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello everyone,<=
br>
<br>
Earlier today I got pointed to proposal N3940, which attempts to<br>
extend the C++ standard library with filesystem access routines. While<br>
reading through the proposal and its list of issues (N4096), I thought<br>
I should get in touch to express my concerns.<br>
<br>
Over the last couple of years there has been a lot of development in<br>
the area of capability-based security. The University of Cambridge<br>
Computer Laboratory has developed a system called Capsicum [1] that is<br>
part of FreeBSD and in the process of being merged into Linux. My<br>
company, Nuxi, is working on a cross-platform computing environment<br>
called CloudABI that can be used to develop secure, sandboxed<br>
UNIX-like applications [2].<br>
<br>
The intent behind Capsicum and CloudABI is that applications can only<br>
access resources by using a capability -- a token. There is no global<br>
namespace. The filesystem can only be accessed through handles that<br>
only expose (parts of) the filesystem namespace. More concretely, it<br>
means that the following construct is not permitted when using<br>
Capsicum:<br>
<br>
int fd =3D open(&quot;/etc/passwd&quot;, O_RDONLY);<br>
<br>
The following construct, however, is allowed, assuming some_directory<br>
is a file descriptor to an open directory:<br>
<br>
int fd =3D openat(some_directory, &quot;my/file.txt&quot;, O_RDONLY);<br>
<br>
The idea is that this method allows you to programmatically determine<br>
which actions an application is allowed to perform. For example, a<br>
simple web server may only possess a file descriptor to its web root<br>
directory during execution, meaning its access is restricted to just<br>
the files it should serve through the web.<br>
<br>
This is good from a security point-of-view. It allows software<br>
developers to reduce the impact of a security vulnerability without<br>
requiring a complex static set of rules to be provided up front (say,<br>
like AppArmor). Another advantage is that software becomes easier to<br>
test. Different parts of the filesystem are used if a program is<br>
invoked with a different set of file descriptors. System testing of<br>
applications may become trivial.<br>
<br>
The reason why I&#39;m getting in touch is that the interfaces described<br=
>
in N3940 seems to have complete disregard for separate filesystem<br>
namespaces. It assumes that the system only provides a single global<br>
filesystem namespace. It looks like an almost direct mapping to POSIX<br>
prior to the 2008 edition. If applications are built on top of this<br>
interface, they will be hard to adapt to systems that use Capsicum.<br>
<br>
I would strongly suggest that all of the global functions are placed<br>
in a separate &#39;class filesystem&#39;. By default there would only be a<=
br>
single instance that attempts to access the global filesystem<br>
namespace. If an implementation supports the POSIX 2008 interface, it<br>
may provide extensions to construct filesystem instances based on file<br>
descriptors to directories.<br>
<br>
This would also address the issues raised in comment #54 in N4096,<br>
raised by Google (who also happened to fund the development of<br>
Capsicum). It could permit filesystem access that is less prone to<br>
race-conditions, but also make it possible to construct artificial<br>
filesystems as part of unit tests.<br>
<br>
I hope that concerns in this area can be addressed before<br>
standardization, as right now this proposal would negatively affect<br>
projects like Capsicum and CloudABI. If needed, I am willing to help<br>
out.<br>
<br>
Relevant links:<br>
<br>
[1] Capsicum: <a href=3D"http://www.cl.cam.ac.uk/research/security/capsicum=
/" target=3D"_blank">http://www.cl.cam.ac.uk/research/security/capsicum/</a=
><br>
[2] Nuxi CloudABI: <a href=3D"https://github.com/NuxiNL/cloudlibc" target=
=3D"_blank">https://github.com/NuxiNL/cloudlibc</a><br>
<br>
Best regards,<br>
<span class=3D"HOEnZb"><font color=3D"#888888">--<br>
Ed Schouten &lt;<a href=3D"mailto:ed@nuxi.nl">ed@nuxi.nl</a>&gt;<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--e89a8f3ba349521f460514ca62ac--

.


Author: Ed Schouten <ed@nuxi.nl>
Date: Wed, 29 Apr 2015 11:40:13 +0200
Raw View
2015-04-28 17:19 GMT+02:00 Jonas Persson <l.j.persson@gmail.com>:
> There was a proposal on boost last year about making filesystem more
> generic. I think his solution might be interesting for your use case too.
> http://lists.boost.org/Archives/boost/2014/01/210470.php

That looks pretty good and would indeed make it possible to write
programs in such a way that they can easily be ported to work with
operating system sandboxing techniques like Capsicum.

Thanks for the pointer!

--
Ed Schouten <ed@nuxi.nl>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.


Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Tue, 5 May 2015 19:23:11 +0200
Raw View
--f46d043892d7cfdab4051558ee2d
Content-Type: text/plain; charset=UTF-8

+Alexander Lamaison who wrote the proposal.

The issue however is that there have not been work to "implement"
this filesystem proposal (in which I am interested too, I plan to try
an implementation based on physfs library, but only in several months from
now).


On Wed, Apr 29, 2015 at 11:40 AM, Ed Schouten <ed@nuxi.nl> wrote:

> 2015-04-28 17:19 GMT+02:00 Jonas Persson <l.j.persson@gmail.com>:
> > There was a proposal on boost last year about making filesystem more
> > generic. I think his solution might be interesting for your use case too.
> > http://lists.boost.org/Archives/boost/2014/01/210470.php
>
> That looks pretty good and would indeed make it possible to write
> programs in such a way that they can easily be ported to work with
> operating system sandboxing techniques like Capsicum.
>
> Thanks for the pointer!
>
> --
> Ed Schouten <ed@nuxi.nl>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--f46d043892d7cfdab4051558ee2d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><br></div><div>+Alexander Lamaison who wrote the prop=
osal.<br></div><div><br></div>The issue however is that there have not been=
 work to &quot;implement&quot;<div>this filesystem proposal (in which I am =
interested too, I plan to try</div><div>an implementation based on physfs l=
ibrary, but only in several months from now).</div><div><br></div></div><di=
v class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Apr 29, 2015=
 at 11:40 AM, Ed Schouten <span dir=3D"ltr">&lt;<a href=3D"mailto:ed@nuxi.n=
l" target=3D"_blank">ed@nuxi.nl</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><span class=3D"">2015-04-28 17:19 GMT+02:00 Jonas Persson &lt=
;<a href=3D"mailto:l.j.persson@gmail.com">l.j.persson@gmail.com</a>&gt;:<br=
>
&gt; There was a proposal on boost last year about making filesystem more<b=
r>
&gt; generic. I think his solution might be interesting for your use case t=
oo.<br>
&gt; <a href=3D"http://lists.boost.org/Archives/boost/2014/01/210470.php" t=
arget=3D"_blank">http://lists.boost.org/Archives/boost/2014/01/210470.php</=
a><br>
<br>
</span>That looks pretty good and would indeed make it possible to write<br=
>
programs in such a way that they can easily be ported to work with<br>
operating system sandboxing techniques like Capsicum.<br>
<br>
Thanks for the pointer!<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
Ed Schouten &lt;<a href=3D"mailto:ed@nuxi.nl">ed@nuxi.nl</a>&gt;<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--f46d043892d7cfdab4051558ee2d--

.


Author: pedro.lamarao@gmail.com
Date: Tue, 5 May 2015 10:46:27 -0700 (PDT)
Raw View
------=_Part_498_1983222054.1430847987217
Content-Type: multipart/alternative;
 boundary="----=_Part_499_919376491.1430847987217"

------=_Part_499_919376491.1430847987217
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Em ter=C3=A7a-feira, 28 de abril de 2015 10:34:18 UTC-3, Ed Schouten escrev=
eu:
=20

> This would also address the issues raised in comment #54 in N4096,=20
> raised by Google (who also happened to fund the development of=20
> Capsicum). It could permit filesystem access that is less prone to=20
> race-conditions, but also make it possible to construct artificial=20
> filesystems as part of unit tests.=20
>


IIRC, in Plan 9, a file system is a property of each process, and parent=20
processes may somehow set up o create child processes file systems.
Basic representation of this design would require some kind of file system=
=20
object, as you suggest.
P.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_499_919376491.1430847987217
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Em ter=C3=A7a-feira, 28 de abril de 2015 10:34:18 UTC-3, E=
d Schouten  escreveu:<div>&nbsp;</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;">This would also address the issues raised in comment #54 in N4096,
<br>raised by Google (who also happened to fund the development of
<br>Capsicum). It could permit filesystem access that is less prone to
<br>race-conditions, but also make it possible to construct artificial
<br>filesystems as part of unit tests.
<br></blockquote><div><br><br>IIRC, in Plan 9, a file system is a property =
of each process, and parent processes may somehow set up o create child pro=
cesses file systems.<br>Basic representation of this design would require s=
ome kind of file system object, as you suggest.<br>P.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_499_919376491.1430847987217--
------=_Part_498_1983222054.1430847987217--

.


Author: alexander.lamaison@gmail.com
Date: Tue, 5 May 2015 10:51:23 -0700 (PDT)
Raw View
------=_Part_826_284312453.1430848283210
Content-Type: multipart/alternative;
 boundary="----=_Part_827_288282996.1430848283210"

------=_Part_827_288282996.1430848283210
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi all,

I'd hoped to find time to work on this last year, but unfortunately didn't.

Ed, your filesystem 'namespacing' problem sounds like exactly the kind of=
=20
thing the generic filesystem proposal [1] could address.  And you hit the=
=20
nail on the head when you talk about testing.  In fact, my motivation for=
=20
the proposal last year was that I wanted to test code that operates using=
=20
my SFTP filesystem API [1] without making the tests dependent on having an=
=20
SFTP server available.  I hoped to be able to slot in the local filesystem=
=20
as a replacement during testing.

IMO two things are needed to make this proposal go anywhere:
1) Some proof-of-concept implementation is required.  I was going to extend=
=20
boost::filesystem with the necessary generic functions, and mirror that API=
=20
with my SFTP filesystem to show both backends being used by a single bit of=
=20
code.
2) My 'proposal' needs to be converted to appropriate C++ standardese.  I=
=20
have no experience of this, so I was planning to give it a rough shot by=20
emulating other proposals and then getting someone like Beman to help me=20
fix it.

Obviously, I've not done any of what I'd planned.  If anyone can help with=
=20
either part that would be great.  Especially the conversion to standardese,=
=20
which I anticipate would take me the longest time by far.

Looking forward to your comments,

Alex

[1] http://alamaison.github.io/2014/01/09/proposal-generic-filesystem/
[2]=20
https://github.com/alamaison/ssh2-cpp/blob/master/ssh/filesystem.hpp#L464

On Tuesday, 5 May 2015 18:23:13 UTC+1, Klaim - Jo=C3=ABl Lamotte wrote:
>
>
> +Alexander Lamaison who wrote the proposal.
>
> The issue however is that there have not been work to "implement"
> this filesystem proposal (in which I am interested too, I plan to try
> an implementation based on physfs library, but only in several months fro=
m=20
> now).
>
>
> On Wed, Apr 29, 2015 at 11:40 AM, Ed Schouten <e...@nuxi.nl <javascript:>=
>=20
> wrote:
>
>> 2015-04-28 17:19 GMT+02:00 Jonas Persson <l.j.p...@gmail.com=20
>> <javascript:>>:
>> > There was a proposal on boost last year about making filesystem more
>> > generic. I think his solution might be interesting for your use case=
=20
>> too.
>> > http://lists.boost.org/Archives/boost/2014/01/210470.php
>>
>> That looks pretty good and would indeed make it possible to write
>> programs in such a way that they can easily be ported to work with
>> operating system sandboxing techniques like Capsicum.
>>
>> Thanks for the pointer!
>>
>> --
>> Ed Schouten <e...@nuxi.nl <javascript:>>
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_827_288282996.1430848283210
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi all,<br><br>I'd hoped to find time to work on this last=
 year, but unfortunately didn't.<br><br>Ed, your filesystem 'namespacing' p=
roblem sounds like exactly the kind of thing the generic filesystem proposa=
l [1] could address.&nbsp; And you hit the nail on the head when you talk a=
bout testing.&nbsp; In fact, my motivation for the proposal last year was t=
hat I wanted to test code that operates using my SFTP filesystem API [1] wi=
thout making the tests dependent on having an SFTP server available.&nbsp; =
I hoped to be able to slot in the local filesystem as a replacement during =
testing.<br><br>IMO two things are needed to make this proposal go anywhere=
:<br>1) Some proof-of-concept implementation is required.&nbsp; I was going=
 to extend boost::filesystem with the necessary generic functions, and mirr=
or that API with my SFTP filesystem to show both backends being used by a s=
ingle bit of code.<br>2) My 'proposal' needs to be converted to appropriate=
 C++ standardese.&nbsp; I have no experience of this, so I was planning to =
give it a rough shot by emulating other proposals and then getting someone =
like Beman to help me fix it.<br><br>Obviously, I've not done any of what I=
'd planned.&nbsp; If anyone can help with either part that would be great.&=
nbsp; Especially the conversion to standardese, which I anticipate would ta=
ke me the longest time by far.<br><br>Looking forward to your comments,<br>=
<br>Alex<br><br>[1] http://alamaison.github.io/2014/01/09/proposal-generic-=
filesystem/<br>[2] https://github.com/alamaison/ssh2-cpp/blob/master/ssh/fi=
lesystem.hpp#L464<br><br>On Tuesday, 5 May 2015 18:23:13 UTC+1, Klaim - Jo=
=C3=ABl Lamotte  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><div><br></div><div>+Alexander Lamaison who wrote the proposal.<b=
r></div><div><br></div>The issue however is that there have not been work t=
o "implement"<div>this filesystem proposal (in which I am interested too, I=
 plan to try</div><div>an implementation based on physfs library, but only =
in several months from now).</div><div><br></div></div><div><br><div class=
=3D"gmail_quote">On Wed, Apr 29, 2015 at 11:40 AM, Ed Schouten <span dir=3D=
"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"_a4fcOrvE7wJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:'=
;return true;" onclick=3D"this.href=3D'javascript:';return true;">e...@nuxi=
..nl</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>2015-04-2=
8 17:19 GMT+02:00 Jonas Persson &lt;<a href=3D"javascript:" target=3D"_blan=
k" gdf-obfuscated-mailto=3D"_a4fcOrvE7wJ" rel=3D"nofollow" onmousedown=3D"t=
his.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:'=
;return true;">l.j.p...@gmail.com</a>&gt;:<br>
&gt; There was a proposal on boost last year about making filesystem more<b=
r>
&gt; generic. I think his solution might be interesting for your use case t=
oo.<br>
&gt; <a href=3D"http://lists.boost.org/Archives/boost/2014/01/210470.php" t=
arget=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.go=
ogle.com/url?q\75http%3A%2F%2Flists.boost.org%2FArchives%2Fboost%2F2014%2F0=
1%2F210470.php\46sa\75D\46sntz\0751\46usg\75AFQjCNEfBKI6HM8A4p0TxBrfMJr8pvX=
UOA';return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75ht=
tp%3A%2F%2Flists.boost.org%2FArchives%2Fboost%2F2014%2F01%2F210470.php\46sa=
\75D\46sntz\0751\46usg\75AFQjCNEfBKI6HM8A4p0TxBrfMJr8pvXUOA';return true;">=
http://lists.boost.org/<wbr>Archives/boost/2014/01/210470.<wbr>php</a><br>
<br>
</span>That looks pretty good and would indeed make it possible to write<br=
>
programs in such a way that they can easily be ported to work with<br>
operating system sandboxing techniques like Capsicum.<br>
<br>
Thanks for the pointer!<br>
<div><div><br>
--<br>
Ed Schouten &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"_a4fcOrvE7wJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascri=
pt:';return true;" onclick=3D"this.href=3D'javascript:';return true;">e...@=
nuxi.nl</a>&gt;<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
_a4fcOrvE7wJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';ret=
urn true;" onclick=3D"this.href=3D'javascript:';return true;">std-proposal.=
...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"_a4fcOrvE7wJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:=
';return true;">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';return true=
;" onclick=3D"this.href=3D'http://groups.google.com/a/isocpp.org/group/std-=
proposals/';return true;">http://groups.google.com/a/<wbr>isocpp.org/group/=
std-<wbr>proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_827_288282996.1430848283210--
------=_Part_826_284312453.1430848283210--

.