You are not logged in.

#1 2018-02-20 15:26:35

nobrakal
Member
Registered: 2018-02-20
Posts: 2

Should installed files keeps the user umask

Hi there,

I have recently adopted the tuxguitar package in the AUR, and a user complaint about a problem of permissions on the installed files and only when the package was installed by trizen, and not with makepkg

It turns out that he has set a umask of 027 in /etc/profile and he finds out that makepkg 'hardset' a correct traditional umask of 0022, and trizen does not do that. Because the package() installs things with a 'cp -a' the user-umask is kept when building/installing with trizen.

As a packager, what should I do ? Hardwrite a correct umask in my PKGBUILD ? Install the files with a sane umask (with 'install' for example) or leave at users preferences (don't do anything) ?

Thank you in advance for your help smile

Offline

#2 2018-02-20 15:33:20

Scimmia
Fellow
Registered: 2012-09-01
Posts: 11,466

Re: Should installed files keeps the user umask

makepkg is the only supported way. If trizen does things differently, that's a trizen problem.

Offline

#3 2018-02-20 16:10:18

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,447
Website

Re: Should installed files keeps the user umask

I agree, this is 100% a trizen issue.  However, the following to use `install` instead of `cp` is still a good idea.

nobrakal wrote:

Install the files with a sane umask (with 'install' for example)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#4 2018-02-20 16:17:48

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: Should installed files keeps the user umask

This is obviously a bug in trizen. But I'm not sure how it manages to override makepkg's umask.

Trilby wrote:

I agree, this is 100% a trizen issue.  However, the following to use `install` instead of `cp` is still a good idea.

nobrakal wrote:

Install the files with a sane umask (with 'install' for example)

Depends how many files you are moving *and the need to preserve directory structure* , the example specifically called out `cp -a`.

Last edited by eschwartz (2018-02-20 16:19:58)


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#5 2018-02-20 17:34:19

nobrakal
Member
Registered: 2018-02-20
Posts: 2

Re: Should installed files keeps the user umask

Hi, thank you for your responses !

I will try to implement a solution with install, even if, as @Eschwartz mentioned it, there is some files to move and cp in a convenient solutions.

Offline

#6 2018-02-20 19:40:53

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: Should installed files keeps the user umask

nobrakal wrote:

Hi, thank you for your responses !

I will try to implement a solution with install, even if, as @Eschwartz mentioned it, there is some files to move and cp in a convenient solutions.

Don't bother. Only people with broken setups or using broken tools have this problem -- writing PKGBUILDs that specifically cater to those one or two people in the wrong, is a total waste of time and leads to more complicated, difficult or annoying to maintain packages. Just tell them it is a trizen bug and they should use a better AUR helper.


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#7 2018-02-22 02:01:17

raith
Member
Registered: 2018-02-21
Posts: 2

Re: Should installed files keeps the user umask

Hi,

I am the user who is affected by this and reported the problem to nobrakal. To clarify:

a) trizen does use makepkg
b) I can reproduce this issue by solely using makepkg to build the package from a snapshot downloaded from AUR, without any AUR-helper

I investigated this problem further in a clean Arch system + umask 027 in /etc/profile and found the following:
While makepkg sets the umask to 0022 (as mentioned above), it (accidentally?) resets it when it installs dependencies. In the function "handle_deps", /etc/profile is sourced again (see line 278 in /usr/bin/makepkg), so the umask is set back to 027 (or whatever the user configured). makepkg now uses the wrong umask (not 0022 anymore).

However, if I happen to have all dependencies of the package I'm going to build installed, makepkg won't source /etc/profile again, leave its umask 0022 intact and build the package just fine.

I can reproduce this bug with the tuxguitar package, but also with the AUR package "crate".

Offline

#8 2018-02-22 02:47:58

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: Should installed files keeps the user umask

...

Okay, wow that's weird. I'll confess I didn't realize makepkg actually did that.

TBH I'm still not sure *why* it does that. As far as I can tell, this was added in https://git.archlinux.org/pacman.git/co … 333fb361ba but I'm not sure of the motivation/context, as the commit message only says:

* Merge of _some_ of the Frugalware makepkg change - this may still be incomplete

I couldn't chase down the exact reasoning in the 2006 November discussions...


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#9 2018-02-22 12:55:57

