------=_Part_4397_1525557826.1505779144454
Content-Type: multipart/alternative;
 boundary="----=_Part_4398_1121651936.1505779144454"

------=_Part_4398_1121651936.1505779144454
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Possibly slightly off topic but bear with me.
Do C, C++ and Posix require a way to re-open a file descriptor?

The two common cases are:
* I have a file and after reading it I may decide I want to write it after=
=20
all.
* I create a new file and having finished setting it up I want to make it=
=20
read only.

Recent discussions about race free file systems have made me more aware of=
=20
the potential problems with this.
When going from read to write you do need a permission check but the other=
=20
way around you do not.

Ideally you should be able to re-open based on the file handle or=20
descriptor to avoid a race if the file is moved, renamed or deleted.
This is similar to the situation with moving locks from shared read to=20
write and back that can also be weak on Posix.

At present I think the only way to do this is to re-open the file using its=
=20
path name unless you are using freopen with a null path-name.

The primary use of the *freopen*() function is to change the file=20
associated with a standard text stream (*stderr*, *stdin*, or *stdout*)
In Posix it it is implementation defined whether freopen() will allow you=
=20
to change the open mode:
  http://pubs.opengroup.org/onlinepubs/009695399/functions/freopen.html

I'm not clear whether the C standard says anything more.

There doesn't seem to be an equivalent for file descriptors.
Apparently some Unix-like OSs support using fcntl() with FD_SETFL but Posix=
=20
specifically says flags for the read or write mode shall be ignored.

Windows has a ReOpenFile() call -=20
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365497(v=3Dvs.85=
).aspx

So my question is should we try make this possible?
For example we might:

* make the behaviour of freopen() fully defined for the case of converting=
=20
a FILE* from read to write or write to read
(something for WG14 not directly in scope for C++)

* add a new function to Posix like:
  int reopen(int fd, int flags)=20
(something for =C5=A7he Austin group not directly in scope for C++)

* add a reopen(mode) to std::basic_filebuf & std::basic_fstream
(very much in scope for C++ and perhaps a way of driving the other two?)

I can't see this functionality in AFIO. Was it considered? Perhaps rejected=
=20
because there is not currently a portable solution?

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5da7aff7-0f91-48d0-b788-fe558e856ba9%40isocpp.or=
g.

------=_Part_4398_1121651936.1505779144454
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Possibly slightly off topic but bear with me.<br>Do C, C++=
 and Posix require a way to re-open a file descriptor?<br><br>The two commo=
n cases are:<br>* I have a file and after reading it I may decide I want to=
 write it after all.<br>* I create a new file and having finished setting i=
t up I want to make it read only.<br><br>Recent discussions about race free=
 file systems have made me more aware of the potential problems with this.<=
br>When going from read to write you do need a permission check but the oth=
er way around you do not.<br><br>Ideally
 you should be able to re-open based on the file handle or descriptor to
 avoid a race if the file is moved, renamed or deleted.<br>This is similar =
to the situation with moving locks from shared read to write and back that =
can also be weak on Posix.<br><br>At
 present I think the only way to do this is to re-open the file using=20
its path name unless you are using freopen with a null path-name.<br><br>Th=
e primary use of the
<b>freopen</b>() function is to change the file associated with a standard =
text stream (<i>stderr</i>, <i>stdin</i>, or <i>stdout</i>)<br>In Posix it =
it is implementation defined whether freopen() will allow you to change the=
 open mode:<br>=C2=A0 http://pubs.opengroup.org/onlinepubs/009695399/functi=
ons/freopen.html<br><br>I&#39;m not clear whether the C standard says anyth=
ing more.<br><br>There doesn&#39;t seem to be an equivalent for file descri=
ptors.<br>Apparently
 some Unix-like OSs support using fcntl() with FD_SETFL but Posix=20
specifically says flags for the read or write mode shall be ignored.<br><br=
>Windows has a ReOpenFile() call - https://msdn.microsoft.com/en-us/library=
/windows/desktop/aa365497(v=3Dvs.85).aspx<br><br>So my question is should w=
e try make this possible?<br>For example we might:<br><br>* make the behavi=
our of freopen() fully defined for the case of converting a FILE* from read=
 to write or write to read<br>(something for WG14 not directly in scope for=
 C++)<br><br>* add a new function to Posix like:<br>=C2=A0 int reopen(int f=
d, int flags) <br>(something for =C5=A7he Austin group not directly in scop=
e for C++)<br><br>* add a reopen(mode) to std::basic_filebuf &amp; std::bas=
ic_fstream<br>(very much in scope for C++ and perhaps a way of driving the =
other two?)<br><br>I can&#39;t see this functionality in AFIO. Was it consi=
dered? Perhaps rejected because there is not currently a portable solution?=
<br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5da7aff7-0f91-48d0-b788-fe558e856ba9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5da7aff7-0f91-48d0-b788-fe558e856ba9=
%40isocpp.org</a>.<br />

------=_Part_4398_1121651936.1505779144454--

------=_Part_4397_1525557826.1505779144454--

.

On Monday, 18 September 2017 16:59:04 PDT tortoise741@gmail.com wrote:
> Possibly slightly off topic but bear with me.
> Do C, C++ and Posix require a way to re-open a file descriptor?
>=20
> The two common cases are:
> * I have a file and after reading it I may decide I want to write it afte=
r
> all.
> * I create a new file and having finished setting it up I want to make it
> read only.

