I have been criticized in some of my posts for advocating d/ling and compiling Gimp as root.
I should login as user and then use "sudo" .

First a bit about my background:
I started with Linux in the late 90's with Slackware-3.x.
There was no internet and you had to use cd's with binaries.
Of course it was all CLI.
It never ran very well I must confess.
Then came RedHat and Süse with installers.
I liked Süse better than RH.
Later I also tried Mandrake and probably some other distro's.
December 2003 I tried Gentoo and was sold,never used any other distro.

None of these distro's used sudo.
I think sudo was introduced by Mr.Shuttleworth (Ubuntu) to make things as easy as possible on ppl switching from Windows to Linux. After all most Window users shudder at having to use the CLI.

Using sudo instead of logging in as root being safer is a fallacy I think.
( Of course you don't browse the internet as root).
An intruder will always enter through the user's domain,it's the only opening to the outside world.
Once this intruder knows the user password it can do what it wants in the system thanks to sudo.
When sudo is not installed the intruder will have to know the root password which will be very hard to do.
I don't run a server,servers need special precautions because they're constantly online.

When I want to install something I log in as root in a terminal (Ctrl-alt-F1...F6) using CLI.

If you're curious to know if there's been any intrusion check /var/log/auth.log.
Then there's rkhunter and chkrootkit that you can run.
Gerard.

But it's not necessarily about protection from malicious activity, sometimes it's just about limiting the potential to trash your own system.

You cannot guarantee, especially if your building from vcs, or nightly tarballs, that someone hasn't made a mistake, like an unfortunate typo in the build process, that could potentially damage your system.

Worst, we can't guarantee we're not going to do something stupid ourselves, after spending a few hours in repetitive tasks trying to get something working, for example doing a destructive operation in one folder, when we thought we we're in another.

In such cases, rare as they may be, not being root can save your bacon.

For similar reasons, given the complexity of software, it's probably safer not to run it with root privileges if you don't need to, especially development snapshots.

It's down to personal preference, my own wherever possible, is to limit exposure to only what's needed to get the job done.

If I didn't write it, I consider it potentially unsafe.
If I wrote it, I consider it probably unsafe.

When you do "make" in root what could happen?
When you do "make install" you have to have root privileges.
Gerard.

Gerard, I checked my /var/log/auth.log and I am curious as to what I should be looking for. Nearly every entry is the same: LinuxMachine CRON[28931]: pam_unix(cron:session): session closed for user root
LinuxMachine CRON[29315]: pam_unix(cron:session): session opened for user root by (uid=0). I am assuming that's me, yes? A couple other entries specifically name me as opening a session.

Guess what I need is an example as to identify an intrusion. Can you give me a more specific example?

make is not restricted from destructive operations, of course you'd expect make targets like clean and distclean to delete stuff, but a basic make command could also run destructive operations, it could be triggered to delete generated files for example, and people make mistakes.

I'm not saying right or wrong, just preference. Is it not safer to assume something is potentially unsafe, than to assume it's safe and be wrong.

Just for anyone reading this thread that might now infer that you have to have root privileges to run make install, it actually depends on where you're installing to, for example you wouldn't need it if you're installing to your home folder.

How many applications have you actually installed to your home folder and had them work?

@nixnine,
The entries you see in your /var/log/auth.log are ok.
You have "cron" running and doing it's thing.
Here's a snippet of my /var/log/auth.log:


The failed login on tty2 was due to mistyping on my part,I had typed "rot" instead of "root".
Since user rot is not known it's not accepted.
I don't use cron,so no cron entries.
Gerard.
Edit:Rereading your post:
LinuxMachine CRON[29315]: pam_unix(cron:session): session opened for user root by (uid=0). I am assuming that's me, yes? A couple other entries specifically name me as opening a session.
No that's not your user login.
It should read "user <your login name>"
Cron has root privileges so it's considered root and runs as user root.
uid is userid.Root has ID nr.0 users usually start at 1000.

This is why i use Windows.If i screw up i can blame it on their software.

I run the make part as a plain user, just because I don't need root privs for this. And as a plain user, it's easier to use the graphical tools (editor, file navigator, and package installer) to make the make work in case of problems.

"sudo make install" of course doesn't protect the system against mistakes in the makefile; but it does protect the systems against mistake I could make before or after issuing the "make install".

I wasn't sure but now it does look like I've caused offence, and for that I apologize as it was not my intention, I was just debating the argument and offering an alternative point of view, which I think I've communicated well enough for people to make an informed choice, so will leave it at that.

Actually I'm quite new to forums and now see it's a bit different from commenting on a blog (which I also don't do much), people build up relationships over time and I've just come crashing in with my opinons . Hmm...I think I'll stick to learning the GIMP for now, and maybe get involved in debates at a later time .

To answer your question, I usually install applications I'm working on in my home folder for convenience, often under a subfolder called apps, I've not as yet run into problems doing that.

Not that I'm advocating that people do that, to do it in the general case you'd want to configure various subsystems so they knew to look there for, eg. shared libraries, man pages, desktop integration files, etc... But you could if you wanted to.

Anyway, sorry for any offence caused.

You didn't offend me, quite the contrary! I'm a new Linux user and was asking a generic question. Installing apps in Windows was one thing (within single user directories), but I notice that in Linux, makefiles tend to point to installation directories, etc. So, when you said install to Home, I figured there was some trick to it. I tend to leave makefiles alone, aside from the occasional tweak when a directed folder doesn't exist, or the readme file suggests changes.

SURE ?
i may be wrong,i never checked because my linux computers is very seldom connected to the net but i was believing that just a default, and that was possible have a different PW for sudo from that used to login

@mahvin: That's good to know, I thought gerard might have taken offence, or people who knew him might have thought I was being deliberately argumentative, after all he's developed his relationship in this community over a couple of years and people have got to know him, and I joined a few days ago. That was late last night though and I was getting tired, so probably misread the situation.

That said, I got a good nights sleep and have awoken refreshed, and I realise I should have been clearer in my initial post, as I think, having read other comments, that people may not understand the purpose of the sudo command, which really comes into it's own in a multi-user environment.

The sudo command is not intended to be a tool to help protect you from an intruder, and as gerard pointed out, it won't, that is indeed a fallacy.

It's purpose is to allow everyday users the ability to operate in general with least privileges, and yet have the ability to elevate privileges to perform specific tasks.

Most distributions these days configure sudo so that a default user, or users who are members of a specific group, say admin, can elevate to root privileges, I think that may lead people to believe it stands for 'Super User Do', rather than 'Switch User Do', and don't consider it any further. Sudo is much more than that.

It can, for example, sanitize the environment before executing specific requests, and on most distributions it's configured to do just that. You can also restrict what programs a user can run when assuming elevated privileges, for example even when elevating to root privileges, you could deny the user the ability to run the rm command, or not allow it to be run with the -rf flag.

In a multi-user environment, for example, some poor sole may have the unenviable task of running around unjamming printers and resetting print queues, using sudo they can assume the privileges of a user/group that can manage print queues, and be restricted in that role to only being able to run print queue related commands.

Because your machine may be in an untrusted environment, where someone else may have an opportunity to use it while you're logged in, sudo will request your password as a means of validating you are the logged in user.

If you want to know more, open up a terminal and type 'man 5 sudoers' to get an idea of what you can do, also try 'less /etc/sudoers' (press 'q' to exit less) to see how yours is configured.

I hope that helps people better understand sudo, and it's purpose.

If it's of interest, I'll explain more clearly why I advocate not elevating privileges for processes that don't require them, and the use of forensic tools, in a later post.

No offence taken (if that is the right way to say it in English) kstuart.
You were not the only one who criticised me.

I think the majority of Linux users use Ubuntu or a derivative.
I explained in an earlier post why these distro's use sudo.

Gerard.

sudo is not an automatic way into the system, you can define exactly what kind of access a user gets when executing sudo by means of the sudoers file. But sure, if you let sudo give root-level privileges then you are essentially just adding another root user with all that entails.

Sudo is very useful for sharing system administration by the way, no need to have all sysadmins share the same account and root account password - just assign them the functionality via sudo (and instill policies to make sure they don't use too simple passwords).

Working on a local machine I usually compile to a prefix in my own folder. If nothing else it's useful to not have my own compiled data on the same partition as the operating system. I use sudo now and then - and my account password is just as complex as my root password.
.
Griatch

In my little single user environment, I never use sudo. Considering the sudo vulnerabilities that have been exposed over the years, it too often provides a false sense of security, which can get you in big trouble.

As far as compiling goes, I always compile as a non-privileged user and install as root. I've never had any problems with that approach. Occasionally, I just leave the binary in a home folder and run it from there.

The vulnerabilities are quite a concern, especially the regressions, before it became commonplace for sudo to be pre-installed and configured, I aliased 'su --session-command' for the job.

Maybe I've become a bit complacent, if it wasn't already installed and configured on my workstation, I wouldn't install it.

Certainly food for thought.

Has any of the Linux users ever experienced a worm/virus/other malware?
I doubt it!
I've used Linux for over a decade and never noticed anything that could have been caused by an intrusion.
I always used the same password for root and another one for user.
Probably all of you used Windows for years,I didn't.
When you install Windows and you boot into the new install you get a warning to install a virus scanner.
Virus scanners don't exist for Linux.
Have you ever wondered why?
If you know how Linux came about you'll know.
Unix was designed by savvy programmers,not by someone with great business acumen but poor programming abilities.
Unix was designed to run central servers for large organizations to connect to multiple desktops.
Each person connected to these severs was issued a username and a password.
Why?
To avoid shenanigans by disgruntled users who wanted to screw up the system.
Remember this was before the internet existed.
Linux is a clone of Unix,like the PC is a clone of the original IBM PC.
The difference between Linux and Unix is that development of Linux is still going on while Unix is practically dead like the IBM PC.
If I'm not mistaken Apple uses Unix.
Gerard.

Hmmm.

There is very little of the original IBM PC in current PCs.

Linux is only an implementation of Unix. There is a Unix standard called Posix, and in the professional world, if you find servers powered by Linux, you also find servers using the various BSD versions (NetBSD, OpenBSD), and more importantly, the proprietary versions of Unix (Solaris on Sun, AIX on IBM). Unix is a big tree and Linux is only a branch. And if you look closely, Linux is only a kernel. All the utilities in the command line interface, and the compiler that generates Linux itself aren't part of Linux.... Other Unixes maybe using other major components such as desktops and window managers, and possibly the X11 support itself

OSX has some Unix roots...