From: Shaya Potter <spotter@cs.columbia.edu>
To: Jamie Lokier <jamie@shareable.org>
Cc: Linux Filesystem Development <linux-fsdevel@vger.kernel.org>
Subject: Re: badly authored udf file systems
Date: Thu, 02 Dec 2004 08:22:26 -0500 [thread overview]
Message-ID: <1101993746.10477.13.camel@localhost.localdomain> (raw)
In-Reply-To: <20041202100308.GA14567@mail.shareable.org>
On Thu, 2004-12-02 at 10:03 +0000, Jamie Lokier wrote:
> Shaya Potter wrote:
> > in looking at the ecma spec
> > (http://www.ecma-international.org/publications/standards/Ecma-167.htm)
> > and section 4/14.9 where the file entry record is discussed, it shows
> > that the permission scheme sort of mirrors unix (i.e. owner, group,
> > other and read/write/execute bits). However, the spec is ambigious
> > because when it refers to the execute bit, it doesn't talk about
> > directories at all. In normal unix, of course one needs the execute bit
> > set, however, its probable other systems dont have such a semantic and
> > hence buggy dvd authoring programs on those platforms don't check for
> > it.
> >
> > Would it be useful to have a file system option to specify something
> > along the lines "buggy_dvd" which automatically gives all directories a
> > 0x111 bump?
>
> If the spec doesn't talk about directory execute permissions at all,
> and it looks like that is intended, then shouldn't the 0x111 bump be
> done all the time for UDF? More exactly, adding execute permissions
> corresponding to whichever read permissions are set.
perhaps, I didn't read through the entire spec, so don't know if
directory permissions are covered elsewhere (though a search of the pdf
for "directory permission" didn't find anything), just the part talking
about permissions.
specifically
---
14.9.5 Permissions (BP 44)
This field shall specify the access allowed to the current file for
certain classes of users as follows:
- If the user's user ID is the same as the Uid field, then bits 10-14
shall apply.
- Otherwise, if the user's group ID is the same as the Gid field, then
bits 5-9 shall apply.
- Otherwise, bits 0-4 shall apply.
Bit 0 = Other: If set to ZERO, shall mean that the user may not execute
the file; If set to ONE, shall mean that
....
Bit 5 = Group: If set to ZERO, shall mean that the user may not execute
the file; If set to ONE, shall mean that the user may execute the file.
....
Bit 10 = Owner: If set to ZERO, shall mean that the user may not execute
the file; If set to ONE, shall mean that the user may execute the file.
---
with the following note
---
Note 27
File access schemes are subject to agreement between the originator and
recipient of the medium as the meanings of both user IDs and group IDs
are implementation dependent; indeed, the permission and file access
models of the receiving and originating systems may be incompatible.
The question of how to interpret permissions on systems which do not
support user IDs and group IDs is outside the scope of Part 4. However,
if a system uses the Uid, Gid and Permissions fields, it is recommended
that such systems use and set all three (owner, group, other) sets of
permissions. It is also recommended that the Uid, Gid and Permissions
fields be mapped to the appropriate fields in the implementation.
---
prev parent reply other threads:[~2004-12-02 13:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-02 3:12 badly authored udf file systems Shaya Potter
2004-12-02 10:03 ` Jamie Lokier
2004-12-02 13:22 ` Shaya Potter [this message]
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=1101993746.10477.13.camel@localhost.localdomain \
--to=spotter@cs.columbia.edu \
--cc=jamie@shareable.org \
--cc=linux-fsdevel@vger.kernel.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).