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
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 11/06/12 13:58, Alejandro López wrote:
<blockquote
cite="mid:CAHDxzRdU92+44ixhKUFPDPeRPJ7aq9q0p3fSwv+ynxmAJduftQ@mail.gmail.com"
type="cite"><br>
<br>
<div class="gmail_quote">On Mon, Jun 11, 2012 at 2:30 PM, Len
Lawrence <span dir="ltr"><<a moz-do-not-send="true"
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 moz-do-not-send="true"
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>
</div>
<br>
</blockquote>
mtab contains this entry:<br>
<br>
/dev/sda6 /home ext4
rw,nosuid,nodev,noexec,relatime,user_xattr,barrier=1,data=ordered 0
0<br>
<br>
fstab had:<br>
# Entry for /dev/sda6 :<br>
UUID=341956e4-fddb-45a6-a191-4c912328ec7a /home ext4 user,defaults 1
2<br>
none /proc proc defaults 0 0<br>
<br>
I have removed the "user," because it does not tally with my other
mga2 workstation.<br>
That does not have noexec against /home.<br>
<br>
About to reboot.<br>
<br>
Thanks for the pointer.<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>
|