owning /usr/local/bin

[bserce123]

I've tried chown-ing and chmod-ing and putting sudo in front of it all after rtf-ing manuals for some hours in order to change ownership of my /usr/local/bin directory from root to my current user (pi) but various responses are like 'sudo must be owned by uid 0 and have setuid bit set'. I can see myself blowing up the works if I continue annoying Terminal in a similar way. I'm sure jargon like this is deeply meaningful to some but it only serves to lose me in the debian jungle. Forth and Pascal and asm were in their day just as confusing but it gradually got easier with practice. So would someone please put me out of the misery?

[topguy]

You should have VERY good reasons for wanting to change the ownership rights of /usr/local/bin.

So tell us what your real problem is.

[B.Goode]

@topguy: there seems to be some previous discussion around this issue in this thread - viewtopic.php?f=63&t=184880&p=1169142#p1169142

[jojopi]

'sudo must be owned by uid 0 and have setuid bit set'

It sounds like you have messed up the permissions of /usr/bin/sudo. That could be difficult to repair, especially if you do not understand how it happened.

Regarding /usr/local/bin, it is normally writeable by group "staff", so you could just have added your user to that group.

[rpdom]

I've tried chown-ing and chmod-ing and putting sudo in front of it all after rtf-ing manuals for some hours in order to change ownership of my /usr/local/bin directory from root to my current user (pi)

Don't do that. It is just wrong.

Why do you think you need to do that?

[topguy]

This is how you install your own script in /usr/local/bin. ( just read "pi" instead of "topguy" )

Code: Select all

# This is the file...
topguy@lounge:~$ ls -l test.sh 
-rwxrw-r-- 1 topguy topguy 156 jan.   8  2016 test.sh

#copying it.
topguy@lounge:~$ sudo cp test.sh /usr/local/bin/

#Checking rights and see that its only eXecutable by root.
topguy@lounge:~$ ls -l /usr/local/bin/test.sh 
-rwxr--r-- 1 root root 156 juni   2 21:57 /usr/local/bin/test.sh

#Change rights and verify that other users also has the 'x' bit.
topguy@lounge:~$ sudo chmod ugo+x /usr/local/bin/test.sh 
topguy@lounge:~$ ls -l /usr/local/bin/test.sh 
-rwxr-xr-x 1 root root 156 juni   2 21:57 /usr/local/bin/test.sh

"./test.sh" would now run the copy in my current directory while "test.sh" runs the one in "/usr/local/bin".

[CarlRJ]

If you want a bin directory that is easily writable/usable by user pi, do mkdir ~pi/bin to create one under your home directory. /usr/local/bin isn't meant to be writable by everyone.

It also sounds like you've mucked up the ownership or permissions of sudo (posting the output of ls -l /usr/bin/sudo would help diagnose this), which is a bit tricky to fix, as all the simple ways involve using... sudo.

[W. H. Heydt]

'sudo must be owned by uid 0 and have setuid bit set'

It sounds like you have messed up the permissions of /usr/bin/sudo. That could be difficult to repair, especially if you do not understand how it happened.

It should be rather easy to fix...but the easy way that comes mind would involve a second SD card and an SD to USB adapter.

[bserce123]

You should have VERY good reasons for wanting to change the ownership rights of /usr/local/bin.

So tell us what your real problem is.

We've been advised in these forums to have personal projects in usr/local/bin for being called by crontab but copying files into that directory or editing them to improve the scope once they are in there when root rules the roost, is not what we want. As its our Raspi, we have one project that we rely on, that runs 24/7 on this dedicated computer, that is what we want to do. Something else we want to do is to find out how to do it safely and do it safely enough for our purposes. What we don't want to do is tread on anyone else's ownership rights in the process.

[bserce123]

If you want a bin directory that is easily writable/usable by user pi, do mkdir ~pi/bin to create one under your home directory. /usr/local/bin isn't meant to be writable by everyone.

It also sounds like you've mucked up the ownership or permissions of sudo (posting the output of ls -l /usr/bin/sudo would help diagnose this), which is a bit tricky to fix, as all the simple ways involve using... sudo.

Everything we have done so far seems still to be working as intended and our Raspi seems to be doing a good job stopping us doing what it doesn't like, so we think we are probably still OK. We're slowly learning how to find out how to do things safely, and that is the main object of this present exercise. If you would kindly point us to some document that says not to use usr/local/bin, and why, we'll gladly take on board any lesson to be learned, and thank you.

[W. H. Heydt]

You should have VERY good reasons for wanting to change the ownership rights of /usr/local/bin.

So tell us what your real problem is.

We've been advised in these forums to have personal projects in usr/local/bin for being called by crontab but copying files into that directory or editing them to improve the scope once they are in there when root rules the roost, is not what we want. As its our Raspi, we have one project that we rely on, that runs 24/7 on this dedicated computer, that is what we want to do. Something else we want to do is to find out how to do it safely and do it safely enough for our purposes. What we don't want to do is tread on anyone else's ownership rights in the process.

*Who* has been advising you to put personal projects into /usr/local/bin? (Can you provide a link to that advice?)

Cron can execute code anywhere. All you need to do is make a crontab entry with the full path to the shell script or executable binary file.

On a *nix system (that cover both unix and Linux) ownership of directories tends to reside with root, a group, or an application system (e.g. MySQL directories are owned by...mysql). Part of the reason for this is that these operating systems are inherently multiuser and its bad form to let users step on each other.

Now something you *could* do would be to create a directory within /usr/local/bin and change the ownership of it to a specific user ID. E.g. sudo mkdir /usr/local/bin/pi ; chown pi /usr/local/bin

[PeterO]

E.g. sudo mkdir /usr/local/bin/pi ; sudo chown pi /usr/local/bin/pi

Fixed it

PeterO

[rpdom]

Now something you *could* do would be to create a directory within /usr/local/bin and change the ownership of it to a specific user ID. E.g. sudo mkdir /usr/local/bin/pi ; chown pi /usr/local/bin/pi

That would defeat the object of putting things in the /usr/local/bin directory as it would no longer be in the run PATH.

For personal commands for my own user I use ~/bin.

For commands I want anyone on the system to be able to use, I use /usr/local/bin with sudo to put the file there.

For commands I (mostly) want only the root user to use, I use /usr/local/sbin with sudo to put them there.

For things I want to run from cron, I mostly use ~/cron.

[jojopi]

It should be rather easy to fix...but the easy way that comes mind would involve a second SD card and an SD to USB adapter.

The difficult part is not fixing sudo, but knowing what else is broken. There is no logical reason to mess with /usr/bin/sudo specifically, so this is just as likely to have been a wildcard or recursive change gone badly wrong.

[achrn]

We've been advised in these forums to have personal projects in usr/local/bin for being called by crontab

Bad advice. Cron can execute stuff from anywhere - just put the full executable path in the crontab. For stuff run by root (which it probably is) I think that's good practice anyway - root should never rely on the PATH setting, in my opinion (you can't immediately tell what PATH is, you might not be running what you think you are, you always want to know exactly what root is running).

but copying files into that directory or editing them to improve the scope once they are in there when root rules the roost, is not what we want.

This makes no sense to me, sorry. Why don't you want to copy files into a directory owned by root? That directory should be owned by root, because anything put there will be run by all users, so you do want root (the overall ultimate controller of the system) to control what gets written in there. You don't want any ordinary user adding files there, so you don't want it owned by an ordinary user. You need to explain why you think it's not what you want.

As its our Raspi, we have one project that we rely on, that runs 24/7 on this dedicated computer, that is what we want to do. Something else we want to do is to find out how to do it safely and do it safely enough for our purposes. What we don't want to do is tread on anyone else's ownership rights in the process.

Putting a file in the /usr/local/bin directory is not treading on anyone's ownership rights. I think you might be confused about what ownership means - root being owner of a directory doesn't mean that all files in that directory should be owned by root. That doesn't work at all - root owns the / directory, so that would mean that root would need to own all the files on the whole system. Root owns /usr/local/bin (and that's the way it should be) and if you want to put a file in there you assume root authority and put it in there. Job done. You can put it in there and then use root authority to change the owner of the file to whatever owner you want the file to have, if that's what you want for some reason. That is, use sudo cp to copy the file in, and then if you want use sudo chown to change the owner and/or sudo chmod to change the permissions.

If you would kindly point us to some document that says not to use usr/local/bin, and why, we'll gladly take on board any lesson to be learned, and thank you.

Eh? I can't point you at any document that says not to stamp on your pi wearing clogs and then boil it in vinegar. I really wouldn't advise doing that, though. /usr/local/bin should be used, but it should be used for the right thing, which is as the place where you put programs or scripts that you want all users on your system to be able to run easily. It's not intended for cron scripts (though you could put them there if you want, if for example you had a script you wanted to run regularly and you wanted users to be able to run it).

