permission errors

[jpeters]

I know I posted a similar issue for tc_2.3RC1.  I was able to reproduce it in TC_2.3.1  logging in both as tc and as root (noautologin), right after rebooting.   I haven't tried with base, norestore.   /usr/local/tce.installed changes to root:root after the install. I think it only happened with ram install. I'll experiment a little more.  (edit: I just noticed the date!)

Code: [Select]

tc@box:~$ ls -ld /usr/local/tce.installed
drwxr-xr-x    2 tc       staff        1520 Sep 14 22:10 /usr/local/tce.installed
tc@box:~$ tce-load -i -r -w xonclock.tcz
sed: couldn't open temporary file /opt//sedyEdQTY: Permission denied
Connecting to distro.ibiblio.org (152.46.7.109:80)
xonclock.tcz         100% |*******************************|   212k 00:00:00 ETA
xonclock.tcz: OK
tc@box:~$ ls -ld /usr/local/tce.installed
drwxr-xr-x    2 root     root         1540 Jan  1  1970 /usr/local/tce.installed



edit: I get the sed error, but permissions remain with regular tcz install:

Code: [Select]

tc@box:~$ ls -ld /usr/local/tce.installed/
drwxr-xr-x    2 tc       staff        1520 Sep 14 22:36 /usr/local/tce.installed                          //
tc@box:~$ tce-load -i -w xonclock.tcz  
sed: couldn't open temporary file /opt//sed7rq4kF: Permission denied
Connecting to distro.ibiblio.org (152.46.7.109:80)
xonclock.tcz         100% |*******************************|   212k 00:00:00 ETA
xonclock.tcz: OK
tc@box:~$ ls -ld /usr/local/tce.installed/
drwxr-xr-x    2 tc       staff        1540 Sep 14 22:38 /usr/local/tce.installed                          //

Edit:

I booted base norestore and got same problem (although no sed error):

Code: [Select]

tc@box:~$ ls -ld /usr/local/tce.installed
drwxrwxr-x    2 tc       staff          60 Sep 14 22:44 /usr/local/tce.installed/
tc@box:~$ tce-load -i -r -w xonclock.tcz
Connecting to distro.ibiblio.org (152.46.7.109:80)
graphics-libs-1.tczl 100% |*******************************|   772k 00:00:00 ETA
graphics-libs-1.tczl: OK
Connecting to distro.ibiblio.org (152.46.7.109:80)
expat2.tczl          100% |*******************************| 69632  00:00:00 ETA
expat2.tczl: OK
Connecting to distro.ibiblio.org (152.46.7.109:80)
fontconfig.tczl      100% |*******************************|   112k 00:00:00 ETA
fontconfig.tczl: OK
Connecting to distro.ibiblio.org (152.46.7.109:80)
xonclock.tcz         100% |*******************************|   212k 00:00:00 ETA
xonclock.tcz: OK
tc@box:~$ ls -ld /usr/local/tce.installed
drwxr-xr-x    2 root     root          140 Jan  1  1970 /usr/local/tce.installed/


[jpeters]

Looks like the culprit is the wrapper getting passed to /usr/local/tce.installed.  The give away is the date:

Code: [Select]

tc@box:/usr/local/tce.installed$ ls -l xonclock
-rwxr-xr-x    1 tc       staff         132 Jan  1  1970 xonclock

Looks like the xonclock permission has been fixed, though (despite the date).  The directory permission seems to get altered by the last installed extension.  If it's root:root, it won't be able to write the next extension that gets loaded. (this could get weird with submitted extensions w/wrappers)

Code: [Select]

tc@box:~$ ls -ld /usr/local/tce.installed/
drwxr-xr-x    2 tc       staff        1780 Jan  1  1970 /usr/local/tce.installed//


[roberts]

When creating extensions it is important to preserve all upstream permissions.

[jpeters]

When creating extensions it is important to preserve all upstream permissions.

While technically perhaps an extension issue, the vulnerability quickly becomes an os issue. A quick check in tce-load would close it.  (I've got one in "update")

edit: the problem continues after a reboot with the automatic load:

Code: [Select]

tc@box:/usr/local$ ls -ld tce.installed/
drwxr-xr-x    2 tc       staff        1780 Jan  1  1970 tce.installed//


[roberts]

I could do that until the next upstream file is clobbered by a poorly constructed extension.
It should not be up to the OS to revalidate every upstream file, as that would surely slow down the whole system. Following proper extension creation rules makes for an optimum results.

[bmarkus]

Following proper extension creation rules makes for an optimum results.

And evaluation of extensions against these rules.

[roberts]

Any *nix system can be clobbered by changing certain permissions. It is not unique to core.

[Jason W]

I am in the middle of updating the extension audit script that will test for the permssions of /usr/local/tce.installed.  I will use it before posting extensions, and as before it is advisable to use it to test with before submitting.

[Jason W]

I have converted all the cramfs/zisofs extensions to squashfs and along with the most existing squashfs extensions have corrected the permissions of /usr/local/tce.installed in each one.  There shouldn't be any more problem with this but if there is please list the offending extensions in this thread.

[curaga]

Wow Jason, you're doing a lot of work. Scripted probably, but still. Thanks for all you do.

[Jason W]

Thanks.

It was scripted for sure.    Did the uploading while I slept so not much time was invested.

[jpeters]

Probably trivial, but what's with the weird dates, like in xonclock, that then are then listed for /usr/local/tce.installed?   Is there a way not to clobber tce.installed's permissions? 

[curaga]

cramfs does not store dates. One of the limitations it has.