Blattus Slafaly £ ¥ 0/00 wrote:
> How do you change to su or root in KDE when a KDE program requires Root
> privs? That is without ending the entire session and logging into KDE
> as root with the bomb screen and everything. I'm just thinking about
> su'ing in a console terminal and executing the KDE program from the
> command line? Is that the way? Just tried it, seems to work. If there is
> another way, let me know. Thanks.

You could try the menu editor, and check "run as different user". If you
have a "shortcut" on the desktop, right-click it, select properties,
click the "Application" tab, then the "Advanced Options" button, and in
the "user" box check "run as different user". I haven't done this for a
long time, but I THINK it's right....

How do you change to su or root in KDE when a KDE program requires Root
privs? That is without ending the entire session and logging into KDE
as root with the bomb screen and everything. I'm just thinking about
su'ing in a console terminal and executing the KDE program from the
command line? Is that the way? Just tried it, seems to work. If there is
another way, let me know. Thanks.
--
Blattus Slafaly ? 3 7/8

Blattus Slafaly £ ¥ 0/00 wrote:
> How do you change to su or root in KDE when a KDE program requires Root
> privs? That is without ending the entire session and logging into KDE
> as root with the bomb screen and everything. I'm just thinking about
> su'ing in a console terminal and executing the KDE program from the
> command line? Is that the way? Just tried it, seems to work. If there is
> another way, let me know. Thanks.

Use 'kdesu' instead of 'su'. I guess the most common task you need as
root, is edit files in /etc. For example, 'kdesu kwrite /etc/filetoedit'.

There's also "System->File Manager->File Manager Super User Mode" in the
K menu. Personally, I use kdesu because it remembers the password so I
won't have to type it over and over again.

Nikos Chantziaras wrote:
> Blattus Slafaly £ ¥ 0/00 wrote:
>> How do you change to su or root in KDE when a KDE program requires
>> Root privs? That is without ending the entire session and logging
>> into KDE as root with the bomb screen and everything. I'm just
>> thinking about su'ing in a console terminal and executing the KDE
>> program from the command line? Is that the way? Just tried it, seems
>> to work. If there is another way, let me know. Thanks.
>
> Use 'kdesu' instead of 'su'. I guess the most common task you need as
> root, is edit files in /etc. For example, 'kdesu kwrite /etc/filetoedit'.
>
> There's also "System->File Manager->File Manager Super User Mode" in the
> K menu. Personally, I use kdesu because it remembers the password so I
> won't have to type it over and over again.

Well I downloaded a program called Kiso to make iso images from cd so I
could add files to them with ISO master and re-burn them. I needed some
files in in a virtual machine in virtualbox and I don't have bridging
set up yet. the program Kiso kept closing saying I needed to be root but
didn't pop up a box to type the root password. I'll try that kdesu next
time.

--
Blattus Slafaly ? 3 7/8

"Blattus Slafaly £ ¥ 0/00 " wrote:
>How do you change to su or root in KDE when a KDE program requires Root
>privs? That is without ending the entire session and logging into KDE
>as root with the bomb screen and everything. I'm just thinking about
>su'ing in a console terminal and executing the KDE program from the
>command line? Is that the way? Just tried it, seems to work. If there is
>another way, let me know. Thanks.

Pay no attention to the insults. Some folks do that.

Let me give you (and them) an example. Say I want to
run "ifconfig" to check on something with my network
connection. You cannot run that as a normal user because
it will not be found by a normal user's search path.

What I do is in a console window run (the $ is the prompt)

$ su

which asks for a password and then (in 10.3 at least) gives
me a blood-red prompt. I can then type

$ ifconfig

and it runs. I then do

$ exit

to get out of being root before I do anything stupid.

There are other programs where you can, instead, run

$ sudo xxxxx

which asks for the root password and then, if you enter it
properly, runs program xxxxx for you. Permission to be root
expires quickly after the end of program xxxxx.

But this technique will not find any program not on your path.

The reason for all this is that the havoc you can work by being
root is unmeasurable. It isn't hard to blow away whole groups
of directories or even wipe the machine totally.

--
--- Paul J. Gans

