Bug 6976

*** Bug 60374 has been marked as a duplicate of this bug. ***

*** Bug 34172 has been marked as a duplicate of this bug. ***

Four years later, still open, still unimplemented, still a good idea. Go for it! :-)

*** Bug 56580 has been marked as a duplicate of this bug. ***

*** Bug 23194 has been marked as a duplicate of this bug. ***

and still only 20 votes? We're still open for patches though

Would be nice to see, now that there are ACL's in 2.6.
One could even stop to manage ACL's with M$ Explorer
trough Samba ;-)

It seems that there is already a fonctionnal implementation here :
http://www.kde-apps.org/content/show.php?content=11315
I'll test it soonly.

On Friday 12 March 2004 17:20, Julien wrote:
> It seems that there is already a fonctionnal implementation here :
> http://www.kde-apps.org/content/show.php?content=11315
> I'll test it soonly.

Good luck.
That's a mockup, not an actual implementation (it's just a .ui file).

*** Bug 77131 has been marked as a duplicate of this bug. ***

The mockup is too complicated.  I mean, its a great step forward, but
it's too complicated for a regular user to be using.  The current
permission manager in konqueror is good enough for regular users, and
something like that should be extended to manage ACLs as well.


El vie, 12-03-2004 a las 12:20, David Faure escribió:
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
>       
> http://bugs.kde.org/show_bug.cgi?id=6976      
> 
> 
> 
> 
> ------- Additional Comments From faure kde org  2004-03-12 18:20 -------
> On Friday 12 March 2004 17:20, Julien wrote:
> > It seems that there is already a fonctionnal implementation here :
> > http://www.kde-apps.org/content/show.php?content=11315
> > I'll test it soonly.
> 
> Good luck.
> That's a mockup, not an actual implementation (it's just a .ui file).

Ideally, permissions should be a plug-in into kfm so that different permission sets can be easily adapted into kfm.  I would imagine that the best way to do this is to take some inspiration from the Linux kernel's security modules and create hooks into kfm that the plug-ins can control.

I did really would like this to be implementet, for advanced users.

> The mockup is too complicated.  I mean, its a great step forward, but 
> it's too complicated for a regular user to be using.  The current 
> permission manager in konqueror is good enough for regular users, and 
> something like that should be extended to manage ACLs as well. 

You know what I say to that??? BS...that's a load of crap...I still haven't figured out the current one...the shell was a lot easier to understand than that, and I AM a relative newbie. There is no point in pretending that things are more complex then they are, just to make them look less confusing, and a 4 x 3 inch grid of check boxes, to me looks way more complex then simple unix file permissions should have to be.

I say that the mockup's ideas are lightyears ahead of the current system...and I might actually be more likely to use kfm if it looked a little more like that mockup. Way to go Julien!!!! I mean we're using unix, and there are well established sets of visuals associated with certain things like file permissions...like the rwx symbolism, which is nice to keep...it makes the interface a lot faster for experienced users; and for newbies we can have a properties panel for each user...and provide the handholding in there, so that newbies can learn it the right way, instead of feeding them bullshit and making things look artificial, and misleading.

:) Just my thoughts...take them or leave them. :)

> Additional Comment #11 From Manuel Amador (Rudd-O) 2004-03-17 01:07 ------- 
> The mockup is too complicated.  I mean, its a great step forward, but 
> it's too complicated for a regular user to be using.  The current 
> permission manager in konqueror is good enough for regular users, and 
> something like that should be extended to manage ACLs as well. 

Maybe, but regular users won't need ACL's at all, they normally are pretty much happy with the standard unix permissions.
If a user is using ACL's he/she should know what he/she is doing.
Even splitting the dialog into two parts makes sense. The ACL part can be
hidden or disabled if the filesystem is not mounted with acl's.
What I'm missing in this dialog is how to deal with default ACL entries.

On Thursday 15 July 2004 18:00, Christian Mayrhuber wrote:
> What I'm missing in this dialog is how to deal with default ACL entries.

