The new fs_mgr library moves much of the knowledge of what filesystems
to mount into a new fstab.<device> file, and just calls one function to
mount all the filesystems.
Change-Id: If3db37530a0676000cba3e679db27aca734227e5
Add SE Android support for init and ueventd.
init:
- Load policy at boot.
- Set the security context for service daemons and their sockets.
- New built-in commands: setcon, setenforce, restorecon, setsebool.
- New option for services: seclabel.
ueventd:
- Set the security context for device directories and nodes.
Change-Id: I98ed752cde503c94d99dfa5b5a47e3c33db16aac
If we process the import directive inline, then the ordering of the
commands for the "on xxx" sections would be a little unexpected. The
init.rc files do not really have an implied order as to which section
appears and gets processed first. The init code itself provides that
ordering explicitly. For the user, the expectation is that if both the
current file and the imported file define a section (e.g. "on init"),
then the commands in the current file will be executed first, and then
the ones from the imported file(s).
The current implementation did not do that. It processed the import
directive inline, and thus the imported (i.e. dependent) files would
appear first in the command lists for the sections. This created
unintended side effects and the solution would have been to try and
put the import lines somewhere in the middle of the init file. This
would be difficult to notice and hard to extract the dependencies.
To solve this, we add the imports to a list for each file being parsed
and process the list after finishing parsing the file. This provides
predictable order for imports and provides a logical flow from the
user perspective: the currently parsed file gets to run its commands
before the files being imported.
Change-Id: I06dc35ff286314060e16b18923683cd2787269de
Signed-off-by: Dima Zavin <dima@android.com>
Adds new property syntax in init files during init file filename
expansion during the import command:
${prop.name}
So, one can do: import /init.${ro.hardware}.usb.rc
Should convert other usages of property names to use the new function.
Change-Id: I9205d7d7a2da620bc8e6b89ac0eb554fad53ded3
Signed-off-by: Dima Zavin <dima@android.com>
The class_reset command used to reset services that had been set to
"disabled" in the init.rc file to a non-disabled state. Now, if the
service was originally set to "disabled", have the reset command set
it back to disabled. Otherwise, set it to the "reset" state as it
currently does.
Change-Id: I0c10582e46a8e443d4748d9d893ae762b19b653a
For example, the following trigger will fire when the sys.foo property
is set to any value:
on property:sys.foo=*
write /data/foo hello
It is also possible to refer to the property within the trigger actions:
on property:sys.foo=*
write /data/foo $sys.foo
Change-Id: If78d20a532f77e17aa5703d53be581ad6736cbcf
Signed-off-by: Mike Lockwood <lockwood@android.com>
Fix for bug 3415286. The persistent properties are normally read early
in the boot process after /data is mounted. However, for an encrypted
system, at that point /data is a tmpfs ramdisk. This change adds a new
command to init (load_persist_props) to read the persistent properties,
and adds an action to init.rc to load the persistent properties. This
action is triggered by setting a property in vold, but that's in a
different CL.
Change-Id: I74b3057974ee6029c29d956b76fef5566700d471
rm only removes a single non-directory directory entry (no -r support)
rmdir removes a single empty directory
Change-Id: I49702b02ba98a177027b126268c2c2846f968195
These are the changes to init and init.rc necessary to
support booting with and encrypted /data filesystem.
A corresponding change to init.<device>.rc goes along
with this change.
Change-Id: I0c7e2cc39568358014a82e317735c0eae14dd683
This keyword will cause init to wait a few seconds before exec'ing
the target binary. Maybe only useful for hacks and debugging.
Change-Id: I85caa0bcbc0be7e48bd21eb9e31e039c0740c8d5
