hi,
when installing pike, dumped .o files are installed only with user permissions:
i am building and installing pike on fedora 12: the same is the case for the previously released 7.8.352
ls -la /usr/local/pike/7.8.530/lib/modules/*.o -rw------- 1 root root 16734 2011-01-26 17:49 /usr/local/pike/7.8.530/lib/modules/Arg.pmod.o -rw------- 1 root root 42028 2011-01-26 17:48 /usr/local/pike/7.8.530/lib/modules/Array.pmod.o -rw------- 1 root root 570 2011-01-26 17:49 /usr/local/pike/7.8.530/lib/modules/__builtin_dirnode.pmod.o -rw------- 1 root root 60 2011-01-26 17:48 /usr/local/pike/7.8.530/lib/modules/__builtin.pmod.o -rw------- 1 root root 2060 2011-01-26 17:49 /usr/local/pike/7.8.530/lib/modules/Colors.pmod.o -rw------- 1 root root 1077 2011-01-26 17:49 /usr/local/pike/7.8.530/lib/modules/Error.pmod.o -rw------- 1 root root 409 2011-01-26 17:48 /usr/local/pike/7.8.530/lib/modules/Float.pmod.o -rw------- 1 root root 30 2011-01-26 17:48 /usr/local/pike/7.8.530/lib/modules/Fuse.pmod.o -rw------- 1 root root 12260 2011-01-26 17:49 /usr/local/pike/7.8.530/lib/modules/Getopt.pmod.o -rw------- 1 root root 30 2011-01-26 17:48 /usr/local/pike/7.8.530/lib/modules/GTK2.pmod.o -rw------- 1 root root 30 2011-01-26 17:48 /usr/local/pike/7.8.530/lib/modules/GTK.pmod.o -rw------- 1 root root 13077 2011-01-26 17:48 /usr/local/pike/7.8.530/lib/modules/Gz.pmod.o -rw------- 1 root root 3032 2011-01-26 17:48 /usr/local/pike/7.8.530/lib/modules/_Image_DWG.pmod.o -rw------- 1 root root 14587 2011-01-26 17:49 /usr/local/pike/7.8.530/lib/modules/_Image_PSD.pmod.o -rw------- 1 root root 14475 2011-01-26 17:48 /usr/local/pike/7.8.530/lib/modules/_Image_PS.pmod.o -rw------- 1 root root 9857 2011-01-26 17:48 /usr/local/pike/7.8.530/lib/modules/_Image_TIFF.pmod.o -rw------- 1 root root 25185 2011-01-26 17:49 /usr/local/pike/7.8.530/lib/modules/_Image_XCF.pmod.o -rw------- 1 root root 9100 2011-01-26 17:49 /usr/local/pike/7.8.530/lib/modules/_Image_XPM.pmod.o -rw------- 1 root root 5624 2011-01-26 17:48 /usr/local/pike/7.8.530/lib/modules/Int.pmod.o -rw------- 1 root root 29270 2011-01-26 17:48 /usr/local/pike/7.8.530/lib/modules/Java.pmod.o -rw------- 1 root root 1809 2011-01-26 17:48 /usr/local/pike/7.8.530/lib/modules/Local.pmod.o -rw------- 1 root root 4488 2011-01-26 17:49 /usr/local/pike/7.8.530/lib/modules/Mapping.pmod.o -rw------- 1 root root 10856 2011-01-26 17:48 /usr/local/pike/7.8.530/lib/modules/Math.pmod.o -rw------- 1 root root 112 2011-01-26 17:49 /usr/local/pike/7.8.530/lib/modules/Multiset.pmod.o -rw------- 1 root root 201 2011-01-26 17:49 /usr/local/pike/7.8.530/lib/modules/Object.pmod.o -rw------- 1 root root 16228 2011-01-26 17:49 /usr/local/pike/7.8.530/lib/modules/Process.pmod.o -rw------- 1 root root 784 2011-01-26 17:48 /usr/local/pike/7.8.530/lib/modules/Program.pmod.o -rw------- 1 root root 3608 2011-01-26 17:48 /usr/local/pike/7.8.530/lib/modules/Regexp.pmod.o -rw------- 1 root root 186 2011-01-26 17:48 /usr/local/pike/7.8.530/lib/modules/System.pmod.o -rw------- 1 root root 17363 2011-01-26 17:48 /usr/local/pike/7.8.530/lib/modules/Thread.pmod.o -rw------- 1 root root 2510 2011-01-26 17:48 /usr/local/pike/7.8.530/lib/modules/Yp.pmod.o
greetings, martin.
umask is 0077, but shouldn't the install script ignore that and set its own umask?
greetings, martin.
On Wed, Jan 26, 2011 at 10:20:02AM +0000, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Why?
because the umask only affects files being created, not copied, which results in an inconsistent installation. all files, except the dumped .o files are world readable. if the umask were relevant for installation then it should apply to all files being installed.
when installing software, the permissions are usually set explicitly in the makefile and not by letting the installing users umask affect them. most software installations also do not produce new files during installation, so the umask normally has no effect at all.
it is therefore an unexpected behaviour, when i have to take care of my umask to avoid files being created with wrong permissions.
greetings, martin.
to be more specific to what is happening here, it doesn't make sense for the dumped .o files to have different permissions than the corresponding source files.
if the source files are world readable, then the .o files should be world readable as well. otherwise the users will just see lots of irritating warnings that they can not explain nor fix:
$ pike /usr/local/pike/7.8.530/lib/modules/Tools.pmod/Hilfe.pmod.o:-: Warning: Decode failed: Bad argument 1 to decode_value(), (expecting string, got int) /usr/local/pike/7.8.530/lib/modules/Parser.pmod/module.pmod.o:-: Warning: Decode failed: Bad argument 1 to decode_value(), (expecting string, got int) /usr/local/pike/7.8.530/lib/modules/__builtin.pmod.o:-: Warning: Decode failed: Bad argument 1 to decode_value(), (expecting string, got int) /usr/local/pike/7.8.530/lib/modules/Parser.pmod/Pike.pmod.o:-: Warning: Decode failed: Bad argument 1 to decode_value(), (expecting string, got int) /usr/local/pike/7.8.530/lib/modules/Parser.pmod/C.pmod.o:-: Warning: Decode failed: Bad argument 1 to decode_value(), (expecting string, got int) /usr/local/pike/7.8.530/lib/modules/ADT.pmod/module.pmod.o:-: Warning: Decode failed: Bad argument 1 to decode_value(), (expecting string, got int) /usr/local/pike/7.8.530/lib/modules/ADT.pmod/Stack.pike.o:-: Warning: Decode failed: Bad argument 1 to decode_value(), (expecting string, got int) /usr/local/pike/7.8.530/lib/modules/Array.pmod.o:-: Warning: Decode failed: Bad argument 1 to decode_value(), (expecting string, got int) /usr/local/pike/7.8.530/lib/modules/Math.pmod.o:-: Warning: Decode failed: Bad argument 1 to decode_value(), (expecting string, got int) /usr/local/pike/7.8.530/lib/modules/Error.pmod.o:-: Warning: Decode failed: Bad argument 1 to decode_value(), (expecting string, got int) /usr/local/pike/7.8.530/lib/modules/Stdio.pmod/module.pmod.o:-: Warning: Decode failed: Bad argument 1 to decode_value(), (expecting string, got int) /usr/local/pike/7.8.530/lib/modules/System.pmod.o:-: Warning: Decode failed: Bad argument 1 to decode_value(), (expecting string, got int) /usr/local/pike/7.8.530/lib/modules/Pike.pmod/module.pmod.o:-: Warning: Decode failed: Bad argument 1 to decode_value(), (expecting string, got int) /usr/local/pike/7.8.530/lib/modules/ADT.pmod/History.pike.o:-: Warning: Decode failed: Bad argument 1 to decode_value(), (expecting string, got int) /usr/local/pike/7.8.530/lib/modules/Stdio.pmod/Readline.pike.o:-: Warning: Decode failed: Bad argument 1 to decode_value(), (expecting string, got int) /usr/local/pike/7.8.530/lib/modules/Stdio.pmod/Terminfo.pmod.o:-: Warning: Decode failed: Bad argument 1 to decode_value(), (expecting string, got int) /usr/local/pike/7.8.530/lib/modules/Thread.pmod.o:-: Warning: Decode failed: Bad argument 1 to decode_value(), (expecting string, got int) Pike v7.8 release 530 running Hilfe v3.5 (Incremental Pike Frontend)
greetings, martin.
Right. If you have set umask to 077 to prevent stuff from being accessed by anyone but yourself, you wouldn't want the source files to get liberal permissions. If the users can't see the pike installation at all, they will not get irritating warnings.
On Wed, Jan 26, 2011 at 05:35:02PM +0000, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Right. If you have set umask to 077 to prevent stuff from being accessed by anyone but yourself, you wouldn't want the source files to get liberal permissions. If the users can't see the pike installation at all, they will not get irritating warnings.
i can not tell what point you are trying to make. do you expect sysadmins to reset their umask before installation for this to work when most applications do not need that (because they do not create files during installation)
sure, it could be added to the README that before installation the umask should be set to 0022, but if the permissions were set correctly when dumping files life would be easier for sysadmins.
mysql also had a bug like this and it has been fixed accordingly: http://bugs.mysql.com/bug.php?id=52213
greetings, martin.
sure, it could be added to the README that before installation the umask should be set to 0022, but if the permissions were set correctly when dumping files life would be easier for sysadmins.
It seems to me that the permissions _are_ set correctly when dumping, but not when installing the source files. Why shouldn't the user be allowed to install with umask 077 if he wants to? The README might say that the user should set his umask the way he wants it to be, but isn't that kind of obvious?
what is not obvious is that i have to change my umask from 0077 to 0022 if i wand to make an installation that is usable by everybody.
the point i am trying to make is that the installation by default should set the permissions so that pike can be used by everybody, regardless of the installers umask.
greetings, martin.
It breaks site policy, but maybe we should do that. What does the other p-languages do?
On Fri, Jan 28, 2011 at 1:00 PM, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum 10353@lyskom.lysator.liu.se wrote:
Why is this not obvious? Umask 077 means "don't make things usable by anyone but me".
There is at least more to Martin's point than I saw at first:
1) Umasks, by definition, affect the permissions of newly created files, not files with an existing set of permissions (i. e. copied ones, untar'ed ones, ...). I think we can somewhat legitimately extrapolate that to complete build sessions. 2) Having half of the files of the Pike installation be affected by the umask and the other half unaffected clearly doesn't help at all, in one way or the other.
So probably it should be decided whether files are affected by the umask at all or not. The current mixing clearly can be of no help to anyone.
I can see two main ways to install pike, one is after compiling the source, and the second using a binary package.
In the first case, the output of the compilation should IMHO respect the users umask. And that for all files the same wheter compiled, installed or dumped.
Whereas in the package management system, the package manager is responsible (because he is responible for the deployment to actually work after installation according to the package management rules). In this case the dumped files should be the same as the installed sources / files.
On Fri, Jan 28, 2011 at 03:51:56PM +0100, Marc Dirix wrote:
In the first case, the output of the compilation should IMHO respect the users umask. And that for all files the same wheter compiled, installed or dumped.
this is complicated by the practice to use a normal user account to compile and only use root to run install. those users could have different umasks.
greetings, martin.
An interresting proposal, but what does it mean in practice? Should the installer always respect umask, and it is the responsibility of the package management system to set the umask correctly for that case?
pike-devel@lists.lysator.liu.se
-
Marc Dirix -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum -
Martin Baehr -
Martin Bähr
-
Peter Bortas ＠ Pike developers forum
-
Tobias S. Josefowitz