From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shaya Potter Subject: Re: badly authored udf file systems Date: Thu, 02 Dec 2004 08:22:26 -0500 Message-ID: <1101993746.10477.13.camel@localhost.localdomain> References: <1101957150.5405.9.camel@localhost.localdomain> <20041202100308.GA14567@mail.shareable.org> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Linux Filesystem Development Return-path: Received: from 152-241-234-66.cosmoweb.net ([66.234.241.152]:64661 "HELO yucs.org") by vger.kernel.org with SMTP id S261618AbULBNW3 (ORCPT ); Thu, 2 Dec 2004 08:22:29 -0500 To: Jamie Lokier In-Reply-To: <20041202100308.GA14567@mail.shareable.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.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. ---