All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kurt Hackel <Kurt.Hackel@oracle.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] Invalid file rights
Date: Tue Aug  3 21:42:00 2004	[thread overview]
Message-ID: <20040804024152.GA23992@ca2.us.oracle.com> (raw)
In-Reply-To: <B44D37711ED29844BEA67908EAF36F037BB933@pdsmsx401.ccr.corp.intel.com>

Yeah I think this is why libc provides...
       int open(const char *pathname, int flags);
       int open(const char *pathname, int flags, mode_t mode);

That "overloaded" open with the mode is only used for the O_CREAT case. 

Thanks!
-kurt

On Wed, Aug 04, 2004 at 09:51:20AM +0800, Chen, Yukun wrote:
> Yeah. You are right.
> 
> I take it for granted that a file will be granted some default rights for its owner, such as read/write, when it is created with open(...,...|O_CREAT) .
> I traced the source code of ocfs2 and found the kernel return a mode 8000 really that means nobody can access the file. Also, I checked it with ext3 filesystem and got the same results.
> 
> So, I think it is nature and it is not a bug yet.
> Thanx.
> 
> Aaron
> 
> -----Original Message-----
> From: Mark Fasheh [mailto:mark.fasheh@oracle.com] 
> Sent: 2004??8??4?? 2:49
> To: Chen, Yukun
> Cc: ocfs2-devel@oss.oracle.com
> Subject: Re: [Ocfs2-devel] Invalid file rights
> 
> On Tue, Aug 03, 2004 at 03:25:42PM +0800, Chen, Yukun wrote:
> > Hi All
> > 
> > I find a file rights bug on kernel 2.4 with svn 1313 code. Steps to
> > duplicate
> > 
> > Being root, create a file in a ocfs2 partition with the sentence below
> > 
> >  open(filename, O_CREAT | O_RDWR )
> > 
> > Then the file will be created with a right 000 --- nobody can write/read
> > it at all. 
> Right, and we get the mode from the kernel for this, right? Is there some
> policy which we're missing? In ocfs_mknod_locked we do "fe->i_mode = mode;"
> so it's definitely being set on disk. later on we also do "inode->i_mode =
> mode;".
> 
> > But, if I use "touch filename" , the file will be created with a right
> > of 644.
> Well, that'd be because:
> 
> [mfasheh@expo ocfs2]$ strace touch file
> <snip>
> open("file", O_WRONLY|O_NONBLOCK|O_CREAT|O_NOCTTY|O_LARGEFILE, 0666) = 3
> <snip>
> 
> So that's "touch" setting the mode there.
>  
> > Any ideas on it? (a bug # 113 has been reported to oss.oracle.com
> > bugzilla)
> So the "touch" case is obvious, but I'm not sure that the 1st one is a bug
> either... If it is, please explain why.
> 	--Mark
> 
> --
> Mark Fasheh
> Software Developer, Oracle Corp
> mark.fasheh@oracle.com
> _______________________________________________
> Ocfs2-devel mailing list
> Ocfs2-devel@oss.oracle.com
> http://oss.oracle.com/mailman/listinfo/ocfs2-devel

  reply	other threads:[~2004-08-03 21:42 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-03 20:51 [Ocfs2-devel] Invalid file rights Chen, Yukun
2004-08-03 21:42 ` Kurt Hackel [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-08-03  2:25 Chen, Yukun
2004-08-03 13:49 ` Mark Fasheh

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=20040804024152.GA23992@ca2.us.oracle.com \
    --to=kurt.hackel@oracle.com \
    --cc=ocfs2-devel@oss.oracle.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.