The Myth of "Once you go Slack, you never go back"
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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
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
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!
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...
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.
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.
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?
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
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
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).
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.
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:
# 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.
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
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.