> So, I want to move away from environment variables, except for LD_LIBRARY_PATH (and maybe PATH), which we can set easily enough before the scope's .so is loaded.
This sounds fine. The point of both is to make things convenient for the developer who may want to organize the code in a particular way or exec() something that is shipped in the click. > scope_directory() // returns the install dir, corresponds to XDG_CONFIG_HOME > cache_directory() // returns the dir that is writable to the scope, > corresponds to XDG_DATA_HOME Sure. > This leaves PATH, TMPDIR, XDG_RUNTIME_DIR, and UBUNTU_APPLICATION_ISOLATION. > > XDG_RUNTIME_DIR and TMPDIR need to be the same anyway, because TMPDIR has to > be a sub-directory of /run/user/<uid>, and the scope can't write to locations > "above" that, so it doesn't make sense to set XDG_RUNTIME_DIR to anything but > TMPDIR. Actually, on Ubuntu XDG_RUNTIME_DIR is set to /run/user/`id -u` as part of the user's login session. This should not be set to something else (and only explicitly set to '/run/user/`id -u`' it it isn't already. > We can add > tmp_directory() // returns a writable tmp directory somewhere below /run/user/<uid> > This will take care of TMPDIR and XDG_RUNTIIME_DIR. I think this is troublesome to only implement this method without setting TMPDIR. We set TMPDIR because well-written (ie, our system) libraries respect this. Not setting this and only offering tmp_directory() will make it so the developer has to know to set this separately if using some library or similar that is creating a temporary file. >For PATH, I'm not sure I see the point. The scope knows where it is installed (in scope_directory()). If the scope wants to exec something in its own bin directory, it can just exec it without having to rely on PATH. We can set a defined path, no problem. But whatever we set it to will have to be a standard path that is the same for all scopes, not containing any scope-specific directories. Well, again, this is all about consistency for developing on Ubuntu. If when writing an app you get PATH set, but don't for a scope, that seems inconsistent. I guess I just figured that all this would happen after the fork() but before the exec() of the scope-runner or the binary. It isn't clear to me why this would affect siblings or parents.... > That leaves UBUNTU_APPLICATION_ISOLATION. I did a Google search and couldn't find any doc on that specific variable. But is it really needed? It is understood that scopes are confined. If a scope really needs to find out whether it is currently under some Apparmor profile, it can just try doing something that won't work if confined. If the attempt fails, the scope knows it's currently confined. https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement#Launching_applications http://developer.ubuntu.com/publish/apps/security-policy-for-click-packages/ (see 'Runtime Environment') Also, I just want to restate that none of this is a security concern when a scope is confined since apparmor will make sure the scope is confined regardless of environment. I filed this bug in the hopes of making things consistent for the developer. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1327426 Title: scopes runner should set various confinement variables To manage notifications about this bug go to: https://bugs.launchpad.net/unity-scopes-api/+bug/1327426/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
