Resource manager

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
1

I’m trying to test my first resource manager.
On resmgr_attach() I get the error “Operation not permitted”.
The manual states, that a resource manager has to be run as root
to be able to attach.
Well, started as root it works.

Why does it have this restriction?
IMHO it would be much more flexible,
if resmgr_attach() could respect the permissions
of the parent directory, where the new name is attached to.

I want to debug my resource managers
in a Neutrino based self hosted environement (Momentics PE 6.2.1b),
With this restriction I have to do it as root,
otherwise I’m not able to test my programms
directly from inside the IDE.

MfG
Werner Schweizer

2

“Werner Schweizer” <nospamWrnr.Schwzr@ch.mullermartini.com> wrote in message
news:lu26b1-i14.ln1@dmzu001.gia.ch…

I’m trying to test my first resource manager.
On resmgr_attach() I get the error “Operation not permitted”.
The manual states, that a resource manager has to be run as root
to be able to attach.

Because it means you could take over whatever path you like, not nice…

Well, started as root it works.

Why does it have this restriction?
IMHO it would be much more flexible,
if resmgr_attach() could respect the permissions
of the parent directory, where the new name is attached to.

I want to debug my resource managers
in a Neutrino based self hosted environement (Momentics PE 6.2.1b),
With this restriction I have to do it as root,
otherwise I’m not able to test my programms
directly from inside the IDE.

MfG
Werner Schweizer

3

Mario Charest postmaster@127.0.0.1 wrote:

MC > “Werner Schweizer” <nospamWrnr.Schwzr@ch.mullermartini.com> wrote in message
MC > news:lu26b1-i14.ln1@dmzu001.gia.ch…

I’m trying to test my first resource manager.
On resmgr_attach() I get the error “Operation not permitted”.
The manual states, that a resource manager has to be run as root
to be able to attach.

MC > Because it means you could take over whatever path you like, not nice…

I think you missed his point. If I have write permission to the parent
directory of the resource manager directory, I should not need to be
root.

This way, I can’t take over all of the pathname space, only where I
have write permission.


Well, started as root it works.

Why does it have this restriction?
IMHO it would be much more flexible,
if resmgr_attach() could respect the permissions
of the parent directory, where the new name is attached to.

I want to debug my resource managers
in a Neutrino based self hosted environement (Momentics PE 6.2.1b),
With this restriction I have to do it as root,
otherwise I’m not able to test my programms
directly from inside the IDE.

4

Werner Schweizer wrote:

I’m trying to test my first resource manager.
On resmgr_attach() I get the error “Operation not permitted”.
The manual states, that a resource manager has to be run as root
to be able to attach.
Well, started as root it works.

Why does it have this restriction?
IMHO it would be much more flexible,
if resmgr_attach() could respect the permissions
of the parent directory, where the new name is attached to.

I want to debug my resource managers
in a Neutrino based self hosted environement (Momentics PE 6.2.1b),
With this restriction I have to do it as root,
otherwise I’m not able to test my programms
directly from inside the IDE.

If you create a localhost target and run qconn as root on your machine,
then you can do it . The IDE tells qconn to launch your app and since
qconn is running as root, it works. I don’t recall the exact steps, but
it solves the problem you are talking about.

Rick…

Rick Duff Internet: rick@astranetwork.com
Astra Network URL: http://www.astranetwork.com
QNX Consulting and Custom Programming Phone: +1 (204) 997-NETW (6389)

5

Werner Schweizer <nospamWrnr.Schwzr@ch.mullermartini.com> wrote:

I’m trying to test my first resource manager.
On resmgr_attach() I get the error “Operation not permitted”.
The manual states, that a resource manager has to be run as root
to be able to attach.
Well, started as root it works.

Why does it have this restriction?

Because you could pretend to be a filesystem, and send back a
root-owned, setuid-root executable to be loaded from the filesystem
you attached with resmgr_attach().

Which means that a non-root resmgr_attach() easily gives root
access.