There's no such API. The closest I can think of is fcntl(F_SETFL), which wo=
n't=20
work. http://pubs.opengroup.org/onlinepubs/9699919799/functions/fcntl.html=
=20
says for F_SETFL:
"Bits corresponding to the file access mode and the file creation flags, as=
=20
defined in <fcntl.h>, that are set in arg shall be ignored."

Other possibilities I investigated:
1) using openat(2) with an empty path and the open file descriptor as the d=
fd:=20
this results in ENOENT because of the empty path (openat has no field to pa=
ss=20
AT_EMPTY_PATH). If you pass any non-empty path, you get ENOTDIR.

2) using first open(2) with O_PATH (Linux-specific) and then trying to open=
=20
that. Also fails the same way.

However, on Linux, you can make it work by opening "/proc/self/fd/%d" with =
the=20
file descriptor number. This will work even if the file has been deleted or=
 was=20
not even present in the file system somewhere you could find. It also works=
 for=20
file descriptors of other processes.

> So my question is should we try make this possible?
> For example we might:
>=20
> * make the behaviour of freopen() fully defined for the case of convertin=
g
> a FILE* from read to write or write to read
> (something for WG14 not directly in scope for C++)

freopen doesn't help because it's a process-local thing. It's not an operat=
ing=20
system object. You can't pass FILE* over Unix sockets and child processes=
=20
can't inherit them.

> * add a new function to Posix like:
>   int reopen(int fd, int flags)
> (something for =C5=A7he Austin group not directly in scope for C++)

First, you implement it in the major OSes to show it is possible. Then POSI=
X=20
may adopt it.

This was first one for O_CLOEXEC, which allows for thread-safe opening of f=
ile=20
descriptors. I also see O_NOSIGPIPE as a future standardisation possibility=
,=20
based on existing practice.

reopen() doesn't exist yet.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2017803.MGL1LO5ust%40tjmaciei-mobl1.

.

------=_Part_4667_17982831.1505808911930
Content-Type: multipart/alternative;
 boundary="----=_Part_4668_410426917.1505808911930"

------=_Part_4668_410426917.1505808911930
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Tuesday, 19 September 2017 01:50:09 UTC+1, Thiago Macieira wrote:
>
> On Monday, 18 September 2017 16:59:04 PDT torto...@gmail.com <javascript:=
>=20
> wrote:=20
> > Possibly slightly off topic but bear with me.=20
> > Do C, C++ and Posix require a way to re-open a file descriptor?=20
> >=20
> > The two common cases are:=20
> > * I have a file and after reading it I may decide I want to write it=20
> after=20
> > all.=20
> > * I create a new file and having finished setting it up I want to make=
=20
> it=20
> > read only.=20
>
> There's no such API. The closest I can think of is fcntl(F_SETFL), which=
=20
> won't=20
> work. http://pubs.opengroup.org/onlinepubs/9699919799/functions/fcntl.htm=
l=20
> says for F_SETFL:=20
> "Bits corresponding to the file access mode and the file creation flags,=
=20
> as=20
> defined in <fcntl.h>, that are set in arg shall be ignored."=20
>
> Yes as I already alluded.=20
The rationale is not stated but I presume its to make implementation easier=
..
=20

> Other possibilities I investigated:=20
> 1) using openat(2) with an empty path and the open file descriptor as the=
=20
> dfd:=20
> this results in ENOENT because of the empty path (openat has no field to=
=20
> pass=20
> AT_EMPTY_PATH). If you pass any non-empty path, you get ENOTDIR.=20
>
> openat() is not appropriate as the file descriptor is for a directory so=
=20
ENOTDIR is exactly the expected behaviour.
=20

> 2) using first open(2) with O_PATH (Linux-specific) and then trying to=20
> open=20
> that. Also fails the same way.=20
>
> However, on Linux, you can make it work by opening "/proc/self/fd/%d" wit=
h=20
> the=20
> file descriptor number. This will work even if the file has been deleted=
=20
> or was=20
> not even present in the file system somewhere you could find. It also=20
> works for=20
> file descriptors of other processes.=20
>
> I did find that trick but it is still opening a path. When I first tried=
=20
it I had accidentally=20
create the file with the wrong permissions and unsurprisingly got an EPERM.
If you were really re-opening using the file descriptor that would not=20
apply.

> So my question is should we try make this possible?=20
> > For example we might:=20
> >=20
> > * make the behaviour of freopen() fully defined for the case of=20
> converting=20
> > a FILE* from read to write or write to read=20
> > (something for WG14 not directly in scope for C++)=20
>
> freopen doesn't help because it's a process-local thing. It's not an=20
> operating=20
> system object. You can't pass FILE* over Unix sockets and child processes=
=20
> can't inherit them.=20
>
> Yes but its one of three interfaces which I'm arguing should be consisten=
t=20
and complementary.

