"&&" operator can now be used to test the validity
of two of more properties.
For example:
on property:test.a=1 && property:test.b=1
setprop test.c 1
The above stub sets the test.c to 1 only when
both test.a=1 and test.b=1
(cherry-pick of 162f7d797c67019a7a3f08c3b0f0ffc91d548ddc.)
Change-Id: I72c19f7aa92231372a416193618ee6c7fd368141
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
42a9349dc4 modified init's
builtin chmod, chown, and mkdir calls to avoid following
symlinks. This addressed a number of attacks we were seeing
at the time where poorly written init scripts were following
attacker supplied symlinks resulting in rooting vulnerabilities.
To avoid race conditions, the previous implementation only ran
fchown / fchmod on file descriptors opened with open(O_NOFOLLOW).
Unfortunately, unlike the normal "chown" or "chmod" calls, this
requires read or write access to the underlying file. This
isn't ideal, as opening some files may have side effects, or
init may not have permission to open certain files (such as when
SELinux is enabled).
Instead of using open(O_NOFOLLOW) + fchown(), use lchown() instead.
As before, the target of the symlink won't be modified by chown.
This also supports setting the ownership of symlinks.
Instead of using open(O_NOFOLLOW) + fchmod(), use
fchmodat(AT_SYMLINK_NOFOLLOW) instead. As before, the target of the
symlink won't be modified by chmod.
This change will continue to ensure that chown/chmod/mkdir doesn't
follow symlinks, without requiring init to open every file in
read-only or read-write mode.
This change depends on bionic commit I1eba0cdb2c509d9193ceecf28f13118188a3cfa7
Addresses the following mako/occam SELinux denial:
audit(1422770408.951:6): avc: denied { write } for pid=1 comm="init" name="smd7" dev="tmpfs" ino=7207 scontext=u:r:init:s0 tcontext=u:object_r:radio_device:s0 tclass=chr_file
Change-Id: I14fde956784d65c44e7aa91dd7eea9a004df3081
/data/tombstones is referenced by core platform code, but is not
guaranteed to exist on all Android devices. Move the directory
creation out of device specific files and into the core
init.rc file.
Bug: https://code.google.com/p/android/issues/detail?id=93207
Change-Id: I94ae5199a6a32c4fe555ca994fc4a8345e0c9690
Delay mounting encryptable but unencrypted volumes until we can
check the ro.vold.forceencrypt flag, then optionally encrypt.
Requires matching vold change from
https://googleplex-android-review.git.corp.google.com/#/c/615309/
Bug: 18764230
Change-Id: If22008be8de6a4f3216b349f81ace49be1730314
This allows a vendor to force encryption on devices via a vendor
partition flag:
ro.vold.forceencryption 1
Bug: 18764230
Change-Id: Id0049ce64e34e4f6f96e593aadd70c277ac131c8
If tracing was not enabled (the ADB_TRACE environment variable was not
set specially), writex() and readx() would still call dump_hex() which
would construct hex tracing strings, which would be immediately
discarded and not printed (because tracing is not enabled).
The fix is to only call dump_hex() if ADB_TRACING evalutes to true, the
same way that dump_packet() is only called if ADB_TRACING evaluates to
true.
Change-Id: I1651680da344389475ebdeea77ba1982960d5764
Signed-off-by: Spencer Low <CompareAndSwap@gmail.com>
Currently, a host running adb will sign a token of any length passed
to it by a device, effectively acting as a signing oracle. If the
ADB_VENDOR_KEYS environment variable is used to specify an additional
key to use, this behavior is not only unexpected, but probably also
unwanted. Further discussion can be found from this thread:
http://www.metzdowd.com/pipermail/cryptography/2015-January/024423.html
This change adds a check to ensure token length matches TOKEN_SIZE
before it's signed, which prevents an attacker from signing longer
messages.
Change-Id: I7b2cc1f051941bf9b66e1c02980850bede501793
On Windows, adb_socket_setbufsize() was taking a file descriptor value
from the compatibility layer in sysdeps_win32.c (namely, an index into
the _win32_fhs array) and passing it to the Winsock setsockopt() call,
which wants a Winsock SOCKET handle. Basically, adb_socket_setbufsize()
was passing `fd` instead of `_fh_from_int(fd)->fh_socket`, resulting in
adb effectively setting a socket buffer size on a random socket in the
process.
The fix is to introduce adb_setsockopt() which just calls setsockopt()
on non-Win32, and which uses the Winsock SOCKET handle on Win32. The
change also moves Win32 disable_tcp_nagle() to a header and adds an
extra sanity check to adb_shutdown().
Change-Id: I4354e818d27538f7ff5b0e70b28bdb6300e1b98b
Signed-off-by: Spencer Low <CompareAndSwap@gmail.com>
