GNOME Bugzilla – Bug 777054
[review] lr/selinux: warn users if certificates are labelled incorrectly
Last modified: 2017-03-24 14:37:55 UTC
And provide an option to relabel them.
dnl Jansson for selinux configuration editing ^^^^^^^? for me (at least with my gtk theme), the info message appears on top of the window. Wouldn't it be nicer to have it close to the "Save" button? Now there are a lot of avc: denied { open } for scontext=system_u:system_r:openvpn_... messages in the terminal. Is that expected? -static const char certcon[] = "unconfined_u:object_r:home_cert_t:s0"; +#define CERTCON "..." - static const char scon[] = "system_u:system_r:openvpn_t:s0"; +#define SCON "..." + gs_free char *filename = NULL; + filename = gtk_file_chooser_get_filename (GTK_FILE_CHOOSER (widget)); This iterates over the GTK tree model to find the filenames in question. It assumes, that all files are indeed certificates. Is that so? Too bad we cannot ask libnm to give all certificate file properties of a connection :( (meta-data branch).
(In reply to Thomas Haller from comment #1) > dnl Jansson for selinux configuration editing > ^^^^^^^? Whoops, a copy&paste error. Fixed. > for me (at least with my gtk theme), the info message appears on top of the > window. Wouldn't it be nicer to have it close to the "Save" button? I think it's customary for revealers to be on top. > Now there are a lot of > avc: denied { open } for scontext=system_u:system_r:openvpn_... > messages in the terminal. Is that expected? Yes. I can't figure out how to make libselinux not print those messages. They may, in the end, come helpful though. > -static const char certcon[] = "unconfined_u:object_r:home_cert_t:s0"; > +#define CERTCON "..." > > - static const char scon[] = "system_u:system_r:openvpn_t:s0"; > +#define SCON "..." Kept this as it is i'd like to keep scon scoped and a constant seems much nicer than a #define/#undef pair. > + gs_free char *filename = NULL; > + > filename = gtk_file_chooser_get_filename (GTK_FILE_CHOOSER > (widget)); > This iterates over the GTK tree model to find the filenames in question. It > assumes, that all files are indeed certificates. Is that so? Too bad we > cannot ask libnm to give all certificate file properties of a connection :( > (meta-data branch). Yes. At some point, NMCertChooser may come helpful and we could just consider those. Unless a sensible way to get metadata for properties lands first.
f6444414a53e8f25becb025f7a9021d3f54921b7