On 11/06/12 12:28, Doug Laidlaw wrote:

On Mon, 11 Jun 2012 11:33:46 +0100
Len Lawrence<tarazed25@gmail.com>  wrote:

After a warm reboot this morning I found that I no longer had the
ability to run my own commands even though the permissions are correct
and ownership is lcl (uid=500).  User system commands are OK so
running a script via ruby for instance works but trying to execute the
script by itself fails even though it is fully executable.  This
applies to all my local bin commands.  Command aliases however do work
as long as they do not involve running any of my bin files.

Even root cannot execute these bin commands; same message "Permission
denied".

In addition the system has switched me to autologin.  Trying to run
mcc I was told it cannot be run in console mode (??).  If I login as
su mcc comes up in console mode, which I am not inclined to use.

The hostname on this machine is belexeuli; this does not appear in
the command prompt: [lcl@localhost ~]$

After su: [root@belexeuli lcl]#

This may all have something to do with my adding groups and changing
group ids yesterday in my attempts to implement a viable sudoers
command.  It worked and I could log out and in again without any
problems.  I even managed a reboot without trouble but today is
another story.

I suspect that solving these multiple problems is beyond my technical
skill even with help so a full reinstall is probably the best bet.
However I will await any comments.

Len

You say that the permissions are correct, but do they include execute
permissions?  The prompt difference may be simply that root's prompt is
no longer the same as a user's prompt.  It is set by a config file for
each user.  You can see the code for it by typing "echo $PS1" In my
case, that gives "[\u@\h \W]\$"  The \h puts in the hostname.  You can
change it for the current session by typing at the user prompt:

    PS1="[\u@\h \W]\$"

You can make that permanent by putting it in your .bash_profile, where
it should override the other at your next login, but really, it is only
a workaround.

With so many issues, I would do a full reinstall, but more knowledgeable
people tell me it is the easy way out.

HTH,

Doug.

Yes, all the commands have execute permission.  I have been using my local bin directory for years and I have never had execute refused so this must reflect some deep system level screwup relating to lcl and maybe something in pam.d.  That is unknown country for me.
Until yesterday there was no lcl group, only user lcl.  The group for lcl was live, which I have
removed from my group list.  live was my primary group, now it is lcl which I added yesterday.  Ownership of my files is now lcl:lcl and in /home/lcl/bin the permissions are nearly all 755.
Note that I can chmod -x <file> and chmod +x <file> but that does not change anything.

I notice that home now contains a "live" directory: /home/live, ownership lcl:lcl, containing tmp and nothing else.  Now that is weird.

The difference in the root and user prompts is probably related to the fact that root cannot access the user's X display.  I have seen that sort of thing before when the two have been using different hostnames.  I think that root is now looking at belexeuli:0 whereas the user has for some reason reverted to localhost:0.  Attempts at using the gui by root throw up protocol errors.

As you say, a reinstall looks like the best way out.  More knowledgeable people would probably know just where to look for the root of the problem(s) but even after 21 years experience of Unix and Linux I know next to nothing about access and security policies.

Cheers

Len