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 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.
Yes, the size for shipping the software will be reduced. But not the actually used disk size. So only the first argument is left.
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?
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.
Note that I wrote .py?, not .py*. Ciao, Michael.
-- Michael Ströder Klauprechtstr. 11 Dipl.-Inform. D-76137 Karlsruhe, Germany Tel.: +49 721 8304316 Mobil: +49 170 2391920 E-Mail: michael@stroeder.com https://www.stroeder.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org