LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)
-   -   (automatic) excution of a program in /usr/sbin as normal user (https://www.linuxquestions.org/questions/linux-software-2/automatic-excution-of-a-program-in-usr-sbin-as-normal-user-4175458774/)

JZL240I-U 04-19-2013 10:36 AM

(automatic) excution of a program in /usr/sbin as normal user
 
I have /usr/sbin/powertop (to minimize power consumption on my netbook) which I want to run automatically late during boot. It has set "-rwxr-xr-x". So I assumed "others" having set their "r-x" (e.g. users like me) can execute it. But I get the message:
Quote:

"Absolute path to 'powertop' is '/usr/sbin/powertop', so running it may require superuser privileges (e.g. root)."
I know that I could add /usr/sbin to my $PATH to get rid of that but I don't want to open that much access to normal users.

Any ideas what is causing this and how to change it without creating security holes? TIA.

linosaurusroot 04-19-2013 10:52 AM

Quote:

Originally Posted by JZL240I-U (Post 4934802)
I know that I could add /usr/sbin to my $PATH to get rid of that but I don't want to open that much access to normal users.

That's safe to do and doesn't increase access.

JZL240I-U 04-22-2013 01:06 AM

Probably a stupid question but anyhow, why is it
Quote:

Originally Posted by linosaurusroot (Post 4934808)
... safe to do and doesn't increase access.

After all, it puts all executables in /usr/sbin in my reach, doesnt't it? Can't this be done selectively just for one program?

chrism01 04-22-2013 01:43 AM

Notice the word 'may' in the msg; its just a warning.
Depending on how you call it, you may be able to suppress it.
If you add it to the startup routines, worst case its just one extra msg amongst many, unless you reboot a lot(!)

JZL240I-U 04-22-2013 01:56 AM

Well, no, it is not only a warning, since I'm thrown back to the prompt. "powertop" has a user interface which should otherwise be shown on the screen (sorry, I mixed two scenarios so as not to flood the forum with stupid questions).

chrism01 04-22-2013 08:24 AM

In that case, its a badly written msg.

The boot process is run by root, so if its in there, you shouldn't get a problem unless you're trying to run it as someone else.
If you want to run it as someone who is not root, try setting suid (as root) on the file.
Code:

chmod u+s /usr/sbin/powertop
This causes it to run as root, regardless of who calls it, eg see /usr/bin/passwd.

JZL240I-U 04-22-2013 08:39 AM

Quote:

chmod u+s /usr/sbin/powertop
Tried it, but no change. When I try it now, I still get

Quote:

"Absolute path to 'powertop' is '/usr/sbin/powertop', so running it may require superuser privileges (e.g. root)."
@ linosaurusroot: Your suggestion doesn't work either. I get
Quote:

Powertop v2.2 must be run with root privileges.
Leaving...
So what now? ;) PAM??

david1941 04-22-2013 08:46 AM

you could try a sym link to the executable in /usr/bin

273 04-22-2013 08:58 AM

I think it's hard coded into powertop to check that the user running it is root, at least that's what I get from the code here:
https://github.com/fenrus75/powertop...r/src/main.cpp
Code:

static void checkroot() {
        int uid;
        uid = getuid();

        if (uid != 0) {
                printf(_("PowerTOP " POWERTOP_VERSION " must be run with root privileges.\n"));
                printf(_("exiting...\n"));
                exit(EXIT_FAILURE);
        }
}


JZL240I-U 04-22-2013 12:27 PM

Quote:

Originally Posted by 273 (Post 4936489)
...it's hard coded into powertop to check that the user running it is root...

Darn. That means when I use my netbook as normal user I have to "su" to root to set the proper power settings. That's bloody inconvenient :mad:. Or do any of you have a different solution?

273 04-22-2013 12:43 PM

I'm afraid I don't, but would something like this help?
http://askubuntu.com/questions/11270...nges-permanent
Not used it myself so can't vouch for it working.

chrism01 04-22-2013 08:50 PM

At least in post #9 the msg says 'must' be run as root; that's much clearer.
Wonder why OP gets a different msg; different version perhaps?
Maybe you should contact the author.

273 04-23-2013 12:57 AM

Quote:

Originally Posted by chrism01 (Post 4936883)
At least in post #9 the msg says 'must' be run as root; that's much clearer.
Wonder why OP gets a different msg; different version perhaps?
Maybe you should contact the author.

