Confused about shared library path

What’s the correct way to specify the path for shared libraries that we
build as part of our application? The executable needs to be setuid root,
which then seems to limit the searching for libraries. We need each
developer to be able to have a private copy of libraries in his home
directory tree, and have his executable pull in those libraries.
LD_LIBRARY_PATH seems to work if the executable is not setuid, but not if it
is. “setconf _CS_LIBPATH” works, but that is a global setting, not a
per-developer setting.

Help!


Marty Doane
Siemens Dematic

Marty Doane <martin.doane@siemens.com> wrote:

What’s the correct way to specify the path for shared libraries that we
build as part of our application? The executable needs to be setuid root,
which then seems to limit the searching for libraries. We need each
developer to be able to have a private copy of libraries in his home
directory tree, and have his executable pull in those libraries.
LD_LIBRARY_PATH seems to work if the executable is not setuid, but not if it
is. “setconf _CS_LIBPATH” works, but that is a global setting, not a
per-developer setting.

If security isn’t an issue on your box you could do this…

chmod u+s /usr/bin/op

…and then you can just use op as a the suid loader for your binary. That
will allow you to set LD_LIBRARY_PATH and still run the binary as root.

It does mean that any user can now do ANYTHING as root. :slight_smile: You could also
compile sudo and have a little more control over who can get root access.

Hope that helps.

chris


Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

Alternatively (which is the way I do it) I have a script that creates
proc links (they are like symbolic links, but disappear after a reboot).

eg:

#!/bin/sh -v
SDIR=/home/drempel/head

ln -sP $SDIR/stage/x86/usr/lib/libffb.so.2 /usr/lib/libffb.so.2
ln -sP $SDIR/stage/x86/usr/lib/libffb.so.2 /x86/usr/lib/libffb.so.2
ln -sP /usr/lib/libffb.so.2 /usr/lib/libffb.so

ln -sP $SDIR/stage/x86/usr/lib/libdisputil.so.2 /usr/lib/libdisputil.so.2
ln -sP $SDIR/stage/x86/usr/lib/libdisputil.so.2
/x86/usr/lib/libdisputil.so.2
ln -sP /usr/lib/libdisputil.so.2 /usr/lib/libdisputil.so

ln -sP $SDIR/stage/x86/usr/lib/libgri.so.2 /usr/lib/libgri.so.2
ln -sP $SDIR/stage/x86/usr/lib/libgri.so.2 /x86/usr/lib/libgri.so.2
ln -sP /usr/lib/libgri.so.2 /usr/lib/libgri.so

ln -sP $SDIR/stage/x86/usr/lib/libphrender.so.2 usr/lib/libphrender.so.2
ln -sP $SDIR/stage/x86/usr/lib/libphrender.so.2
/x86/usr/lib/libphrender.so.2
ln -sP /usr/lib/libphrender.so.2 /usr/lib/libphrender.so

(etc…)

this creates links that setuid root apps will be able to find, but don’t
pollute the real paths (can get back to a normal sane system with a
reboot) You will have to run this script as root (only root can create
proclinks).

Dave Rempel

Chris McKillop wrote:

Marty Doane <> martin.doane@siemens.com> > wrote:

What’s the correct way to specify the path for shared libraries that we
build as part of our application? The executable needs to be setuid root,
which then seems to limit the searching for libraries. We need each
developer to be able to have a private copy of libraries in his home
directory tree, and have his executable pull in those libraries.
LD_LIBRARY_PATH seems to work if the executable is not setuid, but not if it
is. “setconf _CS_LIBPATH” works, but that is a global setting, not a
per-developer setting.



If security isn’t an issue on your box you could do this…

chmod u+s /usr/bin/op

…and then you can just use op as a the suid loader for your binary. That
will allow you to set LD_LIBRARY_PATH and still run the binary as root.

It does mean that any user can now do ANYTHING as root. > :slight_smile: > You could also
compile sudo and have a little more control over who can get root access.

Hope that helps.

chris

“Chris McKillop” <cdm@qnx.com> wrote in message
news:bd8rcj$78m$1@nntp.qnx.com

