installpkg messing up perms
in [Slackware]
|
From: Henrik Carlqvist on 7 Jul 2010 01:53 Dario Niedermann <M8R-cthw2f(a)spamherelots.com> wrote: > Lately, `installpkg` seems to be messing up permissions on system > directories here: the latest incident being '/' set to 700 after > installing a slackbuild. > > Other times, '/usr' and '/home' too were affected, IIRC. This is most likely because of the packages you installed. If a package contains contents from /usr or /home it will also contain that directory. Packages containing a directory will set the permission of that directory to the permissions it has in the package. Also, all packages must of course contain the / directory. You could use tar to examine your packages, example: $ tar -tvf transcode-1.0.3-pentium3-mp.tgz | more drwxr-xr-x root/root 0 2007-08-12 13:56 ./ drwxr-xr-x root/root 0 2007-08-12 13:55 usr/ drwxr-xr-x root/root 0 2007-08-12 13:55 usr/doc/ drwxr-xr-x root/root 0 2007-08-12 13:55 usr/doc/transcode-1.0.3/ -rw-r--r-- root/root 4735 2006-12-22 09:43 usr/doc/transcode-1.0.3/TODO .... As you can see above the permissions for / and /usr are correct. If your package has something like drwx------ for those directories you will get the problem that you describe. regards Henrik -- The address in the header is only to prevent spam. My real address is: hc3(at)poolhem.se Examples of addresses which go to spammers: root(a)localhost postmaster(a)localhost
From: Mike Jones on 7 Jul 2010 09:03 Responding to Dario Niedermann: > Lately, `installpkg` seems to be messing up permissions on system > directories here: the latest incident being '/' set to 700 after > installing a slackbuild. > > Other times, '/usr' and '/home' too were affected, IIRC. > > Is this a known bug? This didn't happen back when 12.2 was new. Maybe > some relatively recent security update is upsetting installpkg? > > TIA I hit something like this a few times. I finally figured out I was causing the problem myself. While the default system umask was 022, my user accounts are set to 077. This means that when I log in as root in a user account's RXVT\Xterm, I get the user's environment, not root's. This also means that running SlackBuild scripts and other things that (re)generate system dirs will set them within the user's umask and not root's. D'OH! Make sure, if you log in as root in an RXVT\Xterm\Terminal\whatever, you use the command "su -" as the dash gives root environment and umask settings!!! Add this to your user()'s .bashrc alias=su="su -" ....and I'll bet your problems vanish. -- *=( http://www.thedailymash.co.uk/ *=( For all your UK news needs.
From: Dario Niedermann on 7 Jul 2010 11:41 Mike Jones <luck(a)dasteem.invalid> wrote: > While the default system umask was 022, my user accounts are set to 077. > This means that when I log in as root in a user account's RXVT\Xterm, I > get the user's environment, not root's. This also means that running > SlackBuild scripts and other things that (re)generate system dirs will > set them within the user's umask and not root's. D'OH! I see... basically I too was getting the 077 umask, courtesy of `sudo`. Anyway - as you and Henrik stated - installpkg is actually tampering with system directories, which seems to be unneeded and potentially harmful. IMO we're looking at a (easily fixed) design flaw here. Thank you guys. -- > head -n1 /etc/*-{version,release} && uname -moprs Slackware 12.2.0 Linux 2.6.27.7-crrm i686 AMD Turion(tm) 64 Mobile Technology MK-36 GNU/Linux
From: Mike Jones on 7 Jul 2010 17:16 Responding to Dario Niedermann: > Mike Jones <luck(a)dasteem.invalid> wrote: > >> While the default system umask was 022, my user accounts are set to >> 077. This means that when I log in as root in a user account's >> RXVT\Xterm, I get the user's environment, not root's. This also means >> that running SlackBuild scripts and other things that (re)generate >> system dirs will set them within the user's umask and not root's. >> D'OH! > > > I see... basically I too was getting the 077 umask, courtesy of `sudo`. > > Anyway - as you and Henrik stated - installpkg is actually tampering > with system directories, which seems to be unneeded and potentially > harmful. IMO we're looking at a (easily fixed) design flaw here. > Well, not so much tampering, as duplicating. As has been mentioned briefly already on this topic, some processes have a dir structure already to copy in, and this simply duplicates what is already there, or creates it if its not. If there are property differences, say permissions, then the new will overwrite the old, as my self-generated fault did, rendering the new only readable by root and causing a problem for user accounts. The new, in your case, may be doing this in reverse, or you may have a cascade glitch if something isn't reading what it needs to because of previous modifications. I'd be looking to any customisations here before assuming installpkg is at fault. If you do some searching and find very little in the way of others having similar problems, this might be a clue that your problem is relatively unique to your system. If you discover something while investigating, post up. All the above FWIW. Good luck. -- *=( http://www.thedailymash.co.uk/ *=( For all your UK news needs.
From: Sylvain Robitaille on 12 Jul 2010 01:50
Dario Niedermann wrote: > Anyway - as you and Henrik stated - installpkg is actually tampering > with system directories, ... That isn't at all what Mike and Henrik stated. It is, however, what seems to be the conclusion you've already reached. > IMO we're looking at a (easily fixed) design flaw here. You're barking up the wrong tree. The behaviour you're seeing is known behaviour of tar, which installpkg depends on. The easily fixed "flaw" is in the tar file (ie. package) you're installing. If you're installing self-made packages, fix the directory tree permissions before making the package. If you're using SlackBuild scripts to create the pacakges, fix your SlackBuild scripts. Hint: all my SlackBuild scripts include the line "umask 022" somewhere near the top. Any additional adjustments to specific permissions can be made later in the script. I hope this helps ... -- ---------------------------------------------------------------------- Sylvain Robitaille syl(a)encs.concordia.ca Systems analyst / AITS Concordia University Faculty of Engineering and Computer Science Montreal, Quebec, Canada ---------------------------------------------------------------------- |