Default file permission required 777

[Amitava_HP-UX]

Hi
I need to copy lots of files in the home directory of a user everyday & execute it in a automated process. But every time i need to change the file permisson to 777 manually & then do it. If i change the umask 000 then file perm i am getting 666 & dir 777.
But is there any was so that i can get the default file perm 777 at the time of creation for a particular user. PLS HELP

[Arunvijai_4]

Hi,

You can specify "umask" in that particular user's profile in $HOME/.profile.

-Arun

[Sivakumar TS · Accepted solution]

Hi,

You cant CREATE a file with execute premission in HPUX.

The MAX permission you can have is only 666 for FILE>

you have to do chmod manually to set execute permission.

Regards,

Siva.

[Frank de Vries]

I personally would hope not.

Consider the architecture of unix it makes
no sense to have 777.
Not just a matter of compromising security,
but it is taking the easiest way out, while
with a bit of thought I am sure you won't need the default 777. (Hence it is not so readily possible)

We use
http://www.courtesan.com/sudo/
for these cases in our scripts,
so we do not compromise security and it
is very easy to configure.

Good luck.

[Amitava_HP-UX]

It seems that not possible, But is there anybody who knows any way to make it possible.

[Senthil Kumar .A_1]

Hi Amitava,

Thats the way the hpux commands were built, all the file creating commands, let it be touch,cat,vi ...all were built to invoke chmod() system call with 666 permission max which are controled by "umask" option externally by OS. This is indeed safe. If you were under the impression, that cc create's a.out with default executable permission ,why not others, thats because , cc invokes system call chmod() explicitly to set execute permission on a.out.

There can be 2 way out for a solution.

1) U may reconsider the way permissions are alotted,777 is very unsafe. Even with the minimal but very effective security control given by unix that is, UGO and RWX, you will still be able to control access without giving 777.

2) U can try using "chmod -R" option instead of setting on each file, or write a script to do so.

regards,
Senthil Kumar .A

[Yogeeraj_1]

hi,

try to modify the script that forms part of the automated process to do a chmod 777 on the files in the home directory.


hope this helps

kind regards
yogeeraj

[Peter Godron]

Amitava,
a copy would preserve the permissions.
If you copy x.sh to a.sh, on which you have set 777 once, a.sh will still have 777, but the code is from x.sh.

I would create a number of files in the users directory, chmod them and then just copy your new files into the existing files.

Or can you please gives us more details on your automated system.

[Bill Hassell]

The only reason to have 777 is that all of these files are programs and scripts. Of course, ANYONE on your computer can trash the files because of the wide open permissions. It is very important to understand that both 666 and 777 permissions are a huge red flag indicating that these files cannot be trusted.

Usually when I see 666 and 777 files, it is because someone got a "permission denied" error message and an untrained system administrator tries to patch the problem with chmod 777. Since you say that you are copying files into a specific user's HOME directory, the solution is quite simple: copy the files into the user's directory and then change the ownership of those files to that user. Since this is automated, the extra step in changing the ownership is just another line in the script. And if these files are important, be sure to use umask 022 (which allows others to read the files) in your script.

I can't emphasize enough how unsafe 666 and 777 permission are, especially on a production machine. Those permissions mean that the contents can NEVER be trusted to be accurate.

[Frank de Vries]

good remark Bill
I couldn't put it in better words myself :)