Hi Adrian, On 08.06.2018 15:50, Adrian Schröter wrote:
On Freitag, 8. Juni 2018, 15:31:59 CEST wrote Keil, Karsten>> Digging a little bit deeper in the repo server backend code, I found that some special handling for symlinks was introduced
In the BSHTTP::cpio_sender function and that the function has some support do follow symlinks, but this was not enabled in the calling function BSServer::reply_cpio, adding 'follow' => 1 as parameter to the call of BSHTTP::cpio_sender seems to fix this problem for me.
Questions: Is this valid as fix for now ? Is this a bug or is here some reason to forbid following symlinks ?
This is considered to be a security feature from our side. We could make it configurable though.
How is this affecting security? If I can create symlinks in /srv/obs/build/$project/$repo/$arch/:full/ on the build server, I can surely also patch out that check in BSHTTP.pm (as I'm doing right now ;-))
This kind of setup is not really 100% supported atm, is there any reason why you don't just use DoD functionality?
DoD just wastes space. DoD does not support file:// urls. Common setup: * have a SMT mirror of $ALL_SUSE_PRODUCTS on a NFS share. * mount that NFS share to /smtrepos * symlink everything into /srv/obs/build/.../:full/ * party on. I do this for all the SLE GM repos, and only DoD the update repos, because (if they are working correctly... ;)) I won't have to trigger new links / repo rescans manually. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org