Sorry for the typo in the package name.

Le primidi 1er floréal, an CCXIV, Stephen Gran a écrit :
> I do not like the idea of umask turned off, frankly.  I can, in the
> general sense, see the idea of public copies by default as opposed to
> private copies by default (although I don't like it), but ignoring user
> set umask is more of a surprise than the current arrangement.  What
> exactly are you looking for here?

I believe there is a small misunderstanding, and I was probably not clear
enough. I did not want to override the umask, just let it do its work.
People who want high privacy, and among other things private copies, set
their umask to 077; people who are more liberal about their data and want
public copies set it to 022, or maybe 002 if they use user groups.

To let the umask do its work, software must call file-creating system calls
(mainly mkdir and open/O_CREAT) with the maximum permissions (666 or 777):
the kernel applies the umask on top of these permissions to get the correct
result.

For example:

she-seel /tmp $ umask 
022
she-seel /tmp $ strace -e open sh -c 'echo foo > bar'
open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/lib/libc.so.6", O_RDONLY)        = 3
open("bar", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
she-seel /tmp $ ls -l bar 
-rw-r--r--  1 cigaes cigaes 4 Apr 20 02:20 bar

<rant>

I have accounts on multiuser systems where most of the users (at least those
with whom I interact) have a policy of mainly public homes and data. In this
context, we often say something like "this file is on my account, you can
look at it". If an application thinks it knows better than me and have
created that file with paranoid permissions, it is a big waste of time.

It can be even worse with group-based access to a CVS repository: in this
case, the files and directories belong to a specific group, the directories
are set-group-id, and the users are expected to have a 002 umask to leave
the files writeable. If a directory becomes non-group-writeable, it can be a
big waste of time for the whole team.

</rant>

Regards,

-- 
  Nicolas George

Attachment: signature.asc
Description: Digital signature

Reply via email to