Nikos Chantziaras wrote:
>Blattus Slafaly £ ¥ 0/00 wrote:
>> How do you change to su or root in KDE when a KDE program requires Root
>> privs? That is without ending the entire session and logging into KDE
>> as root with the bomb screen and everything. I'm just thinking about
>> su'ing in a console terminal and executing the KDE program from the
>> command line? Is that the way? Just tried it, seems to work. If there is
>> another way, let me know. Thanks.

>Use 'kdesu' instead of 'su'. I guess the most common task you need as
>root, is edit files in /etc. For example, 'kdesu kwrite /etc/filetoedit'.

>There's also "System->File Manager->File Manager Super User Mode" in the
>K menu. Personally, I use kdesu because it remembers the password so I
>won't have to type it over and over again.

The only problem with that is that some programs, mainly those in
/sbin (and I think in /usr/sbin) that are not on a user's search
path *unless* they are linked to programs that *are* on the user's
search path.

For those you simply have to be root, which is intentional. A
sudo won't work since you are then still you with root permissions.

--
--- Paul J. Gans

Paul J Gans wrote:
> Let me give you (and them) an example. Say I want to
> run "ifconfig" to check on something with my network
> connection. You cannot run that as a normal user because
> it will not be found by a normal user's search path.
>
> What I do is in a console window run (the $ is the prompt)
>
> $ su
>
> which asks for a password and then (in 10.3 at least) gives
> me a blood-red prompt. I can then type
>
> $ ifconfig
>
> and it runs. I then do

If you were in school this would get you just enough to pass class. ;-)

Now if the GP has enough information, the following will just confuse
hime, making me flink class altogether. :-D

There is more to it. On openSUSE this will work, because su is set the
same as `su -`. I still use `su -`.

As the GP is talking about KDE, it migt be that he needs a graphic
program to run. On GUI this would mean you need to run `sux` or even
better `sux -`. That will make you root with the ability to run programs
as root, like YaST

Then there is kdesu and other GUI based programs that do the same.

> $ exit
>
> to get out of being root before I do anything stupid.

I use [CTRL][d]

> There are other programs where you can, instead, run
>
> $ sudo xxxxx
>
> which asks for the root password and then, if you enter it
> properly, runs program xxxxx for you. Permission to be root
> expires quickly after the end of program xxxxx.
>
> But this technique will not find any program not on your path.

Ther is however a good way if you are running programs often as root.
You can set op sudoers (use `sudo /usr/sbin/visudo`).
Several things can be done.
1) Only specific users can use the program.
2) Only specific users can use a program
by entering the root password
by entering their own password
by not entering a password at all

And by

The advantage of this is that in doing so, you do not need to give users
the root password, while they still have the ability to do certain
maintenence tasks on the sytem.
e.g. you can give people from HR the right to make a new user. That way
the IT people do not need to do that, as it might be more of an
administrative thing then a technical thing.

Another thing might be that you want your webmaster to master the web
and apache, yet not touch the rest.

Yet another way for some programs, is to use the full path. e.g.
traceroute can ifconfig can be run with /sbin/traceroute and
/sbin/ifconfig. You can put a symlink in /usr/local/bin to those
programs, so that users do not have to type in the extra stuff.

You can even put in symlinks with the names ipconfig and tracert if that
is something your users prefere.

> The reason for all this is that the havoc you can work by being
> root is unmeasurable. It isn't hard to blow away whole groups
> of directories or even wipe the machine totally.

chown -r 666 /

I still like that one best. It is so much more evil then just removing
stuff. If you remove everything, you swaer, reinstall and be done. With
this you first try to repair it and waste a LOT of time. :-D

houghi
--

You are standing at the end of a road before a small brick building.
Around you is a forest. A small stream flows out of the building and
down a gully.

The carbonbased lifeform Paul J Gans inspired alt.os.linux.suse with:
> "Blattus Slafaly £ ¥ 0/00 " wrote:
>>How do you change to su or root in KDE when a KDE program requires Root
>>privs? That is without ending the entire session and logging into KDE
>>as root with the bomb screen and everything. I'm just thinking about
>>su'ing in a console terminal and executing the KDE program from the
>>command line? Is that the way? Just tried it, seems to work. If there is
>>another way, let me know. Thanks.
>
> Pay no attention to the insults. Some folks do that.

