Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #231254 > unrolled thread
| Started by | Tony van der Hoff <lists@vanderhoff.org> |
|---|---|
| First post | 2021-01-29 14:10 +0100 |
| Last post | 2021-01-29 18:00 +0100 |
| Articles | 5 — 4 participants |
Back to article view | Back to linux.debian.user
Apparmor pain Tony van der Hoff <lists@vanderhoff.org> - 2021-01-29 14:10 +0100
Re: Apparmor pain Reco <recoverym4n@enotuniq.net> - 2021-01-29 14:30 +0100
Re: Apparmor pain Tony van der Hoff <lists@vanderhoff.org> - 2021-01-29 15:30 +0100
Re: Apparmor pain Brian <ad44@cityscape.co.uk> - 2021-01-29 16:50 +0100
Re: Apparmor pain David Wright <deblis@lionunicorn.co.uk> - 2021-01-29 18:00 +0100
| From | Tony van der Hoff <lists@vanderhoff.org> |
|---|---|
| Date | 2021-01-29 14:10 +0100 |
| Subject | Apparmor pain |
| Message-ID | <BCBHc-7gE-15@gated-at.bofh.it> |
This is a simplified scenario: Say I have 2 machines, both running Debian 10.7. Each machine has 3 users: A, B and C. Each machine has an identical (mantained by Unison) directoery: /home/C/pictures, with permissions ugo:rwx owned by C. Each file therein has permissions ugo:r Both machines can access any file within pictures with no problems, as one would expect. However, using Thunderbird, machine A can attach any file from pictures, but machine B fails silently to do so. Examining the syslog for B it would appear that apparmor is preventing access. From my web research it appears that apparmor was introduced by default at debian 10. On machine B it is blocking Thunderbird, but not on A. I don't understand why my two machines are behaving so differently. I don't think I really want apparmor running at all, but at least I'd like either machine to access C's files. Apparmor's man page gives eye-watering detail, but I can'tr find any easily usable configuration suggestions. The debian wiki gives me a way to disable apparmor by patching grub, but that seems like overkill. Does anyone pease have any suggestions on how to enable an application without major surgery? any help appreciated. Thanks -- Tony van der Hoff | mailto:tony@vanderhoff.org Buckinghamshire, England |
[toc] | [next] | [standalone]
| From | Reco <recoverym4n@enotuniq.net> |
|---|---|
| Date | 2021-01-29 14:30 +0100 |
| Message-ID | <BCC0x-7mH-3@gated-at.bofh.it> |
| In reply to | #231254 |
Hi.
On Fri, Jan 29, 2021 at 12:49:42PM +0000, Tony van der Hoff wrote:
> This is a simplified scenario: Say I have 2 machines, both running Debian 10.7. Each machine has 3 users: A, B and C. Each machine has an identical (mantained
> by Unison) directoery: /home/C/pictures, with permissions ugo:rwx owned by C. Each file therein has permissions ugo:r
...
> I don't understand why my two machines are behaving so differently.
uid difference between hosts A and B, most probably.
Along the other things, thunderbird's apparmor policy contains this:
owner @{HOME}/** r,
I.e. it's allowed to read any file at /home as long as the file is owned
by thunderbird's uid.
> I don't think I really want apparmor running at all,
Add apparmor=0 to kernel's cmdline. Building a kernel without apparmor
helps with that too, but that's straying too far from Debian's defaults.
> The debian wiki gives me a way to disable apparmor by patching grub,
> but that seems like overkill.
You probably got it wrong. Modifying a kernel cmdline and rebuilding
grub with custom patches are different, and they should suggest former
at Debian's wiki.
> Does anyone pease have any suggestions on how to enable an application
> without major surgery? any help appreciated. Thanks
Disabling a problematic apparmor profile altogether is done by:
/usr/sbin/aa-disable /usr/bin/thunderbird
Disabling a problematic apparmor profile but keeping audit records
generation is done by
/usr/sbin/aa-complain /usr/bin/thunderbird
You'll want the first one, probably.
Reco
[toc] | [prev] | [next] | [standalone]
| From | Tony van der Hoff <lists@vanderhoff.org> |
|---|---|
| Date | 2021-01-29 15:30 +0100 |
| Message-ID | <BCCWB-7UX-3@gated-at.bofh.it> |
| In reply to | #231255 |
On 29/01/2021 13:27, Reco wrote:
> Hi.
>
> On Fri, Jan 29, 2021 at 12:49:42PM +0000, Tony van der Hoff wrote:
>> This is a simplified scenario: Say I have 2 machines, both running Debian 10.7. Each machine has 3 users: A, B and C. Each machine has an identical (mantained
>> by Unison) directoery: /home/C/pictures, with permissions ugo:rwx owned by C. Each file therein has permissions ugo:r
> ...
>> I don't understand why my two machines are behaving so differently.
>
> uid difference between hosts A and B, most probably.
> Along the other things, thunderbird's apparmor policy contains this:
>
> owner @{HOME}/** r,
>
> I.e. it's allowed to read any file at /home as long as the file is owned
> by thunderbird's uid.
>
>
>> I don't think I really want apparmor running at all,
>
> Add apparmor=0 to kernel's cmdline. Building a kernel without apparmor
> helps with that too, but that's straying too far from Debian's defaults.
>
>
>> The debian wiki gives me a way to disable apparmor by patching grub,
>> but that seems like overkill.
>
> You probably got it wrong. Modifying a kernel cmdline and rebuilding
> grub with custom patches are different, and they should suggest former
> at Debian's wiki.
>
>
>> Does anyone pease have any suggestions on how to enable an application
>> without major surgery? any help appreciated. Thanks
>
> Disabling a problematic apparmor profile altogether is done by:
>
> /usr/sbin/aa-disable /usr/bin/thunderbird
>
> Disabling a problematic apparmor profile but keeping audit records
> generation is done by
>
> /usr/sbin/aa-complain /usr/bin/thunderbird
>
> You'll want the first one, probably.
>
> Reco
>
Thanks, Reco, that was just the information I needed. I had to install
apparmor-utils, but otherwise aa-disable did the job.
Cheers, Tony
--
Tony van der Hoff | mailto:tony@vanderhoff.org
Buckinghamshire, England |
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2021-01-29 16:50 +0100 |
| Message-ID | <BCEc2-7Q-3@gated-at.bofh.it> |
| In reply to | #231256 |
On Fri 29 Jan 2021 at 14:21:07 +0000, Tony van der Hoff wrote:
>
>
> On 29/01/2021 13:27, Reco wrote:
> > Hi.
> >
> > On Fri, Jan 29, 2021 at 12:49:42PM +0000, Tony van der Hoff wrote:
> > > This is a simplified scenario: Say I have 2 machines, both running Debian 10.7. Each machine has 3 users: A, B and C. Each machine has an identical (mantained
> > > by Unison) directoery: /home/C/pictures, with permissions ugo:rwx owned by C. Each file therein has permissions ugo:r
> > ...
> > > I don't understand why my two machines are behaving so differently.
> >
> > uid difference between hosts A and B, most probably.
> > Along the other things, thunderbird's apparmor policy contains this:
> >
> > owner @{HOME}/** r,
> >
> > I.e. it's allowed to read any file at /home as long as the file is owned
> > by thunderbird's uid.
> >
> >
> > > I don't think I really want apparmor running at all,
> >
> > Add apparmor=0 to kernel's cmdline. Building a kernel without apparmor
> > helps with that too, but that's straying too far from Debian's defaults.
> >
> >
> > > The debian wiki gives me a way to disable apparmor by patching grub,
> > > but that seems like overkill.
> >
> > You probably got it wrong. Modifying a kernel cmdline and rebuilding
> > grub with custom patches are different, and they should suggest former
> > at Debian's wiki.
> >
> >
> > > Does anyone pease have any suggestions on how to enable an application
> > > without major surgery? any help appreciated. Thanks
> >
> > Disabling a problematic apparmor profile altogether is done by:
> >
> > /usr/sbin/aa-disable /usr/bin/thunderbird
> >
> > Disabling a problematic apparmor profile but keeping audit records
> > generation is done by
> >
> > /usr/sbin/aa-complain /usr/bin/thunderbird
> >
> > You'll want the first one, probably.
> >
> > Reco
> >
>
> Thanks, Reco, that was just the information I needed. I had to install
> apparmor-utils, but otherwise aa-disable did the job.
Debian's default provision of apparmor is something I can take or
leave. Generally, I leave it by purging it from the system rather
than installing another unneeded package.
--
Brian.
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2021-01-29 18:00 +0100 |
| Message-ID | <BCFhM-Kl-5@gated-at.bofh.it> |
| In reply to | #231256 |
On Fri 29 Jan 2021 at 14:21:07 (+0000), Tony van der Hoff wrote:
> On 29/01/2021 13:27, Reco wrote:
> > On Fri, Jan 29, 2021 at 12:49:42PM +0000, Tony van der Hoff wrote:
> > > This is a simplified scenario: Say I have 2 machines, both running Debian 10.7. Each machine has 3 users: A, B and C. Each machine has an identical (mantained
> > > by Unison) directoery: /home/C/pictures, with permissions ugo:rwx owned by C. Each file therein has permissions ugo:r
> > ...
> > > I don't understand why my two machines are behaving so differently.
> >
> > uid difference between hosts A and B, most probably.
> > Along the other things, thunderbird's apparmor policy contains this:
> >
> > owner @{HOME}/** r,
> >
> > I.e. it's allowed to read any file at /home as long as the file is owned
> > by thunderbird's uid.
I'm assuming that you mean a file owned by the user who's running TB,
not that TB owns it. (Why would you want TB to own your own mail.)
> > […]
> > Disabling a problematic apparmor profile altogether is done by:
> >
> > /usr/sbin/aa-disable /usr/bin/thunderbird
> >
> > Disabling a problematic apparmor profile but keeping audit records
> > generation is done by
> >
> > /usr/sbin/aa-complain /usr/bin/thunderbird
>
> Thanks, Reco, that was just the information I needed. I had to install
> apparmor-utils, but otherwise aa-disable did the job.
Note that this change does not fix the problem of administering a
group of machines with different users' userids, assuming that
that actually *was* the underlying cause. Many utilities will cope
because they communicate with usernames, but archive files and
filesystems that are shared between machines will employ numeric
IDs, which convey the wrong information. Fixing apparmor just treats
one symptom.
(It's usual for different machines to have different *system* UIDs and
GIDs, except for a very short list. That's a different kettle of fish.)
Cheers,
David.
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.user
csiph-web