[SOLVED] Some application installation questions: log in as root or log in as 'user' & do 'su'
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
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.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Some application installation questions: log in as root or log in as 'user' & do 'su'
Hello:
If you have the time, and the patience, I am trying to understand the differences and/or implications of 'logging in as root to down load & install applications' vs 'logging as 'rob' (a user) to down load & install applications', if any.
And, are there any further considerations based on whether you are down loading a SlackBuild vs a tarred applications from some other reputable web site on the net?
Are there any nuances to be aware of?
I am trying to understand if there are differences to the 'result of the install'.
Thanks,
Last edited by Robert.Thompson; 02-24-2011 at 08:54 AM.
There is no difference, just when you installing apps you need to have root privileges to copy files to system directories. The only difference will be the owner of downloaded file, which if it is dll'd as root, user rob won't be able to modify or delete it. AFAIK best solution is to download, untar, "./configure" and "make" as user and "make install" as root.
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541
Rep:
If you're downloading and building an application; i.e., executing a "packagename.SlackBuild," you will probably be able to do so -- "probably" means that you may have access to all the libraries and any utilities required to successfully build a package. You will not, however, be able to install it logged in a "you;" you must have root permissions to install (using su, sudo or logged in as root.
The same is true of a tar bundle you get from somewhere or other; you'll probably be able to execute configure and make but not make install unless you've root permissions.
The above both assume that you're downloading into your home directory (or /tmp) and compiling there. I would be better if you have a /usr/local/src type of directory tree for stuff you add on to the system -- you'll always know where stuff is and you won't be wading through a forest in your home directory (of course you could have a src tree in your home directory instead -- up to you). Generally speaking, if you have a /usr/local/src tree, it'll be owned by root and you as a user will not be able to write in the tree. So, you'd need to use su or sudo to build and install stuff there. Six of one, half dozen of the other.
Working logged in as root is not for the faint of heart. Inevitably, you'll screw up and blow a lot of stuff away that you did not mean to do. So, not such a good idea.
Working with su or sudo is probably the best way to go -- you don't have to fiddle with granting permissions on directories that ought to be left alone and the chances of wiping out the system are significantly less. On thing you may want to do is edit /etc/login.defs to change the behavior of su. Used to be the default of su - was "as if logged in as;" i.e., you would get the profile of the user you "su-ed" as. Nowadays, the default behavior is that you do not get the profile unless you edit /etc/login.defs to comment-out the line
Code:
#
# If defined, the command name to display when running "su -". For
# example, if this is defined as "su" then a "ps" will display the
# command is "-su". If not defined, then "ps" would display the
# name of the shell actually being run, e.g. something like "-sh".
#
SU_NAME su <comment-out this line (put a # in column 1)>
When you do the above and execute su - fred you will be "fred" as if you logged in on the console. If you su - you will be root as if you logged in as root on the console.
Are then any considerations about a tarball downloaded from, oh, say, SourceForge.net versus SlackBuilds.org? Well, no, probably not (but the SlackBuild will be easier to do 'cause you don't have to think about configuration options and the like).
Learn to use src2pkg if you're building stuff from non-SlackBuilds.org sites. It's a good tool. RTFM.
Distribution: Void, Linux From Scratch, Slackware64
Posts: 3,150
Rep:
The other advantage to building from source via slackbuilds as opposed to installing a pre-built package from another system is that the software will usually be optimized for YOUR system rather than for someone elses, this can make a difference in the speed and stability of the app, both ways have their advantages, I have a couple of progs installed from converted RPM,s simply because of convenience or the fact that they would not build on my system, but I usually try to install either from slackbuilds or via svn/cvs/git etc and then build a package myself.
Working with su or sudo is probably the best way to go -- you don't have to fiddle with granting permissions on directories that ought to be left alone and the chances of wiping out the system are significantly less. On thing you may want to do is edit /etc/login.defs to change the behavior of su. Used to be the default of su - was "as if logged in as;" i.e., you would get the profile of the user you "su-ed" as. Nowadays, the default behavior is that you do not get the profile unless you edit /etc/login.defs to comment-out the line
Code:
#
# If defined, the command name to display when running "su -". For
# example, if this is defined as "su" then a "ps" will display the
# command is "-su". If not defined, then "ps" would display the
# name of the shell actually being run, e.g. something like "-sh".
#
SU_NAME su <comment-out this line (put a # in column 1)>
When you do the above and execute su - fred you will be "fred" as if you logged in on the console. If you su - you will be root as if you logged in as root on the console.
This part appears to be simply wrong.
In my Slackware64 13.1 system, the above line in /etc/login.defs is not commented out and the command...
Code:
su -
..."provides an environment similar to what the user would expect had the user logged in directly."
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541
Rep:
Well, kinda. If that line is not commented out and you're logged in as you and you execute su -, yeah, you get to be godlike but you do not get root's environment (or, for that matter, if you su - someuser, you will not get that user's profile). At least in Korn Shell (which I use) although I do not believe that has anything to do with it; but maybe...
If it is commented out (the way I prefer it) and you su - you get root's profile (or some other user).
Sorry, but I come from SVR4 and Solaris and that's the way they work (thus the way I prefer) and at some point a few years back Slackware stopped working that way and I had to remember to comment out that particular line to get things to behave way I prefer. I have users that have different profiles and when I need to be that user I need to have that profile for testing and making sure that things work as they should for that user and applications used by that user.
Not a big deal, just different than it used to be (in Slackware, about 10.x I think maybe).
No tempest, no teapot and all is well that ends.
Last edited by tronayne; 02-24-2011 at 04:44 PM.
Reason: Fumble finger
The TERM is obviously fine since I ran `su -` from urxvt in X, HUSHLOGIN is false in a login session but not in a `su` session (as expected), LS_COLORS is different because my urxvt has no proper entry in /etc/DIR_COLORS, DISPLAY is set because I'm in X, XAUTHORITY is set again because I'm in X (as another user), and COLORTERM again has to do with my terminal. The only significant difference is HUSHLOGIN which is set as expected. This is without modification to /etc/login.defs (on 64-bit 13.1).
Obviously a much different environment, as expected (see `man su`).
That line in login.defs does this:
Code:
$ ps ax | grep [-]su
14480 pts/17 S 0:00 -su
If there is an application or script that determines how it should act according to the name of the parent process, then you may have issues, but I don't know of any (possibly excepting init etc.) that would do such a thing. If you do, feel free to give some examples. It seems `su -` is acting as it should and it would be subprocesses that aren't...
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541
Rep:
OK, bearing in mind that the line in /etc/login.defs is commented out for all of this, I exited (which is to the console, not to a GUI login) and
Code:
log in as root
env | sort > /tmp/root_login
exit
log in as me
su -
env | sort > /tmp/root_su
diff /tmp/root_login /tmp/root_su
14d13
< HUSHLOGIN=FALSE
That's the only difference (other than who am i shows "me").
What happens is that invoking su - does all the environmental setup that is done from a "raw" login; profiles are invoked (/etc/profile and its cousins plus the user's .profile and .exrc files) and a prompt is displayed. Something like this:
Code:
pita-trona-/home/trona: su -
Password:
When does summertime come to Minnesota, you ask? Well, last year, I
think it was a Tuesday.
pita-root-/root:
All users on my systems are using Korn Shell and everybody gets these defaults (which they can -- and some do -- override in their .profile, .exrc or .kshrc files):
Code:
cat /etc/profile.d/ksh.sh
#!/bin/sh
#ident "$Id$"
#
# Name: $Source$
# Version: $Revision$
# Modified: $Date$
# Purpose: set local environment variables for Korn Shell
# Author: T. N. Ronayne
# Date: 1 Oct 2009
# $Log$
# Set the HOST environment variable
export HOST="`uname -n`"
# Set ksh93 visual editing mode:
if [ "$SHELL" = "/bin/ksh" ]; then
# VISUAL=emacs # ugh
# VISUAL=gmacs # double ugh
VISUAL=vi # ah, elegance
fi
# Set a default shell prompt:
#PS1='`hostname`:`pwd`# '
# Do these anyway in case somebody uses a different shell
if [ "$SHELL" = "/bin/pdksh" ]; then
PS1='! $ '
elif [ "$SHELL" = "/bin/ksh" ]; then
PS1='${HOST}-${USER}-${PWD}: '
elif [ "$SHELL" = "/bin/zsh" ]; then
PS1='%n@%m:%~%# '
elif [ "$SHELL" = "/bin/ash" ]; then
PS1='$ '
else
PS1='\u@\h:\w\$ '
fi
PS2='> '
export PS1 PS2
Everybody, that is, but one user that is comfortable with C-Shell (and uses applications and utilities that no other users do) so that user's environment is set differently (which is not germane so we won't look at it). However, executing su - thatuser starts up C-shell, sets the environment from /etc and the user's .login and .cshrc files. As desired. As expected.
This behavior is what I want so that when I invoke su - somebody I get their complete environment without inheriting anything of the environment I started in (and when I exit there's no corpses messing with my original environment).
Bottom line the behavior is different whether you comment out SU_NAME or leave it at the default; the diff above, I believe, demonstrates that pretty well. The comment in /etc/login.defs does not, I think, go quite far enough to clearly explain the effect of one way or the other.
Too, things may behave differently in BASH; don't know, don't like it, don't use it.
Distribution: slackware64 13.37 and -current, Dragonfly BSD
Posts: 1,810
Rep:
Quote:
Bottom line the behavior is different whether you comment out SU_NAME or leave it at the default; the diff above, I believe, demonstrates that pretty well. The comment in /etc/login.defs does not, I think, go quite far enough to clearly explain the effect of one way or the other.
I haven't altered login.defs at all and I'm seeing the same behaviour as you are. Here's what I'v done :
Code:
login:root
env > login.txt
exit
login: user
su -
env > su-env.txt
diff login.txt su-env.txt
7d6
< HUSHLOGIN=FALSE
This is all with the SU_NAME in login.defs left as default. I run bash as my shell however so possibly that's causing the difference between what I'm seeing and what you're reporting.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.