tequilaOS/platform_system_core
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
platform_system_core/init/action.h

100 lines
3.1 KiB
C
Raw Normal View History

init: Create classes for Action and Command This creates the concept of 'event_trigger' vs 'property_trigger' Previously these were merged into one, such that 'on property:a=b && property:b=c' is triggered when properties a=b and b=c as expected, however combinations such as 'on early-boot && boot' would trigger during both early-boot and boot. Similarly, 'on early-boot && property:a=b' would trigger on both early-boot and again when property a equals b. The event trigger distinction ensures that the first example fails to parse and the second example only triggers on early-boot if property a equals b. This coalesces Actions with the same triggers into a single Action object Change-Id: I8f661d96e8a2d40236f252301bfe10979d663ea6
2015-07-24 02:53:11 +02:00
/*
* Copyright (C) 2015 The Android Open Source Project
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
init: check the arguments of builtins during the build Host init verifier already checks that the names and number of arguments for builtins are correct, but it can check more. This change ensures that property expansions are well formed, and that arguments that can be parsed on the host are correct. For example it checks that UIDs and GIDs exist, that numerical values can be parsed, and that rlimit strings are correct. Test: build Change-Id: Ied8882498a88a9f8324db6b8d1020aeeccc8177b
2019-07-30 18:34:41 +02:00
#pragma once
init: Create classes for Action and Command This creates the concept of 'event_trigger' vs 'property_trigger' Previously these were merged into one, such that 'on property:a=b && property:b=c' is triggered when properties a=b and b=c as expected, however combinations such as 'on early-boot && boot' would trigger during both early-boot and boot. Similarly, 'on early-boot && property:a=b' would trigger on both early-boot and again when property a equals b. The event trigger distinction ensures that the first example fails to parse and the second example only triggers on early-boot if property a equals b. This coalesces Actions with the same triggers into a single Action object Change-Id: I8f661d96e8a2d40236f252301bfe10979d663ea6
2015-07-24 02:53:11 +02:00
#include <map>
#include <queue>
#include <string>
init: rename 'Trigger' to 'Event' and convert to std::variant The term 'trigger' should be used in 'Action' to indicate what causes the 'Action' to be executed. The term 'event' should be used in ActionManager's queue to indicate a state change that is checked against the 'triggers' of an 'Action' to see if it should execute. Convert the previous Trigger class to std::variant, as the latter is better suited for this use. Change-Id: I2558367c8318b536aa69fcec93793f1c12857ef5
2017-04-17 22:25:29 +02:00
#include <variant>
init: Create classes for Action and Command This creates the concept of 'event_trigger' vs 'property_trigger' Previously these were merged into one, such that 'on property:a=b && property:b=c' is triggered when properties a=b and b=c as expected, however combinations such as 'on early-boot && boot' would trigger during both early-boot and boot. Similarly, 'on early-boot && property:a=b' would trigger on both early-boot and again when property a equals b. The event trigger distinction ensures that the first example fails to parse and the second example only triggers on early-boot if property a equals b. This coalesces Actions with the same triggers into a single Action object Change-Id: I8f661d96e8a2d40236f252301bfe10979d663ea6
2015-07-24 02:53:11 +02:00
#include <vector>
init: Use classes for parsing and clean up memory allocations Create a Parser class that uses multiple SectionParser interfaces to handle parsing the different sections of an init rc. Create an ActionParser and ServiceParser that implement SectionParser and parse the sections corresponding to Action and Service classes. Remove the legacy keyword structure and replace it with std::map's that map keyword -> (minimum args, maximum args, function pointer) for Commands and Service Options. Create an ImportParser that implements SectionParser and handles the import 'section'. Clean up the unsafe memory handling of the Action class by using std::unique_ptr. Change-Id: Ic5ea5510cb956dbc3f78745a35096ca7d6da7085
2015-08-26 20:43:36 +02:00
#include "builtins.h"
#include "keyword_map.h"
init: use Result<T> for builtin functions We currently throw out the return values from builtin functions and occasionally log errors with no supporting context. This change uses the newly introduced Result<T> class to communicate a successful result or an error back to callers in order to print an error with clear context when a builtin fails. Example: init: Command 'write /sys/class/leds/vibrator/trigger transient' action=init (/init.rc:245) took 0ms and failed: Unable to write to file '/sys/class/leds/vibrator/trigger': open() failed: No such file or directory Test: boot bullhead Merged-In: Idc18f331d2d646629c6093c1e0f2996cf9b42aec Change-Id: Idc18f331d2d646629c6093c1e0f2996cf9b42aec
2017-08-01 22:50:23 +02:00
#include "result.h"
init: run vendor commands in a separate SELinux context One of the major aspects of treble is the compartmentalization of system and vendor components, however init leaves a huge gap here, as vendor init scripts run in the same context as system init scripts and thus can access and modify the same properties, files, etc as the system can. This change is meant to close that gap. It forks a separate 'subcontext' init that runs in a different SELinux context with permissions that match what vendors should have access to. Commands get sent over a socket to this 'subcontext' init that then runs them in this SELinux context and returns the result. Note that not all commands run in the subcontext; some commands such as those dealing with services only make sense in the context of the main init process. Bug: 62875318 Test: init unit tests, boot bullhead, boot sailfish Change-Id: Idf4a4ebf98842d27b8627f901f961ab9eb412aee
2017-09-13 00:58:47 +02:00
#include "subcontext.h"
init: Use classes for parsing and clean up memory allocations Create a Parser class that uses multiple SectionParser interfaces to handle parsing the different sections of an init rc. Create an ActionParser and ServiceParser that implement SectionParser and parse the sections corresponding to Action and Service classes. Remove the legacy keyword structure and replace it with std::map's that map keyword -> (minimum args, maximum args, function pointer) for Commands and Service Options. Create an ImportParser that implements SectionParser and handles the import 'section'. Clean up the unsafe memory handling of the Action class by using std::unique_ptr. Change-Id: Ic5ea5510cb956dbc3f78745a35096ca7d6da7085
2015-08-26 20:43:36 +02:00
init: create android::init:: namespace With some small fixups along the way Test: Boot bullhead Test: init unit tests Change-Id: I7beaa473cfa9397f845f810557d1631b4a462d6a
2017-06-22 21:53:17 +02:00
namespace android {
namespace init {
init: replace Result<Success> with Result<void> Now that Result<T> is actually expected<T, ...>, and the expected proposal states expected<void, ...> as the way to indicate an expected object that returns either successfully with no object or an error, let's move init's Result<Success> to the preferred Result<void>. Bug: 132145659 Test: boot, init unit tests Change-Id: Ib2f98396d8e6e274f95a496fcdfd8341f77585ee
2019-06-10 20:08:01 +02:00
Result<void> RunBuiltinFunction(const BuiltinFunction& function,
const std::vector<std::string>& args, const std::string& context);
init: run vendor commands in a separate SELinux context One of the major aspects of treble is the compartmentalization of system and vendor components, however init leaves a huge gap here, as vendor init scripts run in the same context as system init scripts and thus can access and modify the same properties, files, etc as the system can. This change is meant to close that gap. It forks a separate 'subcontext' init that runs in a different SELinux context with permissions that match what vendors should have access to. Commands get sent over a socket to this 'subcontext' init that then runs them in this SELinux context and returns the result. Note that not all commands run in the subcontext; some commands such as those dealing with services only make sense in the context of the main init process. Bug: 62875318 Test: init unit tests, boot bullhead, boot sailfish Change-Id: Idf4a4ebf98842d27b8627f901f961ab9eb412aee
2017-09-13 00:58:47 +02:00
init: Use classes for parsing and clean up memory allocations Create a Parser class that uses multiple SectionParser interfaces to handle parsing the different sections of an init rc. Create an ActionParser and ServiceParser that implement SectionParser and parse the sections corresponding to Action and Service classes. Remove the legacy keyword structure and replace it with std::map's that map keyword -> (minimum args, maximum args, function pointer) for Commands and Service Options. Create an ImportParser that implements SectionParser and handles the import 'section'. Clean up the unsafe memory handling of the Action class by using std::unique_ptr. Change-Id: Ic5ea5510cb956dbc3f78745a35096ca7d6da7085
2015-08-26 20:43:36 +02:00
class Command {
init: Stop combining actions In the past, I had thought it didn't make sense to have multiple Action classes with identical triggers within ActionManager::actions_, and opted to instead combine these into a single action. In theory, it should reduce memory overhead as only one copy of the triggers needs to be stored. In practice, this ends up not being a good idea. Most importantly, given a file with the below three sections in this same order: on boot setprop a b on boot && property:true=true setprop c d on boot setprop e f Assuming that property 'true' == 'true', when the `boot` event happens, the order of the setprop commands will actually be: setprop a b setprop e f setprop c d instead of the more intuitive order of: setprop a b setprop c d setprop e f This is a mistake and this CL fixes it. It also documents this order. Secondly, with a given 'Action' now spanning multiple files, in order to keep track of which file a command is run from, the 'Command' itself needs to store this. Ironically to the original intention, this increases total ram usage. This change now only stores the file name in each 'Action' instead of each 'Command'. All in all this is a negligible trade off of ram usage. Thirdly, this requires a bunch of extra code and assumptions that don't help anything else. In particular it forces to keep property triggers sorted for easy comparison, which I'm using an std::map for currently, but that is not the best data structure to contain them. Lastly, I added the filename and line number to the 'processing action' LOG(INFO) message. Test: Boot bullhead, observe above changes Test: Boot sailfish, observe no change in boot time Change-Id: I3fbcac4ee677351314e33012c758145be82346e9
2017-04-18 22:21:54 +02:00
public:
init: use rvalues references for callees of ParseLineSection() ParseLineSection() provides 'args' as an rvalue reference, so its callers can and should use it as such. This saves some copying overhead and cleans up the code a bit. Test: boot Change-Id: Ib906318583dc81de9ea585f5f09fdff35403be1b
2018-10-17 20:11:23 +02:00
Command(BuiltinFunction f, bool execute_in_subcontext, std::vector<std::string>&& args,
init: run vendor commands in a separate SELinux context One of the major aspects of treble is the compartmentalization of system and vendor components, however init leaves a huge gap here, as vendor init scripts run in the same context as system init scripts and thus can access and modify the same properties, files, etc as the system can. This change is meant to close that gap. It forks a separate 'subcontext' init that runs in a different SELinux context with permissions that match what vendors should have access to. Commands get sent over a socket to this 'subcontext' init that then runs them in this SELinux context and returns the result. Note that not all commands run in the subcontext; some commands such as those dealing with services only make sense in the context of the main init process. Bug: 62875318 Test: init unit tests, boot bullhead, boot sailfish Change-Id: Idf4a4ebf98842d27b8627f901f961ab9eb412aee
2017-09-13 00:58:47 +02:00
int line);
init: Use classes for parsing and clean up memory allocations Create a Parser class that uses multiple SectionParser interfaces to handle parsing the different sections of an init rc. Create an ActionParser and ServiceParser that implement SectionParser and parse the sections corresponding to Action and Service classes. Remove the legacy keyword structure and replace it with std::map's that map keyword -> (minimum args, maximum args, function pointer) for Commands and Service Options. Create an ImportParser that implements SectionParser and handles the import 'section'. Clean up the unsafe memory handling of the Action class by using std::unique_ptr. Change-Id: Ic5ea5510cb956dbc3f78745a35096ca7d6da7085
2015-08-26 20:43:36 +02:00
init: replace Result<Success> with Result<void> Now that Result<T> is actually expected<T, ...>, and the expected proposal states expected<void, ...> as the way to indicate an expected object that returns either successfully with no object or an error, let's move init's Result<Success> to the preferred Result<void>. Bug: 132145659 Test: boot, init unit tests Change-Id: Ib2f98396d8e6e274f95a496fcdfd8341f77585ee
2019-06-10 20:08:01 +02:00
Result<void> InvokeFunc(Subcontext* subcontext) const;
init: Use classes for parsing and clean up memory allocations Create a Parser class that uses multiple SectionParser interfaces to handle parsing the different sections of an init rc. Create an ActionParser and ServiceParser that implement SectionParser and parse the sections corresponding to Action and Service classes. Remove the legacy keyword structure and replace it with std::map's that map keyword -> (minimum args, maximum args, function pointer) for Commands and Service Options. Create an ImportParser that implements SectionParser and handles the import 'section'. Clean up the unsafe memory handling of the Action class by using std::unique_ptr. Change-Id: Ic5ea5510cb956dbc3f78745a35096ca7d6da7085
2015-08-26 20:43:36 +02:00
std::string BuildCommandString() const;
init: check the arguments of builtins during the build Host init verifier already checks that the names and number of arguments for builtins are correct, but it can check more. This change ensures that property expansions are well formed, and that arguments that can be parsed on the host are correct. For example it checks that UIDs and GIDs exist, that numerical values can be parsed, and that rlimit strings are correct. Test: build Change-Id: Ied8882498a88a9f8324db6b8d1020aeeccc8177b
2019-07-30 18:34:41 +02:00
Result<void> CheckCommand() const;
init: Use classes for parsing and clean up memory allocations Create a Parser class that uses multiple SectionParser interfaces to handle parsing the different sections of an init rc. Create an ActionParser and ServiceParser that implement SectionParser and parse the sections corresponding to Action and Service classes. Remove the legacy keyword structure and replace it with std::map's that map keyword -> (minimum args, maximum args, function pointer) for Commands and Service Options. Create an ImportParser that implements SectionParser and handles the import 'section'. Clean up the unsafe memory handling of the Action class by using std::unique_ptr. Change-Id: Ic5ea5510cb956dbc3f78745a35096ca7d6da7085
2015-08-26 20:43:36 +02:00
init: Stop combining actions In the past, I had thought it didn't make sense to have multiple Action classes with identical triggers within ActionManager::actions_, and opted to instead combine these into a single action. In theory, it should reduce memory overhead as only one copy of the triggers needs to be stored. In practice, this ends up not being a good idea. Most importantly, given a file with the below three sections in this same order: on boot setprop a b on boot && property:true=true setprop c d on boot setprop e f Assuming that property 'true' == 'true', when the `boot` event happens, the order of the setprop commands will actually be: setprop a b setprop e f setprop c d instead of the more intuitive order of: setprop a b setprop c d setprop e f This is a mistake and this CL fixes it. It also documents this order. Secondly, with a given 'Action' now spanning multiple files, in order to keep track of which file a command is run from, the 'Command' itself needs to store this. Ironically to the original intention, this increases total ram usage. This change now only stores the file name in each 'Action' instead of each 'Command'. All in all this is a negligible trade off of ram usage. Thirdly, this requires a bunch of extra code and assumptions that don't help anything else. In particular it forces to keep property triggers sorted for easy comparison, which I'm using an std::map for currently, but that is not the best data structure to contain them. Lastly, I added the filename and line number to the 'processing action' LOG(INFO) message. Test: Boot bullhead, observe above changes Test: Boot sailfish, observe no change in boot time Change-Id: I3fbcac4ee677351314e33012c758145be82346e9
2017-04-18 22:21:54 +02:00
int line() const { return line_; }
private:
init: Use classes for parsing and clean up memory allocations Create a Parser class that uses multiple SectionParser interfaces to handle parsing the different sections of an init rc. Create an ActionParser and ServiceParser that implement SectionParser and parse the sections corresponding to Action and Service classes. Remove the legacy keyword structure and replace it with std::map's that map keyword -> (minimum args, maximum args, function pointer) for Commands and Service Options. Create an ImportParser that implements SectionParser and handles the import 'section'. Clean up the unsafe memory handling of the Action class by using std::unique_ptr. Change-Id: Ic5ea5510cb956dbc3f78745a35096ca7d6da7085
2015-08-26 20:43:36 +02:00
BuiltinFunction func_;
init: run vendor commands in a separate SELinux context One of the major aspects of treble is the compartmentalization of system and vendor components, however init leaves a huge gap here, as vendor init scripts run in the same context as system init scripts and thus can access and modify the same properties, files, etc as the system can. This change is meant to close that gap. It forks a separate 'subcontext' init that runs in a different SELinux context with permissions that match what vendors should have access to. Commands get sent over a socket to this 'subcontext' init that then runs them in this SELinux context and returns the result. Note that not all commands run in the subcontext; some commands such as those dealing with services only make sense in the context of the main init process. Bug: 62875318 Test: init unit tests, boot bullhead, boot sailfish Change-Id: Idf4a4ebf98842d27b8627f901f961ab9eb412aee
2017-09-13 00:58:47 +02:00
bool execute_in_subcontext_;
init: Use classes for parsing and clean up memory allocations Create a Parser class that uses multiple SectionParser interfaces to handle parsing the different sections of an init rc. Create an ActionParser and ServiceParser that implement SectionParser and parse the sections corresponding to Action and Service classes. Remove the legacy keyword structure and replace it with std::map's that map keyword -> (minimum args, maximum args, function pointer) for Commands and Service Options. Create an ImportParser that implements SectionParser and handles the import 'section'. Clean up the unsafe memory handling of the Action class by using std::unique_ptr. Change-Id: Ic5ea5510cb956dbc3f78745a35096ca7d6da7085
2015-08-26 20:43:36 +02:00
std::vector<std::string> args_;
int line_;
};
init: rename 'Trigger' to 'Event' and convert to std::variant The term 'trigger' should be used in 'Action' to indicate what causes the 'Action' to be executed. The term 'event' should be used in ActionManager's queue to indicate a state change that is checked against the 'triggers' of an 'Action' to see if it should execute. Convert the previous Trigger class to std::variant, as the latter is better suited for this use. Change-Id: I2558367c8318b536aa69fcec93793f1c12857ef5
2017-04-17 22:25:29 +02:00
using EventTrigger = std::string;
using PropertyChange = std::pair<std::string, std::string>;
using BuiltinAction = class Action*;
init: Create classes for Action and Command This creates the concept of 'event_trigger' vs 'property_trigger' Previously these were merged into one, such that 'on property:a=b && property:b=c' is triggered when properties a=b and b=c as expected, however combinations such as 'on early-boot && boot' would trigger during both early-boot and boot. Similarly, 'on early-boot && property:a=b' would trigger on both early-boot and again when property a equals b. The event trigger distinction ensures that the first example fails to parse and the second example only triggers on early-boot if property a equals b. This coalesces Actions with the same triggers into a single Action object Change-Id: I8f661d96e8a2d40236f252301bfe10979d663ea6
2015-07-24 02:53:11 +02:00
class Action {
init: Stop combining actions In the past, I had thought it didn't make sense to have multiple Action classes with identical triggers within ActionManager::actions_, and opted to instead combine these into a single action. In theory, it should reduce memory overhead as only one copy of the triggers needs to be stored. In practice, this ends up not being a good idea. Most importantly, given a file with the below three sections in this same order: on boot setprop a b on boot && property:true=true setprop c d on boot setprop e f Assuming that property 'true' == 'true', when the `boot` event happens, the order of the setprop commands will actually be: setprop a b setprop e f setprop c d instead of the more intuitive order of: setprop a b setprop c d setprop e f This is a mistake and this CL fixes it. It also documents this order. Secondly, with a given 'Action' now spanning multiple files, in order to keep track of which file a command is run from, the 'Command' itself needs to store this. Ironically to the original intention, this increases total ram usage. This change now only stores the file name in each 'Action' instead of each 'Command'. All in all this is a negligible trade off of ram usage. Thirdly, this requires a bunch of extra code and assumptions that don't help anything else. In particular it forces to keep property triggers sorted for easy comparison, which I'm using an std::map for currently, but that is not the best data structure to contain them. Lastly, I added the filename and line number to the 'processing action' LOG(INFO) message. Test: Boot bullhead, observe above changes Test: Boot sailfish, observe no change in boot time Change-Id: I3fbcac4ee677351314e33012c758145be82346e9
2017-04-18 22:21:54 +02:00
public:
Move all Action parsing into ActionParser Bug: 36970783 Test: Build Change-Id: Iea2d97fb45c3e88bc83fb72d6fa67049be42cfa9
2018-02-14 01:24:51 +01:00
Action(bool oneshot, Subcontext* subcontext, const std::string& filename, int line,
const std::string& event_trigger,
const std::map<std::string, std::string>& property_triggers);
init: Stop combining actions In the past, I had thought it didn't make sense to have multiple Action classes with identical triggers within ActionManager::actions_, and opted to instead combine these into a single action. In theory, it should reduce memory overhead as only one copy of the triggers needs to be stored. In practice, this ends up not being a good idea. Most importantly, given a file with the below three sections in this same order: on boot setprop a b on boot && property:true=true setprop c d on boot setprop e f Assuming that property 'true' == 'true', when the `boot` event happens, the order of the setprop commands will actually be: setprop a b setprop e f setprop c d instead of the more intuitive order of: setprop a b setprop c d setprop e f This is a mistake and this CL fixes it. It also documents this order. Secondly, with a given 'Action' now spanning multiple files, in order to keep track of which file a command is run from, the 'Command' itself needs to store this. Ironically to the original intention, this increases total ram usage. This change now only stores the file name in each 'Action' instead of each 'Command'. All in all this is a negligible trade off of ram usage. Thirdly, this requires a bunch of extra code and assumptions that don't help anything else. In particular it forces to keep property triggers sorted for easy comparison, which I'm using an std::map for currently, but that is not the best data structure to contain them. Lastly, I added the filename and line number to the 'processing action' LOG(INFO) message. Test: Boot bullhead, observe above changes Test: Boot sailfish, observe no change in boot time Change-Id: I3fbcac4ee677351314e33012c758145be82346e9
2017-04-18 22:21:54 +02:00
init: replace Result<Success> with Result<void> Now that Result<T> is actually expected<T, ...>, and the expected proposal states expected<void, ...> as the way to indicate an expected object that returns either successfully with no object or an error, let's move init's Result<Success> to the preferred Result<void>. Bug: 132145659 Test: boot, init unit tests Change-Id: Ib2f98396d8e6e274f95a496fcdfd8341f77585ee
2019-06-10 20:08:01 +02:00
Result<void> AddCommand(std::vector<std::string>&& args, int line);
init: use rvalues references for callees of ParseLineSection() ParseLineSection() provides 'args' as an rvalue reference, so its callers can and should use it as such. This saves some copying overhead and cleans up the code a bit. Test: boot Change-Id: Ib906318583dc81de9ea585f5f09fdff35403be1b
2018-10-17 20:11:23 +02:00
void AddCommand(BuiltinFunction f, std::vector<std::string>&& args, int line);
init: check the arguments of builtins during the build Host init verifier already checks that the names and number of arguments for builtins are correct, but it can check more. This change ensures that property expansions are well formed, and that arguments that can be parsed on the host are correct. For example it checks that UIDs and GIDs exist, that numerical values can be parsed, and that rlimit strings are correct. Test: build Change-Id: Ied8882498a88a9f8324db6b8d1020aeeccc8177b
2019-07-30 18:34:41 +02:00
size_t NumCommands() const;
init: Create classes for Action and Command This creates the concept of 'event_trigger' vs 'property_trigger' Previously these were merged into one, such that 'on property:a=b && property:b=c' is triggered when properties a=b and b=c as expected, however combinations such as 'on early-boot && boot' would trigger during both early-boot and boot. Similarly, 'on early-boot && property:a=b' would trigger on both early-boot and again when property a equals b. The event trigger distinction ensures that the first example fails to parse and the second example only triggers on early-boot if property a equals b. This coalesces Actions with the same triggers into a single Action object Change-Id: I8f661d96e8a2d40236f252301bfe10979d663ea6
2015-07-24 02:53:11 +02:00
void ExecuteOneCommand(std::size_t command) const;
void ExecuteAllCommands() const;
init: rename 'Trigger' to 'Event' and convert to std::variant The term 'trigger' should be used in 'Action' to indicate what causes the 'Action' to be executed. The term 'event' should be used in ActionManager's queue to indicate a state change that is checked against the 'triggers' of an 'Action' to see if it should execute. Convert the previous Trigger class to std::variant, as the latter is better suited for this use. Change-Id: I2558367c8318b536aa69fcec93793f1c12857ef5
2017-04-17 22:25:29 +02:00
bool CheckEvent(const EventTrigger& event_trigger) const;
bool CheckEvent(const PropertyChange& property_change) const;
bool CheckEvent(const BuiltinAction& builtin_action) const;
init: Create classes for Action and Command This creates the concept of 'event_trigger' vs 'property_trigger' Previously these were merged into one, such that 'on property:a=b && property:b=c' is triggered when properties a=b and b=c as expected, however combinations such as 'on early-boot && boot' would trigger during both early-boot and boot. Similarly, 'on early-boot && property:a=b' would trigger on both early-boot and again when property a equals b. The event trigger distinction ensures that the first example fails to parse and the second example only triggers on early-boot if property a equals b. This coalesces Actions with the same triggers into a single Action object Change-Id: I8f661d96e8a2d40236f252301bfe10979d663ea6
2015-07-24 02:53:11 +02:00
std::string BuildTriggersString() const;
void DumpState() const;
init: check the arguments of builtins during the build Host init verifier already checks that the names and number of arguments for builtins are correct, but it can check more. This change ensures that property expansions are well formed, and that arguments that can be parsed on the host are correct. For example it checks that UIDs and GIDs exist, that numerical values can be parsed, and that rlimit strings are correct. Test: build Change-Id: Ied8882498a88a9f8324db6b8d1020aeeccc8177b
2019-07-30 18:34:41 +02:00
size_t CheckAllCommands() const;
init: Create classes for Action and Command This creates the concept of 'event_trigger' vs 'property_trigger' Previously these were merged into one, such that 'on property:a=b && property:b=c' is triggered when properties a=b and b=c as expected, however combinations such as 'on early-boot && boot' would trigger during both early-boot and boot. Similarly, 'on early-boot && property:a=b' would trigger on both early-boot and again when property a equals b. The event trigger distinction ensures that the first example fails to parse and the second example only triggers on early-boot if property a equals b. This coalesces Actions with the same triggers into a single Action object Change-Id: I8f661d96e8a2d40236f252301bfe10979d663ea6
2015-07-24 02:53:11 +02:00
init: Use classes for parsing and clean up memory allocations Create a Parser class that uses multiple SectionParser interfaces to handle parsing the different sections of an init rc. Create an ActionParser and ServiceParser that implement SectionParser and parse the sections corresponding to Action and Service classes. Remove the legacy keyword structure and replace it with std::map's that map keyword -> (minimum args, maximum args, function pointer) for Commands and Service Options. Create an ImportParser that implements SectionParser and handles the import 'section'. Clean up the unsafe memory handling of the Action class by using std::unique_ptr. Change-Id: Ic5ea5510cb956dbc3f78745a35096ca7d6da7085
2015-08-26 20:43:36 +02:00
bool oneshot() const { return oneshot_; }
init: Stop combining actions In the past, I had thought it didn't make sense to have multiple Action classes with identical triggers within ActionManager::actions_, and opted to instead combine these into a single action. In theory, it should reduce memory overhead as only one copy of the triggers needs to be stored. In practice, this ends up not being a good idea. Most importantly, given a file with the below three sections in this same order: on boot setprop a b on boot && property:true=true setprop c d on boot setprop e f Assuming that property 'true' == 'true', when the `boot` event happens, the order of the setprop commands will actually be: setprop a b setprop e f setprop c d instead of the more intuitive order of: setprop a b setprop c d setprop e f This is a mistake and this CL fixes it. It also documents this order. Secondly, with a given 'Action' now spanning multiple files, in order to keep track of which file a command is run from, the 'Command' itself needs to store this. Ironically to the original intention, this increases total ram usage. This change now only stores the file name in each 'Action' instead of each 'Command'. All in all this is a negligible trade off of ram usage. Thirdly, this requires a bunch of extra code and assumptions that don't help anything else. In particular it forces to keep property triggers sorted for easy comparison, which I'm using an std::map for currently, but that is not the best data structure to contain them. Lastly, I added the filename and line number to the 'processing action' LOG(INFO) message. Test: Boot bullhead, observe above changes Test: Boot sailfish, observe no change in boot time Change-Id: I3fbcac4ee677351314e33012c758145be82346e9
2017-04-18 22:21:54 +02:00
const std::string& filename() const { return filename_; }
int line() const { return line_; }
init: simplify keyword_map I've heard that keyword_map is too complex, in particular the tuple and the pair in BuiltinFunctionMap, so this change removes a lot of that complexity and, more importantly, better documents how all of this works. Test: boot, init unit tests Change-Id: I74e5f9de7f2ec524cb6127bb9da2956b5f307f56
2019-07-23 01:05:36 +02:00
static void set_function_map(const BuiltinFunctionMap* function_map) {
init: Use classes for parsing and clean up memory allocations Create a Parser class that uses multiple SectionParser interfaces to handle parsing the different sections of an init rc. Create an ActionParser and ServiceParser that implement SectionParser and parse the sections corresponding to Action and Service classes. Remove the legacy keyword structure and replace it with std::map's that map keyword -> (minimum args, maximum args, function pointer) for Commands and Service Options. Create an ImportParser that implements SectionParser and handles the import 'section'. Clean up the unsafe memory handling of the Action class by using std::unique_ptr. Change-Id: Ic5ea5510cb956dbc3f78745a35096ca7d6da7085
2015-08-26 20:43:36 +02:00
function_map_ = function_map;
}
init: Create classes for Action and Command This creates the concept of 'event_trigger' vs 'property_trigger' Previously these were merged into one, such that 'on property:a=b && property:b=c' is triggered when properties a=b and b=c as expected, however combinations such as 'on early-boot && boot' would trigger during both early-boot and boot. Similarly, 'on early-boot && property:a=b' would trigger on both early-boot and again when property a equals b. The event trigger distinction ensures that the first example fails to parse and the second example only triggers on early-boot if property a equals b. This coalesces Actions with the same triggers into a single Action object Change-Id: I8f661d96e8a2d40236f252301bfe10979d663ea6
2015-07-24 02:53:11 +02:00
init: run vendor commands in a separate SELinux context One of the major aspects of treble is the compartmentalization of system and vendor components, however init leaves a huge gap here, as vendor init scripts run in the same context as system init scripts and thus can access and modify the same properties, files, etc as the system can. This change is meant to close that gap. It forks a separate 'subcontext' init that runs in a different SELinux context with permissions that match what vendors should have access to. Commands get sent over a socket to this 'subcontext' init that then runs them in this SELinux context and returns the result. Note that not all commands run in the subcontext; some commands such as those dealing with services only make sense in the context of the main init process. Bug: 62875318 Test: init unit tests, boot bullhead, boot sailfish Change-Id: Idf4a4ebf98842d27b8627f901f961ab9eb412aee
2017-09-13 00:58:47 +02:00
private:
init: Create classes for Action and Command This creates the concept of 'event_trigger' vs 'property_trigger' Previously these were merged into one, such that 'on property:a=b && property:b=c' is triggered when properties a=b and b=c as expected, however combinations such as 'on early-boot && boot' would trigger during both early-boot and boot. Similarly, 'on early-boot && property:a=b' would trigger on both early-boot and again when property a equals b. The event trigger distinction ensures that the first example fails to parse and the second example only triggers on early-boot if property a equals b. This coalesces Actions with the same triggers into a single Action object Change-Id: I8f661d96e8a2d40236f252301bfe10979d663ea6
2015-07-24 02:53:11 +02:00
void ExecuteCommand(const Command& command) const;
bool CheckPropertyTriggers(const std::string& name = "",
const std::string& value = "") const;
std::map<std::string, std::string> property_triggers_;
std::string event_trigger_;
init: Use classes for parsing and clean up memory allocations Create a Parser class that uses multiple SectionParser interfaces to handle parsing the different sections of an init rc. Create an ActionParser and ServiceParser that implement SectionParser and parse the sections corresponding to Action and Service classes. Remove the legacy keyword structure and replace it with std::map's that map keyword -> (minimum args, maximum args, function pointer) for Commands and Service Options. Create an ImportParser that implements SectionParser and handles the import 'section'. Clean up the unsafe memory handling of the Action class by using std::unique_ptr. Change-Id: Ic5ea5510cb956dbc3f78745a35096ca7d6da7085
2015-08-26 20:43:36 +02:00
std::vector<Command> commands_;
bool oneshot_;
init: run vendor commands in a separate SELinux context One of the major aspects of treble is the compartmentalization of system and vendor components, however init leaves a huge gap here, as vendor init scripts run in the same context as system init scripts and thus can access and modify the same properties, files, etc as the system can. This change is meant to close that gap. It forks a separate 'subcontext' init that runs in a different SELinux context with permissions that match what vendors should have access to. Commands get sent over a socket to this 'subcontext' init that then runs them in this SELinux context and returns the result. Note that not all commands run in the subcontext; some commands such as those dealing with services only make sense in the context of the main init process. Bug: 62875318 Test: init unit tests, boot bullhead, boot sailfish Change-Id: Idf4a4ebf98842d27b8627f901f961ab9eb412aee
2017-09-13 00:58:47 +02:00
Subcontext* subcontext_;
init: Stop combining actions In the past, I had thought it didn't make sense to have multiple Action classes with identical triggers within ActionManager::actions_, and opted to instead combine these into a single action. In theory, it should reduce memory overhead as only one copy of the triggers needs to be stored. In practice, this ends up not being a good idea. Most importantly, given a file with the below three sections in this same order: on boot setprop a b on boot && property:true=true setprop c d on boot setprop e f Assuming that property 'true' == 'true', when the `boot` event happens, the order of the setprop commands will actually be: setprop a b setprop e f setprop c d instead of the more intuitive order of: setprop a b setprop c d setprop e f This is a mistake and this CL fixes it. It also documents this order. Secondly, with a given 'Action' now spanning multiple files, in order to keep track of which file a command is run from, the 'Command' itself needs to store this. Ironically to the original intention, this increases total ram usage. This change now only stores the file name in each 'Action' instead of each 'Command'. All in all this is a negligible trade off of ram usage. Thirdly, this requires a bunch of extra code and assumptions that don't help anything else. In particular it forces to keep property triggers sorted for easy comparison, which I'm using an std::map for currently, but that is not the best data structure to contain them. Lastly, I added the filename and line number to the 'processing action' LOG(INFO) message. Test: Boot bullhead, observe above changes Test: Boot sailfish, observe no change in boot time Change-Id: I3fbcac4ee677351314e33012c758145be82346e9
2017-04-18 22:21:54 +02:00
std::string filename_;
int line_;
init: simplify keyword_map I've heard that keyword_map is too complex, in particular the tuple and the pair in BuiltinFunctionMap, so this change removes a lot of that complexity and, more importantly, better documents how all of this works. Test: boot, init unit tests Change-Id: I74e5f9de7f2ec524cb6127bb9da2956b5f307f56
2019-07-23 01:05:36 +02:00
static const BuiltinFunctionMap* function_map_;
init: Create classes for Action and Command This creates the concept of 'event_trigger' vs 'property_trigger' Previously these were merged into one, such that 'on property:a=b && property:b=c' is triggered when properties a=b and b=c as expected, however combinations such as 'on early-boot && boot' would trigger during both early-boot and boot. Similarly, 'on early-boot && property:a=b' would trigger on both early-boot and again when property a equals b. The event trigger distinction ensures that the first example fails to parse and the second example only triggers on early-boot if property a equals b. This coalesces Actions with the same triggers into a single Action object Change-Id: I8f661d96e8a2d40236f252301bfe10979d663ea6
2015-07-24 02:53:11 +02:00
};
init: create android::init:: namespace With some small fixups along the way Test: Boot bullhead Test: init unit tests Change-Id: I7beaa473cfa9397f845f810557d1631b4a462d6a
2017-06-22 21:53:17 +02:00
} // namespace init
} // namespace android
Reference in a new issue Copy permalink