In the case of an album that contains only subalbums, subalbums are not visible from anonymous user access via direct link

[rm-61]

Lychee version

v6.7.2

Did you check the latest Lychee version?

No, I am not using the latest version

Which PHP version are you using?

PHP 8.4

Detailed description of the problem

The behaviour is correct on an v4.0.8 gallery, which is installed on the same server as the v6.7.2 gallery. Screenshot of the former case:

Here, all subalbums are visible.
Screenshot of the v6.7.2 case:

BTW: (off topic) I found that newer versions do no longer present that nice hovered album items with two different (partial) images behind the foreground image. If this feature has been lost, it's a real pity!

Steps to reproduce the issue

1. create a structure with a toplevel album that contains subalbums, which each contain images.
2. enter the toplevel album, copy its URL into the clipboard
3. get into "about album" and allow anonymous users to access an album via direct link, eventually also a password.
4. then open another browser and paste the clipboard content to the URL line. The screen is supposed to look like shown in the second screenshot (eventually after entering a password).

Diagnostics [REQUIRED]

Self-diagnosis:

Info: Full directory permission check is disabled
Warning: You may experience problems when uploading a photo of large size. Take a look in the FAQ for details.
Warning: You may experience problems when uploading a photo of large size. Take a look in the FAQ for details.
Warning: You may experience problems when uploading a photo of large size or handling many/large albums. Take a look in the FAQ for details.
Info: Found 1 small that could be generated.
You can use php artisan lychee:generate_thumbs small 1 to generate them.
Info: Found 1 small2x that could be generated.
You can use php artisan lychee:generate_thumbs small2x 1 to generate them.
Info: Found 1 placeholders that could be generated.
You can use php artisan lychee:generate_thumbs placeholder 1 to generate them.
Info: Have you considered supporting Lychee? :)
Warning: Imagick is not allowed to create thumbs for pdf files.
Verify that the /etc/ImageMagick-6/policy.xml file contains the line .

Info:

Lychee Version (release): 6.7.2
DB Version: 6.7.2

Docker: false
composer install: --no-dev
APP_ENV: production
APP_DEBUG: false
APP_URL: set
APP_DIR: default
LOG_VIEWER_ENABLED: true

