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 typically have several long-running services and CLI tools running under separate service user accounts but using a similar set of modules. So I'd expect your approach to cost more disk space.
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. In the cloud case there is an image that you upload, this will be always smaller by a factor of ~1.3, and the volume can be the same.
Also I think that this can be resolved, using some better way to generate the first pyc in the local cache.
Compiling on-the-fly to a central location would possibly also result in security issues. So you would have to create a central pycache by byte-compiling during RPM post-install as root.
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.
Also .py? files shipped in RPMs at least are integrity-protected by RPM signature.
This will not change, the .py will live under this signature, and the pyc are side effects of those py. -- 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