Stephen Powell wrote: > ...logged in as root... > su barney > vi stuff > Error: messages not turned on: /dev/pts/0: Operation not permitted
The above is basically a normal result of the current environment. At
another level it is a bug in nvi. I suggest that you understand it
and then ignore it. Or jump into the nvi code and fix it.
There are two issues. First is that root needs to protect itself
against attacks against its smart terminal. Therefore "messages"?
will be off by default for root. What does that mean? It means the
ability of processes to send text to the terminal. Processes may be a
"biff" mail notification program saying "you have mail". Or it may be
a user trying to "write(1)" (old Unix IM program) to your terminal.
Or it may be a local user (think student on a multiuser university
system) trying to crack into your terminal by sending smart terminal
escape sequences. (Most terminals have those disabled these days for
security surrounding this issue too. Because even for non-root smart
terminal attacks is still an issue.)
Non-Root User:
$ ls -l /dev/pts/23
crw--w---- 1 rwp tty 136, 23 Jun 29 19:02 /dev/pts/23
Root User:
$ ls -l /dev/pts/11
crw------- 1 root tty 136, 0 Jun 29 19:00 /dev/pts/11
Or in the old days on other systems I recall it being world writable
by other too. But that may be an incorrect memory.
For root the standard is that no one else can write(1) to the
terminal. (And probably "talk" and others too.) See the man page for
mesg(1) for a small amount of additional information. It was common
in the old days to see "mesg n" in root's dot profile file.
man mesg
So back to your problem... You are starting from a /dev/pts/X that is
owned by root and is not otherwise writable. That is good. Safe from
various attacks. That is what you want.
But then the second issue comes into play. You are using su to switch
user to a non-root user. After you have switched to that user the pty
hasn't changed. That is intentional due to the security risk nature
of root. But it means that the non-root user processes can't make
changes to the tty device.
Now is where the nvi bug/misfeature comes into play. There really
isn't any reason for nvi to need to touch the pty. In my opinion it
should do nothing to it by default. Emacs doesn't touch the pty. If
you try your test case with emacs there will be no error printed. Nor
with vim. This is only a problem in the nvi program. Why? Because
it is trying to do too much.
What the nvi program is trying to do is to turn off messages to the
terminal while it is running. It is trying to prevent other local
users from using write(1) to you while you are editing.
man nvi
mesg [on]
Permit messages from other users.
In order to prevent messages from other users it tries to run chmod on
your pty device. This can be seen with strace.
$ strace -v -e chmod -o /tmp/nvi.strace.out nvi .bashrc
$ cat /tmp/nvi.strace.out
chmod("/dev/pts/0", 020620) = -1 EPERM (Operation not permitted)
chmod("/var/tmp/vi.recover/vi.ryTzPt", 0700) = 0
chmod("/dev/pts/0", 020600) = -1 EPERM (Operation not% permitted)
And those chmod's are the source of the messages that you are seeing.
The only way to fix this is to patch the nvi source code to avoid the
chmod calls.
Basically I ignore the errors. The file is edited successfully
anyway. It is just noise. Annoying. But since I know what is
happening and I only do that a very few times I just ignore it.
This would be a reasonable issue to submit as a bug against nvi.
However there are worse problems with nvi. See Bug#497342 which has
been around for years which is much more annoying. Filing bugs is
easy but if no one is around to fix them then it doesn't do much
good. But this is a valid bug in my opinion. Though much less of a
problem than Bug#497342 which is very annoying. Especially since the
previous version 1.79 of nvi didn't have it. But that is a different
story.
Hope this explanation helps!
Bob
signature.asc
Description: Digital signature
