Netatalk
ad: segfault when modifying files on volume owned by other user
If you run ad cp or ad mv (etc.) on a file on a shared volume where the user running ad is also the owner of the dir/files on the shared volume, the operations succeed without issue.
However, if the dir/files are owned by another user, ad throws a segfault.
This is not a new bug. I could reproduce as far back as 3.1.12.
dmark@pretrix:/srv/afptest1$ ad cp 1 11
Mar 15 15:13:05.099331 ad[125273] {netatalk_conf.c:2024} (error:Default): getvolbypath("/srv/afptest1/11"): path does not match basedir regex "/home"
Mar 15 15:13:05.099435 ad[125273] {netatalk_conf.c:2024} (error:Default): getvolbypath("/srv/afptest1/1"): path does not match basedir regex "/home"
Segmentation fault
Sample backtrace
Program received signal SIGSEGV, Segmentation fault.
copy (path=0xaaaaaaaca850 "README", statp=0xffffffffc6d0, tflag=0, ftw=0xffffffffc778) at ../bin/ad/ad_cp.c:376
376 if (!dvolume.vol->vfs->vfs_validupath(dvolume.vol, dir))
(gdb) bt
#0 copy (path=0xaaaaaaaca850 "README", statp=0xffffffffc6d0, tflag=0, ftw=0xffffffffc778) at ../bin/ad/ad_cp.c:376
#1 0x0000fffff7f4dea8 in ftw_startup (dir=0xfffffffff6ff "README", is_nftw=1, func=0xaaaaaaaa3694 <copy>,
up=0xaaaaaaaa2d28 <upfunc>, descriptors=20, flags=19) at ../libatalk/util/ftw.c:817
#2 0x0000fffff7f4dfc4 in nftw (path=0xfffffffff6ff "README", func=0xaaaaaaaa3694 <copy>, up=0xaaaaaaaa2d28 <upfunc>,
descriptors=20, flags=19) at ../libatalk/util/ftw.c:862
#3 0x0000aaaaaaaa35d4 in ad_cp (argc=1, argv=0xfffffffff498, obj=0xffffffffc990) at ../bin/ad/ad_cp.c:338
#4 0x0000aaaaaaaaa568 in main (argc=4, argv=0xfffffffff488) at ../bin/ad/ad.c:68
Is there a [Homes] section in your afp.conf? If so, what happened if it is commented out?
I tested with both a valid [Homes] section and without a [Homes] section at all. It didn't make a difference for this bug.
I haven't so far. I did run into UNIX permissions problems with ad cp not being able to copy the resource fork. Files had different owners, but were in the same group. The setup is a bit non-standard though since I'm using a FUSE overlay for case insensitive operation on A2SERVER. I need to try it with a standard shared folder.
What was the exact setup of folder permissions used for the share?
These are the test volumes in my main Debian Trixie test bed.
drwxr-xr-x 11 root root 4096 Mar 15 15:06 .
drwxr-xr-x 18 root root 4096 Oct 6 12:13 ..
drwxrwsr-x 12 atalk1 afpusers 4096 Oct 25 20:35 afp1
drwxrwxr-x 2 atalk1 afpusers 4096 Oct 25 08:21 afp2
drwxrwxr-x 9 atalk1 afpusers 4096 Mar 9 18:17 afpad1
drwxrwxr-x 2 atalk1 afpusers 4096 Mar 12 17:59 afpad2
drwxrwsrwx 2 dmark afpusers 4096 Feb 17 07:06 afplite
drwxr-xr-x 6 dmark dmark 4096 Mar 30 07:40 afpme
drwxrwsr-x 5 atalk1 afpusers 4096 Mar 27 06:21 afptest1
drwxrwsr-x 5 atalk1 afpusers 4096 Mar 22 18:37 afptest2
Out of these, only "afpme" really works with ad commands for me, when logged in as dmark. I get the segfaults even when the group ownership is different, f.e. dmark:afpusers.
I think I figured out what's triggering this: The valid users option in afp.conf
For instance:
[owntest]
volume name = Ownership Test
path = /srv/afp3
valid users = dmark
drwxrwxrwx 2 root root 4096 4月 5 07:54 afp3
dmark@ub22:/srv/afp3$ ad ls
Apr 05 08:04:10.554530 ad[14146] {netatalk_conf.c:2001} (error:Default): getvolbypath("/srv/afp3/."): path does not match basedir regex "/home"
TheVolumeSettingsFolder AppleShare Network Trash Folder AppleShare.Browser.sit AppleShare IP Browser AppleShare Browser
dmark@ub22:/srv/afp3$ ad cp AppleShare AppleShare2
Apr 05 08:04:26.481102 ad[14151] {netatalk_conf.c:2001} (error:Default): getvolbypath("/srv/afp3/AppleShare2"): path does not match basedir regex "/home"
Apr 05 08:04:26.481125 ad[14151] {netatalk_conf.c:2001} (error:Default): getvolbypath("/srv/afp3/AppleShare"): path does not match basedir regex "/home"
Segmentation fault (core dumped)
As a side note, I'm seeing other errors when operating in the active user's home dir, seemingly unrelated to the valid users setting.
$ ad ls
Apr 05 16:11:57.931828 ad[310387] {unix.c:619} (error:AFPDaemon): initgroups(dmark, 1000): Operation not permitted
Apr 05 16:11:57.932204 ad[310387] {netatalk_conf.c:225} (error:AFPDaemon): Cannot create or append to /var/local/netatalk/afp_voluuid.conf (Permission denied)
Apr 05 16:11:57.932231 ad[310387] {netatalk_conf.c:1255} (error:AFPDaemon): Volume 'dmark's home': couldn't get UUID
$ ad cp UnicodeData.txt UnicodeData33.txt
Apr 05 16:12:21.974341 ad[310389] {unix.c:619} (error:AFPDaemon): initgroups(dmark, 1000): Operation not permitted
There must be something fundamentally missing in how ad gets initialized.
I attempted to zero in on the segfault and try to prevent it. What I found was that the global enum variable type in ad_cp.c got corrupted and doing comparison with it (if (type != FILE_TO_FILE)) caused the crash. Then I attempted adding validation on this enum elsewhere. This led to another adjacent variable getting corrupted instead. So I concluded that some broader memory corruption is happening and can't be protected against in an obvious manner. Perhaps due to bad handling of threads?
Curiously enough, on macOS hosts this works perfectly in the current main branch, no spurious errors or segfaults. The problem reproduces on Linux (Debian, Alpine) that I have tested recently.