capabilities impletementation?

[Robert Watson]

On Fri, 2 Dec 2005, Yanjun Wu wrote:

> My approach is:  Fetch the SEBSD source from the current perforce deposit, 
> and move it FreeBSD6.0; whenever there is a conflict, try to meet FreeBSD6.0 
> first. Now I have made the FreeBSD6.0 source with SEBSD compilable and 
> bootable. However, there are many bugs remains. For example, to make things 
> compilable before I get clear understand about devfs, I drop the "fullpath" 
> parameter of the create_devfs_directory and create_devfs_directory, then try 
> to get the path of dev inside the entry points. Later I found the directory 
> /dev/fd/ is not correctly labeled. It is labeled as device_t instead of the 
> correct removable_device_t.

Regarding the devfs diffs present in the MAC and SEBSD branches -- I built a 
small MAC module to try and determine what the impact of the changes was 
(mac_devfs) which simply prints out messages if the path and fullpath 
arguments differ.  The answer appears to be that they do not differ in any 
realworld cases, at least with the devfs objects I tried.  The case I haven't 
tried is how it handles a multi-level directory under devfs -- i.e., 
/dev/foo/bar/baz, where I think the arguments may differ.  My leaning is that 
we should remove the additional argument, but change the current argument to 
define that it is nul-terminated rather than length limited.  Right now, we 
guarantee a nul termination, but it may be beyond the segment of the path 
we're specifically looking at.  I.e., for /dev/foo/bar/baz, the directory call 
may receive string "foo/bar/baz" but length 3 to indicate that the first 
segment is being considered.  We should instead simply pass in "foo", which 
may be what the fullpath logic is intended to do.  We can probably accomplish 
the same thing in a much more simple way by simply creating a short buffer in 
the stack and using strlcpy.

> But the files 0, 1, 2 are label correctly with removable_device_t. Here I 
> attached the sebsd.c.diff to show my small changes against the current 
> sebsd.c in SEBSD perforce deposit. Any suggestions are appriciated.

/dev/fd/* represent file descriptors of the current process, rather than 
floppy disk drives.  I'm not entirely sure how they should be handled: when 
accessed, they directly manipulate the file descriptor array of a process to 
produce an additional reference to the same open struct file (which in turn 
might point to a fifo, file, directory, socket, etc).  Some special label is 
probably required simply to indicate that no checks are required for open, as 
the process already has the right to hold the initial file descriptor. 
However, most processes should not be able to unlink the nodes (etc), which 
will need to be captured by the SEBSD TE policy.

Robert N M Watson


>
>
> On Wednesday 30 November 2005 16:12, Dingo wrote:
>> seems like you and I are duplicating efforts, maybe as robert suggested
>> we might want to do this as a team effort, might go faster. he mentioned
>> Scott Long possibly giving some guidance and using the perforce tree to
>> do the work in. you want to drop me a snapshot tar or cvs export and ill
>> diff what ive done against what you have. Robert/Scott you guys want to
>> push us forward a bit? i know the cap issue is there, maybe we can all
>> tackle this together as Robert suggested
>>
>> On Tue, 2005-11-29 at 12:17 +0000, Yanjun Wu wrote:
>>> I have written "SEBSD Getting Started HOWTO" for the past Google Summer
>>> of Code. The PDF version is attached. Hope it useful for anyone who would
>>> like to involve SEBSD development and test.
>>> Now I am trying to merge SEBSD into FreeBSD 6.0 Release in my local
>>> machine. Most of things in current SEBSD branch seems OK to directly port
>>> to FreeBSD 6.0R, except for create_devfs_xxx and mount related
>>> entrypoints Robert had mentioned before.
>>
>> To Unsubscribe: send mail to majordomo at trustedbsd.org
>> with "unsubscribe trustedbsd-discuss" in the body of the message
>
To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message