Bug 1080149 - lpf stalls installing : ls: cannot open directory /var/lib/lpf/rpms/<pkg>: Permission denied
Summary: lpf stalls installing : ls: cannot open directory /var/lib/lpf/rpms/<pkg>: Pe...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: lpf
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Alec Leamas
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1118714 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-03-24 18:46 UTC by Paul DeStefano
Modified: 2015-02-02 17:23 UTC (History)
1 user (show)

Fixed In Version: lpf-0.1-8.36e5aa0.fc21
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-10-29 11:02:31 UTC
Type: Bug


Attachments (Terms of Use)

Description Paul DeStefano 2014-03-24 18:46:52 UTC
Description of problem:
lfp seems to build okay, but stalls trying to install.

Version-Release number of selected component (if applicable):
lpf-0.1-6.36e5aa0.fc20.noarch

How reproducible:
Happens always (at least with skype, the only lpf pkg I've tried).

Steps to Reproduce:
1. install lpf
2. install lpf-skype
3. add user to pkg-build
4. start lpf-gui
5. build skype

Actual results:
"Install" phase stalls forever.  The following error repeats at high rate :

ls: cannot open directory /var/lib/lpf/rpms/skype: Permission denied
ls: cannot open directory /var/lib/lpf/rpms/skype: Permission denied
ls: cannot open directory /var/lib/lpf/rpms/skype: Permission denied
...


Expected results:


Additional info:
The resulting packages work great, though!  Skype seems to work better than pkg from web-site.  So glad.

Comment 1 Alec Leamas 2014-03-24 19:34:03 UTC
This looks like a a permission problem   (sic!)...

First question: have you logged out and in again after adding you to the pkg-build group? If not, please do so and report results. 

Next question: If you still have problems after logging out-in, this might be a sudo issue. Are you using sudo otherwise, and have the overall feeling that your installation is sane? In particular, have you this line at the very end of your /etc/sudoers file?

#includedir /etc/sudoers.d

Also, please check that your sg(1) utility is sane. What gives the command

$ sg pkg-build "echo foo" 

for results?

Comment 2 Paul DeStefano 2014-03-24 22:05:54 UTC
(In reply to Alec Leamas from comment #1)
> This looks like a a permission problem   (sic!)...

Yeah, I agree. ;-)

> First question: have you logged out and in again after adding you to the
> pkg-build group? If not, please do so and report results. 

Yes.  I just rechecked, though, using lpf after logging into another virtual console.
 
> Next question: If you still have problems after logging out-in, this might
> be a sudo issue. Are you using sudo otherwise, and have the overall feeling
> that your installation is sane? In particular, have you this line at the
> very end of your /etc/sudoers file?
> 
> #includedir /etc/sudoers.d

Check.  It's in there.  I *always* use sudo for sysadmin work.
 
> Also, please check that your sg(1) utility is sane. What gives the command
> 
> $ sg pkg-build "echo foo" 

$ sg pkg-build "echo foo"
foo


Sorry, I should have said before, but I didn't want to prejudge the situation.  The directory /var/lib/lpf/rpms/skype is 600.  That's probably the permission problem; I just didn't know for sure what caused it.  But I think I do.  yum had a long lived bug, now fixed, in which it did not manage permissions properly, assuming umask instead of setting it.  This caused 'sudo yum' to break things since it inherits umask, while 'sudo -i yum' worked since is sources root env.  This has a suspiciously similar flavor.  Could that be what is happening here?

Regardless, repeating ls indefinitely is incorrect behavior.  This error should be caught.  In this respect, lpf is okay, BTW, it's just lpf-gui that doesn't recognize the fatal error and retries indefinitely.

Comment 3 Alec Leamas 2014-03-25 18:16:34 UTC
(In reply to Paul DeStefano from comment #2)
> (In reply to Alec Leamas from comment #1)

[snip]
So, the easy parts are checked and OK.

> Sorry, I should have said before, but I didn't want to prejudge the
> situation.  The directory /var/lib/lpf/rpms/skype is 600.  That's probably
> the permission problem; I just didn't know for sure what caused it.  But I
> think I do.  yum had a long lived bug, now fixed, in which it did not manage
> permissions properly, assuming umask instead of setting it.  This caused
> 'sudo yum' to break things since it inherits umask, while 'sudo -i yum'
> worked since is sources root env.  This has a suspiciously similar flavor. 
> Could that be what is happening here?

I don't *think* so. These are directories under /var/lib/lpf which by definition are generated by lpf rather than installed by yum.

Nevertheless, it's an important clue. My corresponding directories are 755. Might it be that you have a more restrictive umask than most other users (my is 0002)? And what's the pkg-build user's umask on your machine (also 0002 for me)?

> Regardless, repeating ls indefinitely is incorrect behavior.  This error
> should be caught.  

Agreed. 

> In this respect, lpf is okay, BTW, it's just lpf-gui that
> doesn't recognize the fatal error and retries indefinitely.

Yes, we'll certainly need to handle that. Good catch!

Comment 4 Paul DeStefano 2014-03-26 05:39:25 UTC
Thanks for your help Alec.

> > Sorry, I should have said before, but I didn't want to prejudge the
> > situation.  The directory /var/lib/lpf/rpms/skype is 600.  That's probably
> > the permission problem; I just didn't know for sure what caused it.  But I
> > think I do.  yum had a long lived bug, now fixed, in which it did not manage
> > permissions properly, assuming umask instead of setting it.  This caused
> > 'sudo yum' to break things since it inherits umask, while 'sudo -i yum'
> > worked since is sources root env.  This has a suspiciously similar flavor. 
> > Could that be what is happening here?
> 
> I don't *think* so. These are directories under /var/lib/lpf which by
> definition are generated by lpf rather than installed by yum.

> Nevertheless, it's an important clue. My corresponding directories are 755.
> Might it be that you have a more restrictive umask than most other users (my
> is 0002)?

Oh, sorry, I wasn't clear.  Your thought is what I was suggesting, not that yum was at fault here, too.  Yes, In fact my mask is 0077.  That's why yum's old behavior failed and required sudo -i.

So, I think we are saying that our umask differences match our system differences exactly.

> And what's the pkg-build user's umask on your machine (also 0002
> for me)?

Hmm, my pkg-build user's home directory doesn't have any user-specific profile files.  Does that answer your question?  On my system, user pkg-build's shell is 'nologin' and it is impossible, as far as I know, to load that user's profile.  I suspect you are running a specific command and want me to do it, too, but you stumped me; I can't figure out what it could be.

Comment 5 Alec Leamas 2014-03-26 15:07:53 UTC
OK, this basically seems to be a umask problem. Since you have the test rig: Could you make a test,setting the umask to 0002 the following files, all in /usr/share/lpf/scripts (If you have the proper authorization for that, I guess)?

.../scripts/lpf (~ line 225, after the " exec sg pkg-build "$0 $*"" line
.../scripts/lpf-pkgbuild (line ~114, after the "exec $SUDO -u pkg-build"line)
.../scripts/lpf-sudo-install (in the beginning, ~ line 10)

--a

Comment 6 Paul DeStefano 2014-03-31 04:16:44 UTC
Bingo.  It works, as far as I can tell.

I added umaks 0002 to the top of all three scripts, yum erased skype, then ran lpf-gui.  It complained a couple times about updates and gave an error on install again, but, I tried again and it asked for my password and now the two skype packages are installed like before and skyp works.

This is great.  I hadn't heard of LPF before; now I'm anxious to try out the flash plugin so I can ditch the thrid party repository I added.

Comment 7 Alec Leamas 2014-04-01 06:28:52 UTC
Great! Thanks for help!

Now, this seems  a little bit like a corner case. There is still another bug under investigation, so I'll hold an update until this is also sorted out. But stay tuned, there *will* be an update based on these findings.

Thanks again for reporting this bug and testing support!

Comment 8 Fedora Update System 2014-08-30 06:43:47 UTC
lpf-0.1-8.36e5aa0.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/lpf-0.1-8.36e5aa0.fc19

Comment 9 Fedora Update System 2014-08-30 06:54:04 UTC
lpf-0.1-8.36e5aa0.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/lpf-0.1-8.36e5aa0.fc20

Comment 10 Alec Leamas 2014-08-30 08:31:38 UTC
*** Bug 1118714 has been marked as a duplicate of this bug. ***

Comment 11 Fedora Update System 2014-09-02 06:43:15 UTC
Package lpf-0.1-8.36e5aa0.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing lpf-0.1-8.36e5aa0.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-10059/lpf-0.1-8.36e5aa0.fc19
then log in and leave karma (feedback).

Comment 12 Fedora Update System 2014-10-28 23:15:50 UTC
lpf-0.1-8.36e5aa0.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/lpf-0.1-8.36e5aa0.fc21

Comment 13 Fedora Update System 2014-10-29 11:02:31 UTC
lpf-0.1-8.36e5aa0.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 14 Fedora Update System 2014-10-29 11:03:53 UTC
lpf-0.1-8.36e5aa0.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 15 Paul DeStefano 2015-01-31 23:08:53 UTC
Thank you!

Gave karma, but still less than 3.

Comment 16 Fedora Update System 2015-02-02 17:23:50 UTC
lpf-0.1-8.36e5aa0.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.