ACL support.

ACL support.

[pelletierma]

Hello,

I've given a swing at ACL support for the linux kernel.  Kernel patches and userland support is avaliable for review at

http://sourceforge.net/projects/linux-acl/

I'm looking for complaints, praise, suggestions, and bug reports.  :-)  Since I'm unfamiliar with non-i386 entry.S, I've not yet added the system calls to other architectures, though.  Sorry.

I'm on a slow link, so I can't subscribe to the mailing list and remain sane simultaneously.  Please cc: comments to me; or post on the sourceforge project forums.

If you people think this is a Bad Idea(tm) to begin with, just tell me.  :-)

-- Marc A. Pelletier

-- Original annoucement follows --

Initial release of Linux ACL support.

Somethings to dig your security teeth into: ACL support for the Linux kernel.

Access Control Lists allow fine grained access control to filesystem objects, by attaching a list of permissions to grant or deny specific capabilities to users or groups.
This implementation of ACL for the Linux kernel provides semantics that are almost totally compatible with the traditional POSIX umode model for applications that are unaware of the kernel support.

Features include the ability to set rights for fine grained operation on filesystem objects (such as separate write/truncate/append permissions) to an arbitary number of users or groups; and the ability to "offer" a file for chown()ing by another user.

Currently, using the package requires patching and recompiling your kernel, and installing tools to use the new features, thus requiring some kernel-fu savvy.

Once development has reached a stable, reliable state and has been well tested, the kernel patch aspect will be submitted for inclusion in the main kernel sources.

Testers are welcome, and peer review of the security aspects of the code are welcome, and desired.


-- 




__________________________________________________________________
Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/

Re: ACL support.

[Andreas Dilger]

On Mar 05, 2002  15:32 -0500, pelletierma@netscape.net wrote:
> I've given a swing at ACL support for the linux kernel.  Kernel patches
> and userland support is avaliable for review at
> 
> http://sourceforge.net/projects/linux-acl/

Please see http://acl.bestbits.at/ - this has been added to the 2.5 kernel
already, and has existed for a long time now...

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: ACL support

[pelletierma]

Hello.

In response to a number of email I have received, I wanted to make
something clear:  I'm not out to compete with the bestbit implementation of 
ACLs over extended file attributes.  :-)

What I am offering is an alternative implementation of ACL support at the
VFS level, that remains independent of filesystem support for ACLs.  In
fact, my patch provides filesystem support for ramfs only at this time
(which was ideal for testing).

The extenteded attribute system as implemented is very good (and in fact
I am using it for a project of mine), and provide an excellent
infrastructure for implementing ext2 and ext3 support for ACL...  only
I beleive that providing an uniform interface and evaluation of ACLs that
remains independent of the filesystem is the Right Thing(tm).

Placing ACLs at the VFS level also allows subdivision of the traditional
rwx semantics.  In fact, people emailed me after testing my patch have
suggested additional subdivisions of access right that would be useful
for some other non persistent filesystems (proc and devfs) such as
giving a bit for ioctl()s.  And since my ACL system is based on VFS
inodes, it can be extended to sockets as well, which would make useful
connection and listen permissions, for instance.
I have not touched implementation of ACL for ext2 and ext3 yet /exactly/
because the bestbits extended attributes existed, and I felt the people
working on that code would be in an excellent position to interface with
my ACL support seamlessly.

Both codebases can be viewed as orthogonal, not competing.  That's the
way I chose to look at it, and I hope others can feel the same as well.

Happy coding.  :-)

-- Marc A. Pelletier

-- 




__________________________________________________________________
Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/

Re: ACL support

[Andreas Dilger]

On Mar 07, 2002  15:58 -0500, pelletierma@netscape.net wrote:
> In response to a number of email I have received, I wanted to make
> something clear:  I'm not out to compete with the bestbit implementation of 
> ACLs over extended file attributes.  :-)
> 
> What I am offering is an alternative implementation of ACL support at the
> VFS level, that remains independent of filesystem support for ACLs.

