Hi there. We have something called system flags in FreeBSD. Those are bascially some additional flags you can set on files/directories (not extended attributes nor ACLs). http://www.freebsd.org/cgi/man.cgi?query=chflags&apropos=0&sektion=2&format=html http://www.freebsd.org/cgi/man.cgi?query=chflags&apropos=0&sektion=1&format=html Those are not hard to implement (partially), because there are spare fields in the znode_phys structure, but I''d like to coordinate this with you guys, so we won''t have problems when file system is moved from FreeBSD to Solaris. The other problem is that there is no spare room in ZIL structures, ie. I can''t add anything to lr_setattr_t, which won''t break on-disk compatibility. The suggested way of moving pools is to export it, move to antoher box and import it. Once pool is exported there should be no ZIL records to replay on import, so modifing lr_setattr_t size isn''t really critical, is it? What are your suggestions? -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20070412/69435868/attachment.bin>
Pawel Jakub Dawidek wrote:> Hi there. > > We have something called system flags in FreeBSD. Those are bascially > some additional flags you can set on files/directories (not extended > attributes nor ACLs). > > http://www.freebsd.org/cgi/man.cgi?query=chflags&apropos=0&sektion=2&format=html > http://www.freebsd.org/cgi/man.cgi?query=chflags&apropos=0&sektion=1&format=html > > Those are not hard to implement (partially), because there are spare > fields in the znode_phys structure, but I''d like to coordinate this with > you guys, so we won''t have problems when file system is moved from > FreeBSD to Solaris. The other problem is that there is no spare room in > ZIL structures, ie. I can''t add anything to lr_setattr_t, which won''t > break on-disk compatibility. The suggested way of moving pools is to > export it, move to antoher box and import it. Once pool is exported > there should be no ZIL records to replay on import, so modifing > lr_setattr_t size isn''t really critical, is it? > > What are your suggestions? >I am currently working on adding a number of the BSD flags into ZFS. I will be placing them in the upper half of the z_pflags field. -Mark
Pawel Jakub Dawidek <pjd at FreeBSD.org> wrote:> Hi there. > > We have something called system flags in FreeBSD. Those are bascially > some additional flags you can set on files/directories (not extended > attributes nor ACLs). > > http://www.freebsd.org/cgi/man.cgi?query=chflags&apropos=0&sektion=2&format=html > http://www.freebsd.org/cgi/man.cgi?query=chflags&apropos=0&sektion=1&format=html > > Those are not hard to implement (partially), because there are spare > fields in the znode_phys structure, but I''d like to coordinate this withI would like to see it also on UFS and UFS still has the unused space in the inode to implment it. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On Thu, 2007-04-12 at 14:09 -0600, Mark Shellenbaum wrote:> Pawel Jakub Dawidek wrote:> > What are your suggestions? > > > > I am currently working on adding a number of the BSD flags into ZFS.The existance of the FreeBSD port plus the desire to add a subset of the BSD file flags to solaris means that, IMHO, the less troublesome thing to do in the long run is to just add all of the BSD chflags(2) flags to ZFS now. (the "system" flags on *BSD are tied to securelevel; the closet solaris equivalent would be to define new "set system flag" and "clear system flag" privileges). - Bill
Bill Sommerfeld <sommerfeld at sun.com> wrote:> (the "system" flags on *BSD are tied to securelevel; the closet solaris > equivalent would be to define new "set system flag" and "clear system > flag" privileges).If that privilege is only present in single user mode and this way disallows to clear e.g. the append only flag in multi user mode it may work. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
zfs-discuss-bounces at opensolaris.org wrote on 04/12/2007 04:47:46 PM:> On Thu, 2007-04-12 at 14:09 -0600, Mark Shellenbaum wrote: > > Pawel Jakub Dawidek wrote: > > > > What are your suggestions? > > > > > > > I am currently working on adding a number of the BSD flags into ZFS. > > The existance of the FreeBSD port plus the desire to add a subset of the > BSD file flags to solaris means that, IMHO, the less troublesome thing > to do in the long run is to just add all of the BSD chflags(2) flags to > ZFS now.Or at least the ones Apple depends on. =)> > (the "system" flags on *BSD are tied to securelevel; the closet solaris > equivalent would be to define new "set system flag" and "clear system > flag" privileges). > > - Bill
On Thu, Apr 12, 2007 at 05:47:46PM -0400, Bill Sommerfeld wrote:> On Thu, 2007-04-12 at 14:09 -0600, Mark Shellenbaum wrote: > > Pawel Jakub Dawidek wrote: > > > > What are your suggestions? > > > > > > > I am currently working on adding a number of the BSD flags into ZFS. > > The existance of the FreeBSD port plus the desire to add a subset of the > BSD file flags to solaris means that, IMHO, the less troublesome thing > to do in the long run is to just add all of the BSD chflags(2) flags to > ZFS now. > > (the "system" flags on *BSD are tied to securelevel; the closet solaris > equivalent would be to define new "set system flag" and "clear system > flag" privileges).There''d have to be a way to drop these privs from L on all running processes, which there is, using ppriv(1). So I can see a service whose start method loops over listing all processes (but itself), dropping these privs from their L until no procs remain with these privs, then exit. Is that what you had in mind? A basic priv for setting/resetting UF_* would be nice too. Nico --
On Thu, 2007-04-12 at 17:26 -0500, Nicolas Williams wrote:> > (the "system" flags on *BSD are tied to securelevel; the closet solaris > > equivalent would be to define new "set system flag" and "clear system > > flag" privileges). > > There''d have to be a way to drop these privs from L on all running > processes, which there is, using ppriv(1). So I can see a service whose > start method loops over listing all processes (but itself), dropping > these privs from their L until no procs remain with these privs, then > exit. Is that what you had in mind?I think there very well may be a bunch of plausible alternative ways to exclude ''clear system flag bit'' from the L set; designing the full mechanism is probably best done elsewhere... - Bill
So you''re talking about not just reserving something for on-disk compatibility, but also maybe implementing these for Solaris? Cool. Might be fairly useful for hardening systems (although as long as someone had raw device access, or physical access, they could of course still get around it; that would have to be taken into account in the overall design for it to make much of a difference). Other problems: from a quick look at the header files there''s no room left in the 64-bit version of the stat structure to add something in which to retrieve the flags; that may mean a new and incompatible (with other chflags(2) supporting systems) system call? Also, there''s no provision in pkgmap(4) for file flags; could that be extended compatibly? This message posted from opensolaris.org
Pawel Jakub Dawidek wrote:> ... The other problem is that there is no spare room in > ZIL structures, ie. I can''t add anything to lr_setattr_t, which won''t > break on-disk compatibility. The suggested way of moving pools is to > export it, move to antoher box and import it. Once pool is exported > there should be no ZIL records to replay on import, so modifing > lr_setattr_t size isn''t really critical, is it?Shouldn''t moving pools work even without an export (though an export would be ideal)? Cheers Manoj