Mailinglist Archive: opensuse-factory (381 mails)

< Previous Next >
Re: [opensuse-factory] Re: [opensuse-packaging] Proposal to remove pyc/pyo from Python on TW
  • From: Alberto Planas Dominguez <aplanas@xxxxxxx>
  • Date: Fri, 05 Oct 2018 13:57:22 +0200
  • Message-id: <4326073.RfsSE0yApn@lena>
On Friday, October 5, 2018 1:24:27 PM CEST Michael Ströder wrote:
On 10/5/18 1:17 PM, Alberto Planas Dominguez wrote:
On Friday, October 5, 2018 1:02:39 PM CEST Michael Ströder wrote:
On 10/5/18 10:29 AM, Alberto Planas Dominguez wrote:
On Thursday, October 4, 2018 5:29:20 PM CEST Michael Ströder wrote:
I think that this is indeed the case for this scenario: running the same
code under different users will recreate the pyc under each user id.

Maybe I'm overlooking something but you will end up with at least same
disk size being used. So the argument with cloud storage does not count
at all.

Not necessarily is the case. For one your RPM will be smaller, your live
image will be smaller and your installer system can be smaller or the
same size. That depends on how /var/cache is managed and stored.

Yes, the size for shipping the software will be reduced. But not the
actually used disk size. So only the first argument is left.

No, you will have a pyc for each python module that is actually used. Not all
the Python code is used or eager loaded. This is why is less or equal. And
this is only for the system once that is running. And the py code will live in
a different place (a volume in case of cloud, RAM or any other file system),
so can be considered outside the system space.

In any case if your point is to make explicit that a cache is still wasted
space, yes, you are right. But we remove this space from the ISO image, and at
the same time we enable the chance of deciding where the cache is going to
live.

Also for security reasons I'd not want a tool to write code somewhere.
It's bad practice to let a service account write code somewhere. It
would seriously trigger my paranoia if someone adds rules to AppArmor
profiles allowing that.

Another good point.

For me that's a show-stopper.

For a naive approach like mine, can be. But having __pycache__ living in
another place do not contradict how and who generate the needed pyc files.
For example, a different approach can be to change the Python shim loader
to check if /var/cache is populated with the code, and if not compile it
under the same user always. This will guarantee the uid and gid of the
pyc files.
I don't understand:
If Python is started as non-privileged this user would need write access
to pycache. Or do you want to implement privilege escalation in the
Python shim loader?

Both are possibilities that can be explored. I do not know how to make the
first secured, as we do not want that a user change the pyc. But the second
one can be done in a secure way with a bit of care.


--
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham
Norton, HRB 21284 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany


--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >