On Mon, Jun 11, 2012 at 2:30 PM, Len Lawrence <[email protected]> wrote:
> 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. > Maybe it was somehow mounted with the -noexec flag? Alejandro. > > Cheers > > Len > > >