Also, resmgr_attach is a system level reconfiguration. It is, essentially,
the implementation side of “mount”. That sort of reconfig of a system
requires root.

I want to debug my resource managers
in a Neutrino based self hosted environement (Momentics PE 6.2.1b),
With this restriction I have to do it as root,
otherwise I’m not able to test my programms
directly from inside the IDE.

As someone mentioned, use qconn, and debug with a qconn (IP) connection,
rather than a run local.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

6

“Bill Caroselli” <qtps@earthlink.net> wrote in message
news:brq1t4$lq7$1@inn.qnx.com…

Mario Charest postmaster@127.0.0.1 wrote:

MC > “Werner Schweizer” <> nospamWrnr.Schwzr@ch.mullermartini.com> > wrote in
message
MC > news:> lu26b1-i14.ln1@dmzu001.gia.ch> …
I’m trying to test my first resource manager.
On resmgr_attach() I get the error “Operation not permitted”.
The manual states, that a resource manager has to be run as root
to be able to attach.

MC > Because it means you could take over whatever path you like, not
nice…

I think you missed his point. If I have write permission to the parent
directory of the resource manager directory, I should not need to be
root.

Not really, imagine this. I write a resource manager, in the path space
mounted under /home/user/resmgr. I would have the manager report all files
having +s bit active. I would copy let’s say dinit into that space and be
able to do lots of damage while login as non root!

This way, I can’t take over all of the pathname space, only where I
have write permission.


Well, started as root it works.

Why does it have this restriction?
IMHO it would be much more flexible,
if resmgr_attach() could respect the permissions
of the parent directory, where the new name is attached to.

I want to debug my resource managers
in a Neutrino based self hosted environement (Momentics PE 6.2.1b),
With this restriction I have to do it as root,
otherwise I’m not able to test my programms
directly from inside the IDE.

7

“Mario Charest” postmaster@127.0.0.1 schrieb im Newsbeitrag
news:brrbpg$k1o$1@inn.qnx.com…

“Bill Caroselli” <> qtps@earthlink.net> > wrote in message
news:brq1t4$lq7$> 1@inn.qnx.com> …
Mario Charest postmaster@127.0.0.1 wrote:

MC > “Werner Schweizer” <> nospamWrnr.Schwzr@ch.mullermartini.com> > wrote
in
message
MC > news:> lu26b1-i14.ln1@dmzu001.gia.ch> …
I’m trying to test my first resource manager.
On resmgr_attach() I get the error “Operation not permitted”.
The manual states, that a resource manager has to be run as root
to be able to attach.

MC > Because it means you could take over whatever path you like, not
nice…

I think you missed his point. If I have write permission to the parent
directory of the resource manager directory, I should not need to be
root.

Not really, imagine this. I write a resource manager, in the path space
mounted under /home/user/resmgr. I would have the manager report all
files
having +s bit active. I would copy let’s say dinit into that space and be
able to do lots of damage while login as non root!

What is then the gain of forcing to be root to start a RM?

Either I have to be root to start the RM (as it is now)
or I can open a backdoor to becom root through my RM.
So how is the system protected by this rule?
On the other hand, when writing a RM
I can take care to protect the system so that no user of the RM can use it
as a backdoor.
Werner

This way, I can’t take over all of the pathname space, only where I
have write permission.


Well, started as root it works.

Why does it have this restriction?
IMHO it would be much more flexible,
if resmgr_attach() could respect the permissions
of the parent directory, where the new name is attached to.

I want to debug my resource managers
in a Neutrino based self hosted environement (Momentics PE 6.2.1b),
With this restriction I have to do it as root,
otherwise I’m not able to test my programms
directly from inside the IDE.

8

Thank you for this hint.
Werner

“Rick Duff” <rick@astranetwork.com> schrieb im Newsbeitrag
news:brq1gc$lpk$1@inn.qnx.com…

Werner Schweizer wrote:
I’m trying to test my first resource manager.
On resmgr_attach() I get the error “Operation not permitted”.
The manual states, that a resource manager has to be run as root
to be able to attach.
Well, started as root it works.

