On Wednesday 04 April 2007 23:54, Kai Makisara wrote: > On Wed, 4 Apr 2007, Kern Sibbald wrote: > > > On Wednesday 04 April 2007 20:46, Kai Makisara wrote: > ... > > > > > c. There is a real lack of information about any error condition > > > > > (read/write). One can probably get it via direct SCSI commands, > > but > > > > > why not through an ioctl. > > > > > > This is true. The problem is what and how to tell the user so that the > > > solution is satisfactory for a reasonable number of years. The solutions I > > > have thought about have not passed this test. One alternative is to pass > > > the latest sense data to the user but thinking about the different error > > > conditions, this is a problematic choice. Here also suggestions from and > > > discussion with real users is needed. > > > > Well, you have in front of you a "real" user. > > Yes, you are one of the people I meant with "real users". OK, I'll address this issue in my "second" description that I mention below. > > > I was thinking about a new > > ioctl() that would hopefully be simple, generic, and extensible enough that > > it might be picked up by all Unixes. This is one case were even if it is a > > Linux only solution, I will be really happy. Basically, when I get a -1 > > return from a read/write and ERRNO=EIO, I would like to be able to call an > > ioctl() and get back some basic info about soft errors, hard errors, ... If > > you don't tell me that a new ioctl() is out of the question, I'll make a > > proposal -- it will take me some time to put it together. > > > The general attitude seems to be against new ioctls but I don't want to > rule out that. The mt interface already uses ioctls and they solve the > serialisation problem nicely in this case. > > Whatever the method of delivery will be, the most difficult question is > the contents and format. I don't know any good examples from other > systems, so it has to be Linux-specific (and hopefully adopted by others > as you say). I will wait with interest for your suggestion. OK, I don't think that I have the knowledge of the kernel to be able to make a specific proposal, but I will do the following (unless someone suggests otherwise). First explain to everyone the pains that were caused with the O_NONBLOCK change to opening tape drives. I don't imagine we will go back to the old behavior, but I hope something similar won't happen again, and will propose how a slight change in philosophy could have created less chaos. This I can do in the next few days. Second, I can describe what would be a reasonably complete tape interface from the applications programmers point of view (i.e. Bacula), and how I think we might get there given your input above -- my basic premise is that there does not exist any real Unix tape API, but rather a whole slew of different ioctls on different systems, making applications programming difficult. I think we need a real Unix tape API, but not necessarily a lot more ioctls. This will take at least a week (I think). > > ... > > > > > e. Apparently only root can do the following (IMO, this is a bug or > > > > > programming oversight): > > > > > > > > > > struct mtop mt; > > > > > mt.mt_op = MTSETDRVBUFFER; > > > > > mt.mt_count = MT_ST_CLEARBOOLEANS; > > > > > mt.mt_count |= MT_ST_FAST_MTEOM; > > > > > ... > > > > > ioctl(fd, MIOCTOP, &mt); > > > > > > > > > > Typically Bacula runs tape daemon as non-root. Is there a good > > reason > > > > > why program that has write permission on the device cannot do > > this > > > > > ioctl() and is it possible to change this? > > > > > > > > This is not a bug or an oversight, it is a design decision. The idea is > > > that the system provides the same view of the tape to all users. This view > > > is defined by the system manager (probably with startup scripts). If each > > > user can change the behaviour, the next user never knows what to expect. > > > > Well, I agree that all users should have the same view. However, when Bacula > > has the drive open, it has it open exclusively, so no other users can view > > the drive. When Bacula opens the drive, it should be able to ensure that the > > drive, agrees with Bacula's concept of the drive. When Bacula closes the > > drive, I have no problem if the OS resets values to the common view. Today, > > if Bacula is running as bacula:disk rather than root:root, it cannot make the > > above changes, even if the disk group has write access to the drive. > > OK. I have not thought about this properly but one possible solution might > be something like this: > - separate the current and permanent behaviour flags; the current flags > define the behaviour > - the permanent flags are copied into the current flags when the device is > opened (or at some other well-defined point) > - the booleans set with MTSETDRVBUFFER change always the current flags; if > the user has CAP_SYS_ADMIN, also the permanent flags are changed > > This would enable anyone to change the behaviour for his/her own purposes > but there would still be a stable system-defined behaviour. There already > are attributes that have a current and default value like block size. > > I can see several problems in the details of this suggestion but I will > think about those. One is that if someone having CAP_SYS_ADMIN wants just > a temporary change, it is not possible. A solution would to have a new > op code for temporary changes but this would require explicit changes to > programs. Comments are welcome. The above would solve the problem for me. Today, when root (or someone having CAP_SYS_ADMIN) does a MTSETDRVBUFFER, doesn't it alter the permanent flags? I think we should look at how the other flags are set under various permissions and try to get the MTSETDRVBUFFER to follow the same rules. The basic problem I see with MTSETDRVBUFFER is that it requires CAP_SYS_ADMIN, while the other ones (e.g. MTSETBLK) do not (i.e. an inconsistency). If they all work the same and permit changes without CAP_SYS_ADMIN, then the rules will be much easier for everyone to understand. > > ... > > > Strictly speaking MTSETDRVBUFFER does not need root privileges. It needs > > > CAP_SYS_ADMIN. (Now I see that the error message is misleading and must be > > > fixed.) Does using some other capability make your use easier but, at same > > > time, limit the access to this command to a selected group of users? > > > > Being relatively ignorant of the kernel, I wasn't aware of CAP_SYS_ADMIN. I > > now have a rough idea of what it is, I am unsure if another capability would > > resolve the problem, because I'm not familar with how they are set. > > > Yes, setting the capabilities may be a problem. I don't know how well the > different distributions are able to handle these finer-grained rights. > A software package has to support ideally all distributions and the common > denominator may be to be root for CAP_SYS_ADMIN ;-) To the best of my knowledge Linux is the only system that requires root; this is true at least for the values that Bacula sets. I've only been adding such OS dependent functions for a year or so to attempt to reduce support problems (i.e. making Bacula "self-configure" tape drives to a limited extent). Requiring root permission to configure the tape drive is for Bacula a security problem and thus probably not the best solution. > > > It seems to me that anyone who is the "owner" or in the "group" and has write > > permission on the device should be able to do MTSETDRVBUFFER. There is no > > need for any "other" who has write permission to have such access. I think > > this would allow the sys admin to restrict it appropriately. > > > This would be one solution but it sounds complicated. The primary test for > a file is just if there is write access or not. It does not matter if the > access right comes as user, group, or other. Yes, I can see that would be complicated, and probably not possible, but from an applications (my) stand point, it seems reasonable. > > > > > Thanks for your responses. I see I have some work to do organizing my > > thoughts :-) > > Thanks for your input. > > -- > Kai > - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
