Ticket #69 (closed Defect: wontfix)

Opened 4 months ago

Last modified 3 months ago

Permissions result in non-working programs

Reported by: Jan-Nik Assigned to: Jan-Nik
Priority: Low Milestone: 1.2.5
Component: devtools Version: 1.2.4
Severity: Trivial Keywords:
Cc:

Description

In my project folder there's my glade file:

-rw------- 1 jhasse jhasse 53082 2008-03-12 15:00 main.glade

If i import this file and install it as root it will be owned by root and my program cannot be run by a normal user (binary can't open the glade file, because it can only be read by root). Maybe mackepackage should post an error or even change the permissions.

Attachments

permissions.diff (0.9 kB) - added by Jan-Nik on 04/20/08 14:06:07.
patch

Change History

04/15/08 10:40:26 changed by Jan-Nik

  • owner changed from taj to Jan-Nik.
  • milestone set to 1.2.5.

04/20/08 14:06:07 changed by Jan-Nik

  • attachment permissions.diff added.

patch

(follow-up: ↓ 3 ) 04/22/08 12:01:49 changed by isak

  • status changed from new to closed.
  • resolution set to invalid.

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.

(in reply to: ↑ 2 ; follow-up: ↓ 4 ) 04/22/08 12:44:13 changed by Jan-Nik

  • status changed from closed to reopened.
  • resolution deleted.

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'

(in reply to: ↑ 3 ; follow-up: ↓ 5 ) 04/22/08 13:53:29 changed by 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.

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.

(in reply to: ↑ 4 ) 04/22/08 14:02:22 changed by Jan-Nik

  • status changed from reopened to closed.
  • resolution set to wontfix.

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.