On Mon, Jan 10, 2011 at 1:03 AM, Bob Proulx <[email protected]> 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
