LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 01-29-2015, 01:16 PM   #166
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541

Rep: Reputation: 1065Reputation: 1065Reputation: 1065Reputation: 1065Reputation: 1065Reputation: 1065Reputation: 1065Reputation: 1065

Quote:
Originally Posted by brianL View Post
But how does rm delete itself?
It's running in memory.
 
Old 01-29-2015, 01:34 PM   #167
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 8,792

Rep: Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656
Quote:
Originally Posted by a4z View Post
put FAKEROOT in front of upgradepkg install new
Am I missing something? Why would you want to "upgradepkg install new" using fakeroot? I thought the point was to run the slackbuilds using fakeroot, but installing packages would be using real root... to remove the problem of building the packages as root.

As for locations, is it unacceptable to still start sbopkg as root if it uses fakeroot when running the slackbuilds (unacceptable in the goals of preventing privelege escalation when it isn't needed)? Otherwise, I could see it being a massive pain to install any packages with it, which is an especially useful thing with sbopkg when using queues of multiple packages some of them being dependencies.

Unless I'm misunderstanding, it seems that the above would effectively neuter sbopkg to provide running slackbuilds under fakeroot. Wouldn't the better option be still require root to open it (or at least prompt for root if you elect to install packages after they're built -- if this happened, prompting for root would be required for initial startup (if default locations are used) and whenever any syncs are performed) while providing the option for users to use fakeroot to run the slackbuilds? I think a simple option in the conf file to enable fakeroot would be the best, then before the system is built, if using fakeroot is set, then you can place that command before executing the slackbuild.
 
1 members found this post helpful.
Old 01-29-2015, 01:44 PM   #168
a4z
Senior Member
 
Registered: Feb 2009
Posts: 1,727

Rep: Reputation: 742Reputation: 742Reputation: 742Reputation: 742Reputation: 742Reputation: 742Reputation: 742
Quote:
Originally Posted by bassmadrigal View Post
Am I missing something? Why would you want to "upgradepkg install new" using fakeroot? I thought the point was to run the slackbuilds using fakeroot, but installing packages would be using real root... to remove the problem of building the packages as root.
no, I am just to tired, I will make a note in the orig post,..
of course in front of the slackbuild call.

Quote:
Originally Posted by bassmadrigal View Post
As for locations, is it unacceptable to still start sbopkg as root if it uses fakeroot when running the slackbuilds (unacceptable in the goals of preventing privelege escalation when it isn't needed)? Otherwise, I could see it being a massive pain to install any packages with it, which is an especially useful thing with sbopkg when using queues of multiple packages some of them being dependencies.
personally I would not allow it to run as root, but some people might want to,
in this case fakeroot is not required,
but download extract, these files will have permissions which are not good for users
so if you swithc on one machine between root and user ..

Quote:
Originally Posted by bassmadrigal View Post
Unless I'm misunderstanding, it seems that the above would effectively neuter sbopkg to provide running slackbuilds under fakeroot. Wouldn't the better option be still require root to open it (or at least prompt for root if you elect to install packages after they're built -- if this happened, prompting for root would be required for initial startup (if default locations are used) and whenever any syncs are performed) while providing the option for users to use fakeroot to run the slackbuilds? I think a simple option in the conf file to enable fakeroot would be the best, then before the system is built, if using fakeroot is set, then you can place that command before executing the slackbuild.
[/QUOTE]

thats true, yes you need to install as root and ask for the password,
so if its possible to store the password and reuse it, the default file locations could be used.
good point!
 
Old 01-29-2015, 01:50 PM   #169
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 8,792

Rep: Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656
Quote:
Originally Posted by a4z View Post
thats true, yes you need to install as root and ask for the password,
so if its possible to store the password and reuse it, the default file locations could be used.
good point!
Unfortunately, I don't think there's any secure way of storing the password without causing a new possible security hole...
 
Old 01-29-2015, 01:52 PM   #170
a4z
Senior Member
 
Registered: Feb 2009
Posts: 1,727

Rep: Reputation: 742Reputation: 742Reputation: 742Reputation: 742Reputation: 742Reputation: 742Reputation: 742
Quote:
Originally Posted by bassmadrigal View Post
Unfortunately, I don't think there's any secure way of storing the password without causing a new possible security hole...
of course not in a textfile, temporary ...
you request it once and reuse it, when installing , build, install, like it is by queues
 
Old 01-29-2015, 01:58 PM   #171
ruario
Senior Member
 
Registered: Jan 2011
Location: Oslo, Norway
Distribution: Slackware
Posts: 2,557

Rep: Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761
Quote:
Originally Posted by a4z View Post
these are a bit tricky, I think per default these will not work for a user,
LOGFILE=${LOGFILE:-/var/log/sbopkg/sbopkg-build-log}
QUEUEDIR=${QUEUEDIR:-/var/lib/sbopkg/queues}
REPO_ROOT=${REPO_ROOT:-/var/lib/sbopkg}
SRCDIR=${SRCDIR:-/var/cache/sbopkg}

its not a problem to handle this, but what would be a good place and/or rights for these?
or a sbo group where you have to be member of..?

fix the stuff that it works for personal use seems to be easy because you know your locations..
I think you are over complicating it. Are you really going to have multiple people building packages on your machine? I'm going to guess it will just be you.

I did a quick test and actually it is fairly easy to use sbopkg as non root after all.

Code:
$ cat << EOF > ~/.sbopkg.conf
LOGFILE=$HOME/.var/log/sbopkg/sbopkg-build-log
QUEUEDIR=$HOME/.var/lib/sbopkg/queues
REPO_ROOT=$HOME/.var/lib/sbopkg
SRCDIR=$HOME/.var/cache/sbopkg
EOF
$ fakeroot sbopkg -rb afio
At the end the package '/tmp/afio-2.5.1-x86_64-1_SBo.tgz' was created and is valid.

I got one error but it did not stop the build

Code:
/usr/sbin/sbopkg: line 388: /var/run/sbopkg.pid: Permission denied
P.S. That problem can easily be fixed via issuing the following as root:

Code:
sed -i 's,/\(var/run/sbopkg.pid\),$HOME/.\1,' /usr/sbin/sbopkg
Followed by the following as your regular user:

Code:
mkdir -p $HOME/.var/run
If they made a definable variable for the pid file, that would be enough IMHO.

EDIT: Then again, you could just ignore it. The pid is just to protect you from running two instances of sbopkg at once. As long as you don't do that you should be fine.

Last edited by ruario; 01-29-2015 at 02:06 PM.
 
1 members found this post helpful.
Old 01-29-2015, 02:03 PM   #172
brianL
LQ 5k Club
 
Registered: Jan 2006
Location: Oldham, Lancs, England
Distribution: Slackware64 15; Slackware64-current (VM); Debian 12 (VM)
Posts: 8,290
Blog Entries: 61

Rep: Reputation: Disabled
Quote:
Originally Posted by tronayne View Post
It's running in memory.
Ah, yes. thanks. I'll have to try that command-that-shouldn't-be-mentioned --no-preserve-root in a VM some time.
 
Old 01-29-2015, 02:58 PM   #173
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 8,792

Rep: Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656
Quote:
Originally Posted by a4z View Post
of course not in a textfile, temporary ...
you request it once and reuse it, when installing , build, install, like it is by queues
Even if you have it stored in a variable, unless you're able to encrypt it, isn't it still able to be grabbed? (I'll admit, this is getting outside of my realm of scripting knowledge.) Also, is there a way to pass root's password to su to have it log in without it being typed?
 
Old 01-29-2015, 03:10 PM   #174
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: McKinney, Texas
Distribution: Slackware64 15.0
Posts: 3,858

Rep: Reputation: 2225Reputation: 2225Reputation: 2225Reputation: 2225Reputation: 2225Reputation: 2225Reputation: 2225Reputation: 2225Reputation: 2225Reputation: 2225Reputation: 2225
Why not use "sudo" to do the install? (Assuming that you set your $PATH to match root's prior to running installpkg/upgradepkg.)
 
Old 01-29-2015, 03:36 PM   #175
55020
Senior Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 1,307
Blog Entries: 4

Rep: Reputation: Disabled
Well done Mr Cranium. That's how mine works -- it has a directory /usr/libexec/slackrepo with symlinks to all the good stuff, then it is prepended to $PATH. This is added to /etc/sudoers.d
Code:
username ALL=(ALL) NOPASSWD: /usr/libexec/slackrepo/*
Currently in /usr/libexec/slackrepo I've symlinked
depmod, explodepkg, groupadd, installpkg, ldconfig, pkgtool, removepkg, slackpkg, update-gtk-immodules, upgradepkg, useradd
... and a script that fixes the dumb regex matching in slackpkg
... and (more controversially) mv rm sed
which are necessary to undo some evil things when certain packages are uninstalled. Anyone who thinks those three symlinks are a security hole should meditate upon what a sudoer could do by tarring up a malicious doinst.sh and then running installpkg...

Edit: Found the first problem: the upstream makefile for academic/gtkwave attempts to run /usr/bin/update-desktop-database. If that's typical, this thread has been a real storm in a teacup. Ironically, academic/root builds fine

Last edited by 55020; 01-29-2015 at 05:05 PM.
 
Old 01-29-2015, 07:52 PM   #176
ivandi
Member
 
Registered: Jul 2009
Location: Québec, Canada
Distribution: CRUX, Debian
Posts: 528

Rep: Reputation: 866Reputation: 866Reputation: 866Reputation: 866Reputation: 866Reputation: 866Reputation: 866
After all that arguing I should like to say that I don't mind running slackbuilds as root. IF AND ONLY IF they have been tested running as root. In my PAM project I blindly trust PatV for his slackbuilds. My own additional slackbuilds have been run as user before publishing and I reminded their eventual users that they have to review them, just in case. I didn't publish any binary packages just because IMO installing packages from random locations like forum posts or personal repositories defies the common sense. I am perfectly aware that one can run them in a VM or whatever protected environment but anyway this is simply wrong.

When AlienBob claims that Slackware sort of approved the way SBo works I am confused:
Quote:
Questions and Answers

1. Are you affiliated with and/or endorsed by Slackware?
No. We are not affiliated with or officially endorsed by either Patrick Volkerding or Slackware Linux, Inc.
This project is maintained by volunteers who wish to contribute something useful to the Slackware user community. Furthermore, for clarity's sake, the concept of a SlackBuild script came from Slackware itself, not from us.
I have no doubt in the good will of SBo maintainers.
BUT verification is the ultimate trust (not sure that's the exact English translation, hope you get the idea).


Cheers

Last edited by ivandi; 01-29-2015 at 07:54 PM.
 
Old 01-29-2015, 08:31 PM   #177
hitest
Guru
 
Registered: Mar 2004
Location: Canada
Distribution: Void, Slackware
Posts: 7,341

Rep: Reputation: 3744Reputation: 3744Reputation: 3744Reputation: 3744Reputation: 3744Reputation: 3744Reputation: 3744Reputation: 3744Reputation: 3744Reputation: 3744Reputation: 3744
Quote:
Originally Posted by ivandi View Post
I have no doubt in the good will of SBo maintainers.
BUT verification is the ultimate trust (not sure that's the exact English translation, hope you get the idea).
Take some time to get to know the SBo maintainers. Robby Workman, a maintainer on SBo, is also one of our Slackware developers. I think that you are correct to be cautious with your choice of trusted sources. The SBo people are good people.
 
Old 01-29-2015, 09:11 PM   #178
ivandi
Member
 
Registered: Jul 2009
Location: Québec, Canada
Distribution: CRUX, Debian
Posts: 528

Rep: Reputation: 866Reputation: 866Reputation: 866Reputation: 866Reputation: 866Reputation: 866Reputation: 866
Quote:
Originally Posted by hitest View Post
Take some time to get to know the SBo maintainers. Robby Workman, a maintainer on SBo, is also one of our Slackware developers. I think that you are correct to be cautious with your choice of trusted sources. The SBo people are good people.
I am really sorry you pushed me to quote the zarfy.SlackBuild, the one that started all this:

http://slackbuilds.org/slackbuilds/1...rfy.SlackBuild
Quote:
#!/bin/sh

# Slackware build script for zarfy

# Copyright 2006-2011 Robby Workman, Northport, Alabama, USA
# All rights reserved.
#
....
....
Sorry once again, but I have to verify my sources. As every Slackware user has to (or at least is supposed to). And I am sorry to repeat myself, but this makes extending the default Slackware setup a horribly inefficient and annoying process.

And I repeat myself once again. I have no any doubt that the SBo people are good people.


Cheers
 
Old 01-29-2015, 10:18 PM   #179
qweasd
Member
 
Registered: May 2010
Posts: 621

Rep: Reputation: Disabled
Quote:
Originally Posted by ivandi View Post
Sorry once again, but I have to verify my sources. As every Slackware user has to (or at least is supposed to). And I am sorry to repeat myself, but this makes extending the default Slackware setup a horribly inefficient and annoying process.
I fail to see how Slackware is different in this respect from any other GNU/Linux distribution. Are you worried about sbopkg scripts? I wouldn't be. They are trivial to check for turds, and SBO team does just that and more: based on my experience, they actually run submitted scripts and advise maintainers when something is amiss. If I were you, I would be far more worried about the actual sources. Try guessing how many Debian package maintainers read the software sources? I will guess almost none. This is unlike SBO folks who actually read the submitted diffs! So every user of every GNU/Linux distribution has to trust the good will and the competence of thousands of different upstream teams, and thousands more lone rangers who are kind enough to maintain the software.

I am sure we can find areas where Slackware is horribly inefficient, but extending the full install is simply not it. Sure, it's not fire-and-forget. Sure, you may have to read and fix up a build script every now and then. But at least the build scripts are readable. Ever tried fixing up a Debian package?

Last edited by qweasd; 01-29-2015 at 10:19 PM. Reason: clarification
 
Old 01-29-2015, 10:46 PM   #180
hitest
Guru
 
Registered: Mar 2004
Location: Canada
Distribution: Void, Slackware
Posts: 7,341

Rep: Reputation: 3744Reputation: 3744Reputation: 3744Reputation: 3744Reputation: 3744Reputation: 3744Reputation: 3744Reputation: 3744Reputation: 3744Reputation: 3744Reputation: 3744
Quote:
Originally Posted by ivandi View Post
And I repeat myself once again. I have no any doubt that the SBo people are good people.
It comes down to trust. I've used the scripts from the trustworthy people at SBo who also happen to be good (many are my friends) for many years. I've also used packages that the developers Robby and Eric have created. I've trusted the Slackware developers since 2004 when I first started with Slackware 10.0. I'm not a very trusting person; I tend to write off software that fails to deliver. The SBo people and our developers deliver the goods.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Indie Royale "Back To School Bundle" includes "Swords and Solders" dugan Linux - News 0 09-15-2012 05:23 PM
Slack 11 Konqueror: "System:/" shows no icons. How do I get them back MonctonJohn Slackware 0 02-04-2008 07:24 PM
K3b: - Howto re-dock "Directories" and "Contents" windows back into the main window? hagies Linux - Software 4 04-26-2006 08:38 AM
"You always go back to Slack" (ramble) webfiend Slackware 5 07-18-2002 02:59 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 03:35 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration