refactor(audit): flatpak file perm suffix handling#2096
refactor(audit): flatpak file perm suffix handling#2096Commenter25 wants to merge 1 commit intosecureblue:livefrom
Conversation
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Complexity | 0 |
TIP This summary will be updated as you push new changes. Give us feedback
HastD
left a comment
There was a problem hiding this comment.
What's the reason for this change? I don't think the method this PR uses is simpler, and it doesn't provide useful additional info either unless you need to distinguish between "read-write" and "create" permissions.
This comment was marked as outdated.
This comment was marked as outdated.
91c7778 to
ab3bc0c
Compare
ab3bc0c to
ad79fe8
Compare
| readonly = perm.endswith(":ro") | ||
| [path, _, suffix] = perm.rpartition(":") | ||
| if suffix not in FILESYSTEM_SUFFIXES: | ||
| path = perm # path actually has : |
There was a problem hiding this comment.
What does "path actually has :" mean
There was a problem hiding this comment.
"the path found in the filesystem permission is a path which actually contains a : character"
if a flatpak was granted access to, iunno, xdg-videos/Garfield: The Movie.mp4, then path would become xdg-videos/Garfield and suffix would become The Movie.mp4, which would be wrong
it is a very rare edge case, but it is technically a permitted character in unix filenames :D
This changes the
parse_fs_permissionfunction to have a cleaner check for suffixes. No functionality changes.For context, this used to be more complex of a PR, but I realized my approach was flawed. But I do feel simplifying the if-else chain away was an improvement, so I've simply stripped it to that aspect.