LD_PRELOADed code before or after exec - different behavior after 6.x
head sl.cc pe.c
==> sl.cc <==
#include
#include
class C
{
public:
C(){
printf("C\n");
unsetenv("XXX");
}
};
static C c;
==> pe.c <==
#include
#include
int
main()
{
char *p=getenv("XXX");
if (p != NULL)
printf("XXX=%s\n",p);
return 0;
}
% g++ -fpic -shared sl.cc -o sl.so
% gcc pe.c -o pe
7.x & 8.x ...
% sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so pe'
C
XXX=1
6.x & 4.x ...
% sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so pe'
C
In 6.x and earlier (fedora 16, too), the unsetenv clears the XXX env
var apparently in time to affect the exec'd process. In 8.x & 9.x, it
seems the environment is set and passed to the exec'd process and the
LD_PRELOADed code does not affect that despite its best efforts.
It seems to me that 6.x behavior is more correct, but I'm seeking
opinions before contemplating if / how to put together a fix.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: LD_PRELOADed code before or after exec - different behavior after 6.x
John Hein wrote at 09:17 -0600 on Aug 24, 2012:
>
> head sl.cc pe.c
> ==> sl.cc <==
> #include
> #include
> class C
> {
> public:
> C(){
> printf("C\n");
> unsetenv("XXX");
> }
> };
> static C c;
>
> ==> pe.c <==
> #include
> #include
> int
> main()
> {
> char *p=getenv("XXX");
> if (p != NULL)
>printf("XXX=%s\n",p);
> return 0;
> }
>
>
> % g++ -fpic -shared sl.cc -o sl.so
> % gcc pe.c -o pe
>
> 7.x & 8.x ...
> % sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so pe'
> C
> XXX=1
I meant to write:
7.x & 8.x ...
% sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so pe'
C
% sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so exec pe'
C
XXX=1
> 6.x & 4.x ...
> % sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so pe'
> C
and
6.x & 4.x ...
% sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so pe'
C
% sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so exec pe'
C
> In 6.x and earlier (fedora 16, too), the unsetenv clears the XXX env
> var apparently in time to affect the exec'd process. In 8.x & 9.x, it
> seems the environment is set and passed to the exec'd process and the
> LD_PRELOADed code does not affect that despite its best efforts.
>
> It seems to me that 6.x behavior is more correct, but I'm seeking
> opinions before contemplating if / how to put together a fix.
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: LD_PRELOADed code before or after exec - different behavior after 6.x
John Hein wrote at 09:34 -0600 on Aug 24, 2012:
> John Hein wrote at 09:17 -0600 on Aug 24, 2012:
> >
> > head sl.cc pe.c
> > ==> sl.cc <==
> > #include
> > #include
> > class C
> > {
> > public:
> > C(){
> > printf("C\n");
> > unsetenv("XXX");
> > }
> > };
> > static C c;
> >
> > ==> pe.c <==
> > #include
> > #include
> > int
> > main()
> > {
> > char *p=getenv("XXX");
> > if (p != NULL)
> >printf("XXX=%s\n",p);
> > return 0;
> > }
> >
> >
> > % g++ -fpic -shared sl.cc -o sl.so
> > % gcc pe.c -o pe
> >
> > 7.x & 8.x ...
> > % sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so pe'
> > C
> > XXX=1
>
> I meant to write:
>
> 7.x & 8.x ...
> % sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so pe'
> C
> % sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so exec pe'
> C
> XXX=1
>
> > 6.x & 4.x ...
> > % sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so pe'
> > C
>
> and
> 6.x & 4.x ...
> % sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so pe'
> C
> % sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so exec pe'
> C
Argh. Never mind. I was correct the first time. The shell's exec
doesn't matter...
7.x & 8.x ...
% sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so pe'
C
XXX=1
% sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so exec pe'
C
XXX=1
6.x & 4.x ...
% sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so pe'
C
% sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so exec pe'
C
> > In 6.x and earlier (fedora 16, too), the unsetenv clears the XXX env
> > var apparently in time to affect the exec'd process. In 8.x & 9.x, it
> > seems the environment is set and passed to the exec'd process and the
> > LD_PRELOADed code does not affect that despite its best efforts.
> >
> > It seems to me that 6.x behavior is more correct, but I'm seeking
> > opinions before contemplating if / how to put together a fix.
> >
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: LD_PRELOADed code before or after exec - different behavior after 6.x
On Fri, Aug 24, 2012 at 09:17:22AM -0600, John Hein wrote:
>
> head sl.cc pe.c
> ==> sl.cc <==
> #include
> #include
> class C
> {
> public:
> C(){
> printf("C\n");
> unsetenv("XXX");
> }
> };
> static C c;
>
> ==> pe.c <==
> #include
> #include
> int
> main()
> {
> char *p=getenv("XXX");
> if (p != NULL)
>printf("XXX=%s\n",p);
> return 0;
> }
>
>
> % g++ -fpic -shared sl.cc -o sl.so
> % gcc pe.c -o pe
>
> 7.x & 8.x ...
> % sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so pe'
> C
> XXX=1
>
> 6.x & 4.x ...
> % sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so pe'
> C
>
>
> In 6.x and earlier (fedora 16, too), the unsetenv clears the XXX env
> var apparently in time to affect the exec'd process. In 8.x & 9.x, it
> seems the environment is set and passed to the exec'd process and the
> LD_PRELOADed code does not affect that despite its best efforts.
>
> It seems to me that 6.x behavior is more correct, but I'm seeking
> opinions before contemplating if / how to put together a fix.
>
I suppose that this is a fallback from the POSIXification of putenv().
The libc image of the environment block is now referenced through
the environ var. Since csu always reinitialize the environ, effect
of the changes made by preloaded dso is cleared.
At the end of the message is the patch for HEAD which seems to fix the
issue. It is not applicable to stable/9 or 8. You could try to change
lib/csu//crt1.c to replace unconditional
environ = env;
assignment with
if (environ == NULL)
environ = env;
.
Unfortunately, because csu is linked to the binary, you have to relink
the binary after applying the patch and rebuilding the world. In other
words, old binaries cannot be fixed.
Committing this requires secteam@ review, AFAIR.
diff --git a/lib/csu/amd64/crt1.c b/lib/csu/amd64/crt1.c
index f33aad6..3740e73 100644
--- a/lib/csu/amd64/crt1.c
+++ b/lib/csu/amd64/crt1.c
@@ -61,9 +61,7 @@ _start(char **ap, void (*cleanup)(void))
argc = *(long *)(void *)ap;
argv = ap + 1;
env = ap + 2 + argc;
- environ = env;
- if (argc > 0 && argv[0] != NULL)
- handle_progname(argv[0]);
+ handle_argv(argc, argv, env);
if (&_DYNAMIC != NULL)
atexit(cleanup);
diff --git a/lib/csu/arm/crt1.c b/lib/csu/arm/crt1.c
index 127c28d..e3529b8 100644
--- a/lib/csu/arm/crt1.c
+++ b/lib/csu/arm/crt1.c
@@ -98,10 +98,7 @@ __start(int argc, char **argv, char **env, struct ps_strings
*ps_strings,
const struct Struct_Obj_Entry *obj __unused, void (*cleanup)(void))
{
- environ = env;
-
- if (argc > 0 && argv[0] != NULL)
- handle_progname(argv[0]);
+ handle_argv(argc, argv, env);
if (ps_strings != (struct ps_strings *)0)
__ps_strings = ps_strings;
diff --git a/lib/csu/common/ignore_init.c b/lib/csu/common/ignore_init.c
index e3d2441..89b3734 100644
--- a/lib/csu/common/ignore_init.c
+++ b/lib/csu/common/ignore_init.c
@@ -87,14 +87,18 @@ handle_static_init(int argc, char **argv, char **env)
}
static inline void
-handle_progname(const char *v)
+handle_argv(int argc, char *argv[], char **env)
{
const char *s;
- __progname = v;
- for (s = __progname; *s != '\0'; s++) {
- if (*s == '/')
- __progname = s + 1;
+ if (environ == NULL)
+ environ = env;
+ if (argc > 0 && argv[0] != NULL) {
+ __progname = argv[0];
+ for (s = __progname; *s != '\0'; s++) {
+ if (*s == '/')
+ __progname = s + 1;
+ }
}
}
diff --git a/lib/csu/i386-elf/crt1_c.c b/lib/csu/i386-elf/crt1_c.c
index 3249069..65de04c 100644
--- a/lib/csu/i386-elf/crt1_c.c
+++ b/lib/csu/i386-elf/crt1_c.c
@@ -61,10 +61,7 @@ _start1(fptr cleanup, int argc, char *argv[])
char **env;
env = argv + argc + 1;
- environ = env;
- if (argc > 0 && argv[0] != NULL)
- handle_progname(argv[0]);
-
+ handle_argv(argc, argv, env);
if (&_DYNAMIC != NULL)
atexit(cleanup);
else
diff --git a/lib/csu/mips/crt1.c b/lib/csu/mips/crt1.c
index 1968f06..95348b7 100644
--- a/lib/csu/mips/crt1.c
+++ b/lib/csu/mips/crt1.c
@@ -71,9 +71,7 @@ __start(char **ap,
argc = * (long *) ap;
argv = ap + 1;
env = ap + 2 + argc;
- environ = env;
- if (argc > 0 && argv[0] != NULL)
- handle_progname(argv[0]);
+ handle_argv(argc, argv, env);
if (&_DYNAMIC != NULL)
atexit(cleanup);
diff --git a/lib/csu/powerpc/crt1.c b/lib/csu/powerpc/crt1.c
index c3be90d..d1a3ea0 100644
--- a/lib/csu/powerpc/crt1.c
+++ b/lib/csu/powerpc/crt1.c
@@ -81,10 +81,8 @@ _start(int argc, char **argv, char **env,
struct ps_strings *ps_strings)
{
- environ = env;
- if (argc > 0 && argv[0] != NULL)
- handle_progname(argv[0]);
+ h
Re: LD_PRELOADed code before or after exec - different behavior after 6.x
Answers inline...
Konstantin Belousov wrote at 19:23 +0300 on Aug 24, 2012:
> On Fri, Aug 24, 2012 at 09:17:22AM -0600, John Hein wrote:
> >
> > head sl.cc pe.c
> > ==> sl.cc <==
> > #include
> > #include
> > class C
> > {
> > public:
> > C(){
> > printf("C\n");
> > unsetenv("XXX");
> > }
> > };
> > static C c;
> >
> > ==> pe.c <==
> > #include
> > #include
> > int
> > main()
> > {
> > char *p=getenv("XXX");
> > if (p != NULL)
> >printf("XXX=%s\n",p);
> > return 0;
> > }
> >
> >
> > % g++ -fpic -shared sl.cc -o sl.so
> > % gcc pe.c -o pe
> >
> > 7.x & 8.x ...
> > % sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so pe'
> > C
> > XXX=1
> >
> > 6.x & 4.x ...
> > % sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so pe'
> > C
> >
> >
> > In 6.x and earlier (fedora 16, too), the unsetenv clears the XXX env
> > var apparently in time to affect the exec'd process. In 8.x & 9.x, it
> > seems the environment is set and passed to the exec'd process and the
> > LD_PRELOADed code does not affect that despite its best efforts.
> >
> > It seems to me that 6.x behavior is more correct, but I'm seeking
> > opinions before contemplating if / how to put together a fix.
> >
> I suppose that this is a fallback from the POSIXification of putenv().
> The libc image of the environment block is now referenced through
> the environ var. Since csu always reinitialize the environ, effect
> of the changes made by preloaded dso is cleared.
>
> At the end of the message is the patch for HEAD which seems to fix the
> issue. It is not applicable to stable/9 or 8. You could try to change
> lib/csu//crt1.c to replace unconditional
> environ = env;
> assignment with
> if (environ == NULL)
> environ = env;
> .
Thanks. This fixes my reported problem - tested on 8.x.
> Unfortunately, because csu is linked to the binary, you have to relink
> the binary after applying the patch and rebuilding the world. In other
> words, old binaries cannot be fixed.
>
> Committing this requires secteam@ review, AFAIR.
Indeed this could be a sec issue if someone relies on preloaded
code clearing something in the environment. secteam CC'd
> diff --git a/lib/csu/amd64/crt1.c b/lib/csu/amd64/crt1.c
> index f33aad6..3740e73 100644
> --- a/lib/csu/amd64/crt1.c
> +++ b/lib/csu/amd64/crt1.c
> @@ -61,9 +61,7 @@ _start(char **ap, void (*cleanup)(void))
> argc = *(long *)(void *)ap;
> argv = ap + 1;
> env = ap + 2 + argc;
> -environ = env;
> -if (argc > 0 && argv[0] != NULL)
> -handle_progname(argv[0]);
> +handle_argv(argc, argv, env);
>
> if (&_DYNAMIC != NULL)
> atexit(cleanup);
> diff --git a/lib/csu/arm/crt1.c b/lib/csu/arm/crt1.c
> index 127c28d..e3529b8 100644
> --- a/lib/csu/arm/crt1.c
> +++ b/lib/csu/arm/crt1.c
> @@ -98,10 +98,7 @@ __start(int argc, char **argv, char **env, struct
> ps_strings *ps_strings,
> const struct Struct_Obj_Entry *obj __unused, void (*cleanup)(void))
> {
>
> -environ = env;
> -
> -if (argc > 0 && argv[0] != NULL)
> -handle_progname(argv[0]);
> +handle_argv(argc, argv, env);
>
> if (ps_strings != (struct ps_strings *)0)
> __ps_strings = ps_strings;
> diff --git a/lib/csu/common/ignore_init.c b/lib/csu/common/ignore_init.c
> index e3d2441..89b3734 100644
> --- a/lib/csu/common/ignore_init.c
> +++ b/lib/csu/common/ignore_init.c
> @@ -87,14 +87,18 @@ handle_static_init(int argc, char **argv, char **env)
> }
>
> static inline void
> -handle_progname(const char *v)
> +handle_argv(int argc, char *argv[], char **env)
> {
> const char *s;
>
> -__progname = v;
> -for (s = __progname; *s != '\0'; s++) {
> -if (*s == '/')
> -__progname = s + 1;
> +if (environ == NULL)
> +environ = env;
> +if (argc > 0 && argv[0] != NULL) {
> +__progname = argv[0];
> +for (s = __progname; *s != '\0'; s++) {
> +if (*s == '/')
> +__progname = s + 1;
> +}
> }
> }
>
> diff --git a/lib/csu/i386-elf/crt1_c.c b/lib/csu/i386-elf/crt1_c.c
> index 3249069..65de04c 100644
> --- a/lib/csu/i386-elf/crt1_c.c
> +++ b/lib/csu/i386-elf/crt1_c.c
> @@ -61,10 +61,7 @@ _start1(fptr cleanup, int argc, char *argv[])
> char **env;
>
> env = argv + argc + 1;
> -environ = env;
> -if (argc > 0 && argv[0] != NULL)
> -handle_progname(argv[0]);
> -
> +handle_argv(argc, argv, env);
> if (&_DYNAMIC != NULL)
> atexit(cleanup);
> else
> diff --git a/lib/csu/mips/crt1.c b/lib/csu/mips/crt1.c
> index 1968f06..95348b7 100644
> --- a/lib/csu/mips/crt1.c
> +++ b/lib/csu/mips/crt1.c
> @@ -71,9 +71,7 @@ __start(char **ap,
> argc = * (long *) ap;
> argv = ap + 1;
> env = ap + 2 +
[patch] libc: Do not export .cerror
For some reason, libc exports the symbol .cerror (HIDENAME(cerror)), albeit in the FBSDprivate_1.0 version. It looks like there is no reason for this since it is not used from other libraries. Given that it cannot be accessed from C and its strange calling convention, it is rather unlikely that other things rely on it. Perhaps it is from a time when symbols could not be hidden. Not exporting .cerror causes it to be jumped to directly instead of via the PLT. The below patch is for i386 only and also takes advantage of .cerror's new status by not saving and loading %ebx before jumping to it. (Therefore, .cerror now saves and loads %ebx itself.) Where there was a conditional jump to a jump to .cerror, the conditional jump has been changed to jump to .cerror directly (many modern CPUs don't do static prediction and in any case it is not much of a benefit anyway). The patch decreases the size of libc.so.7 by a few kilobytes. Similar changes could be made to other architectures, and there may be more symbols that are exported but need not be. Index: lib/libc/i386/Symbol.map === --- lib/libc/i386/Symbol.map(revision 239195) +++ lib/libc/i386/Symbol.map(working copy) @@ -63,7 +63,6 @@ __sys_vfork; _vfork; _end; - .cerror; _brk; .curbrk; .minbrk; Index: lib/libc/i386/SYS.h === --- lib/libc/i386/SYS.h (revision 239195) +++ lib/libc/i386/SYS.h (working copy) @@ -36,21 +36,21 @@ #include #include -#defineSYSCALL(x) 2: PIC_PROLOGUE; jmp PIC_PLT(HIDENAME(cerror)); \ - ENTRY(__CONCAT(__sys_,x)); \ +#defineSYSCALL(x) ENTRY(__CONCAT(__sys_,x)); \ .weak CNAME(x); \ .set CNAME(x),CNAME(__CONCAT(__sys_,x));\ .weak CNAME(__CONCAT(_,x)); \ .set CNAME(__CONCAT(_,x)),CNAME(__CONCAT(__sys_,x)); \ - mov __CONCAT($SYS_,x),%eax; KERNCALL; jb 2b + mov __CONCAT($SYS_,x),%eax; KERNCALL; \ + jb HIDENAME(cerror) #defineRSYSCALL(x) SYSCALL(x); ret; END(__CONCAT(__sys_,x)) -#definePSEUDO(x) 2: PIC_PROLOGUE; jmp PIC_PLT(HIDENAME(cerror)); \ - ENTRY(__CONCAT(__sys_,x)); \ +#definePSEUDO(x) ENTRY(__CONCAT(__sys_,x)); \ .weak CNAME(__CONCAT(_,x)); \ .set CNAME(__CONCAT(_,x)),CNAME(__CONCAT(__sys_,x)); \ - mov __CONCAT($SYS_,x),%eax; KERNCALL; jb 2b; ret; \ + mov __CONCAT($SYS_,x),%eax; KERNCALL; \ + jb HIDENAME(cerror); ret; \ END(__CONCAT(__sys_,x)) /* gas messes up offset -- although we don't currently need it, do for BCS */ Index: lib/libc/i386/gen/rfork_thread.S === --- lib/libc/i386/gen/rfork_thread.S(revision 239195) +++ lib/libc/i386/gen/rfork_thread.S(working copy) @@ -113,8 +113,7 @@ popl%esi movl%ebp, %esp popl%ebp - PIC_PROLOGUE - jmp PIC_PLT(HIDENAME(cerror)) + jmp HIDENAME(cerror) END(rfork_thread) .section .note.GNU-stack,"",%progbits Index: lib/libc/i386/sys/brk.S === --- lib/libc/i386/sys/brk.S (revision 239195) +++ lib/libc/i386/sys/brk.S (working copy) @@ -58,14 +58,11 @@ ok: mov $SYS_break,%eax KERNCALL - jb err + jb HIDENAME(cerror) movl4(%esp),%eax movl%eax,(%edx) movl$0,%eax ret -err: - PIC_PROLOGUE - jmp PIC_PLT(HIDENAME(cerror)) #else @@ -77,13 +74,11 @@ ok: mov $SYS_break,%eax KERNCALL - jb err + jb HIDENAME(cerror) movl4(%esp),%eax movl%eax,HIDENAME(curbrk) movl$0,%eax ret -err: - jmp HIDENAME(cerror) #endif END(brk) Index: lib/libc/i386/sys/getcontext.S === --- lib/libc/i386/sys/getcontext.S (revision 239195) +++ lib/libc/i386/sys/getcontext.S (working copy) @@ -42,12 +42,9 @@ movl(%esp),%ecx /* save getcontext return address */ mov $SYS_getcontext,%eax KERNCALL - jb 1f + jb HIDENAME(cerror) addl$4,%esp /* remove stale (setcontext) return address */ jmp *%ecx /* restore return address */ -1: - PIC_PROLOGUE - jmp PIC_PLT(H
webdav locking issues
I did try without success to ask some aspect of this on the questions list, but I'm farther along with this anyway. I have an apache22 server setup with webdav for a subversion server. That is working well (I think, anyway), and I'm able access it from a Winblows XP vm I use for various testing and so forth. I'm still trying to resolve some issues with Windows7, but it appears to work in the apache logs. Apache/webdav is setup with ssl and digest auth - no access unless auth'd. Locking appears to be working as well according to logs and cadaver. libreoffice won't build with java, and doesn't appear to like direct webdav access- certificate issues. But that dog won't hunt anyway due to the minimal user friendliness (if that is actually a term). Even with locking disabled the issue remains. wdfs is what is intended to use for general access (I'm open to suggestion though), and I have tried non-threaded operation, locking modes, no locking, and foreground operation. Without locking, the office's complain about io errors. Using the foreground operation of wdfs and the logs, I can see wdfs lock the file and retrieve it and attempt to lock it again. This errors badly obviously, and wdfs tells office's to come back with read only options. Quite frankly I need a little help on where to go from here. I'm trying to figure out what I'm missing exactly. ATM my best guess would be an issue with wdfs, but there isn't much on the google about it. Any thoughts? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