You make a very good point. The message about the absolute path doesn't seem to be in the listing I linked to and looks like it may even be a system message. Perhaps that means that the sticky bit is working and it's something else?

JZL240I-U 04-23-2013 01:32 AM

Quote:

Originally Posted by 273 (Post 4936964)
...The message about the absolute path doesn't seem to be in the listing I linked to and looks like it may even be a system message. Perhaps that means that the sticky bit is working and it's something else?

That's why I mentioned PAM, but with that I'm entirely out of my depth. I'll try your askubuntu link and come back later.

JZL240I-U 04-24-2013 04:08 AM

Well, that opened a whole new can of worms :rolleyes:.

I had (in part) already incorporated the procedure from your link, 273. I completed it now and thus have a script with all the desired commands. In principle I don't need to run "powertop" anymore, though I'd still like to know, whether these restrictions can be circumvented. Anyways.

The normal user (myself) can run that script and it resides in KDE's Autostart directory. But it doesn't work :mad:. In the most cases access to the /proc and /sys directories (rather their subdirectories) is denied. Also commands like "hdparm", "ethtool" and "iw" are not found. When I "su" too root and run that script I get no error and everything is set as desired. So I'm back to step one.

The same (i.e. nothing) happens, when I incorporate the commands from the script in the user's ".profile" or ".bashrc" files.

Btw. chrism01, I checked with wikipedia, it says that most distributions disable the suid bit of script for security reasons.

You also wrote that the init process is run by root. Thus I copied the script to /etc/init.d and created links at rc3.d and rc5.d. And lo and behold -- the script works as desired -- but only when I log in as root, and not so when I'm the normal user, even though "chkconfig" and YAST's runlevel editor show that the script is active and running.

Seems that "systemd" is not always running as root?!? I don't understand this at all...

273 04-24-2013 04:15 AM

Did you try adding the commands to /etc/rc.local as the link suggested? I'm not sure why that would be different to /etc/init.d/ scripts but it's worth a try?

JZL240I-U 04-24-2013 04:20 AM

SuSE hasn't got a rc.local, so I couldn't try that.

chrism01 04-24-2013 08:01 AM

Re suid on scripts; I knew that but from post #9 it looked like powertop is a cpp thus binary exe.

Maybe its different for you, but normally the boot process has to run as root to do all the privileged things it needs to do, although some sub-processes may be run as a different user for their own reasons.

On eg RHEL, you'd have have an entry in /etc/rc.d/rc.local like
Code:

su - user -c "cmd args"
This syntax means no passwd or sudo reqd.

JZL240I-U 04-25-2013 02:50 AM

I found out what SuSE did to rc.local ;), since Google is my friend :D. They created an "/etc/init.d/after.local", a "script with local commands to be executed from init after all scripts of a runlevel have been executed". I appended

Code:

su - root -c /etc/init.d/<my-script>
It still does not work *sigh*.

Quote:

Originally Posted by chrism01 (Post 4937955)
Re suid on scripts; I knew that but from post #9 it looked like powertop is a cpp thus binary exe.

It is an (interactive) binary. I took it's output and pasted it into a shellscript. That is what we are talking about in the meantime ;).

Quote:

Originally Posted by chrism01 (Post 4937955)
Maybe its different for you, but normally the boot process has to run as root to do all the privileged things it needs to do, although some sub-processes may be run as a different user for their own reasons.

Booting openSuSE is done by "systemd", not anymore by sysvinit. I don't know how "systemd" handles users and permissions.

Quote:

Originally Posted by chrism01 (Post 4937955)
On eg RHEL, you'd have have an entry in /etc/rc.d/rc.local like
Code:

su - root -c "cmd args"
This syntax means no passwd or sudo reqd.

I know that according to the man page of su the above entered "root" is redundant, but neither a simple "-" nor "- root" works. <edit1> A change of the command to

Code:

su - root -c "cmd >> /home/me/error.txt 2>&1"
brought no further insights either. Grrr. </edit1>

<edit2> Found out why: "su" is asking for a password. I created a test-script and ran that from console. [enter favourite expletives here]. What now?

sundialsvcs 04-25-2013 08:15 AM

There is nothing "magical" about the /usr/sbin directory ...

JZL240I-U 04-25-2013 08:48 AM

Thanks for stating the obvious :). Do you also propose a solution for the Problem?


All times are GMT -5. The time now is 01:35 PM.