sh: Remove /.profile

[ivy]

Summary

root's home directory was moved to /root many years ago, so there's no
reason to keep this old link. This brings sh in line with csh, where
/.cshrc was removed in dcb65c5a94d4.

As a side-effect, since /.profile doesn't have the @config tag, this
prevents pkgbase upgrades from overwriting /root/.profile.

Relnotes: yes
PR: 289097

[grahamperrin]

Thanks, people.

Commit log messages for D52161 and D52162 should, please, show:

Reported by: Vivek Khera <vivek at khera.org>

(Nickname: Vick.)

Permission to show his name and email address was granted in private chat a few minutes ago.

[rgrimes]

Note that root does NOT have a home of /root when booted single user. Your going to nuke the environment for root when booted single user.

[emaste]

OK boot -s
Loading kernel...
...
Enter full pathname of shell or RETURN for /bin/sh:
root@:/ # echo $HOME
/root
root@:/ #

[grahamperrin]

Thanks,

In D52161#1191869, @rgrimes wrote:

… single user.

Is either .cshrc or .profile intended to be effective in this mode?

(I'm blissfully ignorant.)

[emaste]

In D52161#1191886, @grahamperrin wrote:

In D52161#1191869, @rgrimes wrote:

… single user.

Is either .cshrc or .profile intended to be effective in this mode?

I don't see a reason it should not be.

I tried it on my system (the text block above) and confirmed that sh read /root/.profile when booted in single user mode.

[kevans]

In D52161#1191888, @emaste wrote:

In D52161#1191886, @grahamperrin wrote:

In D52161#1191869, @rgrimes wrote:

… single user.

Is either .cshrc or .profile intended to be effective in this mode?

I don't see a reason it should not be.

I tried it on my system (the text block above) and confirmed that sh read /root/.profile when booted in single user mode.

I actually can't reproduce that result here. If I remove /.profile and add a SECRETVAR to /root/.profile, it's not populated (and I don't really see where we'd get a $HOME from in init or early /bin/sh)

[rgrimes]

In D52161#1191907, @kevans wrote:

In D52161#1191888, @emaste wrote:

In D52161#1191886, @grahamperrin wrote:

In D52161#1191869, @rgrimes wrote:

… single user.

Is either .cshrc or .profile intended to be effective in this mode?

I don't see a reason it should not be.

I tried it on my system (the text block above) and confirmed that sh read /root/.profile when booted in single user mode.

I actually can't reproduce that result here. If I remove /.profile and add a SECRETVAR to /root/.profile, it's not populated (and I don't really see where we'd get a $HOME from in init or early /bin/sh)

First to Ed, did you rm /.profile? As if you read the contents you well see that it SETS /home.

To kevans, thanks that confirms that it was /.profile that set home.

[emaste]

First to Ed, did you rm /.profile? As if you read the contents you well see that it SETS /home.

I should have it removed in this test VM, but I see I do have some extra /bin/sh commits in my tree although just diagnostics I think. With Kyle's check though I imagine there's something unusual in my environment so will check.

[kevans]

In D52161#1191908, @rgrimes wrote:

In D52161#1191907, @kevans wrote:

In D52161#1191888, @emaste wrote:

In D52161#1191886, @grahamperrin wrote:

In D52161#1191869, @rgrimes wrote:

… single user.

Is either .cshrc or .profile intended to be effective in this mode?

I don't see a reason it should not be.

I tried it on my system (the text block above) and confirmed that sh read /root/.profile when booted in single user mode.

I actually can't reproduce that result here. If I remove /.profile and add a SECRETVAR to /root/.profile, it's not populated (and I don't really see where we'd get a $HOME from in init or early /bin/sh)

First to Ed, did you rm /.profile? As if you read the contents you well see that it SETS /home.

To kevans, thanks that confirms that it was /.profile that set home.

I think I've seen this (valid) argument from you for removing /.profile twice now, but I don't think I've seen you comment on the reason it is like this: how do you feel about trying to set $HOME in init(8) when we invoke the single-user shell?

jrtc27 (intentionally untagged) notes that there's some precedence in sysvinit's sulogin, and systemd's rescue/emergency services:

• https://sources.debian.org/src/systemd/258~rc3-1/units/rescue.service.in#L19
• https://sources.debian.org/src/systemd/258~rc3-1/units/emergency.service.in#L20
• https://sources.debian.org/src/sysvinit/3.14-4/src/sulogin.c?hl=756#L756

We already grab getpwnam("root") in init(8), so it doesn't seem like a stretch or invalid to set $HOME to root's pw_dir if we actually found a pwent to work with.

[rgrimes]

In D52161#1191928, @kevans wrote:

In D52161#1191908, @rgrimes wrote:

In D52161#1191907, @kevans wrote:

In D52161#1191888, @emaste wrote:

In D52161#1191886, @grahamperrin wrote:

In D52161#1191869, @rgrimes wrote:

… single user.

Is either .cshrc or .profile intended to be effective in this mode?

I don't see a reason it should not be.

I tried it on my system (the text block above) and confirmed that sh read /root/.profile when booted in single user mode.

I actually can't reproduce that result here. If I remove /.profile and add a SECRETVAR to /root/.profile, it's not populated (and I don't really see where we'd get a $HOME from in init or early /bin/sh)

First to Ed, did you rm /.profile? As if you read the contents you well see that it SETS /home.

To kevans, thanks that confirms that it was /.profile that set home.

I think I've seen this (valid) argument from you for removing /.profile twice now,

Not that I can recall, but perhaps.

but I don't think I've seen you comment on the reason it is like this: how do you feel about trying to set $HOME in init(8) when we invoke the single-user shell?

I think thats creep of shoving a problem in pkg inability to handle the situation by putting a set of bandaids (removal of /.profile being one, adding setting $HOME to init a second.)

This also removes the "feature" of being able to have the single user /.{profile, csh} NOT links as one might have a lot of stuff added to /root/.profile that just wont be applicable when your booted single user.

IMHO, the bug is caused by pkg not being able to handle a hard linked file, and thats kinda a fundemental unix situation and it should probably learn to handle it.

jrtc27 (intentionally untagged) notes that there's some precedence in sysvinit's sulogin, and systemd's rescue/emergency services:

• https://sources.debian.org/src/systemd/258~rc3-1/units/rescue.service.in#L19
• https://sources.debian.org/src/systemd/258~rc3-1/units/emergency.service.in#L20

I don't think Linux ever had /.profile or /.cshrc.

• https://sources.debian.org/src/sysvinit/3.14-4/src/sulogin.c?hl=756#L756

This last one is in a su command, how is that applicable to a single user startup?

We already grab getpwnam("root") in init(8), so it doesn't seem like a stretch or invalid to set $HOME to root's pw_dir if we actually found a pwent to work with.

Be careful about when and where you set $HOME, all decendants of init well inherit that won't they?

[kevans]

In D52161#1191987, @rgrimes wrote:

In D52161#1191928, @kevans wrote:

but I don't think I've seen you comment on the reason it is like this: how do you feel about trying to set $HOME in init(8) when we invoke the single-user shell?

I think thats creep of shoving a problem in pkg inability to handle the situation by putting a set of bandaids (removal of /.profile being one, adding setting $HOME to init a second.)

I'm viewing this as a question independent of whatever motivated this change.

This also removes the "feature" of being able to have the single user /.{profile, csh} NOT links as one might have a lot of stuff added to /root/.profile that just wont be applicable when your booted single user.

IMHO, the bug is caused by pkg not being able to handle a hard linked file, and thats kinda a fundemental unix situation and it should probably learn to handle it.

jrtc27 (intentionally untagged) notes that there's some precedence in sysvinit's sulogin, and systemd's rescue/emergency services:

• https://sources.debian.org/src/systemd/258~rc3-1/units/rescue.service.in#L19
• https://sources.debian.org/src/systemd/258~rc3-1/units/emergency.service.in#L20

I don't think Linux ever had /.profile or /.cshrc.

Sure, but this is more generally about setting $HOME in single-user-ish environments.

• https://sources.debian.org/src/sysvinit/3.14-4/src/sulogin.c?hl=756#L756

This last one is in a su command, how is that applicable to a single user startup?

* sulogin	This program gives Linux machines a reasonable
*		secure way to boot single user. It forces the
*		user to supply the root password before a
*		shell is started.

(s)ingle (u)ser (login) rather than (s)witch (u)ser (login), presumably.

We already grab getpwnam("root") in init(8), so it doesn't seem like a stretch or invalid to set $HOME to root's pw_dir if we actually found a pwent to work with.

Be careful about when and where you set $HOME, all decendants of init well inherit that won't they?

This would be in the post-fork environment specifically for the shell that we start in single-user, so that only propagates to whatever you're running in single-user rather than all descendants of init.

[jilles]

It seems reasonable to me to use .profile and other files from root's home directory in single user mode as well. Having no .profile at all in single user mode would be bad. I don't think special logic in pkg for hard links is worth it for this particular special case.

We already grab getpwnam("root") in init(8), so it doesn't seem like a stretch or invalid to set $HOME to root's pw_dir if we actually found a pwent to work with.

This should probably work the same way as login(1):

• Change directory (chdir()) to the home directory.
• If changing directory fails, change to / instead and set HOME=/. In this case, there are unlikely to be any shell or other configuration files.

The linked sulogin code looks up the absolute path of the home or root directory using getcwd() and sets HOME from that; I don't think we should do that. It is more work and resolving a symlink is unlikely to be expected (also because regular logins don't do this).

[ivy]

i've temporarily landed D52161 in main to fix the issue with pkg upgrade. note that the motivation behind this change isn't to workaround a pkg issue, it's to be consistent about where we install shell rc files, given that /.cshrc was already removed. if we want to keep /.profile, then for consistency we also need to revert dcb65c5a94d4c622b1d486847dc20488f59974e7; cc @manu.

however i'd rather not do that. you can't really treat /.profile and /.cshrc as "single user mode root profiles" because users without a home directory also get HOME=/, for example if NFS or autofs are down. so what we actually have is one set of rc files for multi-user root login, and another set for both single-user root login and homeless non-root user login. i'm not convinced this is either useful or intentional.

[ivy]

i would like to land this after D52527, which i believe resolves the issue with single user mode.

[jilles]

ObsoleteFiles.inc

54–55 ↗

(On Diff #160987)

This will make it difficult to have a /.profile locally (since make delete-old will delete it again), but pkgbase will fix that, so I think this is fine as it is.

[ivy]

ObsoleteFiles.inc

54–55 ↗

(On Diff #160987)

i may just drop this, since there's no particular need to remove it.