Bug#981817: [Pkg-privacy-maintainers] Bug#981817: onioncircuits: Permission denied: '/usr/local/lib/python3.7/dist-packages/psutil-5.7.2.dist-info'

2021-02-10 Thread Ulrike Uhlig

Hi!

On 10.02.21 13:08, Jonathan Marquardt wrote:

On Wed, Feb 10, 2021 at 12:26:35PM +0100, nodens wrote:

Yes, the apparmor profile shipped with onioncircuit won't allow access
to stuff in /usr/local. So python interpreter can't actually run.



You're right. Just as a test i added "/usr/local/** r," to
/etc/apparmor.d/local/usr.bin.onioncircuits and it works now.


If you prefer, I could reopen the bug and tag it as wontfix for clarity.


I really don't care.

Thank you again! And thank you to Ulrike as well!


I'm glad this was solved! And somehow cooperatively, I like that :)

Ulrike



Bug#981817: [Pkg-privacy-maintainers] Bug#981817: onioncircuits: Permission denied: '/usr/local/lib/python3.7/dist-packages/psutil-5.7.2.dist-info'

2021-02-10 Thread Jonathan Marquardt
On Wed, Feb 10, 2021 at 12:26:35PM +0100, nodens wrote:
> Yes, the apparmor profile shipped with onioncircuit won't allow access
> to stuff in /usr/local. So python interpreter can't actually run.
> 
> I would still advise against mixed system-wide stuff from debian package
> and from pip; and use virtualenv instead for any local needs, but this
> could probably also be worked around by:
> 
> - disabling the onioncircuits profile (not recommended), or
> - adding some local rules to allow access to /usr/local/ in
> /etc/apparmor.d/local/usr.bin.onioncircuits

You're right. Just as a test i added "/usr/local/** r," to 
/etc/apparmor.d/local/usr.bin.onioncircuits and it works now.

> If you prefer, I could reopen the bug and tag it as wontfix for clarity.

I really don't care.

Thank you again! And thank you to Ulrike as well!



Bug#981817: [Pkg-privacy-maintainers] Bug#981817: onioncircuits: Permission denied: '/usr/local/lib/python3.7/dist-packages/psutil-5.7.2.dist-info'

2021-02-10 Thread nodens
On 10/02/2021 11:02, Ulrike Uhlig wrote:
> Hi!
> 
> On 10.02.21 00:18, Jonathan Marquardt wrote:
>> On Fri, Feb 05, 2021 at 12:08:49PM +0100, Clément Hermann wrote:
>>> On 04/02/2021 13:04, Jonathan Marquardt wrote:
 On Thu, Feb 04, 2021 at 12:23:17PM +0100, Clément Hermann wrote:
> 
>> However I found out that it always works (on all of my systems) if I
>> launch
>> onionciruits with the command:
>>
>> $ python3 /usr/bin/onionciruits
>>
>> I have no idea why.
> 
> Could this be related to AppArmor?
> 
> Just a random idea.

Oh right. Of course. Thanks Ulrike :)


Yes, the apparmor profile shipped with onioncircuit won't allow access
to stuff in /usr/local. So python interpreter can't actually run.

I would still advise against mixed system-wide stuff from debian package
and from pip; and use virtualenv instead for any local needs, but this
could probably also be worked around by:

- disabling the onioncircuits profile (not recommended), or
- adding some local rules to allow access to /usr/local/ in
/etc/apparmor.d/local/usr.bin.onioncircuits

The existing rules in /etc/apparmor.d/usr.bin.onioncircuits could be
used as a starting point. I don't think it's relevant to include new
rules in the package.

If you prefer, I could reopen the bug and tag it as wontfix for clarity.

Cheers,

-- 
nodens



Bug#981817: [Pkg-privacy-maintainers] Bug#981817: onioncircuits: Permission denied: '/usr/local/lib/python3.7/dist-packages/psutil-5.7.2.dist-info'

2021-02-10 Thread Jonathan Marquardt
On Wed, Feb 10, 2021 at 10:39:23AM +0100, Clément Hermann wrote:
> "type python3" might tell you if you are maybe using an alternate
> python3 interpreter located in /usr/local when doing that. The shebang
> in onioncircuits explicitely uses /usr/bin/python3 which might be
> different that the one that is first in PATH.
> 
> I would recommend making sure any other, non-system python3 is
> self-enclosed (maybe in /opt) if needed. python-virtualenv might be a
> solution you want to have a look at: system python used for packages,
> and separated, local python for local code.

I'm using the normal python3 installation from the Debian repos, nothing 
special.

$ type python3
python3 is hashed (/usr/bin/python3)

> I'm going to close this bug, since it's not an issue on the package.
> 
> Thanks for the additional info, even if it's not a bug in the package
> this might be useful to other!

Well, at least I now have a workaround to get it running, so that's good 
enough for me.

Thank you for your time!



Bug#981817: [Pkg-privacy-maintainers] Bug#981817: onioncircuits: Permission denied: '/usr/local/lib/python3.7/dist-packages/psutil-5.7.2.dist-info'

2021-02-10 Thread Clément Hermann


On 10/02/2021 00:18, Jonathan Marquardt wrote:
> On Fri, Feb 05, 2021 at 12:08:49PM +0100, Clément Hermann wrote:

>> in a clean Buster virtual machine, I tried to pip3 install psutil then
>> install onioncircuits, and I didn't get this error (though I didn't try
>> with a graphical environment running). There must be something else
>> going on in your environment, maybe check the permissions on /usr/local
>> and below, or try to go the virtualenv route, or if you can, install the
>> python modules you need using Debian Packages (psutil has a recent
>> version available through buster-backports for instance).
>
> I played around a bit and found the following things:
>
> Clean install with Debian 10 with Gnome: onioncircuits works.
>
> After I run "pip3 install psutil" as root: onioncircuits doesn't work.
>
> After I run "pip3 uninstall psutil" as root: It works again.
>
> However I found out that it always works (on all of my systems) if I
launch
> onionciruits with the command:
>
> $ python3 /usr/bin/onionciruit
>
> I have no idea why.

"type python3" might tell you if you are maybe using an alternate
python3 interpreter located in /usr/local when doing that. The shebang
in onioncircuits explicitely uses /usr/bin/python3 which might be
different that the one that is first in PATH.

I would recommend making sure any other, non-system python3 is
self-enclosed (maybe in /opt) if needed. python-virtualenv might be a
solution you want to have a look at: system python used for packages,
and separated, local python for local code.

I'm going to close this bug, since it's not an issue on the package.

Thanks for the additional info, even if it's not a bug in the package
this might be useful to other!

Cheers,

-- 
nodens