[arch-dev-public] wrong permission to packages
On 03/09/2010 08:22 PM, Loui Chang wrote:
On Tue 09 Mar 2010 19:06 +0200, Ionut Biru wrote:
can you change the permission of the file? i really don't know why it has such a permission. I know that we have a cron that fixes the permission but that package was upload yesterday and still has it wrong.
Can you check if the cron is running?
Yeah it's running.
The cron script only specifies g+w so it could still remain unreadable I'm not sure what the policy should be exactly, so maybe you can bring that up on the ML but I've made that file world readable.
this is the second time when this happen and to be fair i don't know why. The cron has: /bin/chmod -R g+w $d/os/{any,i686,x86_64} maybe is better if we change it do chmod 664 by default? -- Ionut
On Tue, Mar 9, 2010 at 12:23 PM, Ionut Biru <biru.ionut@gmail.com> wrote:
On 03/09/2010 08:22 PM, Loui Chang wrote:
On Tue 09 Mar 2010 19:06 +0200, Ionut Biru wrote:
can you change the permission of the file? i really don't know why it has such a permission. I know that we have a cron that fixes the permission but that package was upload yesterday and still has it wrong.
Can you check if the cron is running?
Yeah it's running.
The cron script only specifies g+w so it could still remain unreadable I'm not sure what the policy should be exactly, so maybe you can bring that up on the ML but I've made that file world readable.
this is the second time when this happen and to be fair i don't know why. The cron has:
/bin/chmod -R g+w $d/os/{any,i686,x86_64}
maybe is better if we change it do chmod 664 by default?
The cron job shouldn't do this; the dbscripts should, right? If we just got the permissions right there we wouldn't need the cron job at all actually. -Dan
On Tue, Mar 9, 2010 at 12:41 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Tue, Mar 9, 2010 at 12:23 PM, Ionut Biru <biru.ionut@gmail.com> wrote:
On 03/09/2010 08:22 PM, Loui Chang wrote:
On Tue 09 Mar 2010 19:06 +0200, Ionut Biru wrote:
can you change the permission of the file? i really don't know why it has such a permission. I know that we have a cron that fixes the permission but that package was upload yesterday and still has it wrong.
Can you check if the cron is running?
Yeah it's running.
The cron script only specifies g+w so it could still remain unreadable I'm not sure what the policy should be exactly, so maybe you can bring that up on the ML but I've made that file world readable.
this is the second time when this happen and to be fair i don't know why. The cron has:
/bin/chmod -R g+w $d/os/{any,i686,x86_64}
maybe is better if we change it do chmod 664 by default?
The cron job shouldn't do this; the dbscripts should, right? If we just got the permissions right there we wouldn't need the cron job at all actually.
Yeah, the dbscripts actually DO cover this case. The cron job is there because people sometimes manually move files around. Are people regularly manually moving files? If so it's important to make sure you chmod the files for other users
On 03/09/2010 10:04 PM, Aaron Griffin wrote:
On Tue, Mar 9, 2010 at 12:41 PM, Dan McGee<dpmcgee@gmail.com> wrote:
On Tue, Mar 9, 2010 at 12:23 PM, Ionut Biru<biru.ionut@gmail.com> wrote:
On 03/09/2010 08:22 PM, Loui Chang wrote:
On Tue 09 Mar 2010 19:06 +0200, Ionut Biru wrote:
can you change the permission of the file? i really don't know why it has such a permission. I know that we have a cron that fixes the permission but that package was upload yesterday and still has it wrong.
Can you check if the cron is running?
Yeah it's running.
The cron script only specifies g+w so it could still remain unreadable I'm not sure what the policy should be exactly, so maybe you can bring that up on the ML but I've made that file world readable.
this is the second time when this happen and to be fair i don't know why. The cron has:
/bin/chmod -R g+w $d/os/{any,i686,x86_64}
maybe is better if we change it do chmod 664 by default?
The cron job shouldn't do this; the dbscripts should, right? If we just got the permissions right there we wouldn't need the cron job at all actually.
Yeah, the dbscripts actually DO cover this case. The cron job is there because people sometimes manually move files around.
Are people regularly manually moving files? If so it's important to make sure you chmod the files for other users
really don't know but the permission was 620 and i should ask what was the workflow. -- Ionut
On 03/09/2010 10:43 PM, Ionut Biru wrote:
On 03/09/2010 10:04 PM, Aaron Griffin wrote:
On Tue, Mar 9, 2010 at 12:41 PM, Dan McGee<dpmcgee@gmail.com> wrote:
On Tue, Mar 9, 2010 at 12:23 PM, Ionut Biru<biru.ionut@gmail.com> wrote:
On 03/09/2010 08:22 PM, Loui Chang wrote:
On Tue 09 Mar 2010 19:06 +0200, Ionut Biru wrote:
can you change the permission of the file? i really don't know why it has such a permission. I know that we have a cron that fixes the permission but that package was upload yesterday and still has it wrong.
Can you check if the cron is running?
Yeah it's running.
The cron script only specifies g+w so it could still remain unreadable I'm not sure what the policy should be exactly, so maybe you can bring that up on the ML but I've made that file world readable.
this is the second time when this happen and to be fair i don't know why. The cron has:
/bin/chmod -R g+w $d/os/{any,i686,x86_64}
maybe is better if we change it do chmod 664 by default?
The cron job shouldn't do this; the dbscripts should, right? If we just got the permissions right there we wouldn't need the cron job at all actually.
Yeah, the dbscripts actually DO cover this case. The cron job is there because people sometimes manually move files around.
Are people regularly manually moving files? If so it's important to make sure you chmod the files for other users
really don't know but the permission was 620 and i should ask what was the workflow.
ok. so he has umask 077 and because we are using rsync the permission is persistent. maybe we should fix dbscripts and install the package with the right permission. -- Ionut
On Tue, Mar 9, 2010 at 3:16 PM, Ionut Biru <biru.ionut@gmail.com> wrote:
On 03/09/2010 10:43 PM, Ionut Biru wrote:
On 03/09/2010 10:04 PM, Aaron Griffin wrote:
On Tue, Mar 9, 2010 at 12:41 PM, Dan McGee<dpmcgee@gmail.com> wrote:
On Tue, Mar 9, 2010 at 12:23 PM, Ionut Biru<biru.ionut@gmail.com> wrote:
On 03/09/2010 08:22 PM, Loui Chang wrote:
On Tue 09 Mar 2010 19:06 +0200, Ionut Biru wrote: > > can you change the permission of the file? > i really don't know why it has such a permission. I know that we have > a cron that fixes the permission but that package was upload > yesterday and still has it wrong. > > Can you check if the cron is running?
Yeah it's running.
The cron script only specifies g+w so it could still remain unreadable I'm not sure what the policy should be exactly, so maybe you can bring that up on the ML but I've made that file world readable.
this is the second time when this happen and to be fair i don't know why. The cron has:
/bin/chmod -R g+w $d/os/{any,i686,x86_64}
maybe is better if we change it do chmod 664 by default?
The cron job shouldn't do this; the dbscripts should, right? If we just got the permissions right there we wouldn't need the cron job at all actually.
Yeah, the dbscripts actually DO cover this case. The cron job is there because people sometimes manually move files around.
Are people regularly manually moving files? If so it's important to make sure you chmod the files for other users
really don't know but the permission was 620 and i should ask what was the workflow.
ok. so he has umask 077 and because we are using rsync the permission is persistent. maybe we should fix dbscripts and install the package with the right permission.
Patches welcome. :) -Dan
participants (3)
-
Aaron Griffin
-
Dan McGee
-
Ionut Biru