And sometimes well deserved too.

> Let me give you (and them) an example. Say I want to
> run "ifconfig" to check on something with my network
> connection. You cannot run that as a normal user because
> it will not be found by a normal user's search path.
>
> What I do is in a console window run (the $ is the prompt)
>
> $ su
>
> which asks for a password and then (in 10.3 at least) gives
> me a blood-red prompt. I can then type
>
> $ ifconfig
>
> and it runs. I then do

Not if /sbin isn't in your PATH already, and then you can also run it as
user.
Rtfm; 'su' by itself doesn't change the enviroment variables.

$ echo $PATH
/home/theo/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/gam
es:/opt/kde3/bin:/usr/lib/jvm/jre/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/usr/li
b/qt3/bin:/usr/java/jre1.5.0_01/bin:/usr/sbin:/sbin:/home/theo/bin:/usr/java/jre
1.5.0_01/bin:/usr/sbin:/sbin:/home/theo/bin:/usr/java/jre1.5.0_01/bin

$ su
Password:
root:/home/theo # echo $PATH
/home/theo/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/gam
es:/opt/kde3/bin:/usr/lib/jvm/jre/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/usr/li
b/qt3/bin:/usr/java/jre1.5.0_01/bin:/usr/sbin:/sbin:/home/theo/bin:/usr/java/jre
1.5.0_01/bin:/usr/sbin:/sbin:/home/theo/bin:/usr/java/jre1.5.0_01/bin

Only if I use su with '-', so it gives me a login shell, do I get root's
PATH
$ su -
Password:
root:/root # echo $PATH
/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:
/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/lib/jvm/jre/bin:/usr/lib/mit/bin:
/usr/lib/mit/sbin:/usr/lib/qt3/bin:/usr/java/jre1.5.0_01/bin


> $ exit

Try ^d

> to get out of being root before I do anything stupid.

If you really want to run a one-off command, or a small sequal of
commands as root, use 'su - -c "command;command;.."'

> There are other programs where you can, instead, run
>
> $ sudo xxxxx
>
> which asks for the root password and then, if you enter it

Only if you've set 'rootpw' option in sudoers, otherwise it asks for the
user's password by default.

> properly, runs program xxxxx for you. Permission to be root
> expires quickly after the end of program xxxxx.
> But this technique will not find any program not on your path.

Again: rtfm.
Unless you set 'set_home' in sudoers, so you get root's PATH when you
invoke sudo -s.

> The reason for all this is that the havoc you can work by being
> root is unmeasurable. It isn't hard to blow away whole groups
> of directories or even wipe the machine totally.

That's exactly the point of having an account like root, to be able to
do those things without backtalk from the OS with questions like 'are
you sure'...
And why you then first mention 'su', instead of sudo without the rootpw
option, is beyond me.

Theo
--
theo at van-werkhoven.nl ICQ:277217131 SuSE Linux
linuxcounter.org: 99872 Jabber:muadib at jabber.xs4all.nl AMD XP3000+ 1024MB
"ik _heb_ niets tegen Microsoft, ik heb iets tegen
de uitwassen *van* Microsoft"

Theo v. Werkhoven wrote:
>> $ su
>>
>> which asks for a password and then (in 10.3 at least) gives
>> me a blood-red prompt. I can then type
>>
>> $ ifconfig
>>
>> and it runs. I then do
>
> Not if /sbin isn't in your PATH already, and then you can also run it as
> user.

It works and as we are in a openSUSE group you can expect others to use
it as well and it will most likely work there as well:
houghi@penne : ifconfig
bash: ifconfig: command not found
[~/wallpaper/to_work_on/wpm/to_sort]
houghi@penne : su
Password:
- - R O O T - - - R O O T - - - R O O T - - - R O O T - - - R O O T - -
[10:27:06] [/home/houghi/wallpaper/to_work_on/wpm/to_sort]
root@penne : ifconfig
eth0 Link encap:Ethernet HWaddr 00:0C:6E:02:53:62
inet addr:192.168.1.200 Bcast:192.168.1.255
Mask:255.255.255.0

