New release of ngacl

[Stefan (metze) Metzmacher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christoph Klein schrieb:
> Hi there,
> though it seems to me, that interest is little for my tiny project, i
> try once again to gain some attention.
sorry, I didn't know about it, till now:-)

> Following your list, i had the impression, that development of ntacl-lsm accellerated last weeks. So me too i had spend some more time on my lsm. 
> I still think, it would be useful to throw our lsms togeteher, though up to now nobody could explain to me, what the advanteges of storing full nt-secdescs are.
> They have to be converted every time they are used, and this process doenst
> seem to be simple.
I think one of the principles of kernel development
> is, to do just a few, minor things in kernelspace and everything that
> can be done within userpace should be done in userspace. The second
> point is, that i dont see, how you want to resolve SIDs within the
> kernel?

The idea I have is:

1) having a real security_token with SIDs and privileges stored on each task_struct->security.
   and having the unpacked security_descriptor hanging on each inode->i_security.
   and then do we can provide real NT ACL semantics.

2) the idea to sync the posix acls with the nt acls, was to control
   the hooks which modify them and then ask a userspace tool to map them,
   and then both are stored on disk.

3) when the task_struct doesn't have a nt security_token, the capablity lsm functions
   are called to just check the unix uid/gid's against the posix acl

I'm currently mostly care about 1) and 3) to find out what is actually possible.
also I'm currently doesn't care much about locking and parallel access to an inode,
while changing it's acl. (I'm new to kernel development and first need to find out what of this
stuff is needed)

I think it would be a good idea to just have one lsm that handle different kind of ACLS,
but after a quick look at your kernel module code, there're some basic changes needed.

The main thing, I want to avoid is that we need any mapping of kernel acls to the NTACLS
provided by samba. So the best thing for this is to just use NTACLS in the kernel, or to have
something, that can be mapped 1 to 1 with loosing information.

the another idea is to use acls which use the same access bits, and use generic security identifier
( don't mean NT SID's hear)

so maybe to have a
struct security_identifier {
	enum {UID_T, DOM_SID, FOO } level;
	union {
		uid_t uid;
		struct dom_sid;
		struct foo;
	} u;
};

and also have security_token's with this generic security_identifier

also the NTACLS have SACL's and DACL's we need to store whatevery a windows client wants us to
store, and if possible use this information in the same way the client would expect it.

Do you have any ideas, how we could solve your and our problem, in one module?

> So back to my developments: The newest verion is avaiable from
> http://prdownloads.sourceforge.net/ngacl/ngacl-snapshot-190805.tar.gz?download
> I hope the readme does now fully cover the installation process. Feel
> free to ask questions and send in bug reports or (even better) some
> patches.

- --
metze

Stefan Metzmacher <metze at samba.org> www.samba.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDBxJSm70gjA5TCD8RAghyAKCkLwlp8qPElUrSgfM0qAonQBZcLgCfYuVY
NOvwSqNZOt9v0EnTHmFJJbw=
=9ap8
-----END PGP SIGNATURE-----