[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: "Operation not permitted" error when using su



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    
 : :'  :
 `. `'`
   `-


Reply to: