#7 Security issues that need to be worked out.
As of right now, there are (and always have been) some
issues with trustees.
For example, if I give someone full rights to /var/www,
and take away all their rights to /var/www/blah. They
can easily go into /var/www, rename blah, change stuff,
and rename it back.
I have thought about this a lot. The only solution
that I can currently come up with is how I currently
handle renames of files with hardlinks: return an error
code on the rename operation that the two names are on
different filesystems, and good tools should handle it
correctly by copying/removing. This would ensure that
permissions are correctly handled in all cases.
However, I need to come up with a fast way in a rename
operation to determine if the destination and source
entry have different trustees applied to them or any of
their contained files/directories. This is a bit
difficult without causing slowdowns when there are
large amounts of trustees.....
- Andy
Logged In: NO
What about a flag on all directory dentries that simply says
whether or not there is any trustee information in it or
not. When a directory gets it's trustee's modified, it can
reset the flag. If it was removed, it can check for flags on
it's subdirectories, and check for other trustees on it, and
if there are none, continue up the tree removing flags as
needed.
Then at least you would know whether or not a tree required
searching, and you could follow the flags accordingly. This
should be pretty quick assuming that there aren't too many
entries in the lower levels. It would also be nice that
you've only ever got to run that check on directory renames,
so your average file accesses shouldn't really be affected.
It might actually even be nice if instead of a flag/bit, it
was actually an integer with a count of the trustees records
below. I'm not sure why it would be useful.. maybe if the
tools could tell you the count an admin would like to know.
It's probably about the same to impliment either way, but
the count would be more flexable, and force you to keep
really strict accounting of everything which might be nice.
Logged In: NO
Maybe I'm not thinking this through all the way, but in the example, why don't you just deny renaming /var/www/blah (with a regular "permission denied" error)? I guess it might require a kernel patch, since you now have to check permissions on both the object you're renaming as well as the directory that contains it. But since you're denied rights to /var/www/blah, it makes sense that you shouldn't be able to rename it, even if you have rights to the object above it. At least, since we can't make the trustee rights move with the object we're renaming.
I don't see why this would require any extra flags; shouldn't it just be a simple check if the user has permission on both objects?
Logged In: YES
user_id=549930
Originator: YES
Well, the problem gets even more complicated, let's say I give someone full perms to:
/var/www/blah/foo
and I take away all their rights to foo, so now they can still go
cd /var/www
mv blah blah2
modify blah2/foo
So, not only do you have to check directories themselves, you have to ensure
that all subdirectories do not have trustees.
I guess I didn't really cover that in the original example :)