Tiny Core Linux
Tiny Core Extensions => TCE Talk => Topic started by: GNUser on March 06, 2023, 11:53:01 AM
-
Hi Rich. The same issue you reported here...
http://forum.tinycorelinux.net/index.php/topic,26077.msg167960.html#msg167960
...affects the iwd.tcz extension. To recap, the issue is that user tc gets locked out of an extension's file/directory if said file/directory is owned by UID 1000 and has no read/write permission for the staff group (e.g., ownership is bruno:staff on my system, with 700 permissions). I will submit a corrected iwd.tcz to you (for TCL14 x86_64) now.
-
I propose a patch to the submitqc script that changes any files/directories owned by UID 1000 (which is the normal user's UID when TCL boots with the user=foo boot code) to owned by tc. The proposed patch is attached for reference but I'll send you the complete submission.
This patch will prevent this kind of problem.
-
Hi GNUser
What happens if someone adds more users? Won't that result in UIDs 1000, 1001 (tc), 1002, etc.?
Would it make more sense to search for UID != 1001 to find UIDs to fix?
-
Every file and directory, including inside a squashfs, is owned by one user and one group. The tc:staff (human-readable version), aka 1001:50 (numeric id version), is the safest user:group combination for extension files/directories that should be owned by a non-root user because this combination exists on every TCL machine.
For regular users with UID != 1001 not to encounter "Permission denied" errors, the solution is for files/directories to be owned by the staff group and to have sufficient group permissions.
-
Ah, I think I understand what you are getting at, Rich.
My intention is for files/directories that should be owned by non-root user to have the default non-root user UID, which is 1001 on TCL.
So any UID that is 1000 or >1001 should be changed to 1001. Is this what you are suggesting?
-
Hi GNUser
OK, let me ask it a different way:
Someone booting with user=foo packages an extension. The result is UID == 1000.
The same machine with group, gshadow, shadow, sudoers, etc. backed up and persistent.
Same machine now booted with user=bar packages an extension. Is UID still equal to 1000?
-
If /etc/passwd is persistent and includes a line associating user foo with UID 1000, then booting with user=bar would probably result in UID 1002. I'll test that hypothesis now.
-
Hi Rich. I'm having trouble logging in to my system with user other than root and bruno. But I don't want to troubleshoot this. I think you are right--the real goal is not to detect ownership by UID 1000. The goal is to make sure that files/directories that should be owned by the regular user are owned by tc.
A simpler approach might be to check /etc/sysconfig/tcuser. If other than tc and squashfs contains files/directories owned by that tcuser, change ownership to tc.
What do you think of this approach? Updated patch is attached.
-
An even simpler solution might be to make sure that any files in squashfs that are not owned by root are owned by tc.
Are there rare instances where files/directories in an extension are meant to be owned by a user other than root or tc (e.g., virtual users such as lp)? If so, then this naive approach won't work.
-
An even simpler solution might be to make sure that any files in squashfs that are not owned by root are owned by tc.
Are there rare instances where files/directories in an extension are meant to be owned by a user other than root or tc (e.g., virtual users such as lp)? If so, then this naive approach won't work.
Yes! This is also the solution I applied to my personal TCZs: user=tc, group=staff.
Basically we mount in /tmp/tcloop, but the links are in /usr/bin , owner by root:root.
we could patch on the fly tc_UID and staff_GID in /etc/ (passwd, groups); because the cpio/ tar /gz use only ids but not real names. (seen from win10 with 7zip).
EDIT: even better, if you want to be sure that ONLY tc-UID use the appl, then you create a fake group GID, and all files in squash are owner by: tc:fake. Why you want to allow other not invited "users" to use your app in your system?
-
Hi nick65go. Regular user files/directories in extensions need to be owned by the staff group or else the extension won't work for users that use the user=foo boot code. When this boot code is used, user foo automatically added to the staff group.
I use user=bruno on all my TCL boxes. If you create an extension where regular user files/directories are owned by tc:fake, then I won't be able to use your extension.
-
:GNUser: "A simpler approach might be to check /etc/sysconfig/tcuser. If other than tc and squashfs contains files/directories owned by that tcuser, change ownership to tc."
me: I do not think you could do this. SquashFS is read-only. So ex: if UID=1300, GIU=1400 then that is, frozen. And then tce-load uses sudo to mount the tcz; in /usr/bin (owner root:root) are just link to files in /tmp, owned by UID=1300. What could be done is to create the user UID=1300 (on the fly?) in /etc/passwd and allow used tc UID=1000 (whatever default in TC) to squashfs user UID=1300, same group.
-
I use user=bruno on all my TCL boxes. If you create an extension where regular user files/directories are owned by tc:fake, then I won't be able to use your extension.
Correct, sorry, you talk about public extension, I was wrongly thinking about private tcz.
Like a firefox.tcz runs as user: group = 1300:1400, and tc has acess to UID=1300, and roup GID=1400 is non-existent.
-
SquashFS is read-only.
True. But the submitqc script unsquashes the squashfs when checking the extension. If changes need to be made, the script makes changes and then recreates the squashfs.
-
In this thread I'm specifically talking about extensions being created for the public repository. It's the only time that extensions owned by bruno:staff would ever be a problem.
I could manually change ownership of everything to tc:staff before submitting the extension, of course, but I think it's the job of submitqc to catch and fix small, pesky issues such as this.
-
Right! I am asleep at wheel. The core "problem" for submitqc is that TC community should agree to a common UID:GID for any tcz. Let be this default tc:staff; Or else I, for example, will be uncomfortable for some tcz to modify my /etc/passwd.
-
Hi Rich. Please critique my latest proposal at your convenience:
http://gnuser.ddns.net/public/submitqc.tar.gz.bfe
-
I finally understand what this was about:
http://forum.tinycorelinux.net/index.php/topic,26077.msg167960.html#msg167960
I think for vast majority of extensions (including the two affected by the above issue), the following are true:
- system files (e.g., those in /usr/local/bin and /var) should be owned by root
- access for non-root users is controlled by group and world permissions
In the case of the two affected extensions, the 700 permissions on the directory was a choice made by the upstream developer. Their assumption was that the relevant directory would be owned by root. Their intention was that only root should have access to the directory. This is a completely reasonable security measure that causes no breakage because every system has a root user.
At some point in the extension creation process, the extension maintainer (me :-[) made a mistake. System files which were owned by root somehow ended up being owned by the logged-in, non-root user on my machine (user bruno, UID 1000). Now the 700 permissions on the relevant directory is a little weird, even on my system. On someone else's system where a user with UID 1000 doesn't even exist, the 700 permissions on the directory is a disaster.
Long story short, mea culpa. If you guys want to accept the patch so that submitqc puts a bandaid when this kind of mistake is made, please go ahead. If you prefer correctness over bandaids and prefer not to include the patch, I completely understand.
-
Hi GNUser
I took a look at a few of my extensions (unsquashfs -lls ext.tcz) and most
entries came back as tc/staff. The one exception I found was:
drwxrwsr-x root/staff 33 2020-04-02 17:05 squashfs-root/usr/local/tce.installedI didn't set those users/permissions, so submitqc did that.
So submitqc already does correct some users/permissions.
... Are there rare instances where files/directories in an extension are meant to be owned by a user other than root or tc (e.g., virtual users such as lp)? ...
Maybe a tce.installed script should handle that?
Hi Rich. Please critique my latest proposal at your convenience:
http://gnuser.ddns.net/public/submitqc.tar.gz.bfe
It looks OK to me. Maybe some of the smarter kids could give it look
and provide some feedback. The diff can be found here:
https://forum.tinycorelinux.net/index.php?action=dlattach;topic=26146.0;attach=6380
The one thing I'm unsure of is after calling check_non_tc_user() will the script be able
to run to completion if a non tc user is running it.
I bring this up because initially I tried to use submitqc to correct the UIDs in eiwd.tcz. It
spit out lots of permission denied errors instead. Simply unsquashing/resquashing fixed
the UIDs and submitqc ran correctly.
-
Hi Rich. Thank you for looking it over.
In the meantime, I found this in the wiki (here (http://wiki.tinycorelinux.net/doku.php?id=wiki:creating_extensions)):
All extension creators please note
gutmensch provides the following set of rules:
...
All files root:root, 644 for files, 755 for executables, 755 for directories
...
So there it is. Best to just have root (UID 0), the universal user par excellence, own everything inside the squashfs.
For submitqc to change ownership from one non-root user to another non-root user would seem to contradict recommended best practice. Please just ignore my proposed patch. I'm sorry for the noise.
The one good thing from all this is that I updated the eiwd and iwd extensions for TCL14 x86_64, paying attention to follow best practices at every step. The two extensions have been tested and verified to be working. I will PM them to you.
As always, thank you very much for all your help.
-
Here are contents of an intentionally flawed extension I created for testing purposes:
$ unsquashfs -lls flawed.tcz
Parallel unsquashfs: Using 4 processors
2 inodes (2 blocks) to write
drwxr-xr-x bruno/staff 26 2023-03-07 13:43 squashfs-root
drwxr-xr-x bruno/staff 28 2023-03-07 13:43 squashfs-root/usr
drwxr-xr-x bruno/staff 47 2023-03-07 13:44 squashfs-root/usr/local
drwxr-xr-x bruno/staff 29 2023-03-07 13:45 squashfs-root/usr/local/bin
-rwxr-xr-x bruno/staff 31 2023-03-07 13:45 squashfs-root/usr/local/bin/flawed
drwxr-xr-x bruno/staff 29 2023-03-07 13:45 squashfs-root/usr/local/tce.installed
-rwxr-xr-x bruno/staff 16 2023-03-07 13:45 squashfs-root/usr/local/tce.installed/flawed
Running repo's submitqc with --fix flag results in an extension where some issues have been fixed but not all:
$ unsquashfs -lls flawed.tcz
Parallel unsquashfs: Using 4 processors
2 inodes (2 blocks) to write
drwxr-xr-x bruno/staff 26 2023-03-07 13:43 squashfs-root
drwxr-xr-x bruno/staff 28 2023-03-07 13:43 squashfs-root/usr
drwxr-xr-x bruno/staff 47 2023-03-07 13:44 squashfs-root/usr/local
drwxr-xr-x bruno/staff 29 2023-03-07 13:45 squashfs-root/usr/local/bin
-rwxr-xr-x bruno/staff 31 2023-03-07 13:45 squashfs-root/usr/local/bin/flawed
drwxrwxr-x root/staff 29 2023-03-07 13:45 squashfs-root/usr/local/tce.installed
-rwxr-xr-x tc/staff 16 2023-03-07 13:45 squashfs-root/usr/local/tce.installed/flawed
If I run my patched version of submitqc on the original flawed extension, it produces an extension without any of the issues:
$ unsquashfs -lls flawed.tcz
Parallel unsquashfs: Using 4 processors
2 inodes (2 blocks) to write
drwxr-xr-x tc/staff 26 2023-03-07 13:43 squashfs-root
drwxr-xr-x root/root 28 2023-03-07 13:43 squashfs-root/usr
drwxr-xr-x root/root 47 2023-03-07 13:44 squashfs-root/usr/local
drwxr-xr-x root/root 29 2023-03-07 13:45 squashfs-root/usr/local/bin
-rwxr-xr-x root/root 31 2023-03-07 13:45 squashfs-root/usr/local/bin/flawed
drwxrwxr-x root/staff 29 2023-03-07 13:45 squashfs-root/usr/local/tce.installed
-rwxrwxr-x root/staff 16 2023-03-07 13:45 squashfs-root/usr/local/tce.installed/flawed
The patch is attached, in case it (in whole or in part) is useful to the team.
P.S. Adjusting the ownership of extension's root directory to tc:staff is not strictly necessary but I want it for cosmetic reasons, if nothing else. It seems the majority of extensions in the repo (including juanito's, which serve as a gold standard for me) have it--the mount point ownerships you see in output of ls -l /tmp/tcloop correspond to the ownership of each extension's root directory.
P.P.S. I realize that I'm obviating the need for the CHANGES variable to exist, given that my patched version always rebuilds the extension. I didn't bother to remove the many occurrences of the CHANGES variable because at this point the patch is for demonstration purposes and personal use only.
-
One option might be to add the proposed functionality to the --fix flag behavior, while keeping the script's default behavior and CHANGES variable intact.
Rich and curaga, if you like the above idea I can create a patch to achieve it. Please let me know what you think. I would love to have this helpful functionality in the official version of the script.
-
Hi GNUser
I didn't even know there was a --fix flag. If there are known paths/file types
that should have certain ownerships/permissions I think the default should be
to set them correctly.
-
If there are known paths/file types that should have certain ownerships/permissions I think the default should be to set them correctly.
I agree, but am shy about making big changes to such a venerable script as submitqc.
The patch in Reply #20 can be used as-is or I can polish it further (e.g., get rid of CHANGES variable if we are always going to rebuild the squashfs). I'd be interested in curaga's thoughts as well. Then I can try to create a patch that makes everyone happy.
P.S. Another other odd thing about current submitqc behavior is that it puts tc:staff ownership on startup scripts. The wiki clearly states that root:staff is the preferred ownership for startup scripts (see here (http://wiki.tinycorelinux.net/doku.php?id=wiki:creating_extensions#adding_custom_startup_scripts)).
-
Hi Rich. I polished my patch and would like to propose that the attached version be merged.
With patch, submitqc fixes common ownership/permission mistakes by default. Current version in repo fails to fix these issues.
-
I think the changes are a good idea, but I should mention I don't really deal with this script.
-
Thanks for the feedback, curaga.
Since it seems we have consensus, I will submit updated submitqc.tcz extension to Rich via PM.
Thank you both. Topic may be marked as solved.
-
Hi GNUser
... Topic may be marked as solved.
Done. :)
-
Thank you :)
-
I finally understand the root issue here (no pun intended).
sudo make DESTDIR=/foo/bar installThe above results in root ownership of files inside /foo/bar. All is well because files inside extensions should be owned by root.
Contributor creates baz.tcz from /foo/bar and root ownership is preserved inside the squashfs. All is still well.
But the moment contributor runs unsquashfs baz.tcz (to check something, add a file, or whatever), ownership of everything inside the squashfs-root directory is changed to tc:staff (or bruno:staff in my case). Running 2020 version of submitqc afterwards doesn't fix the non-root ownership once it has crept in.
-
Hi GNUser
TC14 x86 and x86_64 repos have been updated.
If anyone installed submit.tcz since reply #26, please update your copy for a bug fix.
-
Hi Rich. I updated submitqc.tcz on my TC14 x86_64. Works like a dream now.
IMHO now submitqc does everything an extension submitter assumes it is doing. This includes ensuring that ownership and permissions of key files/directories conform to what is recommended in the wiki.
Happy hacking :)
-
hi GNUser
thanks for submitqc, I rely on it fix a lot of my mistakes.
umm because I have AMD APU and unable to boot into xbase.lst I found a command on the web you might consider adding for dep suggestions to submitter?
tce-load -i binutils
readelf -d /pathway2/executable | grep 'NEEDED'
I then use Apps provides to see what TCE contains needed
I then use a local searchtce script to see if I can shorten my dep list.
here is example for you of extra TCE research
0x0000000000000001 (NEEDED) Shared library: [libfontconfig.so.1] # fontconfig -> libXft
so I used apps to get TCE name......and found it is a dep of libXft
Naturally it works on shared object files and I know others tend to use ldd
-
Hi aus9. My workflow for building .dep files is the same as yours. I use readelf -d as well.
Rich has created a script that may do what you are asking for. I haven't tested it yet but like the idea:
http://forum.tinycorelinux.net/index.php/topic,26040.0.html
-
thanks I have bookmarked Rich's script.
-
hi GNUser
forgive me for following feedback....ignore the fact that my build no longer needs some packages and
because its a GUI, I have added an icon theme for a tce.install script to update icon cache.
When you get a chance....can you stop a report of a dep with both a negative and + entry
see imlib2 as reported as missing and then it find it is not missing....in submitqc under "missingdeps" report
--- /tmp/submitqc/missingdeps/feh.tcz.dep.remote 2021-12-26 13:10:10.000000000 +0000
+++ ./feh.tcz.dep 2023-03-13 06:00:34.550051675 +0000
@@ -1,7 +1,8 @@
-imlib2.tcz
-libexif.tcz
-libXinerama.tcz
curl.tcz
-libjpeg-turbo-bin.tcz
-jpegexiforient.tcz
-gtk2.tcz
+file.tcz
+libXinerama.tcz
+libexif.tcz
+libpng.tcz
+libX11.tcz
+imlib2.tcz
+hicolor-icon-theme.tcz
let me know your thoughts when you get a chance please
-
Hi aus9. I briefly looked into your issue.
First I did some sanity checks:
- feh is dynamically linked to libImlib2.so.1, which is provided by imlib2.tcz
- none of feh's other dependencies bring in imlib2.tcz, so imlib2.tcz does need to be present in feh.tcz.dep
- feh.tcz.dep includes imlib2.tcz, so we're good
I ran submitqc --libs on feh.tcz and am not seeing any conflicting information about imlib2.tcz.
Honestly, I don't use submitqc to help me build .dep files (I use readelf + provides.sh + deptree) so I'm not too familiar with what submitqc does in this regard. But I can tell you that If you did find a bug in submitqc, it is not related to the patches I've submitted recently, which deal only with setting correct ownerships/permissions in the squashfs.
I don't have time to look into this further right now, unfortunately.
[Edit]: Changed imlib,tcz to imlib2.tcz. Rich
-
Oops. Everywhere I wrote imlib.tcz I meant imlib2.tcz.
-
Hi GNUser
Fixed.
-
Hi aus9
... When you get a chance....can you stop a report of a dep with both a negative and + entry
see imlib2 as reported as missing and then it find it is not missing....in submitqc under "missingdeps" report ...
It's running a diff between your .dep file and the current .dep file in the repo.
Place the common dependencies in the same order at the beginning of your file
as the ones in the repo .dep file like this:
imlib2.tcz
libexif.tcz
libXinerama.tcz
curl.tcz
file.tcz
libpng.tcz
libX11.tcz
hicolor-icon-theme.tczand you won't see that behavour.
By the way, you don't need to include libpng.tcz and libX11.tcz. They get pulled
in by imlib2.tcz:
rich@tcbox:~$ cat imlib2.tcz.tree
imlib2.tcz
freetype.tcz
libpng.tcz
harfbuzz.tcz
glib2.tcz
libffi.tcz
pcre.tcz
graphite.tcz
bzip2-lib.tcz
libjpeg-turbo.tcz
libpng.tcz <-------------
libXext.tcz
libX11.tcz <----------
libxcb.tcz
libXau.tcz
libXdmcp.tcz
-
GNUser
no worries my fault in not spotting layout is same as a diff command. I blame me for not being a real coder :-[
Hi Rich
sorry for the noise