topic Re: Running RC script in Operating System - HP-UX

Running RC script

Jonathan Caplette_1 — Tue, 29 Jul 2003 14:43:12 GMT

Hi guys,

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

Thanks
Jonathan

Re: Running RC script

Pete Randall — Tue, 29 Jul 2003 14:45:47 GMT

Yep.

Pete

Re: Running RC script

A. Clay Stephenson — Tue, 29 Jul 2003 14:47:19 GMT

Does a hog like slop?

Re: Running RC script

Mark Greene_1 — Tue, 29 Jul 2003 14:48:43 GMT

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

Re: Running RC script

John Meissner — Tue, 29 Jul 2003 14:52:22 GMT

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

Re: Running RC script

Steven E. Protter — Tue, 29 Jul 2003 14:53:13 GMT

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

Re: Running RC script

A. Clay Stephenson — Tue, 29 Jul 2003 14:55:25 GMT

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.

Re: Running RC script

Jonathan Caplette_1 — Tue, 29 Jul 2003 16:09:43 GMT

"Thank you.. Come again!!!"

Re: Running RC script

Caesar_3 — Tue, 29 Jul 2003 19:39:50 GMT

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

Re: Running RC script

prasad_15 — Tue, 29 Jul 2003 22:58:18 GMT

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

Re: Running RC script

Bill Hassell — Wed, 30 Jul 2003 00:41:14 GMT

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