Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Robert Yang <liezhi.yang@windriver.com>
To: Dan McGregor <danismostlikely@gmail.com>,
	Charles Chan <charles.wh.chan@gmail.com>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: Security question: base-files_3.0.14.bb and ${ROOT_HOME} directory permission
Date: Thu, 7 Apr 2016 11:01:45 +0800	[thread overview]
Message-ID: <5705CD99.9000103@windriver.com> (raw)
In-Reply-To: <CACS+7ZS7TMWdR-M7aH8DRupH7P7UN-8Q6kR1EK6v4r+C_v1wbg@mail.gmail.com>



On 04/07/2016 07:17 AM, Dan McGregor wrote:
> On 6 April 2016 at 13:39, Charles Chan <charles.wh.chan@gmail.com> wrote:
>> Hi Robert,
>>
>> Thanks for the patch. I tested it and it worked ... partially.
>>
>> Taking an existing image and then using `opkg install base-files.ipk` will
>> correctly set the permission to 0700.
>>
>> However, when I rebuild the full image rootfs, /home/root still ends up with
>> the wrong permission. I suspect another recipe is modifying the permission.
>> Is there a way (ie. bitbake command) to find out which recipe is causing the
>> change?

I tried a fresh build, it works for me.

>>
>> Thanks again,
>> Charles
>>
>
> I don't know what recipe is creating /home/root, but ${ROOT_HOME}

It is created by base-files

> should probably be added to files/fs-perms.txt with the correct
> permissions set.

Sounds good to me.

// Robert

>
>
>>
>> On Tue, Apr 5, 2016 at 10:33 PM, Robert Yang <liezhi.yang@windriver.com>
>> wrote:
>>>
>>>
>>> I think that it should be a bug, would you please try this patch?
>>>
>>> diff --git a/meta/recipes-core/base-files/base-files_3.0.14.bb
>>> b/meta/recipes-core/base-files/base-files_3.0.14.bb
>>> index d391707..2082ed4 100644
>>> --- a/meta/recipes-core/base-files/base-files_3.0.14.bb
>>> +++ b/meta/recipes-core/base-files/base-files_3.0.14.bb
>>> @@ -95,6 +95,7 @@ do_install () {
>>>          for d in ${dirs755}; do
>>>                  install -m 0755 -d ${D}$d
>>>          done
>>> +       chmod 0700 ${D}${ROOT_HOME}
>>>          for d in ${dirs1777}; do
>>>                  install -m 1777 -d ${D}$d
>>>          done
>>>
>>> // Robert
>>>
>>> On 04/06/2016 01:03 PM, Charles Chan wrote:
>>>>
>>>> (This is my first post to OE list, hopefully I am posting to the right
>>>> mailing
>>>> list.)
>>>>
>>>> Background: During the process of trying to configure SSH keys for root
>>>> user
>>>> login via dropbear, we realized the permission for /home/root directory
>>>> is set
>>>> too loose for group and other members [1]. As a result, dropbears fails
>>>> when we
>>>> try to put the key under /home/root/.ssh
>>>>
>>>> ---------
>>>>
>>>> In the image, /home/root directory is set to 0755:
>>>>
>>>>      $ stat /home/root
>>>>         File: /home/root
>>>>         Size: 4096            Blocks: 8          IO Block: 4096
>>>> directory
>>>>      Device: b302h/45826d    Inode: 13268       Links: 4
>>>>      Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/
>>>> root)
>>>>      Access: 2016-04-05 22:21:13.000000000
>>>>      Modify: 2016-04-05 22:08:57.000000000
>>>>      Change: 2016-04-05 22:08:57.000000000
>>>>
>>>>
>>>> After some debugging, we believe the permission (0755) is initialized in
>>>> base-files_3.0.14.bb <http://base-files_3.0.14.bb> (in line 35) [2].
>>>>
>>>> A few questions:
>>>> 1. I tried looking at the git log for the history, but wasn't able to
>>>> find any
>>>> background on why the permission was set this way. eg. on a desktop Linux
>>>> (Ubuntu), /root is set to 0700:
>>>>
>>>>      $ sudo stat /root
>>>>         File: `/root'
>>>>         Size: 4096 Blocks: 8          IO Block: 4096   directory
>>>>      Device: 801h/2049dInode: 1441793     Links: 3
>>>>      Access: (0700/drwx------)  Uid: (    0/    root)   Gid: (    0/
>>>> root)
>>>>      Access: 2016-04-05 21:29:17.389725228 -0700
>>>>      Modify: 2016-03-22 17:11:54.912479000 -0700
>>>>      Change: 2016-03-22 17:11:54.912479000 -0700
>>>>        Birth: -
>>>>
>>>>
>>>> 2. If we would like to override the directory permission for /home/root
>>>> in our
>>>> image, what is the best way to do it? I am not an expert with bitbake,
>>>> should I
>>>> be patching the base-files_3.0.14.bb <http://base-files_3.0.14.bb>? using
>>>> *_append? or I should be looking at some other recipe altogether?
>>>>
>>>> Sorry for the long email. Thanks in advance.
>>>> Charles
>>>>
>>>> [1]
>>>> https://wiki.openwrt.org/doc/howto/dropbear.public-key.auth#troubleshooting
>>>>
>>>> [2]
>>>>
>>>> http://cgit.openembedded.org/cgit.cgi/openembedded-core/tree/meta/recipes-core/base-files/base-files_3.0.14.bb?h=master#n35
>>>>
>>>>
>>
>>
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>


      reply	other threads:[~2016-04-07  3:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-06  5:03 Security question: base-files_3.0.14.bb and ${ROOT_HOME} directory permission Charles Chan
2016-04-06  5:33 ` Robert Yang
2016-04-06 19:39   ` Charles Chan
2016-04-06 23:17     ` Dan McGregor
2016-04-07  3:01       ` Robert Yang [this message]

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=5705CD99.9000103@windriver.com \
    --to=liezhi.yang@windriver.com \
    --cc=charles.wh.chan@gmail.com \
    --cc=danismostlikely@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    /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