The ACL tab which I implemented in KMail (for IMAP folders) could be a good model to follow.

Hmm, these changes seem to be in CVS since may 2004 and are not part
of an official kmail release. Screenshot anyone?
If this dialog can do ACL's + Default ACL's I would prefer to see it in
konqueror, too.
Dealing with ACL's should look the same in every kde app.

Maybe I misunderstood what "Default ACLs" is.
Anyway here's the kmail dialog.



Created an attachment (id=6688)
acls.png

From the getfacl manpage:
Manpage author: Andreas Gruenbacher, <a.gruenbacher@computer.org>
----SNIP----
       If getfacl is used on a file system that does not support  ACLs,  get-
       facl  displays  the access permissions defined by the traditional file
       mode permission bits.

       The output format of getfacl is as follows:
               1:  # file: somedir/
               2:  # owner: lisa
               3:  # group: staff
               4:  user::rwx
               5:  user:joe:rwx               #effective:r-x
               6:  group::rwx                 #effective:r-x
               7:  group:cool:r-x
               8:  mask:r-x
               9:  other:r-x
              10:  default:user::rwx
              11:  default:user:joe:rwx       #effective:r-x
              12:  default:group::r-x
              13:  default:mask:r-x
              14:  default:other:---

       Lines 4, 6 and 9 correspond to the user, group and other fields of the
       file  mode  permission  bits.  These  three  are  called  the base ACL
       entries. Lines 5 and 7 are named user and named group entries. Line  8
       is  the  effective rights mask. This entry limits the effective rights
       granted to all groups and to named users. (The file owner  and  others
       permissions  are  not affected by the effective rights mask; all other
       entries are.)  Lines 10--14 display the default  ACL  associated  with
       this  directory.  Directories  may  have  a default ACL. Regular files
       never have a default ACL.
----SNAP----

Is there any work going on on this? I would love to see this implemented.

The users are clamouring for it!! :)

http://evidence.sourceforge.net/features.html, http://evidence.sourceforge.net/screenshots/info_acl.jpg

They also do xattr. If you have questions on evidence, contact azundris@azundris.com

http://bugs.kde.org/show_bug.cgi?id=43895 is a duplicate of this one.
http://bugs.kde.org/show_bug.cgi?id=40826 is a duplicate of this one.
http://bugs.kde.org/show_bug.cgi?id=67112 is a duplicate of this one.
http://bugs.kde.org/show_bug.cgi?id=80973 is a duplicate of this one.

Dragging Konqui into the 21st century, kicking and screaming... :)

*** Bug 40826 has been marked as a duplicate of this bug. ***

*** Bug 80973 has been marked as a duplicate of this bug. ***

Created attachment 7895 [details]
ACL Dialog

After a bit of googling I found what Windows 2003 does for ACL's.  They seem to
be present all over the place.

The attached screenshot seems to be a little more professional looking and
long-list friendly than the dialog from evidence.

The username box is usually filled with entries like "DOMAIN\username" and a
special "Everyone" entry which is the default ACL to use.  You can also specify
groups in here as well to fully exploit ACL's.	The simple "Allow / Deny"
interface is user friendly too. Please take a look.

ACLs is not something new for windows 2003, it been around in windows at least since NT4. Given the mysterious popularity of windows, there are probably more people who knows how to use ACLs than how to use standard unix permissions in combinations with groups to do advanced permissions management. 

As I see it the main problem with KDE not being aware of ACLs is not that you can't set them from a KDE GUI  but rather that you can not see them at all. This could be a potential security problem if windows users logged in trough samba have better control over permissions than the unix sysadmin. 

But then again if we just changed the file permissions dialog to display it, most people would wonder why they had to resort to windows or the command line to change them.

ACL support and EA support is deeper than just a change dialog. You need to keep them around when copying files, and you need to check if they are available on the target file system, and if not, need to warn the user about losing them. When creating archives, you need to check if the chosen archive format supports them, and if not, need to warn the user about the information loss.