> * add a new function to Posix like:=20
> >   int reopen(int fd, int flags)=20
> > (something for =C5=A7he Austin group not directly in scope for C++)=20
>
> First, you implement it in the major OSes to show it is possible. Then=20
> POSIX=20
> may adopt it.=20
>
> This was first one for O_CLOEXEC, which allows for thread-safe opening of=
=20
> file=20
> descriptors. I also see O_NOSIGPIPE as a future standardisation=20
> possibility,=20
> based on existing practice.=20
>
> reopen() doesn't exist yet.=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
>    Software Architect - Intel Open Source Technology Center=20
>
> My thought was to do and try to add it to C++ with semantics that are=20
initially required to be implementation defined
with regards to races (i.e. they use the path under the hood for now) and=
=20
use that to help drive the need for putting it into Posix.=20
(as Niall was hinting at for some things in AFIO).
However, you are right, adding it to Linux and BSD would be an far better=
=20
driver towards Posix in the first instance.

I suppose my question here is, if its such am obvious and good idea why=20
hasn't it been done already?
I suspect as I discovered with accessing low level file descriptors there=
=20
are some interesting corner cases to think about,
especially as this is once again at the intersection of at least 3=20
standards.

Regards,

Bruce.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/e9118ecd-d152-4495-8f49-eefa1be9c894%40isocpp.or=
g.

------=_Part_4668_410426917.1505808911930
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, 19 September 2017 01:50:09 UTC+1, Thia=
go Macieira  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Monday, =
18 September 2017 16:59:04 PDT <a href=3D"javascript:" target=3D"_blank" gd=
f-obfuscated-mailto=3D"LOH0nCLmAAAJ" rel=3D"nofollow" onmousedown=3D"this.h=
ref=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javas=
cript:&#39;;return true;">torto...@gmail.com</a> wrote:
<br>&gt; Possibly slightly off topic but bear with me.
<br>&gt; Do C, C++ and Posix require a way to re-open a file descriptor?
<br>&gt;=20
<br>&gt; The two common cases are:
<br>&gt; * I have a file and after reading it I may decide I want to write =
it after
<br>&gt; all.
<br>&gt; * I create a new file and having finished setting it up I want to =
make it
<br>&gt; read only.
<br>
<br>There&#39;s no such API. The closest I can think of is fcntl(F_SETFL), =
which won&#39;t=20
<br>work. <a href=3D"http://pubs.opengroup.org/onlinepubs/9699919799/functi=
ons/fcntl.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fpubs.opengroup.org%2Fon=
linepubs%2F9699919799%2Ffunctions%2Ffcntl.html\x26sa\x3dD\x26sntz\x3d1\x26u=
sg\x3dAFQjCNHdYgEuU_flJl4u_BeGJw9pGh48TA&#39;;return true;" onclick=3D"this=
..href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fpubs.opengroup.org=
%2Fonlinepubs%2F9699919799%2Ffunctions%2Ffcntl.html\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHdYgEuU_flJl4u_BeGJw9pGh48TA&#39;;return true;">http://pub=
s.opengroup.org/<wbr>onlinepubs/9699919799/<wbr>functions/fcntl.html</a>=20
<br>says for F_SETFL:
<br>&quot;Bits corresponding to the file access mode and the file creation =
flags, as=20
<br>defined in &lt;fcntl.h&gt;, that are set in arg shall be ignored.&quot;
<br>
<br></blockquote><div>Yes as I already alluded. <br></div><div>The rational=
e is not stated but I presume its to make implementation easier.<br></div><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Other possibil=
ities I investigated:
<br>1) using openat(2) with an empty path and the open file descriptor as t=
he dfd:=20
<br>this results in ENOENT because of the empty path (openat has no field t=
o pass=20
<br>AT_EMPTY_PATH). If you pass any non-empty path, you get ENOTDIR.
<br>
<br></blockquote><div>openat() is not appropriate as the file descriptor is=
 for a directory so ENOTDIR is exactly the expected behaviour.<br></div><di=
v>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">2) using first o=
pen(2) with O_PATH (Linux-specific) and then trying to open=20
<br>that. Also fails the same way.
<br>
<br>However, on Linux, you can make it work by opening &quot;/proc/self/fd/=
%d&quot; with the=20
<br>file descriptor number. This will work even if the file has been delete=
d or was=20
<br>not even present in the file system somewhere you could find. It also w=
orks for=20
<br>file descriptors of other processes.
<br>
<br></blockquote><div>I did find that trick but it is still opening a path.=
 When I first tried it I had accidentally <br></div><div>create the file wi=
th the wrong permissions and unsurprisingly got an EPERM.</div><div>If you =
were really re-opening using the file descriptor that would not apply.<br><=
/div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; So my=
 question is should we try make this possible?
