Additional info on bug 58790

Mons1990 · 2018-06-16 19:46:03

Hello

Since pacman upgrade I have the problem already reported on bug 58790.
I'm not very expert on permission managment so please help me solving the issue.

I used to mount a tmpfs folder at startup and use it as BUILDDIR for makepkg

[mons@arch-desktop ~]$ cat /etc/fstab
# Static information about the filesystems.
# See fstab(5) for details.


# <file system>					<dir>		<type>		<options>						<dump>	<pass>

# /dev/sda2 (root)
UUID=0cb33af5-7859-4cbb-b686-932910ec4496	/         	ext4      	rw,noatime,discard,data=ordered				0	1

# /dev/sda1 (EFI boot partition)
UUID=19E4-0883      				/boot     	vfat      	rw,noatime,discard,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro	0	2

# /dev/sdb1 (var)
UUID=8d4fa967-faaa-442f-9695-83dc120699d6	/var      	ext4	  	rw,noatime,acl						0	2

# /dev/sdb3 (home)
UUID=82a3c611-ddbf-435b-8250-103fd2ff55d4	/home     	ext4      	rw,noatime,noauto,x-systemd.automount,data=ordered	0	2

# /dev/sdb2 (swap)
UUID=911ed16e-ac24-449f-8bb4-41b61078dc5a	none      	swap      	defaults						0	0

# /tmp (tmp in RAM)
tmpfs						/tmp		tmpfs		nodev,nosuid,size=4G				0	0

# /scratch (Compilazione in RAM)
tmpfs						/scratch	tmpfs		nodev,nosuid					0	0

Now every time I'm trying to compile somthing I receive

[mons@arch-desktop ~]$ makepkg PKGBUILD
chmod: changing permissions of '/scratch': Operation not permitted

==> ERROR: An unknown error has occurred. Exiting...
Segnale 1 definito dall'utente

This error doesn't appear if i comment BUILDDIR or if i set it on /tmp/makepkg (and I don't want to do it because of the limit of 4 GiB).

Is there a solution to have a separate mount point for building in tmpfs?

Thank you in advance

eschwartz · 2018-06-17 02:54:59

The directory "/scratch" is not owned by your user, using the BUILDDIR=/scratch/makepkg should work.

The issue with using /scratch is that it's no different from using /tmp, rather than /tmp/makepkg

That being said, I don't understand this whole situation at all. You don't want to use /tmp, due to a 4GB limit... which you've set yourself, and would rather use yet another tmpfs, this one not restricted in size. Why not just use /tmp?

Mons1990 · 2018-06-17 07:21:52

Eschwartz wrote:

The directory "/scratch" is not owned by your user, using the BUILDDIR=/scratch/makepkg should work.
The issue with using /scratch is that it's no different from using /tmp, rather than /tmp/makepkg
That being said, I don't understand this whole situation at all. You don't want to use /tmp, due to a 4GB limit... which you've set yourself, and would rather use yet another tmpfs, this one not restricted in size. Why not just use /tmp?

Thank you for the answer. When I wrote my fstab I followed this suggestion:

Putting a limit on /tmp size if it is mounted as tmpfs is to prevent a DOS attack. If one service was compromised or one user malicious they could simply write to /tmp until all of the swap and memory would be occupied.

Since the OOM condition does not apply to files the processes would be killed until the malicious user shell would be killed (and he would not be able to log in due to lack of memory) or the compromised service would be killed. At this stage the system would be too slow for administrator to actually do anything other then restart, which would wipe the evidence thus making it effective DOS technique.

Not having /tmp as a separate mount then a slightly different problems would happen. Making the / partition full may render system unbootable and in very bad situation (say a glibc update) it may require much more repairing.

While those problems can be significant for multi-system there is also a reason to prevent it for desktop users. For example I once used a program which tried to write several GB of files in times when 512 MiB was large amount of RAM, which would render system unusable had the tmpfs been unlimited. In such way it only cause problems for the program itself and others trying to write to  /tmp.

50% of RAM for tmpfs allows to use 50% of RAM for other things like running programs thus preventing the large swapping. Since it is generally assumed that minimal amount of information is kept there (41M on my system), but it needs to be quickly accessible is the reason of using tmpfs in the first place (no need to preserve it across reboots is enabling it). Thus 50% is 'reasonable' to both having large slack in case a peak /tmp usage happens while at the same time preventing the system slowdown.

As mentioned by abdelsaid, you can change the settings in /etc/fstab:

none /tmp tmpfs size=2G 0 0 # Change the size= parameter to whatever you want
PS. Where are you trying to compile the kernels (in /tmp)? Usually you compile them with user rights AND save the results in case you need 3rd party modules etc. gcc should keep minimal amount of files on /tmp thus avoiding the whole problem.

Once you use 4 GB of /tmp on 4GB system it is possible (especially when you are using heavyweight desktop environment) that your system will slow down significantly.

loqs · 2018-06-17 07:58:26

man 5 tmpfs wrote:

Mount options
The tmpfs filesystem supports the following mount options:
size=bytes
Specify an upper limit on the size of the filesystem. The size is given in bytes, and rounded up to entire pages.
The size may have a k, m, or g suffix for Ki, Mi, Gi (binary kilo (kibi), binary mega (mebi) and binary giga (gibi)).
The size may also have a % suffix to limit this instance to a percentage of physical RAM.
The default, when neither size nor nr_blocks is specified, is size=50%.

If you had no fstab entry for /tmp it would still use the 50% default size option.

Last edited by loqs (2018-06-17 07:58:45)

eschwartz · 2018-06-17 11:34:34

If you're afraid of being attacked with a DoS, do you really think malicious software will not be clever enough to search fstab for other tmpfs mounts in order to DoS those too?

Where did you find this advice anyway, it is not in our Wiki.

Mons1990 · 2018-06-17 13:02:13

Eschwartz wrote:

If you're afraid of being attacked with a DoS, do you really think malicious software will not be clever enough to search fstab for other tmpfs mounts in order to DoS those too?
Where did you find this advice anyway, it is not in our Wiki.

stackoverflow

So, please let me understand. Assume i want to compile in tmpfs and really don't care about DoS (that is). By default /tmp folder is limited if in tmpfs to the half of the ram amount installed, in my case 8/2 = 4GiB. If my compiling data go beyond this size the computer deadlocks, right? So, I have 16 GiB of swap, should I set the maximum size of /tmp partition in tmpfs to 16 GiB and use /tmp/makepg as BULDDIR?

eschwartz · 2018-06-17 13:13:13

If you try to use more space than is available, the package aborts with "out of disk space" errors. It doesn't deadlock.

And swap is not RAM, if you've got 8GB RAM and 8GB swap then your /tmp will mount, by default, as 4GB. If you would *like* to override this by letting it use all your RAM *and* all your swap, then I guess there's nothing stopping you

Arch Linux

#1 2018-06-16 19:46:03

Additional info on bug 58790

#2 2018-06-17 02:54:59

Re: Additional info on bug 58790

#3 2018-06-17 07:21:52

Re: Additional info on bug 58790

#4 2018-06-17 07:58:26

Re: Additional info on bug 58790

#5 2018-06-17 11:34:34

Re: Additional info on bug 58790

#6 2018-06-17 13:02:13

Re: Additional info on bug 58790

#7 2018-06-17 13:13:13

Re: Additional info on bug 58790

Board footer