sudo and compiling binaries

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

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) 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)

John,

checkinstall looks incredibly useful. Thanks for that tip.

Ian