True, ACL is more than a change dialog. Perhaps we should start with creating warnings when ACLs are destroyed due to copying to non ACL-aware locations and then focus on what the change dialog should look like. The current situation where people may unknowingly loose ACL information is a much more serious problem than not being able to change them from the GUI.

The fact that we can't see or change ACLs in KDE doesn't mean they doesn't exist.

In Bug #80973, which has been marked a duplicate of this bug, the enhancement request is extended not only to ACLs, but also to Extended Attributes.
The cleanest solution would be to make the "Meta Info" tab of the current Konqueror "Properties" Dialog automatically determine if the underlying filesystem supports extended attributes. If it does, the information shown there should include the information found in the extended attributes, and the user should have the option to add, delete or edit those attributes, if ACL or filesystem permissions entitle him/her to do so. Most extended attribute implementations (I recall XFS and ReiserFS) support at least two namespaces of extended attributes: the "root" and "user" layers. Konqueror should respect this fact, too.

http://wiki.kdenews.org/tiki-print.php?page=Ideas+for+saving+and+using+file+metadata

gives a nice introduction and some interesting thougths about this topic

Thank you. I wrote it :-)

So, after fiddling with getfacl and setfacl for about an hour to fix the permissions for a Samba shared directory for ALL clients that we use (Linux, Windows, OSX), I am REALLY hungry for this feature.

Please tell me what needs to be done. I have the impression there is a somewhat-functional implementation in KDE CVS already. Where is it?

Thanks!

Couldn't the first step be just to have a nice GUI for editting them?

Once that was working, and bugs and usability issues ironed out, people could then look at the problems raised in comment 27.

On Wednesday 17 November 2004 13:21, Jens B.Benecke wrote:
> I have the impression there is a somewhat-functional implementation in KDE CVS already. Where is it?

There isn't.
[There was one a few years ago but it had to be removed due to licensing problems].

Created attachment 9624 [details]
acl dialog prototype

Created attachment 9625 [details]
acl dialog prototype

Created attachment 9627 [details]
file acl dialog prototype

Created attachment 9629 [details]
dir/file acl dialog prototype

OK I've started implementing support for ACLs in KDE. So far I've got code to detect support for ACLs under linux and a prototype KFileProperties dialog plugin to display/edit them (see attached screen shots above). I'll post again when I get some more done, hopefully at the weekend.

Sorry for the multiple posts of screen shots - I didn't think konqy was responding and clicked on submit twice by mistake.

The only issue I have with the UI is that this should _replace_ the UI for permissions if ACLs are enabled. The user should never see two spots to manage the perms of a file.

>The only issue I have with the UI is that this should _replace_ the UI for permissions if ACLs are enabled. The user should never see two spots to manage the perms of a file.

Agreed, I just haven't removed the original permissions plugin yet while I'm developing the ACL aware replacement.

That's not consistent with the way POSIX ACLs are implemented though. They *do* exist side by side with traditional permissions.

That's well and good for command line, Michael, but that just confuses users from a usability stand point with GUIs. Granted, the POSIX acl standard sucks in that regard, since it allows for that kind of over-engineering, but it doesn't mean that KDE should follow suite.

IMHO is Gery Greene is really right, there really should ony be one place of handling acl! Have a look an M$ Win there is also only one place for ACL's. 

Btw. what about the ACL's on Solaris? It supports a *little* more than Linux. (Just an idea for the future :). 

I would be _really_ glad if kde 3.4 came with this ACL manager! 

Please, don't state highly subjective opinions about "confusing" UIs and pretend it's about usability. 

Disabling traditional the UI for traditional permissions would be the actual usability bug, since you can't just infer from the availibility of ACLs that the user of the filesystem wants to use them at all. Or do you delete chmod and chown on machines with set/getfacl available? (*)

* That comparison isn't as ridiculous as it may sound - the difference in complexity and difficulty of usage of set/getfacl and chmod/chown reflects quite nicely in the ACL UI vs the tradional permissions UI

First, in reply to comment 43, this likely won't make it until KDE 4.

