On Fri, Jun 24, 2011 at 12:43 PM, Jeff Layton <jlayton@xxxxxxxxx> wrote: > On Mon, 20 Jun 2011 17:01:23 -0500 > shirishpargaonkar@xxxxxxxxx wrote: > >> From: Shirish Pargaonkar <shirishpargaonkar@xxxxxxxxx> >> >> >> Now build security descriptor to change either owner or group at the >> server. Initially security descriptor was built to change only >> ACL, that functionality has been extended. >> >> When either an Owner or Group of a file object at the server is changed, >> rest of security descriptor remains same (DACL etc.). >> >> To set security descriptor, it is essential to open that file >> with WRITE_DAC as well as WRITE_OWNER (Take Ownership) permission bits. >> Function set_cifs_acl_by_fid() has been removed since we can't be >> sure how a file was opened for writing, a valid request can fail >> if the file was not opened with two above mentioned permissions. >> >> It is the server that decides whether a set security descriptor with >> either owner or group change succeeds or not. >> > > I'd like to see an explanation for what problem this solves and why > this is useful. > > Why should I care about this set? With this, what can I do that I > couldn't do before -- chown()/chgrp()? Also, how was this set tested? > In particular I'd like to understand how you tested the part that > handles chown(). Doesn't that require mounting as a user that has > elevated permissions? > > -- > Jeff Layton <jlayton@xxxxxxxxx> > Jeff, basically, cifs client is making sure that when it sends a security descriptor to be set, it sends with a valid and legit SID, otherwise it does not. It does not change the DACL. And then let the server decide whether set security descriptor should succeed or not. If the authenticated user does not have write_owner and write_dac permissions on the object, open at the server would fail too so there would not be any set security descriptor call going through to the server at all. Regards, Shirish -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
