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@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org