Shared flags

Hello!
We have situation during our work with Wine and Cifs-client then we have to use sharing access policy to files and we used 3 free bits from 21 to 23 of attribute flag(it allows to do NT-semantic for opening files in open() and it is necessary for correct implementation of function NTCreateFile in Wine). We think that it'll be useful not only for us and we proffer to add into the file kernel/include/asm-generic/fcntl.h following flags:

#define O_DENYREAD 004000000 /* Do not permit read access */
#define O_DENYWRITE 010000000 /* Do not permit write access */
#define O_DENYDELETE 020000000 /* Do not permit delete or rename operations*/

Quoted 3 lines · Pavel Shilovsky

#define O_DENYREAD 004000000 /* Do not permit read access */
#define O_DENYWRITE 010000000 /* Do not permit write access */
#define O_DENYDELETE 020000000 /* Do not permit delete or rename operations*/

(2) you also need to enforce these semantics in the VFS for local filesystems

Now if (2) doesn't cause too much overhead I would say it's fine, if not I would rather avoid it.

Quoted 8 lines · Christoph Hellwig

Quoted 3 lines · Pavel Shilovsky

#define O_DENYREAD 004000000 /* Do not permit read access */
#define O_DENYWRITE 010000000 /* Do not permit write access */
#define O_DENYDELETE 020000000 /* Do not permit delete or rename operations*/

(2) you also need to enforce these semantics in the VFS for local filesystems

Quoted 2 lines

Now if (2) doesn't cause too much overhead I would say it's fine, if not I would rather avoid it.

On the face of it, they look like they have similar denial-of-service potential as mandatory locks. For example, a root process cleaning out /tmp gets stuck because a user process has O_DENYDELETE set.

Quoted 14 lines · Jamie Lokier

Quoted 12 lines · Christoph Hellwig

Quoted 4 lines · Pavel Shilovsky

#define O_DENYREAD 004000000 /* Do not permit read access */
#define O_DENYWRITE 010000000 /* Do not permit write access */
#define O_DENYDELETE 020000000 /* Do not permit delete or rename operations*/

(2) you also need to enforce these semantics in the VFS for local filesystems

Now if (2) doesn't cause too much overhead I would say it's fine, if not I would rather avoid it.

Quoted 4 lines

On the face of it, they look like they have similar denial-of-service potential as mandatory locks. For example, a root process cleaning out /tmp gets stuck because a user process has O_DENYDELETE set.

Oh, that's the part I forgot to mention in the previous mail, all of these option of course can only be root only, everything else would be - as you say - a complete security nightmare.

We suggest to switch on this flags with special options during mounting. By default, it'll be switch off.
This solution deletes possibility of such situations, like in example.

Quoted 3 lines · Pavel Shilovsky

We suggest to switch on this flags with special options during mounting. By default, it'll be switch off.
This solution deletes possibility of such situations, like in example.

Sorry, having completely weird open modes only for one filesystem, and only depending on mount options is not very nice to the user.

And options or not allowing the above functionality for regular users is a security issue.

A generic mount option is currently used for mandatory locking - this is very similar.

The only different I see, for security, is with mandatory locking a process which doesn't want to get stuck can check the permission bits before opening a file. But I'm not aware of anything actually doing this.

Quoted 7 lines · Jamie Lokier

A generic mount option is currently used for mandatory locking - this is very similar.

The only different I see, for security, is with mandatory locking a process which doesn't want to get stuck can check the permission bits before opening a file. But I'm not aware of anything actually doing this.

More importantly the admin can do it. And mandatory locking doesn't mean you can't remove something, with would be a complete nightmare. It also doesn't apply to directories, which from my reading of the patch this one would do. But yeah, doing the read/write part as as a special case of mandlock on open might make some sense, but I'm still not too convinced.

That more I think about these option the less I like the idea, it's just going to cause a lot of problems to help with some wine issues that hasn't even been explained yet.

Quoted 7 lines · Jamie Lokier

A generic mount option is currently used for mandatory locking - this is very similar.

The only different I see, for security, is with mandatory locking a process which doesn't want to get stuck can check the permission bits before opening a file. But I'm not aware of anything actually doing this.

More importantly the admin can do it. And mandatory locking doesn't mean you can't remove something, with would be a complete nightmare. It also doesn't apply to directories, which from my reading of the patch this one would do. But yeah, doing the read/write part as as a special case of mandlock on open might make some sense, but I'm still not too convinced.

That more I think about these option the less I like the idea, it's just going to cause a lot of problems to help with some wine issues that hasn't even been explained yet.

Quoted 3 lines · Pavel Shilovsky

We suggest to switch on this flags with special options during mounting. By default, it'll be switch off.
This solution deletes possibility of such situations, like in example.

Sorry, having completely weird open modes only for one filesystem, and

only depending on mount options is not very nice to the user.

And options or not allowing the above functionality for regular users is a security issue.

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html