mailarchive of the ptxdist mailing list
 help / color / mirror / Atom feed
From: Artur Wiebe <artur@4wiebe.de>
To: ptxdist@pengutronix.de
Subject: Re: [ptxdist] Resend: Home dir fixup for root in systemd
Date: Wed, 27 Jul 2016 11:11:21 +0200	[thread overview]
Message-ID: <c3131e36-3a3a-5786-2e07-bdf09d0b38be@4wiebe.de> (raw)
In-Reply-To: <20160727105514.29ae34e4@erd980>


[-- Attachment #1.1: Type: text/plain, Size: 3931 bytes --]

Hi all,

to patch systemd to fit some "mistake" in ptxdist seems quite 
disproportionately.

It is much simpler to change home of root to /root by providing own 
/projectroot/etc/passwd then undoing a patch.

Oh, it was just a typo of Michael! Great!

Ialsovote for solution 1: set home for root to /root

Change PTXdist and all places in it that assume the $HOME=/home for root.

Best Regards,
Artur

Am 27.07.2016 um 10:55 schrieb David Jander:
> Dear Michael,
>
> On Wed, 27 Jul 2016 08:55:13 +0200
> Michael Olbrich <m.olbrich@pengutronix.de> wrote:
>
>> Hi,
>>
>> On Tue, Jul 26, 2016 at 04:00:34PM +0200, David Jander wrote:
>>> On Tue, 26 Jul 2016 15:19:59 +0200
>>> Guillermo Rodriguez Garcia <guille.rodriguez@gmail.com> wrote:
>>>    
>>>> Wouldn't it be easier to either use a custom /etc/passwd, or create a /root
>>>> dir in the filesystem ? That sounds better than patching systemd.
>>> Maybe it would be better to change the default /etc/passwd (and everywhere
>>> else) in ptxdist then...
>>>
>>> The problem is that what /etc/passwd says is mandatory. The home directory has
>>> a special meaning to the user. You can get to the home directory via $HOME
>>> passed in the environment, or via the NS-switch (getent) lookup. They are
>>> supposed to be the same.
>>> systemd has hardcoded defaults in source-code, which by definition is ugly as
>>> hell, but the reason is clearly to avoid potentially expensive, blocking
>>> NSS-lookups in the early boot stages, so it is understandable. It would be a
>>> lot better if there was some configuration setting read from a file I guess,
>>> but alas.
>>> On PTXdist now (with the default, shipped /etc/passwd), a user logging in as
>>> "root" via, say a serial console getty, will have a different $HOME than a
>>> systemd service started with User=root. This is bad, and can potentially do
>>> funny things people will not like.
>>> To solve the problem, there are really only two options AFAICS:
>>>
>>>   1.- Change PTXdist and all places in it that assume the $HOME=/home for root.
>>>   No idea how many places that are, nor how many users already depend on this
>>>   historic assumption.
>>>
>>> or
>>>
>>>   2.- Patch systemd to adapt to the reality of PTXdist.
>>>
>>> I agree that option 1 is probably better if PTXdist is more or less the only
>>> place on earth left where $HOME != /root for uid=0. Historically on Unix it
>>> used to be "/", but that is just way too ugly (guess where the name "root"
>>> came from?).
>>>
>>> Using a custom /etc/passwd is not an option, because the default PTXdist stays
>>> broken this way.
>>>
>>> Creating a /root dir is also broken, because like I explained above, the root
>>> user will become schizophrenic when logging in and running services from
>>> systemd alternately. Think about a user logging in, starting a tool that
>>> writes a config files to ~/.bla, and then configuring the same tool to run as a
>>> system service. I would (did!) get slightly mad when finding the tool to run
>>> with a totally different configuration in the latter case.
>> Unless someone comes up with a really good reason, then I think we should go
>> with option 2. I have actually considered making the change in the past
>> just to be consistent. But I never got around to do it.
>> I didn't notice this problem, probably because my rootfs is usually
>> read-only, and /root and /home are both empty.
>>
>> It would be great if some more people would speak up. Such a change can
>> potentially break things, so I'd like to know what others are thinking.
> Ok, just so we understand each other, you propose to go with my original patch
> in this case (i.e. patch systemd to assume $HOME=/home), right?
> In case nobody speaks up against it, will you pick it up as-is, or should I
> make a correct patch (i.e. learn how to properly use git-ptxdist-patch to
> generate a correct series file) and post it here?
>
> Best regards,
>


[-- Attachment #1.2: Type: text/html, Size: 5357 bytes --]

[-- Attachment #2: Type: text/plain, Size: 91 bytes --]

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

  parent reply	other threads:[~2016-07-27  9:11 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-26 12:09 David Jander
2016-07-26 13:19 ` Guillermo Rodriguez Garcia
2016-07-26 14:00   ` David Jander
2016-07-26 15:13     ` Ben Stuyts
2016-07-27  5:41       ` David Jander
2016-07-26 17:50     ` Guillermo Rodriguez Garcia
2016-07-27  5:51       ` David Jander
2016-07-27 12:04         ` Guillermo Rodriguez Garcia
2016-07-27  6:55     ` Michael Olbrich
2016-07-27  8:55       ` David Jander
2016-07-27  9:04         ` Michael Olbrich
2016-07-27  9:11         ` Artur Wiebe [this message]
2016-07-27  9:29           ` David Jander
2016-07-27 10:43             ` Michael Olbrich
2016-07-27 11:24               ` David Jander
2016-07-29  8:07       ` Tim Sander

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c3131e36-3a3a-5786-2e07-bdf09d0b38be@4wiebe.de \
    --to=artur@4wiebe.de \
    --cc=ptxdist@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox