* sysfs mount point permissions in 2.5.64
@ 2003-03-05 21:47 Douglas Gilbert
2003-03-05 23:08 ` Patrick Mochel
0 siblings, 1 reply; 3+ messages in thread
From: Douglas Gilbert @ 2003-03-05 21:47 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-scsi
In lk 2.5.64 on my i386 box the sysfs mount point
( "/sys") changes permission from:
drwxr-xr-x
to
drw-r--r--
during the boot process. I didn't notice this feature
in lk 2.5.63 . Chmodding the directory back to its former
permissions get overridden by subsequent boot sequences.
This change in permissions inhibits non-root users from using
utilities that scan sysfs for information (e.g. lsscsi).
Is this a feature or otherwise?
Doug Gilbert
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: sysfs mount point permissions in 2.5.64
2003-03-05 21:47 sysfs mount point permissions in 2.5.64 Douglas Gilbert
@ 2003-03-05 23:08 ` Patrick Mochel
2003-03-06 22:22 ` Douglas Gilbert
0 siblings, 1 reply; 3+ messages in thread
From: Patrick Mochel @ 2003-03-05 23:08 UTC (permalink / raw)
To: Douglas Gilbert; +Cc: linux-kernel, linux-scsi
On Thu, 6 Mar 2003, Douglas Gilbert wrote:
> In lk 2.5.64 on my i386 box the sysfs mount point
> ( "/sys") changes permission from:
> drwxr-xr-x
> to
> drw-r--r--
> during the boot process. I didn't notice this feature
> in lk 2.5.63 . Chmodding the directory back to its former
> permissions get overridden by subsequent boot sequences.
>
> This change in permissions inhibits non-root users from using
> utilities that scan sysfs for information (e.g. lsscsi).
>
> Is this a feature or otherwise?
This is certainly not intended, and is entirely my fault. The patch below
should fix it.
-pat
===== fs/sysfs/mount.c 1.5 vs edited =====
--- 1.5/fs/sysfs/mount.c Tue Mar 4 12:17:14 2003
+++ edited/fs/sysfs/mount.c Wed Mar 5 17:06:25 2003
@@ -33,7 +33,7 @@
sb->s_op = &sysfs_ops;
sysfs_sb = sb;
- inode = sysfs_new_inode(S_IFDIR | S_IRUGO | S_IWUSR);
+ inode = sysfs_new_inode(S_IFDIR | S_IRWXU | S_IRUGO | S_IXUGO);
if (inode) {
inode->i_op = &simple_dir_inode_operations;
inode->i_fop = &simple_dir_operations;
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: sysfs mount point permissions in 2.5.64
2003-03-05 23:08 ` Patrick Mochel
@ 2003-03-06 22:22 ` Douglas Gilbert
0 siblings, 0 replies; 3+ messages in thread
From: Douglas Gilbert @ 2003-03-06 22:22 UTC (permalink / raw)
To: Patrick Mochel; +Cc: linux-kernel, linux-scsi
Patrick,
Thanks. That patch fixed the problem I reported.
Doug Gilbert
Patrick Mochel wrote:
> On Thu, 6 Mar 2003, Douglas Gilbert wrote:
>
>
>>In lk 2.5.64 on my i386 box the sysfs mount point
>>( "/sys") changes permission from:
>> drwxr-xr-x
>>to
>> drw-r--r--
>>during the boot process. I didn't notice this feature
>>in lk 2.5.63 . Chmodding the directory back to its former
>>permissions get overridden by subsequent boot sequences.
>>
>>This change in permissions inhibits non-root users from using
>>utilities that scan sysfs for information (e.g. lsscsi).
>>
>>Is this a feature or otherwise?
>
>
> This is certainly not intended, and is entirely my fault. The patch below
> should fix it.
>
> -pat
>
> ===== fs/sysfs/mount.c 1.5 vs edited =====
> --- 1.5/fs/sysfs/mount.c Tue Mar 4 12:17:14 2003
> +++ edited/fs/sysfs/mount.c Wed Mar 5 17:06:25 2003
> @@ -33,7 +33,7 @@
> sb->s_op = &sysfs_ops;
> sysfs_sb = sb;
>
> - inode = sysfs_new_inode(S_IFDIR | S_IRUGO | S_IWUSR);
> + inode = sysfs_new_inode(S_IFDIR | S_IRWXU | S_IRUGO | S_IXUGO);
> if (inode) {
> inode->i_op = &simple_dir_inode_operations;
> inode->i_fop = &simple_dir_operations;
>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2003-03-06 23:12 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-03-05 21:47 sysfs mount point permissions in 2.5.64 Douglas Gilbert
2003-03-05 23:08 ` Patrick Mochel
2003-03-06 22:22 ` Douglas Gilbert
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).