Can files be created with permissions set on the command line?
Solution 1
You could use the install
command (part of GNU coreutils) with a dummy file, e.g.
install -b -m 755 /dev/null newfile
The -b
option backs up newfile
if it already exists. You can use this command to set the owner as well.
Solution 2
touch
always creates the file if it doesn't exist, always follows symbolic links, and always makes the file non-executable. You can decide the read and write bits through the umask.
(umask 077; touch file) # creates a 600 (rw-------) file
(umask 002; touch file) # creates a 664 (rw-rw-r--) file
“Safe” atomic file creation (in particular, with O_NOFOLLOW
) is not possible with traditional shell tools. You can use sysopen
in perl. If you have the BSD-inspired mktemp
utility, it creates a file atomically with O_NOFOLLOW
; you'll have to to call chmod
afterwards if the default mode of 600 is not the right one.
Solution 3
Building on @teppic's answer, if you want to create the file with content and mode at the same time (bash):
install -m 755 <(echo commands go here) newscript
<()
places the output into a temporary file, see Process-Substitution
quornian
Updated on September 18, 2022Comments
-
quornian almost 2 years
When creating directories,
mkdir -m <mode> <dir>
provides for creating one or more directories with the given mode/permissions set (atomically).Is there an equivalent for creating files, on the command line?
Something akin to:
open("file", O_WRONLY | O_APPEND | O_CREAT, 0777);
Is using
touch
followed by achmod
my only option here?
Edit: After trying out teppic's suggestion to use
install
, I ran it throughstrace
to see how close to atomic it was. The answer is, not very:$ strace install -m 777 /dev/null newfile ... open("newfile", O_WRONLY|O_CREAT|O_EXCL, 0666) = 4 fstat(4, {st_mode=S_IFREG|0666, st_size=0, ...}) = 0 ... fchmod(4, 0600) = 0 close(4) = 0 ... chmod("newfile", 0777) = 0 ...
Still, it's a single shell command and one I didn't know before.
-
jordanm almost 12 yearsI was in the process of writing out a more detailed explanation, but the wikipedia articles covers everything just fine.
-
quornian almost 12 years+1 for introducing me to
install
-
quornian almost 12 yearsIf only
touch
had the option of creating executable files, that's really what I'm after. Thenumask
could be used to tailor the details. Sadly there is no way withumask
andtouch
to create executables. -
Gilles 'SO- stop being evil' almost 12 years@quornian You can't create a non-empty file atomically anyway. What's the point of creating an empty executable file atomically? Use
touch
followed bychmod +x
. -
Partap almost 12 yearsIt's a useful little command. As its name suggests it's really designed for installing software compiled from source code, to save having to use chmod, chown, and so forth all the time.
-
Stéphane Chazelas almost 12 yearsYou can create non-empty, executables files atomically with... ln or mv. You can always create the file with the right content and permissions in a directory created with umask 077 and move it or ln it afterwards.
-
ceving almost 8 yearsYou likely did not understand the question. This is exactly what the questioner tries to avoid.
-
Lenotre over 7 yearsIf only it took stdin! OK, /proc/self/fd/0 will do for my purpose.
-
Kusalananda over 4 yearsNote that mode 755 is the default permissions of files created with
install
, so-m 755
is not needed. -
Partap over 4 years@Kusalananda It's obviously just an example of how to set a mode, since that was the question, not how to set 755.
-
dimo414 about 4 years@proski another option is a process substitution;
install -b -m 755 <(echo contents) newfile
worked for me. -
user1469306 almost 4 years+1 for mktemp; works for me!
-
nh2 over 2 years
install
does not atomically create files with the given permissions. It callsfchmod()
separately. An unauthorised user may open the file between the creation and the permissions change, thus it possible to read contents later that they are not allowed to read (e.g. for a private key file). Thusinstall
should not be used if file permission security is important. (This was edited into the question, but I think it's good to state it under this answer since it's currently marked accepted despite not fulfilling the requested "atomic" requirement.)