i/builtin: support desktop-file-ids in desktop files rule generation #14444

ZeyadYasser · 2024-08-30T11:33:58Z

This PR adds support for desktop-file-ids for apparmor rules generated when the desktop-legacy and unity7 interfaces are connected because they provide the ability for the snap to access it own desktop files.

This adds a bit of complexity due to the deny rules that needs to be generated to suppress warnings. GenerateAAREExclusionPatterns is used with care to generate the deny rules for multiple patterns.

Now, since the rules generated depend on the snap content itself, more aggressive validation and sanitization is required:

Sanitized desktop file names during mangling so they can only contain [A-Za-z0-9-_.] so they can't contain special AARE characters
- Kept desktop-file-ids as is without sanitization because they should already be validated during install
Added aggressive validation when generating desktop rules (for unity7 and desktop-legacy) that non of the names used in rule generation contain any special AARE characters.
Used defensive approach in rule generation
- where allow rules doesn't depend on desktop files found in the snap but instead depends on the desktop prefix and desktop file ids.
- and deny rules depend desktop file names inside the snap mount, so if a snap somehow escaped all this validation, it can only shoot itself in the foot and deny itself more things

Any single one of the methods used above should have been enough, but since this is generating apparmor rules from user input basically it is better to play it safe here.

Please be as skeptical as possible when reviewing and let me know if you found an edge case that could break the rule generation.

ZeyadYasser · 2024-09-04T13:35:15Z

I just realized that incoming desktop file names must be sanitized before passing to GenerateAAREExclusionPatterns to avoid snaps shipping with desktop file names that contain AARE globbing expressions.

ZeyadYasser · 2024-09-11T08:03:37Z

I just realized that incoming desktop file names must be sanitized before passing to GenerateAAREExclusionPatterns to avoid snaps shipping with desktop file names that contain AARE globbing expressions.

I fixed this in multiple ways, each adding a layer of protection on its own:

Sanitized desktop file names during mangling so they can only contain [A-Za-z0-9-_.] so they can't contain special AARE characters
- Kept desktop-file-ids as is without sanitization because they should already be validated during install
Added aggressive validation when generating desktop rules (for unity7 and desktop-legacy) that non of the names used in rule generation contain any special AARE characters.
Switched to defensive approach in rule generation
- where allow rules doesn't depend on desktop files found in the snap but instead depends on the desktop prefix and desktop file ids.
- and deny rules depend desktop file names inside the snap mount, so if a snap somehow escaped all this validation, it can only shoot itself in the foot and deny itself more things

Signed-off-by: Zeyad Gouda <[email protected]>

snap/info.go

wrappers/desktop.go

interfaces/builtin/utils.go

bboozzoo · 2024-09-13T08:28:02Z

interfaces/builtin/utils.go

