1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
|
<br><br><div class="gmail_quote">On Mon, Jun 11, 2012 at 2:30 PM, Len Lawrence <span dir="ltr"><<a href="mailto:tarazed25@gmail.com" target="_blank">tarazed25@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 11/06/12 12:28, Doug Laidlaw wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, 11 Jun 2012 11:33:46 +0100<br>
Len Lawrence<<a href="mailto:tarazed25@gmail.com" target="_blank">tarazed25@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
After a warm reboot this morning I found that I no longer had the<br>
ability to run my own commands even though the permissions are correct<br>
and ownership is lcl (uid=500). User system commands are OK so<br>
running a script via ruby for instance works but trying to execute the<br>
script by itself fails even though it is fully executable. This<br>
applies to all my local bin commands. Command aliases however do work<br>
as long as they do not involve running any of my bin files.<br>
<br>
Even root cannot execute these bin commands; same message "Permission<br>
denied".<br>
<br>
In addition the system has switched me to autologin. Trying to run<br>
mcc I was told it cannot be run in console mode (??). If I login as<br>
su mcc comes up in console mode, which I am not inclined to use.<br>
<br>
The hostname on this machine is belexeuli; this does not appear in<br>
the command prompt: [lcl@localhost ~]$<br>
<br>
After su: [root@belexeuli lcl]#<br>
<br>
This may all have something to do with my adding groups and changing<br>
group ids yesterday in my attempts to implement a viable sudoers<br>
command. It worked and I could log out and in again without any<br>
problems. I even managed a reboot without trouble but today is<br>
another story.<br>
<br>
I suspect that solving these multiple problems is beyond my technical<br>
skill even with help so a full reinstall is probably the best bet.<br>
However I will await any comments.<br>
<br>
Len<br>
<br>
</blockquote>
You say that the permissions are correct, but do they include execute<br>
permissions? The prompt difference may be simply that root's prompt is<br>
no longer the same as a user's prompt. It is set by a config file for<br>
each user. You can see the code for it by typing "echo $PS1" In my<br>
case, that gives "[\u@\h \W]\$" The \h puts in the hostname. You can<br>
change it for the current session by typing at the user prompt:<br>
<br>
PS1="[\u@\h \W]\$"<br>
<br>
You can make that permanent by putting it in your .bash_profile, where<br>
it should override the other at your next login, but really, it is only<br>
a workaround.<br>
<br>
With so many issues, I would do a full reinstall, but more knowledgeable<br>
people tell me it is the easy way out.<br>
<br>
HTH,<br>
<br>
Doug.<br>
</blockquote>
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.<br>
Until yesterday there was no lcl group, only user lcl. The group for lcl was live, which I have<br>
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.<br>
Note that I can chmod -x <file> and chmod +x <file> but that does not change anything.<br>
<br>
I notice that home now contains a "live" directory: /home/live, ownership lcl:lcl, containing tmp and nothing else. Now that is weird.<br>
<br>
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.<br>
<br>
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.<br>
</blockquote><div><br><br>Maybe it was somehow mounted with the -noexec flag?<br><br>Alejandro.<br><br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Cheers<span class="HOEnZb"><font color="#888888"><br>
<br>
Len<br>
<br>
<br>
</font></span></blockquote></div><br>
|
