FS#7406 - NREP: umask is followed, even if nonsensical

Attached to Project: Pacman
Opened by Benjamin Andresen (klapmuetz) - Saturday, 09 June 2007, 22:08 GMT
Last edited by Dan McGee (toofishes) - Friday, 18 January 2008, 05:10 GMT
Task Type Bug Report
Category General
Status Closed
Assigned To Aaron Griffin (phrakture)
Architecture All
Severity High
Priority Normal
Reported Version 3.0.4
Due in Version 3.1.0
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Summary and Info:
under certain circumstances the currently active umask is used to put metainfo into /var/lib/pacman/local

today it happened with 4 packages that I installed via pacman -U and umask 077 which resulted in 4 packages being chmodded 722.

I can't vouche for it, but if IIRC it happened on pacman -S on my other machine as well.

Steps to Reproduce:
not reproducible, but happened at least 5 times to me over a course of 3 years
(just today again, on a new installation)
This task depends upon

Closed by  Dan McGee (toofishes)
Friday, 18 January 2008, 05:10 GMT
Reason for closing:  Fixed
Additional comments about closing:  Should be fixed as we explicitly set both directory and file permissions when inserting DB entries.
Comment by Dan McGee (toofishes) - Thursday, 14 June 2007, 13:29 GMT
snprintf(path, PATH_MAX, "%s/%s-%s", db->path, info->name, info->version);
oldmask = umask(0000);
mkdir(path, 0755);
/* make sure we have a sane umask */
umask(0022);

As far as I can tell from the code snippet above, the umask is correctly set before we write back files to the local DB (alpm_db_write). Any other ideas?
Comment by Benjamin Andresen (klapmuetz) - Sunday, 17 June 2007, 13:58 GMT
There, my other new laptop that I just installed two days ago has the same problem...
So now I could NREPoduce it twice in 1 week (approx.) :-)

The only pattern I see in the course of some years now is the following:
I use zsh with a config that sets umask to 022 for root, but the bash config
that I use on a fresh install has an umask of 077.

It has to have to do with that.
Other than that I can't see a pattern in the log file that corresponds to the database.
   pacman.log (0 KiB)
   pacman_local (0 KiB)
Comment by Benjamin Andresen (klapmuetz) - Sunday, 17 June 2007, 14:00 GMT
P.S. Granted, after I switch root to zsh and thus umask 022, the problem never arose again.
(I would have noticed, because I build quite a bit of packages and makepkg chokes when some dirs in local/ are 700)
Comment by Glenn Matthys (RedShift) - Sunday, 19 August 2007, 18:25 GMT
Does this possibly have to do with http://bugs.archlinux.org/task/7461 ?
Comment by Dan McGee (toofishes) - Friday, 28 September 2007, 17:50 GMT
Has anyone noticed this behavior in a while? We especially need to test with pacman GIT as the install code has changed a good amount with regard to overwriting and permissions checking.
Comment by Jens Adam (byte) - Friday, 04 January 2008, 11:14 GMT
The issue is even worse with pacman-git. And I'd consider it more of a makepkg bug.

I got reminded about this when I was building some font packages today. I've been using umask 077 for a while in .bashrc and had namcap complain several times before about non-world-readable stuff. Oh, and namcap doesn't work with 3.1 packages, probably because .FILELIST is missing? :(

I used http://aur.archlinux.org/packages.php?do_Details=1&ID=8262 (ttf-funfonts) as an example, but I guess any other PKGBUILD using simple cp instead of install should give similar results.

3.0.6:
LICENSE and .INSTALL have 600 permissions

3.1 (20080102):
All files (dirs are ok) are not world-readable.
Comment by Dan McGee (toofishes) - Friday, 04 January 2008, 17:02 GMT
Are we talking the umask on the DB files here, or the package itself?

If we are talking the package, is it possibly related to  FS#8214 ? Can you insert some debug lines in makepkg to print out your umask inside and out of the fakeroot? I have no way to debug this because I've never experienced this bug.

If PKGBUILDs are using cp instead of install, then this is hard to deal with.
Comment by Benjamin Andresen (klapmuetz) - Friday, 04 January 2008, 17:21 GMT
this bug is talking about the DB files... see "metainfo in /var/lib/pacman/local" in original report.
Comment by Jens Adam (byte) - Friday, 04 January 2008, 18:36 GMT
I'm talking about both.
Comment by Dan McGee (toofishes) - Friday, 04 January 2008, 19:04 GMT
Please separate the issues. The original bug deals with pacman, and what you seemed to describe above is a makepkg issue. Can you open a new bug and copy/paste your comments and description of the bug there? Thanks.
Comment by Jens Adam (byte) - Friday, 04 January 2008, 20:42 GMT
(Err? Ignore that one.)

It's not a separate issue. It's affecting all files in the pkg.tar.gz, no matter whether they end up somewhere in /usr or in /var/lib/pacman/local.
Comment by Aaron Griffin (phrakture) - Friday, 04 January 2008, 20:46 GMT
Ok so wait. Here's the pertinent question: what do you want us to do?

If your PKGBUILD is creating files with 600 permissions, how are we to know if they are really supposed to be 644 or if you meant 600?

I would actually go so far as to blame this on the PKGBUILD for not using 'install'
Comment by Dan McGee (toofishes) - Friday, 04 January 2008, 20:46 GMT
No, it is a completely separate issue.

Packages NEVER touch /var/lib/pacman/local. Never ever. That is pacman's job.

This bug deals ONLY with files in /var/lib/pacman/local/. Your issue deals with files installed everywhere else, where pacman uses the permissions straight from the package and does no umasking of its own. This is _completely different_. I don't care whether you are talking about both- if you see a umask issue with the _packages_, file another bug. If you have issues with _db entries_, then please explain them here. That is all.
Comment by Aaron Griffin (phrakture) - Friday, 04 January 2008, 20:50 GMT
I believe the actual issue reported in the bug is fixed here:
http://projects.archlinux.org/git/?p=pacman.git;a=commitdiff;h=5f811dc0207ead061b89d3acc6466bb390fd242e
Comment by Jens Adam (byte) - Friday, 04 January 2008, 22:22 GMT
Yep, it is.

I got the bacula.tar.gz from AUR, unpacked it in an empty dir, which lead to all those build files being chmodded 600.
makepkg went ok, the .INSTALL in the package being still 600, but upon actual installation with pacman all files in the local db got 644 permissions.

Loading...