It is right to use /usr/local/bin (for its intended purpose).

It is wrong to change the owner of /usr/local/bin.

It is wrong to change the owner or permissions of files in /usr/bin.

[W. H. Heydt]

I suppose what really ought to be said is not that the practices being proposed by the OP are "wrong" so much as that they are not recommended and non-standard with the implication that anyone who gets used to them is likely to have some real problems the first time he tries to do anything on a unix/Linux system administered by someone else. Which is to say that it's better to learn what the standard practices are and stick with them to form good habits.

[bserce123]

We've been advised in these forums to have personal projects in usr/local/bin for being called by crontab

Bad advice. Cron can execute stuff from anywhere - just put the full executable path in the crontab. For stuff run by root (which it probably is) I think that's good practice anyway - root should never rely on the PATH setting, in my opinion (you can't immediately tell what PATH is, you might not be running what you think you are, you always want to know exactly what root is running).

but copying files into that directory or editing them to improve the scope once they are in there when root rules the roost, is not what we want.

This makes no sense to me, sorry. Why don't you want to copy files into a directory owned by root? That directory should be owned by root, because anything put there will be run by all users, so you do want root (the overall ultimate controller of the system) to control what gets written in there. You don't want any ordinary user adding files there, so you don't want it owned by an ordinary user. You need to explain why you think it's not what you want.

As its our Raspi, we have one project that we rely on, that runs 24/7 on this dedicated computer, that is what we want to do. Something else we want to do is to find out how to do it safely and do it safely enough for our purposes. What we don't want to do is tread on anyone else's ownership rights in the process.

Putting a file in the /usr/local/bin directory is not treading on anyone's ownership rights. I think you might be confused about what ownership means - root being owner of a directory doesn't mean that all files in that directory should be owned by root. That doesn't work at all - root owns the / directory, so that would mean that root would need to own all the files on the whole system. Root owns /usr/local/bin (and that's the way it should be) and if you want to put a file in there you assume root authority and put it in there. Job done. You can put it in there and then use root authority to change the owner of the file to whatever owner you want the file to have, if that's what you want for some reason. That is, use sudo cp to copy the file in, and then if you want use sudo chown to change the owner and/or sudo chmod to change the permissions.

If you would kindly point us to some document that says not to use usr/local/bin, and why, we'll gladly take on board any lesson to be learned, and thank you.

Eh? I can't point you at any document that says not to stamp on your pi wearing clogs and then boil it in vinegar. I really wouldn't advise doing that, though. /usr/local/bin should be used, but it should be used for the right thing, which is as the place where you put programs or scripts that you want all users on your system to be able to run easily. It's not intended for cron scripts (though you could put them there if you want, if for example you had a script you wanted to run regularly and you wanted users to be able to run it).

It is right to use /usr/local/bin (for its intended purpose).

It is wrong to change the owner of /usr/local/bin.

It is wrong to change the owner or permissions of files in /usr/bin.

Quite a few hours went into burning midnight oil learning from the wisdom lately dispensed in this topic - for which many thanks, and hopes we have not annoyed too many with our intransigence. What we've done since:-
Found a lot of internet references from sufferers of similar symptoms.
Read many 'solutions', to those references, which quite a few others then disputed.
Loaded our essential project files onto a USB memory dongle.
Dug out a spare SD card and rebooted and reset and updated and upgraded the Raspi as a time-saving measure.
Copied our files back from the dongle.
All's well that ends well. Now to dig out an invasive ants' nest. And get some sleep!

[Heater]

Yep, don't worry about those gnarly old Unix/Linux guys.

Things is, it's your computer. And thanks to the open source world it's your operating system and software as well. You can do what the hell you want with it.

For example I like my machines to boot the Linux kernel and then run node.js immediately. With that I can get all the servers I need running with no traditional Unix baggage.

On the other hand, said gnarly old Unix guys have a point. For normal usage there are expected conventions regarding installation of applications and permissions setup that have been well tested over time with regard security etc. It's perhaps better to follow convention unless you have something special to do.

But, as you noticed, said conventions and "best practice" are still under debate...

[DougieLawson]

If the OP works really hard at setting permission 0777 for everything (except where it's disallowed) he/she will be able to render a Raspbian system to be nearly as insecure as Windows and best of luck with that.

[jahboater]

Perhaps 03777 to include the set user ID and set group ID bits too