> Rtfm; 'su' by itself doesn't change the enviroment variables.

Try it out and see for yourself.

>> $ exit
>
> Try ^d

They both work.

>> to get out of being root before I do anything stupid.
>
> If you really want to run a one-off command, or a small sequal of
> commands as root, use 'su - -c "command;command;.."'

or any of the other methods.

>> There are other programs where you can, instead, run
>>
>> $ sudo xxxxx
>>
>> which asks for the root password and then, if you enter it
>
> Only if you've set 'rootpw' option in sudoers, otherwise it asks for the
> user's password by default.

Well, again this is openSUSE, so we can asume people are using that and
also the defauly settings.

> And why you then first mention 'su', instead of sudo without the rootpw
> option, is beyond me.

Because that is the standard order to mention it. First you explain su,
then you explain sudo. The reason is simple.
A user asks how he can run programs as root. The best way to get him on
his way is to say: open a terminal and type `su -` or even better `sux
-`. That way that user is on his way and can work with several programs
to his liking.

next when he wants to go deeper into things and probably when he has
deleted his complete HD a few times, he has learned a valuable lesson
and will want to know more.

At that moment he has insight and willingness to go on. THEN you explain
how sudoers works.

Is it the best route to take from a technical point of view? No. We are
working with people however, so it is the best socail way of explainingg
things.

You can say often to a kid not to tough something, because it is hot,
but the lesson it learns from understanding what hot means is something
that will stay with him the rest of his life.

So yes, the best way is to explain first what su does and then go on. It
is called learning. And the easiest way is to make the learning curve as
flat as possible, because if it is too steep, people will think it isn't
a curve, but a wall.

The fact that they WILL make mistakes is a good one, because that is a
way to learn.

Once when I worked together with some people doing DNS stuff, there was
a small difference between a DNS maintainer and actualy being a DNS
master. Thatw as forgetting the trailing dot. Only then were you allowed
to call yourself a ful DNS master.

Everybody had that happen at one point (after their initial training,
when they were fully operational) and the problems that caused that and
the way to solve it (with the customer, explaining hings) worked great,
bvecause they would ALWAYS be more carefull with everything else in the
future.

We could have made it idiot proof, but that one error kept them on their
toes for many years, because only then did they understand the true
power of the D N S MASTER.

houghi
--

You are standing at the end of a road before a small brick building.
Around you is a forest. A small stream flows out of the building and
down a gully.

Paul J Gans writes:


>Let me give you (and them) an example. Say I want to
>run "ifconfig" to check on something with my network

IF you only want to 'check' something...

>connection. You cannot run that as a normal user because
>it will not be found by a normal user's search path.

... then just say " /sbin/ifconfig " as a simle user..!


Nothing hinders you to start a programm with it's full path.
Either as a user (notable for /usr/sbin/traceroute ) nor
as root. I have some system, there " /usr/local/bin " is NOT
in the PARH of root. So I start some program ther with it's
full path.

Yours, Holger

Paul J Gans writes:


>The only problem with that is that some programs, mainly those in
>/sbin (and I think in /usr/sbin) that are not on a user's search
>path *unless* they are linked to programs that *are* on the user's
>search path.

True.

>For those you simply have to be root

No.


> which is intentional.

Might be (security by obscurity ?) but _if_ there should be a real
reason for prohibiting a simple user from running a program, there
are still the normal unix rights:

The following command:

ls -l /sbin/ /usr/sbin/ | grep -- ---

shows 21 programs (on my system) which cannot be started by a normal
user; "mgetty" is one of them; "isdnctrl" and "mtr" are executable
only if the user is in the group 'dialout'.

Yours, Holger

On Sun, 16 Mar 2008 04:02:21 +0000, Paul J Gans wrote:

> Let me give you (and them) an example. Say I want to run "ifconfig" to
> check on something with my network connection. You cannot run that as a
> normal user because it will not be found by a normal user's search path.

/sbin/ifconfig works as a normal user under nearly every distro I've ever
used :-)