Second, in reply to comment 44:
IIRC, ACLs (at least on Linux, I'm uncertain about other *NIXs) require that the ACL aspect be enabled as a mount option to the FS volume I see this as a moot point. If the user wants to use ACLs they enable it, if not, then they don't and shouldn't see the ACL configuration page at all.

It's quite common for users (we're talking multiuser OS after all) to have their home directories on a filesystem they don't have control over. :-)

In those cases, if the admin doesn't want to enable their users and teach them about ACLs (which users are getting accustomed to ACLs under Windows anyway...), the admin should have their /home volume mounted WITHOUT ACL support. I still cannot see a reason to keep the permissions page enabled if the ACL one is active.

I believe you really just proved my point, with the "teach them about ACLs" bit, allowing me to go silent again on this topic:

Requiring user re-training surely can't be anyone's idea, yours included, of good UI design (and the implementation of ACLs as a superset of traditional unix file permissions/ownership avoids exactly that issue).

As of now I actually check for the existence of the acl mount parameter in determining if a filesystem supports ACLs or not.

I am intending to show the ACL plugin dialog if the fs on which a file/files resides supports ACLs. Else if the fs does not support ACLs just display the existing perms plugin dialog.

It is true that POSIX ACLs extend the normal permissions but the basic ACL has a one-to-one mapping with the usual permission model (not including the special flags sticky etc). Thus the ACL plugin dialog can be used as a replacement for the usual permission plugin diaog in the case that ACLs are supported by the underlying fs.

As for time scales, this will have to wait for KDE 4 I suspect as I think it will include binary incompatible changes to the 3.x series w.r.t. the KFileItem class - although I need to investigate this more closely. If I can do it in time for 3.5 (if it happens at all) then I will, but 3.4 is already in feature freeze.

Sometimes, especially with as far reaching as ACLs are, when you have new features, you cannot just ignore the fact that there will be retraining involved irregardless. If the admin enables ACLs and the two seperate pages, one for UNIX permissions and the other for POSIX ACLs, are shown, do you think support calls will go down? As a person who works helpdesk at a local university I can tell you that this is simply not true. It wil be the reverse. Why? Because most users will be confused about the fact there is this extra page that LOOKS a lot like an extra permissions setting page. Which do they use? Answer me that after looking through the eyes of the common user.

Hi,

first, I love the fact that somebody is actually implementing ACL support in KDE. Thank you!!!

However, I have to say I too, would not like the idea of two seperate tabs for UNIX permissions and ACLs. Consider the "network sharing" problem: At some point, KDE had *three* different tabs that allowed you to share files over the network. One was kpf, which had to be enabled in KControl by root before being useable (why was it there at all, then?). The other was Samba, which would have been the "default" idea of sharing folders (it being the de facto standard everywhere else). Then there was a third option, which I forgot.

This just bloats the properties. If you want to seperate ACLs and UNIX permissions, put a button "Advanced permissions ..." in the Permissions tab, and merge the existing file permissions with the ACLs (just like setfacl/getfacl do it).

Just putting in more and more options does not really help. If you publish the UI file for the dialog here, I will send you a patch with my ideas.


But anyway, thanks again for actually starting this :-)


Ciao

Jens

In reply to <a href="http://bugs.kde.org/show_bug.cgi?id=6976#c45">comment 45</a>:
Please note that XFS does not require a special mount option for ACLs. I think there's not even an option for turning them off. You can only turn support off in the Kernel itself.

Thanks for the heads up w.r.t. XFS Moritz, I wasn't aware of this. Do you know if this is this also the case for any other fs's?

Just to reiterate I am *NOT* intending to show two tabs for editing permissions. If the underlying fs supports ACL then *only* the ACL tab will be shown. Otherwise, if the fs does not support ACL then the usual permissions tab will be shown. At least this is the plan for the moment and is subject to change better ideas etc.

Unfortunately not. At work we use XFS on all machines. For remote access we use NFS with ACL patches included. NFS doesn't need a special option either as long as you use nfsvers=3. NFS does know a flag for turning ACL off, though (no_acl).

