Tiny Core Linux
Tiny Core Base => TCB Q&A Forum => Topic started by: hjkl on December 14, 2008, 03:01:08 PM
-
Hi,
b34a6ad48638bd082727c8053923d5c9 tinycore_1.0rc4.iso
I open a terminal on TinyCore and 'sudo su'. Now, I get "root@box:~#" and become a root user
in "/root". Before the change, 'sudo su' gave me "root@box:/home/tc#" and used "/home/tc" directory.
I know this is not a bug because I also noticed a change in JWM's menu.
From the menu:
(new: root@box:~#)
aterm -cr red -T "Root Shell" -e sudo su
(old: root@box:/home/tc#)
aterm -cr red -T "Root Shell" -e sudo /bin/sh
I got used to the "old" behavior, so I would like to know why this change is better
than the other one.
-
both are home directories, it's the same as cd ~ ... /home/tc is user tc's home, /root is user root's home.
it makes less sense if you are root to be in another user's home directory.
-
Hi tobiaus,
I see what you mean. Then, I wonder why we kept the other way for a long time.
If I am not mistaken, the "old" behavior goes back beyond DSL-2.0.
Well, I think I have to get rid of my old habit.
Thanks for the reply.
-
hjkl: I agree with your first post.
`sudo su` should not change dirs because it should retain most of the calling user's environment (unless it was made to do so explicitly, ie in sudoers, or a login shell). I'm not sure what change caused this.
I was comparing 1.0 rc3 and rc4 and did not notice a difference between the jwm menus though (~/.jwmrc)
-
As I see it, using su from within an existing terminal should never change the directory, and shouldn't change the environment unless you do "su -". Maybe that's not how su was officially designed, but that's what I think it was designed to do, and that's what makes sense to me.
(new: root@box:~#)
aterm -cr red -T "Root Shell" -e sudo su
(old: root@box:/home/tc#)
aterm -cr red -T "Root Shell" -e sudo /bin/sh
I got used to the "old" behavior, so I would like to know why this change is better
than the other one.
The above change is partly logical to me. Opening a root shell from a menu item should use the root user's chosen shell. The old version used /bin/sh regardless of what root's shell happens to be (assume the shell may have been changed to bash or zsh or whatever else).
I'm not so sure about " root@box:~#". I don't have a problem with it, but I don't understand why or how the root shell is opening in /root. Typically a new shell opens within whatever directory you were in when you opened it, regardless of what HOME is.
-
Typically a new shell opens within whatever directory you were in when you opened it, regardless of what HOME is.
i agree with you, if we're talking about the same tty or the same aterm, switching from user to root and root to user. (although i've seen distros that do not behave this way.)
at any rate it matters more to me (and even then not too much) that the home folder be opened to per new tty or per aterm opened than whether or not sudo su follows that.
in linux there are few standards, but there are many conventions. certainly doing it the dsl way makes perfect sense, unless there is very good reason or strong preference to the contrary.
-
i agree with you, if we're talking about the same tty or the same aterm, switching from user to root and root to user.
Yes, and I would expect a menu item to behave the same. If, for example, you were to cd to an arbitrary directory while in tty , and then startx, you are still now in that new directory, and not in HOME. If you then start a terminal, either regular or root, I would think it would start off in that new directory. As I said, though, I don't have a problem with this particular situation being changed, as you said there are varying conventions...I guess either way works. What I haven't understood is *how* this is done. There doesn't seem to be anything that explicitly sends root to his home when a root term is opened.
-
I guess the only way would be to manually check the differences between rc3 and rc4... unless someone has some kind of insight into this change.
-
In other distros I dabble in, it was my understanding that if I use "sudo su" , I would still have
the global path of the user that I was before using the command, and somewhat limited use of the root shell
due to differing .bash profiles.
If I use " sudo su - " ( or su - ) , then i get the full root path, and unlimited use of the shell.
Is this incorrect? Not the usual behavior?
73
ke4nt
-
isn't it "su -l" rather than "su -"?
-
I guess the only way would be to manually check the differences between rc3 and rc4... unless someone has some kind of insight into this change.
Updated busybox which controls login and shell
-
Juanito: either or. - is just shorter
I guess there's always su -p (though still a bit different)
ah, I forgot su was part of bb.
-
Hi,
Thanks everyone for good insights. They help.
To ^thehatsrule^:
I was comparing 1.0 rc3 and rc4 and did not notice a difference between the jwm menus though (~/.jwmrc)
You are correct. I forgot about the fact that the command:
aterm -cr red -T "Root Shell" -e sudo /bin/sh
was something I remembered.
Coincidentally, that line produced something I would want to see and made me jump to the conclusion.
There is nothing to do with JWM's menu.
To mikshaw:
The above change is partly logical to me. Opening a root shell from a menu item should use the root user's chosen shell. The old version used /bin/sh regardless of what root's shell happens to be (assume the shell may have been changed to bash or zsh or whatever else).
Again, you are right. That was my mistake. Thank you for the information.
I guess either way works. What I haven't understood is *how* this is done. There doesn't seem to be anything that explicitly sends root to his home when a root term is opened.
That's exactly what I would like to know.
To roberts:
Updated busybox which controls login and shell
I need to spend more time studying BusyBox.
OT:
Thank you very much for TinyCore. This is a very exciting project. I like it a lot.
-
Hi,
I have been using BusyBox's 'su' that comes with TinyCore.
So, when I 'sudo su' in '/home/tc', I become 'root' in '/root' directory.
tc@box:~$ sudo su
root@box:~#
Let's suppose that I'm a 'root' user, but a 'tc' user is a different person.
Then, I have no business using the 'tc' user's account or shell environment.
So, the "default" behavior of 'sudo su' on TinyCore makes sense.
However in my case, I am the 'root' and 'tc' user. I am the only person using my computer.
Also, being able to use the 'tc' user's configuration files as 'root' is very practical.
Therefore, I would like to have choices of using the "default" behavior or
sharing the 'tc' user's shell account and its environment.
My solution is to replace BusyBox's 'su' with 'su' from GNU Coreutils.
** Warning: This will install 'su' on your TinyCore temporally. **
24a7ab466c9b448203b9b2f7be944c4d tinycore_1.0rc8.iso
0e718639040e05ca7a3822f1a7d1163e compiletc.tce
tc@box:~$ tce-load compiletc.tce
94e5558ee2a65723d4840bfde2d323f0 coreutils-5.0.tar.bz2
tc@box:~$ tar -xvjf coreutils-5.0.tar.bz2
tc@box:~$ cd coreutils-5.0
tc@box:~/coreutils-5.0$ ./configure
tc@box:~/coreutils-5.0$ make
tc@box:~/coreutils-5.0$ sudo cp src/su /bin
tc@box:~/coreutils-5.0$ exit
Now, when I 'sudo su' in '/home/tc', I become 'root' and stay in the same directory.
However, the 'tc' user's shell account and its environment are not kept.
tc@box:~$ sudo su
root@box:/home/tc#
When I want to share the environment, I use 'sudo su -m' or 'sudo su -p'.
I hope this works for you too.
-
Let's suppose that I'm a 'root' user, but a 'tc' user is a different person.
Then, I have no business using the 'tc' user's account or shell environment.
So, the "default" behavior of 'sudo su' on TinyCore makes sense.
I disagree, since "sudo su" isn't the way for multiple people to use a system.
Tiny Core itself isn't configured by default to be a typical multiuser system.
I would say if you wanted to do this, you'd be better to make a couple of changes
to the init process and give each user a login prompt.
Now, when I 'sudo su' in '/home/tc', I become 'root' and stay in the same directory.
However, the 'tc' user's shell account and its environment are not kept.
tc@box:~$ sudo su
root@box:/home/tc#
When I want to share the environment, I use 'sudo su -m' or 'sudo su -p'.
I agree that this is the way it *should* be, since the user should have the choice and control of such behavior. But as I said it isn't a big problem for me. The one place where it would be a serious pain (and which I haven't tried) is in compiling software. I typically configure and make as regular user, except in a few instances where proper building doesn't happen without root power. When it comes to "make install", I'll sudo su and still be in that same directory. Whether or not "sudo make install" would be a suitable alternative, i don't know. Personally would like to remove sudo entirely (its reason for existence is to make things easier in a multi-user system) and stick with su only. But that's going a little off-topic.
-
Personally would like to remove sudo entirely (its reason for existence is to make things easier in a multi-user system) and stick with su only. But that's going a little off-topic.
i'm used to sudo su to become root, and since you're (thankfully) not root all the time in tc, i'm happy to use it to become root and do root things this way as well: sudo cp source rootonlydestination
there's usually not a login when you're using a livecd, but since i'm used to a login at other times, i wouldn't mind one. it would give the illusion (or the reality, or some of both) of being more secure.
removing sudo because it's being used in a way that's conventional one place and not quite as conventional (but still very useful) in tc seems a bit purist. so is even having multiuser, to some others. if tc is not capable of multiuser (i know, no one said that) i'd like to know what's preventing it. but then if it's really not, the answer is probably "all sorts of things."
-
removing sudo because it's being used in a way that's conventional one place and not quite as conventional (but still very useful) in tc seems a bit purist.
I'm not sure if you're assuming that's the reason I'd like to get rid of it, or if you just made that comment as a general statement. My own reason is mostly for the sake of security. Sudo makes it much too easy to do things as root, in my opinion. My ideal system would require a password to log in, and another password for doing any tasks that require root power.
if tc is not capable of multiuser (i know, no one said that) i'd like to know what's preventing it.
I assume it's quite capable, although I haven't done it yet. It looks like it's set up very similar to DSL, in that /etc/inittab would need to be changed to use getty instead of rungetty, wipe out the su in /root/.profile, and create passwords for tc and root users.
-
My own reason is mostly for the sake of security. Sudo makes it much too easy to do things as root, in my opinion. My ideal system would require a password to log in, and another password for doing any tasks that require root power.
i wasn't sure what your reason was, so i made a general statement that as i can now see, does not apply here. security is a great reason to remove sudo, if it makes much of a difference. i leave the if to your opinion. aside that, i wouldn't mind at all if login passwords were required. i won't argue for them, or against them, although they would be most welcome.
in xubuntu, which because it's ubuntu is odd in this regard, you can sudo su or sudo variouscommandshere, just like in dsl and tc. but if you are trying to do anything that requires root, it still asks for a password, with sudo or without. that seems to last for several minutes (this is good, not good? i don't know.)
if it can exist without compromising security, i really think it ought to be core, but you're more familiar with it. if it wasn't core, i hope it would at least be a .tce extension. i would be interested in ways that tc can be more secure, other than the read-only nature of the boot media and possibly other than the firewall.
i was able to remove sudo from tc very easily just before typing this, but (naturally) i'll have to reboot before i can use appbrowser, or mount or unmount devices. i am also now unable to use login, but i tried to become root that way. "su: must be suid to work properly" :) that's the best message since "reboot: no"
-
in xubuntu, which because it's ubuntu is odd in this regard, you can sudo su or sudo variouscommandshere, just like in dsl and tc. but if you are trying to do anything that requires root, it still asks for a password, with sudo or without. that seems to last for several minutes (this is good, not good? i don't know.)
I haven't used Suse in a couple of years, but I think that's the way sudo worked there too. I think that's probably the standard way to use it.
As far as the password itself, was that the user's password or root password? This is one of the things I've never understood about using sudo in a (typically) single-user system like TC. Sudo was written, as I understand it, to provide certain users the ability to do privileged tasks without having the privilege of knowing a root password...basically only useful if you run a multi-user system. If you are the only user, using sudo with a password provides no benefit over using just su (as far as I know).
if it wasn't core, i hope it would at least be a .tce extension.
I don't think there's any chance sudo will ever be removed. It has become a vital part of many tools. At my level of understanding and patience the best I'd be able to do is replace sudo with a script that prompts for a password, *if* I were to actually build my ideal system from TC. That's an idea I've been pondering in DSL for a long time, and still haven't even tried it.
i am also now unable to use login, but i tried to become root that way. "su: must be suid to work properly"
that's the best message since "reboot: no"
That sounds like maybe an oversight when Busybox was built? As hjkl did, I'd probably use the GNU version anyway .
-
Sudo with a password does have a single advantage compared to su. I believe lucky13 used to keep saying this too. You can restrict the right to use sudo to only the apps you want (reboot, poweroff?).
If sudo is accompanied by PAM you should be able to do all sorts of weird authentication too, starting from time-based (only allow between 13-15) to unbelievably crazy (only allow login if $BREAD is in $TOASTER, $COFFEE is ready, and $FRIENDS is on $TV).
-
can't speak for suse, but i'm glad it's not just a 'buntu thing.
however, in xubuntu/ubuntu/etctu, there is no root account per se, but you can sudo commandshere or sudo su. then you have full root-like capability, but since there is no root password, you use the user account password to gain sudo access. when i put it that way, it sounds like a really stupid idea, but it's my experience (and perhaps misunderstanding) based on using 'buntu for a year or more.
in tinycore, you can already set passwords for both root and tc, and presumably other accounts, so when you say "it's not multiuser" i feel like it depends what your definition is. i don't think the package system (that's relevant) is multiuser, or probably a number of other things. but it's linux, and it has more than one password and more than one account. so i would think, user or tc password to login as user or tc, root password for access to sudo.
but naturally that's hypothetical and depends on whether people (including roberts) wanted to make it that formal by default. i remember using the "secure" boot option in dsl which asked me to create passwords, but it never asked for them again, even when using sudo. i don't understand why, but someone probably does.
-
The "secure" option was mostly for ssh connections on the unmodified livecd. After a remaster or otherwise saved /etc/shadow it was not needed anymore.
-
"sudo su" changes to the home directory of root.
"sudo -s" will remain in the same directory where the command is executed.
-
After a remaster or otherwise saved /etc/shadow it was not needed anymore.
ah, etc/shadow, bringing me back to another question: whenever people talk of changing the password, they do strange incantations involving that pathname. what's wrong with passwd, and passwd username? it seems like it would be more important for everyday use, but no one mentions that (if it is important.)
-
tobiaus: I don't know of any strange incantations, but I think you're right that it's very simple to use passwd. The only connection between the two that I know is that /etc/shadow stores the password created by the passwd command (why it's not /etc/passwd I have no idea).
When I implied that TC is not multiuser, i did not mean it literally. All I was getting at is that it is configured to assume there is only one person using it. This is apparent with the lack of login prompt, additional ttys, or passwords. This isn't to say that it can't be reconfigured easily enough, but just that in its default state it doesn't seem to lend itself easily to multiple people using the same system at the same time. But this is also something that doesn't matter to me, since i'm the only one using my box, so I don't know why I brought it up =o)
curaga: thanks for the extra info on sudo. I forgot that I had experience something that I think is related to what you said. Some GUI applications will not work if you've su'd to root, but will work if you "sudo <command>".
-
indeed, and the other way around, sometimes sudo won't do things sudo su will. sudo killall udhcpc is fine, but i needed to sudo su before you udhcpc -H box -b -i eth0 (presumably, you can just use cpanel.)
also, sudo reboot works when reboot won't (although you don't need to be root to ctrl-alt-del.)
-
I haven't seen any magic incantations recently. Or maybe I just missed them ;)
Passwords should be changed with the passwd command. The secure bootcode uses that too.
They used to be stored in /etc/passwd during the unix era, with weak DES encryption, but there were weak points: not only the easily cracked crypt, but also the fact /etc/passwd is world-readable. Shadow was implemented to move only passwords out of that file, into a new file only readable by root. Shadow can use any algorithm, even DES, but by default it uses MD5 passwords. SHA1 is also supported in the default builds, Blowfish can be patched in. Thus, if you only change passwords, you need to backup /etc/shadow; if you also add / remove users / groups, you'll need to backup /etc/passwd and /etc/group as well. /etc/gshadow is used for group passwords similarly to /etc/shadow.
Heck, I'm still probably the youngest of the crowd when counted in years of Linux use. Why am I teaching everyone :P :D
-
Heck, I'm still probably the youngest of the crowd when counted in years of Linux use. Why am I teaching everyone :P :D
oh, some people just can't help it. lucky for the rest of us, though. :)
-
And because some of us don't learn stuff we don't already use unless we have to
-
well, some of us just don't get this stuff as fast. so we end up choosing between asking the people that understand the stuff we just tried to read, or simply having to use something easier. i quote robert shingledecker in chapter 2 of the official damn small linux book: (i'm on chapter 4 or 5.)
many users have passed through the forums and the collective knowledge is immense. try posting a request for help providing as much detail about your system as possible. who knows? maybe someone else has the same system as you and has a readily available answer. and remember that no question is too dumb to ask. we all had to start somewhere.
-
Oh, crap. I was hoping you'd see that last post of mine as saying "Some of us (myself included) are too lazy to study anything we're not immediately interested in" =o)
-
oh no worries, i know helping people is voluntary anyway. i'd love to do it more often, that's one of the reasons i'm trying to learn more.
you should be familiar enough with that book, you're thanked and mentioned on page xviii. if the book was copylefted, i would buy two. almost no one is going to sell a copylefted book though, except richard stallman: "Permission is granted to make and distribute verbatim copies of this book provided the copyright notice and this permission notice are preserved on all copies." ($25.00)
-
cjgau wrote:
"sudo su" changes to the home directory of root.
"sudo -s" will remain in the same directory where the command is executed.
I noticed 'sudo -s' also keeps the user's shell environment.
So, my replacing BusyBox's 'su' with GNU 'su' to get 'sudo su -m' is overkill.
'sudo -s' is enough for me. Thanks for the information.
-
As mentioned in 1.0 change log, the jwm system menu, the root access xshells, now use cjgau'a suggestion of sudo -s