Permissions result in non-working programs

patch

While I understand the problem, I don't think it is appropriate to fix within autopackage.

There are many reasons for installing files with more restrictive permissions than 644/755 and we should not display warnings for something that may very well be correct behavior.

I doubt this is a real world issue. Remember, autopackage takes its input from whatever make install outputs (in autotools projects at least) which means its very unlikely that such a problem goes unnoticed (all other package formats use the same output, and so does source install)

I'm gonna close this as INVALID, but feel free to re-open it if you don't agree and then we'll discuss some more.

Replying to isak:

While I understand the problem, I don't think it is appropriate to fix within autopackage.

If I remember right, the tool for creating debian packages does also check file permissions and change them automatically.

There are many reasons for installing files with more restrictive permissions than 644/755 and we should not display warnings for something that may very well be correct behavior.

I can't imagine a case where it would be useful. If a program would import something that should not be read by anyone other then the user that installs it that wouldn't work, because you can also install it as root. If you want a file to be only readable by root the user could always install as a normal user and open it nevertheless.

I doubt this is a real world issue. Remember, autopackage takes its input from whatever make install outputs (in autotools projects at least) which means its very unlikely that such a problem goes unnoticed (all other package formats use the same output, and so does source install)

Well, I opened this bug report because I didn't notice this ;). I'm developing a python application and very rarely use the install script (which is only a bash file invoking install). I only did test the autopackage once, but forgot to test installation as root. After I uploaded the autopackage a user who installed it as root told me that my program doesn't start. The problem was that my application couldn't open the .glade file.

I've done a mistake in the patch: '< 5' should be '< 4'

Replying to Jan-Nik:

Replying to isak:

There are many reasons for installing files with more restrictive permissions than 644/755 and we should not display warnings for something that may very well be correct behavior.

I can't imagine a case where it would be useful.

I'm thinking sensitive configuration files in /etc containing passwords or so.

# find /etc -perm 0600 -type f | wc -l
19

Granted, many of these would never ever be installed by autopackage, but the point is that they exist.

If a program would import something that should not be read by anyone other then the user that installs it that wouldn't work, because you can also install it as root. If you want a file to be only readable by root the user could always install as a normal user and open it nevertheless.

Sure it would. You can set RootInstallOnly in your apspec to disable user install.

It not so much protecting the file against the user who installs the package, but rather against other users on the same box after the program has been installed.

Example: Installing FooProgram in ~foo/ as user foo will prevent anyone but foo and root to read this file. Installing it systemwide will prevent anyone except root from reading it.. I think this is an expected behavior.

I doubt this is a real world issue. Remember, autopackage takes its input from whatever make install outputs (in autotools projects at least) which means its very unlikely that such a problem goes unnoticed (all other package formats use the same output, and so does source install)

Well, I opened this bug report because I didn't notice this ;).

:)

I'm developing a python application and very rarely use the install script (which is only a bash file invoking install). I only did test the autopackage once, but forgot to test installation as root. After I uploaded the autopackage a user who installed it as root told me that my program doesn't start. The problem was that my application couldn't open the .glade file.

I'm curious, what did cause this from the beginning? How did the .glade file get 600 in the first place?

My point is that it's such a rare problem that (considering the risk of false positives) it's not worth "fixing". At least in my opinion.

I've done a mistake in the patch: '< 5' should be '< 4'

Ok, will fix that before commit if this patch gets in.

Replying to isak:

Replying to Jan-Nik:

Replying to isak:

There are many reasons for installing files with more restrictive permissions than 644/755 and we should not display warnings for something that may very well be correct behavior.

I can't imagine a case where it would be useful.

I'm thinking sensitive configuration files in /etc containing passwords or so. {{{ # find /etc -perm 0600 -type f | wc -l 19 }}} Granted, many of these would never ever be installed by autopackage, but the point is that they exist.

If a program would import something that should not be read by anyone other then the user that installs it that wouldn't work, because you can also install it as root. If you want a file to be only readable by root the user could always install as a normal user and open it nevertheless.

Sure it would. You can set RootInstallOnly in your apspec to disable user install. It not so much protecting the file against the user who installs the package, but rather against other users on the same box after the program has been installed. Example: Installing FooProgram in ~foo/ as user foo will prevent anyone but foo and root to read this file. Installing it systemwide will prevent anyone except root from reading it.. I think this is an expected behavior.

Okay, I didn't know that this was possible.

I doubt this is a real world issue. Remember, autopackage takes its input from whatever make install outputs (in autotools projects at least) which means its very unlikely that such a problem goes unnoticed (all other package formats use the same output, and so does source install)

Well, I opened this bug report because I didn't notice this ;).

:)

I'm developing a python application and very rarely use the install script (which is only a bash file invoking install). I only did test the autopackage once, but forgot to test installation as root. After I uploaded the autopackage a user who installed it as root told me that my program doesn't start. The problem was that my application couldn't open the .glade file.

I'm curious, what did cause this from the beginning? How did the .glade file get 600 in the first place?

That's a good question. Maybe the glade file was created by svn update on my PC and it's a bug in svn.

My point is that it's such a rare problem that (considering the risk of false positives) it's not worth "fixing". At least in my opinion.

The more I think it over, I agree. I think I will just add the code in my ./install.sh script.