sudo and compiling binaries

das88 · 2010-04-13 20:18:50

Hi all,

This is more of a general linux question but I got a little turned around recently when trying to compile and install clamav.

By default, clamav creates a new user and group called clamav and gives the new user privileges for all the executables that get installed with the program (I think). First off all, I'm confused as to why you would want to do this. Why not just force all users to use sudo to run the program? Second, I never had to set up a password for the new user and once everything was installed I didn't see the new group or user in the "users/groups" application in the main menu of #!. Is it possible clamav somehow created a group I can't see even when I elevate my privileges in the users/groups program?

I'm also unsure as to what the proper procedure is when compiling a program. I've just learned how to do this and my general understanding is that a group of binaries comes with a configure script that generates makefiles for your system. To install the program you do configure; make; make install. Now, should I run that sequence as sudo? My assumption is that if I do, I'll have to sudo to edit any of the program files after I do the install. If I don't do that, will I be able to edit those files as myself? During one of my attempts to install clamav, it generated all the program files with the usual directory structure (files in /bin, /etc, etc.) but placed everything inside my default path (/home/user). Was that just some weird thing the program did or is that because I ran the install sequence as myself and not sudo?

Every time I've (successfully) installed a linux program in the past I've done it with a package manager or a precompiled .deb file that I downloaded. I haven't gotten a feel for the rest of this yet, and I'm having trouble finding any info online. Can anyone make this a little clearer?

Thanks!
Devin

Oh, and the reason I was installing clamav in the first place is that I wanted to scan a windows system for viruses from linux. If this is a dumb way to do that I'd appreciate some pointers there too.

olembe · 2010-04-13 20:21:37

I can give you a partial answer: you can't force all users to use sudo, for a program like this, because Linux systems are designed so that only some users will have access to sudo, and that it should be possible to do day-to-day tasks without needing sudo. Sudo is supposed to be reserved for admin tasks, in other words.

I'm sure someone more knowledgeable will be along shortly to answer the rest of your question!

benj1 · 2010-04-13 22:20:17

first off configure, make, make install.
only the last step would need sudo permissions, because youll be copying it to /usr/local/bin which normal users don't have permission the write to, if you try it without sudo it'll just balk, cos you won't have permission to copy the binary.
if you read the README / INSTALL files it should give you the options you can use when building and installing, assuming the installation script is using autoconf there should be an option to install it somewhere else (ie ~/bin) in that case i would assume config files would also be installed in the users home file, and you also wouldn't need sudo for the last install step.

i wouldn't be too worried about it not needing sudo permissions to run, i would assume the devs know more about security than us mere mortals, programs only tend to (and should only) ask for sudo permissions if they actually need it, package managers need permissions to write to /etc and /usr/bin etc.

ps whats wrong with clamav in the repos

anonymous · 2010-04-13 22:24:41

das88 wrote:

To install the program you do configure; make; make install. Now, should I run that sequence as sudo?

Usually only the last command (make install) is run with sudo.

das88 wrote:

My assumption is that if I do, I'll have to sudo to edit any of the program files after I do the install. If I don't do that, will I be able to edit those files as myself?

Using root to install a program just makes it accessible to all users. As long as your run the program as a user, it will store its configuration file(s) in the user's home folder.

das88 wrote:

Was that just some weird thing the program did or is that because I ran the install sequence as myself and not sudo?

Its the latter. Without sudo, you can only write to your home folder.

das88 wrote:

Oh, and the reason I was installing clamav in the first place is that I wanted to scan a windows system for viruses from linux. If this is a dumb way to do that I'd appreciate some pointers there too.

Just IMO, but Clamav has rather poor detection of Windows malware. Avast would be better. Also you could consider using a Live CD for scanning Windows such as Dr. Web's Live CD.

chillicampari · 2010-04-13 23:59:23

das88 wrote:

...
By default, clamav creates a new user and group called clamav and gives the new user privileges for all the executables that get installed with the program (I think). First off all, I'm confused as to why you would want to do this. Why not just force all users to use sudo to run the program? Second, I never had to set up a password for the new user and once everything was installed I didn't see the new group or user in the "users/groups" application in the main menu of #!. Is it possible clamav somehow created a group I can't see even when I elevate my privileges in the users/groups program?
...