On Sun, 16 Mar 2008, houghi wrote:-

>Theo v. Werkhoven wrote:

>> Not if /sbin isn't in your PATH already, and then you can also run it as
>> user.
>
>It works and as we are in a openSUSE group you can expect others to use
>it as well and it will most likely work there as well:
>houghi@penne : ifconfig
>bash: ifconfig: command not found
>[~/wallpaper/to_work_on/wpm/to_sort]
>houghi@penne : su
>Password:
> - - R O O T - - - R O O T - - - R O O T - - - R O O T - - - R O O T - -
>[10:27:06] [/home/houghi/wallpaper/to_work_on/wpm/to_sort]
>root@penne : ifconfig
>eth0 Link encap:Ethernet HWaddr 00:0C:6E:02:53:62
> inet addr:192.168.1.200 Bcast:192.168.1.255
>Mask:255.255.255.0

There's been a change since the last time I looked at this. It used to
be that using "su" didn't change $PATH to include /sbin or /usr/sbin,
but now it does. Still doesn't give the full root environment or $PATH
though:

davjam@dav2:~> su
Password:
root@dav2:/home/davjam> echo "${PATH}"
/home/davjam/bin:/usr/local/bin:/usr/bin:/sbin:/usr/sbin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/opt/cross/bin:/usr/lib64/jvm
/jre/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/usr/lib/qt3/bin
root@dav2:/home/davjam> exit
davjam@dav2:~> echo "${PATH}"
/home/davjam/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/opt/cross/bin:/usr/lib64/jvm/jre/bin:/usr/li
b/mit/bin:/usr/lib/mit/sbin:/usr/lib/qt3/bin
davjam@dav2:~> su -
Password:
dav2:~ # echo "${PATH}"
/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/opt/cross/bin:/usr/
lib64/jvm/jre/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/usr/lib/qt3/bin

>> Rtfm; 'su' by itself doesn't change the enviroment variables.

By default, su _used to_ set $HOME and $SHELL, and also $USER and
$LOGNAME for non-root users, but didn't touch $PATH.

>Try it out and see for yourself.

It appears that Novell have changed this behaviour as $PATH is also
altered when using su. It's still not quite the same as using "su -" as
that opens the shell as a login shell, with the full environment set up
for that user.

>You can say often to a kid not to tough something, because it is hot,
>but the lesson it learns from understanding what hot means is something
>that will stay with him the rest of his life.

And, if the child is there with others of the same age-group, they also
learn from the first child misfortune as well.

>So yes, the best way is to explain first what su does and then go on. It
>is called learning. And the easiest way is to make the learning curve as
>flat as possible, because if it is too steep, people will think it isn't
>a curve, but a wall.
>
>The fact that they WILL make mistakes is a good one, because that is a
>way to learn.

I think it's one of the best ways to learn, with an even better one
being the ability to learn from other peoples mistakes rather than
having to make the mistakes personally. On the other hand, making the
mistakes personally is a good way of making sure the lessons stick.

>Once when I worked together with some people doing DNS stuff, there was
>a small difference between a DNS maintainer and actualy being a DNS
>master. Thatw as forgetting the trailing dot. Only then were you allowed
>to call yourself a ful DNS master.

Woohoo! That means I'm a DNS master :-)

>We could have made it idiot proof,

No you couldn't. It's a known fact that, every time you find a way to
make something slightly more idiot-proof, Nature compensates by making a
better idiot. One that somehow manages to find other ways around the
idiot-proofing.


Regards,
David Bolt

--
www.davjam.org/lifetype/ www.distributed.net: OGR@100Mnodes, RC5-72@15Mkeys
SUSE 10.1 32bit | openSUSE 10.2 32bit | openSUSE 10.3 32bit | openSUSE 11.0a1
SUSE 10.1 64bit | openSUSE 10.2 64bit | openSUSE 10.3 64bit
RISC OS 3.6 | TOS 4.02 | openSUSE 10.3 PPC |RISC OS 3.11

Holger Petersen wrote:
>> which is intentional.
>
> Might be (security by obscurity ?) but _if_ there should be a real
> reason for prohibiting a simple user from running a program, there
> are still the normal unix rights:

