[pacman-dev] [PATCH] Fix consistency of downloaded sources permissions
Calls to makepg -g and makepkg to download a source files, result in different
permissions on the file if user umask != 0022.
Run makepkg with -g option, will download source files before makepkg set umask
to 0022. Downloaded files permissions will depend on user umask.
Run bare makepkg, will call download source routines after umask was set
to 0022. Downloaded files permissions will be group and world readable.
A collateral damage:
When a user who has a restricted umask (like 077),
update a PKGBUKLD with updpkgsums (which call makepkg -g),
and call a devtools scripts (extra-i686-build) to build the package,
he will get a 'Permission denied',
because the builder (another makepkg call) will be run as nobody user.
Another side effect, when several users share a SRCDEST directory, they cannot
access to files generated by another user with restricted umask.
Altough, this can be workarounded by default ACL in the SRCDEST directory.
The oldest commit with this umask is the first git commit (d04baab) with no
revelent informations provided about the purpose of using an umask.
The last commit moving the umask was 171808. The precious commit message
refered to bug FS#9242 and FS#9362 which recommend to put umask at the top
in makepkg.
This patch put the umask definition at the "beginning" of the makepkg script.
This let us rely that all files generated by makepkg will be with 0022 umask.
Signed-off-by: Sébastien Luttringer
On 10/12/13 10:59, Sébastien Luttringer wrote:
Calls to makepg -g and makepkg to download a source files, result in different permissions on the file if user umask != 0022.
Run makepkg with -g option, will download source files before makepkg set umask to 0022. Downloaded files permissions will depend on user umask. Run bare makepkg, will call download source routines after umask was set to 0022. Downloaded files permissions will be group and world readable.
A collateral damage: When a user who has a restricted umask (like 077), update a PKGBUKLD with updpkgsums (which call makepkg -g), and call a devtools scripts (extra-i686-build) to build the package, he will get a 'Permission denied', because the builder (another makepkg call) will be run as nobody user.
Another side effect, when several users share a SRCDEST directory, they cannot access to files generated by another user with restricted umask. Altough, this can be workarounded by default ACL in the SRCDEST directory.
The oldest commit with this umask is the first git commit (d04baab) with no revelent informations provided about the purpose of using an umask. The last commit moving the umask was 171808. The precious commit message refered to bug FS#9242 and FS#9362 which recommend to put umask at the top in makepkg.
This patch put the umask definition at the "beginning" of the makepkg script. This let us rely that all files generated by makepkg will be with 0022 umask.
Signed-off-by: Sébastien Luttringer
I'll ack this, but rather than fixing all the typos in the long commit message, I'll reduce it to: Calls to 'makepkg -g' and 'makepkg' to download a source files result in different permissions on the file if user has a non-default umask. Put the umask definition at the "beginning" of the makepkg script to ensure all files generated by makepkg have a 0022 umask. A
On Tue, Dec 10, 2013 at 11:45 PM, Allan McRae
On 10/12/13 10:59, Sébastien Luttringer wrote:
Calls to makepg -g and makepkg to download a source files, result in different permissions on the file if user umask != 0022.
Run makepkg with -g option, will download source files before makepkg set umask to 0022. Downloaded files permissions will depend on user umask. Run bare makepkg, will call download source routines after umask was set to 0022. Downloaded files permissions will be group and world readable.
A collateral damage: When a user who has a restricted umask (like 077), update a PKGBUKLD with updpkgsums (which call makepkg -g), and call a devtools scripts (extra-i686-build) to build the package, he will get a 'Permission denied', because the builder (another makepkg call) will be run as nobody user.
Another side effect, when several users share a SRCDEST directory, they cannot access to files generated by another user with restricted umask. Altough, this can be workarounded by default ACL in the SRCDEST directory.
The oldest commit with this umask is the first git commit (d04baab) with no revelent informations provided about the purpose of using an umask. The last commit moving the umask was 171808. The precious commit message refered to bug FS#9242 and FS#9362 which recommend to put umask at the top in makepkg.
This patch put the umask definition at the "beginning" of the makepkg script. This let us rely that all files generated by makepkg will be with 0022 umask.
Signed-off-by: Sébastien Luttringer
I'll ack this, but rather than fixing all the typos in the long commit message, I'll reduce it to:
Calls to 'makepkg -g' and 'makepkg' to download a source files result in different permissions on the file if user has a non-default umask.
Put the umask definition at the "beginning" of the makepkg script to ensure all files generated by makepkg have a 0022 umask.
A
This commit message has some grammar problems in it too. :P This is better: -------------------------------- Calls to 'makepkg -g' and 'makepkg' to download source files result in different permissions on the file if the user has a non-default umask. Put the umask definition at the "beginning" of the makepkg script to ensure all files generated by makepkg have a 0022 umask. -------------------------------- Jason
English is my second language, but: Can one really "call to makepkg"? I would think that one would either just "call makepkg" or alternatively "call on makepkg" [to perform a job]? - Alexander / xyproto
On 11/12/2013 05:45, Allan McRae wrote:
On 10/12/13 10:59, Sébastien Luttringer wrote:
Calls to makepg -g and makepkg to download a source files, result in different permissions on the file if user umask != 0022.
Run makepkg with -g option, will download source files before makepkg set umask to 0022. Downloaded files permissions will depend on user umask. Run bare makepkg, will call download source routines after umask was set to 0022. Downloaded files permissions will be group and world readable.
A collateral damage: When a user who has a restricted umask (like 077), update a PKGBUKLD with updpkgsums (which call makepkg -g), and call a devtools scripts (extra-i686-build) to build the package, he will get a 'Permission denied', because the builder (another makepkg call) will be run as nobody user.
Another side effect, when several users share a SRCDEST directory, they cannot access to files generated by another user with restricted umask. Altough, this can be workarounded by default ACL in the SRCDEST directory.
The oldest commit with this umask is the first git commit (d04baab) with no revelent informations provided about the purpose of using an umask. The last commit moving the umask was 171808. The precious commit message refered to bug FS#9242 and FS#9362 which recommend to put umask at the top in makepkg.
This patch put the umask definition at the "beginning" of the makepkg script. This let us rely that all files generated by makepkg will be with 0022 umask.
Signed-off-by: Sébastien Luttringer
I'll ack this, but rather than fixing all the typos in the long commit message, I'll reduce it to:
I will have my weekly English training tomorrow. I will look at the typos/grammar with my teacher and send you a better long version. :) Cheers, -- Sébastien "Seblu" Luttringer https://www.seblu.net GPG: 0x2072D77A
On 11/12/2013 21:39, Sébastien Luttringer wrote:
On 11/12/2013 05:45, Allan McRae wrote:
On 10/12/13 10:59, Sébastien Luttringer wrote:
Calls to makepg -g and makepkg to download a source files, result in different permissions on the file if user umask != 0022.
Run makepkg with -g option, will download source files before makepkg set umask to 0022. Downloaded files permissions will depend on user umask. Run bare makepkg, will call download source routines after umask was set to 0022. Downloaded files permissions will be group and world readable.
A collateral damage: When a user who has a restricted umask (like 077), update a PKGBUKLD with updpkgsums (which call makepkg -g), and call a devtools scripts (extra-i686-build) to build the package, he will get a 'Permission denied', because the builder (another makepkg call) will be run as nobody user.
Another side effect, when several users share a SRCDEST directory, they cannot access to files generated by another user with restricted umask. Altough, this can be workarounded by default ACL in the SRCDEST directory.
The oldest commit with this umask is the first git commit (d04baab) with no revelent informations provided about the purpose of using an umask. The last commit moving the umask was 171808. The precious commit message refered to bug FS#9242 and FS#9362 which recommend to put umask at the top in makepkg.
This patch put the umask definition at the "beginning" of the makepkg script. This let us rely that all files generated by makepkg will be with 0022 umask.
Signed-off-by: Sébastien Luttringer
I'll ack this, but rather than fixing all the typos in the long commit message, I'll reduce it to:
I will have my weekly English training tomorrow. I will look at the typos/grammar with my teacher and send you a better long version. :)
Training canceled for sickness. Please take the version you prefer. -- Sébastien "Seblu" Luttringer https://www.seblu.net GPG: 0x2072D77A
participants (4)
-
Alexander Rødseth
-
Allan McRae
-
Jason St. John
-
Sébastien Luttringer