[Top][All Lists]

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

Questions to bash "read" builtin functionality

From: Fiedler Roman
Subject: Questions to bash "read" builtin functionality
Date: Fri, 14 Dec 2012 11:28:03 +0000

Hello list,

One of our bash-scrips failed with very low frequency but randomly. The result 
was that exactly 1 byte was lost, so the string returned by "read -t 1" was too 
short. The culprit seems to be the built-in read function itself, the 
probability of failure was about 1:100000 in our case.

After analysis and creation of a reliable reproducer, I'm not sure if this is a 
programming error in bash or a bug in our script as the result of suboptimal 

* Description:

When "read" builtin is used with timeout setting, both with "-t" option or by 
setting the "TMOUT" environment variable, and the timeout occurs when some 
bytes of line were already received by bash, then those bytes are silently 
dropped. The next "read" returns the remainder of the line.

A reproducer for Ubuntu precise is

base64 -d <<BASE64-EOF | tar -xj
(export TMOUT=1; ./FragmentedSend.py | ./BashReadTest)

* Discussion:

The topic has two aspects:

** What is the intended read behavior in that case, is it a bug?

Man-page is silent on that. So even if current behavior is intended, in my 
opinion the possible loss of data in "read" should be mentioned.

              -t timeout
                     Cause read to time out and return failure if  a  complete
                     line  of input is not read within timeout seconds.  time-
                     out may be a decimal number  with  a  fractional  portion
                     following  the decimal point.  This option is only effec-
                     tive if read is reading input from a terminal,  pipe,  or
                     other  special  file;  it has no effect when reading from
                     regular files.  If timeout is 0, read returns success  if
                     input  is  available  on  the  specified file descriptor,
                     failure otherwise.  The exit status is greater  than  128
                     if the timeout is exceeded.

**Mild security aspect:

Since the TMOUT variable might not be filtered when invoking programs via 
"sudo" or within other restricted environments, it might be possible for an 
unprivileged user to invoke programs that use "read" in the same problematic 
way as I did. If he finds ways to influence the timing of the data reaching 
this function, he might be able to remove parts of the input or just cause 
random data corruption.

I would guess, that it would be a quite rare case, e.g. when someone 
implemented following script for login checking

cat [somefile] | sed [regex check for line sanity] | while read authConfLine; do
 ....Handle it

somefile content:

root allprivs Remaining line name of admin
userx someprivs FrankChangedItViaChFn userx allprivs FrankDidIt

Any comments?

DI Roman Fiedler
Safety & Security Department
Assistive Healthcare Information Technology

AIT Austrian Institute of Technology GmbH
Reininghausstrae 13/1  |  8020 Graz  |  Austria
T +43(0) 50550 2957  |  M +43(0) 664 8561599  |  F +43(0) 50550 2950
address@hidden | http://www.ait.ac.at/

FN: 115980 i HG Wien  |  UID: ATU14703506
This email and any attachments thereto, is intended only for use by the 
addressee(s) named herein and may contain legally privileged and/or 
confidential information. If you are not the intended recipient, please notify 
the sender by return e-mail or by telephone and delete this message from your 
system and any printout thereof. Any unauthorized use, reproduction, or 
dissemination of this message is strictly prohibited. Please note that e-mails 
are susceptible to change. AIT Austrian Institute of Technology GmbH shall not 
be liable for the improper or incomplete transmission of the information 
contained in this communication, nor shall it be liable for any delay in its 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]