Using the correct mount options for /tmp and /var

Trenix25

Well-Known Member
Joined
Aug 15, 2017
Messages
673
Reaction score
367
Credits
6,139
I have had a lot of trouble lately trying to install Parrot Linux. I just found out why early this morning. The /var subdirectory tree MUST be mounted with the exec and suid options. If it is mounted with noexec or nosuid it will break the package manager. The problem with AI is that it lacks discernment. It does not know whether something it reads online is actually true or false. Most people, sadly not all of them, but I hope most of them, know that not everything they read online is necessarily true. This is not the case with AI. When I asked Bing, and later going around and around with Copilot to try to find the source of my problem, I was told that /var should be mounted with noexec for security reasons. As it turns out some pinhead out there thought they knew what they were talking about when they clearly didn't know quite as much as they thought they did. They wrote on their web site that /var should be mounted with the noexec mount option and now Bing believes it. As a result I was getting all of these permission denied errors when I tried to install, remove, or upgrade packages with the package manager in Linux. Lynis told me that /tmp should be mounted with noexec as well. I found that to be a serious problem when I tried to install, remove, or upgrade packages with the package manager. Keep in mind that even though root is used when running apt, given that I use Debian, apt appears to drop privileges and run as _apt instead so it will still need access to certain places on the system and needs to be able to execute things in /tmp and /var. I like to have all of my file systems line up nice and neat when using /usr/bin/df and if I have to remount one or more file systems it just might change the order of the affected file systems in that list. I shouldn't have to remount both /tmp and /var just to run apt update or apt upgrade. And I certainly shouldn't have to reboot my system, which can take a half an hour or better to get rebooted, to get everyone logged back in, and get everything set up correctly everytime I use apt. Using an access control list (ACL) allows the root user to fine tune access to specific places for one or more specific users. In order for a normal user to change anything in a system area they would have to have write access to the area they were trying to change. A normal user shouldn't be able to install, remove, or upgrade packages on the system. Perhaps in their own home directory tree, but not in any system areas that could affect other users. It looks like too much trouble, in my own opinion, to have to remount both /tmp and /var just to update and upgrade, and then to have to remount both of them to use noexec afterwards "for security reasons" when a normal user couldn't do anything with /var anyway. They could write to /tmp and /var/tmp, but that's about all. Those scripts in /var will try to write to system areas and basic system level permissions would prevent a normal user from doing that, so no worries. As far as allowing allowing a normal user to run programs from /tmp it is worth noting that they could run their programs from their own home directory tree instead so it really shouldn't make any difference. A system administrator could use fuser or ps to find out which user a program belongs to. If root is concerned that a normal user may abuse /tmp or /var/tmp they could set quotas for their users for both of those places. Just make sure to enable quotas on your file systems and the usrquota and grpquota features as well.

On another somewhat unrelated note, this provides useful insight about how an AI could be tricked into believing something that someone may want it to believe. If an AI, and for that matter a search engine, automatically believes everything it reads online, then someone could write whatever they want on their own web site and wait for the various search engines to find it. If those search engines found enough web sites that all basically said the same thing, but not necessarily using the exact same wording, then the search engines and AIs out there would be highly likely to believe that what they found was in fact the truth. This could really affect search results and the behavior of AIs everywhere. AI developers still need to work on that issue. AIs and search engines need discernment and that may be a tall order since they don't exactly think the way people do. Sadly though, many people will also believe that something is true or false if enough people keep telling them that it is.

Signed,

Matthew Campbell
 
Last edited:


@Trenix25/Matthew Brilliant piece of deductive reasoning. Until these AI developers sort those issues out , discernment is a must on the users part....instead of blindly following, and accepting as absolute truth, what the AI has spat out.
As it turns out some pinhead out there thought they knew what they were talking about when they clearly didn't know quite as much as they thought they did. They wrote on their web site that /var should be mounted with the noexec mount option and now Bing believes it.
an AI could be tricked into believing something that someone may want it to believe. If an AI, and for that matter a search engine, automatically believes everything it reads online, then someone could write whatever they want on their own web site and wait for the various search engines to find it. If those search engines found enough web sites that all basically said the same thing, but not necessarily using the exact same wording, then the search engines and AIs out there would be highly likely to believe that what they found was in fact the truth. This could really affect search results and the behavior of AIs everywhere.
 



Top