coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [coreutils] RFC for adding file creation mode feature into touch uti


From: Eric Blake
Subject: Re: [coreutils] RFC for adding file creation mode feature into touch utility.
Date: Fri, 07 Jan 2011 09:39:02 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.7

On 01/07/2011 09:23 AM, Pádraig Brady wrote:
>> Hmm - mkdir already supports -m/--mode, so it does sound like making
>> touch support the same option might be a useful enhancement.  Of course,
>> if the file exists, the --mode option would be ignored.  And POSIX
>> requires that if the --mode option is not provided but a file is
>> created, that the file have mode 0666 as modified by umask.  We can't
>> use -m, though (POSIX already requires it for mtime).
> 
> Why does mkdir have this option rather than relying on umask?
> My guess is to close security races with sticky bits etc.
> and that creating a file will not have the same issues?

mkdir has -m because POSIX requires it; also, you are right that the
setup of 'mkdir -p -m' creates a hierarchy where you want the
permissions to be set correctly for the entire set for race avoidance.
But touch does not create hierarchies.

> 
> ...
>> I'm 70:30 for adding this idea, and it's rather simple to do, as well
>> (would still need doc, NEWS, and test additions).
> 
> I'm a little less enthused to diverge from POSIX for this.

It's not diverging from POSIX, so much as adding an extension.  It all
boils down to whether the extension would prove useful, and whether it
can optimize work flows faster than any existing alternative that gets
the same end result but with more steps.  But thinking about it more,
I'd rather use just the long-option --mode rather than burn a short
option -M (or any other).

As for creating a file with +x or with 07000 permissions already added,
why?  Creating an empty file as already executable or setuid doesn't
make much sense (the empty file will be a nop); why not wait until the
file has final executable contents before adding +x or special
permissions later?  So, that leaves only permissions matching of a
reference file (and recent GNU cp already supports that), or restricting
permissions less than touch's default of 0666 (but touch honors umask,
so just modify your umask before touch), neither of which need a chmod
after the fact, nor a --mode argument to touch.

What would really clinch the deal is if any other touch implementation
out there already has something like this.  But off the top of my head,
I don't know of any (neither FreeBSD nor Solaris touch provides anything
like this).  So I guess I'm now 50:50 (undecided on whether the
extension makes sense without more evidence of its usefulness).

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]