Michael Herf <[email protected]> wrote:
Hi Alan -- thanks, I didn't know about the DOS bits,
though I'd found the Windows ACLs (which most users
don't know about and apps don't use much.)
I don't understand this comment. ACLs have been around for
a long time and represent (I hope) a well-known, fundamental
security mechanism.
I've learned that it is actually possible to adjust UNIX "chmod"
permissions through Windows owner-ACLs.
Yes, you can use 'chmod' and 'ls' to manage ACLs, in addition
to Windows desktop or command line tools.
However, it's important to say that this isn't a good solution
for Windows users. Windows makes considerable effort to
hide the ACL system from users - the "read-only" DOS
attribute is super-easy for a user to adjust, but changing the
owner-ACL requires one to enable an obscure setting.
Windows makes it very easy to manage ACLs (the Permissions tab).
I don't understand your reference to enabling an obscure setting.
So this is a big hole in basic usability--the average user who
"owns" a read-only CIFS file will be able to do nothing at all
with it. Not delete it or rename it, or make it writable.
If I make all files writable on the UNIX side, it appears as if
the DOS bits do work as you say, and this would indeed work
if people only ever used a Windows client.
Again, I don't understand these comments. The read-only bit is not
specific to Windows clients (it applies to all processes on the OS)
and users can do whatever is permitted by the ACL. If you are not
getting the results you expect, look at the ACL.
But there are many cases where UNIX and Windows usage
overlap (e.g., uploading files to a live webserver). Also, many
Windows applications use the read-only bit as a lightweight
form of file locking, so it seems as if making that visible on the
UNIX side would be preferable to making it a private "DOS" bit.
The DOS bits are visible on the UNIX side ('ls -/ c' or 'ls -/ v'), and
they should behave correctly from a Windows application perspective.
Similarly (my case!) this makes migration from an existing Samba
install hard, since the administrator has to remap all the attributes.
So, even if the default isn't changed, I'd like a way to turn on the
normal Samba behavior - is there a way to expose this option as
a setting?
I'm not sure what you mean by "default" but the intent of the CIFS
service is to provide SMB interoperability for the OpenSolaris OS,
not to behave like Samba. The CIFS service leverages native
OpenSolaris operating system and file system features. Samba is
a user space application that runs on a variety of UNIX operating
systems, which results in making/accepting certain compromises to
provide portability. It doesn't make sense to compromise an OS
service to make it behave like a particular application.
Alan
_______________________________________________
cifs-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
