linux-kernel - Re: [PATCH 25/20] sysfs: Only support removing emtpy sysfs directories.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m1bppid1pw.fsf@fess.ebiederm.org>
Date:	Sun, 24 May 2009 07:17:47 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Kay Sievers <kay.sievers@...y.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	linux-kernel@...r.kernel.org, Tejun Heo <tj@...nel.org>,
	Cornelia Huck <cornelia.huck@...ibm.com>,
	linux-fsdevel@...r.kernel.org,
	"Eric W. Biederman" <ebiederm@...stanetworks.com>
Subject: Re: [PATCH 25/20] sysfs: Only support removing emtpy sysfs  directories.

Kay Sievers <kay.sievers@...y.org> writes:

> On Sat, 2009-05-23 at 23:27 +0200, Kay Sievers wrote:
>> On Sat, May 23, 2009 at 22:13, Eric W. Biederman <ebiederm@...ssion.com> wrote:
>> > From: Eric W. Biederman <ebiederm@...ssion.com>
>> >
>> > I have looked and I have not found a single legitimate case today where
>> > we remove sysfs directories with anything in them.  The only case I have
>> > found to date was a bug.  It was a problem of ownership.  The files in
>> > the directory where not owned by the directory itself.   Leaving open
>> > the potential for double deletion of the directory contents.
>> >
>> > Signed-off-by: Eric W. Biederman <ebiederm@...stanetworks.com>
>> 
>> Sounds good to me. We should try that, and see if there was any valid
>> use case we didn't think of, and if not, it's good to do what this
>> patch does.
>
> I get a bunch of warnings here. The question is if the users should be
> fixed, the warning removed, and/or the auto-deletion added back?

Thanks for finding these.  I was afraid I hadn't look far enough.
To see if non-empty directories were a problem.

Most of these look like attributes, for which the non-empty directory
removal was correct.  Although I am puzzled by why we missed them.

host4/target4:0:0 worries me.  I don't have my head wrapped around
what that is yet.  But is looks like is a directory (which we currently
do not handle correctly), and even more it looks like that is quite
possibly two kobjects in a parent/child situation where the child
was not removed when the child was.

It definitely warrants more investigation.

....

Let's make the plan to investigate these, and see how hard it would be
to actually remove these with the current device/sysfs infrastructure.

Fixing the users and adding back auto-deletion are the only two real options.

I expect we have uncovered at least one more real bug.  So I am inclined
to make the policy that we fix the users.

> I've added:
>   -       WARN(dir_sd->s_dir.children,
>   -               KERN_WARNING "sysfs: removing non-empty dir: %s\n",
>   -               dir_sd->s_name);
>   +       if (dir_sd->s_dir.children) {
>   +               struct sysfs_dirent *sd;
>   +
>   +               WARN(dir_sd->s_dir.children,
>   +                       KERN_WARNING "sysfs: removing non-empty dir: %s\n",
>   +                       dir_sd->s_name);
>   +               sd = dir_sd->s_dir.children;
>   +               while (sd) {
>   +                       printk(KERN_WARNING "%s/%s\n", dir_sd->s_name, sd->s_name);
>   +                       sd = sd->s_sibling;
>   +               }
>   +       }
>
> And get non-empty directories from CPU, SCSI, firmware_class, sound, block:
>   sysfs: removing non-empty dir: state0
>   state0/name
>   state0/desc
>   state0/latency
>   state0/power
>   state0/usage
>   state0/time
>
>   sysfs: removing non-empty dir: 0000:03:00.0
>   0000:03:00.0/data
>   0000:03:00.0/loading
>
>   sysfs: removing non-empty dir: iosched
>   iosched/quantum
>   iosched/fifo_expire_sync
>   iosched/fifo_expire_async
>   iosched/back_seek_max
>   iosched/back_seek_penalty
>   iosched/slice_sync
>   iosched/slice_async
>   iosched/slice_async_rq
>   iosched/slice_idle
>
>   sysfs: removing non-empty dir: queue
>   queue/nr_requests
>   queue/read_ahead_kb
>   queue/max_hw_sectors_kb
>   queue/max_sectors_kb
>   queue/scheduler
>   queue/hw_sector_size
>   queue/rotational
>   queue/nomerges
>   queue/rq_affinity
>   queue/iostats
>
>   sysfs: removing non-empty dir: 4:0:0:0
>   4:0:0:0/queue_depth
>   4:0:0:0/queue_type
>   4:0:0:0/max_sectors
>
>   sysfs: removing non-empty dir: host4
>   host4/target4:0:0
>
>   sysfs: removing non-empty dir: pcmC1D0c
>   pcmC1D0c/pcm_class
>
>   sysfs: removing non-empty dir: card1
>   card1/id
>   card1/number

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/