Bug 72920 - [linux] path "prefixing" is not done on unix domain socket addresses
Summary: [linux] path "prefixing" is not done on unix domain socket addresses
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 5.2.1-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: Dmitry Chagin
URL:
Keywords:
Depends on:
Blocks: 247219
  Show dependency treegraph
 
Reported: 2004-10-20 13:00 UTC by Andriy Gapon
Modified: 2020-07-27 18:59 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andriy Gapon 2004-10-20 13:00:50 UTC
It seems that pathname "prefixing" is not performed for unix domain
socket calls in linux emulation e.g. "/compat/linux" prefix is never
tried to be prepended for bind() and connect() calls. 
When mixed with filesystem calls this leads to linux applications
failing in scenarios like this:


mkdir("/tmp/foo");
//this will create /compat/linux/tmp/foo/ directory

s = socket(AF_LOCAL, SOCK_DGRAM, PF_LOCAL);
strcpy(addr.sun_path, "/tmp/foo/bar");
addr.sun_family = AF_LOCAL;
bind(s, (struct sockaddr *) &addr, SUN_LEN(&addr));
//this will try to bind socket in /tmp/foo/ directory
//which does not exist

I have experinced this problem on FreeBSD 5.2.1 with two real-life
applications:
	oracle 9.2.0.4.0
	IBM WebSphere MQ 5.3

Fix: 

fix should not be very hard to implement, but I'd prefer that someone more
familiar with the code would do it (someone who wrote the similar code for 
filesystem calls).
How-To-Repeat: Existence of this problem can be easily verified using a small program 
with the above code (make sure /tmp/foo directory is not existant).
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2004-11-29 09:31:36 UTC
Responsible Changed
From-To: freebsd-bugs->emulation

Reassign to appropriate mailing list.
Comment 2 Alexander Leidinger freebsd_committer 2005-12-29 16:09:27 UTC
State Changed
From-To: open->feedback

Does this problem still persists on a recent FreeBSD? 
If yes, I suggest to try to come up with a patch, since most 
of the problems are fixed by people which need a particular 
feature (we don't have a maintainer for the linuxolator).
Comment 3 Alexander Leidinger freebsd_committer 2006-01-14 14:23:47 UTC
State Changed
From-To: feedback->open

Feedback reveived, the bug still exist in -current. 
 
http://www.freebsd.org/cgi/query-pr.cgi?pr=72920 
Comment 4 Mark Linimon freebsd_committer freebsd_triage 2006-01-14 18:19:19 UTC
State Changed
From-To: open->analyzed

ISTM 'analyzed' is a better state for this.
Comment 5 Andriy Gapon freebsd_committer 2010-12-05 15:26:02 UTC
State Changed
From-To: analyzed->closed
Comment 6 Andriy Gapon freebsd_committer 2010-12-05 15:27:04 UTC
State Changed
From-To: closed->analyzed

Revert accidental status change.
Comment 7 Dmitry Chagin freebsd_committer 2016-01-17 15:38:49 UTC
take
Comment 8 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:46:43 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
AND
- Untouched since 2018-01-01.
AND
- Affects Base System OR Documentation

DO:

Reset to open status.


Note:
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.