Resource manager pemissions?

I am developing a resource manager and don’t understand why resmgr_attach
fails some times. When run by root, it runs without complaint, and creates
a mount point in /dev or anywhere I like. When run by a normal user, it
complains (with perror):

“Operation not permitted.”
Now if I chmod +s and chown root the file, the same binary when run by a
non-superuser gives:

“Could not find library …so.1”
where … is the name of a custom library that is linked to this server.

Now this makes debugging in the IDE quite a pain, since I don’t want to run
IDE as root. Questions abound.

Why does resmgr_attach fail at all when run as non-root?
Why doesn’t setuid root solve the problem?
How on earth can it run fine in one case and then fail to find a library in
another?

I’m using very simple code modified only slightly from the resource manager
examples, but it seems likely its my own mistakes. What should I look for?

David

David Cawlfield wrote:

I am developing a resource manager and don’t understand why resmgr_attach
fails some times. When run by root, it runs without complaint, and creates
a mount point in /dev or anywhere I like. When run by a normal user, it
complains (with perror):

“Operation not permitted.”
Now if I chmod +s and chown root the file, the same binary when run by a
non-superuser gives:

“Could not find library …so.1”
where … is the name of a custom library that is linked to this server.

Now this makes debugging in the IDE quite a pain, since I don’t want to run
IDE as root. Questions abound.

Why does resmgr_attach fail at all when run as non-root?

Because resmgr_attach is a priviledged operation (RTFM); or perhaps you are
curious about the underlying rationale for having resmgr_attach be a
priviledged operation ?

Why doesn’t setuid root solve the problem?

It does (i.e. it gives the caller sufficient priviledge to successfully
invoke resmgr_attach).

How on earth can it run fine in one case and then fail to find a library in
another?

A couple of reasons off the top of my head:

  1. a component of the path to the library is not readable by the user id
    that started the resmgr.

  2. LD_LIBRARY_PATH is different (i.e. correct) when logged in as root
    (different .profiles perhaps ?).