Re: Add setacl system call?
On Mon, 25 Jul 2011, exorcistkiller wrote: Another question while I'm reading the code. In ufs_acl.c, in static int ufs_getacl_posix1e(struct vop_getacl_args *ap), you commented: As part of the ACL is stored in the inode, and the rest in an EA, assemble both into a final ACL product. From what I learned from Kirk's book, ACLs are supposed be stored in extended attributes blocks. So what do you mean by "part of the ACL is stores in the inode"? I know extended attributes blocks data can be addressed by inode, but how to get ACL directly from the inode? POSIX.1e ACLs are defined as an extension to permissions: additional user entries, group entries, and a mask entry supplement the existing owner, group and other permission bits. Both the APIs and command line tools allow the portions of the ACL representing permission bits to be directly manipulated. For the purpose of the UFS implementation (and I suspect this to be common in other implementations as well), we keep the owner/group/other bits (or sometimes the mask bits) in the existing inode permissions field. All additional entries are stored in the extended attribute. This has some nice properties, not least: (1) stat(2) on the file still only needs look at the inode, not the extended attributes, making it faster. (2) chmod(2) can be implemented by writing out only the inode, also faster. (3) Files without extended ACLs don't need extended attributes stored. The inclusion of a "mask" field in POSIX.1e is motivated similarly: it is what allows stat(2) and chmod(2) to not touch extended ACL fields. This is what the commend means by part of the ACL being stored in the inode, and part in the extended attribute: any areas of an ACL that are actually permission mask entries go in the existing mode bits in the inode for efficiency reasons. Robert ___ 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: HTT vs SMT in x86 SMP topology reporting
On Tue, 26 Jul 2011, Andriy Gapon wrote: Can anybody explain to me why our _x86_ SMP topology discovery and reporting code sometimes reports "HTT" and sometimes "SMT"? As in FreeBSD/SMP: %d package(s) x %d core(s) x %d HTT threads vs FreeBSD/SMP: %d package(s) x %d core(s) x %d SMT threads As I understand, and quoting Wikipedia (I know, I know), SMT stands for simultaneous multithreading and is a generic term for a particular kind of hardware multithreading: http://en.wikipedia.org/wiki/Simultaneous_multithreading The only known (to me) implementation of SMT for x86 is Intel's Hyper-Threading Technology aka HTT aka HT Technology aka hyperthreading: http://en.wikipedia.org/wiki/Hyper-threading http://software.intel.com/en-us/articles/intel-hyper-threading-technology-your-questions-answered/?wapkw=%28Intel+Hyper-Threading+Technology%29 Several MIPS platforms we run on support SMT. Typically this means a set of "weaker" threads sharing a single core, usually context switching as a result of memory access stalls in other threads, and perhaps sharing particularly expensive CPU features, such as a TLB. They sometimes come with high-performance message-passing facilities between threads, or even between cores, to supplement shared memory and IPIs. It may be that HTT is, among other things, a trademark of Intel. Robert ___ 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: Finding symlink information in MAC Framework
On Wed, 27 Jul 2011, per...@pluto.rain.com wrote: > s wrote: > > > ... I am trying to compare the owner of the symlink to the owner > > of what the symlink points to ... At first I was trying to check > > wheter some user is trying to create such a symlink ... > > I've always considered the "ownership" and "permissions" of a > symlink to be an artifact of the implementation, rather than > having any real significance. > > Symlinks did not exist in Bell Labs Unix, at least as of > 6th edition. IIUC they were invented at UCB to get around > the limitation that a hard link could not cross a physical > filesystem boundary (i.e. a mount point); symlinks would > not have been needed had the entire logical filesystem been > contained on a single, unpartitioned physical device because > hard links could have been used instead. One additional thing that symlinks manage to do is to refer to directories as well as files; 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". > Getting back to the original problem, suppose you had no mounted > filesystems (other than special cases like devfs or /proc), the > entire logical filesystem tree being stored on a single device, so > that any file on the system could be hard-linked into any directory > on the system. How would you detect that "some user" had created a > _hard_ link to some arbitrary file? FWIW one of the early unix systems I was exposed to permitted the creation of hard links by arbitrary users. This led to a denial of service situation whereby the original creators of files could be deprived of inodes in the quota system, and blocks too if they removed one of their files without checking if anyone else had it linked first. It was a multiuser system that hosted undergraduates, so obviously this wasn't just a theoretical problem. -- jan grant, University of Bristol. But not for much longer! Update your address books: j...@ioctl.org http://ioctl.org/jan/ Q: What's yellow and equivalent to the axiom of choice? A: Zorn's lemon. ___ 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"
MAC Framework, Socket information
Hi,
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:
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"
A style proposal for referring to upper-level directories in Makefiles
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. For one this speeds up
the filesystem-traversal for the invoked tool. And, perhaps more importantly, it
makes the various build-logs look nicer (and be smaller). The lines in Makefiles
will also be shorter (two characters per level instead of three). For example:
--- secure/Makefile.inc 3 Aug 2009 08:13:06 - 1.25.10.1
+++ secure/Makefile.inc 28 Jul 2011 18:45:52 -
@@ -3,8 +3,8 @@
.include
-.if exists(${.CURDIR}/../../lib/libcrypt/obj)
-CRYPTOBJDIR= ${.CURDIR}/../../lib/libcrypt/obj
+.if exists(${.CURDIR:H:H}/lib/libcrypt/obj)
+CRYPTOBJDIR= ${.CURDIR:H:H}/lib/libcrypt/obj
.else
-CRYPTOBJDIR= ${.CURDIR}/../../lib/libcrypt
+CRYPTOBJDIR= ${.CURDIR:H:H}/lib/libcrypt
.endif
@@ -14,4 +14,4 @@
.if ${MK_OPENSSH} != "no"
-SSHDIR=${.CURDIR}/../../../crypto/openssh
+SSHDIR=${.CURDIR:H:H:H}/crypto/openssh
.endif
The new method is functionally equivalent to the old and I see no drawbacks to
it, do you?
-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: A style proposal for referring to upper-level directories in Makefiles
On 28 July 2011 19:47, Mikhail T. wrote:
> 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. For one this speeds
> up the filesystem-traversal for the invoked tool. And, perhaps more
> importantly, it makes the various build-logs look nicer (and be smaller).
> The lines in Makefiles will also be shorter (two characters per level
> instead of three). For example:
>
> --- secure/Makefile.inc 3 Aug 2009 08:13:06 - 1.25.10.1
> +++ secure/Makefile.inc 28 Jul 2011 18:45:52 -
> @@ -3,8 +3,8 @@
> .include
>
> -.if exists(${.CURDIR}/../../lib/libcrypt/obj)
> -CRYPTOBJDIR= ${.CURDIR}/../../lib/libcrypt/obj
> +.if exists(${.CURDIR:H:H}/lib/libcrypt/obj)
> +CRYPTOBJDIR= ${.CURDIR:H:H}/lib/libcrypt/obj
> .else
> -CRYPTOBJDIR= ${.CURDIR}/../../lib/libcrypt
> +CRYPTOBJDIR= ${.CURDIR:H:H}/lib/libcrypt
> .endif
>
> @@ -14,4 +14,4 @@
>
> .if ${MK_OPENSSH} != "no"
> -SSHDIR= ${.CURDIR}/../../../crypto/openssh
> +SSHDIR= ${.CURDIR:H:H:H}/crypto/openssh
> .endif
>
> The new method is functionally equivalent to the old and I see no drawbacks
> to it, do you?
>
> -mi
Not too convinced I'm afraid-- in the logs I can at least see at a
glance where ${CURDIR} is, and how many directories it's traversing
etc etc.
Chris
___
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
On Thu, Jul 28, 2011 at 11:47 AM, Mikhail T. wrote:
> 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. For one this speeds
> up the filesystem-traversal for the invoked tool. And, perhaps more
> importantly, it makes the various build-logs look nicer (and be smaller).
> The lines in Makefiles will also be shorter (two characters per level
> instead of three). For example:
>
> --- secure/Makefile.inc 3 Aug 2009 08:13:06 - 1.25.10.1
> +++ secure/Makefile.inc 28 Jul 2011 18:45:52 -
> @@ -3,8 +3,8 @@
> .include
>
> -.if exists(${.CURDIR}/../../lib/libcrypt/obj)
> -CRYPTOBJDIR= ${.CURDIR}/../../lib/libcrypt/obj
> +.if exists(${.CURDIR:H:H}/lib/libcrypt/obj)
> +CRYPTOBJDIR= ${.CURDIR:H:H}/lib/libcrypt/obj
> .else
> -CRYPTOBJDIR= ${.CURDIR}/../../lib/libcrypt
> +CRYPTOBJDIR= ${.CURDIR:H:H}/lib/libcrypt
> .endif
>
> @@ -14,4 +14,4 @@
>
> .if ${MK_OPENSSH} != "no"
> -SSHDIR= ${.CURDIR}/../../../crypto/openssh
> +SSHDIR= ${.CURDIR:H:H:H}/crypto/openssh
> .endif
>
> The new method is functionally equivalent to the old and I see no drawbacks
> to it, do you?
This might cause issues with symlink traversal (it's the one thing
that came to mind). It wouldn't be a standard way to do things, but it
could cause problems if this change was made.
Thanks,
-Garrett
___
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"
[PATCH] Linux-like /proc/swaps for linprocfs
Please consider this patch, it implements Linux-like /proc/swaps for linprocfs.
E.g.
$ cat /proc/swaps
FilenameTypeSizeUsedPriority
/dev/zvol/dimoni/swap unknown 2097152 0 -1
--
Robert Millan
--- a/sys/compat/linprocfs/linprocfs.c
+++ b/sys/compat/linprocfs/linprocfs.c
@@ -498,6 +498,44 @@
return (0);
}
+static int
+linprocfs_doswaps(PFS_FILL_ARGS)
+{
+ struct xswdev xsw;
+ int mib[3], mibsize;
+ size_t size;
+ int n;
+ long long total, used;
+ char devname[SPECNAMELEN + 1];
+
+ sbuf_printf(sb, "Filename\t\t\t\tType\t\tSize\tUsed\tPriority\n");
+
+ mibsize = sizeof mib / sizeof mib[0];
+
+ mib[0] = CTL_VM;
+ mib[1] = VM_SWAP_INFO;
+
+ for (n = 0; ; n++) {
+ mib[2] = n;
+ size = sizeof(xsw);
+ if (kernel_sysctl(td, mib, mibsize, &xsw, &size, NULL, 0,
+ NULL, 0) != 0)
+ break;
+
+ size = sizeof(devname);
+ if (kernel_sysctlbyname(td, "kern.devname", devname, &size,
+ &xsw.xsw_dev, sizeof (xsw.xsw_dev), NULL, 0) != 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%u\t%u\t-1\n", devname, total, used);
+ }
+
+ return (0);
+}
+
/*
* Filler function for proc/uptime
*/
@@ -1486,6 +1524,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
@@ -2398,7 +2398,7 @@
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,
+SYSCTL_NODE(_vm, VM_SWAP_INFO, swap_info, CTLFLAG_RD, sysctl_vm_swap_info,
"Swap statistics by device");
/*
--- a/sys/vm/vm_param.h
+++ b/sys/vm/vm_param.h
@@ -84,7 +84,8 @@
#define VM_V_PAGEOUT_FREE_MIN 9 /* cnt.v_pageout_free_min */
#define VM_PAGEOUT_ALGORITHM 10 /* pageout algorithm */
#define VM_SWAPPING_ENABLED 11 /* swapping enabled */
-#define VM_MAXID 12 /* number of valid vm ids */
+#define VM_SWAP_INFO 12 /* swap_info */
+#define VM_MAXID 13 /* number of valid vm ids */
#define CTL_VM_NAMES { \
{ 0, 0 }, \
@@ -99,6 +100,7 @@
{ "v_pageout_free_min", CTLTYPE_UINT}, \
{ "pageout_algorithm", CTLTYPE_INT}, \
{ "swap_enabled", CTLTYPE_INT},\
+ { "swap_info", CTLTYPE_STRUCT},\
}
/*
___
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: [PATCH] FreeBSD compiler extensions
Submitted as PR so that it's not forgotten: http://www.freebsd.org/cgi/query-pr.cgi?pr=159278 -- Robert Millan ___ 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: [PATCH] __FreeBSD_cc_version in
Submitted as PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=159279 -- Robert Millan ___ 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: [PATCH] Improve utf-8 -> cp437 console map
Submitted as PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=159280 2011/7/10 Robert Millan : > This patch adds a few improvements to utf-8 -> cp436 console map > (mostly with Catalan characters in mind, but it probably benefits > other languages). > > The new mappings are as follows: > > ▮ -> █ > ÀÈÍÏÓÒÚ -> AEIIOOU > ŀ / Ŀ -> l / L > > -- > Robert Millan > -- Robert Millan ___ 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: [PATCH] Linux-like /proc/swaps for linprocfs
On Fri, Jul 29, 2011 at 01:15:59AM +0200, Robert Millan wrote: > Please consider this patch, it implements Linux-like /proc/swaps for > linprocfs. > > E.g. > > $ cat /proc/swaps > FilenameTypeSizeUsed > Priority > /dev/zvol/dimoni/swap unknown 2097152 0 -1 > > -- > Robert Millan 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. pgpWfXDOOYNOR.pgp Description: PGP signature