raith
Member
Registered: 2018-02-21
Posts: 2

Re: Should installed files keeps the user umask

Not sourcing /etc/profile seems wrong, when I see, which software, that makepkg might need for building, has files in /etc/profile.d (e.g. Java, Maven, Ant, Mercurial).

The following patch, applied to makepkg.sh.in at least helps on my system to fix these permission issues when building packages:

diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in
index 63b6c3e1..678bcf73 100644
--- a/scripts/makepkg.sh.in
+++ b/scripts/makepkg.sh.in
@@ -276,10 +276,11 @@ handle_deps() {
 	# we might need the new system environment
 	# save our shell options and turn off extglob
 	local shellopts=$(shopt -p)
 	shopt -u extglob
 	source /etc/profile &>/dev/null
+	umask 0022
 	eval "$shellopts"
 
 	return $R_DEPS_SATISFIED
 }

Offline

#10 2018-02-22 13:06:47

R00KIE
Forum Fellow
From: Between a computer and a chair
Registered: 2008-09-14
Posts: 4,734

Re: Should installed files keeps the user umask

What is the content of your /etc/profile? Might you be by any chance setting the default umask in /etc/profile or in any of the files in /etc/profile.d/?


R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K

Offline

#11 2018-02-22 13:15:18

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,447
Website

Re: Should installed files keeps the user umask

ROOKIE, isn't that the point.  Raith already specified that 0027 is set in /etc/profile, but makepkg uses 0022 by default *until* it sources /etc/profile resetting it to 0027 but only if makepkg has to install dependencies.

If this is true, it would be a makepkg problem: makepkg should not build a different package if it has to install dependencies than it would if the dependencies were pre-installed.  What the user has in /etc/profile should not impact this (i.e. if /etc/profile settings are used, they should always be used, they should not be used or not used contingent on whether makepkg needs to install dependencies).

I don't know if it'd be preferable for makepkg to use a hardcoded 0022, or to use the user's specified value in /etc/profile.  I'd lean towards the former, but either one could make sense.  But flip-flopping between either one based solely on whether dependencies were pre-installed is very ugly.

Last edited by Trilby (2018-02-22 13:18:14)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#12 2018-02-22 15:13:31

R00KIE
Forum Fellow
From: Between a computer and a chair
Registered: 2008-09-14
Posts: 4,734

Re: Should installed files keeps the user umask

It seems I missed or misunderstood that it was hardcoded in /etc/profile.

I suppose makepkg should hard code this to keep a sane environment but this might be a knee-jerk reaction, what to do with other things such as locale? Icaclient from the AUR comes to mind, it uses the currently set LANG in some of the install steps. Should this also be overridden and set to a known value or keep the user's configuration?You can't have it both ways, either makepkg hardcodes a few things, which some people will compain about and might break things, or you let it respect what the admin/user has set and it will break other things and people will still complain.


R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K

Offline

#13 2018-02-23 14:24:10

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: Should installed files keeps the user umask

R00KIE wrote:

It seems I missed or misunderstood that it was hardcoded in /etc/profile.

I suppose makepkg should hard code this to keep a sane environment but this might be a knee-jerk reaction, what to do with other things such as locale? Icaclient from the AUR comes to mind, it uses the currently set LANG in some of the install steps. Should this also be overridden and set to a known value or keep the user's configuration?You can't have it both ways, either makepkg hardcodes a few things, which some people will compain about and might break things, or you let it respect what the admin/user has set and it will break other things and people will still complain.

I would be positively delighted if makepkg could set the locale to something sane. Unfortunately there is no such mythical beast.

You cannot set the locale without first checking to see what locales are available, unless you use the builtin C locale which dreadful because it explicitly has no unicode support. C.UTF-8 would be nice, but glibc has stalled on actually adding one. You could assume that en_US.UTF-8 is always available, but that would be wrong because it isn't, unless you use devtools. In fact, it is perfectly valid for the user to configure no UTF-8 locales at all, although I can't think why someone would want it.

If and when C.UTF-8 is ever a thing, I will be quite excited to provide patches for makepkg that set this alongside umask. umask is easy, how do you not-support a umask. tongue

Both these things are relatively common causes for breakage in packages, and should be consistently fixed. raith, please bring this patch to the pacman-dev mailing list for discussion.


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

Board footer

Powered by FluxBB