libtool generates horrible shell code, you don't want to see the
shellcheck results for it ;-)
This is only relevant for local testing (not in CI) because these files
don't exist in git and therefore don't exist when the shellcheck CI job
runs.
This should avoid unconsciously introducing regressions wrt. best practices for shell code.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/842
Acked-by: Christian Boltz <apparmor@cboltz.de>
Merged-by: Christian Boltz <apparmor@cboltz.de>
- Assume /bin/sh has dash's features and ignore corresponding false positives
- Exclude parser/tst, tests and utils/test directories: they have tons
of shellcheck violations but they don't *directly* impact our users.
Let's first focus on code that runs on production systems.
- Exclude rc.apparmor.slackware: I don't know anything about Slackware's
/bin/sh.
The previous code happened to work only because we always pass either 0 or 1
arguments to these functions. If we ever passed them 2+ arguments,
unexpected things would happen.
For details, see https://www.shellcheck.net/wiki/SC2145
Found by rpmlint.
I propose this fix for 3.0 and master to keep the file in sync.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/846
Acked-by: Approved-by: intrigeri <intrigeri@boum.org> for 3.0 and master
Merged-by: Christian Boltz <gitlab2@cboltz.de>
Even if there are Red Hat / Fedora systems that use AppArmor, chances are that
they use systemd, and not an initscript. And even if somehow they do use an
initscript, chances are that it's not this one, as last time it has seen
a non-cosmetic change was in 2007.
* Don't call aa_log_action_end after calling aa_log_failure_msg, because
a generic "failure" message will be outputted twice by the Red Hat and
Slackware init scripts.
* Don't append a space to the initial output from apparmor_stop, in line
with other usages of aa_log_daemon_msg.
Debian doesn't use the init script provided in parser/rc.apparmor.debian,
instead preferring to patch parser/rc.apparmor.functions and call its
functions directly in an init script they maintain themselves (something
they have done since 2006). Since this script is no longer used, and
currently doesn't work correctly anyway because it lacks definitions for
several functions that are relied upon in parser/rc.apparmor.functions,
it can be removed.
If `apparmor_parser -N` (in `profiles_names_list()`) fails,
`aa-remove-unknown` possibly gets an incomplete list of profiles in
`/etc/apparmor.d/` and therefore might remove more profiles than it
should.
Replace the `profiles_names_list()` call with a direct `apparmor_parser`
call, and abort aa-remove-unknown if it exits with $? != 0
Before:
```
aa-remove-unknown -n
AppArmor parser error for /etc/apparmor.d/broken in profile /etc/apparmor.d/broken at line 1: syntax error, unexpected TOK_ID, expecting TOK_OPEN
Would remove 'delete_me'
```
After:
```
./aa-remove-unknown -n
AppArmor parser error for /etc/apparmor.d in profile /etc/apparmor.d/zbroken at line 1: syntax error, unexpected TOK_ID, expecting TOK_OPEN
apparmor_parser exited with failure, aborting.
```
And of course, after fixing the broken profile:
```
./aa-remove-unknown -n
Would remove 'delete_me'
```
Also drop the now-unused profiles_names_list() from rc.apparmor.functions - the only user was aa-remove-unknown.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/836
Acked-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
If apparmor_parser -N (in profiles_names_list()) fails,
aa-remove-unknown possibly gets an incomplete list of profiles in
/etc/apparmor.d/ and therefore might remove more profiles than it
should.
Replace the profiles_names_list() call with a direct apparmor_parser
call, and abort aa-remove-unknown if it exits with $? != 0
Before:
```
aa-remove-unknown -n
AppArmor parser error for /etc/apparmor.d/broken in profile /etc/apparmor.d/broken at line 1: syntax error, unexpected TOK_ID, expecting TOK_OPEN
Would remove 'delete_me'
```
After:
```
./aa-remove-unknown -n
AppArmor parser error for /etc/apparmor.d in profile /etc/apparmor.d/zbroken at line 1: syntax error, unexpected TOK_ID, expecting TOK_OPEN
apparmor_parser exited with failure, aborting.
```
And of course, after fixing the broken profile:
```
./aa-remove-unknown -n
Would remove 'delete_me'
```
Library versioning requires we keep these changes in sync. Since the
3.0.4 release bumped revision we need to do it here as well.
Signed-off-by: John Johansen <john.johansen@canonical.com>
... which is used by aa-remove-unknown.
apparmor_parser can read a whole directory, therefore we don't need to
do the directory listing, excluding *.rpmnew etc. ourself.
Related to https://gitlab.com/apparmor/apparmor/-/issues/148
... which became superfluous after dropping use of xargs as fallback
when loading profiles in 0b8ea047e8
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/833
Acked-by: Approved-by: Jon Tourville <jon.tourville@canonical.com>
Merged-by: John Johansen <john@jjmx.net>
Currently libapparmor fails to build when lto is used because it uses
the asm directive to provide different version of some symbols.
Unfortunately gcc does not recognize this and the symbols defined by
asm are lost and optimized out by lto and then the link fails.
Fixes: https://gitlab.com/apparmor/apparmor/-/issues/214
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/831
Signed-off-by: John Johansen <john.johansen@canonical.com>
The AppArmor systemd scripts correctly detect the Windows Subsystem for Linux as a container, since all Linux distros executing under WSL 2 are containerized; however, unlike the majority of containers (since there is no accessible host distribution above them trying to set AppArmor policies that might interfere), AppArmor itself functions without problems in the WSL environment.
This patch adds WSL detection to the is_container_with_internal_policy function, allowing AppArmor to be started and operate normally in a WSL-plus-systemd environment.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/812
Acked-by: John Johansen <john@jjmx.net>
LP:1377338 <https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1377338>
has been fixed for quite awhile and we don't need to call xargs as
a fallback when loading policy fails.
In addition we really don't want to be doing this because we want to
be moving to atomic profile loads where if one profile fails the
whole load fails. This is a step in that direction.
Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Christian Boltz <apparmor@cboltz.de>
Permission denied when Evince tries to use Chrome to open link.
In config is missing the bin: `/opt/google/chrome/crashpad_handler`.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/830
Acked-by: John Johansen <john@jjmx.net>
This test uses unix_fd_server to open a file and pass
its file descriptor to the attach_disconnected tests, which
then mounts, pivots root and then tries to open the file.
Since the server execs the client, this MR also inverts the order
of the parameters to allow the server to forward the client's args
along with the unix_socket path.
I'm also refactoring out the unix_fd_client logic into unix_fd_common,
so we can use this implementation when creating other clients, which is the case
for the test binary attach_disconnected
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/810
Acked-by: Approved-by: John Johansen <john@jjmx.net>
Merged-by: Georgia Garcia <georgia.garcia@canonical.com>
