[nfsv4] Re: Comments for draft-rmacklem-nfsv4-posix-acls-02

[Pali Rohár <[e-mail]>]

On Friday 09 August 2024 13:44:12 Rick Macklem wrote:
> On Fri, Aug 9, 2024 at 9:45 AM Pali Rohár <[e-mail]>
> wrote:
> 
> > On Wednesday 07 August 2024 13:23:40 Rick Macklem wrote:
> > > On Wed, Aug 7, 2024 at 9:22 AM Pali Rohár <[e-mail]>
> > > wrote:
> > >
> > > > Hello Rick, I'm sending comments for the second part of your email.
> > > >
> > > > On Tuesday 06 August 2024 15:20:50 Rick Macklem wrote:
> > > > > On Tue, Aug 6, 2024 at 10:05 AM Pali Rohár <
> > [e-mail]
> > > > >
> > > > > wrote:
> > > > > > > A server that is configured for a acl_trueform_scope other that
> > > > > > > ACL_SCOPE_FILE_OBJECT MUST not support the posix_default_acl and
> > > > > > > posix_access_acl unless the true form for the file system is
> > > > > > > ACL_MODEL_POSIX_DRAFT.
> > > > > >
> > > > > > This is a restriction which basically means that no existing NFS4
> > > > > > server with native NFS4 ACL support can support "posix_access_acl".
> > > > > > In multiprotocol environment where is NFSv4.0 and NFSv4.1, the NFS4
> > > > > > server would have to provide server scope native NFS4 model (to
> > support
> > > > > > NFSv4.1 as as your document is only for NFSv4.2) which implies that
> > > > > > server must not support POSIX ACL. And same applies in the
> > > > multiprotocol
> > > > > > environment with NFS4 and SMB.
> > > > > >
> > > > > Not exactly. posix_access_acl refers to the proposed optional
> > > > > attribute for NFSv4.2 (same goes for acl_trueform_scope).
> > > > > What the server does w.r.t. "true form" is up to the server.
> > > > > Same goes for the scope of it.
> > > > > (For example, Linux server always use POSIX draft ACLs.)
> > > > >
> > > > > The difference is that NFSv4.0 and 4.1 clients cannot know
> > > > > what the "true form" is and can only see NFSv4 ACLs (possibly
> > > > > mapped to/from POSIX draft ACLs).
> > > > >
> > > > > What the above restriction is meant to do is allow a NFSv4.2
> > > > > client to know that the "true form" is ACL_MODEL_POSIX_DRAFT
> > > > > when the scope is ACL_SCOPE_FILE_SYSTEM or ACL_SCOPE_SERVER
> > > > > by seeing that posix_access_acl and posix_default_acl are
> > > > > supported_attrs for the file system.
> > > > > --> Note that acl_trueform_scope is "per server", so a client
> > > > >     only needs to GETATTR this attribute once for the server.
> > > > >     Then, if that is ACL_SCOPE_FILE_SYSTEM or ACL_SCOPE_SERVER,
> > > > >     it can tell that the "true form" is ACL_MODEL_POSIX_DRAFT
> > > > >     as soon as it sees posix_access_acl and posix_default_acl
> > > > >     in supported_attrs.
> > > > >     --> It does not have to bother to check acl_trueform,
> > > > >         which would often result in an extra RPC.
> > > >
> > > > Ok, I will try to describe this issue in different way on example.
> > > >
> > > > NFS4 client can decide that will not implement support for ACL and DACL
> > > > attributes because, NFS4 client is POSIX only and mapping from NFS4 to
> > > > POSIX cause issues for that client.
> > > >
> > > > NFS4 client will implement this extension, so it would understand only
> > > > POSIX_ACCESS_ACL and POSIX_DEFAULT_ACL attributes.
> > > >
> > > > There are existing NFS4 server which implements multiprotocol
> > > > environment. Such server would always use NFS4 true form ACLs and
> > > > nothing different (for example because POSIX ACL cannot store SMB
> > ACLs).
> > > > So such server would return for acl_trueform_scope ACL_SCOPE_SERVER (or
> > > > ACL_SCOPE_FILE_SYSTEM in case server supports more filesystems and want
> > > > such feature).
> > > >
> > > > Now according to your description, such server "MUST not support the
> > > > posix_default_acl and posix_access_acl" (because its true form is
> > NFS4).
> > > >
> > > > So it means for NFS4 clients which would implement only
> > POSIX_ACCESS_ACL
> > > > and POSIX_DEFAULT_ACL attributes, those NFS4 servers are not able to
> > > > serve any ACL.
> > > >
> > > Yes, exactly what I intend. If the server only uses a true form of
> > > NFSv4 it cannot support the posix_access_acl and posix_default_acl
> > > attributes.
> >
> > Server can implement mapping and in above example I described what can
> > be the common situation.
> >
> > > Trying to support them via mapping has not worked (and as far as I
> > > am concerned will never work).
> >
> > I do not say that it has not worked. For example netapp server's mapping
> > between all ACL models looks to work fine. It is not ideal but generally
> > works. Maybe this is quite different scenario, applies here for this
> > extension. Because you can set ACL via protocol A (in model A) and then
> > retrieve it via protocol B (in model B).
> >
> > > Whether or not this draft is accepted by the working group is up to
> > > the working group, but this is what I am proposing.
> > >
> > >
> > > > And if customers of such NFS4 server start asking for "ACL
> > compatibility
> > > > with that NFS4 client" then such NFS4 server would ignore the part
> > "MUST
> > > > not support the posix_default_acl and posix_access_acl" and will start
> > > > providing these attributes via some translation or mapping (it would be
> > > > even worse mess).
> > > >
> > > There are no RFC police, but I think the customers will find it more
> > useful
> > > to manipulate the NFSv4 ACLs on the server directly, instead of via
> > > some NFSv4<->POSIX ACL mapping exercise, from what I have seen (close
> > > to twenty years without much success when it comes to mapping between
> > > the two ACL models).
> > >
> > > For example, if the client were a Linux
> > > NFSv4 client, they could use the nfs4_setfacl and nfs4_getfacl commands
> > to
> > > manipulate the NFSv4 ACLs on the server. That is going to work a
> > > lot better for them than some potentially incorrect NFSv4<->POSIX
> > > mapping algorithm.
> > >
> > >
> > > > This is why I think it is too restrictive. It is disallowing NFS4
> > > > servers to provide compatibility for POSIX NFS4 clients.
> > > >
> > > I think it is better to encourage POSIX based NFSv4 clients
> > > to support setting/getting ACLs of both models.
> >
> > But for example Linux NFSv4 kernel client has not received NFSv4 ACL
> > support. And it does not look like that it will receive any kind of
> > support. Linux nfs4_setfacl/nfs4_getfacl commands are mostly just hacks,
> > this is not integrated into any ecosystem. Linux userspace application
> > mostly ignore existence of nfs4_setfacl/nfs4_getfacl commands. And I
> > have never seen in wild usage any NFSv4 ACL GUI (or CUI) editor.
> >
> Yep. And I doubt that will change any time soon. And Linux is
> the predominate client out there these days.
> 
> 
> > > For Linux, there are separate commands that handle the two
> > > models. It appears that the Linux NFS project is interested
> > > in implementing this extension, but I believe that the
> > > nfs4_setfacl/nfs4_getfacl commands for directly setting/getting
> > > NFSv4 ACLs will continue to be supported. (Of course, I cannot
> > > speak for them.)
> >
> > So if Linux NFSv4 client is going to implement this extension but not
> > the true NFSv4 ACLs then as I wrote above, NFSv4 servers for Linux
> > compatibility with high probability will ignore the requirement
> > "MUST not support the posix_default_acl and posix_access_acl".
> >
> > That why I think writing such strict MUST NOT requirement does not bring
> > any value.
> >
> That's not what it says, as far as I can see. It does state that for
> the case of ACL_SCOPE_FILE_OBJECT (which I doubt Linux will do,
> except maybe for IBM's GPFS), that if the "true form" is not
> ACL_MODEL_POSIX_DRAFT
> (which is highly unlikely), it must return a 0 length NFSv4 ACL for
> acl/dacl.
> --> I expect Linux knfsd servers to report a scope other than
>     ACL_SCOPE_FILE_OBJECT and a true form of ACL_MODEL_POSIX_DRAFT, so this
>     case will not apply.

Here I mean usage of Linux NFSv4 client with some non-Linux NFSv4
server. Not the Linux knfsd (it is really unlikely that knfsd would
provide non-POSIX ACL model).

> Maybe this should be reworded to say that, for the case of ACL_MODEL_NONE
> (which only happens for ACL_SCOPE_FILE_OBJECT), the posix_access_acl is
> returned 0 length (which is an invalid POSIX ACL).

This would be better. Express all POSIX ACL information only in new
(posix) attributes and let all existing ACL attributes to provide NFSv4
ACL information for backward compatibility with non-POSIX client.

For POSIX ACL model it is enough to figure current state of POSIX ACL
just from posix_access_acl and acl_trueform. So for example GET(dacl) by
some non-Linux NFS4 server can still provide mapped POSIX ACL.

> I'll think about this change.
> 
> It is difficult to decide exactly what the behaviour of the
> ACL_SCOPE_FILE_OBJECT
> is, since the only extant example is IBM's GPFS and I have no way of gaining
> hands on experience with it. (The documentation only gives me vague hints,
> since
> it is intended for users. It is difficult to tell when it switches true form
> between NFSv4 ACLs and POSIX ACLs, but I wanted this extension to be able to
> indicate that to a client, so that it could use the correct "true form".
> 
> Since I am just about to add a short section requiring (probably a SHOULD)
> the GETATTR for the ACL related attributes be atomic w.r.t. SETATTR of these
> attributes, the client should be able to acquire the acl_trueform attribute
> along with the others such that the others do not matter if they are mapped
> or invalid.

This is really a good idea.

> 
> > > For FreeBSD, they are both handled by the same commands, but
> > > with different options and syntax and I can assure you that
> > > FreeBSD will support setting/getting both ACL models. In fact,
> > > most FreeBSD servers export ZFS storage, which currently only
> > > supports the NFSv4 ACL model (for the FreeBSD port, the Linux
> > > port of OpenZFS supports the POSIX model).
> > >
> > > For Solaris, if I read the man page correctly, uses setfacl
> > > to set POSIX draft ACLs and chmod to set NFSv4 ACLs.
> > > (I cannot recall if Solaris supports NFSv4.2?)
> >
> > Basically Solaris setfacl was integrated into chmod. So on modern
> > Solaris systems you will use only chmod. But it does not matter what is
> > the name of system command. Solaris supports NFS v4.1 ACLs. I'm not
> > sure about NFS v4.2, I has not inspected it as this version has minor
> > usage.
> >
> > > The only other NFSv4 client for a POSIX like system I am
> > > aware of is Mac OSX and last time I looked, it was NFSv4.0 only.
> >
> > Yes, this Mac OS X client does not support NFSv4.1, only NFSv4.0
> > (in v4 series).
> >
> > Another POSIX systems which support NFSv4.0 but not NFSv4.1 are HP-UX
> > and IBM AIX.
> >
> > And there is multiplatform libnfs userspace library which is widely used
> > and has POSIX-like API. This library also does not support NFSv4.1, but
> > supports NFSv4.0 and NFSv3.
> >
> > >
> > > > >
> > > > > > I think that this is too strict and what would happen is either
> > that
> > > > > > this extension would not be implemented OR section option (which I
> > > > think
> > > > > > everybody would do) is ignoring this restriction.
> > > > > >
> > > > > As above, this does not define what the server does for NFSv4.0
> > > > > and NFSv4.1, it just simplifies what a NFSv4.2 client needs to
> > > > > check, if it knows about and the server supports the extension
> > > > > proposed by this draft.
> > > > >
> > > > > >
> > > > > > I guess that for compatibility with FreeBSD and Linux, servers
> > would
> > > > > > implement it even on NFS4 server scope model.
> > > > > >
> > > > > Not sure what you mean by this.
> > > >
> > > > I explained above the whole example. I did not mentioned in it explicit
> > > > client and servers as it nos tight to FreeBSD or Linux. Hopefully it
> > > > would be clear now what I mean.
> > > >
> > > I only mention Linux and FreeBSD servers as examples (and the only
> > > ones I have hands on experience with).
> > > However, I believe that Linux and FreeBSD are the only NFSv4.2
> > > client implementations for POSIX-like systems that currently exist,
> > > as discussed above.
> > >
> > >
> > > > > Linux always uses a "true form"
> > > > > of POSIX ACL and FreeBSD supports one of POSIX ACL or NFSv4 ACL
> > > > > on a per-file system basic (at least for now).
> > > > > - That is not changed by this extension. All this extension does
> > > > >   is allow NFSv4.2 clients to use the server more effectively
> > > > >   by choosing to get/set the "true form" and avoiding mapping,
> > > > >   assuming the client and server both implement the extension.
> > > > > Other file systems (IBM's GPFS seems to be the extant example
> > > > > I am aware of) also supports a "true form" on a per-file basis.
> > > > > (Again this is a server file system configuration choice and
> > > > > is not affected by whether or not this extension is supported
> > > > > by a NFSv4.2 server.)
> > > > >
> > > > >
> > > > > >
> > > > > > And I have there two additional points without quoting your
> > document.
> > > > > >
> > > > > > 1)
> > > > > >
> > > > > > Your document does not describe what existing RFC 8881 acl and dacl
> > > > > > attributes should return when user sets new "posix_default_acl" or
> > > > > > "posix_access_acl" attribute. Also what should happen when another
> > > > > > client tries to change acl or dacl attribute when POSIX ACL is
> > already
> > > > > > active.
> > > > > >
> > > > > The intent (if that is not clear, the words need to be improved)
> > > > > is that the server file system shall have one "true form" for each
> > > > > file object. If the attribute(s) for the other "true form" is used
> > > > > on the object (which assumes the server has chosen to put attributes
> > for
> > > > > both in supported_attrs for the file syetem, the
> > GETATTR/READIR/SETATTR
> > > > > will use mapping to translate it to/from the "true form".
> > > >
> > > > Ok, I think this is important to know and was not clear for me.
> > > > So it means that if server's true form is POSIX and NFS4 client call
> > > > GETATTR(DACL) command then server is required to map its POSIX ACL into
> > > > NFS4 ACL. I think that this should be explicitly mentioned to prevent
> > > > any confusion.
> > > >
> > > This is allowed, but not encouraged, by the draft. Again, mapping
> > > has not worked well. (A server can choose to not support the
> > acl/dacl/sacl
> > > attributes if it using a true form of POSIX and this is what this draft
> > > is meant to encourage.)
> >
> > I do not think that mapping has not worked well. There are examples of
> > servers where mapping is used in multiprotocol environment and it is
> > working for clients.
> >
> > Not supporting acl/dacl attribute but providing the access control list
> > support on the server is in my opinion the worst thing for existing
> > NFSv4 clients (existing are those which implement only RFC 8881 and no
> > other extension). They would not be aware why some user has additional
> > access and why not. This can be a problem also for admins or for audit
> > purposes that somebody accessed something to which should not have
> > access.
> 
> 
> > >
> > > > > The intent is to discourage use of mapping. As such, the client using
> > > > > these extensions can avoid that by determining what the "true form"
> > is
> > > > > for the object and using the appropriate attributes.
> > > >
> > > > Now I understand. So NFS4 client without this extension would use just
> > > > ACL and DACL attributes. And NFS4 client with this extension can use
> > > > POSIX_ACCESS_ACL if wants and can benefit from it.
> > > >
> > > Sort of. The intent is to encourage clients to use whatever attributes
> > > correspond to the true form of the ACLs on the server.
> > > Without this extension, the client's only option is using acl/dacl/sacl
> > > (whichever is supported by the server, if they are supported by the
> > server).
> > >
> > >
> > > > > My thinking is that servers like FreeBSD (where the "true form" is
> > > > per-file
> > > > > system and mapping is not supported) would:
> > > > > (A) - Support posix_access_acl and posix_default_acl, but not acl,
> > for
> > > > file
> > > > >   systems that use POSIX ACLs as their "true form".
> > > >
> > > > Why not ACL/DACL attribute at least via mapping? This will degrade NFS4
> > > > clients which use NFS4 true form ACL or similar (e.g. Windows or SMB).
> > > >
> > > > RFC 8881 suggest implementations to implement ACL and DACL attributes
> > > > for access control. So servers which will not implement ACL and DACL
> > > > attribute would for access control would not be compatible with RFC
> > 8881
> > > > clients which expects access control.
> > >
> > >
> > > > > (B) - Support acl, but not posix_access_acl and posix_default_acl,
> > for
> > > > file
> > > > >   systems that ise NFSv4 ACLs as their "true form".
> > > >
> > > > That makes sense. Export POSIX_ACCESS_ACL/POSIX_DEFAULT_ACL only in
> > case
> > > > POSIX is server's true form.
> > > >
> > > > > For Linux servers, they might choose (A) above, or they might choose
> > > > > to support all of acl, posix_access_acl and posix_default_acl, where
> > acl
> > > > > is supported via the mapping algorithms they already use.
> > > > >
> > > > > It is the case of a per-file scope where things get difficult:
> > > > > The server will probably want to support all of acl, posix_access_acl
> > > > > and posix_default_acl, but since the "true form" is defined a one
> > > > > model for each file, then how should the attribute(s) for the other
> > > > > model be handled?
> > > > > - I would like to avoid mapping, so I think being able to return
> > > > >   "no ACL" would be preferred.
> > > >
> > > > I think that this is against RFC 8881 where it is expected that server
> > > > construct ACL attribute which will describe the current access
> > > > permissions.
> > > >
> > > > Returning "no ACL" for NFS4 clients which do not understand this
> > > > extension would be very confusing. User will ask for ACL, user will see
> > > > that it is empty and would think that nobody has access to that file.
> > > > And then would be surprised that somebody can access that file just
> > > > because some optional extension attribute returns some more information
> > > > about access, which the client does not implement. This can lead also
> > to
> > > > security or audit issues.
> > > >
> > > That is a server implementation decision. I will simply say that
> > > clients will also be confused by mapped NFSv4 ACLs.
> >
> > I do not see why NFSv4 client (written according to RFC 8881) has to be
> > confused about NFSv4 ACL. NFSv4 ACL is part of the NFSv4 protocol.
> >
> > > Don't believe me. Well, set up a Linux server and try a NFSv4.1/4.2
> > > mount against it, using a client that can set/get NFSv4 ACLs.
> > > (FreeBSD or a Linux client with nfs4_setfacl/nfs4_getfacl installed
> > > on it.)
> >
> > Getting ACL of some file by nfs4_getfacl will print ACL for that file in
> > NFSv4 ACL format. What is being confusing on this? It looks like that
> > Linux server is converting its POSIX ACL to NFSv4 format on-the-fly and
> > looks to be correct. Personally I do not see a problem on confusion on
> > this step.
> >
> > You can even copy such file with ACL to another NFS4-ACL-compatible
> > storage and all access rights will be preserved (but in NFS4 ACL
> > format). So you can happily copy file on Windows system to local NTFS
> > filesystem, or similarly to ZFS.
> >
> > The issue is with SET operation, that ACEs configured by nfs4_setfacl
> > will result in slightly different ACL. But this is a problem of mapping
> > and it depends on how precisely would be backward translation
> > implemented. If it would cover the most common usage and most common use
> > cases, it would be fine. It looks like that Linux chose to implement
> > this translation in a way that it does not grant more permission than
> > what was in SETATTR(ACL) comment. I understand this decision for
> > security reasons.
> >
> > > Then, set/get some ACLs. I think you'll find the results "interesting"
> > > and understand how confusing it is for client users right now.
> >
> > But here with SET operation, I agree with you, that admin can be
> > confused. Admin tried to set ACL to something, but in reality slightly
> > different was returned back via GET operation.
> >
> > >
> > > > > - I had thought a zero length ACL would work for this, but that no
> > > > >   longer appears to be the case.
> > > >
> > > > Yes, it would not work.
> > > >
> > > > > Maybe, defining an ACL with a single ACE that says "not valid" would
> > > > > work?
> > > >
> > > > I think not. ACL and DACL attribute should always say current access
> > > > permissions for the object. And if server is using some other (e.g.
> > > > POSIX or any other strange scheme) then server should provide the best
> > > > effort translation for such clients.
> > >
> > >
> > > > > This could be the reply for GETATTR/READDIR and could be used to
> > > > > "erase" the ACL for SETATTR.
> > > > > --> I think this is what the next draft will propose.
> > > > >
> > > > >
> > > > > > If interop between mode, dacl and posix_default_acl,
> > posix_access_acl
> > > > > > attributes is not explicitly defined in specification then every
> > server
> > > > > > implementation will invent its own rules and it would just lead to
> > the
> > > > > > mess in multiprotocol environment where clients would not be sure
> > what
> > > > > > can happen. Like it is already with "mode" attribute in NFS v4.1
> > (see
> > > > 2).
> > > > > >
> > > > > For posix_access_acl and posix_default_acl the intent is that the
> > > > > POSIX draft specification defines the interaction between mode and
> > > > > the POSIX ACL.
> > > >
> > > > Ok. But the problem is that POSIX mode != NFS4 mode. Below in 2)
> > > > I described one difference. And because POSIX ACL does not define
> > > > interaction between NFS4 mode and POSIX ACL then I think it is required
> > > > to define it in extension specification to make it clear.
> > > >
> > > > > For NFSv4 ACLs, you are correct. It is a mess.
> > > > > And I wish David N. the best of luck w.r.t. cleaning it up.
> > > >
> > > > Interesting, is David working on cleaning it up? If you are interesting
> > > > I can provide feedback what needs to be fixed (something I have already
> > > > written in my first email to the list).
> > > >
> > > His draft can be found on the ietf datatracker.
> > >  https://datatracker.ietf.org/doc/draft-dnoveck-nfsv4-acls/
> > >
> > > In summary, we will agree to disagree with respect to the
> > > usefulness of mapping between NFSv4<->POSIX ACLs.
> > > You might want to look at:
> > > https://datatracker.ietf.org/doc/draft-ietf-nfsv4-acl-mapping/
> > > and also consider the case of a directory, where the POSIX default
> > > ACL and POSIX access ACL both exist and are not the same.
> > > Further, recall that POSIX only defines the three bits: r,w,x
> >
> > Ok, I can look at it. But this one looks to be a huge and is going to
> > radically update the things.
> >
> > I would like to know if issues which I brought in my first email to this
> > list could be addressed in this David's draft.
> >
> > > rick
> > >
> > >
> > > > > (OpenZFS already has a knob that specifies 4 different ways
> > > > > of doing this. Another knob setting may be needed.)
> > > > >
> > > > > Thanks for the comments, rick
> > > > >
> > > > > >
> > > > > > 2)
> > > > > >
> > > > > > Then there is a problem with "group" bits of "mode" attribute.
> > > > > > In RFC 8881 section 6.2.4 is written:
> > > > > >
> > > > > > "Bits MODE4_RGRP, MODE4_WGRP, and MODE4_XGRP apply to principals
> > > > > > identified in the owner_group attribute but who are not identified
> > in
> > > > > > the owner attribute."
> > > > > >
> > > > > > And in section 6.3.2.1 is written:
> > > > > >
> > > > > > "Some server implementations also add bits permitted to named
> > users and
> > > > > > groups to the group bits (MODE4_RGRP, MODE4_WGRP, and MODE4_XGRP).
> > > > > > Implementations are discouraged from doing this."
> > > > > > "The same user confusion seen when fetching the mode also results
> > if
> > > > > > setting the mode does not effectively control permissions for the
> > > > owner,
> > > > > > group, and other users; this motivates some of the requirements
> > that
> > > > > > follow."
> > > > > >
> > > > > > POSIX ACL with at least one named user or named group requires that
> > > > > > mode group bits refers to POSIX ACL mask, and not to the POSIX ACL
> > > > > > group_obj (which represents owner_group).
> > > > > >
> > > > > > Those RFC 8881 parts of NFS mode attribute are basically not
> > compatible
> > > > > > with POSIX ACL. Your extension does not mention this problem and
> > does
> > > > > > not handle it.
> > > > > >
> > > > > > Existing NFS4 servers which follows the RFC 8881 meaning of mode
> > group
> > > > > > bits, would not be able to implement this your extension for POSIX
> > ACL,
> > > > > > because existing servers cannot change behavior of mode attribute
> > due
> > > > > > backward compatibility. I think that this is a big problem.
> > > > > > Servers in multiprotocol environment mostly follows the RFC 8881
> > advice
> > > > > > to never return something like "POSIX mask" in group bits.
> > > > > >
> > > > > > How to solve this problem. One option could be including all mode
> > bits
> > > > > > into your new "posix_access_acl" attribute and let NFS4 clients to
> > use
> > > > > > only "posix_access_acl" on chown operation, and never use existing
> > > > > > "mode" attribute at all (if the extension is supported by server).
> > > > > >
> > > > > > Another option could be to introduce a new "posix_mode" attribute
> > which
> > > > > > would be strictly POSIX and old "mode" attribute can stay as
> > before for
> > > > > > backward compatibility. Again clients would not use "mode"
> > attribute
> > > > > > anymore.
> > > > > >
> > > > > >
> > > > > > Regards,
> > > > > > Pali
> > > > > >
> > > >
> >