WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: [Solved]: patch for submitqc.tcz  (Read 6105 times)

Offline GNUser

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 1492
[Solved]: patch for submitqc.tcz
« 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.
« Last Edit: March 08, 2023, 10:37:44 AM by Rich »

Offline GNUser

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 1492
Re: patch for submitqc.tcz
« Reply #1 on: March 06, 2023, 11:54:39 AM »
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.

Offline Rich

  • Administrator
  • Hero Member
  • *****
  • Posts: 11560
Re: patch for submitqc.tcz
« Reply #2 on: March 06, 2023, 12:34:07 PM »
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?

Offline GNUser

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 1492
Re: patch for submitqc.tcz
« Reply #3 on: March 06, 2023, 12:46:25 PM »
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.

Offline GNUser

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 1492
Re: patch for submitqc.tcz
« Reply #4 on: March 06, 2023, 01:06:47 PM »
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?
« Last Edit: March 06, 2023, 01:10:29 PM by GNUser »

Offline Rich

  • Administrator
  • Hero Member
  • *****
  • Posts: 11560
Re: patch for submitqc.tcz
« Reply #5 on: March 06, 2023, 01:11:06 PM »
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?

Offline GNUser

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 1492
Re: patch for submitqc.tcz
« Reply #6 on: March 06, 2023, 01:16:54 PM »
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.

Offline GNUser

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 1492
Re: patch for submitqc.tcz
« Reply #7 on: March 06, 2023, 02:08:37 PM »
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.
« Last Edit: March 06, 2023, 02:14:18 PM by GNUser »

Offline GNUser

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 1492
Re: patch for submitqc.tcz
« Reply #8 on: March 06, 2023, 02:22:22 PM »
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.

Offline nick65go

  • Hero Member
  • *****
  • Posts: 831
Re: patch for submitqc.tcz
« Reply #9 on: March 06, 2023, 03:25:59 PM »
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?
« Last Edit: March 06, 2023, 03:40:36 PM by nick65go »

Offline GNUser

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 1492
Re: patch for submitqc.tcz
« Reply #10 on: March 06, 2023, 03:50:45 PM »
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.

Offline nick65go

  • Hero Member
  • *****
  • Posts: 831
Re: patch for submitqc.tcz
« Reply #11 on: March 06, 2023, 03:55:27 PM »
: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.
« Last Edit: March 06, 2023, 04:11:05 PM by nick65go »

Offline nick65go

  • Hero Member
  • *****
  • Posts: 831
Re: patch for submitqc.tcz
« Reply #12 on: March 06, 2023, 03:57:44 PM »
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.
« Last Edit: March 06, 2023, 04:02:05 PM by nick65go »

Offline GNUser

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 1492
Re: patch for submitqc.tcz
« Reply #13 on: March 06, 2023, 03:59:31 PM »
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.

Offline GNUser

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 1492
Re: patch for submitqc.tcz
« Reply #14 on: March 06, 2023, 04:06:51 PM »
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.
« Last Edit: March 06, 2023, 04:08:42 PM by GNUser »