Re: KACL from KIO isn't really POSIX-compliant

2020-12-16 Thread Albert Astals Cid
El dimecres, 2 de desembre de 2020, a les 10:36:30 CET, Gleb Popov va escriure:
> Hello everyone.
> 
> I tried compiling kio/src/core/kacl.cpp on FreeBSD, which does support
> POSIX ACLs, and failed. This is because KACL's code uses non-standard
> Linux-specific acl_* functions. I tried implementing them using standard
> ones and it turned out to be impossible, mainly because types like acl_t
> are opaque to the user of the library.
> 
> For instance, there is no standard acl_get_perm() function and it is
> impossible to implement it without getting into acl_permset_t.
> 
> Now I'm a bit unsure how to solve this. I can implement non-standard
> functions in FreeBSD's libc without touching KACL code, or I can rewrite
> the KACL class to be truly POSIX-compliant. The latter seems to be a better
> idea on the first look, but it'd require keeping track of all the
> permission flags set (again, because there is no acl_get_perm()) inside.
> This will turn KACL class from being a tiny acl_* wrapper into a beefy
> chunk of code, but at least we won't lie that it is POSIX-compliant.
> 
> Any thoughts?

This is exactly why we need CI at the Merge Request stage and not later, we 
would have caught this and whoever was proposing the change would have to fix 
it or find someone to help fix it.

Anyhow, that's off topic :D

About how to fix it, well fixing it in FreeBSD is probably "harder" that in kio 
(amount of people needed to be convinced), so I'd vote for the second so we can 
get unblocked as soon as possible.

On how to fix it in KIO, the optimal way in my opinion is 
"abstract-like-its-kde", i.e. create a wrapper API on top of acl_* that has a 
#if LINUX and just calls the existing code and and #else POSIX and has the 
"beefy chunk of code" (but that's me not having a clue whatsoever about this 
ACL code).

Cheers,
  Albert

> 
> P.S. Please CC me, as I'm not subscribed.
> 






Re: KACL from KIO isn't really POSIX-compliant

2020-12-11 Thread Adriaan de Groot
On 2020 dekula d. 11id 16:37:19 CET Aleix Pol wrote:
> > I tried compiling kio/src/core/kacl.cpp on FreeBSD, which does support
> > POSIX ACLs, and failed. This is because KACL's code uses non-standard
> > Linux-specific acl_* functions. I tried implementing them using standard
> > ones and it turned out to be impossible, mainly because types like acl_t
> > are opaque to the user of the library.

[[ I'm aware of Gleb's work, I'd really like a non-FreeBSD perspective on this 
]]

Here's *part* of the problem:

bool KACL::operator==(const KACL ) const
{
#if HAVE_POSIX_ACL
return (acl_cmp(d->m_acl, rhs.d->m_acl) == 0);
#else
Q_UNUSED(rhs);
return true;
#endif
}

It *looks* like portable code, it's checking if POSIX is available, does a 
comparison, that's fine. Except that acl_cmp() is **not** a POSIX function.

https://man7.org/linux/man-pages/man3/acl_cmp.3.html

The POSIX ACL spec sucks. There is no way to compare sets of ACLs. So the non-
portable Linux-specific function makes a lot of sense: that **should** have 
been in POSIX.

Gleb's question is about where this should be fixed. FreeBSD's libc is the 
"obvious" solution, because this is generally useful ACL API, but fixing up 
libc, especially with something grotty like a Linux-specific function 
(opinions expressed may not be my own) is a slowww process. But doing the 
same thing in KIO itself means a huge code bloat in KIO.

[ade]

signature.asc
Description: This is a digitally signed message part.


Re: KACL from KIO isn't really POSIX-compliant

2020-12-11 Thread Aleix Pol
On Wed, Dec 2, 2020 at 10:47 AM Gleb Popov <6year...@gmail.com> wrote:
>
> Hello everyone.
>
> I tried compiling kio/src/core/kacl.cpp on FreeBSD, which does support POSIX 
> ACLs, and failed. This is because KACL's code uses non-standard 
> Linux-specific acl_* functions. I tried implementing them using standard ones 
> and it turned out to be impossible, mainly because types like acl_t are 
> opaque to the user of the library.
>
> For instance, there is no standard acl_get_perm() function and it is 
> impossible to implement it without getting into acl_permset_t.
>
> Now I'm a bit unsure how to solve this. I can implement non-standard 
> functions in FreeBSD's libc without touching KACL code, or I can rewrite the 
> KACL class to be truly POSIX-compliant. The latter seems to be a better idea 
> on the first look, but it'd require keeping track of all the permission flags 
> set (again, because there is no acl_get_perm()) inside. This will turn KACL 
> class from being a tiny acl_* wrapper into a beefy chunk of code, but at 
> least we won't lie that it is POSIX-compliant.
>
> Any thoughts?
>
> P.S. Please CC me, as I'm not subscribed.

Adding Adriaan who has been working on KDE+FreeBSD things.

Aleix


KACL from KIO isn't really POSIX-compliant

2020-12-02 Thread Gleb Popov
Hello everyone.

I tried compiling kio/src/core/kacl.cpp on FreeBSD, which does support
POSIX ACLs, and failed. This is because KACL's code uses non-standard
Linux-specific acl_* functions. I tried implementing them using standard
ones and it turned out to be impossible, mainly because types like acl_t
are opaque to the user of the library.

For instance, there is no standard acl_get_perm() function and it is
impossible to implement it without getting into acl_permset_t.

Now I'm a bit unsure how to solve this. I can implement non-standard
functions in FreeBSD's libc without touching KACL code, or I can rewrite
the KACL class to be truly POSIX-compliant. The latter seems to be a better
idea on the first look, but it'd require keeping track of all the
permission flags set (again, because there is no acl_get_perm()) inside.
This will turn KACL class from being a tiny acl_* wrapper into a beefy
chunk of code, but at least we won't lie that it is POSIX-compliant.

Any thoughts?

P.S. Please CC me, as I'm not subscribed.