+		// desktop-file-ids are already validated during install.
+		// But still it is better to play it safe and check AARE characters anyway.
+		if err := apparmor.ValidateNoAppArmorRegexp(desktopFileID); err != nil {
+			logger.Noticef("error: %v", err)


also why not fail and let AppArmorConnectedPlug return an error?

Good point, Since desktop-file-ids is a new concept, I believe we can just fail. but for existing prefixed desktop files we could break some snaps but it would be very rare. A snap with weird desktop file names + unity7/desktop-legacy plugs.

CC: @pedronis @jhenstridge

bboozzoo · 2024-09-13T08:31:38Z

interfaces/builtin/utils.go

+		// Validate IDs, This check should never be triggered because
+		// desktop-file-ids are already validated during install.
+		// But still it is better to play it safe and check AARE characters anyway.
+		if err := apparmor.ValidateNoAppArmorRegexp(desktopFileID); err != nil {


wonder if this should perhaps be done in snap.Validate()

Ideally, Yes. But we don't know if there are snaps already in the store with desktop files with undesired names. adding the check in snap.Validate() could break existing installs (but maybe for such snaps, we should?).

don't we do any validation on the ids? I'm sure there are some checks that we can do just based on dbus rules, no?

We do validation in the desktop interface's BeforePreparePlug

snapd/interfaces/builtin/desktop.go

Lines 623 to 633 in b605298

// https://specifications.freedesktop.org/desktop-entry-spec/latest/file-naming.html

// Desktop file id must be a valid D-Bus name:

// - A sequence of non-empty elements separated by dots

// - None of which starts with a digit

// - Each of which contains only characters from the set [A-Za-z0-9-_]

//

// XXX: dashes "-" are not recommended but supported, should they be removed?

// https://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-names

var desktopFileIDRegexp = regexp.MustCompile(`^([A-Za-z_-][\w-]*)(\.[A-Za-z_-][\w-]*)*$`)

func (iface *desktopInterface) validateDesktopFileIDs(attribs interfaces.Attrer) error {

I added the check here to avoid depending on other parts working as expected and having the checks validate input standalone without any assumptions.

I would prefer this is done in snap.Validate() since any existing snaps should be updated. However, if we are concerned about breaking things too much, we should ensure that review-tools implements similar validation logic for desktop-file-ids so we can avoid snaps being uploaded with anything that might try and abuse this (also recall this needs a snap declaration as well which adds additional protection too).

No snaps on the store currently should have desktop-file-ids yet, I think we could add a check for them in snap.Validate() and fail hard there during install/pack. I was confused at first and thought this was for existing desktop file names as well.

I got confused a bit, I don't think we can this check to snap.Validate(). As Samuele mentioned the bad plug will not be there to validate since the snap plugs and slots are sanitized before getting validated so when we reach snap.Validate a bad desktop-file-ids attribute won't be there.

snapd/snap/info_snap_yaml.go

Lines 241 to 242 in 848d437

snap.BadInterfaces = make(map[string]string)

SanitizePlugsSlots(snap)

I don't see a clean way of force validating desktop-file-ids because they are sanitized (and disappear if bad) just before validation. Only thing left of them is an error message under info.BadInterfaces that is shown when running snap pack --check-skeleton.

$ snap pack --check-skeleton squashfs-root build snap "hello" has bad plugs or slots: desktop (desktop-file-ids entry "org.he&&llo.Example" is not a valid D-Bus well-known name)

Maybe I am confused about what is required here, but I think adding validation on the container level snap.validateContainer() for desktop file names on pack/build as @bboozzoo suggested #14444 (comment) is a great idea + checks from review tools to prevent new revision with weird desktop file names.

So it looks like an error here is unexpected and we should return early rather than simply ignore it. snap pack --check-skeleton raises an error with bad plugs/slots, but actual pack does not, which I think was intentional.

I updated that part to return and error instead of doing the fallback as this indicates something dangerous that the early validation and sanitization was bypassed by the snap.

bboozzoo · 2024-09-13T08:34:29Z

interfaces/builtin/utils.go

+		// - Prefixed desktop files are sanitized to only contain non-AARE characters
+		// - Desktop file ids are validated to only contain non-AARE characters
+		// But still it is better to play it safe and check AARE characters anyway.
+		if err := apparmor.ValidateNoAppArmorRegexp(desktopFile); err != nil {


snap.Validate() is also used when packing a snap, maybe it'd be useful to issue a warning if the there's anything wrong with the desktop files.

Hm I don't recall why we don't do any sanity checks of desktop files in validation code, and rather let them fail during install.

Yes, I agree. A warning there wouldn't break existing snaps.

Hm I don't recall why we don't do any sanity checks of desktop files in validation code, and rather let them fail during install.

No idea, I recently landed changes there to validate their file types, but there weren't any other validations. I think without epochs we cannot do better on the container validation side.

A followup material, but we could look into tweaking snap.Validate() interface to pass additional parameter describing the scenario in which it is invoked, and in case of pack/build-time validation fail hard on some new checks we introduce.

A followup material, but we could look into tweaking snap.Validate() interface to pass additional parameter describing the scenario in which it is invoked, and in case of pack/build-time validation fail hard on some new checks we introduce.

This sounds like a great idea.

And we should also extend review-tools to implement similar checks against desktop file names etc.

Filed a ticket to track this idea https://warthogs.atlassian.net/browse/SNAPDENG-32333

I just have one comment, I think the desktop file names check should be on the container level, so I think snap.validateContainer() would be more appropriate to add the additional scenario parameter.

Signed-off-by: Zeyad Gouda <[email protected]>

zyga

One question. I'll re-review this later today.

zyga · 2024-09-12T18:02:32Z

tests/lib/snaps/test-snapd-desktop-file-ids/meta/gui/bad. ,?**[]{}^\$#.desktop

@@ -0,0 +1,6 @@
+[Desktop Entry]


I wish there was a way to comment on the file name in GitHub. This is such a nice name :)

zyga · 2024-09-13T07:41:59Z

interfaces/builtin/utils.go

+	}
+	if len(desktopFiles) == 0 {
+		// Nothing to do
+		return getDesktopFileRulesFallback()


Why do we switch to the fallback in this case?

This is to be consistent with the original implementation, which didn't care about existing desktop files.

snapd/interfaces/builtin/utils.go

Lines 116 to 136 in f3d0682

func getDesktopFileRules(snapInstanceName string) []string {

baseDir := dirs.SnapDesktopFilesDir

rules := []string{

"# Support applications which use the unity messaging menu, xdg-mime, etc",

"# This leaks the names of snaps with desktop files",

fmt.Sprintf("%s/ r,", baseDir),

"# Allowing reading only our desktop files (required by (at least) the unity",

"# messaging menu).",

"# parallel-installs: this leaks read access to desktop files owned by keyed",

"# instances of @{SNAP_NAME} to @{SNAP_NAME} snap",

fmt.Sprintf("%s/@{SNAP_INSTANCE_DESKTOP}_*.desktop r,", baseDir),

"# Explicitly deny access to other snap's desktop files",

fmt.Sprintf("deny %s/@{SNAP_INSTANCE_DESKTOP}[^_.]*.desktop r,", baseDir),

}

for _, t := range aareExclusivePatterns(snapInstanceName) {

rules = append(rules, fmt.Sprintf("deny %s/%s r,", baseDir, t))

}

return rules

}

I know a snap depending on the undocumented behavior that unity7 and desktop-legacy gives it access to list desktop files should not be supported, but who knows what snap will break if that changes?

Signed-off-by: Zeyad Gouda <[email protected]>

pedronis

I did a quick first pass, seems ok. One remark about the already landed helper and one about desktop-ids validation

interfaces/builtin/utils.go

pedronis · 2024-09-16T16:27:59Z

interfaces/builtin/utils.go

+		// Validate IDs, This check should never be triggered because
+		// desktop-file-ids are already validated during install.
+		// But still it is better to play it safe and check AARE characters anyway.
+		if err := apparmor.ValidateNoAppArmorRegexp(desktopFileID); err != nil {


don't we do any validation on the ids? I'm sure there are some checks that we can do just based on dbus rules, no?

Signed-off-by: Zeyad Gouda <[email protected]>

pedronis · 2024-09-18T08:42:32Z

interfaces/builtin/utils.go

+		// desktop-file-ids are already validated during install.
+		// But still it is better to play it safe and check AARE characters anyway.
+		if err := apparmor.ValidateNoAppArmorRegexp(desktopFileID); err != nil {
+			logger.Noticef("invalid desktop file id %q found in %q: %v", desktopFileID, s.InstanceName(), err)


I think my point is if we prefer not to error here ok, but this message should make clear that this situation is an internal error, as the desktop-ids shouldn't have made this far

Updated, and also updated the tests to check that errors are logged properly

Signed-off-by: Zeyad Gouda <[email protected]>

pedronis · 2024-09-18T11:14:50Z

interfaces/builtin/utils.go

@@ -155,7 +155,7 @@ func getDesktopFileRules(s *snap.Info) string {
 	denyRules := "# Explicitly deny access to other snap's desktop files\n"
 	desktopFiles, err := desktopFilesFromInstalledSnap(s)
 	if err != nil {
-		logger.Noticef("error: %v", err)
+		logger.Noticef("internal error: failed to collect desktop files from snap %q: %v", s.InstanceName(), err)


I'm not sure this one and the one below are internal errors though, do we check desktop file names somewhere else?

Good point, the snap mount could have been unmounted due to external reasoning which would cause failure. Updated.

Regarding the ones below:

internal error: invalid desktop file name %q found in snap %q which should have been validated earlier

My reasoning here was that if we got so far and also got a bad desktop file name then snapd have been tricked somehow by the snap either when validating desktop file ids or when sanitizing the desktop file names during install/refresh.

internal error: failed to generate deny rules for snap %q: %v

My reasoning here was that there is a case we didn't account for that breaks deny rules generation

Signed-off-by: Zeyad Gouda <[email protected]>

pedronis

thanks, lgtm, please iterate on this further with other reviewers as needed

bboozzoo

looks quite good

interfaces/builtin/utils.go

bboozzoo · 2024-09-18T12:53:05Z

interfaces/builtin/utils.go

+		// - Prefixed desktop files are sanitized to only contain non-AARE characters
+		// - Desktop file ids are validated to only contain non-AARE characters
+		// But still it is better to play it safe and check AARE characters anyway.
+		if err := apparmor.ValidateNoAppArmorRegexp(desktopFile); err != nil {


A followup material, but we could look into tweaking snap.Validate() interface to pass additional parameter describing the scenario in which it is invoked, and in case of pack/build-time validation fail hard on some new checks we introduce.

interfaces/builtin/utils.go

wrappers/desktop.go

bboozzoo · 2024-09-18T13:03:01Z

interfaces/builtin/utils.go

+//
+// The snap must be mounted.
+func getDesktopFileRules(s *snap.Info) string {
+	const template = `


maybe this could use strings.Builder as well now. Not essential, but give it a try locally, and if the changes look good maybe it's worth pushing.

Is this what you had in mind?

diff --git a/interfaces/builtin/utils.go b/interfaces/builtin/utils.go index 026f7668f5..2475d2f7f1 100644 --- a/interfaces/builtin/utils.go +++ b/interfaces/builtin/utils.go @@ -109,26 +109,18 @@ var desktopFilesFromInstalledSnap = func(s *snap.Info) ([]string, error) { // // The snap must be mounted. func getDesktopFileRules(s *snap.Info) string { - const template = ` -# Support applications which use the unity messaging menu, xdg-mime, etc -# This leaks the names of snaps with desktop files -%s/ r, + var b strings.Builder -# Allow rules: -%s - -# Deny rules: -%s -` + b.WriteString("# Support applications which use the unity messaging menu, xdg-mime, etc\n") + b.WriteString("# This leaks the names of snaps with desktop files\n") + b.WriteString(fmt.Sprintf("%s/ r,\n", dirs.SnapDesktopFilesDir)) // Generate allow rules - allowRules := ` -# Allowing reading only our desktop files (required by (at least) the unity -# messaging menu). -# parallel-installs: this leaks read access to desktop files owned by keyed -# instances of @{SNAP_NAME} to @{SNAP_NAME} snap -` - allowRules += fmt.Sprintf("%s/@{SNAP_INSTANCE_DESKTOP}_*.desktop r,\n", dirs.SnapDesktopFilesDir) + b.WriteString("# Allowing reading only our desktop files (required by (at least) the unity\n") + b.WriteString("# messaging menu).\n") + b.WriteString("# parallel-installs: this leaks read access to desktop files owned by keyed\n") + b.WriteString("# instances of @{SNAP_NAME} to @{SNAP_NAME} snap\n") + b.WriteString(fmt.Sprintf("%s/@{SNAP_INSTANCE_DESKTOP}_*.desktop r,\n", dirs.SnapDesktopFilesDir)) // For allow rules let's be more defensive and not depend on desktop files // shipped by the snap like what is done below in the deny rules so that if // a snap figured out a way to trick the checks below it can only shoot @@ -149,11 +141,11 @@ func getDesktopFileRules(s *snap.Info) string { logger.Noticef("internal error: invalid desktop file ID %q found in snap %q: %v", desktopFileID, s.InstanceName(), err) return getDesktopFileRulesFallback() } - allowRules += fmt.Sprintf("%s/%s r,\n", dirs.SnapDesktopFilesDir, desktopFileID+".desktop") + b.WriteString(fmt.Sprintf("%s/%s r,\n", dirs.SnapDesktopFilesDir, desktopFileID+".desktop")) } // Generate deny rules to suppress apparmor warnings - denyRules := "# Explicitly deny access to other snap's desktop files\n" + b.WriteString("# Explicitly deny access to other snap's desktop files\n") desktopFiles, err := desktopFilesFromInstalledSnap(s) if err != nil { logger.Noticef("failed to collect desktop files from snap %q: %v", s.InstanceName(), err) @@ -188,9 +180,9 @@ func getDesktopFileRules(s *snap.Info) string { logger.Noticef("internal error: failed to generate deny rules for snap %q: %v", s.InstanceName(), err) return getDesktopFileRulesFallback() } - denyRules += excludeRules + b.WriteString(excludeRules) - return fmt.Sprintf(template, dirs.SnapDesktopFilesDir, allowRules[1:], denyRules) + return b.String() } // stringListAttribute returns a list of strings for the given attribute key if the attribute exists.

more less, builder implements Writer, so you can use fmt.Fprintf(&b, ...) where appropriate

Signed-off-by: Zeyad Gouda <[email protected]>

alexmurray

In general this looks quite good - I really like the defence in depth approach and multiple levels of validation. However, I would prefer the validation is done in snap.Validate() to fail-hard earlier to avoid any chance of possible abuse, but will leave this decision up to @pedronis - from a security point of view, this looks really good.

I have also filed a bug for review-tools as well to make sure we implement similar logic there https://bugs.launchpad.net/review-tools/+bug/2081240.

alexmurray · 2024-09-20T01:10:09Z

interfaces/builtin/utils.go

+		// Validate IDs, This check should never be triggered because
+		// desktop-file-ids are already validated during install.
+		// But still it is better to play it safe and check AARE characters anyway.
+		if err := apparmor.ValidateNoAppArmorRegexp(desktopFileID); err != nil {


I would prefer this is done in snap.Validate() since any existing snaps should be updated. However, if we are concerned about breaking things too much, we should ensure that review-tools implements similar validation logic for desktop-file-ids so we can avoid snaps being uploaded with anything that might try and abuse this (also recall this needs a snap declaration as well which adds additional protection too).

alexmurray · 2024-09-20T01:14:28Z

interfaces/builtin/utils.go

+		// - Prefixed desktop files are sanitized to only contain non-AARE characters
+		// - Desktop file ids are validated to only contain non-AARE characters
+		// But still it is better to play it safe and check AARE characters anyway.
+		if err := apparmor.ValidateNoAppArmorRegexp(desktopFile); err != nil {


A followup material, but we could look into tweaking snap.Validate() interface to pass additional parameter describing the scenario in which it is invoked, and in case of pack/build-time validation fail hard on some new checks we introduce.

This sounds like a great idea.

And we should also extend review-tools to implement similar checks against desktop file names etc.

Those errors should never be triggered and indicate that early validation and sanitization was bypassed by the snap so we should fail hard and not do the fallback and prevent the connection. Signed-off-by: Zeyad Gouda <[email protected]>

codecov · 2024-09-23T09:58:51Z

Codecov Report

Attention: Patch coverage is 93.96552% with 7 lines in your changes missing coverage. Please review.

Project coverage is 78.86%. Comparing base (3492595) to head (93d2e69).
Report is 193 commits behind head on master.

Files with missing lines	Patch %	Lines
interfaces/builtin/utils.go	95.29%	3 Missing and 1 partial ⚠️
wrappers/desktop.go	40.00%	2 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #14444      +/-   ##
==========================================
+ Coverage   78.77%   78.86%   +0.09%     
==========================================
  Files        1073     1079       +6     
  Lines      143693   145697    +2004     
==========================================
+ Hits       113191   114910    +1719     
- Misses      23401    23601     +200     
- Partials     7101     7186      +85

Flag	Coverage Δ
unittests	`78.86% <93.96%> (+0.09%)`	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

bboozzoo

LGTM

ZeyadYasser · 2024-09-25T11:43:02Z

Failing tests are known to fail:

google-distro-1:debian-sid-64:tests/main/snap-run
openstack:fedora-40-64:tests/main/selinux-clean

ZeyadYasser force-pushed the desktop-file-ids-apparmor-rules branch 3 times, most recently from 79dfd14 to 8080492 Compare September 2, 2024 15:50

ZeyadYasser mentioned this pull request Sep 2, 2024

many: extract desktop-ids helpers from wrappers package into snap package #14456

Merged

ZeyadYasser force-pushed the desktop-file-ids-apparmor-rules branch from 8080492 to ad2bce2 Compare September 3, 2024 10:11

ZeyadYasser marked this pull request as draft September 4, 2024 13:35

ZeyadYasser force-pushed the desktop-file-ids-apparmor-rules branch from ad2bce2 to ec8468d Compare September 11, 2024 07:53

ZeyadYasser marked this pull request as ready for review September 11, 2024 07:55

ZeyadYasser requested review from zyga, pedronis, bboozzoo, jhenstridge and alexmurray September 11, 2024 08:12

ZeyadYasser added Needs Samuele review Needs a review from Samuele before it can land Needs security review Can only be merged once security gave a :+1: labels Sep 11, 2024

ZeyadYasser added this to the 2.66 milestone Sep 11, 2024

i/builtin: support desktop-file-ids in desktop files rule generation

a315bf8

Signed-off-by: Zeyad Gouda <[email protected]>

ZeyadYasser force-pushed the desktop-file-ids-apparmor-rules branch from ec8468d to a315bf8 Compare September 11, 2024 08:30

bboozzoo reviewed Sep 13, 2024

View reviewed changes

i/builtin: address review comments (thanks @bboozzoo)

4c93ce8

Signed-off-by: Zeyad Gouda <[email protected]>

ZeyadYasser force-pushed the desktop-file-ids-apparmor-rules branch from 5aff77e to 4c93ce8 Compare September 15, 2024 13:42

ZeyadYasser requested a review from bboozzoo September 15, 2024 13:42

zyga reviewed Sep 16, 2024

View reviewed changes

zyga self-requested a review September 16, 2024 08:14

wrappers: ignore duplicates when installing snap desktop files

b364f5c

Signed-off-by: Zeyad Gouda <[email protected]>

pedronis reviewed Sep 16, 2024

View reviewed changes

ZeyadYasser requested a review from pedronis September 17, 2024 12:51

many: s/DesktopFilesFromMount/DesktopFilesFromInstalledSnap

b44c8a2

Signed-off-by: Zeyad Gouda <[email protected]>

pedronis reviewed Sep 18, 2024

View reviewed changes

i/builtin: improve desktop file rules error logs

9ef0181

Signed-off-by: Zeyad Gouda <[email protected]>

ZeyadYasser requested a review from pedronis September 18, 2024 09:44

pedronis reviewed Sep 18, 2024

View reviewed changes

i/builtin: update error log message

9578c24

Signed-off-by: Zeyad Gouda <[email protected]>

ZeyadYasser requested a review from pedronis September 18, 2024 11:47

pedronis approved these changes Sep 18, 2024

View reviewed changes

bboozzoo reviewed Sep 18, 2024

View reviewed changes

alexmurray requested a review from jslarraz September 19, 2024 11:11

{i/builtin,wrappers}: adjust comment and logs wording

e5a4729

Signed-off-by: Zeyad Gouda <[email protected]>

ZeyadYasser requested a review from bboozzoo September 19, 2024 15:54

i/builtin: use string builder for desktop file rules generation

b1eede9

Signed-off-by: Zeyad Gouda <[email protected]>

alexmurray approved these changes Sep 20, 2024

View reviewed changes

alexmurray removed the Needs security review Can only be merged once security gave a :+1: label Sep 20, 2024

bboozzoo approved these changes Sep 25, 2024

View reviewed changes

ZeyadYasser merged commit c139489 into canonical:master Sep 25, 2024
54 of 56 checks passed

ZeyadYasser mentioned this pull request Oct 3, 2024

release: 2.66 #14566

Merged

	// https://specifications.freedesktop.org/desktop-entry-spec/latest/file-naming.html
	// Desktop file id must be a valid D-Bus name:
	// - A sequence of non-empty elements separated by dots
	// - None of which starts with a digit
	// - Each of which contains only characters from the set [A-Za-z0-9-_]
	//
	// XXX: dashes "-" are not recommended but supported, should they be removed?
	// https://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-names
	var desktopFileIDRegexp = regexp.MustCompile(`^([A-Za-z_-][\w-])(\.[A-Za-z_-][\w-])*$`)

	func (iface *desktopInterface) validateDesktopFileIDs(attribs interfaces.Attrer) error {

	snap.BadInterfaces = make(map[string]string)
	SanitizePlugsSlots(snap)

	func getDesktopFileRules(snapInstanceName string) []string {
	baseDir := dirs.SnapDesktopFilesDir

	rules := []string{
	"# Support applications which use the unity messaging menu, xdg-mime, etc",
	"# This leaks the names of snaps with desktop files",
	fmt.Sprintf("%s/ r,", baseDir),
	"# Allowing reading only our desktop files (required by (at least) the unity",
	"# messaging menu).",
	"# parallel-installs: this leaks read access to desktop files owned by keyed",
	"# instances of @{SNAP_NAME} to @{SNAP_NAME} snap",
	fmt.Sprintf("%s/@{SNAP_INSTANCE_DESKTOP}_*.desktop r,", baseDir),
	"# Explicitly deny access to other snap's desktop files",
	fmt.Sprintf("deny %s/@{SNAP_INSTANCE_DESKTOP}[^_.]*.desktop r,", baseDir),
	}
	for _, t := range aareExclusivePatterns(snapInstanceName) {
	rules = append(rules, fmt.Sprintf("deny %s/%s r,", baseDir, t))
	}

	return rules
	}

i/builtin: support desktop-file-ids in desktop files rule generation #14444

i/builtin: support desktop-file-ids in desktop files rule generation #14444

Conversation

ZeyadYasser commented Aug 30, 2024 • edited Loading

ZeyadYasser commented Sep 4, 2024

ZeyadYasser commented Sep 11, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ZeyadYasser Sep 20, 2024 • edited Loading

Choose a reason for hiding this comment

ZeyadYasser Sep 20, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zyga left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pedronis left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pedronis left a comment

Choose a reason for hiding this comment

bboozzoo left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alexmurray left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

codecov bot commented Sep 23, 2024 • edited Loading

Codecov Report

bboozzoo left a comment

Choose a reason for hiding this comment

ZeyadYasser commented Sep 25, 2024

ZeyadYasser commented Aug 30, 2024 •

edited

Loading

ZeyadYasser Sep 20, 2024 •

edited

Loading

ZeyadYasser Sep 20, 2024 •

edited

Loading

codecov bot commented Sep 23, 2024 •

edited

Loading