[BUG] salt cannot locate SLS files from symlinks that go outside of /srv/salt folder.

[ovybach]

Description salt-master cannot locate SLS files that are stored not in default file_root folder but is available through symlink there.

Setup

• [x] VM (hyper-v)
• [x] Rocky Linux 9.3
• [x] onedir packaging

3006.6 version for salt-master and salt-minion use default roots setup (that points base to /srv/salt)

Steps to Reproduce the behavior

1. Use 3006.6 for salt-master and salt-minion (used the same host for both)
2. Сreate a /srv/salt folder
3. Сreate a folder outside /srv/salt, for example: /opt/test
4. Make a symlink: ln -s /opt/test /srv/salt/test_sym
5. create a sample SLS file /srv/salt/test_sym/test.sls with content

t:
  cmd.run:
    - name: hostname

6. Execute /srv/salt/test_sym/test.sls state file: sudo salt '*' state.apply test_sym.test

Actual behavior

vm02rocky9:
    Data failed to compile:
----------
    No matching sls found for 'test_sym.test' in env 'base'

Expected behavior SLS file should be executed.

At least this worked in 3006.5 and previous versions.

Screenshots

Versions Report

salt --versions-report

Salt Version: Salt: 3006.6

Python Version: Python: 3.10.13 (main, Nov 15 2023, 04:34:27) [GCC 11.2.0]

Dependency Versions: cffi: 1.14.6 cherrypy: unknown dateutil: 2.8.1 docker-py: Not Installed gitdb: Not Installed gitpython: Not Installed Jinja2: 3.1.3 libgit2: Not Installed looseversion: 1.0.2 M2Crypto: Not Installed Mako: Not Installed msgpack: 1.0.2 msgpack-pure: Not Installed mysql-python: Not Installed packaging: 22.0 pycparser: 2.21 pycrypto: Not Installed pycryptodome: 3.19.1 pygit2: Not Installed python-gnupg: 0.4.8 PyYAML: 6.0.1 PyZMQ: 23.2.0 relenv: 0.14.2 smmap: Not Installed timelib: 0.2.4 Tornado: 4.5.3 ZMQ: 4.3.4

System Versions: dist: rocky 9.3 Blue Onyx locale: utf-8 machine: x86_64 release: 5.14.0-362.18.1.el9_3.x86_64 system: Linux version: Rocky Linux 9.3 Blue Onyx

[ovybach]

as far as I understood from this commit - e0cdb80b55123f4a024759ffcf2b3f0e0788e7ab this is now expected behavior, right? Salt will now ignore all SLS files that are not inside the "root" folder (/srv/salt or other configured)

[PaulChristophel]

If this is now expected behavior, an option in the master configs to allow this would be appreciated. This is breaking most of our environments, because we rely heavily on symlinks to share code between departments.

[strichter]

Since this seems to be because of a CVE, it is unlikely to be changed back. But there could be a much better error message! I have hit the error twice now in different scenarios and got different error messages.

[KaiwenXue]

If this is now expected behavior, an option in the master configs to allow this would be appreciated. This is breaking most of our environments, because we rely heavily on symlinks to share code between departments.

As a workaround, we've added the locations referenced by symlinks to the file_roots configuration for the salt-master. Then, we've updated our impacted states to no longer be traversing symlinks

[m0duspwnens]

If this is now expected behavior, an option in the master configs to allow this would be appreciated. This is breaking most of our environments, because we rely heavily on symlinks to share code between departments.

It seems that fileserver_followsymlinks and fileserver_ignoresymlinks would be used for this, but maybe I am misunderstanding the descriptions.

It would be helpful to know if this is expected behavior or unintended.

[ocfmatt]

Hello,

I have just run into this too and found this bug report after going round in circles between working clusters and one I have just built in a test environment.

If this is now expected behavior, an option in the master configs to allow this would be appreciated. This is breaking most of our environments, because we rely heavily on symlinks to share code between departments.

It seems that fileserver_followsymlinks and fileserver_ignoresymlinks would be used for this, but maybe I am misunderstanding the descriptions.

It would be helpful to know if this is expected behavior or unintended.

I tried these but they didn't appear to make any difference so I also could be misinterpreting their purpose or the CVE fixes has removed them and references to them need removing from the documentation.

Regards, Matt.

[tacerus]

We also found this to break our setup, as we heavily use symlinks to install formula state directories. The error message is quite misleading, especially the debug ones pretending the files would not exist at all:

[DEBUG   ] Could not find file 'salt://myformula.sls' in saltenv 'base'
[DEBUG   ] Could not find file 'salt://myformula/init.sls' in saltenv 'base'

[Timmeeh]

Also causing confusion here. It doesn't help that trying to list the files in the respective environment using salt-run fileserver.file_list does show the symlinked files / folders.

[KaneTW]

This desperately needs better documentation! Just spent a few hours deep in strace trying to figure out why my sls are failing despite the file existing.

I workarounded this via mount --bind.

[ysagon]

Hi, we have the same issue for files, not only sls files. We were using a state file.manage which uses as source a symlink to /etc/hosts located in /srv/salt/mystate/symhost and it isn't working anymore.

[ephreal]

Hello, I'm having the same issue and being unable to workaround this in any way whatsoever. This also causing issues in the context of a proxy server acting as a letsencrypt ssl cert renewal proxy for internal hosts that need valid ssl certs. Will there be an option to allow symlinks in the future? Perhaps a whitelist for symlinks that are known to be valid?

In my case, a symlink is the most logical and secure way of telling salt where to locate the certificates rather than adding the entire contents of letsencrypt/live to the salt env where it could accidentally be committed to the git repo (let alone the issues required to keep this new copy up to date as well).

[hurzhurz]

For a temporary workaround (until there will hopefully be a solution), maybe try what I already suggested in #66133:

Quick workaround would be to take the roots.py from 3006.5 (or older) and place it in /srv/salt/_fileserver (+ "salt-run saltutil.sync_fileserver" & salt-master restart): https://raw.githubusercontent.com/saltstack/salt/v3006.5/salt/fileserver/roots.py