Then you must not have looked at the bestbits.at code at all.  It includes
a generic VFS interface for EAs and ACLs.  There are ext2, ext3, and XFS
codes which work with this VFS interface.

Some people have had complaints about the bestbits VFS interface, and
another one for people to look at is never a bad thing.

Cheers, Andreas
--
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

ACL Support

[Mike Young]

[-- Attachment #1: Type: text/plain, Size: 1230 bytes --]

Hi All,

 

I've been trying to find out information on ACL support in Reiserfs, but
haven't had much luck finding anything but a few exchanges here and there.
There are numerous capabilities within Reiserfs, which I'd like to take
advantage of, but this issue of ACL support is only growing.  The problem
actually consists of trying to store ACLs in a Windows environment.  The
number of ACEs can be quite sufficient that it can require multiple inodes
to store everything.  As an example, XFS has a maximum inode size of 2K,
which is normally fairly sufficient.  However, if I wish to support all of
the Windows ACL set, then 2K is inadequate and 4K would actually be better.
Again, I can use multiple inodes, but this has a significant affect on
performance.  The bottom line is that I love Linux as a server and believe I
should be able to seamlessly support a Windows client.  I just don't want to
be as slow as a Windows server.

 

With that in mind, can someone give me a quick synopsis of how ACLs are
handled in Reiserfs v3 and v4?  Also, if there is a url to the information
I'd appreciate a pointer to it.  Admittedly, I haven't read the man pages.
So, if it's all there, please forgive me.

 

Many thanks,

 

Mike


[-- Attachment #2: Type: text/html, Size: 3453 bytes --]

Re: ACL Support

[Christian Mayrhuber]

On Thursday 01 April 2004 18:50, Mike Young wrote:
> Hi All,
>
>
>
> I've been trying to find out information on ACL support in Reiserfs, but
> haven't had much luck finding anything but a few exchanges here and there.
> There are numerous capabilities within Reiserfs, which I'd like to take
> advantage of, but this issue of ACL support is only growing.  The problem
> actually consists of trying to store ACLs in a Windows environment.  The
> number of ACEs can be quite sufficient that it can require multiple inodes
> to store everything.  As an example, XFS has a maximum inode size of 2K,
> which is normally fairly sufficient.  However, if I wish to support all of
> the Windows ACL set, then 2K is inadequate and 4K would actually be better.
> Again, I can use multiple inodes, but this has a significant affect on
> performance.  The bottom line is that I love Linux as a server and believe
> I should be able to seamlessly support a Windows client.  I just don't want
> to be as slow as a Windows server.
>
>
>
> With that in mind, can someone give me a quick synopsis of how ACLs are
> handled in Reiserfs v3 and v4?  Also, if there is a url to the information
> I'd appreciate a pointer to it.  Admittedly, I haven't read the man pages.
> So, if it's all there, please forgive me.
>
>
>
> Many thanks,
>
>
>
> Mike

Status of acl's under Linux (start with that, its very informative):
http://www.suse.de/~agruen/acl/linux-acls/

For ReiserfsV3, you have 2 possibilites:
1) use the SuSE distribution, it has ACL's for Reiserfs per default.
2) patch the linux kernel
For kernel 2.6; experimental
  ftp://ftp.suse.com/pub/people/mason/patches/data-logging/experimental/
For kernel 2.4
  http://acl.bestbits.at
  +
  ftp://ftp.suse.com/pub/people/jeffm/reiserfs/aclea/v2.4/

For the capabilities of Reiser4 read: http://www.namesys.com/

Notes:
* Reiser4 is incompatible with Reiser3.
* I don't know if ReiserfsV3 ACL's will ever be included in the official Linux
kernel. SuSE is supporting this stuff.

-- 
lg, Chris

Re: ACL Support

