fresh mac code report

[Brian F. Feldman]

"Ilmar S. Habibulin" <ilmar at watson.org> wrote:
> 
> 
> On Tue, 22 Jan 2002, Brian F. Feldman wrote:
> 
> > > I'm hardly imagine how to approach it. mtree files can be made
> > > automatically or edited by hands. If we create file by hands, then there
> > > is no problem. But if we use something automated, then how could mtree
> > > know of what kind of commands it must use in order to get and then to set
> > > something (extended file attributes). I'll think about it, but if you have
> > > some thought, share them please.
> > I was simply thinking along the lines that it's about as easy to type
> > "setfmac foo/bar {}" as it is "mac=foo/bar", and because of this it may not
> > be worth it specifically adding mac labeling support itself to mtree.
> Yes, i understand that. But you are talking about "making mtree files by
> hands" case. But i want to find some solution, that would help to do such
> thing automatically. I think, that adding some command switch like
> '-<switch> get-command set-command' is what we need. Maybe use of multiple
> switches for a set of commands is possible.

I'm largely skeptical about whether that would be a very clean solution.  
Multiple switches would be possible, but you would have to assume they all 
work the same way (command <filename> to get and command <value> <filename> 
to set) to be able to really get any use without greatly complicating the 
invocation and implementation, don't you think?

> > I don't understand; how do login and init factor into the operation of ssh?
> I think, that ssh trys to access raw terminal in order to get password.
> And terminal device label differs from users label. When i set them equal
> the problem have gone away.

Ah, that's what you mean;  I think that's probably the correct solution.
I'll check this out now.

> > What fmac are your files and pmac is X?  Have you tried adjusting the
> > location of the XAUTHORITY file to, e.g., /tmp and verified it works?
> biba/high on files, biba/low on user(process). That was default, now
> Robert have changed that. So do i, an no i have network and X working
> without enforce_* switch off. Robert said that it was a possible bug
> somewhere, because biba model was switched of too. Sorry, i have no time
> right now for a more deeper investigation of problems. And you have
> changes in sources, so i hope to continue my trouble searchung later,
> maybe in the next week.

I'll also see if I can't get XFree86 working today, too.

> > > > Note that in this case, startx starts with just the user's credentials, and
> > > > permissions needed by X are gained generally from a setuid flag on it or
> > > > Xwrapper.  Also, fd 0, 1, and 2 are all inherited from the context of the
> > > > initial startx executed and not modified, so will generally be the terminal
> > > > device itself.
> > > Ye, i know. I have no time right now to handle this, maybe later i'll try
> > > to understand what the problem is. But enforce_fs=0 helps. ;-)
> >
> > You haven't had any problems with XFree86's ioctl calls on the terminal
> > device, right?
> Yes, X server functions with out error messages on console. I've seen
> errors only from x-clients (xterm, mozilla) and xinit.

That makes sense.  Possibly, it should use syslog for its output; with xdm,
it would be attempting to write to the home directory instead of the console 
which would have similar results too, I'm sure.

> PS. What's the status of capabilities integration into -current?

Largely undecided.  It _looks_ to be very easy to integrate, and even turn 
on by default, but I haven't decided how easy it is to integrate with MAC 
(so I don't want to try to make things difficult right now, but I do want it 
to be in -CURRENT).

-- 
 Brian Fundakowski Feldman           \  FreeBSD: The Power to Serve!  /
 green at FreeBSD.org                    `------------------------------'



To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message