So it looks like relying on special mount options having been given will not work very reliably.

Maybe you've already thought of this but a good way of handling the traditional ugo permissions would be to have them as always-there entries in your ACL dialog that can't be deleted, ie. they can only be modified. Maybe they could be greyed out a bit or something to inforce in the user's mind their non-deletable status.

Also I think it might be a better idea if we kept the existing tabs on the properties dialog and just made your ACL dialog replace the 'Advanced Permissions' dialog from the existing permissions tab. That way you'd still have the simple 'Can View Content', 'Can Read' etc. dropdowns with all the configurability of the ACLs in the Advanced dialog.

Just 'cause ACL is enabled on the filesystem doesn't mean users want to use it for every directory, and it doesn't mean we have to lose the simple and very user friendly permissions dialog we have now. 

ACLs on Linux werent designed as an all-or-nothing approach. Its not a case of if you enable them on the file system you have to use them for every directory. The great thing about them is you can pick and choose which files/directories you use them on and use the simpler standard permissions for the rest.

I agree with Comment 51. We need ACLs and do *not* need two setting-dialogs for it. Less is more! The legacy unix permissions dialog changed in the past already. So I don't see a problem to change it again.

If one has no ACLs enabled, then only the legacy unix permissions are available in this dialog, otherwise you can also change ACLs.

But: when implementing ACLs, please don't forget EAs! One could store keywords, icons, annotations, etc. in EAs. I remember my old OS/2 days, where EAs where omnipresent. But you shouldn't mix ACLs with EAs. For EAs, we need a seperate property dialog. For this, the "Meta-Info" dialog could be extended (so reducing the number of TABs).

@Sean (Comment 53): then we still have 2 kind of dialogs. That's odd from the user's point of view. Because depending on the FS you see different dialogs. That's confusing! The new ACL-Dialog should *replace* the old Unix-Permissions-Dialog completely!

Hi,

to comment 56: EAs are fine, however they only make sense if there is some definite application support for it. See my write-up on the KDE wiki, also mentioned earlier on this bugreport's comment list:
http://wiki.kdenews.org/tiki-print.php?page=Ideas+for+saving+and+using+file+metadata

I think this bug should really concentrate about *permission* attributes, not *metadata* attributes. Otherwise we'd open a wholely different can of worms and never finish. Been there, done that. :-)

Jens

@Comment 54: I'm not aware of the ACL-API (should read the man pages). But: to display the ACL-Dialog, you have to read the ACLs. And the API *should* give you an error like "no ACL support". The other case, ACLs supported but not set, should give you an empty list. So, when using only one dialog, we should have no problems at all.

Display the ACL-Dialog, try to read the ACLs. Then, depending on the error-code, display only Unix-Permissions or all ACLs.

Trying to identify ACL support via mount-options is stupid!

@Comment 56: I agree, EAs should go into an own "Bug".

But: If you implement EA-Handling just as the old Metadata-Handling, you're finished. EAs are basically meta-informations stored along the file in the FS, not *IN* the file. But the handling should be really the same. So you have key=value pairs, no matter if they're stored in or along the file.

I was right! The ACL-API gives you an error, if ACLs are not supported:

man (3) acl_get_file:

[ENOTSUP]   The file system on which the file identified by path_p
            is located does not support ACLs, or ACLs are disabled.

So this is the way to go!

From comment 57:

"That's confusing! The new ACL-Dialog should *replace* the old Unix-Permissions-Dialog completely!"

I didn't think ACLs were meant to replace the old permissions. They work with them, and extend them.

no, but the new ACL-Dialog can handle also the old-style permissions as well.

But there was another idea, I like:

1. Using the old-style dialog
2. include a button "ACLs" in this dialog
3. grey it out if there's no ACL-support

then the ACL-Dialog should only handle the new-style permissions and not the old-style. But this way we can use the old dialog and don't have a seperate TAB page for it and all things are kept together. Greying out the ACL button is better than not displaying it, since you can use a tooltip then "no ACLs available on this file/directory" which is less confusing than the newbie-question "where is that damn ACL button gone?" ;-)

A problem that I can see with the idea in comment 63 is that there will then be 3 places which need to be synchronised to show the same permissions information

1. The old-style permissions dialog
2. The advanced permissions dialog that can be launched from 1.
3. The new ACL dialog that would also be launched from 1.

Which of these three solutions would be preferable (a little vote???):

A. Totally replace the old-style permissions dialog with a new ACL dialog. This can work because of the 1-to-1 mapping of permissions to a non-extended ACL. In the case that ACLs are supported the dialog can highlight the fact that extra ACL entries can be added by enabling the "Add Entry" button. Then, regardless of whether ACLs are supported or not the dialog would always show the ACL_USER_OBJ, ACL_GROUP_OBJ and ACL_OTHER ACL entries as these are the ones which correspond to the usual permissions. These entries can be shown with a different icon or in a different colour to differentiate them from ACL_USER and ACL_GROUP entries. The user will never be allowed to delete the ACL_USER_OBJ, ACL_GROUP_OBJ and ACL_OTHER entries only modify them.


B. Use the existing permissions dialog, but replace the Advanced permissions dialog with an ACL dialog.

C. Something else?

Thinking about it, either of these solutions would appear to be acceptable. Comments/new suggestions?

I would totally vote for solution A - replace the dialog and integrate normal UNIX permissions into the new dialog.

One more vote for A.

I think solution B is the way to go. Comment #44 and #48 are showing good reasons for this solution.

I would vote for version A as well - Why have two dialogs if we can display the same thing in a single one? It sounds logical to me to have some fixed entries there which represent the traditional permission model. 

Here is another vote for B.

As already mentioned, comment #44 and comment #48 stake good reasons to go for B but there is also the issues mentioned in comment #55.

Well, I like A but I would have no problem with B. But as mentioned, B means *replacing* the "advanced" dialog. So you have a simple dialog for standard permissions and the "advanced" with for the expert + ACLs.

What we really NOT want is a new TAB for ACLs.

btw: do we have some dialog for quotas already? Is this a different topic or would it make sense to incorporate it into the permissions dialog? How do Windows handles this?

oh, btw: Windows also has two dialogs for "ordinary" Flags like "Archive", "Readonly" and "Hidden" ("System" is hidden from the user at all) and for ACLs.

So B would be the way to go.

responding to comment 70:
Quotas on Win32 are handled on a seperate tab and only at the drive root properties.

responding to comment 71:
The "ordinary" flags are useless under Windows 5.x and above. The only one that actually does ANYTHING is the hidden flag. The Archive flag doesn't get used for anything anymore and the Read-only flag stopped working when they moved to NTFS, since the FS has ACLs.

#70: In UNIX, Quotas can be set by root only, and are per User or per Group and per Filesystem. So Quotas are a read-only ressource for users, but cannot be edited.

I'd vote for A.  The acl property page shown in the mockup is very straightforward and clear.  

If there is no ACL support, there would just be three entries in that list (user/group/world) that cannot be deleted.  If there is ACL support, you can add new rules to the first 3.

I'm not a huge fan of the traditional property page anyway.  I don't think that a 3 by 3 grid of checkboxes is either pretty or more usable than a list like in the mockup.

@Comment #73: Hi Kristian! What are you doing here? ;-)

Quotas may be set only by root. But the same applies to NFS-Shares and ACLs which where set by root and where the user has no access. You need an "administrator mode" button for this purpose. 

Nonetheless, quotas are part of the filesystem access policy and so there should be some kind of GUI for it, when we also support ACLs and Shares.

I vote for B definately. I think its a mistake to assume that if its enabled on the file system that all users will want to use ACLs for every file and directory. 

They're often (in my experience) only used for special directories (eg. a GNU Arch repository) while you use the normal UNIX permissions for the rest since they're simpler and easier.

I'm still for A: I think it's confusing to show people two different concepts of assigning rights to files if they can be presented in a way so that one is a subset of each other.

