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

On Wed, 27 Jul 2016 11:11:21 +0200
Artur Wiebe <artur@4wiebe.de> wrote:

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

I am also more inclined to solution 1, but I would have agreed to any of both,
whichever Michael prefers... :-)

Anybody dare to say if there are other packages in the PTXdist universe that
are (purposefully) configured to use /home?

Doing a "git grep home", I can find these suspicious locations:

...
projectroot/etc/apache2/httpd.conf:# UserDir: The name of the directory that is appended onto a user's home
projectroot/etc/apache2/httpd.conf:#<Directory /home/*/public_html>
...
projectroot/etc/boa/boa.conf:DocumentRoot /home/httpd/html
projectroot/etc/boa/boa.conf:# UserDir: The name of the directory which is appended onto a user's home
projectroot/etc/boa/boa.conf:ScriptAlias /cgi-bin/ /home/httpd/cgi-bin/
...
projectroot/etc/init.d/startup:[ -x /home/startup ] && /home/startup
...
projectroot/etc/passwd:root:x:0:0:root:/home:/bin/sh
projectroot/etc/passwd:ftp:x:11:101:ftp user:/home:/bin/false
projectroot/etc/passwd:www:x:12:102:www user:/home:/bin/false
projectroot/etc/proftpd.conf:<Directory /home/*>
projectroot/etc/samba/smb.conf:[homes]
projectroot/etc/samba/smb.conf: path        = /home
...
rules/frodo.make:       install -D -m 644 "$(FRODO_DIR)/1541 ROM" "$(FRODO_PKGDIR)/home/1541 ROM"
rules/frodo.make:       install -D -m 644 "$(FRODO_DIR)/Basic ROM" "$(FRODO_PKGDIR)/home/Basic ROM"
rules/frodo.make:       install -D -m 644 "$(FRODO_DIR)/Char ROM" "$(FRODO_PKGDIR)/home/Char ROM"
rules/frodo.make:       install -D -m 644 "$(FRODO_DIR)/Kernal ROM" "$(FRODO_PKGDIR)/home/Kernal ROM"
rules/frodo.make:       @$(call install_copy, frodo, 0, 0, 0644, -, /home/1541 ROM)
rules/frodo.make:       @$(call install_copy, frodo, 0, 0, 0644, -, /home/Basic ROM)
rules/frodo.make:       @$(call install_copy, frodo, 0, 0, 0644, -, /home/Char ROM)
rules/frodo.make:       @$(call install_copy, frodo, 0, 0, 0644, -, /home/Kernal ROM)
rules/frodo.make:       @$(call install_link, frodo, ../etc/frodorc, /home/.frodorc)
...
rules/ltp-base.make:    @$(call install_copy, ltp_base, 0, 0, 0755, /home)
rules/ltp-base.make:    @$(call install_copy, ltp_base, 0, 0, 0755, /home/testcases)
rules/ltp-base.make:    @$(call install_copy, ltp_base, 0, 0, 0755, /home/testcases/bin)
rules/ltp-base.make:                    /home/testcases/$$file) \
rules/ltp-base.make:    @$(call install_copy, ltp_base, 0, 0, 0755, /home/testcases/bin/dumpdir)
rules/ltp-base.make:                    /home/testcases/$$file) \
...
rules/rootfs.in:        prompt "/home"
rules/rootfs.in:          home/ is a common location to store users private data. As ptxdist does
rules/rootfs.make:      @$(call install_copy, rootfs, 0, 0, 2775, /home)
...
rules/systemd.make:#    # don't touch /etc and /home
...

These would at least all need to be patched.
And that was the only real reason why I thought option 2 might be
desirable :-)

> 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,
> >  
> 

Best regards,

-- 
David Jander
Protonic Holland.

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

  reply	other threads:[~2016-07-27  9:29 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
2016-07-27  9:29           ` David Jander [this message]
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=20160727112927.77559959@erd980 \
    --to=david@protonic.nl \
    --cc=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