Marty Doane <> martin.doane@siemens.com> > wrote:
What’s the correct way to specify the path for shared libraries that we
build as part of our application? The executable needs to be setuid
root,
which then seems to limit the searching for libraries. We need each
developer to be able to have a private copy of libraries in his home
directory tree, and have his executable pull in those libraries.
LD_LIBRARY_PATH seems to work if the executable is not setuid, but not
if it
is. “setconf _CS_LIBPATH” works, but that is a global setting, not a
per-developer setting.


If security isn’t an issue on your box you could do this…

chmod u+s /usr/bin/op

…and then you can just use op as a the suid loader for your binary. That
will allow you to set LD_LIBRARY_PATH and still run the binary as root.

It does mean that any user can now do ANYTHING as root. > :slight_smile: > You could also
compile sudo and have a little more control over who can get root access.

Hope that helps.

chris


Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

Well, /usr/bin/op works, but sudo does not. I’m not sure we can live with
that (lack of) security level.

The only choices I see are 1) give each developer root access, or 2) don’t
use shared libraries.


Marty Doane
Siemens Dematic

Well, /usr/bin/op works, but sudo does not. I’m not sure we can live with
that (lack of) security level.

Why doesn’t sudo work? If you use sudo to start a shell and launch the
app from that shell it should be running as root with whatever environment
you setup.

The only choices I see are 1) give each developer root access, or 2) don’t
use shared libraries.

Basically yes. Being able to change shared libs on a suid root binary
is a priv’d operation. There was a huge security hole pre-6.2.0 that
let you hack a system by putting in a fake libsocket in /tmp and
exec’ing a shell when ping was run. :slight_smile:

chris


Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

“Marty Doane” <martin.doane@siemens.com> wrote in message
news:bda83l$bkk$1@nntp.qnx.com

“Chris McKillop” <> cdm@qnx.com> > wrote in message
news:bd8rcj$78m$> 1@nntp.qnx.com> …
Marty Doane <> martin.doane@siemens.com> > wrote:
What’s the correct way to specify the path for shared libraries that
we
build as part of our application? The executable needs to be setuid
root,
which then seems to limit the searching for libraries. We need each
developer to be able to have a private copy of libraries in his home
directory tree, and have his executable pull in those libraries.
LD_LIBRARY_PATH seems to work if the executable is not setuid, but not
if it
is. “setconf _CS_LIBPATH” works, but that is a global setting, not a
per-developer setting.

The only choices I see are 1) give each developer root access, or 2) don’t
use shared libraries.

Unless I misunderstand you, your GOAL is to let each developer write and
compile his version of the library and then have it loaded by a program
running as root, right?

Well, since THAT gives the developer root access, obviously there’s no way
of doing it WITHOUT giving him root access!!!..

The only way to prevent a developer from spawning a root shell from his
shared library is by making sure that the process gives up its root
privileges before calling anything from the shared library. Even if that’s
an acceptable solution (it may be if the process only needs root privileges
during initialization), implementing it reliably can be tricky: consider
that a developer could use a C++ constructor or some other magic to run his
code before your main() gets a chance to call setuid(). The simplest way to
prevent that may be by using dlopen() instead of linking the executable with
the shared library – and dlopen() also allows you to specify the full path
to the shared object.

Why doesn’t sudo work?
If I set LD_LIBRARY_PATH and run “op myapp”, the application runs as

expected.
If I run “sudo myapp”, the libraries are not found.

If you use sudo to start a shell and launch the
app from that shell it should be running as root with whatever environment
you setup.
Do you mean “sudo -s” to get a root privilige shell, then within that shell

“myapp”?

  1. I don’t yet know how to configure that yet, and
  2. That doesn’t seem any better than giving out the root password and using
    “su”.

Basically yes. Being able to change shared libs on a suid root binary
is a priv’d operation. There was a huge security hole pre-6.2.0 that
let you hack a system by putting in a fake libsocket in /tmp and
exec’ing a shell when ping was run. > :slight_smile:
I understand.

I believe it’s not possible to do what I want and still maintain a
locked-down system. My goal has been to put restraints in place to help
developers to remember to respect policy.

Marty

Marty Doane <martin.doane@siemens.com> wrote:

Why doesn’t sudo work?
If I set LD_LIBRARY_PATH and run “op myapp”, the application runs as
expected.
If I run “sudo myapp”, the libraries are not found.

I don’t know why sudo doesn’t work, but op is really simple: it
basically calls setuid(0) followed by exec(). You can write your own
program that does the same but has some extra restrictions on what to
run and/or who to run it for.