| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
| |
(#4461)
See #4454
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit fe0f975f447d59977d90c3226cc8c623b31b20b3.
Note: This only reverts the changes from etc.
The 4 aliases introduced on commit 45f2ba544 are mere, well, aliases.
That is, they fail to address the different usability problems discussed
on [#3447][3447] and in fact only make things more confusing (as has
already been mentioned on [this][4379] and later comments). The main
reason is that the aliases do not meaningfully map to the original
commands. For example, the commands from each pair below seem like they
would do the exact same thing:
* `allow` and `nodeny`
* `deny` and `noallow`
Additionally, if these aliases are not the final commands, but only a
test/work-in-progress, then keeping the wide-scale search/replace
changes made on commit fe0f975f4 would only serve to cause confusion, as
users of firejail-git, contributors and downstream projects might start
changing the commands used on their profiles, only to later have to
change them again, potentially to completely different commands.
The sooner this is undone the better, as (besides the above reasons) the
more profile changes there are between the original commit and the
revert, the harder it is to e.g.: `git diff` versions of files across
the following revision ranges: before the commit, after the commit but
before the revert and after the revert. Note: This is still the case
even if a commit is [ignored by `git blame`][4390].
So let us revert fe0f975f4 and only reapply similar large-scale changes
once we have discussed and settled on better commands.
How the revert was applied: Despite using the auto-generated message
from `git revert`, to ensure correctness and to avoid conflicts the
changes were reverted in different steps: Firstly, revert the files
which can be safely reverted directly ("filestorevert"):
# Find out which files have been changed on fe0f975f44, but have not
# been changed afterwards and list them on "filestorevert"
git show --pretty='' --name-only fe0f975f44 -- etc | LC_ALL=C sort >allfiles
git diff --name-only fe0f975f44..master -- etc | LC_ALL=C sort >filestoignore
comm -2 -3 allfiles filestoignore >filestorevert
# Note: There are 3 extra files on filestoignore because they were
# added after commit fe0f975f44
wc -l allfiles filestoignore filestorevert | head -n 3
# 797 allfiles
# 8 filestoignore
# 792 filestorevert
# Automatically revert files in "filestorevert"
# See https://stackoverflow.com/a/23401018/10095231
tr '\n' '\000' <filestorevert | xargs -0 git show fe0f975f44 -- |
git apply --reverse
printf 'Total files reverted:\n'
git diff --name-only | wc -l
# 792
Secondly, do some search/replace on the rest:
tr '\n' '\000' <filestoignore | xargs -0 sed -i.bak \
-e 's/allow /whitelist /' -e 's/noallow /nowhitelist /' \
-e 's/deny /blacklist /' -e 's/nodeny /noblacklist /' \
-e 's/deny-nolog /blacklist-nolog /'
find etc -name '*.bak' -print0 | xargs -0 rm
Thirdly, verify the result. The following command shows the difference
between all the changes in etc from before fe0f975f44 and this commit
(inclusive):
git diff fe0f975f44~1 -- etc
From the output, it looks like all alias changes are fully reverted and
that the other changes to etc (from after fe0f975f44) remain, so the
revert seems to be done correctly.
[3447]: https://github.com/netblue30/firejail/issues/3447
[4379]: https://github.com/netblue30/firejail/issues/4379#issuecomment-876460222
[4390]: https://github.com/netblue30/firejail/issues/4390
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit bd1819a8641e0eeae016846b28a41e625bcc215b, reversing
changes made to 807af3dce05786f10747cc0938cc98af484c8e97.
The hole PR looks like a single crap, it is not even syntactically
correct. Has anyone at least started kmail with this profile before it
was merged? See #3979, thanks @creideiki for reporting.
> First, there are syntax errors. Several mkdir lines have file names containing asterisks.
> This gives the following error:
>
> Error: "${HOME}/.cache/akonadi*" is an invalid filename: rejected character: "*"
>
> I am not sure what they intend to do, but whatever it is it's not working.
> Especially confusing is the line
>
> mkdir /tmp/akonadi-*
>
> Yes, Akonadi creates a directory in /tmp, but its name is random and seems to have been created
> using mkstemp(3) or similar. I'm not sure how Firejail is supposed to be able to pre-create it.
>
> Removing the asterisks makes Firejail at least accept the profile syntactically and try to run
> the program.
It is rejected by syntax. Has anyone tested?
> At startup, Firejail now prints the following warning:
>
> ***
> *** Warning: cannot whitelist ${DOCUMENTS} directory
> *** Any file saved in this directory will be lost when the sandbox is closed.
> ***
Why was 'include disable-xdg.inc' added together with 'whitelist ${DOCUMENTS}', but
no 'nobalcklist ${DOCUMENTS}'? It can not work.
> The actual error is that PostgreSQL needs access to /usr/lib64/postgresql-13/ in order to run.
> Adding the following line to kmail.profile fixes that:
>
> whitelist /usr/share/postgresql*
Again, has anyone thested this?
> The next problem is this message on the console:
>
> kf.config.core: Couldn't write "/home/creideiki/.config/kmail2rc" . Disk full?
>
> Which may have something to do with the profile creating a directory with that name:
>
> mkdir ${HOME}/.config/kmail2rc
>
> when it's supposed to be a file:
>
> $ stat ~/.config/kmail2rc
> File: /home/creideiki/.config/kmail2rc
> Size: 24660 Blocks: 56 IO Block: 4096 regular file
Has anyone tested this or is this just a blind copy of the noblacklist
from above with noblacklist replaced by mkdir?
> However, the error message
>
> kf.config.core: Couldn't write "/home/creideiki/.config/kmail2rc" . Disk full?
>
> still appears.
Looks like #1793. HAS ANYONE TESTED THIS PROFILE??!
> Finally, when exiting KMail, it crashes with a SIGSEGV:
>
> *** KMail got signal 11 (Exiting)
> *** Dead letters dumped.
> KCrash: crashing... crashRecursionCounter = 2
> KCrash: Application Name = kmail path = /usr/bin pid = 20
> KCrash: Arguments: /usr/bin/kmail
Has any...
> I tried restoring an older kmail.profile, from commit 319f2dc, and it has none of the above problems.
... I give up asking if anyone tested this.
> Given the multitude of problems with commit 5532fbd, I'd suggest reverting it until it can be fixed.
Yes, definitely.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
use it. (#3493)
* blacklist .local/share/kxmlgui5
KDE programs use this to store their toolbar config.
* noblacklist .local/share/kxmlgui5 in the relevant KDE applications.
* Whitelist kxmlgui file for okular.
* Use a glob to blacklist subfolders instead of the parent folder.
noblacklisting individual subdirectories works only if we do it this way
(tested by launching bash in the kate profile).
* Make directory, not file.
* noblacklist relevant subdirs for more KDE applications
|
|
|