On Fri, Sep 14, 2012 at 6:35 AM, Glenn Fowler <g...@research.att.com> wrote:
>
> On Fri, 14 Sep 2012 06:23:46 +0200 Roland Mainz wrote:
>> On Fri, Sep 14, 2012 at 6:01 AM, Roland Mainz <roland.ma...@nrubsig.org>
>> wrote:
>> > Attached (as "astksh_chroot_cd_devfd_cd_f_20120911_001.diff.txt") is a
>> > patch which fixes two issues with "cd":
>> > 1. $ cd /dev/fd/$fd # doesn't work in chroot'ed environments when
>> > /dev/fd is not mounted (thanks to CERN staff for reporting this).
>> > 2. POSIX does not mandate _any_ paths. Since doing a "cd" relative to
>> > a directory fd has become very popular the request was made to add an
>> > alternative to using /dev/fd which is more or less acceptable for the
>> > POSIX people. Based on that and a few discussions I added the option
>> > -f to cd that a directory descriptor can be passed and the path given
>> > is relative to that file descriptor.
>> >
>> > Notes:
>> > - The code introduces a new function called |pathdevfd2relpathfd()| in
>> > libast which can extract the fd number from a /dev/fd/$fd path (even
>> > nested)
>> > - If files or directories are opened relative to /dev/fd/$fd/$path
>> > |sfopen()|/|sfopenat()| will now bypass the /dev/fd filesystem
>> > completely (which gives a nice performance boost). The only exception
>> > is that this can *NOT* be done for a plain /dev/fd/$fd, e.g.
>> > /dev/fd/15. The problem is that there is AFAIK no way to open a file
>> > from a file descriptor without using the /dev/fd filesystem or using
>> > |dup()| ... but |dup()| rules itself out because the resulting
>> > "cloned" fd still shares attributes like the current seek position
>> > with the original fd...
>> >
>> > Glenn: Is it acceptable for |sfopen()| to |dup()| the incoming file fd
>> > (see "Notes" above) ?
>
>> More details on the problem with |dup()| sharing attributes like the
>> seek position between both old and new fd:
>> - I tested /dev/fd on Linux (SuSE 12.1) ... it seems that |dup(15)| is
>> not identical to |open("/dev/fd/15", ...)| ... as expected the seek
>> position is shared for |dup()| but the fd returned by |open()| has
>> it's own seek position
>> - AFAIK the issue is irrelevant for pipes/fifos/sockets... right ?
>> - What about using |pread()|/|pwrite()| instead of |read()|/|write()|
>> on normal, plain files ? This would bypass the issue with the seek
>> position being shared...
>
> sfio uses lseek() to maintain stream consistency
> if
> s1 = sfopen(0, "foo", ...);
> s2 = sfopen(0, "foo", ...);
> gave the same dup'd fd to both s1 and s2 then all havoc would break loose
> remember that streams and associated offsets may cross fork/exec
> so its not just a simple matter of maintaining the offset in user space
> and using pread/pwrite
Ok... thanks...I feared that this is the case...
... so the official way for scripts in chroot trying to work with
_files_ (directories are OK... since my patch fixed that) via /dev/fd
is then to xx@@!!-mount /proc or use the mkfifo builtin.
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.ma...@nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
_______________________________________________
ast-developers mailing list
ast-developers@research.att.com
https://mailman.research.att.com/mailman/listinfo/ast-developers
