Chromium Chronicle nr 15: ograniczanie widoczności docelowej

Odcinek 15: Joe Mason z Montrealu, PQ (listopad 2020 r.)
Poprzednie odcinki

Chrome to duży projekt z wieloma podsystemami. Kod jest często dla jednego komponentu, który byłby przydatny w innym miejscu, ale mógł być ukryty ograniczeń. Ze względów bezpieczeństwa ogranicz dostęp z zewnątrz do niebezpiecznych funkcji. Na przykład funkcja niestandardowa dostosowana do konkretnych potrzeb w zakresie wydajności:

// Blazing fast for 2-char strings, O(n^3) otherwise.
std
::string ConcatShortStringsFast(const std::string& a, const std::string& b);

Istnieje kilka sposobów na ograniczenie dostępu. Kod stopera w regułach widoczności GN poza komponentem w zależności od elementu docelowego. Domyślnie cele to widoczne dla wszystkich, ale możesz to zmienić:

# In components/restricted_component/BUILD.gn
visibility
= [
 
# Applies to all targets in this file.
 
# Only the given targets can depend on them.
 
"//components/restricted_component:*",
 
"//components/authorized_other_component:a_single_target",
]
source_set
("internal") {
 
# This dangerous target should be locked down even more.
  visibility
= [ "//components/restricted_component:privileged_target" ]
}

Deklaracje dotyczące widoczności są weryfikowane za pomocą usługi gn check, która jest częścią każdej kompilacji GN.

Innym mechanizmem jest DEPS include_rules, który ogranicza dostęp do plików nagłówka. Każdy katalog dziedziczy wartość include_rules ze swojego elementu nadrzędnego i może je modyfikować w osobnym pliku DEPS. Wszystkie pliki nagłówka uwzględnione spoza domeny include_rules musi zezwalać na katalogi.

# In //components/authorized_other_component/DEPS
include_rules
= [
 
# Common directories like //base are inherited from
 
# //components/DEPS or //DEPS. Also allow includes from
 
# restricted_component, but not restricted_component/internal.
 
"+components/restricted_component",
 
"-components/restricted_component/internal",
 
# But do allow a single header from internal, for testing.
 
"+components/restricted_component/internal/test_support.h",
]

Aby mieć pewność, że te zależności są odpowiednie, zmiany powodujące dodanie katalogu do include_rules musi zostać zatwierdzona przez OWNERS tego katalogu. Nie wymagane jest zatwierdzenie do ograniczenia katalogu za pomocą atrybutu include_rules! Dostępne opcje Upewnij się, że wszyscy, którzy zmieniają komponent, pamiętają, by nie używać określonych nagłówków przez dodanie zabronionego atrybutu include_rule.

include_rules są sprawdzane przez funkcję przesyłania wstępnego, więc nie zobaczysz żadnych dopóki nie spróbujesz przesłać zmiany. Aby przetestować aplikację include_rules bez przesyłanie, uruchom buildtools/checkdeps/checkdeps.py <directory>.

Zasoby