First let me point out that reviewing patches is always a lot of work.You are right. I appreciate your comments and thank you.
What you've done here by posting an entirely new 30-patch implementation
of tomoyo when (I hope) you're not even serious about that is to
basically tell us our time means nothing to you...
If you *are* serious about it, than to whatever extent I can, which
isn't very much, I say nack.
Like you say there appear to be no real remaining objections to the LSM,What annoyed us was the fact we didn't know how the merge would take place.
only to the VFS part. You're going to try to get around the VFS
objections by not being an LSM?
Look right now TOMOYO is an out of tree patch. You want to get it inYes.
tree. Don't be too hung up on getting it all in at once. Why not
push a subset of the patch without the vfs controls, which will help
to motivate the vfs controls you need? You can (1) keep a much smaller
out of tree patch with your implementation of the vfs controls for your
current customrs/installations, and/or (2) implement a temporary
non-pathname-based alternative, say using xattrs to tag files at setup
time - probably insufficient, but sufficient for people to play.
The smaller patch would also be easier to review.Yes.
Yes, it was ... really surprising. (I was even scared)Let me explain the reason and the history.
We remember the history. On the one hand we feel for you, but on the
other hand many of us have gone through the same thing, and if you'll
notice Casey went through the same thing and persisted.
It's a great pleasure to receive comments from people.We started developing TOMOYO Linux as original patch sets against
2.4 vanilla kernel. We understand the role of LSM, so we ported
TOMOYO Linux to use LSM and submitted it to the LKML on 13 June 2007.
We kept working to reflect feedbacks from the community and believe
no critical Nack remains.
Right, at this point it's mainly a question of finding a way to upstream
tomoyo. (That's mainly *your* burden, but we do try to help :)
Yes, but he didn't say you could implement it in a way that offends theI couldn't agree with you more. I'll never quote that. :)
affected maintainers. Nor did he say it's those maintainers'
responsibility to find you an acceptable solution. They are in fact
being very nice by offering you suggestions.
Also, isn't Miklos helping you to try and find an acceptable approach?We started following the thread and found it's very close to
Right and I am ashamed of it now.Current LSM implementation is sufficient for SELinux
and other label based MACs but not for pathname-based MACs.
This has been argued in the AppAmor thread for quite a long time.
Though proposals had been posted by AppArmor and TOMOYO Linux project,
none has been merged until now.
You're trying to make it sound like you've spent night and day for years
trying to work with the relevant people to come up with something
reasonable. Yet for instance in the thread "vfs: add helpers to check r/o bind mounts"
(april 2) where iiuc two reasonable approaches are discussed, you don't
even take part.
Thank you. (T_T) (crying)We apologize for the confusion we caused in the last posting,
but we don't want to give up returning our work to the mainline.
I'm glad to hear that. Please keep trying.
I wish I could revoke the above statement...We cordially request LSM changes to pass vfsmount parameters.
Again let me point out there is a difference between saying "Linus saidRoger. (_ _) (bowing)
we can have pathname-based access control, but you won't implement it
for me" and doing the hard work to come up with something reasonable.
I know you've tried a few times, but from what I've seen your impression
of the work you've put into it is far different from my impression of
it.