[Solved]: patch for submitqc.tcz

[GNUser]

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.

[GNUser]

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.

[Rich]

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?

[GNUser]

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.

[GNUser]

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?

[Rich]

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?

[GNUser]

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.

[GNUser]

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.

[GNUser]

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.

[nick65go]

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?

[GNUser]

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.

[nick65go]

: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.

[nick65go]

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.

[GNUser]

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.

[GNUser]

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.