I agree. I wasn't aware of that restriction.
regards,
Thomas Hallgren
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Thomas Hallgren" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, June 09, 2004 15:5
"Thomas Hallgren" <[EMAIL PROTECTED]> writes:
> And only the super user can use directory components in a module name?
Only superusers can create C functions in the first place, so quibbling
about what paths they can use doesn't seem that useful ...
regards, tom lane
And only the super user can use directory components in a module name?
regards,
Thomas Hallgren
"Andrew Dunstan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
>
> Thomas Hallgren wrote:
>
> >Isn't the fact that "dynamic_library_path" can
> >be changed at any time by a user a seri
Thomas Hallgren wrote:
Isn't the fact that "dynamic_library_path" can
be changed at any time by a user a serious security flaw?
It's not "a user". Only the superuser can change it.
cheers
andrew
---(end of broadcast)---
TIP 2: you can get off all
"Tommi Maekitalo" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> in linux you can change LD_LIBRARY_PATH in a running process, but it does
not
> help. The library-loader initializes himself at process-startup and
changing
> LD_LIBRARY_PATH do not change the actual path, the process is using for
> dlopen.
>
T
Hi,
in linux you can change LD_LIBRARY_PATH in a running process, but it does not
help. The library-loader initializes himself at process-startup and changing
LD_LIBRARY_PATH do not change the actual path, the process is using for
dlopen.
Tommi Mäkitalo
Am Dienstag, 8. Juni 2004 19:14 schrieb
assure backward compatibility to keep everyone happy.
Kind regards,
Thomas Hallgren
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Thomas Hallgren" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, June 09, 2004 7:24 AM
Subject:
"Thomas Hallgren" <[EMAIL PROTECTED]> writes:
>> ... Furthermore, AFAICT shl_load()
>> requires an exact path spec for the initial shared library; it won't
>> do a path search for that, only for dependencies.)
>>
> Here's an excerpt from the HPUX manual pages on dlopen(3C).
HPUX which? There is
> The variations among platforms are great enough that I don't think you
> can make such an assertion.
>
> (To take one example, HPUX does have a variable like this --- they call
> it SHLIB_PATH --- but it *is not used* unless a flag enabling it was
> provided when the shlib was linked, and I thin
"Andrew Dunstan" <[EMAIL PROTECTED]> wrote:
> And many people just hate playing games with LD_LIBRARY_PATH, and even
> more hate apps that do it.
>
The current design forces me and anyone else who wants a module that depends
on shared libraries to play these games. My suggestion is that we hide thi
"Thomas Hallgren" <[EMAIL PROTECTED]> writes:
> The LD_LIBRARY_PATH or PATH depending on system (Posix or Windows) that is
> effective when the dlopen function is called. All OS'es where shared
> libraries are possible have something similar.
The variations among platforms are great enough that I
From: "Bruce Momjian" <[EMAIL PROTECTED]>
>
> I think the idea is that you want to specify the path in the config
> file, after the app has already started. I don't think you can modify
> the environment variable after the app has started, and even if you can,
> it seems simpler to just do it in o
> "Thomas Hallgren" <[EMAIL PROTECTED]> writes:
> > Why does postgres maintain a loader logic of its own? I can understand
that
> > the dynamic_library_path is necessary in order to configure everything
in
> > one single place. But why not just merge it with the LD_LIBRARY_PATH (or
> > PATH on Wind
"Thomas Hallgren" <[EMAIL PROTECTED]> writes:
> Why does postgres maintain a loader logic of its own? I can understand that
> the dynamic_library_path is necessary in order to configure everything in
> one single place. But why not just merge it with the LD_LIBRARY_PATH (or
> PATH on Windows) and t
Bruce Momjian wrote:
Thomas Hallgren wrote:
Why does postgres maintain a loader logic of its own? I can understand that
the dynamic_library_path is necessary in order to configure everything in
one single place. But why not just merge it with the LD_LIBRARY_PATH (or
PATH on Windows) and then let
Thomas Hallgren wrote:
> Why does postgres maintain a loader logic of its own? I can understand that
> the dynamic_library_path is necessary in order to configure everything in
> one single place. But why not just merge it with the LD_LIBRARY_PATH (or
> PATH on Windows) and then let dlopen do the r
Why does postgres maintain a loader logic of its own? I can understand that
the dynamic_library_path is necessary in order to configure everything in
one single place. But why not just merge it with the LD_LIBRARY_PATH (or
PATH on Windows) and then let dlopen do the rest using a stripped filename?
17 matches
Mail list logo
