Darren J Moffat <[EMAIL PROTECTED]> wrote: > On Fri, 2006-01-27 at 04:31, Joerg Schilling wrote: > > Then it makes sense to also look at my proposal about the O_NONE > > flag because this proposal helps to avoid "file_dac_read" in many cases. > > Where would I find that proposal ?
I did sent it more or less together with this proposal. I'll add it to the end of this mail.... > > I don't like to be forced to do this and I would like to find a way > > that has OS dependent information in files. This could be done if > > there was a negotiation on the way Solaris extended attributes should > > be used on various other OS (NFSv4 brings them to the other OS....). > > Solaris privileges certainly don't make sense on any other system. > Some subset of them might but not all of them. Looks like you did read too quick.... This is not "Solaris privileges" but "Solaris extended attributes". > MAC labels yes most certainly I'd love to have them cross platform. This would be harder to manage. Similar to "Solaris privileges", you cannot expect that other OS use the same way of defining MAC labels. > > I only have experiences where I did already implement things.. > > Do you have any pointers to the MacOS X interface? > > http://arstechnica.com/reviews/os/macosx-10.4.ars/7 >From a quick look, this looks like the Linux interface that I don't really >like. It is a bit unflexible and (more important) it reveals implementation details in a way that forces you to filter away kernel/FS internal attributes in order to prevent seeing things twice: Note that FreeBSD as well as Linux implement ACLs inside system xattrs. Star has e.g. to filter away: "system." and "xfsroot.". Such an implementation tends to be unstable and create the need for frequent application changes. The O_NONE proposal: /*--------------------------------------------------------------------------*/ Date: Thu, 26 Jan 2006 12:11:59 +0100 To: [email protected] Subject: open(2) proposal for POSIX and fine grained privileges Background: Sun (Don Cragun) recently send a proposal to the POSIX standard commitee for integrating the openat() style group of interfaces. Note that the official purpose for adding this to the standard was not extended file attributes but to provide a way to deal with infinite path names. After this was done, people found that the openat() interface has a deficite because you may be able to open("dir" "/" "file", ...) but not able to open("dir", ...); Another issue I like to ddress is that when I try to run cdrecord root-less, I need "file_dac_read" to open a device and "sys_devices" to use USCSI. Having "file_dac_read" would cause cdrecord to be able to burn any local file to a CD which is not desirable. There are two possible solutions: - use something like /dev/scg* and allow it to be opened by anyone. - allow nodes like e.g. /dev/rdsk/* to be opened without read/write permissions to later let the "sys_devices" or in future ""sys_scsi_*" privileges to the real work. I would like to see a general solution for both problems noted above. A possible solution could look this way: Introduce a new open(2) flag: O_NONE that allows to open a file without getting read or write permissions. Then you have a fd that could be used for the USCSI ioctl after the related function in the driver checks for the sys_scsi_* privileges. This is nothing new: On UNOS (a hard realtime aware UNIX clone from 1982), there was no stat() syscall. In order to do the equivalent of a stat() call, you did do th following: fd = Jopen(name, ""); ret = fstat(fd, &statbuf); Jclose(fd); return (ret); And as recently discussed on the POSIX standard mailing list related to a conceptional deficit of the Sun openat() interface, I like to forward the proposal from the POSIX mailinglist: Doing: fd = open("dir", O_READ); fd2 = openat(fd, "name", O_READ); could fail where fd2 = open("dir" "/" "name", O_READ) succeeds because of missing read permissions on "dir". The POSIX proposal was: fd = open("dir", O_DIR); /* succeeds if search permission is present */ fd2 = openat(fd, "name", O_READ); This is exactly what we need, so I propose a new O_NONE flag for open(2) which is the same as the O_DIR flag mentioned by the people from the POSIX standard mailing list. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED] (uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily _______________________________________________ opensolaris-code mailing list [email protected] https://opensolaris.org:444/mailman/listinfo/opensolaris-code
