After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 720039 - Symlink with relative path not followed in library
Symlink with relative path not followed in library
Status: RESOLVED OBSOLETE
Product: shotwell
Classification: Other
Component: alt-filesystem
0.14.1
Other Linux
: Normal minor
: ---
Assigned To: Shotwell Maintainers
Shotwell Maintainers
: 717286 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-12-07 20:02 UTC by Amir Eldor
Modified: 2021-05-19 13:59 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch to let gio follow symlinks (9.39 KB, patch)
2014-12-12 20:38 UTC, Felipe Reyes
needs-work Details | Review

Description Amir Eldor 2013-12-07 20:02:21 UTC
It seems that a relative link is not followed in the library folder. I tried an absolute path to the same folder, restarted shotwell, and the pictures were loaded.

For example, with library at `~Pictures`:

    1. ~/Pictures/other_place => '../more_pics'
    2. ~/Pictures/other_place => '/home/amir/more_pics'

In case 1 pictures were not loaded to the folder and in case 2 they were loaded.
Comment 1 Felipe Reyes 2014-12-12 14:50:03 UTC
Hi,

I'm using git-annex to backup my photos, so all my files are relative links to the git-annex storage and I confirm this is a problem.

I'm using shotwell 0.20.2


Example of one of the symlinks

$ ls Pictures/Photos/2014/01/01/IMG_6846.JPG -l
lrwxrwxrwx 1 freyes freyes 210 Jan  1  2014 Pictures/Photos/2014/01/01/IMG_6846.JPG -> ../../../../.git/annex/objects/qz/wX/SHA256E-s3304220--6fc568b0cb0796b5b07a1ac543843dc99562f2681b0b191670d6218b81a14c6e.JPG/SHA256E-s3304220--6fc568b0cb0796b5b07a1ac543843dc99562f2681b0b191670d6218b81a14c6e.JPG

Thanks,
Comment 2 Felipe Reyes 2014-12-12 20:37:39 UTC
Hi,

I prepared a patch to fix this, it worked for my photo collection, but I'm not sure if it's the proper way to fix this, I would really appreciate if the maintainers could review it.

Thanks,
Comment 3 Felipe Reyes 2014-12-12 20:38:42 UTC
Created attachment 292634 [details] [review]
patch to let gio follow symlinks
Comment 4 Jim Nelson 2014-12-15 20:15:43 UTC
Review of attachment 292634 [details] [review]:

My concern about this approach is that it appears to be a blindly changing every instance of NOFOLLOW_SYMLINKS to NONE without considering the consequences of each situation.  For example, if there's a symlink loop (i.e. ~/a/b/c where c is a symlink to a), there's no checking for that, leading to the possibility of an endless loop when recursing.  (For example, see search_dir() in BatchImport).

More to the point, are all these changes necessary to fix this specific bug, or are they simply being made to get rid of NOFOLLOW_SYMLINKS?  It looks like the latter to me.  The patch needs to address the reported problem so we can test that it solves that problem with some confidence without causing other issues elsewhere.
Comment 5 Jim Nelson 2014-12-15 20:16:07 UTC
*** Bug 717286 has been marked as a duplicate of this bug. ***
Comment 6 Andrej Shadura 2016-06-13 16:41:09 UTC
Any news on this?
Comment 7 Jens Georg 2016-06-13 18:01:26 UTC
Sorry, still wading through the +1000 tickets open for shotwell, takes a bit to check every one of them
Comment 8 anarcat+releases 2018-01-02 20:27:15 UTC
I'm testing this patch right now against 0.26.4 and it works fine. I agree there might be issues with symlink loops, but I would argue that you generally inspect directories that are trusted, unless you import files from third parties, in which case you probably have a whole other pile of security issues to worry about...

But I think Nelson is right that the patch should be more limited. In my use case, I don't think import should follow symlinks, but the library access should follow symlinks.
Comment 9 Jens Georg 2018-01-02 20:38:43 UTC
The remark about symlink loops is a bit odd, there is code in there that checks the filesystem ids to prevent exactly that - unless I misunderstand the import code and that might not be that far fetched.
Comment 10 anarcat+releases 2018-01-02 21:33:43 UTC
I wasn't aware of such checks. In that case, I don't have any objection to the patch.
Comment 11 GNOME Infrastructure Team 2021-05-19 13:59:01 UTC
-- 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/shotwell/-/issues/4431.