[Jeff Mahoney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike Young wrote:
| Hi All,
|
|
|
| I\x19ve been trying to find out information on ACL support in Reiserfs, but
| haven\x19t had much luck finding anything but a few exchanges here and
| there.  There are numerous capabilities within Reiserfs, which I\x19d like
| to take advantage of, but this issue of ACL support is only growing.
| The problem actually consists of trying to store ACLs in a Windows
| environment.  The number of ACEs can be quite sufficient that it can
| require multiple inodes to store everything.  As an example, XFS has a
| maximum inode size of 2K, which is normally fairly sufficient.  However,
| if I wish to support all of the Windows ACL set, then 2K is inadequate
| and 4K would actually be better.  Again, I can use multiple inodes, but
| this has a significant affect on performance.  The bottom line is that I
| love Linux as a server and believe I should be able to seamlessly
| support a Windows client.  I just don\x19t want to be as slow as a Windows
| server.
|
|
|
| With that in mind, can someone give me a quick synopsis of how ACLs are
| handled in Reiserfs v3 and v4?  Also, if there is a url to the
| information I\x19d appreciate a pointer to it.  Admittedly, I haven\x19t read
| the man pages.  So, if it\x19s all there, please forgive me.

ReiserFS v3 ACLs are implemented as an external patchset, though we've
been trying for some time to convince Hans to accept them. I'm not sure
what you mean by "handled," so I guess I'll just give a rundown of how
the backend works.

ACLs are handled by implementing extended attributes for ReiserFS, and
having the system.posix_acl_access and system.posix_acl_default xattrs
handled specially, and are interpreted by the kernel as part of the
permissions process.

In order to implement extended attributes in a manner that doesn't alter
disk format, my patches add a .reiserfs_priv directory to the root of
the filesystems. xattrs are stored in
.reiserfs/xattrs/<objectid>.<generation number>/<xattr name>. This
directory is hidden from userspace completely when xattrs are enabled,
even as root. When not using my patches, the directory is exposed as a
normal directory and the system administrator is welcome to shoot
himself in the foot. Each file contains a magic, a checksum of the data,
~ and the xattr data itself. When quotas are enabled, extended attributes
are included in the quota usage.

Both access and default ACLs are loaded on demand. This means that for
an access ACL to be loaded, reiserfs_permission requires that
information. If the user owns the file or is root, the ACL won't be
loaded from disk. Once loaded, the entire ACL set for that inode is
cached for the life of the inode. For the default ACL to be loaded, a
file or directory must be created under a directory with a default ACL.
Like access ACLs, once loaded, the default ACL is cached for the life of
the inode.

As far as using them goes, the interface is the standard set of
xattr/acl tools you'd use for any other Linux filesystem that supports them.

Since the xattr implementation uses regular files as the backend, the
number of ACLs per inode is limited only by the maximum size of an
xattr, which is currently limited at the VFS layer to 64k. With 64k to
work with, the on-disk format supports approximately 8k ACLs.

For v2.6, your best bet is to use the patches that are merged against
Chris Mason's data logging patch set. You can get those at Chris's FTP
site[1].

For v2.4, if you're not using a SuSE kernel (which has them already),
you can get the patches from my FTP site[2].

I'm not familiar with the v4 ACL/xattr implementation, so I can't comment.

- -Jeff

[1] ftp://ftp.suse.com/pub/people/mason/patches/data-logging/experimental/
[2] ftp://ftp.suse.com/pub/people/jeffm/reiserfs/aclea/v2.4/

- --
Jeff Mahoney
SuSE Labs
jeffm@suse.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAbGfnLPWxlyuTD7IRAqovAKCAKpFn93wBVB/Rj9cRg57fXSx7FgCgmRcD
bjKtPjRIwLtxA7naRR/OkMw=
=Dhvk
-----END PGP SIGNATURE-----

RE: ACL Support

[Mike Young]

Wow Jeff!  That's a great explanation and very helpful too.  Can you answer
a couple more questions for me on the v3.x reiserfs?  I'm trying to
understand the limits right now.  For example, how big of a volume can I
support?  How large of a file?  And how many files?

I actually have a problem in that I've got files that are 2TB in size--
nothing bigger, though.  

Thanks,

Mike

-----Original Message-----
From: Jeff Mahoney [mailto:jeffm@suse.com] 
Sent: Thursday, April 01, 2004 11:05 AM
To: Mike Young
Cc: reiserfs-list@namesys.com
Subject: Re: ACL Support

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike Young wrote:
| Hi All,
|
|
|
| I\x19ve been trying to find out information on ACL support in Reiserfs, but
| haven\x19t had much luck finding anything but a few exchanges here and
| there.  There are numerous capabilities within Reiserfs, which I\x19d like
| to take advantage of, but this issue of ACL support is only growing.
| The problem actually consists of trying to store ACLs in a Windows
| environment.  The number of ACEs can be quite sufficient that it can
| require multiple inodes to store everything.  As an example, XFS has a
| maximum inode size of 2K, which is normally fairly sufficient.  However,
| if I wish to support all of the Windows ACL set, then 2K is inadequate
| and 4K would actually be better.  Again, I can use multiple inodes, but
| this has a significant affect on performance.  The bottom line is that I
| love Linux as a server and believe I should be able to seamlessly
| support a Windows client.  I just don\x19t want to be as slow as a Windows
| server.
|
|
|
| With that in mind, can someone give me a quick synopsis of how ACLs are
| handled in Reiserfs v3 and v4?  Also, if there is a url to the
| information I\x19d appreciate a pointer to it.  Admittedly, I haven\x19t read
| the man pages.  So, if it\x19s all there, please forgive me.

ReiserFS v3 ACLs are implemented as an external patchset, though we've
been trying for some time to convince Hans to accept them. I'm not sure
what you mean by "handled," so I guess I'll just give a rundown of how
the backend works.

ACLs are handled by implementing extended attributes for ReiserFS, and
having the system.posix_acl_access and system.posix_acl_default xattrs
handled specially, and are interpreted by the kernel as part of the
permissions process.

In order to implement extended attributes in a manner that doesn't alter
disk format, my patches add a .reiserfs_priv directory to the root of
the filesystems. xattrs are stored in
.reiserfs/xattrs/<objectid>.<generation number>/<xattr name>. This
directory is hidden from userspace completely when xattrs are enabled,
even as root. When not using my patches, the directory is exposed as a
normal directory and the system administrator is welcome to shoot
himself in the foot. Each file contains a magic, a checksum of the data,
~ and the xattr data itself. When quotas are enabled, extended attributes
are included in the quota usage.

Both access and default ACLs are loaded on demand. This means that for
an access ACL to be loaded, reiserfs_permission requires that
information. If the user owns the file or is root, the ACL won't be
loaded from disk. Once loaded, the entire ACL set for that inode is
cached for the life of the inode. For the default ACL to be loaded, a
file or directory must be created under a directory with a default ACL.
Like access ACLs, once loaded, the default ACL is cached for the life of
the inode.

As far as using them goes, the interface is the standard set of
xattr/acl tools you'd use for any other Linux filesystem that supports them.

Since the xattr implementation uses regular files as the backend, the
number of ACLs per inode is limited only by the maximum size of an
xattr, which is currently limited at the VFS layer to 64k. With 64k to
work with, the on-disk format supports approximately 8k ACLs.

For v2.6, your best bet is to use the patches that are merged against
Chris Mason's data logging patch set. You can get those at Chris's FTP
site[1].

For v2.4, if you're not using a SuSE kernel (which has them already),
you can get the patches from my FTP site[2].

I'm not familiar with the v4 ACL/xattr implementation, so I can't comment.

- -Jeff

[1] ftp://ftp.suse.com/pub/people/mason/patches/data-logging/experimental/
[2] ftp://ftp.suse.com/pub/people/jeffm/reiserfs/aclea/v2.4/

- --
Jeff Mahoney
SuSE Labs
jeffm@suse.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAbGfnLPWxlyuTD7IRAqovAKCAKpFn93wBVB/Rj9cRg57fXSx7FgCgmRcD
bjKtPjRIwLtxA7naRR/OkMw=
=Dhvk
-----END PGP SIGNATURE-----

Re: ACL Support

[Jeff Mahoney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike Young wrote:
| Wow Jeff!  That's a great explanation and very helpful too.  Can you
answer
| a couple more questions for me on the v3.x reiserfs?  I'm trying to
| understand the limits right now.  For example, how big of a volume can I
| support?  How large of a file?  And how many files?
|
| I actually have a problem in that I've got files that are 2TB in size--
| nothing bigger, though.

Mike -

The on-disk format for ReiserFS v3 defines the maximum filesystem size
as 2^32 * blocksize, which is currently limited by the size of a page on
the system. So, 16 TB assuming a 4k blocksize. The maximum file size is
2^61-1bytes, but is obviously limited by the maximum size of the
filesystem. The maximum number of files is 2^32.

If you're using a 2.4 kernel, you're not going to be able to handle that
workload using any filesystem, since block devices are limited to 2^32 *
512 bytes = 2 TB. This, in turn, limits all filesystems to 2 TB in size.

Using the 2.6 kernel, the block device limits have been raised, so
ReiserFS can use its maximum capacity.

- -Jeff

- --
Jeff Mahoney
SuSE Labs
jeffm@suse.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAbI4vLPWxlyuTD7IRAsaSAJwIN8Vv/W+LVO5xA2muNWhAsuusAACfV2sn
eX23G/LcEyflt0svSywvIUM=
=Bi+O
-----END PGP SIGNATURE-----

RE: ACL Support

[Mike Young]

I should be able to get around the 2TB limit using LBD support on the 2.4
kernel.

Other than that, the 16TB limit shouldn't be a problem either since I can't
get beyond that with the current VFS limit of 32-bit inodes on Xeon
platforms.  With that, I can only go 2^32*4k block size, which is 16TB.

Hmmm.  Reiserfs is looking pretty good for me.

Thanks,

Mike

-----Original Message-----
From: Jeff Mahoney [mailto:jeffm@suse.com] 
Sent: Thursday, April 01, 2004 1:49 PM
To: Mike Young
Cc: reiserfs-list@namesys.com
Subject: Re: ACL Support

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike Young wrote:
| Wow Jeff!  That's a great explanation and very helpful too.  Can you
answer
| a couple more questions for me on the v3.x reiserfs?  I'm trying to
| understand the limits right now.  For example, how big of a volume can I
| support?  How large of a file?  And how many files?
|
| I actually have a problem in that I've got files that are 2TB in size--
| nothing bigger, though.

Mike -

The on-disk format for ReiserFS v3 defines the maximum filesystem size
as 2^32 * blocksize, which is currently limited by the size of a page on
the system. So, 16 TB assuming a 4k blocksize. The maximum file size is
2^61-1bytes, but is obviously limited by the maximum size of the
filesystem. The maximum number of files is 2^32.

If you're using a 2.4 kernel, you're not going to be able to handle that
workload using any filesystem, since block devices are limited to 2^32 *
512 bytes = 2 TB. This, in turn, limits all filesystems to 2 TB in size.

Using the 2.6 kernel, the block device limits have been raised, so
ReiserFS can use its maximum capacity.

- -Jeff

- --
Jeff Mahoney
SuSE Labs
jeffm@suse.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAbI4vLPWxlyuTD7IRAsaSAJwIN8Vv/W+LVO5xA2muNWhAsuusAACfV2sn
eX23G/LcEyflt0svSywvIUM=
=Bi+O
-----END PGP SIGNATURE-----

ACL support.

[dE]

Does reiser4 support ACL?

Re: ACL support.

[Edward Shishkin]

On 03/26/2014 06:23 AM, dE wrote:
> Does reiser4 support ACL?

Nope for historical reasons.
I'll provide hints how to implement this, if someone wants..

Edward.

Re: ACL support.

[dE]

On 03/26/14 16:04, Edward Shishkin wrote:
> On 03/26/2014 06:23 AM, dE wrote:
>> Does reiser4 support ACL?
>
> Nope for historical reasons.
> I'll provide hints how to implement this, if someone wants..
>
> Edward.

Thanks for the response.

I was just asking for educational purposes (my home dir recedes on reiser4).

And yes -- I got a major bug to report which cause FF to crash. 
Duplicating ~/.firefox solved the problem. I've the bad ~/.firefox.

What do I have to do to report the problem?

Re: ACL support.

[Edward Shishkin]

On 03/26/2014 04:42 PM, dE wrote:
> On 03/26/14 16:04, Edward Shishkin wrote:
>> On 03/26/2014 06:23 AM, dE wrote:
>>> Does reiser4 support ACL?
>>
>> Nope for historical reasons.
>> I'll provide hints how to implement this, if someone wants..
>>
>> Edward.
>
> Thanks for the response.
>
> I was just asking for educational purposes (my home dir recedes on 
> reiser4).
>
> And yes -- I got a major bug to report which cause FF to crash. 
> Duplicating ~/.firefox solved the problem. I've the bad ~/.firefox.
>
> What do I have to do to report the problem?

1) "bad" means what?
2) any kernel complaints?
3) results of checking the partition with fsck.reiser4
4) Is it possible to reproduce the problem?

Thanks,
Edward.

Re: ACL support.

[dE]

On 03/26/14 21:31, Edward Shishkin wrote:
> On 03/26/2014 04:42 PM, dE wrote:
>> On 03/26/14 16:04, Edward Shishkin wrote:
>>> On 03/26/2014 06:23 AM, dE wrote:
>>>> Does reiser4 support ACL?
>>>
>>> Nope for historical reasons.
>>> I'll provide hints how to implement this, if someone wants..
>>>
>>> Edward.
>>
>> Thanks for the response.
>>
>> I was just asking for educational purposes (my home dir recedes on 
>> reiser4).
>>
>> And yes -- I got a major bug to report which cause FF to crash. 
>> Duplicating ~/.firefox solved the problem. I've the bad ~/.firefox.
>>
>> What do I have to do to report the problem?
>
> 1) "bad" means what?
> 2) any kernel complaints?
> 3) results of checking the partition with fsck.reiser4
> 4) Is it possible to reproduce the problem?
>
> Thanks,
> Edward.

I started having problems with FF which was diagnosed to contents of 
~/.firefox. So renamed it to ~/.firefox_bad and copied ~/.firefox_bad to 
~/.firefox to solve the problem.

So I still have ~/.firefox_bad; this problem occurred twice, and I have 
both of the ~/.firefox_bad

Yes -- the kernel showed a backtrace from some reiser4 sources.

fsck.reiser4 was done -- nothing was wrong.

Yes -- I have the ~/.firefox_bad just for the purpose of bug reporting.

Re: ACL support.

[Edward Shishkin]

On 03/26/2014 05:44 PM, dE wrote:
> On 03/26/14 21:31, Edward Shishkin wrote:
>> On 03/26/2014 04:42 PM, dE wrote:
>>> On 03/26/14 16:04, Edward Shishkin wrote:
>>>> On 03/26/2014 06:23 AM, dE wrote:
>>>>> Does reiser4 support ACL?
>>>>
>>>> Nope for historical reasons.
>>>> I'll provide hints how to implement this, if someone wants..
>>>>
>>>> Edward.
>>>
>>> Thanks for the response.
>>>
>>> I was just asking for educational purposes (my home dir recedes on 
>>> reiser4).
>>>
>>> And yes -- I got a major bug to report which cause FF to crash. 
>>> Duplicating ~/.firefox solved the problem. I've the bad ~/.firefox.
>>>
>>> What do I have to do to report the problem?
>>
>> 1) "bad" means what?
>> 2) any kernel complaints?
>> 3) results of checking the partition with fsck.reiser4
>> 4) Is it possible to reproduce the problem?
>>
>> Thanks,
>> Edward.
>
> I started having problems with FF which was diagnosed to contents of 
> ~/.firefox.

Which kernel version?
Do you use the new reiser4 transaction models announced not so long ago?

> So renamed it to ~/.firefox_bad and copied ~/.firefox_bad to 
> ~/.firefox to solve the problem.
>
> So I still have ~/.firefox_bad; this problem occurred twice, and I 
> have both of the ~/.firefox_bad
>
> Yes -- the kernel showed a backtrace from some reiser4 sources.

Could you send it, if possible?

Thanks,
Edward.

>
> fsck.reiser4 was done -- nothing was wrong.
>
> Yes -- I have the ~/.firefox_bad just for the purpose of bug reporting.

Re: ACL support.

[dE]

On 03/26/14 22:34, Edward Shishkin wrote:
> On 03/26/2014 05:44 PM, dE wrote:
>> On 03/26/14 21:31, Edward Shishkin wrote:
>>> On 03/26/2014 04:42 PM, dE wrote:
>>>> On 03/26/14 16:04, Edward Shishkin wrote:
>>>>> On 03/26/2014 06:23 AM, dE wrote:
>>>>>> Does reiser4 support ACL?
>>>>>
>>>>> Nope for historical reasons.
>>>>> I'll provide hints how to implement this, if someone wants..
>>>>>
>>>>> Edward.
>>>>
>>>> Thanks for the response.
>>>>
>>>> I was just asking for educational purposes (my home dir recedes on 
>>>> reiser4).
>>>>
>>>> And yes -- I got a major bug to report which cause FF to crash. 
>>>> Duplicating ~/.firefox solved the problem. I've the bad ~/.firefox.
>>>>
>>>> What do I have to do to report the problem?
>>>
>>> 1) "bad" means what?
>>> 2) any kernel complaints?
>>> 3) results of checking the partition with fsck.reiser4
>>> 4) Is it possible to reproduce the problem?
>>>
>>> Thanks,
>>> Edward.
>>
>> I started having problems with FF which was diagnosed to contents of 
>> ~/.firefox.
>
> Which kernel version?
> Do you use the new reiser4 transaction models announced not so long ago?
>
>> So renamed it to ~/.firefox_bad and copied ~/.firefox_bad to 
>> ~/.firefox to solve the problem.
>>
>> So I still have ~/.firefox_bad; this problem occurred twice, and I 
>> have both of the ~/.firefox_bad
>>
>> Yes -- the kernel showed a backtrace from some reiser4 sources.
>
> Could you send it, if possible?
>
> Thanks,
> Edward.
>
>>
>> fsck.reiser4 was done -- nothing was wrong.
>>
>> Yes -- I have the ~/.firefox_bad just for the purpose of bug reporting.
>