Why does it have this restriction?
IMHO it would be much more flexible,
if resmgr_attach() could respect the permissions
of the parent directory, where the new name is attached to.

I want to debug my resource managers
in a Neutrino based self hosted environement (Momentics PE 6.2.1b),
With this restriction I have to do it as root,
otherwise I’m not able to test my programms
directly from inside the IDE.

If you create a localhost target and run qconn as root on your machine,
then you can do it . The IDE tells qconn to launch your app and since
qconn is running as root, it works. I don’t recall the exact steps, but
it solves the problem you are talking about.

Rick…

Rick Duff Internet: > rick@astranetwork.com
Astra Network URL: > http://www.astranetwork.com
QNX Consulting and Custom Programming Phone: +1 (204) 997-NETW (6389)

9

“Werner Schweizer” <nospamWrnr.Schwzr@ch.mullermartini.com> wrote in message
news:uh28b1-oe6.ln1@dmzu001.gia.ch…

“Mario Charest” postmaster@127.0.0.1 schrieb im Newsbeitrag
news:brrbpg$k1o$> 1@inn.qnx.com> …


“Bill Caroselli” <> qtps@earthlink.net> > wrote in message
news:brq1t4$lq7$> 1@inn.qnx.com> …
Mario Charest postmaster@127.0.0.1 wrote:

MC > “Werner Schweizer” <> nospamWrnr.Schwzr@ch.mullermartini.com> > wrote
in
message
MC > news:> lu26b1-i14.ln1@dmzu001.gia.ch> …
I’m trying to test my first resource manager.
On resmgr_attach() I get the error “Operation not permitted”.
The manual states, that a resource manager has to be run as root
to be able to attach.

MC > Because it means you could take over whatever path you like, not
nice…

I think you missed his point. If I have write permission to the
parent
directory of the resource manager directory, I should not need to be
root.

Not really, imagine this. I write a resource manager, in the path space
mounted under /home/user/resmgr. I would have the manager report all
files
having +s bit active. I would copy let’s say dinit into that space and
be
able to do lots of damage while login as non root!

What is then the gain of forcing to be root to start a RM?
Either I have to be root to start the RM (as it is now)
or I can open a backdoor to becom root through my RM.
So how is the system protected by this rule?

The idea is to protect again user that are NOT root.

resourge manager don’t really know if you (the person) is really root :wink:


On the other hand, when writing a RM
I can take care to protect the system so that no user of the RM can use it
as a backdoor.
Werner


This way, I can’t take over all of the pathname space, only where I
have write permission.


Well, started as root it works.

Why does it have this restriction?
IMHO it would be much more flexible,
if resmgr_attach() could respect the permissions
of the parent directory, where the new name is attached to.

I want to debug my resource managers
in a Neutrino based self hosted environement (Momentics PE 6.2.1b),
With this restriction I have to do it as root,
otherwise I’m not able to test my programms
directly from inside the IDE.
\

10

“Mario Charest” postmaster@127.0.0.1 schrieb im Newsbeitrag
news:brslsm$kc2$1@inn.qnx.com…

“Werner Schweizer” <> nospamWrnr.Schwzr@ch.mullermartini.com> > wrote in
message
news:> uh28b1-oe6.ln1@dmzu001.gia.ch> …

“Mario Charest” postmaster@127.0.0.1 schrieb im Newsbeitrag
news:brrbpg$k1o$> 1@inn.qnx.com> …


“Bill Caroselli” <> qtps@earthlink.net> > wrote in message
news:brq1t4$lq7$> 1@inn.qnx.com> …
Mario Charest postmaster@127.0.0.1 wrote:

MC > “Werner Schweizer” <> nospamWrnr.Schwzr@ch.mullermartini.com
wrote
in
message
MC > news:> lu26b1-i14.ln1@dmzu001.gia.ch> …
I’m trying to test my first resource manager.
On resmgr_attach() I get the error “Operation not permitted”.
The manual states, that a resource manager has to be run as root
to be able to attach.

