Hi Folks
To allow me to run a program I fetched as a tar.gz archive, then compiled and installed, I have needed to deliberately set the access permissions for the /usr/local/share folder and everything in it so that Owner, and Group, and Others (ie. everyone!) "Can View and Modify Content"

I know there must better way, because 'Group' and 'Others' were probably originally set to "Forbidden" for very good reasons.

The Ownership of /usr/local/share is User: 501, and Group: users, as happens in a standard Debian 'Etch' installation.

The actual install went OK, using ./configure, and 'make'. I needed to su (become root) to do the 'make install' bit. The problem arose when I found the program would run only when invoked from a root terminal, that is - until I messed with the permissions.

What is the right way to do this?

Thanks

You probably only needed to give group and others execute permission. You probably did not need to give group and others read and write permissions. What is the name of the program?

----------------
Steve Stites

Thanks for the reply.

The program is 'gpsk31', which is a phase shift digital communication mode used by radio amateurs that has a reputation for being efficient, low bandwidth relatively interference-proof and reliable.

I could have installed it using Synaptic, but my interest is not in using it for communication. It is because it has a GTK+ graphical interface that includes pushbutton widgets, real-time phasor (amplitude and angle) display, a colour keyed signal spectrum waterfall graph, real-time fast Fourier transform DSP functions processing signals via soundcards, file access routines, user configuration,and more.

I thought it a good place to go peeking into what has to be quite competent source code. This is not to imply I am yet in that league, but I can be curious, and I was a bit in awe. This is the territory of full skills in Xlib, GTK+, M4, Python/Perl, G++, C, and regular expressions.

Getting back to permissions - OK, one can give 'group' and 'others' execute permission. I guess I must have let a key concept slip here. I thought I was a 'user', not a 'group' or even an 'other'. I thought root could set a user to be a member of a 'group' so that he could do whatever that group exists to do. I then find a real long list where even bits of hardware seem to be 'users'. Thats OK - if I just keep reading and peeking, I will get it figured.

The /usr/local/share/ directory should have global execute permissions to allow any user to enter it. However it should not have global write permissions. The user and group owners should both be root. Other should not have write permissions. For one thing, this is a general folder where other software packages (from tarballs) will be installed.

Usually /usr/local/ is the base install directory for tarballs. Commands are usually copied to /usr/local/bin/, and libraries to /usr/local/lib, etc. Any user mode files saved from using the program should be saved in your home directory.

Check the contents of the "make install" target in the Makefile file. You can see which files are saved where.

Also make sure that /usr/local/bin is in your PATH variable. If not add "export PATH=$PATH:/usr/local/bin" to your ~/.profile file if you use bash as your default shell.

My thanks jschiwal for setting it out like that.

While I have been meddling with various Linux distros, and (slowly) losing a DOS/Windows legacy that stalled at Windows 2000, I have tended to slap on any strategy that worked, all the time being aware it could be unwise.

There will come a point when I have to set up a Linux box that might well be an internet connected gateway with mail and print services. I am just going to have to get used to not spreading permissions around like candy at a kiddies party.

G

You might want to read through the documentation for the RPM command. Often a package such as filesystems will setup many of the system directories such as /usr/local. You can use the rpm command to find out if this is the case for rpm based distros, such as SuSE.
On this Fedora Core laptop, /usr/local is created by the filesystem package. The -qV option shows that the permissions were not altered.
You can use the --setperm or --setugids options to fix permissions and group ownerships of the files that a package supplies.

I don't use debian, but it's package program may have similar options.