it grep output of mount and as there is nothing even acl is written in the fstab, in goes into a loop

CC: (none) => mageia, tmb
Summary: parental control => parental control does not work, (acl is not added is the mounted partition)

s/even/even if/ s/in/it/

FWIW, acl option shouldn't be needed on ext4 IIRC.

No idea about the parental control stuff tho'.

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

CC: (none) => anantg

Problem appears to be only present on systems with only ext4 partitions. ext3 or ext3 with ext4 systems do not show the problem.

drakguard tests for acl support by parsing the output of a 'mount' command. If any partition is listed with acl support then drakguard is satisfied. 

However ext4 partitions do not list acl in their mount parameters regardless of whether acl is enabled in fstab. I think this is because the Mageia kernel has CONFIG_EXT4_FS_POSIX_ACL kernel configuration set.

A second circumstance which will confuse drakguard exists when fstab contains a comment line containing the string 'ext'. The regex in drakguard is not smart enough to realise it is a comment.

CC: (none) => derekjenn

Oh wow you gave a nice explanation. Thanks for your help and your work around works very well. Thanks alot

(In reply to Anant Gowerdhan from comment #6)
> Oh wow you gave a nice explanation. Thanks for your help and your work
> around works very well. Thanks alot

more about djennings's workarounds here
https://forums.mageia.org/en/viewtopic.php?f=7&t=4528&p=31979#p31977
and here
https://forums.mageia.org/en/viewtopic.php?f=7&t=4528&p=31979#p31969

CC: (none) => marja11

Created attachment 3615 [details]
Add acl option only for ext2/3 or reiserfs file systems

This proposed patch works for me.
It ignores commented out lines, and only sets the acl option for ext2, ext3, or reiserfs  partitions.
ext4 and btrfs partitions have acl implicitly enabled in the kernel so do not need the acl option.

Derek, The Patch didn't work.

Fixed in SVN.
(http://svn.mandriva.com/viewvc/soft/drakguard/trunk/)
Can you check?

Keywords: (none) => NEEDINFO

(In reply to Thierry Vignaud from comment #10)
> Fixed in SVN.
> (http://svn.mandriva.com/viewvc/soft/drakguard/trunk/)
> Can you check?

mandriva? ;)

or here:

http://svnweb.mageia.org/soft/drakguard/trunk/

The later of course

Sorry, that does not work.

Line 299
if (cat_('/boot/config') =~ /_FS_POSIX_ACL=y/ || grep { $_ && !/acl/ } chomp_(cat_($fstab_file)) && grep { $_ && !/^#/ && m/ext/ } chomp_(cat_($fstab_file)))

returns true even when the acl option is present in fstab

and Line 316
    if (grep { /,acl/ } @mount) {

still has the problem that the mount command never lists acl for ext4 partitions
 so this test always fails.

Hi,

I tried the patch but it doesn't work, I still have the loop. I have four ext4 partitions (with acl option), two nfs, one ntfs (Windows) and the swap. No commented lines.

CC: (none) => lebarhon

(In reply to André DESMOTTES from comment #14)
> Hi,
> 
> I tried the patch but it doesn't work, I still have the loop. I have four
> ext4 partitions (with acl option), two nfs, one ntfs (Windows) and the swap.
> No commented lines.

To make it more clear, André talked about attachment 3615 [details]

https://ml.mageia.org/l/arc/doc-discuss/2013-04/msg00000.html (reload after confirming you're not a spammer)

>
> Which one did you try, the one that is attached to the bug report, or the one
> that Thierry committed? IINM they are different
>
>
The one that is attached to the bug report

Well, to be clear, if the system is installed on an ext4 partition, this message is useless because this option does not concern a system installed on an ex4 partition ?
If so, the problem should be simply resolved by removing the concerned part in the appropriate file, isn't it ?

Version: Cauldron => 3
CC: (none) => guillaume.ber17

Hi,
i try your solution. but there is another problem, when parental control is active you can make a research whith google, you have results but when you click on all the link in the page you can't connect the site.... 
have you got a solution?

CC: (none) => tthunot

this is the message that firefox send when i want to go to the result link


ERROR
The requested URL could not be retrieved

L'erreur suivante s'est produite en essayant d'accéder à l'URL : http://fr.yahoo.com/_ylt=A03uvwmpCq1RhrgAx1RNhJp4/RV=1/RE=1371504554/RH=ZnIueWFob28uY29t/RO=2/RU=aHR0cDovL2ZyLnNwb3J0cy55YWhvby5jb20vdmlkZW8vbW9uYWNvLXBzZy1mYWxjYW8tcGx1cy1mb3J0LTE0NTYwNDk5NC5odG1s/RS=%5EADAruNnv.MxvLXeuzyeMC1jkA3_bDs-

    Accès interdit.

La configuration du contrôle d'accès, empêche votre requête d'être acceptée. Si vous pensez que c'est une erreur, contactez votre fournisseur d'accès.

Votre administrateur proxy est root.

Générer le Mon, 03 Jun 2013 21:32:35 GMT par unconfigured (squid/3.2.10)

i use mageia 2 squid package then parental control is ok on mageia3....

Squid does not start automatically it is blocked by the icapd.service which not start. At the end of the timeout squid start and works but with packages of the version 2

SRPMS  drakguard-0.7.11-1.mga3.src.rpm
       drakguard-0.7.11-1.mga2.src.rpm

RPMS   drakguard-0.7.11-1.mga2.noarch.rpm
       drakguard-0.7.11-1.mga3.noarch.rpm

Updates are mga2 and mga3 core/updates_testing
Packages are 'noarch' so there is no need to test different architectures.


Advisory
========
This is a bugfix update to allow drakguard to use local time when setting internet blackout periods, and to corret a bug when enabling Access Control Lists on ext4 file systems.

Test Procedure
-------------
Part 1 - Ensure ACL can be set on ext4 partitions. Bug9195
--------------------------------------------------

Requirement - Computer with at least one ext4 or btrfs partition.

1/ Before upgrading drakguard start the old version and observe how you get a pop up message saying ACL must be enabled. After enabling ACL you are instructed to reboot and on starting drakguard again you see the same message.

2/ Edit /etc/fstab and remove the option .acl  from any hard drive partition on which it appears. There is no need to reboot or remount the partitions.

3/ Install drakguard-0.7.11-1 from core/updates_testing, and start it.

4/ If all your partitions are ext4 or btrfs then you should not see any pop up and you are ready to start using drakguard.

5/ If you have one or more partitions that are ext2, ext3, or reiserfs you should see the pop up offering to set acl. Select 'Yes'. Before rebooting examine /etc/fstab and observe that any line for an ext2/3 or reiserfs partition now has ,acl set as an option.

6/ reboot and start drakguard again. You should now not see any pop up and you are ready to test ACL command blocking.

7/ Check the 'enable parental control' box and select the 'Block Programs' Tab.
Add the command /usr/bin/ping  to the list of blocked programs and select 'OK'

8/ Open a terminal and try to ping another computer (Do this as your user NOT as root)
$ ping google.com
bash: /usr/bin/ping: Permission denied

9/ Now unblock the ping command and observe it works again.


Part 2 - Testing setting blackout periods with local time Bug 6400
---------------------------------------------------------

1/ Determine your offset from UTC with the commands
date -u 
date 

2/ Open drakguard - Set the checkboxes to 'enable parental control' and 'Time Control'. Select your user to have network access in the user Access box.

3/ If you are WEST of UTC (your time is less than UTC) set the start time to be some hours in the past, and the end time  to be a few minutes in the future (local time) and select OK

4/ Confirm you still have network access.

5/ Wait until one minute past the end time, and try again. Your user access should now be blocked.

If you are EAST of UTC, then proceed as above but set the Start time to be a few minutes in the future and check service starts at that time.

Part 2 Complete.

Keywords: NEEDINFO => (none)
Assignee: bugsquad => derekjenn

Testing complete Mageia 3 i586.

I followed the procedure from comment 21, thanks Derek!
I did not really understand the different expected behaviour for users East or West of UTC, but for me the network restriction worked as expected: I gave me a timespan of 3 minutes of network (local time, which is UTC+2 for me), and after that the network was blocked.

Whiteboard: MGA2TOO => MGA2TOO has_procedure MGA3-32-OK

(In reply to Rémi Verschelde from comment #22)
> I did not really understand the different expected behaviour for users East
> or West of UTC, but for me the network restriction worked as expected: I

Sorry if I confused you there  Rémi. The object was to make sure there was no overlap between the access window and UTC so we can be sure it is working on local time.  I was probably being too anal.

(In reply to Derek Jennings from comment #23)
> 
> Sorry if I confused you there  Rémi. The object was to make sure there was
> no overlap between the access window and UTC so we can be sure it is working
> on local time.  I was probably being too anal.

No problem, now I understand :)
Another way is to test with a timespan < 1h as I did, since no countries are in UTC±½ ;)

CC: (none) => remi

Hello,

With mga2 64b and Cauldron 64b, drakguard 0.7.11 doesn't solve the ACL loop problem.

/ ext4
/home ext4
/media/windows ntfs-3g
/mnt/documents nfs
/mnt/multimedia nfs

no acl option in fstab.

(In reply to André DESMOTTES from comment #25)
> Hello,
> 
> With mga2 64b and Cauldron 64b, drakguard 0.7.11 doesn't solve the ACL loop
> problem.
> 
> / ext4
> /home ext4
> /media/windows ntfs-3g
> /mnt/documents nfs
> /mnt/multimedia nfs
> 
> no acl option in fstab.


Yep. In an ext 4 only environment you get a recurring "enabled but not activated message"  hold off testing while I fix it.  Thanks

New packages in Updates testing soon

SRPMS  drakguard-0.7.14-1.mga3.src.rpm
       drakguard-0.7.14-1.mga2.src.rpm

RPMS   drakguard-0.7.14-1.mga3.noarch.rpm
       drakguard-0.7.14-1.mga2.noarch.rpm

These packages should fix the recurring message in an ext4 only environment described in comment 25

In addition two other bugs are fixed
Bug 7775 interferences between urpmi and parental control (drakguard)
Bug 10513 Parental control does not work with squid 3.2

New Advisory
------------
This is a bugfix update to fix a number of bugs in drakguard.
mga 6400 -Use local time when setting internet blackout periods.
mga 9195 -ACL on ext4 partitions.
mga 7775 -Allow urpmi network access when parental controls enabled.
mga 10513 -Allow drakguard to work with squid 3.2

Test Procedure
---------------
As described in comment 21 with the addition of tests for mga7775 and mga10513

mga7775 test
------------
Install the text based browser 'links'
Prior to installing drakguard-0.7.14-1 enable parental controls and check the box to 'block all network traffic'
Open a terminal and enter su to become root user.
Enter 'links http://www.mirrorservice.org/pub/mageia.org'  Observe in links you can see that connection has been blocked.
Remove the connection block in drakguard.

Install drakguard-0.7.14-1 and repeat
Observe that links now shows you can access the site 

mga 10513 test
--------------
In Mageia 3 prior to installing drakguard-0.7.14-1 enable parental control in drakguard. Do NOT check 'block all traffic'

With a browser, browse to the test page http://dansguardian.org/downloads/test.zip

Observe that you do you see the blue blocking screen from dansguardian. Instead you see a grey error page. The small text at the bottom indicates it is coming from squid.
Disable drakguard. Upgrade to drakguard-0.7.14-1 and repeat.
Observe you now see the blue page from dansguardian.

Mageia 2 should work OK with both old and new versions of drakguard.

Advisory 9195.adv uploaded to svn.

CC: (none) => davidwhodgins

Testing complete on Mageia 3 x86_64. Testing Mageia 2 shortly.

Keywords: (none) => validated_update
Whiteboard: MGA2TOO has_procedure MGA3-32-OK => MGA2TOO has_procedure MGA3-32-OK MGA3-64-OK
CC: (none) => sysadmin-bugs

Testing complete on Mageia 2. Could someone from the sysadmin team
push 9195.adv to updates.

Whiteboard: MGA2TOO has_procedure MGA3-32-OK MGA3-64-OK => MGA2TOO has_procedure MGA3-32-OK MGA3-64-OK MGA2-64-OK MGA2-32-OK

http://advisories.mageia.org/MGAA-2013-0068.html

Status: ASSIGNED => RESOLVED
CC: (none) => boklm
Resolution: (none) => FIXED

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

CC: (none) => daniel.bezivin