MC > Because it means you could take over whatever path you like,
not
nice…

I think you missed his point. If I have write permission to the
parent
directory of the resource manager directory, I should not need to be
root.

Not really, imagine this. I write a resource manager, in the path
space
mounted under /home/user/resmgr. I would have the manager report all
files
having +s bit active. I would copy let’s say dinit into that space
and
be
able to do lots of damage while login as non root!

What is then the gain of forcing to be root to start a RM?
Either I have to be root to start the RM (as it is now)
or I can open a backdoor to becom root through my RM.
So how is the system protected by this rule?

The idea is to protect again user that are NOT root.

resourge manager don’t really know if you (the person) is really root > :wink:

I don’t get your point yet.

I have to do my job and this includes to develop, test and run resouce
managers.
So as it is now, my SysAdmin has to trust me an give me the root password.
An additional drawback is, that I get used to do all my work on the system
as root.

When however the protection would be based on access rigths on the parent
directory,
the SysAdmin has still to trust me, but he is not forced to give the root
password away.
The same is true, if I’m debugging remotely or local via qconn.

On the other hand, when writing a RM
I can take care to protect the system so that no user of the RM can use
it
as a backdoor.
Werner


This way, I can’t take over all of the pathname space, only where I
have write permission.


Well, started as root it works.

Why does it have this restriction?
IMHO it would be much more flexible,
if resmgr_attach() could respect the permissions
of the parent directory, where the new name is attached to.

I want to debug my resource managers
in a Neutrino based self hosted environement (Momentics PE
6.2.1b),
With this restriction I have to do it as root,
otherwise I’m not able to test my programms
directly from inside the IDE.


\

11

Werner Schweizer <nospamWrnr.Schwzr@ch.mullermartini.com> wrote:

I have to do my job and this includes to develop, test and run resouce
managers.
So as it is now, my SysAdmin has to trust me an give me the root password.

Yes, he has to trust you if he wants to let you do your job. But no, he
doesn’t have to give you the root password. Instead, he could give you
a setuid-root executable that will do exactly what he wants to allow you
to do as root, and nothing more. Or one that does anything you ask it
to do but also logs all your requests somewhere. And so on.

An additional drawback is, that I get used to do all my work on the system
as root.

That would be bad if it were necessary, but it’s not. You could, for
instance, have one root shell that you only use to run your resource
manager, and do your development in other shells running as your regular
user.

When however the protection would be based on access rigths on the parent
directory,
the SysAdmin has still to trust me, but he is not forced to give the root
password away.

He’s not forced to give you his password. He is free to decide whether
you can be trusted and allowed to do your job or not. That’s the point.

Any user with access to a compiler or to an ftp client can write or
download a resource manager that presents a setuid-root copy of /bin/sh
to the OS. The sys admin needs to be able to disallow untrusted users
to run such resource managers. Your proposed protection based on access
rigths on the parent directory doesn’t solve this, does it?

12

The idea is to protect again user that are NOT root.

resourge manager don’t really know if you (the person) is really root
:wink:

I don’t get your point yet.



An additional drawback is, that I get used to do all my work on the system
as root.

When however the protection would be based on access rigths on the parent
directory,
the SysAdmin has still to trust me, but he is not forced to give the root
password away.

Indeed he would’nt need to give you root password if it was based on access
rights only, be he should be worried because once started the resource
manager would be able to change the root password -)

But I do see were you could be confuse. You are probably lacking some
knowledge about how resource manager works.

Let’s say resource manager ability to resmgr_attach was based upon parent’s
permission. Your email me your ram disk driver that you just written. I
start it and mount the device under /u/mcharest/ramdrv hence don’t need to
be root cause it’s mounted under my home directory. It’s sounds as if
everything is secure, but it’s not. I run “cp /bin/dinit
/u/mcharest/ramdrv” copy dinit in your resmgr space. Then I tried chmod +s
/bin/dnit/u/mcharest/ramdrv and suprise it works. Why because you could
have forget to prevent +s flag from being set for non root user. Then me
“the non root user” is able to dinit /dev/hd0.0 hence deleting the content
of the HD… Here we are talking about a honest mistake. But it could be
done on purpuse be a malicious user.

