Symlinks need special handling?

[lovehumans]

I'm using dotstate to symlink folders/files into a GIT repo for backup of configs.
I made a custom profile for a new harness, allowing the tool's config dir with:

  "filesystem": { "allow": ["$XDG_STATE_HOME/zot"]}

that didn't allow the symlinked files, so I tried adding the target of the symlinked files:

  "filesystem": {
    "allow": [
      "$XDG_STATE_HOME/zot",
      "$HOME/.config/dotstate/.local/state/zot"
    ],

but that also didn't work.
I tried cat on the individual files through the profile and got asked to add them, that got saved into the profile under the "read_file".

So what is the intended workflow for symlinks?
Do symlinked files have to be mentioned individually? Is there no way to allow a whole directory, including the symlinked files?

[nf-matt]

Which platform are you on? On Mac, the underlying Seatbelt sandbox that nono uses does not allow symlinks to be used as circumvention for permitted directories/files. You have to explicitly allow what they point to as well, AFAIK.

[lovehumans]

Linux (7.1.4-1-cachyos), so Landlock LSM.
The symlinks that sit in $XDG_STATE_HOME/zot are pointing to files in $HOME/.config/dotstate/.local/state/zot.
I assumed this would suffice, but it doesn't.

[nf-matt]

If sandboxed code wrote a symlink, it would be able to get access to any file it wanted, so I'm good with needing to explicitly allow what the symlinks point to. I realize this is a bit more work on me to configure, but I'm ok with it for the added security.

[lovehumans]

What you wrote is beside the point of this bug report.

Allowing both the source and target dir of a symlink, doesn't allow that symlink.
Each symlinked file has to be manually allowed.