Bug 525800 - smartctl displays misleading error msg started as user
Summary: smartctl displays misleading error msg started as user
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: smartmontools
Version: 14
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Michal Hlavinka
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-25 19:41 UTC by Stas Sergeev
Modified: 2011-11-09 14:01 UTC (History)
1 user (show)

Fixed In Version: smartmontools-5.41-1.fc14
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-11-09 14:01:17 UTC


Attachments (Terms of Use)

Description Stas Sergeev 2009-09-25 19:41:23 UTC
Description of problem:
smartctl doesn't seem to work when started as user,
even though this user has the rw access to the device
node.
---
$ ls -l /dev/sda
brw-rw---- 1 root disk 8, 0 Сен 26  2009 /dev/sda
$ id
uid=500(stas) gid=500(stas) группы=6(disk),14(uucp),50(ftp),54(lock),500(stas),505(audio)
$ smartctl -a /dev/sda
smartctl version 5.38 [x86_64-redhat-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/
Probable ATA device behind a SAT layer
Try an additional '-d ata' or '-d sat' argument.
$ su -c "smartctl -a /dev/sda"
smartctl version 5.38 [x86_64-redhat-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/
=== START OF INFORMATION SECTION ===
[then the proper output]
---

Version-Release number of selected component (if applicable):
smartmontools-5.38-13.fc11.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Make sure you have the rw access to /dev/hda
by adding yourself into a "disk" group
2. Run smartctl -a /dev/sda as user
  
Actual results:
Totally misleading error message.

Expected results:
Proper output.

Additional info:
Note the completely misleading error message. It
suggests '-d ata' or '-d sat', which doesn't work
at all.

Comment 1 Michal Hlavinka 2009-10-06 07:34:36 UTC
unfortunately, SMART functions requires more than rw access to device. Used ioctl functions requires root privileges.

Comment 2 Stas Sergeev 2009-10-06 07:43:53 UTC
OK, but at least please fix the error
message then. It suggests '-d ata' or '-d sat',
which doesn't help at all. It was quite
accidentally that I figured out about the
privs.
I'll keep that bug opened for now. If you
feel the message is not worth fixing, then
you can close it again.
Btw, why the ioctls on the device require
more privs than writing to it, is this
intentional?

Comment 3 Michal Hlavinka 2009-10-06 08:06:55 UTC
Well, the problem is ioctl returns the same return code for not enough permissions and for the situations where '-d something' should be used. That's the reason why 'Probable' and 'Try' are used in the error message.

I'm not sure why ioctl requires more privs than writing. This code lays in kernel side and I would only guess.

I'll look at that error message if there is any way if it can be distinguished and fix/close this bug depending on the result.

Comment 4 Stas Sergeev 2009-10-06 18:52:43 UTC
OK, so this is an SG_IO ioctl
returning -EFAULT, nice... "man ioctl"
doesn't even suggest the -EPERM can
be returned. I think ioctl() never
fails with -EPERM because the r/w
access should be sufficient. And
returning -EFAULT instead looks very
wrong.
So I wonder whether it would be good
to just leave smartctl as is.
ioctl() seems to behave wrongly instead,
so maybe the hint from some kernel guru
can help.

Comment 5 Michal Hlavinka 2009-10-07 11:42:05 UTC
I've been talking with kernel guys.

SQ_IO (and other ioctl) needs different privileges for different actions. For some actions you need only read perm, for some you need write perm, but for some you need CAP_SYS_RAWIO, which is available only to root (but even root does not have CAP_SYS_RAWIO capability always if this capability was removed from him by any parent process).

Comment 6 Stas Sergeev 2009-10-07 17:28:10 UTC
Would it be possible to return -EPERM
then? -EFAULT looks really wrong...

By the way, if you have the write perm
to the drive node, like /dev/sda, then
you already ignore everything on that
drive, including its filesystem with
permissions, partition table, and etc.
So is there anything this extra priv
requirement guards against?

Comment 8 Bug Zapper 2010-04-28 10:34:43 UTC
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 9 Stas Sergeev 2010-04-28 10:51:23 UTC
This should really better be fixed.
Or re-assign this to kernel?

Comment 10 Michal Hlavinka 2010-04-28 12:18:59 UTC
oops, this slipped out of my circular todo list

> So is there anything this extra priv
> requirement guards against?

with write perm. you can modify the data on that drive, but still you can't affect state of that drive

From kernel pov, what I was looking for answers, this error code is somehow shared and can't fit everyone.

Anyway, there is bug report filled upstream, so maybe they can make (at least) some parts working maybe. Lets wait for their opinion.

http://sourceforge.net/apps/trac/smartmontools/ticket/61

Comment 11 Bug Zapper 2010-11-04 09:49:28 UTC
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 12 Michal Hlavinka 2011-11-09 14:01:17 UTC
$ smartctl -a /dev/sda
smartctl 5.42 2011-10-20 r3458 [x86_64-linux-3.1.0-7.fc16.x86_64] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

Smartctl open device: /dev/sda failed: Permission denied


Note You need to log in before you can comment on or make changes to this bug.