Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] btrfs filesystem image creation using TARGET_DIR path
Date: Thu, 22 Aug 2019 18:31:14 +0200	[thread overview]
Message-ID: <20190822163114.GF12477@scaer> (raw)
In-Reply-To: <CAP8JTabtfuzkYbxZL99_Ocy9Q+zb-Ek-+F97r3a2+GBnpABG6Q@mail.gmail.com>

Jitesh, All,

On 2019-08-22 19:00 +0530, chalil jitesh spake thusly:
> As per suggestion I tried to build as non-root user also but still the
> issue is getting reproduced and capabilities are not getting retained
> in the btrfs image generated.
> In our project we are setting the permissions from corresponding
> package makefile using the steps as suggested by you.
> Also the capabilities set for a file are working when we build a
> squashfs image from buildroot (BR2_TARGET_ROOTFS_SQUASHFS). (If we
> unmount the squashfs image the capabilities set for a file are working
> for the same target directory which we are using for testing btrfs)
> But when we build the btrfs image from buildroot
> (BR2_TARGET_ROOTFS_BTRFS) for the same target directory we are
> observing this issue (If we unmount the btrfs image, the capabilities
> set for the file are not present in the unmounted path).
> 
> For squashfs file system in buildroot/fs/squashfs/squashfs.mk file,
> the target directory used seems to be BASE_TARGET_DIR.
> $(HOST_DIR)/bin/mksquashfs $(BASE_TARGET_DIR) $@ $(ROOTFS_SQUASHFS_ARGS)

This is not what there is in the official Buildroot tree:

    https://git.buildroot.org/buildroot/tree/fs/squashfs/squashfs.mk#n26

So, you seem to have local modifications.

Please, try to reproduce your issue using the curent official tree (or
at the very least, the latest release).

Regards,
Yann E. MORIN.

> But for btrfs file system in buildroot/fs/btrfs/btrfs.mk file, the
> target directory used seems to be TARGET_DIR .
> BTRFS_OPTS = \
> 	-f \
> 	-r '$( TARGET_DIR)' \
> 
> Kindly please review our observations and please suggest why the
> capabilities are not getting retained for btrfs(uses TARGET_DIR), but
> capabilities are working for squashfs (uses BASE_TARGET_DIR) .
> 
> With Thanks and Regards
> Jitesh
> 
> On 8/1/19, Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
> > Hello,
> >
> > On Thu, 1 Aug 2019 12:19:49 +0530
> > chalil jitesh <chaliljitesh@gmail.com> wrote:
> >
> >> Thanks for reviewing and providing the information.
> >>
> >> The following is the issue i am facing when using the TARGET_DIR.
> >> Suppose we set any capabilities to the files in the BASE_TARGET_DIR
> >> (./target in the below example) during the buildroot compilation. Example
> >> if we set some capabilities to the tool ping in BASE_TARGET_DIR as in
> >> example below.
> >> example : setcap cap_net_raw=ei ./target/bin/ping
> >> If we use BASE_TARGET_DIR with the -r option in
> >> buildroot/fs/btrfs/btrfs.mk
> >> (buildroot/fs/btrfs/btrfs.mk : -r '$(BASE_TARGET_DIR)')
> >> After the rootfs.btrfs image is generated from buildroot, if we mount the
> >> btrfs file sytem and check the capability of the file ping, the
> >> capability
> >> is getting retained in the btrfs file system generated as in example
> >> below
> >> (if BASE_TARGET_DIR  is used btrfs.mk).
> >> [root at localhost images]# mkdir test
> >> [root at localhost images]# mount -t btrfs ./rootfs.btrfs test
> >> [root at localhost images]# getcap ./test/bin/ping
> >> ./test/bin/ping = cap_net_raw+ei
> >> [root at localhost images]#
> >
> > The correct way to assign capabilities is to use the <pkg>_PERMISSIONS
> > variable, which allows to define extended attributes for any file
> > installed by a package.
> >
> > You might want to have a look at the current discussion in the
> > following patches:
> >
> >   http://patchwork.ozlabs.org/patch/1140027/
> >   http://patchwork.ozlabs.org/patch/1140026/
> >
> > Especially the second patch is very relevant, because it's precisely
> > taking care of setting the right capabilities for ping.
> >
> > Also, from the above, it seems like you are doing your Buildroot build
> > as root, which is really not recommended. We strongly recommend to do
> > Buildroot builds as a normal user.
> >
> > Best regards,
> >
> > Thomas
> > --
> > Thomas Petazzoni, CTO, Bootlin
> > Embedded Linux and Kernel engineering
> > https://bootlin.com
> >
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

      reply	other threads:[~2019-08-22 16:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-30 13:03 [Buildroot] btrfs filesystem image creation using TARGET_DIR path chalil jitesh
2019-07-31 12:45 ` Thomas Petazzoni
2019-08-01  6:49   ` chalil jitesh
2019-08-01  7:43     ` Thomas Petazzoni
2019-08-22 13:30       ` chalil jitesh
2019-08-22 16:31         ` Yann E. MORIN [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=20190822163114.GF12477@scaer \
    --to=yann.morin.1998@free.fr \
    --cc=buildroot@busybox.net \
    /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