[arch-general] [vte3] Wrong permissions for /etc/profile.d/vte.sh ?
Hi, As I was checking some stuff about environment variables, I noticed that I have one file in /etc/profile.d which doesn't have the same perms as the others: $ ls -la /etc/profile.d/ total 72 drwxr-xr-x 2 root root 4096 19 juil. 20:36 . drwxr-xr-x 91 root root 4096 22 juil. 15:04 .. -rwxr-xr-x 1 root root 102 24 oct. 2013 gpm.sh -rwxr-xr-x 1 root root 2154 21 mars 02:16 infinality-settings.sh -rwxr-xr-x 1 root root 1972 7 janv. 2014 infinality-settings.sh.old -rwxr-xr-x 1 root root 140 28 mars 15:29 jre.csh -rwxr-xr-x 1 root root 152 28 mars 15:29 jre.sh -rwxr-xr-x 1 root root 156 15 mars 22:09 libreoffice-common.csh -rwxr-xr-x 1 root root 156 15 mars 22:09 libreoffice-common.sh -rwxr-xr-x 1 root root 1052 4 juil. 14:44 locale.sh -rwxr-xr-x 1 root root 50 1 juil. 11:55 mozilla-common.csh -rwxr-xr-x 1 root root 50 1 juil. 11:55 mozilla-common.sh -rwxr-xr-x 1 root root 699 19 juin 21:08 perlbin.csh -rwxr-xr-x 1 root root 668 19 juin 21:08 perlbin.sh -rwxr-xr-x 1 root root 115 13 mai 23:37 seahorse-ssh-askpass.sh -rwxr-xr-x 1 root root 36 20 janv. 2014 vdpau_vaapi.sh -rw-r--r-- 1 root root 1881 23 juin 22:05 vte.sh -rwxr-xr-x 1 root root 115 11 juin 2013 x11-ssh-askpass.sh $ pacman -Qo /etc/profile.d/vte.sh /etc/profile.d/vte.sh belongs to vte3 0.36.3-1 I verified it wasn't some bad commands on my side which changed this file's perms by reinstalling it together with vte-common, however the file remains 644. Does anybody have any hints about why this file, which is a .sh script, doesn't have execute permissions like the others in /etc/profile.d folder? I didn't find any change in latest PKGBUILDs which would cause such permissions, so should I suppose it is an upstream decision? Regards
On 22/07/14 09:55 AM, Neitsab wrote:
Hi,
As I was checking some stuff about environment variables, I noticed that I have one file in /etc/profile.d which doesn't have the same perms as the others:
$ ls -la /etc/profile.d/ total 72 drwxr-xr-x 2 root root 4096 19 juil. 20:36 . drwxr-xr-x 91 root root 4096 22 juil. 15:04 .. -rwxr-xr-x 1 root root 102 24 oct. 2013 gpm.sh -rwxr-xr-x 1 root root 2154 21 mars 02:16 infinality-settings.sh -rwxr-xr-x 1 root root 1972 7 janv. 2014 infinality-settings.sh.old -rwxr-xr-x 1 root root 140 28 mars 15:29 jre.csh -rwxr-xr-x 1 root root 152 28 mars 15:29 jre.sh -rwxr-xr-x 1 root root 156 15 mars 22:09 libreoffice-common.csh -rwxr-xr-x 1 root root 156 15 mars 22:09 libreoffice-common.sh -rwxr-xr-x 1 root root 1052 4 juil. 14:44 locale.sh -rwxr-xr-x 1 root root 50 1 juil. 11:55 mozilla-common.csh -rwxr-xr-x 1 root root 50 1 juil. 11:55 mozilla-common.sh -rwxr-xr-x 1 root root 699 19 juin 21:08 perlbin.csh -rwxr-xr-x 1 root root 668 19 juin 21:08 perlbin.sh -rwxr-xr-x 1 root root 115 13 mai 23:37 seahorse-ssh-askpass.sh -rwxr-xr-x 1 root root 36 20 janv. 2014 vdpau_vaapi.sh -rw-r--r-- 1 root root 1881 23 juin 22:05 vte.sh -rwxr-xr-x 1 root root 115 11 juin 2013 x11-ssh-askpass.sh
$ pacman -Qo /etc/profile.d/vte.sh /etc/profile.d/vte.sh belongs to vte3 0.36.3-1
I verified it wasn't some bad commands on my side which changed this file's perms by reinstalling it together with vte-common, however the file remains 644.
Does anybody have any hints about why this file, which is a .sh script, doesn't have execute permissions like the others in /etc/profile.d folder? I didn't find any change in latest PKGBUILDs which would cause such permissions, so should I suppose it is an upstream decision?
Regards
The permissions don't really matter because they're sourced as long as they're readable. It's incorrect for upstream to be doing this though, because their script needs to be run for every interactive shell. I already filed a bug about it: https://bugs.archlinux.org/task/39684 Arch needs to provide a separate directory sourced in non-login shells and put this there instead.
On 22/07/14 09:55 AM, Neitsab wrote:
Hi,
As I was checking some stuff about environment variables, I noticed that I have one file in /etc/profile.d which doesn't have the same perms as the others:
$ ls -la /etc/profile.d/ total 72 drwxr-xr-x 2 root root 4096 19 juil. 20:36 . drwxr-xr-x 91 root root 4096 22 juil. 15:04 .. -rwxr-xr-x 1 root root 102 24 oct. 2013 gpm.sh -rwxr-xr-x 1 root root 2154 21 mars 02:16 infinality-settings.sh -rwxr-xr-x 1 root root 1972 7 janv. 2014 infinality-settings.sh.old -rwxr-xr-x 1 root root 140 28 mars 15:29 jre.csh -rwxr-xr-x 1 root root 152 28 mars 15:29 jre.sh -rwxr-xr-x 1 root root 156 15 mars 22:09 libreoffice-common.csh -rwxr-xr-x 1 root root 156 15 mars 22:09 libreoffice-common.sh -rwxr-xr-x 1 root root 1052 4 juil. 14:44 locale.sh -rwxr-xr-x 1 root root 50 1 juil. 11:55 mozilla-common.csh -rwxr-xr-x 1 root root 50 1 juil. 11:55 mozilla-common.sh -rwxr-xr-x 1 root root 699 19 juin 21:08 perlbin.csh -rwxr-xr-x 1 root root 668 19 juin 21:08 perlbin.sh -rwxr-xr-x 1 root root 115 13 mai 23:37 seahorse-ssh-askpass.sh -rwxr-xr-x 1 root root 36 20 janv. 2014 vdpau_vaapi.sh -rw-r--r-- 1 root root 1881 23 juin 22:05 vte.sh -rwxr-xr-x 1 root root 115 11 juin 2013 x11-ssh-askpass.sh
$ pacman -Qo /etc/profile.d/vte.sh /etc/profile.d/vte.sh belongs to vte3 0.36.3-1
I verified it wasn't some bad commands on my side which changed this file's perms by reinstalling it together with vte-common, however the file remains 644.
Does anybody have any hints about why this file, which is a .sh script, doesn't have execute permissions like the others in /etc/profile.d folder? I didn't find any change in latest PKGBUILDs which would cause such permissions, so should I suppose it is an upstream decision?
Regards
The permissions don't really matter because they're sourced as long as they're readable.
It's incorrect for upstream to be doing this though, because their script needs to be run for every interactive shell. I already filed a bug about it:
https://bugs.archlinux.org/task/39684
Arch needs to provide a separate directory sourced in non-login shells and put this there instead.
Hi, sorry for the delay I forgot to re-subscribe to the list digest after posting this. Thanks for your answer, this addresses my interrogations. Cheers
participants (2)
-
Daniel Micay
-
Neitsab