You give me telnet/ftp access to you machine. Then I upload my own ram
driver which concidently allow setuid flag to be by non user (or even
reports all files have the setuid flag set) then i could easly take you
machine apart, read your personel files. So even if you’d be root you could
not prevent me from hacking your machine, well you could prevent me from
running any program at all from /u/mcharest or being able to write via ftp.
I would be close to impossible to make your system secure.

See aside from resmgr_attach there is no other check or validation that
resmgr have to comply with, they are responsible to comply OR NOT with all
the permissions stuff. Yes resmgr could check upon the permission of the
parent directory and enforces these same permission, but there is no
mecanism to force them to do so. Thus they cannot be allow to be run by any
other user then root. It’s up to the admin to decide if a program is to be
trusted or not! It’s not up to YOU the non root user. That limitation on
resmgr_attach ensure that the decision is left to root only.

More info. When you do ls /ramdrv (assuming /ramdrv is your resmgr) what is
returned to the ls command by your resmgr is 100% generated by your resmgr
and doesn’t go through any checking by the OS. Hence if the /ramdrv says
the setuid flag is set the program that reads it (being ls or the loader)
doesn’t do any other checking (and why would he has to) to see if the
program responsible for /ramdrv does indeed have the proper rights to return
that flag.

That being said this whole issue raises the question, if there is value in
allowing non root user to resmgr_attach (I think there are). For example I
could write a random number generator, why would it need to be run as root.
But given the way the resmgr framework and the OS is architeched I don’t see
how it could be done.

Making it otherwise would render the OS complexe IHMO (

The same is true, if I’m debugging remotely or local via qconn.


On the other hand, when writing a RM
I can take care to protect the system so that no user of the RM can
use
it
as a backdoor.
Werner


This way, I can’t take over all of the pathname space, only where
I
have write permission.


Well, started as root it works.

Why does it have this restriction?
IMHO it would be much more flexible,
if resmgr_attach() could respect the permissions
of the parent directory, where the new name is attached to.

I want to debug my resource managers
in a Neutrino based self hosted environement (Momentics PE
6.2.1b),
With this restriction I have to do it as root,
otherwise I’m not able to test my programms
directly from inside the IDE.




\

13

“Wojtek Lerch” <wojtek_l@yahoo.ca> wrote in message
news:brvh5b$mi1$1@nntp.qnx.com…

Werner Schweizer <> nospamWrnr.Schwzr@ch.mullermartini.com> > wrote:
I have to do my job and this includes to develop, test and run resouce
managers.
So as it is now, my SysAdmin has to trust me an give me the root
password.

Yes, he has to trust you if he wants to let you do your job. But no, he
doesn’t have to give you the root password. Instead, he could give you
a setuid-root executable that will do exactly what he wants to allow you
to do as root, and nothing more. Or one that does anything you ask it
to do but also logs all your requests somewhere. And so on.

An additional drawback is, that I get used to do all my work on the
system
as root.

That would be bad if it were necessary, but it’s not. You could, for
instance, have one root shell that you only use to run your resource
manager, and do your development in other shells running as your regular
user.

When however the protection would be based on access rigths on the
parent
directory,
the SysAdmin has still to trust me, but he is not forced to give the
root
password away.

He’s not forced to give you his password. He is free to decide whether
you can be trusted and allowed to do your job or not. That’s the point.

Any user with access to a compiler or to an ftp client can write or
download a resource manager that presents a setuid-root copy of /bin/sh
to the OS. The sys admin needs to be able to disallow untrusted users
to run such resource managers. Your proposed protection based on access
rigths on the parent directory doesn’t solve this, does it?

It doesn’t Wojtek, but I’ve been wondering if somehow resmgr could be
“force” to respect the parents permission. Situation comes from the
principle that resmgr are free to do what they want as far as returning
permission flags, and I wonder if it has to be that way.

That discussion reminds me of a some concerns I had about resmgr when NTO
1.0 came out. I remember a long discussion on QUICS about this :wink:
name_attach (or the equivalent QNX4) doesntt require to be run as root,
which I find interesting cause why would ALL server to be run root. If you
read name_attach doc it does says that it’s not the recommanded way for
handling messages based IPC under QNX6 and that resource manager are the
prefered method. I do find the rule that resmgr need to be run root coslty
considering that’s the prefered way all programs should do messaging under
QNX6. I wonder if that’s not an oversight in the design?

  • Mario
14

Indeed he would’nt need to give you root password if it was based on
access
rights only, be he should be worried because once started the resource
manager would be able to change the root password -)

