Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!news.swapon.de!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Martin Gregorie Newsgroups: comp.lang.java.programmer Subject: Re: application server, just without the "web" part... Date: Thu, 4 Sep 2014 12:13:47 +0000 (UTC) Organization: A noiseless patient Spider Lines: 53 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Thu, 4 Sep 2014 12:13:47 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="e5160e2be48f1ea550cf61512446f525"; logging-data="30301"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19t0XQaXLQEpMMReAW5B4wKIhcQHTvK7rk=" User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2) Cancel-Lock: sha1:n5zTn7A4JdQUpCbC3N4+9Su4Jd8= Xref: csiph.com comp.lang.java.programmer:29905 On Thu, 04 Sep 2014 07:36:22 +0000, Andreas Leitgeb wrote: > Martin Gregorie wrote: >> On Wed, 03 Sep 2014 18:29:57 +0000, Martin Gregorie wrote: >>> On Wed, 03 Sep 2014 17:51:45 +0000, Andreas Leitgeb wrote: >>>> Meanwhile that's the remaining part of my problem. The authorization >>>> should not be part of the protocol, but some local "challenge", that >>>> only a particular user on the same machine can do. E.g. write to an >>>> appropriately set up named pipe or unix domain socket. >>>> Unfortunately, Java doesn't seem to support unix domain sockets >>>> without JNI, and named pipes have their own bag of downsides. See >>>> new thread "java unix domain sockets ..." >>> I think you can do what you need with bog standard Java Sockets. >>> Assuming that this program will be listening for incoming connections >>> on a ServerSocket, if your first action after ServerSocket.accept() >>> returns a Socket, is to call Socket.getInetAddress(). You can easily >>> check whether the InetAddress it returns is a local loopback >>> connection or not: if it is on the local loopback, the IP address will >>> be 127.0.0.1 or the IPV6 equivalent. >> I missed seeing the restriction to specific users on the local box. My >> bad. Would requiring the authorised users to belong to a specific group >> help solve the problem? > > I'd be very curious about a mechanism that could be used to restrict the > connecting user's group (even if that same mechanism couldn't also be > used to restrict the user) > > Admittedly, not so much for the task at hand, but for general > learning... AFAIK you can't do it in pure Java, but the possibilities are: - run the groups utility via ProcessBuilder and examine the list of groups it returns. This is a Free Software Foundation utility program that writes a space-delimited list of groups to stdout. Using it may be the easiest way to check group membership: obviously, once the group list has been retrieved it can be scanned by either client or server to see whether the caller is a member of the required group. - call getgrouplist() via JNI. getgrouplist() is a nonstandard function, but is available in Linux and (it says) most BSD versions. The manpage has an example utility that calls it. - have the process call getgroups() via JNI, though this would only return the group ID of supplementary groups the process is a member of. I hope this is useful info. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |