SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
So gcc-solibs isn't unreasonable if software needs those libraries but youI don't want the entire gcc suite.
I am not a specialist in servers, but I heard multiple times that the presence of compilers in a server is considered a huge security issue, unless is about a build server.
Last edited by ZhaoLin1457; 11-15-2019 at 12:38 PM.
I am not a specialist in servers, but I heard multiple times that the presence of compilers in a server is considered a huge security issue, unless is about a build server.
Having an attacker gain access to a server is a huge security issue. At that point installing a compiler is QED.
Security is all a matter of risk management. Since computing platforms have lots of layers, you try to minimize risk at each layer, not just some of the layers. Keeping the installed packages as minimal as possible, and not having a compiler on the host reduces the risk. Nobody in the security space recommends having a compiler installed on a server.
Anyway, should I take this response to mean that slackware policy is to install the compiler should something link against atomics?
I am not very sure about your request, as libatomic is already included in aaa_elflibs (in current, at least, I don't have a 14.2 to check against). You don't need to install GCC.
Quote:
Originally Posted by akschu
Any thoughts on making the GCC libraries their own package? I have some software that links against libatomic which is forcing me to install the entire GCC compiler on a server, which is unwanted.
I am not very sure about your request, as libatomic is already included in aaa_elflibs (in current, at least, I don't have a 14.2 to check against). You don't need to install GCC.
Thanks for that! That is exactly what I was looking for. Didn't realize that was already a thing in -current. I'll work around it for now and keep waiting for 15.0.
I am not very sure about your request, as libatomic is already included in aaa_elflibs (in current, at least, I don't have a 14.2 to check against). You don't need to install GCC.
And yes, libatomic is not included in the 14.2 aaa_elflibs package.
Quote:
Originally Posted by akschu
Security is all a matter of risk management. Since computing platforms have lots of layers, you try to minimize risk at each layer, not just some of the layers. Keeping the installed packages as minimal as possible, and not having a compiler on the host reduces the risk. Nobody in the security space recommends having a compiler installed on a server.
How does a compiler increase the attack surface when its installed, but not being used?
You can get Audacity (and a pile of other DAW software) from alienBOB's repo. Probably easier getting it that way than getting it added to the official package list.
eliloconfig: don't write a boot entry for Slackware in the EFI boot menu if there's already one.
Rationale:
The user is advised to run eliloconfig after a kernel upgrade.
eliloconfig will then find an old entry in the EFI boot menu and suggest to remove it, then write a new one.
But the EFI boot entry in the firmware boot menu just points to elilo.efi, which will not be modified.
So writing a boot entry if one already exists is useless.
Thus I propose that eliloconfig proposes to write a boot entry in the EFI menu only if there's none yet.
This will preserve the NVRAM. Quoting Max Tottenham[1]:
Quote:
I'm weary of this approach, at least in the UEFI case I'd be weary of writing to NVRAM backed EFI variables, as I'm pretty sure these NVRAM chips have pretty low write limits (1-10k write cycles) and are meant to be updated pretty infrequently.
I wouldn't want to create an interface that developers might use thinking that it's fine to stick stuff in there on every boot, only to find out their NVRAM becomes a ROM after a couple of years.
We don't expect a kernel upgrade to be proposed every morning, but the safer the better.
Have seen PHP scripts disguised as image files being uploaded and executed (as www-user not root).
If a compiler is available, then such scripts can use it to create more sophisticated malware. Otherwise they may need to first download and setup the compiler which is not an easy task. Or they could download binaries off a server if they are already available.
Have seen PHP scripts disguised as image files being uploaded and executed (as www-user not root).
This would require the server admin to actually download such a file manually? How are they executed? Maybe I'm missing something obvious, but I can't recall the last time I downloaded an image file with a remote server let alone executed it or even made it executable.
This would require the server admin to actually download such a file manually? How are they executed? Maybe I'm missing something obvious, but I can't recall the last time I downloaded an image file with a remote server let alone executed it or even made it executable.
You as admin pick a PHP app and install it to your server - but in the payload is a rogue php script.
The script has been sneaked in in the development process of said app.
Don't you watch hacked movies? (just kidding)
The premise is not all development teams go by high security rules, assuming the "i'm not a probable target" approach to security.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