However, if the FS supports ACLs but is also shared via Samba or NFS, the ACLs will be respected (at least by Samba) *but* will not (always - depending on mount options?) be visible on the client (so far, at least). But I guess we don't have to care about that, because eventually the network filesystems will have to catch up.

Cheers, and thank you for the hard work!


Jens

You can count this as a vote for option A since I completely agree with Comment 74.

Also, did everyone just skim over my comment, Comment 12?

I fear that the resolution to this bug will create a permissions dialog that's only useful to POSIX ACLs, particularly when there are other ACL paradigms out there.  For example, NDS and AFS aren't well known for conforming to POSIX ACLs, and it would be a shame if the new dialog couldn't handle them.

Also, with a plugin system for ACLs, we can have a default dialog box that works for most ACL systems, but if, like above, some filesystem uses something other than POSIX ACLs, or perhaps the administrator doesn't like the default, she change it.

I would really like to see this happen, but I'd be disappointed if it could only handle POSIX ACLs.

At comment #78: Yes I have been thinking about different plugins fo rthe ACL dialog as we use Novell servers at work and it would be nice to be able to change access rights from within konqy for these file systems.

My long term plan of action is to get a working implementation of a dialog for POSIX ACLs. Then whenI'm happy with this look at converting it to an "ACL plugin" (even though all tab pages are plugins themselves to KProperties dialog). Or if it doesn't make sense to have plugins to a plugin, then to develop more plugins for other types of ACL and then decide at run time which of the ACL tab pages to show depending on which fs the selected files reside on. This could be tricky though since you can mount fs's anywhere, not sure how you would handlean NDS fs mounted in a dir on a reiserfs fs for e.g. Any ideas?

All this is a way off yet though. I'll do some more on the POSIX ACL dialog this weekend.

I vote for Sean Harmers version  A:

To have more than one place to look for file permissions will only lead to misstakes. Posix ACLs is just more of the same thing, so I can't see any
reason to separate them from the rest. It will only lead to support questions, from people not aware of the extra dialog, wondering why permissioins doesn't work.

People, could also make mistakes like writing personal things in files that they by mistake think is readable by them and only them if they don't know of a separate Posix ACL dialog.

One more vote for exactly what Comment 74 describes.  That's the way I've always imagined it working, and I've been imagining and thinking about this in GNOME, KDE, and E-17 for a few years now :)

Great to see someone working on this :D   Any sort of ETA on this?  I guess it hasn't made 3.4?

<AOL-me-too-mode> Just one more vote for A </AOL-me-too-mode>
Consistency rocks!

A

Please just use one dialog for all permissions, my vote goes to option A.

Yes of course one dialog box is better than 36, so I vote A :)

tnagy256@yahoo.fr, your ACL viewer seems like duplicate effort for ACLs in KDE.

Maybe you guys can split the programming load between you.

http://www.kde-apps.org/content/show.php?content=24097

Description:
A small ACL viewer/editor. Editing the Posix Access Control Lists (ACL) is usually done with obscure command-lines (ie: setfacl -m u::7,u:34:4,u:35:6,g:2:1,g:0:7,g:3:4 file.txt). This ACL viewer/editor offers a better visualization.

OK - sorry for the delay, been moving house. Anyway I've checked in some code to trunk/playground/base/acldlg. It's not particularly pretty code, although I think that the dialog looks OK. It's just a very simple app that displays the access ACLs on a list of files passed in on the command line. 

You can alter the existing ACL entries in the dialog, but you can't apply any changes that you make yet. Also, you can't add new entries yet.

Launch the app with "acldlg file1 file2 ... filen".

I'll add some more features this weekend.

oki, good luck :)

Regards,
Thomas

--- Sean Harmer <sean.harmer1@ntlworld.com> a 

SVN commit 424803 by tilladam:

