public inbox for cygwin-patches@cygwin.com
 help / color / mirror / Atom feed
From: Philippe Cerfon <philcerf@gmail.com>
To: cygwin-patches@cygwin.com
Subject: Re: [PATCH] include/cygwin/limits.h: add XATTR_{NAME,SIZE,LIST}_MAX
Date: Fri, 16 Jun 2023 16:09:08 +0200	[thread overview]
Message-ID: <CAN+za=NjpooX1JrwbgDgX8yzHkn6AwtYH8yCOjzkUspMZd1W6g@mail.gmail.com> (raw)
In-Reply-To: <ZIBWqTEkn9c9GWfF@calimero.vinschen.de>

[-- Attachment #1: Type: text/plain, Size: 302 bytes --]

Hey Corinna.

On Wed, Jun 7, 2023 at 12:06 PM Corinna Vinschen
<corinna-cygwin@cygwin.com> wrote:
> Hmm, the comparisons would have to check for XATTR_NAME_MAX anyway,
> so maybe inlining is cleaner in this case.

Please have a look at the updated and attached patches.

Thanks,
Philippe.

[-- Attachment #2: 0001-Cygwin-export-XATTR_-NAME-SIZE-LIST-_MAX.patch --]
[-- Type: text/x-patch, Size: 1099 bytes --]

From 82e2ff6f52d7401210247ae396ce3f1f115d93f0 Mon Sep 17 00:00:00 2001
From: Philippe Cerfon <philcerf@gmail.com>
Date: Tue, 30 May 2023 13:16:18 +0200
Subject: [PATCH 1/2] Cygwin: export XATTR_{NAME,SIZE,LIST}_MAX

These are used for example by CPython.

Signed-off-by: Philippe Cerfon <philcerf@gmail.com>
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
---
 winsup/cygwin/include/cygwin/limits.h | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/winsup/cygwin/include/cygwin/limits.h b/winsup/cygwin/include/cygwin/limits.h
index aefc7c7bd..ea3e2836a 100644
--- a/winsup/cygwin/include/cygwin/limits.h
+++ b/winsup/cygwin/include/cygwin/limits.h
@@ -56,4 +56,11 @@ details. */
 #define __PATH_MAX 4096
 #define __PIPE_BUF 4096
 
+/* XATTR_NAME_MAX is the maximum XATTR name length excluding the null
+ * terminator. Since only XATTRs in the `user' namespace are allowed and the
+ * `user.' prefix is not stored, the maximum is increased by 5. */
+#define XATTR_NAME_MAX 260
+#define XATTR_SIZE_MAX 65536
+#define XATTR_LIST_MAX 65536
+
 #endif /* _CYGWIN_LIMITS_H__ */
-- 
2.40.1


[-- Attachment #3: 0002-Cygwin-use-new-XATTR_-NAME-SIZE-_MAX-instead-of-MAX_.patch --]
[-- Type: text/x-patch, Size: 3150 bytes --]

From 34a2e210082ddbf87d2c9569b6b14775a6cc5b95 Mon Sep 17 00:00:00 2001
From: Philippe Cerfon <philcerf@gmail.com>
Date: Tue, 6 Jun 2023 02:52:49 +0200
Subject: [PATCH 2/2] Cygwin: use new XATTR_{NAME,SIZE}_MAX instead of
 MAX_EA_{NAME,VALUE}_LEN

Signed-off-by: Philippe Cerfon <philcerf@gmail.com>
---
 winsup/cygwin/ntea.cc | 19 +++++++++----------
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/winsup/cygwin/ntea.cc b/winsup/cygwin/ntea.cc
index a400fcb2b..ef1fdf4cc 100644
--- a/winsup/cygwin/ntea.cc
+++ b/winsup/cygwin/ntea.cc
@@ -17,9 +17,7 @@ details. */
 #include "tls_pbuf.h"
 #include <stdlib.h>
 #include <attr/xattr.h>
-
-#define MAX_EA_NAME_LEN    256
-#define MAX_EA_VALUE_LEN 65536
+#include <cygwin/limits.h>
 
 /* At least one maximum sized entry fits.
    CV 2014-04-04: NtQueryEaFile function chokes on buffers bigger than 64K
@@ -27,13 +25,14 @@ details. */
 		  on a remote share, at least on Windows 7 and later.
 		  In theory the buffer should have a size of
 
-		    sizeof (FILE_FULL_EA_INFORMATION) + MAX_EA_NAME_LEN
-		    + MAX_EA_VALUE_LEN
+		    sizeof (FILE_FULL_EA_INFORMATION)
+		    + (XATTR_NAME_MAX + 1 - strlen("user."))
+		    + XATTR_SIZE_MAX
 
 		  (65804 bytes), but we're opting for simplicity here, and
 		  a 64K buffer has the advantage that we can use a tmp_pathbuf
 		  buffer, rather than having to alloca 64K from stack. */
-#define EA_BUFSIZ MAX_EA_VALUE_LEN
+#define EA_BUFSIZ XATTR_SIZE_MAX
 
 #define NEXT_FEA(p) ((PFILE_FULL_EA_INFORMATION) (p->NextEntryOffset \
 		     ? (char *) p + p->NextEntryOffset : NULL))
@@ -55,7 +54,7 @@ read_ea (HANDLE hdl, path_conv &pc, const char *name, char *value, size_t size)
      returns the last EA entry of the file infinitely.  Even utilizing the
      optional EaIndex only helps marginally.  If you use that, the last
      EA in the file is returned twice. */
-  char lastname[MAX_EA_NAME_LEN];
+  char lastname[(XATTR_NAME_MAX + 1 - strlen("user."))];
 
   __try
     {
@@ -95,7 +94,7 @@ read_ea (HANDLE hdl, path_conv &pc, const char *name, char *value, size_t size)
 	      __leave;
 	    }
 
-	  if ((nlen = strlen (name)) >= MAX_EA_NAME_LEN)
+	  if ((nlen = strlen (name)) >= (XATTR_NAME_MAX + 1 - strlen("user.")))
 	    {
 	      set_errno (EINVAL);
 	      __leave;
@@ -197,7 +196,7 @@ read_ea (HANDLE hdl, path_conv &pc, const char *name, char *value, size_t size)
 		  /* For compatibility with Linux, we always prepend "user." to
 		     the attribute name, so effectively we only support user
 		     attributes from a application point of view. */
-		  char tmpbuf[MAX_EA_NAME_LEN * 2];
+		  char tmpbuf[(XATTR_NAME_MAX + 1 - strlen("user.")) * 2];
 		  char *tp = stpcpy (tmpbuf, "user.");
 		  stpcpy (tp, fea->EaName);
 		  /* NTFS stores all EA names in uppercase unfortunately.  To
@@ -297,7 +296,7 @@ write_ea (HANDLE hdl, path_conv &pc, const char *name, const char *value,
       /* Skip "user." prefix. */
       name += 5;
 
-      if ((nlen = strlen (name)) >= MAX_EA_NAME_LEN)
+      if ((nlen = strlen (name)) >= (XATTR_NAME_MAX + 1 - strlen("user.")))
 	{
 	  set_errno (EINVAL);
 	  __leave;
-- 
2.40.1


  reply	other threads:[~2023-06-16 14:09 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAN+za=MhQdD2mzYxqVAm9ZwBUBKsyPiH+9T5xfGXtgxq1X1LAA@mail.gmail.com>
2023-05-30 20:04 ` Brian Inglis
2023-06-05 19:05   ` Corinna Vinschen
2023-06-06  1:04     ` Philippe Cerfon
2023-06-06  1:14     ` Philippe Cerfon
2023-06-06 13:28       ` Corinna Vinschen
2023-06-06 15:17         ` Philippe Cerfon
2023-06-07 10:06           ` Corinna Vinschen
2023-06-16 14:09             ` Philippe Cerfon [this message]
2023-06-16 15:04               ` Corinna Vinschen
2023-06-16 15:43                 ` Philippe Cerfon
2023-06-16 19:49                   ` Corinna Vinschen
2023-06-16 19:52                     ` Philippe Cerfon
2023-06-19  8:53                       ` Corinna Vinschen

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='CAN+za=NjpooX1JrwbgDgX8yzHkn6AwtYH8yCOjzkUspMZd1W6g@mail.gmail.com' \
    --to=philcerf@gmail.com \
    --cc=cygwin-patches@cygwin.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 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 read-only IMAP folder(s) and NNTP newsgroup(s).