Bug 443568

Milos: do not get confused by the component of this report; Boinc has no
Bugzilla components for some reason, Toshio was pinged about the matter and
hopefully things are going to be sorted out soon.

This is clearly caused by the change you did here:
* Mon Apr 14 2008 Milos Jakubicek <xjakub.cz> - 5.10.45-8.20080315svn

%post
#correct wrong owner and group on files under /var/lib/boinc and log files
#caused by bug fixed in 5.10.45-8
chown --silent -R boinc:boinc %{_localstatedir}/log/boinc* \
%{_localstatedir}/lib/boinc/*

This is plain wrong. Please at the very least add "|| :" at the end so that this
evaluates to true in all cases. Also, redirect the error output to /dev/null by
2>/dev/null

Milos, also raising priority to urgent, since this causes the package to be
uninstallable. Please commit fix as soon as CVS gets unlocked and request freeze
break for the build as described here:

http://fedoraproject.org/wiki/ReleaseEngineering/FinalFreezePolicy

I see you've just committed the change, thanks...and sorry for that, I focused
on proper update and forgot to test a fresh install.

However, this is actually not a blocker bug since the package tagged as f9-final
is not boinc-client-5.10.45-8, but boinc-client-5.10.45-5, which is working
fine, however, boinc daemon is running as root instead of the boinc user. So,
Lubomir, should I still mail rel-eng and ask them for approving new build or not?

PS: I'll commit also to the F-7 branch...

(In reply to comment #3)
> I see you've just committed the change, thanks...and sorry for that, I focused
> on proper update and forgot to test a fresh install.
> 
> However, this is actually not a blocker bug since the package tagged as f9-final
> is not boinc-client-5.10.45-8, but boinc-client-5.10.45-5, which is working
> fine, however, boinc daemon is running as root instead of the boinc user. So,
> Lubomir, should I still mail rel-eng and ask them for approving new build or not?

Running stuff that processes potentially untrusted data as root is never a wise
thing, I'd prefer if you broke the freeze for that.

> PS: I'll commit also to the F-7 branch...

Thanks.

Milos: Also, please do updates for releases that include the vulnerable packages. 

I propose that the %post scriptlet goes away for f10, since there will be no
supported upgrade path from the old packages to it, and set the owner and group
for the boinc user owned directories with %attr in %files.

boinc-client-5.10.45-9.20080315svn.fc7 has been submitted as an update for Fedora 7

>I propose that the %post scriptlet goes away for f10, since there will be no
>supported upgrade path from the old packages to it, and set the owner and group
>for the boinc user owned directories with %attr in %files.

I'm not sure about this -- it will break upgrading between releases. I know that
assuming this I can never remove it...but, does it pain having the post
scriptlet there?

Concerning components: I've also mailed Toshio about two weeks ago, hopefully
the script will be fixed soon.

boinc-client-5.10.45-9.20080315svn.fc8 has been submitted as an update for Fedora 8

(In reply to comment #7)
> >I propose that the %post scriptlet goes away for f10, since there will be no
> >supported upgrade path from the old packages to it, and set the owner and group
> >for the boinc user owned directories with %attr in %files.
> 
> I'm not sure about this -- it will break upgrading between releases. I know that
> assuming this I can never remove it...but, does it pain having the post
> scriptlet there?

That's  plain wrong assumption. After the updates are out, there won't exist any
upgrade path that would break, unless users voluntarily install broken packages.

(In reply to comment #9)

> That's  plain wrong assumption. After the updates are out, there won't exist any
> upgrade path that would break, unless users voluntarily install broken packages.

Yes -- provided users will update the package to the most recent version.
Otherwise no. Suppose somebody has already installed the package (in F7/F8) and
won't update it until an upgrade to F10. Then it will definitely break (not the
upgrade itself, but boinc!)

However, this is a very improbable scenario...I'll remove it in F10.

Freeze break approved by rel-eng, boinc-client-5.10.45-9.20080315svn.fc9 tagged
as f9-final.

Earlier today I added a section to the BOINC wiki explaining how to install
BOINC on Fedora 7 and up, see
http://boinc.berkeley.edu/wiki/index.php/Installing_BOINC#Fedora_7_and_up.

Now, from messages here, I see there were possibly some bugs in the rpm package
or something.  I do not understand all the issues because I am still a Linux
newbie.  Is the material I wrote in the wiki correct?  Will the material be
correct when the fixes described in messages above are released?  Or will the
material need to be edited?

No, the instructions are definitely not correct. BOINC shouldn't be run under
the user's account. There is a special account "boinc" for BOINC in Fedora.

Please refer to this page I created recently:
http://fedoraproject.org/wiki/MilosJakubicek/HowToUseBoinc

Probably the best solution is just link to that page.

Milos, thank you for your quick reply and link to HowToUseBoinc :)

I think most users will not want to manually connect the manager to the client.
 Is there a reason why the manager should not be run under the user's account? 
I ask not to be argumentative, just because I'm still learning Linux.

 

(In reply to comment #14)
> I think most users will not want to manually connect the manager to the client.
> Is there a reason why the manager should not be run under the user's account? 
> I ask not to be argumentative, just because I'm still learning Linux.

What do you mean by running the manager? Of course the manager (=the GUI app
BOINC Manager) is run under the user who ran it.

Something completely different is running the BOINC client (=the daemon, the
service). This is run under the "boinc" account. An ordinary user doesn't have
any rights to manipulate with it (start, stop, etc). Even connecting to the
client via BOINC manager needs to be authenticated using the password from
/var/lib/boinc/gui_rpc_auth.cfg because using the manager you can fully control
the client.

So the point is that normal users shouldn't be able to manipulate with
(system-wide running) services. Just ask in case of any unclarity:)

(In reply to comment #15)
> (In reply to comment #14)
> > I think most users will not want to manually connect the manager to the client.
> > Is there a reason why the manager should not be run under the user's account? 
> > I ask not to be argumentative, just because I'm still learning Linux.
> 
> What do you mean by running the manager? Of course the manager (=the GUI app
> BOINC Manager) is run under the user who ran it.
> 
> Something completely different is running the BOINC client (=the daemon, the
> service). This is run under the "boinc" account. An ordinary user doesn't have
> any rights to manipulate with it (start, stop, etc). Even connecting to the
> client via BOINC manager needs to be authenticated using the password from
> /var/lib/boinc/gui_rpc_auth.cfg because using the manager you can fully control
> the client.
> 
> So the point is that normal users shouldn't be able to manipulate with
> (system-wide running) services. Just ask in case of any unclarity:)
> 

I thought you were going to say that.  I understand and I agree that *normal*
users should not be able to manipulate the boinc service.  Access should be
controlled via the gui_rpc password.

Conventional wisdom says the sysadmin should login as root only when necessary
and that he should have an alternate account for normal (non-administrative)
tasks. The instructions I wrote at BOINCWiki recommend that root add *only* his
alternate username to the boinc group and place a link to gui_rpc_auth.cfg
*only* in his alernate user's home directory.  That way he can connect the
manager to localhost without the gui_rpc password and he doesn't have to make
the password blank to make it easy to remember.  I think suggesting to make the
password blank like you did is a bad idea, sorry :)

(In reply to comment #16)
> (In reply to comment #15)
> > (In reply to comment #14)
> > > I think most users will not want to manually connect the manager to the
client.
> > > Is there a reason why the manager should not be run under the user's account? 
> > > I ask not to be argumentative, just because I'm still learning Linux.
> > 
> > What do you mean by running the manager? Of course the manager (=the GUI app
> > BOINC Manager) is run under the user who ran it.
> > 
> > Something completely different is running the BOINC client (=the daemon, the
> > service). This is run under the "boinc" account. An ordinary user doesn't have
> > any rights to manipulate with it (start, stop, etc). Even connecting to the
> > client via BOINC manager needs to be authenticated using the password from
> > /var/lib/boinc/gui_rpc_auth.cfg because using the manager you can fully control
> > the client.
> > 
> > So the point is that normal users shouldn't be able to manipulate with
> > (system-wide running) services. Just ask in case of any unclarity:)
> > 
> 
> I thought you were going to say that.  I understand and I agree that *normal*
> users should not be able to manipulate the boinc service.  Access should be
> controlled via the gui_rpc password.
> 
> Conventional wisdom says the sysadmin should login as root only when necessary
> and that he should have an alternate account for normal (non-administrative)
> tasks. The instructions I wrote at BOINCWiki recommend that root add *only* his
> alternate username to the boinc group and place a link to gui_rpc_auth.cfg
> *only* in his alernate user's home directory.  That way he can connect the
> manager to localhost without the gui_rpc password and he doesn't have to make
> the password blank to make it easy to remember. 

Now I see what you intend by this, however I still do not understand your
question about not running the manager under an ordinary user, but never mind.

> I think suggesting to make the
> password blank like you did is a bad idea, sorry :)

I don't suggest anything. I only wrote that IF (and only if:) somebody wants to
set an empty password, this is the right way how to, because people usually just
delete the file which causes a new one to be created.

But fine, let's make a trade-off, we should probably merge our wiki's and let
the users decide how they arrange it for themselves, hm?

boinc-client-5.10.45-9.20080315svn.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

boinc-client-5.10.45-9.20080315svn.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.

(In reply to comment #17)
> (In reply to comment #16)
> > (In reply to comment #15)
> > > (In reply to comment #14)
> > > > I think most users will not want to manually connect the manager to the
> client.
> > > > Is there a reason why the manager should not be run under the user's
account? 
> > > > I ask not to be argumentative, just because I'm still learning Linux.
> > > 
> > > What do you mean by running the manager? Of course the manager (=the GUI app
> > > BOINC Manager) is run under the user who ran it.
> > > 
> > > Something completely different is running the BOINC client (=the daemon, the
> > > service). This is run under the "boinc" account. An ordinary user doesn't have
> > > any rights to manipulate with it (start, stop, etc). Even connecting to the
> > > client via BOINC manager needs to be authenticated using the password from
> > > /var/lib/boinc/gui_rpc_auth.cfg because using the manager you can fully
control
> > > the client.
> > > 
> > > So the point is that normal users shouldn't be able to manipulate with
> > > (system-wide running) services. Just ask in case of any unclarity:)
> > > 
> > 
> > I thought you were going to say that.  I understand and I agree that *normal*
> > users should not be able to manipulate the boinc service.  Access should be
> > controlled via the gui_rpc password.
> > 
> > Conventional wisdom says the sysadmin should login as root only when necessary
> > and that he should have an alternate account for normal (non-administrative)
> > tasks. The instructions I wrote at BOINCWiki recommend that root add *only* his
> > alternate username to the boinc group and place a link to gui_rpc_auth.cfg
> > *only* in his alernate user's home directory.  That way he can connect the
> > manager to localhost without the gui_rpc password and he doesn't have to make
> > the password blank to make it easy to remember. 
> 
> Now I see what you intend by this, however I still do not understand your
> question about not running the manager under an ordinary user, but never mind.
> 

I am sorry for not clarifying what I meant.  In comment #13 where you said
"BOINC should not be run under the user's account" I thought you were using
BOINC to refer to the manager.  You were actually refering to the client. So
it's not surprising my question seemed odd to you.  

> > I think suggesting to make the
> > password blank like you did is a bad idea, sorry :)
> 
> I don't suggest anything. I only wrote that IF (and only if:) somebody wants to
> set an empty password, this is the right way how to, because people usually just
> delete the file which causes a new one to be created.

I think they delete the file because they are the sysadmin and they feel the
sysadmin should not be required to type in localhost and the gui_rpc_password. 
They think if they delete the file then the password will not be required and
the connection will occur automatically.  So you suggest an empty password and
that works *but* it allows all other users to connect too.  If there is only 1
user (the administrator) then it does not matter but if the machine is on a LAN
then others could connect to the client from other machines.  I think an empty
remote_hosts.cfg might exclude connections from other hosts but I have never
tried that.     

> 
> But fine, let's make a trade-off, we should probably merge our wiki's and let
> the users decide how they arrange it for themselves, hm?

Yes, we could merge the 2 wikis.  Give me a day or 2 to investigate further. 
And I want to hear your thoughts on the other points I raised.

Thanks for discussing this with me.

Oops, the updates haven't been set to close this bug. Resolving as CURRENTRELEASE.