Hi, I am using kppp for dialup, and it often complains that the file /etc/resolv.conf doesn't exist. I've created that file, but some process keeps deleting it. So I thought I replace the link to kppp with a little shell script along the lines of: #!/bin/sh touch /etc/resolv.conf kppp -c "my-dialup-account" The shell script is owned by root, and I set the permissions with chmod a+xs. It now looks like this: -rwsr-sr-x 1 root root 56 2003-11-21 12:56 my_dialup_script I thought the above permissions would cause the script to be executed as root, and therefore it should have permissions to create or modify the file /etc/resolv.conf. But nevertheless 'touch' complains that it doesn't have permissions for the file. Obviously there are some points I don't understand about file permissions. Anyone care to help me out? Thanks Klaus __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
On Friday 21 November 2003 18:18 pm, K V wrote: <SNIP>
The shell script is owned by root, and I set the permissions with chmod a+xs. It now looks like this:
-rwsr-sr-x 1 root root 56 2003-11-21 12:56 my_dialup_script
I thought the above permissions would cause the script to be executed as root, and therefore it should have permissions to create or modify the file /etc/resolv.conf. But nevertheless 'touch' complains that it doesn't have permissions for the file.
AIUI the SUID flag sets the file to execute under the user who initiates it. Thus: user KV starts your script, and it runs with KV's permissions/ privelidges. If root starts the same script it will have root's privelidges. Dylan -- Sweet moderation Heart of this nation Desert us not We are between the wars - Billy Bragg
--- Dylan
The shell script is owned by root, and I set the permissions with chmod a+xs. It now looks like
On Friday 21 November 2003 18:18 pm, K V wrote: <SNIP> this:
-rwsr-sr-x 1 root root 56
12:56 my_dialup_script
I thought the above permissions would cause the
2003-11-21 script
to be executed as root, and therefore it should have permissions to create or modify the file /etc/resolv.conf. But nevertheless 'touch' complains that it doesn't have permissions for the file.
AIUI the SUID flag sets the file to execute under the user who initiates it. Thus: user KV starts your script, and it runs with KV's permissions/ privelidges. If root starts the same script it will have root's privelidges.
Hmmm... applying this logic in reverse: If the SUID flag is NOT set, and the script is owned by root, but executed by user KV, shouldn't it have root privileges? It doesn't seem it has... Klaus __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
Dylan
On Friday 21 November 2003 18:18 pm, K V wrote: <SNIP>
The shell script is owned by root, and I set the permissions with chmod a+xs. It now looks like this:
-rwsr-sr-x 1 root root 56 2003-11-21 12:56 my_dialup_script
I thought the above permissions would cause the script to be executed as root, and therefore it should have permissions to create or modify the file /etc/resolv.conf.
It's true but, due to security reasons, this feature is disabled for shell scripts. I think a Perl script can be used instead but I haven't tested it.
AIUI the SUID flag sets the file to execute under the user who initiates it.
This is not true. -- A.M.
On Friday 21 November 2003 19:51 pm, Alexandr Malusek wrote:
Dylan
writes: On Friday 21 November 2003 18:18 pm, K V wrote: <SNIP>
The shell script is owned by root, and I set the permissions with chmod a+xs. It now looks like this:
-rwsr-sr-x 1 root root 56 2003-11-21 12:56 my_dialup_script
I thought the above permissions would cause the script to be executed as root, and therefore it should have permissions to create or modify the file /etc/resolv.conf.
It's true but, due to security reasons, this feature is disabled for shell scripts. I think a Perl script can be used instead but I haven't tested it.
AIUI the SUID flag sets the file to execute under the user who initiates it.
This is not true.
Thank you for clarifying the situation. It is a good day when we learn something. Dylan
-- A.M.
-- Sweet moderation Heart of this nation Desert us not We are between the wars - Billy Bragg
--- Alexandr Malusek
Dylan
writes: The shell script is owned by root, and I set the permissions with chmod a+xs. It now looks like
On Friday 21 November 2003 18:18 pm, K V wrote: <SNIP> this:
-rwsr-sr-x 1 root root 56
12:56 my_dialup_script
I thought the above permissions would cause the
2003-11-21 script
to be executed as root, and therefore it should have permissions to create or modify the file /etc/resolv.conf.
It's true but, due to security reasons, this feature is disabled for shell scripts. I think a Perl script can be used instead but I haven't tested it.
Thanks for the feedback. I now tried to do the same
thing with a C++ program instead of a shell script:
#include
K V
Thanks for the feedback. I now tried to do the same thing with a C++ program instead of a shell script:
#include
int main() { system("touch /etc/resolv.conf"); return 0; } with permissions as follows:
-rwsr-sr-x 1 root root 8691 2003-11-22 17:02 a.out
However, the same problem occurs:
klaus@linux:~> ./a.out touch: cannot touch `/etc/resolv.conf': Permission denied
Use:
#include
Maybe the problem is that the 'suid' bit can be set only for 'user' and 'group', but not for others?
Some description of the concept is in man pages of setuid, ... If I remember it right, a good description was in the book "Linux Application Development" (see http://people.redhat.com/johnsonm/lad/contents.html). -- A.M.
--- Alexandr Malusek
Use:
#include
#include #include int main() { setuid(0); system("/usr/bin/touch /etc/resolv.conf"); return 0; }
Thanks a lot! That works. I didn't even know about
real vs. effective uid.
--- "Carlos E. R."
man system:
Do not use system() from a program with suid or sgid privileges (...)
I tried both system() and execl(), and the behavior seems to be the same. From what you wrote, however, I guess execl() would be safer, though. Unfortunately there's another issue where my naive approach doesn't work. Calling my binary 'touchresolv', I simply replaced the executable for the shortcut to kppp on my taskbar (kicker) with "touchresolv; kppp". Now if I click the shortcut icon, kicker freezes until I close kppp. After closing kppp, I get an error message "couldn't start /bin/sh". Any ideas? Maybe I should ask this question on the kde list... Klaus __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
The Monday 2003-11-24 at 20:12 -0800, K V wrote:
Any ideas? Maybe I should ask this question on the kde list...
I am not a linux programmer, so I don't really know. But there was a mention of something like that in the man page from which I pasted the relevant bit the other day. But the solution to your original problem must be different. Something must be deleting your resolv file. I could investigate it, but I don't use kppp... try to search for some other files of the name "resolv*", look for scripts containing that word. Start with /etc/ppp/ip-up, it modifies or calls another script that modifies resolv.conf file. Also look under sysconfig/network or roundabouts (from memory). -- Cheers, Carlos Robinson
--- "Carlos E. R."
But the solution to your original problem must be different. Something must be deleting your resolv file. I could investigate it, but I don't use kppp... try to search for some other files of the name "resolv*", look for scripts containing that word.
Start with /etc/ppp/ip-up, it modifies or calls another script that modifies resolv.conf file. Also look under sysconfig/network or roundabouts (from memory).
Thanks, that was the pointer I needed. Turns out there is a simple fix - let me write the whole story up for the list, in case others run into the same problem: The original problem was that kppp is complaining that it can't find the file /etc/resolv.conf; if I created the file it would be deleted after each online session. Turns out the pppd service, upon activating a ppp session, first backs up the original /etc/resolv.conf, and then creates its own version. After terminating the connection, the original file is restored. For some strange reason, however, if the original file is empty, it doesn't get restored, but is deleted instead. So the simple solution is to create a /etc/resolv.conf with a single comment line in it, and everything is fine. Klaus __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
The Tuesday 2003-11-25 at 14:51 -0800, K V wrote:
Turns out the pppd service, upon activating a ppp session, first backs up the original /etc/resolv.conf, and then creates its own version. After terminating
So far, I knew, more or less.
the connection, the original file is restored. For some strange reason, however, if the original file is empty, it doesn't get restored, but is deleted instead.
That, I never would have guessed. I thought it would be more complex than this...
So the simple solution is to create a /etc/resolv.conf with a single comment line in it, and everything is fine.
I suggest you report this to feedback. However... who creates resolv.conf in the first place, yast? It could happen that the next time you run yast or suseconfig it might be deleted again, because the rules for creating it are empty. -- Cheers, Carlos Robinson
The Saturday 2003-11-22 at 14:24 -0800, K V wrote:
with permissions as follows:
-rwsr-sr-x 1 root root 8691 2003-11-22 17:02 a.out
However, the same problem occurs:
klaus@linux:~> ./a.out touch: cannot touch `/etc/resolv.conf': Permission denied
Maybe the problem is that the 'suid' bit can be set only for 'user' and 'group', but not for others? But then, how can one get around this problem?
As I told you the other day, you need only user, not group sgid. -- Cheers, Carlos Robinson
The Saturday 2003-11-22 at 14:24 -0800, K V wrote:
system("touch /etc/resolv.conf"); return 0; }
man system: Do not use system() from a program with suid or sgid privileges, because strange values for some environment variables might be used to subvert system integrity. Use the exec(3) family of functions instead, but not execlp(3) or execvp(3). system() will not, in fact, work properly from programs with suid or sgid privi leges on systems on which /bin/sh is bash version 2, since bash 2 drops privileges on startup. (Debian uses a modified bash which does not do this when invoked as sh.) So... -- Cheers, Carlos Robinson
The Friday 2003-11-21 at 10:18 -0800, K V wrote:
The shell script is owned by root, and I set the permissions with chmod a+xs. It now looks like this:
-rwsr-sr-x 1 root root 56 2003-11-21 12:56 my_dialup_script
If I remember correctly, suid bit is ignored on scripts. Other wise, you need SUID, not SGID. -- Cheers, Carlos Robinson
participants (4)
-
Alexandr Malusek
-
Carlos E. R.
-
Dylan
-
K V