Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
You are not required to type a dash (-) after the su command to get full root privileges. The dash indicates that you want to start in a login shell, which usually means that the correct PATH will be set up, giving the impression of "full" root privileges. If you omit the dash after su, you will get an ordinary shell instead. It has the same privileges, but since the root user's PATH have not been set up, you might have to use the absolute path to the system administration commands that you want to use. Ordinary user commands, like ls, should work as usual.
The system administration commands are often installed in other directories than the ordinary user commands, usually /sbin or /usr/sbin instead of /bin or /usr/bin. The ordinary users PATH does not include the sbin ones, and su without the dash does not either. If you use su -, your PATH will include the sbin directories in addition to the ordinary bin directories.
Distribution: Fedora (workstations), CentOS (servers), Arch, Mint, Ubuntu, and a few more.
"-" sets the environment variables and stuff (other initializations, usually .profile and rc files).
Means if you just do "su username", you get a session (but without the "username"s environment). If you use "su - username", then you get a session initialized to the "username"s environment. So keep it in mind. Most of the time (not always) you'd like to use su with the tailing "-"
well, it isnt so much security reasons, just for protection of yourself. usually anyway. you dont want to run the system as root ... period. but just get a root term and do the command you need,(like install a program). then get out of root. you dont want to log in as root, and run anything for a period of time.
Basically, "yes you can" do a lot of things with this system that are unheard-of in the rather limited world of Microsoft Windows. You can have more than one completely-separate, graphic sessions logged-on at exactly the same time on the same computer, from the same console (or from entirely separate computers).
Originally posted by edong23 well, it isnt so much security reasons, just for protection of yourself. usually anyway. you dont want to run the system as root ... period. but just get a root term and do the command you need,(like install a program). then get out of root. you dont want to log in as root, and run anything for a period of time.
You sure? I'm pretty certain X was deemed insecure in the past - perhaps it's been fixed. Have an idea people can read your keystrokes, so root's password would be at risk. It gave me a warning once that someone might be reading the keystrokes - as a result of trying to copy the MIT magic cookie through the network.
I do this by logging in as root on another virtual terminal. To go from a graphical screen to a text screen, use <CTRL-ALT-F1> then log it in if you haven't already and edit the file with nano or whatever you like. To go back to the graphical screen, use whatever <ALT-F#> key has been assigned to that (on my system it's F7).
yeah, there are times that I could find the graphical switch that has (User) <---> (Root) and when I want to STAY IN THE GUI, I could just flip the switch and gedit that system file.
I wish someone could explain to me the security risk of the SOLE user on the LOCAL keyboard being aliased as ROOT in a GUI. I really don't think it would take too much effort for a seasoned Linux Programmer to make a rule that states:
ALWAYS ASK FOR ROOT PASSWORD (to video display) FROM LOCAL USER (at keyboard) BEFORE ISSUING A DENIAL. the in and outs CAN be hardcoded.
or...at the ultimate very least, the ability to SAVE the long text file you have made under a different name in the same directory. I can't count the times I've attempted to change a file with 20-30 different changes to be slapped with a "permission denied" eg "I just wasted my time making all these adjustments because it wasn't gonna ask for the root password for me to be able to save the friggin thing"
or..maybe being able to hit the 'SUPER' button on a "permission denied" which would ask for root password and retry request.
So many different GUI solutions that haven't been made