* [Buildroot] Default target file system permissions
@ 2013-11-02 8:13 Sven Neumann
2013-11-02 10:06 ` Thomas Petazzoni
0 siblings, 1 reply; 6+ messages in thread
From: Sven Neumann @ 2013-11-02 8:13 UTC (permalink / raw)
To: buildroot
Hi,
I've been debugging some problems with our buildroot builds lately and
found them to be caused by too restrictive permissions on the target
file system. Pretty much all files and directories, unless specified
explicitly in system/device_table.txt are only readable by the owner
(root). This causes problems with samba (/var/nmbd not accessible by
nmbd), dbus services (dbus daemon can not access the service files) and
so on. Basically only services that are running as root can work
correctly, because for other users the system is pretty much
inaccessible. I've come across this mail on the mailing-list which seems
related, but couldn't find an answer:
http://buildroot-busybox.2317881.n4.nabble.com/Default-target-file-system-permissions-td39088.html
I've also tried changing the umask on our buildslaves but that didn't
help.
Here's how the root folder on our target file-system looks like:
drwxr-xr-x 20 root root 4096 Dec 7 1999 .
drwxr-xr-x 20 root root 4096 Dec 7 1999 ..
drwx------ 2 root root 4096 Dec 7 1999 bin
drwxr-xr-x 2 root root 4096 Nov 30 1999 boot
drwxr-xr-x 5 root root 4096 Dec 30 1999 data
drwxr-xr-x 10 root root 12600 Dec 7 1999 dev
drwxr-xr-x 15 root root 4096 Dec 7 1999 etc
drwx------ 3 root root 4096 Dec 7 1999 home
drwx------ 4 root root 4096 Dec 7 1999 lib
lrwxrwxrwx 1 root root 11 Oct 31 20:26 linuxrc ->
bin/busybox
drwx------ 2 root root 4096 Dec 7 1999 media
drwx------ 2 root root 4096 Dec 7 1999 mnt
drwx------ 2 root root 4096 Dec 7 1999 opt
dr-xr-xr-x 62 root root 0 Dec 7 1999 proc
drwx------ 2 root root 4096 Oct 31 22:09 root
lrwxrwxrwx 1 root root 3 Oct 31 18:39 run -> tmp
drwx------ 2 root root 4096 Dec 7 1999 sbin
dr-xr-xr-x 11 root root 0 Dec 7 1999 sys
drwxrwxrwt 12 root root 800 Oct 31 21:51 tmp
drwx------ 7 root root 4096 Dec 7 1999 usr
drwxr-xr-x 7 root root 4096 Dec 7 1999 var
So are the restrictive permissions on the target file-system intentional
and how I can change this situation?
Regards,
Sven
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] Default target file system permissions
2013-11-02 8:13 [Buildroot] Default target file system permissions Sven Neumann
@ 2013-11-02 10:06 ` Thomas Petazzoni
2013-11-02 18:30 ` Sven Neumann
0 siblings, 1 reply; 6+ messages in thread
From: Thomas Petazzoni @ 2013-11-02 10:06 UTC (permalink / raw)
To: buildroot
Dear Sven Neumann,
On Sat, 02 Nov 2013 09:13:19 +0100, Sven Neumann wrote:
> I've been debugging some problems with our buildroot builds lately and
> found them to be caused by too restrictive permissions on the target
> file system. Pretty much all files and directories, unless specified
> explicitly in system/device_table.txt are only readable by the owner
> (root). This causes problems with samba (/var/nmbd not accessible by
> nmbd), dbus services (dbus daemon can not access the service files) and
> so on. Basically only services that are running as root can work
> correctly, because for other users the system is pretty much
> inaccessible. I've come across this mail on the mailing-list which seems
> related, but couldn't find an answer:
> http://buildroot-busybox.2317881.n4.nabble.com/Default-target-file-system-permissions-td39088.html
> I've also tried changing the umask on our buildslaves but that didn't
> help.
>
> Here's how the root folder on our target file-system looks like:
>
> drwxr-xr-x 20 root root 4096 Dec 7 1999 .
> drwxr-xr-x 20 root root 4096 Dec 7 1999 ..
> drwx------ 2 root root 4096 Dec 7 1999 bin
> drwxr-xr-x 2 root root 4096 Nov 30 1999 boot
> drwxr-xr-x 5 root root 4096 Dec 30 1999 data
> drwxr-xr-x 10 root root 12600 Dec 7 1999 dev
> drwxr-xr-x 15 root root 4096 Dec 7 1999 etc
> drwx------ 3 root root 4096 Dec 7 1999 home
> drwx------ 4 root root 4096 Dec 7 1999 lib
> lrwxrwxrwx 1 root root 11 Oct 31 20:26 linuxrc ->
> bin/busybox
> drwx------ 2 root root 4096 Dec 7 1999 media
> drwx------ 2 root root 4096 Dec 7 1999 mnt
> drwx------ 2 root root 4096 Dec 7 1999 opt
> dr-xr-xr-x 62 root root 0 Dec 7 1999 proc
> drwx------ 2 root root 4096 Oct 31 22:09 root
> lrwxrwxrwx 1 root root 3 Oct 31 18:39 run -> tmp
> drwx------ 2 root root 4096 Dec 7 1999 sbin
> dr-xr-xr-x 11 root root 0 Dec 7 1999 sys
> drwxrwxrwt 12 root root 800 Oct 31 21:51 tmp
> drwx------ 7 root root 4096 Dec 7 1999 usr
> drwxr-xr-x 7 root root 4096 Dec 7 1999 var
Interesting, because here I don't have the same behavior:
drwxrwxr-x 2 root root 1420 nov. 1 13:24 bin
drwxr-xr-x 3 root root 100 nov. 1 13:24 dev
drwxr-xr-x 5 root root 500 nov. 1 13:24 etc
drwxrwxr-x 4 root root 80 nov. 1 13:24 home
drwxrwxr-x 2 root root 540 nov. 1 13:24 lib
lrwxrwxrwx 1 root root 3 nov. 1 13:22 lib32 -> lib
lrwxrwxrwx 1 root root 11 nov. 1 13:24 linuxrc -> bin/busybox
drwxrwxr-x 2 root root 40 oct. 27 12:37 media
drwxrwxr-x 2 root root 40 oct. 27 12:37 mnt
drwxrwxr-x 2 root root 40 oct. 27 12:37 opt
drwxrwxr-x 2 root root 40 oct. 27 12:37 proc
drwx------ 2 root root 100 oct. 27 12:37 root
lrwxrwxrwx 1 root root 3 oct. 27 12:37 run -> tmp
drwxrwxr-x 2 root root 940 nov. 1 13:24 sbin
drwxrwxr-x 2 root root 40 oct. 27 12:37 sys
drwxrwxrwt 3 root root 60 nov. 1 13:24 tmp
drwxrwxr-x 6 root root 140 nov. 1 13:24 usr
drwxrwxr-x 4 root root 220 nov. 1 13:24 var
How are the permissions of the directories/files in system/skeleton/ in
your Buildroot sources?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] Default target file system permissions
2013-11-02 10:06 ` Thomas Petazzoni
@ 2013-11-02 18:30 ` Sven Neumann
0 siblings, 0 replies; 6+ messages in thread
From: Sven Neumann @ 2013-11-02 18:30 UTC (permalink / raw)
To: buildroot
Hi,
On Sat, 2013-11-02 at 11:06 +0100, Thomas Petazzoni wrote:
> > Here's how the root folder on our target file-system looks like:
> >
> > drwxr-xr-x 20 root root 4096 Dec 7 1999 .
> > drwxr-xr-x 20 root root 4096 Dec 7 1999 ..
> > drwx------ 2 root root 4096 Dec 7 1999 bin
> > drwxr-xr-x 2 root root 4096 Nov 30 1999 boot
> > drwxr-xr-x 5 root root 4096 Dec 30 1999 data
> > drwxr-xr-x 10 root root 12600 Dec 7 1999 dev
> > drwxr-xr-x 15 root root 4096 Dec 7 1999 etc
> > drwx------ 3 root root 4096 Dec 7 1999 home
> > drwx------ 4 root root 4096 Dec 7 1999 lib
> > lrwxrwxrwx 1 root root 11 Oct 31 20:26 linuxrc ->
> > bin/busybox
> > drwx------ 2 root root 4096 Dec 7 1999 media
> > drwx------ 2 root root 4096 Dec 7 1999 mnt
> > drwx------ 2 root root 4096 Dec 7 1999 opt
> > dr-xr-xr-x 62 root root 0 Dec 7 1999 proc
> > drwx------ 2 root root 4096 Oct 31 22:09 root
> > lrwxrwxrwx 1 root root 3 Oct 31 18:39 run -> tmp
> > drwx------ 2 root root 4096 Dec 7 1999 sbin
> > dr-xr-xr-x 11 root root 0 Dec 7 1999 sys
> > drwxrwxrwt 12 root root 800 Oct 31 21:51 tmp
> > drwx------ 7 root root 4096 Dec 7 1999 usr
> > drwxr-xr-x 7 root root 4096 Dec 7 1999 var
>
> Interesting, because here I don't have the same behavior:
>
> drwxrwxr-x 2 root root 1420 nov. 1 13:24 bin
> drwxr-xr-x 3 root root 100 nov. 1 13:24 dev
> drwxr-xr-x 5 root root 500 nov. 1 13:24 etc
> drwxrwxr-x 4 root root 80 nov. 1 13:24 home
> drwxrwxr-x 2 root root 540 nov. 1 13:24 lib
> lrwxrwxrwx 1 root root 3 nov. 1 13:22 lib32 -> lib
> lrwxrwxrwx 1 root root 11 nov. 1 13:24 linuxrc -> bin/busybox
> drwxrwxr-x 2 root root 40 oct. 27 12:37 media
> drwxrwxr-x 2 root root 40 oct. 27 12:37 mnt
> drwxrwxr-x 2 root root 40 oct. 27 12:37 opt
> drwxrwxr-x 2 root root 40 oct. 27 12:37 proc
> drwx------ 2 root root 100 oct. 27 12:37 root
> lrwxrwxrwx 1 root root 3 oct. 27 12:37 run -> tmp
> drwxrwxr-x 2 root root 940 nov. 1 13:24 sbin
> drwxrwxr-x 2 root root 40 oct. 27 12:37 sys
> drwxrwxrwt 3 root root 60 nov. 1 13:24 tmp
> drwxrwxr-x 6 root root 140 nov. 1 13:24 usr
> drwxrwxr-x 4 root root 220 nov. 1 13:24 var
>
> How are the permissions of the directories/files in system/skeleton/ in
> your Buildroot sources?
OK, that made me think and I've now checked the contents of the
rootfs.tar created by buildroot instead of looking at the deployed
filesystem on the target device. It appears that this is a bug in the
way that we deploy the rootfs and has nothing to do with buildroot. I am
very sorry for bothering you with this. Thanks for your attempt to help,
Regards,
Sven
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] Default target file system permissions
@ 2013-10-31 22:42 Sven Neumann
2013-11-02 22:23 ` Arnout Vandecappelle
0 siblings, 1 reply; 6+ messages in thread
From: Sven Neumann @ 2013-10-31 22:42 UTC (permalink / raw)
To: buildroot
Hi,
I've been debugging some problems with our buildroot builds lately and
found them to be caused by too restrictive permissions on the target
file system. Pretty much all files and directories, unless specified
explicitly in system/device_table.txt are only readable by the owner
(root). This causes problems with samba (/var/nmbd not accessible by
nmbd), dbus services (dbus daemon can not access the service files) and
so on. Basically only services that are running as root can work
correctly, because for other users the system is pretty much
inaccessible. I've come across this mail on the mailing-list which seems
related, but couldn't find an answer:
http://buildroot-busybox.2317881.n4.nabble.com/Default-target-file-system-permissions-td39088.html
Here's how the root folder on our target file-system looks like:
drwxr-xr-x 20 root root 4096 Dec 7 1999 .
drwxr-xr-x 20 root root 4096 Dec 7 1999 ..
drwx------ 2 root root 4096 Dec 7 1999 bin
drwxr-xr-x 2 root root 4096 Nov 30 1999 boot
drwxr-xr-x 5 root root 4096 Dec 30 1999 data
drwxr-xr-x 10 root root 12600 Dec 7 1999 dev
drwxr-xr-x 15 root root 4096 Dec 7 1999 etc
drwx------ 3 root root 4096 Dec 7 1999 home
drwx------ 4 root root 4096 Dec 7 1999 lib
lrwxrwxrwx 1 root root 11 Oct 31 20:26 linuxrc ->
bin/busybox
drwx------ 2 root root 4096 Dec 7 1999 media
drwx------ 2 root root 4096 Dec 7 1999 mnt
drwx------ 2 root root 4096 Dec 7 1999 opt
dr-xr-xr-x 62 root root 0 Dec 7 1999 proc
drwx------ 2 root root 4096 Oct 31 22:09 root
lrwxrwxrwx 1 root root 3 Oct 31 18:39 run -> tmp
drwx------ 2 root root 4096 Dec 7 1999 sbin
dr-xr-xr-x 11 root root 0 Dec 7 1999 sys
drwxrwxrwt 12 root root 800 Oct 31 21:51 tmp
drwx------ 7 root root 4096 Dec 7 1999 usr
drwxr-xr-x 7 root root 4096 Dec 7 1999 var
So are the restrictive permissions on the target file-system intentional
and how I can change this situation?
Regards,
Sven
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] Default target file system permissions
2013-10-31 22:42 Sven Neumann
@ 2013-11-02 22:23 ` Arnout Vandecappelle
0 siblings, 0 replies; 6+ messages in thread
From: Arnout Vandecappelle @ 2013-11-02 22:23 UTC (permalink / raw)
To: buildroot
On 31/10/13 23:42, Sven Neumann wrote:
> Hi,
>
> I've been debugging some problems with our buildroot builds lately and
> found them to be caused by too restrictive permissions on the target
> file system. Pretty much all files and directories, unless specified
> explicitly in system/device_table.txt are only readable by the owner
> (root). This causes problems with samba (/var/nmbd not accessible by
> nmbd), dbus services (dbus daemon can not access the service files) and
> so on. Basically only services that are running as root can work
> correctly, because for other users the system is pretty much
> inaccessible. I've come across this mail on the mailing-list which seems
> related, but couldn't find an answer:
> http://buildroot-busybox.2317881.n4.nabble.com/Default-target-file-system-permissions-td39088.html
As mentioned in that mail, the problem is that you have a restrictive
umask set. Therefore, all files that are created by buildroot get this
umask applied.
I don't really see a solution. For starters, your filesystem skeleton
(in system/skeleton) probably already has wrong permissions. So even if
we'd reset the umask within the buildroot build, the skeleton would still
be installed with the wrong permissions.
I think the only thing we can do is to add a faq entry to the
documentation.
Regards,
Arnout
>
>
> Here's how the root folder on our target file-system looks like:
>
> drwxr-xr-x 20 root root 4096 Dec 7 1999 .
> drwxr-xr-x 20 root root 4096 Dec 7 1999 ..
> drwx------ 2 root root 4096 Dec 7 1999 bin
> drwxr-xr-x 2 root root 4096 Nov 30 1999 boot
> drwxr-xr-x 5 root root 4096 Dec 30 1999 data
> drwxr-xr-x 10 root root 12600 Dec 7 1999 dev
> drwxr-xr-x 15 root root 4096 Dec 7 1999 etc
> drwx------ 3 root root 4096 Dec 7 1999 home
> drwx------ 4 root root 4096 Dec 7 1999 lib
> lrwxrwxrwx 1 root root 11 Oct 31 20:26 linuxrc ->
> bin/busybox
> drwx------ 2 root root 4096 Dec 7 1999 media
> drwx------ 2 root root 4096 Dec 7 1999 mnt
> drwx------ 2 root root 4096 Dec 7 1999 opt
> dr-xr-xr-x 62 root root 0 Dec 7 1999 proc
> drwx------ 2 root root 4096 Oct 31 22:09 root
> lrwxrwxrwx 1 root root 3 Oct 31 18:39 run -> tmp
> drwx------ 2 root root 4096 Dec 7 1999 sbin
> dr-xr-xr-x 11 root root 0 Dec 7 1999 sys
> drwxrwxrwt 12 root root 800 Oct 31 21:51 tmp
> drwx------ 7 root root 4096 Dec 7 1999 usr
> drwxr-xr-x 7 root root 4096 Dec 7 1999 var
>
>
> So are the restrictive permissions on the target file-system intentional
> and how I can change this situation?
>
>
> Regards,
> Sven
>
>
>
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] Default target file system permissions
@ 2013-01-21 4:38 Przemyslaw Wrzos
0 siblings, 0 replies; 6+ messages in thread
From: Przemyslaw Wrzos @ 2013-01-21 4:38 UTC (permalink / raw)
To: buildroot
Hi,
I have a question regarding the default permissions files receive on the
target file system. The issue arises specifically if the host build
system uses a umask that leads to undesirable permissions on the target.
What I've done in the past is use a wrapper shell, that sets the umask
correctly and then calls bash, to replace the SHELL variable in the root
Makefile. This seems like a bit of a hack and I'm sure there must be a
better way to do it I'm not aware of. Now that each package has its own
device_table.txt this seems like it might be one good way, but the
makedev utility doesn't support setting permission recursively as far as
I can tell. Is there a better way to do this?
Cheers,
Przemyslaw Wrzos
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-11-02 22:23 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-11-02 8:13 [Buildroot] Default target file system permissions Sven Neumann
2013-11-02 10:06 ` Thomas Petazzoni
2013-11-02 18:30 ` Sven Neumann
-- strict thread matches above, loose matches on Subject: below --
2013-10-31 22:42 Sven Neumann
2013-11-02 22:23 ` Arnout Vandecappelle
2013-01-21 4:38 Przemyslaw Wrzos
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox