* fstat and similar methods in fhandler_socket_local and fhandler_socket_unix @ 2021-02-20 23:32 Ken Brown 2021-02-20 23:51 ` Ken Brown 0 siblings, 1 reply; 11+ messages in thread From: Ken Brown @ 2021-02-20 23:32 UTC (permalink / raw) To: cygwin-devel fhandler_socket_local::fstat and many similar methods seem to assume that the fhandler is based on a socket *file*. When this is not the case, they end up using handles inappropriately. Consider the following test case, for example. $ cat socket_stat.c #include <time.h> #include <sys/socket.h> #include <sys/un.h> #include <sys/stat.h> #include <errno.h> #include <stdio.h> #include <stdlib.h> #include <unistd.h> void print_stat (struct stat); int main () { struct stat st; int fd; fd = socket (AF_UNIX, SOCK_STREAM, 0); if (fd == -1) { perror ("socket"); exit (1); } if (fstat (fd, &st) < 0) { perror ("fstat"); exit (1); } print_stat (st); } /* https://man7.org/linux/man-pages/man2/lstat.2.html */ void print_stat (struct stat st) { printf("File type: "); switch (st.st_mode & S_IFMT) { case S_IFBLK: printf("block device\n"); break; case S_IFCHR: printf("character device\n"); break; case S_IFDIR: printf("directory\n"); break; case S_IFIFO: printf("FIFO/pipe\n"); break; case S_IFLNK: printf("symlink\n"); break; case S_IFREG: printf("regular file\n"); break; case S_IFSOCK: printf("socket\n"); break; default: printf("unknown?\n"); break; } printf("I-node number: %ld\n", (long) st.st_ino); printf("dev: %lu\n", st.st_dev); printf("rdev: %lu\n", st.st_rdev); printf("Mode: %lo (octal)\n", (unsigned long) st.st_mode); printf("Link count: %ld\n", (long) st.st_nlink); printf("Ownership: UID=%ld GID=%ld\n", (long) st.st_uid, (long) st.st_gid); printf("Preferred I/O block size: %ld bytes\n", (long) st.st_blksize); printf("File size: %lld bytes\n", (long long) st.st_size); printf("Blocks allocated: %lld\n", (long long) st.st_blocks); printf("Last status change: %s", ctime(&st.st_ctime)); printf("Last file access: %s", ctime(&st.st_atime)); printf("Last file modification: %s", ctime(&st.st_mtime)); printf("\n"); } $ gcc -g -O0 -o socket_stat socket_stat.c $ ./socket_stat.exe File type: socket I-node number: 4 dev: 1966200 rdev: 1966200 Mode: 140644 (octal) Link count: 0 Ownership: UID=197609 GID=197121 Preferred I/O block size: 65536 bytes File size: 0 bytes Blocks allocated: 0 Last status change: Wed Dec 31 19:00:00 1969 Last file access: Wed Dec 31 19:00:00 1969 Last file modification: Wed Dec 31 19:00:00 1969 On Linux the output is: File type: socket I-node number: 117 dev: 0 rdev: 0 Mode: 140777 (octal) Link count: 1 Ownership: UID=1000 GID=1000 Preferred I/O block size: 512 bytes File size: 0 bytes Blocks allocated: 0 Last status change: Sat Feb 20 18:13:50 2021 Last file access: Sat Feb 20 18:13:50 2021 Last file modification: Sat Feb 20 18:13:50 2021 I haven't been able to find any documentation about what fstat(2) should do on a socket descriptor, so maybe the difference between Cygwin and Linux is unimportant. But the code path followed on Cygwin definitely seems wrong. fhandler_socket_local::fstat calls fstat_fs which ends up using the io_handle as though it were a file handle. It seems to me that fstat_fs should only be called if we have a path_conv handle (which is the case if the fstat call resulted from a stat call) or if the socket descriptor came from open with O_PATH set. Similar remarks apply to fstatfvs, fchmod,.... In some of these cases, like fchmod, POSIX explicitly states that the behavior is undefined, so maybe we should just fail when there's no underlying socket file. Ken ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: fstat and similar methods in fhandler_socket_local and fhandler_socket_unix 2021-02-20 23:32 fstat and similar methods in fhandler_socket_local and fhandler_socket_unix Ken Brown @ 2021-02-20 23:51 ` Ken Brown 2021-02-21 18:04 ` Ken Brown 0 siblings, 1 reply; 11+ messages in thread From: Ken Brown @ 2021-02-20 23:51 UTC (permalink / raw) To: cygwin-developers On 2/20/2021 6:32 PM, Ken Brown via Cygwin-developers wrote: > fhandler_socket_local::fstat and many similar methods seem to assume that the > fhandler is based on a socket *file*. When this is not the case, they end up > using handles inappropriately. Consider the following test case, for example. > > $ cat socket_stat.c > #include <time.h> > #include <sys/socket.h> > #include <sys/un.h> > #include <sys/stat.h> > #include <errno.h> > #include <stdio.h> > #include <stdlib.h> > #include <unistd.h> > > void print_stat (struct stat); > > int > main () > { > struct stat st; > int fd; > > fd = socket (AF_UNIX, SOCK_STREAM, 0); > if (fd == -1) > { > perror ("socket"); > exit (1); > } > if (fstat (fd, &st) < 0) > { > perror ("fstat"); > exit (1); > } > print_stat (st); > } > > /* https://man7.org/linux/man-pages/man2/lstat.2.html */ > void > print_stat (struct stat st) > { > printf("File type: "); > > switch (st.st_mode & S_IFMT) { > case S_IFBLK: printf("block device\n"); break; > case S_IFCHR: printf("character device\n"); break; > case S_IFDIR: printf("directory\n"); break; > case S_IFIFO: printf("FIFO/pipe\n"); break; > case S_IFLNK: printf("symlink\n"); break; > case S_IFREG: printf("regular file\n"); break; > case S_IFSOCK: printf("socket\n"); break; > default: printf("unknown?\n"); break; > } > > printf("I-node number: %ld\n", (long) st.st_ino); > printf("dev: %lu\n", st.st_dev); > printf("rdev: %lu\n", st.st_rdev); > printf("Mode: %lo (octal)\n", > (unsigned long) st.st_mode); > > printf("Link count: %ld\n", (long) st.st_nlink); > printf("Ownership: UID=%ld GID=%ld\n", > (long) st.st_uid, (long) st.st_gid); > > printf("Preferred I/O block size: %ld bytes\n", > (long) st.st_blksize); > printf("File size: %lld bytes\n", > (long long) st.st_size); > printf("Blocks allocated: %lld\n", > (long long) st.st_blocks); > > printf("Last status change: %s", ctime(&st.st_ctime)); > printf("Last file access: %s", ctime(&st.st_atime)); > printf("Last file modification: %s", ctime(&st.st_mtime)); > printf("\n"); > } > > $ gcc -g -O0 -o socket_stat socket_stat.c > > $ ./socket_stat.exe > File type: socket > I-node number: 4 > dev: 1966200 > rdev: 1966200 > Mode: 140644 (octal) > Link count: 0 > Ownership: UID=197609 GID=197121 > Preferred I/O block size: 65536 bytes > File size: 0 bytes > Blocks allocated: 0 > Last status change: Wed Dec 31 19:00:00 1969 > Last file access: Wed Dec 31 19:00:00 1969 > Last file modification: Wed Dec 31 19:00:00 1969 > > On Linux the output is: > > File type: socket > I-node number: 117 > dev: 0 > rdev: 0 > Mode: 140777 (octal) > Link count: 1 > Ownership: UID=1000 GID=1000 > Preferred I/O block size: 512 bytes > File size: 0 bytes > Blocks allocated: 0 > Last status change: Sat Feb 20 18:13:50 2021 > Last file access: Sat Feb 20 18:13:50 2021 > Last file modification: Sat Feb 20 18:13:50 2021 > > I haven't been able to find any documentation about what fstat(2) should do on a > socket descriptor, so maybe the difference between Cygwin and Linux is > unimportant. But the code path followed on Cygwin definitely seems wrong. > fhandler_socket_local::fstat calls fstat_fs which ends up using the io_handle as > though it were a file handle. It seems to me that fstat_fs should only be > called if we have a path_conv handle (which is the case if the fstat call > resulted from a stat call) or if the socket descriptor came from open with > O_PATH set. > > Similar remarks apply to fstatfvs, fchmod,.... In some of these cases, like > fchmod, POSIX explicitly states that the behavior is undefined, so maybe we > should just fail when there's no underlying socket file. Maybe the answer in all these cases is just to revert to the fhandler_socket methods when our fhandler_socket_local is not based on a socket file. Ken ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: fstat and similar methods in fhandler_socket_local and fhandler_socket_unix 2021-02-20 23:51 ` Ken Brown @ 2021-02-21 18:04 ` Ken Brown 2021-02-22 9:44 ` Corinna Vinschen 0 siblings, 1 reply; 11+ messages in thread From: Ken Brown @ 2021-02-21 18:04 UTC (permalink / raw) To: cygwin-developers On 2/20/2021 6:51 PM, Ken Brown via Cygwin-developers wrote: > On 2/20/2021 6:32 PM, Ken Brown via Cygwin-developers wrote: >> fhandler_socket_local::fstat and many similar methods seem to assume that the >> fhandler is based on a socket *file*. When this is not the case, they end up >> using handles inappropriately. Consider the following test case, for example. >> >> $ cat socket_stat.c >> #include <time.h> >> #include <sys/socket.h> >> #include <sys/un.h> >> #include <sys/stat.h> >> #include <errno.h> >> #include <stdio.h> >> #include <stdlib.h> >> #include <unistd.h> >> >> void print_stat (struct stat); >> >> int >> main () >> { >> struct stat st; >> int fd; >> >> fd = socket (AF_UNIX, SOCK_STREAM, 0); >> if (fd == -1) >> { >> perror ("socket"); >> exit (1); >> } >> if (fstat (fd, &st) < 0) >> { >> perror ("fstat"); >> exit (1); >> } >> print_stat (st); >> } >> >> /* https://man7.org/linux/man-pages/man2/lstat.2.html */ >> void >> print_stat (struct stat st) >> { >> printf("File type: "); >> >> switch (st.st_mode & S_IFMT) { >> case S_IFBLK: printf("block device\n"); break; >> case S_IFCHR: printf("character device\n"); break; >> case S_IFDIR: printf("directory\n"); break; >> case S_IFIFO: printf("FIFO/pipe\n"); break; >> case S_IFLNK: printf("symlink\n"); break; >> case S_IFREG: printf("regular file\n"); break; >> case S_IFSOCK: printf("socket\n"); break; >> default: printf("unknown?\n"); break; >> } >> >> printf("I-node number: %ld\n", (long) st.st_ino); >> printf("dev: %lu\n", st.st_dev); >> printf("rdev: %lu\n", st.st_rdev); >> printf("Mode: %lo (octal)\n", >> (unsigned long) st.st_mode); >> >> printf("Link count: %ld\n", (long) st.st_nlink); >> printf("Ownership: UID=%ld GID=%ld\n", >> (long) st.st_uid, (long) st.st_gid); >> >> printf("Preferred I/O block size: %ld bytes\n", >> (long) st.st_blksize); >> printf("File size: %lld bytes\n", >> (long long) st.st_size); >> printf("Blocks allocated: %lld\n", >> (long long) st.st_blocks); >> >> printf("Last status change: %s", ctime(&st.st_ctime)); >> printf("Last file access: %s", ctime(&st.st_atime)); >> printf("Last file modification: %s", ctime(&st.st_mtime)); >> printf("\n"); >> } >> >> $ gcc -g -O0 -o socket_stat socket_stat.c >> >> $ ./socket_stat.exe >> File type: socket >> I-node number: 4 >> dev: 1966200 >> rdev: 1966200 >> Mode: 140644 (octal) >> Link count: 0 >> Ownership: UID=197609 GID=197121 >> Preferred I/O block size: 65536 bytes >> File size: 0 bytes >> Blocks allocated: 0 >> Last status change: Wed Dec 31 19:00:00 1969 >> Last file access: Wed Dec 31 19:00:00 1969 >> Last file modification: Wed Dec 31 19:00:00 1969 >> >> On Linux the output is: >> >> File type: socket >> I-node number: 117 >> dev: 0 >> rdev: 0 >> Mode: 140777 (octal) >> Link count: 1 >> Ownership: UID=1000 GID=1000 >> Preferred I/O block size: 512 bytes >> File size: 0 bytes >> Blocks allocated: 0 >> Last status change: Sat Feb 20 18:13:50 2021 >> Last file access: Sat Feb 20 18:13:50 2021 >> Last file modification: Sat Feb 20 18:13:50 2021 >> >> I haven't been able to find any documentation about what fstat(2) should do on >> a socket descriptor, so maybe the difference between Cygwin and Linux is >> unimportant. But the code path followed on Cygwin definitely seems wrong. >> fhandler_socket_local::fstat calls fstat_fs which ends up using the io_handle >> as though it were a file handle. It seems to me that fstat_fs should only be >> called if we have a path_conv handle (which is the case if the fstat call >> resulted from a stat call) or if the socket descriptor came from open with >> O_PATH set. >> >> Similar remarks apply to fstatfvs, fchmod,.... In some of these cases, like >> fchmod, POSIX explicitly states that the behavior is undefined, so maybe we >> should just fail when there's no underlying socket file. > > Maybe the answer in all these cases is just to revert to the fhandler_socket > methods when our fhandler_socket_local is not based on a socket file. I think the following should do the job for fstat: --- a/winsup/cygwin/fhandler_socket_local.cc +++ b/winsup/cygwin/fhandler_socket_local.cc @@ -673,11 +673,11 @@ fhandler_socket_local::fcntl (int cmd, intptr_t arg) int __reg2 fhandler_socket_local::fstat (struct stat *buf) { - int res; + if (!pc.handle () && !(get_flags () & O_PATH)) + /* fstat is not being called on a socket file. */ + return fhandler_socket::fstat (buf); - if (get_sun_path () && get_sun_path ()[0] == '\0') - return fhandler_socket_wsock::fstat (buf); - res = fhandler_base::fstat_fs (buf); + int res = fhandler_base::fstat_fs (buf); if (!res) { buf->st_mode = (buf->st_mode & ~S_IFMT) | S_IFSOCK; With this patch, the output of my testcase looks like this: File type: socket I-node number: 6 dev: 1966080 rdev: 1966200 Mode: 140777 (octal) Link count: 1 Ownership: UID=197609 GID=197121 Preferred I/O block size: 65536 bytes File size: 0 bytes Blocks allocated: 0 Last status change: Thu Nov 30 19:00:00 2006 Last file access: Sun Feb 21 13:03:03 2021 Last file modification: Sun Feb 21 13:03:03 2021 If this patch looks right, I'll look at the other system calls too. Ken ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: fstat and similar methods in fhandler_socket_local and fhandler_socket_unix 2021-02-21 18:04 ` Ken Brown @ 2021-02-22 9:44 ` Corinna Vinschen 2021-02-22 20:01 ` Ken Brown 0 siblings, 1 reply; 11+ messages in thread From: Corinna Vinschen @ 2021-02-22 9:44 UTC (permalink / raw) To: cygwin-developers On Feb 21 13:04, Ken Brown via Cygwin-developers wrote: > On 2/20/2021 6:51 PM, Ken Brown via Cygwin-developers wrote: > > On 2/20/2021 6:32 PM, Ken Brown via Cygwin-developers wrote: > > > fhandler_socket_local::fstat and many similar methods seem to assume > > > that the fhandler is based on a socket *file*. When this is not the > > > case, they end up using handles inappropriately. Consider the > > > following test case, for example. > > > > > > $ cat socket_stat.c > > > [...] > > > I haven't been able to find any documentation about what fstat(2) > > > should do on a socket descriptor, so maybe the difference between > > > Cygwin and Linux is unimportant. But the code path followed on > > > Cygwin definitely seems wrong. fhandler_socket_local::fstat calls > > > fstat_fs which ends up using the io_handle as though it were a file > > > handle. I see what you mean. This was clearly fat-fingered, probably after trying to add abstract sockets. > It seems to me that fstat_fs should only be called if we > > > have a path_conv handle (which is the case if the fstat call > > > resulted from a stat call) or if the socket descriptor came from > > > open with O_PATH set. > > > > > > Similar remarks apply to fstatfvs, fchmod,.... In some of these > > > cases, like fchmod, POSIX explicitly states that the behavior is > > > undefined, so maybe we should just fail when there's no underlying > > > socket file. > > > > Maybe the answer in all these cases is just to revert to the > > fhandler_socket methods when our fhandler_socket_local is not based on a > > socket file. > > I think the following should do the job for fstat: > > --- a/winsup/cygwin/fhandler_socket_local.cc > +++ b/winsup/cygwin/fhandler_socket_local.cc > @@ -673,11 +673,11 @@ fhandler_socket_local::fcntl (int cmd, intptr_t arg) > int __reg2 > fhandler_socket_local::fstat (struct stat *buf) > { > - int res; > + if (!pc.handle () && !(get_flags () & O_PATH)) > + /* fstat is not being called on a socket file. */ The comment should probably read "fstat called on a socket"... > + return fhandler_socket::fstat (buf); ...plus adding a comment right here: /* stat/lstat on a socket file or fstat on a socket opened w/ O_PATH */ > - if (get_sun_path () && get_sun_path ()[0] == '\0') > - return fhandler_socket_wsock::fstat (buf); > - res = fhandler_base::fstat_fs (buf); > + int res = fhandler_base::fstat_fs (buf); > if (!res) > { > buf->st_mode = (buf->st_mode & ~S_IFMT) | S_IFSOCK; > > With this patch, the output of my testcase looks like this: > > File type: socket > I-node number: 6 > dev: 1966080 > rdev: 1966200 > Mode: 140777 (octal) > Link count: 1 > Ownership: UID=197609 GID=197121 > Preferred I/O block size: 65536 bytes > File size: 0 bytes > Blocks allocated: 0 > Last status change: Thu Nov 30 19:00:00 2006 > Last file access: Sun Feb 21 13:03:03 2021 > Last file modification: Sun Feb 21 13:03:03 2021 Might be a good idea to check the output twice in your testcase, adding a second fstat call after calling bind, to see if it's still the same after binding the socket to a file. > If this patch looks right, I'll look at the other system calls too. Yeah, I think you're right. Thanks! Corinna ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: fstat and similar methods in fhandler_socket_local and fhandler_socket_unix 2021-02-22 9:44 ` Corinna Vinschen @ 2021-02-22 20:01 ` Ken Brown 2021-02-24 9:06 ` Corinna Vinschen 0 siblings, 1 reply; 11+ messages in thread From: Ken Brown @ 2021-02-22 20:01 UTC (permalink / raw) To: cygwin-developers On 2/22/2021 4:44 AM, Corinna Vinschen via Cygwin-developers wrote: > On Feb 21 13:04, Ken Brown via Cygwin-developers wrote: >> On 2/20/2021 6:51 PM, Ken Brown via Cygwin-developers wrote: >>> On 2/20/2021 6:32 PM, Ken Brown via Cygwin-developers wrote: >>>> fhandler_socket_local::fstat and many similar methods seem to assume >>>> that the fhandler is based on a socket *file*. When this is not the >>>> case, they end up using handles inappropriately. Consider the >>>> following test case, for example. >>>> >>>> $ cat socket_stat.c >>>> [...] >>>> I haven't been able to find any documentation about what fstat(2) >>>> should do on a socket descriptor, so maybe the difference between >>>> Cygwin and Linux is unimportant. But the code path followed on >>>> Cygwin definitely seems wrong. fhandler_socket_local::fstat calls >>>> fstat_fs which ends up using the io_handle as though it were a file >>>> handle. > > I see what you mean. This was clearly fat-fingered, probably after > trying to add abstract sockets. > >> It seems to me that fstat_fs should only be called if we >>>> have a path_conv handle (which is the case if the fstat call >>>> resulted from a stat call) or if the socket descriptor came from >>>> open with O_PATH set. >>>> >>>> Similar remarks apply to fstatfvs, fchmod,.... In some of these >>>> cases, like fchmod, POSIX explicitly states that the behavior is >>>> undefined, so maybe we should just fail when there's no underlying >>>> socket file. >>> >>> Maybe the answer in all these cases is just to revert to the >>> fhandler_socket methods when our fhandler_socket_local is not based on a >>> socket file. >> >> I think the following should do the job for fstat: >> >> --- a/winsup/cygwin/fhandler_socket_local.cc >> +++ b/winsup/cygwin/fhandler_socket_local.cc >> @@ -673,11 +673,11 @@ fhandler_socket_local::fcntl (int cmd, intptr_t arg) >> int __reg2 >> fhandler_socket_local::fstat (struct stat *buf) >> { >> - int res; >> + if (!pc.handle () && !(get_flags () & O_PATH)) >> + /* fstat is not being called on a socket file. */ > > The comment should probably read "fstat called on a socket"... > >> + return fhandler_socket::fstat (buf); > > ...plus adding a comment right here: > > /* stat/lstat on a socket file or fstat on a socket opened w/ O_PATH */ > >> - if (get_sun_path () && get_sun_path ()[0] == '\0') >> - return fhandler_socket_wsock::fstat (buf); >> - res = fhandler_base::fstat_fs (buf); >> + int res = fhandler_base::fstat_fs (buf); >> if (!res) >> { >> buf->st_mode = (buf->st_mode & ~S_IFMT) | S_IFSOCK; >> >> With this patch, the output of my testcase looks like this: >> >> File type: socket >> I-node number: 6 >> dev: 1966080 >> rdev: 1966200 >> Mode: 140777 (octal) >> Link count: 1 >> Ownership: UID=197609 GID=197121 >> Preferred I/O block size: 65536 bytes >> File size: 0 bytes >> Blocks allocated: 0 >> Last status change: Thu Nov 30 19:00:00 2006 >> Last file access: Sun Feb 21 13:03:03 2021 >> Last file modification: Sun Feb 21 13:03:03 2021 > > Might be a good idea to check the output twice in your testcase, adding > a second fstat call after calling bind, to see if it's still the same > after binding the socket to a file. Done. >> If this patch looks right, I'll look at the other system calls too. > > Yeah, I think you're right. Thanks! OK, I've got patches ready to go for fstat, fstatvfs, fchmod, fchown, facl, and link. I have to test them, and then I'll send them to cygwin-patches. In the case of link, I think the only way an fhandler_socket's link method can be called is through link(2) being called on a socket file. So the following should do the job: diff --git a/winsup/cygwin/fhandler.h b/winsup/cygwin/fhandler.h index 21e1df172..f4aa12956 100644 --- a/winsup/cygwin/fhandler.h +++ b/winsup/cygwin/fhandler.h @@ -611,7 +611,6 @@ class fhandler_socket: public fhandler_base int __reg1 fchmod (mode_t newmode); int __reg2 fchown (uid_t newuid, gid_t newgid); int __reg3 facl (int, int, struct acl *); - int __reg2 link (const char *); off_t lseek (off_t, int) { set_errno (ESPIPE); diff --git a/winsup/cygwin/fhandler_socket.cc b/winsup/cygwin/fhandler_socket.cc index f22412650..08870cc6b 100644 --- a/winsup/cygwin/fhandler_socket.cc +++ b/winsup/cygwin/fhandler_socket.cc @@ -357,9 +357,3 @@ fhandler_socket::facl (int cmd, int nentries, aclent_t *aclbufp) set_errno (EOPNOTSUPP); return -1; } - -int -fhandler_socket::link (const char *newpath) -{ - return fhandler_base::link (newpath); -} diff --git a/winsup/cygwin/fhandler_socket_local.cc b/winsup/cygwin/fhandler_socket_local.cc index 2c66a7fd4..176d64b9b 100644 --- a/winsup/cygwin/fhandler_socket_local.cc +++ b/winsup/cygwin/fhandler_socket_local.cc @@ -747,8 +747,6 @@ fhandler_socket_local::facl (int cmd, int nentries, aclent_t *aclbufp) int fhandler_socket_local::link (const char *newpath) { - if (get_sun_path () && get_sun_path ()[0] == '\0') - return fhandler_socket_wsock::link (newpath); fhandler_disk_file fh (pc); return fh.link (newpath); } diff --git a/winsup/cygwin/fhandler_socket_unix.cc b/winsup/cygwin/fhandler_socket_unix.cc index bd5e1b854..3c713e025 100644 --- a/winsup/cygwin/fhandler_socket_unix.cc +++ b/winsup/cygwin/fhandler_socket_unix.cc @@ -2394,10 +2394,6 @@ fhandler_socket_unix::facl (int cmd, int nentries, aclent_t *aclbufp) int fhandler_socket_unix::link (const char *newpath) { - if (sun_path () - && (sun_path ()->un_len <= (socklen_t) sizeof (sa_family_t) - || sun_path ()->un.sun_path[0] == '\0')) - return fhandler_socket::link (newpath); fhandler_disk_file fh (pc); return fh.link (newpath); } Let me know if I've missed something and we really do need fhandler_socket::link. Ken ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: fstat and similar methods in fhandler_socket_local and fhandler_socket_unix 2021-02-22 20:01 ` Ken Brown @ 2021-02-24 9:06 ` Corinna Vinschen 2021-02-24 15:32 ` Ken Brown 0 siblings, 1 reply; 11+ messages in thread From: Corinna Vinschen @ 2021-02-24 9:06 UTC (permalink / raw) To: cygwin-developers On Feb 22 15:01, Ken Brown via Cygwin-developers wrote: > OK, I've got patches ready to go for fstat, fstatvfs, fchmod, fchown, facl, > and link. I have to test them, and then I'll send them to cygwin-patches. > In the case of link, I think the only way an fhandler_socket's link method > can be called is through link(2) being called on a socket file. So the > following should do the job: > > diff --git a/winsup/cygwin/fhandler.h b/winsup/cygwin/fhandler.h > index 21e1df172..f4aa12956 100644 > --- a/winsup/cygwin/fhandler.h > +++ b/winsup/cygwin/fhandler.h > @@ -611,7 +611,6 @@ class fhandler_socket: public fhandler_base > int __reg1 fchmod (mode_t newmode); > int __reg2 fchown (uid_t newuid, gid_t newgid); > int __reg3 facl (int, int, struct acl *); > - int __reg2 link (const char *); > off_t lseek (off_t, int) > { > set_errno (ESPIPE); > diff --git a/winsup/cygwin/fhandler_socket.cc b/winsup/cygwin/fhandler_socket.cc > index f22412650..08870cc6b 100644 > --- a/winsup/cygwin/fhandler_socket.cc > +++ b/winsup/cygwin/fhandler_socket.cc > @@ -357,9 +357,3 @@ fhandler_socket::facl (int cmd, int nentries, aclent_t *aclbufp) > set_errno (EOPNOTSUPP); > return -1; > } > - > -int > -fhandler_socket::link (const char *newpath) > -{ > - return fhandler_base::link (newpath); > -} Hmm. What about linkat (AT_EMPTY_PATH, socket, ...)? This could be called for inet sockets as well as unnamed or abstract unix sockets, in theory... Corinna ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: fstat and similar methods in fhandler_socket_local and fhandler_socket_unix 2021-02-24 9:06 ` Corinna Vinschen @ 2021-02-24 15:32 ` Ken Brown 2021-02-24 17:06 ` Corinna Vinschen 0 siblings, 1 reply; 11+ messages in thread From: Ken Brown @ 2021-02-24 15:32 UTC (permalink / raw) To: cygwin-developers On 2/24/2021 4:06 AM, Corinna Vinschen via Cygwin-developers wrote: > On Feb 22 15:01, Ken Brown via Cygwin-developers wrote: >> OK, I've got patches ready to go for fstat, fstatvfs, fchmod, fchown, facl, >> and link. I have to test them, and then I'll send them to cygwin-patches. >> In the case of link, I think the only way an fhandler_socket's link method >> can be called is through link(2) being called on a socket file. So the >> following should do the job: >> >> diff --git a/winsup/cygwin/fhandler.h b/winsup/cygwin/fhandler.h >> index 21e1df172..f4aa12956 100644 >> --- a/winsup/cygwin/fhandler.h >> +++ b/winsup/cygwin/fhandler.h >> @@ -611,7 +611,6 @@ class fhandler_socket: public fhandler_base >> int __reg1 fchmod (mode_t newmode); >> int __reg2 fchown (uid_t newuid, gid_t newgid); >> int __reg3 facl (int, int, struct acl *); >> - int __reg2 link (const char *); >> off_t lseek (off_t, int) >> { >> set_errno (ESPIPE); >> diff --git a/winsup/cygwin/fhandler_socket.cc b/winsup/cygwin/fhandler_socket.cc >> index f22412650..08870cc6b 100644 >> --- a/winsup/cygwin/fhandler_socket.cc >> +++ b/winsup/cygwin/fhandler_socket.cc >> @@ -357,9 +357,3 @@ fhandler_socket::facl (int cmd, int nentries, aclent_t *aclbufp) >> set_errno (EOPNOTSUPP); >> return -1; >> } >> - >> -int >> -fhandler_socket::link (const char *newpath) >> -{ >> - return fhandler_base::link (newpath); >> -} > > Hmm. What about linkat (AT_EMPTY_PATH, socket, ...)? > > This could be called for inet sockets as well as unnamed or abstract > unix sockets, in theory... Thanks, I missed that case. So we do need fhandler_socket::link. The only question in my mind is what errno it should set. I just tried the following: $ cat socket_linkat.c #define _GNU_SOURCE #include <sys/socket.h> #include <sys/un.h> #include <errno.h> #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <fcntl.h> #define NEW_PATH "/tmp/newpath" int main () { struct sockaddr_un addr; int fd; if (unlink (NEW_PATH) == -1 && errno != ENOENT) { perror ("unlink"); exit (1); } fd = socket (AF_UNIX, SOCK_STREAM, 0); if (fd == -1) { perror ("socket"); exit (1); } if (linkat (fd, "", AT_FDCWD, NEW_PATH, AT_EMPTY_PATH) == -1) perror ("linkat"); } On Linux I get linkat: Invalid cross-device link So I think fhandler_socket::link should fail with EXDEV. Probably it should continue to call fhandler_base::link, and the latter should fail with EXDEV instead of EPERM. Or is there some case where EPERM is more appropriate? Ken ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: fstat and similar methods in fhandler_socket_local and fhandler_socket_unix 2021-02-24 15:32 ` Ken Brown @ 2021-02-24 17:06 ` Corinna Vinschen 2021-02-24 17:27 ` Ken Brown 0 siblings, 1 reply; 11+ messages in thread From: Corinna Vinschen @ 2021-02-24 17:06 UTC (permalink / raw) To: cygwin-developers On Feb 24 10:32, Ken Brown via Cygwin-developers wrote: > On 2/24/2021 4:06 AM, Corinna Vinschen via Cygwin-developers wrote: > > On Feb 22 15:01, Ken Brown via Cygwin-developers wrote: > > > OK, I've got patches ready to go for fstat, fstatvfs, fchmod, fchown, facl, > > > and link. I have to test them, and then I'll send them to cygwin-patches. > > > In the case of link, I think the only way an fhandler_socket's link method > > > can be called is through link(2) being called on a socket file. So the > > > following should do the job: > > > > > > diff --git a/winsup/cygwin/fhandler.h b/winsup/cygwin/fhandler.h > > > index 21e1df172..f4aa12956 100644 > > > --- a/winsup/cygwin/fhandler.h > > > +++ b/winsup/cygwin/fhandler.h > > > @@ -611,7 +611,6 @@ class fhandler_socket: public fhandler_base > > > int __reg1 fchmod (mode_t newmode); > > > int __reg2 fchown (uid_t newuid, gid_t newgid); > > > int __reg3 facl (int, int, struct acl *); > > > - int __reg2 link (const char *); > > > off_t lseek (off_t, int) > > > { > > > set_errno (ESPIPE); > > > diff --git a/winsup/cygwin/fhandler_socket.cc b/winsup/cygwin/fhandler_socket.cc > > > index f22412650..08870cc6b 100644 > > > --- a/winsup/cygwin/fhandler_socket.cc > > > +++ b/winsup/cygwin/fhandler_socket.cc > > > @@ -357,9 +357,3 @@ fhandler_socket::facl (int cmd, int nentries, aclent_t *aclbufp) > > > set_errno (EOPNOTSUPP); > > > return -1; > > > } > > > - > > > -int > > > -fhandler_socket::link (const char *newpath) > > > -{ > > > - return fhandler_base::link (newpath); > > > -} > > > > Hmm. What about linkat (AT_EMPTY_PATH, socket, ...)? > > > > This could be called for inet sockets as well as unnamed or abstract > > unix sockets, in theory... > > Thanks, I missed that case. So we do need fhandler_socket::link. The only > question in my mind is what errno it should set. I just tried the > following: > [...] > On Linux I get > > linkat: Invalid cross-device link > > So I think fhandler_socket::link should fail with EXDEV. Probably it should > continue to call fhandler_base::link, and the latter should fail with EXDEV > instead of EPERM. Or is there some case where EPERM is more appropriate? fhandler_base::link returns EPERM because that covers "filesystem does not support the creation of hard links", which is the most probable case. If we want to return EXDEV by default, the non-disk_file error case will have to check if oldpath and newpath are on the same filesystem. I wonder if this is really worth the effort. Corinna ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: fstat and similar methods in fhandler_socket_local and fhandler_socket_unix 2021-02-24 17:06 ` Corinna Vinschen @ 2021-02-24 17:27 ` Ken Brown 2021-02-25 13:18 ` Ken Brown 0 siblings, 1 reply; 11+ messages in thread From: Ken Brown @ 2021-02-24 17:27 UTC (permalink / raw) To: cygwin-developers On 2/24/2021 12:06 PM, Corinna Vinschen via Cygwin-developers wrote: > On Feb 24 10:32, Ken Brown via Cygwin-developers wrote: >> On 2/24/2021 4:06 AM, Corinna Vinschen via Cygwin-developers wrote: >>> On Feb 22 15:01, Ken Brown via Cygwin-developers wrote: >>>> OK, I've got patches ready to go for fstat, fstatvfs, fchmod, fchown, facl, >>>> and link. I have to test them, and then I'll send them to cygwin-patches. >>>> In the case of link, I think the only way an fhandler_socket's link method >>>> can be called is through link(2) being called on a socket file. So the >>>> following should do the job: >>>> >>>> diff --git a/winsup/cygwin/fhandler.h b/winsup/cygwin/fhandler.h >>>> index 21e1df172..f4aa12956 100644 >>>> --- a/winsup/cygwin/fhandler.h >>>> +++ b/winsup/cygwin/fhandler.h >>>> @@ -611,7 +611,6 @@ class fhandler_socket: public fhandler_base >>>> int __reg1 fchmod (mode_t newmode); >>>> int __reg2 fchown (uid_t newuid, gid_t newgid); >>>> int __reg3 facl (int, int, struct acl *); >>>> - int __reg2 link (const char *); >>>> off_t lseek (off_t, int) >>>> { >>>> set_errno (ESPIPE); >>>> diff --git a/winsup/cygwin/fhandler_socket.cc b/winsup/cygwin/fhandler_socket.cc >>>> index f22412650..08870cc6b 100644 >>>> --- a/winsup/cygwin/fhandler_socket.cc >>>> +++ b/winsup/cygwin/fhandler_socket.cc >>>> @@ -357,9 +357,3 @@ fhandler_socket::facl (int cmd, int nentries, aclent_t *aclbufp) >>>> set_errno (EOPNOTSUPP); >>>> return -1; >>>> } >>>> - >>>> -int >>>> -fhandler_socket::link (const char *newpath) >>>> -{ >>>> - return fhandler_base::link (newpath); >>>> -} >>> >>> Hmm. What about linkat (AT_EMPTY_PATH, socket, ...)? >>> >>> This could be called for inet sockets as well as unnamed or abstract >>> unix sockets, in theory... >> >> Thanks, I missed that case. So we do need fhandler_socket::link. The only >> question in my mind is what errno it should set. I just tried the >> following: >> [...] >> On Linux I get >> >> linkat: Invalid cross-device link >> >> So I think fhandler_socket::link should fail with EXDEV. Probably it should >> continue to call fhandler_base::link, and the latter should fail with EXDEV >> instead of EPERM. Or is there some case where EPERM is more appropriate? > > fhandler_base::link returns EPERM because that covers "filesystem does > not support the creation of hard links", which is the most probable > case. If we want to return EXDEV by default, the non-disk_file error > case will have to check if oldpath and newpath are on the same > filesystem. I wonder if this is really worth the effort. Not if it's my effort. So I guess I should just make fhandler_socket::link return EXDEV. Ken ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: fstat and similar methods in fhandler_socket_local and fhandler_socket_unix 2021-02-24 17:27 ` Ken Brown @ 2021-02-25 13:18 ` Ken Brown 2021-02-25 17:03 ` Corinna Vinschen 0 siblings, 1 reply; 11+ messages in thread From: Ken Brown @ 2021-02-25 13:18 UTC (permalink / raw) To: cygwin-developers On 2/24/2021 12:27 PM, Ken Brown via Cygwin-developers wrote: > On 2/24/2021 12:06 PM, Corinna Vinschen via Cygwin-developers wrote: >> On Feb 24 10:32, Ken Brown via Cygwin-developers wrote: >>> On 2/24/2021 4:06 AM, Corinna Vinschen via Cygwin-developers wrote: >>>> On Feb 22 15:01, Ken Brown via Cygwin-developers wrote: >>>>> OK, I've got patches ready to go for fstat, fstatvfs, fchmod, fchown, facl, >>>>> and link. I have to test them, and then I'll send them to cygwin-patches. >>>>> In the case of link, I think the only way an fhandler_socket's link method >>>>> can be called is through link(2) being called on a socket file. So the >>>>> following should do the job: >>>>> >>>>> diff --git a/winsup/cygwin/fhandler.h b/winsup/cygwin/fhandler.h >>>>> index 21e1df172..f4aa12956 100644 >>>>> --- a/winsup/cygwin/fhandler.h >>>>> +++ b/winsup/cygwin/fhandler.h >>>>> @@ -611,7 +611,6 @@ class fhandler_socket: public fhandler_base >>>>> int __reg1 fchmod (mode_t newmode); >>>>> int __reg2 fchown (uid_t newuid, gid_t newgid); >>>>> int __reg3 facl (int, int, struct acl *); >>>>> - int __reg2 link (const char *); >>>>> off_t lseek (off_t, int) >>>>> { >>>>> set_errno (ESPIPE); >>>>> diff --git a/winsup/cygwin/fhandler_socket.cc >>>>> b/winsup/cygwin/fhandler_socket.cc >>>>> index f22412650..08870cc6b 100644 >>>>> --- a/winsup/cygwin/fhandler_socket.cc >>>>> +++ b/winsup/cygwin/fhandler_socket.cc >>>>> @@ -357,9 +357,3 @@ fhandler_socket::facl (int cmd, int nentries, aclent_t >>>>> *aclbufp) >>>>> set_errno (EOPNOTSUPP); >>>>> return -1; >>>>> } >>>>> - >>>>> -int >>>>> -fhandler_socket::link (const char *newpath) >>>>> -{ >>>>> - return fhandler_base::link (newpath); >>>>> -} >>>> >>>> Hmm. What about linkat (AT_EMPTY_PATH, socket, ...)? While working on this, I discovered that linkat(AT_EMPTY_PATH) doesn't currently work on socket files opened with O_PATH. I started debugging this (not finished yet), and it occurred to me that the implementation of linkat(AT_EMPTY_PATH) could be simplified like this: --- a/winsup/cygwin/syscalls.cc +++ b/winsup/cygwin/syscalls.cc @@ -4962,6 +4962,8 @@ linkat (int olddirfd, const char *oldpathname, int flags) { tmp_pathbuf tp; + fhandler_base *fh = NULL; + __try { if (flags & ~(AT_SYMLINK_FOLLOW | AT_EMPTY_PATH)) @@ -4970,21 +4972,19 @@ linkat (int olddirfd, const char *oldpathname, __leave; } char *oldpath = tp.c_get (); - /* AT_EMPTY_PATH with an empty oldpathname is equivalent to - - linkat(AT_FDCWD, "/proc/self/fd/<olddirfd>", newdirfd, - newname, AT_SYMLINK_FOLLOW); - - Convert the request accordingly. */ if ((flags & AT_EMPTY_PATH) && oldpathname && oldpathname[0] == '\0') { + /* Operate directly on olddirfd. */ if (olddirfd == AT_FDCWD) { set_errno (EPERM); __leave; } - __small_sprintf (oldpath, "/proc/%d/fd/%d", myself->pid, olddirfd); - flags = AT_SYMLINK_FOLLOW; + cygheap_fdget cfd (olddirfd); + if (cfd < 0) + __leave; + fh = cfd; + flags = 0; } else if (gen_full_path_at (oldpath, olddirfd, oldpathname)) __leave; @@ -5003,6 +5003,8 @@ linkat (int olddirfd, const char *oldpathname, } strcpy (oldpath, old_name.get_posix ()); } + if (fh) + return fh->link (newpath); return link (oldpath, newpath); } __except (EFAULT) {} This seems to work fine on regular files and on socket files opened with O_PATH, after I tweak fhandler_socket_local::link (see below). I haven't tested other file types yet. $ cat linkat_test.c #define _GNU_SOURCE #include <sys/types.h> #include <time.h> #include <sys/socket.h> #include <sys/un.h> #include <errno.h> #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <fcntl.h> #define FILE "/tmp/myfile" #define NEW_FILE "/tmp/mynewfile" #define SOCK_PATH "/tmp/mysocket" #define NEW_SOCK_PATH "/tmp/mynewsocket" int main () { struct sockaddr_un addr; int fd; /* Regular file. */ if (unlink (FILE) < 0 && errno != ENOENT) { perror ("unlink"); exit (1); } if (unlink (NEW_FILE) < 0 && errno != ENOENT) { perror ("unlink"); exit (1); } fd = open (FILE, O_RDONLY | O_CREAT, S_IRUSR | S_IWUSR); if (fd < 0) { perror ("open"); exit (1); } printf ("Testing linkat (AT_EMPTY_PATH) on a regular file...\n"); if (linkat (fd, "", AT_FDCWD, NEW_FILE, AT_EMPTY_PATH) < 0) perror ("linkat"); else printf ("success\n\n"); if (close (fd) < 0) { perror ("close"); exit (1); } /* Socket file. */ if (unlink (SOCK_PATH) < 0 && errno != ENOENT) { perror ("unlink"); exit (1); } if (unlink (NEW_SOCK_PATH) < 0 && errno != ENOENT) { perror ("unlink"); exit (1); } fd = socket (AF_UNIX, SOCK_STREAM, 0); if (fd < 0) { perror ("socket"); exit (1); } memset (&addr, 0, sizeof (struct sockaddr_un)); addr.sun_family = AF_UNIX; strcpy (addr.sun_path, SOCK_PATH); if (bind (fd, (struct sockaddr *) &addr, sizeof(struct sockaddr_un)) < 0) { perror ("bind"); exit (1); } if (close (fd) < 0) { perror ("close"); exit (1); } fd = open (SOCK_PATH, O_PATH); if (fd < 0) { perror ("open"); exit (1); } printf ("Testing linkat (AT_EMPTY_PATH) on a socket file...\n"); if (linkat (fd, "", AT_FDCWD, NEW_SOCK_PATH, AT_EMPTY_PATH) < 0) perror ("linkat"); else printf ("success\n"); if (close (fd) < 0) { perror ("close"); exit (1); } } $ gcc -g -O0 -o linkat_test linkat_test.c $ ./linkat_test.exe Testing linkat (AT_EMPTY_PATH) on a regular file... success Testing linkat (AT_EMPTY_PATH) on a socket file... success $ ls -l /tmp/my* -rw------- 2 kbrown None 0 2021-02-25 07:59 /tmp/myfile -rw------- 2 kbrown None 0 2021-02-25 07:59 /tmp/mynewfile srw-r--r-- 2 kbrown None 0 2021-02-25 07:59 /tmp/mynewsocket= srw-r--r-- 2 kbrown None 0 2021-02-25 07:59 /tmp/mysocket= And here's the tweak to fhandler_socket_local::link: --- a/winsup/cygwin/fhandler_socket_local.cc +++ b/winsup/cygwin/fhandler_socket_local.cc @@ -749,9 +749,14 @@ fhandler_socket_local::facl (int cmd, int nentries, aclent_t *aclbufp) int fhandler_socket_local::link (const char *newpath) { - if (get_sun_path () && get_sun_path ()[0] == '\0') + if (!dev ().isfs ()) + /* linkat w/ AT_EMPTY_PATH called on a socket not opened w/ O_PATH. */ return fhandler_socket_wsock::link (newpath); + /* link on a socket file or linkat w/ AT_EMPTY_PATH called on a + socket opened w/ O_PATH. */ fhandler_disk_file fh (pc); + if (get_flags () & O_PATH) + fh.set_handle (get_handle ()); return fh.link (newpath); } I'll put all this together in a patchset, along with the tweaks to fstat, etc., but first I wanted to get your reaction to the proposed simplification of linkat(AT_EMPTY_PATH). Thanks. Ken ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: fstat and similar methods in fhandler_socket_local and fhandler_socket_unix 2021-02-25 13:18 ` Ken Brown @ 2021-02-25 17:03 ` Corinna Vinschen 0 siblings, 0 replies; 11+ messages in thread From: Corinna Vinschen @ 2021-02-25 17:03 UTC (permalink / raw) To: cygwin-developers On Feb 25 08:18, Ken Brown via Cygwin-developers wrote: > While working on this, I discovered that linkat(AT_EMPTY_PATH) doesn't > currently work on socket files opened with O_PATH. I started debugging this > (not finished yet), and it occurred to me that the implementation of > linkat(AT_EMPTY_PATH) could be simplified like this: > > --- a/winsup/cygwin/syscalls.cc > +++ b/winsup/cygwin/syscalls.cc > @@ -4962,6 +4962,8 @@ linkat (int olddirfd, const char *oldpathname, > int flags) > { > tmp_pathbuf tp; > + fhandler_base *fh = NULL; > + > __try > { > if (flags & ~(AT_SYMLINK_FOLLOW | AT_EMPTY_PATH)) > @@ -4970,21 +4972,19 @@ linkat (int olddirfd, const char *oldpathname, > __leave; > } > char *oldpath = tp.c_get (); > - /* AT_EMPTY_PATH with an empty oldpathname is equivalent to > - > - linkat(AT_FDCWD, "/proc/self/fd/<olddirfd>", newdirfd, > - newname, AT_SYMLINK_FOLLOW); > - > - Convert the request accordingly. */ > if ((flags & AT_EMPTY_PATH) && oldpathname && oldpathname[0] == '\0') > { > + /* Operate directly on olddirfd. */ > if (olddirfd == AT_FDCWD) > { > set_errno (EPERM); > __leave; > } > - __small_sprintf (oldpath, "/proc/%d/fd/%d", myself->pid, olddirfd); > - flags = AT_SYMLINK_FOLLOW; > + cygheap_fdget cfd (olddirfd); > + if (cfd < 0) > + __leave; > + fh = cfd; > + flags = 0; > } > else if (gen_full_path_at (oldpath, olddirfd, oldpathname)) > __leave; > @@ -5003,6 +5003,8 @@ linkat (int olddirfd, const char *oldpathname, > } > strcpy (oldpath, old_name.get_posix ()); > } > + if (fh) > + return fh->link (newpath); > return link (oldpath, newpath); > } > __except (EFAULT) {} Good idea. Just a small comment why you set flags to 0 might be nice. > This seems to work fine on regular files and on socket files opened with > O_PATH, after I tweak fhandler_socket_local::link (see below). I haven't > tested other file types yet. For most of them that should end up in fhandler_base:link anyway. Thanks, Corinna ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2021-02-25 17:03 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-02-20 23:32 fstat and similar methods in fhandler_socket_local and fhandler_socket_unix Ken Brown 2021-02-20 23:51 ` Ken Brown 2021-02-21 18:04 ` Ken Brown 2021-02-22 9:44 ` Corinna Vinschen 2021-02-22 20:01 ` Ken Brown 2021-02-24 9:06 ` Corinna Vinschen 2021-02-24 15:32 ` Ken Brown 2021-02-24 17:06 ` Corinna Vinschen 2021-02-24 17:27 ` Ken Brown 2021-02-25 13:18 ` Ken Brown 2021-02-25 17:03 ` Corinna Vinschen
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).