Resource manager

bridged with qdn.public.qnxrtp.os
Werner Schweizer

Resource manager

Post by Werner Schweizer » Wed Dec 17, 2003 1:40 pm

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

Mario Charest

Re: Resource manager

Post by Mario Charest » Wed Dec 17, 2003 3:44 pm

"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

Bill Caroselli

Re: Resource manager

Post by Bill Caroselli » Wed Dec 17, 2003 4:57 pm

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.

Rick Duff

Re: Resource manager

Post by Rick Duff » Wed Dec 17, 2003 5:14 pm

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)

David Gibbs

Re: Resource manager

Post by David Gibbs » Wed Dec 17, 2003 10:14 pm

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.

Mario Charest

Re: Resource manager

Post by Mario Charest » Thu Dec 18, 2003 5:13 am

"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.

Werner Schweizer

Re: Resource manager

Post by Werner Schweizer » Thu Dec 18, 2003 7:45 am

"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.

Werner Schweizer

Re: Resource manager

Post by Werner Schweizer » Thu Dec 18, 2003 8:00 am

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)

Mario Charest

Re: Resource manager

Post by Mario Charest » Thu Dec 18, 2003 5:11 pm

"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 ;-)

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.



Werner Schweizer

Re: Resource manager

Post by Werner Schweizer » Fri Dec 19, 2003 9:56 am

"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 ;-)

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.





Wojtek Lerch

Re: Resource manager

Post by Wojtek Lerch » Fri Dec 19, 2003 6:48 pm

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?

Mario Charest

Re: Resource manager

Post by Mario Charest » Sun Dec 21, 2003 1:27 am

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

resourge manager don't really know if you (the person) is really root
;-)

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.







Mario Charest

Re: Resource manager

Post by Mario Charest » Sun Dec 21, 2003 1:50 am

"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 ;)
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

>

Mario Charest

Re: Resource manager

Post by Mario Charest » Sun Dec 21, 2003 4:16 am

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.









Robert Rutherford

Re: Resource manager

Post by Robert Rutherford » Sun Dec 21, 2003 10:57 pm

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

Post Reply

Return to “qdn.public.qnxrtp.os”