That came out wrong. Resource manager wouldn’t be able to change root
password, but it could give access to running a program with proper
permission to change it.

But I do see were you could be confuse. You are probably lacking some
knowledge about how resource manager works.

Let’s say resource manager ability to resmgr_attach was based upon
parent’s
permission. Your email me your ram disk driver that you just written. I
start it and mount the device under /u/mcharest/ramdrv hence don’t need to
be root cause it’s mounted under my home directory. It’s sounds as if
everything is secure, but it’s not. I run “cp /bin/dinit
/u/mcharest/ramdrv” copy dinit in your resmgr space. Then I tried chmod
+s
/bin/dnit/u/mcharest/ramdrv and suprise it works. Why because you could
have forget to prevent +s flag from being set for non root user. Then me
“the non root user” is able to dinit /dev/hd0.0 hence deleting the content
of the HD… Here we are talking about a honest mistake. But it could be
done on purpuse be a malicious user.

You give me telnet/ftp access to you machine. Then I upload my own ram
driver which concidently allow setuid flag to be by non user (or even
reports all files have the setuid flag set) then i could easly take you
machine apart, read your personel files. So even if you’d be root you
could
not prevent me from hacking your machine, well you could prevent me from
running any program at all from /u/mcharest or being able to write via
ftp.
I would be close to impossible to make your system secure.

See aside from resmgr_attach there is no other check or validation that
resmgr have to comply with, they are responsible to comply OR NOT with all
the permissions stuff. Yes resmgr could check upon the permission of the
parent directory and enforces these same permission, but there is no
mecanism to force them to do so. Thus they cannot be allow to be run by
any
other user then root. It’s up to the admin to decide if a program is to
be
trusted or not! It’s not up to YOU the non root user. That limitation on
resmgr_attach ensure that the decision is left to root only.

More info. When you do ls /ramdrv (assuming /ramdrv is your resmgr) what
is
returned to the ls command by your resmgr is 100% generated by your resmgr
and doesn’t go through any checking by the OS. Hence if the /ramdrv says
the setuid flag is set the program that reads it (being ls or the loader)
doesn’t do any other checking (and why would he has to) to see if the
program responsible for /ramdrv does indeed have the proper rights to
return
that flag.

That being said this whole issue raises the question, if there is value in
allowing non root user to resmgr_attach (I think there are). For example
I
could write a random number generator, why would it need to be run as
root.
But given the way the resmgr framework and the OS is architeched I don’t
see
how it could be done.