<br>&gt; For example we might:
<br>&gt;=20
<br>&gt; * make the behaviour of freopen() fully defined for the case of co=
nverting
<br>&gt; a FILE* from read to write or write to read
<br>&gt; (something for WG14 not directly in scope for C++)
<br>
<br>freopen doesn&#39;t help because it&#39;s a process-local thing. It&#39=
;s not an operating=20
<br>system object. You can&#39;t pass FILE* over Unix sockets and child pro=
cesses=20
<br>can&#39;t inherit them.
<br>
<br></blockquote><div>Yes but its one of three interfaces which I&#39;m arg=
uing should be consistent and complementary.</div><div><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">&gt; * add a new function to Posix like:
<br>&gt; =C2=A0 int reopen(int fd, int flags)
<br>&gt; (something for =C5=A7he Austin group not directly in scope for C++=
)
<br>
<br>First, you implement it in the major OSes to show it is possible. Then =
POSIX=20
<br>may adopt it.
<br>
<br>This was first one for O_CLOEXEC, which allows for thread-safe opening =
of file=20
<br>descriptors. I also see O_NOSIGPIPE as a future standardisation possibi=
lity,=20
<br>based on existing practice.
<br>
<br>reopen() doesn&#39;t exist yet.
<br>
<br></blockquote><div></div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">--=
=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote><div>My thought was to do and try to add it to C++ with se=
mantics that are initially required to be implementation defined</div><div>=
with regards to races (i.e. they use the path under the hood for now) and u=
se that to help drive the need for putting it into Posix. <br></div><div>(a=
s Niall was hinting at for some things in AFIO).</div><div> However, you ar=
e right, adding it to Linux and BSD would be an far better driver towards P=
osix in the first instance.</div><div><br></div><div>I suppose my question =
here is, if its such am obvious and good idea why hasn&#39;t it been done a=
lready?</div><div>I suspect as I discovered with accessing low level file d=
escriptors there are some interesting corner cases to think about,</div><di=
v>especially as this is once again at the intersection of at least 3 standa=
rds.</div><div><br></div><div>Regards,</div><div><br></div><div>Bruce.<br><=
/div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e9118ecd-d152-4495-8f49-eefa1be9c894%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e9118ecd-d152-4495-8f49-eefa1be9c894=
%40isocpp.org</a>.<br />

------=_Part_4668_410426917.1505808911930--

------=_Part_4667_17982831.1505808911930--

.

On Tuesday, 19 September 2017 01:15:11 PDT tortoise741@gmail.com wrote:
> > I did find that trick but it is still opening a path. When I first tried
>
> it I had accidentally
> create the file with the wrong permissions and unsurprisingly got an EPERM.
> If you were really re-opening using the file descriptor that would not
> apply.

If the file can't be opened, it shouldn't be reopenable either. Note that you
can do open(O_RDWR, 0400).

Now, the details of your issue here are relevant. You're brushing them over,
so if you want a discussion of the use-case, go back and look at what you did
wrong when reopening /proc/self/fd/%d.

> I suppose my question here is, if its such am obvious and good idea why
> hasn't it been done already?
> I suspect as I discovered with accessing low level file descriptors there
> are some interesting corner cases to think about,
> especially as this is once again at the intersection of at least 3
> standards.

Because I suppose there isn't such a big need. There aren't many uses of file
descriptor passing to require this feature often enough. That's where you need
OS-provided enforcement.

If you meant protection against accidental writes, then updating FILE* and
std::fstream is fine. That's enforcement by the API, but with no protection
against malicious code doing write(fileno(fptr), "h4x0rz", 6).

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6214938.K7Ek31VM1b%40tjmaciei-mobl1.

.

------=_Part_4946_235526312.1505855056146
Content-Type: multipart/alternative;
 boundary="----=_Part_4947_1430491401.1505855056147"

------=_Part_4947_1430491401.1505855056147
Content-Type: text/plain; charset="UTF-8"



On Tuesday, 19 September 2017 16:05:59 UTC+1, Thiago Macieira wrote:
>
> On Tuesday, 19 September 2017 01:15:11 PDT torto...@gmail.com
> <javascript:> wrote:
> > > I did find that trick but it is still opening a path. When I first
> tried
> >
> > it I had accidentally
> > create the file with the wrong permissions and unsurprisingly got an
> EPERM.
> > If you were really re-opening using the file descriptor that would not
> > apply.
>
> If the file can't be opened, it shouldn't be reopenable either. Note that
> you
> can do open(O_RDWR, 0400).
>
> That is a fair point. I was assuming it should be reopenable because it
was already open but then it wouldn't be respecting its own permissions.


> Now, the details of your issue here are relevant. You're brushing them
> over,
> so if you want a discussion of the use-case, go back and look at what you
> did
> wrong when reopening /proc/self/fd/%d.
>
>
> I suppose my question here is, if its such am obvious and good idea why
> > hasn't it been done already?
> > I suspect as I discovered with accessing low level file descriptors
> there
> > are some interesting corner cases to think about,
> > especially as this is once again at the intersection of at least 3
> > standards.
>
> Because I suppose there isn't such a big need. There aren't many uses of
> file
> descriptor passing to require this feature often enough. That's where you
> need
> OS-provided enforcement.
>
> If you meant protection against accidental writes, then updating FILE* and
> std::fstream is fine. That's enforcement by the API, but with no
> protection
> against malicious code doing write(fileno(fptr), "h4x0rz", 6).
>
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
> Correct. For this case I was thinking solely about a single process for
the purpose of protecting
against bugs. For example, accidentally writing to a file after it has been
'completed' fails if you
make it read-only but not if you open it read-write to start with.

One way to enforce that is by adding reopen() functions to the APIs.
But isn't there a race if the file you are reopening is moved, renamed or
deleted during the reopen operation?
Wouldn't that present a potential attack surface meaning you were better
off just opening the file for both
reading and writing in the first place?

An alternative is constructing a stream with more restrictive permissions
from the more general one.
Something which should already work is:

    iofstream readWriteable("foobar");

    ofstream writeOnly(readWriteable.rdbuf());

    ifstream readOnly(readWriteable.rdbuf());

but this can be subverted easily using:

   iofstream readWriteableAgain(writeOnly.rdbuf());

Is it worth preventing that kind of madness? perhaps making the intent
clearer?

