(old)Puppy Linux Discussion Forum

Here is the problem.. I wish i could find the link.

If permissions on /tmp are not drwxrwxrwt (or 1777) some cups drivers do not work. We found this problem occurring time and time again in Lupu, and it was mainly because of bad DEB packages with 755 or drwxr-xr-x. A package that contains those permissions will change the permissions on /tmp on the system. Some debs were so bad that they weren't even owned by root! They would default to users:500.

I know you delete the file directly but the damage is done. As soon as the pet gets extracted to it's path the permissions change, check your /tmp, permissions will likely be wrong.

It also affects users who want to use the universal installer to install to a USB drive, I don't know why but it is reported in the slacko-5.4 bug thread, I can find that link.. http://murga-linux.com/puppy/viewtopic. ... 630#677630

I hope this gives you some understanding. I had problems with zigbert's Pmusic too, as he was using /tmp as a temporary location to install other stuff, rox right clicks I think, that don't work in woof.

It's not for me, because woof changes the permissions to 1777 when the build is almost complete. it's for the users out there installing and testing. They may find later on that printing has failed or they can't get their USB stick to work. These problems are difficult to debug. If I see a post like that I'll ask for the output of ls -l /

NOTE: You only need to change the permissions on /tmp and no other directory in your package tree.
. . .
In rox, if you select "properties" you get the checkboxes, all on the left (9 of them) should be checked and on the right the bottom one.. "sticky" is the label.

Master_wrong
. . .
during install into usb flashdisk there is syslinux error
Quote:
possibly unsafe /tmp/ permissions

fix
Quote:
chmod 1777 /tmp

then run installer
_________________

01micko

Perms are already 1777 on /tmp. You may have installed a bad package.
_________________

SFR

@Master_wrong & @01micko

