GNOME Bugzilla – Bug 656052
gedit breaks use of user_xattrs
Last modified: 2018-05-24 13:16:43 UTC
Hi. It seems that gedit breaks the usage of at least user_xattrs (and probably of XATTRs and ACLs in general). When setting user_xattrs on any files these are lost as soon as I save the file in gedit. I presume that gedit rewrites them files as new files?! Not sure what should happen in case of "save as...", whether this should preserve xattrs/acls or not. Marking this as critical, as it could impose security issues, especially when the user_xattrs are somehow security relevant (e.g. used by intrusion detection systems or so) Cheers, Chris.
the version is 2.30.x, can you test with a newer version of gedit? por example 2.32.x or 3.0 thank
Well it happens in all versions including 3.0... 2.30 was just the first one where I've noticed this. And if nobody has changed anything in order to support xattrs, why should it have disappeared in the meantime.
Well, we depend on gio for writing files, so something could have changed on it.
Ah I see... ok.. mhh well... I guess the main problem is that the file is like be _recreated_ and not truncated and rewritten (or something like this),... which of course may impose other difficulties.... I guess this is a _general_ problem so perhaps this bug (and the "same" I've opened for Evolution) should be reassigned to something more general.
Having just rechecked with 3.14,... still an issue. Quite "outstanding" that such a security critical issue isn't fixed 3 years... o.O
Hmm, interesting: matej@mitmanek: ~$ getfattr -d attachment.cgi\?id\=282243 # file: attachment.cgi?id=282243 user.mime_type="text/plain; name=\"0001-Initial-set-of-automated-tests-for-gedit.patch\"; charset=" user.xdg.origin.url="https://bug734104.bugzilla-attachments.gnome.org/attachment.cgi?id=282243" matej@mitmanek: ~$ gedit attachment.cgi\?id\=282243 DEBUG:__init__:self.app = None DEBUG:do_activate:RopePluginWindowActivatable activate! DEBUG:__active_tab_state_cb:__active_tab_state_cb callback called! DEBUG:document:calling document property: None DEBUG:__active_tab_state_cb:COnnecting click event handler! matej@mitmanek: ~$ getfattr -d attachment.cgi\?id\=282243 matej@mitmanek: ~$ rpm -q gedit gedit-3.14.3-9.0.3.el7.x86_64 matej@mitmanek: ~$ (that is with https://git.gnome.org/browse/gedit/commit/?id=c1f59ef858a2b6b14f4c05f49cb8d5b4a1642451 applied)
From #gedit: mcepl: Have anybody anything interesting to say about https://bugzilla.gnome.org/show_bug.cgi?id=656052 ? A: mcepl: I assume that is due to writing to a temporary file and then doing an atomic rename/replace A: not much to do but modify the code in gtksourceview, but I guess this isn't something that many people mind B: (ie: the only way to atomicaly replcae a file) B: not doing the newfile+rename is far worse, because you possibly write broken files overwriting old contents B: but copying the xattrs over might be possible, depending on the file-system implementation and LSM at play A: seems gio even has a bug with that part of it, https://git.gnome.org/browse/gtksourceview/tree/gtksourceview/gtksourcefilesaver.c#n465 B: either way, that almost certainly belongs in Gio mcepl: B: well, Gio or Gtksourceview B: G_FILE_CREATE_REPLACE_DESTINATION should probably be respected and fixed in Gio. i don't see a reason for it to be done in GtkSourceView mcepl: ok
Well...if you edit a file you downloaded, should it really still have user.xdg.origin.url set? Is something the "same file" starts to become rather philosophical. I suspect the first pass at this is for gio to support infrastructure to copy user xattrs for REPLACE_DESTINATION as an opt-in behavior, and allow applications to choose it if they wish?
*** Bug 623161 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/434.