dbus-daemon - מקוון בענן

תָכְנִית:

שֵׁם

dbus-daemon - דמון אוטובוס מסרים

תַקצִיר

dbus-daemon

dbus-daemon [--version] [--session] [--system] [--config-file=קובץ]
[--כתובת הדפסה [=מתאר]] [--print-pid [=מתאר]] [--מזלג]

תיאור

dbus-daemon הוא דמון אוטובוס ההודעות של D-Bus. לִרְאוֹת http://www.freedesktop.org/software/dbus/
למידע נוסף על התמונה הגדולה. D-Bus היא ראשית ספרייה המספקת
תקשורת אחד לאחד בין כל שני יישומים; dbus-daemon היא אפליקציה ש
משתמש בספרייה זו כדי ליישם דמון אוטובוס הודעות. תוכניות מרובות מתחברות ל-
דמון אוטובוס הודעות ויכולים להחליף הודעות אחד עם השני.

ישנם שני מופעי אפיק הודעות סטנדרטיים: אפיק ההודעות בכל המערכת (מותקן על
מערכות רבות כמו שירות init "messagebus") ואפיק ההודעות לכל משתמש-כניסה-סשן
(התחיל בכל פעם שמשתמש מתחבר). dbus-daemon משמש עבור שני המקרים הללו, אבל
עם קובץ תצורה אחר.

האפשרות --session מקבילה ל"--config-file=/usr/share/dbus-1/session.conf"ו
האפשרות --system מקבילה ל-"--config-file=/usr/share/dbus-1/system.conf". על ידי
יצירת קובצי תצורה נוספים ושימוש באפשרות --config-file, נוסף
ניתן ליצור דמוני אפיק הודעות למטרות מיוחדות.

הדמון כלל המערכת מופעל בדרך כלל על ידי סקריפט init, הנקרא בדרך כלל בפשטות
"אוטובוס הודעות".

הדמון כלל המערכת משמש בעיקר לשידור אירועי מערכת, כגון שינויים ב
תור המדפסת, או הוספה/הסרה של התקנים.

הדמון לכל הפעלה משמש לתקשורת בין תהליכים שונים בין שולחן העבודה
יישומים (עם זאת, הוא אינו קשור ל-X או ל-GUI בשום אופן).

SIGHUP יגרום לדמון D-Bus לטעון מחדש באופן חלקי את קובץ התצורה שלו ולשטוף
מטמון המידע של המשתמש/הקבוצה שלו. שינויים מסוימים בתצורה ידרשו לבעוט הכל
אפליקציות מחוץ לאוטובוס; אז הם ייכנסו לתוקף רק אם תפעיל מחדש את הדמון. שינויים במדיניות
אמור להיכנס לתוקף עם SIGHUP.

אפשרויות

האפשרויות הבאות נתמכות:

--config-file=FILE
השתמש בקובץ התצורה הנתון.

--מזלג
הכריח את אפיק ההודעות להתפצל ולהפוך לדמון, גם אם קובץ התצורה עושה זאת
לא לציין שצריך. ברוב ההקשרים קובץ התצורה כבר מקבל את זה
נכון, אבל. אפשרות זו אינה נתמכת ב-Windows.

--nofork
הכריח את אפיק ההודעות לא להתפצל ולהפוך לדמון, גם אם קובץ התצורה
מפרט שצריך. ב-Windows, ה-dbus-daemon אף פעם לא מתפצל, אז אפשרות זו היא
מותר אבל לא עושה כלום.

--כתובת הדפסה[=DESCRIPTOR]
הדפס את הכתובת של אפיק ההודעות לפלט סטנדרטי, או לקובץ הנתון
מתאר. זה משמש על ידי תוכניות שמפעילות את אפיק ההודעות.

--print-pid[=DESCRIPTOR]
הדפס את מזהה התהליך של אפיק ההודעות לפלט סטנדרטי, או לקובץ הנתון
מתאר. זה משמש על ידי תוכניות שמפעילות את אפיק ההודעות.

--מוֹשָׁב
השתמש בקובץ התצורה הסטנדרטי עבור אפיק ההודעות לכל הפעלה.

--מערכת
השתמש בקובץ התצורה הסטנדרטי עבור אפיק ההודעות בכל המערכת.

--גִרְסָה
הדפס את הגרסה של הדמון.

--התבוננות פנימית
הדפס את מידע ההתבוננות הפנימית עבור כל הממשקים הפנימיים של D-Bus.

--כתובת[=כתובת]
הגדר את הכתובת להאזנה. אפשרות זו עוקפת את הכתובת שהוגדרה ב-
קובץ תצורה.

