Re: [Ocfs2-devel] [PATCH 1/3] fs: Document the reflink(2) system call.

[Jamie Lokier <jamie@shareable.org>]

jim owens wrote:
> >One last annoyance.  If you're making a new file, then like open() you
> >need another argument, which is the new file's mode which is combined
> >with umask.
> 
> But that only works for minimal traditional permissions.  If you
> want to adjust ACL or MAC, you need to do something else anyway,
> so is it really worth having the old-style mode parameter?

You have a point, and mode+umask is sort of ugly, but:

ACLs and MACs have are intentionally designed so that in 99.9% of
cases, there is no need to do anything else after open(), even in
programs that use different mode arguments for security and don't know
anything about non-traditional permissions.  So very few apps need to
do anything else afterwards.  The ACL/MAC defaults have been carefully
designed to have the right security properties, and people writing
security policies understand how that works.

The most often used mode parameters are almost certainly 0666 meaning
"use what umask says", and 0600 meaning "most restricted useful
permissions" for a new file.

If you want to create a file with restricted permissions without
altering umask, which isn't safe in a threaded program, you must _not_
use 0666 _and then_ narrow the permissions - it's important that the
initial permissions are <= the final ones that you need.

So without the parameter, what's the sane default?

For typical cowlink uses it should be equivalent to open(...,0666) as
you don't want to umask+chmod afterwards.  I wouldn't be surprised if
umask+chmod afterwards gave different ACL/MAC results.

But if you need restricted permission on the file afterwards, since
it's not safe to start wide and then narrow, 0666 is not a suitable
default.

You could say "just change the umask!" but that is bad in a threaded
program, unfortunately.  (Imho they should have made umask
thread-specific; oh well.  In fact you emulate per-thread umask by
adjusting the mode argument in some environments :-)

The mode argument, though ugly, is at least well understood and
security policies (inside apps and outside) do the right thing with it.

-- Jamie