Re: Finding symlink information in MAC Framework
jan.gr...@bristol.ac.uk wrote: On Wed, 27 Jul 2011, per...@pluto.rain.com wrote: ... One additional thing that symlinks manage to do is to refer to directories as well as files Yes; I left that aspect out by way of simplification since it did not seem pertinent to the OP's situation. hard links to directories spawn problems such as requiring garbage collection and smarter filesystem descent algorithms, which is another reason they're typically prohibited except in the case where they're created by mkdir. or by mv, when moving a directory within the same physical filesystem. The two biggest problems I'm aware of are: * They create the possibility that the filesystem is no longer a tree but a more general directed graph which may even be cyclic. The possibility of a cyclic graph would indeed require handling in utilities such as find(1) and ls -R, but the only case I've thought of that would need garbage collection -- as opposed to some minor extension of the current reference-counting scheme -- would be detection of cycles that have become disconnected (unreachable from either the root or any currently-open directory). However, I think prohibition of hard-links to directories is not sufficient to prevent the creation of isolated cycles. Consider: $ mkdir -p /tmp/a/b/c/d/e/f/g $ cd /tmp/a/b/c/d/e $ mv /tmp/a/b f/g Unless either mv or the kernel goes to some trouble to detect the subterfuge, this will create an isolated cycle f/g/b/c/d/e/f/... * Where should my .. entry point, if links to me (other than my . entry and my subdirectories' .. entries) appear in more than one directory? FWIW one of the early unix systems I was exposed to permitted the creation of hard links by arbitrary users. Just _one_? I've never heard of any that did _not_ permit that! (AFAIK Posix requires it.) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: A style proposal for referring to upper-level directories in Makefiles
In message 4e31aed9.4000...@aldan.algebra.com, Mikhail T. writes:
The most common method to refer to the upper directory in Makefile is as
${.CURDIR}/..
I'd like to propose we begin using ${.CURDIR:H} instead.
This will make it even harder for people who try to compile our
bits on alien systems without bmake.
I am not sure if that is a concern we should care about.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: MAC Framework, Socket information
On Thu, 28 Jul 2011, s wrote:
I need to get some info about the socket being created by the user. What I
want to do is log all TCP/UDP outgoing connections that are being made. I
*need* to get the local and remote address, as well as the local and remote
port. I managed to get all of the remote data, but this is useless to me, if
I haven't got the local port. Here is what I have already written:
Most MAC Framework entry points are invoked before operations of interest,
rather than after, because they are intended to perform access control on
operations. I think the closest you may be able to get given current entry
points is logging when the first operation is performed on the connected
socket: i.e., read, write, sendfile, etc, since it will be established at that
point (some caution required: you can invoke system calls on sockets before
and during connect()).
However, I can't help but wonder: would you be better-served by using the
kernel's audit facilities to track events like socket connection? Are you
blending access control and logging in your module, or is this really just
about logging?
Robert
static int slog_socket_check_connect(struct ucred *cred,
struct socket *socket, struct label *socketlabel,
struct sockaddr *sockaddr)
{
if(sockaddr-sa_family == AF_INET) {
struct sockaddr_in sa;
log(LOG_SECURITY | LOG_DEBUG, Somebody made a socket: %d:%d
(%d)\n,
cred-cr_ruid,
ntohs(((struct sockaddr_in*)sockaddr)-sin_port),
ntohs(((struct in_endpoints*)sockaddr)-ie_lport)
);
}
return 0;
}
--
Pozdrawiam,
Jakub 'samu' Szafrański
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
FreeBSD Summer Course
Hello FreeBSDers, I have uploaded the FreeBSD summer course materials. It's good course for beginners. You can check it and I will be glad to receive your comments and suggestions for future courses. https://sites.google.com/site/arabbsd/freebsd-summer-course Regards, -- *Mohammed Farrag* * * ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
installworld fails with /usr/bin and /usr/sbin on separate file systems
Installworld fails in usr.sbin/chown with a cross-device link error,
if /usr/bin and /usr/sbin are not on the same partition due to the
following line in Makefile:
LINKS= ${BINDIR}/chown /usr/bin/chgrp
In this case, ${BINDIR} is /usr/sbin and while both are subdirectories
of /usr (and thus typically within the /usr file system), there is no
reason /usr/bin and /usr/sbin could not be individual and independent
file systems.
(I ran into this problem when I played with ZFS file system tuning and
happened to create separate file systems for the above directories.)
I could not find any other place, where a hard link is used for files
in different subdirectories (typically ${BINDIR}/x - ${BINDIR}/y or
${LIBDIR}/x - ${LIBDIR}/y).
Installworld succeeds, if a symlink is used instead:
SYMLINKS= ${BINDIR}/chown /usr/bin/chgrp
Alternatively, the file could be copied, if the hard link can not be
created.
I'm not sure, whether this is an actual problem, since it does not
appear to have been reported before, but I think that LINK=...
should generally not be used between different directories.
Regards, STefan
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Small fetch(1) patch to improve xfer stats readability
While fetch, (as invoked by portsnap, in my case) displays the completion percentage just fine, when it reaches 100% the output becomes a little messy : -hashnumber percentage_completed of MB KBps time_left Now, when it gets to 100%, the string 100% gets stuck by the hashnumber, e.g. '98727300a76bn062f901100% completed of 65 MB 500KBps 00:00 This little patch fixes the problem. Since this is my first attempt at sending a patch, please bare with me. :-) 213c213 fprintf(stderr, %3d%% of %s, --- fprintf(stderr, %3d%% of %s, ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Small fetch(1) patch to improve xfer stats readability
While fetch, (as invoked by portsnap, in my case) displays the completion percentage just fine, when it reaches 100% the output becomes a little messy : -hashnumber percentage_completed of MB KBps time_left Now, when it gets to 100%, the string 100% gets stuck by the hashnumber, e.g. '98727300a76bn062f901100% completed of 65 MB 500KBps 00:00 This little patch fixes the problem. Since this is my first attempt at sending a patch, please bare with me. :-) 213c213 fprintf(stderr, %3d%% of %s, --- fprintf(stderr, %3d%% of %s, ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
MIPS toolchain
Does anyone have a prebuilt MIPS tool chain? Sent from my iPhone ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: MIPS toolchain
On 07/29/11 10:12 PM, James Jones wrote: Does anyone have a prebuilt MIPS tool chain? If you need MIPS64 then maybe I could get some binaries built or a cross compiler. (Can't help with MIPS32 though) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: MIPS toolchain
On Fri, 29 Jul 2011 11:12:35 -0400 James Jones ja...@freedomnet.co.nz wrote: Does anyone have a prebuilt MIPS tool chain? There's so many unanswered details in this loaded question one cannot possibly hope to answer it correctly. Are you asking for what mips ISA and ABIs? What is to be used as a host? In general, toolchain is generally quite easy to build as cross-tool, assuming FreeBSD supports the target. -- Alexander Kabaev signature.asc Description: PGP signature
Re: A style proposal for referring to upper-level directories in Makefiles
On 29.07.2011 03:27, Poul-Henning Kamp wrote: This will make it even harder for people who try to compile our bits on alien systems without bmake. Bits referring to multiple directories at once? Using a make flavor, that already supports .CURDIR, but not .CURDIR:H? Do such things even exist? Personally, when I need to build a sizable BSD program on another system, I begin with building bmake (NetBSD's pkgsrc project helps with that). Or, if it is not a big program, I just create a GNUmakefile from scratch -- gmake is omnipresent these days. I am not sure if that is a concern we should care about. I don't think, we should either... -mi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FIB separation
On 7/16/11 9:19 AM, Alexander V. Chernikov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hiroki Sato wrote: Vlad Galud...@dudu.ro wrote ina718adb2-ec52-462c-a114-85053f1b2...@dudu.ro: du Hello, du du A couple of years ago, Stef Walter proposed a patch[1] that enforced du the scope of routing messages. The general consesus was that the best du approach would be the OpenBSD way - transporting the FIB number in the du message and letting the user applications filter out unwanted du messages. du du Are there any plans to tackle this before 9.0? I am looking into this and investigating other possible extensions in rtsock messages such as addition of a fib member to rt_msghdr. I am not sure it can be done before 9.0, though... Actually there were an off-list discussion with bz@ and julian@ about interface fibs and rtsock changes several weeks ago. Initial messages: http://lists.freebsd.org/pipermail/freebsd-net/2011-June/029040.html I've got 3 different patches: 1) straight forwarded kern/134931 fix (no fib in rtsock, no breaking ABI, send to bz@) just got back from vacation in hungary so catching up...: Didn't he commit it? bz?? 2) adding fib in rtsock with rtsock versioning and other ABI keeping tricks 3) adding special RTA which can contain TLV pairs, with single defined TLV with routing socket As a result of discussion, first patch was sent to bz@. Since patches from kern/134931 are outdated attaching it here. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: A style proposal for referring to upper-level directories in Makefiles
To me, it just makes things less readable. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: kern/159281: [PATCH] Linux-like /proc/swaps for linprocfs
Hi Kostik,
2011/7/29 Kostik Belousov kostik...@gmail.com:
The patch is too hackish, IMHO.
I would prefer to have an exported kernel function that fills xswdev
by index, used both by vm_swap_info and linprocfs.
For the device name, you would use sw_vp-v_rdev-si_name, see, for
instance, the following fragment in the swapoff_all():
if (vn_isdisk(sp-sw_vp, NULL))
devname = sp-sw_vp-v_rdev-si_name;
else
devname = [file];
This could be another function that returns swap information by index.
Here's a patch with the changes you requested.
--
Robert Millan
--- a/sys/compat/linprocfs/linprocfs.c
+++ b/sys/compat/linprocfs/linprocfs.c
@@ -502,6 +502,32 @@
return (0);
}
+static int
+linprocfs_doswaps(PFS_FILL_ARGS)
+{
+ struct xswdev xsw;
+ int n;
+ long long total, used;
+ char devname[SPECNAMELEN + 1];
+
+ sbuf_printf(sb, Filename\t\t\t\tType\t\tSize\tUsed\tPriority\n);
+
+ for (n = 0; ; n++) {
+ if (swap_info(n, xsw) != 0)
+ break;
+
+ if (swap_devname(n, devname, sizeof(devname)) != 0)
+ break;
+
+ total = (long long)xsw.xsw_nblks * PAGE_SIZE / 1024;
+ used = (long long)xsw.xsw_used * PAGE_SIZE / 1024;
+
+ sbuf_printf(sb, /dev/%-34s unknown\t\t%lld\t%lld\t-1\n, devname, total, used);
+ }
+
+ return (0);
+}
+
/*
* Filler function for proc/uptime
*/
@@ -1490,6 +1516,8 @@
NULL, NULL, NULL, 0);
pfs_create_file(root, stat, linprocfs_dostat,
NULL, NULL, NULL, PFS_RD);
+ pfs_create_file(root, swaps, linprocfs_doswaps,
+ NULL, NULL, NULL, PFS_RD);
pfs_create_file(root, uptime, linprocfs_douptime,
NULL, NULL, NULL, PFS_RD);
pfs_create_file(root, version, linprocfs_doversion,
--- a/sys/vm/swap_pager.c
+++ b/sys/vm/swap_pager.c
@@ -2315,6 +2315,31 @@
return (0);
}
+int
+swap_devname(int name, char *devname, size_t len)
+{
+ int n;
+ struct swdevt *sp;
+ char *tmp_devname;
+
+ n = 0;
+ mtx_lock(sw_dev_mtx);
+ TAILQ_FOREACH(sp, swtailq, sw_list) {
+ if (n == name) {
+ if (vn_isdisk(sp-sw_vp, NULL))
+tmp_devname = sp-sw_vp-v_rdev-si_name;
+ else
+tmp_devname = [file];
+ strncpy(devname, tmp_devname, len);
+ mtx_unlock(sw_dev_mtx);
+ return (0);
+ }
+ n++;
+ }
+ mtx_unlock(sw_dev_mtx);
+ return (ENOENT);
+}
+
void
swapoff_all(void)
{
@@ -2365,30 +2390,24 @@
mtx_unlock(sw_dev_mtx);
}
-static int
-sysctl_vm_swap_info(SYSCTL_HANDLER_ARGS)
+int
+swap_info(int name, struct xswdev *xs)
{
- int *name = (int *)arg1;
int error, n;
- struct xswdev xs;
struct swdevt *sp;
- if (arg2 != 1) /* name length */
- return (EINVAL);
-
n = 0;
mtx_lock(sw_dev_mtx);
TAILQ_FOREACH(sp, swtailq, sw_list) {
- if (n == *name) {
+ if (n == name) {
mtx_unlock(sw_dev_mtx);
- xs.xsw_version = XSWDEV_VERSION;
- xs.xsw_dev = sp-sw_dev;
- xs.xsw_flags = sp-sw_flags;
- xs.xsw_nblks = sp-sw_nblks;
- xs.xsw_used = sp-sw_used;
+ xs-xsw_version = XSWDEV_VERSION;
+ xs-xsw_dev = sp-sw_dev;
+ xs-xsw_flags = sp-sw_flags;
+ xs-xsw_nblks = sp-sw_nblks;
+ xs-xsw_used = sp-sw_used;
- error = SYSCTL_OUT(req, xs, sizeof(xs));
- return (error);
+ return (0);
}
n++;
}
@@ -2396,6 +2415,24 @@
return (ENOENT);
}
+static int
+sysctl_vm_swap_info(SYSCTL_HANDLER_ARGS)
+{
+ int *name = (int *)arg1;
+ int error;
+ struct xswdev xs;
+
+ if (arg2 != 1) /* name length */
+ return (EINVAL);
+
+ error = swap_info(*name, xs);
+ if (error != 0)
+ return (error);
+
+ error = SYSCTL_OUT(req, xs, sizeof(xs));
+ return (error);
+}
+
SYSCTL_INT(_vm, OID_AUTO, nswapdev, CTLFLAG_RD, nswapdev, 0,
Number of swap devices);
SYSCTL_NODE(_vm, OID_AUTO, swap_info, CTLFLAG_RD, sysctl_vm_swap_info,
--- a/sys/vm/swap_pager.h
+++ b/sys/vm/swap_pager.h
@@ -83,6 +83,8 @@
int swap_pager_reserve(vm_object_t, vm_pindex_t, vm_size_t);
void swap_pager_status(int *total, int *used);
void swapoff_all(void);
+int swap_info(int name, struct xswdev *xs);
+int swap_devname(int name, char *devname, size_t len);
#endif/* _KERNEL */
#endif/* _VM_SWAP_PAGER_H_ */
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
