[+] drama (attempting configureProjectForLd)

This commit is contained in:
Reece Wilson 2021-11-15 18:34:46 +00:00
parent 2939130f6e
commit 9c6114e6fb
3 changed files with 77 additions and 1 deletions

View File

@ -14,6 +14,7 @@ local platforms = {
devChainRequiresElfStrip = true,
devChainSupportsElfStrip = true,
devChainCoreUtils = true,
elfSupportsRPath = true,
exts = {
SharedLib = ".so"
}
@ -25,6 +26,7 @@ local platforms = {
devChainRequiresElfStrip = true,
devChainSupportsElfStrip = true,
devChainCoreUtils = true,
elfSupportsRPath = true,
exts = {
SharedLib = ".so"
}

View File

@ -185,6 +185,77 @@ local function configureProjectForTarget()
auRequire("Core/Target").startProject()
end
local function configureProjectForLd(prj)
-- I'm not going to deal with this argument
--
-- I don't care for the opinions of greybeards who are stuck in the opinions put forth by AT&Ts meme of an OS
-- In *NIX land, you have +X, use it. I don't want to hear about how operating systems that have more aggressive
-- executable policies than macos and windows, with their vast ecosystem of file system sandboxing extensions,
-- can't cope with loosely following the intentions of the NT loader for the sake of uniformity across platforms.
--
-- https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#standard-search-order-for-desktop-applications
--
-- inb4 LD_LIBRARY_PATH screeching as if users should be expected to mess around with env vars before launching
-- each application. no, just no.
--
-- inb4 muh security. A malcious dependency injection would be the product of a hostile manipulation of the accessible
-- file system files and/or directories. Both are systematic issues we aren't going to make a dent in. The latter being
-- the fundamental issue your administrators should be focused on mitigating; sandbox all apps that could perform hostile IO.
-- If an attacker can write a malicious module or system lib proxy somewhere, you've failed basic attack mitigation,
-- and you're going to be pwned on non-POSIX targets no matter what.
-- Elevation exploits shouldn't be a problem so long as the linkoptions order is maintained so that $origin and then
-- system libraries are considered before any malcious user-installed libraries could possibly be loaded.
-- If you're running a broken arse system with missing protected libraries and you run software as write-level groups,
-- you have bigger issues than my 'lets treat POSIX systems more like NT for cross-compatibility and sanity' assumption.
-- If you're worried about ld.so running unsigned code, go complain to glib iq-lets who maintain ld.so and force them
-- into developing actual .text and .rodata signature validation with respect to a global root-writable certificate,
-- instead of spreading the ball of responsiblity like hot-fucking-potato in a game of respecting the UNIX :tm: way
-- of doing things (IE, expecting the user to know how to lockdown vendor supplied packages, RO all LD_LIBRARY_PATHs
-- and other undocumented vendor paths, and do god knows what to harden specific softwares dumped without thought
-- across an arahic FHS/XDG tree, while the developers do jack shit to improve stability, maintainablity, and security).
--
-- Change my mind (without parroting what some dude said on some forum over a decade ago)
if (prj.projectType ~= "SharedLib" and
prj.projectType ~= "WindowedApp" and
prj.projectType ~= "ConsoleApp") then
return
end
if (not Aurora.Settings.bForceWin32EscLd) then
return
end
auFilterForConfigPlatforms(function(config, platform, arch)
local platform = Aurora.Platforms[platformName]
if (not platform) then
return
end
if (not platform.elfSupportsRPath) then
return
end
linkoptions { "-Wl,-rpath,'$ORIGIN'", "-Wl,-rpath,'/lib'" }
if (arch == "x86_64" or arch == "arm") then
linkoptions { "-Wl,-rpath,'/lib64'" }
elseif (arch == "x86_32") then
linkoptions { "-Wl,-rpath,'/lib32'" }
end
linkoptions { "-Wl,-rpath,'$PWD'" }
linkoptions { "-Wl,-rpath,'/usr/lib'" }
if (arch == "x86_64" or arch == "arm") then
linkoptions { "-Wl,-rpath,'/usr/lib64'" }
elseif (arch == "x86_32") then
linkoptions { "-Wl,-rpath,'/usr/lib32'" }
end
end)
end
local function setupProject(prj)
print("project", prj.name)
@ -205,6 +276,7 @@ local function setupProject(prj)
configureProjectForPlatforms(prj.projectType)
configureProjectForTarget()
configureProjectForDebug(prj)
configureProjectForLd(prj)
defines "_AU_HAS_ATOMIC_INTRINS"
defines("_AU_BUILDING_" .. string.upper(prj.projectType))
@ -270,7 +342,7 @@ local function setupProject(prj)
end, root)
buildHooks.startProject(prj.name, prj.projectType)
auForEach(prj.dest, function(v)
addDest(prj.name, prj.projectType, v)
end)

View File

@ -102,6 +102,8 @@ auSetDefault(settings, "bForceClangWin32", false)
-- G++ is a mess whose future I don't care for. Not that libc++ doesn't do stupid thing on Linux, but au runtime takes care of a lot of things, so idc.
auSetDefault(settings, "bForceLLVMStl", true)
auSetDefault(settings, "bForceWin32EscLd", true)
-- Premake5 binary name to look for when when tied into cmake. Used by build actions and other lua scripted features
auSetDefault(settings, "sDefaultCmakePremakeBin", "premake5")