That's strange, but in my case /tmp sometimes has 1777 and sometimes 777.
Eg. in my install (pmedia=ataflash on internal SATA HDD) it had 777 by default and I couldn't make it to preserve 1777 after reboot.
(/initrd/pup_ro2/tmp has 777 as well, perhaps that's why?)
I simply added chmod 1777 /tmp to rc.sysinit to achieve this.

On the other hand, when I switch to pmedia=atahd, /tmp suddenly becomes 1777 and, in addition, it appears as a mount point.
(I checked this a few minutes ago in VBox, 5.4-PAE)

Also, pristine boot without a savefile also gives /tmp 777.

IIRC I noticed this also in 5.3.3, but I didn't report it, because usually I have "luck" of experiencing "it's_just_me" kind of issues...

--- dir2pet-5492	2013-01-13 19:09:21.000000000 -0500
+++ dir2pet	2013-03-02 16:33:48.000000000 -0500
@@ -13,6 +13,7 @@
 #w482 if preexisting pet.specs, read fields from it.
 #100201 improve reading of pet.specs
 #100303 fix bug detection arch-dependent pkg.
+#130302 ensure package tmp directory, if any, has all permissions.
 
 if [ ! $1 ];then
  echo "It is required to invoke this script like this:
@@ -347,6 +348,8 @@
  exit
 fi
 
+[ -d $DIRPKG/$BASEPKG/tmp ] && chmod 1777 $DIRPKG/$BASEPKG/tmp #130302
+
 cat /tmp/petspec_db_entry | tail -n 1 > $DIRPKG/$BASEPKG/pet.specs
 
 echo



--- installpkg-5492.sh	2013-02-19 08:35:15.000000000 -0500
+++ installpkg.sh	2013-03-02 16:31:22.000000000 -0500
@@ -47,6 +47,7 @@
 #130114 revert 130112 "multiarch symlinks now optional".
 #130126 'categories.dat' format changed.
 #130219 grep, ignore case.
+#130302 ensure tmp directory has all permissions after package expansion.
 
 #information from 'labrador', to expand a .pet directly to '/':
 #NAME="a52dec-0.7.4"
@@ -358,6 +359,8 @@
 mv /*.xpm /usr/local/lib/X11/mini-icons/ 2>/dev/null
 mv /*.png /usr/local/lib/X11/mini-icons/ 2>/dev/null
 
+ls -dl /tmp | grep -q '^drwxrwxrwt' || chmod 1777 /tmp #130302
+
 #post-install script?...
 if [ -f /pinstall.sh ];then #pet pkgs.
  chmod +x /pinstall.sh

phdzaps wrote:I am not sure if it is a real improvement or not but I think it is:
in /usr/sbin/delayedrun, I change line 199 to read:
[ -x "$a" ] && exec $a &
Things seem to run slightly better for me after. This is in multiple versions of puppy also.

666philb wrote:hi anikin

did you see my reply in the other thread?

rerwin wrote:01micko has been after me to clean up the /tmp directory permisions in my frisbee-1.0 packages, because it created situtaion that jeopardizes puppy stablity/rebustness. I have corrected that problem in the 20130228 version now available in the usual places.

Here is his patient explanation to me:

Here is the problem.. I wish i could find the link.

If permissions on /tmp are not drwxrwxrwt (or 1777) some cups drivers do not work. We found this problem occurring time and time again in Lupu, and it was mainly because of bad DEB packages with 755 or drwxr-xr-x. A package that contains those permissions will change the permissions on /tmp on the system. Some debs were so bad that they weren't even owned by root! They would default to users:500.

I know you delete the file directly but the damage is done. As soon as the pet gets extracted to it's path the permissions change, check your /tmp, permissions will likely be wrong.

It also affects users who want to use the universal installer to install to a USB drive, I don't know why but it is reported in the slacko-5.4 bug thread, I can find that link.. http://murga-linux.com/puppy/viewtopic. ... 630#677630

I hope this gives you some understanding. I had problems with zigbert's Pmusic too, as he was using /tmp as a temporary location to install other stuff, rox right clicks I think, that don't work in woof.

It's not for me, because woof changes the permissions to 1777 when the build is almost complete. it's for the users out there installing and testing. They may find later on that printing has failed or they can't get their USB stick to work. These problems are difficult to debug. If I see a post like that I'll ask for the output of ls -l /

NOTE: You only need to change the permissions on /tmp and no other directory in your package tree.
. . .
In rox, if you select "properties" you get the checkboxes, all on the left (9 of them) should be checked and on the right the bottom one.. "sticky" is the label.

The link points to this conversation:

Master_wrong
. . .
during install into usb flashdisk there is syslinux error
Quote:
possibly unsafe /tmp/ permissions

fix
Quote:
chmod 1777 /tmp

then run installer
_________________

01micko

Perms are already 1777 on /tmp. You may have installed a bad package.
_________________

SFR

@Master_wrong & @01micko

That's strange, but in my case /tmp sometimes has 1777 and sometimes 777.
Eg. in my install (pmedia=ataflash on internal SATA HDD) it had 777 by default and I couldn't make it to preserve 1777 after reboot.
(/initrd/pup_ro2/tmp has 777 as well, perhaps that's why?)
I simply added chmod 1777 /tmp to rc.sysinit to achieve this.

On the other hand, when I switch to pmedia=atahd, /tmp suddenly becomes 1777 and, in addition, it appears as a mount point.
(I checked this a few minutes ago in VBox, 5.4-PAE)

Also, pristine boot without a savefile also gives /tmp 777.

IIRC I noticed this also in 5.3.3, but I didn't report it, because usually I have "luck" of experiencing "it's_just_me" kind of issues...

Attached are small mods to dir2pet and installpkg.sh to ensure correct permissions in a .pet and after installation of any package. Here are the difference listings:

Code: Select all

--- dir2pet-5492	2013-01-13 19:09:21.000000000 -0500
+++ dir2pet	2013-03-02 16:33:48.000000000 -0500
@@ -13,6 +13,7 @@
 #w482 if preexisting pet.specs, read fields from it.
 #100201 improve reading of pet.specs
 #100303 fix bug detection arch-dependent pkg.
+#130302 ensure package tmp directory, if any, has all permissions.
 
 if [ ! $1 ];then
  echo "It is required to invoke this script like this:
@@ -347,6 +348,8 @@
  exit
 fi
 
+[ -d $DIRPKG/$BASEPKG/tmp ] && chmod 1777 $DIRPKG/$BASEPKG/tmp #130302
+
 cat /tmp/petspec_db_entry | tail -n 1 > $DIRPKG/$BASEPKG/pet.specs
 
 echo



--- installpkg-5492.sh	2013-02-19 08:35:15.000000000 -0500
+++ installpkg.sh	2013-03-02 16:31:22.000000000 -0500
@@ -47,6 +47,7 @@
 #130114 revert 130112 "multiarch symlinks now optional".
 #130126 'categories.dat' format changed.
 #130219 grep, ignore case.
+#130302 ensure tmp directory has all permissions after package expansion.
 
 #information from 'labrador', to expand a .pet directly to '/':
 #NAME="a52dec-0.7.4"
@@ -358,6 +359,8 @@
 mv /*.xpm /usr/local/lib/X11/mini-icons/ 2>/dev/null
 mv /*.png /usr/local/lib/X11/mini-icons/ 2>/dev/null
 
+ls -dl /tmp | grep -q '^drwxrwxrwt' || chmod 1777 /tmp #130302
+
 #post-install script?...
 if [ -f /pinstall.sh ];then #pet pkgs.
  chmod +x /pinstall.sh

mchabez wrote:2. Package deps like "upstart-job" aren't resolved in PPM. There is no such package name "upstart-job" in the Ubuntu Precise repos, as it's a virtual package provided by "upstart". One such package dependent on upstart-job is "binfmt-support".