It is not so much a security as it is to make clear that normal users do
not need these. From `man hier`: /sbin Like /bin, this directory holds
commands needed to boot the sys- tem, but which are usually not executed
by normal users

Obviously it would be easy to deny users access to /sbin.

houghi
--

You are standing at the end of a road before a small brick building.
Around you is a forest. A small stream flows out of the building and
down a gully.

The carbonbased lifeform houghi inspired alt.os.linux.suse with:
> Theo v. Werkhoven wrote:
>>> $ su
>>>
>>> which asks for a password and then (in 10.3 at least) gives
>>> me a blood-red prompt. I can then type
>>>
>>> $ ifconfig
>>>
>>> and it runs. I then do
>>
>> Not if /sbin isn't in your PATH already, and then you can also run it as
>> user.
>
> It works and as we are in a openSUSE group you can expect others to use
> it as well and it will most likely work there as well:

The fact that it's an openSUSE thing doesn't automatically make it
sensible or desirable.
I think that 'root' commands must work without surprises like aliases
with undefined options to the real commands etc.

But if you think it's a good idea to let SUSE define how you do root
stuff: fine, I'm not going to argue about that.

My su and sudo work as defined in the man pages, which is how /I/ like
it.

> houghi@penne : ifconfig
> bash: ifconfig: command not found

Yeah, 'echo "PATH=$PATH:/sbin:/usr/sbin" >>/.bashrc' is really hard
isn't it?

>> Rtfm; 'su' by itself doesn't change the enviroment variables.
>
> Try it out and see for yourself.

I did, I showed it here.

>>> $ exit
>>
>> Try ^d
>
> They both work.

That wasn't the issue. It was an advice for a 'shortcut'

>>> to get out of being root before I do anything stupid.
>>
>> If you really want to run a one-off command, or a small sequal of
>> commands as root, use 'su - -c "command;command;.."'
>
> or any of the other methods.
>
>>> There are other programs where you can, instead, run
>>>
>>> $ sudo xxxxx
>>>
>>> which asks for the root password and then, if you enter it
>>
>> Only if you've set 'rootpw' option in sudoers, otherwise it asks for the
>> user's password by default.
>
> Well, again this is openSUSE, so we can asume people are using that and
> also the defauly settings.

rootpw /not/ set *is* the default, for 'normal' sudo anyway.
sudoers(5)
rootpw If set, sudo will prompt for the root password instead of
the password of the invoking user.
This flag is off by default.

>> And why you then first mention 'su', instead of sudo without the rootpw
>> option, is beyond me.
>
> Because that is the standard order to mention it. First you explain su,
> then you explain sudo. The reason is simple.
[..]

The rest of your story is a preach to the wrong chancel, and I'm not in
that chancel. I do not agree that you need to let people play with a
gun with live ammo, before you explain the safety switch, just to
"intensify" the idea why a safety switch is a good idea.

I think that showing people the correct way from the beginning is much
more sensible.

Theo
--
theo at van-werkhoven.nl ICQ:277217131 SuSE Linux
linuxcounter.org: 99872 Jabber:muadib at jabber.xs4all.nl AMD XP3000+ 1024MB
"ik _heb_ niets tegen Microsoft, ik heb iets tegen
de uitwassen *van* Microsoft"

On Sun, 16 Mar 2008, Theo v. Werkhoven wrote:-

>The carbonbased lifeform houghi inspired alt.os.linux.suse with:

>> Well, again this is openSUSE, so we can asume people are using that and
>> also the defauly settings.
>
>rootpw /not/ set *is* the default, for 'normal' sudo anyway.
>sudoers(5)
>rootpw If set, sudo will prompt for the root password instead of
> the password of the invoking user.
> This flag is off by default.

Interestingly, I have four 10.3 installations up and running right now.
Of those four, two were upgrades from 10.0 and the others were fresh
installs. None of those have rootpw in /etc/sudoers . Three of them,
both the fresh installs and one of the upgrades, have the line:

Defaults targetpw

so that the target users password, which is most likely to be root, is
required. The fourth system didn't[0] have that line and so used to ask
for the calling users password instead.


