On 11/06/12 12:28, Doug Laidlaw wrote:
On Mon, 11 Jun 2012 11:33:46 +0100
Len Lawrence<[email protected]> 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
