From: Pavel Shilovsky <piastry-7qunaywFIewox3rIn2DAYQ@public.gmane.org>
To: Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Subject: Re: [PATCH 0/2] Shared flags
Date: Sun, 16 Nov 2008 08:57:18 +0300 [thread overview]
Message-ID: <200811160857.18558.piastry@etersoft.ru> (raw)
In-Reply-To: <20081115113938.GA26576-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
I think that it'll be interesting for others filesystems. Also I should
say that solution with mounting options let us increase usual
possibilities to organize access policy. If you need it, you switch it
on, if don't (like in example) you simply don't use it! In conclusion,
we have increased functionality without any troubles.
Also, I should say that share flags is necessary for working with wine,
because NTCreateFile use it...
On Saturday 15 November 2008 14:39:38 you wrote:
> On Fri, Nov 14, 2008 at 03:37:12AM +0000, Jamie Lokier wrote:
> > 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2008-11-16 5:57 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <49183DF9.9010003@etersoft.ru>
[not found] ` <49183DF9.9010003-7qunaywFIewox3rIn2DAYQ@public.gmane.org>
2008-11-11 8:52 ` [PATCH 0/2] Shared flags Christoph Hellwig
2008-11-11 10:09 ` Jamie Lokier
2008-11-11 11:14 ` Christoph Hellwig
2008-11-13 10:08 ` Pavel Shilovsky
[not found] ` <491BFCBA.80208-7qunaywFIewox3rIn2DAYQ@public.gmane.org>
2008-11-13 9:25 ` Christoph Hellwig
2008-11-14 3:37 ` Jamie Lokier
2008-11-15 11:39 ` Christoph Hellwig
[not found] ` <20081115113938.GA26576-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2008-11-16 5:57 ` Pavel Shilovsky [this message]
[not found] ` <20081113092554.GA3004-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2008-11-16 10:37 ` Benny Halevy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200811160857.18558.piastry@etersoft.ru \
--to=piastry-7qunaywfiewox3rin2dayq@public.gmane.org \
--cc=hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).