Running RC script

[Jonathan Caplette_1]

Hi guys,

I want to know who runs rc scripts... Is that always root????

Thanks
Jonathan

[Pete Randall · Accepted solution]

Yep.


Pete

[A. Clay Stephenson]

Does a hog like slop?

[Mark Greene_1]

Usually, but it doesn't have to be. In /sbin/init.d you could user the setuid bit to force ownership to something other than root. I would think that doing this is NOT recommended for any of the system daemon processes. I'd setup a simple shell script to test this before changing anything.

mark

[John Meissner]

yes. one way this can be changed is to have your rc script 'su - user'

[Steven E. Protter]

A practical, though less humorous answer.

To see who can run something, no matter where it is.

Check permissions.


ll filename

Example:

ll /sbin/init.d/oracle
-rwx------ 1 root sys

The only one that can read write or execute this script is root

If there was an x in the second set of permissions

-rwxr-x---

Then other members of the sys group could also execute it.

If it looked like this:

-rwxr-xr-x

Then anyone can execute it. Note you have to be able to read it to execute it. Hence the r.

Permissions tells the whole story of who can do what on a Unix box.

SEP

[A. Clay Stephenson]

Note that within a given rc script, you can always do an su (and since the user is root, no passwd is needed). It's very common to do something like "su oracle -c command arg1 arg2"; however, it's generally a bad idea to su - oracle -c command arg1 arg2" because almost certainly oracle .profile will contain command which expect an interactive environemt -- which cron ain't. A better method is to have a separate file (e.g. /usr/local/bin/oraenv.sh) and have your rc script and oracle's .profile source this file (viz . /usr/local/bin/oraenv.sh) to set and export environment variables. The sources file must not contain a return or exit statement.

[Jonathan Caplette_1]

"Thank you.. Come again!!!"

[Caesar_3]

Hello!

You create the script in /sbin/init.d/
that can handle parameters (start|stop|start_msg|stop_msg)
and in the /sbin/rcX.d/ create link to it
SNAME
-> /sbin/init.d/<ScriptName>

and in /sbin/rc(X-1).d/ create link to it
KNAME
-> /sbin/init.d/<ScriptName>

And yes it's run with root always.

Caesar

[prasad_15]

Hi,

please advise this.
$ ls -l /bin/newgrp
-r-sr-xr-x 1 root bin 16384 Feb 20 2001 /bin/newgrp

so when I did this
$ newgrp dba
Sorry

Why??? as i have the execute on newgrp set.

Thanks

[Bill Hassell]

As far as the newgrp command, it di run just fine. The problem is not "Execute permission denied", the error was "sorry" which is not meaningful but it was newgrp's way to tell you that your username is not listed in /etc/group with the user dba. Have the system administrator add your username to /etc/group for the dba group.

However, newgrp is archaic today. For 10.20 your sysadmin can create a symlink between /etc/group and /etc/logingroup. For 11.0 and higher, the link is not needed. /etc/group needs to have ONLY alternate group membership listed, not the primary group as this is found in /etc/passwd. This simplifies the passwd file.

To see what groups your login belongs to, use the command: id