$ls /var/lib -l drwx------ 10 root root 4096 May 20 19:21 lib We should modify permission of this directory as follow: $chmod 755 /var/lib If nobody modify this problem in .bb file including this directory operation. I will modify it by my method.
Can you give me more details about what image you are building, I just checked a minimal image and it does not have this problem. I wonder if there is some other recipe that is changing the ownership incorrectly.
Hi Saul, this problem arose when I built a lsb-image by command "$bitbake core-image-lsb-qt3"
Hi Saul, I found package "sudo" change ownership of directory "/var/lib". You can find the specified place by 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
Problem: The issue is that every application that uses a directory ends up creating and owning the directory structure. The permissions may not all match. So when the package manager first creates the directory, those are the permissions that stick for the rest of the filesystem. Solution: We simply need to add the ability to "own" a directory, instead of assuming ownership as we currently do. Question: We need to verify that the default umask is being set properly so that the permissions on default directories ends up to be reasonable. (0755) In the particular sudo case below, the permissions of the tree structure are wrong in the general case, but correct for this package. Switching to an owned directory structure should resolve this problem. So leave this as a known issue for now. If the problem is causing failures in anything outside of the LSB testing, then we should fix it as indicated in the attached patch, however if it's only an LSB failure directory ownership should fix it.
Hi Mark, I think if a image include package sudo, then this problem will arise. If I remove sudo from task-core-basic.bb then this problem will not arise. sorry for my English, can you give me more detailed steps for your solution? Please check my method at http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=xiaofeng/sudo I know this could not be a good solution for my method. If it is only arise for lsb, you mean I should modify this problem in file (.bb or script)related to lsb. right?
(In reply to comment #4) > Problem: > > The issue is that every application that uses a directory ends up creating and > owning the directory structure. The permissions may not all match. So when > the package manager first creates the directory, those are the permissions that Hi Mark, This is because: $(SHELL) $(srcdir)/mkinstalldirs -m 0700 $(DESTDIR)$(timedir) and the timedir=/var/lib/sudo but if /var/lib doesn't exist, the mkinstalldirs would create it and set the mode to 0700 recursively, so all of the /var, /var/lib and /var/lib/sudo would be set to 0700, but what sudo needs is only set /var/lib/sudo to 0700. This should be a bug of sudo, and "mkdir -p $(DESTDIR)/var/lib" before "mkinstalldirs -m 0700 $(DESTDIR)$(timedir)" would fix it. Xiaofeng will test it and send a new patch. //Robert > stick for the rest of the filesystem. > > Solution: > > We simply need to add the ability to "own" a directory, instead of assuming > ownership as we currently do. > > Question: > > We need to verify that the default umask is being set properly so that the > permissions on default directories ends up to be reasonable. (0755) > > > In the particular sudo case below, the permissions of the tree structure are > wrong in the general case, but correct for this package. Switching to an owned > directory structure should resolve this problem. So leave this as a known > issue for now. > > If the problem is causing failures in anything outside of the LSB testing, then > we should fix it as indicated in the attached patch, however if it's only an > LSB failure directory ownership should fix it.
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=505ee4b0a7443c185b101aaa6460d3a566a91fce