Sun, 30 Jun 2013 02:09:35 -0400 (EDT), Bob Proulx wrote: > > 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
Thank you, Bob, for that detailed explanation. I'm not starting out as root though. I'm starting out as "fred" (Applications -> Utilities -> Terminal, in the latest version of Gnome under Jessie, while logged in to the graphical desktop as "fred"), then doing a direct su to "barney". (Those user ids were chosen for illustrative purposes only, they are not the actual user ids that I am using.) The basis of your explanation is sound though. barney does not have the authority to issue chmod against a "file" (/dev/pts/0) owned by fred. Even if the file permissions themselves gave barney permission to write to the file (crw-rw-rw-), that's different from permission to change the file *attributes*. When doing an su to root the problem does not occur because root has ex-officio permission to issue chmod against *any* file. Now that I understand what is happening, I know that I can safely ignore the error message. And I agree, nvi is trying to do too much. Thanks again! -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/425753033.2015930.1372936364173.javamail.r...@md01.wow.synacor.com