my Integrated Development Environment generates source files in my home directory with 755 permissions. I understand that I am the only person with physical access to my Linux machine.

The issue here is that in general source files are never meant to be executed. Therefore, file permissions don't have a sane setting.

The correct setting in this case should be at least 444, if not 440. In general it should be 644. I don't have enough knowledge on Linux security to estimate the impact this change would make to global system security. Because of this my personal approach is to provide as much security as I am capable of without affecting my workflow.

My concerns is that these are generated files. I must not intentionally modify file contents. I must not unintentionally modify file contents. Same for my group. My world shouldn't even know these files exist, yet alone execute them!

My question is whether this qualifies for a bug report or not? It's an upstream issue so I cannot apply changes myself. I found many recommendations for file permissions on the internet, but the only bug reports for permissions I found had a negative impact on the workflow which does not apply in my case.

As far as I can remember, the execute bit is not honoured for data files, so 755 is equivalent to 644. You can modify permanently the access mode of generated files by modifying your umask.

1 members found this post helpful.

On linux you can create any file with any content and make it executable so the executable bit is always honored:

umask is helpful but I am uncertain if it is a solution, because I also have executable files in my working directory. How can I differentiate between source files and compiled binaries?

1 members found this post helpful.

I'm not sure I would call it a bug, but I would say this IDE sucks, it really shouldn't do that.

Are you sure it's your IDE's fault though?

2 members found this post helpful.

You misunderstood. A file (a plain text file, like c source) will not be executable by setting +x on it. That is more or less pointless, sometimes it is just ignored. Obviously there are cases when this flag is checked, for example when the shell is looking for an executable in PATH.
the executable flag is not a right way to decide if a file was source or something else. You can use the command file to check (and identify) anything.

generators (which generate any kind of files) usually honor umask. The only exception is 1. when you tell it to do differently, 2. when it wanted to set any flag "by default" (like the linker will set x on executables).

You are right, setting executable flag on sources is not really nice, but not a security issue.
If you have an IDE most probably you have an option to configure it somehow.

1 members found this post helpful.

The "umask" setting only affects newly created objects. I would think that one would want to make a deliberate choice to make any file executable. My preference would be to have default permissions for any regular files to be "644", "640", or, even, "600" and issue "chmod u+x filespec" as needed.

Even after I've found compiled binaries (using "file *| grep executable"), I'm still picky about just who I would allow to execute those files and, typically, only use the above "chmod" command when it's really necessary.

Executables that I want/need others to be able to use go in "/usr/local/bin" anyway and, then, issue a generous "chmod +x filespec". The "world" doesn't need to be running binaries out of my home directory tree.

UPDATE: You can get confused over the whole executable bit thing when transferring files onto Linux from Windows. I often find "executable" JPEGs, text files, etc. after having completed the transfer. Fixing that requires a couple of commands to clear the executable bits to avoid future confusion when doing any casual "ls" commands.

Cheers...

1 members found this post helpful.

Except for scripts / binaries used during development, debugging or testing. I wasn't aware that bash can execute files without 'x' permission, because:

fails with

but it can be done like so:

I didn't know about umask before. However, my project structure is certainly not prepared for a 177 umask default setting. It would break on many places. I see no problem with a 077 umask, though. That IDE is the single only tool which is incorrectly setting the executable flag anyway. All my other source generators are using 644 permission.


Thank you all for your input. I conclude from this that unsane file permissions are not necessarily a bug, as there are many ways a file can be executed. Instead of relying on security from unknown sources (generated files, git repositories, downloads, NTFS formatted USB drives, etc) we should make our own system secure. On the other hand, as for our own work we should not propagate risky practices but instead recommend sane defaults.

I tend to either touch empty file, make it executable, and start editing it to add the code. Or simply issue the "chmod u+x scriptname" command before I test it with "./scriptname". As you noted, though, even that's not necessary when you can issue "bash scriptname". Eventually, though, after it's been debugged, it gets made executable and moved to $HOME/bin (or /usr/local/bin). YWMV (Your Workflow May Vary)

Running chmod should only be needed for scripts. No chmodding should be needed when creating "binaries" such as come out of gcc. (Try it with "hello.c".)

Cheers...

I tried that, too. Binaries are executable under normal circumstances (gcc default behaviour?). If I set umask 177 before compiling the binary is not executable, though. This proofs that binaries are not necessarily executable.

the +x is just a flag. You can put anywhere or remove if you wish. That will not change the file itself, but how can it be accessed. There are certain cases when the system checks this flag (especially if you are looking for an executable in your PATH) or when you try to execute any file (independently of its real content).
It does not belong strictly to the file, but will rule how can you use it.
using "/bin/bash file" bash should be set to executable
gcc can make real executable binaries, therefore it tries to set this flag.

I gather that gcc makes the final linked binary executable by default, but of course a more conservative umask would override that. In Linux, you always have the final word!

As far as Windows is concerned, I noticed a long time ago that files copied from a mounted Windows device such as a USB key always seemed to have the execute bit set. That's probably because Windows filesystems don't have permissions, so some kind of default has to be used.