I would never do this myself. Instead I would do:

    void writeOnlyStuff(ostream& writable) { //do stuff write only }
    void readOnlyStuff(istream& readOnly) { //do stuff read only }

    void doStuff(void)
    {
        iofstream readWriteable("foobar");
        writeOnlyStuff(readWriteable);
        readOnlyStuff(readWriteable);
    }

I don't think is a way to do the equivalent using existing cstdio or posix
APIs (without a racey open).
I suppose this has come up for me now as I am working with some legacy code
written in C.
Using C is inherently more dangerous. Should we even try fixing it?

Rather than reopen() perhaps,
for Posix:

int readOnlyFd = dup4(readWriteFd, O_RDONLY); //reduce permissions - always
works
int readWriteFd = dup4(readOnlyFd, O_RDWR); //increase permissions - may
fail with EPERM

for C maybe:

File* readWriteFile = open("foobar","w+");
File* readOnlyFile = freopen2(readWriteFile,"r");

dup4 and freopen2 are bad names (any name with a number on the end is
probably a bad name).

But for File* in Posix we can presumably do:

File* readOnlyFile = fdopen(fileno(readWriteFile),"r");

Posix says the flags must respect those of the file descriptor
"The application shall ensure that the mode of the stream as expressed by
the *mode* argument is allowed by the file access mode of the open file
description to which *fildes* refers"
http://pubs.opengroup.org/onlinepubs/009695399/functions/fdopen.html

My Linux man page is a bit more ambiguous:

"The mode of the stream (one of the values "r", "r+", "w", "w+", "a", "a+")
must be compatible with the mode of the file descriptor."

Compatible could be read as implying it should be the exact same mode.






--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5658abb6-7cd2-46ab-ab8b-7795f9776df0%40isocpp.org.

------=_Part_4947_1430491401.1505855056147
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, 19 September 2017 16:05:59 UTC+1, Thia=
go Macieira  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tuesday,=
 19 September 2017 01:15:11 PDT <a href=3D"javascript:" target=3D"_blank" g=
df-obfuscated-mailto=3D"1-sVif52AAAJ" rel=3D"nofollow" onmousedown=3D"this.=
href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;java=
script:&#39;;return true;">torto...@gmail.com</a> wrote:
<br>&gt; &gt; I did find that trick but it is still opening a path. When I =
first tried
<br>&gt;=20
<br>&gt; it I had accidentally
<br>&gt; create the file with the wrong permissions and unsurprisingly got =
an EPERM.
<br>&gt; If you were really re-opening using the file descriptor that would=
 not
<br>&gt; apply.
<br>
<br>If the file can&#39;t be opened, it shouldn&#39;t be reopenable either.=
 Note that you=20
<br>can do open(O_RDWR, 0400).
<br>
<br></blockquote><div>That is a fair point. I was assuming it should be reo=
penable because it was already open but then it wouldn&#39;t be respecting =
its own permissions.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;">Now, the details of your issue here are relevant. You&#39;=
re brushing them over,=20
<br>so if you want a discussion of the use-case, go back and look at what y=
ou did=20
<br>wrong when reopening /proc/self/fd/%d.
<br>
<br></blockquote><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; I su=
ppose my question here is, if its such am obvious and good idea why
<br>&gt; hasn&#39;t it been done already?
<br>&gt; I suspect as I discovered with accessing low level file descriptor=
s there
<br>&gt; are some interesting corner cases to think about,
<br>&gt; especially as this is once again at the intersection of at least 3
<br>&gt; standards.
<br>
<br>Because I suppose there isn&#39;t such a big need. There aren&#39;t man=
y uses of file=20
<br>descriptor passing to require this feature often enough. That&#39;s whe=
re you need=20
<br>OS-provided enforcement.
<br>
<br>If you meant protection against accidental writes, then updating FILE* =
and=20
<br>std::fstream is fine. That&#39;s enforcement by the API, but with no pr=
otection=20
<br>against malicious code doing write(fileno(fptr), &quot;h4x0rz&quot;, 6)=
..
<br>
<br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Thiago Maciei=
ra - thiago (AT) <a href=3D"http://macieira.info" target=3D"_blank" rel=3D"=
nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x3dht=
tp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNa=
nbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.href=3D&#39;http://ww=
w.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x2=
6usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;">macieira.info=
</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"_blank" rel=3D"nofo=
llow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3=
A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAH=
AKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.c=
om/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHG=
RJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote><div><div>Correct. For this case I was thinking solely abo=
ut a single process for the purpose of protecting</div><div>against bugs. F=
or example, accidentally writing to a file after it has been &#39;completed=
&#39; fails if you</div><div>make it read-only but not if you open it read-=
write to start with. <br></div><div><br></div><div>One way to enforce that =
is by adding reopen() functions to the APIs.</div><div>But isn&#39;t there =
a race if the file you are reopening is moved, renamed or deleted during th=
e reopen operation?</div><div>Wouldn&#39;t that present a potential attack =
surface meaning you were better off just opening the file for both</div><di=
v>reading and writing in the first place?<br></div><div><br></div><div>An a=
lternative is constructing a stream with more restrictive permissions from =
the more general one.</div><div>Something which should already work is:</di=
v><div><br></div><div>=C2=A0=C2=A0=C2=A0 iofstream readWriteable(&quot;foob=
ar&quot;);</div><div><br></div><div>=C2=A0=C2=A0=C2=A0 ofstream writeOnly(r=
eadWriteable.rdbuf());</div><div><br></div><div>=C2=A0=C2=A0=C2=A0 ifstream=
 readOnly(readWriteable.rdbuf());</div><div><br></div><div>but this can be =
subverted easily using:</div><div><br></div><div>=C2=A0=C2=A0 iofstream rea=
dWriteableAgain(writeOnly.rdbuf());</div><div><br></div><div>Is it worth pr=
eventing that kind of madness? perhaps making the intent clearer?</div><div=
><br></div><div><div>I would never do this myself. Instead I would do:</div=
></div><div><br></div><div>=C2=A0=C2=A0=C2=A0 void writeOnlyStuff(ostream&a=
mp; writable) { //do stuff write only }<br><div><div><div>=C2=A0=C2=A0=C2=
=A0 void readOnlyStuff(istream&amp; readOnly) { //do stuff read only }<br><=
/div></div><div><br></div></div></div><div>=C2=A0=C2=A0=C2=A0 void doStuff(=
void)</div><div>=C2=A0=C2=A0=C2=A0 {<br><div>=C2=A0 =C2=A0=C2=A0 =C2=A0=C2=
=A0 iofstream readWriteable(&quot;foobar&quot;);</div><div>=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 writeOnlyStuff(readWriteable);</div><div><div>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 readOnlyStuff(readWriteable);</d=
iv>=C2=A0=C2=A0=C2=A0 }</div></div><div><br></div><div></div><div>I don&#39=
;t think is a way to do the equivalent using existing cstdio or posix APIs =
(without a racey open).<br></div><div>I suppose this has come up for me now=
 as I am working with some legacy code written in C.</div><div>Using C is i=
nherently more dangerous. Should we even try fixing it?<br></div><div><br><=
/div><div>Rather than reopen() perhaps,</div><div>for Posix:<br></div><div>=
<br></div><div>int readOnlyFd =3D dup4(readWriteFd, O_RDONLY); //reduce per=
missions - always works<br></div><div>int readWriteFd =3D dup4(readOnlyFd, =
O_RDWR); //increase permissions - may fail with EPERM</div><div><br></div><=
div>for C maybe:</div><div><br></div><div>File* readWriteFile =3D open(&quo=
t;foobar&quot;,&quot;w+&quot;);<br></div><div>File* readOnlyFile =3D freope=
n2(readWriteFile,&quot;r&quot;);</div><div><br></div><div>dup4 and freopen2=
 are bad names (any name with a number on the end is probably a bad name).<=
br></div><div><br></div><div>But for File* in Posix we can presumably do:</=
div><div><br></div><div><div>File* readOnlyFile =3D fdopen(fileno(readWrite=
File),&quot;r&quot;);</div><div><br></div><div>Posix says the flags must re=
spect those of the file descriptor</div><div>&quot;The application shall en=
sure that the mode of the stream as expressed by the <i>mode</i> argument i=
s allowed by the file access
mode of the open file description to which <i>fildes</i> refers&quot;</div>=
<div>http://pubs.opengroup.org/onlinepubs/009695399/functions/fdopen.html<b=
r></div><div><br></div><div>My Linux man page is a bit more ambiguous:<br><=
/div><div><br></div><div>&quot;The mode of the stream (one of the values &q=
uot;r&quot;, &quot;r+&quot;, &quot;w&quot;, &quot;w+&quot;, &quot;a&quot;, =
&quot;a+&quot;) must be compatible with the mode of the file descriptor.&qu=
ot;</div><div><br></div><div>Compatible could be read as implying it should=
 be the exact same mode.<br></div><div><br></div></div><div><br></div><div>=
<br></div><div><br></div>=C2=A0</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5658abb6-7cd2-46ab-ab8b-7795f9776df0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5658abb6-7cd2-46ab-ab8b-7795f9776df0=
%40isocpp.org</a>.<br />

------=_Part_4947_1430491401.1505855056147--

------=_Part_4946_235526312.1505855056146--

.

On Tuesday, 19 September 2017 14:04:16 PDT tortoise741@gmail.com wrote:
> Correct. For this case I was thinking solely about a single process for
> the purpose of protecting
> against bugs. For example, accidentally writing to a file after it has been
> 'completed' fails if you
> make it read-only but not if you open it read-write to start with.
>
> One way to enforce that is by adding reopen() functions to the APIs.

That can easily be done on the API that is under the purview of WG14 (stdio.h)
and WG21 (fstream).

Adding it to the POSIX API is a different matter completely.

> But isn't there a race if the file you are reopening is moved, renamed or
> deleted during the reopen operation?

Yes, if you open it by the original path, which you must have recorded. If you
just reopen /proc/self/fd/%d, there's no race (provided you don't have another
thread closing that fd at the same time).

> for Posix:
>
> int readOnlyFd = dup4(readWriteFd, O_RDONLY); //reduce permissions - always
> works

> dup4 and freopen2 are bad names (any name with a number on the end is
> probably a bad name).

According to the Linux naming, "dup4" should have 4 arguments but you only
have 2. The call you'd have wanted is actually dup3, since it already has a
flags argument that is currently used to pass O_NONBLOCK or O_CLOEXEC. Except
that no one passes O_RDONLY or O_WRONLY or O_RDWR flags today, so the 0 could
be misinterpreted.

Anyway, I don't think "dup" should be used. That means duplicating the file
descriptor but still pointing to the kernel structures, which include the
current read/write cursor position, in addition to the flags. You actually want
something with "open" in the name, indicating it's a different open.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6041524.YLvTZzegA8%40tjmaciei-mobl1.

.

------=_Part_5234_1592095472.1505860097825
Content-Type: multipart/alternative;
 boundary="----=_Part_5235_1826968430.1505860097825"

------=_Part_5235_1826968430.1505860097825
Content-Type: text/plain; charset="UTF-8"

On Tuesday, September 19, 2017 at 12:59:04 AM UTC+1, Bruce Adams wrote:
>
> Possibly slightly off topic but bear with me.
> Do C, C++ and Posix require a way to re-open a file descriptor?
>

POSIX does not.

Windows does via an undocumented set of parameters for NtOpenFile(). This
undocumented use case proved so popular it was formalised into the Win32
ReOpenFile().


>
> The two common cases are:
> * I have a file and after reading it I may decide I want to write it after
> all.
> * I create a new file and having finished setting it up I want to make it
> read only.
>
> Recent discussions about race free file systems have made me more aware of
> the potential problems with this.
> When going from read to write you do need a permission check but the other
> way around you do not.
>
> Ideally you should be able to re-open based on the file handle or
> descriptor to avoid a race if the file is moved, renamed or deleted.
> This is similar to the situation with moving locks from shared read to
> write and back that can also be weak on Posix.
>

Right now, on POSIX, the only way to achieve this is to loop fetching the
path, opening it, and comparing st_ino and st_dev for equivalence.

This ought to not be too bad. Linux opens a fd in single digit
microseconds. Windows is two orders of magnitude slower, even with
ReOpenFile().


>
> I can't see this functionality in AFIO. Was it considered? Perhaps
> rejected because there is not currently a portable solution?
>

Honestly it's because nobody made me think of it until now.

Expect to see it land by end of week at the latest :) It's trivially easy
to implement. It's a good idea, and thanks for suggesting it.

BTW Thiago you may be interested to learn that I wrote a template adapter
which lets you adapt any afio::handle to no longer rely on path retrieval
working (correctly/at all). It's on the user to instantiate adapted handles
however as they incur significant runtime overhead.

Niall

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a05cae3e-4f13-40ee-84c8-7bd2097aad73%40isocpp.org.

------=_Part_5235_1826968430.1505860097825
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, September 19, 2017 at 12:59:04 AM UTC+1, Bruce=
 Adams wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
Possibly slightly off topic but bear with me.<br>Do C, C++ and Posix requir=
e a way to re-open a file descriptor?<br></div></blockquote><div><br></div>=
<div>POSIX does not.</div><div><br></div><div>Windows does via an undocumen=
ted set of parameters for NtOpenFile(). This undocumented use case proved s=
o popular it was formalised into the Win32 ReOpenFile().</div><div>=C2=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br>The t=
wo common cases are:<br>* I have a file and after reading it I may decide I=
 want to write it after all.<br>* I create a new file and having finished s=
etting it up I want to make it read only.<br><br>Recent discussions about r=
ace free file systems have made me more aware of the potential problems wit=
h this.<br>When going from read to write you do need a permission check but=
 the other way around you do not.<br><br>Ideally
 you should be able to re-open based on the file handle or descriptor to
 avoid a race if the file is moved, renamed or deleted.<br>This is similar =
to the situation with moving locks from shared read to write and back that =
can also be weak on Posix.<br></div></blockquote><div><br></div><div>Right =
now, on POSIX, the only way to achieve this is to loop fetching the path, o=
pening it, and comparing st_ino and st_dev for equivalence.</div><div><br><=
/div><div>This ought to not be too bad. Linux opens a fd in single digit mi=
croseconds. Windows is two orders of magnitude slower, even with ReOpenFile=
().</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div=
 dir=3D"ltr"><br>I can&#39;t see this functionality in AFIO. Was it conside=
red? Perhaps rejected because there is not currently a portable solution?<b=
r></div></blockquote><div><br></div><div>Honestly it&#39;s because nobody m=
ade me think of it until now.</div><div><br></div><div>Expect to see it lan=
d by end of week at the latest :) It&#39;s trivially easy to implement. It&=
#39;s a good idea, and thanks for suggesting it.</div><div><br></div><div>B=
TW Thiago you may be interested to learn that I wrote a template adapter wh=
ich lets you adapt any afio::handle to no longer rely on path retrieval wor=
king (correctly/at all). It&#39;s on the user to instantiate adapted handle=
s however as they incur significant runtime overhead.</div><div><br></div><=
div>Niall=C2=A0</div><div><br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a05cae3e-4f13-40ee-84c8-7bd2097aad73%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a05cae3e-4f13-40ee-84c8-7bd2097aad73=
%40isocpp.org</a>.<br />

------=_Part_5235_1826968430.1505860097825--

------=_Part_5234_1592095472.1505860097825--

.

On Tuesday, 19 September 2017 15:28:17 PDT Niall Douglas wrote:
> BTW Thiago you may be interested to learn that I wrote a template adapter
> which lets you adapt any afio::handle to no longer rely on path retrieval
> working (correctly/at all). It's on the user to instantiate adapted handles
> however as they incur significant runtime overhead.

My kernel developer colleagues advised against relying on readlink(2) on
/proc/self/fd. It's not meant for the purpose you want it to. So my
recommendation is that you redesign so that retrieving the path name is an
optional and possibly-failing feature.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2579084.KATNCcGOsE%40tjmaciei-mobl1.

.

------=_Part_4996_1315395966.1505869907752
Content-Type: multipart/alternative;
 boundary="----=_Part_4997_1155077769.1505869907753"

------=_Part_4997_1155077769.1505869907753
Content-Type: text/plain; charset="UTF-8"


>
>
>> I can't see this functionality in AFIO. Was it considered? Perhaps
>> rejected because there is not currently a portable solution?
>>
>
> Honestly it's because nobody made me think of it until now.
>
> Expect to see it land by end of week at the latest :) It's trivially easy
> to implement. It's a good idea, and thanks for suggesting it.
>