System: Linux
PHP Version: 8.4.25
PHP User agent: Lychee/6 (https://lycheeorg.dev/)
Timezone: Europe/Berlin
Max uploaded file size: 20M
Max post size: 60M
Chunk size: 12.80 MB
Max execution time: 30
SQLite Version: 3.40.1

exec() Available: yes
Imagick Available: 1
Imagick Enabled: 1
Imagick Version: 1691
GD Version: 2.3.3
Number of foreign key: 13 found.

Config:

version: 060702
check_for_updates: 0
sorting_photos_col: taken_at
sorting_photos_order: ASC
sorting_albums_col: max_taken_at
sorting_albums_order: ASC
imagick: 1
skip_duplicates: 0
small_max_width: 0
small_max_height: 360
medium_max_width: 1920
medium_max_height: 1280
lang: en
image_overlay_type: desc
default_license: reserved
compression_quality: 80
grants_full_photo_access: 1
delete_imported: 0
mod_frame_enabled: 1
mod_frame_refresh: 30
thumb_2x: 0
small_2x: 1
medium_2x: 0
landing_page_enable: 0
search_public: 0
hide_version_number: 0
recent_age: 1
grants_download: 0
photos_wraparound: 0
map_display: 0
zip64: 1
map_display_public: 0
map_provider: Wikimedia
map_include_subalbums: 0
update_check_every_days: 3
has_exiftool: 1
share_button_visible: 0
import_via_symlink: 0
has_ffmpeg: 0
location_decoding: 0
location_decoding_timeout: 30
location_show: 1
location_show_public: 0
rss_enable: 0
rss_recent_days: 7
rss_max_items: 100
prefer_available_xmp_metadata: 0
editor_enabled: 1
lossless_optimization: 0
local_takestamp_video_formats: .avi|.mov
log_max_num_line: 1000
unlock_password_photos_with_url_param: 0
nsfw_visible: 1
nsfw_blur: 0
nsfw_warning: 0
nsfw_warning_admin: 0
nsfw_banner_override:
map_display_direction: 1
album_subtitle_type: oldstyle
upload_processing_limit: 4
new_photos_notification: 0
zip_deflate_level: 6
default_album_protection: 1
album_decoration: layers
album_decoration_orientation: row
allow_username_change: 0
auto_fix_orientation: 1
use_job_queues: 0
random_album_id: starred
use_last_modified_date_when_no_exif_date: 0
layout: justified
date_format_photo_thumb: M j, Y, g:i:s A e
date_format_photo_overlay: M j, Y, g:i:s A e
date_format_sidebar_uploaded: M j, Y, g:i:s A e
date_format_sidebar_taken_at: M j, Y, g:i:s A e
date_format_hero_min_max: F Y
date_format_hero_created_at: M j, Y, g:i:s A T
date_format_album_thumb: M Y
upload_chunk_size: 0
nsfw_banner_blur_backdrop: 0
search_pagination_limit: 300
search_minimum_length_required: 4
photo_layout_justified_row_height: 320
photo_layout_masonry_column_width: 300
photo_layout_grid_column_width: 250
photo_layout_square_column_width: 200
photo_layout_gap: 12
display_thumb_album_overlay: always
display_thumb_photo_overlay: hover
default_album_thumb_aspect_ratio: 1/1
use_album_compact_header: 0
back_button_enabled: 0
back_button_text: Return to Home
SA_random_thumbs: 0
login_required: 0
enable_unsorted: 0
enable_starred: 0
enable_recent: 0
enable_on_this_day: 0
login_required_root_only: 1
dark_mode_enabled: 1
low_quality_image_placeholder: 1
show_keybinding_help_popup: 1
show_keybinding_help_button: 1
disable_se_call_for_actions: 0
enable_se_preview: 0
slideshow_timeout: 4
keep_original_untouched: 1
timeline_photos_enabled: 1
timeline_photos_public: 0
timeline_photos_granularity: day
timeline_photos_order: taken_at
timeline_photos_layout: square
timeline_photos_pagination_limit: 200
timeline_albums_enabled: 1
timeline_albums_public: 0
timeline_albums_granularity: year
timeline_left_border_enabled: 1
timeline_photo_date_format_year: Y
timeline_photo_date_format_month: M Y
timeline_photo_date_format_day: j M Y
timeline_photo_date_format_hour: g:i
timeline_album_date_format_year: Y
timeline_album_date_format_month: M Y
timeline_album_date_format_day: j M
hide_nsfw_in_smart_albums: 1
hide_nsfw_in_frame: 1
hide_nsfw_in_map: 1
hide_nsfw_in_search: 1
search_photos_layout: square
hide_nsfw_in_rss: 1
hide_nsfw_in_timeline: 1
number_albums_per_row_mobile: 3
cache_enabled: 0
cache_ttl: 86400
low_number_of_shoots_per_day: 10
medium_number_of_shoots_per_day: 50
high_number_of_shoots_per_day: 100
maintenance_processing_limit: 5000
disable_recursive_permission_check: 1
exif_disabled_for_all: 0
file_name_hidden: 0
default_old_settings: 0
default_expert_settings: 0
default_all_settings: 0
client_side_favourite_enabled: 0
disable_thumb_download: 1
disable_thumb2x_download: 1
disable_small_download: 0
disable_small2x_download: 0
disable_medium_download: 0
disable_medium2x_download: 0
temporary_image_link_enabled: 0
temporary_image_link_when_logged_in: 0
temporary_image_link_when_admin: 0
temporary_image_link_life_in_seconds: 86400
secure_image_link_enabled: 0
SA_override_visibility: 0
TA_override_visibility: 0
enable_colour_extractions: 0
colour_extraction_driver: farzai
home_page_default: gallery
flow_enabled: 0
flow_public: 0
flow_base:
flow_max_items: 10
flow_strategy: auto
flow_include_sub_albums: 0
flow_include_photos_from_children: 0
flow_open_album_on_click: 0
flow_display_open_album_button: 0
flow_highlight_first_picture: 1
flow_min_max_enabled: 1
flow_display_statistics: 1
flow_compact_mode_enabled: 1
flow_image_header_enabled: 1
flow_image_header_cover: cover
flow_image_header_height: 24
flow_carousel_enabled: 1
flow_carousel_height: 6
date_format_flow_published: M j, Y, g:i:s A e
date_format_flow_min_max: F Y
flow_blur_nsfw_enabled: 1
hide_nsfw_in_flow: 1
skip_duplicates_early: 1
sync_delete_missing_photos: 0
sync_delete_missing_albums: 0
sync_dry_run: 1
gallery_header_enabled: 0
gallery_header_logged_in_enabled: 0
gallery_header:
gallery_header_bar_transparent: 1
gallery_header_bar_gradient: 1
import_via_url_forbidden_localhost: 1
import_via_url_forbidden_local_ip: 1
import_via_url_require_https: 1
import_via_url_forbidden_ports: 1
details_links_enabled: 1
details_links_public: 1
is_scroll_to_navigate_photos_enabled: 1
is_swipe_vertically_to_go_back_enabled: 1

Browser & System [REQUIRED]

Chromium 150.0
Kubuntu 24.4
Server: Debian bookworm

Please confirm (incomplete submissions will not be addressed)

• I have provided easy and step-by-step instructions to reproduce the bug.
• I understand my bug report will be removed if I haven't met the criteria above.
• I understand that if I am requested to provide more information, I must do so within 14 days or the bug report will be closed.

[ildyria]

BTW: (off topic) I found that newer versions do no longer present that nice hovered album items with two different (partial) images behind the foreground image. If this feature has been lost, it's a real pity!

Yes, that was necessary for speed optimization. I really liked it too, but sacrifices had to be made when you are dealing with 100 000 of pictures in deep nested sub albums.

Also, I strongly recommend you to upgrade ASAP to the latest version. It is extremely likely that you are vulnerable to many of these: https://github.com/LycheeOrg/Lychee/security/advisories?state=published

create a structure with a toplevel album that contains subalbums, which each contain images.

1. enter the toplevel album, copy its URL into the clipboard
2. get into "about album" and allow anonymous users to access an album via direct link, eventually also a password.
3. then open another browser and paste the clipboard content to the URL line. The screen is supposed to look like shown in the second screenshot (eventually after entering a password).

Question, does the sub albums have their access set to public visible? If not. then Yes that is the intended behavior

[rm-61]

Question, does the sub albums have their access set to public visible? If not. then Yes that is the intended behavior

Yes, public visible, but with the same password. When I change one of the two sub-albums to have access without password, it is shown. But that's not what I want. Then I have inspected precisely how I did it in the 2022 album set (using 4.0.8). Here, I set the toplevel album as public, and album and subalbums had not set the "Hidden" option (direct link needed). Now I did the same in the current Album in 6.7.2. Voilà - visible.

Today I realize that the hidden option only has a meaningful effect with toplevel albums, because these are otherwise shown when I open the public (gallery) URL (of course in the case that the main "switch" public is active). On levels below that, this option will hide any such assigned sub-album thumbnail, except when a direct link is provided for such album. I hardly see a practical use case for doing so. Hence on all sub-album levels the hidden option could eventually be removed in the corresponding visibility submenu (if I think false, please correct me).
Given the above, an album password can be set on any album or sub-album whose URL is sent to others via e-mail or other communication channels, and when private stuff is present (in my 2022 album set), I applied the same password for each album with private content (entering password one time automatically releases other albums with the same password). Other, less intimate friends became the opportunity to view all albums with less private images.

Final word: sorry that I thought that I had found a bug!

Regarding

Also, I strongly recommend you to upgrade ASAP to the latest version.

I see the quite recent Album password bypass problem. That means that not only my old 4.0.8 should be upgraded...
But, speaking of the album password bypass, what is meant with

The attacker only needs the album's ID (a public album is reachable by its share link / ID

Is ID the 24-byte alphanumeric string in the album URL? Which would primarily be a matter of sharing an album link only with friends while writing them to delete the e-mail as soon as the URL is captured from the e-mail?
Another solution could be to create a single read-only user name (other than "guest") with associated password that can be sent to friends, in order to overcome the outlined risks with Album passwords.

[ildyria]

Today I realize that the hidden option only has a meaningful effect with toplevel albums

No :)

