[texhax] Explanation? - Was texhash trouble in TL on Ubuntu

[Gordon Haverland]

On August 16, 2012, Axel E. Retif wrote:
> What I do is prepend TeXLive path in /etc/environment:

A bunch of this is of a philosophical nature.  Unfortunately, the 
people coming into this, have never seen the philosophy.

Root is the superuser, and can do whatever they want to.  
Permissions are not checked.  Somethings are impossible, so 
sometimes root sees errors that look like permissions.

Because root can do anything, people should not get in the habit 
of doing anything "normal" as root.  Root is there to maintain the 
system.  Root is not there to run TeX programs, or moreso to run 
anything in a GUI.  Most *buntu people using sudo are doing so 
from a GUI.  I can't remember there being any problems, but it is 
more likely to have problems from a GUI than from a plain old text 
console.

Consequently, the PATH for the root user should be much different 
than for ordinary users.  A good example is having '.' in the 
PATH, this is relatively common for users, it should never be 
present in the PATH of root.  Users probably have /usr/bin and 
/usr/local/bin near the front of the PATH, root should have /bin, 
/sbin, /usr/sbin and /usr/local/sbin near the front of the PATH, 
and might not even have /usr/bin or /usr/local/bin in the PATH.

Debian, and Debian based systems typically create UserIDs with the 
preferred name of the user, and at the same time creating a group 
with the same name.  This makes UserID _own_ the group of the same 
name.  And the owner of a group, as an ordinary user, can control 
the UserIDs of other logins that belong to that group.

If I am logged in as fred, I am allowed to make wilma a member of 
group 'fred'.  And I can do the same for barney and betty.  And if 
mrslate is on the same computer, there is nothing that requires 
fred to make mrslate a member of group fred.

Each user is allowed to administer their own group, and they can 
make group permissions as permissive or as closed as they want.  
They can also make use of SGID on programs, so that anyone in the 
group, can run programs as if it was the GROUP running them.  Some 
people have heard of problems with SUID, SGID is similar, and 
missing some of the headaches.

On Debian, the normal installation of PostgreSQL installs a 
postgres user.  It is not possible to login as the postgres user.  
But, there are adminstrative tasks that only the postgres user can 
do.  The only (proper?) way to do these, is to make use of the 
root user.

Related to the sudo command, is the su command.  Su allows a user 
to become another user.  With no argument, su assumes someone 
wants to become root, and so it prompts for the root password.  
But, su will allow users to "become" other users.  If fred does
  su wilma
fred is prompted for wilma's password, and if fred knows wilma's 
password, fred "assumes" the ID of wilma, and anything fred does 
until he closes the shell that su provided, is done as the user 
wilma.

The above is true for all users, except for root.  If root wants 
to assume any user's ID, no password is asked for.  I mentioned 
PostgreSQL earlier, and root can "assume" the postgres ID by doing
  su postgres
And no password is required.  Which is how the postgres user can 
do things, that need to be done manually, when the user postgres 
is not allowed to login.

This is too long.  I hope this trip into UN*X permissions has been 
of help.

Gord