First batch of changes largely extracted from patches by 
György Szombathelyi <gyurco@freemail.hu>, sent to the lists sometime
before 3.2 but sadly ignored, for various reasons. We're not entirely
sure yet that shipping the acls themselves via slave metadata is the
right way to go about things, but we'll start out from here and see
where it takes us. We being KDAB, namely David, Steffen and myself. If
you are actively working on anything related to POSIX ACLs atm, please
get in touch with me/us.

CCMAIL: gyurco@freemail.hu
CCMAIL: 6976@bugs.kde.org


 M  +12 -0     configure.in.in  
 M  +4 -1      kio/kio/global.h  
 M  +36 -0     kio/tests/kioslavetest.cpp  
 M  +1 -0      kio/tests/kioslavetest.h  
 M  +1 -1      kioslave/file/Makefile.am  
 M  +518 -205  kioslave/file/file.cc   [POSSIBLY UNSAFE: system]
 M  +6 -0      kioslave/file/file.h  

Heya folks,

please find attached two patches, one against kdelibs/kioslave/file and one 
against kdelibs/kio, which together implement support for managing POSIX ACLs 
on filesystems that support it. Please review, I'll then merge this into 3.5.

The backend is based off of patches by Gy

This is fantastic! Thank you for doing this! Where do I send the pizza? ;-)

Do you have a screenshot how the dialog looks? Or an UI file?

Thank you for implementing it. It was badly needed.

Looks like this: http://kdab.net/~till/kacl-dialog.png

The "special" checkboxes should probably be laid out horizontally now that they are
the only ones left, to give more room to the listview below.

Yep, I'm currently cheating and simply hiding the others, but I guess I need to lay them out myself.

*** Bug 110411 has been marked as a duplicate of this bug. ***

SVN commit 455966 by tilladam:

Finally merge the acl editing from the working branch. Please test, I'll
polish it over the coming days, now that I finally have some time for
it. Yes, binner, I know there are style guide violations, I will fix
them. The other pending issue is making the icons themeable.

Coordinated with coolo.

BUG: 6976


 M  +8 -0      configure.in.bot  
 M  +13 -0     configure.in.in  
 M  +1 -1      kio/Makefile.am  
 M  +2 -2      kio/kfile/Makefile.am  
 A             kio/kfile/images.h   [License: no copyright GENERATED FILE]
 A             kio/kfile/kacleditwidget.cpp   [License: GPL (v2+) (wrong address)]
 A             kio/kfile/kacleditwidget.h   [License: GPL (v2+) (wrong address)]
 A             kio/kfile/kacleditwidget_p.h   [License: GPL (v2+) (wrong address)]
 M  +111 -37   kio/kfile/kpropertiesdialog.cpp  
 M  +8 -2      kio/kio/Makefile.am  
 M  +7 -0      kio/kio/chmodjob.cpp  
 M  +12 -2     kio/kio/global.h  
 A             kio/kio/kacl.cpp   [License: LGPL (v2+) (wrong address)]
 A             kio/kio/kacl.h   [License: LGPL (v2+) (wrong address)]
 M  +49 -10    kio/kio/kfileitem.cpp  
 M  +22 -0     kio/kio/kfileitem.h  
 A             kio/tests/kacltest.cpp   [License: LGPL (v2+) (wrong address)]
 A             kio/tests/kacltest.h   [License: LGPL (v2+) (wrong address)]
 M  +226 -35   kioslave/file/file.cc  
 M  +6 -1      kioslave/file/file.h  

Out of curiosity, has anyone tested it yet? It's in the 3.5 beta1, so I'd appreciate any feedback you guys can give me, so I have a chance to resolve outstanding issues in time for 3.5 final. Thanks.

Hello,
I just upgraded to KDE 3.5 (OpenSuSE 10.0 supplementary update) and the ACL dialog seems to work fine. Great work! :-)

However, since KDE 3.5 uses its own IO protocols heavily (ie. for the /boot directory Konqueror shows "system:/media/hda1/boot", for the home directory it shows "system:/home", etc) it should also work on those kinds of URLs. Is it possible / easy to implement this?

Jens

Can you please file a new wish for this, Jens? I'll have a look for KDE 4.