Kernel is 3.8.5. So no, it's an old one.

Yes, I'll send the bt. Wait.

Re: ACL support.

[dE]

On 03/27/14 20:51, dE wrote:
> On 03/26/14 22:34, Edward Shishkin wrote:
>> On 03/26/2014 05:44 PM, dE wrote:
>>> On 03/26/14 21:31, Edward Shishkin wrote:
>>>> On 03/26/2014 04:42 PM, dE wrote:
>>>>> On 03/26/14 16:04, Edward Shishkin wrote:
>>>>>> On 03/26/2014 06:23 AM, dE wrote:
>>>>>>> Does reiser4 support ACL?
>>>>>>
>>>>>> Nope for historical reasons.
>>>>>> I'll provide hints how to implement this, if someone wants..
>>>>>>
>>>>>> Edward.
>>>>>
>>>>> Thanks for the response.
>>>>>
>>>>> I was just asking for educational purposes (my home dir recedes on 
>>>>> reiser4).
>>>>>
>>>>> And yes -- I got a major bug to report which cause FF to crash. 
>>>>> Duplicating ~/.firefox solved the problem. I've the bad ~/.firefox.
>>>>>
>>>>> What do I have to do to report the problem?
>>>>
>>>> 1) "bad" means what?
>>>> 2) any kernel complaints?
>>>> 3) results of checking the partition with fsck.reiser4
>>>> 4) Is it possible to reproduce the problem?
>>>>
>>>> Thanks,
>>>> Edward.
>>>
>>> I started having problems with FF which was diagnosed to contents of 
>>> ~/.firefox.
>>
>> Which kernel version?
>> Do you use the new reiser4 transaction models announced not so long ago?
>>
>>> So renamed it to ~/.firefox_bad and copied ~/.firefox_bad to 
>>> ~/.firefox to solve the problem.
>>>
>>> So I still have ~/.firefox_bad; this problem occurred twice, and I 
>>> have both of the ~/.firefox_bad
>>>
>>> Yes -- the kernel showed a backtrace from some reiser4 sources.
>>
>> Could you send it, if possible?
>>
>> Thanks,
>> Edward.
>>
>>>
>>> fsck.reiser4 was done -- nothing was wrong.
>>>
>>> Yes -- I have the ~/.firefox_bad just for the purpose of bug reporting.
>>
>
> Kernel is 3.8.5. So no, it's an old one.
>
> Yes, I'll send the bt. Wait.

