access control for networked file server

--===============1216106028==
Content-Type: multipart/alternative; 
	boundary="----=_Part_17901_7552800.1180903862806"

------=_Part_17901_7552800.1180903862806
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Dear all,

I am writing a user-level networked file system with a user-level networked
file server. My server simply receives requests from its clients over TCP
and performs the necessary requested operations on the files stored locally
at the server. Right now the server is not run as root, but it can be, if
necessary.

I want to add support for POSIX ACL to the server and I am not able to
figure out what would be the best way to do it. I need some advise for this.

I was thinking of using one of the two options:

1) Since the server is running at user-level, let the underlying file system
take care of the access control. I am using reiserfs as the underlying file
system, which supports posix acls. But the problem is following: while
performing file system operations (such as read, write, open etc) how can
the file server supply to the underlying OS/FS the userid and groupid of the
user that is requesting the operation? Because the userid and groupid of the
requester should be used to check acls and not the effective userid and
groupid of my file server process. Is it possible to tell the underlying
fs/os to use a particular <userid, groupid> rather than the one used by the
server?


2) If the file server cannot specify the <userid, groupid> for every file
system call, then I can do the following: I can create a userid and groupid
that will be the effective userid and groupid of the file server. All files
created on the server will always have ACL_USER_OBJ and  ACL_GROUP_OBJ as
this userid and groupid. This userid and groupid will have full permissions
on the files, but only the file server will be able to use these ids. Thus,
when the underlying OS/FS checks for acl the permissions will be always
granted.

Now the check/set user's access permissions, my file server will use the
functions provided in  acl(5) to manipulate acls. The file server will check
if the user has appropriate permissions, and if yes perform the
read/write/open system calls during which the OS/FS will use the <userid,
groupid> of the file server which has full permissions.

Thus, there will be two levels of acls - one with default userid, groupid
will be used to make sure that the OS grants the file server all rights for
the files *created* at the server and the second level is the acls
maintained by my file server which will be used by the file server to check
of the requester has the necessary permissions.

Can anyone please suggest whether the first approach is feasible and whether
the second approach is sensible or not? Your help will be greatly
appreciated.

Thanks.

-- Fantoosh

------=_Part_17901_7552800.1180903862806
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div>&nbsp;</div>
<div>Dear all,</div>
<div>&nbsp;</div>
<div>I am writing a user-level networked file system with a user-level networked file server. My server simply receives requests from its clients over TCP and performs the necessary requested operations on the files stored locally at the server. Right now the server is not run as root, but it can be, if necessary.
</div>
<div>&nbsp;</div>
<div>I want to add support for POSIX ACL to the server and I am not able to figure out what would be the best way to do it. I need some advise for this.</div>
<div>&nbsp;</div>
<div>I was thinking of using one of the two options:</div>
<div>&nbsp;</div>
<div>1) Since the server is running at user-level, let the underlying file system take care of the access control. I am using reiserfs as the underlying file system, which supports posix acls. But the problem is following: while performing file system operations (such as read, write, open etc) how can the file server supply to the underlying OS/FS the userid and groupid of the user that is requesting the operation? Because the userid and groupid of the requester should be used to check acls and not the effective userid and groupid of my file server process. Is it possible to tell the underlying fs/os to use a particular &lt;userid, groupid&gt; rather than the one used by the server? 
</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>2) If the file server cannot specify the &lt;userid, groupid&gt; for every file system call, then I can do the following: I can create a userid and groupid that will be the effective userid and groupid of the file server. All files created on the server will always have ACL_USER_OBJ and&nbsp;&nbsp;ACL_GROUP_OBJ as this userid and groupid. This userid and groupid will have full permissions on the files, but only the file server will be able to use these ids. Thus, when the underlying OS/FS checks for acl the permissions will be always granted.
</div>
<div>&nbsp;</div>
<div>Now the check/set user&#39;s access&nbsp;permissions, my file server will use the functions provided in&nbsp;&nbsp;acl(5) to manipulate acls. The file server will check if the user has appropriate permissions, and if yes perform the read/write/open system calls during which the OS/FS will use the &lt;userid, groupid&gt; of the file server which has full permissions.
</div>
<div>&nbsp;</div>
<div>Thus, there will be two levels of acls - one with default userid, groupid will be used to make sure that the OS grants the file server all rights for the files *created* at the server and the second level is the acls maintained by my file server which will be used by the file server to check of the requester has the necessary permissions.
</div>
<div>&nbsp;</div>
<div>Can anyone please suggest whether the first approach is feasible and whether the second approach is sensible or not? Your help will be greatly appreciated. </div>
<div>&nbsp;</div>
<div>Thanks.</div>
<div>&nbsp;</div>
<div>-- Fantoosh</div>

------=_Part_17901_7552800.1180903862806--

--===============1216106028==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
acl-devel mailing list
[email protected]
http://acl.bestbits.at/mailman/listinfo/acl-devel

--===============1216106028==--