Now in master branch, documented
at https://ned14.github.io/afio/classafio__v2__xxx_1_1file__handle.html#ae1053e7ccf8805ab03f51a6b917de53a

> BTW Thiago you may be interested to learn that I wrote a template adapter
> > which lets you adapt any afio::handle to no longer rely on path
> retrieval
> > working (correctly/at all). It's on the user to instantiate adapted
> handles
> > however as they incur significant runtime overhead.
>
> My kernel developer colleagues advised against relying on readlink(2) on
> /proc/self/fd. It's not meant for the purpose you want it to. So my
> recommendation is that you redesign so that retrieving the path name is an
> optional and possibly-failing feature.


As I explained before, you cannot race free unlink or rename without it.
And that's a data destroying kind of race, let alone the security
implications.

As I've also explained before, I've soak tested /proc/self/fd under a very
rapidly changing filesystem on Linux as far back as the 2.6 kernels and it
works just fine. If end users don't like it, it's trivial to override
current_path() in a subclass returning a stored path by the subclass, or
now to use the provided template adaptor class, or just turn off it being
used at all via passing in flags requesting it not be used at handle
creation.

I think that's plenty of options for end users. Nobody has to use it or
rely on it.

Regarding whether it should be the default or not, I think we should always
default to safety. The implementation is carefully written to detect
instability and fail. Your program may error out, but no data will be lost.
That's a very sensible default in my book. The programmer should be the one
to explicitly opt out of default safety.