--מערכת הפעלה
אפשר הפעלת שירות בסגנון systemd. שימושי רק בשילוב עם systemd
מנהל מערכת והפעלה בלינוקס.

--nopidfile
אל תכתוב קובץ PID גם אם הוא מוגדר בקבצי התצורה.

תְצוּרָה קובץ

לדמון של אוטובוס הודעות יש קובץ תצורה שמתמחה אותו בפרט מסוים
יישום. לדוגמה, קובץ תצורה אחד עשוי להגדיר את אפיק ההודעות להיות א
אפיק הודעות כלל-מערכתי, בעוד שאחר עשוי להגדיר אותו להיות אפיק לכל משתמש-כניסה-סשן.

קובץ התצורה גם קובע מגבלות משאבים, פרמטרי אבטחה וכדומה
קדימה.

קובץ התצורה אינו חלק מכל מפרט יכולת פעולה הדדית והיפוך שלו
התאימות אינה מובטחת; מסמך זה הוא תיעוד, לא מפרט.

ההגדרות הסטנדרטיות של אפיק ההודעות הכוללות את המערכת והכל הפעלה מוגדרות בקבצים
"/usr/share/dbus-1/system.conf"ו"/usr/share/dbus-1/session.conf". הקבצים האלה בדרך כלל
a system-local.conf או session-local.conf in /etc/dbus-1; אתה יכול לשים מקומי
עוקף בקבצים אלה כדי להימנע משינוי קבצי התצורה הראשיים.

קובץ התצורה הוא מסמך XML. עליו לכלול את הצהרת ה-doctype הבאה:

<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">

הרכיבים הבאים עשויים להיות קיימים בקובץ התצורה.

·

אלמנט שורש.

·

הסוג הידוע של אפיק המסרים. הערכים המוכרים כיום הם "מערכת" ו"סשן";
אם מוגדרים ערכים אחרים, יש להוסיף אותם למפרט D-Bus, או
מרווח שמות. האחרון אלמנט "מנצח" (מתעלמים מהערכים הקודמים). האלמנט הזה
שולט רק באילו משתני סביבה ספציפיים באפיק הודעות מוגדרים מופעלים
לקוחות. רוב המדיניות שמבדילה בין אפיק הפעלה מאפיק המערכת היא
נשלט משאר האלמנטים בקובץ התצורה.

אם הסוג הידוע של אפיק ההודעות הוא "הפעלה", אז ה-DBUS_STARTER_BUS_TYPE
משתנה הסביבה יוגדר ל-"session" וסביבת DBUS_SESSION_BUS_ADDRESS
המשתנה יוגדר לכתובת של אוטובוס הפגישה. כמו כן, אם סוג ה-
אוטובוס ההודעות הוא "מערכת", ואז משתנה הסביבה DBUS_STARTER_BUS_TYPE יוגדר
ל-"system" ומשתנה הסביבה DBUS_SESSION_BUS_ADDRESS יוגדר ל-
כתובת של אפיק המערכת (שבדרך כלל ידוע בכל מקרה).

דוגמא: מוֹשָׁב

·

כלול קובץ filename.conf בנקודה זו. אם שם הקובץ הוא
relative, הוא ממוקם יחסית לקובץ התצורה שעושה את הכליל.

יש לו תכונה אופציונלית "ignore_missing=(yes|no)" שברירת המחדל היא "לא" אם
לא מסופק. תכונה זו קובעת אם מדובר בשגיאה קטלנית עבור הקובץ הכלול
לְהֵעָדֵר.

·

כלול את כל הקבצים ב מזון בנקודה זו. קבצים בספרייה
כלולים בסדר לא מוגדר. רק קבצים המסתיימים ב-".conf" כלולים.

זה נועד לאפשר הרחבה של אפיק המערכת על ידי חבילות מסוימות. לדוגמה,
אם CUPS רוצה להיות מסוגל לשלוח הודעה על שינויים בתור המדפסת, זה יכול
התקן קובץ ב-/usr/share/dbus-1/system.d or /etc/dbus-1/system.d שאפשרה את כל האפליקציות
לקבל הודעה זו ואיפשר למשתמש הדמון של המדפסת לשלוח אותה.

·

חשבון המשתמש שבו הדמון צריך לפעול, בתור שם משתמש או כ-UID. אם הדמון
לא יכול לשנות ל-UID זה בעת ההפעלה, הוא ייצא. אם אלמנט זה אינו קיים, ה-
daemon לא ישתנה או אכפת לו מה-UID שלו.

