Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
cmd: make locking around namespaces explicit #3149
Conversation
zyga
added some commits
Apr 6, 2017
All checks have passed
Some checks were not successful
Some checks were not successful
Some checks were not successful
Some checks were not successful
zyga
referenced this pull request
Apr 6, 2017
Merged
snap-confine: add code to ensure that / or /snap is mounted "shared" #3136
| + gint exit_status = 0; | ||
| + GError *error = NULL; | ||
| + | ||
| + argv = calloc(5, sizeof *argv); |
mvo5
Apr 6, 2017
Collaborator
What is the advantage of doing this (and the following 14 lines) over:
const char *argv[] = { "rm", "-rf", "--", dir, NULL };
mvo5
Apr 6, 2017
Collaborator
What about: char *argv[] = { "rm", "-rf", "--", (char*)dir, NULL }; then (especially since execv will not modify them, according to http://pubs.opengroup.org/onlinepubs/009604499/functions/exec.html). Anyway, one of the reasons why C code reviews make me grumpy.
zyga
Apr 7, 2017
Contributor
I mean that individual arguments need to be writable according to the API. That's why all the strdup's are up there.
mvo5
Apr 7, 2017
Collaborator
The opengroup page is an interessting read (the RATIONAL part about argv) to see why argv is char*. i.e. The statement about argv[] and envp[] being constants is included to make explicit to future writers of language bindings that these objects are completely constant. Due to a limitation of the ISO C standard, it is not possible to state that idea in standard C.. But shrug things like this make me do as little as possible with C code.
| + return lock_fd; | ||
| +} | ||
| + | ||
| +int sc_lock_global() |
| sc_initialize_ns_groups(); | ||
| + // TODO: implement this. | ||
| + debug("share snap directory here..."); | ||
| + sc_unlock(NULL, global_lock_fd); |
| struct sc_ns_group *group = | ||
| sc_open_ns_group(snap_name, SC_NS_FAIL_GRACEFULLY); | ||
| if (group != NULL) { | ||
| - sc_lock_ns_mutex(group); |
mvo5
Apr 6, 2017
Collaborator
It seems cmd/snap-confine/ns-support.h still has a reference in the header to this one?
zyga
added some commits
Apr 6, 2017
Some checks were not successful
Some checks were not successful
|
The errors show some issues in the CI setup. We're executing snap-confine under a profile that doesn't have the correct rules but those rules are now present in the tree. Probably the run-from-core logic is faulty somewhere. I'll investigate this now. |
zyga
added some commits
Apr 13, 2017
All checks have passed
mvo5
approved these changes
Apr 18, 2017
Looks good (but needs a second review). I still dislike https://github.com/snapcore/snapd/pull/3149/files#r110140992 but shrug its just tests.
zyga commentedApr 6, 2017
This branch allows anyone to use new locking primitives (sc_lock/sc_unlock) and
makes the namespace module not do any locking anymore. Locking is now moved
explicitly to happen in snap-confine so that we can do various initialization
under one global lock and then some more initialization under per-snap lock.
This will allow us to move the sharing of /snap to inside snap-confine and have
support for running inside containers and running with deputy systemd.
Signed-off-by: Zygmunt Krynicki zygmunt.krynicki@canonical.com