For example:

This is the view from public/guest.

But if I login as admin, I have that many albums in it:

So that allows me to have all the portraits that I took for different people, but while keeping some not directly browsable by moving around my website. But I can always give the direct URL of a hidden album to a friend and then they have access to their content.

Public Hidden albums are IMHO way more useful than password protected albums.

Final word: sorry that I thought that I had found a bug!

Your report is very much appreciated! It helps us make Lychee better. :)

Is ID the 24-bytecharacter base64 string in the album URL?

yes. It is actually a cryptographic secure string of 144 bits, so most likely better than most chosen passwords. :)
This is also why I don't bother to set password on my albums, because the ID is so strong in randomness.

[ildyria]

Another solution could be to create a single read-only user name (other than "guest") with associated password that can be sent to friends, in order to overcome the outlined risks with Album passwords.

That is indeed a more interesting solution due to the granular aspect of the permissions.

[rm-61]

Today I realize that the hidden attribute only has a meaningful effect with toplevel albums

No :)
[view without login]
But if I login as admin, I have that many albums in it:
[partial view]
So that allows me to have all the portraits that I took for different people, but while keeping some not directly browsable by moving around my website. But I can always give the direct URL of a hidden album to a friend and then they have access to their content.

I understand this use case. BTW: in your use case, the password bypass problem is not relevant, because you rely on hidden only. So in this case you could utilize a Lychee version where this problem is not fixed. Right?
Well, now I tell you why I prefer the combination of hidden AND password (let's focus on toplevel albums). I regard the transfer of the direct link over e-mail, messenger or social media as a potential risk that others get to it (think of hacked IMAP servers where your e-mails are stored - that's why I stick to POP3). An extra password (sent separately) poses a sort of method of last resort in order to make undesired access less probable.
In this use case, I must upgrade the Lychee software. In your use case, regardless upgrade or not: the risk that the base-64 ID gets in false hands is anyhow present. What do you think of this assumption?