Making it otherwise would render the OS complexe IHMO (
The same is true, if I’m debugging remotely or local via qconn.


On the other hand, when writing a RM
I can take care to protect the system so that no user of the RM can
use
it
as a backdoor.
Werner


This way, I can’t take over all of the pathname space, only
where
I
have write permission.


Well, started as root it works.

Why does it have this restriction?
IMHO it would be much more flexible,
if resmgr_attach() could respect the permissions
of the parent directory, where the new name is attached to.

I want to debug my resource managers
in a Neutrino based self hosted environement (Momentics PE
6.2.1b),
With this restriction I have to do it as root,
otherwise I’m not able to test my programms
directly from inside the IDE.






\

15

On 19 Dec 2003 18:48:11 GMT, Wojtek Lerch wrote:

Werner Schweizer <> nospamWrnr.Schwzr@ch.mullermartini.com> > wrote:
I have to do my job and this includes to develop, test and run resouce
managers.
So as it is now, my SysAdmin has to trust me an give me the root password.

Yes, he has to trust you if he wants to let you do your job. But no, he
doesn’t have to give you the root password. Instead, he could give you
a setuid-root executable that will do exactly what he wants to allow you
to do as root, and nothing more. Or one that does anything you ask it
to do but also logs all your requests somewhere. And so on.

We use “sudo” for exactly this kind of functionality. sudo allows the
SysAdmin to provide a specific list of commands that a particular user is
allowed to perform as root.

sudo ports easily to NTO.

Rob Rutherford

16

Werner Schweizer wrote:

I’m trying to test my first resource manager.
On resmgr_attach() I get the error “Operation not permitted”.
The manual states, that a resource manager has to be run as root
to be able to attach.
Well, started as root it works.

Why does it have this restriction?
IMHO it would be much more flexible,
if resmgr_attach() could respect the permissions

I’d argue that you should be able to take over a piece
of the pathname space if all the resource managers who
already own that namespace agree that it is OK.
An attempt to do a resmgr_attach should result in a
message going in turn to each resource manager with
existing authority over that namespace, as with
any other request. The resource manager should
answer “yes”, “no”, or “don’t care” to the resmgr_attach
request, much like the way opens work.

Default policy for resource managers would be “no”,
but resource managers that implement file systems that
allow making directories could say “yes” if their permission
rules permitted making a directory at that point.

There’s a problem with program launch trusting
permissions information from a resource manager, but
that can be settled by having program launch check
whether the resource manager that owns the object being
launched is trusted.

The “root” restriction on resmgr_attach is bad for security;
it results in code running as root that doesn’t really have to
run as root. Only drivers that need hardware access
should have to run as root.

The whole business of how processes get linked up needs some
rethinking. The resource-manager structure is oriented
towards I/O; if you want to use QNX messages as transactions,
it’s a bad fit. name_attach is useful, but the documentation
says it’s deprecated. name_open doesn’t yet work across the network.
(Even without “global names”, it should be possible to open
“/net/NODENAME/dev/name/local/CONNECTIONNAME” when appropriate,
but that doesn’t work, I’m told.) And I’ve mentioned in other messages,
inter-node spawn is buggy.

The end result is that building a distributed real-time system
is a huge pain. Messaging works fine once you set up the connnections,
but setting them up is a mess.

John Nagle
Team Overbot

17

John Nagle <nagle@downside.com> wrote:

JN > The whole business of how processes get linked up needs some
JN > rethinking. The resource-manager structure is oriented
JN > towards I/O; if you want to use QNX messages as transactions,
JN > it’s a bad fit. name_attach is useful, but the documentation
JN > says it’s deprecated. name_open doesn’t yet work across the network.
JN > (Even without “global names”, it should be possible to open
JN > “/net/NODENAME/dev/name/local/CONNECTIONNAME” when appropriate,
JN > but that doesn’t work, I’m told.) And I’ve mentioned in other messages,
JN > inter-node spawn is buggy.

JN > The end result is that building a distributed real-time system
JN > is a huge pain. Messaging works fine once you set up the connnections,
JN > but setting them up is a mess.

Hi John. I do completely agree with you. However . . .

If it is such a big deal to have a resource manager run as root, you
can write your own version of the QNX4 nameloc utility, and run it as
a root process. Then other non-root processes can easily name_attach(),
name_detach() and name_locate(). Then all of your transaction server
processes need not bother running as root. They can just register
themselves with the phone book.

In fact, I think that this is such a good idea that I’m going to
authorize QSSL to release the source to QNX4’s nameloc. It will have
to be modified to return the channel in addiotion to the pid. QSSL can
also strip out the QNX4 licensing code if they want to.

18

Mario Charest postmaster@127.0.0.1 wrote:

“Wojtek Lerch” <> wojtek_l@yahoo.ca> > wrote in message
news:brvh5b$mi1$> 1@nntp.qnx.com> …
Any user with access to a compiler or to an ftp client can write or
download a resource manager that presents a setuid-root copy of /bin/sh
to the OS. The sys admin needs to be able to disallow untrusted users
to run such resource managers. Your proposed protection based on access
rigths on the parent directory doesn’t solve this, does it?

It doesn’t Wojtek, but I’ve been wondering if somehow resmgr could be
“force” to respect the parents permission. Situation comes from the
principle that resmgr are free to do what they want as far as returning
permission flags, and I wonder if it has to be that way.

I’m afraid it does: any resmgr that is expected to support chown() and
chmod() must be allowed to return any combination of user id and
permission bits that a sufficiently privileged client may decide to set
a file to.

The setuid root problem is just the most obvious security hole that
allowing untrusted resmgrs would open, but I’m sure there are many
others. For instance, there may be a legitimate setuid-root program
that saves some sensitive information to a temporary file. If the
program uses the O_EXCL flag and creates the file as unreadable to
anybody, the data should be safe; but only if the filesystem can be
trusted. If I manage to fool the program into saving its data to my own
resmgr, I can steal or alter information that I wasn’t supposed to have
access to. Sounds much easier than finding and exploiting a buffer
overflow…

19

Hi John. I do completely agree with you. However . . .

If it is such a big deal to have a resource manager run as root, you
can write your own version of the QNX4 nameloc utility, and run it as
a root process. Then other non-root processes can easily name_attach(),
name_detach() and name_locate(). Then all of your transaction server
processes need not bother running as root. They can just register
themselves with the phone book.

We essentially did something like that, but we did it by having
our programs all be children of our “watchdog”, which knows which
process is which and can provide directory services.

In fact, I think that this is such a good idea that I’m going to
authorize QSSL to release the source to QNX4’s nameloc. It will have
to be modified to return the channel in addiotion to the pid. QSSL can
also strip out the QNX4 licensing code if they want to.

That sounds like a step in the right direction.

John Nagle
Team Overbot

20

Thanks for any responses.
It seems to be a complex problem.
This comes mainly from the fact, that some people is talking about general
purpose computer.
Others, like me, are talking about embedded systems,
where the security rules are completely different.
There is no general purpose MMI,
only application specific user interaction is possible.
Security problems have to be considered only for service access
via telnet or other remote access.

I’m planing to implement my whole application
(a newspaper mailroom automation system)
as a couple of processes programmed as resource managers.
It has to be done in a way, that in a small mailroom,
all processes are run on one PC.
In a large mailroom, the processes heve to be spread over a couple of PC’s.
These RM’s are not general purpose, but largely depending on each other
and to the hardware and equipment (machines produced by our company).

The current OS rules are forcing me to run the whole application as root.
A lot of the protection mechanisms the OS provides,
are inactive for root processes and have to be reimplemented by the RM’s.

“Werner Schweizer” <nospamWrnr.Schwzr@ch.mullermartini.com> schrieb im
Newsbeitrag news:lu26b1-i14.ln1@dmzu001.gia.ch…

I’m trying to test my first resource manager.
On resmgr_attach() I get the error “Operation not permitted”.
The manual states, that a resource manager has to be run as root
to be able to attach.
Well, started as root it works.

Why does it have this restriction?
IMHO it would be much more flexible,
if resmgr_attach() could respect the permissions
of the parent directory, where the new name is attached to.

I want to debug my resource managers
in a Neutrino based self hosted environement (Momentics PE 6.2.1b),
With this restriction I have to do it as root,
otherwise I’m not able to test my programms
directly from inside the IDE.

MfG
Werner Schweizer