su: can't chdir to home directory /home/tc

[baz]

I enabled the boot code "showapps" and I am also using a custom user "baz". My boot screen is now littered with the message "su: can't chdir to home directory /home/tc" for every app that loads. It doesn't seem to be causing any real problems but thought I should mention it in case it may affect something down the road.

[bmarkus]

I think using other user than 'tc' is risky. There are applications expecting 'tc' and not tested for other users. I advice use tc and when your setup works as expected change it to 'baz'. It will help you to identify misbehaving applications.

[baz]

You are very right, I've had a lot of issues, but I am willing to be the guinea pig to get it up to speed if the team is into it. Is that something TC cares about, or should I just forget about it for the moment?

It would be nice to have a proper multi-user environment, with passwords required and all that, like other distros.

[bmarkus]

Please note, that TC is a very young system introducing new ideas. Actually core team is focusing other tasks; as far as I see real multi user environment will come in a later phase of the project.

[danielibarnes]

@Developers: please read below for what may be bugs.

@baz

My boot screen is now littered with the message "su: can't chdir to home directory /home/tc" for every app that loads.

You don't mention which version you are using. I recall this being a problem with an early version. I booted Tiny Core 2.8.1 with the options: pause showapps user=baz. All of my extensions loaded without error. This means your issues can be fixed once we determine what the problem is.

@ bmarkus

as far as I see real multi user environment will come in a later phase of the project.

How do you define "multi user environment" and in what way does Tiny Core not fulfill that definition? In my mind, being able to create users and groups makes a multi-user environment, but I can see there being more to it than that for other people. As a quick test to answer my own question to you, I created a user: user1 (no password because I scripted it):

# adduser -D user1
# echo user1:user1|chpasswd

I found a few of what could be bugs:

1) The /etc/skel files are not copied to the user's home directory, even if -h is used.
2) The /etc/skel/.webdata.lst file includes the text "home/tc." I'm not sure how this file is used.
3) .logo.xpm is not included in /etc/skel

I fixed the home directory:
# rmdir /home/user1
# cp -r /etc/skel /home/user1
# cp /home/tc/.logo.xpm /home/user1

Modified the .webdata.lst file:
# sed 's/tc/user1/' -i /home/user1/.webdata.lst

Changed the ownership:
# chown -R user1:user1 /home/user1

Created a backup file (only as a test -- a true multiuser system would have a /home partition):
# tar czf /mnt/hda2/mutce/mydata.tgz /etc/passwd /etc/shadow /etc/group /home/user1

Reboot and start tinycore with tce=hda2/mutce noautologin boot options. Login as user1 and run startx. This is where I think your concerns are. There are several "sudo" statements in /usr/bin/startx. This will cause X to fail for non-tc users. If those are commented out so X can start, the "Logout --> Exit to prompt" function in the menu still fails, possibly because /usr/bin/exittc includes
sudo pkill `cat /etc/sysconfig/Xserver`.

I think the next question is, can this be fixed or does it require re-architecting Tiny Core in some way? The sudo statements are embedded everywhere. There are some things, like Appbrowser, which don't make sense to provide to non-tc users. But for things like "exit to prompt", can sudo be removed? I think that is the beginning of the answer.

[bmarkus]

@ bmarkus

as far as I see real multi user environment will come in a later phase of the project.

How do you define "multi user environment" and in what way does Tiny Core not fulfill that definition? In my mind, being able to create users and groups makes a multi-user environment, but I can see there being more to it than that for other people.
...

You answered the question For example window managers, like Xfce4 and LXDE but for sure other bit more complex programs too must setup an initial setup in user's home like different config files, initalize variables, create directory structure (re)start services, etc. There are programs with hardwired home, there are others taking care of it, etc.

Also, at the moment user's home must be in /home dir due to base system limitations (backup, etc.) which is not true for an ordinary system where you can put home dir to anywhere which is r/w and so on.

Just few points but for sure there are others. All together there are no guarantee that a certain application will work with other user different than tc

[curaga]

Appears busybox adduser doesn't support the etc/skel functionality. IIRC on GNU adduser one has to give the -m option as well, it's not the default.

Looks like this is in bb master, but not in any released version though.

[danielibarnes]

Note: the topic of discussion has split from the original question posed by baz.

window managers ... must setup an initial setup in user's home

It appears the scripts in /etc/skel try to be independent of which window manager is in use, but I can see there may be files necessary for one WM that are completely unnecessary for another. Perhaps each WM extension can provide it's own or something. I'm not sure how it is handled by other distros.

you can put home dir to anywhere which is r/w

We need a list of things like this (i.e. requirements) if the developers are to evaluate "can TC be multi-user."

there are no guarantee that a certain application will work with other user different than tc

For extensions, that can be left to the maintainer, but for the core there need to be red/green tests based on the aforementioned list to show the requirements were met. Each app or script in TC can be classified as tc-only or multiuser-compatible. If it is compatible, then it needs to be tested. If it is tc-only then it needs to be properly gated against use by non-tc users.

busybox adduser doesn't support the etc/skel functionality.

In which case bug #1 goes away by using the GNU utility, but #2 and #3 still apply if #3 is applicable. Is solving #2 more than simply replacing /home/tc with ~/ ?

[maro]

I'd like to add my 2c, and will try to provide an explanation for the messages that were reported by the OP. I've used TC 2.9rc4 for my analysis, but I strongly believe that the same would happen when using TC 2.8.1:
 
(1) I assume that the OP has removed the '/home/tc' directory, but not the entry for user 'tc' in the '/etc/passwd' file.

(2) The messages are been generated during the execution of '/usr/bin/tce-setup' (which itself is called by '/etc/init.d/tc-config'). When using boot parameter 'showapps' the respective branch in 'tce-config' does not suppress any message (i.e. /usr/bin/tce-setup "booting"). Without this boot parameter all messages are suppressed (i.e. /usr/bin/tce-setup "booting" > /dev/null 2>&1 &).

(3) In 'tce-setup' the following lines contain hard-coded references to user 'tc':
    7:USER="tc"
    15:  su tc -c 'tce-load '"$FLAGS"' '"$FILE"

The fact that in the case of the OP the user 'tc' still exists allows for the successful installation of extensions at boot time. If one removes this user permanently from the system (e.g. re-mastering of the initrd) no extensions would be loaded at boot time. This is due to the fact that the 'su' command would fail completely (instead of merely issuing warnings).

A potential improvement would be to replace to two lines in '/usr/bin/tce-setup' with something along the lines of:
    7:[ -n $USER ] || USER="tc"
    15:  su $USER -c 'tce-load '"$FLAGS"' '"$FILE"

[roberts]

Since tce-setup is typically run from initd, there would be no value for USER.
However the boot parameter user value is stored in /etc/sysconfg/tcuser and thus USER should be set using that value. It will be in 2.9 final.

[moB]

...

We need a list of things like this (i.e. requirements) if the developers are to evaluate "can TC be multi-user."
...

If it is compatible, then it needs to be tested. If it is tc-only then it needs to be properly gated against use by non-tc users.
...

Yes. Other distros have had similar troubles - eg DSL/DSL-N had the appbrowser appear on other users' desktops even though they had no access to its functionality.

Good term "gated". I like that; just what is needed.

b

ps don't mean to imply that TC is a derivative of that other OS. TC is obviously a new project lead by RobertS. (That other ship is clearly sinking without him.)

"if you have anything important to tell us, out with it"
Moby-Dick