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

[Rakib Mullick]

On Mon, Jan 10, 2011 at 1:03 AM, Bob Proulx <address@hidden> wrote:
> Rakib Mullick wrote:
>> Jim Meyering wrote:
>> > Why do you want an option for this when you can already use touch
>> > to create a file with selected permissions via your umask?
>>
>> I think umask change the the file creation mask system wide. I might
>> not want it for every file I create.
>
> No.  The umask only affects the current process.  It doesn't affect
> other processes system wide.  It will affect files created by the
> current process, but that is the point of it.
>
>> > If you say that you require an execute bit or some special bit to
>> > be set, please explain why.  I do not see how having such bits set
>> > on an empty file would be useful.  If you're about to add content,
>>
>> No. It's not just about setting an execute bit, say I might have
>> create a file with 'sudo touch filename', in that case I just can see
>> the file by doing 'cat filename' or 'vim filename'.
>
> In which case the file is zero sized.  Emitting the file with 'cat'
> would read a zero sized file.  But you wouldn't want to edit the file
> with 'editor filename'.  Since you specifically created it as a root
> owned file then the user would not have permissions to edit the file.
> And you wouldn't want to 'sudo editor filename' either because of the
> security implications.  You /may/ want to use 'sudoedit'.
>
Yes. To be more precise I want to give user the write permission, as
if he/she can do 'editor filename' and can edit and save.

>> So, again I need to do, 'sudo chmod xxx filename' to make it
>> available to its user. So, it can be summed up as:
>
> Please say exactly what mode bits you want to set.  That was the
> question asked in the last email.  Please don't say mode xxx but
> instead say exactly what mode bits you are talking about.
>
In my case, I needed to set write permission for the user. I tried to
tell it generically, that's why I used xxx.

> Because otherwise we have to imagine and guess.  I can only guess that
> you mean to make it unavailable, right?
>
>  $ sudo touch /tmp/afile
>  $ ls -l /tmp/afile
>  -rw-r--r-- 1 root root 0 Jan  9 11:48 /tmp/afile
>
> If you wanted to block it then you should need to chmod it.
>
>  $ sudo chmod go-rwx /tmp/afile
>  $ ls -l /tmp/afile
>  -rw------- 1 root root 0 Jan  9 11:48 /tmp/afile
>
>> (Assume, to create a file under /usr/src/work)
>>              sudo touch /usr/src/work/filename (to create a file)
>>              sudo chmod xxx /usr/src/work/filename (to give a user proper 
>> permission)
>
> Please say exactly what mode bits you want to set.
>
In my case, I wanted to set write mode. But, anyone might have wanted
to set other bit's.

> Because with the above touch you would have a root owned file.  The
> only way you could give a user permission to write to the file would
> be to open it up for global writing by any user.
>
>  $ sudo chmod ugo=rw /tmp/afile
>  $ ls -l /tmp/afile
>  -rw-rw-rw- 1 root root 0 Jan  9 11:48 /tmp/afile
>
> That is bad.  You do not want to do this.
>
Yes. I didn't want it.

>> After adding this feature we can do this:
>>             sudo touch --mode xxx /usr/src/work/filename
>> thats it.
>
> As I read your message you are saying you want to do:
>
>  sudo touch --mode ugo=rw /usr/src/work/filename
>
Maybe, yes. But, I might have want to set different permission in
different context.

> Instead of doing:
>
>  sudo touch /usr/src/work/filename
>  sudo chmod ugo=rw /usr/src/work/filename
>
> Just wishing to reduce two commands down to one command is not a good
> reason for doing this.
>
Yes. When other file creation utility could have one, then why not in touch?

> Secondly you don't want to make files writable by other just to share
> them.  That is bad.
>
> If you want to provide for a group of users to be able to share access
> to a file then you should use group permissions.  Create a work group
> for use by the group.  Make the directory owned and writable by the
> group.  Then when new files are created it will be owned by the group.
> There is no need to use sudo.  Just operate as a normal user.  For
> each user that is to have access to this group add that user to the
> group.
>
> This is a very short summary of the process.  Search the web for User
> Private Group and read about how Unix file group permissions enable
> this behavior natively.  I believe this is the concept that you should
> be using.
>
Thanks for your help. When things get changed, the way of doing things
also get changed. Since its not going to be changed, so I have to use
this concept. :)


thanks,
rakib