Description of problem: By default, Lua allows loading code from the current directory, and Fedora doesn't change this in packaged scripts installed in the system path. This has security implications. Steps to Reproduce: 1. Install any package that provides a #!/usr/bin/lua script, such as (but not limited) to luarocks 2. In the terminal: echo 'os.execute("echo rm -rf /")' > lfs.lua; luarocks --version Actual results: $ luarocks --version rm -rf / /usr/bin/lua: /usr/share/lua/5.4/luarocks/fs/lua.lua:299: attempt to index a boolean value (upvalue 'lfs') stack traceback: /usr/share/lua/5.4/luarocks/fs/lua.lua:299: in function 'luarocks.fs.lua.current_dir' (...tail calls...) /usr/share/lua/5.4/luarocks/fs/unix.lua:50: in function 'luarocks.fs.unix.absolute_name' (...tail calls...) /usr/share/lua/5.4/luarocks/fs/linux.lua:8: in function 'luarocks.fs.linux.is_dir' (...tail calls...) /usr/share/lua/5.4/luarocks/fs/lua.lua:193: in function 'luarocks.fs.lua.dir' (...tail calls...) /usr/share/lua/5.4/luarocks/fs/lua.lua:177: in function 'luarocks.fs.lua.list_dir' (...tail calls...) /usr/share/lua/5.4/luarocks/fs/lua.lua:229: in function 'luarocks.fs.lua.modules' (...tail calls...) /usr/share/lua/5.4/luarocks/cmd.lua:511: in function 'luarocks.cmd.run_command' /home/augusto/Projects/digestif/.luarocks/lib/luarocks/rocks-5.4/luarocks/3.9.2-1/bin/luarocks:35: in main chunk [C]: in ? Expected results: $ luarocks --version /usr/bin/luarocks 3.9.1 LuaRocks main command-line interface Additional info: I'm using the following fix on a Lua program I maintain: #!/usr/bin/env lua -- Remove relative directories from package path package.path = package.path:gsub("%f[^\0;]%.[^;]*", ""):gsub(";+", ";"):gsub("^;", ""):gsub(";$", "") package.cpath = package.cpath:gsub("%f[^\0;]%.[^;]*", ""):gsub(";+", ";"):gsub("^;", ""):gsub(";$", "") Fedora can probably do better and use hardcoded pacakge.path and cpath values, since these are known in advance. Scripts with the #!/usr/bin/texlua shebang also might be affected by this issue. Since texlua provides an alternative method to find packages based on kpathsea, something like this should be used as well: os.setenv("TEXMFDOTDIR", "/dev/null") However, this last modification will break programs that expect to find TeX files in the current directory. I don't know of a more fine grained way that would allow that but still exclude random Lua libraries from being found.
I can see the concern here. Right now, this is what we get for Linux from upstream (from luaconf.h, which is luaconf-$ARCH.h on Fedora): #define LUA_ROOT "/usr/" #define LUA_LDIR "/usr/share/lua/" LUA_VDIR "/" #define LUA_CDIR "/usr/lib64/lua/" LUA_VDIR "/" #if !defined(LUA_PATH_DEFAULT) #define LUA_PATH_DEFAULT \ LUA_LDIR"?.lua;" LUA_LDIR"?/init.lua;" \ LUA_CDIR"?.lua;" LUA_CDIR"?/init.lua;" \ "./?.lua;" "./?/init.lua" #endif #if !defined(LUA_CPATH_DEFAULT) #define LUA_CPATH_DEFAULT \ LUA_CDIR"?.so;" LUA_CDIR"loadall.so;" "./?.so" #endif Trawling backwards in time through lua's GitHub, it looks like ./?.lua, ./?/init.lua, and ./?.so were moved to the end of the PATHs in 2009 (so that they wouldn't be loaded first), but it has looked for these since November 2004. I am worried that while this may be the right thing to do from a security perspective, removing these ./ items here may cause lots of lua programs to simply stop working, because they have been assuming that ./ paths are valid. On top of that, no other distribution (I checked Debian, Ubuntu, SuSE, Gentoo, Arch) is changing LUA_PATH_DEFAULT or LUA_CPATH_DEFAULT. I'm concerned about the user experience if lua just "stops working right" on Fedora (and eventually, RHEL). Checking lua-l seems to reinforce that: A) there is a legitimate concern here B) removing the . items from the path may break things C) the better way of doing it (using the invoked script path instead of ./) is hard http://lua-users.org/cgi-bin/namazu.cgi?query=.%2F%3F.lua&idxname=lua-l&max=10 But, I suspect you know all this already, since I found your thread here: http://lua-users.org/lists/lua-l/2022-12/msg00011.html ****** I don't mean to discount your concern, in fact, I share it. But I am reluctant to make a Fedora specific change to the way Lua operates. I would strongly prefer if upstream would take a change to their default behavior that Fedora could inherit. As a proof of concept, I worked up this patch: https://spot.fedorapeople.org/lua-5.4.4-unsafe-paths.patch Notably, this causes the lua test suite to fail immediately during package build. It's easy enough to hack around ( I just export LUA_PATH=";;./?.lua" ) but it demonstrates how this will break a lot of lua mindset assumptions. I would be interested in which approach you think is most likely to succeed upstream.
This message is a reminder that Fedora Linux 37 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '37'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 37 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 37 entered end-of-life (EOL) status on 2023-12-05. Fedora Linux 37 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.