We still don't really have a clue what went wrong, but "Failed to write"
made it sound like we did.
Change-Id: Ic58b13202e2d8ea6b095f7046db9d0771d77ce65
By using Minijail we avoid writing the same priv-dropping code over
and over again. This also enables future hardening opportunities.
We're already using Minijail for priv-dropping on Brillo.
Minijail is unit- and integration-tested on the
Chrome OS CI infrastructure (pulling from the same repo, see
https://wmatrix.googleplex.com/security?tests=security_Minijail0).
Once CI comes to Android, it will be continuously tested there as well.
Both 'adb root' and 'adb unroot' still work.
Bug: 26099611
Change-Id: I52c456ea272d27bd6fbc71200f4fdd928a592158
The current implementation of the host commands "adb wait-for-*" allows
to specify only the transport layer (local, usb or any).
This patch allows the specification of the expected device state
(bootloader, recovery, device or sideload), this is usefull for
scripting purposes.
Use case:
$ adb reboot sideload-auto-reboot
$ adb wait-for-usb-sideload && adb sideload package.zip
Change-Id: I276a6be4d82f8b7901f74e1e5395b86d16548e8f
Signed-off-by: Leo Sartre <leox.sartre@intel.com>
Reads from functionfs allocate contiguous buffers in the kernel, causing
long ones to sometimes fail because of memory fragmentation.
Bug: http://b/26206622
Change-Id: Id40753d6f29b37b5ca97c3e2fa3921f52b4242de
Back in 080427e4e2, we said:
If the kernel doesn't support file capabilities, we ignore
a prctl(PR_CAPBSET_DROP) failure. In a future CL, this could
become a fatal error.
Make it a fatal error. With SELinux support, all devices are
required to support file capabilities.
Change-Id: I0ce0c4cb9387c42e325cbf1a63c5d82e6aab530c
Previously, for `adb shell`, we were using setenv after forking to set
up the child's environment. This would occasionally deadlock in the
child, which would cause the main thread to deadlock waiting for the
child to complete. This patch constructs the environment before forking
and passes it to execle, eliminating the deadlock.
Bug: http://b/25847115
Change-Id: I720d472770564b1449819ddaab945a89844244a8
Shell scripts of the following form do not work properly with adb:
echo "foo\nbar\nbaz" | {
read FOO
while [ "$FOO" != "" ]; do
adb shell echo $FOO
read FOO
done
}
The first run of adb shell will consume all of the contents of stdin,
causing the loop to immediately end. ssh solves this by providing a -n
flag that causes it to not read from stdin. This commit adds the same.
Bug: http://b/25817224
Change-Id: Id74ca62ef520bcf03678b50f4bf203916fd81038
During early boot, we may be mounting and unmounting /data.
Having the home directory for adb shell commands, such as
"adb shell logcat", on the /data directory prevents unmounting.
This reverts commit 173eb396c7.
Bug: 26132185
Change-Id: Ib7c2f9e696f52bf5bbb79223d90dd76791779587
We had mostly-working hacks before, but it's time to just modify LinePrinter
to suit our needs. If we tell LinePrinter what kind of output we're giving
it, it can manage things automatically.
This fixes the minor bug where we'd sometimes have a blank line after an
error message.
Change-Id: I07ff52437f2402de311e237dd1b2dd338d9b668a
Make the home directory for adb shell be /data/local/tmp and
automatically change into that directory.
Change-Id: Ib5cc6e1ecdd31a37e986cf03836f7589ebd40868
Also, inline the bulk_read and bulk_write functions which were only
being used by one other function.
Bug: http://b/25847115
Change-Id: I218a869030219f606577a5529601c542488115e0
The current permission messages can be confusing for users who don't
know about udev and USB access permissions. This CL adds some checks to
try to identify common udev problems, and adds a link to online
documentation.
Example messages:
1) adb server is in plugdev group but access is still denied:
$ adb devices
List of devices attached
082f59270073e1e3 no permissions (verify udev rules); see [developer.android.com/tools/device.html]
2) plugdev group exists but adb server is not in it:
$ adb shell
error: USB permission failure: udev requires plugdev group membership.
See [developer.android.com/tools/device.html] for more information.
3) plugdev group does not exist:
$ adb shell
error: USB permission failure.
See [developer.android.com/tools/device.html] for more information.
Bug: http://b/25777880
Change-Id: I536565adc12ab657c75151309795674181205db0
If we stat a file and get a size of 0, and then successfully read bytes
from that file, we would previously divide by zero when calculating the
percentage completion of the file. This case happens either when we're
racing against something else writing to the file, or when we're pulling
magical files such as the ones in /dev/cpuctl/ that lie about their
size.
Bug: http://b/25925733
Change-Id: I980b9c14f44a1eb4a42bc8736c94fa6db06c08d1
The previous change to do this (f96dc73b) only skipped individually
named symlinks, not symlinks inside of a directory that was being
pulled.
Bug: http://b/25601283
Change-Id: I25bdcbc546a9d3a0dbd8dacdb065fb134d96022b
This patch ensures that we read any error response from the server if the
server closes the connection. Unfortunately, that's not sufficient to ensure
that we always see the server's error message --- sometimes the data just
gets thrown away because we keep writing without reading. Setting SO_LINGER
avoids this.
Bug: http://b/25230872
Change-Id: I96c019cc72bd139198de79bf29e6536cc462c20f
We're now able to send packets faster than the device can handle them,
meaning that sometimes we're several packets through before the device
says "hey, wait, I can't write" and closes the connection. At best this
led to us reporting that we couldn't sync because "Connection reset";
at worst we'd get SIGPIPE because we were still streaming to a connection
that had already been closed.
This change renames adb_main adb_server_main, and moves the ignoring of
SIGPIPE into adb_commandline so it applies to both client and server (but
not adbd).
This change doesn't address the "wrong error message" part of the problem,
but at least it means you'll get *an* error message.
Bug: http://b/25230872
Change-Id: Ic60e4d13ed03fdcdf0d5cbc97201ebd1097c16ed
I put the conditional in the wrong place, not realizing that even the
old shell system allowed one 'argument'.
Bug: http://b/25765657
Change-Id: I2752fb838d6377bf24e5b4cf959462557a196c87
Elliott Hughes