[0] It does now.

Regards,
David Bolt

--
www.davjam.org/lifetype/ www.distributed.net: OGR@100Mnodes, RC5-72@15Mkeys
SUSE 10.1 32bit | openSUSE 10.2 32bit | openSUSE 10.3 32bit | openSUSE 11.0a1
SUSE 10.1 64bit | openSUSE 10.2 64bit | openSUSE 10.3 64bit
RISC OS 3.6 | TOS 4.02 | openSUSE 10.3 PPC |RISC OS 3.11

houghi wrote:
> Holger Petersen wrote:
>>> which is intentional.
>> Might be (security by obscurity ?) but _if_ there should be a real
>> reason for prohibiting a simple user from running a program, there
>> are still the normal unix rights:
>
> It is not so much a security as it is to make clear that normal users do
> not need these. From `man hier`: /sbin Like /bin, this directory holds
> commands needed to boot the sys- tem, but which are usually not executed
> by normal users
>
> Obviously it would be easy to deny users access to /sbin.

Those executables are unlikely to be used by "users", except the user
who is also root. At home, it means you So instead of worrying
about su, the simplest solution is to put /sbin and /usr/sbin in your
PATH (~/.bashrc) and use sudo and kdesu or sux.

Oh, and ifconfig needs root if changing interface parameters.

David Bolt wrote:
> There's been a change since the last time I looked at this. It used to
> be that using "su" didn't change $PATH to include /sbin or /usr/sbin,
> but now it does. Still doesn't give the full root environment or $PATH
> though:

I believe this was in a release notes of one of the versions. I am sure
I have seen it mentioned somewhere.

> By default, su _used to_ set $HOME and $SHELL, and also $USER and
> $LOGNAME for non-root users, but didn't touch $PATH.

That has changed. Unfortunatly I can not remeber when or where I saw it.
Looked up google and also mailinglists, but I was unable to find it in
my 5 minute search.
The main reason was that you did not need to type su - anymore and there
was no real security reason NOT to do it.


houghi
--

You are standing at the end of a road before a small brick building.
Around you is a forest. A small stream flows out of the building and
down a gully.

Theo v. Werkhoven wrote:
>> It works and as we are in a openSUSE group you can expect others to use
>> it as well and it will most likely work there as well:
>
> The fact that it's an openSUSE thing doesn't automatically make it
> sensible or desirable.

Indeed is des not. However this is an openSUSE group, so one should
expect them to have the openSUSE defaults, be they right or wrong.

> I think that 'root' commands must work without surprises like aliases
> with undefined options to the real commands etc.

Great if that is your idea.

> But if you think it's a good idea to let SUSE define how you do root
> stuff: fine, I'm not going to argue about that.

This would not be the place to do that arguement.

> My su and sudo work as defined in the man pages, which is how /I/ like
> it.

Great. Mine work as default and yet I sill always type `sux -`

>> houghi@penne : ifconfig
>> bash: ifconfig: command not found
>
> Yeah, 'echo "PATH=$PATH:/sbin:/usr/sbin" >>/.bashrc' is really hard
> isn't it?
>
>>> Rtfm; 'su' by itself doesn't change the enviroment variables.
>>
>> Try it out and see for yourself.
>
> I did, I showed it here.

OK, my bad. So you have either not the default, or a system that does
not yet have the changes.

>> Well, again this is openSUSE, so we can asume people are using that and
>> also the defauly settings.
>
> rootpw /not/ set *is* the default, for 'normal' sudo anyway.
> sudoers(5)

Again, we are working with openSUSE here, so we should take the defaults
of openSUSE as our defaults. If the default would be to have no password
for anbody to use root (which would be bad) then that would be what we
would use (and change).
(Unfortunatly?) we need to work with the tools that are given to us and
in this case this is the default settings.

> I think that showing people the correct way from the beginning is much
> more sensible.

I agree. The sad thing is that it does not work. When working with
people, sensible is not always the right way to achieve a goal.

houghi
--

You are standing at the end of a road before a small brick building.
Around you is a forest. A small stream flows out of the building and
down a gully.