Ok, I've realized the mailing list software rejected the mail silently.

Re: ACL support.

[Edward Shishkin]

On 04/08/2014 08:28 PM, Daniel Horne wrote:
> On 26 March 2014 10:34, Edward Shishkin <edward.shishkin@gmail.com
> <mailto:edward.shishkin@gmail.com>> wrote:
>
>     On 03/26/2014 06:23 AM, dE wrote:
>
>         Does reiser4 support ACL?
>
>
>     Nope for historical reasons.
>     I'll provide hints how to implement this, if someone wants..
>
>
> I occasionally have a look at making an XATTR implementation before
> getting sidetracked.
>
> There's a couple of points I'm not quite decided on:
>
> Whether to make a generic xattr stat_data plugin and use it to store all
> different types of attribute, or make different plugins for ACL, SElinux
> contexts, and user xattrs.
>
> You've previously stated that stat_data plugins are limited to 4k. This
> should be fine for selinux contexts and all but pathologically long
> access control lists, I'm not sure about the use of user xattrs. Would
> making separate stat_data plugins give separate 4k limits to each type
> of attribute, or is that all-inclusive?
>


Actually stat-data is an on-disk container of inode fields. That said, I 
would prefer to store xattrs in special items, which are different from 
stat-data (one such item per a pair (xattr_name, xattr_value)).


> There's also the matter of choosing an on-disk format. A simple list
> format, perhaps? Lookup would be O(n), but given the small amount of
> data we're expecting to store there, that may be OK.

I suggest that we use the following format for the xattr items.

The key of the item associated with the pair (xattr_name, xattr_value) 
is [base_key, offset], where base_key is calculated by build_xattr_key()
(not yet implemented). This function does mostly the same as 
build_sd_key(). The difference is that build_xattr_key() installs
a special reserved (and currently not used) minor locality 
KEY_ATTR_NAME_MINOR (see key.h for the definition).

64-bit key offset is composed of 32-bit major_offset and 32-bit minor 
offset. Major offset is a 32-hash of the xattr_name. Minor offset is the 
number of the collision in the chronology ordering.

Format of the item body is the following:
. size-of-xattr_name (16 bit)
. xattr_name;
. xattr_value

So getxattr(2) is resolved to the following actions:

. build base_key for the xattr_name;
. set major offset as hash(xattr_name);
. linear search for precise xattr_name among all items with the same 
[key_base, major_offset].
. return respective xattr_value (or NOT_FOUND).

setxattr(2) is resolved to the following actions:

. compose the item body in accordance with the format above;
. build base_key for xattr_name;
. set the major offset, i.e. hash(xattr_name);
. search for the xattr_name among all items with the same [base_key, 
major_offset];
. update the item body, or (depending on the flags) return EEXIST, if 
the item with xattr_name was found;
. set the respective minor_offset by the search results, if the item 
with xattr_name was not found;
. insert the new item with the [base_key, offset] to the current 
position in the tree.

For simplicity and performance reasons let's assume that xattr items are 
solid. That said, any xattr item contains exactly one unit. In 
particular, it means that sizeof(xattr_name + xattr_value) can not 
exceed 4096 - (sizeof(node_header) + sizeof(item_header)). Let's 
implement xattrs support with such restrictions for now. Also, don't 
update minor offsets of colliding items when removing xattr: I don't 
think that we'll exceed the limit for the number of collisions (2^32)
in the foreseeable future.

Makes sense?
Let me know if any problems..

Thanks,
Edward.