Niall

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a85463fd-4585-4f79-9e1a-c4f2bcea4dcb%40isocpp.org.

------=_Part_4997_1155077769.1505869907753
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>I can&#39;=
t see this functionality in AFIO. Was it considered? Perhaps rejected becau=
se there is not currently a portable solution?<br></div></blockquote><div><=
br></div><div>Honestly it&#39;s because nobody made me think of it until no=
w.</div><div><br></div><div>Expect to see it land by end of week at the lat=
est :) It&#39;s trivially easy to implement. It&#39;s a good idea, and than=
ks for suggesting it.</div></div></blockquote><div><br></div><div>Now in ma=
ster branch, documented at=C2=A0https://ned14.github.io/afio/classafio__v2_=
_xxx_1_1file__handle.html#ae1053e7ccf8805ab03f51a6b917de53a</div><div><br><=
/div><div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.=
8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">&gt; BT=
W Thiago you may be interested to learn that I wrote a template adapter=C2=
=A0<br>&gt; which lets you adapt any afio::handle to no longer rely on path=
 retrieval=C2=A0<br>&gt; working (correctly/at all). It&#39;s on the user t=
o instantiate adapted handles=C2=A0<br>&gt; however as they incur significa=
nt runtime overhead.=C2=A0<br><br>My kernel developer colleagues advised ag=
ainst relying on readlink(2) on=C2=A0<br>/proc/self/fd. It&#39;s not meant =
for the purpose you want it to. So my=C2=A0<br>recommendation is that you r=
edesign so that retrieving the path name is an=C2=A0<br>optional and possib=
ly-failing feature.=C2=A0</blockquote><div><br></div><div>As I explained be=
fore, you cannot race free unlink or rename without it. And that&#39;s a da=
ta destroying kind of race, let alone the security implications.</div><div>=
<br></div><div>As I&#39;ve also explained before, I&#39;ve soak tested /pro=
c/self/fd under a very rapidly changing filesystem on Linux as far back as =
the 2.6 kernels and it works just fine. If end users don&#39;t like it, it&=
#39;s trivial to override current_path() in a subclass returning a stored p=
ath by the subclass, or now to use the provided template adaptor class, or =
just turn off it being used at all via passing in flags requesting it not b=
e used at handle creation.</div><div><br></div><div>I think that&#39;s plen=
ty of options for end users. Nobody has to use it or rely on it.</div><div>=
<br></div><div>Regarding whether it should be the default or not, I think w=
e should always default to safety. The implementation is carefully written =
to detect instability and fail. Your program may error out, but no data wil=
l be lost. That&#39;s a very sensible default in my book. The programmer sh=
ould be the one to explicitly opt out of default safety.</div><div><br></di=
v></div><div>Niall</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a85463fd-4585-4f79-9e1a-c4f2bcea4dcb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a85463fd-4585-4f79-9e1a-c4f2bcea4dcb=
%40isocpp.org</a>.<br />

------=_Part_4997_1155077769.1505869907753--

------=_Part_4996_1315395966.1505869907752--

.