On 2011年05月23日 05:54, Saul Wold wrote:
On
05/21/2011 07:22 PM, Xiaofeng Yan wrote:
On 2011年05月22日 02:48, Wolfgang Denk wrote:
Dear Xiaofeng Yan,
In
message<d448b57c57fec346230d40fadc08625bd8c83224.1305972143.git.xiaofeng.yan@windriver.com>
you wrote:
From: Xiaofeng
Yan<xiaofeng.yan@windriver.com>
[YOCTO #1092]
Solve access permission for directory "/var/lib".
Makefile from package sudo change the ownership incorrectly.
Xiaofeng,
I would suggest you take a look at what nfs-utils is doing at
rootfs build time. That might be the package that's causing
problems.
Sau!
Hi Saul,
I remove package sudo from task-core-basic.bb and build a new
lsb-image without sudo. After building successfully, I startup lsb
image without sudo on emenlow. I check the access permission for
directory "/var/lib"
root@emenlow:/# ls var/ -l
total 5
drwxr-xr-x 2 root root 1024 May 19 10:17 backups
lrwxrwxrwx 1 root root 14 May 23 20:22 cache ->
volatile/cache
drwxr-xr-x 11 root root 1024 May 23 20:22
lib
drwxr-sr-x 2 root root 1024 May 19 10:17 local
lrwxrwxrwx 1 root root 13 May 23 20:22 lock -> volatile/lock
lrwxrwxrwx 1 root root 12 May 23 20:22 log -> volatile/log
drwxr-sr-x 2 root root 1024 May 19 10:17 mail
lrwxrwxrwx 1 root root 12 May 23 20:22 run -> volatile/run
drwxr-xr-x 5 root root 1024 May 23 05:54 spool
lrwxrwxrwx 1 root root 12 May 23 20:22 tmp -> volatile/tmp
drwxrwxrwt 7 root root 140 May 23 20:31 volatile
So I think package sudo change access permission for "/var/lib"
finally. Also I checked file "install_solution.manifest"
.......
/media/D/poky/32/poky.e/build/tmp/deploy/rpm/core2/nfs-utils-1.2.3-r2.core2.rpm
/media/D/poky/32/poky.e/build/tmp/deploy/rpm/core2/cronie-1.4.7-r2.core2.rpm
/media/D/poky/32/poky.e/build/tmp/deploy/rpm/core2/gzip-1.4-r0.core2.rpm
/media/D/poky/32/poky.e/build/tmp/deploy/rpm/core2/sudo-1.7.4p6-r0.core2.rpm
......
I don't know whether the packages are installed to image as the
sequence or not.
Signed-off-by: Xiaofeng
Yan<xiaofeng.yan@windriver.com>
---
meta/recipes-extended/sudo/sudo.inc | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-extended/sudo/sudo.inc
b/meta/recipes-extended/sudo/sudo.inc
index 6a04a9c..5ea089c 100644
--- a/meta/recipes-extended/sudo/sudo.inc
+++ b/meta/recipes-extended/sudo/sudo.inc
@@ -30,4 +30,5 @@ pkg_postinst_${PN} () {
chmod 4111 /usr/bin/sudo
chmod 0440 /etc/sudoers
+ chmod 0755 /var/lib
Sorry, but this commit message is misleading. You don't
change the
ownership here, but the file permissions.
Hi Wolfgang Denk,
Thanks for your reply. I am make lsb test to pass LSB
certification. LSB
Test suite check /vat/lib, but failed with the following
information.
/tset/LSB.fhs/var/lib/lib-tc 1 failed
Message from the test:
Reference 5.8-1(A)
The /var/lib directory exists and is searchable
Unexpected output written to stdout, as shown below:
stdout:lsb_test_dir: expected be able to search directory
/var/lib, got an error
stdout:ls: cannot open directory /var/lib: Permission denied
emenlow$ls /var/lib -l
drwx------ 10 root root 4096 May 20 19:21 lib
For general machine, the ownership of this directory is as
follow:
ubuntu$ls /var/lib -l
drwxr-xr-x 67 root root 4096 2010-12-15 23:30 lib
In fact, many packages make a operation to directory "/var/lib".
I find
the Makefile from package "sudo" change the ownership. Please
review the
following patch.
--- Makefile.orj 2011-05-21 16:32:35.392833427 +0800
+++ Makefile 2011-05-21 16:36:47.979380106 +0800
@@ -482,7 +482,7 @@
$(DESTDIR)$(visudodir) $(DESTDIR)$(noexecdir) \
$(DESTDIR)$(sudoersdir) $(DESTDIR)$(docdir) \
$(DESTDIR)$(mandirsu) $(DESTDIR)$(mandirform)
- $(SHELL) $(srcdir)/mkinstalldirs -m 0700 $(DESTDIR)$(timedir)
+ $(SHELL) $(srcdir)/mkinstalldirs -m 0755 $(DESTDIR)$(timedir)
install-binaries: install-dirs $(PROGS)
$(INSTALL) -b~ -O $(install_uid) -G $(install_gid) -M 04111 sudo
$(DESTDIR)$(sudodir)/sudo
So "0700" make this directory without access permission. Perhaps
it
could not be right method, I think you have a better method to
solve
this problem. If you have, Please share with me.
Thanks for your suggestion again.
Thanks
Yan
Best regards,
Wolfgang Denk
_______________________________________________
poky mailing list
poky@yoctoproject.org
https://lists.yoctoproject.org/listinfo/poky