The Persistence of Vision Raytracer (POV-Ray).
This is the legacy Bug Tracking System for the POV-Ray project. Bugs listed here are being migrated to our github issue tracker. Please refer to that for new reports or updates to existing ones on this system.
Opened by Grimbert Jérôme - 2012-02-26
Last edited by William F Pokorny - 2016-11-07
FS#239 - Owner and group of user's local configurations on install is always root (bad)
I reinstall a system, (so ~/.povray was not existant), and then
installed povray from sources, as a normal user (excepted the
installation step):
$ ./configure ...
$ make
$ make check
$ sudo make install
I find these steps pretty much standard.
The problem I’m noticing is that the $HOME/.povray hierarchy get owned
by root (hey, it’s *MY* directory !). There is a chown in the Makefile
for the target files (povray.ini & povray.conf), as well as subtree but:
* povowner & povgroup are hard coded to 0 (I would expect a copy of the
owner & group of $HOME, wouldn’t I ?)
For getting povowner, I would suggest `stat -c “%u” $HOME`
For povgroup, `stat -c “%g” $HOME`
Are they portable enough ? (I could ask on Monday a Solaris system, but
I do not have bsd and the other flavours of unix)
(Stat is in section 1 of man, part of gnu coreutils, /usr/bin/stat)
Side note: This is fine to install for the local user, but new later
users could benefit also from a ~/.povray/3.7/ subtree ; what about also
filling the /etc/skel (when available) ? (and in /etc/skel, root owner
is fine!)
Monday, 07 November 2016, 12:24 GMT
Reason for closing: Fixed
Additional comments about closing:
Appears to be fixed, but never closed.
Has been working OK for too me as Ubuntu
user.
I did some digging and found that in ~unix/prebuild.sh on lines 568 and 569 that indeed your above recommendation is already there! Part of the preparation of a linux source distribution is to run the script to generate addition files for the build process. I build right in the perforce tree and no matter what I do I cannot run that script without elevation. I made darn sure everything in that tree was owned by me and the group I'm in (users) but the script even kills my terminal window. However running as sudo . ./prebuild.sh places some files owned by root/root (others are owned by me) in the build tree. Are we looking at actual vs effective uid/gid problem here because when I look at the generated Makefile.am povowner and povgroup indeed are = 0
Well, it should not be part of the preparation of the source distribution, but determined dynamically during installation.
If I understood you (Jim) correctly, the distribution is getting hard-coded values of the user which prepare the sources.
Maybe we are missing some escape sequence in prebuild.sh to not execute `stat...` during the cat « pbEOF, so that they remains in generated Makefile.am
I'm also curious about HOME : in povuser, it is referred with $(HOME) (and it works), whereas in povowner it is ${HOME} . There might be something fishy around that syntax (one is for shell, one for make, but ${ is pretty unique , maybe bogus ? )
It seems that
povowner = \`stat -c %u \$(HOME)\`
povgroup = \`stat -c %g \$(HOME)\`
would be ok in prebuild.sh (backslash before backquote, and dollar; change curly to straight parentheses }
Please confirm and if ok, perform the update in repository (I dare not touching that part without peer-review at RC stage)
I'm not sure whether I count as a peer when it comes to Unix, but from what I know this should be the (or at least one) proper way to do it.
after trying the above without any luck I ran (in ~unix/ directory) sudo -u ash ./prebuild.sh and it ran fine and added the following to ../Makefile.am:
povowner = 1000
povgroup = 100
which corresponds to my local uid/gid however when I sudo -u ash make install it complains that 'ash' doesn't have permission to replace the old binary with the newly compiled version. I also messed around with sudo rules and tried to add several rules concerning /usr/bin/make and /usr/bin/install without getting any further.
So .... I think that prebuild.sh is just fine (witness above) but the rest of the process HAS to be something to do with effective -vs- actual uid/gid
Is my system lacking somehow .... any sudo pro's out there?
I tired and tired (no joy) to get (in makefile syntax) something that would be dynamic (which is REALLY what we need here), and here's what I've come up with after I found a makefile tutorial and it said that make can access variables in the user environment, so I changed lines 568, 569 in
~unix/prebuild.sh from:
povowner = `stat -c %u ${HOME}`
povgroup = `stat -c %g ${HOME}`
to this:
povowner = \$(TheOwner)
povgroup = \$(TheGroup)
it causes this entry in Makefile.am that the user will get:
povowner = $(TheOwner)
povgroup = $(TheGroup)
if I were the user I'd unpack the package and:
export TheOwner=`stat -c %u ${HOME}`
export TheGroup=`stat -c %g ${HOME}`
./configure –prefix /home/ash/bin/povray ... other stuff
make
make install
I think we're getting close, but instead of setting environment variables we should get ./configure to somehow do the job. Try the following:
In prebuild.sh, replace the offending lines with:
and insert the following lines into the configure.ac script somewhere between "AC_INIT(...)" and "AC_OUTPUT":
povowner = `stat -c %u ${HOME}` povgroup = `stat -c %g ${HOME}` AC_SUBST([povowner]) AC_SUBST([povgroup])Yep that did the trick! I was onto that based on the code just above in prebuild.sh, I wasn't sure where but thanks for the nudge towards configure.ac
btw: here's a fairly decent ref:
Make Overview
I'll follow up with all the changes
submitted change #5615
It's ok for me. I would have pushed the stat in the makefile, but it's fine if configure does it: we can assume that the one running configure is the one which will perform the installation.
(at worst, the $(HOME) (notice () ! ) might end to be different from the ${HOME} (notice {}, not ()) when configure was run.)