Pacman

Welcome to the Pacman bug tracker. Please search the current bugs and feature requests before filing a new one! Use advanced search and select "Search in Comments".

* Please select the correct category and version.
* Write a descriptive summary, background info, and provide a reproducible test case whenever possible.
Tasklist

FS#9242 - custom umask makes some aur packages have wrong file permissions

Attached to Project: Pacman
Opened by Dawid Wróbel (cromo) - Thursday, 17 January 2008, 11:57 GMT
Last edited by Xavier (shining) - Monday, 18 February 2008, 22:44 GMT
Task Type Bug Report
Category makepkg
Status Closed
Assigned To Xavier (shining)
Architecture All
Severity Low
Priority Normal
Reported Version 3.1.0
Due in Version 3.1.2
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Summary and Info:
I have reinstalled the opera-devel package from AUR yesterday. opera stopped working, it wouldn't run. I checked file permissions and found out that pretty much all of them have X00 permissions set. I thought it was the PKGBUILD's fault, but it was not. I have umask 077 set here locally and unless I change them to 022, the files in the output packages will have such limited permissions. I am not sure if that's a bug or a feature, but I am sure I used to install opera-devel with that 077 umask many times before and it was fine. I suspect pacman 3.1.0 (or actually makepkg) has changed something in its behaviour, hence the problem.

Steps to Reproduce:
Set umask to 077 temporarly, build the opera-devel package from AUR.
This task depends upon

Closed by  Xavier (shining)
Monday, 18 February 2008, 22:44 GMT
Reason for closing:  Fixed
Additional comments about closing:  will be fixed in 3.1.2 (commit 17180890a5).
Comment by Xavier (shining) - Thursday, 17 January 2008, 14:19 GMT
Indeed someone else (solstice) reported that issue, but I'm very confused about what the actual problem is. Thanks for reporting the bug anyway, I am not sure why solstice didn't do it.

So you also seem to think this a regression from makepkg 3.1. Any chances you can try with makepkg 3.0 in the same condition?
You could grab makepkg and makepkg.conf from 3.0.6 tarball : ftp://ftp.archlinux.org/other/pacman/pacman-3.0.6.tar.gz

solstice said he didn't have this issue with 3.0.6. But I can reproduce the problem with both versions...
Now that I think about it, make sure you also build as user (with fakeroot) in 3.0.6.

When building as root, with 3.0.6 or 3.1.0, it works fine for me.
Comment by Dawid Wróbel (cromo) - Thursday, 17 January 2008, 16:19 GMT
I can confirm that it's reproducible under both 3.0.6 and 3.1.0.
Changing umask to 022 before makepkg'ing works fine.
Please also note, that the Opera's install.sh script complains when run with umask set to something different than 022. Funny though that it installs fine when run from PKGBUILD's build() function.
I have no idea how comes it worked fine in the past. I don't think Opera changed something, I have installe the same version (20080103) previously (about 2 weeks ago) without any problems.
Comment by Xavier (shining) - Thursday, 17 January 2008, 16:25 GMT
makepkg sets the umask to 022 itself. you can add the umask command to the PKGBUILD build function, to check that.
So I don't understand what is the difference between setting the umask in the shell calling makepkg, and setting it in makepkg itself.

Also note that the problem only happens when using fakeroot. There are also known bugs with fakeroot :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=361306

I am still able to reproduce the problem mentioned there, even with fakeroot 1.9 which was supposed to fix it.
And whether I am in a filesystem with ACL or not doesn't matter. I always get the permission problem.
Comment by Dawid Wróbel (cromo) - Thursday, 17 January 2008, 18:09 GMT
Thing is that I tested adding the umask command to PKGBUILD and it doesn't work at all(!). If makepkg is supposed to do it, too, maybe it's blocked somehow?
Comment by Aaron Griffin (phrakture) - Thursday, 17 January 2008, 20:51 GMT
Just a guess: maybe fakeroot wraps/blocks the umask changes and we need to set the umask BEFORE we use fakeroot?
Comment by Aaron Griffin (phrakture) - Thursday, 17 January 2008, 22:07 GMT
well, it's not that...
Comment by Aaron Griffin (phrakture) - Thursday, 17 January 2008, 22:45 GMT
Ok, thanks to Eliott and Xavier here:

Steps to reproduce
------------------
umask 077
fakeroot
umask 022
touch x y z
exit
tar czf foo.tar.gz x y z --preserve #ERROR is with --preserve
tar czf bar.tar.gz x y z
mkdir foo
mkdir bar
mv foo.tar.gz foo/
mv bar.tar.gz bar/
cd foo && tar xzf foo.tar.gz && cd ..
cd bar && tar xzf bar.tar.gz && cd ..