I agree with you that a (preferably) non-standard read only login name and a non-guessable password (sent in two separate messages and a link in one of them) is more secure.
Nevertheless, hidden and album password is more elegant, because my friends merely need to click on the link in order to view below toplevel - necessarily a link with base-64 ID, secure without hidden attribute set because the hidden attribute does not act as an added access filter in this case). Effectively this attribute controls visibility of the album thumbnail.

To be generally precise: when I say album thumbnail or album, I mean the mere view of the album "cover". Otherwise I say album content.
My use case is an invisible toplevel album as a secure door (& image family cover) via direct link. Its subalbums must all be visible in order for the viewer-user to have an overview of the albums below any single toplevel album, regardless viewing limits of album contents. Even albums showing a key lock symbol are okay (if the password is another one). Because subalbums with hidden attribute set are not visible, this attribute must be unset as already acknowledged after discussion start.

Public Hidden albums are IMHO way more useful than password protected albums.

Password only access makes no sense, that's correct. Even in the light of the Album password problem, because the recipient of the password needs - to see the levels below toplevel album thumbnails - a direct link.

In the (possible) case that a direct link is supplied on any level below the toplevel, unset hidden atttributes do not impact security, because the direct link is inherently inavoidable in this case to point to the intended album (or image). You cannot step into it downwards from the toplevel because of the hidden state of its album thumbnails. An unset password on a subalbum could then be accessed freely on a direct link (I tested this), but as said: it offers the same security related to the content view, even regardless of its hidden attribute is set or not.
Well, yet I'm curious what you say to this bold displayed statement.