I don't use clamav but from what it sounds like, you may have to set up the user/group manually. The documentation *should* have the specifics you'll want for that app.

I'm totally rusty on this, skipping stuff and can't guarantee it's totally correct (I'm just going from memory since I couldn't find an easy to read guide, but then again, I didn't look that hard) tongue and I'm probably not going into that much detail, but here's a stab at the "why" part of the question (at least how I understand it, anyway)...

To expand a bit on olembe's post, just like you don't normally want regular (human) users to run as root normally, similar concepts apply to non-human groups and users. They do need higher permissions usually while interacting with the rest of the system but being part of a group can keep them within certain areas that they are allowed to write to. It's a safety mechanism for the most part. It has a basic interaction with root, since root pretty much just looks at group permissions and says "go ahead and do your thing" or "hey, you can't do that here". Root is actually kinda dumb, even though it's the most priviledged user**. Though it knows the safe boundaries for each group and where everything in that group is allowed to be so you don't have things like your printer attempting to print out an audio file and stuff like that.

The non-human user interacts within it's own group and other groups. One reason it's a user is because it does a lot of things unattended and it is in charge of it's processes. The user can also be part of multiple groups so the users identify what they are to other users and know what each other needs to do. For example it needs to communicate with the scheduler so you don't have to run it on demand each time if you don't want to. Some users are more privileged than others and can request root to give them priority over other users, and even get their process kicked off (which you generally want in something like a virus scanner, even though it's not usually needed natively in a *nix). But this kind of thing is why you want to follow the documentation to add the group and user from reading it from the install notes for that application (if it doesn't do it automagically) since it may need a special permission set to show where it is in the food chain.

It's the sort of thing you get a feel for as you work with it more.

Also, if anyone out there sees anything wrong or extra confusing with the above stuff I wrote, please jump on it to make it better- thanks!

** (edit- I know I didn't separate out root user and root owned daemon(s) at all but I'm trying to keep it sorta short).

Last edited by chillicampari (2010-04-14 07:08:47)

johnraff · 2010-04-14 03:06:53

On compiling in general: I try to avoid compiling software from source if possible - it can be a real pita getting all the dependencies sorted out, and untangling mistakes also... Still, sometimes you really need/want that package, and sometimes it all works fine smile

The "checkinstall" package (in the repositories) can help make life simpler. Instead of installing the files directly with the "sudo make install" command, "sudo checkinstall" will make a .deb file you can install with gdebi or dpkg. More important, you can uninstall it with your usual package management tools.

A couple of Ubuntu Wiki tutorials:
https://help.ubuntu.com/community/CompilingSoftware
https://help.ubuntu.com/community/CompilingEasyHowTo

olembe · 2010-04-14 06:40:32

John,

checkinstall looks incredibly useful. Thanks for that tip.

Ian

shengchieh · 2010-04-16 02:39:54

If you still need help compiling, check out

http://www.maximumpc.com/article/howtos … urce_linux (Compile Programs From Source in Linux)
http://www.tuxfiles.org/linuxhelp/softinstall.html (Installing software from source in Linux)
http://www.linux.lk/software/compiling.php (Compiling Software Packages; 2003)
http://howto.wired.com/wiredhowtos/inde … egory=Work (Compile Software from Source Code)
http://liquidweather.net/howto/index.php?id=82 (compiling software)

Sheng-Chieh

CrunchBang Linux

SEARCH

#1 2010-04-13 20:18:50

sudo and compiling binaries

#2 2010-04-13 20:21:37

Re: sudo and compiling binaries

#3 2010-04-13 22:20:17

Re: sudo and compiling binaries

#4 2010-04-13 22:24:41

Re: sudo and compiling binaries

#5 2010-04-13 23:59:23

Re: sudo and compiling binaries

#6 2010-04-14 03:06:53

Re: sudo and compiling binaries

#7 2010-04-14 06:40:32

Re: sudo and compiling binaries

#8 2010-04-16 02:39:54

Re: sudo and compiling binaries

Board footer