suid root on extensions

[wdchromium]

I was wondering if there was any way I can set a binary as suid root if the binary comes from a mounted extension.  That is, without me compiling the extension myself.  In this case, I just need suid root on screen for multiuser sharing.

$ sudo chmod +s /usr/local/bin/screen
chmod: /usr/local/bin/screen: Read-only file system

Since I know screen is just a symlink to a readonly mount on /tmp/tcloop--etc... ts the best way overwriting the /usr/local/bin symlink with the  binary and adding it to .filetool.list?

Or is there a more elegant solution?

[tinypoodle]

More elegant solutions I could think of:

1. Unsquash the extension, make your changes, squash again.
2. Make your cause for a change to the package maintainer (references might help supporting it), only if you think that would not have negative impact on the majority of users.

[hiro]

Copying is also ok, it's probably the only elegant solution in cloud mode.
I have this in /usr/local/bin/fl

#!/bin/sh
#
# ----s links.
# usage: fl '/----ingpath/----inglink'

NAME=$(basename $1) && DIR=$(dirname $1) && cd $DIR && sudo cp $NAME $NAME.tmp && sudo rm $NAME && sudo mv $NAME.tmp $NAME

I guess I watched too much George Carlin

{Edited for profanity by Jason W}

[wdchromium]

*bump head*

Sometimes, when I stare at a problem for too long, I get into the idea that I have gone over all the possible solutions, and unsquashing has never even occurred to me, despite how many extensions I've made for my distro.

That's definitely the solution I'm looking for, since I'd certainly prefer not to have all these changes end up in my mydata.tgz, cluttering up the place.

Thanks a ton! It'll push me way forward!

[hiro]

heh, just be careful not to update your packages too often. I updated wicd,gtk2 today and now without a working gtk2 I don't have internet anymore on one pc

I would like to note that recovering from such bugs is so great that I will stop cursing for today. I connected an old LAN cable, booted with the base kernel option, removed my whole optional directory and executed tce-load -wi `cat onboot.lst`.

One more reason why I think resquashing extensions is not always great and elegant.

[wdchromium]

The idea of unsquashing actually gave me ANOTHER idea which I think ended up being far better, given updating and maintenance.

I ended up just creating my own extension, containing the numerous modifications I make to microcore, but as a scripted change.  So instead of saving /usr/local/bin/screen, i have my extension consider 'screen' a dependency (ensuring its loading before), I then copy the actual binary from screen's symlink (/tmp/tcloop/screen/usr/local/bin/screen) and copy the actual extensions binary to the directory where I can modify its suid root.

This makes it upgrade-safe and makes my changes not depend on mydata.tgz!  Perfect!

[tinypoodle]

But at the cost of additional memory usage equal to unsquashed and copied files (if I understood the details right).

[wdchromium]

Correct, this comes at the cost of a minimal amount of memory, but an amount which cannot be avoided if I wish to maintain updatability of the screen package. What I'm doing is simply overwriting the symlink, which has a negligible memory footprint of 45bytes)

lrwxrwxrwx    1 root     root            45 Dec 22 03:48 screen -> /tmp/tcloop/screen/usr/local/bin/screen
-rwsr-sr-x    1 root     root        241204 Dec 22 03:48 screen

So yep definitely, since I'm copying the screen binary to the file system, it incurs a direct cost of 241204 bytes.  However, in my particular situation, I value 241204 bytes of RAM less than I do the version dependency, so it'll all work out.