#check perms now
ls -l foo/
tar -tzvf foo/foo.tar.gz

ls -l bar/
tar -tzvf bar/bar.tar.gz

The issue appears to happen when EXTRACTING a tarball with --preserve
Comment by Thomas Bächler (brain0) - Friday, 18 January 2008, 06:43 GMT
Xavier, I cannot reproduce any permission problems anymore with fakeroot 1.9. Can you create a test case and comment on bug #8214? It seems that these bugs are related.
Comment by Xavier (shining) - Friday, 18 January 2008, 07:48 GMT
Thomas: Ok, I added a comment there.
But I am no longer sure the two bugs are related.

Aaron: I followed your instructions, and I get the same permissions in the two archives (644 on all files inside), and the same permissions when the archive are extracted (600 on all files in foo/ and bar/).

Now, about this opera package. When I install it manually :
$ mkdir test
$ ./install.sh DESTDIR=test
$ ls -l test/usr/share/opera/encoding.bin
-rw------- 1 xav xav 653419 jan 3 12:04 test/usr/share/opera/encoding.bin

That is with umask 022, because with another umask, the install.sh script won't even run at all!
So isn't the problem only in opera install script?

I don't understand how makepkg manages to get 644 permission on all these files, when run with umask 022.
$ ls -l pkg/usr/share/opera/encoding.bin
-rw-r--r-- 1 xav xav 653419 jan 3 12:04 pkg/usr/share/opera/encoding.bin

This is driving me nuts. I just tried again the first manual step. And now I get 644 permission there too! Just crazy.
Comment by Dawid Wróbel (cromo) - Friday, 18 January 2008, 09:46 GMT
Xavier, it was driving me nuts, too, but I found out it somehow sets the umask permanently (?) for the session when I put the umask into PKGBUILD explicitly. Or something like this, not sure, it's all weird. However still, umask run from console shown umask bits like it should, fakeroot was probably setting it only for itself or what? I had to logout to bring the things back to normal.
I am just blindly guessing here, this is nothing to be sure of at all.

Comment by Aaron Griffin (phrakture) - Friday, 18 January 2008, 18:13 GMT
I am officially deeming this: Most Confusing Bug Ever
Comment by Dawid Wróbel (cromo) - Sunday, 20 January 2008, 20:54 GMT
519:cromo@kromka:~$ subdownloader
python: can't open file '/usr/share/subdownloader/SubDownloader.py': [Errno 13] Permission denied

Downloaded from AUR. Same problem.
Comment by Roman Kyrylych (Romashka) - Monday, 21 January 2008, 08:15 GMT
Hm, something related to fakeroot was reported in  FS#9232 
Comment by Allan McRae (Allan) - Friday, 08 February 2008, 04:39 GMT
I really think this is just an opera installer problem.

This is my testing

> umask 022
> makepkg
Permissions are good

> cd src/opera.../ # using src as extracted by amkepkg
> ./install.sh DESTDIR=tmpdir
Permissions are good

Clear all {pkg,src} directories
> umask 077
> makepkg
Permissions are bad

> cd src/opera.../ # using src as extracted by makepkg
> umask 022 # Won't install otherwise
> ./install.sh DESTDIR=tmpdir
Permissions are bad

A brief ivestigation suggests that in the opera install.sh "cp" is used to install files. If they are not extracted with the right permissions...
Comment by Xavier (shining) - Friday, 08 February 2008, 20:54 GMT
Of course!
I checked again and it all makes sense now.
I did really well on this one. First, I managed to confuse everyone by talking about fakeroot bugs and stuff.
And when  bug 9362  was reported, I also failed to see the link with it..

So, well, we are back to the question asked in that other bug report then :
should we move (or copy) umask 022 to the beginning of makepkg?

Hm, actually, since handledeps sources profile.d/ and stuff, and the extraction happens after,
maybe we should set the umask just once right before the extraction?
Comment by Xavier (shining) - Thursday, 14 February 2008, 14:27 GMT Comment by Dawid Wróbel (cromo) - Thursday, 14 February 2008, 14:52 GMT
OK, but how about setting the umask back after finishing building of package?
Comment by Xavier (shining) - Thursday, 14 February 2008, 15:46 GMT
It isn't done automatically? I thought the umask was only set for the makepkg shell session.
Comment by Dawid Wróbel (cromo) - Thursday, 14 February 2008, 17:12 GMT
Oh, I see. Didn't know that.

Loading...