האחרון כניסה בקובץ "מנצח", מתעלמים מהאחרים.

המשתמש משתנה לאחר שהאוטובוס סיים אתחול. אז שקעים וכו' יהיו
נוצר לפני החלפת משתמש, אך לא ייקרא נתונים מלקוחות לפני החלפת משתמש.
המשמעות היא שניתן ליצור שקעים וקבצי PID במיקום הדורש שורש
הרשאות לכתיבה.

·

אם קיים, דמון האוטובוס הופך לדמון אמיתי (מתפצל ברקע וכו'). זֶה
משמש בדרך כלל במקום אפשרות שורת הפקודה --fork.

·

אם קיים, דמון האוטובוס שומר על ה-umask המקורי שלו כאשר מתפצל. זה עשוי להיות שימושי עבור
להימנע מהשפעה על התנהגותם של תהליכי הילד.

·

אם קיים, דמון האוטובוס ייכנס ל-syslog.

·

אם קיים, הדמון של האוטובוס יכתוב את ה-Pid שלו לקובץ שצוין. קובץ --nopid
אפשרות שורת הפקודה עדיפה על הגדרה זו.

·

אם קיימים, חיבורים שאומתו באמצעות מנגנון ANONYMOUS יהיו
מורשה להתחבר. לאפשרות זו אין השפעה מעשית אלא אם כן המנגנון ANONYMOUS
הופעל גם באמצעות אלמנט, המתואר להלן.

·

הוסף כתובת שהאוטובוס צריך להאזין בה. הכתובת היא בפורמט D-Bus סטנדרטי
שמכיל שם תחבורה בתוספת פרמטרים/אפשרויות אפשריות.

דוגמא: unix:path=/tmp/foo

דוגמא: tcp:host=localhost,port=1234

אם יש מרובים אלמנטים, ואז האוטובוס מאזין במספר כתובות. ה
אוטובוס יעביר את כתובתו לשירותים שהתחילו או לבעלי עניין אחרים עם האחרון
כתובת שצוינה ב ראשון. כלומר, אפליקציות ינסו להתחבר לאחרון
כתובת ראשונה.

שקעי tcp יכולים לקבל כתובות IPv4, כתובות IPv6 או שמות מארח. אם שם מארח נפתר
למספר כתובות, השרת יקשר לכולן. המשפחה=ipv4 או family=ipv6
ניתן להשתמש באפשרויות כדי לאלץ אותו להיקשר לקבוצת משנה של כתובות

דוגמא: tcp:host=localhost,port=0,family=ipv4

מקרה מיוחד הוא שימוש במספר יציאה של אפס (או השמטת היציאה), כלומר ל
בחר יציאה זמינה שנבחרה על ידי מערכת ההפעלה. מספר היציאה שנבחר יכול להיות
התקבל עם פרמטר שורת הפקודה --print-address ויהיה קיים באחר
מקרים שבהם השרת מדווח על כתובת משלו, כגון כאשר DBUS_SESSION_BUS_ADDRESS הוא
להגדיר.

דוגמא: tcp:host=localhost,port=0

כתובות tcp/nonce-tcp מאפשרות גם אפשרות bind=hostname, המשמשת בכתובת הניתנת להאזנה ל
הגדר את הממשק שבו השרת יקשיב: או ששם המארח הוא ה-IP
כתובת של אחד מהממשקים של המחשב המקומי (בדרך כלל 127.0.0.1), שם DNS
שפותר לאחת מכתובות ה-IP הללו, '0.0.0.0' כדי להאזין בכל ממשקי ה-IPv4
בו-זמנית, או '::' כדי להאזין בכל ממשקי IPv4 ו-IPv6 בו-זמנית (אם
נתמך על ידי מערכת ההפעלה). אם לא צוין, ברירת המחדל היא אותו ערך כמו "מארח".

דוגמא: tcp:host=localhost,bind=0.0.0.0,port=0

·

מפרט מנגנוני הרשאה מותרים. אם האלמנט הזה לא קיים, אז הכל ידוע
מנגנונים מותרים. אם יש מרובים אלמנטים, כל המנגנונים המפורטים
מורשים. הסדר שבו רשומים מנגנונים אינו משמעותי.

דוגמא: חיצוני

דוגמא: DBUS_COOKIE_SHA1

·

מוסיף ספרייה לסריקה לאיתור קבצי שירות. ספריות נסרקות החל מה-
הראשון להופיע בקובץ התצורה (קובץ ה-.service הראשון שנמצא המספק א
ייעשה שימוש בשירות מסוים).

קבצי שירות אומרים לאוטובוס כיצד להפעיל תוכנית אוטומטית. הם משמשים בעיקר
עם האפיק לכל הפעלה, לא באפיק כלל המערכת.

·

שווה לציון סדרה של
אלמנטים עבור כל אחת מספריות הנתונים ב-"XDG Base Directory Specification" עם
ספריית המשנה "dbus-1/services", כך למשל "/usr/share/dbus-1/services" יהיה
בין המדריכים שחיפשו.

ניתן למצוא את "מפרט XDG Base Directory" בכתובת
http://freedesktop.org/wiki/Standards/basedir-spec אם הוא לא זז, אחרת נסה את שלך
מנוע החיפוש המועדף.

ה האפשרות רלוונטית רק לאפיק לכל הפעלה
daemon שהוגדר ב-/etc/dbus-1/session.conf. מכניס אותו לכל קובץ תצורה אחר
זה כנראה יהיה שטויות.

·

מפרט את ספריות ההפעלה הסטנדרטיות בכל המערכת
יש לחפש קבצי שירות. ברירת המחדל של אפשרות זו היא
/usr/share/dbus-1/system-services.

ה האפשרות רלוונטית רק לדמון האוטובוס לכל מערכת
מוגדר ב-/usr/share/dbus-1/system.conf. הכנסת אותו לכל קובץ תצורה אחר יעשה זאת
כנראה שטויות.

·

מציין את עוזר ה-setuid המשמש להפעלת דמוני מערכת עם an
משתמש חלופי. בדרך כלל זה צריך להיות קובץ ההפעלה dbus-daemon-launch-helper ב
ממוקם בליבקסק.

ה האפשרות רלוונטית רק לדמון האוטובוס לכל מערכת המוגדר ב
/usr/share/dbus-1/system.conf. לשים אותו בכל קובץ תצורה אחר כנראה
להיות שטויות.

·

קובע מגבלת משאבים. לדוגמה:

64
512

תכונת השם היא חובה. שמות הגבלה זמינים הם:

"max_incoming_bytes" : גודל כולל בבתים של הודעות
נכנס מחיבור יחיד
"max_incoming_unix_fds" : המספר הכולל של הודעות Unix Fds
נכנס מחיבור יחיד
"max_outgoing_bytes" : גודל כולל בבתים של הודעות
בתור לחיבור בודד
"max_outgoing_unix_fds" : המספר הכולל של הודעות Unix Fds
בתור לחיבור בודד
"max_message_size" : גודל מקסימלי של הודעה בודדת ב
בתים
"max_message_unix_fds": מקסימום unix fds של הודעה בודדת
"service_start_timeout" : אלפיות שנייה (אלפיות) עד
שירות שהתחיל צריך להתחבר
"auth_timeout" : אלפיות השנייה (אלפיות) א
ניתן חיבור ל
לאמת
"pending_fd_timeout" : אלפיות שנייה (אלפיות) א
fd ניתן לשידור אליו
dbus-daemon לפני ניתוק ה-
הקשר
"max_completed_connections" : מספר מקסימלי של חיבורים מאומתים
"max_incomplete_connections" : מספר מקסימלי של לא מאומתים
חיבורים
"max_connections_per_user" : מספר מקסימלי של חיבורים שהושלמו מ
אותו משתמש
"max_pending_service_starts" : המספר המרבי של השקות שירות ב
להתקדם בו זמנית
"max_names_per_connection" : מספר מקסימלי של שמות ליחיד
חיבור יכול להיות בעלים
"max_match_rules_per_connection": המספר המקסימלי של כללי התאמה ליחיד
הקשר
"max_replies_per_connection" : המספר המרבי של השיטה הממתינה
תשובות לכל חיבור
(מספר השיחות המתנהלות)
"reply_timeout" : אלפיות שנייה (אלפיות)
עד פסק זמן של קריאת שיטה

הגדלים המקסימליים של תור נכנס/יוצא מאפשרים הודעה חדשה בתור אם נשאר בייט אחד
מתחת למקסימום אז למעשה אתה יכול לחרוג מהמקסימום ב-max_message_size.

max_completed_connections חלקי max_connections_per_user הוא מספר המשתמשים
יכולים לעבוד יחד למניעת שירות של כל שאר המשתמשים על ידי שימוש בכל החיבורים ב-
אוטובוס כלל מערכתי.

מגבלות הן בדרך כלל מעניינות רק באפיק כלל המערכת, לא באפיקי הפגישות של המשתמש.

·

ה אלמנט מגדיר מדיניות אבטחה שיש להחיל על קבוצה מסוימת של
חיבורים לאוטובוס. מדיניות מורכבת ו אלמנטים. מדיניות כן
משמש בדרך כלל עם האוטובוס כולו; הם דומים לחומת אש בכך שהם מאפשרים
תנועה צפויה ולמנוע תנועה בלתי צפויה.

נכון לעכשיו, לאפיק המערכת יש מדיניות דחיית ברירת מחדל לשליחת קריאות לשיטה ולבעלות
שמות אוטובוסים. לכל השאר, בפרט הודעות תשובה, קבלת צ'קים ואותות יש
ברירת מחדל של מדיניות היתר.

באופן כללי, עדיף לשמור על שירותי מערכת כתוכניות קטנות וממוקדות הפועלות פנימה
תהליך משלהם ולספק שם אוטובוס בודד. לאחר מכן, כל מה שצריך זה
כלל להרשאה "שלו" לתת לתהליך לתבוע את שם האוטובוס, וכן א
כלל "send_destination" כדי לאפשר תעבורה מחלק או מכל ה-uids לשירות שלך.

ה לאלמנט יש אחת מארבע תכונות:

context="(ברירת מחדל|חובה)"
at_console="(true|false)"
user="username or userid"
group="שם קבוצה או גיד"

המדיניות מוחלת על חיבור באופן הבא:

- כל המדיניות של context="default" מוחלת
- כל מדיניות group="קבוצת המשתמש של Connection" מוחלת
בסדר לא מוגדר
- כל המדיניות של user="connection's auth user" מוחלת
בסדר לא מוגדר
- כל מדיניות at_console="true" מוחלת
- כל מדיניות at_console="false" מוחלת
- כל מדיניות ההקשר="חובה" חלה

מדיניות שיושמה מאוחר יותר תעקוף את אלו שהוחלו קודם לכן, כאשר המדיניות חופפת.
מספר מדיניות עם אותו משתמש/קבוצה/הקשר מוחלים בסדר שבו הם מופיעים
קובץ התצורה.




א אלמנט מופיע מתחת ל-a אלמנט ואוסר על פעולה כלשהי. ה
אלמנט עושה חריגה מהקודם הצהרות, ועובד בדיוק כמו אבל
עם המשמעות ההפוכה.

התכונות האפשריות של אלמנטים אלה הם:

send_interface="interface_name"
send_member="method_or_signal_name"
send_error="שם_שגיאה"
send_destination="name"
send_type="method_call" | "שיטת_החזרה" | "אות" | "שְׁגִיאָה"
send_path="/path/name"

receive_interface="interface_name"
receive_member="method_or_signal_name"
receive_error="שם_שגיאה"
receive_sender="name"
receive_type="method_call" | "שיטת_החזרה" | "אות" | "שְׁגִיאָה"
receive_path="/path/name"

send_requested_reply="true" | "שֶׁקֶר"
receive_requested_reply="true" | "שֶׁקֶר"

eavesdrop="true" | "שֶׁקֶר"

own="name"
own_prefix="name"
user="שם משתמש"
group="groupname"

דוגמאות:







ה התכונות של האלמנט קובעות אם ההכחשה "תואמת" פעולה מסוימת.
אם זה תואם, הפעולה נדחית (אלא אם כללים מאוחרים יותר בקובץ התצורה מאפשרים זאת).

כללי send_destination ו-receiver_sender פירושם שלא ניתן לשלוח הודעות אל או
התקבלו מה*בעלים* של השם הפרטי, לא שאסור לשלוח אותם *לשם זה*.
כלומר, אם לחיבור יש שירותים A, B, C, ושליחה ל-A נדחתה, שליחה ל-B
או C גם לא יעבוד.

שאר התכונות send_* ו-receive_* הן התאמות טקסטואליות/לפי ערך בלבד מול ה
שדה נתון בכותרת ההודעה.

"האזנת סתר" מתרחשת כאשר אפליקציה מקבלת הודעה שהייתה מפורשת
מופנה לשם שהאפליקציה אינה בבעלותו, או מהווה תשובה להודעה כזו.
האזנת סתר חלה אפוא רק על הודעות הממוענות לשירותים ולתשובות
הודעות כאלה (כלומר זה לא חל על אותות).

ל , eavesdrop="true" מציין שהכלל תואם גם בעת האזנה.
eavesdrop="false" הוא ברירת המחדל ומשמעות הדבר היא שהכלל מאפשר לעבור רק להודעות
הנמען שצוין. ל , eavesdrop="true" מציין שהכלל תואם
רק בעת האזנה. eavesdrop="false" הוא ברירת המחדל עבור גם, אבל הנה זה
פירושו שהכלל תקף תמיד, גם כשלא מצותתים. תכונת האזנת סתר
ניתן לשלב רק עם כללי שליחה וקבלה (עם תכונות send_* ו-receive_*).

התכונה [send|receive]_requested_reply פועלת בדומה לתכונת האזנה.
זה שולט אם ה אוֹ תואם תשובה שצפויה (מתאים ל
הודעת שיחת שיטה קודמת). התכונה הזו הגיונית רק עבור הודעות תשובה
(שגיאות ושיטה חוזרת), ומתעלמים ממנה עבור סוגי הודעות אחרים.

ל , [send|receive]_requested_reply="true" היא ברירת המחדל ומציינת שרק
התשובות המבוקשות מותרות על פי הכלל. [שלח|קבל]_requested_reply="false" פירושו
שהכלל מאפשר כל תשובה גם אם לא צפויה.

ל , [send|receive]_requested_reply="false" הוא ברירת המחדל אך מציין כי
הכלל תואם רק כאשר התשובה לא התבקשה. [שלח|קבל]_requested_reply="true"
מציין שהכלל חל תמיד, ללא קשר למצב תשובה ממתין.

הכחשות משתמשים וקבוצות אומרות שהמשתמש או הקבוצה הנתונים לא יתחברו להודעה
אוֹטוֹבּוּס.

עבור "שם", "שם משתמש", "שם קבוצה" וכו' ניתן להחליף את התו "*", כלומר
"כל." גלובס מורכבים כמו "foo.bar.*" אינם מותרים לעת עתה, כי הם מתאימים לעבודה
ליישם ואולי לעודד אבטחה מרושלת בכל מקרה.

מאפשר לך להיות הבעלים של השם "ab" או כל שם שהשם הראשון שלו
אלמנטים מופרדים בין נקודות הם "ab": בפרט, אתה יכול להיות הבעלים של "abc" או "abcd", אך לא
"a.bc" או "ac". זה שימושי כאשר שירותים כמו Telepathy ו-ReserveDevice מגדירים א
משמעות עבור תת-עצים של שמות ידועים, כגון
org.freedesktop.Telepathy.ConnectionManager.(כל דבר) ו
org.freedesktop.ReserveDevice1.(כל דבר).

זה לא הגיוני לדחות משתמש או קבוצה בתוך a עבור משתמש או קבוצה;
הכחשות משתמש/קבוצה יכולות להיות רק בתוך מדיניות context="default" או context="mandatory".

בודד הכלל עשוי לציין שילובים של תכונות כגון send_destination ו
send_interface ו- send_type. במקרה זה, ההכחשה חלה רק אם שתי התכונות
להתאים להודעה שנדחתה. לְמָשָׁל
send_destination="foo.blah"/> ימנע הודעות עם הממשק הנתון והנתון
שם אוטובוס. כדי לקבל אפקט OR אתה מציין מרובה כללים.

אינך יכול לכלול גם תכונות send_ ו-receive_ באותו כלל, שכן "אם ה
ניתן לשלוח הודעה" ו"האם ניתן לקבל אותה" מוערכים בנפרד.

היזהר עם send_interface/receive_interface, כי שדה הממשק בהודעות
הוא אופציונלי. בפרט, אל תפרט ! זה יהיה
לגרום לחסימת הודעות ללא ממשק עבור כל השירותים, וזה כמעט בוודאות שלא
למה התכוונת. השתמש תמיד בכללי הטופס:
send_destination="org.foo.Service"/>

·

ה הרכיב מכיל הגדרות הקשורות לאבטחה משופרת לינוקס. פרטים נוספים
לְהַלָן.

·

א אלמנט מופיע מתחת ל-an אלמנט ויוצר מיפוי. עכשיו
רק סוג אחד של שיוך אפשרי:



משמעות הדבר היא שאם חיבור מבקש לקבל את השם "org.freedesktop.Foobar", אז
הקשר המקור יהיה ההקשר של החיבור והקשר היעד יהיה
"foo_t" - ראה את הדיון הקצר על SELinux למטה.

שימו לב, ההקשר כאן הוא הקשר היעד כאשר מבקשים שם, לא ההקשר של
הקשר בעל השם.

כרגע אין דרך להגדיר ברירת מחדל לבעלות על שם כלשהו, ​​אם נוסיף את התחביר הזה
ייראה כמו:



אם אתה מוצא סיבה שזה שימושי, הודע למפתחים. כרגע ברירת המחדל תהיה
להיות ההקשר הביטחוני של האוטובוס עצמו.

אם שניים אלמנטים מציינים את אותו שם, האלמנט מופיע מאוחר יותר ב-
ייעשה שימוש בקובץ התצורה.

·

ה הרכיב משמש להגדרת תיווך AppArmor באוטובוס. זה יכול להכיל
תכונה אחת שמציינת את מצב הגישור:



מצב ברירת המחדל הוא "מופעל". במצב "מופעל", תיווך AppArmor יבוצע אם
תמיכה ב-AppArmor זמינה בליבה. אם זה לא זמין, dbus-daemon יהיה
התחל אך תיווך AppArmor לא יתרחש. במצב "מושבת", תיווך AppArmor הוא
נָכֶה. במצב "נדרש", תיווך AppArmor יופעל אם קיימת תמיכה ב-AppArmor
זמין, אחרת dbus-daemon יסרב להתחיל.

לא ניתן לשנות את מצב התיווך AppArmor של האוטובוס לאחר שהאוטובוס מתחיל. משנה
המצב בקובץ התצורה ושליחת אות SIGHUP לדמון אין השפעה
על מצב הגישור.

SELINUX

לִרְאוֹת http://www.nsa.gov/selinux/ לפרטים מלאים על SELinux. כמה קטעים שימושיים:

כל נושא (תהליך) ואובייקט (למשל קובץ, שקע, אובייקט IPC וכו') במערכת הוא
הוקצו אוסף של תכונות אבטחה, המכונה הקשר אבטחה. אבטחה
ההקשר מכיל את כל תכונות האבטחה הקשורות לנושא מסוים או
אובייקט הרלוונטי למדיניות האבטחה.

על מנת לכלול טוב יותר הקשרי אבטחה וכדי לספק יעילות רבה יותר, ה
קוד אכיפת מדיניות של SELinux מטפל בדרך כלל במזהי אבטחה (SIDs) במקום זאת
מאשר הקשרים ביטחוניים. SID הוא מספר שלם שמופה על ידי שרת האבטחה ל-a
הקשר אבטחה בזמן ריצה.

כאשר נדרשת החלטת אבטחה, קוד אכיפת המדיניות מעביר זוג SIDs
(בדרך כלל ה-SID של נושא ו-SID של אובייקט, אבל לפעמים זוג נושאים
SIDs או זוג SIDs של אובייקטים), ומחלקת אבטחת אובייקט לשרת האבטחה. ה
מחלקת אבטחת אובייקט מציינת את סוג האובייקט, למשל תהליך, קובץ רגיל, א
ספרייה, שקע TCP וכו'.

החלטות גישה מציינות אם ניתנת הרשאה לזוג נתוני SID או לא
וכיתה. לכל מחלקת אובייקט יש קבוצה של הרשאות משויכות המוגדרות לשליטה
פעולות על אובייקטים עם אותה מחלקה.

D-Bus מבצע בדיקות אבטחה של SELinux בשני מקומות.

ראשית, בכל פעם שהודעה מנותבת מחיבור אחד לחיבור אחר, האוטובוס
daemon יבדוק הרשאות עם הקשר האבטחה של החיבור הראשון כמקור,
הקשר האבטחה של החיבור השני כמטרה, מחלקת אובייקט "dbus" ומבוקש
הרשאה "send_msg".

אם הקשר אבטחה אינו זמין עבור חיבור (בלתי אפשרי בעת שימוש בדומיין UNIX
sockets), אז ההקשר היעד שבו נעשה שימוש הוא ההקשר של דמון האוטובוס עצמו. יש
כרגע אין דרך לשנות את ברירת המחדל הזו, כי אנחנו מניחים שרק תחום UNIX
שקעים ישמשו לחיבור לאוטובוס כלל המערכת. אם זה ישתנה, כנראה נוסיף
דרך להגדיר את הקשר ברירת המחדל של החיבור.

שנית, בכל פעם שחיבור מבקש להיות בעל שם, דמון האוטובוס יבדוק הרשאות
עם הקשר האבטחה של החיבור כמקור, הקשר האבטחה שצוין עבור
השם בקובץ התצורה כמטרה, מחלקת האובייקט "dbus" והרשאה מבוקשת
"acquire_svc".

הקשר האבטחה עבור שם אוטובוס מצוין עם ה- אלמנט שתואר
מוקדם יותר במסמך זה. אם לשם אין הקשר אבטחה משויך ב-
קובץ התצורה, ייעשה שימוש בהקשר האבטחה של דמון האוטובוס עצמו.

APPARMOR

הקשר הכליאה של AppArmor מאוחסן כאשר יישומים מתחברים לאוטובוס. ה
הקשר הכליאה מורכב מתווית ומצב כליאה. כאשר החלטה ביטחונית
נדרש, הדמון משתמש בהקשר הכליאה כדי לשאול את מדיניות AppArmor
לקבוע אם יש לאפשר או לדחות את הפעולה ואם יש לבחון את הפעולה.

הדמון מבצע בדיקות אבטחה של AppArmor בשלושה מקומות.

ראשית, בכל פעם שהודעה מנותבת מחיבור אחד לחיבור אחר, האוטובוס
daemon יבדוק הרשאות עם התווית של החיבור הראשון כמקור, תווית
ו/או שם החיבור של החיבור השני כמטרה, יחד עם שם האוטובוס, ה
שם הנתיב, שם הממשק ושם החבר. השב להודעות, כגון method_return
והודעות שגיאה, מותרות באופן מרומז אם הן בתגובה להודעה שיש לה
כבר הותר.

שנית, בכל פעם שחיבור מבקש להיות בעל שם, דמון האוטובוס יבדוק הרשאות
עם התווית של החיבור כמקור, השם המבוקש כמטרה, יחד עם ה-
שם אוטובוס.

שלישית, בכל פעם שחיבור מנסה לצותת, דמון האוטובוס יבדוק הרשאות
עם התווית של החיבור כמקור, יחד עם שם האוטובוס.

כללי AppArmor לתיווך באוטובוס אינם מאוחסנים בקבצי תצורת האוטובוס. הם
מאוחסן בפרופיל AppArmor של האפליקציה. בבקשה תראה apparmor.d(5) לקבלת פרטים נוספים.

פיתרון

אם אתה מנסה להבין לאן ההודעות שלך הולכות או מדוע אינך מקבל
הודעות, יש כמה דברים שאתה יכול לנסות.

זכור שאפיק המערכת נעול מאוד ואם לא התקנת א
קובץ מדיניות האבטחה כדי לאפשר להודעה שלך לעבור, זה לא יעבוד. עבור אוטובוס הפגישה,
זה לא דאגה.

הדרך הפשוטה ביותר להבין מה קורה באוטובוס היא להפעיל את צג dbus
תוכנית, שמגיעה עם חבילת D-Bus. אתה יכול גם לשלוח הודעות בדיקה עם
dbus-send. לתוכניות אלה יש דפי אדם משלהן.

אם אתה רוצה לדעת מה הדמון עצמו עושה, אולי תשקול להפעיל מכשיר נפרד
עותק של הדמון לבדיקה מולו. זה יאפשר לך לשים את הדמון תחת a
מאתר באגים, או הפעל אותו עם פלט מילולי, מבלי לבלבל את ההפעלה והמערכת האמיתית שלך
דמונים.

כדי להפעיל עותק ניסיון נפרד של הדמון, למשל, תוכל לפתוח מסוף ולהקליד:

DBUS_VERBOSE=1 dbus-daemon --session --print-address

כתובת הדמון לבדיקה תודפס כאשר הדמון יתחיל. אתה תצטרך ל
העתק והדבק כתובת זו והשתמש בה כערך של DBUS_SESSION_BUS_ADDRESS
משתנה סביבה כאשר אתה מפעיל את היישומים שברצונך לבדוק. זה יגרום
יישומים אלה להתחבר לאפיק הבדיקה שלך במקום DBUS_SESSION_BUS_ADDRESS של
אוטובוס הפגישה האמיתי שלך.

ל-DBUS_VERBOSE=1 לא תהיה השפעה אלא אם העותק שלך של D-Bus הידור עם מילולית
מצב מופעל. זה לא מומלץ בבניית ייצור בגלל השפעת הביצועים. אתה
ייתכן שיהיה עליך לבנות מחדש את D-Bus אם העותק שלך לא נבנה מתוך מחשבה על ניפוי באגים. (DBUS_VERBOSE
משפיע גם על ספריית ה-D-Bus ובכך יישומים המשתמשים ב-D-Bus; זה עשוי להיות שימושי לראות
פלט מילולי הן בצד הלקוח והן מהדמון.)

אם אתה רוצה להיות מפואר, אתה יכול ליצור תצורת אוטובוס מותאמת אישית עבור אוטובוס הניסוי שלך (ראה
הקבצים session.conf ו-system.conf שמגדירים את שתי תצורות ברירת המחדל עבור
דוגמא). זה יאפשר לך לציין ספרייה אחרת עבור קבצי שירות, עבור
דוגמא.

השתמש ב-dbus-daemon באינטרנט באמצעות שירותי onworks.net