Indication of extended attributes availability.

HI,
I WOULD LIKE TO HAVE SOME SORT OF INDICATION OF EXTENDED
ATTRIBUTES 
AVAILABILITY FOR GIVEN FS. IT SEEMS THAT THINGS LIKE THIS
(MAC, ACLS ETC.) 
ARE INDICATED USING MOUNT FLAGS AND THOSE ARE AVAILABLE
THROUGH STATFS() 
CALL. THE FOLLOWING IS TENTATIVE PATCH THAT WOULD EXPOSE
EXTENDED ATTRIBUTES 
AVAILABILITY AS MOUNT FLAG. IT IS COMPLETELY UNTESTED. I
WOULD JUST LIKE TO 
KNOW IF IT IS A VIABLE APPROACH TO THE PROBLEM OR SHOULD I
SCRATCH IT AND TRY 
SOMETHING ELSE?


--- ./SYS/MOUNT.H~	2007-04-10 12:12:44.000000000 +0200
+++ ./SYS/MOUNT.H	2008-03-21 22:48:04.436630277 +0100
 -218,7
+218,6  VOID          __MNT_VNODE_MARKERFREE(STR
  #DEFINE	MNT_SYNCHRONOUS	0X00000002	/* FILESYSTEM WRITTEN
SYNCHRONOUSLY */
  #DEFINE	MNT_NOEXEC	0X00000004	/* CAN'T EXEC FROM
FILESYSTEM */
  #DEFINE	MNT_NOSUID	0X00000008	/* DON'T HONOR SETUID BITS
ON FS */
-#DEFINE	MNT_NODEV	0		/* DEPRECATED OPTION */
  #DEFINE	MNT_UNION	0X00000020	/* UNION WITH UNDERLYING
FILESYSTEM */
  #DEFINE	MNT_ASYNC	0X00000040	/* FILESYSTEM WRITTEN
ASYNCHRONOUSLY */
  #DEFINE	MNT_SUIDDIR	0X00100000	/* SPECIAL HANDLING OF SUID
ON DIRS */
 -246,6
+245,7  VOID          __MNT_VNODE_MARKERFREE(STR
   * BUT VISIBLE TO THE USER.
   * XXX SOME OF THESE ARE NOT QUITE RIGHT.. (I'VE NEVER
SEEN THE ROOT FLAG SET)
   */
+#DEFINE MNT_EXTATTR	0X00000010	/* FILESYSTEM WITH EXTENDED
ATTRIBUTES */
  #DEFINE	MNT_LOCAL	0X00001000	/* FILESYSTEM IS STORED
LOCALLY */
  #DEFINE	MNT_QUOTA	0X00002000	/* QUOTAS ARE ENABLED ON
FILESYSTEM */
  #DEFINE	MNT_ROOTFS	0X00004000	/* IDENTIFIES THE ROOT
FILESYSTEM */
 -265,7
+265,8  VOID          __MNT_VNODE_MARKERFREE(STR
  			MNT_ROOTFS	| MNT_NOATIME	| MNT_NOCLUSTERR| 
  			MNT_NOCLUSTERW	| MNT_SUIDDIR	| MNT_SOFTDEP	| 
  			MNT_IGNORE	| MNT_EXPUBLIC	| MNT_NOSYMFOLLOW | 
-			MNT_JAILDEVFS	| MNT_MULTILABEL | MNT_ACLS)
+			MNT_JAILDEVFS	| MNT_MULTILABEL | MNT_ACLS     | 
+			MNT_EXTATTR)

  /* MASK OF FLAGS THAT CAN BE UPDATED. */
  #DEFINE	MNT_UPDATEMASK (MNT_NOSUID	| MNT_NOEXEC	| 
--- ./UFS/UFS/UFS_EXTATTR.C~	2006-03-13 04:08:08.000000000
+0100
+++ ./UFS/UFS/UFS_EXTATTR.C	2008-03-21 22:59:50.766939565
+0100
 -220,6
+220,10  UFS_EXTATTR_START(STRUCT MOUNT *MP, STRU

  	UMP->UM_EXTATTR.UEPM_UCRED = CRHOLD(TD->TD_UCRED);

+	MNT_ILOCK(MP);
+	MP->F_FLAGS |= MNT_EXTATTR;
+	MNT_IUNLOCK(MP);
+
  UNLOCK:
  	UFS_EXTATTR_UEPM_UNLOCK(UMP, TD);

 -549,6
+553,10  UFS_EXTATTR_STOP(STRUCT MOUNT *MP, STRUC
  		    UELE->UELE_ATTRNAME, TD);
  	}

+	MNT_ILOCK(MP);
+	MP->F_FLAGS &= ~MNT_EXTATTR;
+	MNT_IUNLOCK(MP);
+
  	UMP->UM_EXTATTR.UEPM_FLAGS &=
~UFS_EXTATTR_UEPM_STARTED;

  	CRFREE(UMP->UM_EXTATTR.UEPM_UCRED);

--
VH

On Fri, 21 Mar 2008, Václav Haisman wrote:

> I would like to have some sort of indication of
extended attributes 
> availability for given FS. It seems that things like
this (MAC, ACLs etc.) 
> are indicated using mount flags and those are available
through statfs() 
> call. The following is tentative patch that would
expose extended attributes 
> availability as mount flag. It is completely untested.
I would just like to 
> know if it is a viable approach to the problem or
should I scratch it and 
> try something else?

I think the preferred programmatic approach is actually via
fpathconf(2).  I 
don't know if any other OS's have assigned a _PC constant
for extended 
attributes, but if they have we should probably use the same
one.  However, I 
guess there's a meta-question: is your goal to allow
programs to be able to 
tell if extended attributes are available, or for
administrators to be able to 
tell?

Robert N M Watson
Computer Laboratory
University of Cambridge

>
>
> --- ./sys/mount.h~	2007-04-10 12:12:44.000000000 +0200
> +++ ./sys/mount.h	2008-03-21 22:48:04.436630277 +0100
>  -218,7 +218,6  void          __mnt_vnode_markerfree(str
> #define	MNT_SYNCHRONOUS	0x00000002	/* filesystem
written 
> synchronously */
> #define	MNT_NOEXEC	0x00000004	/* can't exec from
filesystem 
> */
> #define	MNT_NOSUID	0x00000008	/* don't honor setuid
bits on 
> fs */
> -#define	MNT_NODEV	0		/* Deprecated option */
> #define	MNT_UNION	0x00000020	/* union with underlying 
> filesystem */
> #define	MNT_ASYNC	0x00000040	/* filesystem written 
> asynchronously */
> #define	MNT_SUIDDIR	0x00100000	/* special handling of
SUID 
> on dirs */
>  -246,6 +245,7  void          __mnt_vnode_markerfree(str
>  * but visible to the user.
>  * XXX some of these are not quite right.. (I've never
seen the root flag 
> set)
>  */
> +#define MNT_EXTATTR	0x00000010	/* filesystem with
extended 
> attributes */
> #define	MNT_LOCAL	0x00001000	/* filesystem is stored 
> locally */
> #define	MNT_QUOTA	0x00002000	/* quotas are enabled on 
> filesystem */
> #define	MNT_ROOTFS	0x00004000	/* identifies the root 
> filesystem */
>  -265,7 +265,8  void          __mnt_vnode_markerfree(str
> 			MNT_ROOTFS	| MNT_NOATIME	| MNT_NOCLUSTERR| 
> 			MNT_NOCLUSTERW	| MNT_SUIDDIR	| MNT_SOFTDEP	| 
> 			MNT_IGNORE	| MNT_EXPUBLIC	| MNT_NOSYMFOLLOW | 
> -			MNT_JAILDEVFS	| MNT_MULTILABEL | MNT_ACLS)
> +			MNT_JAILDEVFS	| MNT_MULTILABEL | MNT_ACLS     | 
> +			MNT_EXTATTR)
>
> /* Mask of flags that can be updated. */
> #define	MNT_UPDATEMASK (MNT_NOSUID	| MNT_NOEXEC	| 
> --- ./ufs/ufs/ufs_extattr.c~	2006-03-13
04:08:08.000000000 +0100
> +++ ./ufs/ufs/ufs_extattr.c	2008-03-21
22:59:50.766939565 +0100
>  -220,6 +220,10  ufs_extattr_start(struct mount *mp, stru
>
> 	ump->um_extattr.uepm_ucred =
crhold(td->td_ucred);
>
> +	MNT_ILOCK(mp);
> +	mp->f_flags |= MNT_EXTATTR;
> +	MNT_IUNLOCK(mp);
> +
> unlock:
> 	ufs_extattr_uepm_unlock(ump, td);
>
>  -549,6 +553,10  ufs_extattr_stop(struct mount *mp, struc
> 		    uele->uele_attrname, td);
> 	}
>
> +	MNT_ILOCK(mp);
> +	mp->f_flags &= ~MNT_EXTATTR;
> +	MNT_IUNLOCK(mp);
> +
> 	ump->um_extattr.uepm_flags &=
~UFS_EXTATTR_UEPM_STARTED;
>
> 	crfree(ump->um_extattr.uepm_ucred);
>
> --
> VH
>
>
_______________________________________________
freebsd-fsfreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to
"freebsd-fs-unsubscribefreebsd.org"

ROBERT WATSON WROTE, ON 22.3.2008 19:05:
> 
> ON FRI, 21 MAR 2008, VáCLAV HAISMAN WROTE:
> 
>> I WOULD LIKE TO HAVE SOME SORT OF INDICATION OF
EXTENDED ATTRIBUTES 
>> AVAILABILITY FOR GIVEN FS. IT SEEMS THAT THINGS
LIKE THIS (MAC, ACLS 
>> ETC.) ARE INDICATED USING MOUNT FLAGS AND THOSE ARE
AVAILABLE THROUGH 
>> STATFS() CALL. THE FOLLOWING IS TENTATIVE PATCH
THAT WOULD EXPOSE 
>> EXTENDED ATTRIBUTES AVAILABILITY AS MOUNT FLAG. IT
IS COMPLETELY 
>> UNTESTED. I WOULD JUST LIKE TO KNOW IF IT IS A
VIABLE APPROACH TO THE 
>> PROBLEM OR SHOULD I SCRATCH IT AND TRY SOMETHING
ELSE?
> 
> I THINK THE PREFERRED PROGRAMMATIC APPROACH IS ACTUALLY
VIA 
> FPATHCONF(2).  I DON'T KNOW IF ANY OTHER OS'S HAVE
ASSIGNED A _PC 
> CONSTANT FOR EXTENDED ATTRIBUTES, BUT IF THEY HAVE WE
SHOULD PROBABLY 
> USE THE SAME ONE.  HOWEVER, I GUESS THERE'S A
META-QUESTION: IS YOUR 
> GOAL TO ALLOW PROGRAMS TO BE ABLE TO TELL IF EXTENDED
ATTRIBUTES ARE 
> AVAILABLE, OR FOR ADMINISTRATORS TO BE ABLE TO TELL?
> 
MY ORIGINAL INTENT WAS TO JUST EXTEND /BIN/CP WITH SWITCH
THAT WOULD ALLOW 
COPYING OF EXTENDED ATTRIBUTES TOGETHER WITH THE CONTENTS OF
FILES. WHEN I 
LOOKED AT ITS SOURCE I NOTICED THAT IT USES FPATHCONF() FOR
QUERYING FOR ACLS 
CAPABILITY. BECAUSE I HAVE NOT FOUND EXTENDED ATTRIBUTES IN
FPATHCONF(2) I 
HAVE LOOKED AT STATFS(2) BUT THERE IS NOTHING THERE EITHER.
SO I THOUGHT THE 
INFORMATION WOULD HAVE TO BE CONVEYED TO EITHER OF THE
SYSCALLS SOMEHOW. THE 
MNT_FLAG FIELD OF STRUCT MOUNT SEEMS LIKE A LOGICAL PLACE TO
PUT THE 
INFORMATION INTO. FROM THERE IT SEEMS IT COULD BE USED BY
EITHER FPATHCONF() 
OR STATFS() OR BOTH.

SO, TO ANSWER THE QUESTION, THE GOAL IS TO ALLOW PROGRAMS TO
DETECT EXTENDED 
ATTRIBUTES AVAILABILITY.

AS TO WHAT OTHER OSES DO, SOLARIS MENTIONS _PC_XATTR_ENABLED
AND 
_PC_XATTR_EXISTS IN FPATHCONF(2).

--
VH

On Sat, 22 Mar 2008, Václav Haisman wrote:

>> I think the preferred programmatic approach is
actually via fpathconf(2). I 
>> don't know if any other OS's have assigned a _PC
constant for extended 
>> attributes, but if they have we should probably use
the same one. 
>> However, I guess there's a meta-question: is your
goal to allow programs to 
>> be able to tell if extended attributes are
available, or for administrators 
>> to be able to tell?
>
> My original intent was to just extend /bin/cp with
switch that would allow 
> copying of extended attributes together with the
contents of files. When I 
> looked at its source I noticed that it uses fpathconf()
for querying for 
> ACLs capability. Because I have not found extended
attributes in 
> fpathconf(2) I have looked at statfs(2) but there is
nothing there either. 
> So I thought the information would have to be conveyed
to either of the 
> syscalls somehow. The mnt_flag field of struct mount
seems like a logical 
> place to put the information into. From there it seems
it could be used by 
> either fpathconf() or statfs() or both.
>
> So, to answer the question, the goal is to allow
programs to detect extended 
> attributes availability.
>
> As to what other OSes do, Solaris mentions
_PC_XATTR_ENABLED and 
> _PC_XATTR_EXISTS in fpathconf(2).

mount flags are normally used for places where there is a
desire to report an 
administrative setting, and on the whole, extended
attributes are a property 
of the file system type, and not a per-mount setting.  UFS1
extended 
attributes are intended to be the exception rather than the
rule.  The way 
fpathconf() works inside the kernel is that the request is
delivered directly 
to the file system that implements the target of the path
provided, so it can 
return information on whatever granularity it wants -- be it
per-mount, 
per-volume, etc.  I think the Solaris model sounds pretty
sensible, although 
one thing worth considering is that Solari's extended
attributes may, in fact, 
be file forks or streams, and called extended attributes due
to NFSv4 using 
that terminology (an unfortunate overloading inconsistent
with the use in many 
OS's).  In which case we might want to use a different name.
 It would be 
worth checking Linux and Mac OS X as well.

Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-fsfreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to
"freebsd-fs-unsubscribefreebsd.org"

ROBERT WATSON WROTE, ON 22.3.2008 21:00:
 >[...]
> MOUNT FLAGS ARE NORMALLY USED FOR PLACES WHERE THERE IS
A DESIRE TO 
> REPORT AN ADMINISTRATIVE SETTING, AND ON THE WHOLE,
EXTENDED ATTRIBUTES 
> ARE A PROPERTY OF THE FILE SYSTEM TYPE, AND NOT A
PER-MOUNT SETTING.  
> UFS1 EXTENDED ATTRIBUTES ARE INTENDED TO BE THE
EXCEPTION RATHER THAN 
> THE RULE.  THE WAY FPATHCONF() WORKS INSIDE THE KERNEL
IS THAT THE 
> REQUEST IS DELIVERED DIRECTLY TO THE FILE SYSTEM THAT
IMPLEMENTS THE 
> TARGET OF THE PATH PROVIDED, SO IT CAN RETURN
INFORMATION ON WHATEVER 
> GRANULARITY IT WANTS -- BE IT PER-MOUNT, PER-VOLUME,
ETC.  I THINK THE 
> SOLARIS MODEL SOUNDS PRETTY SENSIBLE, ALTHOUGH ONE
THING WORTH 
> CONSIDERING IS THAT SOLARI'S EXTENDED ATTRIBUTES MAY,
IN FACT, BE FILE 
> FORKS OR STREAMS, AND CALLED EXTENDED ATTRIBUTES DUE TO
NFSV4 USING THAT 
> TERMINOLOGY (AN UNFORTUNATE OVERLOADING INCONSISTENT
WITH THE USE IN 
> MANY OS'S).  IN WHICH CASE WE MIGHT WANT TO USE A
DIFFERENT NAME.  IT 
> WOULD BE WORTH CHECKING LINUX AND MAC OS X AS WELL.
> 
I HAVE DONE SOME DIGGING USING THE MAN PAGES MIRRORS ON
WWW.FREEBSD.ORG.

1. ONLY SOLARIS HAS THE _PC_XATTR_*. ACCORDING TO 
<HTTP://WWW.FREEBSD.ORG/CGI/MAN.CGI?QUERY=FSATTR&APRO
POS=0&SEKTION=0&MANPATH=SUNOS+5.10&FORMAT=HTML&g
t; 
  _PC_XATTR_* ARE REALLY ABOUT EXTENDED ATTRIBUTES. CITATION
FROM THE PAGE:

"NOT ALL IMPLEMENTATIONS ARE ABLE TO, OR WANT TO,
SUPPORT THE FULL MODEL. FOR 
EXAMPLE, THE IMPLEMENTATION FOR THE UFS FILE SYSTEM ALLOWS
ONLY REGULAR FILES 
AS ATTRIBUTES (FOR EXAMPLE, NO SUB-DIRECTORIES) AND REJECTS
ATTEMPTS TO PLACE 
ATTRIBUTES ON ATTRIBUTES."

THIS SOUNDS CLOSE ENOUGH TO WHAT FREEBSD HAS.

2. NEITHER LINUX NOR DARWIN SEEM TO SUPPORT QUERYING
AVAILABILITY OF EXTENDED 
ATTRIBUTES EVEN THOUGH THEY SUPPORT THEIR USE USING
GETXATTR() ETC.


--
VH

WHAT ABOUT
<HTTP://SHELL.SH.CVUT.CZ/~WILX/FREEBSD/EXTATTR2.DIFF>?
IT EXTENDS 
UFS_PATHCONF() WITH HANDLING OF _PC_XATTR_ENABLED. THE PATCH
IS UNTESTED.

--
VH

On Sun, 23 Mar 2008, Václav Haisman wrote:

> What about <http://shell.sh.cvut.cz/~wilx/freebsd/extattr2.diff>?
 It extends 
> ufs_pathconf() with handling of _PC_XATTR_ENABLED. The
patch is untested.

I think it sounds fairly reasonable.  However, the switch
for ufs_pathconf() 
appears to be missing the _PC_XATTR_EXISTS case?

I'd probably panic rather than KASSERT() there.

I'll also need to update the fpathconf(2) man page to list
_PC_XATTR_*.

Finally, I'm not convinced, having reread the fsattr man
page on Solaris, that 
what they mean by XATTR is what we mean by extended
attribute.  However, I 
think that's a confusion fairly specific to Solaris and that
we do have and 
apply a consistent meaning for extended attribute.  A
question for Pawel would 
be how he plans to expose ZFS "extended
attributes" (file streams) in FreeBSD, 
so I've CC'd him.

Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-fsfreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to
"freebsd-fs-unsubscribefreebsd.org"