Tiny Core Linux
Tiny Core Extensions => TCE Q&A Forum => Topic started by: aus9 on March 04, 2013, 06:18:55 PM
-
Hi
My build scripts are run by user tc
Recently I discovered that something was complaining something was not owned by root. I have always given root to any tce.installed script so my question is,
should I build using sudo su?
if I need to use sudo su, I will do so after running the wget source tarball
Or build under tc and then do something like
sudo chown -R root:root <target-folder>
trivia
###
the culprit is my foomatic-rip where ownership is currently
ls -al /usr/local/lib/cups
total 0
drwxr-xr-x 4 tc staff 80 Feb 20 17:20 ./
drwxr-xr-x 33 tc staff 15920 Feb 20 17:20 ../
drwxr-xr-x 2 tc staff 60 Feb 20 17:20 backend/
drwxr-xr-x 2 tc staff 60 Feb 20 17:20 filter/
no cups loaded just the foo*-rip
-
wiki will also be wrong, so let me explain it.
last change with old way is @ Last modified: 2012/10/24 18:27
Adding Custom Startup Scripts
blah blah
chown -R root:staff /tmp/package/usr/local/tce.installed
chmod -R 775 /tmp/package/usr/local/tce.installed
I added @ Last modified: 2012/10/24 18:31 a new section and
Important step before you move on
blah blah
mkdir -p /tmp/package/usr/local/tce.installed
touch /tmp/package/usr/local/tce.installed/package
sudo chown -R root:staff /tmp/package/usr/local/tce.installed
sudo chmod -R 775 /tmp/package/usr/local/tce.installed
Now to explain my change, in the history old way I changed a few things
I added the sudo
yes it was me.
But at no stage did I add any sudo su, or instruction to do this script as root. That means the old way, would have failed as local user because you can not change chown to root without being root eg
touch aa
tc@box:~$ chown root aa
chown: changing ownership of `aa': Operation not permitted
So I assumed because of NO mention that the script was to be run as root, it needed the sudo command
Now if we now assume script is to be run as root, then we can remove the sudo, but then we must tell user that script is to be run as root.
AFAIK at no version does anyone say to run as root. It that clearer?
Sorry if this sounds trivial but to me its important. From the local village idiot point of view, users can follow the wiki and that leads to more downstream maintainers, with luck. If I was ashamed of all my errors I would not have submitted anything. And I hoping you can see, by exposing my errors that we improve, so others don't fall for the same mistakes but make their own new mistakes or better still none at all.
cheers and thanks for reading
-
Hi aus9
For the few extensions I created I wrote a script that builds, creates the files (tcz, info, dep, etc.), and bundles the
files in an encrypted tarball ready for submission. I made it a point to prefix only those commands in the script
that require it with sudo. This way the script does not need to be run as root.
-
I understand, but maybe you could share a template of
owner:group
permissions
for each relevant folder
If I run it as root I am likely to get root:root
but looking at /etc there seems to be mixture?
-
trying to be smart I booted with bootcode base norestore to check TCB owners and permissions.
for usr
total 0
drwxrwxr-x 7 root staff 140 Apr 30 2010 .
drwxrwxr-x 17 root staff 380 Mar 6 08:49 ..
drwxrwxr-x 2 root staff 3440 Feb 17 16:32 bin
drwxrwxr-x 3 root staff 640 Mar 6 08:46 lib
drwxrwxr-x 5 root staff 100 Jan 7 2012 local
drwxrwxr-x 2 root staff 360 Jan 10 05:15 sbin
drwxrwxr-x 11 root staff 220 Nov 9 2010 share
for usr/local
total 0
drwxrwxr-x 5 root staff 100 Jan 7 2012 .
drwxrwxr-x 7 root staff 140 Apr 30 2010 ..
drwxrwxr-x 2 root staff 40 Mar 4 2010 bin
drwxrwxr-x 3 root staff 60 Mar 4 2010 lib
drwxrwxr-x 2 root staff 40 Jan 7 2012 tce.installed
inferred rule root:staff chmod 775
now load tcz cups and check /usr/local/etc (which has init.d sub-folder for starting etc services)
There is a mixture in there but for cups
root:root 755
2) because tc is a member of staff there are two ways of doing this
root:root chmod 744 would work IMHO
or
root:staff chmod 744 would work IMHO
sudo /usr/local/etc/init.d/cups start
should work and
that way we can have a blanket rule for tcz submitters to use
root:staff for all submissions but for any subfolder that contains config files or daemons, they are to use 744
I do agree that root:root focuses the mind that its a root thing but I am trying to have only 3 rules
rule (1) owner for all files is root:staff
rule (2) any config file or daemon file chmod 744.....ie rwx r-- r--
rule (3) all others are chmod 775................................ie rwx rwx r-x
IMHO any tcz-doc can still still be read, any executable lying under /usr/local/bin is still executable by tc user
but to check status of (say) cups would now be a root thing as currently I can check by tc user
tc@box:~$ /usr/local/etc/init.d/cups status
cups is not running.
what do others think?
-
There may be other users than tc and root.
They need to be able to execute programs and search directories too.
-
They need to be able to execute programs and search directories too.
sure and what is stopping them reading it if the read is showing as r ...r....r?
and what is stopping them from executing it if the execute is showing as ....x.....x.....x?......for rule (3)
Other users can become temporary root under rule (2) by running sudo <command>
but I don't care whether the rule or suggested rule is crap, as long as someone can tell me what ownership and permissions you would like for tcz submissions --
as the only rule AFAIK in the wiki is for tce.installed
should any build script be run as root or not?
If not, as Rich prefers to run as local, and thats exactly what I have been doing, then lets be clear what changes to make please.
Thanks for reading
trivia
####
rule (3) is a made up rule by me and not an official rule.....I am just trying to find out what is the official rule
-
Hi aus9
I think you are over-thinking this. I just checked the Wiki and it has two references to the word root, neither of
which refer to running as root. It also has two references to sudo, neither of which refer to becoming root.
I would say run as the default user (tc) and change the permissions as per the Adding Custom Startup Scripts
paragraph in the Wiki.
Then load and test the extension, if something complains about needing root ownership, modify the script
you use to build and package that extension to correct only the files and or directories that require it, and
run it again. Repeat as required.
-
Rich
thankyou for your thoughts. Let me expand a little so you know why I am asking.
1) All of my printer submissions can not be tested by me, as I have a printer that can not use a open source driver. So testing is very limited.
2) As the local village idiot, I seek clarity. I am aware we live in a grey world, but why can't we have rules that we can see.
If I go into /usr/local I see differences in ownership and permissions. Yes sorry if the word root was confusing in above, I mean either root ownership or root powers when I talk about root.....Please forgive me. Now because I have loaded some private extensions I happy to know I can spot some issues.......but the point is.....why not have a set of rules to comply with?
below is example of someone not following the rules (me) but what rules?
ls -al /usr/local
total 0
drwxr-xr-x 13 tc staff 260 Oct 26 2009 ./
drwxr-xr-x 7 tc staff 140 Oct 26 2009 ../
drwxr-xr-x 2 tc staff 11320 Oct 26 2009 bin/
drwxr-xr-x 3 root root 260 Nov 9 19:22 chromium-browser/
drwxr-xr-x 4 root root 80 Mar 7 14:48 chromium-browser-addons/
drwxr-xr-x 18 root root 460 Mar 7 14:48 etc/
drwxr-xr-x 7 root root 240 Dec 14 2010 include/
drwxr-xr-x 31 root root 15760 Mar 7 14:48 lib/
drwxr-xr-x 5 root root 640 Oct 29 2011 libexec/
drwxr-xr-x 10 root root 200 Aug 22 2012 plugins/
drwxr-xr-x 2 root root 2700 Dec 14 2010 sbin/
drwxr-xr-x 49 tc staff 1020 Mar 7 14:48 share/
drwxrwxr-x 2 root staff 3220 Mar 7 14:48 tce.installed/
above ownership of tc:staff indicates I have built tczs as local user. Once I can see the other owner/permissons it reasonable to suggest there should be a rule.
I repeat that users should be able to follow the wiki and everyone should be following the same template or set of rules.
AAAH some one might suggest that all I need to do, is look at existing owners and permissions?
In below example, there are variations, suggesting we need rules
If something is owned by root, it can be rwx even if its only a text file
I could go on, but I hope you see what I on about?
s -al /etc
total 176
drwxr-xr-x 10 root root 880 Mar 7 14:48 ./
drwxrwxr-x 17 root staff 360 Dec 21 23:29 ../
lrwxrwxrwx 1 root root 21 Mar 7 14:48 OpenCL -> /usr/local/etc/OpenCL
drwxr-xr-x 2 root root 100 Mar 7 14:48 X11/
-rw-r--r-- 1 root root 574 Mar 7 14:48 blkid.tab
-rw-r--r-- 1 root root 574 Mar 7 14:48 blkid.tab.old
-rw------- 1 root staff 140 Mar 5 2010 busybox.conf
lrwxrwxrwx 1 root root 26 Mar 7 14:48 environment -> /usr/local/etc/environment
drwxr-xr-x 4 root root 120 Apr 19 2009 fonts/
-rw-r--r-- 1 root root 752 Mar 7 14:48 fstab
-rw-rw-r-- 1 root staff 65 Mar 7 14:48 group
-rw-rw-r-- 1 root staff 63 Mar 7 14:48 group-
-rw-rw---- 1 root staff 56 Mar 7 14:48 gshadow
-rw-rw---- 1 root staff 54 Mar 7 14:48 gshadow-
-rw-rw-r-- 1 root staff 26 Mar 5 2010 host.conf
-rw-r--r-- 1 root root 4 Mar 7 14:48 hostname
-rw-r--r-- 1 root root 274 Mar 7 14:48 hosts
drwxrwxr-x 3 root staff 220 Jan 21 05:15 init.d/
-rw-rw-r-- 1 root staff 637 Aug 23 2011 inittab
-rw-rw-r-- 1 root staff 11 Nov 25 2011 issue
-rw-r--r-- 1 root root 50523 Mar 7 14:48 ld.so.cache
-rw-rw-r-- 1 root staff 15 Mar 5 2010 ld.so.conf
-rw-rw-r-- 1 root staff 801 Aug 15 2011 mke2fs.conf
-rw-rw-r-- 1 root staff 46 Mar 5 2010 modprobe.conf
-rw-rw-r-- 1 root staff 101 Nov 25 2011 motd
lrwxrwxrwx 1 root staff 12 Aug 9 2011 mtab -> /proc/mounts
-rw-rw-r-- 1 root staff 189 Mar 5 2010 nsswitch.conf
lrwxrwxrwx 1 root root 20 Mar 7 14:48 pam.d -> /usr/local/etc/pam.d
-rw-r--r-- 1 root root 161 Mar 7 14:48 passwd
drwxrwxr-x 2 root staff 60 Mar 5 2010 pcmcia/
-rw-rw-r-- 1 root staff 972 Jun 9 2012 profile
drwxrwxr-x 2 root staff 40 Mar 5 2010 profile.d/
-rw-rw-r-- 1 root staff 6455 Nov 6 2011 protocols
-rw-rw-r-- 1 root staff 52 Mar 7 14:48 resolv.conf
-rw-rw-r-- 1 root staff 1615 Mar 5 2010 rpc
-rw-rw-r-- 1 root staff 185 Mar 5 2010 securetty
lrwxrwxrwx 1 root root 23 Mar 7 14:48 security -> /usr/local/etc/security
-rw-rw-r-- 1 root staff 11349 Mar 5 2010 services
-rw-r----- 1 root root 134 Mar 7 14:48 shadow
-rw-rw-r-- 1 root staff 52 Mar 5 2010 shells
drwxr-xr-x 4 root root 220 Mar 7 14:48 skel/
-r--r----- 1 root root 293 Mar 5 2010 sudoers
drwxrwxr-x 2 root staff 280 Mar 7 14:48 sysconfig/
drwxr-xr-x 3 root root 80 Aug 11 2012 udev/
None of my tczs use /etc
thanks for reading
-
Hi Aus9, I'm not sure I totally understand what you're trying to suggest, but my 2c anyway...
General steps for building an extension are usually:
./configure
make
make DESTDIR=/tmpinstalllocation install
#package it up
I personally find it good practice to make sure that 3rd step (make install) is run as root. That's what the person who wrote the application/library/etc expected to happen when their code was built, and the Makefile might set specific permissions (eg, etc files might need to be owned by nobody:myspecialgroup or something) or other weird things, so NOT running the make install as root is potentially going to introduce odd and hard to solve bugs in extensions.
Also, it can be difficult to write up one set of rules/instructions/tempate that will work for every app -
* pppd has it's /etc files hardcoded
* php needs INSTALLPATH=... make install (or something along those lines, don't remember exactly) instead of make DESTDIR=... install
* pptp, dwm, and a few other apps don't even have configure files
* some apps use automake
There are countless other oddities out there, beyond what I've listed. Those are just the ones I've personally dealt with. A set of rules/templates/instructions more specific than what we already have seems counterproductive.
-
althalus
ok thats good to know. I will repeat that I would like the wiki to explain what owner:group and permissions are needed. Your answer is the first one to provide facts that I have not verified but accept ok.
Now the details. It appears that what you meant to say was
sudo make DESTDIR=/tmpinstalllocation install
inferred from your remark
I personally find it good practice to make sure that 3rd step (make install) is run as root
########
So pretend you are new to tcz submissons. So ideally you follow the wiki. (Yes I know there is more than one, and forum posts)
If the reason why others can not give me a simple of rules, based somewhat on your answer, no problem, I will close this thread shortly so people don't feel harassed. But I would like to see if you now see why I am posting which you did understand before.
I would like to edit wiki to say something like
" Please check that your owner:group and permissions will allow your software to run as securely as possible"
I would appreciate it if you now understand me and reply, if not, well boo hoo I will close this thread as solved in a couple of days.
I am about the rebuild something that is a depend for something else, and naturally have one more item to add to my checklist before submission
I am on a learning curve and depend almost entirely on wikis as I may lack the superior skills some other have. In that regard, I am still a newbie.
thanks for reading
-
I would like to edit wiki to say something like
" Please check that your owner:group and permissions will allow your software to run as securely as possible"
yes, but for that particular application, how do I do that? What ARE the correct permissions? Besides, I would argue that it's only necessary for setuid and etc files. Both of which are not a problem if you've run make install as root.
-
althalus
Do you have a sense of humour?
What ARE the correct permissions?
That was my original question. Does the penny drop yet?
ok looking at http://www.tinycorelinux.net/4.x/x86/tcz/src/lxpanel/lxpanel.build, from bmarkus
find $TMPDIR/ -type d | xargs chmod -v 755;
probably built as root, so I will enforce root:root and see what it looks compared to other tczs
-
Do you have a sense of humour?
What ARE the correct permissions?
That was my original question. Does the penny drop yet?
You miss my point. The point is, that question can and often does have a different answer for each application.
-
There are two categories of ownership and ACL. One is generic, related to Core itself like /usr/local/tce.installed etc. It is independent from the specific application.
Second category is application specific. You may need 600 on specific files, 644 on others, 755 or very more or to execute file as root without being root lioke Xorg servers, etc.
-
Simple set of rules:
1. All files root:root, 644 for files, 755 for executables, 755 for directories
2. Special settings varying on the software, e.g. setuid, setgid for Xorg, read/write-only for root in /etc/private or /var/..., special user like postfix or mysql, etc. within the extension or setup with the tce.installed/* script while booting.
3. [/usr/local]/etc/init.d/xyz scripts are usually system services and not user based services, so the simple set here is: check for root user, if not, just fail.
4. Tiny Core special settings, e.g. root:staff for /usr/local/tce.installed and 775
Optional:
5. If app/service can be run as a normal user (not as root!), make sure your init, start or extensions scripts are able to handle this. For example, query the $TCUSER variable and set the permissions accordingly when installing the extension. Or reconfigure the software so that it defaults to user writeable directories like $HOME, /tmp, etc.
@cups example: Since the service is run as root either way, the init script should also fail when not run as root, which is the easiest solution. Checkout the checkroot() helper function in /etc/init.d/tc-functions e.g. Try to use sudo in scripts as less as possible.
-
thankyou all for replying especially gutmensch
for those who are using some of my tczs, a number of them will need fixing.
I apologise for the time it will cause to be wasted for my fav tcz checker and users who wonder why they might see an update in the weeks ahead.
thread marked as solved