As far as I can tell, this is hard-coded into standard utilities. I straced both a touch creating a new file and a mkdir creating a new directory. The touch trace produced this: open( , O_WRONLY| | | , ) = "newfile" O_CREAT O_NOCTTY O_NONBLOCK 0666 3 while the mkdir trace produced this: mkdir( , ) "newdir" 0777 Short of coding the file/directory creation process in C, I don't see a way of modifying the default permissions. It seems to me, though, that not making files executable by default makes sense: you don't want any random text to be accidentally misconstrued as shell commands. Update To give you an example of how the permission bits are hard-coded into the standard utilities. Here are some relevant lines from two files in the coreutils package that contains the source code for both and , among others: touch(1) mkdir(1) : mkdir.c (specified_mode) { (!change) error (EXIT_FAILURE, , _( ), quote (specified_mode)); options.mode = mode_adjust ( S_IRWXUGO, , umask_value, change, &options.mode_bits ); (change); } options.mode = S_IRWXUGO & ~umask_value; } if * = ( ); struct mode_change change mode_compile specified_mode if 0 "invalid mode %s" true free else In other words, if the mode is not specified, set it to (read: ) modified by the umask_value. S_IRWXUGO 0777 is even clearer: touch.c default_permissions = S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH; int That is, give read and write permissions to everyone (read: ), which will be modified by the process umask on file creation, of course. 0666 You may be able to get around this programmatically only: i.e. while creating files from within either a C program, where you make the system calls directly or from within a language that allows you to make a low-level syscall (see for example Perl's sysopen under perldoc -f sysopen).
